原文标题:O Ethereum deveria concordar em consagrar mais coisas no protocolo?
Autor original: Vitalik Buterin
Tradutor do Odaily Planet Daily | 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.
Este artigo irá aprofundar alguns dos raciocínios filosóficos por trás da filosofia original do encapsulamento mínimo, bem como algumas formas recentes de pensar sobre essas ideias. O objetivo será começar a construir uma estrutura para identificar melhor os possíveis objetivos onde o encapsulamento de determinadas funcionalidades pode valer a pena considerar.
Uma 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 sobre si mesmo e deixasse quase todo esse trabalho para os usuários. Idealmente, o protocolo é apenas uma máquina virtual e a validação de um bloco é apenas uma chamada de máquina virtual.
Esta é uma reconstrução aproximada do diagrama do quadro branco que Gavin Wood e eu desenhámos no início de 2015, quando estava falando sobre como seria o Ethereum 2.0.
A "função de transição de estado" (a função que lida com o bloco) será apenas uma única chamada de VM, e todas as outras lógicas acontecerão através de contratos: alguns contratos em nível de sistema, mas principalmente contratos fornecidos pelo usuário. Uma característica muito interessante deste modelo é que 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, em seguida, terá permissão de execução atualizada.
Estas discussões em 2015 aplicam-se especificamente a duas áreas que consideramos: abstração de contas e dimensionamento. No caso do escalonamento, a ideia é tentar criar uma forma abstrata máxima de escalonamento 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 funcionalidade de computação estendida muito geral. Da perspectiva da máquina virtual, a chamada irá para algum subsistema separado e retornará magicamente a resposta correta algum tempo depois.
Exploramos brevemente essa ideia, mas rapidamente a abandonamos porque estávamos muito focados em provar que qualquer tipo de escalonamento 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 futuro possível para o escalonamento do Ethereum na verdade parece muito próximo desta visão! Com a abstração da conta, 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 a tentar fazer algo o mais próximo possível do puro ponto de partida de “uma transação é apenas uma chamada”.
*Há muito código padrão entre o processamento da transação e a realização da chamada EVM subjacente real a partir do endereço do remetente, e mais código padrão depois disso. Como reduzimos esse código o mais próximo possível de zero? *
Um dos principais códigos aqui é valid_transaction(state, tx), que é responsável por verificar se o nonce e a assinatura da transação estão corretos. O verdadeiro objetivo da abstração de contas desde o início tem sido permitir que os usuários substituam a verificação não incremental básica e a verificação 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 múltiplas assinaturas. Portanto, encontrar uma maneira de reestruturar apply_transaction em uma simples chamada EVM não é apenas uma tarefa de "tornar o código limpo pelo simples fato de tornar o código limpo"; em vez disso, trata-se de mover a lógica para o código da conta do usuário, dando aos usuários a flexibilidade necessária. precisar.
No entanto, insistir que apply_transaction contenha o mínimo de lógica fixa possível acabou criando muitos desafios. Podemos dar uma olhada em uma das primeiras propostas de abstração de contas, EIP-86.
Se o EIP-86 fosse incluído como está, reduziria a complexidade do EVM ao custo de aumentar enormemente a complexidade de outras partes da pilha Ethereum, exigindo essencialmente que o mesmo código fosse escrito em outro lugar, além de introduzir um todo nova classe de estranheza. Por exemplo, a mesma transação com o mesmo valor de hash pode aparecer várias vezes na cadeia, sem mencionar o problema de invalidação múltipla.
*Vários problemas de invalidação na abstração de conta. Uma transação incluída na cadeia poderia invalidar milhares de outras transações no mempool, facilitando o preenchimento barato do mempool. *
Desde então, a abstração da conta evoluiu em etapas. O EIP-86 mais tarde tornou-se EIP-208 e, eventualmente, surgiu o prático EIP-2938.
No entanto, o EIP-2938 é tudo menos minimalista. Seu conteúdo inclui:
Novo tipo de transação
Três novas variáveis globais de escopo de transação
Dois novos opcodes, incluindo o muito desajeitado opcode PAYgas para lidar com verificações de preço e limite de gás, como pontos de interrupção de execução de EVM e para armazenar temporariamente ETH para pagamento único
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
Em um esforço para alcançar a abstração de contas sem envolver os principais desenvolvedores do Ethereum (que estavam focados na otimização dos clientes Ethereum e na implementação de fusões), o EIP-2938 foi finalmente reprojetado como ERC-4337, que estava completamente fora do protocolo.
ERC-4337. Depende inteiramente de chamadas EVM!
Por ser um ERC, ele não requer um hard fork e existe tecnicamente “fora do protocolo Ethereum”. Então...problema resolvido? Acontece que não é o caso. O atual roteiro de médio prazo para o ERC-4337 envolve, na verdade, a transição de grandes partes do ERC-4337 para uma série de recursos de protocolo, o que é um exemplo útil de orientação sobre por que esse caminho deve ser considerado.
Pacote ERC-4337
Existem vários motivos principais discutidos para a eventual reincorporação do ERC-4337 no protocolo:
eficiência de gás: Qualquer operação executada dentro do EVM incorre em algum nível de sobrecarga da máquina virtual, incluindo ineficiências ao usar recursos caros de gás, como slots de armazenamento. Atualmente, essas ineficiências adicionais somam pelo menos 20 mil gases, ou mais. Colocar esses componentes no protocolo é a maneira mais fácil de eliminar esses problemas.
Risco de bug de código: Se o “contrato de ponto de entrada” ERC-4337 tiver um bug terrível o suficiente, todas as carteiras compatíveis com ERC-4337 poderão ver todos os seus fundos secarem. A substituição de contratos por funcionalidades dentro do protocolo cria uma obrigação implícita de corrigir bugs de código por meio de hard forks, eliminando assim o risco de os usuários ficarem sem fundos.
Suporta opcodes EVM, como txt.origin. O próprio ERC-4337 faz com que o txt.origin retorne o endereço de um "empacotador" que empacota um conjunto de ações do usuário em uma transação. A abstração da conta nativa resolve esse problema fazendo com que txt.origin aponte para a conta real que envia a transação, fazendo com que ela se comporte da mesma forma que o EOA.
Resistência à censura: Um dos desafios da separação entre proponente e construtor é que fica mais fácil revisar transações individuais. Num mundo onde o protocolo Ethereum pode identificar transações únicas, este problema pode ser bastante atenuado por listas de inclusão, que permitem aos proponentes 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 ao usuário ERC-4337 operações. Envolver o ERC-4337 e tornar a ação do usuário um tipo de transação "adequado" resolveria esse problema.
Vale ressaltar que em sua forma atual, o ERC-4337 é significativamente mais caro do que as transações “básicas” do Ethereum: uma transação custa 21.000 gás, enquanto o ERC-4337 custa cerca de 42.000 gás.
Em teoria, deveria ser possível ajustar o sistema de custo de gás EVM até que o custo no protocolo e o custo de acesso ao armazenamento fora do protocolo correspondam; não há razão para precisar gastar 9.000 gás para transferir ETH quando outros tipos de edição de armazenamento as operações são mais baratas. Na verdade, dois EIPs relacionados à próxima transformação da árvore Verkle tentam fazer exatamente isso. Mas mesmo se fizermos isso, há uma razão óbvia pela qual não importa o quão eficiente o EVM se torne, as funções do protocolo encapsulado serão inevitavelmente muito mais baratas do que o código EVM: o código encapsulado não precisa pagar gás para pré-carregamento.
Uma carteira ERC-4337 totalmente funcional é grande e a implementação compilada e colocada na cadeia ocupa cerca de 12.800 bytes. Claro, você poderia implantar esse código uma vez e usar DELEGATECALL para permitir que cada carteira individual o chamasse, mas você ainda precisaria acessar o código em cada bloco onde ele é usado. No EIP de custo de gás da árvore Verkle, 12.800 bytes formarão 413 pedaços. O acesso a esses pedaços exigirá o pagamento de 2 vezes o custo do ramo testemunha (um total de 3.800 gás) e 413 vezes o custo do pedaço testemunho (um total de 82.600). gás). Isso nem sequer 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 (aproximadamente 158.700 gases para carregar de acordo com as regras EIP da árvore Verkle).
Isto leva a um problema: o custo do gás para realmente acessar esses códigos deve ser amortizado de alguma forma entre as transações. A abordagem atual usada pelo ERC-4337 não é muito boa: a primeira transação do pacote consome um custo único de armazenamento/leitura de código, tornando-a muito mais cara do que outras transações. O encapsulamento intraprotocolo permitirá que essas bibliotecas públicas compartilhadas se tornem parte do protocolo e sejam livremente acessíveis a todos.
O que podemos aprender com este exemplo e quando o encapsulamento deve ser praticado de forma mais geral?
Neste exemplo, vemos algumas razões diferentes para encapsular abstrações de contas em protocolos.
**As abordagens baseadas no mercado que “levam a complexidade ao limite” têm maior probabilidade de falhar quando os custos fixos são elevados. **Na verdade, o roteiro de abstração de contas de longo prazo parece ter muitos custos fixos por bloco. 244.100 gás para carregar código de carteira padronizado é uma coisa; mas a agregação pode 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 sejam livremente acessíveis a todos resolveria muito bem esse problema.
**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, muitas vezes faz mais sentido para a comunidade blockchain assumir a responsabilidade de um hard fork para corrigir quaisquer bugs que surjam. ERC-4337 introduz uma grande quantidade de código compartilhado globalmente. No longo prazo, é sem dúvida mais razoável corrigir erros no código por meio de hard forks do que fazer com que os usuários percam uma grande quantidade de ETH.
**Às vezes, uma forma mais forte de protocolo pode ser implementada aproveitando diretamente sua funcionalidade. **O principal exemplo aqui são os recursos resistentes à censura dentro do protocolo, como listas de inclusão: As listas de inclusão no protocolo podem garantir melhor a resistência à censura do que os métodos fora do protocolo. Para que as operações no nível do usuário realmente se beneficiem do protocolo incluem listas. As operações individuais em nível de usuário precisam ser "legíveis" para o protocolo. Outro exemplo menos conhecido é que o design de prova de aposta Ethereum da era 2017 tinha abstração de conta de chaves de aposta, que foi abandonada em favor do BLS encapsulado porque o BLS suportava um mecanismo de "agregação" que precisava ser implementado no protocolo e níveis de rede, isso pode tornar o processamento de um grande número de assinaturas mais eficiente.
Mas é importante lembrar que mesmo a abstração de contas dentro do protocolo de encapsulamento ainda é um enorme “desencapsulamento” em comparação com o status quo. Hoje, as transações Ethereum de nível superior só podem ser iniciadas a partir de contas de propriedade externa (EOA), que são verificadas usando uma única assinatura de curva elíptica secp 256k 1. A abstração da 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, vemos também o maior motivo contra o encapsulamento: Flexibilidade para atender às necessidades de diferentes usuários.
Vamos aprofundar a história examinando alguns outros exemplos de recursos que foram recentemente considerados para encapsulamento. Em particular, analisaremos: ZK-EVM, separação proponente-construtor, pools de memória privados, staking de liquidez e nova pré-compilação.
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. Existe um ecossistema bastante diversificado de implementações independentes: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth e muitos mais.
Uma controvérsia recente no campo EVM ZK-rollup está relacionada a como lidar com bugs que podem aparecer no código ZK. Atualmente, todos esses sistemas em operação possuem alguma forma de mecanismo de “conselho de segurança” que controla o sistema de atestação em caso de bug. No ano passado, tentei criar um quadro padronizado que encorajasse os projectos a esclarecer o quanto confiam no sistema de certificação e o quanto confiam no Conselho de Segurança, e a reduzir gradualmente a sua autoridade sobre essa organização ao longo do tempo.
*A médio prazo, é provável que o rollup dependa de múltiplos sistemas de certificação, com o Conselho de Segurança a ter poder apenas em casos extremos em que dois sistemas de certificação diferentes divergem. *
No entanto, há uma sensação de que parte deste trabalho parece redundante. Já temos uma camada base Ethereum, tem um EVM, e já temos um mecanismo funcional para lidar com bugs na implementação: se houver bug, o cliente será atualizado para corrigi-lo, e a cadeia continuará funcionando . Do ponto de vista do cliente com bugs, parece que os bloqueios finalizados não serão mais confirmados, mas pelo menos não veremos os usuários perdendo fundos. Da mesma forma, se os rollups quiserem apenas manter a função equivalente do EVM, então eles precisam implementar sua própria governança para mudar constantemente suas regras internas do ZK-EVM para corresponder às atualizações da camada base Ethereum, o que parece errado porque, em última análise, eles são construídos no topo da própria camada base Ethereum, ele sabe quando atualizar e de acordo com quais novas regras.
Como esses ZK-EVMs L2 usam basicamente exatamente o mesmo EVM do Ethereum, podemos de alguma forma incorporar "verificar a execução do EVM no ZK" na funcionalidade do protocolo e lidar com exceções aplicando o consenso social do Ethereum, como bugs e atualizações, como já fazemos para o A própria execução do EVM da camada base?
Este é um tema importante e desafiador.
Um possível tópico de debate sobre a disponibilidade de dados no ZK-EVM nativo é a monitoração de estado. ZK-EVMs seriam muito mais eficientes em termos de dados se não precisassem transportar dados de "testemunha". Ou seja, se um determinado dado foi lido ou escrito em algum bloco anterior, podemos simplesmente assumir que o provador tem acesso a ele e não precisa disponibilizá-lo novamente. Não se trata apenas de não recarregar o armazenamento e o código; acontece que, se um rollup compactar os dados corretamente, a compactação com estado poderá economizar até três vezes mais dados em comparação com a compactação sem estado.
Isso significa que para a pré-compilação 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 esse rollup ZK pré-compilado é muito mais caro do que usar o rollup de código personalizado.
**2.**A pré-compilação permite que ponteiros apontem para dados usados ou gerados por execuções anteriores. Isso torna o rollup ZK 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á uma boa razão para encapsular a verificação ZK-EVM de alguma forma: o rollup já está construindo sua própria versão personalizada, e Ethereum está disposto a implementar EVM em L1 com o peso de suas múltiplas implementações e consenso social fora da cadeia. errado, mas L2 fazendo exatamente o mesmo trabalho teria que implementar um dispositivo complexo envolvendo o Conselho de Segurança. Mas, por outro lado, há um grande problema nos detalhes: existem diferentes versões do ZK-EVM e têm custos e benefícios diferentes. A distinção entre stateful e stateless apenas arranha a superfície; tentativas de suportar código personalizado "quase EVM" que foi comprovado por outros sistemas podem expor um espaço de design maior. Portanto, embalar ZK-EVM traz esperança e desafios.
Proponente de encapsulamento e separação de construtor (ePBS)
A ascensão do MEV torna a produção de blocos uma actividade económica em escala, com actores sofisticados capazes de produzir blocos que geram mais receitas do que o algoritmo padrão, que simplesmente observa um mempool de transacções e contém-as. Até agora, a comunidade Ethereum tem tentado resolver este problema usando esquemas de separação proponente-construtor fora do protocolo, como MEV-Boost, que permite que validadores regulares ("proponentes") enviem blocos para Building é terceirizado para atores especializados ("Construtores ").
No entanto, o MEV-Boost faz suposições de confiança em uma nova classe de atores chamada retransmissores. Nos últimos dois anos, surgiram muitas propostas para criar um “pacote PBS”. Quais são os benefícios de fazer isso? Neste caso, a resposta é muito simples: um PBS construído usando diretamente recursos de protocolo é mais poderoso (no sentido de ter suposições de confiança mais fracas) do que um PBS construído sem usá-los. Isto é semelhante ao caso de encapsular oráculos de preços dentro de um protocolo – embora neste caso haja fortes objeções.
Encapsular pool de memória privada
Quando um usuário envia uma transação, ela fica imediatamente pública e visível para todos, mesmo antes de ser incluída na rede. Isto deixa os utilizadores de muitas aplicações vulneráveis a ataques económicos, como o front-running.
Recentemente, tem havido 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, porém, é que tal esquema requer um tipo especial de criptografia: para evitar que os usuários inundem o sistema e o descriptografem primeiro, a criptografia deve ser descriptografada automaticamente depois que a transação tiver sido realmente aceita de forma irreversível.
Existem várias técnicas com diferentes compensações para implementar esta forma de criptografia. Jon Charbonneau uma vez descreveu bem:
Criptografia para operadores centralizados como Flashbots Protect**. **
Criptografia de bloqueio de tempo, esta forma de criptografia pode ser descriptografada por qualquer pessoa após certas etapas de cálculo sequencial e não pode ser paralelizada;
Criptografia de limite, confie em um comitê de maioria honesta para descriptografar os dados. Consulte o conceito de cadeias de beacon fechadas para sugestões específicas.
Hardware confiável, como SGX.
Infelizmente, cada método de criptografia tem pontos fracos diferentes. Embora para cada solução exista um segmento 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 atrasada seja aperfeiçoada ou algum outro avanço tecnológico, encapsular a funcionalidade de negociação anti-ahead na Camada 1 parece ser uma proposta difícil, mesmo que seja um recurso valioso o suficiente para que muitos aplicativos resolvam. surgiu o plano.
Encapsular a aposta de liquidez
Uma necessidade comum entre os usuários do Ethereum DeFi é a capacidade de usar simultaneamente seu ETH para piquetagem e como garantia em outras aplicações. Outra solicitação comum é simplesmente por conveniência: os usuários desejam poder fazer staking (e proteger as chaves de staking on-line) sem a complexidade de executar um nó e mantê-lo sempre on-line.
De longe, a “interface” de piquetagem mais simples que atende a essas duas necessidades é apenas um token ERC 20: converta seu ETH em “piquetagem ETH”, segure-o e depois converta-o novamente. Na verdade, provedores de liquidez como Lido e Rocket Pool já estão fazendo isso. No entanto, existem alguns mecanismos naturais de centralização em jogo com o staking de liquidez: as pessoas passarão naturalmente a apostar na versão maior da ETH porque é a mais familiar e líquida.
Cada versão do ETH apostado precisa ter algum mecanismo para determinar quem pode se tornar o operador do nó subjacente. Não pode ser ilimitado porque então os invasores participarão e usarão os fundos dos usuários para expandir seus ataques. Atualmente, os dois primeiros são Lido e Rocket Pool, com o primeiro tendo operadores de nós na lista de permissões do DAO e o último permitindo que qualquer pessoa execute um nó com um depósito de 8 ETH. Os dois métodos apresentam riscos diferentes: o método Rocket Pool permite que um invasor conduza um ataque de 51% na rede e força os usuários a pagar a maior parte dos custos; já no método DAO, se um determinado token apostado dominar, isso levará a um único dispositivo de governança potencialmente comprometido controla uma grande parte de todos os validadores Ethereum. Para seu crédito, protocolos como o Lido implementaram salvaguardas, mas uma camada de defesa pode não ser suficiente.
No curto prazo, uma opção é incentivar os participantes do ecossistema a utilizarem um conjunto diversificado de fornecedores de liquidez para reduzir a possibilidade de um interveniente dominante representar um risco sistémico. No longo prazo, porém, este é 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 alguma funcionalidade no protocolo para tornar o staking de liquidez menos centralizado? **
A questão principal aqui é: que tipo de funcionalidade no protocolo? Um problema com a simples criação de um token fungível de "staking ETH" dentro do protocolo é que ele teria que ter uma governança encapsulada em todo o Ethereum para escolher quem executará os nós, ou seria aberto, mas isso o transformaria em um ataque do invasor. Ferramentas.
Uma ideia interessante é o artigo de Dankrad Feist sobre maximização da aposta de liquidez. Primeiro, vamos enfrentar a questão: se o Ethereum estiver sujeito a um ataque de 51%, apenas 5% do ETH atacado poderá ser cortado. Esta é uma compensação razoável; com mais de 26 milhões de ETH atualmente apostados, o custo de atacar um terço disso (~8 milhões de ETH) é excessivo, especialmente considerando quantos ataques “fora do modelo” podem ser feitos de uma só vez. custo mais baixo. Na verdade, compensações semelhantes foram exploradas na proposta do Supercomité para implementar a finalidade de faixa única.
Se aceitarmos que apenas 5% do ETH de ataque é cortado, então mais de 90% do ETH apostado não será afetado pelo corte, então eles podem ser usados como tokens de piquetagem líquidos fungíveis dentro do protocolo e depois usados por outras aplicações.
Este caminho é interessante. Mas ainda deixa uma questão: o que exatamente está encapsulado? **Rocket Pool funciona de forma muito semelhante: cada operador de nó fornece alguns fundos e os stakers de liquidez fornecem o restante. Podemos simplesmente ajustar algumas constantes para limitar a penalidade máxima de redução a 2 ETH, e o rETH existente do Rocket Pool se tornará livre de riscos.
Com simples ajustes de protocolo, também podemos fazer outras coisas inteligentes. Por exemplo, digamos que queremos um sistema com dois "níveis" de piquetagem: operadores de nós (elevados requisitos de garantia) e depositantes (sem requisitos mínimos de garantia, podem entrar e sair a qualquer momento), mas ainda queremos dotar uma amostra aleatória poderes do comitê de depositantes para evitar a centralização dos operadores de nós, como recomendar uma lista de transações que devem ser incluídas (por motivos de resistência à censura), controlar a seleção de fork durante vazamentos de inatividade ou exigir assinaturas em blocos. Isso poderia ser feito de uma forma que essencialmente sai do protocolo, ajustando o protocolo para exigir que cada validador forneça (i) uma chave de piquetagem regular e (ii) um endereço ETH que pode ser usado em cada slot é chamado para gerar o chave de penhor secundária. O protocolo daria poder a ambas as chaves, mas o mecanismo para selecionar a segunda chave em cada slot poderia ser deixado para o protocolo do pool de piquetagem. Ainda pode ser melhor encapsular algumas funcionalidades diretamente, mas é importante notar que esse espaço de design de “incluir algumas coisas e deixar outras para o usuário” existe.
Encapsular mais pré-compilação
Contratos pré-compilados (ou "contratos pré-compilados") são contratos Ethereum que implementam operações criptográficas complexas, com lógica implementada nativamente no código do cliente, em vez do código do contrato inteligente EVM. A pré-codificação é um compromisso adotado desde o início do desenvolvimento do Ethereum: como o overhead de uma máquina virtual é muito grande para algum código muito complexo e altamente especializado, podemos implementar algumas aplicações importantes em código nativo, valorizando operações críticas para torná-las mais rápidas. Hoje, isso inclui basicamente algumas funções hash específicas e operações de curva elíptica.
Atualmente, há um impulso para adicionar pré-compilação para secp 256 r 1, uma curva elíptica ligeiramente diferente da secp 256 k 1 usada para contas Ethereum básicas, que é amplamente utilizada, pois é bem suportada por módulos de hardware confiáveis. Use-a para aumentar a segurança da carteira. Nos últimos anos, a comunidade também pressionou para adicionar pré-compilação para BLS-12-377, BW 6-761, emparelhamento generalizado e outros recursos.
O contra-argumento a esses pedidos por mais pré-compiladores é que muitos dos pré-compiladores adicionados anteriormente (como RIPEMD e BLAKE) acabaram sendo usados muito menos do que o esperado, e devemos aprender com isso. Em vez de adicionar mais pré-compilação para operações específicas, talvez devêssemos nos concentrar em uma abordagem mais suave baseada em ideias como EVM-MAX e a proposta SIMD Hibernate-But-Always-Resumable, que permitiria que implementações de EVM rodassem com menor custo. uma ampla gama de classes de código. Talvez até mesmo a pré-compilação existente e pouco utilizada pudesse ser removida e substituída por uma implementação de código EVM (inevitavelmente menos eficiente) das mesmas funções. Dito isto, ainda é possível que existam operações criptográficas específicas que sejam valiosas o suficiente para serem aceleradas, por isso faz sentido adicioná-las como pré-compiladas.
O que aprendemos com tudo isso?
O desejo de encapsular o mínimo possível é compreensível e bom; ele decorre da tradição filosófica do Unix de criar software minimalista que pode facilmente se adaptar às diferentes necessidades dos usuários e evitar a maldição do inchaço do software. No entanto, o blockchain não é um sistema operacional de computação pessoal, mas um sistema social. Isto significa que faz sentido encapsular certas funcionalidades no protocolo.
Em muitos casos, estes outros exemplos são semelhantes ao que vimos na abstração da conta. Mas também aprendemos algumas lições novas:
Funções encapsuladas podem ajudar a evitar riscos de centralização em outras áreas da pilha:
Freqüentemente, manter o protocolo básico mínimo e simples empurra a complexidade para algum ecossistema fora do protocolo. Do ponto de vista da filosofia Unix, tudo bem. No entanto, existe por vezes o risco de o ecossistema fora do protocolo se tornar centralizado, geralmente (mas não só) devido aos elevados custos fixos. O encapsulamento às vezes pode reduzir a centralização de fato.
Encapsular muito conteúdo pode estender demais a confiança e a carga de governança do protocolo:
Este é o assunto de um artigo anterior sobre "Não sobrecarregue o consenso do Ethereum": se o encapsulamento de um recurso específico enfraquece o modelo de confiança e torna o Ethereum como um todo mais "subjetivo", isso enfraquece o Ethereum. Neutralidade confiável. Nestes casos, é melhor ter a funcionalidade específica como um mecanismo no topo do Ethereum, em vez de tentar trazê-la para dentro do próprio Ethereum. Os pools de memória criptografados são o melhor exemplo aqui, o que pode ser um pouco difícil de encapsular, pelo menos até que a criptografia de latência melhore.
Encapsular muito conteúdo pode tornar o protocolo excessivamente complexo:
A complexidade do protocolo é um risco sistêmico que aumenta ao adicionar muitos recursos a um protocolo. A pré-compilação é o melhor exemplo.
No longo prazo, a funcionalidade de encapsulamento pode ser contraproducente porque as necessidades do usuário são imprevisíveis:
Um recurso que muitas pessoas consideram importante e que será utilizado por muitos usuários provavelmente não é utilizado com muita frequência na prática.
Além disso, o staking de liquidez, ZK-EVM e exemplos pré-compilados mostram a possibilidade de um caminho intermediário: consagração mínima viável. O protocolo não precisa encapsular toda a funcionalidade, mas pode conter partes específicas que abordam os principais desafios, tornando a funcionalidade fácil de implementar sem ser muito paranóica ou muito restrita. Exemplos incluem:
Em vez de encapsular um sistema completo de apostas de liquidez, é melhor alterar as regras de penalidade de apostas para tornar mais viável a aposta de liquidez sem confiança;
Em vez de encapsular mais pré-compiladores, é melhor encapsular EVM-MAX e/ou SIMD para facilitar a implementação eficiente de uma classe mais ampla de operações;
Pode simplesmente encapsular a verificação EVM em vez de encapsular todo o conceito de rollup.
Podemos estender o diagrama anterior da seguinte forma:
Às vezes faz sentido encapsular algo, e remover pré-compiladores raramente usados é um exemplo. A abstração da conta 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, na verdade, ser surpreendentemente semelhante àquele que desempacotou a pré-compilação: uma das propostas é o EIP-5003, que permitiria aos EOAs converter suas contas para terem o mesmo (ou melhor) contrato funcional.
Quais características devem ser trazidas para o protocolo e quais devem ser deixadas para outras camadas do ecossistema é uma troca complexa. Espera-se que esta compensação continue a melhorar ao longo do tempo, à medida que a nossa compreensão das necessidades dos utilizadores e o conjunto disponível de ideias e tecnologias continuam a melhorar.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
O último artigo longo de Buterin: O protocolo Ethereum deveria encapsular mais funções?
原文标题:O Ethereum deveria concordar em consagrar mais coisas no protocolo?
Autor original: Vitalik Buterin
Tradutor do Odaily Planet Daily | 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.
Este artigo irá aprofundar alguns dos raciocínios filosóficos por trás da filosofia original do encapsulamento mínimo, bem como algumas formas recentes de pensar sobre essas ideias. O objetivo será começar a construir uma estrutura para identificar melhor os possíveis objetivos onde o encapsulamento de determinadas funcionalidades pode valer a pena considerar.
Uma 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 sobre si mesmo e deixasse quase todo esse trabalho para os usuários. Idealmente, o protocolo é apenas uma máquina virtual e a validação de um bloco é apenas uma chamada de máquina virtual.
Esta é uma reconstrução aproximada do diagrama do quadro branco que Gavin Wood e eu desenhámos no início de 2015, quando estava falando sobre como seria o Ethereum 2.0.
A "função de transição de estado" (a função que lida com o bloco) será apenas uma única chamada de VM, e todas as outras lógicas acontecerão através de contratos: alguns contratos em nível de sistema, mas principalmente contratos fornecidos pelo usuário. Uma característica muito interessante deste modelo é que 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, em seguida, terá permissão de execução atualizada.
Estas discussões em 2015 aplicam-se especificamente a duas áreas que consideramos: abstração de contas e dimensionamento. No caso do escalonamento, a ideia é tentar criar uma forma abstrata máxima de escalonamento 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 funcionalidade de computação estendida muito geral. Da perspectiva da máquina virtual, a chamada irá para algum subsistema separado e retornará magicamente a resposta correta algum tempo depois.
Exploramos brevemente essa ideia, mas rapidamente a abandonamos porque estávamos muito focados em provar que qualquer tipo de escalonamento 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 futuro possível para o escalonamento do Ethereum na verdade parece muito próximo desta visão! Com a abstração da conta, 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 a tentar fazer algo o mais próximo possível do puro ponto de partida de “uma transação é apenas uma chamada”.
*Há muito código padrão entre o processamento da transação e a realização da chamada EVM subjacente real a partir do endereço do remetente, e mais código padrão depois disso. Como reduzimos esse código o mais próximo possível de zero? *
Um dos principais códigos aqui é valid_transaction(state, tx), que é responsável por verificar se o nonce e a assinatura da transação estão corretos. O verdadeiro objetivo da abstração de contas desde o início tem sido permitir que os usuários substituam a verificação não incremental básica e a verificação 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 múltiplas assinaturas. Portanto, encontrar uma maneira de reestruturar apply_transaction em uma simples chamada EVM não é apenas uma tarefa de "tornar o código limpo pelo simples fato de tornar o código limpo"; em vez disso, trata-se de mover a lógica para o código da conta do usuário, dando aos usuários a flexibilidade necessária. precisar.
No entanto, insistir que apply_transaction contenha o mínimo de lógica fixa possível acabou criando muitos desafios. Podemos dar uma olhada em uma das primeiras propostas de abstração de contas, EIP-86.
Se o EIP-86 fosse incluído como está, reduziria a complexidade do EVM ao custo de aumentar enormemente a complexidade de outras partes da pilha Ethereum, exigindo essencialmente que o mesmo código fosse escrito em outro lugar, além de introduzir um todo nova classe de estranheza. Por exemplo, a mesma transação com o mesmo valor de hash pode aparecer várias vezes na cadeia, sem mencionar o problema de invalidação múltipla.
*Vários problemas de invalidação na abstração de conta. Uma transação incluída na cadeia poderia invalidar milhares de outras transações no mempool, facilitando o preenchimento barato do mempool. *
Desde então, a abstração da conta evoluiu em etapas. O EIP-86 mais tarde tornou-se EIP-208 e, eventualmente, surgiu o prático EIP-2938.
No entanto, o EIP-2938 é tudo menos minimalista. Seu conteúdo inclui:
Em um esforço para alcançar a abstração de contas sem envolver os principais desenvolvedores do Ethereum (que estavam focados na otimização dos clientes Ethereum e na implementação de fusões), o EIP-2938 foi finalmente reprojetado como ERC-4337, que estava completamente fora do protocolo.
ERC-4337. Depende inteiramente de chamadas EVM!
Por ser um ERC, ele não requer um hard fork e existe tecnicamente “fora do protocolo Ethereum”. Então...problema resolvido? Acontece que não é o caso. O atual roteiro de médio prazo para o ERC-4337 envolve, na verdade, a transição de grandes partes do ERC-4337 para uma série de recursos de protocolo, o que é um exemplo útil de orientação sobre por que esse caminho deve ser considerado.
Pacote ERC-4337
Existem vários motivos principais discutidos para a eventual reincorporação do ERC-4337 no protocolo:
Vale ressaltar que em sua forma atual, o ERC-4337 é significativamente mais caro do que as transações “básicas” do Ethereum: uma transação custa 21.000 gás, enquanto o ERC-4337 custa cerca de 42.000 gás.
Em teoria, deveria ser possível ajustar o sistema de custo de gás EVM até que o custo no protocolo e o custo de acesso ao armazenamento fora do protocolo correspondam; não há razão para precisar gastar 9.000 gás para transferir ETH quando outros tipos de edição de armazenamento as operações são mais baratas. Na verdade, dois EIPs relacionados à próxima transformação da árvore Verkle tentam fazer exatamente isso. Mas mesmo se fizermos isso, há uma razão óbvia pela qual não importa o quão eficiente o EVM se torne, as funções do protocolo encapsulado serão inevitavelmente muito mais baratas do que o código EVM: o código encapsulado não precisa pagar gás para pré-carregamento.
Uma carteira ERC-4337 totalmente funcional é grande e a implementação compilada e colocada na cadeia ocupa cerca de 12.800 bytes. Claro, você poderia implantar esse código uma vez e usar DELEGATECALL para permitir que cada carteira individual o chamasse, mas você ainda precisaria acessar o código em cada bloco onde ele é usado. No EIP de custo de gás da árvore Verkle, 12.800 bytes formarão 413 pedaços. O acesso a esses pedaços exigirá o pagamento de 2 vezes o custo do ramo testemunha (um total de 3.800 gás) e 413 vezes o custo do pedaço testemunho (um total de 82.600). gás). Isso nem sequer 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 (aproximadamente 158.700 gases para carregar de acordo com as regras EIP da árvore Verkle).
Isto leva a um problema: o custo do gás para realmente acessar esses códigos deve ser amortizado de alguma forma entre as transações. A abordagem atual usada pelo ERC-4337 não é muito boa: a primeira transação do pacote consome um custo único de armazenamento/leitura de código, tornando-a muito mais cara do que outras transações. O encapsulamento intraprotocolo permitirá que essas bibliotecas públicas compartilhadas se tornem parte do protocolo e sejam livremente acessíveis a todos.
O que podemos aprender com este exemplo e quando o encapsulamento deve ser praticado de forma mais geral?
Neste exemplo, vemos algumas razões diferentes para encapsular abstrações de contas em protocolos.
Mas é importante lembrar que mesmo a abstração de contas dentro do protocolo de encapsulamento ainda é um enorme “desencapsulamento” em comparação com o status quo. Hoje, as transações Ethereum de nível superior só podem ser iniciadas a partir de contas de propriedade externa (EOA), que são verificadas usando uma única assinatura de curva elíptica secp 256k 1. A abstração da 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, vemos também o maior motivo contra o encapsulamento: Flexibilidade para atender às necessidades de diferentes usuários.
Vamos aprofundar a história examinando alguns outros exemplos de recursos que foram recentemente considerados para encapsulamento. Em particular, analisaremos: ZK-EVM, separação proponente-construtor, pools de memória privados, staking de liquidez e nova pré-compilação.
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. Existe um ecossistema bastante diversificado de implementações independentes: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth e muitos mais.
Uma controvérsia recente no campo EVM ZK-rollup está relacionada a como lidar com bugs que podem aparecer no código ZK. Atualmente, todos esses sistemas em operação possuem alguma forma de mecanismo de “conselho de segurança” que controla o sistema de atestação em caso de bug. No ano passado, tentei criar um quadro padronizado que encorajasse os projectos a esclarecer o quanto confiam no sistema de certificação e o quanto confiam no Conselho de Segurança, e a reduzir gradualmente a sua autoridade sobre essa organização ao longo do tempo.
*A médio prazo, é provável que o rollup dependa de múltiplos sistemas de certificação, com o Conselho de Segurança a ter poder apenas em casos extremos em que dois sistemas de certificação diferentes divergem. *
No entanto, há uma sensação de que parte deste trabalho parece redundante. Já temos uma camada base Ethereum, tem um EVM, e já temos um mecanismo funcional para lidar com bugs na implementação: se houver bug, o cliente será atualizado para corrigi-lo, e a cadeia continuará funcionando . Do ponto de vista do cliente com bugs, parece que os bloqueios finalizados não serão mais confirmados, mas pelo menos não veremos os usuários perdendo fundos. Da mesma forma, se os rollups quiserem apenas manter a função equivalente do EVM, então eles precisam implementar sua própria governança para mudar constantemente suas regras internas do ZK-EVM para corresponder às atualizações da camada base Ethereum, o que parece errado porque, em última análise, eles são construídos no topo da própria camada base Ethereum, ele sabe quando atualizar e de acordo com quais novas regras.
Como esses ZK-EVMs L2 usam basicamente exatamente o mesmo EVM do Ethereum, podemos de alguma forma incorporar "verificar a execução do EVM no ZK" na funcionalidade do protocolo e lidar com exceções aplicando o consenso social do Ethereum, como bugs e atualizações, como já fazemos para o A própria execução do EVM da camada base?
Este é um tema importante e desafiador.
Um possível tópico de debate sobre a disponibilidade de dados no ZK-EVM nativo é a monitoração de estado. ZK-EVMs seriam muito mais eficientes em termos de dados se não precisassem transportar dados de "testemunha". Ou seja, se um determinado dado foi lido ou escrito em algum bloco anterior, podemos simplesmente assumir que o provador tem acesso a ele e não precisa disponibilizá-lo novamente. Não se trata apenas de não recarregar o armazenamento e o código; acontece que, se um rollup compactar os dados corretamente, a compactação com estado poderá economizar até três vezes mais dados em comparação com a compactação sem estado.
Isso significa que para a pré-compilação 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 esse rollup ZK pré-compilado é muito mais caro do que usar o rollup de código personalizado.
**2.**A pré-compilação permite que ponteiros apontem para dados usados ou gerados por execuções anteriores. Isso torna o rollup ZK 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á uma boa razão para encapsular a verificação ZK-EVM de alguma forma: o rollup já está construindo sua própria versão personalizada, e Ethereum está disposto a implementar EVM em L1 com o peso de suas múltiplas implementações e consenso social fora da cadeia. errado, mas L2 fazendo exatamente o mesmo trabalho teria que implementar um dispositivo complexo envolvendo o Conselho de Segurança. Mas, por outro lado, há um grande problema nos detalhes: existem diferentes versões do ZK-EVM e têm custos e benefícios diferentes. A distinção entre stateful e stateless apenas arranha a superfície; tentativas de suportar código personalizado "quase EVM" que foi comprovado por outros sistemas podem expor um espaço de design maior. Portanto, embalar ZK-EVM traz esperança e desafios.
Proponente de encapsulamento e separação de construtor (ePBS)
A ascensão do MEV torna a produção de blocos uma actividade económica em escala, com actores sofisticados capazes de produzir blocos que geram mais receitas do que o algoritmo padrão, que simplesmente observa um mempool de transacções e contém-as. Até agora, a comunidade Ethereum tem tentado resolver este problema usando esquemas de separação proponente-construtor fora do protocolo, como MEV-Boost, que permite que validadores regulares ("proponentes") enviem blocos para Building é terceirizado para atores especializados ("Construtores ").
No entanto, o MEV-Boost faz suposições de confiança em uma nova classe de atores chamada retransmissores. Nos últimos dois anos, surgiram muitas propostas para criar um “pacote PBS”. Quais são os benefícios de fazer isso? Neste caso, a resposta é muito simples: um PBS construído usando diretamente recursos de protocolo é mais poderoso (no sentido de ter suposições de confiança mais fracas) do que um PBS construído sem usá-los. Isto é semelhante ao caso de encapsular oráculos de preços dentro de um protocolo – embora neste caso haja fortes objeções.
Encapsular pool de memória privada
Quando um usuário envia uma transação, ela fica imediatamente pública e visível para todos, mesmo antes de ser incluída na rede. Isto deixa os utilizadores de muitas aplicações vulneráveis a ataques económicos, como o front-running.
Recentemente, tem havido 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, porém, é que tal esquema requer um tipo especial de criptografia: para evitar que os usuários inundem o sistema e o descriptografem primeiro, a criptografia deve ser descriptografada automaticamente depois que a transação tiver sido realmente aceita de forma irreversível.
Existem várias técnicas com diferentes compensações para implementar esta forma de criptografia. Jon Charbonneau uma vez descreveu bem:
Infelizmente, cada método de criptografia tem pontos fracos diferentes. Embora para cada solução exista um segmento 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 atrasada seja aperfeiçoada ou algum outro avanço tecnológico, encapsular a funcionalidade de negociação anti-ahead na Camada 1 parece ser uma proposta difícil, mesmo que seja um recurso valioso o suficiente para que muitos aplicativos resolvam. surgiu o plano.
Encapsular a aposta de liquidez
Uma necessidade comum entre os usuários do Ethereum DeFi é a capacidade de usar simultaneamente seu ETH para piquetagem e como garantia em outras aplicações. Outra solicitação comum é simplesmente por conveniência: os usuários desejam poder fazer staking (e proteger as chaves de staking on-line) sem a complexidade de executar um nó e mantê-lo sempre on-line.
De longe, a “interface” de piquetagem mais simples que atende a essas duas necessidades é apenas um token ERC 20: converta seu ETH em “piquetagem ETH”, segure-o e depois converta-o novamente. Na verdade, provedores de liquidez como Lido e Rocket Pool já estão fazendo isso. No entanto, existem alguns mecanismos naturais de centralização em jogo com o staking de liquidez: as pessoas passarão naturalmente a apostar na versão maior da ETH porque é a mais familiar e líquida.
Cada versão do ETH apostado precisa ter algum mecanismo para determinar quem pode se tornar o operador do nó subjacente. Não pode ser ilimitado porque então os invasores participarão e usarão os fundos dos usuários para expandir seus ataques. Atualmente, os dois primeiros são Lido e Rocket Pool, com o primeiro tendo operadores de nós na lista de permissões do DAO e o último permitindo que qualquer pessoa execute um nó com um depósito de 8 ETH. Os dois métodos apresentam riscos diferentes: o método Rocket Pool permite que um invasor conduza um ataque de 51% na rede e força os usuários a pagar a maior parte dos custos; já no método DAO, se um determinado token apostado dominar, isso levará a um único dispositivo de governança potencialmente comprometido controla uma grande parte de todos os validadores Ethereum. Para seu crédito, protocolos como o Lido implementaram salvaguardas, mas uma camada de defesa pode não ser suficiente.
No curto prazo, uma opção é incentivar os participantes do ecossistema a utilizarem um conjunto diversificado de fornecedores de liquidez para reduzir a possibilidade de um interveniente dominante representar um risco sistémico. No longo prazo, porém, este é 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 alguma funcionalidade no protocolo para tornar o staking de liquidez menos centralizado? **
A questão principal aqui é: que tipo de funcionalidade no protocolo? Um problema com a simples criação de um token fungível de "staking ETH" dentro do protocolo é que ele teria que ter uma governança encapsulada em todo o Ethereum para escolher quem executará os nós, ou seria aberto, mas isso o transformaria em um ataque do invasor. Ferramentas.
Uma ideia interessante é o artigo de Dankrad Feist sobre maximização da aposta de liquidez. Primeiro, vamos enfrentar a questão: se o Ethereum estiver sujeito a um ataque de 51%, apenas 5% do ETH atacado poderá ser cortado. Esta é uma compensação razoável; com mais de 26 milhões de ETH atualmente apostados, o custo de atacar um terço disso (~8 milhões de ETH) é excessivo, especialmente considerando quantos ataques “fora do modelo” podem ser feitos de uma só vez. custo mais baixo. Na verdade, compensações semelhantes foram exploradas na proposta do Supercomité para implementar a finalidade de faixa única.
Se aceitarmos que apenas 5% do ETH de ataque é cortado, então mais de 90% do ETH apostado não será afetado pelo corte, então eles podem ser usados como tokens de piquetagem líquidos fungíveis dentro do protocolo e depois usados por outras aplicações.
Este caminho é interessante. Mas ainda deixa uma questão: o que exatamente está encapsulado? **Rocket Pool funciona de forma muito semelhante: cada operador de nó fornece alguns fundos e os stakers de liquidez fornecem o restante. Podemos simplesmente ajustar algumas constantes para limitar a penalidade máxima de redução a 2 ETH, e o rETH existente do Rocket Pool se tornará livre de riscos.
Com simples ajustes de protocolo, também podemos fazer outras coisas inteligentes. Por exemplo, digamos que queremos um sistema com dois "níveis" de piquetagem: operadores de nós (elevados requisitos de garantia) e depositantes (sem requisitos mínimos de garantia, podem entrar e sair a qualquer momento), mas ainda queremos dotar uma amostra aleatória poderes do comitê de depositantes para evitar a centralização dos operadores de nós, como recomendar uma lista de transações que devem ser incluídas (por motivos de resistência à censura), controlar a seleção de fork durante vazamentos de inatividade ou exigir assinaturas em blocos. Isso poderia ser feito de uma forma que essencialmente sai do protocolo, ajustando o protocolo para exigir que cada validador forneça (i) uma chave de piquetagem regular e (ii) um endereço ETH que pode ser usado em cada slot é chamado para gerar o chave de penhor secundária. O protocolo daria poder a ambas as chaves, mas o mecanismo para selecionar a segunda chave em cada slot poderia ser deixado para o protocolo do pool de piquetagem. Ainda pode ser melhor encapsular algumas funcionalidades diretamente, mas é importante notar que esse espaço de design de “incluir algumas coisas e deixar outras para o usuário” existe.
Encapsular mais pré-compilação
Contratos pré-compilados (ou "contratos pré-compilados") são contratos Ethereum que implementam operações criptográficas complexas, com lógica implementada nativamente no código do cliente, em vez do código do contrato inteligente EVM. A pré-codificação é um compromisso adotado desde o início do desenvolvimento do Ethereum: como o overhead de uma máquina virtual é muito grande para algum código muito complexo e altamente especializado, podemos implementar algumas aplicações importantes em código nativo, valorizando operações críticas para torná-las mais rápidas. Hoje, isso inclui basicamente algumas funções hash específicas e operações de curva elíptica.
Atualmente, há um impulso para adicionar pré-compilação para secp 256 r 1, uma curva elíptica ligeiramente diferente da secp 256 k 1 usada para contas Ethereum básicas, que é amplamente utilizada, pois é bem suportada por módulos de hardware confiáveis. Use-a para aumentar a segurança da carteira. Nos últimos anos, a comunidade também pressionou para adicionar pré-compilação para BLS-12-377, BW 6-761, emparelhamento generalizado e outros recursos.
O contra-argumento a esses pedidos por mais pré-compiladores é que muitos dos pré-compiladores adicionados anteriormente (como RIPEMD e BLAKE) acabaram sendo usados muito menos do que o esperado, e devemos aprender com isso. Em vez de adicionar mais pré-compilação para operações específicas, talvez devêssemos nos concentrar em uma abordagem mais suave baseada em ideias como EVM-MAX e a proposta SIMD Hibernate-But-Always-Resumable, que permitiria que implementações de EVM rodassem com menor custo. uma ampla gama de classes de código. Talvez até mesmo a pré-compilação existente e pouco utilizada pudesse ser removida e substituída por uma implementação de código EVM (inevitavelmente menos eficiente) das mesmas funções. Dito isto, ainda é possível que existam operações criptográficas específicas que sejam valiosas o suficiente para serem aceleradas, por isso faz sentido adicioná-las como pré-compiladas.
O que aprendemos com tudo isso?
O desejo de encapsular o mínimo possível é compreensível e bom; ele decorre da tradição filosófica do Unix de criar software minimalista que pode facilmente se adaptar às diferentes necessidades dos usuários e evitar a maldição do inchaço do software. No entanto, o blockchain não é um sistema operacional de computação pessoal, mas um sistema social. Isto significa que faz sentido encapsular certas funcionalidades no protocolo.
Em muitos casos, estes outros exemplos são semelhantes ao que vimos na abstração da conta. Mas também aprendemos algumas lições novas:
Freqüentemente, manter o protocolo básico mínimo e simples empurra a complexidade para algum ecossistema fora do protocolo. Do ponto de vista da filosofia Unix, tudo bem. No entanto, existe por vezes o risco de o ecossistema fora do protocolo se tornar centralizado, geralmente (mas não só) devido aos elevados custos fixos. O encapsulamento às vezes pode reduzir a centralização de fato.
Este é o assunto de um artigo anterior sobre "Não sobrecarregue o consenso do Ethereum": se o encapsulamento de um recurso específico enfraquece o modelo de confiança e torna o Ethereum como um todo mais "subjetivo", isso enfraquece o Ethereum. Neutralidade confiável. Nestes casos, é melhor ter a funcionalidade específica como um mecanismo no topo do Ethereum, em vez de tentar trazê-la para dentro do próprio Ethereum. Os pools de memória criptografados são o melhor exemplo aqui, o que pode ser um pouco difícil de encapsular, pelo menos até que a criptografia de latência melhore.
A complexidade do protocolo é um risco sistêmico que aumenta ao adicionar muitos recursos a um protocolo. A pré-compilação é o melhor exemplo.
Um recurso que muitas pessoas consideram importante e que será utilizado por muitos usuários provavelmente não é utilizado com muita frequência na prática.
Além disso, o staking de liquidez, ZK-EVM e exemplos pré-compilados mostram a possibilidade de um caminho intermediário: consagração mínima viável. O protocolo não precisa encapsular toda a funcionalidade, mas pode conter partes específicas que abordam os principais desafios, tornando a funcionalidade fácil de implementar sem ser muito paranóica ou muito restrita. Exemplos incluem:
Podemos estender o diagrama anterior da seguinte forma:
Às vezes faz sentido encapsular algo, e remover pré-compiladores raramente usados é um exemplo. A abstração da conta 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, na verdade, ser surpreendentemente semelhante àquele que desempacotou a pré-compilação: uma das propostas é o EIP-5003, que permitiria aos EOAs converter suas contas para terem o mesmo (ou melhor) contrato funcional.
Quais características devem ser trazidas para o protocolo e quais devem ser deixadas para outras camadas do ecossistema é uma troca complexa. Espera-se que esta compensação continue a melhorar ao longo do tempo, à medida que a nossa compreensão das necessidades dos utilizadores e o conjunto disponível de ideias e tecnologias continuam a melhorar.