Todos estão falando sobre a Abstração de Conta (AA) e seu potencial para revolucionar a experiência do usuário no espaço blockchain. No entanto, o principal mal-entendido sobre a AA é que ela vai além de meramente abstrair taxas de gás ou habilitar transações em lote. Como? Através de sistemas de gerenciamento de chaves programáveis.

Esses sistemas podem fornecer segurança em nível de hardware para dispositivos do dia a dia e integrar métodos de autenticação Web2 em ambientes Web3, permitindo-nos ir além das tradicionais frases-semente de 12 palavras. Hoje, vou explicar diferentes sistemas de gerenciamento de chaves que os desenvolvedores podem utilizar e os casos de uso específicos onde eles são mais úteis.

Avançando além de 12 palavras

Nossa indústria adora palavras da moda e “sem semente” é uma das mais recentes a chamar atenção. Embora todos concordemos que esperar que os usuários armazenem suas chaves privadas com segurança seja impraticável e tenha resultado na perda de milhões de dólares, a pergunta continua: se não mostramos aos usuários as frases de semente, onde armazenamos as chaves?

Sem a Abstração de Conta (AA), a maioria das soluções existentes depende da Computação Multi-Partes (MPC) para distribuir chaves em várias partes e criar um limite para realizar transações. Essas soluções geralmente afirmam ser auto-custodiadas. No entanto, isso não é totalmente preciso. Por exemplo, a Binance armazena uma parte da chave, atuando como um depositário caso os usuários percam seus dispositivos. Essa configuração significa que, apesar das alegações, os usuários não têm controle total sobre suas chaves e ainda há uma dependência de uma entidade centralizada para a recuperação de chaves.

Além disso, se qualquer chave compartilhada for vazada, não há como revogar a chave da conta principal. A revogação é impossível porque Contas de Propriedade Externa (EOAs) não suportam a rotação de chaves, o que significa que as chaves vazadas sempre farão parte da conta. Isso representa um risco de segurança significativo, pois as chaves comprometidas não podem ser substituídas ou removidas, deixando a conta vulnerável indefinidamente.

Se você deseja aprender mais sobre como AA abre o caminho para contas programáveis e rotação de chaves, você podeverifique meu artigo.

1. Contas totalmente programáveis: Abstração de conta

A Abstração de Conta permite que os desenvolvedores construam diferentes sistemas de gestão de chaves. Uma conta pode ser controlada com múltiplas chaves e diferentes métodos de autenticação, todos suportando rotação de chaves. Ainda melhor, o poder das chaves pode ser diferenciado. Isso significa que os usuários podem utilizar chaves diferentes para a mesma conta, cada uma adaptada para diferentes casos de uso. Mais tarde, explicarei esses casos de uso com mais detalhes.

Com AA, os fundos são armazenados em contratos inteligentes, e a propriedade da conta é definida por esses contratos inteligentes. As contas compatíveis com o EIP-4337 têm duas partes em suas transações.

1. A primeira parte é a verificação, onde a propriedade da conta é verificada na cadeia.
2. A segunda parte é a execução, que executa a mensagem.

As duas partes são totalmente programáveis; por exemplo, você pode definir duas chaves (i, ii), e a primeira chave (i) pode executar transações imediatas, enquanto a segunda chave (ii) só pode executar transações após um bloqueio de tempo. Isso significa que podemos definir o poder das chaves, adicionar um bloqueio de tempo ou habilitar outras condições para executar uma transação.

Portanto, quando falamos de contas tradicionais (EOAs), autenticação é igual a autorização. Com AA, a autorização é programável, para que os desenvolvedores possam definir um esquema de controle de acesso baseado em funções e aplicar o princípio do menor privilégio.

Existem muitos métodos de autenticação (ou seja, sistemas de gerenciamento de chaves) no espaço cripto que podem permitir esquemas de controle de acesso baseados em funções e usar apenas uma chave não pode resolver todos os problemas associados ao gerenciamento de chaves. Os aspectos mais importantes dos sistemas de gerenciamento de chaves são: onde a chave é armazenada e quem a autentica.

Prós e contras de diferentes sistemas de gestão de chaves

Vou resumir rapidamente as Passkeys (Enclaves Seguros do Consumidor), Soluções Baseadas em MPC, Soluções baseadas em TEE na nuvem, Soluções de Custódia, Tradicionais 12 palavras e Chaves de Sessão. Depois disso, explicarei as melhores combinações.

1. 12 palavras tradicionais - (secp256k1) -

Bitcoin e Ethereum suportam asecp256k1Algoritmo ECC (criptografia de curva elíptica) para criar chaves privadas e armazená-las nos dispositivos dos usuários. Este método é amplamente utilizado em EOAs e também pode ser aplicado acontas inteligentes. Para usá-lo, o aplicativo da carteira gera uma chave privada usando um algoritmo de geração de chaves aleatórias e, em seguida, armazena a chave privada no armazenamento compartilhado.

Usar secp256k1 tem várias vantagens: não incorre em custos adicionais de gás, é barato e fácil de verificar na cadeia via o pré-cálculo ecrecover. Também é auto-custodial porque apenas o usuário pode acessar a chave.

No entanto, há algumas desvantagens:

1. É desafiador educar os usuários sobre como armazenar com segurança suas chaves no caso de perderem seus dispositivos.
2. Um cavalo de Troia ou malware poderia roubar a chave privada dos dispositivos dos usuários, pois ela está armazenada em armazenamento compartilhado.

NIST does not support the secp256k1 curve, which means it’s not commonly supported by popular frameworks and most hardware.

2. Passkeys (Enclaves Seguros do Consumidor)

Quase todos os dispositivos modernos possuem dois componentes principais: um sistema operacional (com armazenamento compartilhado associado) e uma Enclave Segura. O sistema operacional lida com a maioria das operações, exceto por tarefas sensíveis como proteção de dados biométricos, chaves criptográficas, criptografia e desbloqueio do dispositivo.

Os desenvolvedores criaram um microchip dedicado chamado Secure Enclave para gerenciar essas operações sensíveis separadamente. O Secure Enclave funciona de forma semelhante a uma carteira de hardware; ele opera de forma independente, manipulando com segurança dados sensíveis, e até mesmo o proprietário do dispositivo não pode acessar seu conteúdo. Felizmente, o Secure Enclave suporta operações criptográficas, como criar chaves privadas e assinar mensagens com elas. Infelizmente, o Secure Enclave não suporta a curva que o Ethereum suporta (secp256k1), em vez disso, ele suporta a curva p256. Para habilitar a verificação nativa P256, nós (@getclave"">@getclave equipe) propôs oRIP-7212e quase todos os grandes rollups agora o suportam.

E a melhor parte sobre Secure Enclaves é que podemos criar uma chave privada dentro de Secure Enclaves apenas com autenticação biométrica, o que permite uma experiência de integração com apenas um clique com a melhor segurança disponível em dispositivos modernos - nível de hardware. Mas também tem algumas desvantagens:

• A verificação P256 sem RIP-7212 é cara e aumenta o risco de bugs.
• Uma vez que a chave não pode ser extraída, a recuperabilidade é uma função ausente aqui (Passkeys permite uma recuperabilidade limitada, mas não é suficiente)
• Se o domínio web da chave de acesso, ou aplicativo Secure Enclave (SE), parar de funcionar, os usuários não poderão acessar a chave privada, pois o Secure Enclave foi projetado para ser isolado e independente. Sem o aplicativo ou domínio web associado, não há como recuperar ou interagir com a chave privada, deixando os usuários incapazes de realizar operações criptográficas necessárias. - Vou explicar como resolver esse problema.

3. Soluções de gerenciamento de chaves baseadas em SSS

As soluções SSS (Shamir’s Secret Sharing) criam uma maneira de eliminar o único ponto de falha que os sistemas tradicionais de gerenciamento de chaves têm. Basicamente, elas dividem as chaves em diferentes partes e estabelecem um limiar para acessar a chave. Ao distribuir essas partes, o SSS garante que nenhuma entidade única detenha a chave inteira, aumentando assim a segurança.

Vamos examinar onde eles armazenam as chaves e como eles alcançam o quórum para acessar a chave privada. A maioria dos protocolos existentes usa três partes das chaves: uma parte é armazenada no dispositivo do usuário, uma é mantida em seu servidor (ou dentro de uma Rede de MPC) e uma é reservada como backup. Algumas aplicações, como o Google Drive, utilizam soluções de armazenamento em nuvem para armazenar essas partes das chaves.

Assim, os usuários delegam o controle de sua carteira a outras partes com um quórum. O MPC (cálculo multipartidário) é poderoso para delegar responsabilidades de gerenciamento de chaves a diferentes partes, mas também tem algumas desvantagens:

A maioria das soluções de MPC requer uma parte centralizada, e às vezes, o que eles chamam de descentralizado não é realmente descentralizado. MPC com AA é poderoso porque a rotação de chaves é possível, mas muitas soluções de MPC incluem alguma funcionalidade de gatekeeping. Além disso, em muitos casos, chaves anteriores podem ser usadas mesmo após a rotação, então é necessário confiar que as chaves são realmente descartadas. Algumas soluções de MPC podem censurar usuários, então confiar exclusivamente em MPC nem sempre é viável.

Outra grande desvantagem do SSS é que ele reconstrói a chave privada, geralmente no navegador. É um risco de segurança enorme que uma chave de texto simples esteja disponível no lado do cliente. O TSS nunca reconstrói a chave e usa o MPC para federar a assinatura em partes da chave.

4. Soluções TEE Baseadas em Nuvem

Eu não acho que os Ambientes Executados com Confiança Baseados em Nuvem (TEEs) e soluções baseadas em SSS sejam tão diferentes, mas ainda queria explicar como eles funcionam. Ambientes Executados com Confiança funcionam exatamente como são codificados; eles são imutáveis (pelo menos dizem ser), e TEEs não mostram o que está dentro, mesmo para o proprietário do TEE. Eles são projetados para funcionar com integridade - fazendo a coisa certa mesmo que ninguém esteja observando. Então, as chaves nunca são expostas ao cliente assim que os TEEs estão fazendo seu trabalho corretamente.

Ao utilizar TEEs, podemos construir camadas de gestão de chaves onde os desenvolvedores podem usar diferentes métodos de autenticação, e o TEE pode verificá-los. Após a verificação, o TEE assina uma mensagem com a chave privada associada ao usuário e a verifica na cadeia.

A chave privada principal que controla os fundos dos usuários é armazenada dentro do TEE e não pode ser extraída. Isso ameaça a descentralização porque, se o serviço decidir fechar ou censurar os usuários, não há nada que um construtor de dApp possa fazer.

TEE baseado em nuvem parece promissor na teoria, mas no passado, vimos vulnerabilidades comosgx.failem TEEs em nuvem. No entanto, a vantagem de TEEs é que mesmo que haja uma porta dos fundos ou vulnerabilidade, o atacante precisaria de acesso físico ao TEE, razão pela qual o hardware do consumidor (Enclave Seguro - Passkeys) é tão poderoso, pois o hardware do consumidor armazena a chave dentro do Enclave Seguro dos usuários e apenas o proprietário pode acessar a chave, enquanto TEEs em nuvem armazenam as chaves dentro de uma nuvem e isso torna vulnerável a ataques.

Não é o seu enclave seguro, não são as suas moedas.

Como mencionei, TEEs têm algumas vantagens, como o uso de quase todos os métodos de autenticação sem quaisquer bloqueadores criptográficos. No entanto, eles também têm algumas desvantagens:

Se os provedores de serviços desligarem o servidor, os fundos dos usuários são congelados e ninguém pode acessá-los. As chaves são armazenadas dentro do Cloud TEE, o que significa que eles podem censurar os usuários. Depender exclusivamente de TEEs para o gerenciamento de chaves cria um único ponto de falha.

Chaves de sessão: Uma nova forma de permissões limitadas

Nós falamos sobre chaves permanentes. E se pudermos gerar uma chave temporária que tenha acesso limitado aos ativos e desapareça após um tempo determinado pelo usuário? A Chave de Sessão nos permite fazer isso:

No mundo web2, as chaves de sessão são como senhas temporárias usadas durante uma conversa entre dois dispositivos (como seu computador e um servidor). Elas são criadas no início da conversa, usadas para manter a segurança das informações compartilhadas e depois descartadas após o término da conversa. Portanto, mesmo que um hacker de alguma forma descubra essa senha, ele não pode usá-la para ouvir conversas futuras, pois uma nova senha (ou chave de sessão) diferente é criada a cada vez.

Assim como no mundo Web3, definimos chaves de sessão como uma estrutura que pode potencialmente mudar a forma como os usuários interagem com dApps. O objetivo das chaves de sessão é permitir que os usuários definam pré-aprovações por um tempo específico em uma variedade de cenários e realizem transações sem assinar. Mas como isso funciona?

Os usuários criam uma chave de sessão de permissões limitadas que podem gastar ativos apenas conforme especificado pelo usuário, por um período limitado de tempo e que pode ser revogada a qualquer momento. Depois disso, um serviço de back-end permite que os usuários realizem transações assinando em seu nome. Essa configuração cria uma janela de confiança temporária entre o dApp e os usuários. É muito melhor do que aprovações infinitas, porque a aprovação que os usuários dão é apenas para ativos específicos e por um período definido. Mesmo que o dApp seja hackeado, os usuários não precisam se preocupar com uma chave de sessão criada meses atrás 🙂.

Melhores combinações de autenticação e gerenciamento de chaves para diferentes casos de uso

Eu expliquei diferentes sistemas de gestão de chaves e seus prós e contras. Com o poder do AA, podemos combinar esses sistemas de gestão de chaves e criar estruturas poderosas com mínimos trade-offs. Vamos explicar C.1) Passkey + recuperação com timelock - Clave - uma aplicação fintech que armazena fundos valiosos.

Métodos de autenticação baseados em Enclave Seguro (chaves de acesso) oferecem segurança a nível de hardware; no entanto, sua capacidade de recuperação muitas vezes é insuficiente para a maioria dos usuários. Felizmente, AA permite que os desenvolvedores combinem diferentes métodos de assinatura e os usem em uma conta. Ao adicionar um signatário de recuperação a uma conta inteligente, podemos resolver o problema de recuperação que as chaves de acesso apresentam.

Existem várias opções de recuperação, como recuperação social, recuperação universal (recuperação baseada em ZK-Email) e recuperação baseada em MPC. No entanto, na minha opinião, para um aplicativo fintech projetado para ser totalmente auto-custodial, a recuperação social resolve a maioria dos problemas. Na Clave, construímos um módulo de recuperação social e estamos trabalhando na Recuperação Universal.

Esta abordagem maximiza a segurança, o que é ótimo para aplicações financeiras. Mas tem uma importante desvantagem: o aplicativo requer autenticação biométrica para cada transação que o usuário deseja fazer. Imagine que você queira compartilhar um conteúdo em um aplicativo de mídia social e o aplicativo exiba uma tela de autenticação biométrica... Terrível, não é?

Aplicações não financeiras como aplicativos sociais-Fi e jogos descentralizados precisam de uma maneira mais fácil de realizar transações, idealmente sem exigir que os usuários assinem cada transação. Como? Aqui está a resposta:

1. Passkey + recuperação com timelock + chaves de sessão - aplicativo social móvel

As chaves de sessão permitem que os usuários façam transações sem uma tela de assinatura. Jogos ou aplicativos sociais baseados em NFTs podem herdar chaves de sessão para ter acesso temporário e limitado aos ativos dos usuários. Se você acha que isso adiciona uma suposição extra de confiança, vamos explicar como os fronts de hoje funcionam:

Hoje em dia, a maioria dos usuários nem sequer verifica o que estão assinando ao jogar um jogo ou interagir com um dApp. Isso é perigoso porque um front-end malicioso pode fazer com que os usuários percam todos os seus ativos.

As chaves de sessão são uma alternativa melhor para isso. Os usuários podem verificar por quanto tempo a sessão estará ativa e a quais ativos a sessão pode acessar, reduzindo a necessidade de confiar no dApp. Após o término do tempo da sessão, os usuários não precisam se preocupar com aprovações = Não há mais necessidade derevoke.cashgosto de aplicações :)

2. MPC ou assinante baseado em nuvem TEE + assinante auto-custodial para escapar

A desvantagem das camadas de gerenciamento de chaves de terceiros baseadas em MPC ou Cloud TEE é que a maioria delas não é autogerenciada e possui componentes centralizados significativos. No entanto, alguns dApps requerem carteiras embutidas sem sobrecarga adicional de gás, tornando necessárias soluções baseadas em MPC ou Cloud TEE. Adicionar um assinante adicional para o “rage quit” pode resolver o problema de censura desses sistemas de gerenciamento de chaves e também mitigar possíveis questões legais que esses dApps possam enfrentar. Você precisa de uma carteira inteligente para construir isso, porque a rotação de chaves não é possível com EOAs.

Já existem várias aplicações que utilizam esta arquitetura de gestão de chaves.

3. 12 palavras + Hardware Signer para maximizar a segurança - Experiência de extensão de navegador DeFi

Os usuários DeFi adoram a experiência da extensão do navegador, e mudar o comportamento do usuário é uma das coisas mais difíceis no mundo moderno. Então, por que não construir uma alternativa melhor? Combinar um assinante de hardware (Secure Enclave ou Passkey Signer) com frases de semente de 12 palavras acessíveis via uma extensão também poderia resolver o problema das chaves privadas vazadas. Esta abordagem melhora a segurança sem a necessidade de alterar o comportamento dos usuários. Várias equipes na indústria AA estão trabalhando para viabilizar isso. (por exemplo, @myBraavos)

Contas inteligentes não são inteligentes o suficiente

Imagine que você é um usuário que primeiro gerou um EOA com @MetaMaske depois descobriu uma alternativa como Zerion. Você decide usar @zerion, e tudo o que você precisa fazer é importar sua frase-semente - simples. Agora, imagine tentar fazer o mesmo na Starknet, onde todas as carteiras são contas inteligentes. Você não pode, porque Braavos e Argent não são compatíveis. Esse problema também existe no ecossistema EIP-4337 e@zkSyncAA nativo da gate.

Precisamos de padrões (não gatekeepers) ou pelo menos uma maneira melhor de financiar novas carteiras. Caso contrário, nunca haverá adoção generalizada de carteiras inteligentes, e os players existentes permanecerão como os tomadores de decisão, ditando práticas do setor mesmo que não estejam corretas.

Além disso, 'rage quit' deve ser um recurso padrão, pois atores centrais em quase todos os sistemas de gerenciamento de chaves podem ser desligados. Deve ser mais fácil para os usuários alterarem signatários ou alternarem contratos inteligentes, e o auto-hospedagem deve ser a opção padrão para os usuários. Existem dois padrões modulares de contas inteligentes: ERC-6900 e ERC-7579. Ambos estão tentando alcançar um objetivo semelhante - tornar as contas inteligentes mais inteligentes.

Agradecimentos especiais aDerek ,Konrad, eNoampara feedback e comentários!

Aviso Legal:

1. Este artigo é republicado de [X]. Todos os direitos autorais pertencem ao autor original [2077Research]. Se houver objeções a este reenvio, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem conselho de investimento.
3. A equipe de tradução da Gate Learn traduziu o artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.