Polkadot y Ethereum 2.0 son protocolos de blockchains fragmentadas (sharded blockchain protocols). Como tales, proporcionan escalabilidad mediante la ejecución de transacciones en shards (fragmentos) separados y proporcionan un protocolo para enviar mensajes entre shards.
Modelo #
Todos los shards de Ethereum 2.0 tienen la misma función de transición de estado (STF), es decir, las reglas que gobiernan el cambio de estado de la blockchain en cada bloque. Esta STF proporciona una interfaz para la ejecución de smart contracts (contratos inteligentes). Los contratos existen en un solo shard y pueden enviar mensajes asincrónicos entre shards.
Del mismo modo, en Polkadot, cada shard alberga la lógica central, los shards se ejecutan en paralelo y Polkadot puede enviar mensajes asincrónicos entre shards. Sin embargo, cada shard de Polkadot (en la terminología de Polkadot, “parachain“) tiene un único STF. Las aplicaciones pueden existir dentro de un solo shard o a través de shards mediante la composición de la lógica. Polkadot utiliza WebAssembly (Wasm) como “meta-protocolo”. El STF de un shard puede ser abstracto siempre que los validadores de Polkadot puedan ejecutarlo dentro de un entorno Wasm. Polkadot apoyará los smart contracts a través de parachains. Para ofrecer algo de perspectiva, en Ethereum, los smart contracts pueden llamarse entre sí de forma sincrónica en el mismo shard y de forma asincrónica entre shards. En Polkadot, los smart contracts podrán llamarse mutuamente de forma sincrónica en la misma parachain y de forma asincrónica entre parachains.
Arquitectura #
Ethereum 2.0 #
La cadena principal de Ethereum 2.0 se llama Beacon Chain. La carga principal de la Beacon Chain son las attestations, que son votos sobre la disponibilidad de los datos de los shard y la validez de la Beacon Chain. Cada shard en Ethereum 2 es simplemente una blockchain con la interfaz Ethereum Wasm (eWasm).
Ethereum 2.0 lanzó la fase 0 de un despliegue multifase en diciembre de 2020, operando en paralelo a la cadena heredada de Ethereum 1.0:
- Fase 0 aprovisionó la Beacon Chain, aceptando depósitos de los validadores e implementando el consenso proof-of-stake, eventualmente entre muchos shards.
- Fase 1 lanza 64 shards como cadenas simples, para probar la finalidad de la Beacon Chain. Cada shard envía “enlaces cruzados” a la Beacon Chain, que contiene la información para finalizar los datos del shard.
- Fase 1.5 integra Eth 1 como un shard para finalizar los bloques de la cadena de proof of work (prueba de trabajo).
- Fase 2 implementa la interfaz de eWasm, eliminando progresivamente la proof of work, para finalmente hacer el sistema utilizable para los usuarios finales. [1]
Tras el lanzamiento de la Beacon Chain en la fase 0, la hoja de ruta se modificó para dar prioridad a la transición de la cadena heredada de Ethereum 1.0 de Proof-of-Work al consenso Proof-of-Stake de Ethereum 2.0, precediendo al rollout de shards en la red. [2]
La red también tendrá “side chains (cadenas laterales)” para interactuar con las cadenas que no están bajo el protocolo de finalidad de Ethereum 2.0.
Polkadot #
Al igual que Ethereum 2.0, Polkadot también tiene una cadena principal, llamada Relay Chain, con varios shards, llamadas parachains. Las parachains no están restringidas a una única interfaz como eWasm. En su lugar, pueden definir su propia lógica e interfaz, siempre y cuando proporcionen su STF a los validadores de la Relay Chain para que puedan ejecutarlo.
Polkadot, ahora activo como Relay Chain, sólo planea lanzar la capacidad de validar hasta 20 shards por bloque, escalando gradualmente hasta 100 shards por bloque. Además de las parachains, que se programan para su ejecución cada bloque, Polkadot también tiene parathreads, que se programan de forma dinámica. Esto permite que las cadenas compartan los slots de los shards, de forma parecida a como varias aerolíneas pequeñas podrían compartir una puerta de embarque en un aeropuerto.
Para interactuar con las cadenas que quieren utilizar su propio proceso de finalización (por ejemplo, Bitcoin), Polkadot tiene parachains puente que ofrecen compatibilidad bidireccional.
Consenso #
Tanto Ethereum 2.0 como Polkadot utilizan modelos de consenso híbridos en los que la producción de bloques y la finalidad tienen cada uno su propio protocolo. Los protocolos de finalidad – Casper FFG para Ethereum 2.0 y GRANDPA para Polkadot – están basados en GHOST y pueden finalizar lotes de bloques en una ronda. Para la producción de bloques, ambos protocolos utilizan protocolos basados en slots que asignan aleatoriamente validadores a un slot y proporcionan una regla de elección de fork (bifurcación) para los bloques no finalizados – RandDAO/LMD para Ethereum 2.0 y BABE para Polkadot.
Hay dos diferencias principales entre el consenso de Ethereum 2.0 y el de Polkadot:
1.- Ethereum 2.0 finaliza los lotes de bloques según períodos de tiempo llamados “epochs (épocas)”. El plan actual es tener 32 bloques por epoch y finalizarlos todos en una ronda. Con un tiempo de bloque previsto de 12 segundos, esto significa que el tiempo previsto para la finalidad es de 6 minutos (12 minutos como máximo). [3] El protocolo de finalidad de Polkadot, GRANDPA, finaliza lotes de bloques basándose en comprobaciones de disponibilidad y validez que se producen a medida que la cadena propuesta crece. El tiempo de finalización varía en función del número de comprobaciones que haya que realizar (y los informes de invalidez hacen que el protocolo requiera comprobaciones adicionales). El tiempo esperado hasta la finalidad es de 12 a 60 segundos.
2.0 Ethereum 2.0 requiere un gran número de validadores por shard para proporcionar fuertes garantías de validez. Polkadot puede ofrecer mayores garantías con menos validadores por shard. Polkadot lo consigue haciendo que los validadores distribuyan un código de borrado a todos los validadores del sistema, de forma que cualquiera -no sólo los validadores del shard- pueda reconstruir el bloque de una parachain y comprobar su validez. Las asignaciones aleatorias de validadores de parachain y las comprobaciones secundarias realizadas por validadores seleccionados al azar hacen imposible que el pequeño conjunto de validadores de cada parachain se confabule.
Mecánica del staking #
Ethereum 2.0 es una red proof-of-stake que requiere 32 ETH para hacer staking por cada instancia de validador. Los validadores tienen un nodo principal de la Beacon Chain y varios clientes validadores, uno por cada 32 ETH. Estos validadores son asignados a “comités”, que son grupos seleccionados al azar para validar shards en la red. Ethereum 2.0 se basa en tener un gran conjunto de validadores para proporcionar garantías de disponibilidad y validez: Necesitan al menos 111 validadores por shard para hacer funcionar la red y 256 validadores por shard para finalizar todos los shards en una epoch. Con 64 shards, son 16_384 validadores (dados 256 validadores por shard). [4][5]
Polkadot puede proporcionar fuertes garantías de finalidad y disponibilidad con muchos menos validadores. Polkadot utiliza Nominated Proof of Stake (NPoS) para seleccionar validadores de un conjunto más pequeño, permitiendo a los holders más pequeños nominar validadores para ejecutar la infraestructura mientras siguen reclamando las recompensas del sistema, sin ejecutar un nodo propio. Polkadot planea tener 1_000 validadores al final de su primer año de funcionamiento, y necesita unos diez validadores por cada parachain en la red.
Shards #
Cada shard en Ethereum 2.0 tiene el mismo STF. Cada shard enviará “enlaces cruzados” a la beacon chain e implementará un entorno de ejecución de eWasm. EWasm es un subconjunto restringido de Wasm para contratos en Ethereum. La interfaz eWasm proporciona un conjunto de métodos disponibles para los contratos. Debería haber un conjunto similar de herramientas de desarrollo como Truffle y Ganache para desarrollar para eWasm. [7]
Cada shard de Polkadot tiene un STF abstracto basado en Wasm. Cada shard puede exponer una interfaz personalizada, siempre que la lógica compile a Wasm y el shard proporcione una función de “ejecución de bloque” a los validadores de Polkadot. Polkadot cuenta con el framework de desarrollo Substrate que permite la composibilidad de todo el espectro con un conjunto de módulos que pueden ser configurados, compuestos y extendidos para desarrollar el STF de una cadena.
Paso de mensajes #
Los shards en Ethereum 2.0 tendrán acceso al estado de los demás a través de sus enlaces cruzados y pruebas de estado. En el modelo de Ethereum 2.0 con 64 shards, cada uno publica un enlace cruzado en la Beacon Chain para cada bloque, [4] lo que significa que los shards podrían contener lógica que se ejecuta en base a alguna light client proof de una transacción en otro shard. [8] Ethereum 2.0 no ha publicado una especificación para que los nodos pasen mensajes entre shards.
Polkadot utiliza el Cross Consensus Message Passing Format (Formato de Paso de Mensajes de Consenso Cruzado -XCM-) para que las parachains se envíen mensajes arbitrarios entre sí. Las parachains abren conexiones entre sí y pueden enviar mensajes a través de sus canales establecidos. Dado que los collators deberán ser también nodos completos de la Relay Chain, estarán conectados y podrán retransmitir mensajes de la parachain A a la parachain B. Los mensajes no pasan por la Relay Chain, sólo las proofs of post y las operaciones del canal (abrir, cerrar, etc.) van a la Relay Chain. Esto mejora la escalabilidad al mantener los datos en los límites del sistema.
Polkadot añadirá un protocolo llamado SPREE que proporciona una lógica compartida para los mensajes entre cadenas. Los mensajes enviados con SPREE conllevan garantías adicionales sobre la procedencia y la interpretación por parte de la cadena receptora.
Gobernanza #
La gobernanza de Ethereum 2.0 aún no está resuelta. Ethereum actualmente utiliza procedimientos de gobernanza off-chain (fuera de la cadena) como discusiones en GitHub, llamadas a All Core Devs y Ethereum Magicians para tomar decisiones sobre el protocolo. [9]
Polkadot utiliza la gobernanza on-chain con un sistema multicameral. Hay varias vías para emitir propuestas, por ejemplo, desde el Consejo on-chain, el Comité Técnico, o desde el público. Todas las propuestas pasan en última instancia por un referéndum público, en el que la mayoría de los tokens siempre puede controlar el resultado. Para los referendos de baja participación, Polkadot utiliza un sesgo de quórum adaptativo para establecer el umbral de aprobación. Los referendos pueden cubrir una variedad de temas, incluyendo la asignación de fondos de un Tesoro on-chain o la modificación del código de runtime subyacente de la cadena. Las decisiones se promulgan on-chain y son vinculantes y autónomas.
Actualizaciones #
Las actualizaciones en Ethereum 2.0 seguirán el procedimiento normal de hard-fork, requiriendo que los validadores actualicen sus nodos para implementar los cambios del protocolo.
Usando el meta-protocolo Wasm, Polkadot puede promulgar actualizaciones de la cadena y propuestas exitosas sin un hard fork. Cualquier cosa que esté dentro del STF, la cola de transacciones o los off-chain workers pueden ser actualizados sin bifurcar la cadena.
Conclusión #
Tanto Ethereum 2.0 como Polkadot utilizan un modelo de shards en el que las cadenas de shards (“shards” en Ethereum 2.0 y “parachains/parathreads” en Polkadot) están aseguradas por una cadena principal mediante la vinculación del estado de los shards en los bloques de las cadenas principales. Los dos protocolos difieren en algunas áreas principales. En primer lugar, todos los shards de Ethereum 2.0 tienen el mismo STF, mientras que Polkadot permite que los shards tengan un STF abstracto. En segundo lugar, los procesos de gobernanza en Ethereum 2.0 están planeados para estar off-chain y por lo tanto requieren la coordinación de un hard fork para promulgar las decisiones de gobernanza, mientras que en Polkadot las decisiones están on-chain y se promulgan de forma autónoma. En tercer lugar, los mecanismos de selección de validadores son diferentes porque Polkadot puede proporcionar fuertes garantías de disponibilidad y validez con un menor número de validadores por shard.