Sempre que uma troca centralizada significativa entra em colapso, surge uma pergunta comum: podemos usar a tecnologia criptográfica para resolver o problema? As bolsas podem criar provas criptográficas mostrando que os fundos que detêm na cadeia são suficientes para cobrir as suas responsabilidades para com os utilizadores, em vez de depender apenas de métodos “legais” como permissões governamentais, revisões de auditores e verificar os antecedentes pessoais daqueles que gerem e operam a bolsa. As bolsas podem estabelecer um sistema onde é fundamentalmente impossível retirar os fundos dos depositantes sem o seu consentimento. Potencialmente, poderíamos explorar todo o espectro entre CEXs ambiciosos e de bom coração que “não fazem coisas ruins” e DEXs em cadeia que “não podem fazer coisas ruins” mas são atualmente ineficientes e vazam privacidade. Este artigo irá aprofundar as tentativas históricas de tornar as transações mais próximas de fidedignas, as limitações destas tecnologias e algumas ideias mais novas e mais poderosas usando zk-SNARKs e outras tecnologias avançadas.

Balanços e Merkle Trees: Prova Antiga de Solvência

As primeiras tentativas das bolsas de usar métodos criptográficos para provar que não estavam a enganar os seus utilizadores podem ser rastreadas há muito tempo. Em 2011, a maior bolsa de Bitcoin na altura, a MtGox, provou que tinha fundos transferindo 424242 BTC para um endereço pré-anunciado. Em 2013, começaram as discussões sobre como provar o outro lado da equação: o tamanho total dos depósitos dos clientes. Se provar que os depósitos dos clientes são iguais a X (uma “prova de responsabilidade”) e provar a propriedade das chaves privadas para moedas X (uma “prova de activos”), tem prova de solvência: mostrou que a bolsa tem os fundos para reembolsar todos os depositantes.

O método mais simples para provar depósitos era publicar uma lista de pares (nome de utilizador, saldo). Cada utilizador pode verificar se o seu saldo foi incluído, e qualquer pessoa pode verificar a lista inteira para garantir que (i) cada saldo não é negativo e (ii) o total é igual ao valor reclamado. No entanto, isso viola a privacidade, então uma pequena modificação poderia ser feita: publicar uma lista de pares (hash (nome de utilizador, sal), saldo) e enviar a cada utilizador em particular o seu valor de sal. Mas mesmo isso vaza informações de saldo e padrões de mudanças de saldo. O desejo de proteger a privacidade leva-nos à próxima invenção: a tecnologia da árvore Merkle (também conhecida como hash tree).

Verde: Charlie node. Azul: David node, que também é o nó que Charlie receberá como parte da sua prova. Amarelo: Nó raiz, exibido publicamente a todos.

A tecnologia da árvore Merkle envolve colocar o balanço de um cliente numa árvore de soma Merkle. Nesta árvore, cada nó é um par (equilíbrio, hash). Os nós da folha da camada inferior representam os saldos individuais dos clientes e os valores de hash salgados dos seus nomes de utilizador. Em cada nó de nível superior, o saldo é a soma dos dois saldos abaixo e o valor do hash é o hash dos dois nós abaixo. Uma prova de soma Merkle, como uma prova de Merkle, é um “ramo” da árvore, composto de nós irmãos no caminho da folha à raiz.

As bolsas enviam a cada utilizador uma prova da soma Merkle do seu saldo para provar as suas participações. Os utilizadores têm então a garantia de que o seu saldo está corretamente incluído como parte do total. Um exemplo de código simples pode ser encontrado aqui.

O vazamento de privacidade neste design é muito menor do que numa lista totalmente pública e pode ser ainda mais reduzido embaralhando ramos cada vez que a raiz é publicada. No entanto, ainda existe alguma fuga de privacidade. Charlie pode saber que alguém tem um saldo de 164 ETH, que a soma dos saldos de dois utilizadores é 70 ETH, etc. Um invasor que controla muitas contas ainda pode aprender muito sobre os utilizadores da bolsa.

Um aspecto sutil mas importante deste esquema é a possibilidade de saldos negativos: E se uma bolsa com um saldo de cliente de 1390 ETH tiver apenas 890 ETH em reservas e tentar cobrir o défice adicionando um saldo de -500 ETH sob uma conta fictícia na árvore? Acontece que esta possibilidade não quebra o esquema, embora seja precisamente por isso que precisamos de árvores de soma Merkle em vez de árvores Merkle normais. Suponha que o Henry seja uma conta fictícia controlada pela bolsa, onde é colocado -500 ETH.

A verificação da prova de Greta falhará: a troca terá de lhe oferecer o nó de -500 ETH do Henry, que ela rejeitará por ser inválido. A verificação de Eve e Fred também falhará uma vez que o ETH total nos nós intermédios acima do Henry é -230, tornando-os inválidos também! Para escapar ao roubo, a bolsa terá de esperar que ninguém na metade direita de toda a árvore verifique a sua prova de saldo.

Se a troca puder identificar utilizadores no valor de 500ETH, e eles acreditarem que esses utilizadores ou não se preocuparão em verificar a prova ou não serão acreditados quando reclamarem de nunca terem recebido uma prova, então a troca pode escapar com confiança da punição por roubo. No entanto, a troca também poderá atingir o mesmo efeito excluindo estes utilizadores da árvore.

Portanto, com o único propósito de demonstrar prova de passivos, a tecnologia da árvore Merkle é essencialmente tão boa quanto o esquema de prova de passivo. Mas os seus atributos de privacidade ainda não são ideais. Pode usar as árvores Merkle de forma mais inteligente, por exemplo, fazendo de cada satoshi ou wei uma folha individual, mas, em última análise, com técnicas mais modernas, existem melhores maneiras de conseguir isso.

Melhorar a privacidade e a robustez com o zk-SNARKS

Os zk-SNARKs são uma tecnologia poderosa, potencialmente para a criptografia o que os transformadores são para a inteligência artificial: uma tecnologia universalmente potente que sobrecarrega completamente uma infinidade de questões em tecnologias específicas desenvolvidas décadas atrás. Naturalmente, podemos usar o zk-SNARKS para simplificar e melhorar muito a privacidade nos protocolos de prova de responsabilidade.

A coisa mais simples que podemos fazer é colocar todos os depósitos de utilizadores numa árvore Merkle (ou mais simplesmente, um compromisso KZG) e usar um ZK-SNARK para provar que todos os saldos na árvore não são negativos e somam-se coletivamente a um valor reivindicado. Adicionar uma camada de hashing para a privacidade, dar a cada utilizador uma filial Merkle (ou prova KZG) não revelará os saldos de nenhum outro utilizador.

Usar os compromissos KZG é um método para evitar fugas de privacidade, uma vez que elimina a necessidade de fornecer “nós irmãos” como prova. Um simples ZK-SNARK pode ser usado para provar a soma dos saldos e que cada saldo não é negativo. Podemos usar um ZK-SNARK especializado para provar a soma e a não negatividade dos saldos no referido KZG. Aqui está um exemplo simples que consegue isso. Introduzimos um polinómio auxiliar, que “estabelece os bits de cada saldo” (para fins ilustrativos, vamos supor que os saldos estão dentro), e cada 16 posições rastreiam um total em curso com um deslocamento, então a soma é zero apenas quando o total real é consistente com o total declarado. Se z é a -128ª raiz da unidade, podemos provar a seguinte equação.

O primeiro valor numa configuração eficaz é 0 0 0 0 0 0 0 0 1 2 5 10 20 -165 0 0 0 0 0 0 0 1 3 6 12 25 50 -300... Para perceber como essas equações podem ser transformadas em verificações polinomiais e depois em zk-SNARKs, consulte o meu artigo sobre zk-SNARKS para mais explicações aqui e aqui. Embora não seja um protocolo ideal, demonstra de facto que as provas criptográficas deste tipo não são tão misteriosas nos dias de hoje!

Com apenas algumas fórmulas adicionais, esses sistemas de restrições podem ser adaptados a cenários mais complexos. Por exemplo, num sistema de negociação alavancado, é aceitável que os utilizadores individuais tenham saldos negativos, desde que tenham outros ativos suficientes para cobrir os fundos com alguma garantia. Um SNARK pode ser usado para provar esta restrição mais complexa, tranquilizando os utilizadores de que a bolsa não arriscará os seus fundos, isentando secretamente outros utilizadores das regras.

A longo prazo, este tipo de prova de dívida ZK poderia potencialmente ser usado não só para depósitos de clientes nas bolsas mas também para uma gama mais ampla de empréstimos. Sempre que alguém toma um empréstimo, colocaria um registo num polinómio ou árvore contendo esse empréstimo, com a raiz desta estrutura a ser publicada na cadeia. Isso permitiria que qualquer pessoa que procurasse um empréstimo fornecesse provas ZK aos credores de que não pediram muito emprestado de outros empréstimos. Em última análise, as inovações legais podem até fazer com que os empréstimos cometidos desta forma tenham uma prioridade mais elevada do que os empréstimos não autorizados. Isto leva-nos na mesma direção que uma ideia discutida em “Sociedade Descentralizada: Encontrando a Alma da Web3“: estabelecer um conceito de reputação negativa ou colateral na cadeia através de alguma forma de “token com alma”.

Prova de Ativos

A versão mais simples da prova de activos é o protocolo que vimos acima: para provar que detém X quantidade de moedas, só precisa de mover X moedas num momento pré-acordado ou numa transação que inclua a mensagem “Estes fundos pertencem à Binance” no seu campo de dados. Para evitar taxas de transação, pode, alternativamente, assinar uma mensagem fora da cadeia; tanto o Bitcoin como o Ethereum têm padrões para mensagens de assinatura fora da cadeia.

Esta técnica simples de prova de ativos tem duas questões práticas:

1. Processamento de “armazenamento a frio”.

2. Dupla utilização de garantias.

Por razões de segurança, a maioria das bolsas mantém a maioria dos fundos dos seus clientes em “armazenamento frio”: em computadores offline onde as transações precisam ser assinadas manualmente e transferidas para a internet. A configuração de armazenamento a frio que uma vez usei para fundos pessoais envolvia um computador permanentemente offline, gerando um código QR contendo a transação assinada, que eu poderia digitalizar com o meu telefone. Os protocolos de troca modernos são mais complexos, muitas vezes envolvendo cálculos multipartidários entre vários dispositivos. Dadas essas configurações, mesmo uma mensagem extra para provar o controle sobre um endereço é uma operação cara!

Uma transação pode tomar vários caminhos:

• Manter alguns endereços de longo prazo conhecidos publicamente. A bolsa gera vários endereços, publica prova de propriedade para cada uma, e depois reutiliza esses endereços. Este é de longe o esquema mais simples, embora adicione algumas restrições sobre como proteger a segurança e a privacidade.

• Configure muitos endereços, provando aleatoriamente alguns. A troca pode ter muitos endereços, talvez usar cada um apenas uma vez e retirá-los após uma transação. Neste caso, a bolsa pode ter um protocolo para selecionar aleatoriamente alguns endereços que devem ser “abertos” para provar a propriedade. Algumas trocas já fizeram algo semelhante com auditores mas, em princípio, esta técnica pode tornar-se um processo totalmente automatizado.

• Opções de ZKP mais complexas. Por exemplo, uma bolsa poderia definir todos os seus endereços como 1/2 multi-assinaturas, onde a chave de cada endereço é diferente, e a outra é uma versão cega de alguma chave de backup de emergência “principal”, armazenada de uma forma complexa mas altamente segura, como uma multi-assinatura 12/16. Para proteger a privacidade e evitar expor todo o seu conjunto de endereços, uma troca pode até executar uma prova de conhecimento zero na cadeia de blocos, provando o saldo total de todos os endereços com este formato na cadeia.

Outra questão importante é impedir a dupla utilização de garantias. As bolsas poderiam facilmente transitar garantias entre si para a prova de reserva, fingindo ser solvente quando não estão. Idealmente, a prova de solvência seria em tempo real, atualizando a prova após cada bloco. Se isso não for prático, uma opção menos ideal é coordenar um horário fixo entre diferentes bolsas, por exemplo, provar reservas todas as terças-feiras às 14:00 UTC.

A última pergunta é: podemos fazer prova de ativos em moeda fidutiária? As bolsas não detêm apenas criptomoedas; também detêm moedas fiduciárias dentro do sistema bancário. Aqui, a resposta é: sim, mas tal processo dependerá inevitavelmente do modelo fiduciário “fiduciário”: o próprio banco pode provar saldos, auditores podem provar balanços, etc. Considerando que o fiat não pode ser verificado criptograficamente, este é o melhor que pode ser feito dentro desse quadro, mas ainda vale a pena fazer.

Outra abordagem é separar de forma limpa uma entidade que administra a bolsa e lida com stablecoins garantidos por ativos, como o USDC, de outra entidade que lida com o processo de entrada e saída de caixa entre criptomoedas e o sistema bancário tradicional (o próprio USDC). Uma vez que os “passivos” do USDC são apenas tokens ERC20 em cadeia, a prova de responsabilidade é “gratuita”, exigindo apenas prova de ativos.

Plasma e Validiums: Podemos tornar os CEXs sem restrições?

Suponha que queremos ir mais longe: não queremos apenas provar que a bolsa tem os fundos para reembolsar o dinheiro dos utilizadores. Em vez disso, queremos impedir completamente a bolsa de roubar fundos dos utilizadores.

A primeira grande tentativa a este respeito foi o Plasma, uma solução de extensão popular na comunidade de investigação Ethereum em 2017 e 2018. O Plasma funciona dividindo o saldo num conjunto de “moedas” individuais, cada uma atribuída a um índice e localizada numa posição específica na árvore Merkle de um bloco de Plasma. Uma transferência válida de uma moeda requer colocar a transação na posição correta na árvore, com a raiz da árvore a ser publicada na cadeia.

Um esquema simplificado de uma versão do Plasma. As moedas são armazenadas num contrato inteligente e as regras do protocolo Plasma são executadas à força durante a retirada.

OmiseGO tentou construir uma troca descentralizada neste protocolo, mas desde então, eles mudaram para outras ideias. A este respeito, o próprio grupo Plasma também evoluiu, tornando-se agora o projeto Optimism, concentrando-se em rollups otimistas de EVM.

As limitações tecnológicas do Plasma, tal como concebidas em 2018 (como provar a fragmentação da moeda), não valem a pena considerar. Desde o pico do discurso do Plasma em 2018, os zk-SNARKs tornaram-se mais viáveis em casos de utilização relacionados com a expansão. Como mencionado anteriormente, os zk-SNARKs mudaram tudo.

Uma versão mais moderna do conceito de Plasma é o que a Starkware chama de validium: essencialmente o mesmo que o ZK-Rollup, exceto que os dados são armazenados fora da cadeia. Esta estrutura pode ser usada para muitos casos de utilização, particularmente onde um servidor centralizado precisa de executar algum código e provar a sua execução correta. Num valídio, os operadores não podem roubar fundos, embora dependendo dos detalhes da implementação, alguns fundos do utilizador possam ficar presos se o operador desaparecer.

Tudo isto é muito promissor: a relação entre CEX e DEX está longe de ser uma oposição binária. Na verdade, há todo um espectro de opções, incluindo várias formas de centralização híbrida, onde pode usufruir de benefícios como a eficiência e, ao mesmo tempo, ter inúmeras salvaguardas criptográficas para prevenir os operadores centralizados da maioria das formas de abuso.

No entanto, na metade direita deste espaço de design, é necessário discutir uma questão fundamental: lidar com os erros do utilizador. Até agora, o tipo de erro mais crítico é: O que deve ser feito se os utilizadores esquecerem as suas palavras-passe, perderem os seus dispositivos, forem pirateados ou perderem o acesso às suas contas?

As trocas podem resolver este problema: primeiro através da recuperação de e-mail, e se isso falhar, através de formas mais complexas de recuperação via KYC. No entanto, para poder resolver esses problemas, as trocas precisam ter um controlo real sobre as moedas. Para ter a capacidade de restaurar legitimamente o acesso às contas de utilizador, as trocas precisam ter o poder que também poderia ser utilizado indevidamente para roubar fundos dessas contas. Este é um trade-off inevitável.

A solução ideal a longo prazo depende da autocustódia, complementada por tecnologias como carteiras multi-assinatura e de recuperação social, para ajudar os utilizadores a lidar com emergências. Mas, a curto prazo, existem duas soluções alternativas aparentes, cada uma com custos e benefícios distintamente diferentes.

Conclusão: Melhores Intercâmbios no Futuro

A curto prazo, existem duas categorias distintas de trocas: custódia e sem custódia. Hoje, este último é representado por DEXes como o Uniswap. No futuro, poderemos também ver CEXes criptograficamente “restritos”, onde os fundos dos utilizadores são mantidos em algo semelhante a um contrato inteligente de validium. Podemos também testemunhar o surgimento de trocas de semi-custódia, onde confiamos nelas com fiat em vez de criptomoeda.

Ambos os tipos de trocas continuarão a existir. A maneira mais simples e compatível com versões anteriores de aumentar a segurança das trocas de custódia é aumentar a prova de reservas. Isto envolve uma combinação de prova de activos e prova de passivo. O desenvolvimento de protocolos bem estruturados para ambos apresenta desafios técnicos, mas devemos progredir tanto quanto possível nas duas áreas, e abrir o código do software e dos processos para que todas as trocas possam beneficiar.

A longo prazo, espero que avancemos cada vez mais para que todas as bolsas não sejam de custódia, pelo menos em termos de criptomoeda. A recuperação da carteira existirá para novos utilizadores que lidam com pequenas quantias e para instituições que necessitem de tais arranjos por razões legais. Podem ser necessárias opções de recuperação altamente centralizadas, mas isso pode ser feito ao nível da carteira, não dentro da própria bolsa. A forma como o magic.link interage com plataformas como o Polymarket é um exemplo desta abordagem. Em termos de moeda fiduciária, o fluxo entre o sistema bancário tradicional e o ecossistema criptográfico pode ser facilitado por processos locais de entrada/saída de caixa para stablecoins apoiados em ativos, como o USDC. No entanto, atingir este objetivo totalmente levará algum tempo.

Agradecimentos especiais a Balaji Srinivasan, bem como aos funcionários da Coinbase, Kraken e Binance pelas suas discussões.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [Chaincatcher]. Todos os direitos de autor pertencem ao autor original [Vitalik]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.