Los Principios Detrás del Diseño del Protocolo: AMMs

En abril de 2021, se publicaron dos propuestas de borrador diferentes para creadores de mercado automáticos. Fue un evento raro — nunca ha habido múltiples propuestas para la misma característica redactadas al mismo tiempo — y demostró un interés generalizado en agregar AMMs a Stellar. Las dos propuestas diferían en algunas maneras clave, y esto inmediatamente expuso tensión entre dos metas competidoras. Primero, la versión inicial de creadores de mercado automáticos debería ser lo más simple posible. Segundo, los creadores de mercado automáticos deberían estar profundamente integrados en el protocolo de Stellar.

La meta de simplicidad suena, bueno, bastante simple. Pero simple significa diferentes cosas para diferentes personas. Desde mi perspectiva como implementador de stellar-core, un diseño simple es aquel que es más fácil de implementar y probar. Desde la perspectiva de las personas que construyen en Stellar, sin embargo, un diseño simple es aquel con el que es más fácil trabajar. Cuando un diseño es simple de ambas maneras, los usuarios se benefician al obtener acceso a productos de alta calidad rápidamente. Y en un mundo ideal, hay un diseño que satisface ambos deseos. Pero el mundo real es a menudo complicado.

Considera el siguiente concepto de diseño de alto nivel: los creadores de mercado automáticos son completamente independientes del intercambio descentralizado existente y hay un conjunto completamente nuevo de operaciones para interactuar con ellos. Este diseño habría sido relativamente simple de implementar, pero no habría estado profundamente integrado con el protocolo de Stellar. Definitivamente no habría sido simple de usar. Todos los que construyen en Stellar habrían tenido que decidir si querían comerciar solo con el intercambio descentralizado existente o solo con los creadores de mercado automáticos, creando un problema de coordinación no muy diferente al modelo de coco diamante. No hay razón para comerciar usando creadores de mercado automáticos si no hay liquidez allí, y no hay razón para proporcionar liquidez usando creadores de mercado automáticos si nadie está comerciando con ellos.

Claramente necesitábamos un diseño que aceptara cierta dificultad de implementación adicional a cambio de una mejor experiencia para los desarrolladores. La solución que encontramos fue permitir el comercio con creadores de mercado automáticos a través de un conjunto existente de operaciones de Stellar que combinan transferencia y conversión de moneda: pagos de ruta. Estas operaciones actualmente se pueden usar para comerciar con el intercambio descentralizado, y aumentarlas para permitir también el comercio contra AMMs significa que los desarrolladores que aprovechan la liquidez en cadena no necesitan cambiar sus aplicaciones en absoluto para aprovechar los fondos de liquidez. El protocolo puede elegir por ellos si es mejor comerciar con el intercambio descentralizado o con los creadores de mercado automáticos; este proceso se conoce como “enrutamiento”. Cambiar los pagos de ruta de esta manera evita completamente el problema de coordinación mencionado anteriormente, y todos se benefician automáticamente de mejores precios. Estas son algunas de las ventajas clave de integrar profundamente los creadores de mercado automáticos en el protocolo.

¿Problema resuelto? No del todo. Todavía estaba el asunto complicado de determinar cómo el protocolo enrutaría los comercios. Como mencioné anteriormente, había dos propuestas diferentes de AMM, y la mayor diferencia entre ellas era sus métodos para enrutar los comercios. La propuesta original para creadores de mercado automáticos sugería lo que más tarde llamaríamos ejecución “entrelazada”. En este modelo, el protocolo entrelazaría los comercios con el creador de mercado automático y los comercios con el libro de órdenes. El entrelazado siempre produce los mejores precios posibles, pero es más complicado de implementar. La segunda propuesta sugería lo que más tarde llamaríamos ejecución de “mejor lugar”. En este modelo, el protocolo comerciaría toda la cantidad con el cambio descentralizado o toda la cantidad con el libro de órdenes. Ejecutar contra un solo lugar es más simple de implementar, pero no hay garantía de que produzca los mejores precios posibles. Para la ejecución de mejor lugar, el enrutamiento se hace en base a una conversión por vez. Por ejemplo, un pago de ruta usando la ruta A → B → C podría enrutar la conversión A → B al libro de órdenes y la conversión B → C al creador de mercado automático.

La clave realización fue que el mecanismo de enrutamiento no impactaba la complejidad para los desarrolladores. Los desarrolladores no pueden elegir el mecanismo de enrutamiento, está abstracto para ellos como un detalle manejado útilmente por el protocolo. Esto nos da la libertad de mejorar el mecanismo de enrutamiento sin interrupción para los desarrolladores: a nadie le molesta cuando sus usuarios comienzan a obtener mejores tasas de cambio. Al final, decidimos implementar primero la ejecución de mejor lugar porque nos permitiría lanzar creadores de mercado automáticos más pronto. De esta manera, podemos comenzar a aprender qué quieren realmente los desarrolladores y usuarios de los creadores de mercado automáticos en Stellar y cómo difiere la utilización de aquellos en otras blockchains.

Al diseñar el protocolo de Stellar, nos enfrentamos a decisiones difíciles sobre cuándo la complejidad está justificada y qué partes asumirán el costo de ella. Manejamos estas decisiones caso por caso, buscando buenos resultados para desarrolladores y usuarios. Pero siempre tratamos de dejar la puerta abierta a mejoras adicionales. Siguiendo este enfoque, hemos sentado las bases para los creadores de mercado automáticos en Stellar. Ahora tenemos la oportunidad de construir sobre ella.

¿Tienes una idea? Involúcrate en stellar-protocol o únete a la lista de correo de stellar-dev para seguir la discusión!