“La relación entre blockchain modular y blockchain única es complementaria y no conflictiva”.
Título original: “Coexistir el futuro de las plataformas de contratos inteligentes”
Escrito por: FF, equipo de investigación de LBank Labs
Compilado por: Sharon, BlockBeats
Nota del editor:
La cadena de bloques modular se ha convertido en una de las tendencias de desarrollo de 2024 identificadas por los miembros de la comunidad criptográfica, incluidas instituciones de inversión como a16z. Al mismo tiempo, la actualización de Ethereum Cancún es inminente y existen diversas opiniones sobre la tecnología blockchain modular y blockchain monolítica en la comunidad. LBank publicó recientemente un artículo dando su propia opinión al respecto. Después de comparar y analizar la arquitectura técnica subyacente de Ethereum 2.0 con Near y Polkadot, LBank cree que las cadenas de bloques modulares y las cadenas de bloques individuales no deben considerarse antagónicas, sino complementarias. , la cadena modular puede servir como elemento intermedio de la cadena de monómero, y la cadena de monómero puede servir como una capa específica de la cadena modular. Aprenden de las fortalezas y debilidades de los demás y se desarrollan juntos. BlockBeats compila el texto original de la siguiente manera:
##TL; DR
Este artículo es una continuación de nuestra investigación anterior titulada Oportunidades en narrativas modulares. En ese artículo, profundizamos en la ola modular impulsada por Ethereum y Celestia e identificamos las diversas oportunidades.
Es importante señalar, sin embargo, que las narrativas modulares no deberían limitar nuestra perspectiva. En los últimos años, la tecnología blockchain ha logrado avances significativos, con la aparición de arquitecturas blockchain monolíticas y modulares.
En este artículo, primero analizaremos estos dos enfoques arquitectónicos y compararemos Ethereum con otros competidores de Ethereum del ciclo anterior. Sorprendentemente, hay más similitudes entre ellos de lo que la gente piensa.
A continuación, exploraremos los desafíos y las consideraciones específicas asociadas con estos dos enfoques arquitectónicos mientras miramos hacia un futuro simbiótico para las plataformas de contratos inteligentes. En el pasado, el ecosistema blockchain estaba dominado por cadenas de bloques monolíticas, con cada nueva cadena de bloques L1 operando de forma independiente, lo que resultaba en una competencia feroz y una cooperación limitada en el mercado; sin embargo, ahora nos encontramos en una conectividad e interoperabilidad cadena a cadena entre las etapas. están más desarrollados que nunca. Por eso, preferimos las plataformas abiertas, ya sean modulares o monolíticas.
Todas las arquitecturas blockchain conducirán a la expansión
Esta sección proporciona una comparación detallada de las diferencias y similitudes entre Ethereum y otras cadenas de bloques monolíticas, destacando sus diferencias en el diseño arquitectónico. También analiza las diferencias entre el diseño modular y la arquitectura monolítica, así como los desafíos involucrados para lograr una verdadera escalabilidad.
Si bien Ethereum tiene un diseño modular, también utiliza la fragmentación como medio para lograr escalabilidad. La fragmentación permite que las transacciones y los datos se procesen en paralelo en varios fragmentos, lo que aumenta el rendimiento y la capacidad.
Sin embargo, la implementación de la fragmentación también conlleva su propio conjunto de desafíos, como garantizar la disponibilidad de los datos, la finalidad de las transacciones y facilitar las transacciones cruzadas. Superar estos desafíos requiere una consideración cuidadosa y soluciones innovadoras para integrar con éxito la fragmentación en una cadena de bloques monolítica. Ejemplos de fragmentación incluyen Ethereum, Near y Polkadot.
ETH 2.0 y cerca
El pasado del diseño Nightshade
La comparación de Ethereum 2.0 (ETH2.0) y Near Protocol se centra en las diferencias clave en sus enfoques. El enfoque de Ethereum implica fragmentación centrada en Rollup, donde las capas de ejecución y disponibilidad de datos están desacopladas. Esto aprovecha la L1 subyacente para proporcionar seguridad y consolidación para lograr escalabilidad.
Near decidió construir una red fragmentada desde el principio, considerando plenamente la existencia de fragmentación de datos y fragmentación de ejecución en su arquitectura incorporada. Esta es la primera diferencia clave. El diseño del método central Rollup de Ethereum es relativamente simple, pero aún requiere fragmentación de disponibilidad de datos (Danksharding) para permitir que L2 funcione de manera eficiente.
La segunda diferencia clave se explica claramente a continuación. En comparación con la cadena de balizas y la cadena de relés comunes, Near ha elegido una solución de fragmentación diferente. Cerca de sí mismo se divide en diferentes fragmentos, cada fragmento es responsable de generar y almacenar bloques como parte del bloque.
El diseño llamado “Nightshade” permite lograr una lectura y escritura de contratos inteligentes sin interrupciones entre fragmentos, aunque esto impone un umbral más alto para los desarrolladores. Los usuarios ni siquiera serán conscientes de los fragmentos con los que interactúan.
En la narrativa modular del artículo anterior, discutimos soluciones a los problemas de componibilidad e interoperabilidad. Sin embargo, esto no es un problema para Near porque su fragmentación incorporada esencialmente permite transacciones entre fragmentos, similares a las transacciones cruzadas en L2.
La hoja de ruta de Nightshade incluye las siguientes etapas:
- Etapa 0: Nightshade simple, solo un fragmento;
- Fase 1: productor de solo fragmentos (Nota del editor: se refiere a un productor que es el único responsable de generar bloques en un fragmento (una partición en la red));
- Fase 2: Full Nightshade, donde ningún validador rastrea todos los fragmentos;
- Fase 3: ajuste dinámicamente la cantidad de fragmentos según la carga.
En términos de progreso, Near se encuentra actualmente entre la Fase 1 y la Fase 2. El productor exclusivo de Chunk presentado el año pasado sólo puede rastrear el estado de un fragmento. Sin embargo, todavía existen validadores de nodos completos responsables de mantener el estado global.
Starsight en progreso: fragmentación centrada en ZK
Si bien Near lidera el diseño de fragmentación, también ha aprendido mucho de la revolución de Ethereum. Para lograr los objetivos de la Fase 2, ningún validador debe realizar un seguimiento de todos los fragmentos. En cambio, el “pescador” actúa como guardia de seguridad, monitoreando el estado y generando evidencia de fraude en las impugnaciones. El diseño central es muy similar al Optimistic Rollup, pero implementarlo por completo es complejo.
Por eso muchos protocolos están abandonando esta solución. Por ejemplo, Optimism ha pasado a una solución zk y Arbitrum no permite la presentación de pruebas de fraude sin licencia. Claramente, los zkRollups son el futuro de Ethereum. También podemos ver la influencia de zkRollups en el nuevo diseño de fragmentación de Near.
Verificación sin estado
¿Qué pasaría si hubiera una solución mejor para eliminar el desafío detrás del juego? Aquí es donde Near introduce la validación sin estado. La verificación sin estado genera verificación de estado sin entregar el estado a otros fragmentos. Con un testigo estatal, no hay necesidad de un “pescador” ni de pruebas de fraude.
En una configuración de validación sin estado, existen dos tipos de validadores. Los validadores de nodo completo anteriores ahora se cambian a validadores sin estado, mientras que los proponentes de bloques permanecen sin cambios. Los proponentes de bloques son responsables de generar bloques y testigos de estado, que necesitan mantener el estado del fragmento localmente.
Los validadores sin estado, por otro lado, reciben testigos de estado para verificar la transición de estado de cada bloque. Al introducir la rotación del validador, es casi imposible que un validador corrompa un fragmento.
La introducción de la validación sin estado trae muchos beneficios. El costo de ejecutar validadores sin estado es mucho menor que antes, lo que permite que más validadores se unan al consenso. Esto aumenta la descentralización de toda la red. Para los proponentes de bloques, a medida que se agregan más fragmentos, el estado de cada fragmento será más pequeño. Dado que el cuello de botella de la cadena de bloques es principalmente la lectura y escritura de estados, el rendimiento de un único fragmento se puede mejorar significativamente si el estado se mantiene completamente en la memoria.
La magia de las pruebas de conocimiento cero
Antes de la llegada de las pruebas de conocimiento cero (ZKP), tradicionalmente se utilizaban testigos estatales en MPT. Sin embargo, con la madurez y el reciente desarrollo de ZKP, muchos protocolos, incluido Near, han adoptado activamente esta transición. ZKP destaca por la simplicidad y las características de privacidad que ofrece, reduciendo significativamente el coste de la verificación de la transición de estado. Además de sus datos comprimidos, ZKP es pequeño y fácil de verificar. Al aprovechar las pruebas recursivas, el estado de todos los fragmentos se puede verificar colectivamente.
Una prueba de transición de estado para un fragmento consta de tres elementos básicos: garantizar la exactitud del hash del bloque, confirmar la precisión del estado utilizado durante la ejecución y verificar la ejecución en tiempo de ejecución. Actualmente, queda un desafío: a pesar de los importantes avances del año pasado, generar pruebas todavía lleva más tiempo de lo esperado.
Se espera que esto evolucione aún más a medida que continúen los esfuerzos para demostrar las capacidades de ingeniería y sistemas. Es por eso que Near se asoció con Polygon para construir zkWASM.
Para mantener la rápida certeza actual sin afectar la experiencia del usuario, Near ha realizado ajustes modulares. Starsight ha desacoplado el consenso y la ejecución, permitiendo que el consenso se ejecute de forma independiente y decida qué transacciones se incluirán en un bloque. Las llamadas a procedimientos remotos (RPC) proporcionan una finalidad optimista. Una vez que se genera una prueba para una transición de estado particular, se envía a un bloque y posteriormente un validador verifica la validez de la prueba.
Esta prueba actúa como confirmación de la nueva raíz del estado y de la nueva raíz del recibo saliente. En este caso, las pruebas de conocimiento cero funcionan como testigos estatales. Sin embargo, ZKP sólo puede confirmarse o rechazarse por consenso, lo que elimina la necesidad de rotación de validadores. ZKP garantiza corrección y seguridad a través de las matemáticas y funciona de manera muy similar a Rollup, que hereda las características de seguridad de Ethereum.
El diseño modular puede proporcionar beneficios adicionales en cadenas monolíticas. La flexibilidad de Starsight es que funciona no solo con el tiempo de ejecución Near WASM existente, sino también con cualquier tiempo de ejecución que pueda generar pruebas zk para transiciones de estado, como EVM y Move.
ETH 2.0 y Polkadot
Misma filosofía de diseño
Hay más similitudes entre Ethereum 2.0 y Polkadot de las que se esperaba inicialmente, una confirmación resaltada por las implementaciones comunes de Gavin Wood. Algunos incluso han sugerido que Polkadot representa el objetivo final de ETH 2.0 y, si bien esto no es del todo exacto, la analogía captura una verdad fundamental.
Desde nuestra perspectiva, Polkadot demuestra un mayor nivel de madurez en ingeniería. Antes de que existiera la prueba de conocimiento cero, la arquitectura centrada en Rollup de Ethereum estaba estrechamente integrada con el diseño de Polkadot. Una comparación directa de términos puede revelar sorprendentes similitudes en sus objetivos finales.
Cadena de baliza y cadena de relé
Como capa de coordinación, la cadena de baliza enfatiza la disponibilidad de datos de una manera centrada en el resumen; la cadena de retransmisión es responsable de la retransmisión de mensajes y el mantenimiento de los datos de la cadena paralela. La seguridad compartida proviene de la cadena de retransmisión y Ethereum se posiciona para heredar la seguridad. .sexo.
Acumulación y Parachain
Las cadenas paralelas son responsables de ejecutar transacciones, publicar datos en la cadena de retransmisión y personalizar sus propias transiciones de estado; Rollup ejecuta transacciones fuera de L1, luego publica datos en L1 y llega a un consenso.
Es evidente una filosofía de diseño consistente: mantener la capa base simple, mantener la disponibilidad de los datos, coordinar la información y aprovechar las capas superiores para mejorar completamente la funcionalidad y la escalabilidad.
Diferentes estrategias y ciclos conducen a diferentes resultados
A pesar de compartir las mismas filosofías de diseño y trabajar hacia objetivos comunes, el estado actual de las dos cadenas de bloques difiere dramáticamente. Según las estadísticas de Etherscan y Subscan, el volumen de transacciones diarias de Ethereum supera el millón, mientras que Polkadot tiene solo 12.000 en los últimos días. En cuanto a las cuentas activas diarias, vemos 395.000 en Ethereum y 8.000 en Polkadot.
La diferencia en su estatus actual se debe en gran medida a sus respectivas estrategias. Polkadot persigue la arquitectura definitiva y abandona deliberadamente la función de contrato inteligente. Los desarrolladores necesitan construir “palets” o módulos de cadena de aplicaciones, lo que supone una pesada carga para muchos. La combinación de estrategias agresivas y el alto umbral para las subastas de espacios dan como resultado un ecosistema que carece del dinamismo suficiente para compensar estos desafíos.
Por el contrario, Ethereum prioriza el mercado y pretende satisfacer sus necesidades. Ajusta su hoja de ruta en consecuencia, adoptando un enfoque paso a paso.
Si bien no profundizaremos en las razones específicas del auge de Ethereum y el declive de Polkadot, la comparación entre ETH 2.0 y Polkadot nos brinda información valiosa sobre el futuro de la arquitectura blockchain y el potencial de un ecosistema abierto y colaborativo.
Conceptos abstractos y estándares de excelencia.
A pesar de los desafíos que enfrenta actualmente, Polkadot tiene muchos diseños avanzados que vale la pena explorar y aprender.
Una contribución destacada del ecosistema de Polkadot es el marco subestado, que proporciona un excelente concepto de abstracción para las cadenas de aplicaciones. Este marco permite a las partes del proyecto lanzar fácilmente sus propias cadenas. Fuera del ecosistema de Polkadot, observamos que se construyen muchas cadenas activas en Substrate, incluidos proyectos como Polygon Avail y Starknet Madara, sin mencionar numerosas cadenas independientes.
Si bien las “paletas” pueden constituir una carga técnica para los desarrolladores de contratos inteligentes, proporcionan poderosas herramientas de abstracción para los desarrolladores de protocolos. Estas “paletas” se pueden reutilizar en todas las cadenas de Substrate, lo que ayuda a promover el consenso comunitario y los esfuerzos de estandarización. Esta característica permite la especialización y optimización para aplicaciones específicas.
Las tendencias actuales en Recursos como Servicio (RaaS), como OP stack y Polygon CDK, demuestran un cierto nivel de abstracción. Sin embargo, estas iniciativas, como los repositorios de código abierto, aún no son completas en comparación con Substrate. A medida que RaaS evoluciona, podemos esperar mayores mejoras en la personalización y disponibilidad de los módulos de la cadena.
La segunda característica distintiva de Polkadot es el paso de mensajes de consenso cruzado (XCMP), un protocolo de mensajería que permite a las paracaídas intercambiar mensajes arbitrarios sin pasar por la cadena de retransmisión. Esto significa que los contratos inteligentes pueden llamarse entre sí sin problemas dentro de la misma parachain, así como entre diferentes parachain.
Por el contrario, se requieren puentes de activos y cambios de red al interactuar con diferentes Rollups en Ethereum. Este proceso plantea desafíos como una liquidez fragmentada y una interoperabilidad rota. Para solucionar estos problemas, abogamos por que la Fundación Ethereum desempeñe un papel de liderazgo en el desarrollo de estándares y promueva activamente la aplicación de estos estándares en diversos Rollups. Este enfoque contribuirá significativamente al desarrollo futuro de Ethereum y sus ecosistemas relacionados para que sean más fluidos e interoperables.
El último gran avance para Polkadot es la implementación de un módulo de gobernanza en cadena, que efectivamente convierte a Polkadot en un verdadero metaprotocolo. Este módulo brinda a las partes interesadas el poder de votar directamente en la cadena y decidir el destino de las actualizaciones de la cadena. Una vez que se alcanza un umbral predeterminado, la cadena realizará actualizaciones de tiempo de ejecución de forma autónoma. Esto representa un cambio considerable con respecto al principal mecanismo de consenso social de Ethereum en la actualidad.
Retos por resolver
La comparación anterior muestra que, aunque existen diferencias sutiles, la esencia de las plataformas de contratos inteligentes sigue siendo básicamente la misma. Por lo tanto, tanto las cadenas de bloques monolíticas como las modulares enfrentan ciertos desafíos.
En esta sección, exploraremos dos desafíos comunes que enfrentan las plataformas de contratos inteligentes en su conjunto, antes de profundizar en cuestiones específicas relacionadas con las cadenas modulares.
Dilemas clave de la innovación
Uno de los principales desafíos que enfrentan las plataformas de contratos inteligentes es establecer un entorno competitivo e innovador. La popularidad de las soluciones L1 compatibles con EVM se ha vuelto algo monótona, incluso Vitalik Buterin las clasificó según su compatibilidad.
Si bien se reconoce la importancia histórica de los innovadores EVM y Solidity, también es fundamental reconocer que la tecnología ha evolucionado con el tiempo. Insistir en la naturaleza legal y tradicional del EVM puede limitar el progreso, especialmente frente a los límites de bloques de Ethereum.
El entusiasmo por las diferentes arquitecturas, máquinas virtuales (VM) y lenguajes de contratos inteligentes surge del deseo de escapar de las limitaciones de la EVM. La diversidad en estos aspectos atrae a desarrolladores y usuarios que prefieren utilizar diferentes lenguajes de programación y funciones de contratos inteligentes. Por ejemplo, en el mercado primario, Move VM (Aptos, Sui) y Cario VM (Starknet) han alcanzado valoraciones altas debido a las expectativas de innovación y posibilidades que aportan.
Al apostar por la próxima plataforma innovadora, se debe reconocer el dominio de la cuota de mercado de EVM. Pero a medida que el mercado madura, tiende a caer en un duopolio, siendo ejemplos Android e iOS y Windows y Mac.
WASM es un fuerte competidor de EVM, siendo Solana el actor más importante. A pesar de las críticas, las innovaciones clave de Solana, como el reloj de prueba de historial (POH), el control de concurrencia optimista (OCC) y el protocolo de reenvío de transacciones sin mempool, lo distinguen de otros protocolos y rompen con el límite tradicional del diseño de bloques.
Cómo construir un consenso amplio
El consenso aquí mencionado va más allá del estrecho nivel técnico e involucra el amplio campo del consenso social.
Desde una perspectiva de consenso, es comprensible que muchas L1 y L2 opten por la compatibilidad con EVM. Esta opción les proporciona la forma más sencilla de conectarse al ecosistema Ethereum. Sin embargo, a medida que aumenta el número de cadenas EVM y Rollups, la utilidad marginal decreciente tiende a atraer a desarrolladores y usuarios transitorios y desleales, que pueden irse rápidamente después de recibir lanzamientos aéreos.
Además de la compatibilidad con EVM, generar consenso mediante la reanudación proporciona otra narrativa convincente para involucrar a la comunidad existente. Construir desde cero se está volviendo cada vez más complejo, lo que subraya la importancia de elegir el activo de rehipotecación adecuado. Un punto sutil pero crítico es que suponiendo que todas las capas modulares utilicen derivados de seguridad L1 (LSD) para garantizar la seguridad, la diferencia entre una cadena de bloques monolítica y una cadena de bloques de bloques modulares se reduce.
Además, algunos protocolos extienden su influencia a un grupo más amplio de usuarios de Web2, especialmente en el campo de los juegos. Si bien este enfoque es eficaz, requiere un fuerte esfuerzo de desarrollo empresarial. Muchos actores tradicionales prefieren ampliar su base de usuarios como medio para lograr consenso en un entorno cambiante.
Problemas específicos con las cadenas modulares
Si bien las cadenas de bloques modulares distribuyen eficientemente las cargas de trabajo entre cadenas o módulos conectados, resolver desafíos específicos es fundamental para lograr una verdadera escalabilidad. Las principales preocupaciones con las cadenas modulares incluyen la fragmentación, la fragilidad, la ejecución cruzada y la centralización.
-
Fragmentación: La fragmentación resulta de una competencia feroz entre diferentes capas. Si bien es posible que los competidores actuales no colaboren de inmediato, se espera que la evolución de los protocolos universales y las abstracciones de cuentas brinden a los usuarios una experiencia perfecta en varios productos;
-
Vulnerabilidad: La vulnerabilidad resulta de diferentes supuestos de seguridad entre diferentes capas. En una cadena de bloques modular, cada módulo funciona de forma independiente, lo que introduce vulnerabilidades potenciales. Cuando una capa específica encuentra un problema, éste puede afectar a otras capas integradas, una compensación inherente al movimiento hacia la modularidad;
-
Ejecución cruzada: en la cadena de bloques modular, la ejecución cruzada es crucial para lograr la interoperabilidad de la cadena modular. La falta de protocolos estandarizados dificulta la integración perfecta entre diferentes módulos. Además, se deben abordar los problemas de ejecución asincrónica, inherentes a la fragmentación, para lograr una verdadera escalabilidad de las cadenas de bloques modulares;
-
Centralización: aunque la descentralización de Rollup puede no ser tan crítica como la descentralización de L1, sigue siendo un problema de seguridad importante. La descentralización es necesaria para garantizar la vitalidad, resistir la censura y evitar ventajas monopolísticas. El protocolo está trabajando activamente para resolver estos problemas a través de soluciones como ordenadores de fragmentos, código repetitivo abstracto y exposición de la lógica empresarial solo a los desarrolladores de cadenas. La adopción de estas soluciones puede ayudar a resolver problemas de ejecución cruzada.
Un futuro de colaboración e inclusión
Al examinar las dos partes anteriores, queda claro que las cadenas de bloques modulares y monolíticas representan productos de diferentes épocas, encarnan compensaciones en el triángulo imposible y reflejan diferentes opciones filosóficas.
Durante años, el espacio criptográfico ha estado atrapado en un ciclo de cadenas de bloques monolíticas, en el que cada nueva L1 construye un sistema cerrado, lo que genera una intensa competencia de suma cero. Este entorno a menudo conduce al extremismo cuando las plataformas compiten por los usuarios en sus ecosistemas.
El surgimiento de la cadena de bloques modular introduce un enfoque colaborativo e inclusivo que enfatiza la colaboración y la interconexión entre diferentes cadenas, un desarrollo positivo para toda la industria. Un enfoque colaborativo permite que los módulos funcionen juntos sin problemas, mejorando la funcionalidad general y la experiencia del usuario.
Además, la naturaleza colaborativa de la cadena de bloques modular facilita el desarrollo de módulos innovadores y especializados. La colaboración y el intercambio de recursos entre diferentes cadenas permiten a los desarrolladores centrarse en áreas específicas de especialización, lo que da como resultado módulos de alta calidad hechos a medida y adecuados para casos de uso específicos. Además, las rupturas de la cadena monolítica se pueden desacoplar y fusionar secuencialmente en capas modulares.
Es fundamental que las cadenas de bloques modulares y monolíticas no se consideren antagónicas, sino más bien complementarias. Aprenden de las fortalezas y debilidades de los demás y se desarrollan juntos. Los límites entre ellas pueden no ser obvios, ya que las cadenas modulares pueden actuar como middleware para cadenas monolíticas, mientras que las cadenas monolíticas pueden actuar como capas específicas de cadenas modulares.
En lugar de centrarse en distinciones categóricas, la atención debería centrarse en cultivar una red abierta, adoptar innovaciones clave y generar un amplio consenso.
Apéndice:
Introducción al formato de mensajes de consenso cruzado (XCM) · Polkadot Wiki
Polkadot: La base de una nueva Internet | de Jack Platts | Red Lunares | Medio
Sustrato: pila de tecnología Web3
El panorama de la pila OP | EN documentos de pila
OpenGov: ¿Qué es Polkadot Gov2? Red rayo de luna
NEARCON 2023 | Etapa de la capa 2: día 2: YouTube
Hoja de ruta de Ethereum | ethereum.org
Arquitectura con estado versus arquitectura sin estado: por qué ganó Stateless | Virtasante
NEAR—El funcionamiento de Blockchain | Documentación CERCA
Proveedores de implementación de Polygon CDK
El panorama de la pila OP
