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

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

Avançando além de 12 palavras

A nossa indústria adora palavras da moda, e “sem sementes” é uma das mais recentes a captar a atenção. Embora todos concordemos que esperar que os utilizadores armazenem as suas chaves privadas de forma segura é impraticável e resultou na perda de milhões de dólares, a questão permanece: se não mostrarmos aos utilizadores as frases-semente, onde armazenamos as chaves?

Sem a Abstração de Conta (AA), a maioria das soluções existentes depende da Computação Multipartidária (MPC) para distribuir chaves em várias partes e criar um limite para fazer transações. Essas soluções muitas vezes afirmam ser auto-custodial. No entanto, isso não é totalmente exato. Por exemplo, a Binance armazena uma parte da chave, agindo como um custodiante no caso de os usuários perderem seus dispositivos. Essa configuração significa que, apesar das declarações, os usuários não estão realmente no controle de 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 divulgada, não há como revogar a chave da conta principal. A revogação é impossível porque as Contas Proprietárias Externas (EOAs) não suportam 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 chaves comprometidas não podem ser substituídas ou removidas, deixando a conta vulnerável indefinidamente.

Se quiser saber mais sobre como o AA abre o caminho para contas programáveis e rotação de chaves, podeverificar o meu artigo.

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

A Abstração de Conta permite aos desenvolvedores construir diferentes sistemas de gestão de chaves. Uma conta pode ser controlada com várias chaves e diferentes métodos de autenticação, todos suportando rotação de chaves. Ainda melhor, o poder das chaves pode ser diferenciado. Isto significa que os utilizadores podem usar diferentes chaves para a mesma conta, cada uma adaptada a diferentes casos de uso. Mais tarde, irei explicar estes casos de uso com mais detalhe.

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 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, 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. Isto significa que podemos definir o poder das chaves, adicionar um bloqueio de tempo ou ativar 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, assim os programadores podem definir um esquema de controlo 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 gestão de chaves) no espaço criptográfico que podem permitir esquemas de controlo de acesso baseados em funções, e usar apenas uma chave não pode resolver todos os problemas associados à gestão de chaves. Os aspetos mais importantes dos sistemas de gestão 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 Chaves de Acesso (Enclaves Seguros para Consumidores), Soluções Baseadas em MPC, Soluções Baseadas em TEE em Nuvem, Soluções de Custódia, Palavras Tradicionais de 12 e Chaves de Sessão. Depois disso, explicarei as melhores combinações.

1. 12 palavras tradicionais - (secp256k1) -

Bitcoin e Ethereum suportam osecp256k1Algoritmo 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 inteligentesPara o utilizar, a aplicação da carteira gera uma chave privada através de um algoritmo de geração de chaves aleatórias e depois armazena a chave privada em armazenamento partilhado.

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

No entanto, existem algumas desvantagens:

1. É desafiador educar os usuários sobre o armazenamento seguro de suas chaves no caso de perderem seus dispositivos.
2. Um trojan ou malware poderia roubar a chave privada dos dispositivos dos usuários, uma vez que ela é armazenada em armazenamento compartilhado.

NIST não suporta a curva secp256k1, o que significa que não é comumente suportada por frameworks populares e pela maioria do hardware.

2. Passkeys (Enclaves de Segurança do Consumidor)

Quase todos os dispositivos modernos têm dois componentes principais: um sistema operativo (com armazenamento partilhado associado) e uma Enclave Segura. O sistema operativo lida com a maioria das operações, exceto tarefas sensíveis como proteger dados biométricos, chaves criptográficas, encriptação 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, gerencia 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 oferece suporte a operações criptográficas, como criar chaves privadas e assinar mensagens com elas. Infelizmente, o Secure Enclave não oferece suporte à 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 equipa) propôs oRIP-7212e quase todos os grandes rollups agora o suportam.

E a melhor parte sobre Enclaves Seguros é que podemos criar uma chave privada dentro dos Enclaves Seguros com apenas autenticação biométrica, o que possibilita uma experiência de integração com apenas um clique, com a melhor segurança disponível em dispositivos modernos - a 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 característica ausente aqui (Passkeys permite uma recuperabilidade limitada, mas não é suficiente)
• Se o domínio web da palavra-passe ou da aplicação Secure Enclave (SE) deixar de funcionar, os utilizadores não conseguem aceder à chave privada porque o Secure Enclave foi concebido para ser isolado e independente. Sem a aplicação ou o domínio web associado, não há forma de recuperar ou interagir com a chave privada, deixando os utilizadores incapazes de realizar operações criptográficas necessárias. - Vou explicar como resolver este problema.

3. Soluções de gestão de chaves baseadas em SSS

As soluções SSS (Compartilhamento Secreto de Shamir) criam uma forma de eliminar o único ponto de falha que os sistemas tradicionais de gestão de chaves têm. Essencialmente, dividem as chaves em diferentes partes e estabelecem um limiar para aceder à chave. Ao distribuir estas partes, o SSS garante que nenhuma entidade detém a chave completa, aumentando assim a segurança.

Vamos examinar onde eles armazenam as chaves e como 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 no servidor deles (ou dentro de uma Rede de MPC) e uma é reservada como backup. Algumas aplicações, como o Google Drive, utilizam soluções de armazenamento na nuvem para armazenar essas partes das chaves.

Assim, os usuários delegam o controle de sua carteira para outras partes com um quórum. O MPC (Computação Multi-Partes) é 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, por vezes, o que chamam de descentralizado não é verdadeiramente descentralizado. MPC com AA é poderoso porque a rotação de chaves é possível, mas muitas soluções de MPC incluem alguma funcionalidade para o controle de acesso. 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 depender exclusivamente de MPC nem sempre é viável.

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

4. Soluções baseadas em TEE na nuvem

Não acho que os Ambientes de Execução Confiáveis Baseados em Nuvem (TEEs) e as soluções baseadas em SSS sejam tão diferentes, mas ainda queria explicar como funcionam. Os Ambientes de Execução Confiáveis funcionam exatamente como são codificados; eles são imutáveis (pelo menos afirmam ser), e os TEEs não mostram o que está dentro nem mesmo para o proprietário do TEE. Eles são projetados para funcionar com integridade - fazendo a coisa certa mesmo se ninguém estiver observando. Portanto, 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 verifica-a 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.

As TEEs baseadas na cloud parecem promissoras na teoria, mas no passado, vimos vulnerabilidades como sgx.failem TEEs em nuvem. No entanto, a vantagem das TEEs é que mesmo que haja uma porta dos fundos ou vulnerabilidade, o atacante precisaria de acesso físico ao TEE, é por isso que 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 somente o proprietário pode acessar a chave, enquanto os TEEs em nuvem armazenam as chaves em uma nuvem e isso os torna vulneráveis a ataques.

Não é a sua área de segurança, não são as suas moedas.

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

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

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

Já falamos sobre chaves permanentes. E se pudermos gerar uma chave temporal que tenha acesso limitado a ativos e desapareça após um tempo que o usuário decida? 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 o seu computador e um servidor). Elas são criadas no início da conversa, usadas para manter a informação compartilhada segura e depois descartadas após o fim da conversa. Assim, mesmo que um hacker de alguma forma descubra esta senha, ele não pode usá-la para ouvir futuras conversas, porque uma nova senha (ou chave de sessão) diferente é criada a cada vez.

Como no mundo Web3, definimos chaves de sessão como um framework que pode potencialmente alterar a forma como os utilizadores interagem com dApps. O objetivo das chaves de sessão é permitir que os utilizadores definam pré-aprovações por um período específico em várias situações e efetuem transações sem assinatura. Mas como funciona?

Os usuários criam uma permissão limitada como uma chave de sessão que pode gastar ativos apenas conforme especificado pelo usuário, por um período limitado de tempo e pode ser revogada a qualquer momento. Depois disso, um serviço de backend 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 se o dApp for 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 gestão de chaves para diferentes casos de uso

Expliquei diferentes sistemas de gestão de chaves e os seus prós e contras. Com o poder do AA, podemos combinar esses sistemas de gestão de chaves e criar estruturas poderosas com compromissos mínimos. 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 Secure Enclave (passkeys) proporcionam segurança a nível de hardware; no entanto, a sua recuperabilidade é frequentemente insuficiente para a maioria dos utilizadores. Felizmente, o AA permite aos programadores combinar diferentes métodos de assinatura e utilizá-los numa única conta. Ao adicionar um signatário de recuperação a uma conta inteligente, conseguimos resolver o problema de recuperabilidade que as passkeys têm.

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 uma aplicação fintech que é projetada 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 a trabalhar na Recuperação Universal.

Esta abordagem maximiza a segurança, o que é ótimo para aplicações financeiras. Mas tem uma desvantagem importante: a aplicação requer autenticação biométrica para cada transação que o utilizador pretende fazer. Imagine que deseja partilhar um conteúdo numa aplicação de redes sociais e a aplicação mostra um ecrã de autenticação biométrica... Terrível, não é?

Aplicações não financeiras como apps sociais-Fi e jogos descentralizados precisam de uma forma 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 bloqueio temporal + 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 baseados em NFT ou aplicativos sociais 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 front-ends de hoje funcionam:

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

As chaves de sessão são uma alternativa melhor para isso. Os usuários podem verificar 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 necessidaderevoke.cashgosto de aplicações :)

2. Assinador baseado em MPC ou cloud TEE + assinador de auto-custódia para escapar

A desvantagem das camadas de gestão de chaves de terceiros baseadas em MPC ou Cloud TEE é que a maioria delas não é auto-custodial e tem componentes centralizados significativos. No entanto, algumas dApps requerem carteiras embutidas sem despesas extras de gás, necessitando de soluções baseadas em MPC ou Cloud TEE. Adicionar um signatário extra para o "rage quit" pode resolver o problema de censura que esses sistemas de gestão de chaves têm e também mitigar possíveis questões legais que essas dApps possam enfrentar. Você precisa de uma carteira inteligente para construir isso, pois 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 do navegador DeFi

Os utilizadores de DeFi adoram a experiência da extensão do navegador, e mudar o comportamento do utilizador é 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 através de uma extensão também poderia resolver o problema das chaves privadas vazadas. Essa abordagem melhora a segurança sem a necessidade de alterar o comportamento dos utilizadores. Várias equipes na indústria AA estão trabalhando para possibilitar isso. (por exemplo. @myBraavos)

Contas inteligentes não são suficientemente inteligentes

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 precisa fazer é importar sua frase de segurança - simples. Agora, imagine tentar fazer o mesmo no 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 .

Precisamos de padrões (não guardiões) ou pelo menos uma maneira melhor de financiar novas carteiras. Caso contrário, nunca haverá uma adoção generalizada de carteiras inteligentes, e os players existentes continuarão a ser os tomadores de decisão, ditando práticas da indústria mesmo que não estejam corretas.

Além disso, "rage quit" deve ser uma funcionalidade padrão, pois os atores centrais em quase todos os sistemas de gerenciamento de chaves podem ser desligados. Deve ser mais fácil para os usuários alterarem os signatários ou trocarem de contratos inteligentes, e a 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, eNoam para feedback e comentários!

Aviso legal:

1. Este artigo é reimpresso de [X]. Todos os direitos autorais pertencem ao autor original [2077Research]. Se houver objeções a esta reimpressão, entre em contato com a Gate Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem um conselho de investimento.
3. A equipe do Learn da Gate traduziu o artigo para outras línguas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.