Experiência do usuário de transações cruzadas-L2

Agora existe uma estrada cada vez mais detalhada para melhorar a experiência do usuário de cross-L2, que possui uma parte de curto prazo e uma parte de longo prazo. Aqui, vou falar sobre a parte de curto prazo: ideias que são teoricamente implementáveis até mesmo hoje.

As ideias principais são (i) envios integrados entre L2 e (ii) endereços e solicitações de pagamento específicos da cadeia. Sua carteira deve ser capaz de lhe fornecer um endereço que (seguindo o estilo de este rascunho ERC) parece com isso:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

Quando alguém (ou alguma aplicação) lhe der um endereço neste formato, você deverá ser capaz de colá-lo no campo “para” da carteira e clicar em “enviar”. A carteira deve processar automaticamente o envio da melhor maneira possível:

• Se você já tem moedas suficientes do tipo necessário na cadeia de destino, envie as moedas diretamente.
• Se você tiver moedas do tipo necessário em outra cadeia (ou várias outras cadeias), use um protocolo como ERC-7683 (efetivamente uma DEX cross-chain) para enviar as moedas
• Se você tiver moedas de um tipo diferente na mesma ou em outras cadeias, use as bolsas descentralizadas para convertê-las no tipo certo de moeda na cadeia certa e enviá-las. Isso deve exigir permissão explícita do usuário: o usuário veria quanto do que está pagando e quanto o destinatário está recebendo.

Mockup de possível interface de carteira com suporte a endereços de várias cadeias

O acima é para o “you copy-paste um endereço (ou ENS, por exemplo, vitalik.eth@optimism.eth) para alguém lhe pagar" caso de uso. Se um dapp está solicitando um depósito (por exemplo, veja este exemplo Polymarket) então o fluxo ideal é estender a API web3 e permitir que o dapp faça uma solicitação de pagamento específica da cadeia. Sua carteira seria capaz de atender a essa solicitação da maneira que precisar. Fazer a experiência do usuário funcionar bem também exigiria padronizar uma solicitação de getAvailableBalance, e as carteiras precisariam pensar cuidadosamente em quais cadeias armazenam os ativos dos usuários por padrão para maximizar a segurança e facilidade de transferências.

Pedidos de pagamento específicos da cadeia também poderiam ser colocados em códigos QR, que as carteiras móveis poderiam escanear. Em um cenário de pagamentos ao consumidor em pessoa (ou online), o destinatário faria uma chamada de API de código QR ou web3 que diz “Quero X unidades do token Y na cadeia Z, com ID de referência ou retorno de chamada W”, e a carteira seria livre para atender a esse pedido da maneira que puder. Outra opção é um protocolo de link de reivindicação, onde a carteira do usuário gera um código QR ou URL que contém uma autorização para reivindicar uma certa quantidade de fundos de seu contrato onchain, e é trabalho do destinatário descobrir como mover esses fundos para sua própria carteira.

Outro tópico relacionado são os pagamentos de gás. Se você receber ativos em uma L2 onde ainda não possui ETH e precisar enviar uma transação nessa L2, uma carteira deveria ser capaz de usar automaticamente um protocolo (por exemplo, RIP-7755) para pagar o gás em uma cadeia onde você tem ETH. Se a carteira espera que você faça mais transações nesse L2 no futuro, ela também deve usar uma DEX para enviar por exemplo. alguns milhões de gás no valor de ETH, para que transações futuras possam gastar gás diretamente lá (já que isso é mais barato).

Segurança da conta

Uma maneira pela qual eu conceitualizo o desafio da segurança da conta é que uma boa carteira deve ser simultaneamente boa em duas áreas: (i) proteger o usuário de ter a carteira invadida ou maliciosa pelo desenvolvedor e (ii) proteger o usuário de seus próprios erros.

O erro de digitação na esquerda não foi intencional. No entanto, ao vê-lo, percebi que é perfeitamente apropriado para o contexto, então decidi mantê-lo.

Minha solução preferida para isso, para sobredezanosfoi recuperado por meio social e por carteiras multisig, com controle de acesso graduado. A conta do usuário possui duas camadas de chaves: uma chave primária e N guardiões (por exemplo, N = 5). A chave primária é capaz de realizar operações de baixo valor e não financeiras. A maioria dos guardiões é necessária para realizar (i) operações de alto valor, como enviar todo o valor da conta, ou (ii) alterar a chave primária ou qualquer um dos guardiões. Se desejado, a chave primária pode ser autorizada a realizar operações de alto valor com um bloqueio de tempo.

O acima é um design básico e pode ser aumentado. Chaves de sessão e mecanismos de permissão como ERC-7715pode ajudar a suportar diferentes equilíbrios entre conveniência e segurança para diferentes aplicativos. Arquiteturas de guardião mais complicadas, como ter várias durações de bloqueio temporal em diferentes limites, podem ajudar a maximizar a chance de recuperação de conta legítima bem-sucedida, minimizando o risco de roubo.

Quem ou o que deveriam ser os guardiões?

Para um usuário de criptografia experiente que está dentro de uma comunidade de usuários de criptografia experientes, uma opção viável são as chaves dos seus amigos e familiares. Se você pedir a cada um deles para fornecer um endereço novo, então ninguém precisa saber quem eles são - na verdade, seus guardiões nem precisam saber quem são uns aos outros. A chance deles conluírem sem que um deles te informe é mínima. No entanto, para a maioria dos novos usuários, essa opção não está disponível.

Uma segunda opção são os guardiões institucionais: empresas que se especializam em realizar o serviço de apenas assinar uma transação se receberem alguma outra confirmação de que um pedido está vindo de você: por exemplo, um código de confirmação, ou para usuários de alto valor um chamada de vídeo. As pessoas tentaram fazer isso por muito tempo, por exemplo,Eu perfilava a CryptoCorp em 2013. No entanto, até agora, tais empresas não têm sido muito bem-sucedidas.

Uma terceira opção são vários dispositivos pessoais (por exemplo, telefone, desktop, carteira de hardware). Isso pode funcionar, mas também é difícil de configurar e gerenciar para usuários inexperientes. Há também o risco de os dispositivos serem perdidos ou roubados ao mesmo tempo, especialmente se estiverem no mesmo local.

Recentemente, temos visto mais carteiras baseadas em passkeys. As passkeys podem ser copiadas apenas em seus dispositivos, tornando-as uma solução pessoal ou copiadas na nuvem, tornando sua segurança dependente de umcomplicado híbridoda segurança de senhas, pressupostos de hardware institucional e confiável. Realisticamente, as passkeys são um ganho de segurança valioso para os usuários comuns, mas sozinhas não são suficientemente fortes para proteger as economias de uma pessoa.

Felizmente, com ZK-SNARKs, temos uma quarta opção: ID centralizado envolto em ZK. Esse gênero inclui zk-email, Anon Aadhaar, Myna Wallet, e muitos outros. Basicamente, você pode transformar muitas formas de ID centralizado (corporativo ou governamental) e transformá-lo em um endereço Ethereum, do qual você só pode enviar transações gerando uma prova de posse do ID centralizado usando ZK-SNARK.

Com essa adição, agora temos uma ampla variedade de opções, e o ID centralizado ZK-wrapped é exclusivamente “amigável para iniciantes”.

Para que isso funcione, precisa ser implementado com uma interface de usuário integrada e simplificada: você deve ser capaz de simplesmente especificar que deseja "gate"example@gmail.com” como um guardião, e deve gerar automaticamente o endereço Ethereum zk-email correspondente por baixo do capô. Usuários avançados devem ser capazes de inserir seu e-mail (junto com talvez um valor de salt para privacidade, que seria salvo nesse e-mail) em um aplicativo de terceiros de código aberto, e confirmar que o endereço gerado está correto. O mesmo deve ser verdadeiro para qualquer outro tipo de guardião suportado.

Mockup da possível interface Segura

Note que hoje, um desafio prático com o zk-email especificamente é que ele depende deAssinaturas DKIM, que usam chaves que são rotacionadas uma vez a cada poucos meses, e essas chaves não são elas próprias assinadas por qualquer outra autoridade. Isso significa que o zk-email hoje tem algum nível de requisito de confiança além do próprio provedor; isso poderia ser reduzido se o zk-email usasse TLSNotarydentro do hardware confiável para verificar chaves atualizadas, mas não é ideal. Esperançosamente, os provedores de e-mail começarão a assinar suas chaves DKIM diretamente. Hoje, eu recomendaria usar zk-email para um guardião, mas não para a maioria dos seus guardiões: não armazene fundos em uma configuração onde a quebra do zk-email significa que você perde o acesso aos seus fundos.

Novos usuários e carteiras no aplicativo

Novos usuários realisticamente não vão querer ter que inserir um grande número de guardiões em sua primeira experiência de inscrição. Portanto, as carteiras devem oferecer a eles uma opção muito simples. Uma rota natural é um 2-de-3 usando zk-email em seu endereço de e-mail, uma chave armazenada localmente no dispositivo do usuário (que poderia ser uma senha), e uma chave de backup mantida pelo provedor. Conforme o usuário ganha mais experiência ou acumula mais ativos, em algum momento ele deverá ser solicitado a adicionar mais guardiões.

Carteiras integradas em aplicativos são inevitáveis, porque os aplicativos que tentam atrair usuários não cripto não desejam a experiência do usuário confusa de pedir que seus usuários baixem dois novos aplicativos (o próprio aplicativo, mais uma carteira Ethereum) ao mesmo tempo. No entanto, um usuário de muitas carteiras de aplicativos deve ser capaz de vincular todas as suas carteiras, para que tenham apenas um "controle de acesso" com que se preocupar. A maneira mais simples de fazer isso é um esquema hierárquico, onde há um processo de "vinculação" rápido que permite a um usuário definir sua carteira principal como guardiã de todas as suas carteiras de aplicativos. O cliente Farcaster Warpcast já oferece suporte a isso:

Por padrão, a recuperação da sua conta Warpcast é controlada pela equipe Warpcast. No entanto, você pode "tomar a soberania" da sua conta Farcaster e alterar a recuperação para o seu próprio endereço.

Protegendo os usuários de golpes e outras ameaças externas

Além da segurança da conta, as carteiras de hoje fazem muito para identificar endereços falsos, phishing, golpes e outras ameaças externas, e tentam proteger seus usuários dessas ameaças. Ao mesmo tempo, muitas das contramedidas ainda são bastante primitivas: por exemplo, exigindo um clique para enviar ETH ou outros tokens para qualquer novo endereço, independentemente de você estar enviando $100 ou $100.000. Aqui, não há uma única solução mágica; é uma série de correções lentas e melhorias contínuas para diferentes categorias de ameaças. No entanto, há muito valor em continuar a trabalhar duro para melhorar aqui.

Privacidade

Agora é o momento de começar a levar a privacidade no Ethereum muito mais a sério. A tecnologia ZK-SNARK está agora muito avançada, tecnologias de privacidade que mitigam os riscos regulatórios sem depender de backdoors, como Piscinas de privacidade, estão se tornando mais maduras, e infraestrutura secundária como Wakue as mempools ERC-4337 estão se tornando mais estáveis lentamente. No entanto, até agora, fazer transferências privadas no Ethereum exigia que os usuários baixassem e usassem explicitamente uma “carteira de privacidade”, como Ferrovia(ouUmbraparaendereços furtivosIsso adiciona grande inconveniente e reduz o número de pessoas que estão dispostas a fazer transferências privadas. A solução é que as transferências privadas precisam ser integradas diretamente nas carteiras.

Uma implementação simples é a seguinte. Uma carteira poderia armazenar uma parte dos ativos de um usuário como um 'saldo privado' em um pool de privacidade. Quando um usuário faz uma transferência, ela automaticamente seria retirada do pool de privacidade primeiro. Se um usuário precisa receber fundos, a carteira poderia gerar automaticamente um endereço furtivo.

Além disso, uma carteira poderia gerar automaticamente um novo endereço para cada aplicativo em que um usuário participa (por exemplo, um protocolo defi). Os depósitos viriam do pool de privacidade e as retiradas iriam diretamente para o pool de privacidade. Isso permite que a atividade de um usuário em qualquer aplicativo seja desvinculada de sua atividade em outros aplicativos.

Uma vantagem dessa técnica é que ela é um caminho natural não apenas para transferência de ativos que preservam a privacidade, mas também para preservação da identidade. A identidade já acontece na cadeia: qualquer aplicativo que utiliza gate de comprovação de pessoa (por exemplo, doações do Gitcoin), qualquer bate-papo com gate de token, Ethereum Seguir Protocolo, e muito mais são todas identidades onchain. Queremos que este ecossistema também seja preservador da privacidade. Isso significa que a atividade de um usuário onchain não deve ser coletada em um só lugar: cada item deve ser armazenado separadamente, e a carteira do usuário deve ser a única coisa com uma “visão global” que vê todas as suas declarações ao mesmo tempo. Um ecossistema nativamente com muitas contas por usuário ajuda a conseguir isso, assim como os protocolos de declaração offchain como EASeZupass.

Isso representa uma visão pragmática para a privacidade do Ethereum no futuro a médio prazo. Pode ser implementado hoje, embora haja recursos que possam ser introduzidos em L1 e L2 para tornar as transferências de preservação de privacidade mais eficientes e confiáveis. Alguns defensores da privacidade argumentam que a única coisa aceitável é a privacidade total de tudo: criptografar todo o EVM. Eu argumentaria que isso pode ser ideal como resultado a longo prazo, mas requer uma reformulação muito mais fundamental dos modelos de programação e atualmente não está no nível de maturidade em que está pronto para ser implementado em toda a Ethereum. Precisamos de privacidade-por-padrão para obter conjuntos de anonimato suficientemente grandes. No entanto, focar primeiro em tornar (i) as transferências entre contas e (ii) os casos de uso de identidade e identidade-adjacentes, como atestações, privados é um primeiro passo pragmático que é muito mais fácil de implementar e que as carteiras podem começar hoje.

As carteiras Ethereum também precisam se tornar carteiras de dados

Uma consequência de qualquer solução de privacidade eficaz, seja para pagamentos ou para identidade ou outros casos de uso, é que ela cria uma necessidade para o usuário armazenar dados offchain. Isso era óbvio no Tornado Cash, que exigia que os usuários salvassem cada "nota" individual representando um depósito de 0,1-100 ETH. Protocolos de privacidade mais modernos às vezes salvam os dados criptografados onchain e usam uma única chave privada para descriptografá-los. Isso é arriscado, porque se a chave for vazada, ou se os computadores quânticos se tornarem viáveis, todos os dados se tornam públicos. Atestados offchain como EAS e Zupass têm uma necessidade ainda mais óbvia de armazenamento de dados offchain.

Carteiras precisam se tornar não apenas software para armazenar permissões de acesso on-chain, mas também software para armazenar seus dados privados. Isso é algo que o mundo não cripto está reconhecendo cada vez mais também, por exemplo, veja Tim Berners-Lee’strabalho recente em armazenamento de dados pessoais. Todos os problemas que precisamos resolver em torno de garantir robustamente o controle das permissões de acesso, também precisamos resolver em torno de garantir robustamente a acessibilidade e a não vazamento de dados. Talvez as soluções possam ser sobrepostas: se você tiver N guardiões, use compartilhamento de segredo M-de-N entre esses mesmos N guardiões para armazenar seus dados. Os dados são inerentemente mais difíceis de proteger, porque você não pode revogar a participação de alguém neles, mas devemos encontrar soluções de custódia descentralizadas que sejam o mais seguras possível.

Acesso seguro à cadeia

Hoje, as carteiras confiam em seus provedores de RPC para fornecerem qualquer informação sobre uma cadeia. Isso é uma vulnerabilidade de duas maneiras:

1. O provedor RPC pode tentar roubar dinheiro fornecendo informações falsas, por exemplo, sobre preços de mercado
2. O provedor RPC poderia extrair informações privadas sobre quais aplicativos e outras contas um usuário está interagindo

Idealmente, queremos tapar ambas essas lacunas. Para tapar a primeira, precisamos de clientes leves padronizados para L1 e L2s, que verifiquem diretamente o consenso da blockchain.Heliosjá faz isso para L1 e já fez algum trabalho preliminar para apoiar alguns L2s específicos. Para cobrir adequadamente todos os L2s, o que precisamos é de um padrão pelo qual um contrato de configuração representando um L2 (também usado para endereços específicos da cadeia) possa declarar uma função, talvez de uma maneira semelhante aERC-3668, contendo a lógica para obter raízes de estado recentes e verificar provas de estado e recibos contra essas raízes de estado. Dessa forma, poderíamos ter um cliente leve universal, permitindo que as carteiras verifiquem com segurança qualquer estado ou eventos na L1 e L2.

Para privacidade, hoje a única abordagem realista é executar seu próprio nó completo. No entanto, agora que os L2s estão entrando em cena, executar um nó completo de tudo está se tornando cada vez mais difícil. O equivalente a um cliente leve aqui é recuperação de informações privadas (PIR). PIR envolve um servidor que mantém uma cópia de todos os dados e um cliente que envia ao servidor uma solicitação criptografada. O servidor realiza um cálculo sobre todos os dados, o que retorna os dados desejados do cliente, criptografados com a chave do cliente, sem revelar ao servidor qual parte dos dados o cliente acessou.

Para manter o servidor honesto, os itens de banco de dados individuais seriam eles próprios ramos Merkle, para que o cliente pudesse verificá-los usando seu cliente leve.

PIR é muito computacionalmente caro. Existem várias maneiras de contornar este problema:

• Força bruta: melhorias em algoritmos, ou hardware especializado, poderiam potencialmente tornar o PIR rápido o suficiente para ser executado. Essas técnicas podem depender de pré-processamento: os servidores poderiam armazenar dados criptografados e embaralhados para cada cliente, e os clientes poderiam consultar esses dados. O principal desafio no contexto do Ethereum é adaptar essas técnicas a conjuntos de dados que mudam rapidamente (como o estado faz). Isso torna os custos computacionais em tempo real mais baixos, mas pode aumentar significativamente os custos computacionais e de armazenamento totais.
• Reduzir o requisito de privacidade: por exemplo, cada busca só poderia ter 1 milhão de "misturas", então o servidor saberia um milhão de valores possíveis que o cliente poderia ter acessado, mas não uma granularidade mais fina
• Multi-servidor PIR: algoritmos PIR são frequentemente muito mais rápidos se você usar vários servidores com uma suposição de honestidade 1-de-N entre esses servidores.
• Anonimato em vez de confidencialidade: em vez de ocultar o conteúdo da solicitação, a solicitação pode ser enviada por meio de uma mixnet, ocultando o remetente da solicitação. No entanto, fazer isso de forma eficaz inevitavelmente aumenta a latência, piorando a experiência do usuário.

Descobrir a combinação certa de técnicas para maximizar a privacidade, mantendo a praticidade no contexto Ethereum é um problema de pesquisa aberto, e eu dou as boas-vindas aos criptógrafos que tentam a mão nisso.

Carteiras de Keystore ideais

Além das transferências e do acesso ao estado, outro fluxo de trabalho importante que precisa funcionar sem problemas em um contexto cross-L2 é a alteração da configuração de validação de uma conta: seja a alteração de suas chaves (por exemplo, recuperação), ou uma alteração mais profunda na lógica inteira da conta. Aqui, existem três níveis de soluções, em ordem crescente de dificuldade:

1. Atualizações reproduzidas: quando um usuário altera sua configuração, uma mensagem autorizando essa alteração é reproduzida em todas as cadeias onde a carteira detecta que um usuário possui ativos. Potencialmente, o formato da mensagem e as regras de validação podem ser tornados independentes da cadeia, para que possam ser reproduzidos automaticamente em quantas cadeias forem possíveis.
2. Keystores em L1: as informações de configuração estão em L1, e a carteira em L2 as lê com um L1SLOAD ou REMOTESTATICCALL. Dessa forma, a atualização da configuração precisa ser feita apenas na L1, e a configuração se torna efetiva automaticamente.
3. Keystores em L2: as informações de configuração vivem em L2, e a carteira em L2 lê-as com um ZK-SNARK. Isso é o mesmo que (2), exceto que as atualizações de armazenamento de chaves podem ser mais baratas, embora, por outro lado, as leituras sejam mais caras.

A solução (3) é particularmente poderosa porque se encaixa bem com a privacidade. Em uma 'solução de privacidade' normal, um usuário tem um segredo s, um 'valor de folha' L é publicado na cadeia, e um usuário prova que L = hash(s, 1) e N = hash(s, 2) para algum segredo (nunca revelado) que eles controlam. O nullifier N é publicado, garantindo que gastos futuros da mesma folha falhem, sem revelar L. Isso depende do usuário manter s em segurança. Uma solução de privacidade amigável à recuperação diria: s é uma localização (por exemplo, endereço e slot de armazenamento) na cadeia, e o usuário deve provar uma consulta de estado: L = hash(sload(s), 1).

Segurança Dapp

O elo mais fraco na segurança de um usuário muitas vezes é o dapp. Na maioria das vezes, um usuário interage com um aplicativo indo para um site, que implicitamente baixa o código da interface do usuário em tempo real de um servidor e então o executa no navegador. Se o servidor for hackeado, ou se o DNS for hackeado, o usuário receberá uma cópia falsa da interface, que poderia enganar o usuário a fazer coisas arbitrárias. Recursos da carteira como simulações de transações são muito úteis na mitigação dos riscos, mas estão longe de ser perfeitos.

Idealmente, moveríamos o ecossistema para o controle de versão de conteúdo on-chain: um usuário acessaria um dapp por meio de seu nome ENS, que conteria o hash IPFS da interface. Uma transação onchain de um multisig ou DAO seria necessária para atualizar a interface. As carteiras mostrariam aos usuários se eles estão interagindo com uma interface onchain mais segura ou uma interface web2 menos segura. As carteiras também podem mostrar aos usuários se eles estão interagindo com uma cadeia segura (por exemplo, estágio 1+, várias auditorias de segurança).

Para usuários preocupados com a privacidade, as carteiras também podem adicionar um modo paranoico, que exige que os usuários cliquem em aceitar solicitações HTTP, e não apenas operações web3:

Mockup de possível interface para modo paranoico

Uma abordagem mais avançada seria ir além do HTML + Javascript e escrever a lógica de negócios de dapps em uma linguagem dedicada, talvez uma camada relativamente fina sobre Solidity ou Vyper. Os navegadores poderiam então gerar automaticamente uma interface de usuário para qualquer funcionalidade necessária.OKContractjá está fazendo isso.

Outra direção é a info-defesa criptoeconômica: desenvolvedores de dapp, empresas de segurança, implantadores de cadeia e outros podem oferecer uma garantia que seria paga aos usuários afetados se um dapp fosse hackeado ou prejudicasse de alguma outra forma os usuários, agindo de maneira altamente enganosa, conforme determinado por algum DAO de adjudicação onchain. A carteira poderia mostrar ao usuário uma pontuação baseada no tamanho da garantia.

O futuro a longo prazo

O acima foi tudo no contexto de interfaces convencionais, que envolvem apontar e clicar em coisas e inserir coisas em campos de texto. No entanto, também estamos à beira de paradigmas mudando muito mais profundamente:

• IA, o que poderia nos levar a sair de um paradigma de apontar, clicar e digitar para um paradigma de 'dizer o que você quer fazer e o robô descobrir'
• Interfaces cérebro-computador, tanto abordagens "suaves" como rastreamento ocular, quanto técnicas mais diretas e até invasivas (ver: primeiro paciente da Neuralink este ano)
• Clientes engajados na defesa ativa: o navegador Braveprotege ativamente os usuários contra anúncios, rastreadores e muitos outros objetos indesejáveis. Muitos navegadores, plugins e carteiras cripto possuem equipes inteiras trabalhando ativamente para proteger os usuários contra todos os tipos de ameaças de segurança e privacidade. Esses tipos de "guardiões ativos" se tornarão ainda mais poderosos na próxima década.

Essas três tendências juntas levarão a um repensar muito mais profundo de como as interfaces funcionam. Por meio de entrada de linguagem natural, rastreamento ocular ou, eventualmente, BCI mais direto, juntamente com o conhecimento de seu histórico (talvez incluindo mensagens de texto, desde que todos os dados sejam processados localmente), uma "carteira" poderia ter uma ideia intuitiva clara do que você deseja fazer. A IA poderia então traduzir essa intuição em um "plano de ação" concreto: uma série de interações onchain e offchain que realizam o que você deseja. Isso poderia reduzir muito a necessidade de interfaces de usuário de terceiros completamente. Se um usuário interage com um aplicativo de terceiros (ou outro usuário), a IA deve pensar negativamente em nome do usuário, identificar quaisquer ameaças e sugerir planos de ação para evitá-las. O ideal seria que houvesse um ecossistema aberto dessas IAs, produzidas por diferentes grupos com diferentes vieses e estruturas de incentivo.

Essas ideias mais radicais dependem de tecnologia que é extremamente imatura hoje, e por isso eu não colocaria meus ativos hoje em uma carteira que depende deles. No entanto, algo assim parece ser claramente o futuro, e por isso vale a pena começar a explorar mais ativamente nessa direção.

Disclaimer:

1. Este artigo foi reproduzido de [Vitalik]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learn equipe, e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de aprendizado do Gate. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.