Este artículo es una traducción de un artículo escrito por Matt Finestone sobre la descentralización de los rollups y el approach que Taiko está utilizando para lograr esto. Taiko es un ZK-rollup que prioriza la descentralización y ser Ethereum-equivalent (sobre esto, más adelante), recientemente lanzaron su testnet, así que si les interesa pueden ir explorándolo en su página.

Puntos por abordar:

• ¿Qué es un rollup descentralizado?

• ¿Cómo se descentraliza un rollup?

• ¿Cuáles son las ventajas y desventajas de un rollup descentralizado?

• El approach de Taiko: Eficiencia progresiva

• Implementación descentralizada y gobernanza descentralizada

• Cómo la descentralización es parte del Ethereum-equivalence (equivalente con Ethereum)

Puede que te sorprenda (o tal vez no) que existe cierto desacuerdo sobre qué vendría a ser un rollup descentralizado. Pero, de todos modos, una definición aceptada por la mayoría los considera como:

Un tipo de rollup donde cada usuario puede asegurar de que su transacción será procesada.

Uno se puede preguntar, ¿por qué necesitamos un rollup descentralizado? Al fin y al cabo la seguridad la suele garantizar una L1 como Ethereum ¿no?

Los rollups te aseguran de que mientras exista la L1 (capa de disponibilidad de data - data availability layer), el usuario pueda reconstruir el estado de la L2 y salirse del rollup forzando una transacción en la L1. Si el sistema no satisface este criterio, entonces no podríamos decir que esto es un rollup, probablemente sea un sidechain u otra cosa. Por esto mismo también es importante escoger una L1 que sea descentralizada (corra de manera ininterrumpida, sea censorship-resistant, etc.). Una matiz más por considerar para un rollup de propósito general, a diferencia de un rollup de aplicación específica, es que los usuarios deberían tener la capacidad de forzar la inclusión de cualquier transacción de manera arbitraria, no solo transacciones que están de ‘salida’.

Una vez que podemos confirmar que estamos hablando de un rollup, tenemos que precisar que lo que define a un rollup como “descentralizado” depende de qué tan costoso o fácil sería que un usuario pueda forzar la inclusión de su transacción. Por ejemplo, ¿necesitan mucho poder computacional para generar una prueba ZK? ¿O pueden usar hardware ordinario o alquilar un servidor barato por un período de tiempo corto? ¿Podría un actor privilegiado restringir la capacidad de que se incluya la transacción de un individuo por un plazo de 30 días? Cuanto menos prohibitivo, más descentralizado.

En realidad, es poco probable que un usuario quiera correr su propio nodo para un rollup, y en el caso de un ZK-rollup, el prover add-on. En cambio un usuario probablemente sí va a querer saber que el rollup con el cual está interactuando tenga una amplia y diversa base de participantes que realicen funciones necesarias. Y que nuevos participantes puedan unirse al network para realizar estas funciones, sin necesitar permiso (permissionlessly) - incluyendo ellos mismos si así lo desean.

Teniendo esto en cuenta, terminemos esta sección con otra definición de un rollup descentralizado que nos podría ayudar a mejorar nuestro entendimiento del tema:

Un rollup descentralizado es uno en el que varias partes pueden participar en cada posición de la red, es decir, como proposers, provers y node runners.

Esto nos lleva a la siguiente sección.

Dadas las definiciones brindadas previamente, particularmente la segunda, puedes apreciar que podemos descentralizar un rollup asegurando que todos los roles puedan ser realizados por distintas partes - idealmente, se trataría de un conjunto vasto y geográficamente diverso. Estos roles son:

• Proposers

• Provers

• Node runners

Antes de revisar cada rol, repasemos un punto mencionado en la sección anterior: los rollups, al ser una solución L2, deciden qué L1 van a escalar, o más precisamente, qué L1 desean usar para garantías de seguridad. Al decir “garantías de seguridad” nos referimos a depender en una L1 para consenso y la disponibilidad de datos (data availability). Ya que esto no es algo que el mismo rollup podría ajustar para ser más descentralizado, escoger una L1 suficientemente descentralizada es clave, y por esto mismo es que Taiko escoge Ethereum, por contar con las garantías de seguridad más robustas.

Ahora, sobre los otros roles.

Proposers Los proposers construyen bloques en los rollups de las transacciones de los usuarios en la L2 y los proponen a una L1. A veces estos son referidos como secuenciadores en otros rollups.

Estos deciden qué transacciones se incluyen en cada bloque y cómo ordenarlas. Claramente los proposers gozan de mucho poder ya que pueden lucrar de cada transacción y decidir cuáles excluir, por lo tanto tienen la capacidad de censurar ciertas transacciones, aplicaciones o usuarios.

Como mencionamos -> en un rollup descentralizado los usuarios deberían asumir que se incluyan todas las transacciones válidas.

Provers Los provers generan pruebas SNARK que afirman la validez de las transacciones y bloques en una L2 a partir de los bloques propuestos mencionados anteriormente.

Estos deciden qué bloque propuesto deberían convertir a un bloque verificado on-chain. Este decide cuando un bloque puede llegar a su estado de verificación on-chain, pero no cuáles transacciones van en un bloque o en qué orden llegan. Hasta que se llegue a este estado de verificación on-chain, el prover puede dejar pendientes ciertas transacciones que dependen de una prueba de validez, o dejar pendientes ciertos bloques que vendrían a estar verificados on-chain pero que están a la espera de que su bloque padre (es decir el bloque anterior) sea verificado.

Como mencionamos -> un rollup descentralizado debería permitir que todos los usuarios cuenten con una verificación de todas sus transacciones válidas.

Node runners Los node runners o ejecutores de nodos, cumplen la función de ejecutar transacciones a partir de datos on-chain (L1) para mantenerse sincronizados con el estado del rollup.

Los proposers y provers tienen que ejecutar nodos de rollup completos para cumplir con sus respectivos roles. Otros actores pueden ejecutar nodos, como por ejemplo, aquellos brindando servicios como exploradores de bloques (e.g. etherscan), proveedores de infraestructura, y usuarios que quieren mantenerse sincronizados con el estado del chain por cualquier motivo.

Como mencionamos -> un rollup descentralizado debería permitir que los usuarios esperen que se ejecuten todas sus transacciones válidas.

Al movernos en el espectro de la centralización vs descentralización nos encontramos ante algunos tradeoffs.

En esta sección, los pros y contras aplican tanto a los proposers como a los provers (que colectivamente denominaremos como operadores); dejaremos de lado a los node runners, pero se consciente de que ejecutar un nodo de un rollup es un requisito para ambos roles.

En el contexto de los proposers/provers de rollups, notamos lo siguiente:

El approach de la mayoría de rollups existentes ha sido uno de centralización primero, bajo la promesa de ir descentralizando progresivamente con el tiempo. Esto puede que tenga sentido, ya que todavía existe mucha incertidumbre, varias hipótesis que probar, y dentro de todo we’re still early. Contar con un proposer y prover centralizados (o sea un secuenciador y un validador en términos más amplios) hace que sea más sencillo asegurar el funcionamiento propio y eficiente del rollup. Esto se puede notar en la siguiente tabla:

En contraste, Taiko busca contar con un proposer y prover completamente descentralizado (y permissionless) desde el inicio. El protocolo no contará con filtros ni allowlists; todos podrán realizar aquellas tareas (de prover y proposer). Además, Taiko planea contar con esquemas de coordinación definidos a nivel protocolar mínimos para proposers/provers. La idea es que sea leaderless (sin líderes).

Todos los rollups terminan escogiendo el sweet spot que satisfaga las necesidades de sus usuarios. Este será distinto dependiendo de cada rollup, al igual que el sendero que escojan para llegar a este spot. Puedes empezar centralizado e ir cediendo el control, o puedes empezar descentralizado e ir implementando reglas de coordinación cada vez más rígidas (o inclusive ir delegando control). Es definitivamente posible que algunas de las desventajas de la descentralización resulten en impedimentos para el performance de la red, y si esto sucede Taiko tendrá que implementar medidas como esquemas para designar líderes para así evitar realizar tareas redundantes.

En este sentido, el approach de Taiko se puede considerar como eficiencia progresiva, en contraposición con la descentralización progresiva; pasando de completa descentralización y falta de estructuras, a un punto medio de ser necesitado.

Esto no significa que Taiko no va a contar con “training wheels” desde el inicio. Algunas medidas como permitir que los smart contracts sean upgradeable (actualizables), se mantendrán hasta asegurar el funcionamiento del protocolo. Esto es principalmente por un tema de seguridad: si los contratos no cuentan con un proxy-based upgradability entonces siempre existirá el peligro de que los usuarios pierdan sus tokens/assets por algún tipo de bug. El control sobre el upgradeability de los smart contracts será cedido a la DAO en algún momento.

Hace poco Vitalik escribió un artículo donde menciona que “una estructura de gobernanza descentralizada protege de los ataques internos, y una implementación descentralizada protege de los ataques externos.”. Esto lo dijo en el contexto de las DAOs - tanto sobre la estructura de gobernanza y la implementación. Específicamente se menciona un objetivo para la descentralización de una DAO: robustness.

Opinamos que sería bastante útil aplicar este concepto a los rollups y separar la “estructura de gobernanza” para referirnos a la DAO del rollup, y la “implementación” como la arquitectura misma del rollup.

Por lo tanto, hemos discutido cómo un rollup puede defenderse de amenazas externas (censura, liveness failure) con una implementación descentralizada. Pero no debemos dejar de lado cómo un rollup puede defenderse de amenazas internas - contra la organización y comunidad que inicialmente lo diseñó y actualmente mantiene. La herramienta para esto es la gobernanza, es decir, una DAO.

Respecto de la gobernanza, el approach de Taiko es similar al de otros rollups, y similar a la mayoría de proyectos que existen en Ethereum, de DeFi a infraestructura. Este approach es uno de descentralización progresiva: el control sobre el protocolo se va a ir reduciendo gradualmente, cediendo este a la comunidad, siendo específicos al Taiko DAO. Es muy temprano como para describir los detalles de la DAO y qué mecanismos de gobernanza se van a implementar, pero se tocará en otro artículo más adelante.

Un último comentario al respecto, ya para cerrar esta sección: vemos que la implementación ofrece un análisis en un momento específico sobre las propiedades del rollup, mientras la gobernanza puede describir como la implementación fue variando con el tiempo, y que partes tomaron esas decisiones.

En búsqueda de un Ethereum-equivalence puro, Takio valora altamente la priorizar la descentralización. Sería extraño tener dicho equivalence como objetivo, abarcando la EVM, hash functions, state y tx trees, etc., sin también connotar la equivalencia en la composición de la red.

Emular Ethereum para Taiko implica que todo se alinea hacia Ethereum: la ZK-EVM, otra arquitectura del base layer de Ethereum, consideraciones filosóficas (ethos), comunidad y vibes. Esto se extiende a la descentralización de la red y las propiedades principales que le brinda a desarrolladores y usuarios: censorship-resistance y liveness.

Como bien se menciona en el artículo, hoy en día la mayoría de rollups suelen optar por un approach de descentralización progresiva, lo cual puede que sea más eficiente cuando se empieza a desarrollar el rollup, pero siempre tendrá sus tradeoffs y desafortunadamente no suele existir un roadmap claro de cuándo se descentralizará el protocolo más allá de la gobernanza (tenemos rollups que ya cuentan con DAOs pero que siguen teniendo validadores/secuenciadores centralizados).

Esto, más el hecho de que la descentralización de por sí es un espectro, hace que algunos ignoren su ausencia sea por complacencia o simplemente indiferencia, hasta que sea tarde. Por esto nos parece importante resaltar el approach de Taiko, no solo por ser disruptiva sino también por la importancia de priorizar la descentralización y de tomarla como punto de partida. Sea buena o no la idea, el tiempo lo dirá, pero definitivamente será interesante ver cómo se desarrolla.

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y unite a la conversación en nuestra comunidad de Telegram!

https://twitter.com/Layer2es

https://t.me/l2espaniol

Con 💗 desde DeFi LATAM 🤝 DeFi para principiantes

Este artículo es una traducción de un artículo escrito por Matt Finestone sobre la descentralización de los rollups y el approach que Taiko está utilizando para lograr esto. Taiko es un ZK-rollup que prioriza la descentralización y ser Ethereum-equivalent (sobre esto, más adelante), recientemente lanzaron su testnet, así que si les interesa pueden ir explorándolo en su página.

Puntos por abordar:

• ¿Qué es un rollup descentralizado?

• ¿Cómo se descentraliza un rollup?

• ¿Cuáles son las ventajas y desventajas de un rollup descentralizado?

• El approach de Taiko: Eficiencia progresiva

• Implementación descentralizada y gobernanza descentralizada

• Cómo la descentralización es parte del Ethereum-equivalence (equivalente con Ethereum)

Puede que te sorprenda (o tal vez no) que existe cierto desacuerdo sobre qué vendría a ser un rollup descentralizado. Pero, de todos modos, una definición aceptada por la mayoría los considera como:

Un tipo de rollup donde cada usuario puede asegurar de que su transacción será procesada.

Uno se puede preguntar, ¿por qué necesitamos un rollup descentralizado? Al fin y al cabo la seguridad la suele garantizar una L1 como Ethereum ¿no?

Los rollups te aseguran de que mientras exista la L1 (capa de disponibilidad de data - data availability layer), el usuario pueda reconstruir el estado de la L2 y salirse del rollup forzando una transacción en la L1. Si el sistema no satisface este criterio, entonces no podríamos decir que esto es un rollup, probablemente sea un sidechain u otra cosa. Por esto mismo también es importante escoger una L1 que sea descentralizada (corra de manera ininterrumpida, sea censorship-resistant, etc.). Una matiz más por considerar para un rollup de propósito general, a diferencia de un rollup de aplicación específica, es que los usuarios deberían tener la capacidad de forzar la inclusión de cualquier transacción de manera arbitraria, no solo transacciones que están de ‘salida’.

Una vez que podemos confirmar que estamos hablando de un rollup, tenemos que precisar que lo que define a un rollup como “descentralizado” depende de qué tan costoso o fácil sería que un usuario pueda forzar la inclusión de su transacción. Por ejemplo, ¿necesitan mucho poder computacional para generar una prueba ZK? ¿O pueden usar hardware ordinario o alquilar un servidor barato por un período de tiempo corto? ¿Podría un actor privilegiado restringir la capacidad de que se incluya la transacción de un individuo por un plazo de 30 días? Cuanto menos prohibitivo, más descentralizado.

En realidad, es poco probable que un usuario quiera correr su propio nodo para un rollup, y en el caso de un ZK-rollup, el prover add-on. En cambio un usuario probablemente sí va a querer saber que el rollup con el cual está interactuando tenga una amplia y diversa base de participantes que realicen funciones necesarias. Y que nuevos participantes puedan unirse al network para realizar estas funciones, sin necesitar permiso (permissionlessly) - incluyendo ellos mismos si así lo desean.

Teniendo esto en cuenta, terminemos esta sección con otra definición de un rollup descentralizado que nos podría ayudar a mejorar nuestro entendimiento del tema:

Un rollup descentralizado es uno en el que varias partes pueden participar en cada posición de la red, es decir, como proposers, provers y node runners.

Esto nos lleva a la siguiente sección.

Dadas las definiciones brindadas previamente, particularmente la segunda, puedes apreciar que podemos descentralizar un rollup asegurando que todos los roles puedan ser realizados por distintas partes - idealmente, se trataría de un conjunto vasto y geográficamente diverso. Estos roles son:

• Proposers

• Provers

• Node runners

Antes de revisar cada rol, repasemos un punto mencionado en la sección anterior: los rollups, al ser una solución L2, deciden qué L1 van a escalar, o más precisamente, qué L1 desean usar para garantías de seguridad. Al decir “garantías de seguridad” nos referimos a depender en una L1 para consenso y la disponibilidad de datos (data availability). Ya que esto no es algo que el mismo rollup podría ajustar para ser más descentralizado, escoger una L1 suficientemente descentralizada es clave, y por esto mismo es que Taiko escoge Ethereum, por contar con las garantías de seguridad más robustas.

Ahora, sobre los otros roles.

Proposers Los proposers construyen bloques en los rollups de las transacciones de los usuarios en la L2 y los proponen a una L1. A veces estos son referidos como secuenciadores en otros rollups.

Estos deciden qué transacciones se incluyen en cada bloque y cómo ordenarlas. Claramente los proposers gozan de mucho poder ya que pueden lucrar de cada transacción y decidir cuáles excluir, por lo tanto tienen la capacidad de censurar ciertas transacciones, aplicaciones o usuarios.

Como mencionamos -> en un rollup descentralizado los usuarios deberían asumir que se incluyan todas las transacciones válidas.

Provers Los provers generan pruebas SNARK que afirman la validez de las transacciones y bloques en una L2 a partir de los bloques propuestos mencionados anteriormente.

Estos deciden qué bloque propuesto deberían convertir a un bloque verificado on-chain. Este decide cuando un bloque puede llegar a su estado de verificación on-chain, pero no cuáles transacciones van en un bloque o en qué orden llegan. Hasta que se llegue a este estado de verificación on-chain, el prover puede dejar pendientes ciertas transacciones que dependen de una prueba de validez, o dejar pendientes ciertos bloques que vendrían a estar verificados on-chain pero que están a la espera de que su bloque padre (es decir el bloque anterior) sea verificado.

Como mencionamos -> un rollup descentralizado debería permitir que todos los usuarios cuenten con una verificación de todas sus transacciones válidas.

Node runners Los node runners o ejecutores de nodos, cumplen la función de ejecutar transacciones a partir de datos on-chain (L1) para mantenerse sincronizados con el estado del rollup.

Los proposers y provers tienen que ejecutar nodos de rollup completos para cumplir con sus respectivos roles. Otros actores pueden ejecutar nodos, como por ejemplo, aquellos brindando servicios como exploradores de bloques (e.g. etherscan), proveedores de infraestructura, y usuarios que quieren mantenerse sincronizados con el estado del chain por cualquier motivo.

Como mencionamos -> un rollup descentralizado debería permitir que los usuarios esperen que se ejecuten todas sus transacciones válidas.

Al movernos en el espectro de la centralización vs descentralización nos encontramos ante algunos tradeoffs.

En esta sección, los pros y contras aplican tanto a los proposers como a los provers (que colectivamente denominaremos como operadores); dejaremos de lado a los node runners, pero se consciente de que ejecutar un nodo de un rollup es un requisito para ambos roles.

En el contexto de los proposers/provers de rollups, notamos lo siguiente:

El approach de la mayoría de rollups existentes ha sido uno de centralización primero, bajo la promesa de ir descentralizando progresivamente con el tiempo. Esto puede que tenga sentido, ya que todavía existe mucha incertidumbre, varias hipótesis que probar, y dentro de todo we’re still early. Contar con un proposer y prover centralizados (o sea un secuenciador y un validador en términos más amplios) hace que sea más sencillo asegurar el funcionamiento propio y eficiente del rollup. Esto se puede notar en la siguiente tabla:

En contraste, Taiko busca contar con un proposer y prover completamente descentralizado (y permissionless) desde el inicio. El protocolo no contará con filtros ni allowlists; todos podrán realizar aquellas tareas (de prover y proposer). Además, Taiko planea contar con esquemas de coordinación definidos a nivel protocolar mínimos para proposers/provers. La idea es que sea leaderless (sin líderes).

Todos los rollups terminan escogiendo el sweet spot que satisfaga las necesidades de sus usuarios. Este será distinto dependiendo de cada rollup, al igual que el sendero que escojan para llegar a este spot. Puedes empezar centralizado e ir cediendo el control, o puedes empezar descentralizado e ir implementando reglas de coordinación cada vez más rígidas (o inclusive ir delegando control). Es definitivamente posible que algunas de las desventajas de la descentralización resulten en impedimentos para el performance de la red, y si esto sucede Taiko tendrá que implementar medidas como esquemas para designar líderes para así evitar realizar tareas redundantes.

En este sentido, el approach de Taiko se puede considerar como eficiencia progresiva, en contraposición con la descentralización progresiva; pasando de completa descentralización y falta de estructuras, a un punto medio de ser necesitado.

Esto no significa que Taiko no va a contar con “training wheels” desde el inicio. Algunas medidas como permitir que los smart contracts sean upgradeable (actualizables), se mantendrán hasta asegurar el funcionamiento del protocolo. Esto es principalmente por un tema de seguridad: si los contratos no cuentan con un proxy-based upgradability entonces siempre existirá el peligro de que los usuarios pierdan sus tokens/assets por algún tipo de bug. El control sobre el upgradeability de los smart contracts será cedido a la DAO en algún momento.

Hace poco Vitalik escribió un artículo donde menciona que “una estructura de gobernanza descentralizada protege de los ataques internos, y una implementación descentralizada protege de los ataques externos.”. Esto lo dijo en el contexto de las DAOs - tanto sobre la estructura de gobernanza y la implementación. Específicamente se menciona un objetivo para la descentralización de una DAO: robustness.

Opinamos que sería bastante útil aplicar este concepto a los rollups y separar la “estructura de gobernanza” para referirnos a la DAO del rollup, y la “implementación” como la arquitectura misma del rollup.

Por lo tanto, hemos discutido cómo un rollup puede defenderse de amenazas externas (censura, liveness failure) con una implementación descentralizada. Pero no debemos dejar de lado cómo un rollup puede defenderse de amenazas internas - contra la organización y comunidad que inicialmente lo diseñó y actualmente mantiene. La herramienta para esto es la gobernanza, es decir, una DAO.

Respecto de la gobernanza, el approach de Taiko es similar al de otros rollups, y similar a la mayoría de proyectos que existen en Ethereum, de DeFi a infraestructura. Este approach es uno de descentralización progresiva: el control sobre el protocolo se va a ir reduciendo gradualmente, cediendo este a la comunidad, siendo específicos al Taiko DAO. Es muy temprano como para describir los detalles de la DAO y qué mecanismos de gobernanza se van a implementar, pero se tocará en otro artículo más adelante.

Un último comentario al respecto, ya para cerrar esta sección: vemos que la implementación ofrece un análisis en un momento específico sobre las propiedades del rollup, mientras la gobernanza puede describir como la implementación fue variando con el tiempo, y que partes tomaron esas decisiones.

En búsqueda de un Ethereum-equivalence puro, Takio valora altamente la priorizar la descentralización. Sería extraño tener dicho equivalence como objetivo, abarcando la EVM, hash functions, state y tx trees, etc., sin también connotar la equivalencia en la composición de la red.

Emular Ethereum para Taiko implica que todo se alinea hacia Ethereum: la ZK-EVM, otra arquitectura del base layer de Ethereum, consideraciones filosóficas (ethos), comunidad y vibes. Esto se extiende a la descentralización de la red y las propiedades principales que le brinda a desarrolladores y usuarios: censorship-resistance y liveness.

Como bien se menciona en el artículo, hoy en día la mayoría de rollups suelen optar por un approach de descentralización progresiva, lo cual puede que sea más eficiente cuando se empieza a desarrollar el rollup, pero siempre tendrá sus tradeoffs y desafortunadamente no suele existir un roadmap claro de cuándo se descentralizará el protocolo más allá de la gobernanza (tenemos rollups que ya cuentan con DAOs pero que siguen teniendo validadores/secuenciadores centralizados).

Esto, más el hecho de que la descentralización de por sí es un espectro, hace que algunos ignoren su ausencia sea por complacencia o simplemente indiferencia, hasta que sea tarde. Por esto nos parece importante resaltar el approach de Taiko, no solo por ser disruptiva sino también por la importancia de priorizar la descentralización y de tomarla como punto de partida. Sea buena o no la idea, el tiempo lo dirá, pero definitivamente será interesante ver cómo se desarrolla.

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y unite a la conversación en nuestra comunidad de Telegram!

https://twitter.com/Layer2es

https://t.me/l2espaniol

Con 💗 desde DeFi LATAM 🤝 DeFi para principiantes