TL;DR

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

Autenticar utilizadores autorizados é crucial para transações seguras. Com a evolução da segurança na internet e da UX, passámos da autenticação por palavra-passe para a biometria, como o reconhecimento facial e as impressões digitais. O WebAuthn é um desenvolvimento chave nesta progressão. Este artigo discute de perto três termos:

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

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. 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 operativo, personalizada por vários fornecedores de dispositivos e sistemas. Por exemplo, a chave de acesso da Apple usa a chave armazenada no Porta-chaves iCloud para sincronização entre dispositivos. No entanto, essa abordagem normalmente é bloqueada para 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 segurança anti-phishing de alto nível e uma experiência amigável. Aqui está a ideia de fundi-los no blockchain:

Camada de Chave: Os utilizadores autenticam-se usando métodos biométricos contínuos, como reconhecimento facial ou impressão digital. Por baixo, é o processador de segurança baseado em hardware, como Enclave Seguro ou serviços de armazenamento na nuvem, como iCloud e Google Cloud, que tratam da gestão da chave. Mais tarde, irei abordar questões de interconexão entre dispositivos e plataformas.

Camada de Conta: Uma Conta de Contrato Inteligente (CCI) oferece a capacidade de atribuir signatários arbitrários (por exemplo, SE e Passkey) e mecanismos de limiar. Além disso, o seu design modular melhora a flexibilidade e a capacidade de atualização. Por exemplo, uma CCI pode adaptar dinamicamente os seus requisitos de assinatura com base em fatores como o montante da transação, tempo ou endereço IP. Por outro lado, uma Conta de Propriedade Externa tradicional (EOA) pode ser aumentada com serviços de MPC, a sua combinação oferece melhor interoperabilidade e rentabilidade em comparação com CCI, embora falte funcionalidades avançadas que as CCIs fornecem, especialmente para a 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 elevados, uma vez que utiliza a curva r1 para a geração de chaves. Portanto, algumas soluções de Camada 2 como o zkSync, planejando pré-cálculos da curva r1 do EIP-7212 nativamente. Além disso, existem serviços de terceiros, verificadores de Solidity, verificadores de Conhecimento Zero (ZK) e sistemas de gestão de chaves distribuídas, para facilitar a assinatura da curva r1 de forma mais econômica.

Aviso legal:

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

A experiência do usuário em Cripto é péssima? A gestão de chaves é péssima!

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

Geração de Chave: Um número aleatório selecionado da curva elíptica secp256k1 serve como a chave privada. Esta 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), quantidade, preço do gás e endereço do destinatário, é assinada usando a chave privada. Este processo, envolvendo o ECDSA, um algoritmo de assinatura digital que utiliza 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 hashed para derivar a chave pública do remetente e confirmar a autenticidade da transação comparando o endereço derivado com o do remetente.

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

Muitos podem pensar que a Abstração de Conta (AA) é a solução para tudo relacionado com a má experiência do utilizador, o que direi que não é exatamente. AA trata da alteração das 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 tópico deste artigo, quebrar a validação de assinatura fixa (assinatura ECDSA abstrata). Em vez de EOA, as SCAs podem atribuir signatários arbitrários e mecanismos de assinatura como assinatura múltipla (multisigs) ou chaves de escopo (chaves de sessão). No entanto, apesar da flexibilidade e avanço na capacidade de atualização de AA, a dependência fundamental de chave(s) para a assinatura de transações permanece inalterada.

Mesmo quando convertida numa frase-semente de 12 palavras, a gestão de uma chave privada continua a ser um desafio, colocando riscos de perda ou ataques de phishing. Os utilizadores devem navegar entre camadas complexas de soluções descentralizadas ou o abraço caloroso de serviços centralizados, nenhum dos quais é ideal.

Porque a experiência com cripto é tão má? Uma grande parte disso é devido à má gestão das chaves. Isso sempre requer compromissos entre experiência, segurança e descentralização. Este artigo explora potenciais soluções ótimas para gerir a chave.

Camadas de Gestão de Chave

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

Para esclarecer antecipadamente, evito usar os métodos populares de 'auto-custódia, semi-custódia e custódia total' 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 armazenada nos nós descentralizados de TEE). Classificar as soluções meramente como 'boas' ou 'más' com base no tipo de custódia é excessivamente simplista e não leva em conta a sua adequação variada. Para uma avaliação mais sutil dos métodos de gestão de chaves, sugiro analisá-los através de três camadas distintas:

Responsabilidade

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

Dado que os indivíduos frequentemente enfrentam desafios na gestão da chave, a distribuição da responsabilidade de salvaguardar a chave surge como uma estratégia natural de mitigação de riscos. Esta categoria inclui métodos como usar várias chaves para assinar colaborativamente, como visto em sistemas de Assinatura Múltipla (Multi-sig), e dividir a chave privada em partes através de um Esquema de Compartilhamento Secreto (SSS) ou Computação Multi-Partes (MPC).

Multi-sig: Exigir várias chaves privadas completas para gerar assinaturas de transação. Este método requer comunicação on-chain sobre os diferentes signatários, incorrendo em taxas de transação mais elevadas e afetando a privacidade porque o número de signatários é visível on-chain.

SSS: uma chave privada é gerada num único local e um distribuidor distribui pedaços 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(Threshold Signature Scheme): como uma implementação de MPC, uma abordagem criptográfica que permite a várias partes realizar cálculos enquanto mantêm em conjunto as suas entradas privadas. Cada parte cria independentemente uma parte de chave secreta, e as transações são assinadas sem que estas partes tenham nunca de se encontrar fisicamente. Introduz taxas mais baixas porque está fora da cadeia, e não há risco de um único ponto de falha como SSS.

Armazenamento

Armazene a chave ou partes, afetadas por fatores de segurança, acessibilidade, custo e descentralização.

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

Armazenamento descentralizado como IPFS e Filecoin.

Computador/móvel 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 está isolado do processador principal para fornecer uma camada adicional 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, especificamente projetados para armazenar com segurança chaves privadas.

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 normalmente 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 o acesso está de facto autorizado a fazê-lo. Olhando para trás na história, podemos categorizar a história da seguinte forma:

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

Algo que tens: Inclui cartões inteligentes, tokens de hardware (senhas únicas baseadas no tempo) ou fatores digitais como verificações de contas sociais e códigos SMS enviados para um telefone.

Alguém Que É: Envolva características físicas únicas 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 push combinada por SMS, para adicionar mais camadas de segurança às contas de usuário.

Análise de jogadores existentes

MetaMask permite que os usuários usem uma senha para acessar a chave armazenada no armazenamento do navegador local do usuário.

A Trust Wallet permite aos utilizadores utilizar uma palavra-passe ou faceID para aceder à chave armazenada no armazenamento local do browser do utilizador, o utilizador também pode escolher o serviço de nuvem para fazer backup da chave privada.

Privy permite aos utilizadores utilizar vários métodos de login social como email, usando SSS para dividir em três partes:

Partilha de dispositivos: Navegador-iFrame, móvel- enclave seguro.

Auth share: Armazenado pelo privy, ligado ao id privy).

Partilha de recuperação: Palavra-passe do utilizador ou encriptada pela Privy armazenada num módulo de segurança de hardware (HSM).

Particle permite aos utilizadores usar o login social, utilizando MPC-TSS que tem duas partes:

Partilha de dispositivo: navegador-iFrame

Chave de compartilhamento do servidor: servidor da Particle

Nova Solução

Camada chave: WebAuthn, Enclave Seguro e Passkey

As soluções existentes acima têm sido fundamentais na introdução dos usuários à web3. No entanto, muitas vezes vêm com desafios: as senhas podem ser esquecidas ou alvo de ataques de phishing, e até mesmo o 2FA, embora mais seguro, pode ser complicado com suas várias etapas. Além disso, nem todo mundo se sente confortável em confiar a terceiros o gerenciamento de chaves, os usuários ainda dependem da disponibilidade e da vivacidade do sistema, enquanto alguns serviços garantem que eles não possam acessar a chave.

Isto leva-nos a ponderar se existe uma solução mais eficaz, que ofereça a solução mais próxima de uma experiência de utilizador sem confiança, de alta segurança e sem costuras. Esta pesquisa leva-nos aos métodos web2 ótimos. Vários termos estão intimamente relacionados com o 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 com este padrão.

WebAuthn

O WebAuthn padroniza a interface de autenticação de usuários em aplicações baseadas na web. Permite que os usuários façam login em contas na internet usando autenticadores externos em vez de uma senha. Os autenticadores podem ser Autenticadores Itinerantes (Yubikey, Titan key) ou um Autenticador de Plataforma (Chave embutida no chaveiro em dispositivos Apple), e assim por diante.

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

Benefícios do webAuthn:

Segurança Reforçada: Elimina a dependência de senhas, reduzindo a vulnerabilidade a phishing, ataques de 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 apenas com um toque ou verificação biométrica.

Proteção da Privacidade: Durante a autenticação, não são transmitidos segredos partilhados, e os websites individuais não recebem qualquer 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 o Google Pixel.

Geração de Chave: Usando 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 a Enclave Segura. O usuário nunca lida com a chave em texto simples, tornando difícil que a chave privada seja comprometida.

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

Autenticação: Os utilizadores utilizam o reconhecimento facial ou impressão digital para aceder, a Enclave Segura utiliza a chave privada para assinar um desafio do serviço, e o serviço verifica utilizando a chave pública.

Vantagens do webAuthn baseado em dispositivo:

Segurança a nível de hardware: Utilizando a Enclave Segura, um gestor de chaves baseado em hardware isolado para fornecer uma camada extra de segurança.

Resistência a phishing: Não envolva a introdução de qualquer informação 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.

Baseado na nuvem WebAuthn, Chave de acesso

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

Vamos tomar a Passkey da Apple como exemplo:

Geração de chaves: O dispositivo macOS, iOS ou iPadOS do usuário, como autenticador, gera um par de chaves público-privadas quando o usuário cria a conta. Em seguida, envia a chave pública para o servidor, e a chave privada é armazenada no chaveiro 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: Este processo será o mesmo que aceder ao iCloud. Autenticar na conta do iCloud, receber um código SMS e introduzir o código de acesso de um dos dispositivos.

WebAuthn baseado na nuvem prós:

Dispositivo cruzado: As chaves de acesso foram projetadas para serem convenientes e acessíveis a partir de todos os dispositivos usados regularmente. Mas atualmente limitadas aos dispositivos Apple, para Android é mais desafiador devido às suas diversas versões e variações de hardware.

Resistência à Pesca: Igual ao acima.

Experiência Conveniente: Igual ao acima.

Passkey baseado na nuvem contras:

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

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

Camada da conta: SCA e EOA

Até agora, podemos ver que manter a segurança ao nível do hardware enquanto se aborda a compatibilidade entre dispositivos e plataformas é desafiante. Igualmente crucial é a opção de recuperação social, como adicionar vários guardiões para uma segurança reforçada. Neste contexto, a tecnologia blockchain pode mostrar-nos um caminho.

Uma lacuna notável quando tentamos implementar o web2 webAuthn para web3: o Web2 apenas requer a prova de propriedade, enquanto o web3 também necessita 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), sendo elas próprias contratos inteligentes, funcionam como entidades on-chain, capazes de atribuir signatários arbitrários. Esta flexibilidade permite programar vários dispositivos e plataformas - como definir um telefone Android, um Macbook e um iPhone - como signatários. Além disso, a Conta de Contrato Inteligente Modular permite a possibilidade de atualização, trocando novos signatários, alterando o limite de assinatura de 2 em 3 para configurações ainda mais intricadas.

Imagina uma carteira que adapta os seus requisitos de segurança com base no contexto: permite autenticação de um único signatário quando o utilizador está num endereço IP local familiar, mas exige múltiplos signatários para transações a partir de endereços IP desconhecidos ou acima de um determinado valor. Com modularidade e programabilidade, a nossa imaginação é o único limite para tais inovações. Muitos fornecedores de serviços de SCA constroem ativamente este espaço, incluindo Safe, Zerodev, Biconomy, Etherspots, Rhinestone, etc. Também um grande obrigado à infraestrutura como Stackup, Plimico, Alchemy que tornam isto possível.

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

EOAs podem alcançar recuperação social e compatibilidade entre dispositivos/plataformas através de serviços de MPC. Apesar de os EOAs terem signatários fixos, os fornecedores de MPC podem dividir as 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 com tempo de bloqueio e desativação fácil de chaves. No entanto, ainda oferece capacidades superiores de interligação entre cadeias por ser agnóstico à cadeia e atualmente é mais econômico do que os SCAs. Notáveis fornecedores de MPC incluem Privy, Particle Network, web3Auth, carteira OKX, carteira Binance, 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 esta curva.

No entanto, os pares de chaves gerados de acordo com os padrões WebAuthn, usam 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 consulte a sua pesquisa.

Solução de Protocolo:

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

Avaliação: Esta proposta cria um contrato pré-compilado que realiza verificações de assinatura na curva elíptica “secp256r1” pelos parâmetros fornecidos do hash da mensagem, componentes r e s da assinatura, e coordenadas x, y da chave pública. Assim, qualquer cadeia EVM - principalmente os rollups Ethereum - poderá integrar facilmente este contrato pré-compilado. Até agora, o pré-compilado do protocolo pode ser a solução mais eficiente em termos de gás.

Implementação: zkSync

Serviço de terceiros

Solução: Turnkey

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

Implementação: Goldfinch

Soluções Verificadoras 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: Esta abordagem utiliza provas de conhecimento zero para verificar cálculos fora da Máquina Virtual Ethereum (EVM), reduzindo os custos computacionais on-chain.

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 assinatura 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 aprendizagem; consulte sempre os seus sites oficiais para obter informações precisas.

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

Básico:

Demo: https://getclave.io/

Conta: SCA

Cadeia: ZkSync

Processo de transação:

Criação de chave: O utilizador fornece autenticação biométrica, como impressão digital ou reconhecimento facial, sendo gerado um par de chaves dentro do Enclave Seguro, que nunca é revelado nem sai para o exterior.

Assinatura de chave: O aplicativo recebe uma mensagem de transação obrigatória e encaminha um pedido de assinatura para a Enclave Segura, o usuário fornece bio-autenticação para aprovar a assinatura, e a Enclave Segura assina a mensagem com a chave e a envia 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 assinatura num período de tempo.

Mecanismo de recuperação:

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

Backup na nuvem: Um EOA será criado quando o utilizador escolher o backup na nuvem, a chave privada do EOA é armazenada quer no iCloud quer no Google Drive, o utilizador pode utilizar esta chave privada armazenada na nuvem para aceder à sua conta a partir de um dispositivo diferente, e os utilizadores podem remover ou sobrescrever esta secção de backup a qualquer momento.

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

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

Noções básicas:

Demo: https://alpha.soulwallet.io/wallet

Conta: ERC4337 SCA

Cadeia: Ethereum, Optimism, Arbitrum e em breve todos os EVM de camada 2

Processo de transação:

Criação de chave: Os utilizadores fornecem autenticação biométrica, como impressão digital ou reconhecimento facial, e o sistema operativo gera uma Chave de Acesso e faz backup dela usando o serviço de nuvem. Pode adicionar mais do que uma chave de acesso entre dispositivos e plataformas diferentes.

Adicionar guardiões (Opcional): O utilizador pode atribuir diferentes endereços EVM EOA como guardiões e definir um limite para a recuperação da 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:

Chave de acesso: Utilize qualquer chave de acesso definida para entrar na carteira usando um dispositivo arbitrário.

Recuperação dos guardiões: Os guardiões atribuídos podem rodar a carteira de acordo com o limiar, e um bloqueio de tempo pode ser posteriormente endereçado para prevenir comportamento malicioso.

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

Noções básicas:

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

Cadeia: 30+ cadeias

Chave: MPC-TSS, 2/3

Conta: 4337 SCA

Processo de transação:

Criação de chave: 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 copiada para os serviços de nuvem preferidos do dispositivo, como Google Cloud, iCloud e Huawei Cloud.

Assinatura de chaves: OKX usando a tecnologia MPC-TSS, o usuário pode obter a assinatura completa usando dois de três compartilhamentos de chave privada ao assinar a transação, os compartilhamentos de chave nunca se encontram durante este processo.

Mecanismo de recuperação:

Mecanismo 2/3: Quando o usuário faz logout, o dispositivo fica indisponível ou uma das chaves do dispositivo é comprometida, você pode usar um novo dispositivo para fazer login na carteira OKX (obter a partilha do servidor) e obter a partilha do serviço de nuvem, combinando essas 2 partilhas para recuperar a carteira, a carteira OKX irá gerar novas partilhas secretas.

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

Noções básicas:

Demo: https://w3a.link/passkeysDemo

Cadeia: Todos os 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 partes da chave. A Parte1 é a parte 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; Parte2 é a parte do dispositivo armazenada no armazenamento local do dispositivo do usuário; Parte3 é gerada pelo computador local e é feita backup pelos serviços de nuvem preferidos pelo usuário.

Assinatura de chave: A arquitetura Web3Auth MPC-TSS garante que a chave do usuário está sempre disponível, mesmo usando a assinatura de limite, 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 desconectado, o dispositivo está indisponível ou uma das chaves do dispositivo está comprometida, você pode usar o método de login social para fazer login na conta webAuthn e obter o compartilhamento de nuvem de chave de acesso, combinar esses 2 compartilhamentos para recuperar a carteira.

Protocolo Lit (MPC-TSS + nós descentralizados + Passkey) + (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 rede, pode ser adotada tanto por SCA como por EOA.

Processo de transação:

Criação de chave: Quando o utilizador deseja criar uma carteira, deve primeiro selecionar um método de autenticação (passkey, login social oAuth suportado), sendo então enviado um pedido 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 através de um processo chamado Geração Distribuída de Chaves (DKG). Funcionando 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 inteiramente.

Assinatura de chave: Recebendo o pedido, os nós Lit validam ou rejeitam independentemente o pedido em relação ao método de autenticação atribuído e, usando a tecnologia MPC-TSS, 1. As partes das chaves são recolhidas acima do limiar (20 de 30) para gerar uma assinatura e combinadas pelo cliente para cumprir o pedido.

Mecanismo de recuperação:

Mecanismo 2/3: Utilize os métodos de autenticação armazenados no contrato inteligente para acessar a conta, os nós Lit validam os pedidos e prosseguirão se mais de 2/3 dos nós confirmarem.

Conclusão:

Impulsionado pelo entusiasmo pela camada 2, camada 3 e soluções de disponibilidade de dados, estamos ansiosos para melhorar o desempenho da blockchain. Além disso, buscando segurança real, combinando a privacidade da Prova de Conhecimento Zero com a natureza transparente. Todos os esforços têm como alvo um objetivo: Estar pronto para utilizadores reais que interagem frequentemente com a blockchain e adotam cripto nas suas vidas.

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

Imagine um usuário Rui: Ela descobre um fantástico dApp, facilmente se inscreve usando reconhecimento facial ou uma impressão digital, com a opção de configurar backups ou tutores. À medida que ela se envolve com o dApp, ela executa transações sem problemas, possivelmente com pequenas taxas ERC20 ou até mesmo 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 signatário de backup ou revisando sua lista de guardiões.

Os nossos construtores fazem isso acontecer. Integrando o WebAuthn e o Passkey, melhoramos a gestão da chave privada, tornando-a segura e amigável para o utilizador. Além da chave, o SCA como entidade abre um mundo de segurança e funcionalidade personalizadas. E quanto às taxas de gás? Tornam-se menos pesadas, graças aos fornecedores de Paymaster que podem criar um 'cofre' para trocas ou até permitir que os anunciantes cubram as taxas dos utilizadores. No centro desta evolução, particularmente para o mainnet do Ethereum e os seus equivalentes Layer2s, está o ERC4337. Ele introduz uma mempool alternativa que distingue as transações de SCAs das de EOAs, sem grandes revisões de protocolo. Por outro lado, algumas redes Layer 2 estão até a abraçar SCAs nativamente, incorporando-os perfeitamente nos seus sistemas.

Requer esforços tremendos para tornar tudo mais fácil. Existem muitos desafios, como reduzir as taxas de implementação, validação e execução para o 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 mais perto de resolver o quebra-cabeça dia após dia. E empreendimentos cripto como nós - SevenX, estão prontos para ajudar grandes empresas a realizar sua visão.

Aviso Legal：

1. Este artigo é reeditado a partir de [GateSevenX Ventures]. Todos os direitos autorais pertencem ao autor original [@Rui]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa, 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 qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.