*Reenviar el título original:Informe de investigación de Eureka Partners: Singularity - Transacciones de privacidad en una cadena de bloques transparente

Introducción

En 1969, el método de negociación en los mercados financieros todavía se basaba en los parqués tradicionales. En ese momento, la tecnología informática aún no estaba madura y los operadores se basaban en gritar órdenes en voz alta, un método que era ineficiente y carecía de privacidad, lo que dificultaba que los inversores institucionales realizaran grandes transacciones sin causar fluctuaciones en el mercado. Instinet, fundada por Jérôme Pustilnik, surgió como respuesta a este desafío. Instinet permitía a los inversores colocar órdenes de forma anónima a través de una plataforma de negociación electrónica, que se encargaba de hacer coincidir las órdenes de compradores y vendedores y de ejecutar las operaciones. Este modelo no solo mejoró la eficiencia comercial, sino que también garantizó la confidencialidad de las transacciones, evitando eficazmente el impacto en el mercado y la fuga de información.

Hoy en día, los avances tecnológicos han llevado al nacimiento de la tecnología blockchain, una innovación revolucionaria que ha aportado una transparencia y seguridad sin precedentes a las transacciones financieras. Sin embargo, la naturaleza pública y la inmutabilidad de la cadena de bloques, si bien aportan muchos beneficios al mercado, también presentan nuevos desafíos para los comerciantes de grandes transacciones. En el libro mayor público de la cadena de bloques, cada transacción es visible para todos los participantes, lo que dificulta que los comerciantes de grandes transacciones permanezcan en el anonimato. Las plataformas de intercambio tradicionales no pueden proteger completamente la privacidad de los operadores, y la divulgación pública de grandes órdenes puede provocar fluctuaciones de precios, lo que afecta la eficiencia y los costos de negociación. Además, la incertidumbre regulatoria y la opacidad del mercado también plantean riesgos adicionales para los inversores.

Este informe explorará los dark pools en la cadena de bloques como una solución innovadora que introduce tecnologías avanzadas de protección de la privacidad y mecanismos de negociación automatizados para proporcionar un entorno más seguro y eficiente para las grandes transacciones de criptomonedas. También se hablará de cómo Singularity, a través de sus soluciones innovadoras que utilizan tecnologías como FHE (Fully Homomorphic Encryption) y ZKP (Zero-Knowledge Proof), ofrece a los grandes inversores una plataforma de negociación descentralizada privada y compatible.

¿Qué es Dark Pools?

Los dark pools en los mercados financieros tradicionales se refieren a plataformas de negociación privadas que no divulgan públicamente información comercial, lo que permite a los inversores realizar grandes transacciones sin exponer sus intenciones comerciales. La aparición de la negociación de dark pool en los Estados Unidos está estrechamente relacionada con la creciente demanda de transferencias de capital a gran escala debido a la creciente frecuencia de fusiones y adquisiciones en el mercado de valores. Con el desarrollo de los mercados financieros, la importancia de los dark pools en diversos campos, como las acciones, los bonos y las divisas, se ha vuelto cada vez más prominente, especialmente en la era en la que dominan las operaciones algorítmicas y de alta frecuencia. Las estadísticas muestran que las transacciones de dark pool representan entre el 30% y el 50% del mercado de valores, convirtiéndose en un componente importante de la liquidez del mercado.

En el mercado de las criptomonedas, a medida que crece el grupo de grandes inversores, la demanda de transacciones de gran volumen sigue aumentando. Estas grandes órdenes tienen un impacto significativo en el mercado, a veces incluso desencadenando turbulencias en el mercado. Para evitar estos riesgos, muchos traders recurren al mercado OTC o incluso a los grupos de Telegram para realizar transacciones. Según datos del exchange Kraken en 2020, el volumen global de operaciones OTC se ha multiplicado por 20 desde 2018, con un volumen medio diario de transacciones de aproximadamente 300 mil millones de dólares, lo que representa casi el 70% del volumen total de operaciones del mercado de criptomonedas. Sin embargo, el mercado OTC también se enfrenta a problemas de liquidez insuficiente y falta de regulación. Para hacer frente a estos desafíos, se han introducido los dark pools como solución, con el objetivo de proporcionar un entorno comercial más estable y privado.

Los puntos clave sobre las piscinas oscuras incluyen:

• Privacidad y confidencialidad: Los dark pools permiten a los operadores realizar transacciones de forma anónima, protegiendo su identidad y el tamaño de la orden en el mercado público hasta que se ejecute la transacción.

• Reducción del impacto en el mercado: Los dark pools permiten a los grandes inversores institucionales ejecutar grandes órdenes sin causar fluctuaciones significativas de precios en el mercado público, lo que minimiza el impacto y el deslizamiento del mercado.

• No divulgación de las estrategias de trading: Las transacciones de dark pool ayudan a proteger las estrategias de los traders para que no sean conocidas por el mercado público, evitando que sean explotadas por MEV (Miner Extractable Value), el arbitraje de copy trading y el arbitraje estadístico.

• Liquidez y mejora de precios: Los dark pools proporcionan liquidez adicional al mercado al poner en contacto a compradores y vendedores que pueden no encontrar contrapartes en los exchanges tradicionales, lo que puede ofrecer mejoras de precios, especialmente para operaciones de gran volumen.

• Supervisión regulatoria: Los dark pools están regulados, y los organismos reguladores supervisan las actividades de los dark pools para evitar el acceso injusto, el uso de información privilegiada o la manipulación del mercado. Sin embargo, para muchos dark pools, el estilo de gestión centralizada sigue planteando riesgos de seguridad, fiabilidad y posible uso indebido de los datos privados. Históricamente, ha habido varios casos en los que los dark pools centralizados fueron penalizados por violar los principios de confianza.

Tecnologías de privacidad principales

Las piscinas oscuras son una rama de la vía de la privacidad. A través de las siguientes tecnologías de mejora de la privacidad (PET), como las pruebas de conocimiento cero (ZKP), la computación multipartita (MPC) y el cifrado totalmente homomórfico (FHE), los dark pools inyectan privacidad en su infraestructura.

Prueba de conocimiento cero (ZKP)

La tecnología Zero-Knowledge Proof (ZKP) permite a un probador demostrar la exactitud de una declaración a un verificador sin revelar ninguna información sustancial. Esta tecnología es particularmente crucial en las soluciones de escalado de capa 2 de Ethereum, como ZK Rollup, que logra la verificación de la validez de las transacciones comprimiendo los datos de las transacciones en pruebas compactas de ZK y enviándolas a la red principal. Estas pruebas no solo ocupan un espacio de almacenamiento mínimo, sino que también protegen la privacidad de la información de las transacciones, incorporando las ventajas naturales de un mecanismo sin confianza. La aplicación de la tecnología ZKP no se limita al escalado, sino que también incluye la computación de privacidad, siendo sus principales implementaciones zkSNARKs, zkSTARKs y Bulletproofs. Estas tecnologías promueven colectivamente la mejora de la protección de la privacidad de las criptomonedas y la eficiencia de las transacciones.

Introducción a las pruebas de conocimiento cero

Cómputo multipartito (MPC)

La computación multipartita (MPC) es una tecnología que permite a varias partes calcular una función juntas sin revelar sus entradas individuales. En el ámbito de la privacidad, MPC proporciona un método para proteger los datos confidenciales, lo que permite a las partes realizar análisis de datos, tareas de cálculo o tomar decisiones sin exponer los datos personales. La principal ventaja de MPC radica en su capacidad de protección de la privacidad. A través de la computación distribuida y las tecnologías de cifrado, los participantes pueden asegurarse de que sus datos permanezcan privados durante todo el proceso de cómputo.

Introducción a la computación multipartita segura

▪ Cifrado totalmente homomórfico (FHE)

El cifrado totalmente homomórfico (FHE) es una tecnología criptográfica que permite el cálculo directo de datos cifrados sin necesidad de descifrarlos primero. Esto significa que se pueden realizar operaciones como la suma, la resta y la multiplicación en los datos mientras permanecen cifrados, y los resultados del cálculo, una vez descifrados, son coherentes con los obtenidos al realizar las mismas operaciones en los datos originales. El valor fundamental de FHE radica en proporcionar una poderosa herramienta para la protección de la privacidad, lo que permite que los datos permanezcan confidenciales durante el procesamiento, mejorando así significativamente la seguridad de los datos.

Equilibrio entre la lucha contra la censura y el cumplimiento

Los exchanges descentralizados (DEX) que operan en blockchains públicas, como Uniswap y Curve, son susceptibles al Valor Máximo Extraíble (MEV) debido a la naturaleza pública y transparente de sus libros de contabilidad. Esta transparencia significa que los detalles de los pedidos son visibles para todos, lo que permite a los buscadores y constructores optimizar sus ganancias mediante la reorganización de los pedidos de transacciones, lo que puede afectar negativamente a otros usuarios hasta cierto punto.

Los dark pools, como una forma de centro de negociación financiera, tienen sus principales ventajas en la protección de la privacidad y la lucha contra la censura. En los dark pools, los detalles de las órdenes generalmente se mantienen en secreto para terceros, ya que cada orden genera pruebas de conocimiento cero (ZKP), lo que reduce la divulgación pública de la información de la transacción. Esta arquitectura es particularmente atractiva para los grandes tenedores e inversores institucionales, ya que protege sus estrategias comerciales de ser explotadas por competidores o manipuladores del mercado. Además, las características de los dark pools también ayudan a resistir el MEV, ya que el orden y los detalles de las transacciones no son públicos, lo que reduce la posibilidad de reordenamiento.

Sin embargo, estas ventajas pueden disminuir cuando las transacciones necesitan llamar a contratos públicos o utilizar secuenciadores compartidos, ya que estas operaciones podrían exponer la información de la transacción, lo que brinda oportunidades para la captura de MEV. Sin embargo, para los grandes tenedores e inversores institucionales que buscan privacidad y protección contra la censura, especialmente cuando sus actividades comerciales requieren una alta confidencialidad, los dark pools siguen siendo una opción atractiva.

La aparición de herramientas de protección de la privacidad como Tornado Cash ofrece la posibilidad de realizar actividades financieras anónimas en la cadena, pero estas herramientas también han sido utilizadas por los delincuentes para actividades ilegales como el blanqueo de capitales. La dirección del contrato inteligente de Tornado Cash fue incluida en la lista de la Oficina de Control de Activos Extranjeros (OFAC) debido al incumplimiento. La OFAC mantiene una lista de Nacionales Especialmente Designados (SDN, por sus siglas en inglés) para sancionar a las personas y entidades que no cumplen. Los protocolos que no se ajustan a las regulaciones de la OFAC tienen una alta probabilidad de que sus transacciones sean excluidas de los bloques on-chain. A partir del 23 de febrero de 2024, el 45% de los bloques requieren una revisión de la lista de la OFAC. Este problema anticensura afecta no solo a los productores de bloques, sino también a los validadores y repetidores, que pueden ignorar selectivamente ciertas transacciones o bloques.

Proporción de bloques revisados por las listas de la OFAC

Con la prohibición de Tornado Cash por incumplimiento, ha surgido un vacío en el mercado para las soluciones de privacidad que cumplen con los requisitos. Para llenar este vacío, los proyectos posteriores de dark pool deben brindar protección de la privacidad y evitar riesgos regulatorios similares. Un método eficaz es integrar procesos KYB/KYC verificados en el proyecto, garantizando la legalidad de las actividades de los usuarios y ayudando a evitar posibles riesgos regulatorios. Las regulaciones legales a menudo van a la zaga de los avances tecnológicos, lo que hace que los proyectos de privacidad sean fácilmente explotables para actividades ilegales. Adoptar y cumplir activamente con las regulaciones es crucial para garantizar la seguridad y legalidad del proyecto.

Panorama de la competencia y análisis de proyectos

Entre 2010 y 2022, el número de proyectos de dark pool fue limitado y estos proyectos no obtuvieron un reconocimiento generalizado entre el público en general. Sin embargo, con el avance de las tecnologías que mejoran la privacidad, como las pruebas de conocimiento cero (ZKP) y la computación multipartita (MPC), el dominio del dark pool dio la bienvenida a una serie de soluciones tecnológicas innovadoras. El desarrollo de estas tecnologías hizo que las piscinas oscuras volvieran a estar en el ojo público en 2023. Sin embargo, debido a la complejidad de la tecnología, el número de proyectos en la carrera de la piscina oscura sigue siendo relativamente pequeño. Aquí hay algunos proyectos que se han vuelto relativamente maduros.

1. Renegade, establecido en 2022, es un dark pool descentralizado basado en la arquitectura MPC-ZKP, diseñado para proporcionar servicios de grandes transacciones a inversores institucionales. Renegade realiza la coincidencia de pedidos a través de una red peer-to-peer y la tecnología Multi-Party Computation (MPC) y utiliza ZK-SNARK para garantizar que los detalles de la transacción permanezcan anónimos para personas ajenas durante el proceso de verificación de coincidencia de pedidos. Además, emplea un mecanismo de ejecución de punto medio para garantizar que todas las transacciones se liquiden directamente al precio de punto medio agregado en tiempo real de los exchanges centralizados para evitar el deslizamiento. Su función de comercio cruzado anónimo predeterminado, combinada con indicadores de interés, promueve el descubrimiento integral de precios y optimiza la liquidez.

2. Penumbra es una plataforma de trading descentralizada construida dentro del ecosistema Cosmos, que ofrece un entorno de trading similar a un dark pool que permite a los usuarios operar manteniendo la privacidad. A través de un mecanismo de delegación privada, Penumbra combina la protección de la privacidad y el mecanismo de consenso Proof-of-Stake (PoS), ofreciendo derivados de staking, staking fiscalmente eficiente y gobernanza on-chain con voto privado. Penumbra se conecta al ecosistema de Cosmos a través de la comunicación entre cadenas de bloques (IBC), que sirve como un dark pool en todo el ecosistema que permite transacciones privadas en cualquier activo compatible con IBC. Los usuarios también pueden utilizar ZSwap, un exchange privado descentralizado que admite subastas por lotes de ofertas selladas y liquidez concentrada similar a Uniswap-V3, para intercambiar estos activos.

3. Panther es una plataforma DeFi de cadena cruzada que incorpora tecnología de conocimiento cero, destinada a proporcionar una solución que cumpla con la normativa y proteja la privacidad del usuario. Los usuarios pueden depositar activos digitales en los Pools Blindados de Activos Múltiples (MASP) de Panther y recibir zAssets en una proporción de 1:1. A través del módulo Zswap, Panther se conecta a otros protocolos DeFi, agregando cotizaciones para la selección del usuario. Durante las transacciones, Zswap crea un contrato de depósito en garantía encriptado, lo que permite a los usuarios intercambiar activos sin revelar los detalles de la transacción. Este diseño permite que los activos coexistan en diversos grupos, manteniendo la heterogeneidad de los datos, lo que dificulta el seguimiento y la desanonimización de los usuarios. Los grupos blindados de Panther aprovechan la tecnología ZK SNARK y ZKP para garantizar la privacidad y el cumplimiento de las transacciones.

4. Railgun es un sistema de privacidad con una arquitectura ZKP-MPC diseñada para Ethereum, BSC, Polygon y Arbitrum, que utiliza tecnología de encriptación de conocimiento cero (ZK) y aprovecha la tecnología MPC para la ceremonia de configuración de confianza. Permite a los usuarios ejecutar contratos inteligentes y operaciones DeFi de forma segura mientras mantienen la privacidad de las transacciones. Cuando los usuarios emiten órdenes de transacción a través de Railgun, un contrato inteligente de Adapt Module procesa automáticamente el desblindaje de privacidad del saldo privado, valida la orden y luego los relés encuentran el mejor tipo de cambio en liquidez DEX agregada, finalmente volviendo a proteger los activos de la transacción para garantizar el anonimato de la actividad y las direcciones del usuario. Este proceso no solo es aplicable a los intercambios de activos, sino que también puede extenderse a otros tipos de transacciones DeFi.

Interpretación técnica de la singularidad:

Cómo implementar transacciones privadas

Entendiendo el Concepto de Transacciones Privadas

Para comprender el concepto de transacciones privadas, es esencial considerar tanto a las partes involucradas en la transacción como los detalles de la transacción, diferenciando entre dos tipos de privacidad: el anonimato y la ocultación.

Una transacción estándar incluye los siguientes elementos:

• Partes de la transacción: Esto incluye al remitente (Trader A) y al destinatario (Trader B) de la transacción.

• Detalles de la transacción: Esto abarca el monto de la transacción, el número de subtransacciones, el hash de la transacción y otros detalles específicos.

Las transacciones privadas se pueden clasificar en dos tipos según el nivel de visibilidad de la información para terceros:

• Transacciones anónimas: En las transacciones anónimas, las direcciones del remitente y del destinatario son desconocidas para terceros. Esto significa que durante el proceso de transacción, a excepción de las dos partes involucradas en la transacción, nadie más puede identificar a los participantes específicos. Por ejemplo, Tornado Cash es un protocolo de privacidad que logra el anonimato al ofuscar las rutas de transacción.

• Transacciones ocultas: En las transacciones ocultas, aunque las direcciones del remitente y del destinatario son visibles, no se conocen los detalles específicos de la transacción. Esto significa que el monto de la transacción, el número de subtransacciones, el hash de la transacción y otra información detallada se ocultan a terceros. Este tipo de privacidad se puede lograr utilizando tecnologías como Zero-Knowledge Proofs (ZKP). Por ejemplo, Zcash es una criptomoneda de privacidad que utiliza la tecnología zk-SNARKs para ocultar los detalles de las transacciones.

Interpretación general de la arquitectura de Singularity

Visión general de la arquitectura de Singularity

En cuanto a la estructura general, se puede dividir en aproximadamente 5 módulos:

1. Singularidad

Este es el contrato inteligente con el que los usuarios interactúan principalmente, utilizado para expresar y ejecutar la lógica del circuito ZK. Las funcionalidades de estos contratos inteligentes incluyen ocultar el saldo y los registros de transacciones de los tokens ETH/ERC20 para lograr el anonimato y la ocultación del contenido de las transacciones. Sirve como un fondo de liquidez que agrega todos los activos de todo tipo de comerciantes. Su nombre se debe a su característica única, es decir, para todos los observadores, todas las transacciones del protocolo parecen originarse en este contrato inteligente. Este diseño proporciona a los usuarios privacidad multidimensional.

En el protocolo Singularity, las notas ZK forman la unidad básica de las transacciones, que contiene información crítica de la transacción, incluido el tipo de activo, la cantidad y un identificador cifrado relacionado con el propietario. El diseño de estas Notas tiene como objetivo proporcionar un alto nivel de protección de la privacidad, asegurando que las identidades de los operadores y la información de los activos estén salvaguardadas de manera efectiva.

Cada nota incluye la siguiente información clave:

• Tipo de activo: Indica el tipo de activo involucrado en la transacción, como el tipo de token de una criptomoneda u otros activos digitales.

• Importe: Indica la cantidad de activos contenidos en el pagaré, que se utiliza para determinar el valor de la transacción.

• Rho: Un valor de campo generado aleatoriamente que se utiliza para mejorar la privacidad de las transacciones, evitando que los observadores externos rastreen y analicen la transacción.

• Clave pública Schnorr: Se utiliza para la firma criptográfica y la verificación de la identidad de las transacciones, lo que garantiza que solo los usuarios autorizados puedan realizar operaciones de transacción válidas.

Además de la información anterior, cada nota también genera un anulador correspondiente. La generación de Anuladores emplea técnicas de hash criptográfico, tomando el valor aleatorio y la clave pública de la Nota como entradas y procesándolas para producir el Anulador correspondiente. Este diseño tiene como objetivo proporcionar seguridad adicional para las transacciones, asegurando que solo los usuarios legítimos autorizados puedan operar y consumir el Pagaré de manera efectiva.

Adición y almacenamiento de notas

En el protocolo Singularity, todas las notas se adjuntan a un árbol de Merkle de solo anexión y la raíz del nuevo árbol de Merkle se almacena permanentemente. El propósito de este diseño es garantizar la integridad y seguridad de las transacciones, evitando que los datos sean manipulados y corrompidos.

Para ilustrarlo con un ejemplo sencillo:

Supongamos que Alice es una usuaria del protocolo Singularity. En algún momento, realiza una transacción, depositando 1 ETH en el contrato de Singularity. Esta transacción se registrará como una nota y se adjuntará al árbol de Merkle actual. En este momento, la raíz del árbol de Merkle se calcula a partir de esta única nota.

Posteriormente, Bob también realiza una transacción, depositando 0,5 ETH en el contrato de Singularity. Esta transacción también se registrará como una nota y se anexará al árbol de Merkle actual. La raíz del árbol de Merkle se actualiza a medida que se agregan nuevas notas.

Nota: En el caso de que se genere un número impar de notas para la raíz del árbol de Merkel, las dos notas individuales se duplicarán y se calcularán sus hashes.

A medida que más usuarios realizan transacciones, cada nueva nota se agrega al árbol de Merkel en orden cronológico. Por lo tanto, el historial de transacciones de cada usuario se conserva dentro de la misma estructura de datos, y la integridad de todo el historial de transacciones se puede verificar de manera eficiente calculando el hash raíz del árbol de Merkel. Dado que el árbol de Merkel es solo de anexar, es imposible modificar o eliminar cualquier nota que se haya agregado al árbol, lo que garantiza la seguridad e inmutabilidad de los datos de la transacción.

Verificación de transacciones de notas

Cuando los operadores realizan transacciones, deben revelar el Anulador correspondiente y proporcionar evidencia relacionada en la prueba de conocimiento cero para verificar que el Anulador está asociado con la Nota correspondiente y demostrar la existencia de la Nota en el árbol de Merkel. Los contratos inteligentes verificarán la singularidad del Anulador y la validez de las pruebas para garantizar la legalidad y seguridad de la transacción.

Por ejemplo:

Supongamos que Alice tiene una nota que contiene 1 ETH que depositó en el contrato de Singularity, y el anulador de esa nota es "AAA123". Ahora, Alice quiere usar estos fondos para una transacción, por lo que debe proporcionar "AAA123" como el Anulador y probar los siguientes dos puntos a través de una prueba de conocimiento cero:

1. Demostrar que "AAA123" está asociado con el pagaré gastado, es decir, que los fondos para esta transacción provienen efectivamente de ese pagaré.

2. Demostrar la existencia de la Nota en el árbol de Merkel, es decir, que la Nota fue depositada previamente en el contrato de Singularity y no ha sido manipulada.

El contrato inteligente verificará el Anulador y las pruebas proporcionadas por Alice para garantizar la unicidad del Anulador y la validez de las pruebas. Solo cuando se pasa la verificación, el contrato ejecutará la transacción y transferirá los fondos al destinatario deseado por Alice. Por lo tanto, el contrato inteligente garantiza la legalidad y seguridad de la transacción, evitando cualquier actividad maliciosa o fraudulenta.

A continuación se muestra la implementación de pseudocódigo de la lógica anterior:

Pseudocódigo
solidez del pragma ^0.8.0;
contract SingularityContract {
   mapping(address => mapping(bytes32 => bool)) private invalidValues;
   mapping(bytes32 => bool) merkleTree privado;
   Operación de depósito, depositando fondos en el contrato de Singularity
   function deposit(bytes32 noteHash, bytes32 invalidValue) público pagadero {
       require(msg.value > 0, "Deposit amount must be greater than 0");
       // Add the Note to the Merkel tree
       merkleTree[noteHash] = true
       // Store the nullifier
       invalidValues[msg.sender][noteHash] = true;
   }
   Operación de gasto de la transacción, verificación del anulador y la evidencia, ejecución de la transacción
   función spend(bytes32 noteHash, bytes32 invalidValue, bytes de prueba de memoria) {
       // Verify that the provided nullifier matches the stored one
       require(invalidValues[msg.sender][noteHash], "Invalid value does not match");
       // Verify the existence of the Note in the Merkel tree
       require(merkleTree[noteHash], "Note does not exist in the Merkle tree");
       // Verify the zero-knowledge proof
       require(_verifyProof(noteHash, invalidValue, proof), "Proof verification failed");
       // Execute the transaction, transferring funds to the recipient
       // The specific transfer operation is omitted here
   }
   público 
   Función de verificación de prueba de conocimiento cero
   function _verifyProof(bytes32 noteHash, bytes32 invalidValue, bytes memory proof) private view devuelve (bool) {
       // In practice, specific zero-knowledge proof verification is required
       // The specific verification process is omitted here
       // If the proof is successfully verified, return true, otherwise return false
       return true;
   }
}

1. Libro

Book emplea la tecnología de cifrado totalmente homomórfico (FHE) para crear un libro de órdenes fuera de línea completamente privado, lo que proporciona a los operadores un entorno comercial seguro y confiable. Dentro del sistema Book, un grupo especial de nodos FHE, conocidos como Bookies, desempeñan un papel fundamental, gestionando colectivamente el libro de órdenes. El proceso de emparejamiento incluye:

Los nodos de la API cifran los pedidos para garantizar la confidencialidad del contenido del pedido. A continuación, las casas de apuestas utilizan el protocolo FHE para realizar cálculos de coincidencia de órdenes, salvaguardando el secreto de la información de las órdenes. Los resultados de la conciliación de órdenes se publican, pero el contenido de la orden original permanece confidencial para proteger los derechos de privacidad de los operadores. Los traders emparejados pueden comunicarse directamente y liquidar utilizando la función Swap del contrato Singularity, mientras que los traders que no lleguen a un acuerdo se enfrentarán a penalizaciones de reputación.

Para garantizar el funcionamiento estable del sistema Book, se adopta un mecanismo de incentivos de la regla de la mayoría, y los Bookies están obligados a apostar tokens:

• Las casas de apuestas utilizan un mecanismo de regla de mayoría para abordar posibles desacuerdos en la coincidencia de órdenes cifrados, lo que evita actividades maliciosas.

• El staking de tokens tiene como objetivo protegerse contra los ataques de Sybil al tiempo que motiva a los corredores de apuestas a cumplir con sus deberes y garantizar el buen funcionamiento del sistema.

En el sistema Book, la gestión de la identidad y la reputación es clave, con innovaciones que incluyen:

• Cada identidad anónima corresponde a una reputación que refleja su probabilidad de asentamiento histórico, al tiempo que mantiene la privacidad de la identidad.

• Los operadores pueden establecer umbrales de reputación para filtrar las contrapartes que coinciden con las órdenes, lo que garantiza la seguridad y la fiabilidad de las transacciones.

• Los traders que no lleguen a un acuerdo recibirán penalizaciones de reputación, lo que también afectará a la reputación de sus homólogos comerciales.

Por ejemplo, supongamos que Alicia quiere comprar 1 ETH,

• Envío de pedidos: Alice envía un pedido para comprar 1 ETH a un precio específico de $2000 USDT.

• Coincidencia de pedidos: El sistema Book encuentra un vendedor, Bob, dispuesto a vender 1 ETH a $2000 USDT.

• Confirmación de la transacción: Alice y Bob confirman que sus pedidos se han realizado correctamente.

• Liquidación de la transacción: Alice le paga a Bob $2000 USDT y recibe 1 ETH. El sistema Singularity actualiza los saldos de sus cuentas.

• Gestión de la reputación: Si Bob no completa la transacción a tiempo o muestra otros comportamientos negativos, su reputación puede reducirse, lo que lleva al sistema a restringir su emparejamiento con otros operadores. Si el índice de reputación de Bob es 5, indica que es un trader fiable. Sin embargo, si no completa la transacción a tiempo o se involucra en otros comportamientos negativos, como cancelar pedidos varias veces o manipular el mercado maliciosamente, su reputación podría verse afectada. Esto podría llevar a una disminución de 1 punto en su calificación de reputación a 4, lo que limitaría aún más su umbral de participación comercial futura.

1. Automatización

La automatización es un AMM-DEX integrado en el protocolo, y Book actúa como proveedor alternativo de liquidez. Dado que los operadores pueden enviar transacciones a través de Singularity para depositar fondos, y Singularity es anónimo, los depósitos en Automation también son anónimos. Esto significa que las identidades de los comerciantes no están expuestas, protegiendo su privacidad.

Los traders pueden retirar fondos de Automation en cualquier momento y transferirlos al contrato de Singularity. Esta flexibilidad permite a los operadores gestionar libremente sus fondos y retirarlos cuando sea necesario. Del mismo modo, dado que el contrato de Singularity en sí mismo es anónimo, el proceso de retiro también mantiene el anonimato de los comerciantes.

En el caso de las órdenes que no se pueden hacer coincidir con ninguna orden de Book, Automation proporcionará una coincidencia para ayudar a aumentar la liquidez. Esto garantiza que, incluso si las órdenes no se emparejan de inmediato, las órdenes de los operadores aún se pueden procesar y sus operaciones pueden continuar. Al proporcionar liquidez adicional, la automatización mejora la eficiencia general y la experiencia comercial del protocolo.

1. Retractor

En Singularity, el Relayer desempeña un papel crucial, responsable de enviar metatransacciones en nombre de los usuarios y pagar la tarifa de gas por las transacciones de los usuarios. Este diseño está motivado por el deseo de proteger el anonimato del usuario. Dado que las tarifas de gas deben pagarse a la cadena de bloques de capa base típicamente pública, si los usuarios pagaran sus propias tarifas de gas, sus identidades podrían quedar expuestas.

Los repetidores llevan a cabo esta tarea mediante el envío de metatransacciones. Las metatransacciones son verificables y computables de forma nativa, lo que evita que los Retransmisores manipulen o alteren el contenido de las transacciones, garantizando así la seguridad e integridad de las transacciones. Además, para evitar el comportamiento malicioso de los Relayers, el sistema está diseñado con una red Relayer sin confianza. Esto significa que cualquiera puede ejecutar un repetidor sin necesidad de proporcionar ningún tipo de garantía.

Las transacciones presentadas por los usuarios y sus tarifas asociadas son públicas y se pagarán a los Retransmisores para compensarlos por las Tarifas de Gas que cubren. Este diseño hace que la red Relayer sea un sistema racional, en el que aceptarán y enviarán cualquier transacción rentable. Incluso si hay repetidores maliciosos, garantizar la presencia de al menos un repetidor honesto garantiza la integridad del sistema. Por supuesto, los comerciantes tienen la opción de ejecutar su propio Relayer y reemplazar la tarifa de gas, aunque a expensas de cierta privacidad.

1. API

La API sirve como nodo de interfaz para que los usuarios interactúen con el protocolo. A través de la API, los usuarios pueden generar y enviar pruebas del contrato de Singularity, gestionar los pedidos del Book, escuchar el Book para encontrar coincidencias y negociar acuerdos sobre el contrato de Singularity. Además, la API permite a los usuarios interactuar con Relayers.

Transacciones de privacidad

Con base en la estructura antes mencionada, se pueden implementar las transacciones de privacidad mencionadas anteriormente:

• Transacciones anónimas (automatización)

Al realizar transacciones con Automation, dado que los operadores necesitan realizar una operación de depósito, la cantidad de dinero comprometida cada vez quedará expuesta, al igual que cada depósito en Singularity no puede evitar ser escuchado por terceros que escuchan los detalles de la transacción. Por lo tanto, realizar transacciones a través de la automatización sacrificará la ocultación de la transacción.

Cabe señalar que cuando el Libro no puede igualar a un trader, aunque su orden puede incluirse en el pool de trading de Automation para su emparejamiento (lo que parece exponer la dirección del trader), el anonimato del trader sigue estando garantizado, porque la entidad que transfiere su liquidez es Singularity.

• Transacciones Anónimas + Ocultas (Liquidación a través de la Singularidad)

Al liquidar transacciones a través de Singularity, independientemente de cómo se lleve a cabo el descubrimiento del precio de la transacción y la coincidencia de intenciones, la liquidación final de la transacción aún puede garantizar su anonimato y ocultación. Esto se debe a que el contrato de Singularity es responsable de la liquidación de la custodia de los fondos y la transferencia final de los fondos, logrando así visibilidad a la vista mientras se opera en la oscuridad.

Dark Pool Trading: La implementación de la singularidad

Proceso de trading de Singularity

Un dark pool, dirigido a grandes instituciones y traders profesionales, proporciona una plataforma para operar sin afectar a los precios de mercado. Se adapta principalmente a dos tipos de necesidades comerciales: transferencia e intercambio. A continuación, detallaremos cómo Singularity implementa estos dos tipos de transacciones en función del contenido representado en el diagrama anterior. Es importante tener en cuenta que los nodos de API y los nodos de trading forman parte del mismo nodo en el diagrama; Para mayor claridad, aquí se describen como dos tipos diferentes de nodos.

1. Transacciones de transferencia

Las transacciones de transferencia se realizan principalmente entre dos nodos de Trader. Definimos el nodo Trader receptor como Trader A y el nodo Trader emisor como Trader B. El proceso específico para una transacción entre el Trader A y el Trader B es el siguiente:

1) Al realizar una transacción, el Trader B debe depositar fondos en el contrato de Singularity. El Trader B encripta esta transacción de depósito llamando a una API, generando así una ZK Proof, también conocida como ZK Note, y la proporciona al contrato de Singularity para verificar que el Trader B ha depositado los fondos.

2) Después de depositar los fondos, el Trader B inicia una transacción de transferencia llamando a una API para enviar una nota ZK al contrato de Singularity.

3) Al recibir la Nota del Trader B, el contrato de Singularity identifica al Trader A correspondiente en función de la información proporcionada en la Nota. En este punto, el Trader A puede extraer el importe de la transacción de Transferencia del contrato de Singularity.

En este proceso, observamos que la interacción entre los nodos y el contrato se lleva a cabo a través de ZK Notes. Las notas utilizan un modelo UTXO para la transferencia, que posee inherentemente un grado de privacidad y anonimato en comparación con el modelo de cuenta. Este método garantiza que los detalles de una transacción sean conocidos solo por su iniciador, mientras que externamente, parece como si alguna dirección interactuara con el contrato de Singularity. Sin embargo, los detalles básicos de la transacción, como la dirección del destinatario o el importe de la transacción, no se pueden capturar.

1. Operaciones de swap

En comparación con las transacciones de transferencia, las transacciones de swap son algo más complejas debido a la necesidad de encontrar una contraparte comercial. Aquí, definimos el nodo Trader que desea participar en una transacción de Swap como Trader C y el nodo Trader del socio comercial finalmente encontrado como Trader D. El proceso de transacción específico entre el Trader C y el Trader D es el siguiente:

1) De manera similar al primer paso de la transacción de transferencia, el Trader C necesita depositar fondos en el contrato de Singularity y, simultáneamente, el Trader C iniciará una transacción de Orden en el nodo Book llamando a una API.

2) Actuando como un nodo de libro de órdenes fuera de la cadena, el nodo Libro intenta hacer coincidir diferentes transacciones de pedidos en un entorno de cifrado totalmente homomórfico (FHE) sin conocer los detalles específicos de las transacciones de pedidos.

un. Una vez que la coincidencia se haya realizado correctamente, el nodo Book notificará a los dos nodos Trader correspondientes para que procedan con la transacción.

b. Si falla la coincidencia, el Libro depositará los fondos relacionados con esta transacción en la Automatización on-chain como liquidez reservada. Esto es similar a depositar dinero sobrante en un servicio de ahorro como Yu'e Bao. Si todavía hay transacciones que no coinciden más adelante, priorizarán el comercio desde la automatización. Solo cuando los fondos en Automation sean insuficientes para completar la transacción, interactuará con DEX externos como Uniswap a través del contrato de Singularity.

Después de encontrar la contraparte comercial y negociar los detalles del Swap, los traders firmarán los detalles de la transacción del Swap mutuamente. Luego, cualquiera de las partes puede usar estas firmas para construir una prueba de conocimiento cero, lo que permite que la transacción cambie la propiedad de Notes sin que ambas partes estén en línea. Es importante tener en cuenta que, para proteger la privacidad de la transacción, las transacciones de Swap se siguen realizando a través del contrato de Singularity.

Por lo tanto, podemos ver que Singularity utiliza principalmente las tecnologías ZK (Zero Knowledge) y FHE en el proceso de transacción para lograr la privacidad y el anonimato. El uso de la tecnología ZK garantiza que los detalles de cualquier transacción solo sean conocidos por el iniciador, pero permite que otros comerciantes o el contrato de Singularity lo verifiquen rápidamente; La tecnología FHE permite que el nodo Book calcule transacciones de coincidencia mutua durante el proceso de coincidencia sin necesidad de conocer los detalles específicos de las transacciones, y también mantiene la confidencialidad de la información de la transacción original cuando se notifica a ambas partes, lo que significa que las partes solo saben con quién están negociando, pero no el tipo de activo específico y el monto de la operación.

Resumen y evaluación

El mercado OTC representa casi el 70% de todo el volumen de operaciones del mercado de criptomonedas, lo que pone de manifiesto la importante demanda de transacciones de privacidad en la industria Web3. Sin embargo, el sector del comercio de privacidad aún enfrenta varios desafíos, como cumplir con los requisitos regulatorios de los organismos gubernamentales, realizar transacciones sin revelar información específica sobre los usuarios y las transacciones, y prevenir acciones maliciosas por parte de las partes comerciales. Los dark pools descentralizados como Singularity representan una solución innovadora que puede proporcionar a los usuarios mayores niveles de protección de la privacidad y resistencia a la censura mediante el uso de tecnologías de privacidad y contratos inteligentes, reduciendo la dependencia de entidades centralizadas. Estas plataformas admiten grandes transacciones de forma anónima y pueden integrarse con los servicios de cumplimiento para crear un entorno comercial descentralizado y que cumpla con la normativa.

Consideraciones clave para el sector de piscinas oscuras:

1. Arquitectura técnica: Las pruebas de conocimiento cero (ZKP) y la computación multipartita (MPC) son fundamentales para el sector de los dark pools, ya que permiten la verificación de la validez de las transacciones sin revelar los detalles de las mismas. Muchos protocolos actuales dependen en gran medida o en su totalidad de MPC, que tiene dos inconvenientes principales: baja eficiencia computacional y complejidad del protocolo. Los protocolos MPC requieren probar y verificar los ZKP dentro de un marco MPC, que es computacionalmente intensivo. Además, MPC a menudo necesita conexiones de red estables, lo que es difícil de lograr en una red descentralizada global. Estos factores hacen que los protocolos basados completamente en MPC no sean prácticos para aplicaciones a gran escala, como los motores de coincidencia de pedidos.

2. Anonimato y protección de la privacidad: La regulación es un tema ineludible en el sector de la privacidad. Garantizar que las transacciones y los fondos sean completamente anónimos y, al mismo tiempo, proporcionar suficiente protección de la privacidad es una tarea difícil. Es particularmente importante para los usuarios que desean operar con capital compatible. Los proyectos de dark pool necesitan urgentemente integrar los procesos KYB/KYC, adoptar la regulación de forma proactiva y garantizar que los datos KYC/KYB de los usuarios no se filtren para mantener la legalidad de la plataforma y la confianza de los usuarios.

3. Liquidez y seguridad de los fondos: La liquidez es un factor crítico en las operaciones de dark pool. Garantizar un volumen de negociación y una seguridad de fondos suficientes es vital para una coincidencia eficiente de las órdenes y para mejorar el anonimato y la voluntad de participar de los operadores. En los dark pools, el anonimato de los fondos aumenta con el tamaño del pool, lo que dificulta el seguimiento de depositantes específicos. En escenarios de escasa liquidez, los modelos de libro de órdenes de muchos protocolos tienen limitaciones a la hora de hacer coincidir las operaciones entre los usuarios, ya que no siempre proporcionan suficiente liquidez para todas las órdenes. Además de los libros de órdenes, los innovadores mecanismos de negociación de AMM y la integración de más aplicaciones DeFi de varios ecosistemas blockchain podrían ser formas efectivas de expandir la liquidez.

4. Escalabilidad : Garantizar una buena escalabilidad para dar cabida a un número creciente de usuarios y volúmenes de transacciones es esencial para los dark pools. Los dark pools corren el riesgo de sufrir pérdidas si se enfrentan a un aumento de los LP sin que coincidan las órdenes. Por lo tanto, los dark pools deben tener en cuenta sus capas de liquidación, el diseño técnico y la hoja de ruta del ecosistema durante la fase de diseño para satisfacer las mayores demandas de transacciones, especialmente en el marco de marcos regulatorios progresivamente exhaustivos.

El dark pool trading, con cierta historia en las industrias tradicionales y que aún no ha sido refutado como solución, sigue teniendo una importante demanda de mercado y potencial de desarrollo. El trading tradicional de dark pool se enfrenta a riesgos de confianza con los traders centralizados, mientras que los proyectos descentralizados como Singularity adoptan de forma innovadora un modelo de "dark pool + pool transparente para dark trades", abordando los puntos débiles de la dependencia de la centralización, la privacidad insuficiente y la escasa resistencia a la censura.

A diferencia de los proyectos anteriores de comercio de privacidad, Singularity ofrece la funcionalidad de comercio de privacidad de activos junto con las capacidades de comercio de activos DeFi. El mercado actual está inundado de agregadores comerciales, pero pocos tienen características distintivas o un diseño que mejore la adherencia del usuario. Singularity, que sirve como una capa de privacidad para los grupos transparentes, aborda en primer lugar los puntos débiles comerciales de las instituciones y las ballenas, manteniendo la asimetría de la información. En comparación con las soluciones actuales de trading de privacidad, el diseño de un dark pool (capa de privacidad) encarna naturalmente el principio de "mantener el dinero en el bolsillo", ya que la privacidad se pierde si los fondos de los traders entran y salen con frecuencia de la plataforma, lo que equivale a la auto-revelación. Por lo tanto, la mayoría de los fondos prefieren permanecer en el dark pool durante un tiempo suficiente antes de retirarse, lo que beneficia el crecimiento estable del TVL del proyecto y brinda a los usuarios más seguridad.

Basado en los estándares antes mencionados para dark pools descentralizados, Singularity se destaca entre las soluciones actuales de dark pool por varias razones:

• Anonimato y protección de la privacidad: Para el anonimato, el enfoque convencional es Zero-Knowledge Proofs (ZKP). Por lo tanto, encontrar los socios adecuados es clave. Actualmente, Singularity delega los procesos KYC y KYB fuera de la cadena a ComplyCube (KYC) y Shufti Pro (KYC y KYB), con Keyring construyendo las pruebas correspondientes y los oráculos que finalmente llevan estas pruebas a la cadena de bloques. En comparación con otros proyectos, Singularity está más en línea con los requisitos de cumplimiento actuales, evitando futuros riesgos regulatorios similares a los que enfrenta Tornado Cash.

• Seguridad del fondo: No es posible realizar una comparación directa de la seguridad del contrato. Sin embargo, dado que Singularity permite que los pools transparentes actúen como dark pools, puede disminuir la disposición de los usuarios y las instituciones a mover fondos, exponiendo potencialmente su capital a riesgos de seguridad contractuales a largo plazo. Como se mencionó anteriormente, las transferencias frecuentes de fondos por parte de las instituciones/usuarios también pueden exponer las direcciones, lo que requiere un equilibrio entre la privacidad de la dirección y la seguridad del fondo.

• Liquidez: A diferencia de los proyectos que se basan únicamente en modelos de libro de órdenes/AMM, Singularity introduce tanto libros de órdenes como AMM para maximizar la eficiencia de liquidez. Sin embargo, la aplicación real puede mostrar que la diferencia en la liquidez debida a los modelos de negociación podría no ser significativa, dependiendo más de las capacidades de desarrollo comercial del proyecto y su cumplimiento, y la decisión final descansa en gran medida en manos de los usuarios del mercado.

• Escalabilidad : En términos de compatibilidad del ecosistema, la compatibilidad de Singularity con el ecosistema EVM es una narrativa convencional. Si no se considera la creación de su propia cadena, la eficiencia de la liquidación de transacciones sigue estando muy limitada por su capa de liquidación. En casos extremos, es posible que estas capas no puedan manejar transacciones de alta frecuencia. Por lo tanto, a medio y largo plazo, los proyectos que amplíen la dirección del ecosistema app-chain serán más escalables. Técnicamente, Singularity opta por FHE+ZKP, que es más eficiente que las soluciones MPC-ZKP debido a la alta eficiencia computacional requerida por MPC-ZKP. Por lo tanto, el enfoque tecnológico elegido por Singularity parece satisfacer las necesidades de transacción. Desde el punto de vista de la expansión del ecosistema, el enfoque de "pool transparente como dark pool" puede extenderse a escenarios no transaccionales y otros contextos DeFi, ofreciendo posibilidades imaginativas comparables a las propuestas por Uniswap V4 con ganchos.

Si bien se reconocen las competencias básicas de Singularity, también es importante ser consciente de los riesgos potenciales a los que se puede enfrentar el proyecto en el futuro:

• Pérdida de la función de descubrimiento de precios de mercado: Debido al anonimato y al gran volumen de operaciones de dark pool, es posible que los precios de los activos en el mercado no reflejen con precisión las fluctuaciones dentro de la dark pool. Esto da lugar a una pérdida de descubrimiento efectivo de precios, ya que otros participantes del mercado no pueden acceder a la información sobre las operaciones de dark pool. La excepción es si los usuarios utilizan DEX convencionales para el descubrimiento de precios en Singularity, donde los precios pueden reflejar la oferta y la demanda reales del mercado.

• Riesgo regulatorio del gobierno: Las operaciones de dark pool, potencialmente utilizadas para evadir la regulación y los estándares, podrían llevar a las agencias gubernamentales a implementar medidas regulatorias más estrictas. Estas podrían incluir una mejor supervisión y regulación de las operaciones de dark pool o sanciones para las personas y entidades que participen en dichas operaciones. Estas medidas podrían afectar el desarrollo y la operación del proyecto Singularity y aumentar los riesgos legales.

• Control y seguridad de los fondos: Con los fondos mantenidos a largo plazo en contratos de Singularity, similares a una bóveda, podría haber riesgos contractuales en situaciones extremas. Sin embargo, dado que Singularity no implica la comunicación multicadena ni se basa en repetidores de transacciones, su seguridad es al menos mayor que la de los puentes entre cadenas.

• Riesgos KYC/KYB: La alta dependencia de un número limitado de socios para las comprobaciones de calificación de los usuarios podría introducir puntos únicos de fallo.

En resumen, Eureka Partners considera la vía de la privacidad como una importante inversión estratégica. Para las instituciones de inversión y otras partes interesadas, Singularity representa el comercio de dark pool; Sin embargo, para los reguladores, es más parecido a un "grupo gris". Anticipamos que las operaciones OTC e institucionales adoptarán gradualmente métodos de negociación regulados de privacidad de dark pool. Creemos que el desarrollo tecnológico actual en Web3 está haciendo un "progreso iterativo". Tras la estricta regulación de Tornado Cash, surgió un visible vacío en la demanda de comercio de privacidad. Históricamente, la implementación de reglas a menudo va a la zaga de los avances y revoluciones tecnológicas. Cuando la tecnología se enfrenta a desafíos, debemos aceptar el cambio y no desperdiciar ninguna crisis. Esperamos que Singularity se convierta en el próximo líder en el tema de la privacidad regulada de ZK para piscinas oscuras.

"Nunca desperdicies una buena crisis". - Winston Churchill

Renuncia:

1. Este artículo es una reimpresión de Eureka Partners, reenvíe el título original 'Informe de investigación de Eureka Partners: Singularidad - Transacciones de privacidad en cadenas de bloques transparentes', Todos los derechos de autor pertenecen al autor original [Oliver, Andy, Howe]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.