Los exchanges descentralizados, o DEXs, se han vuelto cada vez más populares recientemente. Si bien Ethereum sigue siendo la blockchain preferida con ofertas populares como Uniswap, Curve y Balancer, los precios del gas han aumentado drásticamente en los últimos meses, lo que ha afectado negativamente a los usuarios.
Muchos usuarios se están dando cuenta de que están gastando una parte cada vez mayor de sus tenencias para garantizar que las transacciones se confirmen, mientras que otros ya no tienen una forma de interactuar con los productos DeFi que tenga sentido financieramente.
El sentimiento de “¿cuándo la capa 2?” se menciona con creciente urgencia en la comunidad, pero afortunadamente Nervos ha sido diseñado con una arquitectura ideal para soportar un DEX de capa 2 escalable, que puede generar tarifas de transacción sostenibles y tiempos de confirmación predecibles. Puedes leer más sobre la filosofía de diseño y la arquitectura en capas de Nervos en el documento de posicionamiento.
En este artículo, compartiremos detalles sobre los dos tipos de DEXs de capa 2 que puedes diseñar en Nervos, pero primero, describamos las diferentes categorías de infraestructura DEX.
Las posibilidades de DEX en Nervos
Con la evolución de los servicios de intercambio en cadena y DeFi, en la actualidad podemos dividir un DEX como infraestructura en varios tipos. Uno es el tipo de libro de pedidos, representado por Etherdelta y 0x, que se puede subdividir en correspondencia de pedidos dentro y fuera de la cadena. El segundo es el tipo AMM representado por Uniswap, que proporciona una profundidad al establecer automáticamente el precio a través de una ecuación matemática. El tercero es el tipo de creador de mercado representado por Kyber, que cotiza automáticamente los mejores precios entre varios grupos de reservas externas.
La característica entre los tres modelos es que los activos del usuario están en custodia propia, ya que no se confía en el proveedor de servicios. Como resultado, los DEX son sustancialmente más seguros que los exchanges centralizados tradicionales. Más recientemente, con el desarrollo de la tecnología rollup, se ha intentado utilizar esta tecnología y sus mejoras, zk-rollup y optimistic rollup, para optimizar los DEX. Esto se logra mediante la introducción de un agregador fuera de la cadena que borra un gran número de transacciones fuera de la cadena y luego las liquida periódicamente en la Capa 1. Este enfoque también mejora significativamente el rendimiento de las transacciones de la Capa 1 y reduce el costo promedio de las transacciones.
El modelo de Célula adoptado en CKB es muy diferente del modelo de cuenta en Ethereum en términos de diseño de producto y protocolo, lo que plantea un desafío para la implementación de un DEX en CKB. Sin embargo, el rollup utiliza un modelo de liquidación dentro de la cadena / agregación fuera de la cadena, que solo necesita verificar que los resultados de la compensación fuera de la cadena sean correctos en lugar de actualizar continuamente el estado de la cuenta del usuario a través de transacciones. El modelo en resumen está muy en línea con la lógica comercial de CKB, por lo que en este artículo discutiremos el diseño de un CKB DEX basado en un modelo de agregación de órdenes de capa 2.
Procesos básicos de negocios
Depositar y Retirar
En el depósito, el usuario delega el derecho de operar un activo al contrato DEX. Esta operación se puede comparar con el proceso de depósito de un exchange centralizado tradicional, pero el activo es sin custodia, lo que significa que la propiedad del activo permanece en el usuario.
En el proceso de depósito, el usuario autoriza un contrato para administrar sus activos y genera una célula que registra los activos depositados. La lógica de la célula está asegurada por el correspondiente script de tipo de compensación DEX, que registra el hash de la clave pública del usuario utilizado para autenticar las acciones. También permite que el contrato modifique su saldo de acuerdo con las reglas predefinidas.
El campo para datos de la célula de la cuenta registra el saldo de los diversos activos del usuario y, según el tipo de DEX, el libro de pedidos del usuario también puede almacenarse aquí.
La operación de retiro es la inversa de la operación de depósito. En este proceso, el usuario combina su célula de cuenta con una o más células de depósito y genera una o más células de activos. Hay una situación que debe tenerse en cuenta aquí. Si el usuario no ha terminado su negocio en el agregador de Capa 2, el agregador puede enviar una transacción agregada que hace referencia a la célula del usuario, sin embargo, también puede ser referenciada por una transacción de retiro. Para evitar que esto suceda, debemos imponer restricciones adicionales a los retiros. Por ejemplo, el usuario debe anunciar una célula previa al retiro antes de un retiro formal. Un retiro formal debe hacer referencia a esta célula de pre-retiro, y si el agregador ve esta célula de pre-retiro, automáticamente excluirá del estado la célula de cuenta del usuario.
Orden de transaccional y emparejamiento
Nos referimos a la célula de cuenta del usuario como el estado inicial, y para un DEX de AMM, habrá un estado inicial adicional registrado en una ‘célula de pool de activos’. El usuario establece una conexión con el agregador en la segunda capa, obtiene la cotización de precio actual e información del pedido y luego envía los pedidos. La orden de la transacción incluye la descripción de la transacción, como, por ejemplo: “0.1 cBTC por 1000 cUSD”, y la firma de la transacción. Una vez que el agregador recopila el pedido del usuario, inmediatamente le envía información al usuario para que pueda ver que su transacción ha sido aceptada.
Después, el agregador compara las órdenes recibidas en tiempo real y actualiza el estado de cada célula de cuenta involucrada (nuevos estados) y luego confirma regularmente la nueva célula de cuenta en la blockchain para la liquidación en cadena. Cada transacción consta del estado inicial, el nuevo estado y la firma digital del usuario. El tipo de script de la célula de cuenta es responsable de verificar la validez de la liquidación.
AMM DEX y su proceso de emparejamiento
Al igual que Uniswap, un AMM DEX en CKB también necesita un pool de activos configurado para proveedores de liquidez. En esta sección, usaremos el par comercial CKB-sUDT como ejemplo, demostrando cómo agregar un par comercial y cómo proporcionar liquidez.
Agregar par comercial e inyecte liquidez inicial
Para evitar la adición duplicada de los mismos pares comerciales, es necesario introducir aquí un mecanismo para el registro de pares.
Cuando el usuario registra un nuevo par comercial, debe verificar si ya existe en la célula de registro. De lo contrario, puede registrarlo con éxito y usar el hash de la identificación del token como identificador del par comercial. El nuevo par agregará un nuevo registro al registro. Actualmente no hay ningún método diseñado para anular el registro de un par de tokens.
Para que el grupo comience a facilitar los intercambios, alguien debe sembrarlo con un depósito inicial de cada token al registrar el par. Este primer proveedor de liquidez fijará el precio inicial del pool. Se les incentiva a depositar un valor igual de ambos tokens en el grupo. Por ejemplo, si 1 CKB = 0.01 USDT, el usuario debe inyectar 50k CKB y 500 USDT en el depósito inicial. Estos dos activos generan una única célula de pool de activos que se utilizará para transacciones posteriores.
Siempre que se deposita liquidez en un grupo, se ‘mintean’ tokens especiales conocidos como tokens de liquidez a la dirección del proveedor de liquidez en proporción a la cantidad de liquidez que están contribuyendo al pool. Estos tokens son una representación de la contribución de un proveedor de liquidez a un pool. Para recuperar la liquidez subyacente (más las comisiones acumuladas mientras su liquidez estaba bloqueada), los proveedores de liquidez deben quemar sus tokens de liquidez. La lógica empresarial aquí es básicamente idéntica a la de Uniswap.
El Liquidity Token es un UDT extendido que se ajusta al estándar sUDT. La diferencia entre este UDT extendido y el sUDT estándar es que su código de contrato es ligeramente diferente y la etiqueta de activo de Liquidity Token es el hash del par comercial.
Añadir y retirar liquidez
Cualquiera puede convertirse en un proveedor de liquidez para un pool depositando un valor equivalente de cada token subyacente a cambio de tokens de liquidez. Estos tokens rastrean las cuotas de liquidez del pool y se pueden canjear por los activos subyacentes en cualquier momento.
Para evitar conflictos de transacciones o problemas DDoS debido a interacciones frecuentes con un grupo de activos, es posible que sea necesario introducir algunas restricciones. Por ejemplo, agregar requisitos de umbral, requisitos de tarifa de retiro, etc.
Emparejamiento de transacciones y cálculo de tarifas
El servidor de agregación recopila los pedidos de los usuarios durante un período de tiempo y los agrega. Estas órdenes incluyen: órdenes de compra, órdenes de venta, agregar liquidez o eliminar órdenes de liquidez. Teniendo en cuenta la equidad de la ordenación de transacciones, las órdenes agregadas se ejecutan de acuerdo con las siguientes reglas (orden). Este enfoque puede minimizar el deslizamiento de transacciones.
-
Se procesan las órdenes para agregar liquidez
-
Todas las órdenes de compra y venta se combinan directamente de acuerdo con el precio actual.
-
Luego, el resto de las órdenes de compra y venta se pueden compensar de acuerdo con la curva de precios predeterminada. (Estos se pueden procesar en el pedido de acuerdo con los requisitos de deslizamiento).
-
Se procesan las órdenes para eliminar la liquidez
Siempre que se produzca una transacción, los usuarios deben pagar una determinada tarifa (por ejemplo, 0,3%). Parte de esta tarifa (por ejemplo, 0,2%) va directamente al pool de activos como un beneficio para el proveedor de liquidez, y la otra parte (por ejemplo, 0,1%) se paga a una dirección designada como tarifa de operación del agregador.
Libro de órdenes (OrderBook) DEX y su proceso de emparejamiento
Comparado con el modelo AMM, el modelo de libro de órdenes tiene dos diferencias importantes: una es que sus órdenes son generalmente limitadas en lugar de órdenes a mercado, lo que significa que el comerciante controla el precio de la transacción; la segunda es que no proporciona liquidez ilimitada y el usuario debe esperar a que se igualen las órdenes. En términos de estructura de datos, el modelo de libro de órdenes agrega más orden de datos a la cadena que el modelo AMM y elimina los tokens de liquidez y los pools de fondos.
Actualización de las órdenes limitadas
Después de que el operador “deposita” el activo en el DEX, puede colocar una orden limitada. El contenido de la orden límite incluye: activo solicitado, precio de transacción, cantidad en la transacción, etc. Para facilitar el seguimiento, cada orden de límite generará un identificador único ‘oid’ (esto se puede lograr utilizando el hash de punto de salida de la primera célula de entrada.).
Emparejamiento de órdenes y cálculo de tarifas
Ten en cuenta que la orden limitada del comerciante se enviará primero al agregador. Un agregador emparejará parte de los pedidos directamente y enviará los pedidos no completados temporalmente a la cadena, actualizando el libro de pedidos en cadena. En el próximo ciclo de agregación, estos pedidos sin completar participarán en la próxima ronda de emparejamiento como entradas, y no se requerirá que los comerciantes envíen una nueva firma de transacción nuevamente.
El emparejamiento de órdenes sigue la siguiente lógica:
-
Todos los pedidos nuevos agregados se procesan junto con los pedidos antiguos almacenados en los datos de la célula.
-
Se divide los pedidos en dos filas según los pedidos de compra y venta y se organizan en orden descendente y ascendente según el precio.
-
Coinciden los pedidos principales de las dos filas. A su vez, si los precios coinciden, la transacción se ejecutará al precio promedio y se actualizará la información sobre la cantidad del pedido y el saldo de la cuenta del usuario.
-
Se continúa procesando el siguiente pedido principal hasta que no pueda coincidir.
La tarifa de transacción se cobra en proporción a la cantidad de la transacción (por ejemplo, 0,1%) y es cobrada por el operador del agregador.
Resumen
En este artículo, diseñamos dos tipos de DEX de capa 2 en CKB. Ambos han hecho un uso completo de las características de agregación del modelo UTXO, completaron la agregación de transacciones y el emparejamiento fuera de la cadena, y redujeron el volumen de transacciones en la cadena, así como los costos cognitivos de los usuarios. Y lo más importante, estos diseños garantizan la descentralización y la falta de confianza de la custodia de activos.
En comparación con la solución acumulada, la solución de agregación de transacciones de este artículo no utiliza pruebas de conocimiento cero o suposiciones optimistas en los desafíos para reducir la complejidad computacional de la verificación de transacciones. Por lo tanto, el rendimiento real, que se espera que sea ~ 200-300 TPS, está relacionado con la relación entre el límite superior de los ciclos de cálculo en un bloque y el costo del ciclo de una verificación de firma única.
Aunque en el modelo de libro de pedidos las ordenes antiguas no requieren la verificación de la firma por segunda vez, la mejora en el rendimiento relacionada con esto es limitada. Sin embargo, creemos que, en el futuro, podemos aumentar considerablemente el rendimiento de las transacciones a través de soluciones criptográficas cómo la tecnología a prueba de conocimiento cero y la tecnología de firma agregada.
Para mantenerse actualizado sobre todo lo relacionado con Nervos:
Únete a nuestra comunidad: Discord - GitHub - Foro - Twitter
Esta es una traducción al español por @luisantoniocrag y revisada por @Lalo