Vitalik: Como as bolsas centralizadas podem provar seus fundos?

Sempre que uma exchange centralizada significativa entra em colapso, surge uma pergunta comum: podemos usar a tecnologia criptográfica para resolver o problema? As bolsas poderiam criar provas criptográficas mostrando que os fundos que mantêm na rede são suficientes para cobrir suas responsabilidades para com os usuários, em vez de apenas confiar em métodos “legais”, como permissões governamentais, revisões de auditores e verificação dos antecedentes pessoais daqueles que gerenciam e operam o intercâmbio. As bolsas poderiam estabelecer um sistema onde fosse 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 on-chain que “não podem fazer coisas ruins”, mas que atualmente são ineficientes e vazam privacidade. Este artigo se aprofundará nas tentativas históricas de tornar as transações mais próximas do trustless, nas limitações dessas tecnologias e em algumas ideias mais novas e poderosas usando ZK-SNARKs e outras tecnologias avançadas.

Balanços e árvores Merkle: prova de solvência à moda antiga

As primeiras tentativas das bolsas de usar métodos criptográficos para provar que não estavam fraudando seus usuários remontam a um longo caminho. Em 2011, a maior exchange de Bitcoin da época, a MtGox, provou que tinha fundos ao transferir 424.242 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 você provar que os depósitos dos clientes são iguais a X (uma “prova de responsabilidade”) e provar a propriedade das chaves privadas para X moedas (uma “prova de ativos”), você terá prova de solvência: você mostrou que a exchange tem fundos para reembolsar todos depositantes.

O método mais simples para comprovar depósitos era publicar uma lista de pares (nome de usuário, saldo). Cada usuário pode verificar se seu saldo foi incluído e qualquer pessoa pode verificar a lista inteira para garantir (i) que cada saldo não é negativo e (ii) que o total é igual ao valor reivindicado. No entanto, isso viola a privacidade, portanto, uma pequena modificação poderia ser feita: publicar uma lista de pares (hash(nome de usuário, salt), saldo) e enviar de forma privada a cada usuário seu valor salt. Mas mesmo isso vaza informações sobre o equilíbrio e padrões de mudanças no equilíbrio. O desejo de proteger a privacidade nos leva à próxima invenção: a tecnologia Merkle Tree (também conhecida como hash tree).

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

A tecnologia da árvore Merkle envolve colocar o balanço patrimonial de um cliente em uma árvore Merkle Sum. Nesta árvore, cada nó é um par (equilíbrio, hash). Os nós folha da camada inferior representam os saldos de clientes individuais e os valores de hash salgados de seus nomes de usuário. 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 de Merkle, assim 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 usuário um comprovante de saldo Merkle para comprovar suas participações. Os usuários têm então a garantia de que seu saldo está incluído corretamente como parte do total. Um exemplo de código simples pode ser encontrado aqui.

O vazamento de privacidade neste design é muito menor do que em uma lista totalmente pública e pode ser ainda mais reduzido embaralhando as ramificações cada vez que a raiz é publicada. No entanto, ainda existe algum vazamento de privacidade. Charlie pode saber que alguém tem saldo de 164 ETH, que a soma dos saldos de dois usuários é 70 ETH, etc. Um invasor que controla muitas contas ainda pode aprender muito sobre os usuários da exchange.

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

A verificação da prova de Greta falhará: a exchange terá que oferecer o nó de -500 ETH de Henry, que ela rejeitará por ser inválido. A verificação de Eve e Fred também falhará, já que o total de ETH nos nós intermediários acima de Henry é -230, tornando-os inválidos também! Para escapar do roubo, a bolsa terá que torcer para que ninguém na metade direita de toda a árvore verifique o comprovante de saldo.

Se a exchange puder identificar usuários no valor de 500ETH, e eles acreditarem que esses usuários não se preocuparão em verificar a prova ou não serão acreditados quando reclamarem por nunca terem recebido uma prova, então a exchange poderá escapar com segurança da punição por roubo. No entanto, a troca também poderia alcançar o mesmo efeito ao excluir esses usuários da árvore.

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

Melhorando a privacidade e a robustez com 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 supera completamente uma infinidade de problemas em tecnologias específicas desenvolvidas há décadas. Naturalmente, podemos usar ZK-SNARKs para simplificar e aumentar significativamente a privacidade nos protocolos de prova de responsabilidade.

A coisa mais simples que podemos fazer é colocar todos os depósitos dos usuários em uma á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 coletivamente um valor reivindicado . Adicionar uma camada de hashing para privacidade, dando a cada usuário uma filial Merkle (ou prova KZG) não revelará o saldo de nenhum outro usuário.

Usar compromissos KZG é um método para evitar vazamentos de privacidade, pois 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 utilizar um ZK-SNARK especializado para comprovar a soma e a não negatividade dos saldos do 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 assumir que os saldos estão dentro de ), e cada 16 posições rastreiam um total acumulado com um deslocamento, de modo que a soma é zero somente quando o total real é consistente com o total declarado. Se z for a -128ª raiz da unidade, podemos provar a seguinte equação.

O primeiro valor em uma configuração eficaz é 0 0 0 0 0 0 0 0 0 0 1 2 5 10 20 -165 0 0 0 0 0 0 0 0 1 3 6 12 25 50 -300… Para entender como tais equações podem ser transformadas em verificações polinomiais e depois em ZK-SNARKs, consulte meu artigo sobre ZK-SNARKs para obter mais explicações aqui e aqui . Embora não seja um protocolo ideal, na verdade demonstra que as provas criptográficas deste tipo não são tão misteriosas hoje em dia!

Com apenas algumas fórmulas adicionais, tais 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 activos suficientes para cobrir os fundos com algumas garantias. Um SNARK pode ser usado para provar esta restrição mais complexa, assegurando aos utilizadores 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 utilizado não só para depósitos de clientes em bolsas, mas também para uma gama mais ampla de empréstimos. Sempre que alguém toma um empréstimo, coloca um registro em um polinômio ou árvore contendo esse empréstimo, com a raiz dessa estrutura sendo publicada na cadeia. Isso permitiria que qualquer pessoa que buscasse um empréstimo fornecesse prova ZK aos credores de que não pediu muito emprestado de outros empréstimos. Em última análise, as inovações legais podem até fazer com que os empréstimos comprometidos desta forma tenham uma prioridade mais elevada do que os empréstimos não autorizados. Isto nos leva na mesma direção de uma ideia discutida em “Sociedade Descentralizada: Encontrando a Alma da Web3“: estabelecer um conceito de reputação negativa ou garantia na cadeia através de alguma forma de “token vinculado à alma”.

Prova de ativos

A versão mais simples de prova de ativos é o protocolo que vimos acima: para provar que você possui uma quantidade X de moedas, basta movimentar X moedas em um horário pré-acordado ou em uma transação que inclua a mensagem “Estes fundos pertencem a Binance” em seu campo de dados. Para evitar taxas de transação, você pode alternativamente assinar uma mensagem fora da rede; tanto o Bitcoin quanto o Ethereum têm padrões para mensagens de assinatura fora da cadeia.

Esta técnica simples de prova de ativos tem dois problemas práticos:

1. Processamento de “armazenamento frio”.

2. Dupla utilização de garantias.

Por razões de segurança, a maioria das bolsas mantém a maior parte 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 refrigerado que usei uma vez para fundos pessoais envolvia um computador permanentemente off-line, gerando um código QR contendo a transação assinada, que eu poderia digitalizar com 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 seguir vários caminhos:

• Mantenha alguns endereços de longo prazo conhecidos publicamente. A exchange gera vários endereços, publica comprovantes de propriedade uma vez e depois reutiliza esses endereços. Este é de longe o esquema mais simples, embora acrescente algumas restrições sobre como proteger a segurança e a privacidade.

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

• Opções de ZKP mais complexas. Por exemplo, uma exchange poderia definir todos os seus endereços como 1/2 assinaturas múltiplas, 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 assinatura múltipla 12/16. Para proteger a privacidade e evitar a exposição de todo o seu conjunto de endereços, uma exchange poderia até executar uma prova de conhecimento zero no blockchain, comprovando o saldo total de todos os endereços com esse formato na cadeia.

Outra questão importante é evitar a dupla utilização de garantias. As bolsas poderiam facilmente transferir garantias entre si como prova de reserva, fingindo ser solventes quando não o sã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 as diferentes bolsas, por exemplo, comprovar reservas todas as terças-feiras às 14h UTC.

A última questão é: podemos fazer prova de ativos em moeda fiduciária? As exchanges não guardam apenas criptomoedas; eles também detêm moedas fiduciárias no sistema bancário. Aqui, a resposta é: sim, mas tal processo dependerá inevitavelmente do modelo de confiança “fiduciário”: o próprio banco pode comprovar saldos, os auditores podem comprovar balanços, etc. pode ser feito dentro dessa estrutura, mas ainda vale a pena fazer.

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

Plasma e Validiums: Podemos tornar os CEXs irrestritos?

Suponha que queiramos ir mais longe: não queremos apenas provar que a bolsa tem fundos para reembolsar o dinheiro dos utilizadores. Em vez disso, queremos evitar completamente que a exchange roube os fundos dos usuários.

A primeira grande tentativa nesse sentido foi o Plasma, uma solução de extensão popular na comunidade de pesquisa Ethereum em 2017 e 2018. O Plasma funciona dividindo o saldo em um conjunto de “moedas” individuais, cada uma com um índice atribuído e localizada em uma 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 sendo publicada na cadeia.

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

A OmiseGo tentou construir uma troca descentralizada neste protocolo, mas desde então, eles mudaram para outras ideias. Nesse sentido, o próprio grupo Plasma também evoluiu, tornando-se agora o projeto Optimism, com foco em rollups EVM otimistas.

As limitações tecnológicas do Plasma, tal como concebido em 2018 (como a comprovação da fragmentação da moeda), não valem a pena serem consideradas. Desde o auge do discurso do Plasma em 2018, os ZK-SNARKs tornaram-se mais viáveis em casos de uso relacionados à expansão. Como mencionado anteriormente, os ZK-SNARKs mudaram tudo.

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

Tudo isso é 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 você pode desfrutar de benefícios como eficiência e ao mesmo tempo ter inúmeras proteções criptográficas para evitar que operadores centralizados sofram a maioria das formas de abuso.

Porém, na metade direita deste espaço de design, é necessário discutir uma questão fundamental: o tratamento dos erros do usuário. Até agora, o tipo de erro mais crítico é: O que deve ser feito se os usuários esquecerem suas senhas, perderem seus dispositivos, forem hackeados ou perderem o acesso às suas contas?

As exchanges podem resolver esse problema: primeiro por meio da recuperação de e-mail e, se isso falhar, por meio de formas mais complexas de recuperação via KYC. No entanto, para poder resolver tais problemas, as bolsas precisam ter controle real sobre as moedas. Para terem a capacidade de restaurar legitimamente o acesso às contas dos utilizadores, as exchanges precisam de ter o poder que também poderia ser potencialmente utilizado indevidamente para roubar fundos dessas contas. Esta é uma troca inevitável.

A solução ideal a longo prazo depende da autocustódia, complementada por tecnologias como carteiras de múltiplas assinaturas 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 Exchanges no Futuro

No curto prazo, existem duas categorias distintas de trocas: com custódia e sem custódia. Hoje, este último é representado por DEXes como o Uniswap. No futuro, também poderemos ver CEXes criptograficamente “restritos”, onde os fundos dos usuários são mantidos em algo semelhante a um contrato inteligente válido. Poderemos também testemunhar o surgimento de exchanges semi-custodiais, onde confiamos nelas com moeda fiduciária em vez de criptomoeda.

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

A longo prazo, espero que avancemos cada vez mais no sentido de que todas as exchanges sejam não-custodiais, pelo menos em termos de criptomoedas. A recuperação de carteira existirá para novos usuários que lidam com pequenas quantias e para instituições que necessitam de tais providências por motivos legais. Podem ser necessárias opções de recuperação altamente centralizadas, mas isso pode ser feito no nível da carteira, e não na própria exchange. A forma como o magic.link interage com plataformas como o Polymarket é um exemplo dessa 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 dinheiro para stablecoins garantidas por ativos, como o USDC. Contudo, alcançar plenamente este objectivo levará algum tempo.

Agradecimentos especiais a Balaji Srinivasan, bem como à equipe da Coinbase, Kraken e Binance por suas discussões.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [Chaincatcher]. Todos os direitos autorais pertencem ao autor original [Vitalik]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.