Los intercambios descentralizados, o DEX, se han vuelto cada vez más populares recientemente, ya que los usuarios se saltan las plataformas centralizadas en favor de alternativas sin permisos, sin confianza y componibles. Si bien Ethereum sigue siendo la cadena de bloques preferida con ofertas populares como Uniswap, Curve y Balancer, los precios de la gasolina 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 admitir un DEX de capa 2 escalable, que puede generar tarifas de transacción sostenibles y tiempos de confirmación predecibles. Puede 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 DEX de capa 2 que puede diseñar en Nervos, pero primero, describamos las diferentes categorías de infraestructura DEX.
Con la evolución de los servicios de intercambio en cadena y DeFi, podemos dividir un DEX como infraestructura en varios tipos amplios en la actualidad. 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 infinita al establecer automáticamente el precio mediante una ecuación matemática. El tercero es el tipo de creador de mercado representado por Kyber, que cotiza automáticamente los mejores precios de varios grupos de reservas externas.
La característica unificadora de 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 intercambios 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 una gran cantidad 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 Cell 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 en cadena / agregación fuera de cadena, que solo necesita verificar que los resultados de compensación fuera de cadena sean correctos en lugar de actualizar continuamente el estado de la cuenta de usuario a través de transacciones. El modelo de resumen está muy en línea con la lógica empresarial de CKB, por lo que en este artículo analizaremos el diseño de un CKB DEX basado en un modelo de agregación de órdenes de capa 2.
Depósito y retiro
En depósito, el usuario delega el derecho a operar un activo al contrato DEX. Esta operación se puede comparar con el proceso de depósito de un intercambio centralizado tradicional, pero el activo no tiene 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 Celda de Cuenta que registra los activos depositados. La lógica de la celda de la cuenta 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 acciones. También permite que el contrato modifique su saldo según las reglas predefinidas.
El campo de datos de la celda 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 celda de cuenta con una o más celdas de depósito y genera una o más celdas 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 celda de cuenta del usuario; sin embargo, esta celda de cuenta 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 celda previa al retiro antes de un retiro formal. Un retiro formal debe hacer referencia a esta celda de pre-retiro, y si el agregador ve esta celda de pre-retiro, automáticamente excluirá la celda de cuenta del usuario del estado.
Orden de transacción y emparejamiento
Nos referimos a la celda de cuenta del usuario como el estado inicial, y para un DEX de AMM, habrá un estado inicial adicional registrado en una 'celda de grupo de activos'. El usuario establece una conexión con el agregador de Capa 2, obtiene la cotización de precio actual y información del pedido y luego envía los pedidos de transacciones. La orden de transacción incluye la descripción de la transacción (orden), como "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 de eso, el agregador compara las órdenes recibidas en tiempo real y actualiza el estado de cada celda de cuenta involucrada (nuevos estados) y luego confirma regularmente la nueva celda de cuenta en la cadena para la liquidación en cadena. Cada transacción en cadena consta del estado inicial, el nuevo estado y la firma digital del usuario. El tipo de script de la celda de la cuenta es responsable de verificar la validez de la liquidación.
Similar a Uniswap, un AMM DEX en CKB también necesita un grupo 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.
Agregue 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 celda 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 existe un 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 celda de grupo de activos que se utilizará para transacciones posteriores.
Siempre que se deposita liquidez en un grupo, se acuñan 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 grupo. Estos tokens son una representación de la contribución de un proveedor de liquidez a un grupo. Para recuperar la liquidez subyacente (más las tarifas que se devengaron 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.
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.
Agregar / quitar liquidez
Cualquiera puede convertirse en un proveedor de liquidez para un grupo depositando un valor equivalente de cada token subyacente a cambio de tokens de liquidez. Estos tokens rastrean las cuotas de liquidez prorrateadas del grupo total 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.
Comparación 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.
Procesar agregar órdenes de 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 a pedido de acuerdo con los requisitos de deslizamiento de la orden). Procesar órdenes de eliminación de liquidez
Siempre que se produzca una operación, los usuarios deben pagar una determinada tarifa (por ejemplo, 0,3%). Parte de esta tarifa (por ejemplo, 0,2%) va directamente al conjunto 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.
Comparado con el modelo AMM, el modelo de cartera de pedidos tiene dos diferencias principales: una es que sus pedidos son generalmente pedidos limitados en lugar de pedidos de 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 pedidos agrega más datos de pedidos a la cadena que el modelo AMM y elimina los tokens de liquidez y los grupos de fondos.
Actualizar órdenes de límite
Después de que el operador "deposita" el activo en el DEX, puede realizar una orden limitada. El contenido de la orden de límite incluye: activo solicitado, precio de transacción, cantidad de transacción, etc. Para facilitar el seguimiento, cada orden de límite generará un identificador único 'oid' (esto se puede lograr usando el hash de punto de salida de la primera celda de entrada .).
Comparación de transacciones y cálculo de tarifas
Tenga 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 motor de emparejamiento sigue la siguiente lógica:
Todos los nuevos pedidos agregados a través de datos de testigos se procesan junto con los pedidos antiguos almacenados en datos de celda. Divida los pedidos en dos colas de acuerdo con los pedidos de compra y venta y organícelos en orden descendente y ascendente según el precio. 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. Continúe procesando el siguiente pedido principal hasta que no se pueda igualar.
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.
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 desconfianza 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 más 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, los pedidos antiguos 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 como la tecnología a prueba de conocimiento cero y la tecnología de firma agregada.
