Secuenciadores compartidos para cadenas de aplicaciones Starknet y Madara

Introducción

Hoy en día ya estamos viendo proyectos que empiezan a experimentar con Madara para sus cadenas de aplicaciones. Pragma, Kakarot, Mangata Finance y Dojo son sólo algunos ejemplos. Mientras creamos en el futuro de múltiples cadenas y el poder del escalamiento de zk, solo veremos muchos más de estos proyectos en el futuro. Sin embargo, el creciente número de cadenas de aplicaciones también plantea dudas sobre

1. Descentralización
2. Componibilidad
3. Experiencia de desarrollo

En este post intentaré explicar los problemas que surgen por tener muchas cadenas de aplicaciones y también plantear una posible solución al problema que considero elegante y óptima para Madara y Starknet. Si ya conoce bien las cadenas de aplicaciones y la secuenciación compartida, no dude en pasar a la sección "Espera, es simplemente Polkadot de nuevo".

¿Qué sucede en las 100 cadenas de aplicaciones?

Digamos que estamos en un futuro en el que ahora tenemos 100 cadenas de aplicaciones diferentes que se instalan en Ethereum. Abordemos todos los problemas que esto causará.

Descentralización fragmentada

Cada cadena de aplicaciones deberá resolver la descentralización por sí sola. Ahora, la descentralización de las cadenas de aplicaciones no es tan necesaria como la de las L1, principalmente porque dependemos de las L1 para la seguridad. Sin embargo, todavía necesitamos la descentralización para garantizar la vivacidad, la resistencia a la censura y evitar ventajas monopólicas (tarifas elevadas, por ejemplo). Sin embargo, también es importante tener en cuenta que si cada cadena de aplicaciones resuelve la descentralización a su manera, esto conducirá muy rápidamente a la fragmentación de los conjuntos de validadores. Cada cadena de aplicaciones tendría que desarrollar incentivos económicos para incorporar nuevos validadores. Además, los validadores necesitarían seleccionar con qué clientes se sienten cómodos ejecutando. Sin mencionar la enorme barrera de entrada que esto crea para que los desarrolladores lancen sus propias cadenas de aplicaciones (en lugar de implementar un contrato inteligente que es solo una transacción).

Componibilidad

La componibilidad significa esencialmente interacción entre aplicaciones. En Ethereum o Starknet, esto simplemente significa llamar a otro contrato y todo lo demás lo maneja el propio protocolo. Sin embargo, con las cadenas de aplicaciones, esto se vuelve mucho más difícil. Las diferentes cadenas de aplicaciones tienen sus propios bloques y mecanismos de consenso. Cada vez que intenta interactuar con otra cadena de aplicaciones, debe examinar cuidadosamente el algoritmo de consenso y las garantías de finalidad y, en consecuencia, configurar un puente entre cadenas (directamente a la cadena o a través de L1). Si deseas interactuar con 10 cadenas de aplicaciones con diferentes diseños, deberás hacerlo 10 veces diferentes.

Experiencia de desarrollo

Resolver la descentralización y la unión no es fácil. Si este es un requisito para cada cadena de aplicaciones, será muy difícil para el desarrollador de contratos inteligentes habitual construir su propia cadena de aplicaciones. Además, a medida que cada cadena de aplicaciones intenta resolver estos problemas a su manera, pronto veremos diferentes estándares seguidos por diferentes cadenas, lo que hará aún más difícil unirse al ecosistema.

Los secuenciadores compartidos pueden resolver esto

Ahora bien, si sigues el espacio de la cadena de aplicaciones, es posible que hayas oído hablar del término "secuenciadores compartidos". Es la idea de tener un conjunto común de validadores para todas las cadenas que tienen como objetivo resolver los problemas mencionados anteriormente. Así es como funciona.

Descentralización compartida

La esencia misma de los secuenciadores compartidos es que no es necesario tener un conjunto diferente de validadores para cada cadena de aplicaciones o L2. En cambio, puede tener un conjunto de validadores realmente eficiente y descentralizado que secuencian los bloques para todas las cadenas. Imagine bloques que contienen transacciones de 100 cadenas de aplicaciones diferentes. Podrías estar pensando que esto realmente va a inflar el secuenciador, ya que necesitas poder manejar motores de ejecución para cada cadena de aplicaciones.

Bueno, ¡no lo haces!

Dado que hoy en día casi todos los secuenciadores están centralizados, se piensa en el secuenciador como una única aplicación que recopila transacciones, las ordena, las ejecuta y publica los resultados en la L1. Sin embargo, estos trabajos se pueden separar en múltiples componentes modulares. Por el bien de esta explicación, los dividiré en dos.

1. Motor de pedidos: Se encarga de secuenciar las transacciones en un orden específico. Una vez que el motor de pedidos haya decidido este orden, DEBE seguirse. Esto se aplica confirmando esta orden en L1 y obligando a los verificadores de L1 a verificar si las transacciones se ejecutaron en el orden requerido.
2. Motor de resumen: el motor de resumen es básicamente todo lo que hace el resumen: recopilar transacciones de los usuarios, ejecutarlas, crear pruebas y actualizar el estado en la L1. Idealmente, esto se puede dividir en más componentes, pero lo evitaríamos en esta publicación.

Aquí, el motor de pedidos es el secuenciador compartido y el motor de resumen es básicamente toda la lógica de resumen. Entonces el ciclo de vida de la transacción se ve así

Los secuenciadores compartidos básicamente ordenan transacciones en paquetes acumulativos y las envían a la L1. Por lo tanto, al descentralizar el conjunto de secuenciador compartido, ¡básicamente descentraliza todos los paquetes acumulativos vinculados a ese conjunto de secuenciador! Para tener una idea más detallada del funcionamiento de los secuenciadores compartidos, también puede consultar este sorprendente <a href="https://hackmd.io/@EspressoSystems/EspressoSequencer"> artículo 17 de Espresso.

Componibilidad

Uno de los principales problemas de la componibilidad es comprender cuándo finaliza la transacción en la otra cadena de aplicaciones y, en consecuencia, tomar medidas en su cadena. Pero con los secuenciadores compartidos, ambos paquetes acumulativos componibles comparten bloques entre sí. Entonces, si una transacción se revierte en el paquete B, todo el bloque se revierte y esto hace que la transacción en el paquete A también se revierta.

Ahora bien, esto seguramente suena más fácil decirlo que hacerlo. Para esto. la comunicación entre paquetes acumulativos debe ser eficiente y escalable. Los secuenciadores compartidos deben elaborar estándares adecuados sobre cómo se pueden comunicar los paquetes acumulativos, cómo deberían verse los mensajes entre cadenas, cómo lidiar con las actualizaciones de los paquetes acumulativos, etc. Si bien estos son problemas que tienen solución, son complicados y no fáciles de resolver.

Experiencia de desarrollador

Si bien los secuenciadores compartidos abstraen el aspecto de descentralización y facilitan la mensajería entre cadenas, todavía existen algunos estándares que cada cadena debe seguir para ser compatible con el secuenciador compartido. Por ejemplo, todas las transacciones acumuladas deben transformarse a un formato general que el secuenciador comprenda. De manera similar, los bloques del secuenciador deben filtrarse para recuperar las transacciones relevantes. Para resolver esto, asumiría que los secuenciadores compartidos generarían marcos acumulativos o SDK que abstraen el código repetitivo y exponen solo la parte de la lógica empresarial a los desarrolladores de la cadena de aplicaciones.

Aquí hay un diagrama de cómo se verán las cadenas de aplicaciones con secuenciadores compartidos.

Espera, es solo Polkadot otra vez.

Polkadot comenzó a trabajar en el futuro de múltiples cadenas mucho antes que Ethereum. De hecho, han estado trabajando en ello durante más de 5 años y si está familiarizado con Polkadot, habrá notado que el diseño anterior básicamente está reinventando muchas cosas que Polkadot ya ha hecho.

La cadena de relevo (descentralización compartida)

La cadena de relés es básicamente el motor de pedido + L1 en el diagrama de secuencia anterior. La cadena de relevos

1. Transacciones de pedidos en todas las paracaídas (acumulaciones)
2. Verifica las transacciones ejecutadas correctamente (en lugar de la verificación zk, en realidad vuelve a ejecutar el código de ejecución del paquete acumulativo para verificar las diferencias de estado)

Es posible que se haya dado cuenta de que el relé es básicamente el secuenciador compartido que comentamos anteriormente. Excepto por el hecho de que la cadena de retransmisión también necesita verificar la ejecución (ya que Polkadot es un L1), mientras que eso se lo dejamos a Ethereum.

XCM y XCMP

Mencionamos en la sección anterior que si cada cadena creara sus propios métodos para interoperar con otras cadenas, pronto estaríamos inundados de diferentes estándares y formatos en todas las cadenas. Deberá realizar un seguimiento de todos estos formatos para cada cadena con la que interactúe. Además, también deberá responder preguntas como ¿qué sucede si una cadena se actualiza? Sin embargo, estos problemas pueden abordarse elegantemente introduciendo estándares que todas las cadenas deben seguir.

Como habrás adivinado, Polkadot ya lo ha hecho. XCM es el formato de mensajería y XCMP es el protocolo de mensajería que todas las cadenas de sustrato pueden utilizar para comunicarse entre sí. No entraré en detalles, pero puedes leerlo aquí 5.

Sustrato y Cumulus

Substrate es un marco desarrollado por Parity que se puede utilizar para construir cadenas de bloques. Si bien todas las paracaídas de Polkadot usan sustrato, el sustrato en realidad se construye de manera independiente de la cadena. El marco abstrae todos los aspectos comunes de una cadena de bloques para que usted pueda concentrarse en la lógica de su aplicación. Como sabemos, Madara se basa en Substrate, al igual que Polkadot, Polygon Avail y muchos otros proyectos. Además, Cumulus es un middleware además de Substrate que le permite conectar su cadena a Polkadot.

Entonces, continuando con nuestra analogía como antes, se puede considerar Substrate y Cumulus como sustitutos de los marcos acumulativos que le permiten crear cadenas de aplicaciones y conectarlas a los secuenciadores compartidos.

Secuenciadores compartidos → Cadenas de retransmisión
Componibilidad → XCM y XCMP
Estructuras/pilas acumuladas → Sustrato y Cumulus

Entonces sí, ¡es prácticamente todo de nuevo! Aparte de esto, Polkadot y Parity cuentan con algunos de los equipos más experimentados y financiados que continúan construyendo Substrate y Polkadot para agregar más funciones y hacerlo más escalable. La tecnología ya ha sido probada durante años y cuenta con un montón de herramientas de desarrollo listas para usar.

¿Establecer Polkadot en Ethereum?

Si bien es cierto que Polkadot comenzó a construir el futuro de múltiples cadenas mucho antes que Ethereum, no se puede negar que a partir de hoy, Ethereum es la cadena de bloques más descentralizada y el lugar donde residen la mayoría de las aplicaciones y la liquidez. Sin embargo, ¿qué pasaría si hubiera una manera de incorporar toda la tecnología de Polkadot al ecosistema Ethereum?

¡Hay! De hecho, ya hemos empezado esto con Madara. Madara utiliza el marco Substrate para permitir que cualquiera pueda construir su propia solución L2/L3 basada en zk sobre Ethereum. Lo que necesitamos a continuación es la cadena de retransmisión de Polkadot en forma de secuenciador compartido. Básicamente, si podemos reutilizar la cadena de retransmisión de Polkadot pero

1. Elimine la parte de verificación ya que eso sucede en el L1 a través de pruebas zk
2. Confirmar el orden de las transacciones en la L1
3. Optimice los nodos y los algoritmos de consenso para admitir Tendermint/HotStuff

Podemos obtener secuenciadores compartidos como se mencionó anteriormente. Obviamente, es más fácil decirlo que hacerlo. Sin embargo, creo que este camino es más pragmático que reconstruir los secuenciadores, estándares y marcos desde cero. Polkadot ya ha resuelto muchos problemas de una manera independiente de la cadena que podemos tomar prestada para Ethereum. Como producto secundario obtenemos

1. Un conjunto activo de desarrolladores que continúan construyendo y educando al mundo sobre Substrate.
2. Un conjunto de herramientas para desarrolladores activo y una comunidad sólida
3. Muchas paracaídas activas también pueden optar por instalarse en Ethereum si así lo desean (vimos a Astar hacer lo mismo recientemente con Polygon CDK)

Conclusión

Mi idea principal al escribir esta publicación es abrir la discusión entre el ecosistema más amplio de Starknet y Ethereum. Siento que el modelo de secuenciación compartida desempeñará un papel importante en la descentralización no sólo de Starknet sino también de todas las cadenas de aplicaciones que consideren construir sobre él. Mientras tengamos confianza en la tesis de la cadena de aplicaciones y el escalamiento de zk, es inevitable un análisis exhaustivo del modelo de secuenciación compartida. Además, a medida que Madara avanza hacia la producción y Starknet ha comenzado su trabajo de descentralización, creo que ahora es importante abordar este tema. Por lo tanto, solicito a todos los que lean esto que dejen cualquier comentario o sugerencia que tengan sobre el tema. ¡Esperamos leer tus pensamientos!

Apéndice

Lunares contra Cosmos

Cosmos, al igual que Polkadot, lleva muchos años buscando un futuro de múltiples cadenas. Como resultado, se han realizado muchos desarrollos con Cosmos SDK e IBC y también vemos muchas cadenas de aplicaciones construidas sobre el ecosistema de Cosmos. Por lo tanto, es justo considerar también a Cosmos para este enfoque. Mi opinión personal sobre este tema es que Polkadot es más relevante ya que resuelve el problema de los secuenciadores compartidos, mientras que Cosmos requiere que cada cadena de aplicaciones cree su propio conjunto de validadores. Además, Substrate siempre se ha construido de manera independiente de la cadena para permitir a los desarrolladores construir cadenas de bloques sin suposiciones sobre los algoritmos de consenso o el ecosistema de Polkadot. Esta es también la razón por la que elegimos Substrate para Madara. Sin embargo, dicho esto, mi experiencia en Cosmos es limitada y me encantaría escuchar más sobre esto de parte de personas más experimentadas. También puede encontrar más información sobre la comparación de las dos redes aquí.

Descargo de responsabilidad:

1. Este artículo se reimprime de [starknet]. Todos los derechos de autor pertenecen al autor original [apoorvsadana]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.