Assinante de abstração de conta baseado em chave de acesso para carteiras de contratos inteligentes – Página 2 – Aplicativos

Já demorei muito para comentar aqui, mas antes tarde do que nunca. Em primeiro lugar, parabéns a @rishotics e ao restante da equipe Banana SDK por liderar esta conversa. Como mantenedor do Passkeys(dot)is vejo o potencial da tecnologia para ser aplicada em criptografia apesar de algumas ressalvas já identificadas.

Para mim, existem alguns requisitos mínimos necessários para que esta configuração funcione:

• Conta inteligente multi-sig – Embora as chaves de acesso sejam um mecanismo de “pontapé inicial” ideal para integrar um usuário, elas possuem algumas falhas já apontadas no thread que as tornam inadequadas para torná-las uma solução de longo prazo como a única configuração de assinante em uma conta inteligente. Aqui eu imagino algo como um Cofre que pode ser inicialmente provisionado por uma Chave de Acesso, mas que pode adicionar outros assinantes e até mesmo remover a si mesmo, se necessário.

• Implementação de cliente puro – Neste momento estamos tentando passar pelo tradicional webauthn fluxo de trabalho, que envolve um servidor que cria uma solicitação e a emparelha com o nome de usuário passado como parte dos parâmetros de criação de chave. No entanto, depender de um servidor para “permitir” nomes de usuário em vez de passar a assinatura ECDSA pode criar um ponto de falha centralizado indesejado, não necessário para uma carteira inteligente.

• Implantação lenta – Devido à forma como as chaves de acesso funcionam, podemos gerar uma chave pública durante a geração da primeira instância da conta. Essa chave pode então ser passada para um contrato e um entrypoint para fornecer um endereço de conta inteligente. Poderíamos usar esse endereço desde o dia 0 até que quiséssemos implantá-lo, permitindo-nos um envolvimento mínimo com ele até que fosse necessário (por exemplo, lançamento aéreo na conta). Parece que @nlok5923 já tem uma maneira de disponibilizar esse endereço.

• Custo mínimo de gás – Mesmo em L2s, o custo atual de um secp256r1 a verificação de assinatura é de cerca de 1,2 milhão, o que é um bom dinheiro. Existem vários grupos explorando a redução desse custo (gás ruim), inclusive fazendo otimizações de curvas elípticas (veja a apresentação da equipe de Ledger para EthCC ’23), mas nada é “oficial” ainda. Até minha própria demonstração no github (passkeys-webauth) tem esse custo.

• Auditoria – No final das contas estamos verificando manualmente uma assinatura ECDSA, já que o Ethereum atual ecrecover não é capaz de analisar esta curva. Assim, seria benéfico para a comunidade reunir-se para uma auditoria em torno de um padrão que possa ser usado em toda a indústria e beneficiar igualmente os criadores de carteiras inteligentes, em vez de construir mais um bloco de Lego.

Se conseguirmos resolver estes pontos, acredito que as outras preocupações poderão ser parcial ou totalmente atenuadas. Por exemplo, podemos contornar a sincronização nativa do iCloud Keychain da Apple e confiar na configuração do HSM fornece um vetor de ataque semelhante a, digamos, um login Web2 OAuth como Web3Auth. Mesmo assim, eu diria que as chaves de acesso oferecem uma alternativa melhor, já que podem funcionar offline e sem qualquer interface de servidor, desde que navigator.credentials é suportado pelo navegador.

Agora, para responder algumas perguntas:

• MicahZoltu – As chaves são armazenadas no dispositivo e sincronizadas com o iCloud para dispositivos iOS (outros dispositivos não possuem armazenamento automático em nuvem). No iOS, você não pode ativar chaves de acesso sem as Chaves do iCloud ativadas, mas pode remover a chave do iCloud depois de sincronizada e somente do iCloud. Em termos de segurança, em teoria, e com base em declarações feitas por vários porta-vozes da Apple, a Apple armazena as credenciais KEK do usuário em seus HSMs, que seriam apagadas após 10 tentativas fracassadas de acesso ao iCloud do usuário. Assim, mesmo no caso de uma apreensão governamental, eles seriam tecnicamente incapazes de partilhar a chave. É claro que metadados e outras informações relacionadas ao IP, até mesmo ao ponto de impressão digital do dispositivo, ainda seriam provavelmente possíveis. plusminushalf compartilhou mais sobre isso em uma postagem anterior.

• drortirosh sim, isso está correto. O que é ainda mais engraçado é que a carga útil de assinatura real não importa. Por causa do jeito webauthn funciona, sempre assinamos em cima do authenticatorData e não pode fazer uso da carga útil. Portanto, a única coisa que podemos aprender com este pedido é “está assinado”. Não importa o que o usuário assina, apenas que ele assinou algo no momento X.

• Victor928, seria seguro assumir que todas as transações através de uma conta inteligente baseada em senha teriam um requisito mínimo do secp256r1 verificação, atualmente com custo de 1,2 milhão em uma implementação ingênua, algumas pesquisas apontando que caiu para 300 mil-60 mil (veja a apresentação de Ledger para EthCC ’23 sobre isso).

• Joseph, sob uma única implementação ingênua 1 em 1 de uma conta inteligente baseada em Passkey, não há revogação de chave e, portanto, seria terrível se você precisasse alternar. No momento, a única maneira de “compartilhar” uma chave de acesso é fisicamente via Airdrop para um contato próximo ou usando um autenticador de roaming (por exemplo, Yubikey). Portanto, uma configuração multi-sig provavelmente seria preferida. Outros comentários já foram respondidos por @rishotics no último post.

(Observação: Alguém com mais direitos, por favor, atualize para mencionar as pessoas marcadas).

Olá José, ótimos insights. Com base neles, veja como nós da Biconomy abordamos esses desafios:

• Conta inteligente multi-assinatura: Reconhecendo as preocupações que você levantou, projetamos uma arquitetura modular para nossa carteira inteligente. Abrange:

  • Módulos de validação: Estes ditam a lógica de propriedade da carteira de contrato inteligente.
  • Módulos de recursos: introduzem recursos adicionais à conta. Após a implantação, os usuários podem escolher entre o módulo de validação ECDSA padrão com chaves secp256k1 ou optar pelo módulo de validação Passkey. Para resolver as preocupações sobre as chaves de acesso, temos a opção de ativar um módulo de recuperação social como alternativa.

• Implementação de cliente puro: Acredito que este não seja um ponto de falha centralizado/único. Gostaria de enfatizar que o keyId nas chaves de acesso não faz parte da assinatura. Quando um contrato inteligente é gerado on-chain, ele verifica x mod n == r. Como mencionado em @ nlok5923, a análise desses valores pode gerar o endereço H160 compatível com Ethereum. O nome de usuário ou este endereço pode ser usado e armazenado fora da cadeia. O keyId nas chaves de acesso simplesmente direciona com qual chave de acesso específica assinar.

• Implantação preguiçosa: Semelhante a qualquer carteira conectada a um dapp, quando um usuário se conecta com chaves de acesso, o dapp pode aproveitar as coordenadas x, y para solicitar à fábrica da conta inteligente o endereço da conta inteligente contrafactual. A derivação do endereço dependerá da fórmula: moduleContractAddr + ModuleData + índice, onde ModuleData abrange x, y e keyId.

• Minimizando os custos do gás: Na verdade, os custos do gás são uma preocupação. Uma solução promissora, na minha opinião, é implementar uma pré-compilação para p256. EIP-7212 descreveu esta abordagem de forma eficaz. A equipe do Opclave também está trabalhando nisso, tendo incorporado uma pré-compilação no optimism-geth para minimizar o uso de gás.

• Auditoria: Realizamos várias auditorias para secp256r1 e temos algumas preocupações notáveis ​​que todos deveriam analisar. Compartilhando isso para que possamos discutir mais sobre isso: bcnmy/scw-contracts.

Espero que isso acrescente profundidade e estou ansioso para ver mais perspectivas sobre o assunto.

Ótimos pontos, @amanraj1608

Tive algumas dúvidas por curiosidade sobre as implementações modulares de SCA da Biconomy.

• Como você mencionou, o endereço seria calculado de forma contrafactual antes da implantação da carteira de contrato inteligente e é derivado de moduleContractAddr + ModuleData + index. Portanto, antes de solicitar um endereço contrafactual, o usuário precisa, de alguma forma, fornecer informações de que precisa que o módulo de chave de acesso seja ativado? e digamos que em um futuro próximo ele não precise mais do recurso de chave de acesso, então o usuário poderá cancelar a assinatura desse módulo. Suponha que se ele fizer isso, então o ModuleData deve mudar e isso levaria a uma mudança no cálculo do endereço da carteira do contrato inteligente sempre que o usuário tentasse se conectar a um dapp que integrasse o SDK da conta inteligente do Biconomy?

• Certamente concorda que a pré-compilação do p256 beneficiaria muito o Passkey ou o ecossistema r1 em geral. Mas acho que a Ledger também lançou a implementação do verificador r1 durante o ethcc, o que reduz a verificação para 70 a 75k de gás e é o mais eficiente atualmente.

• Também acredito que no futuro próximo, em vez de vários padrões de módulo de conta de contrato inteligente, teremos algo como um mercado de módulos uniforme onde os desenvolvedores podem publicar seus módulos construídos e os usuários podem assinar/cancelar a assinatura dos módulos com base em seus requisitos. Adoraria saber como a Biconomy está cuidando disso.

Obrigado!

Portanto, antes de solicitar um endereço contrafactual, o usuário precisa, de alguma forma, fornecer informações de que ele precisa que o módulo de chave de acesso seja ativado

Sim, então o usuário precisa passar as informações de um endereço do módulo de autorização no momento da implantação. Este módulo de autorização conterá os dados de quem é o proprietário do ACS.
No futuro, se alguém quiser mudar do módulo ECDSA para o módulo de senha ou vice-versa, isso pode ser feito usando o enableModule método. Sim, o endereço mudará se você estiver calculando com um dado de endereço e enviando os outros dados de endereço. Mas este é o mesmo caso de antes, para obter o endereço contrafactual você precisava do EOA. Se o contrato já estiver implantado com qualquer módulo, ele não será alterado.
Além disso, se você calculou e implantou com chaves de acesso na cadeia A e depois alterou o módulo para ecdsa, e se quiser o mesmo endereço na cadeia B, poderá fazer a mesma coisa, implantar a conta inteligente com as mesmas chaves de acesso e atualizar o módulo de propriedade com os dados desejados.

em vez de vários padrões de módulo de conta de contrato inteligente, teremos algo como um módulo uniforme

Acredito que o ERC-6900 resolverá esse problema e a Biconomy também estaria trabalhando nisso.

Olá @rishotics @todos

Estou fazendo uma pesquisa focada no design EIP-7999 / Universal Overflow ethresear.ch/t/gas-overflow-for-multidimensional-fee-markets/24766 , especificamente em torno de suposições de contrato e infra-compatibilidade em torno da observabilidade de gás (gasleft (), encaminhamento de gás CALL, padrões de gás retido, etc.).

Atualmente, estou coletando perspectivas do mundo real de engenheiros de protocolo, equipes de abstração/infra de contas e desenvolvedores de contratos inteligentes para entender algo bastante específico:

Se o Universal Overflow preserva o invariantes reais nos quais os desenvolvedores confiam hojeou preserva principalmente um modelo simplificado que parece correto no nível do protocolo, mas diverge dos padrões de uso de produção.

Por exemplo, em sistemas infra-pesados ​​(bundlers / paymasters / solucionadores), o gás é frequentemente tratado menos como uma “métrica de execução restante” e mais como uma limite de orçamento e segurança em caminhos de execução aninhados. Estou tentando entender se esse modelo mental quebra sob a semântica multidimensional de gás + estouro.

Se você tiver um momento, eu realmente valorizaria sua perspectiva sobre:

• se a observabilidade do gás é realmente confiável para a correção em sua pilha (em vez de apenas estimativa/margens de segurança),

• e se o Universal Overflow mudaria quaisquer suposições na simulação de agrupamento/execução.

Estou essencialmente agregando perspectivas em diferentes contextos de implementação (clientes, infraestrutura e contratos) para ver onde está a real fragilidade.

Você estaria aberto para um bate-papo rápido de 15 a 20 minutos ou também posso apenas expressar suas ideias de forma assíncrona aqui, se for mais fácil.

Obrigado,
Ifeoluwa