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

Neste artigo, fornecemos uma visão geral das dark pools e exploramos seu papel nas finanças tradicionais e no DeFi. Explicamos ainda mais os mecanismos das dark pools nativas de criptomoedas e discutimos possíveis obstáculos para uma adoção mais ampla das dark pools onchain.

Introdução: Dark pools no financiamento tradicional

Apesar de parecer sombrio e ilegal, os 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 financeiro ou uma bolsa organizada de forma privada para a negociação de valores mobiliários. Dark pools permitem que investidores institucionais negociem sem exposição até depois que a negociação tenha sido executada e reportada. 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 anonimamente. O desejo de realizar negociações anonimamente deriva da sensibilidade dos preços de mercado à demanda e oferta percebidas (ainda mais aumentada pelas plataformas de negociação eletrônicas que permitem respostas quase instantâneas mesmo a sinais fracos). Isso é especialmente verdadeiro em bolsas de valores tradicionais, onde o livro de ofertas é público e as pessoas podem fazer ou cancelar ordens a qualquer momento.

O livro de ofertas em uma bolsa de ordens limitadas central (CLOB) é público. (fonte)

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

Neste 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 captarã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 pode 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 de preço ocorre antes que sua ordem seja preenchida.

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

Frontrunning

Imagine que Alice, uma investidora, decide vender um grande número de ações da Tesla em uma bolsa de valores tradicional. Se ela colocar sua ordem de venda no mercado, os detalhes dessa ordem, incluindo o tamanho e a intenção, tornam-se publicamente visíveis para outros participantes antes que a negociação seja finalizada. Uma empresa de negociação sofisticada, equipada com algoritmos de negociação de alta velocidade, pode perceber essa grande ordem e agir rapidamente sobre essas informações.

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 ordem de venda irá reduzir 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 seja executada, a inundação de ações no mercado faz com que o preço caia, e a empresa de negociação pode então recomprar a mesma ação a uma taxa com desconto, lucrando com a diferença.

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

Cotação desvanecendo

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

Para evitar comprar as ações a $200 apenas para ver seu valor declinar, o formador de mercado cancela ou modifica rapidamente sua ordem de compra. Essa ação, conhecida como desvanecimento de cotação, remove efetivamente 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.

Desvanecer a cotação desfavorece injustamente traders 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 ofertas é público nas exchanges centralizadas de livro de ofertas limitadas (CLOB), os market makers podem ver as ordens entrantes em tempo real e reagir de acordo. Infelizmente, Alice não tem como impedir que sua negociação seja afetada por essa prática, já que ela decorre da transparência do livro de ofertas em si.

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', os dark pools executam negociações fora das bolsas públicas como a NYSE (Bolsa de Valores de Nova York) e a Nasdaq. As ordens submetidas pelos compradores e vendedores são combinadas diretamente e somente o operador central tem informações sobre o livro de pedidos.

Mais importante ainda, cada pessoa que negocia através de uma dark pool só tem conhecimento de sua própria ordem(s) 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 realizar negociações em grande 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á antecipação ou desvanecimento de cotação 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 um dark pool, definindo um preço de venda de $1 por ação. O dark pool identifica e corresponde 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 inconsciente dos detalhes da transação até depois do acerto. Somente então o mercado descobre que 10 bilhões de ações mudaram 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 a negociação através de um pool escuro 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 só 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 desaparecer com a cotação porque o livro de ordens está oculto - Bob deve planejar realmente comprar ações para saber que alguém tem 10 bilhões de ações para vender (essa informação é conhecida quando a ordem é correspondida).
• Furar a operação de Alice é difícil, já que o operador central obscurece os detalhes das ordens de compra e venda pendentes e a liquidez do mercado. A única maneira da operação de Alice se tornar pública é se o administrador da dark pool compartilhar as informações com partes externas.isso é ilegal, no entanto).

Atualmente, existem dezenas de pools em operação e estima-se que 40 por cento das negociações eletrônicas são realizadas por meio de dark pools. A crescente popularidade das dark pools tem coincidido com regulação em crescimento, especialmente considerando o acesso privilegiado dos operadores de pool às informações sobre ordens pendentes (o Credit Suisse e o Barclays foram multados em um total de $150m em 2016 por vazarem informações sobre negociações em dark pools para partes externas).

Dark pools em DeFi

(fonte)

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

• Os nós arquivados podem consultar o blockchain para obter informações sobre transações históricas que interagem com uma piscina AMM e cruzá-las com atividades on-chain associadas 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 do DEX suscetíveis ao problema de desaparecimento de cotação, onde as pessoas cancelam ordens de compra/venda em resposta a uma grande negociação capaz de movimentar o mercado e levar a uma execução com o pior preço para os traders.
• O estado posterior de um DEX pode ser calculado de forma trivial por qualquer pessoa que esteja observando o mempool, o que abre a porta para a extração maliciosa do MEV (valor extraível máximo) por validadores e bots do MEV. Esses atores podem observar o impacto de uma negociação no pool do DEX e decidir realizar uma negociação antecipada ou sandwich a transação se a simulação de mudanças de estado revelar lucros potenciais. (O fato de os usuários enviarem transações 'em claro' para inclusão em um bloco agrava o problema.)
• A negociação da DEX pode falhar se um produtor de bloco censurar deliberadamente a transação de um usuário. Como as informações da conta estão disponíveis publicamente, os validadores podem criar perfis para endereços específicos e optar por discriminar essas contrapartes ao processar transações.
• Validadores podem ver informações sobre uma transação e decidir excluí-la do próximo bloco. Os usuários não podem ocultar detalhes da transação dos validadores ou evitar divulgar a intenção de comprar/vender tokens.

(Origem)

Essas questões levaram as DEXes tradicionais a perderem a preferência de grandes baleias e traders institucionais sensíveis a preço e qualidade de execução. DeFi é a maior vítima, no entanto - com as DEXes incapazes de substituir as exchanges TradFi, apesar de possuírem várias qualidades, como transações sem fronteiras e execução transparente e sem confiança para os usuários. Novas alternativas como CowSwap e UniswapXapareceram para resolver o problema, mas reintroduzem a necessidade de confiar em um operador central, semelhante ao funcionamento tradicional das dark pools. Enquanto as dark pools no TradFi são privadas no sentido de que as informações da conta são ocultadas dos outros, esses dados continuam acessíveis ao banco ou operador, tornando-os suscetíveis a abusos ou vazamentos se os administradores não forem capazes ou pouco escrupulosos.

Trazer dark pools onchain não só é possível, mas representa uma abordagem ótima para a construção de plataformas de negociação descentralizadas que oferecem execução de qualidade sem depender excessivamente 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 das dark pools, esse desafio pode ser superado. A solução está na tecnologia de aprimoramento de privacidade (PET), uma abordagem criptográfica que permite a ocultação de informações ao mesmo tempo que 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 das dark pools.

Construir dark pools descentralizados pode parecer impossível, uma vez que as blockchains são projetadas para serem transparentes e consultáveis. Isso é, de fato, o que torna as blockchains melhores do que bancos de dados regulares: todos podem 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 de privacidade (PET) - que permite ocultar informações ao mesmo tempo em que garante que as atualizações do livro-razão sejam consistentes com as regras.

Como funcionam as dark pools?

Não há uma única maneira de construir uma dark pool onchain. No entanto, todas as dark pools cripto compartilham a característica comum: elas usam vários mecanismos criptográficos para ocultar informações sobre as negociações onchain e aumentar a qualidade da execução para os usuários.

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

Renegado, Tristero, e Railgun são exemplos de pools escuros onchain no ecossistema Ethereum. Vamos analisar brevemente cada um desses protocolos para fornecer uma visão geral de como os pools escuros onchain funcionam na prática. Este artigo se concentrará no Renegade, explorando seu design e a abordagem do protocolo para proteger informações sobre negociações conduzidas por participantes do mercado.

Renegade: Acelerando DeFi privado com criptografia de ponta

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

No seu âmago, a Renegade permite aos usuários realizar negociações onchain sem confiança, com a mesma precisão e qualidade de execução das bolsas centralizadas, mantendo, ao mesmo tempo, as garantias de privacidade necessárias para proteger contra a frente corrente, o desaparecimento de cotações e outras práticas exploratórias. Ao introduzir uma única árvore de merkle global para gestão de estado, a Renegade mantém os benefícios da transparência da blockchain, tais como verificabilidade e imutabilidade, enquanto protege os detalhes sensíveis das negociações do olhar 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 as 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, ela também expõe os traders a práticas prejudiciais como frontrunning, quote fading e perfil de endereço.

Tanto para pequenos traders quanto 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. Renegade elimina esses problemas ao introduzir técnicas criptográficas que mantêm a privacidade sem comprometer a integridade dos sistemas descentralizados.

Valor Extraível Máximo (MEV)

Lucro total médio de 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 na negociação

A transparência dos orderbooks baseados em blockchain expõe os traders a riscos tanto pré-trade quanto pós-trade:

• Riscos pré-transação: Em sistemas de livro de ordens abertos, as ordens publicamente visíveis sinalizam a intenção dos traders, permitindo que adversários ajustem suas 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 as negociações entrantes, causando deslizamento e degradação da qualidade da execução.
• Riscos pós-negociação: Uma vez que uma negociação é executada, seus detalhes, incluindo estratégias e padrões de negociação, são permanentemente registrados na cadeia. Atuantes maliciosos ou concorrentes podem analisar esses dados históricos para prever e explorar negociações futuras. Essa falta de privacidade pós-negociação deixa os negociadores, especialmente as instituições, vulneráveis à exploração.

Ao combinar esses em uma categoria mais ampla, o Renegade aborda todo o ciclo de vida dos problemas de transparência de negociação com soluções criptográficas que garantem a privacidade pré-negociação e a 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. Adversários podem analisar esses dados para criar perfis detalhados, vinculando o comportamento de negociação com carteiras específicas. Esse perfilamento permite práticas discriminatórias, como oferecer preços piores ou direcionar seletivamente determinados usuários. Embora as identidades blockchain sejam pseudônimas, análises sofisticadas podem correlacionar endereços com entidades do mundo real ou padrões comportamentais, exacerbando ainda mais essas vulnerabilidades.

O design centrado na privacidade do Renegade garante que as identidades e estratégias do usuário permaneçam protegidas durante todo o processo de negociação, protegendo os participantes de varejo e institucionais.

No cerne desses problemas está a transparência inevitável das blockchains. Embora a transparência garanta verificação sem confiança e imutabilidade - qualidades críticas para sistemas descentralizados - ela também expõe detalhes sensíveis sobre a atividade do usuário. Cada negociação, atualização de saldo ou transação pendente se torna uma informação pública que atores adversários podem analisar, manipular ou explorar para obter lucro. Isso cria um sistema em que os usuários enfrentam desafios como extração de MEV, manipulação de negociações e perfis baseados em endereços, todos os quais degradam a qualidade da execução e minam a confiança nos mercados descentralizados.

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

Juntos, essas técnicas formam um sistema perfeito em que as negociações permanecem privadas, a execução é verificável e os detalhes do pedido ficam ocultos ao longo do ciclo de vida. Isso elimina as vulnerabilidades inerentes às blockchains transparentes, ao mesmo tempo em que preserva a descentralização e a validação sem confiança.

Com uma compreensão clara dos problemas que a Renegade resolve e sua abordagem à privacidade, vamos mergulhar em como o sistema funciona para fornecer negociação segura, privada e justa.

Como o Renegade funciona por baixo dos panos?

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

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

• Árvore de compromisso e design de carteira: Como as carteiras dos usuários permanecem completamente off-chain e privadas, seguras por compromissos criptográficos e gerenciadas por uma hierarquia de chave sofisticada.
• Relayers e super relayers: O papel dos relayers na facilitação de correspondência comercial segura e execução, juntamente com sua integração com permissões de carteira delegadas.
• Motor de correspondência MPC: mecanismo revolucionário de computação multipartidária de duas partes do Renegade que garante correspondência comercial privada e sem confiança.
• SNARKs colaborativos: Como liquidações atômicas são alcançadas através da integração perfeita de provas de conhecimento zero com computação multi-party.
• Desempenho e escalabilidade: uma discussão sobre as compensações envolvidas nas escolhas de design da Renegade e como sua arquitetura equilibra privacidade, descentralização e eficiência.

Ao aproveitar essas inovações, o Renegade não só 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 do Renegade e a árvore de compromisso

Renegade introduz um modelo de gerenciamento de estado que prioriza a privacidade e verificabilidade. Em seu cerne, o sistema emprega uma Árvore de Compromisso, uma árvore de Merkle global apenas para acréscimos que armazena representações criptográficas (compromissos) das carteiras do usuário. Este design garante que o conteúdo da carteira permaneça 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 blockchain, a Renegade mantém todas as informações da carteira fora da blockchain, permitindo que os usuários gerenciem com segurança seus saldos, pedidos e histórico de transações sem expor detalhes sensíveis. Na blockchain, essas carteiras são representadas apenas ocultando e vinculando compromissos, hashes criptográficos que obscurecem o conteúdo da carteira, ao mesmo tempo em que garantem que não possam ser adulterados ou reutilizados indevidamente.

Uma analogia: Carteiras como mini-rollups

Para entender melhor a arquitetura do Renegade, podemos fazer uma comparação com os rollups do Ethereum. Em um rollup, as transações são executadas fora da cadeia, 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 enviada para o Ethereum. Junto com essa raiz de estado, uma prova de conhecimento zero (ZKP) é fornecida para validar que a transição de estado segue as regras do protocolo rollup sem revelar detalhes de transações.

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ções, ocorrem off-chain. Essas atualizações são refletidas no estado privado da carteira, inacessíveis a observadores externos, incluindo o Ethereum.
• Compromisso on-chain: Após a atualização do estado da carteira, o novo compromisso é adicionado à árvore de compromissos. Este compromisso serve como um resumo criptográfico dos novos saldos, ordens e quaisquer alterações feitas durante o processo de atualização da carteira. A atualização é acompanhada por um ZKP, garantindo que a transição do antigo estado da carteira para o novo seja válida.

Essa semelhança destaca como as Carteiras Renegade funcionam como mini-rollups. Elas processam independentemente as mudanças de estado fora da cadeia, ao mesmo tempo em que dependem da árvore de compromisso para sincronizar seu estado com o sistema mais amplo. Importante ressaltar que esse processo é exclusivamente projetado para melhorar a privacidade, e não a 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

Toda 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 aos usuários modificar suas carteiras mantendo a integridade do sistema.

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

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

1. Comprometer-se com a nova carteira: o usuário gera um novo estado da carteira refletindo as atualizações desejadas, como colocação de pedidos, ajustes de saldo ou liquidações comerciais, e calcula seu compromisso criptográfico. Um ZKP é apresentado para provar o seguinte:
   • O compromisso da carteira antiga existe na Árvore de Compromisso.
   • Os anuladores são calculados corretamente e únicos.
   • A transição do estado antigo da carteira para o novo segue as regras do protocolo (por exemplo, sem aumentos de saldo não autorizados).
   • O usuário 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 carteira antiga como 'gastos' e insere o novo compromisso na Árvore de Compromissos.

(Fonte: Documentação Renegade)

A arquitetura baseada em compromisso da Renegade garante que os dados sensíveis de negociação permaneçam seguros o tempo todo. A natureza de ocultação e vinculação dos compromissos 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 ordens.

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 partes externas. Isso garante que o protocolo mantenha a privacidade pré-negociação, protegendo os usuários de estratégias adversárias como frontrunning e manipulação de cotação.

Hierarquia de chave e sistema de relayer

Renegade depende de relayers para facilitar operações críticas como a correspondência de pedidos e liquidação, permitindo que os usuários negociem com eficiência sem comprometer a segurança. Para alcançar isso, o protocolo implementa uma hierarquia de chaves robusta, um quadro criptográfico que separa as permissões de controle e visualização, garantindo que os usuários mantenham a custódia de seus ativos enquanto delegam tarefas específicas aos relayers. Esse sistema não apenas protege informações sensíveis da carteira, mas também simplifica as interações com relayers, tornando a negociação privada e descentralizada mais prática e amigável ao usuário.

Como funciona a hierarquia de chaves

Embora o design atual da Hierarquia de Chaves do Renegade tenha evoluído além de sua descrição inicial no whitepaper, os princípios fundamentais permanecem consistentes. Quando uma carteira é criada pela primeira vez e comprometida com a Árvore de Compromissos, ela inclui cinco segredos distintos que definem coletivamente 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, saques, realização de pedidos ou cancelamentos — exigem uma assinatura da chave secreta raiz. Para garantir a máxima segurança, a chave raiz é mantida estritamente no lado do cliente e nunca é compartilhada com nenhuma parte externa, incluindo relayers.
• Escalar de correspondência: O escalar de correspondência é um valor escalar secreto definido sobre a curva bn254 e serve como 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, o escalar de correspondência é um único valor secreto que os relayers usam para gerar provas de conhecimento zero (ZKPs), comprovando seu conhecimento da 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, o escalar de correspondência é combinado com 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 os relayers transmitam atualizações em tempo real, como alterações na carteira ou status do pedido, para o usuário sem comprometer a segurança da carteira ou sua integridade criptográfica. Embora não esteja diretamente ligada às operações da carteira, essa chave facilita a comunicação contínua e melhora a experiência geral de negociação.
• Semente cega e semente compartilhada: A semente cega e semente compartilhada são componentes essenciais que permitem que os relayers descriptografem e processem informações de carteira com segurança. Essas sementes funcionam como chaves de visualização, concedendo aos relayers 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áfico que vincula os estados da carteira. Isso garante que a presença da carteira na Commitment Tree permaneça comprovável sem expor seu conteúdo.

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

Como funcionam os relayers no Renegade

Os Relayers no Renegade atuam como intermediários críticos que permitem que o protocolo mantenha sua natureza de preservação de privacidade e descentralização, oferecendo uma experiência de negociação perfeita. Agindo como facilitadores e capacitadores, os relayers são autorizados pela hierarquia de chaves a realizar operações específicas em nome do usuário sem comprometer a custódia ou a privacidade da carteira. Ao aproveitar os segredos incorporados na carteira, os relayers podem descriptografar as informações da carteira, identificar ordens pendentes e enviar correspondências para o contrato inteligente para liquidação, mantendo ao mesmo tempo garantias criptográficas estritas.

A relação entre os relayers e a Hierarquia de Chaves é 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, semente de ocultação e semente de compartilhamento - com o relayer. Esses segredos concedem ao relayer a capacidade de visualizar e processar dados da carteira de forma segura. O escalar de correspondência permite que os relayers autorizem e resolvam correspondências provando o conhecimento de sua pré-imagem de hash de Poseidon por meio de provas de conhecimento zero (ZKPs). Enquanto isso, a semente de ocultação e a semente de compartilhamento garantem que os relayers possam acessar 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 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, uma vez que o par de chaves raiz - a chave custodiante final - permanece com o usuário. Este design garante que os usuários mantenham a propriedade total de suas carteiras ao terceirizar tarefas específicas para eficiência.

Os Relayers também trazem uma conveniência significativa para o processo de negociação ao lidar com a complexidade computacional de corresponder pedidos com o mecanismo de correspondência MPC e garantir a validade dessas correspondências por meio de SNARKs colaborativos. Esse mecanismo permite que os Relayers descarreguem grande parte do fardo 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 com segurança essas operações, os Relayers não apenas protegem detalhes sensíveis da carteira durante a correspondência de pedidos e compensação, mas também aliviam muitos dos desafios de UX tipicamente 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 aprimora ainda mais a experiência do usuário, garantindo que os usuários permaneçam 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 usuários podem delegar suas carteiras para repassadores por períodos prolongados, concedendo-lhes acesso persistente para corresponder a pedidos sem ter que compartilhar novas chaves repetidamente. Ao mesmo tempo, os usuários podem revogar o acesso do repassador a qualquer momento criando uma nova carteira e transferindo seus ativos, resetando efetivamente a delegação. Esse mecanismo equilibra a conveniência de longo prazo com a adaptabilidade de curto prazo, atendendo tanto aos traders casuais quanto aos participantes mais conscientes da segurança.

Ao integrar relayers em sua arquitetura, Renegade alcança uma rara combinação de descentralização, privacidade e usabilidade. Os relayers atuam como intermediários confiáveis sem exigir confiança explícita, graças às salvaguardas criptográficas aplicadas pela Hierarquia de Chaves. Isso permite que a Renegade amplie suas operações enquanto mantém os mais altos níveis de segurança e autonomia do usuário.

Em resumo, a arquitetura de árvore de compromisso e hierarquia de chaves do Renegade fornecem uma estrutura fundamental para equilibrar privacidade e verificabilidade nas negociações descentralizadas. Ao garantir que as carteiras dos usuários permaneçam totalmente fora da cadeia e representadas na cadeia apenas como compromissos criptográficos, o Renegade elimina a visibilidade de dados sensíveis de negociação.

Este design não apenas evita a frente de fila, desvanecimento de cotações e outros comportamentos exploratórios, mas também permite que os usuários mantenham a custódia total de seus fundos por meio do par de chaves raiz. O esquema de compromisso-revelação, juntamente com o uso de ZKPs, garante que as atualizações da carteira e as transições de estado sejam 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 forte privacidade coexistem perfeitamente.

O sistema de relayers, integrado com a Hierarquia de Chaves, eleva ainda mais a experiência do usuário e a eficiência operacional do Renegade. Os relayers simplificam o processo de negociação ao gerenciar 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 de API simétrica preenche a lacuna entre garantias robustas de privacidade e uma experiência do 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 total sobre suas carteiras enquanto os relayers operam dentro de papéis estritamente definidos. Esse sistema cria um equilíbrio único onde 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

No Renegade, o processo de correspondência de pedidos combina as ações do usuário, a facilitação do relayer e os protocolos criptográficos de ponta para criar uma experiência de negociação contínua e privada. Esta seção segue a jornada de um único pedido - desde sua criação pelo usuário até o ajuste final - explicando o papel dos relayers, a mecânica do mecanismo de correspondência MPC e as garantias de segurança fornecidas pelos SNARKs colaborativos. Ao explorar essas 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 o primeiro passo: como um usuário cria um pedido e como essa ação prepara o terreno para o restante do processo de correspondência.

O usuário cria um pedido

A jornada de correspondência de pedidos no Renegade começa com o usuário interagindo 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 - já que o Renegade não é um livro de ordens central de limite (CLOB) e visa evitar complexidade desnecessária - em vez disso, cada ordem é ancorada no ponto médio, o que significa que a negociação é executada no ponto médio da diferença prevalecente em grandes exchanges como Binance, Coinbase, OKX e Kraken. Uma vez que o preço tenha sido determinado usando dados de várias fontes, 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 da carteira atualizado leva em consideração quaisquer saldos reservados necessários para cumprir a negociação, bem como as taxas de 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 da carteira anterior é nulificado de forma segura, impedindo qualquer possibilidade de reutilização ou gastos duplos.

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 detalhes sensíveis sobre o pedido ou conteúdos 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 usuário, todo esse processo é perfeito. Assim que o pedido for realizado com sucesso, o estado atualizado da carteira, incluindo saldos remanescentes e pedidos ativos, é exibido em tempo real. É importante ressaltar que a intenção de negociação do usuário e os detalhes da carteira permanecem completamente privados, preservando as garantias de privacidade pré-negociação da Renegade.

Com o pedido agora registrado no sistema, o relayer pode começar a processá-lo em busca de possíveis correspondências, dando o próximo passo no processo de negociação seguro e privado.

Relayer processa o pedido

Uma vez que o usuário faz um pedido, o relayer se torna uma parte essencial do processo, facilitando interações seguras e privadas entre a carteira do usuário e o sistema Renegade em geral. Armado com os segredos delegados - o match scalar, a semente do cego e a semente compartilhada - o relayer descriptografa a carteira do usuário para acessar os detalhes do pedido recém-criado. Essa delegação torna o relayer o intermediário crítico, conectando perfeitamente a carteira privada do usuário e o ecossistema de negociação em geral, garantindo que o pedido seja correspondido de forma eficiente e em total conformidade com as garantias de privacidade e segurança do protocolo.

A primeira tarefa do relayer é descriptografar a carteira usando a semente do cegamento e a semente compartilhada, que são dinamicamente hashadas para cada transação. Isso garante que esses valores sejam exclusivos 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, 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 permanece exclusivamente sob o controle 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 para a 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 detalhes da ordem.
• Metadados adicionais necessários para verificações de compatibilidade, como taxas e preferências de liquidação.

A tupla de handshake é então transmitida para outras camadas dentro da rede peer-to-peer (P2P), sinalizando a disponibilidade da ordem enquanto garante que sua privacidade permaneça intacta. À medida que o handshake se propaga, outros relayers monitoram as tuplas recebidas para identificar pedidos que podem potencialmente corresponder aos gerenciados por suas carteiras. A relayer responsável pelo pedido do usuário faz o mesmo, procurando continuamente contrapartes que atendam aos critérios especificados pelo usuário usando os compromissos criptográficos e metadados de compatibilidade.

(Fonte: Documentação Renegade)

Quando uma possível correspondência é identificada, os relayers responsáveis pelos dois pedidos iniciam comunicação direta para iniciar a próxima fase: correspondência segura de pedidos usando o Motor de Correspondência MPC. Isso garante uma transição perfeita da criação de pedidos para a correspondência segura, mantendo ao mesmo tempo as garantias de privacidade essenciais da Renegade.

Correspondência das Ordens

O processo de correspondência de pedidos na Renegade destaca uma aplicação inovadora de Computação de Múltiplas Partes (MPC), projetado especificamente para permitir negociações seguras, privadas e descentralizadas. Ao contrário das implementações tradicionais do MPC, que muitas vezes envolvem a contribuição de múltiplos participantes para um cálculo coletivo, o MPC do Renegade é projetado para uma configuração de duas partes. Nesse caso, dois relayers, atuando em nome de seus respectivos usuários, colaboram para avaliar se suas ordens podem ser correspondidas. Essa adaptação única do MPC garante que nenhum relayer obtenha detalhes sensíveis sobre a ordem do outro, como tipos de tokens, saldos ou preços, ao mesmo tempo em que permite a correspondência precisa e confiável das ordens.

(Fonte: Documentação Renegade)

O mecanismo de correspondência do 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 dos pedidos. Ao longo desse processo, todas as informações permanecem criptografadas e são representadas como compartilhamentos secretos dentro do protocolo MPC. O cálculo verifica se os pedidos se alinham em parâmetros-chave, como compatibilidade de pares de tokens, suficiência de saldo e condições de preços. Se os pedidos forem considerados incompatíveis, o processo termina sem divulgar nenhuma informação sobre a correspondência tentada, preservando a privacidade da negociação de ambas as partes.

Se o motor MPC determinar que os pedidos são compatíveis, ele 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 montantes 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 dos relayers 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 Motor de Correspondência do MPC, 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 acesso à sua chave de visualização, 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 colaborativamente constroem uma prova SNARK colaborativa, que confirma criptograficamente que a correspondência é válida de acordo com as regras do protocolo. Essa prova garante que:

• As ordens foram corretamente correspondidas com base em 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 motor MPC.

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 motor MPC aos compromissos armazenados na Árvore de Compromisso, eles fornecem um mecanismo de validação sem confiança que garante que a correspondência adere às regras do protocolo da Renegade. Somente após a verificação da prova para os valores criptografados na tupla de correspondência, como os montantes a serem trocados, tornam-se acessíveis. Esta abordagem faseada protege a privacidade da negociação de ambas as partes ao longo do processo de correspondência e validação.

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

Finalização da negociação

Após a validação do par de correspondência e da prova colaborativa SNARK, o processo passa para a fase de finalização, onde os resultados do comércio correspondido são registrados de forma segura e preparados para liquidação. Nesta fase, todas as validações criptográficas necessárias foram concluídas, garantindo a integridade do comércio enquanto mantém a privacidade das duas partes envolvidas.

Para finalizar a partida, a carteira de cada trader gera um registro do comércio, resumindo quais tokens foram trocados, em quais quantidades e em qual direção. Esses registros servem como marcadores seguros para os resultados da partida e estão diretamente ligados aos compromissos criptográficos que representam os estados atualizados das carteiras. Importante destacar que esses registros são gerados de forma privada para cada trader e incluem salvaguardas criptográficas para evitar acesso ou manipulação não autorizados.

Depois de verificar os registros e provas de negociação criptografados, o contrato inteligente do Renegade atualiza a árvore de compromissos e marca os pedidos como "onerados", impedindo novas ações até a liquidação. Esses registros criptografados persistem na árvore de compromisso para referência de liquidação. Esta fase demonstra a arquitetura de segurança de privacidade do Renegade: detalhes de negociação criptografados combinados com provas criptográficas permitem negociações privadas e sem confiança, mantendo a verificabilidade durante todo o processo de liquidação.

Desempenho e escalabilidade

Esta seção mergulha em dois desafios fundamentais que surgem das escolhas de design inovadoras do Renegade:

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

Vamos explorar cada um deles em detalhes.

Custos computacionais de MPC e SNARKs

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

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

Em resumo, essas duas operações representam uma das maiores cargas computacionais para relayers encarregados de corresponder ordens de usuário. Embora esse custo seja uma compensação necessária para alcançar as fortes garantias de privacidade e segurança que definem o Renegade, ele continua sendo uma consideração fundamental para a escalabilidade e a experiência do usuário.

Escalabilidade da rede de relé

O design do Renegade minimiza a confiança nos intermediários, confiando neles apenas para a vivacidade necessária para combinar negociações. Além disso, os intermediários não possuem autoridade custodial ou 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 fortalecimento computacional dos intermediários - 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 diversa de intermediários, variando em tamanho e capacidade computacional, coexistir no mesmo ecossistema sem causar problemas sistêmicos.

Essa flexibilidade é uma das forças do Renegade. Relayers menores podem operar de forma eficaz ao lado de relayers maiores e mais poderosos, garantindo uma rede robusta e descentralizada. A dependência do protocolo em garantias criptográficas garante que todos os relayers, independentemente do tamanho ou escala, devem aderir às mesmas regras estritas de validação, preservando a justiça e integridade do sistema.

Por outro lado, os super relayers oferecem um papel especializado dentro da rede, projetado para atender a usuários avançados e participantes institucionais. Ao contrário dos relayers padrão, os super relayers operam com acesso de chave raiz delegada, concedendo-lhes controle total sobre a carteira de um usuário. Isso significa que eles não são apenas confiáveis para correspondência de negociações, mas também 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 em velocidade e desempenho, já que os super relayers podem contornar etapas de verificação on-chain para operações específicas.

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 relayer para uso pessoal, como instituições ou traders individuais sofisticados. Esses usuários podem aproveitar os super relayers para otimizar seus sistemas de negociação, se beneficiando de execução de pedidos quase instantânea e redução de custos, mantendo a supervisão direta da infraestrutura.

(Fonte: Documentação Renegade)

A rede relayer do Renegade, com sua mistura de standard e super relayers, exemplifica um sistema escalável e adaptável. Ele 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 falta de confiança e permissão.

Conclusão

Neste artigo, introduzimos o conceito de dark pools, destacando seu papel nas finanças tradicionais e sua crescente importância nas finanças descentralizadas. Ao examinar o Renegade, demonstramos como inovações criptográficas como provas de conhecimento zero e computação multipartidária podem lidar com questões críticas, como frontrunning, fading de cotações e extração de MEV, abrindo caminho para negociações descentralizadas seguras e privadas.

Seguindo em frente, a discussão sobre dark pools se expandirá 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.

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

Aviso Legal:

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