Autoridade de gasto inteligente ou EOA para contas privadas – Privacidade

Isenção de responsabilidade: tanto a ideia quanto o texto são em colaboração com @DamianStraszak.

Ideia geral

Meta. Deixe uma conta EVM padrão, seja uma EOA ou um contrato inteligente, ser o único autoridade que aprova gastos de uma conta privada ZK.

Mecanismo. O controlador assina um EIP‑712 (dados estruturados digitados) Autorização de gastosenquanto um separado prova_chave deriva segredos de notas e gera as provas ZK. A prova deve corresponder a um compromisso de autorização na rede.

Garantia. A custódia permanece sob os mesmos controles EVM em que os usuários já confiam (carteiras de hardware, multisigs, governança), enquanto a prova e o armazenamento secreto podem ser delegados sem dar poder de compra ou revelar textos simples.

Isso permite:

• controle multisig ou de contrato inteligente sobre uma conta privada usando padrões criptográficos existentes,

• proteção de carteira de hardware (as chaves do controlador ficam no dispositivo; visualizar e provar que os segredos ficam fora da carteira),

• delegar o armazenamento secreto e comprovar a um serviço externo sem dar-lhe custódia (é claro que isso COMpromete até certo ponto as garantias de privacidade, mesmo se o TEE for usado),

• integração direta de carteira – as carteiras anexam dados EIP-712 à transação e se comunicam com um RPC dedicado, sem lidar com segredos ou provas,

• transferências privadas opcionais para usuários que nunca utilizaram o sistema, endereçadas por sua conta EVM regular. Os segredos do destinatário podem ser compartilhados por meio de um retransmissor confiável ou criptografados com Waku/Whisper, este último exigindo que a chave pública do destinatário seja conhecida.

Limitações

• Algumas fugas de informação são inevitáveis, mas quando utilizadas como pretendido, o único sinal visível é que “a conta controlada por este endereço realizou alguma operação.” Na prática:

  • o sistema é opcional; os usuários ainda podem operar no modo clássico sem autoridade de gastos separada,

  • a autorização e a prova podem ser apresentadas separadamente, permitindo a prova atrasada para misturas baseadas no tempo.

control_account – um EOA ou um contrato inteligente. É utilizado apenas para autorizar ações e pode ser um multisig com chaves no hardware. Em alguma capacidade limitada (embora ainda razoável), pode até ser um DAO ou qualquer outro contrato inteligente que não tenha recursos exclusivos de assinatura (ou seja, o suporte EIP-1271 não é necessário).

proving_key – um par de chaves usado para (a) descriptografar SpendAuthorization e declarar instantâneos e (b) derivar novos segredos de notas. O vazamento prejudica a privacidade, não a custódia. O rodízio é autorizado pelo control_account.

SpendAuthorization – uma instrução digitada enviada por control_account que vincula a ação a ser comprovada (transferência ou saque, os depósitos não exigem Autorização de gastos). GastosAutorizações são armazenados em uma árvore Merkle dedicada. Um comprovante de gasto deve incluir um comprovante de associação Merkle para uma SpendAuthorization correspondente.

Rotação – ambos control_account e proving_key pode ser girado sem revelar a rotação na cadeia (girar o registrado proving_key com autorização do control_account).

Ordem das operações durante a transação:

Controlador (mantém control_account) autoriza ações criando um Autorização de gastos.

Provador (mantém proving_key) armazena segredos e gera provas.

Uma transação é bem-sucedida quando:

1. o SpendAuthorization é inserido na árvore SpendAuthorization Merkle pelo controlador

2. o provador envia uma prova ZK que consome as notas autorizadas e corresponde ao SpendAuthorization. (isso pode ser feito por provador externo em outra transação, ou alternativamente – enviado com SpendAuthorisation para otimização de gás)

Exemplo não trivial: o control_account é uma conta multisig, por exemplo, SAFE, e um dos signatários armazena segredos ZK e executa o provador. Todos os assinantes já veem o estado da conta, portanto, nenhuma privacidade extra é perdida devido à comprovação da delegação.

Presumimos que o leitor esteja familiarizado com o funcionamento da privacidade baseada em ZK no sistema EVM e, portanto, não definimos termos como note, trapdoorenullifier nem explicar quais restrições precisam ser verificadas para realizar transações privadas regulares. As implementações específicas diferem em alguns detalhes técnicos (incluindo o tratamento do anulador), mas as diferenças não estão relacionadas ao que está sendo proposto. Descrições específicas podem ser encontradas aqui: https://docs.blanksquare.io/protocol-details/shielder ou aqui: https://docs.railgun.org/wiki/learn/privacy-system.

Estrutura da nota:

Cada nota inclui os campos usuais e um campo opcional:

• control_account: address | 0 – se for diferente de zero, os gastos deverão corresponder a um SpendAuthorization autorizado por este endereço.

Novos segredos de notas (trapdoor e o segredo que mais tarde produzirá o nullifier) são derivados de um PRF codificado pelo proving_keypermitindo a recuperação em caso de perda de outros segredos.

Em caso de control_account campo sendo definido como 0o sistema de privacidade funciona sem esta modificação, ou seja, a prova de SpendAuthorisation é trivialmente aceita, permitindo que transações que não exigem SpendAuthorisations se misturem com aquelas que exigem, mas optam por atrasar a execução (ou seja, não envia a prova na mesma transação que SpendAuthorisation).

Árvore Merkle de SpendAuthorization

Uma árvore Merkle adicional é criada, com SpendAuthorizations armazenados como pares (control_account, enc_ck(SpendAuthorization)) onde enc_ck é a criptografia simétrica com chave derivada de proving_key por esquema de criptografia simétrica amigável ao snark (por exemplo, este). O SpendAuthorization em si contém campos:

opType, // TRANSFER | WITHDRAW
invalidatedNotesHash, // hash of sorted list of input note commitments
newNotesHash, // hash of sorted list of output note commitments
value, // WITHDRAW value (0 for TRANSFER)
recipient, // EVM address (0 for TRANSFER)
expiry, // block/time after which this authorisation is invalid
control_account, // address
privacySystemId // domain separation inside EIP-712

Para inserir SpendAuthorization na árvore Merkle, o controlador chama:

• AddSpendAuthorization: o control_account envia ciphertext. O contrato acrescenta (control_account, ciphertext) e anexa.

Comentário sobre a criação de SpendAuthorization:

Em geral, existem duas maneiras de os usuários utilizarem este sistema: armazenando todos os segredos localmente ou delegando-os a algum sistema externo. No primeiro cenário, o SpendAuthorization pode ser facilmente criado com base em todos os dados de sua propriedade. Neste último caso, é um pouco mais complicado e o controlador precisa iniciar a comunicação com o Prover antes de construir a autorização para aprender:

Modelo de privacidade:

À primeira vista, pode parecer enviar SpendAuthorizations diretamente do control_account anula totalmente o propósito do sistema através do vazamento de relação com o controlador. Não é exatamente o caso:

• no contexto de uma transação privada, a única informação realmente revelada é que control_account executou ALGUMA operação. Este é, sem dúvida, um grau bastante elevado de privacidade, especialmente control_account pode ser alternado de forma privada à vontade e o novo só precisa de fundos para o custo do gás para enviar transações.

• mesmo no contexto da retirada, nem toda a privacidade precisa ser cedida – atrasando a execução (ou seja, usando AdicionarSpendAutorização e atrasar o envio de uma prova via retransmissor), o usuário pode efetivamente diminuir as chances de vincular uma retirada específica ao fato de enviar SpendAuthorization.

• em geral ao enviar SpendAuthorization com comprovante, aconselha-se a utilização de transação privada mesmo no caso de destinatários que normalmente não utilizam o sistema. O simples fato de que o destinatário provavelmente reivindicará a transferência recebida com algum atraso aumenta a privacidade.

Modelo de ameaça

• proving_key vazamentos: o invasor pode ler saldos/histórico do período entre as rotações, mas não posso gastar.

• acesso ao control_account vazamentos: a custódia foi perdida

• provador/retransmissor é malicioso: eles não podem gastar sem SpendAuthorization; eles podem reter provas, mas trocar o retransmissor resolve isso

Extensões razoáveis ​​omitidas para maior clareza:

• tags de visualização devem ser adicionadas a SpendAuthorizations para simplificar a verificação de SpendAuthorizations de sua propriedade