As dark pools estão emergindo rapidamente como a próxima fronteira do setor de finanças descentralizadas (DeFi) do Ethereum. Os designs de dark pool mitigam problemas como incerteza de preço e privacidade de negociação inadequada em exchanges onchain - problemas que fizeram com que investidores externos ficassem cautelosos em relação ao DeFi, apesar dos benefícios óbvios como acesso a liquidez 24/7 e mecanismos de geração de rendimento inovadores.

Neste artigo, fornecemos uma visão geral das dark pools e exploramos seu papel nas finanças tradicionais e no DeFi. Além disso, explicamos os mecanismos das dark pools nativas de criptomoedas e discutimos possíveis obstáculos para a adoção mais ampla de dark pools na cadeia.

Introdução: Dark pools na finança tradicional

Apesar de parecer sombria e ilegal, as dark pools são na verdade um componente de longa data do sistema financeiro tradicional (altamente regulamentado). Abaixo está uma definição de dark pool do Investopedia:

Um dark pool é um fórum ou bolsa financeira organizada privadamente para negociação de valores mobiliários. Dark pools permitem que investidores institucionais negociem sem exposição até depois da execução e relato da negociação. Dark pools são um tipo de sistema de negociação alternativo (ATS) que oferece a certos investidores a oportunidade de fazer pedidos grandes e realizar negociações sem revelar publicamente suas intenções durante a busca por um comprador ou vendedor.

As dark pools são populares entre investidores institucionais, indivíduos de alto patrimônio líquido, fundos de hedge, empresas de fundos mútuos e outras entidades que desejam executar negociações em grande escala de forma anônima. O desejo de realizar negociações de forma anônima deriva da sensibilidade dos preços de mercado à demanda e oferta percebidas (ainda mais aumentada pelas plataformas de negociação eletrônica que permitem respostas quase instantâneas a sinais fracos). Isso é especialmente verdadeiro em bolsas tradicionais onde o livro de ordens é público e as pessoas podem colocar ou cancelar ordens à vontade.

O livro de ordens numa bolsa de central limit orderbook (CLOB) é público. (fonte)

Suponha que Alice coloca uma ordem de venda no mercado para vender 500 ações da Tesla em uma exchange. Esta é uma ordem pequena que terá pouco impacto no preço das ações da Tesla oferecidas na exchange. No entanto, Alice colocar uma ordem para vender 10 milhões de ações da Tesla é uma coisa completamente diferente.

Nesse cenário, uma grande ordem de venda visível no livro de ofertas sinaliza uma possível queda na demanda pelas ações da Tesla. Empresas de negociação sofisticadas, especialmente aquelas que utilizam algoritmos de negociação de alta frequência (HFT), provavelmente perceberão esse sinal. Elas podem agir rapidamente vendendo suas posições antes que a ordem de Alice seja executada, antecipando uma queda no preço das ações da Tesla. Consequentemente, o valor de mercado das ações da Tesla poderia diminuir, resultando em um preço de execução pior para Alice. Se Alice não estiver utilizando técnicas avançadas de negociação, sua operação pode resultar em prejuízo porque a queda no preço ocorre antes que sua ordem seja preenchida.

O problema é ainda mais complicado pela presença deempresas de HFTque empregam algoritmos proprietários capazes de responder em tempo real à atividade em uma bolsa de valores de livro de ordens central (CLOB). Aqui estão alguns cenários hipotéticos:

Frontrunning

Imagine Alice, uma investidora, decide vender um grande número de ações da Tesla numa bolsa de valores tradicional. Se ela colocar a sua ordem de venda no mercado, os detalhes desta ordem, incluindo o tamanho e a intenção, tornam-se publicamente visíveis para outros participantes antes do negócio ser finalizado. Uma empresa de negociação sofisticada, equipada com algoritmos de negociação de alta velocidade, pode notar esta grande ordem e agir rapidamente com base nesta informação.

Por exemplo, a empresa de negociação pode decidir vender suas próprias ações da Tesla antes que a ordem de Alice seja executada, antecipando que sua grande venda de ações irá diminuir o preço das ações. Ao fazer isso, a empresa garante um preço mais alto para suas ações antes que o mercado reaja à venda de Alice. Uma vez que a grande ordem de Alice for executada, o grande volume de ações atingindo o mercado faz com que o preço caia, e a empresa de negociação pode então recomprar as mesmas ações a um preço com desconto, lucrando com a diferença.

Esta prática, chamada de frontrunning, explora a visibilidade da ordem de Alice para obter uma vantagem financeira à custa dela. O resultado para Alice é um preço de execução pior para sua negociação, porque o mercado reage negativamente antes que sua ordem seja completada. Frontrunning é um problema significativo em sistemas financeiros tradicionais onde os livros de ordens são públicos, permitindo que certos participantes ajam com base em informações antes que outros tenham a chance.

Desvanecimento de cotação

Vamos continuar com o exemplo de Alice, mas desta vez focando no comportamento dos market makers - entidades que fornecem cotações de compra e venda em uma exchange. Suponha que a grande ordem de venda de Alice se torne visível no livro de ofertas público da exchange. Um market maker inicialmente tinha uma oferta permanente para comprar ações da Tesla a $200 cada. Ao ver a ordem de venda considerável de Alice, o market maker pode suspeitar que o aumento do fornecimento fará com que o preço das ações da Tesla caia.

Para evitar comprar as ações a $200 apenas para ver o seu valor diminuir, o market maker cancela ou modifica rapidamente a sua ordem de compra. Esta ação, conhecida como fading de cotação, remove eficazmente a liquidez do mercado. Quando a ordem de venda de Alice finalmente é executada, há menos compradores restantes, e ela tem que se contentar com um preço mais baixo - talvez $195 em vez de $200.

A desvantagem injusta da cotação desaparecida prejudica os negociantes como Alice, permitindo que os provedores de liquidez ajustem suas cotações com base em conhecimentos semelhantes aos de insiders sobre as negociações de outros participantes. Como o livro de ordens é público em bolsas centralizadas de livro de ordens limitadas (CLOB), os formadores de mercado podem ver as ordens recebidas em tempo real e reagir de acordo. Infelizmente, Alice não tem como impedir que sua negociação seja afetada por essa prática, pois ela decorre da transparência do próprio livro de ordens.

Por que dark pools?

As dark pools surgiram na finança tradicional como resposta aos problemas mencionados anteriormente. Ao contrário de uma bolsa de valores "iluminada", as dark pools executam negociações fora das bolsas públicas, como a NYSE (Bolsa de Valores de Nova Iorque) e a Nasdaq. As ordens enviadas por compradores e vendedores são correspondidas diretamente e somente o operador central tem informações sobre o livro de ordens.

Mais importante, cada pessoa que negocia através de uma dark pool está ciente apenas de sua própria(s) ordem(ns) e do preço de compensação. A menos que o operador central vaze informações, é impossível saber qualquer coisa sobre outros usuários - como suas identidades e tamanho/valor das ordens - mesmo ao negociar ativos com contrapartes.

Isso tem várias implicações para pessoas que desejam negociar com exposição mínima às flutuações do mercado. Especificamente, os traders podem conduzir negociações em larga escala sem revelar a intenção de comprar ou vender uma determinada ação ao público e reduzir o impacto de uma negociação no mercado de ações. Isso aumenta a certeza de que uma negociação significativa não sofrerá front running ou quote fading e o vendedor (ou comprador) terá o melhor preço disponível.

Suponha que Alice decida vender 10 bilhões de ações da Tesla em uma dark pool, estabelecendo um preço de venda de $1 por ação. A dark pool identifica e combina a ordem de Alice com a ordem correspondente de Bob para comprar 10 bilhões de ações da Tesla com a mesma avaliação. Quando a negociação é executada, o público permanece sem saber os detalhes da transação até depois do acerto. Somente então o mercado descobre que 10 bilhões de ações trocaram de mãos, mas sem saber as identidades do comprador ou vendedor, protegendo assim as intenções e estratégias de negociação de ambas as partes.

Podemos ver como negociar através de uma piscina escura protege os interesses de Alice e aumenta a qualidade da execução e a certeza do preço de compensação:

• Bob não sabe nada sobre Alice e apenas sabe que recebeu 10 bilhões de ações da Tesla por 10 bilhões de dólares, e alguém recebeu 10 bilhões de dólares por essas ações. Bob não pode desvanecer a cotação porque o livro de ordens está oculto - Bob deve planejar comprar efetivamente as ações para saber que alguém tem 10 bilhões de ações para vender (essa informação é conhecida quando a ordem é correspondida).
• Negociar à frente do trade de Alice é difícil, uma vez que o operador central obfusca os detalhes das ordens de compra e venda pendentes e a liquidez do mercado. A única forma de a trade de Alice se tornar informação pública é se o administrador da dark pool partilhar a informação com partes externas (isto é ilegal, no entanto).

Hoje, existem dezenas de pools em operação e estimativas sugerem que 40 por cento das negociações eletrônicas são realizadas através de dark pools. A crescente popularidade das piscinas escuras coincidiu com regulamentação crescente, especialmente dada a acesso privilegiado dos operadores de pools à informação sobre ordens pendentes (o Credit Suisse e o Barclays foram multados em um total de $150 milhões em 2016 por vazarem informações sobre negociações em dark pools para partes externas).

Piscinas escuras em DeFi

(origem)

Se as piscinas escuras são necessárias no TradFi, elas são, sem dúvida, ainda mais críticas no DeFi devido à transparência inerente dos sistemas de blockchain e aos desafios que isso cria para manter a privacidade e a qualidade da execução das negociações. Isso é especialmente verdadeiro para as bolsas descentralizadas (DEXes) que facilitam negociações eletrônicas e fornecem funcionalidades semelhantes às bolsas tradicionais.

• Os nós de arquivo podem consultar o blockchain para obter informações sobre transações históricas interagindo com uma piscina AMM e cruzá-las com a atividade onchain associada a um endereço específico. Isso torna trivial para qualquer pessoa copiar estratégias de negociação empregadas por traders alfa.
• A mempool, que armazena informações sobre transações pendentes, é pública e está disponível para qualquer pessoa conectada a um nó completo. Isso torna os usuários da DEX suscetíveis ao problema de cotação embaçada, onde as pessoas cancelam ordens de compra/venda em resposta a uma grande negociação capaz de mover o mercado e leva à execução com pior preço para os traders.
• O estado posterior de um DEX pode ser calculado facilmente por qualquer pessoa que observe o mempool, o que abre a porta para a extração maliciosa de MEV (valor máximo extraível) por validadores e bots de MEV. Esses atores podem observar o impacto de uma negociação na pool do DEX e decidir fazer uma operação de frontrun ou sandwich na transação se a simulação das mudanças de estado revelar lucros potenciais. (O fato de os usuários enviarem transações 'em aberto' para inclusão em um bloco agrava o problema.)
• A negociação DEX pode falhar se um produtor de blocos censurar deliberadamente uma transação de um utilizador. Como as informações da conta estão publicamente disponíveis, os validadores podem criar perfis para endereços específicos e escolher discriminar essas contrapartes ao processar transações.
• Os validadores podem ver informações sobre uma transação e decidir excluí-la do próximo bloco. Os utilizadores não podem ocultar os detalhes da transação dos validadores ou evitar divulgar a intenção de comprar/vender tokens.

(Origem)

Esses problemas fizeram com que as DEXes tradicionais deixassem de ser favoritas entre grandes investidores e traders institucionais sensíveis ao preço e à qualidade de execução. No entanto, a DeFi é a maior vítima, com as DEXes incapazes de substituir as bolsas TradFi, apesar de apresentarem várias qualidades, como transações sem fronteiras e execução transparente e sem confiança para os usuários. Novas alternativas como CowSwapeUniswapXparecem ter resolvido o problema, mas reintroduzem a necessidade de confiar num operador central, semelhante ao funcionamento dos dark pools tradicionais. Embora os dark pools no TradFi sejam privados no sentido em que as informações da conta são ocultas dos outros, esses dados permanecem acessíveis ao banco ou operador, tornando-os suscetíveis a abusos ou fugas de informação se os administradores forem pouco capazes ou pouco escrupulosos.

Levar as piscinas escuras onchain não é apenas possível, mas representa uma abordagem ótima para a construção de plataformas de negociação descentralizadas que ofereçam execução de qualidade sem uma dependência excessiva de operadores centrais. Embora a transparência inerente das blockchains - onde qualquer pessoa pode verificar a precisão computacional através da execução de um nó - possa parecer em desacordo com a funcionalidade da piscina escura, esse desafio pode ser superado. A solução está na tecnologia de aprimoramento de privacidade (PET), uma abordagem criptográfica que permite o ocultamento de informações enquanto mantém a integridade das atualizações do livro-razão. Isso nos permite aproveitar a verificabilidade da blockchain ao introduzir os recursos de privacidade essenciais para a operação da piscina escura.

Construir dark pools descentralizados pode parecer impossível, uma vez que as blockchains são projetadas para serem transparentes e consultáveis. Na verdade, é isso que torna as blockchains melhores do que os bancos de dados regulares: qualquer pessoa pode executar um nó e verificar se as alterações no banco de dados são computadas corretamente. Mas podemos contornar essa restrição aproveitando a criptografia - especificamente, a tecnologia de aprimoramento da privacidade (PET) - que permite ocultar informações garantindo que as atualizações do livro-razão sejam consistentes com as regras.

Como funcionam as piscinas escuras?

Não há uma maneira de construir um pool escuro onchain. No entanto, todos os dark pools de criptografia compartilham a característica comum: eles usam vários mecanismos criptográficos para ocultar informações sobre negociações onchain e aumentar a qualidade de execução para os usuários.

A Computação de várias partes (MPC), provas de conhecimento zero, criptografia em limiar, Criptografia Completamente Homomórfica (FHE) e Ambientes de Execução Confiáveis (TEEs) são algumas primitivas disponíveis para designers de mecanismos que trabalham em dark pools cripto-nativas. O objetivo em todos os casos é manter garantias em torno da privacidade das negociações sem aumentar suposições de confiança ou tornar o sistema suscetível a manipulação.

Renegado, Tristero, e Railgunsão exemplos de dark pools onchain no ecossistema Ethereum. Vamos dar uma breve olhada em cada um desses protocolos para fornecer uma visão geral de como as dark pools onchain funcionam na prática. Este artigo vai focar no Renegade, explorando seu design e a abordagem do protocolo para proteger informações sobre as negociações conduzidas pelos participantes do mercado.

Renegade: Acelerando DeFi privado com criptografia de ponta

Renegade é uma dark pool descentralizada e preservadora de privacidade, projetada para solucionar falhas críticas na paisagem de negociação descentralizada de finanças (DeFi) existente. Ao aproveitar técnicas criptográficas avançadas como provas de conhecimento zero (ZKPs) e computação multipartidária (MPC), o Renegade permite que os usuários realizem, correspondam e liquidem pedidos com segurança, sem revelar seus saldos, intenções de negociação ou estratégias a terceiros. Ao contrário das DEXes tradicionais, que expõem os dados do livro de pedidos à escrutínio público, o Renegade criptografa todas as informações da carteira e dos pedidos, garantindo que as negociações ocorram de forma privada e sejam resistentes à manipulação.

No seu núcleo, o Renegade permite aos utilizadores realizar negociações trustless e onchain com a mesma precisão e qualidade de execução das bolsas centralizadas, mantendo as garantias de privacidade necessárias para proteger contra frontrunning, quote fading e outras práticas exploratórias. Ao introduzir uma única árvore de merkle global para a gestão de estado, o Renegade mantém os benefícios da transparência da blockchain, como a verificabilidade e imutabilidade, ao mesmo tempo que protege os detalhes sensíveis das negociações do olhar do público.

Abordando os problemas dos sistemas DeFi atuais

O design das exchanges descentralizadas (DEXes) hoje - seja baseado em Automated Market Makers (AMMs) ou Central Limit Order Books (CLOBs) - introduz falhas críticas que afetam todos os participantes, desde usuários regulares até traders institucionais. Esses problemas surgem porque transações e ordens são transmitidas em texto simples em blockchains transparentes. Embora a transparência seja fundamental para a verificação sem confiança, também expõe os traders a práticas prejudiciais, como frontrunning, quote fading e perfilagem de endereços.

Tanto para pequenos traders como para grandes investidores, essas vulnerabilidades resultam em execução de negociações deficientes, perdas financeiras e redução da confiança na finança descentralizada. A Renegade elimina esses problemas ao introduzir técnicas criptográficas que mantêm a privacidade sem comprometer a integridade dos sistemas descentralizados.

Valor Máximo Extraível (MEV)

Lucro médio total MEV (conjunto de dados de 30 dias) de acordo com EigenPhi

Sempre que as ordens e transações são visíveis na mempool, elas se tornam suscetíveis à manipulação pelos produtores de bloco (na Camada 1) ou sequenciadores (na Camada 2). Esses atores podem reordenar, antecipar ou retroceder transações para obter lucro. Por exemplo, observar uma grande ordem de compra ou venda permite que atores maliciosos executem suas transações com taxas de gás mais altas primeiro (antecipação) ou explorem oportunidades imediatamente após a execução (retrocessão). Esta forma de MEV afeta todos os designs de DEX, independentemente de utilizarem uma arquitetura AMM ou CLOB.

Transparência comercial

A transparência dos orderbooks baseados em blockchain expõe os traders a riscos pré-negociação e pós-negociação:

• Riscos pré-negociação: Em sistemas de livro de pedidos abertos, ordens publicamente visíveis sinalizam a intenção dos negociadores, permitindo que adversários ajustem estratégias em resposta. Isso pode levar a táticas manipulativas como o desvanecimento de cotações, onde os provedores de liquidez retiram suas ordens para explorar negociações em curso, causando derrapagens e degradação na qualidade da execução.
• Riscos pós-negociação: Uma vez que uma negociação é executada, os seus detalhes, incluindo estratégias e padrões de negociação, são permanentemente registados na cadeia. Agentes maliciosos ou concorrentes podem analisar estes dados históricos para prever e explorar negociações futuras. Esta falta de privacidade pós-negociação deixa os traders, especialmente as instituições, vulneráveis à exploração.

Ao combinar esses em uma categoria mais ampla, Renegade aborda todo o ciclo de vida das questões de transparência comercial com soluções criptográficas que garantem privacidade pré-negociação e liquidação segura pós-negociação.

Perfilagem baseada em endereço

Em sistemas de blockchain transparentes, cada transação expõe o endereço da parte iniciante. Os adversários podem analisar estes dados para criar perfis detalhados, relacionando o comportamento de negociação com carteiras específicas. Este perfilamento permite práticas discriminatórias, como oferecer preços piores ou direcionar seletivamente determinados utilizadores. Embora as identidades blockchain sejam pseudônimas, análises sofisticadas podem correlacionar endereços com entidades do mundo real ou padrões comportamentais, agravando ainda mais estas vulnerabilidades.

O design centrado na privacidade da Renegade garante a proteção das identidades e estratégias dos usuários ao longo do processo de negociação, protegendo tanto os participantes varejistas quanto institucionais.

No cerne destes problemas está a transparência inevitável das blockchains. Enquanto a transparência garante verificação sem confiança e imutabilidade - qualidades críticas para sistemas descentralizados - também expõe detalhes sensíveis sobre a atividade do utilizador. Cada negociação, atualização de saldo ou transação pendente torna-se informação pública que atores adversários podem analisar, manipular ou explorar para obter lucro. Isto cria um sistema onde os utilizadores enfrentam desafios como extração de MEV, manipulação de negociações e perfilagem baseada em endereços, todos os quais degradam a qualidade de execução e erodem a confiança nos mercados descentralizados.

Para resolver esses problemas, o Renegade substitui a transparência por privacidade controlada através do uso combinado de provas de conhecimento zero (ZKPs) e computação multipartidária (MPC). ZKPs garantem que as negociações são válidas, os saldos são suficientes e as regras do protocolo são aplicadas sem nunca revelar o conteúdo da carteira ou detalhes da transação. Ao mesmo tempo, o MPC permite a correspondência segura de pedidos, onde várias partes colaboram para encontrar correspondências de negociação sem expor quaisquer entradas ou vazar informações sensíveis.

Em conjunto, estas técnicas formam um sistema contínuo onde as negociações permanecem privadas, a execução é verificável e os detalhes da ordem são ocultados ao longo do ciclo de vida. Isto elimina as vulnerabilidades inerentes às blockchains transparentes, preservando simultaneamente a descentralização e a validação sem confiança.

Compreendendo claramente os problemas que Renegade resolve e sua abordagem à privacidade, vamos mergulhar em como o sistema funciona para fornecer negociações seguras, privadas e justas.

Como funciona o Renegade sob o capô?

Renegade reimagina a negociação descentralizada, integrando técnicas criptográficas avançadas que redefinem os limites da transparência, privacidade e imparcialidade na DeFi. Ao abordar as limitações das trocas descentralizadas convencionais, a Renegade introduz uma abordagem inovadora que combina tecnologias de preservação de privacidade com negociação sem confiança, em cadeia.

Esta seção fornece uma visão mais detalhada dos componentes arquitetônicos exclusivos que alimentam Renegade. Vamos explorar:

• Design de árvore de compromisso e carteira: Como as carteiras dos usuários permanecem totalmente off-chain e privadas, protegidas por compromissos criptográficos e gerenciadas por meio de uma hierarquia de chaves sofisticada.
• Relayers e super relayers: O papel dos relayers na facilitação da correspondência e execução seguras de negociações, juntamente com sua integração com permissões de carteira delegada.
• Motor de correspondência MPC: mecanismo revolucionário de computação multiparte de duas partes do Renegade que garante correspondência de negociação privada e sem confiança.
• SNARKs colaborativos: como acordos atômicos são alcançados por meio da integração perfeita de provas de conhecimento zero com computação multiparte.
• Desempenho e escalabilidade: Uma discussão sobre as compensações envolvidas nas escolhas de design do Renegade e como sua arquitetura equilibra privacidade, descentralização e eficiência.

Aproveitando essas inovações, a Renegade não apenas resolve as falhas críticas dos modelos DEX existentes, mas também lança as bases para um ambiente de negociação descentralizado mais seguro, privado e equitativo.

As carteiras da Renegade e a árvore de compromissos

O Renegade introduz um modelo de gestão de estado que prioriza a privacidade e a verificabilidade. No seu cerne, o sistema utiliza uma Árvore de Compromisso, uma árvore global de Merkle apenas para acréscimo que armazena representações criptográficas (compromissos) das carteiras dos utilizadores. Este design garante que o conteúdo das carteiras permanece completamente privado, ao mesmo tempo que mantém as garantias de confiança dos sistemas descentralizados.

Ao contrário das exchanges descentralizadas tradicionais (DEXs), onde os dados da carteira são visíveis na cadeia, Renegade mantém todas as informações da carteira fora da cadeia, permitindo que os usuários gerenciem com segurança seus saldos, pedidos e histórico de transações sem expor detalhes sensíveis. Na cadeia, essas carteiras são representadas apenas por compromissos ocultos e de ligação, hashes criptográficos que obscurecem o conteúdo da carteira, garantindo que não possam ser adulterados ou reutilizados indevidamente.

Uma analogia: Carteiras como mini-rollups

Para entender melhor a arquitetura do Renegade, podemos estabelecer um paralelo com os rollups Ethereum. Num rollup, as transações são executadas off-chain, onde as alterações de estado ocorrem de forma privada e apenas a raiz do estado, uma representação criptográfica do estado cumulativo do rollup, é periodicamente submetida ao Ethereum. Juntamente com esta raiz do estado, é fornecida uma prova de conhecimento zero (ZKP) para validar que a transição de estado cumpre as regras do protocolo rollup sem revelar quaisquer detalhes da transação.

As carteiras renegadas operam de maneira surpreendentemente semelhante:

• Execução off-chain: Todas as operações de carteira, como colocação de ordens, atualizações de saldo e execução de negociação, ocorrem off-chain. Essas atualizações são refletidas no estado privado da carteira, inacessível a observadores externos, incluindo o Ethereum.
• On-chain commitment: Depois que o estado da carteira é atualizado, o novo compromisso é adicionado à árvore de compromisso. Esse compromisso serve como um resumo criptográfico dos novos saldos, pedidos e quaisquer alterações feitas durante o processo de atualização da carteira. A atualização é acompanhada por uma Prova de Conhecimento Zero (ZKP), garantindo que a transição do antigo estado da carteira para o novo seja válida.

Esta semelhança destaca como as Carteiras Renegade funcionam como mini-rollups. Processam independentemente as alterações de estado fora da cadeia, enquanto dependem da árvore de compromissos para sincronizar o seu estado com o sistema mais amplo. Importante, este processo é exclusivamente adaptado para melhorar a privacidade, em vez de escalabilidade, mantendo os dados da carteira opacos e ilegíveis para todos os observadores externos.

Esquema de compromisso-revelação para atualizações de carteira

Cada operação em uma carteira na Renegade segue um esquema de commit-reveal, garantindo privacidade e correção durante todo o processo de atualização. Esse mecanismo permite que os usuários modifiquem suas carteiras, mantendo a integridade do sistema.

1. Revelar a antiga carteira: O usuário envia uma prova de Merkle mostrando que o seu compromisso anterior de carteira existe como uma folha na Árvore de Compromisso. Crucialmente, esse processo de revelação não divulga nenhum detalhe sobre o conteúdo da carteira, preservando as garantias de privacidade pré-negociação do Renegade. O sistema apenas fica sabendo que o compromisso da carteira é válido e está incluído na árvore.
2. Calcular anuladores: Para evitar a reutilização de estados antigos de carteira, o Renegade requer o cálculo de dois anuladores para cada carteira: um anulador de gastos de carteira e um anulador de correspondência de carteira. Esses anuladores são derivados do compromisso da carteira antiga e um valor de aleatoriedade privado, garantindo a singularidade.

Os anuladores são então submetidos juntamente com o novo compromisso da carteira para garantir que a carteira antiga não possa ser reutilizada.

1. Comprometa-se com a nova carteira: o usuário gera um novo estado de carteira refletindo as atualizações desejadas - como colocação de ordem, ajustes de saldo ou liquidações de negociação - e calcula seu compromisso criptográfico. Uma Prova de Conhecimento Zero (ZKP) é enviada para provar o seguinte:
   • O compromisso da carteira antiga existe na Árvore de Compromissos.
   • Os anuladores são calculados corretamente e únicos.
   • A transição do estado da carteira antiga para o novo adere às regras do protocolo (por exemplo, sem aumentos de saldo não autorizados).
   • O utilizador possui as chaves secretas necessárias para autorizar a atualização.

Uma vez que a prova é verificada e os anuladores são confirmados como não utilizados, o contrato inteligente marca os anuladores da antiga carteira como "gastos" e insere o novo compromisso na Árvore de Compromisso.

(Fonte: Documentação Renegade)

A arquitetura baseada no compromisso da Renegade garante que os dados sensíveis de negociação permaneçam seguros em todos os momentos. A natureza de ocultação e vinculação das transações de carteira garante que nenhum observador externo possa inferir o conteúdo da carteira, mesmo com acesso à árvore de compromisso. Além disso, a aleatoriedade incluída no cálculo do compromisso da carteira impede que adversários criem tabelas de arco-íris para identificar estados comuns de carteira, como carteiras com saldo zero ou pedidos.

Ao combinar esses mecanismos criptográficos com provas de conhecimento zero, a Renegade alcança um design de privacidade em primeiro lugar, onde as operações da carteira são verificáveis, mas invisíveis para as partes externas. Isso garante que o protocolo mantenha a privacidade pré-negociação, protegendo os usuários de estratégias adversárias como a frente e manipulação de cotações.

Hierarquia de chaves e sistema de relayers

O Renegade depende de relayers para facilitar operações críticas como a correspondência de pedidos e a resolução, permitindo aos utilizadores negociar de forma eficiente sem comprometer a segurança. Para alcançar isto, o protocolo implementa uma hierarquia de chaves robusta, um enquadramento criptográfico que separa as permissões de controlo e visualização, garantindo que os utilizadores mantenham a custódia dos seus ativos enquanto delegam tarefas específicas aos relayers. Este sistema não só assegura informações sensíveis da carteira, mas também simplifica interações com relayers, tornando a negociação privada e descentralizada mais prática e amigável para o utilizador.

Como funciona a hierarquia de chaves

Embora o design atual da Hierarquia de Chave da Renegade tenha evoluído além da sua descrição inicial no whitepaper, os princípios fundamentais permanecem consistentes. Quando uma carteira é criada pela primeira vez e registrada na Árvore de Compromisso, ela inclui cinco segredos distintos que coletivamente definem sua funcionalidade. Esses segredos são:

• Par de chaves raiz: O par de chaves raiz é um par de chaves ECDSA (curva secp256k1), idêntico a uma chave privada Ethereum padrão. É a chave mais autoritária e concede custódia total sobre a carteira. Todas as operações que modificam o estado da carteira - como depósitos, retiradas, realização de pedidos ou cancelamentos - requerem uma assinatura da chave secreta raiz. Para garantir a máxima segurança, a chave raiz é mantida estritamente do lado do cliente e nunca é compartilhada com nenhuma parte externa, incluindo os relayers.
• Correspondência escalar: A correspondência escalar é um valor escalar secreto definido sobre a curva bn254 e serve como o mecanismo pelo qual os relayers são autorizados a enviar correspondências para liquidação para o contrato inteligente ou camada base. Ao contrário dos pares de chaves assimétricas tradicionais, a correspondência escalar é um único valor secreto que os relayers usam para gerar provas de conhecimento zero (ZKPs), provando seu conhecimento do pré-imagem do escalar sob o hash Poseidon. Isso garante que os relayers só possam liquidar correspondências explicitamente autorizadas pela configuração da carteira. Além disso, a correspondência escalar é associada a taxas predefinidas na carteira, permitindo que os usuários especifiquem as cobranças exatas que os relayers podem aplicar por seus serviços.
• Chave de API simétrica: A chave de API simétrica é uma ferramenta fora do protocolo usada para autenticar as interações entre o usuário e o relayer. Isso permite que relayers transmitam atualizações em tempo real, como mudanças na carteira ou status de pedidos, para o usuário sem comprometer a segurança da carteira ou sua integridade criptográfica. Embora não esteja diretamente relacionada às operações da carteira, essa chave facilita a comunicação perfeita e melhora a experiência geral de negociação.
• Semente cega e semente compartilhada: A semente cega e a semente compartilhada são componentes essenciais que permitem aos retransmissores descriptografar e processar informações da carteira de forma segura. Essas sementes funcionam como chaves de visualização, concedendo aos retransmissores a capacidade de acessar o estado privado da carteira. No entanto, como sementes, elas são dinamicamente hashadas em valores que mudam a cada transação. Isso garante que os valores cegos e compartilhados sejam específicos para a operação atual, evitando qualquer reutilização ou acesso não intencional.

A semente cega é responsável por indexar a carteira on-chain, criando uma cadeia de hash criptográfica que liga os estados da carteira. Isso garante que a presença da carteira na Árvore de Compromisso permaneça demonstrável sem expor seu conteúdo.

A semente compartilhada é usada para construir "compartilhamentos secretos" de dados de carteira, permitindo que o relayer colabore com o mecanismo de correspondência MPC durante o processo de correspondência de pedidos. Essa integração permite que os relayers realizem suas funções de forma segura e sem revelar detalhes sensíveis sobre a carteira para a rede mais ampla.

Como os relayers funcionam em renegade

Os relayers em Renegade são intermediários críticos que permitem que o protocolo mantenha sua natureza de preservação de privacidade e descentralização, ao mesmo tempo que oferece uma experiência de negociação perfeita. Atuando como facilitadores e possibilitadores, os relayers são capacitados pela hierarquia de chaves para executar operações específicas em nome do usuário sem comprometer a custódia da carteira ou a privacidade. Ao aproveitar os segredos incorporados na carteira, os relayers podem descriptografar informações da carteira, identificar pedidos pendentes e enviar correspondências para o contrato inteligente para liquidação - tudo isso mantendo garantias criptográficas rigorosas.

A relação entre os relayers e a Key Hierarchy é construída com base em um modelo claro de delegação. Os usuários compartilham apenas os segredos necessários, como o escalar de correspondência, a semente do ofuscador e a semente compartilhada, com o relayer. Esses segredos concedem ao relayer a capacidade de visualizar e processar os dados da carteira com segurança. O escalar de correspondência permite que os relayers autorizem e resolvam correspondências comprovando o conhecimento de sua pré-imagem de hash Poseidon por meio de provas de conhecimento zero (ZKPs). A semente do ofuscador e a semente compartilhada, por sua vez, garantem que os relayers possam acessar os dados da carteira sem expô-los a observadores externos ou obter controle não autorizado. Essa separação de poderes garante que os relayers tenham as ferramentas para realizar suas tarefas delegadas sem comprometer o controle ou a segurança geral do usuário.

Uma das principais vantagens deste sistema é que ele permite a delegação granular. Os relayers estão restritos aos papéis explicitamente permitidos pelos segredos compartilhados. Por exemplo, embora os relayers possam visualizar os detalhes da carteira e corresponder a pedidos pendentes, eles não podem modificar, retirar ou cancelar pedidos, pois o par de chaves raiz - a chave custodial final - permanece com o usuário. Este design garante que os usuários mantenham a propriedade total de suas carteiras, ao mesmo tempo que terceirizam tarefas específicas para maior eficiência.

Os Relayers também trazem uma conveniência significativa para o processo de negociação, lidando com a complexidade computacional da correspondência de pedidos com o motor de correspondência MPC e garantindo a validade dessas correspondências por meio dos SNARKs colaborativos. Esse mecanismo permite que os Relayers descarreguem grande parte do ônus técnico dos usuários, ao mesmo tempo em que mantêm as rigorosas garantias de privacidade pré e pós-negociação da Renegade. Ao gerenciar essas operações de forma segura, os Relayers não apenas protegem os detalhes sensíveis da carteira durante a correspondência e o acerto de pedidos, mas também aliviam muitos dos desafios de UX normalmente associados a sistemas de preservação de privacidade. Sua capacidade de fornecer atualizações em tempo real por meio da chave de API simétrica também aprimora a experiência do usuário, garantindo que os usuários estejam informados sobre suas negociações e o status da carteira, sem comprometer a segurança.

Na prática, este sistema cria um ambiente de negociação altamente flexível e seguro. Os utilizadores podem delegar as suas carteiras a intermediários por períodos prolongados, concedendo-lhes acesso persistente para corresponder ordens sem terem de partilhar repetidamente novas chaves. Ao mesmo tempo, os utilizadores podem revogar o acesso dos intermediários a qualquer momento, criando uma nova carteira e transferindo os seus ativos, redefinindo eficazmente a delegação. Este mecanismo equilibra a conveniência a longo prazo com a adaptabilidade a curto prazo, atendendo tanto aos traders casuais como aos participantes mais conscientes da segurança.

Ao integrar relayers em sua arquitetura, a Renegade alcança uma combinação rara de descentralização, privacidade e usabilidade. Relayers atuam como intermediários confiáveis sem exigir confiança explícita, graças aos salvaguardas criptográficos impostos pela Hierarquia de Chaves. Isso permite que a Renegade escale suas operações mantendo os mais altos níveis de segurança e autonomia do usuário.

Em resumo, a arquitetura de árvore de compromisso do Renegade e a hierarquia de chaves fornecem um quadro fundamental para equilibrar privacidade e verificabilidade em negociações descentralizadas. Ao garantir que as carteiras dos usuários permaneçam completamente off-chain e representadas on-chain apenas como compromissos criptográficos, o Renegade elimina a visibilidade de dados sensíveis de negociação.

Este design não só previne comportamentos de front-running, quote fading e outros comportamentos exploratórios, mas também permite aos utilizadores manter a custódia total dos seus fundos através do par de chaves raiz. O esquema de commit-reveal, em conjunto com o uso de ZKPs, garante que as atualizações da carteira e as transições de estado são seguras, à prova de adulteração e completamente opacas para observadores externos. Isso garante um ambiente de negociação onde a verificação sem confiança e a privacidade forte coexistem perfeitamente.

O sistema de relayers, integrado com a Hierarquia de Chave, eleva ainda mais a experiência do usuário e a eficiência operacional da Renegade. Os relayers simplificam o processo de negociação, gerenciando as tarefas computacionalmente intensivas de correspondência de pedidos e liquidação, aproveitando o mecanismo de correspondência MPC e a prova SNARK para manter a privacidade e garantir a correção. Ao mesmo tempo, sua capacidade de fornecer atualizações em tempo real através da chave API simétrica preenche a lacuna entre garantias robustas de privacidade e uma experiência de usuário tranquila.

Ao separar as permissões de visualização e correspondência, a hierarquia de chaves garante que os usuários mantenham o controle final sobre suas carteiras enquanto os relayers operam dentro de funções estritamente definidas. Este sistema cria um equilíbrio único em que os usuários se beneficiam das propriedades de preservação da privacidade de técnicas criptográficas avançadas sem encontrar as barreiras de usabilidade normalmente associadas a tais sistemas.

Como as ordens são correspondidas em Renegade

Em Renegade, o processo de correspondência de ordens combina ações do usuário, facilitação do relé e protocolos criptográficos de ponta para criar uma experiência de negociação suave e privada. Esta seção segue a jornada de uma única ordem - desde a sua criação pelo usuário até ao acerto final - explicando o papel dos relés, a mecânica do mecanismo de correspondência MPC e as garantias de segurança fornecidas pelos SNARKs colaborativos. Ao explorar estas etapas, descobriremos como o Renegade garante que as negociações permaneçam privadas, atômicas e totalmente verificáveis sem sacrificar a usabilidade ou a confiança.

Com isso, vamos começar examinando a primeira etapa: como um usuário cria uma ordem e como essa ação prepara o terreno para o resto do processo de correspondência.

Utilizador cria uma ordem

A jornada de correspondência de pedidos no Renegade começa quando o usuário interage com a interface para criar um pedido. Isso envolve especificar parâmetros-chave, como o par de negociação (por exemplo, WETH/USDC) e a quantidade que desejam negociar. Ao contrário dos sistemas tradicionais, o Renegade não suporta ordens limitadas - uma vez que o Renegade não é um livro de ordens limitadas centralizado (CLOB) e tem como objetivo evitar complexidade desnecessária - em vez disso, cada pedido é fixado no ponto médio, o que significa que a negociação é executada no ponto médio do spread predominante em grandes exchanges como Binance, Coinbase, OKX e Kraken. Assim que o preço é determinado usando dados de várias plataformas, os usuários confirmam os detalhes do pedido e o software da carteira atualiza perfeitamente o estado para refletir o novo pedido, ao mesmo tempo em que adere à arquitetura de preservação de privacidade do Renegade.

O estado atualizado da carteira leva em conta quaisquer saldos reservados necessários para cumprir a negociação, bem como taxas do relayer. Este novo estado é criptograficamente comprometido usando um esquema de compromisso de ocultação e ligação, garantindo que o conteúdo da carteira permaneça privado e incompreensível para observadores externos. Para manter a integridade do sistema, o estado anterior da carteira é anulado de forma segura, impedindo qualquer possibilidade de reutilização ou gasto duplo.

O software da carteira envia então o compromisso atualizado para a árvore de compromissos como parte do esquema de compromisso-revelação da Renegade, juntamente com uma prova de conhecimento zero (ZKP) que valida toda a transição. Esta prova garante que a atualização da carteira segue as regras do protocolo, incluindo saldos suficientes e transições de estado corretas, sem revelar quaisquer detalhes sensíveis sobre a ordem ou conteúdo da carteira. Uma vez verificada a transição, a carteira antiga é marcada como gasta e o novo compromisso é adicionado com segurança à Árvore de Compromissos.

Do ponto de vista do utilizador, todo este processo é contínuo. Uma vez que a ordem é colocada com sucesso, o estado atualizado da carteira, incluindo saldos restantes e ordens ativas, é exibido em tempo real. Importante, a intenção de negociação do utilizador e os detalhes da carteira permanecem completamente privados, preservando as garantias de privacidade pré-negociação da Renegade.

Com a ordem agora registrada no sistema, o relayer pode começar a processá-la em busca de possíveis correspondências, dando continuidade ao processo de negociação seguro e privado.

O relayer processa o pedido

Uma vez que o utilizador efetua uma encomenda, o intermediário torna-se uma parte essencial do processo, facilitando interações seguras e privadas entre a carteira do utilizador e o sistema Renegade mais amplo. Munido dos segredos delegados - o escalar de correspondência, a semente do cego e a semente compartilhada - o intermediário desencripta a carteira do utilizador para aceder aos detalhes da encomenda recém-criada. Esta delegação torna o intermediário um intermediário crítico, estabelecendo uma ponte perfeita entre a carteira privada do utilizador e o ecossistema de negociação mais amplo, garantindo que a encomenda seja correspondida de forma eficiente e em conformidade total com as garantias de privacidade e segurança do protocolo.

A primeira tarefa do relayer é descriptografar a carteira usando a semente do ofuscador e a semente compartilhada, que são dinamicamente hashadas para cada transação. Isso garante que esses valores sejam únicos para a operação específica, reforçando ainda mais a privacidade e segurança. Uma vez descriptografado, o relayer ganha acesso de visualização ao estado privado da carteira, incluindo a ordem recém-criada, os saldos e quaisquer outras ordens pendentes. No entanto, o relayer não pode modificar ou interferir no conteúdo da carteira, pois o par de chaves raiz continua sob controle exclusivo do usuário.

Após acessar o estado da carteira, o relayer constrói uma tupla de handshake para comunicar com segurança a ordem à rede Renegade. Esta tupla contém:

• Compromissos criptográficos para os detalhes do pedido (por exemplo, par de tokens, quantidade, preço).
• Um predicado de conhecimento zero, que prova criptograficamente que a ordem é válida de acordo com as regras do protocolo sem expor detalhes sensíveis, como os saldos da carteira ou as especificidades da ordem.
• Metadados adicionais necessários para verificações de compatibilidade, como taxas e preferências de liquidação.

Em seguida, a tupla de aperto de mão é transmitida para outros relayers dentro da rede peer-to-peer (P2P), sinalizando a disponibilidade da ordem enquanto garante a privacidade. À medida que o aperto de mão se propaga, outros relayers monitoram as tuplas recebidas para identificar ordens que possam corresponder às gerenciadas por suas carteiras. O relayer responsável pela ordem do usuário faz o mesmo, procurando continuamente contrapartes que atendam aos critérios especificados pelo usuário usando compromissos criptográficos e metadados de compatibilidade.

(Fonte: Documentação Renegade)

Quando uma correspondência em potencial é identificada, os relayers responsáveis pelas duas ordens iniciam uma comunicação direta para iniciar a próxima fase: correspondência segura de pedidos usando o MPC Matching Engine. Isso garante uma transição perfeita da criação do pedido para a correspondência segura, mantendo as garantias de privacidade do Renegade.

Correspondência das Ordens

O processo de correspondência de ordens na Renegade mostra uma aplicação inovadora de Computação de Múltiplas Partes (MPC), projetada especificamente para permitir negociação segura, privada e descentralizada. Ao contrário das implementações tradicionais de MPC, que geralmente envolvem vários participantes contribuindo com inputs para um cálculo coletivo, o MPC da Renegade foi projetado para uma configuração de duas partes. Nesse caso, dois relayers, cada um agindo em nome de seus respectivos usuários, colaboram para avaliar se seus pedidos podem ser correspondidos. Essa adaptação única do MPC garante que nenhum relayer aprenda detalhes sensíveis sobre o pedido do outro, como tipos de token, saldos ou preços, permitindo ainda a correspondência precisa e confiável de pedidos.

(Fonte: Documentação Renegade)

O motor de correspondência MPC começa processando entradas criptografadas de ambos os relayers. Essas entradas incluem detalhes críticos como os pares de tokens, quantidades, preços e estados de carteira associados às ordens. Ao longo desse processo, todas as informações permanecem criptografadas e são representadas como compartilhamentos secretos dentro do protocolo MPC. A computação verifica se as ordens estão alinhadas em parâmetros-chave, como compatibilidade de pares de tokens, suficiência de saldo e condições de preços. Se as ordens forem consideradas incompatíveis, o processo é encerrado sem vazar informações sobre a tentativa de correspondência, preservando a privacidade da negociação de ambas as partes.

Se o motor MPC determinar que as ordens são compatíveis, gera uma tupla de correspondência, uma representação criptográfica da correspondência. Esta tupla inclui detalhes essenciais como os tokens a serem trocados, os valores envolvidos e a direção da negociação para cada participante.

No entanto, de acordo com a abordagem de privacidade em primeiro lugar da Renegade, este conjunto não é imediatamente aberto. Em vez disso, permanece criptografado, garantindo que nenhum relayer possa acessar prematuramente seu conteúdo ou inferir detalhes sobre a ordem da contraparte. Ao adiar a exposição dessas informações e devido às robustas suposições criptográficas do MPC Matching Engine, a Renegade elimina o risco de dados sensíveis serem revelados durante o processo de correspondência, mesmo no caso de um relayer malicioso.

(Fonte: Documentação Renegade)

A principal exceção é o relayer que você escolhe antes de enviar seu pedido; como eles têm a sua chave de visualização delegada, um relayer desonesto poderia acessar todos os seus pedidos passados e futuros. No entanto, o fato de que essa é a única suposição de confiança dentro do Renegade e que você pode executar livremente seu próprio relayer torna essa preocupação praticamente insignificante.

Para validar a tupla de correspondência, os relayers constroem colaborativamente uma prova SNARK colaborativa, que confirma criptograficamente que a correspondência é válida de acordo com as regras do protocolo. Esta prova garante que:

• As ordens foram correspondidas corretamente com base nas suas entradas criptografadas.
• A tupla de correspondência reflete com precisão os estados da carteira e as ordens fornecidas durante o processo de MPC.
• Nenhum relayer manipulou a tupla de correspondência ou enviou dados inválidos para o mecanismo MPC.

As Provas Colaborativas de SNARK desempenham um papel crítico na garantia da integridade do processo de correspondência. Ao vincular as saídas criptografadas do mecanismo MPC aos compromissos armazenados na Árvore de Compromisso, elas fornecem um mecanismo de validação sem confiança que garante que a correspondência esteja em conformidade com as regras do protocolo da Renegade. Somente após a verificação da prova nos valores criptografados na tupla de correspondência - como as quantias a serem trocadas - eles se tornam acessíveis. Essa abordagem em fases protege a privacidade da negociação de ambas as partes durante todo o processo de correspondência e validação.

Uma vez verificada a Prova SNARK Colaborativa e aberta a tupla de correspondência criptografada, o sistema passa para a fase de liquidação. Neste ponto, as ordens correspondentes são totalmente validadas e prontas para liquidação, com todos os detalhes da negociação encapsulados e verificados com segurança. Essa integração perfeita do MPC e dos SNARKs Colaborativos garante que o processo de correspondência da Renegade seja não apenas privado e seguro, mas também confiável e à prova de violações, estabelecendo um novo padrão para negociações descentralizadas.

Finalização do comércio

Depois que o par de correspondência e a Prova SNARK Colaborativa forem validados, o processo passa para a fase de finalização, onde os resultados da negociação correspondida são registrados com segurança e preparados para a liquidação. Nesta fase, todas as validações criptográficas necessárias foram concluídas, garantindo a integridade da negociação ao mesmo tempo em que mantém a privacidade das duas partes envolvidas.

Para finalizar a correspondência, a carteira de cada negociante gera um registo da transação, resumindo quais tokens foram trocados, em que quantidades e em que direção. Estes registos funcionam como espaços reservados seguros para os resultados da correspondência e estão diretamente ligados aos compromissos criptográficos que representam os estados atualizados das carteiras. É importante notar que estes registos são gerados de forma privada para cada negociante e incluem salvaguardas criptográficas para evitar acesso ou manipulação não autorizados.

Após verificar os registros de negociação criptografados e as provas, o contrato inteligente da Renegade atualiza a árvore de compromisso e marca os pedidos como "encumbered" - impedindo novas ações até o ajuste. Esses registros criptografados persistem na árvore de compromisso para referência de ajuste. Essa fase demonstra a arquitetura de privacidade-segurança da Renegade: detalhes de negociação criptografados combinados com provas criptográficas permitem negociação privada e sem confiança, mantendo a verificabilidade em todo o processo de ajuste.

Desempenho e escalabilidade

Esta seção aborda dois desafios fundamentais que surgem das escolhas de design inovadoras da Renegade:

• Custos computacionais de MPC e SNARKs: Os compromissos na latência e nas demandas de recursos introduzidos por essas técnicas criptográficas avançadas.
• Escalabilidade da rede de corretoras: Como a infraestrutura peer-to-peer da Renegade gerencia altos volumes de negociação e se adapta às necessidades dos usuários variados.

Vamos explorar cada um deles em detalhe.

Custos computacionais de MPC e SNARKs

A arquitetura da Renegade depende fortemente do motor de correspondência MPC e de provas colaborativas de SNARK para oferecer privacidade e segurança incomparáveis. No entanto, essas técnicas criptográficas avançadas exigem demandas computacionais substanciais. O processo MPC requer que os relayers realizem cálculos criptografados em entradas compartilhadas em segredo, o que envolve múltiplas rodadas de comunicação e cálculo seguros para avaliar a compatibilidade das ordens. Isso introduz uma sobrecarga significativa em comparação com sistemas de correspondência tradicionais, especialmente ao processar negociações complexas ou de alto volume.

Da mesma forma, a geração de Provas SNARK colaborativas é uma tarefa intensiva em recursos. Embora os SNARKs sejam projetados para serem eficientes para verificação on-chain, sua criação envolve extensas operações criptográficas, especialmente ao provar declarações complexas como validade de pedidos e transições de estado de carteira. Esse custo computacional adiciona ao tempo e aos recursos necessários para concluir uma negociação, tornando-o menos adequado para cenários que exigem negociação de alta frequência ou instantânea.

Em resumo, essas duas operações representam uma das maiores cargas computacionais para os relayers encarregados de combinar as ordens dos usuários. Embora esse custo seja um compromisso necessário para atingir as fortes garantias de privacidade e segurança que definem Renegade, ainda é uma consideração importante para escalabilidade e experiência do usuário.

Escalabilidade da rede do relayer

O design do Renegade minimiza a confiança nos relayers, dependendo deles apenas para a vivacidade necessária para combinar negociações. Além disso, os relayers não têm autoridade custodial nem poder de tomada de decisão, pois todas as ações são validadas criptograficamente por meio de provas de conhecimento zero (ZKPs). Esse design sem confiança significa que o reforço computacional dos relayers - por exemplo, aumentando sua capacidade de processamento para lidar com mais negociações - não introduz riscos significativos. Ao mesmo tempo, a arquitetura de rede do Renegade é totalmente sem permissão, permitindo uma variedade diversificada de relayers, variando em tamanho e capacidade computacional, para coexistir no mesmo ecossistema sem causar problemas sistêmicos.

Essa flexibilidade é um dos pontos fortes do Renegade. Relayers menores podem operar de forma eficaz ao lado de outros maiores e mais poderosos, garantindo uma rede robusta e descentralizada. A confiança do protocolo em garantias criptográficas garante que todos os retransmissores, independentemente do tamanho ou escala, devem aderir às mesmas regras rigorosas de validação, preservando a justiça e integridade do sistema.

Os super retransmissores, por outro lado, oferecem um papel especializado dentro da rede, projetado para atender a usuários avançados e participantes institucionais. Ao contrário dos relés padrão, os super relayers operam com acesso delegado à chave raiz, concedendo-lhes controle total sobre a carteira de um usuário. Isso significa que eles não são confiáveis apenas para combinar negociações, mas para gerenciar todo o ciclo de vida da carteira, incluindo colocações de pedidos, cancelamentos e ajustes de saldo. Ao delegar a chave raiz, os usuários obtêm melhorias significativas na velocidade e no desempenho, já que o super relayer pode ignorar as etapas de verificação on-chain para determinadas operações.

No entanto, a delegação da chave raiz introduz um alto nível de confiança, tornando os super relayers adequados principalmente para entidades que operam sua própria infraestrutura de recamada para uso pessoal, como instituições ou comerciantes individuais sofisticados. Esses usuários podem aproveitar super relayers para otimizar seus sistemas de negociação, beneficiando-se da execução de ordens quase instantânea e custos reduzidos, mantendo a supervisão direta da infraestrutura.

(Fonte: Documentação Renegade)

A rede de relés da Renegade, com sua combinação de relés padrão e super relés, exemplifica um sistema escalável e adaptável. Ela alcança essa escalabilidade sem sacrificar a descentralização ou a segurança, garantindo que a rede possa lidar com diversos requisitos de usuários e volumes de negociação, mantendo seus princípios fundamentais de não confiança e permissão.

Conclusão

Neste artigo, introduzimos o conceito de dark pools, destacando o seu papel nas finanças tradicionais e a sua crescente importância nas finanças descentralizadas. Ao examinarmos a Renegade, demonstramos como inovações criptográficas como provas de conhecimento zero e computação multipartidária podem abordar questões críticas como frontrunning, quote fading e extração de MEV, abrindo caminho para uma negociação descentralizada segura e privada.

No futuro, a discussão sobre dark pools será ampliada para incluir outros protocolos importantes, como Tristero e Railgun. Ambos esses projetos oferecem abordagens únicas para aprimorar a privacidade e a qualidade de execução do comércio, cada um empregando metodologias diferentes para alcançar seus objetivos.

Em próximos artigos, iremos aprofundar-nos nos designs destes protocolos, explorando as suas vantagens, características distintas e como se comparam entre si e com Renegade. Esta exploração mais ampla irá lançar luz sobre as diversas soluções que moldam o futuro das finanças descentralizadas preservadoras da privacidade.

Aviso legal:

1. Este artigo é republicado a partir de [2077research]. Todos os direitos autorais pertencem ao autor original [Emmanuel AwosikaeKoray Akpinar]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são unicamente do autor e não constituem qualquer conselho de investimento.
3. A equipe de aprendizado da gate faz traduções do artigo para outros idiomas. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.