Agradecimentos especiais a Dan Finlay, Karl Floersch, David Hoffman e às equipes da Scroll e da SoulWallet pelos comentários, revisões e sugestões.

À medida que a Ethereum passa de uma tecnologia experimental jovem para uma pilha de tecnologia madura capaz de realmente levar uma experiência aberta, global e sem permissão para os usuários comuns, há três grandes transições técnicas pelas quais a pilha precisa passar, mais ou menos simultaneamente:

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

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

Sem o primeiro, a Ethereum fracassa porque cada transação custa US$ 3,75 (US$ 82,48 se tivermos outra corrida de touros), e todo produto que visa ao mercado de massa inevitavelmente se esquece da cadeia e adota soluções alternativas centralizadas para tudo.

Sem o segundo, a Ethereum fracassa porque os usuários não se sentem à vontade para armazenar seus fundos (e ativos não financeiros), e todos passam a usar bolsas centralizadas.

Sem o terceiro, o Ethereum fracassa porque ter todas as transações (e POAPs, etc.) disponíveis publicamente para literalmente qualquer pessoa ver é um sacrifício de privacidade alto demais para muitos usuários, e todos passam a usar soluções centralizadas que, pelo menos, ocultam um pouco seus dados.

Essas três transições são cruciais pelos motivos acima. Mas eles também são desafiadores devido à intensa coordenação envolvida para resolvê-los adequadamente. Não são apenas os recursos do protocolo que precisam ser aprimorados; em alguns casos, a maneira como interagimos com a Ethereum precisa mudar fundamentalmente, exigindo mudanças profundas nos aplicativos e nas carteiras.

As três transições reformularão radicalmente o relacionamento entre usuários e endereços

Em um mundo de dimensionamento de L2, os usuários existirão em muitos L2s. O senhor é membro da ExampleDAO, que vive do otimismo? Então o senhor tem uma conta no Optimism! O senhor está mantendo um CDP em um sistema de stablecoin na ZkSync? Então o senhor tem uma conta no ZkSync! O senhor já experimentou algum aplicativo que por acaso vivia em Kakarot? Então o senhor tem uma conta no Kakarot! Os dias em que um usuário tinha apenas um endereço não existirão mais.

Eu tenho ETH em quatro lugares, de acordo com minha visualização da Brave Wallet. E sim, Arbitrum e Arbitrum Nova são diferentes. Não se preocupe, isso ficará mais confuso com o tempo!

As carteiras de contratos inteligentes aumentam a complexidade, pois tornam muito mais difícil ter o mesmo endereço em L1 e nos vários L2s. Atualmente, a maioria dos usuários usa contas de propriedade externa, cujo endereço é literalmente um hash da chave pública usada para verificar as assinaturas - portanto, nada muda entre L1 e L2. No entanto, com as carteiras de contratos inteligentes, manter um endereço se torna mais difícil. Embora muito trabalho tenha sido feito para tentar fazer com que os endereços sejam hashes de código que possam ser equivalentes em todas as redes, principalmente o CREATE2 e a fábrica de singleton ERC-2470, é difícil fazer com que isso funcione perfeitamente. Algumas L2s (por exemplo. "type 4 ZK-EVMs") não são totalmente equivalentes a EVMs, muitas vezes usando Solidity ou um conjunto intermediário, impedindo a equivalência de hash. E mesmo quando o senhor pode ter equivalência de hash, a possibilidade de as carteiras mudarem de propriedade por meio de mudanças de chave cria outras consequências não intuitivas.

A privacidade exige que cada usuário tenha ainda mais endereços e pode até mudar os tipos de endereços com os quais estamos lidando. Se as propostas de endereços furtivos forem amplamente utilizadas, em vez de cada usuário ter apenas alguns endereços, ou um endereço por L2, os usuários 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 ativos são armazenados de uma maneira diferente: os fundos de muitos usuários são armazenados no mesmo contrato inteligente (e, portanto, no mesmo endereço). Para enviar fundos a um usuário específico, os usuários precisarão contar com o 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 usuário ~= um endereço" de maneiras diferentes, e alguns desses efeitos se refletem na complexidade da execução das transições. Dois pontos específicos de complexidade são:

1. Se o senhor quiser pagar alguém, como obterá as informações sobre como pagá-lo?
2. Se os usuários tiverem muitos ativos armazenados em diferentes locais em diferentes cadeias, como eles farão as principais alterações 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 pelo café (se o "eu" for literalmente eu, o autor deste artigo, então "café" é, obviamente, uma metonímia para "chá verde"). O senhor está me vendendo o café, mas só está configurado para receber moedas no Taiko. O que fazer?

Há basicamente duas soluções:

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

É claro que essas 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 houver sorte, ou um caminho de ponte entre L2s.

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

Felizmente, a transição para carteiras de contratos inteligentes não representa um grande ônus para o sistema de endereçamento, mas ainda há alguns problemas técnicos em outras partes da pilha de aplicativos que precisam ser resolvidos. As carteiras precisarão ser atualizadas para garantir que não enviem apenas 21.000 gas junto com uma transação, e será ainda mais importante garantir que o lado de recebimento do pagamento de uma carteira rastreie não apenas as transferências de ETH das EOAs, mas também a ETH enviada pelo código de contrato inteligente. Aplicativos que se baseiam no pressuposto de que a propriedade do endereço é imutável (por exemplo, o As NFTs que proíbem contratos inteligentes para impor royalties) terão que encontrar outras maneiras de atingir seus objetivos. As carteiras de contratos inteligentes também facilitarão algumas coisas - notadamente, se alguém receber apenas um token ERC20 que não seja ETH, poderá usar os paymasters ERC-4337 para pagar pelo gás com esse token.

A privacidade, por outro lado, mais uma vez apresenta grandes desafios com os quais ainda não lidamos de fato. O Tornado Cash original não apresentou nenhum desses problemas, pois não suportava transferências internas: os usuários só podiam depositar no sistema e sacar dele. No entanto, quando o senhor puder fazer transferências internas, os usuários precisarão usar o esquema de endereçamento interno do sistema de privacidade. Na prática, as "informações de pagamento" de um usuário precisariam conter (i) algum tipo de "chave pública de gastos", um compromisso com um segredo que o destinatário poderia usar para gastar, e (ii) alguma forma de o remetente enviar informações criptografadas que somente o destinatário pode descriptografar, para ajudar o destinatário a descobrir o pagamento.

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

Visão geral esquemática de um esquema abstrato de endereços furtivos baseado em criptografia e ZK-SNARKs.

Uma lição importante aqui é que, em um ecossistema favorável à privacidade, um usuário terá tanto as chaves de publicação de gastos quanto as chaves de publicação de criptografia, e as "informações de pagamento" de um usuário deverão incluir ambas as chaves. Há também bons motivos, além dos pagamentos, para expandir nessa direção. Por exemplo, se quisermos um e-mail criptografado baseado em Ethereum, os usuários precisarão fornecer publicamente algum tipo de chave de criptografia. No "mundo EOA", poderíamos reutilizar as chaves da conta para isso, mas em um mundo seguro de carteira de contrato inteligente, provavelmente deveríamos ter uma funcionalidade mais explícita para isso. 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 maneira padrão de implementar alterações de chave e recuperação social em um mundo com muitos endereços por usuário é simplesmente fazer com que os usuários executem o procedimento de recuperação em cada endereço separadamente. Isso pode ser feito com um clique: a carteira pode incluir um software para executar o procedimento de recuperação em todos os endereços de um usuário ao mesmo tempo. No entanto, mesmo com essas 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: este é autoexplicativo.
2. Endereços contrafactuais: endereços para os quais o contrato inteligente ainda não foi publicado (na prática, isso significa uma conta da qual o senhor ainda não enviou fundos). Como usuário, o senhor 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 decorrentes de esquemas de endereços furtivos.
3. Privacidade: se um usuário tiver intencionalmente muitos endereços para evitar vinculá-los uns aos outros, ele certamente não desejará vincular publicamente todos eles recuperando-os ao mesmo tempo!

Resolver esses problemas é difícil. Felizmente, existe uma solução um tanto elegante que funciona razoavelmente bem: uma arquitetura que separa a lógica de verificação e a posse de ativos.

Cada usuário tem um contrato de armazenamento de chaves, que existe em um local (pode ser a rede principal ou uma L2 específica). Os usuários, então, têm 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. Os gastos com esses endereços exigiriam uma prova que fosse para o contrato do repositório de chaves mostrando a chave pública de gastos atual (ou, mais realisticamente, muito recente).

A prova pode ser implementada de várias maneiras:

• Acesso direto ao L1 somente para leitura dentro do L2. É possível modificar os L2s para dar a eles uma maneira de ler diretamente o estado do L1. Se o contrato do repositório de chaves estiver em L1, isso significaria que os contratos em L2 podem acessar o repositório de chaves "gratuitamente"
• Ramos de Merkle. As ramificações de Merkle podem provar o estado L1 para um L2, ou o estado L2 para um L1, ou o senhor pode combinar os dois para provar partes do estado de um L2 para outro L2. O principal ponto fraco das provas de Merkle é o alto custo do gás devido ao comprimento da prova: potencialmente 5 kB para uma prova, embora isso seja reduzido para < 1 kB no futuro devido às árvores de Verkle.
• ZK-SNARKs. O senhor pode reduzir os custos de dados usando um ZK-SNARK de uma ramificação de Merkle em vez da própria ramificação. É 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 em um bloco.
• Compromissos da KZG. Os L2s, ou os esquemas criados sobre eles, poderiam introduzir um sistema de endereçamento sequencial, permitindo que as provas de estado dentro desse sistema tivessem apenas 48 bytes. Como no caso dos ZK-SNARKs, um esquema de múltiplas provas poderia mesclar todas essas provas em uma única prova por bloco.

Se quisermos evitar fazer uma prova por transação, podemos implementar um esquema mais leve que exija apenas uma prova cross-L2 para recuperação. Os gastos de uma conta dependeriam de uma chave de gastos cuja pubkey correspondente é armazenada nessa conta, mas a recuperação exigiria uma transação que copiasse a spending_pubkey atual no keystore. Os fundos em endereços contrafatuais estão seguros, mesmo que suas chaves antigas não estejam: Para "ativar" um endereço contrafatual e transformá-lo em um contrato de trabalho, seria necessário fazer uma prova cross-L2 para copiar a spending_pubkey atual. Este tópico nos fóruns do Safe descreve como uma arquitetura semelhante pode funcionar.

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

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

Esses esquemas podem ser complexos. O lado positivo é que há muitas sinergias potenciais entre eles. Por exemplo, o conceito de "contratos de repositório de chaves" também poderia ser uma solução para o desafio dos "endereços" mencionado na seção anterior: se quisermos que os usuários tenham endereços persistentes, que não mudem toda vez que o usuário atualizar uma chave, poderíamos colocar meta-endereços furtivos, chaves de criptografia e outras informações no contrato de repositório de chaves e usar o endereço do contrato de repositório de chaves como o "endereço" do usuário.

Muita infraestrutura secundária precisa ser atualizada

Usar o ENS é caro. Hoje, em junho de 2023, a situação não é tão ruim: a taxa de transação é significativa, mas ainda é comparável à taxa de domínio ENS. O registro do zuzalu.eth me custou cerca de US$ 27, dos quais US$ 11 foram de taxas de transação. Mas, se tivermos outro mercado em alta, as taxas vão disparar. Mesmo sem os aumentos de preço da ETH, as taxas de gás que retornam a 200 gwei aumentariam a taxa de câmbio de um registro de domínio para US$ 104. Portanto, se quisermos que as pessoas realmente usem a ENS, especialmente em casos de uso como mídias sociais descentralizadas, em que os usuários exigem registro quase gratuito (e a taxa de domínio da ENS não é um problema porque essas plataformas oferecem subdomínios aos seus usuários), precisamos que a ENS trabalhe no L2.

Felizmente, a equipe do ENS deu um passo à frente e o ENS on L2 está realmente acontecendo! O ERC-3668 (também conhecido como "o padrão CCIP"), juntamente com o ENSIP-10, oferece uma maneira de verificar automaticamente os subdomínios ENS em qualquer L2. O padrão CCIP exige a configuração de um contrato inteligente que descreva um método para verificar provas de dados em L2 e um domínio (por exemplo, o senhor pode ter um contrato inteligente com o senhor). A Optinames usa ecc.eth) pode ser colocada sob o controle de tal contrato. Quando o contrato da CCIP controlar o ecc.eth no L1, o acesso a algum subdomínio.ecc.eth envolverá automaticamente a localização e a verificação de uma prova (por exemplo, o Merkle branch) do estado em L2 que realmente armazena esse subdomínio específico.

Na verdade, buscar as provas envolve ir a uma lista de URLs armazenados no contrato, o que, reconhecidamente, parece uma centralização, embora eu afirme que não é: trata-se de um modelo de confiança 1-de-N (provas inválidas são capturadas pela lógica de verificação na função de retorno de chamada do contrato CCIP e, desde que um dos URLs retorne uma prova válida, o senhor está 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 reformas radicais do tipo que precisamos são realmente possíveis. Mas há muito mais reformas na camada de aplicativos que precisam ser feitas. Alguns exemplos:

• Muitos dapps dependem de usuários que fornecem assinaturas fora da cadeia. Com as contas de propriedade externa (EOAs), isso é fácil. O ERC-1271 oferece uma maneira padronizada de fazer isso para carteiras de contratos inteligentes. No entanto, muitos dapps ainda não são compatíveis com o ERC-1271; eles precisarão ser.
• Dapps que usam "is this an EOA?" para discriminar entre usuários e contratos (por exemplo, para evitar transferências ou impor royalties) serão quebrados. Em geral, desaconselho a tentativa de encontrar uma solução puramente técnica aqui; descobrir se uma determinada transferência de controle criptográfico é ou não uma transferência de propriedade beneficiária é um problema difícil e provavelmente não pode ser resolvido sem recorrer a alguns mecanismos fora da cadeia orientados pela comunidade. Muito provavelmente, os aplicativos terão que depender menos da prevenção de transferências e mais de técnicas como os impostos Harberger.
• A forma como as carteiras interagem com os gastos e as chaves de criptografia terá que ser aprimorada. Atualmente, as carteiras costumam usar assinaturas determinísticas para gerar chaves específicas de aplicativos: assinar um nonce padrão (por exemplo, o hash do nome do aplicativo) com a chave privada de um EOA gera um valor determinístico que não pode ser gerado sem a chave privada e, portanto, é seguro em um sentido puramente técnico. No entanto, essas técnicas são "opacas" para a carteira, impedindo que a carteira implemente verificações de segurança no nível da interface do usuário. Em um ecossistema mais maduro, a assinatura, a criptografia e as funcionalidades relacionadas terão que ser tratadas pelas carteiras de forma mais explícita.
• Clientes leves (por exemplo. Helios) terá que verificar os L2s e não apenas o L1. Atualmente, os clientes leves se concentram na verificação da validade dos cabeçalhos L1 (usando o protocolo de sincronização do cliente leve) e na verificação das ramificações Merkle do estado L1 e das transações com raiz no cabeçalho L1. Amanhã, eles também precisarão verificar uma prova do estado de L2 com raiz na raiz do estado armazenado em L1 (uma versão mais avançada disso analisaria as pré-confirmações de L2).

As carteiras precisarão proteger tanto os ativos quanto os dados

Hoje em dia, as carteiras estão no negócio de proteger ativos. Tudo vive na cadeia, e a única coisa que a carteira precisa proteger é a chave privada que está guardando esses ativos no momento. Se o senhor alterar a chave, poderá publicar com segurança sua chave privada anterior na Internet no dia seguinte. No entanto, em um mundo ZK, isso não é mais verdade: a carteira não está apenas protegendo as credenciais de autenticação, mas também mantém seus dados.

Vimos os primeiros sinais desse mundo com o Zupass, o sistema de identidade baseado no ZK-SNARK que foi usado no Zuzalu. Os usuários tinham uma chave privada que usavam para se autenticar no sistema, que poderia ser usada para fazer provas básicas como "provar que sou residente de Zuzalu, sem revelar qual". Mas o sistema Zupass também começou a ter outros aplicativos integrados, principalmente os selos (a versão do Zupass dos POAPs).

Um dos meus muitos selos Zupass, confirmando que sou um orgulhoso membro da Equipe Cat.

O principal recurso que os carimbos oferecem em relação aos POAPs é que os carimbos são privados: o usuário mantém os dados localmente e só prova um carimbo (ou algum cálculo sobre os carimbos) a alguém se quiser que essa pessoa tenha essas informações sobre o usuário. Mas isso cria um risco adicional: se o senhor perder essas informações, perderá seus selos.

É claro que o problema de manter os dados pode ser reduzido ao problema de manter uma única chave de criptografia: algum terceiro (ou até mesmo a cadeia) pode manter uma cópia criptografada dos dados. Isso tem a vantagem conveniente de que as ações que o senhor realiza não alteram a chave de criptografia e, portanto, não exigem nenhuma interação com o sistema que mantém sua chave de criptografia segura. Mas, mesmo assim, se o senhor perder a chave de criptografia, perderá tudo. Por outro lado, se alguém vir sua chave de criptografia, verá tudo o que foi criptografado com essa chave.

A solução de fato da Zupass foi incentivar as pessoas a armazenar suas chaves em vários dispositivos (por exemplo, o laptop e telefone), pois a chance de eles perderem o acesso a todos os dispositivos ao mesmo tempo é pequena. Poderíamos ir além e usar o compartilhamento de segredos para armazenar a chave, dividida entre vários guardiões.

Esse tipo de recuperação social via MPC não é uma solução suficiente para carteiras, pois significa que não apenas os guardiões atuais, mas também os anteriores, poderiam conspirar para roubar seus ativos, o que é um risco inaceitavelmente alto. Mas os vazamentos de privacidade são, em geral, um risco menor do que a perda total de ativos, e alguém com um caso de uso que exige muita privacidade pode sempre aceitar um risco maior de perda se não fizer o backup da chave associada a essas ações que exigem privacidade.

Para evitar sobrecarregar o usuário com um sistema bizantino de vários caminhos de recuperação, as carteiras que oferecem suporte à recuperação social provavelmente precisarão gerenciar tanto a recuperação de ativos quanto a recuperação de chaves de criptografia.

Voltar à identidade

Uma das linhas comuns dessas mudanças é que o conceito de "endereço", um identificador criptográfico que o usuário usa para representar "você" na cadeia, terá que mudar radicalmente. As "instruções sobre como interagir comigo" não seriam mais apenas um endereço ETH; elas teriam que ser, de alguma forma, uma combinação de vários endereços em vários L2s, meta-endereços furtivos, chaves de criptografia e outros dados.

Uma maneira de fazer isso é tornar o ENS sua identidade: seu registro ENS poderia conter todas essas informações e, se o senhor enviar a alguém bob.eth (ou bob.ecc.eth, ou...), eles poderiam pesquisar e ver tudo sobre como pagar e interagir com o senhor, inclusive nas formas mais complicadas de preservação de privacidade e entre domínios.

Mas essa abordagem centrada no ENS tem dois pontos fracos:

• Ele vincula muitas coisas ao seu nome. Seu nome não é o senhor, seu nome é um dos muitos atributos do senhor. Deveria ser possível alterar seu nome sem mudar todo o seu perfil de identidade e atualizar uma série de registros em vários aplicativos.
• O senhor não pode ter nomes contrafactuais sem confiança. Um dos principais recursos de UX de qualquer blockchain é a capacidade de enviar moedas para pessoas que ainda não interagiram com a cadeia. Sem essa funcionalidade, há uma armadilha: a interação com a cadeia exige o pagamento de taxas de transação, o que exige... já ter moedas. Os endereços ETH, inclusive os endereços de contratos inteligentes com CREATE2, têm esse recurso. Os nomes ENS não o fazem, porque se dois Bobs decidirem, fora da cadeia, que são bob.ecc.eth, não há como escolher qual deles receberá 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 poderia conter todas as várias informações sobre o usuário e como interagir com ele (e com o CCIP, algumas dessas informações poderiam estar fora da cadeia), e os usuários usariam o contrato do repositório de chaves como identificador principal. Mas os ativos reais que eles recebem seriam armazenados em todos os tipos de lugares diferentes. Os contratos de repositório de chaves não estão vinculados a um nome e são compatíveis com o contrafactual: o senhor 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.

Outra categoria de soluções tem a ver com o abandono total do conceito de endereços voltados para o usuário, em um espírito semelhante ao do protocolo de pagamento Bitcoin. Uma ideia é confiar mais nos canais de comunicação direta entre o remetente e o destinatário; por exemplo, o remetente poderia enviar um link de reivindicação (como um URL explícito ou um código QR) que o destinatário poderia usar para aceitar o pagamento da forma que desejar.

Independentemente de o remetente ou o destinatário agir primeiro, uma maior confiança nas carteiras que geram diretamente informações de pagamento atualizadas em tempo real poderia reduzir o atrito. Dito isso, os identificadores persistentes são convenientes (especialmente com o ENS), e a suposição de comunicação direta entre o remetente e o destinatário é realmente complicada na prática e, portanto, podemos acabar vendo uma combinação de diferentes técnicas.

Em todos esses projetos, é fundamental manter as coisas descentralizadas e compreensíveis para os usuários. Precisamos garantir que os usuários tenham acesso fácil a uma visão atualizada de quais são seus ativos atuais e quais mensagens foram publicadas e destinadas a eles. Essas visualizações devem depender de ferramentas abertas, 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 em uma "torre de abstração" opaca, na qual os desenvolvedores tenham dificuldade para entender o que está acontecendo e adaptá-la a novos contextos. Apesar dos desafios, alcançar escalabilidade, segurança de carteira e privacidade para usuários regulares é crucial para o futuro da Ethereum. Não se trata apenas de viabilidade técnica, mas de acessibilidade real para usuários comuns. Precisamos nos erguer para enfrentar esse desafio.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[vitalik], Todos os direitos autorais pertencem ao autor original[Vitalik Buterin]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.