Agradecimentos especiais a Dan Finlay, Karl Floersch, David Hoffman e às equipas Scroll e SoulWallet pelo feedback, revisão e sugestões.

À medida que o Ethereum passa de uma jovem tecnologia experimental para uma pilha tecnológica madura, capaz de proporcionar uma experiência aberta, global e sem permissões aos utilizadores comuns, há três grandes transições técnicas que a pilha tem de sofrer, aproximadamente em simultâneo:

• A transição para oescalonamento L2 - todos a mudar para rollups
• A transição da segurança das carteiras - todos estão a mudar para carteiras com contratos inteligentes
• A transição da privacidade - garantir que as transferências de fundos que preservam a privacidade estão disponíveis e que todos os outros dispositivos que estão a ser desenvolvidos (recuperação social, identidade, reputação) preservam a privacidade

O triângulo de transição do ecossistema. Só pode escolher 3 de 3.

Sem o primeiro, o Ethereum falha porque cada transação custa 3,75 dólares (82,48 dólares se tivermos outra corrida de touros), e todos os produtos que visam o mercado de massas esquecem inevitavelmente a cadeia e adoptam soluções alternativas centralizadas para tudo.

Sem o segundo, o Ethereum falha porque os utilizadores não se sentem à vontade para armazenar os seus fundos (e activos não financeiros), e todos se deslocam para trocas centralizadas.

Sem o terceiro, o Ethereum falha porque ter todas as transacções (e POAPs, etc.) disponíveis publicamente para literalmente qualquer pessoa ver é um sacrifício de privacidade demasiado elevado para muitos utilizadores, e toda a gente passa para soluções centralizadas que, pelo menos, escondem um pouco os seus dados.

Estas três transições são cruciais pelas razões acima referidas. Mas são também um desafio devido à intensa coordenação necessária para os resolver corretamente. Não são apenas as características do protocolo que precisam de ser melhoradas; em alguns casos, a forma como interagimos com o Ethereum precisa de mudar fundamentalmente, exigindo mudanças profundas nas aplicações e nas carteiras.

As três transições irão remodelar radicalmente a relação entre os utilizadores e os endereços

Num mundo de escalonamento L2, os utilizadores vão existir em muitos L2s. É membro da ExampleDAO, que vive do otimismo? Então tem uma conta no Otimismo! Está a manter um CDP num sistema de stablecoin no ZkSync? Então já tem uma conta no ZkSync! Uma vez foi experimentar uma aplicação que por acaso vivia em Kakarot? Então já tem uma conta no Kakarot! Os dias em que um utilizador tinha apenas um endereço desapareceram.

Tenho ETH em quatro sítios, de acordo com a minha vista da Brave Wallet. E sim, Arbitrum e Arbitrum Nova são diferentes. Não se preocupe, com o passar do tempo vai ficar mais confuso!

As carteiras de contratos inteligentes adicionam mais complexidade, tornando muito mais difícil ter o mesmo endereço em L1 e nos vários L2s. Atualmente, a maioria dos utilizadores utiliza contas externas, cujo endereço é literalmente um hash da chave pública utilizada para verificar as assinaturas, pelo que nada muda entre L1 e L2. No entanto, com as carteiras de contratos inteligentes, manter um endereço torna-se mais difícil. Embora tenha sido feito muito trabalho para tentar fazer com que os endereços sejam hashes de código que possam ser equivalentes em todas as redes, nomeadamente o CREATE2 e a fábrica de singleton ERC-2470, é difícil fazer com que isto funcione na perfeição. Algumas L2 (por exemplo. "type 4 ZK-EVMs") não são exatamente equivalentes a EVM, utilizando frequentemente o Solidity ou um conjunto intermédio, o que impede a equivalência de hash. E mesmo quando pode ter equivalência de hash, a possibilidade de as carteiras mudarem de proprietário através de alterações de chave cria outras consequências pouco intuitivas.

A privacidade exige que cada utilizador tenha ainda mais endereços e pode até alterar os tipos de endereços com que estamos a lidar. Se as propostas de endereços furtivos forem amplamente utilizadas, em vez de cada utilizador ter apenas alguns endereços, ou um endereço por L2, os utilizadores poderão ter um endereço por transação. Outros esquemas de privacidade, mesmo os já existentes, como o Tornado Cash, alteram a forma como os activos são armazenados de uma forma diferente: os fundos de muitos utilizadores são armazenados no mesmo contrato inteligente (e, por conseguinte, no mesmo endereço). Para enviar fundos a um utilizador específico, os utilizadores terão de recorrer ao próprio sistema de endereçamento interno do esquema de privacidade.

Como vimos, cada uma das três transições enfraquece o modelo mental "um utilizador ~= um endereço" de formas diferentes, e alguns destes efeitos reflectem-se na complexidade da execução das transições. Dois pontos específicos de complexidade são:

1. Se quiser pagar a alguém, como é que vai obter a informação sobre como pagar?
2. Se os utilizadores tiverem muitos activos armazenados em diferentes locais e em diferentes cadeias, como é que fazem as alterações principais e a recuperação social?

As três transições e os pagamentos na cadeia (e a identidade)

Tenho moedas no Scroll e quero pagar um café (se o "eu" for literalmente eu, o autor deste artigo, então "café" é, obviamente, uma metonímia para "chá verde"). Está a vender-me o café, mas só está preparado para receber moedas no Taiko. O que é que faz?

Existem basicamente duas soluções:

1. As carteiras receptoras (que podem ser comerciantes, mas também podem ser apenas indivíduos comuns) esforçam-se muito por apoiar todos os L2 e têm algumas funcionalidades automatizadas para consolidar fundos de forma assíncrona.
2. O destinatário fornece o seu L2 juntamente com o seu endereço, e a carteira do remetente encaminha automaticamente os fundos para o L2 de destino através de um sistema de ponte entre L2.

É claro que estas soluções podem ser combinadas: o destinatário fornece a lista de L2s que está disposto a aceitar e a carteira do remetente calcula o pagamento, que pode envolver um envio direto, se tiver sorte, ou um caminho de ligação entre L2s.

Mas este é apenas um exemplo de um desafio fundamental que as três transições introduzem: acções simples como pagar a alguém começam a exigir muito mais informação do que apenas um endereço de 20 bytes.

Felizmente, a transição para carteiras de contratos inteligentes não representa um grande encargo para o sistema de endereçamento, mas ainda há algumas questões técnicas noutras partes da pilha de aplicações que precisam de ser resolvidas. As carteiras terão de ser actualizadas para garantir que não enviam apenas 21000 gás juntamente com uma transação, e será ainda mais importante garantir que o lado de receção de pagamentos de uma carteira rastreia não só as transferências de ETH das EOAs, mas também as ETH enviadas por código de contrato inteligente. As aplicações que se baseiam no pressuposto de que a propriedade do endereço é imutável (por exemplo. As NFTs que proíbem os contratos inteligentes para fazer cumprir os direitos de autor) terão de encontrar outras formas de atingir os seus objectivos. As carteiras de contratos inteligentes também facilitarão algumas coisas - nomeadamente, se alguém receber apenas um token ERC20 que não seja ETH, poderá utilizar os paymasters ERC-4337 para pagar o gás com esse token.

A privacidade, por outro lado, coloca, mais uma vez, grandes desafios que ainda não foram verdadeiramente abordados. O Tornado Cash original não introduziu nenhuma destas questões, porque não suportava transferências internas: os utilizadores só podiam depositar no sistema e levantar do mesmo. No entanto, quando puder efetuar transferências internas, os utilizadores terão de utilizar o esquema de endereçamento interno do sistema de privacidade. Na prática, a "informação de pagamento" de um utilizador teria de conter (i) algum tipo de "chave pública de despesa", um compromisso com um segredo que o destinatário poderia utilizar para gastar, e (ii) alguma forma de o remetente enviar informação cifrada que só o destinatário pode decifrar, para ajudar o destinatário a descobrir o pagamento.

Os protocolos de endereços furtivos baseiam-se num conceito de meta-endereços, que funcionam da seguinte forma: uma parte do meta-endereço é uma versão oculta da chave de despesa do remetente e outra parte é a chave de encriptação do remetente (embora uma implementação mínima possa definir essas duas chaves como sendo as mesmas).

Esquema de um esquema abstrato de endereços furtivos baseado em cifragem e ZK-SNARKs.

Uma lição importante aqui é que, num ecossistema favorável à privacidade, um utilizador terá tanto as chaves de publicação de despesas como as chaves de publicação de encriptação, e a "informação de pagamento" de um utilizador terá de incluir ambas as chaves. Há também boas razões, para além dos pagamentos, para avançar nesta direção. Por exemplo, se quisermos correio eletrónico encriptado com base no Ethereum, os utilizadores terão de fornecer publicamente algum tipo de chave de encriptação. No "mundo EOA", poderíamos reutilizar as chaves de conta para este efeito, mas num mundo seguro de carteiras com contratos inteligentes, deveríamos provavelmente ter uma funcionalidade mais explícita para este efeito. Isso também ajudaria a tornar a identidade baseada no Ethereum mais compatível com ecossistemas de privacidade descentralizados que não sejam do Ethereum, principalmente chaves PGP.

As três transições e a recuperação chave

A forma predefinida de implementar alterações de chave e recuperação social num mundo de muitos endereços por utilizador é simplesmente fazer com que os utilizadores executem o procedimento de recuperação em cada endereço separadamente. Isto pode ser feito com um clique: a carteira pode incluir software para executar o procedimento de recuperação em todos os endereços de um utilizador ao mesmo tempo. No entanto, mesmo com estas simplificações de UX, a recuperação ingénua de vários endereços tem três problemas:

1. Impraticabilidade do custo do gás: esta é auto-explicativa.
2. Endereços contrafactuais: endereços para os quais o contrato inteligente ainda não foi publicado (na prática, isto significa uma conta da qual ainda não enviou fundos). Você, enquanto utilizador, tem um número potencialmente ilimitado de endereços contrafactuais: um ou mais em cada L2, incluindo L2s que ainda não existem, e todo um outro conjunto infinito de endereços contrafactuais resultantes de esquemas de endereços furtivos.
3. Privacidade: se um utilizador tiver intencionalmente muitos endereços para evitar ligá-los uns aos outros, não vai certamente querer ligá-los publicamente recuperando-os ao mesmo tempo!

A resolução destes problemas é difícil. Felizmente, existe uma solução algo elegante que funciona razoavelmente bem: uma arquitetura que separa a lógica de verificação e a posse de activos.

Cada utilizador tem um contrato de armazenamento de chaves, que existe num local (pode ser a rede principal ou um L2 específico). Os utilizadores têm então endereços em diferentes L2s, em que a lógica de verificação de cada um desses endereços é um ponteiro para o contrato do repositório de chaves. A realização de despesas a partir desses endereços exigiria uma prova que entraria no contrato do repositório de chaves, mostrando a chave pública de despesas atual (ou, mais realisticamente, muito recente).

A prova pode ser implementada de várias formas:

• Acesso direto ao L1 só de leitura dentro do L2. É possível modificar os L2s para lhes dar uma forma de ler diretamente o estado do L1. Se o contrato do repositório de chaves estiver em L1, isso significa que os contratos em L2 podem aceder ao repositório de chaves "gratuitamente"
• Ramos de Merkle. Os ramos Merkle podem provar o estado L1 para um L2, ou o estado L2 para um L1, ou pode combinar os dois para provar partes do estado de um L2 para outro L2. O principal ponto fraco das provas de Merkle é o elevado custo do gás devido ao comprimento da prova: potencialmente 5 kB para uma prova, embora este valor seja reduzido para < 1 kB no futuro devido às árvores de Verkle.
• ZK-SNARKs. Pode reduzir os custos de dados utilizando um ZK-SNARK de um Merkle branch em vez do próprio branch. É possível criar técnicas de agregação fora da cadeia (por exemplo, em cima do EIP-4337) para que um único ZK-SNARK verifique todas as provas de estado entre cadeias num bloco.
• Compromissos KZG. Os L2, ou os esquemas construídos sobre eles, poderiam introduzir um sistema de endereçamento sequencial, permitindo que as provas de estado dentro deste sistema tivessem apenas 48 bytes. Tal como acontece com as ZK-SNARKs, um esquema multi-prova poderia fundir todas estas provas numa única prova por bloco.

Se quisermos evitar fazer uma prova por transação, podemos implementar um esquema mais leve que apenas requer uma prova cross-L2 para recuperação. Os gastos a partir de uma conta dependem de uma chave de gastos cuja chave pública correspondente é armazenada nessa conta, mas a recuperação requer uma transação que copia a chave pública de gastos atual no repositório de chaves. Os fundos em endereços contrafactuais estão seguros mesmo que as suas chaves antigas não estejam: "ativar" um endereço contrafactual para o transformar num contrato de trabalho exigiria fazer uma prova cross-L2 para copiar a spending_pubkey atual. Este tópico nos fóruns Safe descreve como pode funcionar uma arquitetura semelhante.

Para adicionar privacidade a esse esquema, basta encriptar o ponteiro e fazer todas as nossas provas dentro de ZK-SNARKs:

Com mais trabalho (por exemplo. utilizando <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof"> this como ponto de partida), poderíamos também eliminar a maior parte da complexidade dos ZK-SNARKs e criar um esquema mais simples baseado em KZG.

Estes regimes podem tornar-se complexos. O lado positivo é que existem muitas sinergias potenciais entre eles. Por exemplo, o conceito de "contratos de repositório de chaves" também pode ser uma solução para o desafio dos "endereços" mencionado na secção anterior: se quisermos que os utilizadores tenham endereços persistentes, que não mudem sempre que o utilizador actualiza uma chave, podemos colocar meta-endereços furtivos, chaves de encriptação e outras informações no contrato de repositório de chaves e utilizar o endereço do contrato de repositório de chaves como "endereço" do utilizador.

Muitas infra-estruturas secundárias precisam de ser actualizadas

A utilização da ENS é dispendiosa. Hoje, em junho de 2023, a situação não é muito má: a taxa de transação é significativa, mas ainda é comparável à taxa do domínio ENS. O registo de zuzalu.eth custou-me cerca de 27 dólares, dos quais 11 dólares corresponderam a taxas de transação. Mas se tivermos outro mercado em alta, as comissões vão disparar. Mesmo sem o aumento do preço do ETH, o regresso das taxas de gás a 200 gwei aumentaria a taxa de câmbio de um registo de domínio para 104 dólares. Por isso, se quisermos que as pessoas utilizem realmente a ENS, especialmente em casos de utilização como as redes sociais descentralizadas, em que os utilizadores exigem um registo quase gratuito (e a taxa de domínio da ENS não é um problema porque estas plataformas oferecem subdomínios aos seus utilizadores), precisamos que a ENS trabalhe no L2.

Felizmente, a equipa ENS deu um passo em frente e o ENS on L2 está mesmo a acontecer! O ERC-3668 (também conhecido como "norma CCIP"), juntamente com o ENSIP-10, permite que os subdomínios ENS em qualquer L2 sejam automaticamente verificáveis. A norma CCIP exige a criação de um contrato inteligente que descreva um método para verificar provas de dados em L2 e um domínio (por exemplo, o domínio de um computador). Optinames utiliza ecc.eth) pode ser colocado sob o controlo de um contrato deste tipo. Uma vez que o contrato CCIP controla ecc.eth em L1, o acesso a algum subdomínio.ecc.eth envolverá automaticamente a procura e verificação de uma prova (por exemplo. Merkle branch) do estado em L2 que armazena efetivamente esse subdomínio específico.

Na verdade, ir buscar as provas envolve ir a uma lista de URLs armazenados no contrato, o que parece uma centralização, embora eu argumente que não é: é um modelo de confiança 1-de-N (as provas inválidas são apanhadas pela lógica de verificação na função de retorno de chamada do contrato CCIP e, desde que um dos URLs devolva uma prova válida, está tudo bem). A lista de URLs pode conter dezenas deles.

O esforço do ENS CCIP é uma história de sucesso e deve ser visto como um sinal de que são efetivamente possíveis reformas radicais do tipo das que necessitamos. Mas há muito mais reformas na camada de aplicação que precisam de ser feitas. Alguns exemplos:

• Muitos dapps dependem de utilizadores que fornecem assinaturas fora da cadeia. Com as contas de titularidade externa (EOAs), isto é fácil. O ERC-1271 fornece uma maneira padronizada de fazer isso para carteiras de contratos inteligentes. No entanto, muitos dapps ainda não suportam o ERC-1271; terão de o fazer.
• As Dapps que utilizam a pergunta "isto é um EOA?" para discriminar entre utilizadores e contratos (por exemplo, para impedir a transferência ou aplicar royalties) vão quebrar. Em geral, desaconselho a tentativa de encontrar uma solução puramente técnica neste caso; descobrir se uma determinada transferência de controlo criptográfico é ou não uma transferência de propriedade efectiva é um problema difícil e provavelmente não pode ser resolvido sem recorrer a alguns mecanismos fora da cadeia, conduzidos pela comunidade. Muito provavelmente, as aplicações terão de recorrer menos à prevenção de transferências e mais a técnicas como os impostos Harberger.
• A forma como as carteiras interagem com as despesas e as chaves de encriptação terá de ser melhorada. Atualmente, as carteiras utilizam frequentemente assinaturas determinísticas para gerar chaves específicas da aplicação: assinar um nonce padrão (por exemplo, o hash do nome da aplicação) com a chave privada de uma EOA gera um valor determinístico que não pode ser gerado sem a chave privada, pelo que é seguro num sentido puramente técnico. No entanto, estas técnicas são "opacas" para a carteira, impedindo-a de implementar verificações de segurança ao nível da interface do utilizador. Num ecossistema mais maduro, a assinatura, a encriptação e as funcionalidades relacionadas terão de ser tratadas pelas carteiras de forma mais explícita.
• Clientes ligeiros (por exemplo. Helios) terá de verificar os L2 e não apenas o L1. Atualmente, os clientes ligeiros centram-se na verificação da validade dos cabeçalhos L1 (utilizando o protocolo de sincronização de clientes ligeiros) e na verificação dos ramos Merkle do estado L1 e das transacções com raiz no cabeçalho L1. Amanhã, terá também de verificar uma prova do estado de L2 com raiz na raiz do estado armazenado em L1 (uma versão mais avançada deste processo analisaria efetivamente as pré-confirmações de L2).

As carteiras terão de proteger tanto os activos como os dados

Hoje em dia, as carteiras têm por objetivo proteger os bens. Tudo vive na cadeia, e a única coisa que a carteira precisa de proteger é a chave privada que está atualmente a guardar esses activos. Se alterar a chave, pode publicar com segurança a sua chave privada anterior na Internet no dia seguinte. No entanto, num mundo ZK, isto já não é verdade: a carteira não está apenas a proteger as credenciais de autenticação, está também a guardar os seus dados.

Vimos os primeiros sinais de um mundo assim com o Zupass, o sistema de identidade baseado no ZK-SNARK que foi utilizado no Zuzalu. Os utilizadores tinham uma chave privada que utilizavam para se autenticarem no sistema, que podia ser utilizada para fazer provas básicas como "provar que sou um residente de Zuzalu, sem revelar qual". Mas o sistema Zupass também começou a ter outras aplicações incorporadas, nomeadamente selos (a versão Zupass dos POAPs).

Um dos meus muitos carimbos Zupass, confirmando que sou um orgulhoso membro da Equipa Cat.

A principal caraterística que os selos oferecem em relação aos POAPs é o facto de os selos serem privados: os dados são guardados localmente e só pode provar um selo (ou um cálculo sobre os selos) a alguém se quiser que essa pessoa tenha essa informação sobre si. Mas isto cria um risco acrescido: se perder essa informação, perde os seus selos.

É claro que o problema da posse de dados pode ser reduzido ao problema da posse de uma única chave de encriptação: um terceiro (ou mesmo a cadeia) pode ter uma cópia encriptada dos dados. Isto tem a vantagem conveniente de que as acções que realiza não alteram a chave de encriptação e, por isso, não requerem quaisquer interacções com o sistema que mantém a sua chave de encriptação segura. Mas, mesmo assim, se perder a sua chave de encriptação, perde tudo. E, por outro lado, se alguém vir a sua chave de encriptação, vê tudo o que foi encriptado com essa chave.

A solução de facto da Zupass consistia em incentivar as pessoas a armazenar a sua chave em vários dispositivos (por exemplo. portátil e telemóvel), uma vez que a probabilidade de perder o acesso a todos os dispositivos ao mesmo tempo é mínima. Poderíamos ir mais longe e utilizar a partilha de segredos para armazenar a chave, dividida entre vários guardiões.

Este tipo de recuperação social via MPC não é uma solução suficiente para as carteiras, porque significa que não só os actuais guardiões, mas também os anteriores, podem conspirar para roubar os seus bens, o que é um risco inaceitavelmente elevado. Mas as fugas de privacidade são geralmente um risco menor do que a perda total de activos, e alguém com um caso de utilização muito exigente em termos de privacidade pode sempre aceitar um risco maior de perda se não fizer o backup da chave associada a essas acções exigentes em termos de privacidade.

Para evitar sobrecarregar o utilizador com um sistema bizantino de múltiplos caminhos de recuperação, as carteiras que suportam a recuperação social terão provavelmente de gerir tanto a recuperação de bens como a recuperação de chaves de encriptação.

Voltar à identidade

Uma das linhas comuns destas alterações é o facto de o conceito de "endereço", um identificador criptográfico que utiliza para representar "você" na cadeia, ter de mudar radicalmente. As "instruções sobre como interagir comigo" já não seriam apenas um endereço ETH; teriam de ser, de alguma forma, uma combinação de múltiplos endereços em múltiplos L2s, meta-endereços furtivos, chaves de encriptação e outros dados.

Uma forma de o fazer é fazer do ENS a sua identidade: o seu registo ENS pode conter todas estas informações e, se enviar a alguém bob.eth (ou bob.ecc.eth, ou...), podem consultar e ver tudo sobre como pagar e interagir consigo, incluindo as formas mais complicadas de preservação da privacidade entre domínios.

Mas esta abordagem centrada no ENS tem dois pontos fracos:

• Associa demasiadas coisas ao seu nome. O seu nome não é você, o seu nome é um dos muitos atributos de si. Deveria ser possível alterar o seu nome sem ter de mudar todo o seu perfil de identidade e atualizar uma série de registos em muitas aplicações.
• Não pode ter nomes contrafactuais sem confiança. Uma das principais características de UX de qualquer cadeia de blocos é a capacidade de enviar moedas a pessoas que ainda não interagiram com a cadeia. Sem essa funcionalidade, existe um "catch-22": interagir com a cadeia requer o pagamento de taxas de transação, o que requer... já ter moedas. Os endereços ETH, incluindo os endereços de contratos inteligentes com CREATE2, têm esta caraterística. Os nomes ENS não o fazem, porque se dois Bobs decidirem, fora da cadeia, que são bob.ecc.eth, não há forma de escolher qual deles fica com o nome.

Uma solução possível é colocar mais coisas no contrato do repositório de chaves mencionado na arquitetura anteriormente neste post. O contrato do repositório de chaves pode conter todas as informações sobre si e a forma de interagir consigo (e, com o CCIP, algumas dessas informações podem estar fora da cadeia), e os utilizadores utilizariam o seu contrato de repositório de chaves como identificador principal. Mas os activos reais que recebem seriam armazenados em todo o tipo de locais diferentes. Os contratos de repositório de chaves não estão ligados a um nome e são contrafactuais: pode gerar um endereço que, comprovadamente, só pode ser inicializado por um contrato de repositório de chaves que tenha determinados parâmetros iniciais fixos.

Uma outra categoria de soluções tem a ver com o abandono total do conceito de endereços para o utilizador, num espírito semelhante ao do protocolo de pagamento Bitcoin. Uma ideia é basear-se mais nos canais de comunicação direta entre o remetente e o destinatário; por exemplo, o remetente poderia enviar uma ligação para o pedido (quer como URL explícito quer como código QR) que o destinatário poderia utilizar para aceitar o pagamento como quisesse.

Independentemente de ser o remetente ou o destinatário a agir primeiro, uma maior confiança nas carteiras que geram diretamente informações de pagamento actualizadas em tempo real poderá reduzir o atrito. Dito isto, os identificadores persistentes são convenientes (especialmente com a ENS), e o pressuposto da comunicação direta entre o remetente e o destinatário é realmente complicado na prática, pelo que podemos acabar por assistir a uma combinação de diferentes técnicas.

Em todas estas concepções, é fundamental manter as coisas descentralizadas e compreensíveis para os utilizadores. Temos de garantir que os utilizadores têm acesso fácil a uma visão actualizada dos seus activos actuais e das mensagens publicadas que lhes são destinadas. Estes pontos de vista devem depender de ferramentas abertas e não de soluções proprietárias. Será necessário um trabalho árduo para evitar que a maior complexidade da infraestrutura de pagamento se transforme numa "torre de abstração" opaca, em que os programadores tenham dificuldade em compreender o que se passa e em adaptá-la a novos contextos. Apesar dos desafios, conseguir escalabilidade, segurança da carteira e privacidade para os utilizadores regulares é crucial para o futuro do Ethereum. Não se trata apenas de viabilidade técnica, mas de acessibilidade real para os utilizadores regulares. Temos de estar à altura deste desafio.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[vitalik], Todos os direitos de autor pertencem ao autor original[Vitalik Buterin]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.