Resposta da pergunta: O Ethereum deveria concordar em consagrar mais coisas no protocolo?
Autor original: Vitalik Buterin
Tradutor diário do planeta Odaily | Nian Yin Si Tang
Agradecimentos especiais a Justin Drake, Tina Zhen e Yoav Weiss pelo feedback e avaliação.
Desde o início do projeto Ethereum, tem havido uma forte filosofia de tentar tornar o núcleo do Ethereum o mais simples possível e conseguir isso tanto quanto possível através da construção de protocolos em cima dele. No espaço blockchain, o debate “construir em L1” versus “foco em L2” é muitas vezes pensado principalmente como uma questão de escalabilidade, mas na verdade, existem questões semelhantes no atendimento às necessidades de vários usuários do Ethereum: troca de ativos digitais, privacidade , nomes de usuário, criptografia avançada, segurança de conta, resistência à censura, proteção frontal e muito mais. No entanto, tem havido algumas tentativas recentes e cautelosas de consagrar mais desses recursos no protocolo principal do Ethereum.
Esta postagem se aprofundará em alguns dos raciocínios filosóficos por trás da filosofia original de encapsulamento mínimo, bem como em algumas maneiras recentes de pensar sobre essas ideias. O objetivo será começar a construir uma estrutura para identificar melhor possíveis alvos onde encapsular determinada funcionalidade pode valer a pena considerar.
Filosofia inicial sobre minimalismo de protocolo
No início da história do que era então conhecido como “Ethereum 2.0”, havia um forte desejo de criar um protocolo limpo, simples e bonito que tentasse construir o mínimo possível por conta própria e deixasse quase todo esse trabalho para os usuários. O ideal é que o protocolo seja apenas uma máquina virtual, e a verificação de um bloco seja apenas uma chamada de máquina virtual.
Esta é uma reconstrução aproximada de um diagrama de quadro branco que Gavin Wood e eu desenhamos no início de 2015, quando eu estava falando sobre como seria o Ethereum 2.0.
A “função de transição de estado” (a função que processa um bloco) será apenas uma única chamada de VM, e toda a outra lógica acontecerá por meio de contratos: alguns contratos em nível de sistema, mas principalmente contratos fornecidos pelo usuário. Um recurso muito interessante desse modelo é que até mesmo um hard fork inteiro pode ser descrito como uma única transação para o contrato do processador de bloco, que será aprovado pela governança off-chain ou on-chain e então executado com permissões atualizadas.
Essas discussões em 2015 são particularmente aplicáveis a duas áreas que consideramos: abstração e dimensionamento de contas. No caso de dimensionamento, a ideia é tentar criar uma forma de dimensionamento o mais abstrata possível que pareça uma extensão natural do diagrama acima. Os contratos podem chamar dados que não são armazenados pela maioria dos nós Ethereum, e o protocolo detectará isso e resolverá a chamada por meio de alguma função de computação estendida muito geral. Da perspectiva da VM, a chamada irá para um subsistema separado e, magicamente, retornará a resposta correta algum tempo depois.
Exploramos brevemente essa linha de pensamento, mas rapidamente a abandonamos porque estávamos muito focados em provar que qualquer tipo de dimensionamento de blockchain era possível. Embora, como veremos mais tarde, a combinação de amostragem de disponibilidade de dados e ZK-EVM signifique que um possível futuro para escalar o Ethereum realmente parece muito próximo dessa visão! Com a abstração de contas, por outro lado, sabíamos desde o início que algum tipo de implementação era possível, então a pesquisa começou imediatamente, tentando fazer algo o mais próximo possível do ponto de partida puro de "uma transação é apenas uma chamada".
Há muito código clichê entre o processamento da transação e a realização das chamadas EVM subjacentes reais do endereço do remetente, e mais código clichê por vir. Como podemos reduzir esse código o mais próximo possível de zero?
Um dos principais códigos aqui é validate_transaction(state, tx), que é responsável por verificar se o nonce e a assinatura da transação estão corretos. Desde o início, o objetivo real da abstração de contas tem sido permitir que os usuários substituam a verificação básica não incremental e ECDSA por sua própria lógica de verificação, para que os usuários possam usar mais facilmente recursos como recuperação social e carteiras com várias assinaturas. Portanto, encontrar uma maneira de reestruturar apply_transaction como uma simples chamada EVM não era apenas uma tarefa de “código limpo pelo bem do código limpo”; em vez disso, tratava-se de mover a lógica para o código da conta do usuário, dando ao usuário a flexibilidade que ele desejava.
Entretanto, insistir em que apply_transaction contivesse o mínimo de lógica fixa possível acabou causando muitos desafios. Podemos analisar uma das primeiras propostas de abstração de contas, a EIP-86.
Se o EIP-86 fosse incluído como está, reduziria a complexidade do EVM às custas de um aumento massivo da complexidade em outras partes da pilha Ethereum, exigindo essencialmente que o mesmo código exato fosse escrito em outro lugar, além de introduzir classes inteiramente novas de estranheza, como a possibilidade de que a mesma transação com o mesmo hash pudesse aparecer várias vezes na cadeia, sem mencionar o problema de invalidação múltipla.
O problema de invalidação múltipla na abstração de contas. Uma transação incluída na cadeia pode invalidar milhares de outras transações no mempool, facilitando a inundação do mempool de forma barata.
Desde então, a abstração de contas evoluiu em etapas. Mais tarde, o EIP-86 se tornou EIP-208 e, finalmente, surgiu o prático EIP-2938.
No entanto, o EIP-2938 está longe de ser minimalista. Seu conteúdo inclui:
Novos tipos de transação
Três novas variáveis globais com escopo de transação
Dois novos opcodes, incluindo o opcode PAYgas muito estranho para lidar com verificações de preço e limite de gás, como um ponto de interrupção de execução EVM e para armazenar temporariamente ETH para pagamentos de taxas únicas
Um conjunto complexo de estratégias de mineração e retransmissão, incluindo uma lista de opcodes proibidos durante a fase de verificação da transação
Para atingir a abstração de contas sem envolver os principais desenvolvedores do Ethereum (que estavam focados em otimizar os clientes Ethereum e implementar a fusão), o EIP-2938 foi finalmente reprojetado como ERC-4337, o que está completamente fora do protocolo.
ERC-4337. Ele depende inteiramente de chamadas EVM!
Por ser um ERC, ele não requer um hard fork e tecnicamente existe “fora do protocolo Ethereum”. Então...o problema está resolvido? Acontece que isso não é verdade. O atual roteiro de médio prazo para o ERC-4337 envolve, na verdade, transformar grandes partes do ERC-4337 em uma série de recursos de protocolo, o que é um exemplo útil de por que esse caminho pode ser considerado.
Envolvendo ERC-4337
Vários motivos importantes foram discutidos para eventualmente reintegrar o ERC-4337 ao protocolo:
Eficiência de gás: qualquer operação realizada dentro do EVM gera algum grau de sobrecarga da máquina virtual, incluindo ineficiências ao usar recursos caros em termos de gás, como slots de armazenamento. Atualmente, essas ineficiências adicionais somam pelo menos 20.000 custos de gás, ou até mais. Colocar esses componentes no protocolo é a maneira mais fácil de eliminar esses problemas.
Risco de bug no código: se o “contrato de ponto de entrada” ERC-4337 tivesse um bug terrível o suficiente, todas as carteiras compatíveis com ERC-4337 poderiam ver todos os seus fundos drenados. Substituir um contrato por um recurso no protocolo cria uma responsabilidade implícita de corrigir bugs de código por meio de um hard fork, eliminando assim o risco de os fundos dos usuários serem drenados.
Suporta opcodes EVM como txt.origin. O próprio ERC-4337 faz com que txt.origin retorne o endereço de um "agrupador" que empacota um conjunto de ações do usuário em uma transação. A abstração de conta nativa pode resolver esse problema fazendo com que txt.origin aponte para a conta real que enviou a transação, fazendo com que funcione da mesma forma que o EOA.
Resistência à censura: Um dos desafios da separação entre proponente e construtor é que fica mais fácil censurar transações individuais. Em um mundo onde o protocolo Ethereum pode identificar transações individuais, esse problema pode ser bastante aliviado por listas de inclusão, que permitem ao proponente especificar uma lista de transações que devem ser incluídas nos próximos dois slots em quase todos os casos. No entanto, o ERC-4337 fora do protocolo encapsula “operações do usuário” em uma única transação, tornando as operações do usuário opacas ao protocolo Ethereum; portanto, a lista de inclusão fornecida pelo protocolo Ethereum não será capaz de fornecer resistência à censura às operações do usuário ERC-4337. Encapsular o ERC-4337 e tornar a ação do usuário um tipo de transação “adequado” resolveria esse problema.
Vale a pena mencionar que, em sua forma atual, o ERC-4337 é significativamente mais caro do que as transações "básicas" do Ethereum: as transações custam 21.000 gás, enquanto o ERC-4337 custa cerca de 42.000 gás.
Em teoria, deve ser possível ajustar o sistema de custo de gás EVM até que o custo dentro do protocolo e o custo de acesso ao armazenamento fora do protocolo coincidam; não há razão para que a transferência de ETH custe 9.000 de gás quando outros tipos de operações de edição de armazenamento são mais baratos. Na verdade, dois dos EIPs relacionados à próxima transição da árvore Verkle tentam fazer isso. Mas mesmo se fizéssemos isso, há uma razão óbvia pela qual, não importa quão eficiente o EVM se torne, a funcionalidade do protocolo encapsulado será inevitavelmente muito mais barata que o código EVM: o código encapsulado não precisa pagar gás para ser pré-carregado.
Uma carteira ERC-4337 totalmente funcional é grande, com a implementação compilada e enviada para a cadeia ocupando cerca de 12.800 bytes. Claro, você pode implantar esse código uma vez e usar DELEGATECALL para permitir que cada carteira individual o chame, mas o código ainda precisaria estar acessível em cada bloco que o utilizasse. Sob o custo de gás da árvore Verkle EIP, 12.800 bytes serão agrupados em 413 blocos, e o acesso a esses blocos exigirá o pagamento de 2 vezes o branch_cost da testemunha (para um total de 3.800 gás) e 413 vezes o chunk_cost da testemunha (para um total de 82.600 gás). Isso nem começa a mencionar o próprio ponto de entrada ERC-4337, que, na versão 0.6.0, tem 23.689 bytes na cadeia (cerca de 158.700 de gás para carregar de acordo com as regras EIP da árvore Verkle).
Isso leva a um problema: o custo do gás para acessar esse código precisa ser amortizado de alguma forma na transação. A abordagem atual usada pelo ERC-4337 não é muito boa: a primeira transação em um pacote consome um custo único de armazenamento/busca de código, tornando-a muito mais cara do que outras transações. O encapsulamento dentro do protocolo permitirá que essas bibliotecas públicas compartilhadas se tornem parte do protocolo, livremente acessíveis a todos.
O que podemos aprender com esse exemplo e quando usar o encapsulamento de forma mais geral?
Neste exemplo, vimos algumas justificativas diferentes para encapsular aspectos da abstração da conta no protocolo.
Abordagens baseadas no mercado que “levam a complexidade ao limite” têm maior probabilidade de falhar quando os custos fixos são altos. De fato, o roteiro de abstração de contas de longo prazo parece que haverá muitos custos fixos por bloco. 244, 100 gás para carregar código de carteira padronizado é uma coisa; mas a agregação poderia adicionar centenas de milhares de gás para verificação ZK-SNARK, bem como o custo na cadeia de verificação de prova. Não há como cobrar dos usuários esses custos sem introduzir enormes ineficiências de mercado, e transformar alguns desses recursos em recursos de protocolo que são livremente acessíveis a todos resolve esse problema muito bem.
Resposta de toda a comunidade a bugs de código. Se algum trecho de código for usado por todos os usuários ou por uma ampla gama de usuários, geralmente faz mais sentido que a comunidade blockchain assuma a responsabilidade por um hard fork para corrigir quaisquer bugs que surjam. ERC-4337 introduz uma grande quantidade de código compartilhado globalmente. A longo prazo, é sem dúvida mais razoável corrigir erros no código por meio de um hard fork do que fazer com que os usuários percam uma grande quantidade de ETH.
Às vezes, uma forma mais forte do protocolo pode ser implementada explorando diretamente sua funcionalidade. O exemplo principal aqui são os recursos resistentes à censura dentro do protocolo, como listas de inclusão: listas de inclusão dentro do protocolo podem fornecer melhor resistência à censura do que métodos fora do protocolo e, para que as operações em nível de usuário realmente se beneficiem das listas de inclusão dentro do protocolo, as operações individuais em nível de usuário precisam ser "legíveis" pelo protocolo. Outro exemplo menos conhecido é que o design de Prova de Participação do Ethereum da era de 2017 com abstração de conta para chaves de staking foi abandonado em favor do Wrapper BLS porque o BLS suporta um mecanismo de "agregação" que deve ser implementado no nível do protocolo e da rede, o que pode tornar o processamento de um grande número de assinaturas mais eficiente.
Mas é importante lembrar que mesmo a abstração de contas dentro de um protocolo wrapper ainda é um enorme “desencapsulamento” em comparação ao status quo. Hoje, as transações de nível superior do Ethereum só podem ser iniciadas a partir de contas de propriedade externa (EOAs), que são verificadas usando uma única assinatura de curva elíptica secp 256 k 1. A abstração de conta elimina isso e deixa as condições de validação para o usuário definir. Portanto, nesta história sobre abstração de contas, também vemos o maior motivo contra o encapsulamento: flexibilidade para atender às necessidades de diferentes usuários.
Vamos desenvolver um pouco mais essa história observando alguns outros exemplos de recursos que foram considerados para encapsulamento recentemente. Vamos nos concentrar especificamente em: ZK-EVM, separação entre proponente e construtor, mempools privados, staking de liquidez e novas pré-compilações.
Pacote ZK-EVM
Vamos voltar nossa atenção para outro alvo potencial de encapsulamento para o protocolo Ethereum: ZK-EVM. Atualmente, temos um grande número de ZK-rollups que precisam escrever códigos bastante semelhantes para verificar a execução de blocos Ethereum semelhantes em ZK-SNARKs. Há um ecossistema bastante diversificado de implementações independentes: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth e muitos outros.
Uma controvérsia recente no espaço EVM ZK-rollup está relacionada a como lidar com possíveis bugs no código ZK. Atualmente, todos esses sistemas em operação têm algum tipo de mecanismo de “conselho de segurança” que pode controlar o sistema de provas em caso de bug. No ano passado, procurei criar uma estrutura padronizada para incentivar projetos a esclarecer quanta confiança eles depositam nos sistemas de certificação e no Conselho de Segurança, e a reduzir gradualmente o poder sobre essa organização ao longo do tempo.
No médio prazo, os rollups podem depender de múltiplos sistemas de atestação, com o Conselho de Segurança tendo poder apenas no caso extremo de um desacordo entre dois sistemas de atestação diferentes.
No entanto, há uma sensação de que parte desse trabalho parece redundante. Já temos a camada base do Ethereum, ela tem uma EVM e já temos um mecanismo funcional para lidar com bugs na implementação: se houver um bug, o cliente é atualizado para corrigi-lo e a cadeia continua operando. Da perspectiva do cliente com bugs, blocos que pareciam finalizados não serão mais confirmados, mas pelo menos não veremos usuários perdendo fundos. Da mesma forma, se os rollups quiserem apenas manter uma função equivalente à EVM, eles precisam implementar sua própria governança para alterar constantemente suas regras internas do ZK-EVM para corresponder às atualizações da camada base do Ethereum, o que parece errado porque, em última análise, eles são construídos sobre a própria camada base do Ethereum, que sabe quando atualizar e de acordo com quais novas regras.
Como essas L2 ZK-EVMs usam basicamente o mesmo EVM que o Ethereum, podemos de alguma forma incorporar "verificar a execução do EVM no ZK" na funcionalidade do protocolo e lidar com anomalias como bugs e atualizações aplicando o consenso social do Ethereum, assim como já fazemos para a execução do EVM da camada base?
Este é um tópico importante e desafiador.
Um possível tópico de debate sobre a disponibilidade de dados no ZK-EVM nativo é o estado. Se os ZK-EVMs não precisassem transportar dados de “testemunhas”, eles seriam muito mais eficientes em termos de dados. Ou seja, se um dado específico já foi lido ou escrito em um bloco anterior, podemos simplesmente assumir que o provador tem acesso a ele e não precisa disponibilizá-lo novamente. Isso é mais do que simplesmente não recarregar o armazenamento e o código; Acontece que se um rollup compacta os dados corretamente, a compactação com estado pode economizar até 3 vezes os dados em comparação à compactação sem estado.
Isso significa que para pré-compilações ZK-EVM temos duas opções:
1. A pré-compilação requer que todos os dados estejam disponíveis no mesmo bloco. Isso significa que o provador pode ser sem estado, mas também significa que usar um ZK-rollup pré-compilado é muito mais caro do que um rollup usando código personalizado.
2. A pré-compilação permite que ponteiros apontem para dados usados ou gerados por execuções anteriores. Isso torna o ZK-rollup próximo do ideal, mas é mais complexo e introduz um novo estado que deve ser armazenado pelo provador.
O que podemos aprender com isso? Há um bom motivo para envolver a verificação do ZK-EVM de alguma forma: os rollups já estão construindo suas próprias versões personalizadas, e parece errado que o Ethereum esteja disposto a colocar o peso de suas múltiplas implementações e consenso social fora da cadeia na execução L1 do EVM, mas um L2 fazendo exatamente o mesmo trabalho teria que implementar dispositivos complexos envolvendo um Conselho de Segurança. Mas, por outro lado, um grande detalhe está nos detalhes: existem diferentes versões do ZK-EVM, e elas têm diferentes custos e benefícios. A distinção com/sem estado é apenas a ponta do iceberg; tentativas de oferecer suporte a “quase-EVM”, onde código personalizado foi comprovado em outros sistemas, provavelmente exporão um espaço de design muito maior. Portanto, empacotar o ZK-EVM traz promessas e desafios.
Separação do proponente e construtor de pacotes (ePBS)
A ascensão do MEV tornou a produção de blocos uma atividade econômica em larga escala, com atores sofisticados capazes de produzir blocos que geram mais receita do que o algoritmo padrão, que simplesmente observa o pool de memória das transações e as inclui. Até agora, a comunidade Ethereum tentou resolver esse problema usando esquemas de separação entre proponentes e construtores fora do protocolo, como o MEV-Boost, que permite que validadores regulares (“proponentes”) terceirizem a construção de blocos para participantes especializados (“construtores”).
No entanto, o MEV-Boost faz suposições de confiança em uma nova classe de participantes, chamados relés. Nos últimos dois anos, houve muitas propostas para criar um “pacote PBS”. Quais são os benefícios de fazer isso? Nesse caso, a resposta é muito simples: um PBS construído usando diretamente funções de protocolo é mais forte (no sentido de ter suposições de confiança mais fracas) do que um PBS construído sem usá-las. Isso é semelhante ao caso dos oráculos de preço dentro de protocolos wrapper — embora, neste caso, também haja fortes objeções.
Encapsular pool de memória privada
Quando um usuário envia uma transação, ela se torna imediatamente pública e visível para todos, mesmo antes de ser incluída na cadeia. Isso deixa os usuários de muitos aplicativos vulneráveis a ataques econômicos, como o front-running.
Recentemente, houve uma série de projetos dedicados à criação de “mempools privados” (ou “mempools criptográficos”), que criptografam as transações dos usuários até que sejam irreversivelmente aceitas em um bloco.
O problema, no entanto, é que esse esquema exige um tipo especial de criptografia: para evitar que os usuários inundem o sistema e o descriptografem primeiro, a criptografia deve ser descriptografada automaticamente assim que a transação for verdadeira e irreversivelmente aceita.
Para obter essa forma de criptografia, existem várias técnicas com diferentes compensações. Jon Charbonneau descreveu bem:
Criptografia para operadores centralizados, como o Flashbots Protect.
Criptografia com bloqueio de tempo, que é uma forma de criptografia que pode ser descriptografada por qualquer pessoa após uma determinada sequência de etapas de cálculo e não pode ser paralelizada;
Criptografia de limite, confiando em um comitê majoritário honesto para descriptografar os dados. Veja o conceito de Closed Beacon Chain para sugestões específicas.
Hardware confiável, como SGX.
Infelizmente, cada método de criptografia tem diferentes fraquezas. Embora para cada solução haja um subconjunto de usuários dispostos a confiar nela, nenhuma solução é confiável o suficiente para ser realmente aceita pela Camada 1. Portanto, pelo menos até que a criptografia de latência seja aperfeiçoada ou algum outro avanço tecnológico ocorra, encapsular a funcionalidade anti-front-running na Camada 1 parece ser uma proposta difícil, mesmo que seja um recurso valioso o suficiente para que muitas soluções de aplicativos já tenham surgido.
Estaca de Liquidez Encapsulada
Uma demanda comum entre os usuários do Ethereum DeFi é a capacidade de usar seu ETH tanto para staking quanto como garantia em outras aplicações. Outra solicitação comum é simplesmente por conveniência: os usuários querem poder fazer stake sem a complexidade de executar um nó e mantê-lo sempre online (e proteger as chaves de stake online).
De longe, a “interface” de staking mais simples que atende a ambas as necessidades é apenas um token ERC 20: converta seu ETH em “ETH staking”, segure-o e então converta de volta. Na verdade, provedores de staking de liquidez como Lido e Rocket Pool já começaram a fazer isso. No entanto, existem alguns mecanismos centralizadores naturais em ação com o staking líquido: as pessoas naturalmente recorrem ao staking da versão maior do ETH porque é a mais familiar e líquida.
Cada versão de staking de ETH requer algum mecanismo para determinar quem pode se tornar o operador do nó subjacente. Não pode ser ilimitado porque então os invasores podem participar e amplificar o ataque usando fundos do usuário. Atualmente, os dois principais são Lido, que tem operadores de nós na lista de permissões de DAO, e Rocket Pool, que permite que qualquer pessoa execute um nó com um depósito de 8 ETH. As duas abordagens têm riscos diferentes: a abordagem Rocket Pool permite que um invasor lance um ataque de 51% na rede e force os usuários a pagar a maior parte dos custos; quanto à abordagem DAO, se um determinado token apostado se tornar dominante, isso levará a um único dispositivo de governança potencialmente atacável controlando uma grande parte de todos os validadores Ethereum. É claro que protocolos como o Lido implementaram precauções, mas uma camada de defesa pode não ser suficiente.
No curto prazo, uma opção é incentivar os participantes do ecossistema a usar uma gama diversificada de provedores de staking de liquidez para reduzir a probabilidade de risco sistêmico representado por um único provedor dominante. No entanto, a longo prazo, esse é um equilíbrio instável e a dependência excessiva da pressão moral para resolver problemas é perigosa. Surge uma pergunta natural: faz sentido encapsular algum tipo de funcionalidade no protocolo para tornar a participação de liquidez menos centralizada?
A questão principal aqui é: que tipo de funcionalidade dentro do protocolo? O problema de simplesmente criar um token fungível "ETH apostado" dentro do protocolo é que ele teria que ter um wrapper em torno da governança de todo o Ethereum para escolher quem pode executar os nós, ou ser aberto, o que o transformaria em uma ferramenta para invasores.
Uma ideia interessante é o artigo de Dankrad Feist sobre como maximizar a liquidez de staking. Primeiro, vamos cerrar os dentes e perceber que se o Ethereum for atacado por 51%, apenas 5% do ETH atacado poderá ser confiscado. Esta é uma troca razoável; com mais de 26 milhões de ETH atualmente em stake, o custo de atacar um terço deles (~8 milhões de ETH) seria excessivo, especialmente considerando quantos ataques “fora do modelo” podem ser realizados a um custo muito menor. Na verdade, compensações semelhantes foram exploradas na proposta do “super comitê” para implementar a finalidade de slot único.
Se aceitarmos que apenas 5% do ETH atacado é cortado, então mais de 90% do ETH apostado não será afetado pelo corte, então eles podem ser usados como tokens de staking de liquidez fungíveis dentro do protocolo e então usados por outras aplicações.
Essa trilha é interessante. Mas ainda resta a questão: o que exatamente está encapsulado? O Rocket Pool opera de forma muito semelhante: cada operador de nó fornece alguns fundos e os participantes da liquidez fornecem o restante. Podemos simplesmente ajustar algumas constantes para limitar a penalidade máxima de corte a 2 ETH, e o rETH existente do Rocket Pool se tornará livre de riscos.
Também podemos fazer outras coisas inteligentes com ajustes simples de protocolo. Por exemplo, suponha que queremos um sistema com duas “camadas” de staking: operadores de nós (altos requisitos de garantia) e depositantes (sem requisitos mínimos de garantia, podem entrar e sair a qualquer momento), mas ainda queremos evitar a centralização dos operadores de nós, dando poderes a um comitê de depositantes amostrados aleatoriamente, como sugerir uma lista de transações que devem ser incluídas (por motivos de resistência à censura), controlar a escolha do fork durante vazamentos de inatividade ou ser obrigado a assinar blocos. Isso pode ser alcançado de uma forma amplamente fora do protocolo, ajustando o protocolo para exigir que cada validador forneça (i) uma chave de staking regular e (ii) um endereço ETH que pode ser chamado entre cada slot para gerar uma chave de staking secundária. O protocolo concederá autoridade a ambas as chaves, mas o mecanismo para selecionar a segunda chave em cada slot pode ser deixado para o protocolo do pool de staking. Ainda pode ser melhor encapsular algumas funcionalidades diretamente, mas vale a pena notar que esse tipo de espaço de design "inclua algumas coisas e deixe outras para o usuário" existe.
Encapsule mais pré-compilados
Pré-compilações (ou "contratos pré-compilados") são contratos Ethereum que implementam operações criptográficas complexas, onde a lógica é implementada nativamente no código do cliente em vez do código do contrato inteligente EVM. A pré-codificação foi um compromisso adotado no início do desenvolvimento do Ethereum: como a sobrecarga da máquina virtual é muito grande para alguns códigos muito complexos e altamente especializados, podemos implementar algumas operações-chave que são valiosas para aplicativos importantes em código nativo para torná-los mais rápidos. Hoje, isso envolve basicamente algumas funções hash especializadas e operações de curva elíptica.
Atualmente, há um esforço para adicionar uma pré-compilação para secp 256 r 1, uma curva elíptica ligeiramente diferente da secp 256 k 1 usada para contas básicas de Ethereum, porque ela é bem suportada por módulos de hardware confiáveis, então seu uso generalizado pode melhorar a segurança da carteira. Nos últimos anos, a comunidade também tem pressionado para adicionar pré-compilações para BLS-12-377, BW 6-761, pareamento generalizado e outros recursos.
Um contra-argumento a esses pedidos por mais arquivos pré-compilados é que muitos dos arquivos pré-compilados que foram adicionados anteriormente (como RIPEMD e BLAKE) acabaram tendo muito menos uso do que o esperado, e devemos aprender com isso. Em vez de adicionar mais pré-compilações para operações específicas, talvez devêssemos nos concentrar em uma abordagem mais modesta baseada em ideias como o EVM-MAX e as propostas SIMD inativas, mas sempre retomáveis, que permitiriam que as implementações do EVM executassem uma ampla classe de código a um custo menor. Talvez até mesmo as pré-compilações existentes, raramente utilizadas, pudessem ser removidas e substituídas por implementações de código EVM (inevitavelmente menos eficientes) das mesmas funções. Dito isso, ainda é possível que existam operações criptográficas específicas que sejam valiosas o suficiente para serem aceleradas, fazendo sentido adicioná-las como uma pré-compilação.
O que aprendemos com tudo isso?
O desejo de encapsular o mínimo possível é compreensível e bom; vem da tradição filosófica do Unix de criar software mínimo que pode ser facilmente adaptado às diferentes necessidades dos usuários e evitar a maldição do inchaço do software. No entanto, blockchain não é um sistema operacional de computação pessoal, mas um sistema social. Isso significa que faz sentido encapsular determinada funcionalidade em um protocolo.
Em muitos casos, esses outros exemplos são semelhantes ao que vimos com a abstração de contas. Mas também aprendemos algumas novas lições:
Encapsular a funcionalidade pode ajudar a evitar riscos de centralização em outras áreas da pilha:
Muitas vezes, manter o protocolo base mínimo e simples empurra a complexidade para algum ecossistema fora do protocolo. Da perspectiva da filosofia Unix, isso é bom. No entanto, às vezes existe o risco de que o ecossistema extraprotocolo se torne centralizado, geralmente (mas não apenas) devido aos altos custos fixos. O encapsulamento às vezes pode reduzir a centralização de fato.
Encapsular muito pode expandir excessivamente a carga de confiança e governança do protocolo:
Este é o tema de um artigo anterior sobre “Não sobrecarregue o consenso do Ethereum”: se encapsular uma funcionalidade específica enfraquece o modelo de confiança e torna o Ethereum como um todo mais “subjetivo”, isso enfraquece a neutralidade confiável do Ethereum. Nesses casos, é melhor implementar a funcionalidade específica como um mecanismo sobre o Ethereum em vez de tentar introduzi-la no próprio Ethereum. O mempool criptografado é o melhor exemplo aqui, e pode ser um pouco difícil de encapsular, pelo menos até que a tecnologia de criptografia retardada melhore.
Encapsular muitas coisas pode tornar o protocolo muito complexo:
A complexidade do protocolo é um risco sistêmico, e adicionar muitos recursos a um protocolo aumenta esse risco. A pré-compilação é o melhor exemplo.
A longo prazo, encapsular a funcionalidade pode ser contraproducente porque as necessidades do usuário são imprevisíveis:
Um recurso que muitas pessoas consideram importante e que será usado por muitos usuários pode não ser usado com muita frequência na prática.
Além disso, a aposta de liquidez, o ZK-EVM e os casos de pré-compilação mostram a possibilidade de um caminho intermediário: consagração viável mínima. Os protocolos não precisam encapsular uma funcionalidade inteira, mas podem conter partes específicas que abordam os principais desafios, tornando essa funcionalidade fácil de implementar sem ser excessivamente paranoica ou muito restrita. Exemplos incluem:
Em vez de encapsular um sistema completo de staking de liquidez, é melhor mudar as regras de penalidade de staking para tornar o staking de liquidez sem confiança mais viável;
Em vez de encapsular mais pré-compiladores, encapsular EVM-MAX e/ou SIMD para tornar uma classe mais ampla de operações mais fácil de implementar eficientemente;
Em vez de encapsular todo o conceito de rollup, pode-se simplesmente encapsular a verificação EVM.
Podemos expandir o diagrama anterior da seguinte forma:
Às vezes faz sentido encapsular algo; remover a pré-compilação raramente usada é um exemplo. A abstração de contas como um todo, como mencionado anteriormente, também é uma forma importante de desencapsulamento. Se quisermos oferecer suporte à compatibilidade com versões anteriores para usuários existentes, o mecanismo pode ser muito semelhante ao das pré-compilações descompiladas: uma das propostas é o EIP-5003, que permitiria que as EOAs convertessem suas contas em contratos com a mesma (ou melhor) funcionalidade.
É uma escolha complexa entre quais recursos devem ser incluídos no protocolo e quais devem ser deixados para outras camadas do ecossistema. Esperamos que essa compensação continue a melhorar ao longo do tempo, à medida que nossa compreensão das necessidades do usuário e do conjunto de ideias e tecnologias disponíveis melhore.