Quando o Ethereum se transforma de uma jovem tecnologia experimental em uma pilha de tecnologia madura que pode realmente trazer uma experiência aberta, global e sem permissão para usuários comuns, a pilha precisa passar por três grandes transformações tecnológicas, aproximadamente simultaneamente:
Mudança de escala L2 - todos migram para rollups
Mudança de segurança de carteira - todos migram para carteiras de contrato inteligentes
Mudança de privacidade - Garanta transferências de dinheiro que preservam a privacidade e garanta que todas as outras ferramentas que estão sendo desenvolvidas (recuperação social, identidade, reputação) preservam a privacidade
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)
Este é o triângulo da transformação do ecossistema. Você só pode escolher 3 de 3.
Sem o primeiro, o Ethereum falharia porque cada transação custaria $ 3,75 ($ 82,48 se tivéssemos outra alta), e todo produto do mercado de massa acabaria esquecendo a cadeia e adotaria uma solução centralizada para tudo.
Sem o segundo, o Ethereum falharia, pois os usuários relutariam em armazenar seus fundos (e ativos não financeiros) e todos passariam para exchanges centralizadas.
Sem um terceiro, o Ethereum falharia, pois todas as transações (e POAPs, etc.) solução.
Pelas razões mencionadas acima, essas três transições são críticas. Mas também são desafiadores devido à intensa coordenação necessária para resolvê-los. Não apenas a funcionalidade do protocolo precisa ser melhorada, mas há casos em que mudanças bastante fundamentais precisam ser feitas na forma como interagimos com o Ethereum, exigindo mudanças profundas em aplicativos e carteiras.
Essas três mudanças vão revolucionar a relação entre usuários e endereços
Em um mundo estendido de L2, os usuários existirão em muitos L2s. Você é membro do ExampleDAO, que está no Optimism? Então você tem uma conta no Optimism! Você possui CDP no sistema de stablecoin do ZkSync? Então você tem uma conta no ZkSync! Você já tentou alguns aplicativos que estão no Kakarot? Então você tem uma conta no Kakarot! Foi-se o tempo em que os usuários tinham apenas um endereço.
Eu tenho ETH em quatro lugares, de acordo com minha visão da Brave Wallet. Sim, Arbitrum e Arbitrum Nova são diferentes. Não se preocupe, isso vai ficar mais complicado com o tempo!
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-a9bb8e17d9-dd1a6f-62a40f)
As carteiras de contratos inteligentes adicionam mais complexidade, tornando mais difícil ter o mesmo endereço no L1 e em vários L2s. Hoje, a maioria dos usuários está usando contas de propriedade externa cujos endereços são, na verdade, o hash da chave pública usada para verificar a assinatura - portanto, nada muda entre L1 e L2. No entanto, com carteiras de contrato inteligentes, manter um endereço se torna mais difícil. Embora muito trabalho tenha sido feito tentando tornar os endereços um hash de código equivalente em toda a rede, principalmente as fábricas de singleton CREATE2 e ERC-2470, tem sido muito difícil fazer isso perfeitamente. Alguns L2s (como "tipo 4 ZK-EVMs") não são totalmente equivalentes aos EVMs, geralmente usando Solidity ou um assembly intermediário, evitando a equivalência de hash. Mesmo que você pudesse ter equivalência de hash, a possibilidade de carteiras mudarem de propriedade por meio de mudanças de chave tem outras consequências não intuitivas.
A privacidade requer mais endereços por usuário e pode até alterar os tipos de endereços que gerenciamos. Se a proposta de endereço privado for amplamente utilizada, ao invés de apenas alguns endereços por usuário, ou um endereço por L2, pode haver um endereço por transação. Outros esquemas de privacidade, mesmo os já existentes, como o Tornado Cash, alteram a maneira como os ativos são armazenados de 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, o usuário precisa contar com o próprio sistema de endereço interno do esquema de privacidade.
Como vimos, as três mudanças enfraqueceram o modelo mental “um usuário ~= um endereço” de maneiras diferentes, e alguns desses efeitos retroalimentaram a complexidade da implementação das mudanças. Duas complicações específicas são:
Se você deseja pagar alguém, como obtém as informações para pagá-lo?
Se um usuário armazena muitos ativos em lugares diferentes em cadeias diferentes, como ele realiza a substituição de chaves e a recuperação social?
Três transições estão relacionadas a pagamentos on-chain (e identidade)
Tenho moedas no Scroll e quero pagar pelo café (se "eu" está literalmente se referindo a mim como o autor deste artigo, então "café" é obviamente uma metonímia de "chá verde"). Você está me vendendo café, mas só vai receber moedas no Taiko. o que eu faço?
Basicamente existem duas soluções:
A carteira receptora (pode ser um comerciante ou apenas um indivíduo comum) se esforça para oferecer suporte a cada L2, com alguma funcionalidade automática para integrar fundos de forma assíncrona.
O destinatário fornece seu L2 e seu endereço, e a carteira do remetente encaminha automaticamente os fundos para o L2 de destino por meio de algum tipo de sistema de ponte inter-L2.
Obviamente, essas soluções podem ser combinadas: o destinatário fornece a lista L2 que está disposto a aceitar e a carteira do remetente calcula o pagamento, que pode envolver envio direto (se tiver sorte) ou por meio de um caminho em ponte na L2.
Mas esse é apenas um exemplo do principal desafio introduzido pelos três turnos: algo tão simples quanto pagar alguém começa a exigir mais informações do que apenas um endereço de 20 bytes.
Felizmente, a mudança para carteiras de contrato inteligentes não sobrecarregou muito o sistema de endereços, mas ainda existem alguns problemas técnicos que precisam ser resolvidos em outras partes da pilha de aplicativos. As carteiras precisam ser atualizadas para garantir que não estejam apenas enviando 21.000 gás em transações, mas, mais importante, para garantir que o lado de recebimento de pagamentos da carteira não apenas rastreie as transferências de ETH de EOAs, mas também ETH enviado por código de contrato inteligente. Aplicativos que dependem da suposição de propriedade imutável de endereços (por exemplo, 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 - em particular, se alguém aceitar apenas tokens não-ETH ERC20, poderá usar um pagador ERC-4337 para pagar pelo gás com esse token.
Por outro lado, a privacidade novamente apresenta grandes desafios que ainda não resolvemos. O Tornado Cash original não apresentava esses problemas porque não suportava transferências internas: os usuários só podiam depositar no sistema e sacar. Uma vez que você pode fazer transferências internas, os usuários precisam usar o esquema de endereço interno do sistema de privacidade. Na prática, a "mensagem de pagamento" de um usuário precisa conter (i) algum tipo de "chave pública de gasto", uma promessa de um segredo que o destinatário pode usar para gastar e (ii) o remetente envia uma mensagem criptografada que somente o destinatário pode descriptografar uma maneira de ajudar os destinatários a descobrir pagamentos.
O protocolo de endereço de privacidade baseia-se no conceito de meta-endereço, que funciona da seguinte maneira: parte do meta-endereço é uma versão oculta da chave de gastos do remetente e a outra parte é a chave de criptografia do remetente (embora implementações mínimas pode definir isso Ambas as chaves são as mesmas).
![Vitalik: Para alcançar a aterrissagem em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-39bca9184c-dd1a6f-62a40f)
A principal lição aqui é que, em um ecossistema focado na privacidade, os usuários terão chaves públicas de gastos e chaves públicas de criptografia, e as "informações de pagamento" dos usuários terão que conter ambas as chaves. Além de pagar, há outros bons motivos para expandir nessa direção. Por exemplo, se quiséssemos e-mail criptografado no Ethereum, os usuários precisariam fornecer publicamente alguma forma de chave de criptografia. Em um "mundo EOA", poderíamos reutilizar chaves de conta para conseguir isso, mas em um mundo de carteiras de contratos inteligentes seguras, provavelmente deveríamos ter uma funcionalidade mais explícita para conseguir isso. Isso também ajudará a tornar as identidades baseadas em Ethereum mais compatíveis com ecossistemas de privacidade descentralizados não Ethereum, sendo o exemplo mais proeminente as chaves PGP.
Três transformações e recuperação de chaves
Em um mundo onde um usuário pode ter vários endereços, a maneira padrão de implementar mudanças importantes e recuperação social é fazer com que o usuário execute procedimentos de recuperação em cada endereço individualmente. Isso pode ser feito com um clique: as carteiras podem conter software para executar procedimentos de recuperação nos endereços de todos os usuários simultaneamente. No entanto, mesmo com essa simplificação de UX, existem três problemas com a recuperação ingênua de vários endereços:
Contas de gás irrealistas: esta fala por si.
Endereço contrafactual: um endereço cujo contrato inteligente não foi publicado (na verdade, isso significa uma conta da qual você ainda não enviou fundos). Como usuário, você tem um número potencialmente infinito de endereços contrafactuais: um ou mais em cada L2, incluindo L2s que ainda não existem, e um conjunto completamente diferente de endereços contrafactuais infinitos, derivados do esquema de endereço esteganográfico.
Privacidade: Se um usuário tiver muitos endereços intencionalmente para evitar vinculá-los, certamente não deseja vincular todos eles publicamente restaurando-os ao mesmo tempo ou mais ou menos!
Resolver esses problemas é difícil. Felizmente, existe uma solução bastante elegante que funciona muito bem: uma arquitetura que separa a lógica de validação da retenção de ativos.
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-25b93e2117-dd1a6f-62a40f)
Cada usuário tem um contrato de keystore que existe em um local (pode ser a rede principal ou um L2 específico). Os usuários então têm endereços em diferentes L2s, onde a lógica de verificação para cada endereço é um ponteiro para o contrato de keystore. Os gastos desses endereços exigirão uma prova no contrato de armazenamento de chave mostrando a chave pública de gasto atual (ou mais realisticamente, a mais recente).
A prova pode ser obtida de várias maneiras:
Leia o acesso L1 somente leitura diretamente em L2. L2 pode ser modificado para dar a eles uma maneira de ler o estado de L1 diretamente. Se o contrato de keystore estiver em L1, isso significará que os contratos em L2 têm acesso "livre" ao keystore.
Filial de Merkel. Ramificações Merkle podem provar estados L1 para L2, ou estados L2 para L1, ou você pode combinar os dois para provar partes de um estado L2 para outro L2. A principal fraqueza das provas Merkle é o alto custo do gás devido ao comprimento da prova: uma prova pode exigir 5 kB, embora isso seja reduzido para menos de 1 kB no futuro graças às árvores Verkle.
ZK-SNARKs. Você pode reduzir os custos de dados usando ZK-SNARKs de ramificações Merkle em vez das próprias ramificações. Técnicas de agregação off-chain (por exemplo, baseadas em EIP-4337) podem ser construídas de forma que um único ZK-SNARK verifique todas as provas de estado cross-chain em um bloco.
Compromisso KZG. O L2, ou esquemas construídos sobre ele, pode introduzir um sistema de endereçamento sequencial que permite que as provas de estado dentro desse sistema tenham apenas 48 bytes de comprimento. Como ZK-SNARKs, um esquema multi-prova pode combinar todas essas provas em uma única prova para cada bloco.
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-a50b6aa1e3-dd1a6f-62a40f)
Se quisermos evitar fazer uma prova para cada transação, podemos implementar uma solução mais leve, só precisamos fazer uma prova cross-L2 ao recuperar. Os gastos de uma conta dependerão de uma chave de gastos cuja chave pública correspondente está armazenada na conta, mas a recuperação exigirá uma transação copiando a chave pública de gastos atual no armazenamento de chaves. Os fundos em um endereço contrafactual são seguros, mesmo que sua chave antiga não seja: "ativar" um endereço contrafactual, transformá-lo em um contrato de trabalho exigirá uma prova cruzada de L2 que replique a chave pública de gastos atual. Este tópico nos fóruns do Safe descreve como uma arquitetura semelhante pode funcionar.
Para adicionar privacidade a tal esquema, precisamos apenas criptografar o ponteiro e, em seguida, fazer todas as provas em ZK-SNARKs:
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-137a30a3c1-dd1a6f-62a40f)
Com mais trabalho (por exemplo, usando este trabalho como ponto de partida), também podemos retirar a maior parte da complexidade dos ZK-SNARKs e fazer um esquema mais simples baseado em KZG.
Esses cenários podem ficar complicados. No entanto, existem muitas sinergias potenciais entre esses programas. Por exemplo, o conceito de "contrato de keystore" também pode ser uma solução para o desafio de "endereço" mencionado na seção anterior: se quisermos que os usuários tenham endereços persistentes que não mudam quando os usuários atualizam suas chaves, é possível colocar metaendereços secretos, chaves de criptografia e outras informações em um contrato de armazenamento de chaves e usar o endereço do contrato de armazenamento de chaves como o "endereço" do usuário.
Muita infraestrutura secundária precisa ser atualizada
Usar o ENS é caro. Hoje, junho de 2023, as coisas não estão tão ruins: as taxas de transação, embora altas, são comparáveis às taxas de domínio ENS. O registro no zuzalu.eth me custou cerca de $ 27, dos quais $ 11 são taxas de transação. Mas se tivermos outro mercado em alta, as taxas vão disparar. Mesmo sem o aumento do preço do ETH, o retorno da taxa de gás para 200 gwei aumentaria a taxa de transação para registro de domínio para US$ 104. Portanto, se quisermos que as pessoas realmente usem o ENS, especialmente para casos de uso como mídia social descentralizada, onde os usuários solicitam registro quase gratuito (as taxas de domínio do ENS não são um problema, pois essas plataformas fornecem subdomínios para seus usuários), precisamos do ENS Runs on L2 .
Felizmente, a equipe do ENS já está em movimento, e o ENS no L2 está realmente acontecendo! O ERC-3668 (também conhecido como "padrão CCIP"), juntamente com o ENSIP-10, fornece um método para validar automaticamente os subdomínios ENS em qualquer L2. O padrão CCIP requer a configuração de um contrato inteligente que descreva um método para verificar provas de dados L2, e nomes de domínio (ecc.eth para Optinames, por exemplo) podem ser colocados sob o controle de tal contrato. Uma vez que o contrato CCIP controla ecc.eth em L1, o acesso a algum subdomínio.ecc.eth envolverá automaticamente encontrar e verificar o estado L2 da prova (por exemplo, filial Merkle) que realmente armazena esse subdomínio específico.
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-b1a43ef2c1-dd1a6f-62a40f)
Na verdade, obter provas envolve acessar uma série de URLs armazenadas no contrato, o que reconhecidamente parece centralização, embora eu argumente que na verdade não é: é um modelo de confiança 1-de-N (provas inválidas seriam bloqueadas pelo CCIP A verificação lógica na função callback do contrato capta que, desde que haja uma URL que retorne uma prova válida, não há problema). Esta lista de URLs pode conter dezenas de URLs.
O trabalho do ENS CCIP é uma história de sucesso e deve ser visto como um sinal de que o tipo de reforma radical de que precisamos é possível. Mas são necessárias mais reformas em nível de aplicativo. Alguns exemplos incluem:
Muitos dapps dependem de usuários para fornecer assinaturas off-chain. Para contas de propriedade externa (EOAs), é fácil. O ERC-1271 fornece uma maneira padronizada para carteiras de contratos inteligentes fazerem isso. No entanto, muitos dapps ainda não suportam ERC-1271; eles precisam apoiá-lo.
Dapps que usam "Is this EOA?" para diferenciar entre usuários e contratos (por exemplo, para impedir transferências ou aplicar royalties) serão interrompidos. Em geral, eu desaconselho tentar encontrar uma solução puramente técnica; a questão de descobrir se uma determinada transferência de controle criptográfico é uma transferência de interesse benéfico é um problema difícil que não pode ser resolvido sem recorrer a alguma comunidade off-chain Mecanismos acionados. Em seguida, resolva. Muito provavelmente, os aplicativos terão que depender menos do bloqueio de transferências e mais de técnicas como o imposto de Harberger.
A forma como as carteiras interagem com os gastos e as chaves de criptografia precisará melhorar. Atualmente, as carteiras normalmente usam assinaturas determinísticas para gerar chaves específicas do aplicativo: um nonce padrão (por exemplo, um hash do nome do aplicativo) é assinado com a chave privada do EOA, gerando um nonce que não pode ser gerado sem a chave privada. de , por isso é tecnicamente seguro. No entanto, essas técnicas são "opacas" para a carteira, impedindo que as carteiras implementem verificações de segurança no nível da interface do usuário. Em um ecossistema mais maduro, assinatura, criptografia e funções relacionadas precisam ser tratadas de forma mais explícita pelas carteiras.
Clientes leves (por exemplo, Helios) terão que verificar L2, não apenas L1. Hoje, os clientes leves se concentram em verificar a validade do cabeçalho L1 (usando o protocolo de sincronização do cliente leve) e validar o estado L1 e as bifurcações Merkle das transações originadas no cabeçalho L1. Amanhã, eles também precisam verificar a comprovação do estado L2 proveniente da raiz do estado armazenado em L1 (essa versão mais avançada, na verdade, olha para a pré-confirmação de L2).
Carteiras precisam proteger ativos e dados
Agora, o negócio da carteira é proteger ativos. Tudo está na cadeia e a única coisa que a carteira precisa proteger são as chaves privadas que atualmente protegem esses ativos. Se você alterar as chaves, poderá publicar com segurança sua chave privada anterior na Internet no dia seguinte. No entanto, em um mundo de provas de conhecimento zero, esse não é mais o caso: as carteiras não estão apenas protegendo as credenciais de autenticação, elas estão protegendo seus dados.
Vimos os primeiros sinais desse mundo com o Zupass, o sistema de identidade baseado em ZK-SNARK usado na Zuzalu. Os usuários possuem uma chave privada, que utilizam para autenticar o sistema, que pode ser utilizada para fazer provas básicas como "provar que sou morador de Zuzalu, mas não revelar qual". No entanto, o sistema Zupass também passou a ter outros aplicativos construídos sobre ele, principalmente Stamps (versão Zupass dos POAPs).
Um dos meus muitos selos Zupass provando que sou um membro orgulhoso do Team Cat.
A principal característica que os selos oferecem sobre os POAPs é que os selos são privados: você mantém os dados localmente e só prova o selo (ou algum cálculo sobre ele) para eles se quiser que eles tenham essas informações sobre você. Mas isso aumenta o risco: se você perder essa informação, perde o carimbo.
Obviamente, o problema de manter dados se resume ao problema de manter uma chave criptográfica: um terceiro (ou mesmo a cadeia) pode manter uma cópia criptografada dos dados. Isso tem a vantagem conveniente de que a ação que você executa não altera a chave de criptografia, portanto, nenhuma interação com o sistema que mantém sua chave de criptografia segura é necessária. Mas mesmo assim, se você perder sua chave de criptografia, perderá tudo. Por outro lado, se alguém vir sua chave de criptografia, poderá ver tudo criptografado com essa chave.
A solução de fato da Zupass é incentivar as pessoas a armazenar suas chaves em vários dispositivos (por exemplo, laptop e telefone), pois as chances de perder todas ao mesmo tempo são pequenas. Podemos dar um passo adiante e usar um compartilhamento secreto para armazenar a chave, dividindo a chave entre vários guardiões.
Essa recuperação social via MPC não é uma solução adequada para carteiras, pois significa que não apenas os tutores atuais, mas também os tutores anteriores podem conspirar para roubar seus ativos, o que é um alto risco inaceitável. No entanto, uma violação de privacidade geralmente é menos arriscada do que uma perda completa de ativos e, se alguém exigir um caso de uso altamente preservador de privacidade, ele pode aceitar um risco maior de perda por não fazer backup das chaves associadas que exigem privacidade. ações de preservação.
Para evitar sobrecarregar os usuários com um sistema complexo de vários caminhos de recuperação, as carteiras que oferecem suporte à recuperação social podem precisar gerenciar a recuperação de ativos e a recuperação da chave de criptografia.
De volta à questão da identidade
Um tema comum dessas mudanças é que o conceito de um "endereço" que você usa na cadeia como um identificador criptográfico que representa "você" precisa mudar radicalmente. "Instruções sobre como interagir comigo" não são mais apenas um endereço ETH; eles devem conter alguma combinação de vários endereços em vários L2s, meta-endereços secretos, chaves de criptografia e outros dados de alguma forma.
Uma maneira de fazer isso é tornar a ENS sua identidade: seu registro ENS pode conter todas essas informações e, se você enviar a alguém bob.eth (ou bob.ecc.eth, ou...), eles poderão descobrir e aprender sobre todas as coisas que pagam e interagem com você, inclusive de formas transversais mais complexas e de preservação da privacidade.
No entanto, essa abordagem centrada no ENS tem dois pontos fracos:
Liga muitas coisas ao seu nome. Seu nome não é você, seu nome é apenas um de seus muitos atributos. Você deve poder alterar seu nome sem mover todo o seu perfil de identidade e atualizar vários registros em muitos aplicativos.
Você não pode ter nomes contrafactuais não confiáveis. Um recurso chave de UX de qualquer blockchain é a capacidade de enviar moedas para pessoas que ainda não interagiram com a cadeia. Sem essa funcionalidade, há um problema do ovo e da galinha: interagir com a cadeia exige o pagamento de taxas de transação e o pagamento de taxas requer... já possuir moedas. Endereços ETH, incluindo endereços de contrato inteligente com CREATE2, possuem esse recurso. O nome ENS não, porque se dois Bobs decidirem que são bob.ecc.eth off-chain, não há como escolher qual deles receberá o nome.
Uma solução possível é colocar mais coisas no contrato de keystore mencionado na arquitetura anteriormente neste post. O contrato de keystore pode conter várias informações sobre você e como você interage com ele (via CCIP, algumas das quais podem ser off-chain), e os usuários podem usar seu contrato de keystore como um identificador primário. Mas os ativos reais que eles recebem serão armazenados em vários lugares diferentes. Os contratos de keystore não estão vinculados a nomes, eles são amigáveis contrafactuais: você pode gerar um endereço que só pode ser inicializado por um contrato de keystore com alguns parâmetros iniciais fixos.
Outra categoria de soluções tem a ver com o abandono do conceito de endereços orientados ao usuário, que é semelhante em espírito ao 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 pode enviar um link de reivindicação (como um URL explícito ou código QR) que o destinatário pode usar Aceitar pagamentos da maneira que desejar.
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-f7c28b44ae-dd1a6f-62a40f)
Seja o remetente ou o destinatário quem age primeiro, confiar mais nas carteiras para gerar diretamente informações de pagamento atualizadas em tempo real reduz o atrito. Dito isto, os identificadores persistentes são convenientes (especialmente com ENS) e, na prática, a suposição de comunicação direta entre o remetente e o destinatário é um problema muito complicado, portanto, podemos considerar uma combinação de diferentes tecnologias.
Em todos esses designs, é fundamental manter as coisas descentralizadas e compreensíveis para os usuários. Precisamos garantir que os usuários possam acessar facilmente a visão mais atualizada de seus ativos atuais, bem como as informações publicadas destinadas a eles. Essas visões devem basear-se em ferramentas abertas em vez de soluções proprietárias. Será necessário muito trabalho para impedir que uma infraestrutura de pagamento mais complexa se torne uma "torre de abstração" opaca para que os desenvolvedores entendam o que está acontecendo e adaptem-se ao novo ambiente. Apesar dos desafios, alcançar a escalabilidade, a segurança da carteira e a privacidade do Ethereum para usuários comuns é fundamental. Não se trata apenas de viabilidade técnica, mas também de acessibilidade real para o usuário comum. Precisamos enfrentar esse desafio.
Agradecimentos especiais a Dan Finlay, Karl Floersch, David Hoffman e às equipes Scroll e SoulWallet por seus comentários, críticas e sugestões.
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Vitalik: Para alcançar uma implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade
Original: "As Três Transições"
Escrito por: Vitalik Buterin
Compilar: MarsBit, MK
Quando o Ethereum se transforma de uma jovem tecnologia experimental em uma pilha de tecnologia madura que pode realmente trazer uma experiência aberta, global e sem permissão para usuários comuns, a pilha precisa passar por três grandes transformações tecnológicas, aproximadamente simultaneamente:
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)
Este é o triângulo da transformação do ecossistema. Você só pode escolher 3 de 3.
Sem o primeiro, o Ethereum falharia porque cada transação custaria $ 3,75 ($ 82,48 se tivéssemos outra alta), e todo produto do mercado de massa acabaria esquecendo a cadeia e adotaria uma solução centralizada para tudo.
Sem o segundo, o Ethereum falharia, pois os usuários relutariam em armazenar seus fundos (e ativos não financeiros) e todos passariam para exchanges centralizadas.
Sem um terceiro, o Ethereum falharia, pois todas as transações (e POAPs, etc.) solução.
Pelas razões mencionadas acima, essas três transições são críticas. Mas também são desafiadores devido à intensa coordenação necessária para resolvê-los. Não apenas a funcionalidade do protocolo precisa ser melhorada, mas há casos em que mudanças bastante fundamentais precisam ser feitas na forma como interagimos com o Ethereum, exigindo mudanças profundas em aplicativos e carteiras.
Essas três mudanças vão revolucionar a relação entre usuários e endereços
Em um mundo estendido de L2, os usuários existirão em muitos L2s. Você é membro do ExampleDAO, que está no Optimism? Então você tem uma conta no Optimism! Você possui CDP no sistema de stablecoin do ZkSync? Então você tem uma conta no ZkSync! Você já tentou alguns aplicativos que estão no Kakarot? Então você tem uma conta no Kakarot! Foi-se o tempo em que os usuários tinham apenas um endereço.
Eu tenho ETH em quatro lugares, de acordo com minha visão da Brave Wallet. Sim, Arbitrum e Arbitrum Nova são diferentes. Não se preocupe, isso vai ficar mais complicado com o tempo!
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-a9bb8e17d9-dd1a6f-62a40f)
As carteiras de contratos inteligentes adicionam mais complexidade, tornando mais difícil ter o mesmo endereço no L1 e em vários L2s. Hoje, a maioria dos usuários está usando contas de propriedade externa cujos endereços são, na verdade, o hash da chave pública usada para verificar a assinatura - portanto, nada muda entre L1 e L2. No entanto, com carteiras de contrato inteligentes, manter um endereço se torna mais difícil. Embora muito trabalho tenha sido feito tentando tornar os endereços um hash de código equivalente em toda a rede, principalmente as fábricas de singleton CREATE2 e ERC-2470, tem sido muito difícil fazer isso perfeitamente. Alguns L2s (como "tipo 4 ZK-EVMs") não são totalmente equivalentes aos EVMs, geralmente usando Solidity ou um assembly intermediário, evitando a equivalência de hash. Mesmo que você pudesse ter equivalência de hash, a possibilidade de carteiras mudarem de propriedade por meio de mudanças de chave tem outras consequências não intuitivas.
A privacidade requer mais endereços por usuário e pode até alterar os tipos de endereços que gerenciamos. Se a proposta de endereço privado for amplamente utilizada, ao invés de apenas alguns endereços por usuário, ou um endereço por L2, pode haver um endereço por transação. Outros esquemas de privacidade, mesmo os já existentes, como o Tornado Cash, alteram a maneira como os ativos são armazenados de 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, o usuário precisa contar com o próprio sistema de endereço interno do esquema de privacidade.
Como vimos, as três mudanças enfraqueceram o modelo mental “um usuário ~= um endereço” de maneiras diferentes, e alguns desses efeitos retroalimentaram a complexidade da implementação das mudanças. Duas complicações específicas são:
Se você deseja pagar alguém, como obtém as informações para pagá-lo?
Se um usuário armazena muitos ativos em lugares diferentes em cadeias diferentes, como ele realiza a substituição de chaves e a recuperação social?
Três transições estão relacionadas a pagamentos on-chain (e identidade)
Tenho moedas no Scroll e quero pagar pelo café (se "eu" está literalmente se referindo a mim como o autor deste artigo, então "café" é obviamente uma metonímia de "chá verde"). Você está me vendendo café, mas só vai receber moedas no Taiko. o que eu faço?
Basicamente existem duas soluções:
A carteira receptora (pode ser um comerciante ou apenas um indivíduo comum) se esforça para oferecer suporte a cada L2, com alguma funcionalidade automática para integrar fundos de forma assíncrona.
O destinatário fornece seu L2 e seu endereço, e a carteira do remetente encaminha automaticamente os fundos para o L2 de destino por meio de algum tipo de sistema de ponte inter-L2.
Obviamente, essas soluções podem ser combinadas: o destinatário fornece a lista L2 que está disposto a aceitar e a carteira do remetente calcula o pagamento, que pode envolver envio direto (se tiver sorte) ou por meio de um caminho em ponte na L2.
Mas esse é apenas um exemplo do principal desafio introduzido pelos três turnos: algo tão simples quanto pagar alguém começa a exigir mais informações do que apenas um endereço de 20 bytes.
Felizmente, a mudança para carteiras de contrato inteligentes não sobrecarregou muito o sistema de endereços, mas ainda existem alguns problemas técnicos que precisam ser resolvidos em outras partes da pilha de aplicativos. As carteiras precisam ser atualizadas para garantir que não estejam apenas enviando 21.000 gás em transações, mas, mais importante, para garantir que o lado de recebimento de pagamentos da carteira não apenas rastreie as transferências de ETH de EOAs, mas também ETH enviado por código de contrato inteligente. Aplicativos que dependem da suposição de propriedade imutável de endereços (por exemplo, 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 - em particular, se alguém aceitar apenas tokens não-ETH ERC20, poderá usar um pagador ERC-4337 para pagar pelo gás com esse token.
Por outro lado, a privacidade novamente apresenta grandes desafios que ainda não resolvemos. O Tornado Cash original não apresentava esses problemas porque não suportava transferências internas: os usuários só podiam depositar no sistema e sacar. Uma vez que você pode fazer transferências internas, os usuários precisam usar o esquema de endereço interno do sistema de privacidade. Na prática, a "mensagem de pagamento" de um usuário precisa conter (i) algum tipo de "chave pública de gasto", uma promessa de um segredo que o destinatário pode usar para gastar e (ii) o remetente envia uma mensagem criptografada que somente o destinatário pode descriptografar uma maneira de ajudar os destinatários a descobrir pagamentos.
O protocolo de endereço de privacidade baseia-se no conceito de meta-endereço, que funciona da seguinte maneira: parte do meta-endereço é uma versão oculta da chave de gastos do remetente e a outra parte é a chave de criptografia do remetente (embora implementações mínimas pode definir isso Ambas as chaves são as mesmas).
![Vitalik: Para alcançar a aterrissagem em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-39bca9184c-dd1a6f-62a40f)
A principal lição aqui é que, em um ecossistema focado na privacidade, os usuários terão chaves públicas de gastos e chaves públicas de criptografia, e as "informações de pagamento" dos usuários terão que conter ambas as chaves. Além de pagar, há outros bons motivos para expandir nessa direção. Por exemplo, se quiséssemos e-mail criptografado no Ethereum, os usuários precisariam fornecer publicamente alguma forma de chave de criptografia. Em um "mundo EOA", poderíamos reutilizar chaves de conta para conseguir isso, mas em um mundo de carteiras de contratos inteligentes seguras, provavelmente deveríamos ter uma funcionalidade mais explícita para conseguir isso. Isso também ajudará a tornar as identidades baseadas em Ethereum mais compatíveis com ecossistemas de privacidade descentralizados não Ethereum, sendo o exemplo mais proeminente as chaves PGP.
Três transformações e recuperação de chaves
Em um mundo onde um usuário pode ter vários endereços, a maneira padrão de implementar mudanças importantes e recuperação social é fazer com que o usuário execute procedimentos de recuperação em cada endereço individualmente. Isso pode ser feito com um clique: as carteiras podem conter software para executar procedimentos de recuperação nos endereços de todos os usuários simultaneamente. No entanto, mesmo com essa simplificação de UX, existem três problemas com a recuperação ingênua de vários endereços:
Resolver esses problemas é difícil. Felizmente, existe uma solução bastante elegante que funciona muito bem: uma arquitetura que separa a lógica de validação da retenção de ativos.
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-25b93e2117-dd1a6f-62a40f)
Cada usuário tem um contrato de keystore que existe em um local (pode ser a rede principal ou um L2 específico). Os usuários então têm endereços em diferentes L2s, onde a lógica de verificação para cada endereço é um ponteiro para o contrato de keystore. Os gastos desses endereços exigirão uma prova no contrato de armazenamento de chave mostrando a chave pública de gasto atual (ou mais realisticamente, a mais recente).
A prova pode ser obtida de várias maneiras:
Leia o acesso L1 somente leitura diretamente em L2. L2 pode ser modificado para dar a eles uma maneira de ler o estado de L1 diretamente. Se o contrato de keystore estiver em L1, isso significará que os contratos em L2 têm acesso "livre" ao keystore.
Filial de Merkel. Ramificações Merkle podem provar estados L1 para L2, ou estados L2 para L1, ou você pode combinar os dois para provar partes de um estado L2 para outro L2. A principal fraqueza das provas Merkle é o alto custo do gás devido ao comprimento da prova: uma prova pode exigir 5 kB, embora isso seja reduzido para menos de 1 kB no futuro graças às árvores Verkle.
ZK-SNARKs. Você pode reduzir os custos de dados usando ZK-SNARKs de ramificações Merkle em vez das próprias ramificações. Técnicas de agregação off-chain (por exemplo, baseadas em EIP-4337) podem ser construídas de forma que um único ZK-SNARK verifique todas as provas de estado cross-chain em um bloco.
Compromisso KZG. O L2, ou esquemas construídos sobre ele, pode introduzir um sistema de endereçamento sequencial que permite que as provas de estado dentro desse sistema tenham apenas 48 bytes de comprimento. Como ZK-SNARKs, um esquema multi-prova pode combinar todas essas provas em uma única prova para cada bloco.
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-a50b6aa1e3-dd1a6f-62a40f)
Se quisermos evitar fazer uma prova para cada transação, podemos implementar uma solução mais leve, só precisamos fazer uma prova cross-L2 ao recuperar. Os gastos de uma conta dependerão de uma chave de gastos cuja chave pública correspondente está armazenada na conta, mas a recuperação exigirá uma transação copiando a chave pública de gastos atual no armazenamento de chaves. Os fundos em um endereço contrafactual são seguros, mesmo que sua chave antiga não seja: "ativar" um endereço contrafactual, transformá-lo em um contrato de trabalho exigirá uma prova cruzada de L2 que replique a chave pública de gastos atual. Este tópico nos fóruns do Safe descreve como uma arquitetura semelhante pode funcionar.
Para adicionar privacidade a tal esquema, precisamos apenas criptografar o ponteiro e, em seguida, fazer todas as provas em ZK-SNARKs:
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-137a30a3c1-dd1a6f-62a40f)
Com mais trabalho (por exemplo, usando este trabalho como ponto de partida), também podemos retirar a maior parte da complexidade dos ZK-SNARKs e fazer um esquema mais simples baseado em KZG.
Esses cenários podem ficar complicados. No entanto, existem muitas sinergias potenciais entre esses programas. Por exemplo, o conceito de "contrato de keystore" também pode ser uma solução para o desafio de "endereço" mencionado na seção anterior: se quisermos que os usuários tenham endereços persistentes que não mudam quando os usuários atualizam suas chaves, é possível colocar metaendereços secretos, chaves de criptografia e outras informações em um contrato de armazenamento de chaves e usar o endereço do contrato de armazenamento de chaves como o "endereço" do usuário.
Muita infraestrutura secundária precisa ser atualizada
Usar o ENS é caro. Hoje, junho de 2023, as coisas não estão tão ruins: as taxas de transação, embora altas, são comparáveis às taxas de domínio ENS. O registro no zuzalu.eth me custou cerca de $ 27, dos quais $ 11 são taxas de transação. Mas se tivermos outro mercado em alta, as taxas vão disparar. Mesmo sem o aumento do preço do ETH, o retorno da taxa de gás para 200 gwei aumentaria a taxa de transação para registro de domínio para US$ 104. Portanto, se quisermos que as pessoas realmente usem o ENS, especialmente para casos de uso como mídia social descentralizada, onde os usuários solicitam registro quase gratuito (as taxas de domínio do ENS não são um problema, pois essas plataformas fornecem subdomínios para seus usuários), precisamos do ENS Runs on L2 .
Felizmente, a equipe do ENS já está em movimento, e o ENS no L2 está realmente acontecendo! O ERC-3668 (também conhecido como "padrão CCIP"), juntamente com o ENSIP-10, fornece um método para validar automaticamente os subdomínios ENS em qualquer L2. O padrão CCIP requer a configuração de um contrato inteligente que descreva um método para verificar provas de dados L2, e nomes de domínio (ecc.eth para Optinames, por exemplo) podem ser colocados sob o controle de tal contrato. Uma vez que o contrato CCIP controla ecc.eth em L1, o acesso a algum subdomínio.ecc.eth envolverá automaticamente encontrar e verificar o estado L2 da prova (por exemplo, filial Merkle) que realmente armazena esse subdomínio específico.
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-b1a43ef2c1-dd1a6f-62a40f)
Na verdade, obter provas envolve acessar uma série de URLs armazenadas no contrato, o que reconhecidamente parece centralização, embora eu argumente que na verdade não é: é um modelo de confiança 1-de-N (provas inválidas seriam bloqueadas pelo CCIP A verificação lógica na função callback do contrato capta que, desde que haja uma URL que retorne uma prova válida, não há problema). Esta lista de URLs pode conter dezenas de URLs.
O trabalho do ENS CCIP é uma história de sucesso e deve ser visto como um sinal de que o tipo de reforma radical de que precisamos é possível. Mas são necessárias mais reformas em nível de aplicativo. Alguns exemplos incluem:
Muitos dapps dependem de usuários para fornecer assinaturas off-chain. Para contas de propriedade externa (EOAs), é fácil. O ERC-1271 fornece uma maneira padronizada para carteiras de contratos inteligentes fazerem isso. No entanto, muitos dapps ainda não suportam ERC-1271; eles precisam apoiá-lo.
Dapps que usam "Is this EOA?" para diferenciar entre usuários e contratos (por exemplo, para impedir transferências ou aplicar royalties) serão interrompidos. Em geral, eu desaconselho tentar encontrar uma solução puramente técnica; a questão de descobrir se uma determinada transferência de controle criptográfico é uma transferência de interesse benéfico é um problema difícil que não pode ser resolvido sem recorrer a alguma comunidade off-chain Mecanismos acionados. Em seguida, resolva. Muito provavelmente, os aplicativos terão que depender menos do bloqueio de transferências e mais de técnicas como o imposto de Harberger.
A forma como as carteiras interagem com os gastos e as chaves de criptografia precisará melhorar. Atualmente, as carteiras normalmente usam assinaturas determinísticas para gerar chaves específicas do aplicativo: um nonce padrão (por exemplo, um hash do nome do aplicativo) é assinado com a chave privada do EOA, gerando um nonce que não pode ser gerado sem a chave privada. de , por isso é tecnicamente seguro. No entanto, essas técnicas são "opacas" para a carteira, impedindo que as carteiras implementem verificações de segurança no nível da interface do usuário. Em um ecossistema mais maduro, assinatura, criptografia e funções relacionadas precisam ser tratadas de forma mais explícita pelas carteiras.
Clientes leves (por exemplo, Helios) terão que verificar L2, não apenas L1. Hoje, os clientes leves se concentram em verificar a validade do cabeçalho L1 (usando o protocolo de sincronização do cliente leve) e validar o estado L1 e as bifurcações Merkle das transações originadas no cabeçalho L1. Amanhã, eles também precisam verificar a comprovação do estado L2 proveniente da raiz do estado armazenado em L1 (essa versão mais avançada, na verdade, olha para a pré-confirmação de L2).
Carteiras precisam proteger ativos e dados
Agora, o negócio da carteira é proteger ativos. Tudo está na cadeia e a única coisa que a carteira precisa proteger são as chaves privadas que atualmente protegem esses ativos. Se você alterar as chaves, poderá publicar com segurança sua chave privada anterior na Internet no dia seguinte. No entanto, em um mundo de provas de conhecimento zero, esse não é mais o caso: as carteiras não estão apenas protegendo as credenciais de autenticação, elas estão protegendo seus dados.
Vimos os primeiros sinais desse mundo com o Zupass, o sistema de identidade baseado em ZK-SNARK usado na Zuzalu. Os usuários possuem uma chave privada, que utilizam para autenticar o sistema, que pode ser utilizada para fazer provas básicas como "provar que sou morador de Zuzalu, mas não revelar qual". No entanto, o sistema Zupass também passou a ter outros aplicativos construídos sobre ele, principalmente Stamps (versão Zupass dos POAPs).
Um dos meus muitos selos Zupass provando que sou um membro orgulhoso do Team Cat.
A principal característica que os selos oferecem sobre os POAPs é que os selos são privados: você mantém os dados localmente e só prova o selo (ou algum cálculo sobre ele) para eles se quiser que eles tenham essas informações sobre você. Mas isso aumenta o risco: se você perder essa informação, perde o carimbo.
Obviamente, o problema de manter dados se resume ao problema de manter uma chave criptográfica: um terceiro (ou mesmo a cadeia) pode manter uma cópia criptografada dos dados. Isso tem a vantagem conveniente de que a ação que você executa não altera a chave de criptografia, portanto, nenhuma interação com o sistema que mantém sua chave de criptografia segura é necessária. Mas mesmo assim, se você perder sua chave de criptografia, perderá tudo. Por outro lado, se alguém vir sua chave de criptografia, poderá ver tudo criptografado com essa chave.
A solução de fato da Zupass é incentivar as pessoas a armazenar suas chaves em vários dispositivos (por exemplo, laptop e telefone), pois as chances de perder todas ao mesmo tempo são pequenas. Podemos dar um passo adiante e usar um compartilhamento secreto para armazenar a chave, dividindo a chave entre vários guardiões.
Essa recuperação social via MPC não é uma solução adequada para carteiras, pois significa que não apenas os tutores atuais, mas também os tutores anteriores podem conspirar para roubar seus ativos, o que é um alto risco inaceitável. No entanto, uma violação de privacidade geralmente é menos arriscada do que uma perda completa de ativos e, se alguém exigir um caso de uso altamente preservador de privacidade, ele pode aceitar um risco maior de perda por não fazer backup das chaves associadas que exigem privacidade. ações de preservação.
Para evitar sobrecarregar os usuários com um sistema complexo de vários caminhos de recuperação, as carteiras que oferecem suporte à recuperação social podem precisar gerenciar a recuperação de ativos e a recuperação da chave de criptografia.
De volta à questão da identidade
Um tema comum dessas mudanças é que o conceito de um "endereço" que você usa na cadeia como um identificador criptográfico que representa "você" precisa mudar radicalmente. "Instruções sobre como interagir comigo" não são mais apenas um endereço ETH; eles devem conter alguma combinação de vários endereços em vários L2s, meta-endereços secretos, chaves de criptografia e outros dados de alguma forma.
Uma maneira de fazer isso é tornar a ENS sua identidade: seu registro ENS pode conter todas essas informações e, se você enviar a alguém bob.eth (ou bob.ecc.eth, ou...), eles poderão descobrir e aprender sobre todas as coisas que pagam e interagem com você, inclusive de formas transversais mais complexas e de preservação da privacidade.
No entanto, essa abordagem centrada no ENS tem dois pontos fracos:
Uma solução possível é colocar mais coisas no contrato de keystore mencionado na arquitetura anteriormente neste post. O contrato de keystore pode conter várias informações sobre você e como você interage com ele (via CCIP, algumas das quais podem ser off-chain), e os usuários podem usar seu contrato de keystore como um identificador primário. Mas os ativos reais que eles recebem serão armazenados em vários lugares diferentes. Os contratos de keystore não estão vinculados a nomes, eles são amigáveis contrafactuais: você pode gerar um endereço que só pode ser inicializado por um contrato de keystore com alguns parâmetros iniciais fixos.
Outra categoria de soluções tem a ver com o abandono do conceito de endereços orientados ao usuário, que é semelhante em espírito ao 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 pode enviar um link de reivindicação (como um URL explícito ou código QR) que o destinatário pode usar Aceitar pagamentos da maneira que desejar.
![Vitalik: Para alcançar a implementação em larga escala, o Ethereum deve passar por três transformações: L2, carteira e privacidade] (https://img.gateio.im/social/moments-69a80767fe-f7c28b44ae-dd1a6f-62a40f)
Seja o remetente ou o destinatário quem age primeiro, confiar mais nas carteiras para gerar diretamente informações de pagamento atualizadas em tempo real reduz o atrito. Dito isto, os identificadores persistentes são convenientes (especialmente com ENS) e, na prática, a suposição de comunicação direta entre o remetente e o destinatário é um problema muito complicado, portanto, podemos considerar uma combinação de diferentes tecnologias.
Em todos esses designs, é fundamental manter as coisas descentralizadas e compreensíveis para os usuários. Precisamos garantir que os usuários possam acessar facilmente a visão mais atualizada de seus ativos atuais, bem como as informações publicadas destinadas a eles. Essas visões devem basear-se em ferramentas abertas em vez de soluções proprietárias. Será necessário muito trabalho para impedir que uma infraestrutura de pagamento mais complexa se torne uma "torre de abstração" opaca para que os desenvolvedores entendam o que está acontecendo e adaptem-se ao novo ambiente. Apesar dos desafios, alcançar a escalabilidade, a segurança da carteira e a privacidade do Ethereum para usuários comuns é fundamental. Não se trata apenas de viabilidade técnica, mas também de acessibilidade real para o usuário comum. Precisamos enfrentar esse desafio.
Agradecimentos especiais a Dan Finlay, Karl Floersch, David Hoffman e às equipes Scroll e SoulWallet por seus comentários, críticas e sugestões.