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 esteticamente agradável que tentasse construir por conta própria com o mínimo possível e deixasse quase todo esse tipo de trabalho para os usuários. Idealmente, o protocolo é apenas uma máquina virtual, e validar um bloco é apenas uma chamada de máquina virtual.
A "função de transição de estado" (a função que processa o bloco) será apenas uma única chamada de VM, e toda a outra lógica acontecerá através do contrato: alguns contratos no nível do sistema, mas principalmente contratos fornecidos pelo usuário. Uma característica muito boa desse modelo é que até mesmo um hard fork inteiro pode ser descrito como uma única transação para um contrato de processador de bloco que será aprovado pela governança off-chain ou on-chain e, em seguida, executado com privilégios elevados.
Estas discussões em 2015 aplicam-se, em particular, a duas áreas consideradas: abstração de contas e escala. No caso do dimensionamento, a ideia é tentar criar uma forma de abstração máxima de escalonamento que pareça uma extensão natural do gráfico acima. Os contratos podem chamar dados que não são armazenados pela maioria dos nós Ethereum, e o protocolo detetará isso e resolverá a chamada com algum tipo de função de computação estendida muito geral. Da perspetiva da máquina virtual, a chamada entra em algum subsistema separado e retorna magicamente a resposta correta depois de um tempo.
Exploramos essa linha de pensamento brevemente, mas rapidamente desistimos porque estávamos muito focados em verificar se qualquer tipo de escalonamento de blockchain é possível. Embora vejamos mais tarde, a combinação de amostragem de disponibilidade de dados e ZK-EVM significa que um possível futuro para o escalonamento Ethereum realmente parece muito próximo dessa visão! Por outro lado, para a abstração de contas, sabíamos desde o início que algum tipo de implementação era possível, então a pesquisa imediatamente começou a tentar trazer algo o mais próximo possível do ponto de partida puro de "negociar é apenas uma chamada" para a realidade.
Entre processar a transação e fazer a chamada EVM subjacente real do endereço do remetente, há muito código clichê e mais código clichê depois disso. Como podemos reduzir este 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 a transação tem o nonce e a assinatura corretos. Desde o início, o objetivo prático da abstração de conta era permitir que os usuários substituíssem a verificação básica não incremental e ECDSA por sua própria lógica de verificação, para que os usuários pudessem usar mais facilmente recursos como recuperação social e carteiras multiassinatura. Assim, encontrar uma maneira de rearquitetar a aplicação_transaction como uma simples chamada EVM não é apenas uma tarefa de "código limpo para tornar o código limpo"; Em vez disso, trata-se de mover a lógica para o código de conta do usuário, dando ao usuário a flexibilidade de que precisa.
No entanto, insistir que aplicar_transaction conter o mínimo possível de lógica fixa acaba criando muitos desafios. Podemos dar uma olhada em uma das primeiras propostas de abstração de contas, EIP-86 .
Se o EIP-86 for incluído como está, reduzirá a complexidade do EVM ao custo de aumentar maciçamente a complexidade de outras partes da pilha Ethereum, exigindo que um código essencialmente idêntico seja escrito em outro lugar, exceto para introduzir categorias estranhas inteiramente novas, como a mesma transação com o mesmo número de hash pode aparecer várias vezes na cadeia, sem mencionar o problema de invalidação múltipla.
Múltiplos problemas de invalidação na abstração da conta. Uma transação incluída on-chain pode invalidar milhares de outras transações no mempool, tornando o mempool fácil de inundar de forma barata.
Desde então, a abstração de contas evoluiu em etapas. O EIP-86 mais tarde tornou-se EIP-208 e, eventualmente, o EIP-2938 prático.
No entanto, o EIP-2938 é tudo menos minimalista. O seu conteúdo inclui:
· Novos tipos de transação
· Variáveis globais para três novos escopos de negociação
· Dois novos opcodes, incluindo o muito desajeitado opcode PAYgas para lidar com verificações de preço e limite de gás, realizar pontos de interrupção como EVM e armazenar temporariamente ETH por uma taxa única
· 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
A fim de implementar a abstração de conta sem envolver os desenvolvedores principais do Ethereum (que se concentram na otimização dos clientes Ethereum e na implementação da fusão), o EIP-2938 acabou sendo rearquitetado para o ERC-4337 totalmente fora do protocolo.
Por se tratar de um ERC, ele não requer um hard fork e tecnicamente existe "fora do protocolo Ethereum". Então...... O problema está resolvido? Acontece que não é esse o caso. O atual roteiro de médio prazo do ERC-4337 envolve, na verdade, eventualmente transformar grande parte do ERC-4337 em um conjunto de recursos de protocolo, o que é um exemplo orientador útil de por que esse caminho deve ser considerado.
Pacote ERC-4337
Existem várias razões principais discutidas para eventualmente trazer o ERC-4337 de volta ao protocolo:
Eficiência de gás: Qualquer operação feita dentro do EVM resulta 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.000 gás, ou mais. Colocar esses componentes em um protocolo é a maneira mais fácil de eliminar esses problemas.
Risco de bug de código: Se o "contrato de ponto de entrada" do ERC-4337 tiver um bug assustador o suficiente, todas as carteiras compatíveis com o ERC-4337 podem ver todos os seus fundos secarem. A substituição de contratos por funcionalidade no protocolo cria uma obrigação implícita de corrigir erros de código através de hard forks, eliminando assim o risco de os fundos dos utilizadores secarem.
Suporte para opcodes EVM, como txt.origin. O próprio ERC-4337 faz com que txt.origin retorne o endereço de um "bundler" que empacota um conjunto de ações do usuário em uma transação. A abstração de conta nativa resolve esse problema fazendo com que txt.origin aponte para a conta real que envia a transação, fazendo com que ela funcione da mesma forma que o EOA.
Resistente à censura: Um dos desafios da separação proponente/construtor é que se torna mais fácil rever transações individuais. Este problema pode ser muito aliviado em um mundo onde o protocolo Ethereum pode reconhecer uma única transação, permitindo que o proponente especifique 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 "apropriado" resolverá esse problema.
Vale a pena mencionar que, em sua forma atual, o ERC-4337 é muito mais caro do que uma transação Ethereum "básica": o custo de transação é de 21.000 gás, enquanto o ERC-4337 custa cerca de 42.000 gás.
Teoricamente, deveria ser possível ajustar o sistema de custos de gás EVM até que o custo no acordo e o custo do acesso fora do protocolo ao armazenamento coincidissem; Quando outros tipos de operações de edição de armazenamento são mais baratos, não há razão para transferir ETH a 9000 gás. Na verdade, dois EIPs relacionados à próxima conversão da árvore Verkle realmente tentam fazer exatamente isso. Mas mesmo que o façamos, há uma razão óbvia pela qual a funcionalidade de protocolo encapsulado será inevitavelmente muito mais barata do que o código EVM, não importa quão eficiente o EVM se torne: o código encapsulado não precisa pagar gás para pré-carregamento.
A carteira ERC-4337 totalmente funcional é grande, e a implementação que a compila e coloca on-chain ocupa 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 você ainda precisa acessar o código em cada bloco que o usa. Sob o EIP de custo de gás da árvore Verkle, 12.800 bytes constituiriam 413 blocos, e acessar esses pedaços exigiria pagar 2x o ramo testemunha_cost (3.800 gás total) e 413x o pedaço testemunha_cost (82.600 gás total). E isso nem está começando a mencionar o ponto de entrada ERC-4337 em si, que na versão 0.6.0 tem 23.689 bytes na cadeia (cerca de 158.700 gás para carregar de acordo com as regras EIP da árvore Verkle).
Isso leva ao problema: o custo do gás de realmente acessar esses códigos deve de alguma forma ser amortizado em toda a transação. A abordagem atual usada pelo ERC-4337 não é muito boa: a primeira transação no pacote consome um custo único de armazenamento/leitura de código, tornando-a muito mais cara do que outras transações. O encapsulamento no protocolo permitirá que essas bibliotecas públicas compartilhadas façam parte do protocolo e sejam livremente acessíveis a todos.
O que podemos aprender com este exemplo e quando as embalagens serão mais comuns? **
Neste exemplo, vemos algumas lógicas diferentes para encapsular o aspeto de abstração de conta no protocolo.
As abordagens baseadas no mercado que "empurram a complexidade para o 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 que cada bloco tem muitos custos fixos. 244, 100 gás para carregar códigos de carteira padronizados é uma coisa; Mas a agregação pode adicionar centenas de milhares de gás à validação ZK-SNARK, bem como o custo on-chain da validação de prova de cadeia. Não há como cobrar dos usuários por esses custos sem introduzir muitas ineficiências de mercado, e traduzir alguns desses recursos em recursos de protocolo que todos podem acessar gratuitamente resolve bem esse problema.
Respostas de toda a comunidade a bugs de código. Se alguns trechos de código são usados por todos os usuários ou uma gama muito ampla de usuários, geralmente faz mais sentido para a comunidade blockchain assumir a responsabilidade por um hard fork para corrigir quaisquer bugs que surjam. O ERC-4337 introduz uma grande quantidade de código globalmente compartilhado, e corrigir bugs no código através de um hard fork é, sem dúvida, mais razoável a longo prazo do que fazer com que os usuários percam muito ETH.
Às vezes, uma forma mais forte pode ser alcançada alavancando diretamente a funcionalidade do protocolo. O principal exemplo aqui é o recurso anticensura no protocolo, como a lista de inclusão: a lista de inclusão dentro do protocolo pode garantir resistência à censura melhor do que o método fora do protocolo, e para que as operações no nível do usuário realmente se beneficiem da lista de inclusão dentro do protocolo, uma única operação no nível do usuário precisa ser "legível" para o protocolo. Outro exemplo menos conhecido é o design de prova de participação Ethereum da era de 2017 que abstraiu a conta de chave de participação, que foi abandonada em favor do encapsulamento do BLS, já que o BLS suporta um mecanismo de "agregação" que deve ser implementado no nível de protocolo e rede, o que pode tornar o tratamento de um grande número de assinaturas mais eficiente.
Mas é importante lembrar que mesmo encapsular a abstração de conta no protocolo ainda é um enorme "desencapsulamento" em comparação com a situação atual. Hoje, as transações Ethereum de nível superior só podem ser iniciadas a partir de contas de propriedade externa (EOAs) que são verificadas com uma única assinatura de curva elíptica secp 256k1. A abstração de conta elimina isso e deixa os critérios de validação para o usuário definir. Assim, nesta história sobre abstração de contas, também vemos o maior argumento contra o encapsulamento: flexibilidade para atender às necessidades de diferentes usuários.
Vamos aprofundar ainda mais esta história olhando para vários outros exemplos de recursos que foram recentemente considerados encapsulados. Prestaremos especial atenção a: ZK-EVM, separação proponente-construtor, mempools privados, staking de liquidez e nova pré-compilação.
Pacote ZK-EVM
Vamos voltar nossa atenção para outro alvo potencial de encapsulamento do protocolo Ethereum: ZK-EVM. Atualmente, temos um grande número de rollups ZK, todos os quais têm que escrever código bastante semelhante para verificar a execução de blocos Ethereum semelhantes no ZK-SNARK. 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 espaço EVM ZK-rollup tem a ver com como lidar com possíveis bugs no código ZK. Atualmente, todos esses sistemas em execução têm algum tipo de mecanismo do "Conselho de Segurança" que controla o sistema de atestado em caso de bugs. No ano passado, tentei criar uma estrutura padronizada para incentivar projetos a esclarecer seu nível de confiança no sistema de certificação, bem como no Conselho de Segurança, e reduzir gradualmente sua autoridade sobre a organização ao longo do tempo.
A médio prazo, os rollups podem contar com vários sistemas de atestado, e o Conselho de Segurança só terá o poder em casos extremos em que dois sistemas de certificação diferentes divergem.
No entanto, há um sentimento de que parte do trabalho parece redundante. Já temos a camada base Ethereum, tem um EVM, e já temos um mecanismo de trabalho para lidar com bugs na implementação: se houver um bug, o cliente atualizará para corrigi-lo, e então a cadeia continuará a funcionar. Do ponto de vista do cliente buggy, parece que os blocos que foram finalizados não serão mais confirmados, mas pelo menos não veremos os usuários perderem dinheiro. Da mesma forma, se os rollups querem apenas manter seu papel equivalente ao EVM, então eles precisam implementar sua própria governança para mudar constantemente suas regras internas ZK-EVM para corresponder às atualizações para a camada base do Ethereum, o que parece errado porque, em última análise, eles são construídos em cima da própria camada base do Ethereum, que sabe quando atualizar e de acordo com quais novas regras.
Uma vez que esses L2 ZK-EVMs usam basicamente exatamente os mesmos EVMs do Ethereum, podemos de alguma forma incorporar "verificar a execução do EVM no ZK" na função de protocolo e lidar com exceções, como bugs e atualizações, aplicando o consenso social do Ethereum, como já fazemos com a própria implementaçã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 é o statefulness. Se os ZK-EVMs não precisassem carregar dados "testemunhas", sua eficiência de dados seria muito maior. Ou seja, se um determinado dado já foi lido ou escrito em algum bloco anterior, podemos simplesmente supor 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 a compactação stateful pode salvar até 3x dados em comparação com a compactação stateless se um rollup compactar os dados corretamente.
Isso significa que, para a pré-compilação ZK-EVM, temos duas opções:
A pré-compilação requer que todos os dados estejam disponíveis no mesmo bloco. Isso significa que o provador pode ser sem monitoração de estado, mas também significa que usar esse pacote cumulativo de ZK pré-compilado é muito mais caro do que usar o pacote cumulativo com código personalizado.
A pré-compilação permite que o ponteiro aponte para dados previamente executados, usados ou gerados. Isso torna o ZK-rollup quase 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 de alguma forma a verificação ZK-EVM: o rollup já está construindo sua própria versão personalizada, e o Ethereum está disposto a pesar suas múltiplas implementações e consenso social off-chain em L1 para executar EVM, o que parece errado, mas L2 fazendo exatamente o mesmo trabalho deve implementar gadgets complexos envolvendo o Conselho de Segurança. Mas, por outro lado, há um grande problema nos detalhes: existem diferentes versões do ZK-EVM, que diferem em custo e benefício. A distinção entre stateful e stateless apenas arranha a superfície; Tentar suportar "quase-EVM", códigos personalizados que foram comprovados por outros sistemas, pode expor mais espaço de design. Encapsular o ZK-EVM, portanto, apresenta promessas e desafios.
Separação entre invólucros e construtores (ePBS)
A ascensão do MEV tornou a produção de blocos uma atividade econômica em grande escala, com participantes complexos capazes de produzir blocos que geram mais receita do que o algoritmo padrão, que simplesmente observa o mempool de transações e as contém. Até agora, a comunidade Ethereum tentou resolver esse problema usando um esquema de separação entre proponente e construtor 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 chamada revezamentos. Nos últimos dois anos, houve muitas propostas para criar "PBS encapsulado". Quais são os benefícios disso? Neste caso, a resposta é simples: o PBS construído diretamente com recursos de protocolo é mais poderoso (no sentido de ter pressupostos de confiança mais fracos) do que o PBS construído sem eles. Isso é semelhante ao caso dos oráculos de preço dentro do protocolo de encapsulamento – embora, neste caso, também haja forte oposição.
Encapsulando pool de memória privada
Quando um usuário envia uma transação, ela é 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 transações preventivas.
Recentemente, houve uma série de projetos dedicados à criação de "mempools privados" (ou "mempools criptografados") que criptografam as transações dos usuários até que elas sejam irreversivelmente aceitas em um bloco.
O problema, no entanto, é que tais esquemas exigem um tipo especial de criptografia: para evitar que os usuários inundem o sistema e o descriptografem primeiro, a criptografia deve ser automaticamente descriptografada depois que a transação tiver sido de fato irreversivelmente aceita.
Para conseguir esta forma de encriptação, existem várias técnicas de compensação. Jon Charbonneau disse uma vez bem:
Criptografe operadores centralizados, como o Flashbots Protect.
criptografia timelock, que pode ser descriptografada por qualquer pessoa após uma determinada etapa de cálculo sequencial e não pode ser paralelizada;
Criptografia de limite, confiando em um comitê de maioria honesta para descriptografar os dados. Para obter recomendações específicas, consulte Conceito de cadeia de beacon fechada.
Hardware confiável, como SGX.
Infelizmente, cada encriptação tem pontos fracos diferentes. Embora para cada solução, haja um subconjunto de usuários dispostos a confiar nela, nenhuma das soluções é confiável o suficiente para que ela seja realmente aceita pela Camada 1. Assim, pelo menos até que a criptografia de latência seja aperfeiçoada ou algum outro avanço tecnológico, encapsular a funcionalidade de negociação anti-avançada na Camada 1 parece uma proposta difícil, mesmo que seja um recurso valioso o suficiente para que muitas soluções de aplicativos tenham surgido.
Estabilização de liquidez encapsulada
Uma necessidade comum para os usuários do Ethereum DeFi é a capacidade de usar seu ETH simultaneamente para staking e como garantia em outros aplicativos. Outra necessidade comum é simplesmente por conveniência: os usuários querem ser capazes de apostar (e proteger chaves de staking online) sem a complexidade de executar um nó e mantê-lo sempre online.
Até agora, a "interface" de staking mais simples que satisfaz ambas as necessidades é apenas um token ERC 20: converta seu ETH em "stake ETH", segure-o e converta-o de volta. Na verdade, provedores de staking de liquidez como Lido e Rocket Pool já começaram a fazê-lo. No entanto, o staking de liquidez tem alguns mecanismos naturais de centralização em ação: as pessoas naturalmente entram na versão maior do staking ETH porque é o mais familiar e líquido.
Cada versão do ETH de staking requer algum mecanismo para determinar quem pode ser o operador do nó subjacente. Não pode ser ilimitado, pois então os atacantes se juntarão e amplificarão o ataque com os fundos do usuário. Atualmente, os dois primeiros são o Lido, que tem um operador de nó de lista branca DAO, e o Rocket Pool, que permite que qualquer pessoa execute um nó com 8 ETH depositados. Os dois métodos têm riscos diferentes: a abordagem Rocket Pool permite que os atacantes realizem ataques de 51% na rede e força os usuários a pagar a maior parte do custo; Quanto à abordagem DAO, se um determinado token de staking dominar, isso resulta em um único gadget de governança potencialmente atacado controlando uma parte significativa de todos os validadores Ethereum. É certo que protocolos como o Lido já têm precauções em vigor, mas uma camada de defesa pode não ser suficiente.
A curto prazo, uma opção consiste em incentivar os participantes no ecossistema a utilizarem uma gama diversificada de fornecedores de liquidez para reduzir a probabilidade de risco sistémico de uma única empresa. A longo prazo, porém, trata-se de um equilíbrio precário e é perigoso confiar demasiado na pressão moral para resolver os problemas. Uma pergunta natural surge: faz sentido encapsular algum tipo de funcionalidade no protocolo para tornar o staking de liquidez menos centralizado?
A questão-chave aqui é: que tipo de funcionalidade no protocolo? O problema com a simples criação de um token fungível "staking ETH" no protocolo é que ele tem que ter uma governança encapsulada em todo o Ethereum para escolher quem executa os nós, ou é aberto, mas isso o transforma em uma ferramenta para invasores.
Uma ideia interessante é o artigo de Dankrad Feist sobre a maximização da staking de liquidez. Primeiro, vamos morder a bala e se o Ethereum for atacado por 51%, apenas 5% do ataque ETH pode ser confiscado. Trata-se de um compromisso razoável; Com mais de 26 milhões de ETH atualmente sendo apostados, um terço disso (cerca de 8 milhões de ETH) do custo do ataque é excessivo, especialmente considerando quantos ataques "fora do modelo" podem ser feitos a um custo menor. De facto, foram exploradas soluções de compromisso semelhantes na proposta da Super Comissão de implementar a finalidade da faixa horária única.
Se aceitarmos que apenas 5% do ETH de ataque é confiscado, então mais de 90% do ETH apostado não será afetado pelo confisco, então eles podem ser usados como tokens de staking de liquidez fungível dentro do protocolo e, em seguida, usados por outros aplicativos.
O caminho é interessante. Mas ainda deixa a pergunta: o que exatamente é encapsulado? O 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 a 2 ETH e o rETH existente do Rocket Pool se tornará livre de riscos.
Com ajustes de protocolo simples, também podemos fazer outras coisas inteligentes. Por exemplo, digamos que queremos um sistema com duas "camadas" de staking: operadores de nó (altos requisitos de garantia) e depositantes (sem requisitos mínimos de garantia e podem entrar e sair a qualquer momento), mas ainda queremos impedir a centralização dos operadores de nó capacitando um comitê de depositantes amostrado aleatoriamente, como sugerir uma lista de transações que devem ser incluídas (por razões resistentes à censura), controlar a seleção de forks durante vazamentos inativos ou exigir assinatura de bloco. Isso pode ser conseguido de uma forma que essencialmente se desvincula 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 em cada slot para gerar uma chave de staking secundária. O protocolo dará poder a ambas as chaves, mas o mecanismo para escolher a segunda chave em cada slot pode ser deixado para o protocolo do pool de apostas. Ainda pode ser melhor encapsular alguns recursos diretamente, mas vale a pena notar que isso "incluir algumas coisas e deixar tudo o resto para o usuário" espaço de design existe.
Encapsular mais pré-compilações
Pré-compilados (ou "contratos pré-compilados") são contratos Ethereum que implementam operações criptográficas complexas, cuja 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 de uma máquina virtual era muito grande para algum código muito complexo e altamente especializado, poderíamos implementar algumas operações-chave em código local que eram valiosas para aplicações importantes para torná-lo mais rápido. Hoje, isso basicamente inclui algumas funções de hash específicas e operações de curva elíptica.
Atualmente, há um esforço para adicionar pré-compilação para secp 256 R1, uma curva elíptica ligeiramente diferente da secp 256 K1 para contas Ethereum básicas, pois é bem suportado por módulos de hardware confiáveis, então o uso generalizado dele pode melhorar a segurança da carteira. Nos últimos anos, a comunidade também pressionou pela adição de pré-compilações para BLS-12-377, BW 6-761, emparelhamento generalizado e outros recursos.
O contra-argumento para esses pedidos de mais arquivos pré-compilados é que muitas das pré-compilações adicionadas anteriormente (por exemplo, RIPEMD e BLAKE) acabam usando muito menos do que o esperado, e devemos aprender com eles. 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 propostas SIMD adormecidas, mas sempre recuperáveis, que permitirão que as implementações de EVM executem uma ampla gama de classes de código a um custo mais baixo. Talvez até mesmo a pré-compilação existente raramente usada pudesse ser removida e substituída por uma implementação (inevitavelmente menos eficiente) do código EVM da mesma função. Dito isso, ainda é possível que existam operações criptográficas específicas que sejam valiosas o suficiente para acelerar, então faz sentido adicioná-las como pré-compiladas.
O que aprendemos com tudo isto?
O desejo de encapsular o mínimo possível é compreensível e bom; Deriva da tradição filosófica Unix de criar software minimalista 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 certas funcionalidades no protocolo.
Em muitos casos, esses outros exemplos são semelhantes ao que vemos na abstração do relato. Mas também aprendemos algumas novas lições:
O encapsulamento pode ajudar a evitar o risco de centralização em outro lugar da pilha:
Muitas vezes, manter o protocolo básico mínimo e simples empurra a complexidade para além de alguns dos protocolos do ecossistema. Do ponto de vista filosófico do Unix, isso é bom. No entanto, às vezes há o risco de que ecossistemas fora do protocolo se centralizem, geralmente (mas não só) por causa dos altos custos fixos. Às vezes, o encapsulamento pode reduzir a centralização de fato.
Encapsular muito conteúdo pode expandir demais a confiança e a carga de governança no protocolo:
Este é o tópico de um artigo anterior sobre "Não sobrecarregue o consenso Ethereum": se encapsular uma função específica enfraquece o modelo de confiança e torna o Ethereum como um todo mais "subjetivo", enfraquece a neutralidade confiável do Ethereum. Nesses casos, é melhor apresentar um recurso específico como um mecanismo em cima do Ethereum do que tentar introduzi-lo ao próprio Ethereum. Aqui, os pools de memória criptografada são o melhor exemplo, e pode ser um pouco difícil de encapsular, pelo menos até que a criptografia de latência melhore.
Encapsular demais pode complicar demais o protocolo:
A complexidade do protocolo é um risco sistêmico que pode ser aumentado pela adição de muitos recursos ao protocolo. A pré-compilação é o melhor exemplo.
A longo prazo, a funcionalidade de encapsulamento pode sair pela culatra porque as necessidades do usuário são imprevisíveis:
Um recurso que muitas pessoas consideram importante e será usado por muitos usuários provavelmente não é usado regularmente na prática.
Além disso, o staking de liquidez, ZK-EVM e casos pré-compilados mostram a possibilidade de um caminho intermediário: a consagração mínima viável. Os protocolos não precisam encapsular toda a função, mas podem conter partes específicas que abordam os principais desafios, tornando a função fácil de implementar sem ser muito paranoica ou muito estreita. Exemplos disso incluem:
Em vez de encapsular um sistema completo de penhor de liquidez, é melhor alterar as regras de penalização de staking para tornar mais viável o penhor de liquidez sem confiança;
Em vez de encapsular mais pré-compiladores, encapsular EVM-MAX e/ou SIMD para facilitar a implementação eficiente para uma ampla gama de categorias operacionais;
A verificação EVM pode simplesmente ser encapsulada em vez de encapsular todo o conceito de rollup.
Podemos expandir o gráfico anterior da seguinte forma:
Às vezes, faz sentido embrulhar algo, e 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 apoiar a retrocompatibilidade para os utilizadores existentes, o mecanismo pode realmente ser surpreendentemente semelhante ao que desencapsula pré-compilados: uma das propostas é o EIP-5003, que permitiria à EOA converter as suas contas em contratos com a mesma (ou melhor) funcionalidade.
Que características devem ser introduzidas no protocolo e quais devem ser deixadas para outras camadas do ecossistema é um compromisso complexo. Espera-se que este compromisso continue a melhorar ao longo do tempo, à medida que a nossa compreensão das necessidades dos utilizadores e das ideias e pacotes tecnológicos disponíveis continue a melhorar.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Vitalik Buterin: O Ethereum deve encapsular mais recursos?
Primeiras filosofias do minimalismo protocolar
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 esteticamente agradável que tentasse construir por conta própria com o mínimo possível e deixasse quase todo esse tipo de trabalho para os usuários. Idealmente, o protocolo é apenas uma máquina virtual, e validar um bloco é apenas uma chamada de máquina virtual.
A "função de transição de estado" (a função que processa o bloco) será apenas uma única chamada de VM, e toda a outra lógica acontecerá através do contrato: alguns contratos no nível do sistema, mas principalmente contratos fornecidos pelo usuário. Uma característica muito boa desse modelo é que até mesmo um hard fork inteiro pode ser descrito como uma única transação para um contrato de processador de bloco que será aprovado pela governança off-chain ou on-chain e, em seguida, executado com privilégios elevados.
Estas discussões em 2015 aplicam-se, em particular, a duas áreas consideradas: abstração de contas e escala. No caso do dimensionamento, a ideia é tentar criar uma forma de abstração máxima de escalonamento que pareça uma extensão natural do gráfico acima. Os contratos podem chamar dados que não são armazenados pela maioria dos nós Ethereum, e o protocolo detetará isso e resolverá a chamada com algum tipo de função de computação estendida muito geral. Da perspetiva da máquina virtual, a chamada entra em algum subsistema separado e retorna magicamente a resposta correta depois de um tempo.
Exploramos essa linha de pensamento brevemente, mas rapidamente desistimos porque estávamos muito focados em verificar se qualquer tipo de escalonamento de blockchain é possível. Embora vejamos mais tarde, a combinação de amostragem de disponibilidade de dados e ZK-EVM significa que um possível futuro para o escalonamento Ethereum realmente parece muito próximo dessa visão! Por outro lado, para a abstração de contas, sabíamos desde o início que algum tipo de implementação era possível, então a pesquisa imediatamente começou a tentar trazer algo o mais próximo possível do ponto de partida puro de "negociar é apenas uma chamada" para a realidade.
Entre processar a transação e fazer a chamada EVM subjacente real do endereço do remetente, há muito código clichê e mais código clichê depois disso. Como podemos reduzir este 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 a transação tem o nonce e a assinatura corretos. Desde o início, o objetivo prático da abstração de conta era permitir que os usuários substituíssem a verificação básica não incremental e ECDSA por sua própria lógica de verificação, para que os usuários pudessem usar mais facilmente recursos como recuperação social e carteiras multiassinatura. Assim, encontrar uma maneira de rearquitetar a aplicação_transaction como uma simples chamada EVM não é apenas uma tarefa de "código limpo para tornar o código limpo"; Em vez disso, trata-se de mover a lógica para o código de conta do usuário, dando ao usuário a flexibilidade de que precisa.
No entanto, insistir que aplicar_transaction conter o mínimo possível de lógica fixa acaba criando muitos desafios. Podemos dar uma olhada em uma das primeiras propostas de abstração de contas, EIP-86 .
Se o EIP-86 for incluído como está, reduzirá a complexidade do EVM ao custo de aumentar maciçamente a complexidade de outras partes da pilha Ethereum, exigindo que um código essencialmente idêntico seja escrito em outro lugar, exceto para introduzir categorias estranhas inteiramente novas, como a mesma transação com o mesmo número de hash pode aparecer várias vezes na cadeia, sem mencionar o problema de invalidação múltipla.
Múltiplos problemas de invalidação na abstração da conta. Uma transação incluída on-chain pode invalidar milhares de outras transações no mempool, tornando o mempool fácil de inundar de forma barata.
Desde então, a abstração de contas evoluiu em etapas. O EIP-86 mais tarde tornou-se EIP-208 e, eventualmente, o EIP-2938 prático.
No entanto, o EIP-2938 é tudo menos minimalista. O seu conteúdo inclui:
· Novos tipos de transação
· Variáveis globais para três novos escopos de negociação
· Dois novos opcodes, incluindo o muito desajeitado opcode PAYgas para lidar com verificações de preço e limite de gás, realizar pontos de interrupção como EVM e armazenar temporariamente ETH por uma taxa única
· 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
A fim de implementar a abstração de conta sem envolver os desenvolvedores principais do Ethereum (que se concentram na otimização dos clientes Ethereum e na implementação da fusão), o EIP-2938 acabou sendo rearquitetado para o ERC-4337 totalmente fora do protocolo.
Por se tratar de um ERC, ele não requer um hard fork e tecnicamente existe "fora do protocolo Ethereum". Então...... O problema está resolvido? Acontece que não é esse o caso. O atual roteiro de médio prazo do ERC-4337 envolve, na verdade, eventualmente transformar grande parte do ERC-4337 em um conjunto de recursos de protocolo, o que é um exemplo orientador útil de por que esse caminho deve ser considerado.
Pacote ERC-4337
Existem várias razões principais discutidas para eventualmente trazer o ERC-4337 de volta ao protocolo:
Eficiência de gás: Qualquer operação feita dentro do EVM resulta 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.000 gás, ou mais. Colocar esses componentes em um protocolo é a maneira mais fácil de eliminar esses problemas.
Risco de bug de código: Se o "contrato de ponto de entrada" do ERC-4337 tiver um bug assustador o suficiente, todas as carteiras compatíveis com o ERC-4337 podem ver todos os seus fundos secarem. A substituição de contratos por funcionalidade no protocolo cria uma obrigação implícita de corrigir erros de código através de hard forks, eliminando assim o risco de os fundos dos utilizadores secarem.
Suporte para opcodes EVM, como txt.origin. O próprio ERC-4337 faz com que txt.origin retorne o endereço de um "bundler" que empacota um conjunto de ações do usuário em uma transação. A abstração de conta nativa resolve esse problema fazendo com que txt.origin aponte para a conta real que envia a transação, fazendo com que ela funcione da mesma forma que o EOA.
Resistente à censura: Um dos desafios da separação proponente/construtor é que se torna mais fácil rever transações individuais. Este problema pode ser muito aliviado em um mundo onde o protocolo Ethereum pode reconhecer uma única transação, permitindo que o proponente especifique 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 "apropriado" resolverá esse problema.
Vale a pena mencionar que, em sua forma atual, o ERC-4337 é muito mais caro do que uma transação Ethereum "básica": o custo de transação é de 21.000 gás, enquanto o ERC-4337 custa cerca de 42.000 gás.
Teoricamente, deveria ser possível ajustar o sistema de custos de gás EVM até que o custo no acordo e o custo do acesso fora do protocolo ao armazenamento coincidissem; Quando outros tipos de operações de edição de armazenamento são mais baratos, não há razão para transferir ETH a 9000 gás. Na verdade, dois EIPs relacionados à próxima conversão da árvore Verkle realmente tentam fazer exatamente isso. Mas mesmo que o façamos, há uma razão óbvia pela qual a funcionalidade de protocolo encapsulado será inevitavelmente muito mais barata do que o código EVM, não importa quão eficiente o EVM se torne: o código encapsulado não precisa pagar gás para pré-carregamento.
A carteira ERC-4337 totalmente funcional é grande, e a implementação que a compila e coloca on-chain ocupa 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 você ainda precisa acessar o código em cada bloco que o usa. Sob o EIP de custo de gás da árvore Verkle, 12.800 bytes constituiriam 413 blocos, e acessar esses pedaços exigiria pagar 2x o ramo testemunha_cost (3.800 gás total) e 413x o pedaço testemunha_cost (82.600 gás total). E isso nem está começando a mencionar o ponto de entrada ERC-4337 em si, que na versão 0.6.0 tem 23.689 bytes na cadeia (cerca de 158.700 gás para carregar de acordo com as regras EIP da árvore Verkle).
Isso leva ao problema: o custo do gás de realmente acessar esses códigos deve de alguma forma ser amortizado em toda a transação. A abordagem atual usada pelo ERC-4337 não é muito boa: a primeira transação no pacote consome um custo único de armazenamento/leitura de código, tornando-a muito mais cara do que outras transações. O encapsulamento no protocolo permitirá que essas bibliotecas públicas compartilhadas façam parte do protocolo e sejam livremente acessíveis a todos.
O que podemos aprender com este exemplo e quando as embalagens serão mais comuns? **
Neste exemplo, vemos algumas lógicas diferentes para encapsular o aspeto de abstração de conta no protocolo.
As abordagens baseadas no mercado que "empurram a complexidade para o 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 que cada bloco tem muitos custos fixos. 244, 100 gás para carregar códigos de carteira padronizados é uma coisa; Mas a agregação pode adicionar centenas de milhares de gás à validação ZK-SNARK, bem como o custo on-chain da validação de prova de cadeia. Não há como cobrar dos usuários por esses custos sem introduzir muitas ineficiências de mercado, e traduzir alguns desses recursos em recursos de protocolo que todos podem acessar gratuitamente resolve bem esse problema.
Respostas de toda a comunidade a bugs de código. Se alguns trechos de código são usados por todos os usuários ou uma gama muito ampla de usuários, geralmente faz mais sentido para a comunidade blockchain assumir a responsabilidade por um hard fork para corrigir quaisquer bugs que surjam. O ERC-4337 introduz uma grande quantidade de código globalmente compartilhado, e corrigir bugs no código através de um hard fork é, sem dúvida, mais razoável a longo prazo do que fazer com que os usuários percam muito ETH.
Às vezes, uma forma mais forte pode ser alcançada alavancando diretamente a funcionalidade do protocolo. O principal exemplo aqui é o recurso anticensura no protocolo, como a lista de inclusão: a lista de inclusão dentro do protocolo pode garantir resistência à censura melhor do que o método fora do protocolo, e para que as operações no nível do usuário realmente se beneficiem da lista de inclusão dentro do protocolo, uma única operação no nível do usuário precisa ser "legível" para o protocolo. Outro exemplo menos conhecido é o design de prova de participação Ethereum da era de 2017 que abstraiu a conta de chave de participação, que foi abandonada em favor do encapsulamento do BLS, já que o BLS suporta um mecanismo de "agregação" que deve ser implementado no nível de protocolo e rede, o que pode tornar o tratamento de um grande número de assinaturas mais eficiente.
Mas é importante lembrar que mesmo encapsular a abstração de conta no protocolo ainda é um enorme "desencapsulamento" em comparação com a situação atual. Hoje, as transações Ethereum de nível superior só podem ser iniciadas a partir de contas de propriedade externa (EOAs) que são verificadas com uma única assinatura de curva elíptica secp 256k1. A abstração de conta elimina isso e deixa os critérios de validação para o usuário definir. Assim, nesta história sobre abstração de contas, também vemos o maior argumento contra o encapsulamento: flexibilidade para atender às necessidades de diferentes usuários.
Vamos aprofundar ainda mais esta história olhando para vários outros exemplos de recursos que foram recentemente considerados encapsulados. Prestaremos especial atenção a: ZK-EVM, separação proponente-construtor, mempools privados, staking de liquidez e nova pré-compilação.
Pacote ZK-EVM
Vamos voltar nossa atenção para outro alvo potencial de encapsulamento do protocolo Ethereum: ZK-EVM. Atualmente, temos um grande número de rollups ZK, todos os quais têm que escrever código bastante semelhante para verificar a execução de blocos Ethereum semelhantes no ZK-SNARK. 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 espaço EVM ZK-rollup tem a ver com como lidar com possíveis bugs no código ZK. Atualmente, todos esses sistemas em execução têm algum tipo de mecanismo do "Conselho de Segurança" que controla o sistema de atestado em caso de bugs. No ano passado, tentei criar uma estrutura padronizada para incentivar projetos a esclarecer seu nível de confiança no sistema de certificação, bem como no Conselho de Segurança, e reduzir gradualmente sua autoridade sobre a organização ao longo do tempo.
A médio prazo, os rollups podem contar com vários sistemas de atestado, e o Conselho de Segurança só terá o poder em casos extremos em que dois sistemas de certificação diferentes divergem.
No entanto, há um sentimento de que parte do trabalho parece redundante. Já temos a camada base Ethereum, tem um EVM, e já temos um mecanismo de trabalho para lidar com bugs na implementação: se houver um bug, o cliente atualizará para corrigi-lo, e então a cadeia continuará a funcionar. Do ponto de vista do cliente buggy, parece que os blocos que foram finalizados não serão mais confirmados, mas pelo menos não veremos os usuários perderem dinheiro. Da mesma forma, se os rollups querem apenas manter seu papel equivalente ao EVM, então eles precisam implementar sua própria governança para mudar constantemente suas regras internas ZK-EVM para corresponder às atualizações para a camada base do Ethereum, o que parece errado porque, em última análise, eles são construídos em cima da própria camada base do Ethereum, que sabe quando atualizar e de acordo com quais novas regras.
Uma vez que esses L2 ZK-EVMs usam basicamente exatamente os mesmos EVMs do Ethereum, podemos de alguma forma incorporar "verificar a execução do EVM no ZK" na função de protocolo e lidar com exceções, como bugs e atualizações, aplicando o consenso social do Ethereum, como já fazemos com a própria implementaçã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 é o statefulness. Se os ZK-EVMs não precisassem carregar dados "testemunhas", sua eficiência de dados seria muito maior. Ou seja, se um determinado dado já foi lido ou escrito em algum bloco anterior, podemos simplesmente supor 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 a compactação stateful pode salvar até 3x dados em comparação com a compactação stateless se um rollup compactar os dados corretamente.
Isso significa que, para a pré-compilação ZK-EVM, temos duas opções:
A pré-compilação requer que todos os dados estejam disponíveis no mesmo bloco. Isso significa que o provador pode ser sem monitoração de estado, mas também significa que usar esse pacote cumulativo de ZK pré-compilado é muito mais caro do que usar o pacote cumulativo com código personalizado.
A pré-compilação permite que o ponteiro aponte para dados previamente executados, usados ou gerados. Isso torna o ZK-rollup quase 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 de alguma forma a verificação ZK-EVM: o rollup já está construindo sua própria versão personalizada, e o Ethereum está disposto a pesar suas múltiplas implementações e consenso social off-chain em L1 para executar EVM, o que parece errado, mas L2 fazendo exatamente o mesmo trabalho deve implementar gadgets complexos envolvendo o Conselho de Segurança. Mas, por outro lado, há um grande problema nos detalhes: existem diferentes versões do ZK-EVM, que diferem em custo e benefício. A distinção entre stateful e stateless apenas arranha a superfície; Tentar suportar "quase-EVM", códigos personalizados que foram comprovados por outros sistemas, pode expor mais espaço de design. Encapsular o ZK-EVM, portanto, apresenta promessas e desafios.
Separação entre invólucros e construtores (ePBS)
A ascensão do MEV tornou a produção de blocos uma atividade econômica em grande escala, com participantes complexos capazes de produzir blocos que geram mais receita do que o algoritmo padrão, que simplesmente observa o mempool de transações e as contém. Até agora, a comunidade Ethereum tentou resolver esse problema usando um esquema de separação entre proponente e construtor 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 chamada revezamentos. Nos últimos dois anos, houve muitas propostas para criar "PBS encapsulado". Quais são os benefícios disso? Neste caso, a resposta é simples: o PBS construído diretamente com recursos de protocolo é mais poderoso (no sentido de ter pressupostos de confiança mais fracos) do que o PBS construído sem eles. Isso é semelhante ao caso dos oráculos de preço dentro do protocolo de encapsulamento – embora, neste caso, também haja forte oposição.
Encapsulando pool de memória privada
Quando um usuário envia uma transação, ela é 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 transações preventivas.
Recentemente, houve uma série de projetos dedicados à criação de "mempools privados" (ou "mempools criptografados") que criptografam as transações dos usuários até que elas sejam irreversivelmente aceitas em um bloco.
O problema, no entanto, é que tais esquemas exigem um tipo especial de criptografia: para evitar que os usuários inundem o sistema e o descriptografem primeiro, a criptografia deve ser automaticamente descriptografada depois que a transação tiver sido de fato irreversivelmente aceita.
Para conseguir esta forma de encriptação, existem várias técnicas de compensação. Jon Charbonneau disse uma vez bem:
Criptografe operadores centralizados, como o Flashbots Protect.
criptografia timelock, que pode ser descriptografada por qualquer pessoa após uma determinada etapa de cálculo sequencial e não pode ser paralelizada;
Criptografia de limite, confiando em um comitê de maioria honesta para descriptografar os dados. Para obter recomendações específicas, consulte Conceito de cadeia de beacon fechada.
Hardware confiável, como SGX.
Infelizmente, cada encriptação tem pontos fracos diferentes. Embora para cada solução, haja um subconjunto de usuários dispostos a confiar nela, nenhuma das soluções é confiável o suficiente para que ela seja realmente aceita pela Camada 1. Assim, pelo menos até que a criptografia de latência seja aperfeiçoada ou algum outro avanço tecnológico, encapsular a funcionalidade de negociação anti-avançada na Camada 1 parece uma proposta difícil, mesmo que seja um recurso valioso o suficiente para que muitas soluções de aplicativos tenham surgido.
Estabilização de liquidez encapsulada
Uma necessidade comum para os usuários do Ethereum DeFi é a capacidade de usar seu ETH simultaneamente para staking e como garantia em outros aplicativos. Outra necessidade comum é simplesmente por conveniência: os usuários querem ser capazes de apostar (e proteger chaves de staking online) sem a complexidade de executar um nó e mantê-lo sempre online.
Até agora, a "interface" de staking mais simples que satisfaz ambas as necessidades é apenas um token ERC 20: converta seu ETH em "stake ETH", segure-o e converta-o de volta. Na verdade, provedores de staking de liquidez como Lido e Rocket Pool já começaram a fazê-lo. No entanto, o staking de liquidez tem alguns mecanismos naturais de centralização em ação: as pessoas naturalmente entram na versão maior do staking ETH porque é o mais familiar e líquido.
Cada versão do ETH de staking requer algum mecanismo para determinar quem pode ser o operador do nó subjacente. Não pode ser ilimitado, pois então os atacantes se juntarão e amplificarão o ataque com os fundos do usuário. Atualmente, os dois primeiros são o Lido, que tem um operador de nó de lista branca DAO, e o Rocket Pool, que permite que qualquer pessoa execute um nó com 8 ETH depositados. Os dois métodos têm riscos diferentes: a abordagem Rocket Pool permite que os atacantes realizem ataques de 51% na rede e força os usuários a pagar a maior parte do custo; Quanto à abordagem DAO, se um determinado token de staking dominar, isso resulta em um único gadget de governança potencialmente atacado controlando uma parte significativa de todos os validadores Ethereum. É certo que protocolos como o Lido já têm precauções em vigor, mas uma camada de defesa pode não ser suficiente.
A curto prazo, uma opção consiste em incentivar os participantes no ecossistema a utilizarem uma gama diversificada de fornecedores de liquidez para reduzir a probabilidade de risco sistémico de uma única empresa. A longo prazo, porém, trata-se de um equilíbrio precário e é perigoso confiar demasiado na pressão moral para resolver os problemas. Uma pergunta natural surge: faz sentido encapsular algum tipo de funcionalidade no protocolo para tornar o staking de liquidez menos centralizado?
A questão-chave aqui é: que tipo de funcionalidade no protocolo? O problema com a simples criação de um token fungível "staking ETH" no protocolo é que ele tem que ter uma governança encapsulada em todo o Ethereum para escolher quem executa os nós, ou é aberto, mas isso o transforma em uma ferramenta para invasores.
Uma ideia interessante é o artigo de Dankrad Feist sobre a maximização da staking de liquidez. Primeiro, vamos morder a bala e se o Ethereum for atacado por 51%, apenas 5% do ataque ETH pode ser confiscado. Trata-se de um compromisso razoável; Com mais de 26 milhões de ETH atualmente sendo apostados, um terço disso (cerca de 8 milhões de ETH) do custo do ataque é excessivo, especialmente considerando quantos ataques "fora do modelo" podem ser feitos a um custo menor. De facto, foram exploradas soluções de compromisso semelhantes na proposta da Super Comissão de implementar a finalidade da faixa horária única.
Se aceitarmos que apenas 5% do ETH de ataque é confiscado, então mais de 90% do ETH apostado não será afetado pelo confisco, então eles podem ser usados como tokens de staking de liquidez fungível dentro do protocolo e, em seguida, usados por outros aplicativos.
O caminho é interessante. Mas ainda deixa a pergunta: o que exatamente é encapsulado? O 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 a 2 ETH e o rETH existente do Rocket Pool se tornará livre de riscos.
Com ajustes de protocolo simples, também podemos fazer outras coisas inteligentes. Por exemplo, digamos que queremos um sistema com duas "camadas" de staking: operadores de nó (altos requisitos de garantia) e depositantes (sem requisitos mínimos de garantia e podem entrar e sair a qualquer momento), mas ainda queremos impedir a centralização dos operadores de nó capacitando um comitê de depositantes amostrado aleatoriamente, como sugerir uma lista de transações que devem ser incluídas (por razões resistentes à censura), controlar a seleção de forks durante vazamentos inativos ou exigir assinatura de bloco. Isso pode ser conseguido de uma forma que essencialmente se desvincula 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 em cada slot para gerar uma chave de staking secundária. O protocolo dará poder a ambas as chaves, mas o mecanismo para escolher a segunda chave em cada slot pode ser deixado para o protocolo do pool de apostas. Ainda pode ser melhor encapsular alguns recursos diretamente, mas vale a pena notar que isso "incluir algumas coisas e deixar tudo o resto para o usuário" espaço de design existe.
Encapsular mais pré-compilações
Pré-compilados (ou "contratos pré-compilados") são contratos Ethereum que implementam operações criptográficas complexas, cuja 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 de uma máquina virtual era muito grande para algum código muito complexo e altamente especializado, poderíamos implementar algumas operações-chave em código local que eram valiosas para aplicações importantes para torná-lo mais rápido. Hoje, isso basicamente inclui algumas funções de hash específicas e operações de curva elíptica.
Atualmente, há um esforço para adicionar pré-compilação para secp 256 R1, uma curva elíptica ligeiramente diferente da secp 256 K1 para contas Ethereum básicas, pois é bem suportado por módulos de hardware confiáveis, então o uso generalizado dele pode melhorar a segurança da carteira. Nos últimos anos, a comunidade também pressionou pela adição de pré-compilações para BLS-12-377, BW 6-761, emparelhamento generalizado e outros recursos.
O contra-argumento para esses pedidos de mais arquivos pré-compilados é que muitas das pré-compilações adicionadas anteriormente (por exemplo, RIPEMD e BLAKE) acabam usando muito menos do que o esperado, e devemos aprender com eles. 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 propostas SIMD adormecidas, mas sempre recuperáveis, que permitirão que as implementações de EVM executem uma ampla gama de classes de código a um custo mais baixo. Talvez até mesmo a pré-compilação existente raramente usada pudesse ser removida e substituída por uma implementação (inevitavelmente menos eficiente) do código EVM da mesma função. Dito isso, ainda é possível que existam operações criptográficas específicas que sejam valiosas o suficiente para acelerar, então faz sentido adicioná-las como pré-compiladas.
O que aprendemos com tudo isto?
O desejo de encapsular o mínimo possível é compreensível e bom; Deriva da tradição filosófica Unix de criar software minimalista 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 certas funcionalidades no protocolo.
Em muitos casos, esses outros exemplos são semelhantes ao que vemos na abstração do relato. Mas também aprendemos algumas novas lições:
O encapsulamento pode ajudar a evitar o risco de centralização em outro lugar da pilha:
Muitas vezes, manter o protocolo básico mínimo e simples empurra a complexidade para além de alguns dos protocolos do ecossistema. Do ponto de vista filosófico do Unix, isso é bom. No entanto, às vezes há o risco de que ecossistemas fora do protocolo se centralizem, geralmente (mas não só) por causa dos altos custos fixos. Às vezes, o encapsulamento pode reduzir a centralização de fato.
Encapsular muito conteúdo pode expandir demais a confiança e a carga de governança no protocolo:
Este é o tópico de um artigo anterior sobre "Não sobrecarregue o consenso Ethereum": se encapsular uma função específica enfraquece o modelo de confiança e torna o Ethereum como um todo mais "subjetivo", enfraquece a neutralidade confiável do Ethereum. Nesses casos, é melhor apresentar um recurso específico como um mecanismo em cima do Ethereum do que tentar introduzi-lo ao próprio Ethereum. Aqui, os pools de memória criptografada são o melhor exemplo, e pode ser um pouco difícil de encapsular, pelo menos até que a criptografia de latência melhore.
Encapsular demais pode complicar demais o protocolo:
A complexidade do protocolo é um risco sistêmico que pode ser aumentado pela adição de muitos recursos ao protocolo. A pré-compilação é o melhor exemplo.
A longo prazo, a funcionalidade de encapsulamento pode sair pela culatra porque as necessidades do usuário são imprevisíveis:
Um recurso que muitas pessoas consideram importante e será usado por muitos usuários provavelmente não é usado regularmente na prática.
Além disso, o staking de liquidez, ZK-EVM e casos pré-compilados mostram a possibilidade de um caminho intermediário: a consagração mínima viável. Os protocolos não precisam encapsular toda a função, mas podem conter partes específicas que abordam os principais desafios, tornando a função fácil de implementar sem ser muito paranoica ou muito estreita. Exemplos disso incluem:
Em vez de encapsular um sistema completo de penhor de liquidez, é melhor alterar as regras de penalização de staking para tornar mais viável o penhor de liquidez sem confiança;
Em vez de encapsular mais pré-compiladores, encapsular EVM-MAX e/ou SIMD para facilitar a implementação eficiente para uma ampla gama de categorias operacionais;
A verificação EVM pode simplesmente ser encapsulada em vez de encapsular todo o conceito de rollup.
Podemos expandir o gráfico anterior da seguinte forma:
Às vezes, faz sentido embrulhar algo, e 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 apoiar a retrocompatibilidade para os utilizadores existentes, o mecanismo pode realmente ser surpreendentemente semelhante ao que desencapsula pré-compilados: uma das propostas é o EIP-5003, que permitiria à EOA converter as suas contas em contratos com a mesma (ou melhor) funcionalidade.
Que características devem ser introduzidas no protocolo e quais devem ser deixadas para outras camadas do ecossistema é um compromisso complexo. Espera-se que este compromisso continue a melhorar ao longo do tempo, à medida que a nossa compreensão das necessidades dos utilizadores e das ideias e pacotes tecnológicos disponíveis continue a melhorar.