Autor original: Vitalik Buterin, fundador da Ethereum
Agradecimentos especiais a Dan Finlay, Karl Floersch, David Hoffman e às equipes Scroll e SoulWallet por seus comentários, críticas e sugestões.
À medida que o Ethereum passa de uma tecnologia jovem e experimental para uma pilha de tecnologia madura, capaz de realmente oferecer uma experiência aberta, global e sem permissão para usuários comuns, a pilha precisará passar por três grandes transições tecnológicas aproximadamente simultaneamente:
Transição de expansão L2 - todos se movem para rollups
Transição de segurança de carteira - todos migram para carteiras de contrato inteligentes
Transição de privacidade - Certifique-se de que as transferências de fundos que preservam a privacidade estejam disponíveis e certifique-se de que todos os outros dispositivos em desenvolvimento (recuperação social, identidade, reputação) preservam a privacidade
Triângulo de transição do ecossistema.
Sem o primeiro, o Ethereum falharia, pois cada transação custa $ 3,75 ($ 82,48 se tivermos outra alta) e todo produto voltado para o mercado de massa inevitavelmente esquecerá a cadeia e adotará uma solução centralizada para tudo.
Sem o segundo, o Ethereum teria falhado, pois os usuários relutavam em armazenar seus fundos (e ativos não financeiros) e todos se voltavam para exchanges centralizadas.
Sem um terceiro, o Ethereum falharia porque todas as transações (e POAP, etc.) Uma solução centralizada que oculta seus dados ao máximo.
Essas três transições são críticas pelos motivos descritos acima. Mas eles também são desafiadores, porque abordá-los adequadamente requer uma coordenação estreita. Não é apenas a funcionalidade do protocolo que precisa ser melhorada; em alguns casos, a forma como interagimos com o Ethereum precisa mudar fundamentalmente, exigindo mudanças profundas nos aplicativos e carteiras.
Essas três transições reformularão fundamentalmente o relacionamento entre usuários e endereços
Em um mundo estendido de L2, os usuários existirão em muitos L2s. Você é um membro do ExampleDAO que confia no Otimismo? Então você tem uma conta Otimismo! Você possui CDP no sistema stablecoin no ZkSync? Então você tem uma conta no ZkSync! Você já experimentou alguns dos aplicativos no kakarot? Então você tem uma conta no Kakarot! Longe vão os dias em que um usuário tinha apenas um endereço.
*De acordo com minha visão da Brave Wallet, tenho ETH em quatro lugares. Sim, Arbitrum e Arbitrum Nova são diferentes. Não se preocupe, vai ficar mais confuso com o tempo! *
As carteiras de contratos inteligentes adicionam complexidade e tornam mais difícil ter o mesmo endereço em 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, hashes das chaves públicas usadas para verificar assinaturas - portanto, nada muda entre L1 e L2. No entanto, com carteiras de contrato inteligentes, fica mais difícil reservar um endereço. Embora muito trabalho tenha sido feito para tentar tornar os endereços um hash de código equivalente em todas as redes, principalmente as fábricas de singleton CREATE2 e ERC-2470, tem sido difícil fazer isso funcionar perfeitamente. Alguns L2s (como "Tipo 4 ZK-EVM") não são exatamente equivalentes ao EVM, geralmente Solidity ou assemblies intermediários são usados para evitar a equivalência de hash. Mesmo se 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é mudar os tipos de endereços com os quais estamos lidando. Se a proposta de endereço furtivo for amplamente utilizada, ao invés de apenas alguns endereços por usuário, ou um endereço por L2, os usuários podem ter um endereço por transação. Outros esquemas de privacidade, mesmo os existentes, como o Tornado Cash, mudam a forma 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 precisará contar com o próprio sistema de endereçamento interno do esquema de privacidade.
Como vimos, cada uma dessas três transições enfraquece o modelo mental "um usuário ~= um endereço" de maneiras diferentes, com alguns desses efeitos realimentando a complexidade da implementação da transição. Dois pontos de complicação especiais são:
Se você quisesse pagar a alguém, como obteria informações sobre como pagá-lo?
Se um usuário tem muitos ativos em cadeias armazenados em lugares diferentes, como eles realizam mudanças importantes e recuperação social?
Três transições e pagamentos on-chain (e identidades)
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ó pode receber moedas no Taiko. o que fazer
Basicamente existem duas soluções:
A carteira receptora (que pode ser um comerciante ou um indivíduo comum) trabalha muito para oferecer suporte a cada L2, com alguma automação para integrar fundos de forma assíncrona.
O beneficiá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 sistema de ponte inter-L2.
Claro, essas soluções podem ser combinadas: o destinatário fornece uma lista de L2s que está disposto a aceitar e a carteira do remetente calcula o pagamento, que pode envolver um envio direto ou um caminho em ponte através do L2, se tiver sorte.
Mas este é apenas um exemplo de um desafio importante que essas três transições apresentam: operações simples como pagar alguém começam a exigir mais informações do que apenas um endereço de 20 bytes.
Felizmente, a transição para carteiras de contrato inteligentes não sobrecarregará o sistema de endereçamento, mas ainda há alguns problemas técnicos a serem resolvidos em outras partes da pilha de aplicativos. As carteiras precisarão ser atualizadas para garantir que não enviem apenas 21.000 gás com a transação, e é mais importante garantir que o recebimento do pagamento da carteira não apenas rastreie a transferência de ETH do EOA, mas também rastreie o ETH enviado pelo 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 aplicar taxas de royalties) terão que encontrar outras maneiras de atingir seus objetivos. As carteiras de contratos inteligentes também facilitarão as coisas - principalmente, se alguém receber apenas um token ERC20 não ETH, poderá usar esse token para pagar pelo gás usando os paymasters ERC-4337.
A privacidade, por outro lado, representa novamente um grande desafio que ainda não enfrentamos. O Tornado Cash original não apresentava nenhum desses problemas porque não suportava transferências internas: os usuários só podiam depositar no sistema e sacar dele. No entanto, uma vez que as transferências internas sejam possíveis, os usuários precisarão usar o esquema de endereçamento 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 possa usar para gastar e (ii) alguma forma de o remetente enviar a criptomoeda apenas informações que o beneficiário pode decifrar para ajudar o beneficiário a descobrir o pagamento.
O protocolo de endereço furtivo 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 possam definir tanto chaves são as mesmas).
Diagrama esquemático de um esquema abstrato de endereço furtivo baseado em criptografia e ZK-SNARKs.
Uma lição importante aqui é que, em um ecossistema favorável à privacidade, os usuários terão chaves públicas de consumo e chaves públicas de criptografia, e as "informações de pagamento" do usuário devem incluir ambas as chaves. Além dos pagamentos, há bons motivos para expandir nessa direção. Por exemplo, se quisermos emails criptografados baseados em Ethereum, os usuários precisarão fornecer publicamente algum tipo de chave de criptografia. No "mundo EOA", poderíamos reutilizar as chaves de conta para isso, mas no mundo das carteiras de contratos inteligentes seguras, provavelmente deveríamos fornecer uma função mais explícita para isso. Isso também ajuda a tornar as identidades baseadas em Ethereum mais compatíveis com ecossistemas de privacidade descentralizados não Ethereum, especialmente chaves PGP.
Três transições e recuperação de chaves
A maneira padrão de implementar mudanças críticas e recuperação social em um mundo onde cada usuário tem vários endereços é simplesmente fazer com que o usuário execute o processo de recuperação em cada endereço separadamente. Isso pode ser feito com um clique: as carteiras podem conter software que pode executar procedimentos de recuperação em todos os endereços de um usuário simultaneamente. No entanto, mesmo com essa simplificação da experiência do usuário, existem três problemas com a recuperação simples de vários endereços:
O custo do gás é impraticável: este é auto-explicativo.
Endereços contrafactuais: endereços que o contrato inteligente ainda não emitiu (na verdade, isso significa contas das quais você ainda não enviou fundos). Como usuário, você pode ter um número infinito de endereços contrafactuais: um ou mais endereços em cada L2, incluindo L2s que ainda não existem, e outro conjunto infinito de endereços contrafactuais resultantes do esquema de endereços furtivos.
Privacidade: Se um usuário tiver intencionalmente vários endereços para evitar vinculá-los uns aos outros, certamente não deseja vinculá-los publicamente restaurando-os ao mesmo tempo ou mais ou menos!
Resolver esses problemas é difícil. Felizmente, existe uma solução elegante que funciona razoavelmente bem: uma arquitetura que separa a lógica de validação da retenção de ativos.
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 validação para cada endereço é um ponteiro para o contrato de keystore. Os gastos desses endereços exigem prova de entrada no contrato de armazenamento de chave mostrando a chave pública de gasto atual (ou, mais realisticamente, mais recente).
A prova pode ser obtida de várias maneiras:
Acesso L1 direto somente leitura em L2. L2 pode ser modificado para ler o estado L1 diretamente. Se o contrato de keystore estiver em L1, isso significa que os contratos dentro de L2 têm acesso "livre" ao keystore
Filial de Merkel. As ramificações Merkle podem atestar o estado L1 para L2 ou o estado L2 para L1, ou você pode combinar os dois para atestar o estado parcial de um 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, mas isso será reduzido para < 1 kB no futuro graças às árvores Verkle.
ZK-SNARKs. Você pode reduzir os custos de dados usando forks ZK-SNARKs de Merkle em vez dos próprios forks. Técnicas de agregação fora da cadeia podem ser construídas (por exemplo, no topo do EIP-4337) para que um ZK-SNARK verifique todas as provas de estado da cadeia cruzada em um bloco.
Promessa KZG. L2, ou esquemas construídos sobre eles, podem introduzir um sistema de endereçamento sequencial, permitindo que as provas de estado dentro desse sistema tenham apenas 48 bytes de comprimento. Como ZK-SNARKs, vários esquemas de prova podem combinar todas essas provas em uma única prova para cada bloco.
Se quisermos evitar fazer uma prova para cada transação, podemos implementar um esquema mais leve que requer apenas uma prova cross-L2 para 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 para copiar a chave pública de gastos atual no armazenamento de chaves. Fundos em endereços contrafactuais são seguros, mesmo que suas chaves antigas não sejam: "ativar" um endereço contrafactual para transformá-lo em um contrato de trabalho requer uma prova L2 cruzada para duplicar a chave de gastos_pub atual. Este tópico nos fóruns do Safe descreve como uma arquitetura semelhante funciona.
Para adicionar privacidade a tal esquema, simplesmente criptografamos este ponteiro, e então fazemos todas as provas em ZK-SNARKs:
Com mais trabalho (por exemplo, usando este trabalho como ponto de partida), também podemos remover a maior parte da complexidade dos ZK-SNARKs e fazer um esquema mais simples baseado em KZG.
Esses cenários podem ficar complicados. No lado positivo, existem muitas sinergias potenciais entre eles. Por exemplo, o conceito de "contratos de keystore" também pode resolver o desafio de "endereço" mencionado na seção anterior: se quisermos que os usuários tenham endereços permanentes que não mudem toda vez que o usuário rechavear, podemos colocar os metaendereços ocultos , as chaves de criptografia e outras informações são colocadas no contrato de armazenamento de chaves e o endereço do contrato de armazenamento de chaves é usado como o "endereço" do usuário.
Muita infraestrutura secundária precisa ser atualizada
Usar o ENS é caro. Hoje, em junho de 2023, as coisas não estão tão ruins: as taxas de transação são altas, mas ainda comparáveis às taxas de domínio ENS. O registro no zuzalu.eth me custou cerca de $ 27, dos quais $ 11 foram 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, mover as taxas de gás de volta para 200 gwei aumentaria a taxa de tx para registros 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, em que os usuários exigem registro quase gratuito (e as taxas de domínio do ENS não são um problema, pois essas plataformas fornecem subdomínios aos usuários), precisamos do ENS em L2 para funcionar .
Felizmente, a equipe do ENS se intensificou e o ENS no L2 está acontecendo! O ERC-3668 (também conhecido como "padrão CCIP"), juntamente com o ENSIP-10, fornece uma maneira de tornar os subdomínios ENS em qualquer L2 automaticamente verificáveis. O padrão CCIP requer a criação de um contrato inteligente que descreva um método de verificação de provas de dados L2 e que os domínios (por exemplo, Optinames use ecc.eth) possam ser colocados sob o controle de tal contrato. Assim que o contrato CCIP assumir o controle de ecc.eth em L1, o acesso a algum subdomínio.ecc.eth envolverá automaticamente encontrar e verificar a prova de estado (por exemplo, ramificação Merkle) em L2, onde esse subdomínio específico está realmente armazenado.
Na verdade, obter as provas envolve uma lista de URLs armazenadas no contrato, o que com certeza parece centralizado, mas acho que não é: é 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 , desde que um dos URLs retorne uma prova válida, tudo bem). A lista de URLs pode conter dezenas.
O esforço 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 é realmente possível. Mas ainda há muitas reformas na camada de aplicação que precisam ser feitas. Alguns exemplos:
Muitos dapps dependem de usuários para fornecer assinaturas off-chain. Com uma conta de propriedade externa (EOA), é 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 precisarão.
Dapps que usam "Is this EOA?" para diferenciar usuários e contratos (por exemplo, impedir transferências ou impor taxas de royalties) serão interrompidos. Em geral, eu aconselharia não procurar soluções puramente técnicas aqui; descobrir se uma determinada transferência de controle criptográfico é uma transferência de propriedade efetiva é um problema difícil que não pode ser resolvido sem abordar alguns mecanismos orientados pela comunidade fora da cadeia. Muito provavelmente, os aplicativos terão que depender menos da prevenção de desvios e mais de técnicas como os impostos de Harberger.
Deve melhorar a forma como as carteiras interagem com os gastos e as chaves de criptografia. Atualmente, as carteiras normalmente usam assinaturas determinísticas para gerar chaves específicas do aplicativo: assinar um nonce padrão (como um hash do nome do aplicativo) com a chave privada do EOA gera um valor determinístico que não pode ser gerado sem a chave privada, portanto, é seguro num sentido puramente técnico. No entanto, essas técnicas são "opacas" para as carteiras, impedindo que as carteiras implementem verificações de segurança no nível da interface do usuário. Em ecossistemas mais maduros, assinatura, criptografia e funções relacionadas terão que ser tratadas de forma mais explícita pelas carteiras.
Clientes leves (como Helios) terão que autenticar L2 e não apenas L1. Hoje, os clientes leves concentram-se na verificação da validade dos cabeçalhos L1 (usando o protocolo de sincronização do cliente leve) e na verificação dos garfos Merkle do estado L1 e das transações enraizadas nos cabeçalhos L1. Amanhã, eles também precisam verificar a prova do estado L2, que está enraizada na raiz do estado armazenada em L1 (a versão mais avançada realmente analisa a pré-confirmação do L2).
As carteiras precisarão proteger ativos e dados
Hoje, as carteiras estão no negócio de 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 sua chave, poderá publicar com segurança sua chave privada anterior na Internet no dia seguinte. No entanto, no mundo ZK, isso não é mais verdade: a carteira não apenas protege as credenciais de autenticação, mas também armazena seus dados.
Vimos os primeiros sinais desse mundo com Zupass, o sistema de identidade baseado em ZK-SNARK usado por Zuzalu. O usuário possui uma chave privada para autenticação no sistema, que pode ser utilizada para fazer provas básicas como "provar que sou morador de Zuzalu sem revelar qual". Mas o sistema Zupass também começou a construir outros aplicativos em cima dele, principalmente o stamp (versão Zupass do POAP).
Um dos meus muitos selos Zupass confirmando que sou um membro orgulhoso do Team Cat.
A principal característica que os selos oferecem em comparação com o POAP é que os selos são privados: você mantém os dados localmente e, se quiser que alguém tenha informações sobre você, basta provar um selo (ou algum cálculo sobre um selo) para alguém. Mas isso aumenta o risco: se você perder essa informação, perde o carimbo.
Obviamente, o problema de manter os dados pode ser reduzido ao problema de manter uma única chave de criptografia: algum terceiro (ou mesmo 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 prática da Zupass é incentivar as pessoas a armazenar suas chaves em vários dispositivos (como um laptop e um telefone), pois as chances de perder o acesso a todos eles ao mesmo tempo são pequenas. Podemos dar um passo adiante e usar um compartilhamento secreto para armazenar as chaves, distribuídas 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 risco inaceitavelmente alto. Mas o risco de uma violação de privacidade geralmente é menor do que o risco total de perda de ativos, e as pessoas com casos de uso de alta privacidade sempre podem aceitar um risco maior de perda por não fazer backup das chaves associadas a essas operações que exigem privacidade.
Para evitar que os usuários sejam sobrecarregados por sistemas bizantinos com 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 à identidade
Uma das coisas que essas mudanças têm em comum é que o conceito de "endereço", o identificador criptográfico que você usa para representar "você" na cadeia, precisa mudar fundamentalmente. "Instruções sobre como interagir comigo" não serão mais apenas um endereço ETH; eles devem ser uma combinação de vários endereços em vários L2s, meta-endereços furtivos, chaves de criptografia e outros dados de alguma forma.
Uma maneira é tornar o ENS sua identidade: seu registro ENS pode conter apenas todas essas informações e, se você enviar a alguém bob.eth (ou bob.ecc.eth, ou...), eles poderão procurar e ver tudo sobre como ele paga e interage com você, incluindo métodos mais complexos entre domínios e preservação da privacidade.
Mas essa abordagem centrada no ENS tem dois pontos fracos:
Ele associa muitas coisas ao seu nome de domínio. Seu nome de domínio não é você, seu nome de domínio é um dos muitos atributos de você. Deve ser possível alterar seu nome de domínio sem mover todo o seu perfil de identidade e atualizar um monte de registros em muitos aplicativos.
Você não pode ter milho contrafactual não confiável. 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: interagir com a cadeia exige o pagamento de taxas de transação, o que requer... já ter moedas. Endereços ETH, incluindo endereços de contrato inteligente com CREATE2, têm essa funcionalidade. Os nomes 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 conteúdo no contrato de keystore mencionado na arquitetura anteriormente neste artigo. O contrato de keystore pode conter todos os tipos de informações sobre você e como você interage com ele (para CCIP, algumas dessas informações podem estar fora da cadeia) e os usuários usarão seu contrato de keystore como seu identificador principal. Mas os ativos reais que eles recebem serão armazenados em vários lugares diferentes. Os contratos de keystore são independentes de nome e são amigáveis contrafactuais: você pode gerar um endereço que pode ser provado ser inicializado apenas por um contrato de keystore com alguns parâmetros iniciais fixos.
Outro tipo de solução é semelhante ao protocolo de pagamento Bitcoin, abandonando completamente o conceito de endereços orientados ao usuário. 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 para seguir sua disposição de aceitar o pagamento.
Independentemente de o remetente ou o destinatário se mover primeiro, confiar mais nas carteiras para gerar diretamente informações de pagamento atualizadas em tempo real reduz o atrito. Dito isso, identificadores persistentes são convenientes (especialmente com ENS), enquanto a suposição de comunicação direta entre remetente e destinatário é muito complicada na prática, então podemos acabar vendo uma combinação de diferentes tecnologias.
Em todos esses projetos, tornar as coisas discretas e fáceis para os usuários entenderem é o mais importante. Precisamos garantir que os usuários tenham acesso fácil à visão mais recente de quais são seus ativos atuais e quais notícias são publicadas para eles. Essas perspectivas devem se basear em ferramentas abertas, não em soluções proprietárias. Impedir que uma infraestrutura de pagamento mais complexa se torne uma "torre de abstração" opaca, onde os desenvolvedores têm dificuldade em entender o que está acontecendo e adaptá-la ao novo ambiente exigirá muito trabalho. Apesar dos desafios, alcançar escalabilidade, segurança de carteira e privacidade para usuários comuns é fundamental para o futuro do Ethereum. Não se trata apenas de viabilidade técnica, mas também de acessibilidade real para o usuário médio. Precisamos estar à altura desse desafio.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Vitalik Buterin: as três transições técnicas do Ethereum
Autor original: Vitalik Buterin, fundador da Ethereum
Agradecimentos especiais a Dan Finlay, Karl Floersch, David Hoffman e às equipes Scroll e SoulWallet por seus comentários, críticas e sugestões.
À medida que o Ethereum passa de uma tecnologia jovem e experimental para uma pilha de tecnologia madura, capaz de realmente oferecer uma experiência aberta, global e sem permissão para usuários comuns, a pilha precisará passar por três grandes transições tecnológicas aproximadamente simultaneamente:
Sem o primeiro, o Ethereum falharia, pois cada transação custa $ 3,75 ($ 82,48 se tivermos outra alta) e todo produto voltado para o mercado de massa inevitavelmente esquecerá a cadeia e adotará uma solução centralizada para tudo.
Sem o segundo, o Ethereum teria falhado, pois os usuários relutavam em armazenar seus fundos (e ativos não financeiros) e todos se voltavam para exchanges centralizadas.
Sem um terceiro, o Ethereum falharia porque todas as transações (e POAP, etc.) Uma solução centralizada que oculta seus dados ao máximo.
Essas três transições são críticas pelos motivos descritos acima. Mas eles também são desafiadores, porque abordá-los adequadamente requer uma coordenação estreita. Não é apenas a funcionalidade do protocolo que precisa ser melhorada; em alguns casos, a forma como interagimos com o Ethereum precisa mudar fundamentalmente, exigindo mudanças profundas nos aplicativos e carteiras.
Essas três transições reformularão fundamentalmente o relacionamento entre usuários e endereços
Em um mundo estendido de L2, os usuários existirão em muitos L2s. Você é um membro do ExampleDAO que confia no Otimismo? Então você tem uma conta Otimismo! Você possui CDP no sistema stablecoin no ZkSync? Então você tem uma conta no ZkSync! Você já experimentou alguns dos aplicativos no kakarot? Então você tem uma conta no Kakarot! Longe vão os dias em que um usuário tinha apenas um endereço.
As carteiras de contratos inteligentes adicionam complexidade e tornam mais difícil ter o mesmo endereço em 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, hashes das chaves públicas usadas para verificar assinaturas - portanto, nada muda entre L1 e L2. No entanto, com carteiras de contrato inteligentes, fica mais difícil reservar um endereço. Embora muito trabalho tenha sido feito para tentar tornar os endereços um hash de código equivalente em todas as redes, principalmente as fábricas de singleton CREATE2 e ERC-2470, tem sido difícil fazer isso funcionar perfeitamente. Alguns L2s (como "Tipo 4 ZK-EVM") não são exatamente equivalentes ao EVM, geralmente Solidity ou assemblies intermediários são usados para evitar a equivalência de hash. Mesmo se 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é mudar os tipos de endereços com os quais estamos lidando. Se a proposta de endereço furtivo for amplamente utilizada, ao invés de apenas alguns endereços por usuário, ou um endereço por L2, os usuários podem ter um endereço por transação. Outros esquemas de privacidade, mesmo os existentes, como o Tornado Cash, mudam a forma 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 precisará contar com o próprio sistema de endereçamento interno do esquema de privacidade.
Como vimos, cada uma dessas três transições enfraquece o modelo mental "um usuário ~= um endereço" de maneiras diferentes, com alguns desses efeitos realimentando a complexidade da implementação da transição. Dois pontos de complicação especiais são:
Se você quisesse pagar a alguém, como obteria informações sobre como pagá-lo?
Se um usuário tem muitos ativos em cadeias armazenados em lugares diferentes, como eles realizam mudanças importantes e recuperação social?
Três transições e pagamentos on-chain (e identidades)
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ó pode receber moedas no Taiko. o que fazer
Basicamente existem duas soluções:
Claro, essas soluções podem ser combinadas: o destinatário fornece uma lista de L2s que está disposto a aceitar e a carteira do remetente calcula o pagamento, que pode envolver um envio direto ou um caminho em ponte através do L2, se tiver sorte.
Mas este é apenas um exemplo de um desafio importante que essas três transições apresentam: operações simples como pagar alguém começam a exigir mais informações do que apenas um endereço de 20 bytes.
Felizmente, a transição para carteiras de contrato inteligentes não sobrecarregará o sistema de endereçamento, mas ainda há alguns problemas técnicos a serem resolvidos em outras partes da pilha de aplicativos. As carteiras precisarão ser atualizadas para garantir que não enviem apenas 21.000 gás com a transação, e é mais importante garantir que o recebimento do pagamento da carteira não apenas rastreie a transferência de ETH do EOA, mas também rastreie o ETH enviado pelo 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 aplicar taxas de royalties) terão que encontrar outras maneiras de atingir seus objetivos. As carteiras de contratos inteligentes também facilitarão as coisas - principalmente, se alguém receber apenas um token ERC20 não ETH, poderá usar esse token para pagar pelo gás usando os paymasters ERC-4337.
A privacidade, por outro lado, representa novamente um grande desafio que ainda não enfrentamos. O Tornado Cash original não apresentava nenhum desses problemas porque não suportava transferências internas: os usuários só podiam depositar no sistema e sacar dele. No entanto, uma vez que as transferências internas sejam possíveis, os usuários precisarão usar o esquema de endereçamento 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 possa usar para gastar e (ii) alguma forma de o remetente enviar a criptomoeda apenas informações que o beneficiário pode decifrar para ajudar o beneficiário a descobrir o pagamento.
O protocolo de endereço furtivo 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 possam definir tanto chaves são as mesmas).
Uma lição importante aqui é que, em um ecossistema favorável à privacidade, os usuários terão chaves públicas de consumo e chaves públicas de criptografia, e as "informações de pagamento" do usuário devem incluir ambas as chaves. Além dos pagamentos, há bons motivos para expandir nessa direção. Por exemplo, se quisermos emails criptografados baseados em Ethereum, os usuários precisarão fornecer publicamente algum tipo de chave de criptografia. No "mundo EOA", poderíamos reutilizar as chaves de conta para isso, mas no mundo das carteiras de contratos inteligentes seguras, provavelmente deveríamos fornecer uma função mais explícita para isso. Isso também ajuda a tornar as identidades baseadas em Ethereum mais compatíveis com ecossistemas de privacidade descentralizados não Ethereum, especialmente chaves PGP.
Três transições e recuperação de chaves
A maneira padrão de implementar mudanças críticas e recuperação social em um mundo onde cada usuário tem vários endereços é simplesmente fazer com que o usuário execute o processo de recuperação em cada endereço separadamente. Isso pode ser feito com um clique: as carteiras podem conter software que pode executar procedimentos de recuperação em todos os endereços de um usuário simultaneamente. No entanto, mesmo com essa simplificação da experiência do usuário, existem três problemas com a recuperação simples de vários endereços:
Resolver esses problemas é difícil. Felizmente, existe uma solução elegante que funciona razoavelmente bem: uma arquitetura que separa a lógica de validação da retenção de ativos.
A prova pode ser obtida de várias maneiras:
Para adicionar privacidade a tal esquema, simplesmente criptografamos este ponteiro, e então fazemos todas as provas em ZK-SNARKs:
Esses cenários podem ficar complicados. No lado positivo, existem muitas sinergias potenciais entre eles. Por exemplo, o conceito de "contratos de keystore" também pode resolver o desafio de "endereço" mencionado na seção anterior: se quisermos que os usuários tenham endereços permanentes que não mudem toda vez que o usuário rechavear, podemos colocar os metaendereços ocultos , as chaves de criptografia e outras informações são colocadas no contrato de armazenamento de chaves e o endereço do contrato de armazenamento de chaves é usado como o "endereço" do usuário.
Muita infraestrutura secundária precisa ser atualizada
Usar o ENS é caro. Hoje, em junho de 2023, as coisas não estão tão ruins: as taxas de transação são altas, mas ainda comparáveis às taxas de domínio ENS. O registro no zuzalu.eth me custou cerca de $ 27, dos quais $ 11 foram 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, mover as taxas de gás de volta para 200 gwei aumentaria a taxa de tx para registros 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, em que os usuários exigem registro quase gratuito (e as taxas de domínio do ENS não são um problema, pois essas plataformas fornecem subdomínios aos usuários), precisamos do ENS em L2 para funcionar .
Felizmente, a equipe do ENS se intensificou e o ENS no L2 está acontecendo! O ERC-3668 (também conhecido como "padrão CCIP"), juntamente com o ENSIP-10, fornece uma maneira de tornar os subdomínios ENS em qualquer L2 automaticamente verificáveis. O padrão CCIP requer a criação de um contrato inteligente que descreva um método de verificação de provas de dados L2 e que os domínios (por exemplo, Optinames use ecc.eth) possam ser colocados sob o controle de tal contrato. Assim que o contrato CCIP assumir o controle de ecc.eth em L1, o acesso a algum subdomínio.ecc.eth envolverá automaticamente encontrar e verificar a prova de estado (por exemplo, ramificação Merkle) em L2, onde esse subdomínio específico está realmente armazenado.
O esforço 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 é realmente possível. Mas ainda há muitas reformas na camada de aplicação que precisam ser feitas. Alguns exemplos:
As carteiras precisarão proteger ativos e dados
Hoje, as carteiras estão no negócio de 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 sua chave, poderá publicar com segurança sua chave privada anterior na Internet no dia seguinte. No entanto, no mundo ZK, isso não é mais verdade: a carteira não apenas protege as credenciais de autenticação, mas também armazena seus dados.
Vimos os primeiros sinais desse mundo com Zupass, o sistema de identidade baseado em ZK-SNARK usado por Zuzalu. O usuário possui uma chave privada para autenticação no sistema, que pode ser utilizada para fazer provas básicas como "provar que sou morador de Zuzalu sem revelar qual". Mas o sistema Zupass também começou a construir outros aplicativos em cima dele, principalmente o stamp (versão Zupass do POAP).
A principal característica que os selos oferecem em comparação com o POAP é que os selos são privados: você mantém os dados localmente e, se quiser que alguém tenha informações sobre você, basta provar um selo (ou algum cálculo sobre um selo) para alguém. Mas isso aumenta o risco: se você perder essa informação, perde o carimbo.
Obviamente, o problema de manter os dados pode ser reduzido ao problema de manter uma única chave de criptografia: algum terceiro (ou mesmo 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 prática da Zupass é incentivar as pessoas a armazenar suas chaves em vários dispositivos (como um laptop e um telefone), pois as chances de perder o acesso a todos eles ao mesmo tempo são pequenas. Podemos dar um passo adiante e usar um compartilhamento secreto para armazenar as chaves, distribuídas 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 risco inaceitavelmente alto. Mas o risco de uma violação de privacidade geralmente é menor do que o risco total de perda de ativos, e as pessoas com casos de uso de alta privacidade sempre podem aceitar um risco maior de perda por não fazer backup das chaves associadas a essas operações que exigem privacidade.
Para evitar que os usuários sejam sobrecarregados por sistemas bizantinos com 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 à identidade
Uma das coisas que essas mudanças têm em comum é que o conceito de "endereço", o identificador criptográfico que você usa para representar "você" na cadeia, precisa mudar fundamentalmente. "Instruções sobre como interagir comigo" não serão mais apenas um endereço ETH; eles devem ser uma combinação de vários endereços em vários L2s, meta-endereços furtivos, chaves de criptografia e outros dados de alguma forma.
Uma maneira é tornar o ENS sua identidade: seu registro ENS pode conter apenas todas essas informações e, se você enviar a alguém bob.eth (ou bob.ecc.eth, ou...), eles poderão procurar e ver tudo sobre como ele paga e interage com você, incluindo métodos mais complexos entre domínios e preservação da privacidade.
Mas essa abordagem centrada no ENS tem dois pontos fracos:
Uma solução possível é colocar mais conteúdo no contrato de keystore mencionado na arquitetura anteriormente neste artigo. O contrato de keystore pode conter todos os tipos de informações sobre você e como você interage com ele (para CCIP, algumas dessas informações podem estar fora da cadeia) e os usuários usarão seu contrato de keystore como seu identificador principal. Mas os ativos reais que eles recebem serão armazenados em vários lugares diferentes. Os contratos de keystore são independentes de nome e são amigáveis contrafactuais: você pode gerar um endereço que pode ser provado ser inicializado apenas por um contrato de keystore com alguns parâmetros iniciais fixos.
Outro tipo de solução é semelhante ao protocolo de pagamento Bitcoin, abandonando completamente o conceito de endereços orientados ao usuário. 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 para seguir sua disposição de aceitar o pagamento.
Em todos esses projetos, tornar as coisas discretas e fáceis para os usuários entenderem é o mais importante. Precisamos garantir que os usuários tenham acesso fácil à visão mais recente de quais são seus ativos atuais e quais notícias são publicadas para eles. Essas perspectivas devem se basear em ferramentas abertas, não em soluções proprietárias. Impedir que uma infraestrutura de pagamento mais complexa se torne uma "torre de abstração" opaca, onde os desenvolvedores têm dificuldade em entender o que está acontecendo e adaptá-la ao novo ambiente exigirá muito trabalho. Apesar dos desafios, alcançar escalabilidade, segurança de carteira e privacidade para usuários comuns é fundamental para o futuro do Ethereum. Não se trata apenas de viabilidade técnica, mas também de acessibilidade real para o usuário médio. Precisamos estar à altura desse desafio.