Precio de Dymension (DYM)

DYM es el activo nativo de la capa de liquidación de Dymension. El objetivo de diseño de Dymension es proporcionar infraestructura de liquidación e interoperabilidad para rollups específicos de aplicaciones denominados RollApps; por tanto, DYM está relacionado con la participación en la seguridad de esa capa de liquidación y con el diseño económico del protocolo, y no es necesariamente el token nativo de un RollApp individual.

Un RollApp es un entorno de ejecución independiente asignado a una aplicación concreta: procesa las transacciones y transiciones de estado de esa aplicación, en lugar de competir con todas las aplicaciones por los recursos de ejecución de una misma cadena. Dymension trata estos rollups específicos de aplicaciones como instancias desplegables, para que las aplicaciones mantengan su propia lógica y diseño de comisiones mientras se conectan a la capa de liquidación. Esta división de «ejecución independiente, liquidación compartida» no significa que el RollApp asuma por sí mismo todas las responsabilidades de seguridad. El Litepaper describe el RollApp como una instancia de ejecución autónoma: puede tener un token de comisiones nativo y lógica flexible, pero obtiene los servicios correspondientes mediante el marco de liquidación de Dymension.

Dymension separa la ejecución, la liquidación y la disponibilidad de datos en responsabilidades distintas. La capa de ejecución del RollApp procesa las transacciones; la capa de liquidación mantiene las raíces de estado, procesa disputas y establece puentes entre diferentes entornos; la capa de disponibilidad de datos garantiza que los datos publicados puedan obtenerse y verificarse. Por lo tanto, una actualización de estado no consiste solo en «completar una transacción en un RollApp». El resultado de la ejecución debe enviarse en una forma que la capa de liquidación pueda rastrear y disputar, y los datos relacionados también deben estar disponibles; el propósito de la arquitectura por capas es que las aplicaciones elijan soluciones de disponibilidad de datos según sus necesidades de seguridad y coste, en vez de concentrar todo el trabajo en una misma capa.

El secuenciador recibe, ordena y agrupa las transacciones de un RollApp, y luego forma actualizaciones de estado para su liquidación posterior. Según el diseño del Litepaper, las entidades que participan en la secuenciación deben hacer staking de DYM y delegarlo a validadores de la capa de liquidación; en el modo de secuenciación descentralizada, la cantidad relativa en staking afecta la oportunidad de obtener períodos de secuenciación. Aquí el staking no es simplemente una tarifa de uso. Vincula la elegibilidad para secuenciar con una garantía que puede estar sujeta a restricciones: si una actualización enviada por un secuenciador se demuestra errónea en una disputa, la garantía relacionada puede ser reducida. La implementación concreta de la secuenciación y los parámetros operativos siguen dependiendo del RollApp correspondiente y de la implementación del protocolo.

No necesariamente. Los RollApps tienen autonomía de comisiones y las aplicaciones pueden establecer sus tarifas de red en DYM, el token nativo de ese RollApp, una stablecoin u otros activos; lo que los usuarios pagan realmente depende de las reglas de comisiones adoptadas por ese RollApp. Esto es distinto del papel de DYM en el diseño de seguridad de la capa de liquidación: DYM puede utilizarse en acuerdos de staking relacionados con la participación en la capa de liquidación, pero el Litepaper no establece como regla general que «cada transacción de RollApp debe pagarse en DYM».

Dymension adopta un enfoque de disputas optimista: las actualizaciones de estado pueden enviarse primero, pero otros participantes pueden verificarlas durante el período de disputa. Si alguien presenta una impugnación válida, la capa de liquidación vuelve a ejecutar la transacción disputada en la máquina virtual RollApp (RVM) con el mismo contexto para obtener un resultado determinista. Si la reejecución demuestra que el estado enviado es incorrecto, el estado erróneo se revierte y la garantía del secuenciador malicioso puede ser reducida. La existencia del período de disputa deja una ventana para la verificación y la impugnación; también implica que la finalidad debe entenderse junto con este mecanismo, y no basarse solo en el primer envío del secuenciador.

IRC es un protocolo de comunicación entre RollApps basado en IBC. Utiliza el Hub de liquidación de Dymension al que se conectan en común los distintos RollApps para transmitir mensajes entre ellos, en lugar de exigir que cada par de aplicaciones establezca por separado una conexión de confianza independiente. Su importancia es que las aplicaciones pueden mantener sus respectivos entornos de ejecución y diseños de comisiones, mientras se comunican de manera verificable mediante una infraestructura de liquidación compartida. La existencia de IRC no significa que cualquier activo o aplicación sea automáticamente compatible; los mensajes y activos que realmente pueden transmitirse siguen dependiendo de la implementación de los RollApps pertinentes.

El Hub de liquidación de Dymension incorpora un creador de mercado automatizado (AMM), utilizado para proporcionar liquidez compartida sobre seguridad compartida. Se posiciona como infraestructura para los RollApps y puede admitir el enrutamiento de activos y el descubrimiento de precios, en lugar de ser simplemente un pool de negociación desplegado por una aplicación individual. La función del AMM es proporcionar una capa de liquidez común para las interacciones de activos de múltiples RollApps; sin embargo, el precio de negociación, el deslizamiento y la liquidez disponible siguen estando determinados por el estado concreto de los pools, y el AMM incorporado no garantiza por sí mismo la profundidad de intercambio ni el precio de ningún activo.