Maladex resuelve escalas de concurrencia más allá de los límites de la memoria y diseña el mejor Cardano DEX posible

20 min readSep 24, 2021

El motor de comparación de pedidos de Maladex logra la máxima concurrencia definida por la ley de Amdahl e introduce un mecanismo de escalado más allá de los límites de transacción de 16kB y tamaño de bloque de 65kB. Maladex lo logra al mismo tiempo al introducir el concepto revolucionario de swaps programables, aumentar la eficiencia del capital, eliminar la pérdida no permanente y proporcionar un mecanismo para la descentralización del enrutamiento de pedidos DEX.

Fuente: Blog de Maladex

Introducción

Cardano utiliza un nuevo modelo de salida de transacciones no gastadas extendido (EUTxO) para representar el estado del libro mayor. Las consecuencias de esta elección de modelado son:

localidad de contexto, es decir, cada transacción consume la cantidad mínima de información requerida que conduce a una ejecución predecible y tarifas mucho más bajas (y exactas) que las cadenas de bloques con una memoria global.
concurrencia, dado que no existe un estado global, podemos pensar en todas las transacciones que ocurren en paralelo entre sí. donde interactúan entre sí al mismo tiempo.
Congestión de EUTxO donde varios agentes intentan gastar la misma entrada, lo que genera una condición de carrera y solo la primera transacción enviada se ejecuta con éxito.

A diferencia de los modelos basados en cuentas como Ethereum, que actúa como una aplicación de un solo subproceso con memoria global, Cardano es un sistema altamente concurrente. En cualquier sistema concurrente, es necesario administrar el acceso a las partes compartidas para garantizar que se produzca la salida correcta. Cardano logra esta propiedad de corrección mediante el requisito de que cada EUTxO se debe gastar para modificar su estado y que solo se puede gastar una vez por bloque (actualmente 20 segundos).

Esto tiene 2 consecuencias importantes:

las transacciones son mucho más baratas y las tarifas se pueden calcular exactamente, lo que conduce a una experiencia de usuario mucho mejor;
Los desarrolladores de Plutus deben considerar la concurrencia como parte de su diseño de DApp e implementarla de tal manera que se logre el mayor rendimiento posible manteniendo la equidad y la confianza.

Finalmente, Cardano tiene actualmente un desafío de escala adicional que es

una memoria de transacciones limitada a 16 kB;
una memoria de bloque limitada a 65 kB.

Esto plantea un serio desafío al modelo basado en cuentas propuesto por todos los demás DEX de Cardano (como SundaeSwap o MinSwap), ya que incluso las transacciones agregadas más pequeñas por código fuera de la cadena pueden exceder fácilmente en promedio ambos límites, lo que conduce a transacciones que no se pueden ejecutar debido a no encajar en el límite de memoria de transacciones o debido a una grave limitación de rendimiento (por ejemplo, solo 4 transacciones por bloque = 20 s).

En este artículo, cubrimos más a fondo cómo nuestro revolucionario modelo de intercambios programables aborda este problema debido a la fragmentación y el modelo de compromiso de 2 fases y cómo planeamos escalar mucho más allá de esas limitaciones al introducir nuestra propia cabeza de Hydra y cadena lateral.

Scripts de Cardano

A menudo escuchamos el término engañoso ‘contratos inteligentes’ aplicado a Cardano. Sí, Cardano tiene contratos inteligentes según la definición más general, pero la forma en que los implementa es significativamente diferente. Por lo tanto, cuando hablamos de scripts de Cardano usamos 2 términos en lugar de la frase “contratos inteligentes”:

validadores en cadena / código en cadena: el código (script) que se ejecuta en cadena y verifica que la transacción se puede ejecutar correctamente;
código fuera de la cadena: el código que no se ejecuta en la cadena de bloques. Este código es responsable de preparar transacciones y enviarlas en cadena.

Es una distinción fundamental porque implica que ejecutar código fuera de la cadena en el caso de Cardano DApps no solo es útil sino obligatorio. Incluso en el caso de una aplicación completamente distribuida, el código fuera de la cadena tendría que distribuirse a cada parte para interactuar con los datos en la cadena. On-chain no almacena scripts, solo sus hashes. Creemos que esta es una mejora de eficiencia significativa con respecto a otros modelos sin sacrificar muchas propiedades excelentes de la cadena de bloques. También vale la pena señalar que la cadena de bloques clásica basada en cuentas funciona de manera muy similar, pero sin una distinción clara de qué parte se calcula previamente fuera de la cadena y se proporciona como datos y cuál en la cadena a través de EVM, etc. Cardano elige el minimalismo saludable sin sacrificar ninguna propiedad de descentralización y seguridad.

Las buenas propiedades (no custodia, sin necesidad de confianza, etc.) se derivan del diseño criptográfico, no de las métricas de vanidad en las que cripto Twitter tiende a confiar. Cardano está diseñado para mantener todas las propiedades de seguridad en comparación con cualquier otra cadena de bloques, y en muchos casos las mejora significativamente dado el progreso que se ha producido en este campo desde el inicio de Bitcoin.

Descripción general de las soluciones de escalado propuestas por otros DEX

La única información más específica con respecto a otras soluciones ha sido proporcionada por ErgoDex, MinSwap y Meld (el último de los cuales no es un DEX). Todos los demás DEX (como SundaeSwap, OccamX, etc.) solo han insinuado cuál podría ser su solución sin dar ninguna prueba o entregar soluciones concretas con ningún detalle más allá de unas pocas palabras de moda en sus publicaciones en los medios.

La solución de ErgoDex utiliza un secuenciador fuera de la cadena que analiza todos los pedidos de límite y AMM y prepara transacciones agregadas para ejecutarlos. A pesar de que esto conduce a la centralización de la ejecución de órdenes, creemos que es una solución sólida y bastante eficiente. La cadena de bloques de Cardano ha sido diseñada para tener validadores en cadena y código fuera de cadena, que, incluso dentro del ecosistema de desarrolladores de Cardano, muchos aún no han comprendido (a juzgar por la discusión que se origina en otros DEX). Sin embargo, este modelo se puede mejorar mucho.

MinSwap propone un modelo muy similar a ErgoDex simplemente dándole un nombre elegante: “Laminar”, pero bajo el capó, esta solución utiliza el mismo modelo de procesamiento por lotes que se basa en los datos del libro mayor proporcionados por Cardano Node, por lo que, por ejemplo, se puede ejecutar en cualquier relay.

Desde nuestra perspectiva, conceptualmente estos son 2 modelos idénticos con solo pequeñas diferencias técnicas, y un intento de ajustar una solución a un problema creado por el modelo de liquidez, en lugar de resolver el problema fundamentalmente desde cero.

A menudo vemos que los términos paralelo y concurrente se usan incorrectamente y usamos ambos términos en este artículo, aclaremos su significado antes de continuar:

concurrencia significa el progreso de la misma tarea por múltiples agentes al mismo tiempo, lo que implica comunicación entre agentes (un agente puede significar hilo, proceso, persona, Mal, etc.);
El paralelismo significa dividir una tarea en tareas más pequeñas, cada una de las cuales puede proceder de manera independiente, lo que esto implica es que no hay comunicación entre los agentes.

¿Por qué nunca pensamos que la concurrencia fuera un problema?

Fue divertido para nosotros observar todas las emociones injustificadas en torno a la incapacidad de interactuar con cualquier eUTxO más de una vez por bloque. La controversia vende y, sin duda, muchos proyectos gestionan una campaña de marketing exitosa además del FUD de concurrencia de rápida difusión, las piezas que deben recopilar los proyectos que se desarrollan en silencio.

En primer lugar, fue una realización obvia a la que llegar, una de las primeras cosas con las que te encuentras cuando piensas en cómo construir un intercambio descentralizado. En segundo lugar, si un desarrollador no puede resolver un problema, no es el problema del hardware o el software, sino simplemente la falta de habilidades del desarrollador. La concurrencia es un campo estudiado en profundidad con una serie no solo de investigaciones y publicaciones vívidas, sino con una tonelada de ejemplos del mundo real, sin mencionar una base de datos distribuida.

Las bases de datos distribuidas tratan temas que van desde confirmaciones de 2 fases, consistencia de datos y muchas compensaciones, como se describe en el teorema de CAP. Es un campo listo para inspirar una serie de soluciones para lograr la concurrencia en el blockchain.

Al abordar por primera vez el diseño de una solución para el problema de concurrencia, inmediatamente aparecen una tonelada de soluciones como

compromiso en cadena con una recompensa por fusionarse en el grupo de liquidez EUTxO;
un secuenciador fuera de la cadena propuesto por ErgoDex: https://github.com/ergolabs/ergo-dex-backend
lote determinista propuesto por Meld: https://medium.com/meld-labs/concurrent-deterministic-batching-on-the-utxo-ledger-99040f809706 ;
Fragmentación de EUTxO y un mecanismo de selección determinista para asegurar una colisión mínima;
uso de algoritmos aleatorios y solución de fragmentación para realizar la programación puramente en cadena, dada una fuente confiable de aleatoriedad;
y muchos más, incluido el nuestro que se describe a continuación.

Este problema se informó primero, luego se magnificó por el discurso de las redes sociales y los usuarios que daban por sentado todas las palabras dadas por los desarrolladores (es decir, la concurrencia es un problema y actualmente solo puede ejecutar una transacción por bloque), luego se retiró por los maximalistas de Ethereum, y finalmente explotó en Twitter. Un verdadero crapfest por el que podemos agradecer a un molino de agua de incompetencia diabólica que mágicamente vierte agua sobre sí mismo desafiando todas las leyes de la entropía, pero bienvenido a Internet.

La simple verdad es que EUTxO es un modelo novedoso de concurrencia y blockchain. Es un nuevo matrimonio, y debido a que es un nuevo matrimonio, necesitamos pioneros que piensen en soluciones y se basen en el trabajo de los demás para llegar a un conjunto de patrones de diseño y bibliotecas estándar. No es nada nuevo, así es como ha funcionado el mundo de la ingeniería desde la época de las cintas perforadas.

Sin embargo, nos damos cuenta de la angustia de la comunidad no técnica y de la curiosidad de los técnicos sobre cómo las diferentes plataformas abordarán el problema. Entonces entregaremos un informe completo, que se puede ver a continuación.

Swaps programables

Antes de entrar en la discusión detallada de cómo abordamos la concurrencia y el límite de memoria, describamos cómo funciona nuestro DEX.

Maladex es un proyecto que no solo tiene como objetivo construir un intercambio descentralizado capaz de intercambio simple de activos en tiempo real, sino que tiene como objetivo introducir una serie de conceptos novedosos como la escritura y ejecución de estrategias comerciales, índices, derivados, sintéticos, estructuras de opciones y inversión activa similar a la forma en que los fondos de cobertura generan rendimientos.

El concepto central de la estrategia anterior es la creación de un marco que permite a los usuarios especificar estrategias comerciales que luego se pueden ejecutar automáticamente. Esto cambia el juego a medida que avanza el comercio descentralizado porque, por primera vez, cualquiera puede diseñar una solución que ejecutará órdenes complejas sin que el usuario tenga que monitorear el intercambio en todo momento o desarrollar sus propias soluciones que interactúan con los protocolos de blockchain.

Entonces, dicho esto, podemos presentar nuestros intercambios programables.

Un swap programable es un conjunto de activadores en los que deben ocurrir transacciones y fondos para dichas transacciones.

Los intercambios programables permiten las siguientes acciones y muchas otras:

proporcionar liquidez utilizando cualquier fórmula de curva de liquidez (incluyendo x * y = constante) dentro de cualquier rango (esta es una extensión de UniSwap v3 por sí sola con la capacidad de especificar una curva de liquidez); Además, Maladex en el futuro le ayudará a elegir la curva de liquidez óptima;
establecer una orden de límite de compra / venta;
DCA (Dollar-Cost Average o promedio de costo en dólares) durante 30 días desde USD a Cardano cada día comprando una parte de ADA, o incluso ajustando las partes por ponderaciones según la dinámica de precios de ADA;
proporcionar liquidez cuando el precio de ADA / USD se mantenga estable, pero tan pronto como se mueva más allá del rango deseado, intercambie todos los USD por ADA;
Sembrar bots de arbitraje Maladex que explotan las ineficiencias de precios de los modelos utilizados por otros intercambios para aumentar las ganancias de los sembradores de bots de arbitraje y aumentar la eficiencia general del mercado y garantizar que Maladex refleje el verdadero precio de mercado, independientemente de TVL (Valor total bloqueado);
desarrollar estrategias avanzadas de negociación automatizada e incluso compartirlas con otras personas de la comunidad a través del reparto de beneficios (por ejemplo, compartir la estrategia con métricas de rendimiento publicadas y, por ejemplo, recaudar el 1% de todos los ingresos generados por la estrategia) conectando a los redactores de estrategias con el capital;
cubra dinámicamente su posición utilizando derivados / subyacentes / etc .;
y muchos más.

Finalmente, un modelo de intercambios programables permite extender el protocolo de negociación de Maladex sin necesidad de actualizaciones duras, básicamente permanece para siempre compatible con versiones anteriores.

Swaps programables y Mal

La razón por la que Mal parece un demonio se debe a los intercambios programables. Un Daemon en informática es un proceso en segundo plano que realiza tareas para el usuario, al igual que nuestros intercambios programables. Incluso se podría decir que cada intercambio programable es un demonio (o Mal). Como los swaps programables son los bloques de construcción subyacentes de todo en la plataforma Maladex, desde swaps, pasando por DCA, índices, sintéticos, desarrollo de estrategias e inversión activa, es justo que recibamos el nombre de Mal.

Solución de concurrencia Maladex

El protocolo de intercambio programable de Maladex se compone de 2 partes:

La fase de compromiso: envía el compromiso a la cadena de bloques para realizar una determinada acción; cada compromiso se puede cancelar enviando una orden de cancelación como otro intercambio programable; cada compromiso es un NFT y se puede producir en paralelo utilizando una política de acuñación;
La fase de ejecución: todos los compromisos se ejecutan en cada bloque entre sí, lo que resulta en operaciones. Debido a la alta fragmentación y al enrutamiento optimizado, las transacciones requieren mucha menos memoria y se pueden administrar de manera eficiente.

¿Cómo se almacenan los intercambios programables?

Maladex utiliza una política de acuñación para almacenar todos los intercambios programables como NFT en cadena. Cada NFT tiene datos que definen todos los disparadores. Publicar estos datos en cadena para que todos los vean y verifiquen.

La política de acuñación no sufre problemas de concurrencia y cualquiera puede enviar tantas órdenes de intercambio programables en cualquier momento como desee. Esto naturalmente conduce a la máxima concurrencia posible, es decir, donde todos los pedidos se pueden enviar sin un solo error. La única limitación aquí es el tamaño del límite de bloque de 65kB, aunque se aumentará en los próximos meses y no es un factor limitante para Maladex, ya que tenemos planes de escalar mucho más allá de cualquier límite activo (más sobre eso más adelante).

La ley de Amdahl representa el límite teórico de velocidad alcanzable en la cadena de bloques Cardano al aumentar la concurrencia.

Este enfoque ya garantiza 0 transacciones fallidas. Si MinSwap lanzara una red de prueba con este modelo, no habría sido posible que fallara ninguna transacción. En el peor de los casos, solo se ejecutarían secuencialmente una vez en la cadena.

Finalmente, como un buen detalle, planeamos en el futuro implementar recibos de transacciones en forma de NFT. Digamos que su DCA programable terminó de ejecutarse después de 30 días o su orden límite fue igualada, acuñaremos un NFT con el historial de su operación: las entradas, salidas y una visualización de la transacción para representar la operación como una imagen. Más allá del uso pragmático de información transparente y fácilmente disponible sobre cómo se ejecutó la operación, esos recibos de NFT pueden convertirse en objetos de colección en algún momento: la primera operación del token X, su mejor operación, etc.

Fase de ejecución

Los activadores son un conjunto de condiciones que deben cumplirse para que se ejecute la transacción:

la orden de mercado no tiene disparadores y se ejecutará al mejor precio de mercado disponible inmediatamente;
La orden de límite de venta requerirá que la relación de los otros activos sea L o superior;
La orden límite de compra requerirá que la relación del otro activo sea U o inferior;
DCA de USD a ADA durante 30 días requerirá que hayan transcurrido 24 horas desde la última actualización, que todavía queden días en 30 días y potencialmente cualquier otra condición;
El suministro de liquidez AMM requerirá que las órdenes igualadas estén dentro del rango en el que se proporciona la liquidez (por ejemplo, negociar ADA / USD entre $ 2 y 3 por ADA), etc.

Además, para cancelar cualquier pedido existente, se envía un nuevo compromiso con la prueba de propiedad de que el intercambio programable propiedad del usuario debe devolverse al usuario en su estado dado. Esto, además, mejora la escalabilidad ya que cada intercambio programable tendrá un solo propietario.

La fase de ejecución se gestiona como un conjunto de nodos a los que se aplica un planificador gráfico. Tiene una similitud agradable con el modelo de ejecución y la programación de gráficos de Apache Spark .

La ejecución ocurre en las siguientes etapas:

Se aplican todas las órdenes de cancelación y las órdenes activas que se han cancelado se eliminan de las fronteras.
Todos los disparadores de swaps programables se evalúan con un gráfico de disparadores compartidos (esta es solo una forma óptima de evaluar millones de disparadores al mismo tiempo) y se marcan como activos o inactivos.
Todos los disparadores activos forman lo que se llama una frontera activa: un conjunto de todos los nodos (intercambios programables) que son ejecutables en el bloque dado. Todos los disparadores inactivos, intercambios programables que no se pueden ejecutar en el bloque dado, forman una frontera inactiva y se pueden omitir de todos los cálculos en este bloque.
Un motor de coincidencia de órdenes de intercambio proporciona una programación óptima, a través de la construcción de gráficos de ejecución óptima (los nodos de gráficos son EUTxO y el flujo de datos de los bordes) de la ejecución de intercambio programable dadas las restricciones como el límite de memoria de transacciones, la equidad (por ejemplo, ejecutar órdenes de mercado en el orden de presentación ), ordenación inmutable (la ordenación no puede verse influenciada por ningún factor externo para evitar la ejecución anticipada, MEV, etc.). El motor de comparación de pedidos crea transacciones optimizadas para un bloque determinado y las envía en cadena.
On-chain realiza la validación de las órdenes enviadas para todos los factores desencadenantes y restricciones, lo que garantiza una ejecución sin confianza. El bloque anterior comprometía intercambios programables para hacerse visibles en el siguiente bloque, los resultados de las transacciones anteriores producen nuevos intercambios programables (nodos), algunos intercambios se activan, algunos se vuelven inactivos. El ciclo se repite.

Fronteras

Para aumentar aún más la eficiencia de la solución de programación de gráficos, presentamos el concepto de

frontera activa: todos los intercambios programables activos (todos los activadores) activos en el bloque dado;
frontera inactiva: todos los intercambios programables con al menos un disparador inactivo.

Este enfoque para la programación de gráficos aumenta significativamente la eficiencia de los algoritmos de enrutamiento y hace que el estado de transición entre bloques sea más rápido.

Finalmente, los propios disparadores forman un gráfico desde la activación (disparadores) hasta la ejecución del estado. Esto es muy similar a las redes de Petri y por una razón debido a la similitud inherente entre el modelo eUTxO y el bloqueo de los eUTxO requeridos para la transición de estado y la transición de estado en sí.

Fuera de la cadena vs en la cadena

Una propiedad de la que no se habla con suficiente profundidad es el hecho de que cualquier blockchain requiere un componente fuera de la cadena. En el caso de los modelos clásicos basados en cuentas como Ethereum, alguien necesita proporcionar datos al contrato inteligente, estos datos se preparan fuera de la cadena, luego el usuario los aprueba en la billetera confiable y se envían a la cadena de bloques para su ejecución.

Cardano simplemente formaliza este concepto permitiendo una información mínima requerida en la cadena, es decir, validadores que brindan todas las garantías típicas y en las que los desarrolladores DEX deben especificar las propiedades de equidad y confianza.

Fuera de la cadena es una parte integral de Cardano y permite la formación eficiente de transacciones. Independientemente de lo que se especifique en el validador en cadena y de lo que se especifique en el código fuera de la cadena, siempre que los desarrolladores tengan acceso al código fuera de la cadena, cualquiera puede interactuar con el protocolo.

Creemos que los modelos propuestos por ErgoDex no son inherentemente defectuosos, solo requieren un escrutinio adicional en el código de validación en cadena de código abierto y la verificación de que los hashes en cadena corresponden a los scripts fuera de cadena.

Por lo tanto, no es sorprendente que cada DEX tenga un componente de enrutamiento fuera de la cadena. Cualquier otra solución requeriría que la comunidad desarrolle su propio software de enrutamiento que cumpla con las condiciones establecidas en los validadores en cadena y proporcione enrutamiento para las transacciones DEX a través de un mecanismo de recompensa.

Motor de ejecución fuera de cadena

Cualquiera puede ejecutar un motor de ejecución fuera de la cadena

DEX tiene un incentivo para ejecutarlo de forma gratuita, ya que ya cobra una pequeña tarifa porcentual de todas las transacciones (similar al 0,1–0,3%);
Cualquiera puede ejecutar el motor de ejecución DEX dado su código abierto provisto junto con cualquier nodo Cardano (por ejemplo, junto con el relay).

Maladex ejecutará múltiples instancias auto-escalables del motor de enrutamiento y coincidencia de pedidos en Kubernetes y proporcionará el motor de código abierto para que se ejecute cualquier SPO (operador de stake pool).

El nodo Cardano en el siguiente ejemplo es un nodo actualizado que puede transmitir transacciones a la cadena de bloques. Un ejemplo de tal nodo es un relay. Una parte de las tarifas DEX se asignará para la ejecución de la orden, lo que proporcionará la descentralización del componente DEX de enrutamiento.

Además, ejecutar estos motores de ejecución fuera de la cadena con la ayuda de la comunidad no solo aumenta la descentralización de DEX (ahora está dirigido por un grupo distribuido de personas en lugar de enrutado por una entidad centralizada como en el caso de los DEX clásicos), sino que también conduce naturalmente al siguiente punto de este artículo, es decir, escalar más allá de las limitaciones de la memoria de bloques y transacciones, y aumentar la velocidad de ejecución de las transacciones, a través de cabezales de Hydra.

Solución de límite de memoria

Las transacciones de Cardano están limitadas a 16kB y los bloques a 65kB. Aunque Cardano planea ajustar los parámetros en respuesta a la carga de la red, es mejor pensar en términos de escalabilidad más allá de estas limitaciones típicas de blockchain.

Introduzcamos el concepto de escalar las capacidades de ejecución de DEX a través de cabezales de Hydra.

Cada SPO (operador de stake pool) que ejecute un relay Cardano y un motor de ejecución Maladex podrá unirse a un grupo de operadores que participen en la creación de cabezas de Hydra.

Una cabeza de Hydra es una solución de incrustación de capa 2 de Cardano isomorfa. Isomorfismo significa que no se requiere compilación entre diferentes formatos de código y uno puede enfocarse en escribir código Plutus.

La formación de cabezas de Hydra permitirá tiempos de bloqueo mucho más cortos dentro de la cabeza de Hydra, por ejemplo, produciendo bloque de capa 2 cada 1s y mayor límite de memoria. Cada estado de cabeza de Hydra de bloque de capa 1 se comprometerá con la cadena.

Como solo el estado final se devuelve a la capa 1, donde finalmente se valida y fusiona, sin historial, permite un escalado significativo de la velocidad de las transacciones y el límite de memoria. Una cabeza de Hydra de Maladex será capaz de ejecutar múltiples ciclos de bloque (por ejemplo, 20) durante un solo bloque de la capa 1 de Cardano y devolver el resultado de 20 bloques a la capa 1.

¿Necesitamos un modelo basado en cuentas para DEX?

MinSwap menciona en su artículo que creen que se requiere un modelo (ineficiente) basado en cuentas para el funcionamiento de DEX porque el estado debe estar centralizado para los modelos de liquidez AMM (creador de mercado automatizado).

Estamos completamente en desacuerdo con esto. En cualquier mercado, el precio actual y la liquidez es una propiedad emergente de las órdenes subyacentes. En los mercados clásicos, la liquidez se proporciona a través de órdenes limitadas en la cartera de pedidos, en los mercados descentralizados típicos se proporciona a través de fórmulas AMM, que se pueden centralizar completamente como en el caso de UniSwap v1 / v2 (y todos los proyectos que intentan imitar este modelo en Cardano como SundaeSwap, MinSwap, etc.) o muy fragmentado como en el caso de UniSwap v3.

Para que las órdenes se ejecuten, sólo se necesita información local, por ejemplo, para hacer coincidir una orden de venta limitada con una orden de compra límite correspondiente cuyos precios cruzan son necesarios. De manera similar, para que se ejecute la orden de mercado, solo necesitamos encontrar la orden de límite de precio más bajo o el fragmento de AMM que coincida (en el caso de Maladex AMM que da como resultado el mejor precio de ejecución).

Por lo tanto, el estado de liquidez global como en UniSwap v1 / v2 (y como lo proponen SundaeSwap o MinSwap) es completamente innecesario. Además, es muy indeseable, ya que conduce a un suministro de liquidez extremadamente ineficiente.

Los CFMM (creadores de mercado de fórmula constante) con liquidez global creen que es tan probable que compre pizza de 12" hoy por $ 20 como por ¢ 1 o $ 1B. Esto conduce a una ineficiencia de liquidez extrema y modelos de mercado poco realistas.

La fragmentación de la liquidez por sí sola, como es el caso de UniSwap v3, conduce a la aparición de un modelo de precios geométrico y, como resultado, a una reducción significativa de la pérdida no permanente (impermanent loss) y un aumento de la eficiencia del capital.

La alta eficiencia del capital significa que los precios de mercado se pueden representar de manera efectiva utilizando incluso un capital pequeño en los modelos AMM (creador de mercado automatizado) y la baja pérdida no permanente significa que los inversores no pierden fondos simplemente usando DEX.

Por lo tanto, Maladex no es solo el primer DEX de Cardano en proponer un modelo que elimina inherentemente la pérdida no permanente y aumenta significativamente la eficiencia del capital, sino el primer DEX que propone ambos. Creemos que este cambio de paradigma hará posible la transición de comerciantes e inversores de intercambios centralizados a intercambios descentralizados.

Una capa para escalar todas las DApps

La generalidad de Maladex propuso intercambios programables y el enfoque óptimo para la concurrencia, la eficiencia de la memoria debido a la fragmentación del estado y, finalmente, las cabezas de hydra significan que es una plataforma ideal para permitir el escalado de DApps. En el futuro, planeamos permitir que otras DApps se ejecuten a través de nuestro protocolo logrando automáticamente una alta concurrencia.

¿Por qué nuestro modelo es el mejor alcanzable?

Finalmente, analicemos por qué el modelo de intercambio propuesto por Maladex es el mejor posible (punto).

El modelo propuesto:

logra la máxima concurrencia según lo define la ley de Amdahl ;
aumenta el rendimiento de las transacciones más allá de las limitaciones de Cardano mediante el uso de cabezales de Hydra;
proporciona incentivos incorporados para la ejecución justa de órdenes;
permite la expresión sin confianza de tipos de órdenes más allá de la oferta actual de intercambios tanto centralizados como descentralizados, tanto nativos de blockchain como finanzas tradicionales;
permite la distribución del componente de enrutamiento, que clásicamente está centralizado por cada intercambio y la participación de la comunidad en el funcionamiento del intercambio;
está libre de pérdidas impermanentes y naturalmente conduce a una alta eficiencia de capital (que aumentaremos aún más a través de otras características de Maladex);
converge en el precio de mercado real (aumentando la eficiencia del mercado) y permitiendo que Maladex sea un Oracle del precio de mercado real para los activos nativos de Cardano.

Donde otros DEX brindan problemas de los que hablar, estamos listos para brindar soluciones para todos, e incluso aquellos de los que otros no se dan cuenta son problemas graves como la falta de ineficiencia de capital y una gran pérdida no permanente.