Los dark pools están emergiendo rápidamente como la próxima frontera del sector de finanzas descentralizadas (DeFi) de Ethereum. Los diseños de dark pools mitigan problemas como la incertidumbre de precios y la privacidad de las operaciones en los intercambios onchain, problemas que han hecho que los inversores externos se muestren cautelosos con DeFi, a pesar de los obvios beneficios como el acceso a liquidez las 24 horas del día, los 7 días de la semana y los novedosos mecanismos de generación de rendimiento.

En este artículo proporcionamos una visión general de las dark pools y exploramos su papel en las finanzas tradicionales y DeFi. Además, explicamos los mecanismos de las dark pools nativas de criptomonedas y discutimos posibles obstáculos para una adopción más amplia de las dark pools en la cadena.

Introducción: Dark pools en las finanzas tradicionales

A pesar de sonar ominosos e ilegales, los dark pools son en realidad un componente de larga data del sistema financiero tradicional (altamente regulado). A continuación se muestra una definición de un dark pool de Investopedia:

“Un dark pool es un foro o intercambio financiero organizado de forma privada para negociar valores. Los dark pools permiten a los inversores institucionales operar sin exposición hasta después de que se haya ejecutado y reportado la operación. Los dark pools son un tipo de sistema de negociación alternativo (ATS) que brinda a ciertos inversores la oportunidad de realizar grandes pedidos y operaciones sin revelar públicamente sus intenciones durante la búsqueda de un comprador o vendedor.”

Las piscinas oscuras son populares entre inversores institucionales, personas de alto patrimonio neto, fondos de cobertura, empresas de fondos mutuos y otras entidades que desean ejecutar operaciones a gran escala de forma anónima. El deseo de realizar operaciones de forma anónima se deriva de la sensibilidad de los precios de mercado a la demanda y oferta percibidas (aumentada aún más por las plataformas de negociación electrónica que permiten respuestas casi instantáneas incluso a señales débiles). Esto es especialmente cierto en los intercambios tradicionales donde el libro de órdenes es público y las personas pueden realizar o cancelar órdenes a voluntad.

El libro de órdenes en un intercambio de libro de órdenes central (CLOB) es público. fuente)

Supongamos que Alice coloca una orden de venta en el mercado para vender 500 acciones de Tesla en un intercambio. Esta es una orden pequeña que apenas tendrá algún impacto en el precio de las acciones de Tesla ofrecidas en el intercambio. Sin embargo, que Alice coloque una orden para vender 10 millones de acciones de acciones de Tesla es algo completamente diferente.

En este escenario, una gran orden de venta visible en el libro de órdenes señala una posible disminución en la demanda de acciones de Tesla. Las empresas de trading sofisticadas, especialmente aquellas que utilizan algoritmos de trading de alta frecuencia (HFT), probablemente captarán esta señal. Pueden actuar rápidamente vendiendo sus tenencias antes de que se ejecute la orden de Alice, anticipando una disminución en el precio de las acciones de Tesla. En consecuencia, el valor de mercado de las acciones de Tesla podría disminuir, lo que resultaría en un peor precio de ejecución para Alice. Si Alice no está utilizando técnicas de trading avanzadas, su operación podría terminar en pérdida debido a que la caída del precio ocurre antes de que se llene su orden.

El problema se complica aún más por la presencia de firmas HFTquienes emplean algoritmos propietarios capaces de responder en tiempo real a la actividad en un intercambio de libros de órdenes de límite central (CLOB). Aquí hay algunos escenarios hipotéticos:

Frontrunning

Imagina a Alice, una inversora, decide vender una gran cantidad de acciones de Tesla en una bolsa de valores tradicional. Si coloca su orden de venta en el mercado, los detalles de esta orden, incluyendo el tamaño y la intención, se vuelven visibles públicamente para otros participantes antes de que se finalice el intercambio. Una firma de trading sofisticada, equipada con algoritmos de trading de alta velocidad, podría notar esta gran orden y actuar rápidamente en base a esta información.

Por ejemplo, la empresa de trading podría decidir vender sus propias acciones de Tesla antes de que se ejecute la orden de Alice, anticipando que su gran orden de venta hará que el precio de las acciones caiga. Al hacerlo, la empresa asegura un precio más alto para sus acciones antes de que el mercado reaccione a la venta de Alice. Una vez que se ejecute la gran orden de Alice, la avalancha de acciones que llegan al mercado hace que el precio baje, y la empresa de trading puede comprar nuevamente las mismas acciones a un precio con descuento, obteniendo ganancias de la diferencia.

Esta práctica, llamada frontrunning, explota la visibilidad de la orden de Alice para obtener una ventaja financiera a expensas de ella. El resultado para Alice es un precio de ejecución peor para su operación porque el mercado reacciona negativamente antes de que se complete su orden. El frontrunning es un problema significativo en los sistemas financieros tradicionales donde los libros de órdenes son públicos, lo que permite a ciertos participantes actuar con información antes de que otros tengan la oportunidad.

Fading de la cotización

Continuemos con el ejemplo de Alice, pero esta vez centrándonos en el comportamiento de los creadores de mercado, entidades que proporcionan cotizaciones de compra y venta en un intercambio. Supongamos que la gran orden de venta de Alice se vuelve visible en el libro de órdenes público del intercambio. Un creador de mercado inicialmente tenía una oferta permanente para comprar acciones de Tesla a $200 cada una. Al ver la orden de venta considerable de Alice, el creador de mercado podría sospechar que el aumento de la oferta hará que el precio de las acciones de Tesla caiga.

Para evitar la compra de acciones a $200 solo para ver su valor disminuir, el creador de mercado cancela o modifica rápidamente su orden de compra. Esta acción, conocida como desvanecimiento de cotización, efectivamente elimina la liquidez del mercado. Cuando finalmente se ejecuta la orden de venta de Alice, quedan menos compradores y ella tiene que conformarse con un precio más bajo, quizás $195 en lugar de $200.

El desvanecimiento de cotizaciones perjudica injustamente a los traders como Alice al permitir que los proveedores de liquidez ajusten sus cotizaciones en función de un conocimiento similar al de los insiders de las operaciones de otros participantes. Debido a que el libro de órdenes es público en los exchanges centralizados de limit orderbook (CLOB), los creadores de mercado pueden ver las órdenes entrantes en tiempo real y reaccionar en consecuencia. Desafortunadamente, Alice no tiene forma de evitar que su operación se vea afectada por esta práctica, ya que surge de la transparencia del propio libro de órdenes.

¿Por qué dark pools?

Los dark pools aparecieron en las finanzas tradicionales como respuesta a los problemas mencionados anteriormente. A diferencia de un intercambio 'iluminado', los dark pools ejecutan operaciones fuera de los intercambios públicos como el NYSE (Bolsa de Valores de Nueva York) y Nasdaq. Las órdenes enviadas por compradores y vendedores se emparejan directamente y solo el operador central tiene información sobre el libro de órdenes.

Más importante aún, cada persona que opera a través de una piscina oscura solo es consciente de su propia(s) orden(es) y del precio de compensación. A menos que el operador central filtre información, es imposible saber nada sobre otros usuarios, como sus identidades y el tamaño/valor de las órdenes, incluso cuando se negocian activos con contrapartes.

Esto tiene varias implicaciones para las personas que desean operar con una exposición mínima a las fluctuaciones del mercado. Específicamente, los traders pueden realizar operaciones a gran escala sin revelar la intención de comprar o vender una acción en particular al público y reducir el impacto de una operación en el mercado de valores. Esto aumenta la certeza de que una operación significativa no sufrirá adelantamiento o desvanecimiento de cotizaciones y el vendedor (o comprador) obtendrá el mejor precio disponible.

Supongamos que Alice decide vender 10 mil millones de acciones de Tesla en una piscina oscura, estableciendo un precio de venta de $1 por acción. La piscina oscura identifica y empareja la orden de Alice con la orden correspondiente de Bob para comprar 10 mil millones de acciones de Tesla con la misma valoración. Cuando se ejecuta la operación, el público permanece sin conocer los detalles de la transacción hasta después del acuerdo. Solo entonces el mercado se entera de que 10 mil millones de acciones cambiaron de manos, pero sin conocer las identidades del comprador o vendedor, protegiendo así las intenciones y estrategias comerciales de ambas partes.

Podemos ver cómo operar a través de una piscina oscura protege los intereses de Alice y aumenta la calidad de ejecución y la certeza del precio de liquidación:

• Bob no sabe nada sobre Alice y solo sabe que recibió 10 mil millones de acciones de Tesla por 10 mil millones de dólares, y alguien recibió 10 mil millones de dólares por esas acciones. Bob no puede desvanecer la cotización porque el libro de órdenes está oculto. Bob debe planificar realmente comprar acciones para saber si alguien tiene 10 mil millones de acciones para vender (esta información se conoce una vez que se empareja la orden).
• Es difícil adelantarse al comercio de Alice ya que el operador central oscurece los detalles de las órdenes de compra y venta pendientes y la liquidez del mercado. La única forma en que el comercio de Alice se convierte en información pública es si el administrador de la piscina oscura comparte la información con partes externas.esto es ilegal, sin embargo).

Hoy, hay docenas de pools en funcionamiento y las estimaciones sugieren que El 40 por ciento de las operaciones electrónicas se realizan a través de dark pools. La creciente popularidad de las dark pools ha coincidido con regulación creciente, especialmente dado el acceso privilegiado de los operadores de piscinas a información sobre órdenes pendientes (Credit Suisse y Barclays fueron multados con un total de $150 millones en 2016 por filtrar información sobre operaciones en piscinas oscuras a partes externas).

Piscinas oscuras en DeFi

(origen)

Si los dark pools son necesarios en TradFi, probablemente sean aún más críticos en DeFi debido a la transparencia inherente de los sistemas blockchain y los desafíos que esto crea para mantener la privacidad del comercio y la calidad de ejecución. Esto es especialmente cierto para los intercambios descentralizados (DEXes) que facilitan operaciones electrónicas y proporcionan funcionalidades similares a los intercambios tradicionales.

• Los nodos de archivo pueden consultar la cadena de bloques para obtener información sobre transacciones históricas que interactúan con una piscina AMM y hacer referencias cruzadas con la actividad en cadena asociada a una dirección particular. Esto hace que sea trivial para cualquiera copiar estrategias comerciales empleadas por operadores alfa.
• El mempool, que almacena información sobre transacciones pendientes, es público y está disponible para cualquier persona conectada a un nodo completo. Esto hace que los usuarios de DEX sean susceptibles al problema de desvanecimiento de cotizaciones, donde las personas cancelan órdenes de compra/venta en respuesta a una gran transacción capaz de mover el mercado y conduce a una ejecución al peor precio para los traders.
• El estado posterior de un DEX puede ser calculado trivialmente por cualquier persona que observe el mempool, lo que abre la puerta a la extracción maliciosa de MEV (valor extraíble maximal) por parte de validadores y bots de MEV. Estos actores pueden observar el impacto de una operación en el pool de DEX y decidir adelantarse o intercalar la transacción si la simulación de cambios de estado revela posibles ganancias. (Que los usuarios envíen transacciones 'en claro' para su inclusión en un bloque agrava el problema).
• La operación de intercambio DEX podría no completarse si un productor de bloques censura deliberadamente la transacción de un usuario. Dado que la información de la cuenta está disponible públicamente, los validadores pueden crear perfiles para direcciones específicas y optar por discriminar contra esas contrapartes al procesar transacciones.
• Los validadores podrían ver información sobre una transacción y decidir excluirlo del próximo bloque. Los usuarios no pueden ocultar los detalles de la transacción a los validadores o evitar revelar su intención de comprar/vender tokens.

(Fuente)

Estos problemas han llevado a que los DEX tradicionales pierdan el favor de los grandes inversores y traders institucionales que son sensibles al precio y a la calidad de ejecución. DeFi es la mayor víctima, ya que los DEX no han podido suplantar a los intercambios TradFi a pesar de contar con varias ventajas como transacciones sin fronteras y ejecución transparente y sin confianza para los usuarios. Nuevas alternativas como gate.io están emergiendo en el espacio de intercambio de criptomonedas, proporcionando una mejor experiencia de usuario y una mayor capacidad de adaptación a las necesidades del mercado.Intercambio de vacas y UniswapXhan aparecido para resolver el problema, pero reintroducen la necesidad de confiar en un operador central, similar a cómo funcionan los dark pools tradicionales. Mientras que los dark pools en TradFi son privados en el sentido de que la información de la cuenta está oculta para otros, estos datos siguen siendo accesibles para el banco u operador, lo que los hace susceptibles al abuso o filtraciones si los administradores son menos capaces o poco escrupulosos.

Traer dark pools onchain no solo es posible, sino que representa un enfoque óptimo para construir plataformas de negociación descentralizadas que ofrecen una ejecución de calidad sin una excesiva dependencia de operadores centrales. Si bien la transparencia inherente de las blockchains, donde cualquiera puede verificar la precisión computacional a través de la ejecución de un nodo, puede parecer en desacuerdo con la funcionalidad de dark pool, este desafío puede superarse. La solución radica en la tecnología de mejora de la privacidad (PET), un enfoque criptográfico que permite el ocultamiento de información mientras se mantiene la integridad de las actualizaciones del libro mayor. Esto nos permite aprovechar la verificabilidad de la blockchain al tiempo que se introducen las características de privacidad esenciales para la operación de dark pool.

Construir piscinas oscuras descentralizadas puede parecer imposible, ya que las blockchains están diseñadas para ser transparentes y consultables. De hecho, esto es lo que hace que las blockchains sean mejores que las bases de datos regulares: cualquiera puede ejecutar un nodo y verificar que los cambios en la base de datos se calculen correctamente. Pero podemos sortear esta restricción aprovechando la criptografía, específicamente la tecnología de mejora de la privacidad (PET), que permite ocultar información mientras se asegura que las actualizaciones del libro mayor sean consistentes con las reglas.

¿Cómo funcionan las piscinas oscuras?

No hay una única forma de construir una piscina oscura en cadena. Sin embargo, todas las piscinas oscuras de criptomonedas comparten la característica común: utilizan varios mecanismos criptográficos para ocultar información sobre operaciones en cadena y aumentar la calidad de ejecución para los usuarios.

La computación multiparte (MPC), las pruebas de conocimiento cero, el cifrado de umbral, el cifrado completamente homomórfico (FHE) y los entornos de ejecución confiables (TEEs) son algunas de las primitivas disponibles para los diseñadores de mecanismos que trabajan en dark pools nativos de cripto. El objetivo en todos los casos es mantener garantías en torno a la privacidad del comercio sin aumentar las suposiciones de confianza o hacer que el sistema sea susceptible a la manipulación.

Renegado, Tristero, y Railgunson ejemplos de dark pools en cadena en el ecosistema de Ethereum. Repasaremos brevemente cada uno de estos protocolos para ofrecer una visión general de cómo funcionan en la práctica los dark pools en cadena. Este artículo se centrará en Renegade, explorando su diseño y el enfoque del protocolo para salvaguardar la información sobre las operaciones realizadas por los participantes del mercado.

Renegado: Acelerando DeFi privado con criptografía de vanguardia

Renegade es una piscina oscura descentralizada y preservadora de la privacidad diseñada para abordar fallas críticas en el panorama comercial de finanzas descentralizadas (DeFi) existente. Al aprovechar técnicas criptográficas avanzadas como las pruebas de conocimiento cero (ZKPs) y la computación multiparte (MPC), Renegade permite a los usuarios realizar, igualar y liquidar pedidos de forma segura sin revelar sus saldos, intenciones comerciales o estrategias a terceros. A diferencia de los DEX tradicionales, que exponen los datos del libro de pedidos al escrutinio público, Renegade cifra toda la información de la billetera y los pedidos, asegurando que las operaciones se realicen de manera privada y sean resistentes a la manipulación.

En su esencia, Renegade permite a los usuarios lograr operaciones sin confianza en la cadena con la misma precisión y calidad de ejecución que los exchanges centralizados, al mismo tiempo que mantiene las garantías de privacidad necesarias para protegerse contra el frontrunning, la desvanecimiento de cotización y otras prácticas explotadoras. Al introducir un único árbol merkle global para la gestión del estado, Renegade conserva los beneficios de la transparencia de blockchain, como la verificabilidad e inmutabilidad, al mismo tiempo que protege los detalles sensibles de las operaciones de la mirada pública.

Abordando los problemas de los sistemas DeFi actuales

El diseño de los intercambios descentralizados (DEXes) de hoy en día, ya sea basado en creadores de mercado automatizados (AMMs) o libros de órdenes límite centrales (CLOBs), introduce fallas críticas que afectan a todos los participantes, desde usuarios regulares hasta traders institucionales. Estos problemas surgen porque las transacciones y las órdenes se transmiten como texto plano en blockchains transparentes. Si bien la transparencia es fundamental para la verificación sin confianza, también expone a los traders a prácticas dañinas como frontrunning, quote fading y perfilado de direcciones.

Tanto para los pequeños comerciantes como para los grandes inversores, estas vulnerabilidades resultan en una mala ejecución de las operaciones, pérdidas financieras y una confianza reducida en las finanzas descentralizadas. Renegade elimina estos problemas al introducir técnicas criptográficas que preservan la privacidad sin comprometer la integridad de los sistemas descentralizados.

Valor Maximal Extraíble (MEV)

Ganancia total promedio de MEV (conjunto de datos de 30 días) según EigenPhi

Cuando las órdenes y transacciones son visibles en la mempool, se vuelven susceptibles a la manipulación por parte de los productores de bloques (en la Capa 1) o secuenciadores (en la Capa 2). Estos actores pueden reorganizar, adelantarse o retroceder transacciones con fines de lucro. Por ejemplo, observar una gran orden de compra o venta permite a actores malintencionados ejecutar sus transacciones con tarifas de gas más altas primero (adelantándose) o aprovechar oportunidades inmediatamente después de la ejecución (retrocediendo). Esta forma de MEV afecta a todos los diseños de DEX, independientemente de si utilizan una arquitectura AMM o CLOB.

Transparencia de comercio

La transparencia de los libros de pedidos basados en blockchain expone a los operadores a riesgos tanto previos como posteriores a la operación:

• Riesgos previos a la operación: En los sistemas de libro de órdenes abiertos, las órdenes públicamente visibles señalan la intención de los operadores, lo que permite a los adversarios ajustar sus estrategias en respuesta. Esto puede dar lugar a tácticas manipulativas como el desvanecimiento de cotizaciones, donde los proveedores de liquidez retiran sus órdenes para aprovechar las operaciones entrantes, lo que provoca deslizamiento y una calidad de ejecución degradada.
• Riesgos posteriores a la negociación: una vez que se ejecuta una operación, sus detalles, incluyendo estrategias y patrones de negociación, se registran permanentemente en la cadena. Los actores malintencionados o los competidores pueden analizar estos datos históricos para predecir y explotar futuras operaciones. Esta falta de privacidad después de la negociación deja a los traders, especialmente a las instituciones, vulnerables a la explotación.

Al combinar esto en una categoría más amplia, Renegade aborda todo el ciclo de vida de los problemas de transparencia comercial con soluciones criptográficas que garantizan la privacidad previa al comercio y la liquidación segura posterior al comercio.

Perfilado basado en dirección

En sistemas blockchain transparentes, cada transacción expone la dirección de la parte que la inicia. Los adversarios pueden analizar estos datos para crear perfiles detallados, vinculando el comportamiento comercial con billeteras específicas. Este perfilado permite prácticas discriminatorias, como ofrecer precios peores o dirigirse selectivamente a ciertos usuarios. Si bien las identidades blockchain son seudónimas, los análisis sofisticados pueden correlacionar direcciones con entidades del mundo real o patrones de comportamiento, lo que agrava aún más estas vulnerabilidades.

El diseño centrado en la privacidad de Renegade garantiza que las identidades de los usuarios y las estrategias se mantengan protegidas durante todo el proceso de negociación, salvaguardando tanto a los participantes minoristas como a los institucionales.

En el centro de estos problemas se encuentra la transparencia inevitable de las cadenas de bloques. Si bien la transparencia garantiza la verificación sin confianza y la inmutabilidad, cualidades críticas para los sistemas descentralizados, también expone detalles sensibles sobre la actividad del usuario. Cada operación, actualización de saldo o transacción pendiente se convierte en información pública que los actores adversarios pueden analizar, manipular o explotar con fines de lucro. Esto crea un sistema en el que los usuarios enfrentan desafíos como la extracción de MEV, la manipulación del comercio y el perfilado basado en direcciones, todo lo cual degrada la calidad de ejecución y socava la confianza en los mercados descentralizados.

Para resolver estos problemas, Renegade reemplaza la transparencia con privacidad controlada a través del uso combinado de pruebas de conocimiento cero (ZKPs) y computación multiparte (MPC). ZKPs garantizan que las operaciones son válidas, los saldos son suficientes y las reglas del protocolo se aplican sin revelar nunca el contenido de la billetera o los detalles de la transacción. Al mismo tiempo, MPC permite el emparejamiento seguro de órdenes, donde múltiples partes colaboran para encontrar coincidencias comerciales sin exponer ningún dato de entrada o filtrar información sensible.

Juntas, estas técnicas forman un sistema perfecto en el que las operaciones permanecen privadas, la ejecución es verificable y los detalles del pedido están ocultos en todo el ciclo de vida. Esto elimina las vulnerabilidades inherentes en las blockchains transparentes al tiempo que preserva la descentralización y la validación sin confianza.

Con una comprensión clara de los problemas que Renegade resuelve y su enfoque en la privacidad, vamos a profundizar en cómo funciona el sistema para ofrecer operaciones seguras, privadas y justas.

¿Cómo funciona Renegade bajo el capó?

Renegade reimagina el comercio descentralizado mediante la integración de técnicas criptográficas avanzadas que redefinen los límites de transparencia, privacidad y equidad en DeFi. Al abordar las limitaciones de los intercambios descentralizados convencionales, Renegade introduce un enfoque innovador que combina tecnologías de preservación de la privacidad con operaciones de trading sin confianza en la cadena.

Esta sección brinda una mirada más detallada a los componentes arquitectónicos únicos que alimentan Renegade. Exploraremos:

• Diseño de árbol de compromiso y billetera: Cómo las billeteras de usuario permanecen completamente fuera de la cadena y privadas, aseguradas por compromisos criptográficos y administradas a través de una sofisticada jerarquía de claves.
• Relayers y super relayers: El papel de los relayers en facilitar el emparejamiento y ejecución seguros del comercio, junto con su integración con los permisos de billetera delegados.
• motor de emparejamiento MPC: el innovador mecanismo de cálculo multi-party de dos partes de Renegade que garantiza el emparejamiento privado y sin confianza en el comercio.
• SNARKs colaborativos: cómo se logran liquidaciones atómicas a través de la integración perfecta de pruebas de conocimiento cero con computación multiparte.
• Rendimiento y escalabilidad: Una discusión sobre los compromisos involucrados en las decisiones de diseño de Renegade y cómo su arquitectura equilibra la privacidad, descentralización y eficiencia.

Al aprovechar estas innovaciones, Renegade no solo resuelve las fallas críticas de los modelos existentes de DEX, sino que también establece las bases para un entorno de trading descentralizado más seguro, privado y equitativo.

Las carteras de Renegade y el árbol de compromiso

Renegade presenta un modelo de gestión de estados que prioriza la privacidad y la verificabilidad. En su núcleo, el sistema emplea un árbol de compromiso, un árbol de Merkle global de solo agregado que almacena representaciones criptográficas (compromisos) de las billeteras de los usuarios. Este diseño asegura que el contenido de las billeteras permanezca completamente privado al mismo tiempo que mantiene las garantías sin confianza de los sistemas descentralizados.

A diferencia de los intercambios descentralizados tradicionales (DEX) donde los datos de la billetera son visibles en la cadena, Renegade mantiene toda la información de la billetera fuera de la cadena, lo que permite a los usuarios gestionar de forma segura sus saldos, órdenes e historial de transacciones sin exponer detalles sensibles. En la cadena, estas billeteras se representan únicamente ocultando y vinculando compromisos, hash criptográficos que oscurecen el contenido de la billetera al tiempo que garantizan que no se puedan manipular o reutilizar de manera incorrecta.

Una analogía: Carteras como mini-rollups

Para comprender mejor la arquitectura de Renegade, podemos establecer un paralelismo con los rollups de Ethereum. En un rollup, las transacciones se ejecutan fuera de la cadena, donde los cambios de estado ocurren de forma privada, y solo la raíz de estado, una representación criptográfica del estado acumulativo del rollup, se envía periódicamente a Ethereum. Junto a esta raíz de estado, se proporciona una prueba de conocimiento cero (ZKP) para validar que la transición de estado cumple con las reglas del protocolo de rollup sin revelar detalles de ninguna transacción.

Las carteras renegadas operan de manera sorprendentemente similar:

• Ejecución fuera de la cadena: Todas las operaciones de billetera, como la colocación de órdenes, las actualizaciones de saldo y la ejecución de operaciones, ocurren fuera de la cadena. Estas actualizaciones se reflejan en el estado privado de la billetera, inaccesible para observadores externos, incluido Ethereum.
• Compromiso en la cadena: Después de que se actualiza el estado de la billetera, su nuevo compromiso se agrega al árbol de compromisos. Este compromiso sirve como un resumen criptográfico de los nuevos saldos, órdenes y cualquier cambio realizado durante el proceso de actualización. La actualización va acompañada de una prueba de conocimiento nula, lo que garantiza que la transición del antiguo estado de la billetera al nuevo sea válida.

Esta similitud resalta cómo las carteras Renegade funcionan como mini-rollups. Procesan de forma independiente los cambios de estado fuera de la cadena mientras dependen del árbol de compromiso para sincronizar su estado con el sistema más amplio. Es importante señalar que este proceso está diseñado exclusivamente para mejorar la privacidad, en lugar de la escalabilidad, al mantener los datos de la cartera opacos e ilegibles para todos los observadores externos.

Esquema de compromiso-revelación para actualizaciones de billetera

Cada operación en una billetera en Renegade sigue un esquema de compromiso-revelación, asegurando la privacidad y la corrección durante todo el proceso de actualización. Este mecanismo permite a los usuarios modificar sus billeteras manteniendo la integridad del sistema.

1. Revelar la vieja billetera: El usuario presenta una prueba de Merkle que muestra que su compromiso de billetera anterior existe como una hoja en el árbol de compromiso. Es crucial destacar que este proceso de revelación no revela ningún detalle sobre el contenido de la billetera, preservando las garantías de privacidad previas al comercio de Renegade. El sistema solo aprende que el compromiso de la billetera es válido y está incluido en el árbol.
2. Calcular anuladores: Para evitar la reutilización de estados antiguos de billetera, Renegade requiere el cálculo de dos anuladores para cada billetera: un anulador de gasto de billetera y un anulador de coincidencia de billetera. Estos anuladores se derivan del compromiso de la billetera antigua y un valor aleatorio privado, asegurando la singularidad.

Los anuladores se envían junto con el nuevo compromiso de billetera para asegurar que la antigua billetera no pueda ser reutilizada.

1. Compromiso con la nueva billetera: el usuario genera un nuevo estado de billetera que refleja las actualizaciones deseadas, como la colocación de órdenes, ajustes de saldo o liquidaciones comerciales, y calcula su compromiso criptográfico. Se presenta una Prueba de Conocimiento Cero (ZKP) para demostrar lo siguiente:
   • El compromiso de la antigua billetera existe en el Árbol de Compromisos.
   • Los anuladores se calculan correctamente y son únicos.
   • La transición del estado de la antigua billetera al nuevo se adhiere a las reglas del protocolo (por ejemplo, no hay aumentos de saldo no autorizados).
   • El usuario posee las claves secretas necesarias para autorizar la actualización.

Una vez que se verifica la prueba y se confirma que los anuladores no se han utilizado, el contrato inteligente marca los anuladores de la antigua billetera como "gastados" e inserta el nuevo compromiso en el árbol de compromisos.

(Fuente: documentación de Renegade)

La arquitectura basada en compromisos de Renegade garantiza que los datos de trading sensibles se mantengan seguros en todo momento. La naturaleza de ocultación y vinculación de las compromisos de la billetera garantiza que ningún observador externo pueda inferir el contenido de la billetera, incluso con acceso al árbol de compromisos. Además, la aleatoriedad incluida en el cálculo de los compromisos de la billetera impide que los adversarios creen tablas arcoíris para identificar estados comunes de la billetera, como billeteras con saldos cero o órdenes.

Al combinar estos mecanismos criptográficos con pruebas de conocimiento cero, Renegade logra un diseño centrado en la privacidad donde las operaciones de la cartera son verificables pero invisibles para partes externas. Esto asegura que el protocolo mantenga la privacidad previa al intercambio, protegiendo a los usuarios de estrategias adversarias como el frontrunning y la manipulación de cotizaciones.

Jerarquía de claves y sistema de retransmisión

Renegade se basa en los relayers para facilitar operaciones críticas como la coincidencia de órdenes y el liquidación, lo que permite a los usuarios operar de manera eficiente sin comprometer la seguridad. Para lograr esto, el protocolo implementa una jerarquía de claves sólida, un marco criptográfico que separa los permisos de control y visualización, asegurando que los usuarios mantengan la custodia de sus activos mientras delegan tareas específicas a los relayers. Este sistema no solo protege la información sensible de la billetera, sino que también simplifica las interacciones con los relayers, lo que hace que el comercio privado y descentralizado sea más práctico y fácil de usar.

Cómo funciona la jerarquía de claves

Aunque el diseño actual de la jerarquía de claves de Renegade ha evolucionado más allá de su descripción inicial en el documento técnico, los principios básicos siguen siendo consistentes. Cuando se crea una billetera por primera vez y se compromete con el árbol de compromisos, incluye cinco secretos distintos que definen colectivamente su funcionalidad. Estos secretos son:

• Par de claves raíz: El par de claves raíz es un par de claves ECDSA (curva secp256k1), idéntico a una clave privada estándar de Ethereum. Es la clave más autorizada y otorga la custodia completa sobre la billetera. Todas las operaciones que modifican el estado de la billetera, como depósitos, retiros, colocación de órdenes o cancelaciones, requieren una firma de la clave secreta raíz. Para garantizar la máxima seguridad, la clave raíz se mantiene estrictamente en el lado del cliente y nunca se comparte con ninguna parte externa, incluidos los retransmisores.
• Coincidencia escalar: El escalar de coincidencia es un valor escalar secreto definido sobre la curva bn254 y sirve como mecanismo mediante el cual se autoriza a los relayers a enviar coincidencias para liquidación al contrato inteligente o capa base. A diferencia de los pares de claves asimétricas tradicionales, el escalar de coincidencia es un único valor secreto que los relayers utilizan para generar pruebas de conocimiento cero (ZKPs), demostrando su conocimiento de la preimagen del escalar bajo el hash de Poseidon. Esto garantiza que los relayers solo puedan liquidar coincidencias autorizadas explícitamente por la configuración de la billetera. Además, el escalar de coincidencia se combina con tarifas predefinidas en la billetera, lo que permite a los usuarios especificar los cargos exactos que los relayers pueden aplicar por sus servicios.
• Clave API simétrica: La clave API simétrica es una herramienta fuera del protocolo utilizada para autenticar interacciones entre el usuario y el relayer. Permite que los relayers transmitan actualizaciones en tiempo real, como cambios en la billetera o estados de pedidos, al usuario sin comprometer la seguridad de la billetera o su integridad criptográfica. Si bien no está directamente relacionada con las operaciones de la billetera, esta clave facilita la comunicación sin interrupciones y mejora la experiencia comercial en general.
• Semilla ciega y semilla compartida: La semilla ciega y la semilla compartida son componentes esenciales que permiten a los relayers descifrar y procesar la información de la billetera de forma segura. Estas semillas funcionan como claves de vista, otorgando a los relayers la capacidad de acceder al estado privado de la billetera. Sin embargo, como semillas, se convierten dinámicamente en valores que cambian con cada transacción. Esto asegura que los valores ciegos y compartidos son específicos para la operación actual, evitando cualquier reutilización o acceso no intencional.

La semilla del cegador es responsable de indexar la billetera en la cadena, creando una cadena de hash criptográfico que vincula los estados de la billetera. Esto asegura que la presencia de la billetera en el Árbol de Compromiso siga siendo demostrable sin exponer su contenido.

La semilla de participación se utiliza para construir “secret shares” de los datos de la billetera, lo que permite al relayer colaborar con el motor de coincidencia MPC durante el proceso de coincidencia de pedidos. Esta integración permite a los relayers realizar sus funciones de manera segura y sin revelar detalles sensibles sobre la billetera a la red en general.

¿Cómo funcionan los relayers en renegade

Los Relayers en Renegade actúan como intermediarios críticos que permiten al protocolo mantener su naturaleza de preservación de privacidad y descentralizada al mismo tiempo que ofrece una experiencia de trading fluida. Actuando como facilitadores y habilitadores, los Relayers están empoderados por la jerarquía de claves para realizar operaciones específicas en nombre del usuario sin comprometer la custodia o privacidad de la billetera. Aprovechando los secretos integrados en la billetera, los Relayers pueden descifrar la información de la billetera, identificar órdenes pendientes y enviar coincidencias al contrato inteligente para el ajuste, todo ello manteniendo garantías criptográficas estrictas.

La relación entre los relayers y la Jerarquía de Claves se basa en un modelo claro de delegación. Los usuarios comparten sólo los secretos necesarios, como el escalar de coincidencia, la semilla de enmascarador y la semilla de compartición, con el relayer. Estos secretos otorgan al relayer la capacidad de ver y procesar datos de la cartera de forma segura. El escalar de coincidencia permite a los relayers autorizar y liquidar coincidencias demostrando el conocimiento de su preimagen de hash de Poseidon a través de pruebas de conocimiento cero (ZKPs). La semilla de enmascarador y la semilla de compartición, por su parte, garantizan que los relayers puedan acceder a los datos de la cartera sin exponerlo a observadores externos o sin obtener un control no autorizado. Esta separación de poderes garantiza que los relayers tengan las herramientas para realizar sus tareas delegadas sin comprometer el control o la seguridad general del usuario.

Una de las principales ventajas de este sistema es que permite la delegación detallada. Los retransmisores están limitados a los roles explícitamente permitidos por los secretos compartidos. Por ejemplo, si bien los retransmisores pueden ver los detalles de la billetera y hacer coincidir órdenes pendientes, no pueden modificar, retirar o cancelar órdenes, ya que el par de claves raíz, la clave custodia definitiva, permanece con el usuario. Este diseño garantiza que los usuarios mantengan la plena propiedad de sus billeteras mientras externalizan tareas específicas para mejorar la eficiencia.

Los Relayers también brindan una gran comodidad al proceso de negociación al manejar la complejidad computacional de emparejar órdenes con el motor de emparejamiento MPC y garantizar la validez de estas coincidencias a través de SNARKs colaborativos. Este mecanismo permite a los Relayers descargar gran parte de la carga técnica de los usuarios al tiempo que mantienen las rigurosas garantías de privacidad previas y posteriores al comercio de Renegade. Al gestionar de forma segura estas operaciones, los Relayers no solo protegen los detalles sensibles de la billetera durante la coincidencia y liquidación de órdenes, sino que también alivian muchos de los desafíos de UX típicamente asociados con los sistemas de preservación de la privacidad. Su capacidad para proporcionar actualizaciones en tiempo real a través de la clave API simétrica mejora aún más la experiencia del usuario, asegurando que los usuarios se mantengan informados sobre sus operaciones y el estado de su billetera sin comprometer la seguridad.

En la práctica, este sistema crea un entorno de negociación altamente flexible y seguro. Los usuarios pueden delegar sus billeteras a intermediarios durante períodos prolongados, otorgándoles acceso persistente para emparejar órdenes sin tener que compartir repetidamente nuevas claves. Al mismo tiempo, los usuarios pueden revocar el acceso del intermediario en cualquier momento al crear una nueva billetera y transferir sus activos, lo que restablece efectivamente la delegación. Este mecanismo equilibra la comodidad a largo plazo con la adaptabilidad a corto plazo, atendiendo tanto a los traders ocasionales como a los participantes más conscientes de la seguridad.

Al integrar relayers en su arquitectura, Renegade logra una rara combinación de descentralización, privacidad y usabilidad. Los relayers actúan como intermediarios de confianza sin requerir confianza explícita, gracias a las salvaguardias criptográficas impuestas por la Jerarquía de Claves. Esto permite que Renegade escale sus operaciones manteniendo los niveles más altos de seguridad y autonomía del usuario.

En resumen, la arquitectura de árbol de compromiso y la jerarquía de claves de Renegade proporcionan un marco fundamental para equilibrar la privacidad y la verificabilidad en el comercio descentralizado. Al garantizar que las billeteras de los usuarios permanezcan completamente fuera de la cadena y se representen en la cadena solo como compromisos criptográficos, Renegade elimina la visibilidad de los datos comerciales sensibles.

Este diseño no solo evita el frontrunning, la desvanecimiento de cotizaciones y otros comportamientos explotadores, sino que también permite a los usuarios conservar la custodia total de sus fondos a través del par de claves raíz. El esquema de compromiso y revelación, junto con el uso de ZKPs, garantiza que las actualizaciones de billetera y las transiciones de estado sean seguras, a prueba de manipulaciones y completamente opacas para los observadores externos. Esto asegura un entorno de negociación donde la verificación sin confianza y la privacidad sólida coexisten sin problemas.

El sistema de intermediario, integrado con la Jerarquía de Claves, eleva aún más la experiencia del usuario y la eficiencia operativa de Renegade. Los intermediarios simplifican el proceso de negociación al gestionar las tareas computacionalmente intensivas de la coincidencia de pedidos y el acuerdo, aprovechando el motor de coincidencia MPC y la demostración SNARK para mantener la privacidad y garantizar la corrección. Al mismo tiempo, su capacidad para proporcionar actualizaciones en tiempo real a través de la clave API simétrica acorta la brecha entre garantías de privacidad sólidas y una experiencia de usuario fluida.

Al separar los permisos de visualización y coincidencia, la jerarquía de claves garantiza que los usuarios mantengan el control final sobre sus billeteras, mientras que los repetidores operan dentro de roles estrictamente definidos. Este sistema crea un equilibrio único en el que los usuarios se benefician de las propiedades de preservación de la privacidad de las técnicas criptográficas avanzadas sin encontrar las barreras de usabilidad típicamente asociadas con dichos sistemas.

Cómo se emparejan las órdenes en Renegade

En Renegade, el proceso de emparejar órdenes combina las acciones del usuario, la facilitación del relayer y los protocolos criptográficos de vanguardia para crear una experiencia de trading fluida y privada. Esta sección sigue el recorrido de una sola orden, desde su creación por parte del usuario hasta el acuerdo final, explicando el papel de los relayers, la mecánica del motor de emparejamiento MPC y las garantías de seguridad proporcionadas por los SNARKs colaborativos. Al explorar estas etapas, descubriremos cómo Renegade asegura que las operaciones sigan siendo privadas, atómicas y completamente verificables sin sacrificar la usabilidad o la falta de confianza.

Con eso, comencemos examinando el primer paso: cómo un usuario crea una orden y cómo esta acción establece el escenario para el resto del proceso de coincidencia.

El usuario crea una orden

El viaje de emparejamiento de órdenes en Renegade comienza con el usuario interactuando con la interfaz para crear una orden. Esto implica especificar parámetros clave como el par de negociación (por ejemplo, WETH/USDC) y la cantidad que desean negociar. A diferencia de los sistemas tradicionales, Renegade no admite órdenes limitadas, ya que Renegade no es un libro de órdenes limitadas centralizado (CLOB) y tiene como objetivo evitar la complejidad innecesaria. En su lugar, cada orden está anclada al punto medio, lo que significa que la operación se ejecuta en el punto medio del spread prevaleciente en importantes intercambios como Binance, Coinbase, OKX y Kraken. Una vez que el precio ha sido determinado utilizando datos de múltiples lugares, los usuarios confirman los detalles de su orden, y el software de la billetera actualiza sin problemas el estado para reflejar la nueva orden mientras se adhiere a la arquitectura de preservación de la privacidad de Renegade.

El estado de billetera actualizado tiene en cuenta cualquier saldo reservado necesario para cumplir el intercambio, así como las tarifas de relé. Este nuevo estado está comprometido criptográficamente mediante un esquema de compromiso de ocultación y vinculación, asegurando que el contenido de la billetera permanezca privado e incomprensible para observadores externos. Para mantener la integridad del sistema, el estado anterior de la billetera se anula de forma segura, evitando cualquier posibilidad de reutilización o doble gasto.

Luego, el software de la billetera envía el compromiso actualizado al árbol de compromiso como parte del esquema de compromiso-revelación de Renegade, junto con una prueba de conocimiento cero (ZKP) que valida toda la transición. Esta prueba asegura que la actualización de la billetera siga las reglas del protocolo, incluyendo saldos suficientes y transiciones de estado correctas, sin revelar detalles sensibles sobre el pedido o el contenido de la billetera. Una vez que se verifica la transición, la billetera antigua se marca como gastada y el nuevo compromiso se agrega de manera segura al Árbol de Compromiso.

Desde la perspectiva del usuario, todo este proceso es fluido. Una vez que la orden se realiza con éxito, el estado actualizado de la billetera, incluidos los saldos restantes y las órdenes activas, se muestra en tiempo real. Es importante destacar que la intención comercial del usuario y los detalles de la billetera permanecen completamente privados, preservando las garantías de privacidad previas a la negociación de Renegade.

Con el pedido ahora comprometido con el sistema, el relayer puede comenzar a procesarlo en busca de posibles coincidencias, dando el siguiente paso en el proceso de trading seguro y privado.

El relayer procesa la orden

Una vez que el usuario realiza un pedido, el relayer se convierte en una parte esencial del proceso, facilitando interacciones seguras y privadas entre la billetera del usuario y el sistema Renegade en general. Armado con los secretos delegados, el escalar de coincidencia, la semilla del cegador y la semilla compartida, el relayer desencripta la billetera del usuario para acceder a los detalles del pedido recién creado. Esta delegación convierte al relayer en el intermediario crítico, uniendo de manera transparente la billetera privada del usuario y el ecosistema comercial en general, asegurando que el pedido se empareje de manera eficiente y cumpla plenamente con las garantías de privacidad y seguridad del protocolo.

La primera tarea del relayer es descifrar la billetera usando la semilla cegadora y la semilla compartida, que se hash dinámicamente para cada transacción. Esto garantiza que estos valores sean únicos para la operación específica, reforzando aún más la privacidad y la seguridad. Una vez descifrada, el relayer obtiene acceso a la vista del estado privado de la billetera, incluida la orden recién creada, los saldos y cualquier otra orden pendiente. Sin embargo, el relayer no puede modificar ni interferir con el contenido de la billetera, ya que el par de claves raíz sigue estando únicamente bajo el control del usuario.

Después de acceder al estado de la billetera, el retransmisor construye una tupla de saludo para comunicar de forma segura la orden a la red Renegade. Esta tupla contiene:

• Compromisos criptográficos con los detalles de la orden (por ejemplo, par de tokens, cantidad, precio).
• Un predicado de conocimiento cero, que demuestra criptográficamente que el pedido es válido según las reglas del protocolo sin exponer detalles sensibles como los saldos de la billetera o los detalles del pedido.
• Se requiere metadatos adicionales para verificaciones de compatibilidad, como tarifas y preferencias de liquidación.

A continuación, la tupla de protocolo de enlace se transmite a otros repetidores dentro de la red peer-to-peer (P2P), lo que indica la disponibilidad del pedido al tiempo que garantiza que su privacidad permanezca intacta. A medida que el protocolo de enlace se propaga, otros repetidores monitorean las tuplas entrantes para identificar los pedidos que podrían coincidir con los administrados por sus billeteras. El repetidor responsable del pedido del usuario hace lo mismo, buscando continuamente contrapartes que cumplan con los criterios especificados por el usuario utilizando los compromisos criptográficos y los metadatos de compatibilidad.

(Fuente: Documentación de Renegade)

Cuando se identifica una posible coincidencia, los repetidores responsables de los dos pedidos comienzan la comunicación directa para iniciar la siguiente fase: la coincidencia segura de pedidos mediante el motor de coincidencia de MPC. Esto garantiza una transición fluida desde la creación de pedidos hasta la coincidencia segura, al tiempo que mantiene las principales garantías de privacidad de Renegade.

Coincidencia de órdenes

El proceso de emparejar órdenes en Renegade muestra una aplicación innovadora deComputación de múltiples partes (MPC), diseñado específicamente para permitir el comercio seguro, privado y descentralizado. A diferencia de las implementaciones tradicionales de MPC, que a menudo implican que múltiples participantes contribuyan con entradas para un cálculo colectivo, el MPC de Renegade está diseñado para una configuración de dos partes. En este caso, dos relayers, cada uno actuando en nombre de sus respectivos usuarios, colaboran para evaluar si sus órdenes pueden coincidir. Esta adaptación única de MPC garantiza que ningún relayer aprenda detalles confidenciales sobre la orden del otro, como tipos de tokens, saldos o precios, mientras permite una coincidencia precisa y sin confianza de órdenes.

(Fuente: documentación de Renegade)

El motor de coincidencia de MPC comienza procesando entradas encriptadas de ambos relayers. Estas entradas incluyen detalles críticos como los pares de tokens de las órdenes, cantidades, precios y estados de billetera asociados. A lo largo de este proceso, toda la información permanece encriptada y se representa como partes secretas dentro del protocolo MPC. La computación verifica si las órdenes se alinean en parámetros clave, como la compatibilidad de pares de tokens, suficiencia de saldo y condiciones de precios. Si se encuentra que las órdenes no son compatibles, el proceso se termina sin revelar ninguna información sobre la coincidencia intentada, preservando la privacidad de la negociación de ambas partes.

Si el motor MPC determina que las órdenes son compatibles, genera una tupla de coincidencia, una representación criptográfica de la coincidencia. Esta tupla incluye detalles esenciales como los tokens que se intercambiarán, las cantidades involucradas y la dirección del intercambio para cada participante.

Sin embargo, en línea con el enfoque de privacidad en primer lugar de Renegade, esta tupla no se abre de inmediato. En su lugar, permanece encriptada, asegurando que ninguno de los retransmisores pueda acceder prematuramente a su contenido o inferir detalles sobre la orden de la contraparte. Al posponer la exposición de esta información y debido a las sólidas suposiciones criptográficas del Motor de Coincidencia de MPC, Renegade elimina el riesgo de que se revele información sensible durante el proceso de coincidencia, incluso en el caso de un retransmisor malicioso.

(Fuente: documentación de Renegade)

La principal excepción es el relayer que elijas antes de enviar tu orden; ya que se les delega tu clave de vista, un relayer deshonesto podría acceder a todas tus órdenes pasadas y futuras. Sin embargo, el hecho de que esta sea la única suposición de confianza dentro de Renegade y que puedas ejecutar libremente tu propio relayer hace que esta preocupación sea en gran medida insignificante.

Para validar la tupla de coincidencia, los intermediarios construyen colaborativamente una prueba SNARK colaborativa, que confirma criptográficamente que la coincidencia es válida según las reglas del protocolo. Esta prueba garantiza que:

• Las órdenes se emparejaron correctamente en función de sus entradas encriptadas.
• La tupla de coincidencia refleja con precisión los estados de la billetera y las órdenes proporcionadas durante el proceso de MPC.
• Ningún relayer manipuló la tupla del partido o envió datos inválidos al motor MPC.

Las pruebas colaborativas de SNARK desempeñan un papel fundamental en garantizar la integridad del proceso de coincidencia. Al vincular las salidas cifradas del motor MPC a los compromisos almacenados en el árbol de compromisos, proporcionan un mecanismo de validación sin confianza que garantiza que la coincidencia cumpla con las reglas del protocolo de Renegade. Solo después de que la prueba se verifique que los valores cifrados en la tupla de coincidencia, como las cantidades a intercambiar, sean accesibles. Este enfoque escalonado protege la privacidad comercial de ambas partes durante todo el proceso de coincidencia y validación.

Una vez que se verifica la prueba colaborativa de SNARK y se abre la tupla de coincidencia cifrada, el sistema pasa a la fase de liquidación. En este punto, las órdenes coincidentes están completamente validadas y listas para su liquidación, con todos los detalles comerciales encapsulados y verificados de forma segura. Esta perfecta integración de MPC y SNARK colaborativos garantiza que el proceso de emparejamiento de Renegade no solo sea privado y seguro, sino también confiable y a prueba de manipulaciones, estableciendo un nuevo estándar para el comercio descentralizado.

Finalización de la operación de comercio

Después de que se hayan validado la tupla de coincidencia y la prueba colaborativa SNARK, el proceso pasa a la fase de finalización, donde los resultados del intercambio coincidente se registran de forma segura y se preparan para el acuerdo. En esta etapa, se han completado todas las validaciones criptográficas necesarias, lo que garantiza la integridad del intercambio al tiempo que se mantiene la privacidad de ambas partes involucradas.

Para finalizar el partido, la billetera de cada operador genera un registro del intercambio, resumiendo qué tokens se intercambiaron, en qué cantidades y en qué dirección. Estos registros sirven como marcadores seguros para los resultados del partido y están vinculados directamente a los compromisos criptográficos que representan los estados actualizados de la billetera. Es importante destacar que estos registros se generan de forma privada para cada operador e incluyen salvaguardias criptográficas para evitar el acceso no autorizado o la manipulación.

Después de verificar los registros de comercio encriptados y las pruebas, el contrato inteligente de Renegade actualiza el árbol de compromiso y marca las órdenes como 'gravadas', impidiendo acciones adicionales hasta el acuerdo. Estos registros encriptados persisten en el árbol de compromiso como referencia para el acuerdo. Esta fase demuestra la arquitectura de seguridad y privacidad de Renegade: los detalles de comercio encriptados combinados con pruebas criptográficas permiten un comercio privado y sin confianza mientras se mantiene la verificabilidad durante todo el proceso de liquidación.

Rendimiento y escalabilidad

Esta sección profundiza en dos desafíos fundamentales que surgen de las decisiones de diseño innovadoras de Renegade:

• Costos computacionales de MPC y SNARKs: Los compromisos en latencia y demandas de recursos introducidos por estas técnicas criptográficas avanzadas.
• Escalabilidad de la red del relayer: Cómo la infraestructura peer-to-peer de Renegade maneja volúmenes de negociación elevados y se adapta a las diferentes necesidades de los usuarios.

Vamos a explorar cada uno de estos en detalle.

Costos computacionales de MPC y SNARKs

La arquitectura de Renegade depende en gran medida del motor de emparejamiento de MPC y de las pruebas colaborativas de SNARK para ofrecer una privacidad y seguridad sin igual. Sin embargo, estas técnicas criptográficas avanzadas requieren un considerable poder de cálculo. El proceso de MPC requiere que los relayers realicen cálculos cifrados sobre entradas compartidas en secreto, lo cual implica múltiples rondas de comunicación y cálculo seguros para evaluar la compatibilidad de las órdenes. Esto introduce una sobrecarga significativa en comparación con los sistemas de emparejamiento tradicionales, especialmente al procesar operaciones complejas o de alto volumen.

Del mismo modo, generar Pruebas SNARK colaborativas es una tarea intensiva en recursos. Si bien los SNARK están diseñados para ser eficientes para su verificación en cadena, su creación implica operaciones criptográficas extensas, especialmente al demostrar declaraciones complejas como la validez del pedido y las transiciones del estado de la billetera. Este costo computacional se suma al tiempo y los recursos necesarios para completar una operación comercial, lo que lo hace menos adecuado para escenarios que requieren operaciones de alta frecuencia o comercio instantáneo.

En resumen, estas dos operaciones representan una de las mayores cargas computacionales para los relayers encargados de igualar las órdenes de usuario. Si bien este costo es un compromiso necesario para lograr las sólidas garantías de privacidad y seguridad que definen Renegade, sigue siendo una consideración clave para la escalabilidad y la experiencia del usuario.

Escalabilidad de la red de operadores

El diseño de Renegade minimiza la confianza en los relayers, confiando en ellos solo para la viabilidad necesaria para igualar operaciones. Más allá de esto, los relayers no tienen autoridad de custodia ni poder de toma de decisiones, ya que todas las acciones son validadas criptográficamente a través de pruebas de conocimiento cero (ZKPs). Este diseño sin confianza significa que fortalecer computacionalmente a los relayers, por ejemplo, aumentando su poder de procesamiento para manejar más operaciones, no introduce riesgos significativos. Al mismo tiempo, la arquitectura de red de Renegade es completamente permisiva, lo que permite que una amplia gama de relayers, de diferentes tamaños y capacidades computacionales, coexistan dentro del mismo ecosistema sin causar problemas sistémicos.

Esta flexibilidad es una de las fortalezas de Renegade. Los relayers más pequeños pueden operar de manera efectiva junto a los más grandes y poderosos, asegurando una red sólida y descentralizada. La dependencia del protocolo en garantías criptográficas asegura que todos los relayers, sin importar su tamaño o escala, deben adherirse a las mismas reglas estrictas de validación, preservando la equidad e integridad del sistema.

Por otro lado, los super relayers ofrecen un rol especializado dentro de la red, diseñado para satisfacer a usuarios avanzados y participantes institucionales. A diferencia de los relayers estándar, los super relayers operan con acceso delegado a la clave raíz, lo que les otorga control total sobre la billetera del usuario. Esto significa que no solo se les confía para emparejar operaciones, sino también para administrar todo el ciclo de vida de la billetera, incluyendo la realización, cancelación y ajuste de saldos de órdenes. Al delegar la clave raíz, los usuarios obtienen mejoras significativas en velocidad y rendimiento, ya que el super relayer puede omitir los pasos de verificación en la cadena para ciertas operaciones.

Sin embargo, la delegación de la clave raíz introduce un alto nivel de confianza, lo que hace que los superrelayers sean adecuados principalmente para entidades que operan su propia infraestructura de relayer para uso personal, como instituciones o traders individuales sofisticados. Estos usuarios pueden aprovechar los superrelayers para optimizar sus sistemas de negociación, beneficiándose de una ejecución de pedidos casi instantánea y costos reducidos, al mismo tiempo que mantienen una supervisión directa de la infraestructura.

(Fuente: Documentación Renegade)

La red de retransmisión de Renegade, con su combinación de relés estándar y superiores, ejemplifica un sistema escalable y adaptable. Logra esta escalabilidad sin sacrificar la descentralización o la seguridad, asegurando que la red pueda manejar diversos requisitos de los usuarios y volúmenes de negociación mientras mantiene sus principios fundamentales de falta de confianza y falta de permisos.

Conclusión

En este artículo, presentamos el concepto de dark pools, resaltando su papel en las finanzas tradicionales y su creciente importancia en las finanzas descentralizadas. Al examinar a Renegade, demostramos cómo las innovaciones criptográficas como las pruebas de conocimiento cero y los cálculos multiparte pueden abordar problemas críticos como el frontrunning, el quote fading y la extracción de MEV, abriendo el camino para un comercio descentralizado seguro y privado.

Avanzando, la discusión sobre dark pools se ampliará para incluir otros protocolos destacados como Tristero y Railgun. Ambos proyectos ofrecen enfoques únicos para mejorar la privacidad comercial y la calidad de ejecución, cada uno empleando metodologías diferentes para lograr sus objetivos.

En próximos artículos, profundizaremos en el diseño de estos protocolos, explorando sus ventajas, características distintivas y cómo se comparan entre sí y con Renegade. Esta exploración más amplia arrojará luz sobre las diversas soluciones que dan forma al futuro de las finanzas descentralizadas que preservan la privacidad.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [ 2077investigación]. Todos los derechos de autor pertenecen al autor original [Emmanuel Awosika y Koray Akpinar]. Si hay objeciones a esta reimpresión, por favor contacte al Aprendizaje de Gateequipo, y ellos lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen consejo de inversión.
3. El equipo de Aprendizaje de gate realiza traducciones del artículo a otros idiomas. A menos que se mencione, copiar, distribuir o plagiar los artículos traducidos está prohibido.