TL;DR

A chave privada é o núcleo que nos permite assinar transações no Ethereum, mas gerenciá-la tem sido um pesadelo, mesmo na forma legível de “frases-semente”. No entanto, nosso objetivo nunca foi transformar a blockchain em um jogo sofisticado.

Autenticar usuários autorizados é crucial para transações seguras. Com a evolução da segurança na internet e da experiência do usuário, passamos da autenticação por senha para biometria como reconhecimento facial e impressões digitais. WebAuthn é um desenvolvimento chave nessa progressão. Este artigo discute de perto três termos:

WebAuthn: Um padrão de autenticação web que utiliza credenciais baseadas em chave pública, frequentemente criadas por autenticadores externos. Ele elimina a necessidade de senhas e permite autenticação segura do usuário.

Enclave Seguro: Uma área segura baseada em hardware dentro de dispositivos de computação, o Enclave Seguro é projetado para proteger dados sensíveis. Versões de um Enclave Seguro são encontradas em dispositivos iOS, Android e Windows. Ele pode servir como um autenticador seguro ao implementar o WebAuthn, mas a chave privada, vinculada ao ES, frequentemente apresenta desafios entre dispositivos.

Passkey: Uma implementação do WebAuthn ao nível do sistema operacional, personalizada por vários fornecedores de dispositivos e sistemas. Por exemplo, o Passkey da Apple usa a chave armazenada no iCloud Keychain para sincronização entre dispositivos. No entanto, essa abordagem geralmente está limitada a plataformas ou sistemas específicos.

Como descrito acima, as implementações do webAuthn estão alinhadas com nosso objetivo para os usuários diários de blockchain, para alcançar alta segurança contra phishing e uma experiência amigável. Aqui está a ideia de fundi-los no blockchain:

Camada Chave: Os usuários se autenticam usando métodos biométricos contínuos, como reconhecimento facial ou impressão digital. Sob o capô, é o processador de segurança baseado em hardware, como o Enclave Seguro ou serviços em nuvem como iCloud e Google Cloud, que lidam com o gerenciamento de chaves. Mais tarde, abordarei as questões de interoperabilidade entre dispositivos e plataformas.

Camada de conta: Uma conta de contrato inteligente (SCA) oferece a capacidade de atribuir signatários arbitrários (por exemplo, SE e chave de acesso) e mecanismos de limite. Além disso, seu design modular aumenta a flexibilidade e a capacidade de atualização. Por exemplo, um SCA pode adaptar seus requisitos de assinatura dinamicamente com base em fatores como quantidade de transação, tempo ou endereço IP. Por outro lado, uma Conta de Propriedade Externa (EOA) tradicional pode ser aumentada com serviços MPC, sua combinação oferece melhor interoperabilidade e custo-benefício em comparação com o SCA, embora não tenha funcionalidades avançadas que os SCAs fornecem, especialmente para rotação de chaves.

Camada de assinatura: O Ethereum suporta nativamente a curva k1, mas a verificação de assinatura do WebAuthn incorre em custos mais altos, já que usa a curva r1 para geração de chaves. Portanto, algumas soluções de Camada 2 como zkSync, planejando pré-compilações de curva EIP-7212 r1 nativas. Além disso, há serviços de terceiros, verificadores de solidez, verificadores de conhecimento zero (ZK) e sistemas de gerenciamento de chaves distribuídas, para facilitar a assinatura da curva r1 de maneira mais econômica.

Isenção de responsabilidade:

O avanço tecnológico não garante o sucesso de mercado; Nem todos os dispositivos e plataformas adotaram a Passkey; O uso do SCA pode ser mais caro do que o EOA; A solução proposta evolui com o progresso tecnológico.

Crypto UX é uma porcaria? A gestão de chaves é uma porcaria!

No reino do blockchain, o controle real dos ativos blockchain não está nas mãos do usuário ou do provedor da carteira, mas sim na chave privada. Essa chave é a mais integral para todo o processo de execução de uma transação no Ethereum. Para entender melhor isso, vamos tomar o EOA como exemplo:

Geração de Chave: Um número aleatório selecionado da curva elíptica secp256k1 serve como chave privada. Essa chave é então multiplicada por um ponto predefinido na curva para gerar a chave pública. O endereço Ethereum é derivado dos últimos 20 bytes da chave pública hash. A 'frase-semente' geralmente é introduzida para backup legível por humanos, permitindo a derivação determinística das chaves privadas e públicas.

Assinatura de transações: Uma transação, contendo detalhes como nonce (um número sequencial), valor, preço do gás e endereço do destinatário, é assinada usando a chave privada. Esse processo, envolvendo o ECDSA, um algoritmo de assinatura digital que usa criptografia de curva elíptica e adota secp256k1 como a curva, gera uma assinatura consistindo de valores (r, s, v). A assinatura e a transação original são então transmitidas na rede.

Verificação de Transações: Uma vez que uma transação atinge os nós do Ethereum, ela passa por um processo de validação na mempool do nó. Para verificar o signatário, os nós usam a assinatura e a transação hash para derivar a chave pública do remetente e confirmar a autenticidade da transação, combinando o endereço derivado com o remetente.

Como descrito acima, a chave privada é uma entidade essencial on-chain. Originalmente, contas Ethereum, conhecidas como Contas de Propriedade Externa (EOAs), dependiam exclusivamente de uma única chave privada, o que representava riscos significativos, uma vez que perder a chave significava perder o acesso à conta.

Muitos podem pensar que a Abstração de Conta (AA) é a solução para tudo relacionado à má experiência do usuário, o que eu diria que não exatamente. AA trata de mudar as regras de validade para serem programáveis, e a programabilidade da Conta de Contrato Inteligente (SCAs) torna isso possível. AA é poderoso, permite o envio de várias transações em paralelo (nonce abstrato), patrocínio de gás e pagamento de gás em ERC20 (gás abstrato), e mais relevante para o tema deste artigo, para quebrar a validação de assinatura fixa (assinatura ECDSA abstrata). Em vez de EOA, SCAs podem atribuir signatários arbitrários e mecanismos de assinatura como multi-assinatura (multisigs) ou chaves de escopo (chaves de sessão). No entanto, apesar da flexibilidade e avanço de atualização da AA, a dependência fundamental de chave(s) para a assinatura de transação permanece inalterada.

Mesmo ao ser convertida em uma frase-semente de 12 palavras, gerenciar uma chave privada continua sendo um desafio, apresentando riscos de perda ou ataques de phishing. Os usuários devem navegar entre camadas complexas de soluções descentralizadas ou o abraço caloroso de serviços centralizados, nenhum deles é ideal.

Por que a experiência cripto é uma? Grande parte disso é porque a gestão de chaves é uma. Sempre requer compensações em experiência, segurança e descentralização. Este artigo explora possíveis soluções ideais para gerenciar a chave.

Camadas de Gerenciamento de Chave

Nunca haverá uma solução única que sirva para todos, a melhor maneira de preservar a chave é adaptada aos cenários específicos do usuário, influenciada por fatores como tipo de usuário (institucional ou individual), montante de capital, frequência de transações e tipos de interação.

Para esclarecer antecipadamente, evito usar os métodos populares de 'auto, semi e totalmente custódia' para catalogar. Na minha opinião, a verdadeira auto custódia significa assinar uma transação de forma independente, sem depender de outra parte, mesmo que a solução não seja custodial no sentido tradicional (como ser armazenado nos nós descentralizados TEE). Classificar as soluções meramente como 'boas' ou 'ruins' com base no tipo de custódia é excessivamente simplista e não leva em consideração sua adequação variada. Para uma avaliação mais detalhada dos métodos de gerenciamento de chaves, sugiro analisá-los por meio de três camadas distintas:

Responsabilidade

Se deve dividir a responsabilidade de gerenciar uma chave entre diferentes partes.

Dado que os indivíduos muitas vezes enfrentam desafios na gestão da chave, distribuir a responsabilidade de salvaguardar a chave emerge como uma estratégia natural de mitigação de riscos. Essa categoria inclui métodos como o uso de várias chaves para assinar colaborativamente, como visto em sistemas Multi-Signature (Multi-sig), e a divisão da chave privada em compartilhamentos por meio de um Esquema de Compartilhamento Secreto (SSS) ou Multi-Party Computation (MPC).

Multi-sig: Exigir múltiplas chaves privadas completas para gerar assinaturas de transação. Este método requer comunicação on-chain sobre os diferentes signatários, acarretando em taxas de transação mais altas e impactando a privacidade, uma vez que o número de signatários é visível on-chain.

SSS: uma chave privada é gerada em um único local, e um distribuidor distribui partes desta chave para diferentes partes. Todas as partes devem reconstruir a chave privada completa para assinar uma transação. No entanto, esta reconstrução temporária pode introduzir vulnerabilidades.

MPC-TSS(Esquema de Assinatura de Limiar): como uma implementação do MPC, uma abordagem criptográfica que permite que várias partes realizem cálculos mantendo suas entradas privadas em conjunto. Cada parte cria independentemente uma parte da chave secreta, e as transações são assinadas sem que essas partes precisem se encontrar fisicamente. Ele introduz taxas mais baixas porque está fora da cadeia, e não há risco de ponto único de falha como SSS.

Armazenamento

Armazene a chave ou as ações, afetadas pelos fatores de segurança, acessibilidade, custo e descentralização.

Serviços de nuvem centralizados como AWS, iCloud e outros servidores. Eles são convenientes para transações frequentes, mas mais vulneráveis à censura.

Armazenamento descentralizado como IPFS e Filecoin.

Computador/celular local: As chaves são armazenadas localmente dentro do armazenamento seguro do navegador.

Carteiras de papel: Impressão física de chaves privadas ou códigos QR.

Ambiente de Execução Confiável (TEE): O TEE fornece uma área segura dentro do processador principal para executar ou armazenar dados sensíveis, isolados do sistema operacional principal.

Enclave Seguro: O Enclave Seguro em dispositivos modernos é isolado do processador principal para fornecer uma camada extra de segurança e é projetado para manter os dados sensíveis do usuário seguros mesmo quando o kernel do Processador de Aplicativos é comprometido.

Carteiras de hardware: dispositivos físicos como Ledger e Trezor, projetados especificamente para armazenar chaves privadas com segurança.

Módulo de Segurança de Hardware (HSM): HSMs são dispositivos de hardware especializados projetados para gerenciamento seguro de chaves e operações criptográficas. Eles são tipicamente usados em ambientes corporativos e oferecem recursos de segurança de alta qualidade.

Acesso

Como verificar a identidade do usuário para acessar a chave armazenada

A autenticação está envolvida no acesso à chave armazenada. Trata-se de validar que o indivíduo que tenta acessar tem de fato autorização para fazê-lo. Olhando para a história, podemos categorizar a história assim:

Algo que você sabe: senhas, PINs, respostas a perguntas de segurança ou padrões específicos.

Algo que você tem: Inclui cartões inteligentes, tokens de hardware (senhas únicas baseadas em tempo) ou fatores digitais como verificação de conta social e códigos SMS enviados para um telefone.

Alguém que você é: Envolva características físicas exclusivas do usuário, como impressões digitais, reconhecimento facial (como o Face ID da Apple ou o Windows Hello), reconhecimento de voz ou varreduras de íris/retina.

Sobre estes, 2FA e MFA são métodos que combinam dois ou mais fatores, como notificação por push combinada por SMS, para adicionar mais camadas de segurança às contas de usuário.

Análise de Jogadores Existente

MetaMask permite aos usuários usar uma senha para acessar a chave armazenada no armazenamento local do navegador do usuário.

Trust Wallet permite aos usuários usar uma senha ou faceID para acessar a chave armazenada no armazenamento local do navegador do usuário, o usuário também pode escolher um serviço de nuvem para fazer backup da chave privada.

O Privy permite que os usuários usem vários métodos de login social, como e-mail, usando o SSS para dividir três compartilhamentos:

Compartilhamento de dispositivo: Navegador-iFrame, móvel-enclave seguro.

Auth share: Armazenado pelo privy, link para o id privy).

Recuperação compartilhada: senha do usuário ou criptografada pelo Privy armazenada no módulo de segurança de hardware (HSM).

Particle permite que os usuários usem login social, usando MPC-TSS que tem duas partes:

Compartilhamento de dispositivo: navegador-iFrame

Compartilhamento da chave do servidor: servidor da Particle

Nova Solução

Camada chave: WebAuthn, Secure Enclave e Passkey

As soluções existentes acima foram fundamentais para apresentar os usuários à web3. No entanto, muitas vezes elas vêm com desafios: as senhas podem ser esquecidas ou ser alvo de ataques de phishing, e até mesmo a autenticação de dois fatores, embora mais segura, pode ser complicada com suas múltiplas etapas. Além disso, nem todos se sentem confortáveis em confiar a gestão de chaves a um terceiro, os usuários ainda dependem da disponibilidade e vivacidade de seus sistemas, enquanto alguns serviços garantem que não podem acessar a chave.

Isso nos leva a refletir se há uma solução mais eficaz - uma que ofereça a solução mais próxima de uma experiência de usuário sem confiança, alta segurança e sem interrupções. Essa busca nos leva aos métodos web2 ótimos. Vários termos estão fortemente relacionados ao tópico, como descrevi no início do artigo, WebAuthn é o próprio padrão de autenticação, enquanto Secure Enclave e Passkey são implementações ou componentes relacionados a esse padrão.

WebAuthn

A WebAuthn padroniza a interface de autenticação de usuários em aplicativos baseados na web. Ele permite que os usuários façam login em contas da internet usando autenticadores externos, em vez de uma senha. Os autenticadores podem ser Autenticadores de Roaming (Yubikey, chave Titan) ou um Autenticador de Plataforma (chave embutida no chaveiro em dispositivos Apple), e assim por diante.

A Aliança FIDO (Fast IDentity Online) desenvolveu inicialmente as tecnologias por trás do WebAuthn. Foi oficialmente declarado um padrão da web pelo W3C em março de 2019 e, juntamente com sua padronização, grandes navegadores como Google Chrome, Mozilla Firefox, Microsoft Edge e Apple Safari adotaram o WebAuthn, aumentando significativamente sua abrangência e usabilidade. Agora é suportado por muitos dispositivos avançados.

Benefícios do webAuthn:

Segurança aprimorada: Elimina a dependência de senhas, reduzindo a vulnerabilidade a phishing, força bruta e ataques de repetição.

Experiência do Usuário Melhorada: Oferece um processo de login mais simples e rápido, muitas vezes com apenas um toque ou verificação biométrica.

Proteção de Privacidade: Nenhum segredo compartilhado é transmitido durante a autenticação, e os sites individuais não recebem nenhuma informação pessoal identificável.

Escalabilidade e Padronização: Como um padrão da web, o WebAuthn garante consistência e interoperabilidade entre diferentes navegadores e plataformas.

WebAuthn vinculado ao dispositivo, por exemplo, Enclave Seguro

Em casos modernos, podemos usar o processador de hardware como autenticador, como Secure Enclave para dispositivos Apple, Trustzone para Android e Strongbox para Google Pixel.

Geração de Chave: Utilizando criptografia de chave pública, um par de chaves é gerado de acordo com os padrões WebAuthn, normalmente utilizando a curva P-256 r1. A chave pública é enviada para o serviço, enquanto a chave privada NUNCA deixa o Enclave Seguro. O usuário nunca lida com a chave em texto simples, tornando difícil a comprometimento da chave privada.

Armazenamento de Chave: A chave privada é armazenada com segurança dentro do Secure Enclave do dispositivo, um subsistema fortificado segregado do processador principal. Ele protege dados sensíveis, garantindo que mesmo que o sistema principal seja comprometido, o material da chave bruta permaneça inacessível. A barreira para comprometer o Secure Enclave é extremamente alta e, portanto, os tipos de dados mais sensíveis, como Apple Pay e dados do FaceID, são armazenados lá. Aqui está uma explicação detalhada de como o SE funciona.

Autenticação: os usuários usam o reconhecimento facial ou impressão digital para acessar, a Cofre Seguro usando a chave privada para assinar um desafio do serviço e o serviço verifica usando a chave pública.

Vantagens do webAuthn baseado em dispositivo:

Segurança em nível de hardware: Usando o Secure Enclave, um gerenciador de chaves isolado baseado em hardware para fornecer uma camada extra de segurança.

Resistência à pesca: Não envolva a inserção de informações em dispositivos ou sites potencialmente comprometidos.

Experiência conveniente: Eles fornecem uma experiência mais amigável ao usuário. Os usuários não precisam mais lembrar de senhas complexas para sites diferentes.

Desvantagens do webAuthn baseado em dispositivo:

Restrições do dispositivo: A chave privada não pode ser exportada ou recuperada se o dispositivo for perdido ou danificado, a operação entre dispositivos é impossível.

WebAuthn baseado em nuvem, Chave de segurança

Abordando o desafio da funcionalidade entre dispositivos, gigantes da tecnologia introduziram a implementação baseada em nuvem do webAuthn, Passkey é amplamente conhecido por causa da Apple.

Vamos pegar a Passkey da Apple como exemplo:

Geração de chave: O dispositivo macOS, iOS ou iPadOS do usuário, como autenticador, gera um par de chaves pública-privada quando o usuário cria a conta. Em seguida, envia a chave pública para o servidor, e a chave privada é armazenada no keychain do iCloud do dispositivo. Os dados do iCloud Keychain são criptografados com um par de chaves vinculado ao hardware e armazenados em um módulo de segurança de hardware (HSM). A chave é inacessível para a Apple.

Sincronização entre dispositivos: Esse processo será o mesmo que acessar o iCloud. Autenticar na conta do iCloud, receber um código por SMS e inserir o código de acesso de um dos dispositivos.

Vantagens do webAuthn baseado em nuvem:

Cross-device: Passkeys foram projetados para serem convenientes e acessíveis de todos os dispositivos usados regularmente. Mas atualmente limitados a dispositivos Apple, para Android é mais desafiador devido às suas diversas versões e variações de hardware.

Resistência a Phishing: Igual ao acima.

Experiência Conveniente: Igual ao acima.

Chave de acesso baseada na nuvem contras:

Conte com o serviço de nuvem: Comparado ao webAuthn baseado em dispositivo, a chave de acesso baseada em nuvem eleva o nível de segurança do hardware do Secure Enclave para o chaveiro do iCloud, alguns podem argumentar que é custodial para o seu serviço de nuvem. Alguns aspectos-chave a considerar incluem: A conta de AppleID do usuário usada com o iCloud é comprometida; Embora o iCloud Keychain empregue criptografia de ponta a ponta para proteger os dados, erros operacionais ou vulnerabilidades representam um risco.

Restringir à plataforma: Por exemplo, usar uma senha baseada no iCloud em um dispositivo Android é extremamente desafiador. Além disso, ao contrário dos métodos tradicionais, a Apple e o Google não enviam assertivas específicas do dispositivo. Isso significa que atualmente é impossível verificar o tipo de dispositivo que gerou uma chave, o que levanta questões sobre a confiabilidade da chave e seus metadados associados.

Camada da Conta: SCA e EOA

Até agora, podemos ver que manter a segurança a nível de hardware ao mesmo tempo em que se aborda a compatibilidade entre dispositivos e plataformas é desafiador. Igualmente crucial é a opção de recuperação social, como adicionar vários guardiões para segurança aprimorada. Nesse contexto, a blockchain pode nos mostrar um caminho.

Uma lacuna significativa quando tentamos implementar web2 webAuthn para web3: o Web2 só exige a comprovação da propriedade, enquanto o web3 também exige autorizar a transação simultaneamente. Com o Passkey, os desenvolvedores não têm controle sobre a mensagem de assinatura, que é tipicamente genérica, como 'entrar'. Isso pode levar à manipulação potencial do front-end, os usuários assinando mensagens às cegas - uma preocupação aparentemente menor, mas crucial.

Contas de Contrato Inteligente (CCI), inerentemente contratos inteligentes em si mesmos, funcionam como entidades on-chain, capazes de atribuir signatários arbitrários. Essa flexibilidade permite a programação de vários dispositivos e plataformas - como configurar um telefone Android, um Macbook e um iPhone - como signatários. Ainda mais, a Conta de Contrato Inteligente Modular permite a atualização, a troca de novos signatários, a alteração do limite de assinatura de 2 em 3 para configurações ainda mais complexas.

Imagine uma carteira que adapta seus requisitos de segurança com base no contexto: permite autenticação de um único signatário quando o usuário está em um endereço IP local familiar, mas requer vários signatários para transações de endereços IP desconhecidos ou acima de um certo valor. Com modularidade e programabilidade, nossa imaginação é o único limite para tais inovações. Muitos provedores de serviços de SCA constroem ativamente esse espaço, incluindo Safe, Zerodev, Biconomy, Etherspots, Rhinestone, etc. Também um grande reconhecimento à infraestrutura como Stackup, Plimico, Alchemy que tornam isso possível.

Por favor, verifique se minha pesquisa anterior fornece um contexto mais abrangente sobre SCA.

EOAs podem alcançar recuperação social e compatibilidade entre dispositivos/plataformas por meio de serviços de MPC. Apesar de EOAs possuírem signatários fixos, os provedores de MPC podem dividir chaves em partes para segurança e flexibilidade aprimoradas. Este método carece dos recursos programáveis e atualizáveis do SCA, como recuperação por timelock e desativação fácil de chaves. No entanto, ainda oferece capacidades superiores de interconexão entre cadeias por ser agnóstico em relação às cadeias e atualmente é mais econômico do que o SCA. Notáveis provedores de MPC incluem Privy, Particle Network, web3Auth, OKX wallet, Binance wallet, etc.

Camada de Assinatura: suporte R1

Vamos dar um passo atrás para entender o contexto: No Ethereum, as chaves privadas são números aleatórios selecionados a partir da curva k1, e o processo de assinatura também utiliza essa curva.

No entanto, os pares de chaves gerados de acordo com os padrões WebAuthn utilizam a curva r1. Portanto, verificar uma assinatura r1 no Ethereum é aproximadamente três vezes mais caro do que uma assinatura k1. Aqui estão algumas abordagens para lidar com isso:

Crédito para Dogan, para um conhecimento mais aprofundado, por favor, verifique a sua pesquisa.

Solução do Protocolo:

Solução: EIP7212, Pré-compilado para suporte à Curva secp256r1 proposto pela equipe da Clave.

Avaliação: Esta proposta cria um contrato pré-compilado que realiza verificações de assinatura na curva elíptica "secp256r1" por determinados parâmetros de hash da mensagem, componentes r e s da assinatura e coordenadas x, y da chave pública. Assim, qualquer cadeia EVM - principalmente rollups Ethereum - será capaz de integrar este contrato pré-compilado facilmente. De longe, a pré-compilação de protocolo talvez seja a solução mais eficiente em gás.

Implementação: zkSync

Serviço de terceiros

Solução: Turnkey

Avaliação: um TEE da Turquia garante que a chave privada seja acessível apenas ao usuário por meio de seu PassKey e nunca acessível para o Turnkey, no entanto, isso ainda requer a vivacidade do serviço.

Implementação: Goldfinch

Soluções de Verificação de Solidity:

Solução: Verificador de Solidez da FCL, Verificador de Solidez da FCL com Pré-computação, Verificador P256 da Daimo

Implementação: Clave, Carteira Óbvia

Verificador de Conhecimento Zero (ZK):

Solução: Risc0 Bonsai, halo2-ecc da Axiom

Avaliação: Este método utiliza provas de conhecimento zero para verificar cálculos fora da Máquina Virtual Ethereum (EVM), reduzindo os custos computacionais na cadeia.

Implementação: Carteira Bonfire(Risc0), Laboratórios Know Nothing(Axiom)

Cada uma destas soluções oferece um método diferente para capacitar a verificação de assinaturas r1 mais barata e viável no ecossistema do Ethereum, e aqui está uma avaliação feita por Dogan.

Estudo de Caso de Implementação

*Por favor, note que a partir de dezembro de 2023, a maioria dessas soluções está em estágios iniciais e pode mudar ou melhorar a qualquer momento. Esses exemplos são apenas para fins de aprendizado; sempre consulte seus sites oficiais para obter informações precisas.

Carteira de chaves: (WebAuthn de Enclave Seguro) + (SCA)

Fundamentos:

Demonstração: https://getclave.io/

Conta: SCA

Cadeia: ZkSync

Processo de transação:

Criação de chaves: o usuário fornece autenticação biométrica, como impressão digital ou reconhecimento facial, um par de chaves é gerado dentro do Secure Enclave, que nunca é revelado ou sai para fora.

Assinatura de chave: O aplicativo recebe uma mensagem de transação necessária e encaminha uma solicitação de assinatura para o Enclave Seguro, o usuário fornece a bio-autenticação para aprovar a assinatura, e o Enclave Seguro assina a mensagem com a chave, e a mesma é transmitida para os nós da blockchain.

Funções adicionais: A conta de contrato inteligente possibilita muitas funções poderosas. Em primeiro lugar, patrocínio de gás. Devido ao pagador, outras partes como dApp ou anunciantes podem pagar a taxa de gás do usuário, tornando o processo de transação mais suave, e também podem permitir que os usuários paguem o gás em ERC20 em vez de Ether ou token nativo. E usando a chave de sessão, o usuário pode realizar transações sem necessidade de assinatura em um período de tempo.

Mecanismo de recuperação:

O processo de recuperação é conduzido pelo contrato inteligente da Clave no zkSync, o usuário pode cancelar a recuperação durante um bloqueio de 48 horas, para evitar atividades não autorizadas e maliciosas.

Backup na nuvem: Um EOA será criado quando o usuário escolher o backup na nuvem, a chave privada do EOA é armazenada no iCloud ou Google Drive, o usuário pode usar essa chave privada armazenada na nuvem para acessar sua conta de um dispositivo diferente e os usuários podem remover ou sobrescrever esta seção de backup a qualquer momento.

Recuperação social: o usuário pode atribuir o endereço de clave de sua família ou amigo como backup, se M de N guardiões derem uma confirmação para a recuperação, esta será executada após 48 horas de bloqueio, se não for cancelada.

Carteira Soul: (Chave de acesso) + (4337 SCA)

Noções básicas:

Demonstração: https://alpha.soulwallet.io/wallet

Conta: ERC4337 SCA

Cadeia: Ethereum, Optimism, Arbitrum e em breve todos os EVM layer2

Processo de transação:

Criação de chave: Os usuários fornecem autenticação biométrica como impressão digital ou reconhecimento facial, e o sistema operacional gera a senha e a faz backup usando o serviço de nuvem. Você pode adicionar mais de uma senha em vários dispositivos e plataformas.

Adicionar guardiões (Opcional): O usuário pode atribuir diferentes endereços de EOA EVM como guardiões e configurar um limite para recuperação de conta.

Geração de conta: Usando implantação contrafactual, os usuários não precisam pagar nenhuma taxa até a primeira transação

Mecanismo de recuperação:

Passkey: Use qualquer passkey definido para fazer login na carteira usando um dispositivo arbitrário.

Recuperação dos guardiões: Os guardiões designados podem girar a carteira de acordo com o limite, e um bloqueio de tempo pode ser abordado posteriormente para evitar comportamentos maliciosos.

OKX carteira:(MPC-TSS + Passkey) + (4337 SCA)

Noções básicas:

Demo: https://www.okx.com/help/o-que-e-uma-carteira-de-contrato-inteligente-aa

Corrente: 30+ correntes

Chave: MPC-TSS, 2/3

Conta: 4337 SCA

Processo de transação:

Criação de chaves: Ao criar uma carteira, o OKX transforma uma única chave privada em três partes separadas. A Parte 1 é armazenada no servidor OKX, a Parte 2 é armazenada no armazenamento local do dispositivo do usuário e a Parte 3 é gerada pelo dispositivo, criptografada e pode ser armazenada nos serviços de nuvem preferidos do dispositivo, como Google Cloud, iCloud e Huawei Cloud.

Assinatura de chave: A OKX usando a tecnologia MPC-TSS, o usuário pode obter a assinatura completa usando duas das três partes da chave privada ao assinar a transação, as partes da chave nunca se encontram durante este processo.

Mecanismo de recuperação:

Mecanismo 2/3: Quando o usuário sair, o dispositivo estiver indisponível ou uma das chaves do dispositivo estiver comprometida, você pode usar um novo dispositivo para fazer login na carteira OKX (obter a compartilhamento do servidor) e obter o compartilhamento do serviço de nuvem, combinar esses 2 compartilhamentos para recuperar a carteira, a carteira OKX gerará novos compartilhamentos secretos.

Web3Auth: (MPC-TSS + Passkey)+ (EOA/SCA)

Básico:

Demo: https://w3a.link/passkeysDemo

Cadeia: Todos EVM e Solana

Chave: MPC-TSS, geralmente 2/3

Conta: Qualquer conta como EOA, 4337 SCA ou SCA geral

Processo de transação:

Criação de chaves: Ao criar uma carteira, são geradas três chaves. A Chave1 é uma chave de login social, o usuário pode digitar seu e-mail e uma rede descentralizada de nós armazena a chave para cada usuário; a Chave2 é uma chave de dispositivo armazenada no armazenamento local do usuário; a Chave3 é gerada pelo computador local e é armazenada pelo serviço de nuvem preferido do usuário.

Assinatura de chave: A arquitetura Web3Auth MPC-TSS garante que a chave do usuário esteja sempre disponível, mesmo usando a assinatura de limiar, as chaves nunca são reconstruídas ou armazenadas em um único local.

Mecanismo de recuperação:

Recuperação de limite Quando o usuário faz logout, o dispositivo está indisponível ou uma das chaves no dispositivo está comprometida, você pode usar o método de login social para acessar a conta webAuthn e obter o compartilhamento de nuvem da chave de acesso, combinando esses 2 compartilhamentos para recuperar a carteira.

Protocolo Lit (MPC-TSS + nós descentralizados + chave de acesso) + (EOA/SCA)

Informações básicas:

Demonstração: https://lit-pkp-auth-demo.vercel.app/

Cadeia: A maioria da EVM, Cosmos, Solana.

Conta: MPC-TSS, 20 de 30 em rede, pode ser adotado tanto por SCA quanto por EOA.

Processo de transação:

Criação de chave: Quando o usuário deseja criar uma carteira, primeiro selecione um método de autenticação (passkey, login social oAuth suportado), uma solicitação é então enviada ao relayer para criar pares de chaves e armazenar a lógica de autenticação no contrato inteligente. Cada par de chaves é gerado coletivamente pelos nós Lit por meio de um processo chamado Geração de Chave Distribuída (DKG). Operando como uma rede descentralizada, 30 nós Lit em execução dentro de TEE, cada nó detém uma parte da chave, mas a chave privada nunca existe em sua totalidade.

Assinatura de chave: Ao receber a solicitação, os nós Lit validam ou rejeitam independentemente a solicitação em relação ao método de autenticação atribuído e, utilizando a tecnologia MPC-TSS, 1. As partes da chave são coletadas acima do limite (20 de 30) para gerar uma assinatura e combinadas pelo cliente para atender à solicitação.

Mecanismo de recuperação:

Mecanismo de 2/3: Use os métodos de autenticação armazenados no contrato inteligente para acessar a conta, os nós Lit validam as solicitações e ele prosseguirá se mais de 2/3 dos nós confirmarem.

Conclusão:

Impulsionado pelo entusiasmo por soluções de Camada2, Camada3 e disponibilidade de dados, estamos ansiosos para melhorar o desempenho do blockchain. Além disso, buscando segurança real, combinando Privacidade de Prova de Conhecimento Zero com a natureza da transparência. Todos os esforços têm como alvo um objetivo: Estar pronto para usuários reais que interagem frequentemente com o blockchain e adotam cripto em suas vidas.

É fácil ficar preso em um sonho de tecnologia ideal, mas devemos perguntar: que tipo de experiência estamos buscando? Envisionamos um mundo onde a cripto é sobre intuição em vez de termos técnicos intimidantes, onde um usuário mergulha na toca do coelho sem hesitação e complicações.

Imagine um usuário Rui: Ela descobre um dApp fantástico, se cadastra facilmente usando reconhecimento facial ou impressão digital, com a opção de configurar backups ou guardiões. Conforme ela interage com o dApp, executa transações sem problemas, possivelmente com pequenas taxas ERC20 ou até mesmo sem nenhuma. Mais tarde, ela personaliza as configurações de sua carteira - talvez ativando um bloqueio de tempo para transações automatizadas, adicionando outro dispositivo como um signatário de backup, ou revisando sua lista de guardiões.

Nossos construtores fazem isso acontecer. Integrando WebAuthn e Passkey, aprimoramos o gerenciamento de chaves privadas, tornando-o seguro e amigável ao usuário. Além da chave, a SCA como uma entidade abre um reino de segurança e funcionalidade personalizadas. E quanto às taxas de gás? Elas se tornam menos pesadas, graças aos provedores de Pagamento que podem criar um 'cofre' para trocas ou até mesmo permitir que anunciantes cubram as taxas dos usuários. No centro dessa evolução, especialmente para a mainnet do Ethereum e seus equivalentes Layer2s, está o ERC4337. Ele introduz uma mempool alternativa que diferencia transações SCA de EOAs, sem grandes reformulações de protocolo. Por outro lado, algumas redes Layer 2 estão até mesmo adotando SCAs nativamente, incorporando-os perfeitamente em seus sistemas.

Exige esforços tremendos para tornar tudo mais fácil. Muitos desafios existem, como reduzir as taxas de implantação, validação e execução para SCA; Padronizar a interface para aumentar a interoperabilidade de contas; Sincronizar o estado da conta entre cadeias; e muitos mais. Crédito a todos os construtores, estamos nos aproximando da resolução do quebra-cabeça dia após dia. E empreendimentos de cripto como nós - SevenX, estão prontos para ajudar grandes empresas a realizar sua visão.

Aviso Legal：

1. Este artigo é reproduzido a partir de [SevenX Ventures]. Todos os direitos autorais pertencem ao autor original [@Rui]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipe e eles cuidarão disso 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 do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.