Autor: Vitalik, fundador da Ethereum; Tradução: Jinse Finance cryptonaitive
À medida que o Ethereum evolui de uma tecnologia jovem e experimental para uma pilha de tecnologia madura capaz de oferecer uma experiência aberta, global e sem permissão para usuários comuns, existem três grandes transições tecnológicas que precisam acontecer simultaneamente:
A primeira é a transformação da expansão da capacidade L2 - todos se voltam para a tecnologia Rollup;
O segundo é a Transformação da segurança da carteira - Todos começam a usar carteiras de contrato inteligentes;
A terceira é a transformação da privacidade - garantir que a funcionalidade de transferência de fundos para preservação da privacidade esteja disponível e garantir que todas as outras ferramentas desenvolvidas (recuperação social, verificação de identidade, reputação, etc.) tenham recursos para preservação da privacidade.
Triângulo de Transformação do Ecossistema Ethereum. Você só pode escolher todos os três. *
Sem o primeiro item, o Ethereum falhará porque cada transação custa $ 3,75 ($ 82,48 se passarmos por outra corrida de touros), e todo produto do mercado de massa inevitavelmente abandonará o comércio on-chain e adotará uma solução centralizada.
Sem o segundo item, o Ethereum falharia, pois os usuários relutariam em armazenar seus fundos (e ativos não financeiros) e todos recorreriam a trocas centralizadas.
Sem o terceiro item, o Ethereum falharia porque, para muitos usuários, todas as transações (e POAP etc) seriam publicamente visíveis, o sacrifício da privacidade seria muito grande e todos recorreriam a pelo menos algum nível de dados ocultos Solução centralizada.
Pelas razões descritas acima, essas três transições são críticas. Mas também são desafiadores devido à complexidade da coordenação envolvida. Não é apenas a funcionalidade do protocolo que precisa ser melhorada; em alguns casos, a forma como interagimos com o Ethereum precisa mudar fundamental e profundamente, exigindo grandes mudanças nos aplicativos e carteiras.
Essas três transformações irão remodelar fundamentalmente a relação entre usuários e endereços
Em um mundo de escala L2, os usuários existirão em várias redes L2. Você é um membro do ExampleDAO? ExampleDAO está no Otimismo. Então você tem uma conta na Optimism! Você possui um CDP de um sistema stablecoin no ZkSync? Então você tem uma conta no ZkSync! Você já experimentou alguns dos aplicativos localizados no Kakarot? Então você tem uma conta no Kakarot! Foi-se o tempo em que os usuários tinham apenas um endereço.
*Minha visão da carteira Brave, tenho Ethereum em quatro lugares. Sim, Arbitrum e Arbitrum Nova são diferentes. Não se preocupe, as coisas vão ficar mais complicadas com o tempo! *
**Carteiras de contrato inteligentes adicionam mais complexidade, pois torna mais difícil ter o mesmo endereço em L1 e várias redes L2. **A maioria dos usuários hoje usa 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, manter um endereço torna-se mais difícil ao usar uma carteira de contrato inteligente. Embora muito trabalho tenha sido feito para tentar tornar os endereços um hash de código equivalente em diferentes redes, sendo o mais importante CREATE2 e a fábrica singleton ERC-2470, é difícil conseguir isso perfeitamente. Algumas redes L2 (por exemplo, "ZK-EVM do quarto tipo") não são exatamente equivalentes a EVMs, geralmente usando Solidity ou linguagem assembly intermediária em vez de equivalentes de hash. Mesmo que a equivalência de hash pudesse ser alcançada, a possibilidade de carteiras mudarem de propriedade por meio de mudanças de chave leva a outras consequências menos previsíveis.
**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 furtivo for amplamente utilizada, os usuários podem ter um endereço por transação em vez de apenas alguns endereços por usuário ou um endereço por rede L2. Outros esquemas de privacidade, mesmo os já existentes, como o Tornado Cash, mudam a maneira como os ativos são armazenados de maneiras diferentes: 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, essas três transformações enfraquecem o modelo mental "um usuário ≈ um endereço" de maneiras diferentes, algumas das quais, por sua vez, aumentam a complexidade da execução dessas transformações. Duas das questões particularmente complexas são:
**1. Se você quiser pagar alguém, como obterá as informações de pagamento? **
**2. Se os usuários armazenam ativos em diferentes locais em diferentes cadeias, como eles realizam mudanças importantes e recuperação social? **
Essas três transições e pagamentos on-chain (e identidade)
Eu mantenho tokens no Scroll e quero usá-los para comprar café (se o "eu" literal se refere a Vitalik, o autor deste artigo, então "café" significa "chá verde"). Você vende café no Taiko, mas só aceita tokens no Taiko. o que fazer?
Basicamente existem duas soluções:
A carteira receptora (que pode ser um comerciante ou um indivíduo comum) se esforça para oferecer suporte a cada L2 e possui algumas funções assíncronas de fusão de fundos.
O beneficiário fornece suas informações de L2 ao lado do 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 entre L2.
Claro, essas soluções podem ser usadas em combinação: o beneficiário fornece a lista L2 que está disposto a aceitar e a carteira do remetente determina o método de pagamento, que pode ser enviado diretamente (com sorte) ou pago por meio de uma ponte entre o L2.
Mas este é apenas um exemplo de um desafio importante introduzido pelas três transformações: Comportamentos de pagamento simples começam a exigir mais informações do que apenas um endereço de 20 bytes.
Felizmente, mudar para carteiras de contrato inteligentes não é um grande fardo para o sistema de endereços, mas ainda há 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 ao enviar transações, mas é preciso prestar mais atenção para garantir que o destinatário da carteira rastreie não apenas as transferências de ETH do EOA, mas também as transferências de ETH do código de contrato inteligente. Aplicativos que dependem 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, especialmente se alguém aceitar apenas tokens não-ETH ERC20, eles poderão usar um paymaster ERC-4337 para pagar pelo gás usando esse token.
Por outro lado, a questão da privacidade é novamente um grande desafio 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 e sacar dinheiro no sistema. 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" do usuário precisará conter (i) algum tipo de "chave pública de gasto", um compromisso secreto que o destinatário pode usar para gastar e (ii) o remetente pode enviar mensagens criptografadas que somente o destinatário pode descriptografar O destinatário da ajuda descobre o método de pagamento.
O protocolo de endereço Stealth baseia-se no conceito de um meta-endereço, que funciona da seguinte forma: parte do meta-endereço é a chave de gastos do remetente e a outra parte é a chave criptografada do remetente (embora uma implementação mínima possa definir ambas as chaves ser o mesmo).
Uma visão geral dos esquemas abstratos de endereços furtivos baseados em criptografia e ZK-SNARKs
Uma lição importante aqui é que ** em um ecossistema favorável à privacidade, o usuário terá tanto a chave pública de gasto quanto a chave pública de criptografia, e as "informações de pagamento" do usuário precisarão conter ambas as chaves. **Além de pagar, existem outros 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 da conta, mas no mundo das carteiras de contratos inteligentes seguras, provavelmente deveríamos fornecer uma funcionalidade 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.
Essas três transições e recuperação de chave
Em um mundo onde cada usuário tem vários endereços, a maneira padrão de implementar mudanças importantes e recuperação social é fazer com que os usuários executem o processo de recuperação em cada endereço individualmente. Isso pode ser feito com um clique: a carteira pode fornecer uma função de software para executar o processo de recuperação simultaneamente em todos os endereços do usuário. No entanto, mesmo com essa simplificação da experiência do usuário, existem três problemas com a recuperação de vários endereços:
1. O custo do gás não é realista: Isso é evidente.
2. Endereços contrafactuais: endereços que ainda não emitiram um contrato inteligente (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 virtuais: um ou mais em cada L2, incluindo L2s que ainda não existem, e todo um conjunto infinito de endereços virtuais decorrentes do esquema de endereços furtivos.
3. Privacidade: Se um usuário usa intencionalmente vários endereços para evitar associá-los uns aos outros, certamente não deseja associar publicamente todos eles restaurando-os ao mesmo tempo ou quase ao mesmo tempo!
Resolver esses problemas é difícil. Felizmente, existe uma solução bastante elegante que funciona muito bem: Esta arquitetura 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). Então, os usuários têm endereços em diferentes L2s e a lógica de verificação para cada endereço é um ponteiro para o contrato de keystore. O gasto de fundos desses endereços exigirá o fornecimento de uma prova de uma chave pública de gasto atual (ou mais realisticamente, muito recente) para os fundos.
Esta prova pode ser obtida de várias maneiras:
** Acesso somente leitura a L1 diretamente dentro de L2. ** L2 pode ser modificado para permitir a leitura direta do estado L1. Se o contrato de keystore estiver em L1, isso significa que os contratos em L2 têm acesso "livre" ao keystore.
**Ramos Merkle. **Os ramos de Merkle podem provar o estado L1 para L2, ou o estado L2 para L1, ou uma combinação de ambos pode provar 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, que pode exigir um comprimento de prova de 5kB, mas devido ao uso de árvores Verkle, isso será reduzido para <1kB no futuro.
**ZK-SNARKs. **Você pode reduzir os custos de dados usando ZK-SNARKs de ramificações Merkle em vez de usar as próprias ramificações. Técnicas de agregação fora da cadeia (por exemplo, no topo do EIP-4337) podem ser construídas para permitir que um único ZK-SNARK verifique todas as provas de estado da cadeia cruzada em um bloco.
**KZG Promessa. **Seja L2 ou o esquema construído sobre ele, um sistema de endereçamento sequencial pode ser introduzido, permitindo que a prova de estado dentro do sistema seja de apenas 48 bytes. Como ZK-SNARKs, esquemas multi-prova podem combinar todas essas provas em uma única prova para cada bloco.
Se quisermos evitar a necessidade de uma prova para cada transação, podemos implementar um esquema mais leve que requer apenas recuperação em provas L2. O gasto de uma conta dependeria de uma chave de gasto com sua chave pública correspondente armazenada na conta, mas a recuperação exigiria uma transação para copiar a chave pública de gasto atual no armazenamento de chaves. Mesmo que suas chaves antigas não estejam seguras, os fundos no endereço virtual estão seguros: "ativar" o endereço virtual para transformá-lo em um contrato utilizável exigirá uma prova cruzada de L2 para replicar a chave pública de gasto atual. Há um tópico nos fóruns do Safe que descreve como uma arquitetura semelhante funciona.
Para adicionar privacidade a tal esquema, precisamos apenas criptografar os ponteiros e fazer todas as provas dentro dos ZK-SNARKs:
Com mais trabalhos (como este trabalho como ponto de partida), também podemos retirar ZK -A maior parte da complexidade dos SNARKs, construindo um esquema baseado em KZG mais simplificado.
Esses cenários podem ficar complicados. A vantagem é que existem muitas sinergias potenciais entre eles. Por exemplo, o conceito de "contrato keystore" também pode ser uma solução para o "endereço" mencionado na seção anterior: se quisermos que os usuários tenham um endereço persistente que não mude toda vez que o usuário atualizar a chave, pode colocar o sigilo O endereço meta, chave de criptografia e outras informações são colocadas no contrato de armazenamento de chave, e o endereço do contrato de armazenamento de chave é usado como o "endereço" do usuário.
Muita infraestrutura secundária precisa ser atualizada
Usar o ENS é caro. Embora não seja tão caro quanto antes em junho de 2023, a taxa de transação para registrar um nome de domínio ainda é relativamente alta, comparável ao custo de um nome de domínio ENS. Por exemplo, custa cerca de $ 27 para se registrar no zuzalu.eth, $ 11 dos quais são taxas de transação. Mas se o mercado ficar otimista novamente, as taxas vão subir. Mesmo que o preço do ETH não aumente, se a taxa de gás voltar a 200 gwei, a taxa de transação para o registro do nome de domínio chegará a 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 podem fornecer subdomínios aos usuários), precisamos que o ENS seja usado em Camada 2.
Felizmente, a equipe do ENS já se intensificou e o ENS está sendo implementado na Camada 2! ERC-3668 (também conhecido como "padrão CCIP") e ENSIP-10 fornecem uma maneira de verificar automaticamente os subdomínios ENS em qualquer Camada 2. O padrão CCIP requer a configuração de um contrato inteligente que descreva o método de verificação de provas de dados na Camada 2, e um nome de domínio (por exemplo, ecc.eth para Optinames) pode ser colocado sob o controle de tal contrato. Depois que o contrato CCIP controla ecc.eth em L1, acessar um determinado subdomínio.ecc.eth encontrará e verificará automaticamente uma prova que armazena o estado da Camada 2 desse subdomínio específico (por exemplo, uma ramificação Merkle).
na verdade, a obtenção dessas provas envolve o acesso a uma lista de URLs armazenadas no contrato, embora isso seja de alguma forma, pode parecer centralização, mas eu diria que na verdade não é: é um modelo de confiança 1-para-N (provas inválidas são detectadas pela lógica de validação na função de retorno de chamada do contrato CCIP, desde que um dos URLs A que retorna uma prova válida está bem). A lista de URLs pode conter dezenas de URLs.
**O esforço CCIP da ENS é uma história de sucesso e deve ser visto como um sinal de que as reformas radicais de que precisamos são realmente possíveis. ** Mas ainda há muitas reformas em nível de aplicativo que precisam ser feitas. aqui estão alguns exemplos:
**Muitos DApps dependem de usuários para fornecer assinaturas off-chain. **Para Contas Externas (EOA), é fácil. O ERC-1271 fornece uma maneira padronizada de fazer isso para carteiras de contratos inteligentes. No entanto, muitos DApps ainda não suportam ERC-1271 e precisam ser adaptados.
** DApps que usam "isto é um EOA?" para diferenciar entre usuários e contratos (por exemplo, para evitar transferências ou impor royalties) terão problemas. **Em geral, eu desaconselharia tentar encontrar uma solução puramente técnica aqui; determinar se uma determinada transferência de controle criptográfico é uma transferência de propriedade efetiva é um problema difícil que pode não ser resolvido sem recorrer a alguns métodos orientados pela comunidade off-chain mecanismos resolvem. Muito provavelmente, os aplicativos dependerão menos de meios técnicos de bloqueio de transferências e mais de técnicas como o imposto de Harberger.
**A interação da carteira com pagamentos e chaves de criptografia precisará ser aprimorada. **Atualmente, as carteiras normalmente usam assinaturas determinísticas para gerar chaves específicas do aplicativo: assinar um nonce padrão (por exemplo, um hash do nome do aplicativo) com a chave privada do EOA gerará um valor determinístico, a menos que a chave privada esteja em posse, caso contrário, o valor não pode ser gerado e, portanto, é puramente 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 precisarão ser tratadas de forma mais explícita pelas carteiras.
Clientes Light (como Helios) precisarão autenticar a Camada 2 em vez de apenas a Camada 1**. **Atualmente, o light client está focado em verificar a validade das informações do cabeçalho do bloco L1 (usando o protocolo de sincronização do light client) e verificar a ramificação Merkle do estado L1 e as transações com base nas informações do cabeçalho do bloco L1. No futuro, eles também precisarão verificar as provas do estado L2 enraizadas na raiz do estado armazenada em L1 (versões mais avançadas realmente examinarão a pré-confirmação L2).
As carteiras precisarão proteger ativos e dados
Atualmente, a missão da carteira é proteger o patrimônio. Tudo é armazenado na cadeia, tudo o que a carteira precisa proteger são as chaves privadas que atualmente protegem esses ativos. Se você alterar a chave, poderá postar com segurança a chave privada anterior publicamente na Internet no dia seguinte. No entanto, em um mundo de conhecimento zero, esse não é mais o caso: as carteiras não apenas protegem as credenciais de autenticação, mas também armazenam seus dados.
Vemos os primeiros sinais de tal mundo em Zuzalu com Zupass, um sistema de identidade baseado em ZK-SNARK. O usuário possui uma chave privada, que serve para autenticação no sistema, que pode ser utilizada para gerar provas básicas como "comprovar que sou morador de Zuzalu sem revelar qual morador sou". O sistema Zupass também começou a construir outros aplicativos em cima dele, principalmente selos (versão Zupass do POAP).
*Um dos meus muitos selos Zupass confirmando que sou membro do Team Cat. *
A principal característica dos carimbos relativos ao POAP é que eles são privados: você mantém os dados localmente e só prova um carimbo para o ZK deles (ou executa algum cálculo nos carimbos) se desejar fornecer essa informação a alguém. Mas isso também traz um risco adicional: se você perder essa informação, perderá seus selos.
Obviamente, o problema de manter dados pode ser reduzido ao problema de manter uma única chave de criptografia: um terceiro (mesmo na 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 contém a chave de criptografia é necessária. Mas mesmo assim, se você perder a chave de criptografia, perderá todos os seus dados. E, por sua vez, 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 usando o compartilhamento de chaves para dividir o armazenamento de chaves entre vários protetores.
A recuperação social via MPC não é uma solução adequada para carteiras, pois significa que não apenas o protetor atual, mas também os protetores anteriores podem conspirar para roubar seus ativos, o que é um risco inaceitavelmente alto. Embora uma violação de privacidade geralmente seja menos arriscada do que uma perda total de ativos, para casos de uso com altas necessidades de privacidade, um risco maior de perda pode ser aceito por não fazer backup das chaves associadas a essas necessidades de privacidade.
Para evitar atolar os usuários em um sistema complexo de vários caminhos de recuperação, as carteiras que oferecem suporte à recuperação social podem precisar gerenciar os dois aspectos da recuperação de ativos e da recuperação da chave de criptografia.
De volta à identidade
Um tema comum entre essas mudanças é que o conceito de "endereço" como uma representação de identidade no blockchain precisará mudar fundamentalmente. ** "Instruções de como interagir comigo" não será mais apenas um endereço ETH; express. **
Uma dessas maneiras é usar o ENS como sua identidade: seu registro ENS pode conter todas as informações sobre como pagar e interagir com você, se você enviar a alguém bob.eth (ou bob.ecc.eth etc.), eles podem consultar e aprenda sobre tudo o que interage com você, inclusive de formas mais complexas entre domínios e com proteção de privacidade.
No entanto, essa abordagem centrada no ENS sofre de dois pontos fracos:
**Associa muito conteúdo ao seu nome. **Seu nome não significa tudo sobre você, é apenas um dos muitos atributos sobre você. Deve ser possível alterar seu nome sem migrar todo o seu perfil de identidade e atualizar registros em muitos aplicativos.
**Você não pode ter nomes contrafactuais que não exijam confiança. **Um recurso importante da experiência do usuário de qualquer blockchain é a capacidade de enviar tokens para pessoas que ainda não interagiram com a cadeia. Sem essa funcionalidade, há um dilema: interagir com a cadeia exige pagar taxas de transação e pagar taxas de transação requer... já possuir tokens. Endereços ETH, incluindo endereços de contrato inteligente com CREATE2, possuem essa funcionalidade. Os nomes ENS não, porque se ambos os Bobs decidirem fora da cadeia que são bob.ecc.eth, não há como escolher qual Bob receberá o nome.
Uma solução possível é colocar mais conteúdo no contrato de keystore mencionado anteriormente na arquitetura deste artigo. Um contrato de armazenamento de chave pode conter várias informações sobre você e interações com você (e com CCIP, algumas dessas informações podem ser off-chain), os usuários usarão seu contrato de armazenamento de chave como seu identificador primário. No entanto, os ativos que eles realmente recebem serão armazenados em vários lugares diferentes. Os contratos de keystore são independentes de nome e amigáveis ao nome virtual: você pode gerar um endereço que só pode ser inicializado por um contrato de keystore com determinados parâmetros iniciais fixos.
Outra classe de soluções envolve abandonar totalmente a noção de endereços voltados para o usuário, semelhante ao protocolo de pagamento do 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 solicitação (como um URL explícito ou código QR), que o destinatário pode usar para enviar qualquer solicitação que deseje aceitar pagamento.
Seja o remetente ou o destinatário quem age primeiro, confiar mais nas carteiras para gerar informações de pagamento atualizadas em tempo real reduz o atrito. No entanto, identificadores persistentes são convenientes (especialmente com ENS), ao passo que, na prática, confiar na comunicação direta entre o remetente e o destinatário é um problema muito complicado, portanto, uma combinação de diferentes técnicas pode ser vista.
Em todos esses projetos, é fundamental permanecer descentralizado e compreensível para os usuários. Precisamos garantir que os usuários possam acessar facilmente uma visão atualizada de seus ativos atuais e mensagens direcionadas 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 a maior complexidade da infraestrutura de pagamento se torne uma "torre de abstração" opaca, difícil de entender e adaptar a novos ambientes. 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.
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: O ecossistema Ethereum precisa de três transformações tecnológicas
Autor: Vitalik, fundador da Ethereum; Tradução: Jinse Finance cryptonaitive
À medida que o Ethereum evolui de uma tecnologia jovem e experimental para uma pilha de tecnologia madura capaz de oferecer uma experiência aberta, global e sem permissão para usuários comuns, existem três grandes transições tecnológicas que precisam acontecer simultaneamente:
Sem o primeiro item, o Ethereum falhará porque cada transação custa $ 3,75 ($ 82,48 se passarmos por outra corrida de touros), e todo produto do mercado de massa inevitavelmente abandonará o comércio on-chain e adotará uma solução centralizada.
Sem o segundo item, o Ethereum falharia, pois os usuários relutariam em armazenar seus fundos (e ativos não financeiros) e todos recorreriam a trocas centralizadas.
Sem o terceiro item, o Ethereum falharia porque, para muitos usuários, todas as transações (e POAP etc) seriam publicamente visíveis, o sacrifício da privacidade seria muito grande e todos recorreriam a pelo menos algum nível de dados ocultos Solução centralizada.
Pelas razões descritas acima, essas três transições são críticas. Mas também são desafiadores devido à complexidade da coordenação envolvida. Não é apenas a funcionalidade do protocolo que precisa ser melhorada; em alguns casos, a forma como interagimos com o Ethereum precisa mudar fundamental e profundamente, exigindo grandes mudanças nos aplicativos e carteiras.
Essas três transformações irão remodelar fundamentalmente a relação entre usuários e endereços
Em um mundo de escala L2, os usuários existirão em várias redes L2. Você é um membro do ExampleDAO? ExampleDAO está no Otimismo. Então você tem uma conta na Optimism! Você possui um CDP de um sistema stablecoin no ZkSync? Então você tem uma conta no ZkSync! Você já experimentou alguns dos aplicativos localizados no Kakarot? Então você tem uma conta no Kakarot! Foi-se o tempo em que os usuários tinham apenas um endereço.
**Carteiras de contrato inteligentes adicionam mais complexidade, pois torna mais difícil ter o mesmo endereço em L1 e várias redes L2. **A maioria dos usuários hoje usa 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, manter um endereço torna-se mais difícil ao usar uma carteira de contrato inteligente. Embora muito trabalho tenha sido feito para tentar tornar os endereços um hash de código equivalente em diferentes redes, sendo o mais importante CREATE2 e a fábrica singleton ERC-2470, é difícil conseguir isso perfeitamente. Algumas redes L2 (por exemplo, "ZK-EVM do quarto tipo") não são exatamente equivalentes a EVMs, geralmente usando Solidity ou linguagem assembly intermediária em vez de equivalentes de hash. Mesmo que a equivalência de hash pudesse ser alcançada, a possibilidade de carteiras mudarem de propriedade por meio de mudanças de chave leva a outras consequências menos previsíveis.
**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 furtivo for amplamente utilizada, os usuários podem ter um endereço por transação em vez de apenas alguns endereços por usuário ou um endereço por rede L2. Outros esquemas de privacidade, mesmo os já existentes, como o Tornado Cash, mudam a maneira como os ativos são armazenados de maneiras diferentes: 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, essas três transformações enfraquecem o modelo mental "um usuário ≈ um endereço" de maneiras diferentes, algumas das quais, por sua vez, aumentam a complexidade da execução dessas transformações. Duas das questões particularmente complexas são:
**1. Se você quiser pagar alguém, como obterá as informações de pagamento? **
**2. Se os usuários armazenam ativos em diferentes locais em diferentes cadeias, como eles realizam mudanças importantes e recuperação social? **
Essas três transições e pagamentos on-chain (e identidade)
Eu mantenho tokens no Scroll e quero usá-los para comprar café (se o "eu" literal se refere a Vitalik, o autor deste artigo, então "café" significa "chá verde"). Você vende café no Taiko, mas só aceita tokens no Taiko. o que fazer?
Basicamente existem duas soluções:
A carteira receptora (que pode ser um comerciante ou um indivíduo comum) se esforça para oferecer suporte a cada L2 e possui algumas funções assíncronas de fusão de fundos.
O beneficiário fornece suas informações de L2 ao lado do 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 entre L2.
Claro, essas soluções podem ser usadas em combinação: o beneficiário fornece a lista L2 que está disposto a aceitar e a carteira do remetente determina o método de pagamento, que pode ser enviado diretamente (com sorte) ou pago por meio de uma ponte entre o L2.
Mas este é apenas um exemplo de um desafio importante introduzido pelas três transformações: Comportamentos de pagamento simples começam a exigir mais informações do que apenas um endereço de 20 bytes.
Felizmente, mudar para carteiras de contrato inteligentes não é um grande fardo para o sistema de endereços, mas ainda há 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 ao enviar transações, mas é preciso prestar mais atenção para garantir que o destinatário da carteira rastreie não apenas as transferências de ETH do EOA, mas também as transferências de ETH do código de contrato inteligente. Aplicativos que dependem 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, especialmente se alguém aceitar apenas tokens não-ETH ERC20, eles poderão usar um paymaster ERC-4337 para pagar pelo gás usando esse token.
Por outro lado, a questão da privacidade é novamente um grande desafio 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 e sacar dinheiro no sistema. 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" do usuário precisará conter (i) algum tipo de "chave pública de gasto", um compromisso secreto que o destinatário pode usar para gastar e (ii) o remetente pode enviar mensagens criptografadas que somente o destinatário pode descriptografar O destinatário da ajuda descobre o método de pagamento.
O protocolo de endereço Stealth baseia-se no conceito de um meta-endereço, que funciona da seguinte forma: parte do meta-endereço é a chave de gastos do remetente e a outra parte é a chave criptografada do remetente (embora uma implementação mínima possa definir ambas as chaves ser o mesmo).
Uma visão geral dos esquemas abstratos de endereços furtivos baseados em criptografia e ZK-SNARKs
Uma lição importante aqui é que ** em um ecossistema favorável à privacidade, o usuário terá tanto a chave pública de gasto quanto a chave pública de criptografia, e as "informações de pagamento" do usuário precisarão conter ambas as chaves. **Além de pagar, existem outros 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 da conta, mas no mundo das carteiras de contratos inteligentes seguras, provavelmente deveríamos fornecer uma funcionalidade 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.
Essas três transições e recuperação de chave
Em um mundo onde cada usuário tem vários endereços, a maneira padrão de implementar mudanças importantes e recuperação social é fazer com que os usuários executem o processo de recuperação em cada endereço individualmente. Isso pode ser feito com um clique: a carteira pode fornecer uma função de software para executar o processo de recuperação simultaneamente em todos os endereços do usuário. No entanto, mesmo com essa simplificação da experiência do usuário, existem três problemas com a recuperação de vários endereços:
1. O custo do gás não é realista: Isso é evidente.
2. Endereços contrafactuais: endereços que ainda não emitiram um contrato inteligente (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 virtuais: um ou mais em cada L2, incluindo L2s que ainda não existem, e todo um conjunto infinito de endereços virtuais decorrentes do esquema de endereços furtivos.
3. Privacidade: Se um usuário usa intencionalmente vários endereços para evitar associá-los uns aos outros, certamente não deseja associar publicamente todos eles restaurando-os ao mesmo tempo ou quase ao mesmo tempo!
Resolver esses problemas é difícil. Felizmente, existe uma solução bastante elegante que funciona muito bem: Esta arquitetura 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). Então, os usuários têm endereços em diferentes L2s e a lógica de verificação para cada endereço é um ponteiro para o contrato de keystore. O gasto de fundos desses endereços exigirá o fornecimento de uma prova de uma chave pública de gasto atual (ou mais realisticamente, muito recente) para os fundos.
Esta prova pode ser obtida de várias maneiras:
Se quisermos evitar a necessidade de uma prova para cada transação, podemos implementar um esquema mais leve que requer apenas recuperação em provas L2. O gasto de uma conta dependeria de uma chave de gasto com sua chave pública correspondente armazenada na conta, mas a recuperação exigiria uma transação para copiar a chave pública de gasto atual no armazenamento de chaves. Mesmo que suas chaves antigas não estejam seguras, os fundos no endereço virtual estão seguros: "ativar" o endereço virtual para transformá-lo em um contrato utilizável exigirá uma prova cruzada de L2 para replicar a chave pública de gasto atual. Há um tópico nos fóruns do Safe que descreve como uma arquitetura semelhante funciona.
Para adicionar privacidade a tal esquema, precisamos apenas criptografar os ponteiros e fazer todas as provas dentro dos ZK-SNARKs:
Esses cenários podem ficar complicados. A vantagem é que existem muitas sinergias potenciais entre eles. Por exemplo, o conceito de "contrato keystore" também pode ser uma solução para o "endereço" mencionado na seção anterior: se quisermos que os usuários tenham um endereço persistente que não mude toda vez que o usuário atualizar a chave, pode colocar o sigilo O endereço meta, chave de criptografia e outras informações são colocadas no contrato de armazenamento de chave, e o endereço do contrato de armazenamento de chave é usado como o "endereço" do usuário.
Muita infraestrutura secundária precisa ser atualizada
Usar o ENS é caro. Embora não seja tão caro quanto antes em junho de 2023, a taxa de transação para registrar um nome de domínio ainda é relativamente alta, comparável ao custo de um nome de domínio ENS. Por exemplo, custa cerca de $ 27 para se registrar no zuzalu.eth, $ 11 dos quais são taxas de transação. Mas se o mercado ficar otimista novamente, as taxas vão subir. Mesmo que o preço do ETH não aumente, se a taxa de gás voltar a 200 gwei, a taxa de transação para o registro do nome de domínio chegará a 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 podem fornecer subdomínios aos usuários), precisamos que o ENS seja usado em Camada 2.
Felizmente, a equipe do ENS já se intensificou e o ENS está sendo implementado na Camada 2! ERC-3668 (também conhecido como "padrão CCIP") e ENSIP-10 fornecem uma maneira de verificar automaticamente os subdomínios ENS em qualquer Camada 2. O padrão CCIP requer a configuração de um contrato inteligente que descreva o método de verificação de provas de dados na Camada 2, e um nome de domínio (por exemplo, ecc.eth para Optinames) pode ser colocado sob o controle de tal contrato. Depois que o contrato CCIP controla ecc.eth em L1, acessar um determinado subdomínio.ecc.eth encontrará e verificará automaticamente uma prova que armazena o estado da Camada 2 desse subdomínio específico (por exemplo, uma ramificação Merkle).
**O esforço CCIP da ENS é uma história de sucesso e deve ser visto como um sinal de que as reformas radicais de que precisamos são realmente possíveis. ** Mas ainda há muitas reformas em nível de aplicativo que precisam ser feitas. aqui estão alguns exemplos:
As carteiras precisarão proteger ativos e dados
Atualmente, a missão da carteira é proteger o patrimônio. Tudo é armazenado na cadeia, tudo o que a carteira precisa proteger são as chaves privadas que atualmente protegem esses ativos. Se você alterar a chave, poderá postar com segurança a chave privada anterior publicamente na Internet no dia seguinte. No entanto, em um mundo de conhecimento zero, esse não é mais o caso: as carteiras não apenas protegem as credenciais de autenticação, mas também armazenam seus dados.
Vemos os primeiros sinais de tal mundo em Zuzalu com Zupass, um sistema de identidade baseado em ZK-SNARK. O usuário possui uma chave privada, que serve para autenticação no sistema, que pode ser utilizada para gerar provas básicas como "comprovar que sou morador de Zuzalu sem revelar qual morador sou". O sistema Zupass também começou a construir outros aplicativos em cima dele, principalmente selos (versão Zupass do POAP).
*Um dos meus muitos selos Zupass confirmando que sou membro do Team Cat. *
A principal característica dos carimbos relativos ao POAP é que eles são privados: você mantém os dados localmente e só prova um carimbo para o ZK deles (ou executa algum cálculo nos carimbos) se desejar fornecer essa informação a alguém. Mas isso também traz um risco adicional: se você perder essa informação, perderá seus selos.
Obviamente, o problema de manter dados pode ser reduzido ao problema de manter uma única chave de criptografia: um terceiro (mesmo na 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 contém a chave de criptografia é necessária. Mas mesmo assim, se você perder a chave de criptografia, perderá todos os seus dados. E, por sua vez, 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 usando o compartilhamento de chaves para dividir o armazenamento de chaves entre vários protetores.
A recuperação social via MPC não é uma solução adequada para carteiras, pois significa que não apenas o protetor atual, mas também os protetores anteriores podem conspirar para roubar seus ativos, o que é um risco inaceitavelmente alto. Embora uma violação de privacidade geralmente seja menos arriscada do que uma perda total de ativos, para casos de uso com altas necessidades de privacidade, um risco maior de perda pode ser aceito por não fazer backup das chaves associadas a essas necessidades de privacidade.
Para evitar atolar os usuários em um sistema complexo de vários caminhos de recuperação, as carteiras que oferecem suporte à recuperação social podem precisar gerenciar os dois aspectos da recuperação de ativos e da recuperação da chave de criptografia.
De volta à identidade
Um tema comum entre essas mudanças é que o conceito de "endereço" como uma representação de identidade no blockchain precisará mudar fundamentalmente. ** "Instruções de como interagir comigo" não será mais apenas um endereço ETH; express. **
Uma dessas maneiras é usar o ENS como sua identidade: seu registro ENS pode conter todas as informações sobre como pagar e interagir com você, se você enviar a alguém bob.eth (ou bob.ecc.eth etc.), eles podem consultar e aprenda sobre tudo o que interage com você, inclusive de formas mais complexas entre domínios e com proteção de privacidade.
No entanto, essa abordagem centrada no ENS sofre de dois pontos fracos:
Uma solução possível é colocar mais conteúdo no contrato de keystore mencionado anteriormente na arquitetura deste artigo. Um contrato de armazenamento de chave pode conter várias informações sobre você e interações com você (e com CCIP, algumas dessas informações podem ser off-chain), os usuários usarão seu contrato de armazenamento de chave como seu identificador primário. No entanto, os ativos que eles realmente recebem serão armazenados em vários lugares diferentes. Os contratos de keystore são independentes de nome e amigáveis ao nome virtual: você pode gerar um endereço que só pode ser inicializado por um contrato de keystore com determinados parâmetros iniciais fixos.
Outra classe de soluções envolve abandonar totalmente a noção de endereços voltados para o usuário, semelhante ao protocolo de pagamento do 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 solicitação (como um URL explícito ou código QR), que o destinatário pode usar para enviar qualquer solicitação que deseje aceitar pagamento.
Seja o remetente ou o destinatário quem age primeiro, confiar mais nas carteiras para gerar informações de pagamento atualizadas em tempo real reduz o atrito. No entanto, identificadores persistentes são convenientes (especialmente com ENS), ao passo que, na prática, confiar na comunicação direta entre o remetente e o destinatário é um problema muito complicado, portanto, uma combinação de diferentes técnicas pode ser vista.
Em todos esses projetos, é fundamental permanecer descentralizado e compreensível para os usuários. Precisamos garantir que os usuários possam acessar facilmente uma visão atualizada de seus ativos atuais e mensagens direcionadas 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 a maior complexidade da infraestrutura de pagamento se torne uma "torre de abstração" opaca, difícil de entender e adaptar a novos ambientes. 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.