Vitalik recomenda o uso de zk-SNARKs para separar contas lógicas de negociação de contas que possuem ativos. Isso melhora a privacidade, a experiência do usuário e a recuperação social com um clique. O pesquisador da Ethereum, Toni Wahrstätter, fornece uma análise detalhada deste protótipo de carteira, cobrindo fluxo de trabalho e vantagens.
Muito obrigado a Matt pelas ótimas discussões sobre este tópico e por desenvolver esta ferramenta para analisar cada contrato e colocá-lo em uma árvore Merkle esparsa que simplifica a prototipagem, eliminando a necessidade de provas zk na árvore Patrícia. Além disso, obrigado a Vitalik por sua excelente contribuição.
Gerenciar várias contas pode ser desafiador por vários motivos, incluindo recuperação social, privacidade, L2 e problemas gerais de experiência do usuário. Usar um endereço furtivo torna as coisas mais complicadas porque cada interação requer uma nova conta. Vitalik recomenda o uso de zk-SNARKs para separar contas lógicas de negociação de contas que possuem ativos. Isso melhora a privacidade, a experiência do usuário e a recuperação social com um clique.
Para o seguinte, recomendo primeiro verificar a postagem "Três Transformações" de Vitalik para obter informações básicas.
Em poucas palavras, o que estamos tentando alcançar é:
**Recuperação social completa sem comprometer a privacidade. **
1. Método tradicional
Uma implementação simples, mas que compromete a privacidade, é assim:
O usuário fornece uma assinatura e alguma intenção/comando para a conta de depósito de ativos.
A conta de depósito de ativos encaminha a assinatura para a conta de depósito lógica.
A conta de depósito lógica deriva a chave pública da assinatura e compara-a com a sua chave pública armazenada.
Se a verificação for aprovada, a conta lógica notificará a conta de depósito de ativos para continuar a operação.
A conta de depósito de ativos executa as ordens do usuário.
A desvantagem é que isso vincula publicamente contas lógicas e contas de depósito de ativos, comprometendo assim a privacidade.
2. Use ZK-SNARK
Ao usar zk-SNARKs, os usuários podem provar que estão autorizados a gastar sem revelar a conexão entre a conta de depósito lógica e a conta de depósito de ativos.
O fluxo de trabalho é o seguinte:
O usuário constrói localmente uma árvore Merkle e identifica as folhas que contêm seu contrato.
1.1. Uma árvore Merkle contém basicamente os valores slot0 e slot1 de cada contrato existente, classificados por data ou nome.
1.2. Cada usuário pode construir uma árvore Merkle localmente com base no estado mais recente.
O usuário constrói uma prova zk para provar que conhece o segredo da conta de depósito lógica. Prova em detalhes mais tarde.
O usuário envia prova zk para a conta de depósito de ativos.
Certificado de verificação de conta de depósito de ativos, confirmando o seguinte:
4.1 Os usuários sabem onde está a lógica.
4.2 O usuário conhece um valor secreto que é hash e mapeado para o valor armazenado na conta de retenção lógica.
4.3 Os usuários podem reconstruir o estado da conta raiz da árvore Merkle mantida na cadeia canônica (por exemplo, pré-compilada)
4.4 Use números aleatórios corretos (usados para trocar chaves em contas de depósito lógicas).
Essencialmente, um usuário pode dizer: "Tenho permissão comprovada da conta de retenção lógica para executar esta ação e sei a localização dessa conta lógica".
vantagem
Experiência do usuário: uma chave privada ou uma configuração de múltiplas assinaturas pode controlar várias contas, mesmo que estejam em L2s diferentes.
Restaurar: as contas podem ser restauradas mais facilmente com uma única atualização de contrato.
Privacidade: Sem links públicos entre contas.
Compatibilidade: Isso ajuda a popularizar carteiras de Abstração de Conta (AA) e outros recursos.
Além disso, ao adicionar outro contrato (agregador) entre a lógica e o contrato de detenção de ativos, múltiplas provas de diferentes contas de detenção de ativos podem ser fornecidas numa única transação, permitindo que a conta seja tratada quase como um UTXO. Os agregadores poderão obter vários certificados zk e encaminhá-los para suas respectivas contas de retenção de ativos para verificação. É claro que tal agregador poderia criar ligações – incluindo privacidade – entre contas individuais de detenção de activos.
Vale a pena notar que não é necessariamente uma escolha entre usar SNARKs (e, portanto, confiar em sua segurança) e não usar SNARKs (e, portanto, perder boas propriedades de privacidade). Um compromisso poderia ser usar uma prova SNARK para abrir uma janela de tempo no contrato de retenção lógica, seguida por um pequeno atraso, após o qual o proprietário do contrato de retenção lógica pode alterar o valor do slot0, em vez de exigir uma prova SNARK para gastar e alterando assim a lógica de consumo. O atual proprietário do contrato pode usar um atraso antes da abertura da janela de tempo para evitar atualizações de credenciais.
detalhes técnicos
A configuração zk-SNARK inclui elementos privados:
Chave usada para verificação.
O endereço da conta de depósito lógica é o endereço apontado pela conta de depósito de ativos.
Ramo Merkle para identificar valores de estado específicos.
Um nonce que permite a rotação de chaves enquanto invalida chaves antigas. Elementos privados, como endereços de contratos e segredos de lógica de texto simples, não são tornados públicos, mas são usados para vincular de forma privada contas de retenção lógica e contas de retenção de ativos. Ao gerar provas de todo o estado, não há necessidade de uma autoridade central construir uma árvore Merkle para enviar provas.
1. Conta de retenção lógica
Um protótipo para uma conta bancária lógica pode ser assim:
solidez do pragma >=0,7,0 <0,9,0;
contrato LogicHoldingAccount é próprio { uint256 public slot0 = 0x1234; // hash secreto uint256 public nonce = 0; // acompanhar as principais alterações no endereço do proprietário público;
function updateOwner(uint256 newValue) public onlyOwner { nonce += 1; slot0 = novoValor;
slot0: a variável pública que inicialmente contém o valor do hash. Somente o proprietário conhece a pré-imagem com hash.
nonce: Um contador que rastreia o número de atualizações de informações do proprietário. Isso garante que as chaves antigas se tornem inválidas.
updateOwner(uint256 newValue): Função que atualiza o valor e adiciona um número aleatório.
Este contrato rastreia a lógica de gastos atual do proprietário (slot0) e permite atualizações por meio da função updateOwner.
2. Conta titular de conta
solidez do pragma >=0,7,0 <0,9,0;
contrato AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234...;
// Tamanho do campo escalar, Tamanho do campo base, Dados da chave de verificação, etc. // ...
função verificarProof( uint [2] dados de chamada _pA, uint [2] [2] dados de chamada _pB, uint [2] dados de chamada _pC, uint [2] calldata _pubSignals) public view return (bool val) { // Código assembly Snarkjs para verificação de prova... // ... }
// _pubSignals [0] - a raiz da árvore Contract-slot0||nonce Merkle // _pubSignals [1] - a função de endereço do detentor lógico hased ute (endereço a pagar a, valor uint256, uint [2] dados de chamada _pA, uint [2] [2] dados de chamada _pB, uint [2] dados de chamada _pC, uint [2] calldata _pubSignals) public { contractRootPrecompile.getRoot(block.number) uint256 especificadoLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, "Não permitido");
As contas de retenção de ativos armazenam ativos como ETH e permitem que os usuários enviem comprovantes de retiradas. Ao verificar se o especificadoLogicHolder corresponde ao logicHoldingAccountHash, o proprietário pode garantir que o contrato de retenção de ativos aceite apenas provas do contrato de retenção lógica autorizado, em vez de qualquer contrato arbitrário.
O segredo fornecido como sinal privado na construção da prova garante que apenas o dono da conta que contém a lógica de gastos possa acessar os fundos da conta de depósito de ativos.
3. Circuito
O circuito a seguir foi desenvolvido usando circcom, o código completo pode ser encontrado aqui.
template Main(níveis) { raiz de entrada de sinal; lógica de entrada de sinalHoldingAddressHash; lógica de entrada de sinalHoldingAddress; segredo de entrada de sinal; entrada de sinal nonce; caminho de entrada de sinalElements [levels] ; caminho de entrada de sinalÍndices [levels] ; componente secretHasher = SecretHasher(); secretHasher.secret <== segredo; componente hasher = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; árvore de componentes = MerkleTreeChecker(níveis); tree.leaf <== hasher.commitment; árvore.root <== raiz; for (i = 0; i < níveis; i++) { tree.pathElements [i] <== pathElements [i] ; árvore.pathIndices [i] <== índices de caminho [i] ;
componente principal {public [root,logicHoldingAddressHash]} = Main(N);
O circuito tem um total de 7 sinais, 2 dos quais são públicos, nomeadamente a raiz da árvore Merkle e o endereço hash da conta de depósito lógica (que deve ser hash antes de ser codificado no contrato de detenção de ativos para evitar que os observadores agreguem a conta) classe) com base na mesma lógica da conta titular).
para concluir
Num mundo onde os utilizadores devem gerir múltiplas contas, a necessidade de uma funcionalidade de recuperação social centralizada está a tornar-se cada vez mais importante. Zk-SNARK pode ser usado em carteiras que implementam separação lógica/ativos, permitindo aos usuários usar a “lógica” da Conta A para gastar da Conta B sem criar um link entre as duas. Como primeiro passo, as provas SNARK podem ser utilizadas para ações menos arriscadas do que desembolsos de ativos. Por exemplo, um bom ponto de partida pode ser permitir que os usuários iniciem “solicitações de retirada”. Se o proprietário do contrato de retenção lógica não levantar objeções, o usuário poderá finalizar a solicitação após um período de tempo.
Desta forma, o titular do contrato de retenção lógica ainda pode intervir, ainda que de forma violadora da privacidade, caso algo inesperado aconteça.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Recuperação social completa: Como os zk-SNARKs realizam a separação entre a lógica de transação da carteira e os ativos?
Autor original: @Toni Wahrstätter
Data de lançamento: 12 de setembro de 2023
Tradução: Instituto de Pesquisa DeBox
Prefácio
Vitalik recomenda o uso de zk-SNARKs para separar contas lógicas de negociação de contas que possuem ativos. Isso melhora a privacidade, a experiência do usuário e a recuperação social com um clique. O pesquisador da Ethereum, Toni Wahrstätter, fornece uma análise detalhada deste protótipo de carteira, cobrindo fluxo de trabalho e vantagens.
Gerenciar várias contas pode ser desafiador por vários motivos, incluindo recuperação social, privacidade, L2 e problemas gerais de experiência do usuário. Usar um endereço furtivo torna as coisas mais complicadas porque cada interação requer uma nova conta. Vitalik recomenda o uso de zk-SNARKs para separar contas lógicas de negociação de contas que possuem ativos. Isso melhora a privacidade, a experiência do usuário e a recuperação social com um clique.
Em poucas palavras, o que estamos tentando alcançar é:
**Recuperação social completa sem comprometer a privacidade. **
1. Método tradicional
Uma implementação simples, mas que compromete a privacidade, é assim:
A desvantagem é que isso vincula publicamente contas lógicas e contas de depósito de ativos, comprometendo assim a privacidade.
2. Use ZK-SNARK
Ao usar zk-SNARKs, os usuários podem provar que estão autorizados a gastar sem revelar a conexão entre a conta de depósito lógica e a conta de depósito de ativos.
O fluxo de trabalho é o seguinte:
1.1. Uma árvore Merkle contém basicamente os valores slot0 e slot1 de cada contrato existente, classificados por data ou nome.
1.2. Cada usuário pode construir uma árvore Merkle localmente com base no estado mais recente.
O usuário constrói uma prova zk para provar que conhece o segredo da conta de depósito lógica. Prova em detalhes mais tarde.
O usuário envia prova zk para a conta de depósito de ativos.
Certificado de verificação de conta de depósito de ativos, confirmando o seguinte:
4.1 Os usuários sabem onde está a lógica.
4.2 O usuário conhece um valor secreto que é hash e mapeado para o valor armazenado na conta de retenção lógica.
4.3 Os usuários podem reconstruir o estado da conta raiz da árvore Merkle mantida na cadeia canônica (por exemplo, pré-compilada)
4.4 Use números aleatórios corretos (usados para trocar chaves em contas de depósito lógicas).
Essencialmente, um usuário pode dizer: "Tenho permissão comprovada da conta de retenção lógica para executar esta ação e sei a localização dessa conta lógica".
vantagem
Além disso, ao adicionar outro contrato (agregador) entre a lógica e o contrato de detenção de ativos, múltiplas provas de diferentes contas de detenção de ativos podem ser fornecidas numa única transação, permitindo que a conta seja tratada quase como um UTXO. Os agregadores poderão obter vários certificados zk e encaminhá-los para suas respectivas contas de retenção de ativos para verificação. É claro que tal agregador poderia criar ligações – incluindo privacidade – entre contas individuais de detenção de activos.
detalhes técnicos
A configuração zk-SNARK inclui elementos privados:
1. Conta de retenção lógica
Um protótipo para uma conta bancária lógica pode ser assim:
solidez do pragma >=0,7,0 <0,9,0;
contrato LogicHoldingAccount é próprio { uint256 public slot0 = 0x1234; // hash secreto uint256 public nonce = 0; // acompanhar as principais alterações no endereço do proprietário público;
function updateOwner(uint256 newValue) public onlyOwner { nonce += 1; slot0 = novoValor;
Este contrato rastreia a lógica de gastos atual do proprietário (slot0) e permite atualizações por meio da função updateOwner.
2. Conta titular de conta
solidez do pragma >=0,7,0 <0,9,0;
contrato AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234...;
// Tamanho do campo escalar, Tamanho do campo base, Dados da chave de verificação, etc. // ...
função verificarProof( uint [2] dados de chamada _pA, uint [2] [2] dados de chamada _pB, uint [2] dados de chamada _pC, uint [2] calldata _pubSignals) public view return (bool val) { // Código assembly Snarkjs para verificação de prova... // ... }
// _pubSignals [0] - a raiz da árvore Contract-slot0||nonce Merkle // _pubSignals [1] - a função de endereço do detentor lógico hased ute (endereço a pagar a, valor uint256, uint [2] dados de chamada _pA, uint [2] [2] dados de chamada _pB, uint [2] dados de chamada _pC, uint [2] calldata _pubSignals) public { contractRootPrecompile.getRoot(block.number) uint256 especificadoLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, "Não permitido");
bool validProof = verifyProof(_pA, _pB, _pC, _pubSignals) == verdadeiro; if (validProof) { (bool sucesso,) = to.call{value:amount}(""); exigir (sucesso); } }
receber() pagamento externo {
As contas de retenção de ativos armazenam ativos como ETH e permitem que os usuários enviem comprovantes de retiradas. Ao verificar se o especificadoLogicHolder corresponde ao logicHoldingAccountHash, o proprietário pode garantir que o contrato de retenção de ativos aceite apenas provas do contrato de retenção lógica autorizado, em vez de qualquer contrato arbitrário.
O segredo fornecido como sinal privado na construção da prova garante que apenas o dono da conta que contém a lógica de gastos possa acessar os fundos da conta de depósito de ativos.
3. Circuito
O circuito a seguir foi desenvolvido usando circcom, o código completo pode ser encontrado aqui.
pragma circo 2.0.2;
incluir "./modules/merkleTree.circom"; incluir "./modules/commitmentHasher.circom";
template Main(níveis) { raiz de entrada de sinal; lógica de entrada de sinalHoldingAddressHash; lógica de entrada de sinalHoldingAddress; segredo de entrada de sinal; entrada de sinal nonce; caminho de entrada de sinalElements [levels] ; caminho de entrada de sinalÍndices [levels] ; componente secretHasher = SecretHasher(); secretHasher.secret <== segredo; componente hasher = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; árvore de componentes = MerkleTreeChecker(níveis); tree.leaf <== hasher.commitment; árvore.root <== raiz; for (i = 0; i < níveis; i++) { tree.pathElements [i] <== pathElements [i] ; árvore.pathIndices [i] <== índices de caminho [i] ;
componente principal {public [root,logicHoldingAddressHash]} = Main(N);
O circuito tem um total de 7 sinais, 2 dos quais são públicos, nomeadamente a raiz da árvore Merkle e o endereço hash da conta de depósito lógica (que deve ser hash antes de ser codificado no contrato de detenção de ativos para evitar que os observadores agreguem a conta) classe) com base na mesma lógica da conta titular).
para concluir
Num mundo onde os utilizadores devem gerir múltiplas contas, a necessidade de uma funcionalidade de recuperação social centralizada está a tornar-se cada vez mais importante. Zk-SNARK pode ser usado em carteiras que implementam separação lógica/ativos, permitindo aos usuários usar a “lógica” da Conta A para gastar da Conta B sem criar um link entre as duas. Como primeiro passo, as provas SNARK podem ser utilizadas para ações menos arriscadas do que desembolsos de ativos. Por exemplo, um bom ponto de partida pode ser permitir que os usuários iniciem “solicitações de retirada”. Se o proprietário do contrato de retenção lógica não levantar objeções, o usuário poderá finalizar a solicitação após um período de tempo.
Desta forma, o titular do contrato de retenção lógica ainda pode intervir, ainda que de forma violadora da privacidade, caso algo inesperado aconteça.