Recientemente, Optimism, liderado por ETH Layer 2, y zkSync, Polygon, Arbitrum y StarkNet han lanzado sus propias soluciones Stack, todas con el objetivo de construir un conjunto de códigos modulares de código abierto que permitan a los desarrolladores personalizar su propia Capa 2.
Como todos sabemos, el Ethereum actual es conocido por su bajo rendimiento y alto nivel de Gas. La aparición de Capa 2 como OP y zkSync Era ha resuelto estos problemas. Sin embargo, ya sea que se implemente en una máquina virtual EVM o en la Capa 2, existe esencialmente un problema de "compatibilidad". Este no es solo el código subyacente de Dapp que debe ser compatible con EVM, sino también la soberanía de Dapp.
La primera parte es el nivel de código. Dado que EVM necesita encargarse de varios tipos de aplicaciones implementadas en él, se ha optimizado en el caso de usuario promedio para tener en cuenta todos los tipos de usuarios. Pero no es tan amigable con las Dapps implementadas en él. Por ejemplo, las aplicaciones Gamefi prestarán más atención a la velocidad y el rendimiento, mientras que los usuarios de Socialfi pueden prestar más atención a la privacidad y la seguridad. Sin embargo, debido a la naturaleza integral de EVM, Dapp debe renunciar a algo, que es la compatibilidad a nivel de código.
La segunda parte es el nivel de soberanía. Dado que todas las Dapps comparten infraestructura, han surgido dos conceptos: gobernanza de aplicaciones y gobernanza subyacente. La gobernanza de aplicaciones está sin duda sujeta a la gobernanza subyacente. Las necesidades específicas de algunas Dapps requieren una actualización a través del EVM subyacente. entonces Dapp carece de soberanía. Por ejemplo, las nuevas funciones de Uniswap V4 requieren que el EVM subyacente admita el almacenamiento transitorio y dependa de que EIP-1153 se agregue a la actualización de Cancún.
Para resolver los problemas de soberanía y bajo rendimiento de procesamiento de Ethereum L1 mencionados anteriormente, surgieron Cosmos (2019) y Polkadot (2020). Ambos esperan ayudar a desarrollar y construir sus propias cadenas personalizadas, permitiendo a las Dapps blockchain controlar la autonomía soberana, lograr una interoperabilidad entre cadenas de alto rendimiento y realizar una red de interoperabilidad de cadena completa.
Hoy, 4 años después, las L2 también lanzaron sus propias soluciones de red de hipervínculos, desde OP Stack, ZK Stack, Polygon 2.0, Arbitrum Orbit y finalmente StarkNet, para no quedarse atrás, lanzó el concepto Stack.
¿Qué tipo de colisiones y chispas ocurrirán entre el pionero de la red de cadena completa CP (Cosmos Polkadot) y los L2? Para brindarle una perspectiva integral y profunda, exploraremos este tema en profundidad a través de una serie de tres artículos. **Este artículo, como primer capítulo de esta serie, clasificará las soluciones técnicas de cada empresa, el segundo capítulo clasificará el modelo económico y la ecología de cada solución y resumirá las diferencias entre la Capa 1 y la Capa 1.2 Stack selecciona las características que deben considerarse. En el último capítulo, analizamos cómo Layer 2 desarrolla su propia supercadena y resumimos toda la serie de artículos. **
1. Cosmos
Cosmos es una red descentralizada de cadenas de bloques paralelas independientes. Al proporcionar un SDK de marco de desarrollo común, los desarrolladores pueden construir fácilmente sus propias cadenas de bloques, y múltiples cadenas de bloques independientes y diferentes de aplicaciones específicas pueden interactuar entre sí. Los enlaces se comunican entre sí, formando una red interoperable. y red de cadena completa escalable.
1. Marco estructural
Como se mencionó anteriormente, cuando hay cadenas de aplicaciones a gran escala en el ecosistema y cada cadena utiliza el protocolo IBC para comunicarse y transmitir tokens, toda la red será tan engorrosa y difícil de clasificar como una telaraña.
Entonces, para resolver este problema, Cosmos propuso una arquitectura en capas, que contiene dos tipos de blockchains: Hubs (cadena central) y Zones (cadena regional).
**Las zonas son cadenas de aplicaciones convencionales y los concentradores son cadenas de bloques especialmente diseñadas para conectar zonas entre sí, principalmente sirviendo de comunicación entre zonas. **Cuando una Zona crea una conexión IBC con el Hub, el Hub puede acceder automáticamente (es decir, enviar y recibir) a todas las Zonas conectadas a él. Esta estructura reduce en gran medida la complejidad de la comunicación.
Además, cabe señalar que Cosmos y Cosmos Hub son dos cosas completamente diferentes. Cosmos Hub es solo una de las cadenas que existen en el ecosistema de Cosmos y sirve principalmente como emisor y centro de comunicación de $ATOM. **Puedes entender Hub como el centro del ecosistema, pero en realidad cualquier cadena puede convertirse en un Hub. Si el Hub se convierte en el centro del ecosistema, esto es en realidad contrario a la intención original de Cosmos. ** Debido a que Cosmos está esencialmente comprometido con la autonomía de cada cadena y tiene soberanía absoluta, si el Hub se usa como centro de poder, entonces la soberanía ya no se llama soberanía. Entonces, al comprender Hub, debes prestar especial atención a este punto.
2. Tecnologías clave
2.1 IBC
IBC (Comunicación entre cadenas de bloques), que es comunicación entre cadenas, permite que cadenas heterogéneas transfieran tokens y datos entre sí. En el ecosistema Cosmos, el marco subyacente del SDK es el mismo y se debe utilizar el motor de consenso Tendermint. Sin embargo, todavía existe heterogeneidad, ya que las cadenas pueden tener diferentes funcionalidades, casos de uso y detalles de implementación dentro del marco.
Entonces, ¿cómo lograr la comunicación entre cadenas heterogéneas?
Sólo requiere una finalidad a nivel de consenso. Finalidad instantánea significa que siempre que más de 1/3 de los validadores sean correctos, el bloque no se bifurcará, lo que garantiza que la transacción sea definitiva una vez que se produzca el bloque. Independientemente de las diferencias en los casos de aplicación y el consenso entre cadenas heterogéneas, siempre que se garantice que sus niveles de consenso cumplan con la finalidad, la interoperabilidad entre cadenas estará determinada por reglas unificadas.
El siguiente es un proceso básico de comunicación entre cadenas. Supongamos que desea transferir 10 $ATOM de la cadena A a la cadena B:
Seguimiento: cada cadena ejecuta un nodo ligero de otras cadenas, por lo que cada cadena puede verificar otras cadenas.
Vinculación: primero bloquee 10 $ATOM en la cadena A para que los usuarios no puedan usarlos y envíe un certificado de bloqueo
Prueba de bloqueo (relé): hay un relé entre las cadenas AB para enviar prueba de bloqueo
Validación: Verificar los bloques de la cadena A en la cadena B. Si son correctos, se crearán 10 $ATOM en la cadena B.
En este momento, el $ATOM de la cadena B no es el $ATOM real, sino solo un certificado. El $ATOM bloqueado en la cadena A no se puede utilizar, pero el de la cadena B se puede utilizar normalmente. Cuando el usuario consume las credenciales en B, el $ATOM bloqueado en la cadena A también será destruido.
Sin embargo, el mayor desafío al que se enfrenta la comunicación entre cadenas no es cómo representar los datos de una cadena en otra, sino cómo manejar situaciones como bifurcaciones y reorganizaciones de cadenas.
Porque cada cadena en Cosmos es una cadena individual independiente y autónoma con su propio verificador dedicado. Por lo tanto, es muy probable que haya particiones que hagan el mal. Por ejemplo, si la cadena A transmite mensajes a la cadena B, entonces es necesario verificar los validadores de la cadena B con anticipación antes de decidir si confiar en la cadena.
Por ejemplo, supongamos que el pequeño punto rojo en la imagen representa un token ETM, y todos los usuarios en las tres particiones de ABC quieren usar EVMOS para ejecutar Dapps en las particiones, porque las transferencias de activos se llevan a cabo a través de comunicación entre cadenas. ETM.
Si la partición Ethermint lanza un ataque de doble gasto en este momento, la partición ABC sin duda se verá afectada, pero solo se limitará a esto. Las redes restantes no relacionadas con ETM no recibirán ningún ataque, esto también lo garantiza Cosmos. Incluso si se produce dicha transmisión de información maliciosa, no afectará a toda la red.
2.2 BFT de menta tierna
Cosmos utiliza Tendermint BFT como algoritmo de consenso subyacente y motor de consenso de Cosmos. Combina y empaqueta la infraestructura subyacente y la capa de consenso de la cadena de bloques en una solución de motor universal, y utiliza la tecnología ABCI para soportar la encapsulación de cualquier lenguaje de programación. la capa y la red de consenso subyacentes. **Por lo tanto, los desarrolladores son libres de elegir el idioma que deseen.
2.3 SDK de Cosmos
Cosmos SDK es un marco modular lanzado por Cosmos que simplifica la operación de creación de Dapps en la capa de consenso. Los desarrolladores pueden crear fácilmente aplicaciones/cadenas específicas sin tener que reescribir el código de cada módulo, lo que reduce en gran medida la presión de desarrollo y ahora permite a los desarrolladores portar aplicaciones implementadas en EVM a Cosmos.
Fuente:
Además, las cadenas de bloques creadas con Tendermint y Cosmos SDK también están creando nuevos ecosistemas y nuevas tecnologías que están liderando el desarrollo de la industria, como Nym, la cadena de privacidad, Celestia, que proporciona disponibilidad de datos, etc. Es precisamente gracias a la flexibilidad y facilidad de uso que proporciona Cosmos que los desarrolladores pueden centrarse en la innovación del proyecto sin tener que considerar la duplicación del trabajo.
2.4 Cuenta de seguridad entre cadenas
1) Seguridad entre cadenas
Debido a que Cosmos es diferente del ecosistema Ethereum, tiene L1 y L2. Cada cadena de aplicaciones en el ecosistema Cosmos es igual entre sí y no existe una relación progresiva o superior-inferior. Sin embargo, por esta razón, la seguridad entre cadenas no es tan completa como la de Ethereum. En Ethereum, Ethereum confirma la finalidad de todas las transacciones y hereda el valor subyacente. Pero para una cadena de bloques única que construya su propia seguridad, ¿cómo se debe mantener la seguridad?
Cosmos lanzó Interchain Security, que esencialmente permite la seguridad compartida al compartir una gran cantidad de nodos existentes. Por ejemplo, la cadena monolítica puede compartir un conjunto de nodos de verificación con Cosmos Hub para generar nuevos bloques para la cadena monolítica. Dado que los nodos sirven tanto a Cosmos Hub como a la cadena única, pueden recibir tarifas y recompensas de ambas cadenas.
Fuente:/tokenomics-dao/token-use-cases-part-1-atom-of-true-stake-token-5 fd 21 d 41161 e
Como se muestra en la figura, las transacciones generadas originalmente dentro de la cadena X son generadas por los nodos de X para su verificación. Si comparte un nodo con Cosmos Hub ($ATOM), las transacciones generadas originalmente en la cadena X serán verificadas y calculadas por los nodos de la cadena Hub para generar nuevos bloques para X.
Lógicamente, elegir una cadena relativamente madura con una gran cantidad de nodos, como la cadena Hub, es la primera opción para la seguridad compartida. Porque si quieren atacar una cadena de este tipo, los atacantes necesitan tener una gran cantidad de tokens $ATOM como prenda, lo que aumenta la dificultad del ataque.
No solo eso, el mecanismo de seguridad entre cadenas también reduce en gran medida las barreras para la creación de nuevas cadenas. En términos generales, si una nueva cadena no tiene recursos particularmente excelentes, es posible que deba dedicar mucho tiempo a atraer validadores y cultivar el ecosistema. Pero en Cosmos, debido a que los validadores se pueden compartir con la cadena Hub, esto reduce en gran medida la presión sobre la nueva cadena y acelera el proceso de desarrollo.
2) Cuenta entre cadenas
En el ecosistema Cosmos, debido a que cada cadena de aplicaciones se rige por sí misma, las aplicaciones no pueden acceder entre sí. Por lo tanto, Cosmos proporciona una cuenta entre cadenas que permite a los usuarios acceder directamente a todas las cadenas de Cosmos que admiten IBC desde Cosmos Hub, de modo que los usuarios puedan acceder a las aplicaciones de la cadena B en la cadena A para lograr una interacción de cadena completa.
2.Lunares
Al igual que Cosmos, Polkadot se compromete a construir una infraestructura que permita a los desarrolladores implementar libremente nuevas cadenas y lograr la interoperabilidad entre cadenas.
1. Marco estructural
1.1 Cadena de relevos:
La cadena de relevos también puede denominarse cadena principal, que puede entenderse como el Sol en el sistema solar. Como parte central de toda la red, todas las cadenas secundarias giran a su alrededor. Como se muestra en la figura, una cadena de retransmisión (Relay Chain) está vinculada a muchas cadenas con diferentes funciones, como cadena de transacciones, cadena de almacenamiento de archivos, cadena de Internet de las cosas, etc.
Fuente:/polkadot-network/polkadot-the-foundation-of-a-new-internet-e 8800 ec 81 c 7
Esta es la solución de expansión jerárquica de Polkadot: una cadena de retransmisión se conecta a otra cadena de retransmisión para lograr una escalabilidad ilimitada. (Nota: a finales de junio de este año, el fundador de Polkadot, Gavin, propuso Polkadot 2.0, que puede cambiar una nueva perspectiva sobre la comprensión de Polkadot).
1.2 Paracadena:
La cadena de retransmisión tiene varias ranuras Para-Chain y la parachain está conectada a la cadena de retransmisión a través de estas ranuras, como se muestra en la figura:
Fuente:om/cn/learn/slot-auction-cn
Sin embargo, para obtener un espacio, las paracaídas participantes deben apostar su $DOT. Una vez que se obtiene una ranura, la parachain puede interactuar con la red principal de Polkadot a través de esta ranura y compartir seguridad. Vale la pena mencionar que el número de espacios es limitado y aumentará gradualmente. Inicialmente se espera que admita 100 espacios, y los espacios se reorganizarán periódicamente y se asignarán de acuerdo con el mecanismo de gobernanza para mantener la actividad de la ecología parachain.
Las paracaídas que obtienen tragamonedas pueden disfrutar de la seguridad compartida y la liquidez entre cadenas del ecosistema de Polkadot. Al mismo tiempo, la cadena paralela también debe proporcionar a cambio ciertos beneficios y contribuciones a la red principal de Polkadot, como realizar la mayor parte del procesamiento de transacciones de la red.
1.3 Hilos paralelos:
Los parathreads son otro mecanismo de procesamiento similar a los parachains, la diferencia es que los parachains tienen ranuras una por una y ranuras dedicadas que pueden ejecutarse continuamente sin interrupción. Pero los subprocesos paralelos se refieren a compartir una ranura entre subprocesos paralelos y turnarse para usar esta ranura para ejecutarse. **
Cuando un hilo paralelo obtiene el derecho a usar la ranura, puede funcionar temporalmente como una parachain, procesando transacciones, generando bloques, etc. Pero cuando finaliza este período de tiempo, la ranura debe liberarse para que la utilicen otros subprocesos paralelos.
Por lo tanto, los hilos paralelos no necesitan hipotecar activos durante mucho tiempo, solo necesitan pagar una tarifa determinada al adquirirlos en cada período de tiempo, por lo que se puede decir que es un método de pago por uso para usar la ranura. Por supuesto, si un parathread recibe suficiente apoyo y votos, se puede actualizar a parachain y obtener una ranura fija.
En comparación con las paracaídas, los hilos paralelos tienen costos más bajos y reducen el umbral de entrada para Polkadot, pero no hay garantía de cuándo se puede obtener el derecho a usar la ranura, que no es estable. Por lo tanto, ¿cuáles son más adecuadas para uso temporal o prueba de nuevas cadenas? Aquellas cadenas que esperan operar de manera estable aún deben actualizarse a paracaídas.
1.4 Puente adaptador:
La comunicación entre parachains solo se puede lograr a través de XCMP (se presentará más adelante) y comparten seguridad y el mismo consenso. ¿Y qué pasa si es una cadena heterogénea?
Una cosa que debe tenerse en cuenta aquí es que, aunque el marco proporcionado por Substrate hace que todas las cadenas conectadas al ecosistema de Polkadot sean isomorfas, con el desarrollo del ecosistema, inevitablemente habrá algunas cadenas públicas maduras con grandes sistemas que quieran participar. .en la ecología. Si les pide que vuelvan a implementar usando solo Substrate, es básicamente imposible. Entonces, ¿cómo implementar la transmisión de mensajes entre cadenas heterogéneas?
**Tome un ejemplo de la vida real. Si desea transferir archivos desde un teléfono Apple a un teléfono Android a través de una conexión, los enchufes son diferentes, por lo que necesita un convertidor para conectarse. Esta es la función real del puente de transferencia. ** Es una paracadena que es un intermediario entre la cadena de retransmisión y la cadena heterogénea (cadena externa). Los contratos inteligentes se implementan en la cadena paralela y la cadena heterogénea, lo que permite que la cadena de retransmisión interactúe con la cadena externa y logre operaciones cruzadas. Función de cadena.
2. Tecnologías clave
2.1 NENAAbuelo
BABE (Asignación ciega para extensión Blockchain) es el mecanismo de generación de bloques de Polkadot. En pocas palabras, selecciona validadores al azar para producir nuevos bloques, y a cada validador se le asigna un intervalo de tiempo diferente. Dentro de este intervalo de tiempo, solo los validadores asignados a este intervalo pueden producir bloques.
Instrucciones adicionales:
El intervalo de tiempo es un método utilizado para dividir series de tiempo en el mecanismo de generación de bloques de blockchain. La cadena de bloques se dividirá en intervalos de tiempo que aparecen a intervalos fijos. Cada franja horaria representa un bloque de tiempo fijo.
Dentro de cada intervalo de tiempo, solo los nodos asignados a ese intervalo de tiempo pueden producir bloques.
**Es decir, es un periodo de tiempo exclusivo. En el período de tiempo 1, el validador 1 asignado a este período de tiempo 1 es responsable de producir bloques. Cada validador tiene un período de tiempo y no puede producir bloques repetidamente. **
La ventaja de esto es que la asignación aleatoria maximiza la equidad porque todos tienen la oportunidad de ser asignados. Y como se conoce la franja horaria, todos pueden prepararse con anticipación y no habrá generación de bloques inesperados.
A través de este método de generación de bloques asignados aleatoriamente, se garantiza el funcionamiento ordenado y justo del ecosistema de Polkadot. Entonces, ¿cómo garantizar que todos los bloques adopten el mismo consenso? A continuación, presentaremos otro mecanismo de Polkadot: abuelo.
Grandpa es un mecanismo para finalizar bloques, que puede resolver el problema de bifurcación que puede ocurrir debido a diferentes consensos cuando BABE produce bloques. Por ejemplo, el nodo 1 y el nodo 2 de BABE produjeron bloques diferentes al mismo tiempo, lo que resultó en una bifurcación. En este momento entrará en juego el abuelo, que preguntará a todos los validadores: ¿Qué cadena creen que es mejor?
Los validadores observarán ambas cadenas y votarán por la que consideren mejor. La cadena con más votos eventualmente será confirmada por el abuelo y se convertirá en la cadena final, y la cadena rechazada será abandonada.
Por lo tanto, el abuelo es como el "abuelo" de todos los validadores, desempeñando el papel de quien toma la decisión final, eliminando el riesgo de bifurcaciones que pueda traer BABE. Permite a Blockchain finalizar una cadena en la que todos estén de acuerdo.
En resumen, BABE es responsable de producir bloques al azar y el abuelo es responsable de seleccionar la cadena final. Los dos trabajan juntos para permitir que el ecosistema de Polkadot funcione de forma segura.
2.2 Sustrato
Substrate es un marco de desarrollo escrito en lenguaje Rust, con componentes extensibles subyacentes proporcionados por FRAME, lo que permite a Substrate admitir una variedad de casos de uso diferentes. Cualquier cadena de bloques creada con Substrate no solo es compatible de forma nativa con Polkadot, sino que puede compartir seguridad y ejecutarse simultáneamente con otras cadenas paralelas. También ayuda a los desarrolladores a crear sus propios mecanismos de consenso exclusivos, modelos de gobernanza, etc., y cambia constantemente según las necesidades. de desarrolladores.
Además, Substrate proporciona una gran comodidad a la hora de actualizarse automáticamente, porque es un módulo independiente en tiempo de ejecución y se puede separar de otros componentes. Por lo tanto, este módulo en ejecución se puede reemplazar directamente al actualizar funciones. Como parachain que comparte consenso, siempre que la red y el consenso estén sincronizados con la cadena de retransmisión, la lógica operativa se puede actualizar directamente sin la necesidad de una bifurcación dura.
2.3 XCM
Si pudiera explicar XCM en una oración, sería: **Un formato de comunicación entre cadenas que permite que diferentes cadenas de bloques interactúen. **
Por ejemplo, Polkadot tiene muchas parachains. Si la parachain A quiere comunicarse con la parachain B, necesita empaquetar la información en formato XCM. **XCM es como un protocolo de lenguaje: si todos usan este protocolo para comunicarse, podrán comunicarse sin barreras. **
El formato XCM (Formato de mensajes de consenso cruzado) es el formato de mensaje estándar utilizado para la comunicación entre cadenas en el ecosistema de Polkadot, y de él se derivan tres métodos diferentes de entrega de mensajes:
XCMP (Mensajería entre cadenas): En desarrollo. Los mensajes se pueden transmitir directamente o reenviar a través de una cadena de retransmisión, siendo la transmisión directa más rápida y el reenvío a través de una cadena de retransmisión más escalable pero aumentando la latencia.
HRMP/XCMP-lite (Mensajería de enrutamiento de retransmisión horizontal): En uso. Es una alternativa simplificada a XCMP. Todos los mensajes se almacenan en la cadena de retransmisión y actualmente realiza el trabajo principal de mensajería entre cadenas.
VMP (Mensajería Vertical): En desarrollo. Es un protocolo para transmitir mensajes verticalmente entre cadenas de retransmisión y cadenas paralelas. Los mensajes se almacenan en la cadena de retransmisión y la cadena de retransmisión los analiza antes de transmitirlos.
Por ejemplo, dado que el formato XCM contiene variedad de información, como la cantidad de activos a transferir, la cuenta receptora, etc. Al enviar un mensaje, el canal HRMP o la cadena de retransmisión entregará este mensaje en formato XCM. Después de que la otra cadena paralela recibe el mensaje, verificará si el formato es correcto, luego analizará el contenido del mensaje y luego lo ejecutará de acuerdo con las instrucciones del mensaje, como transferir activos a una cuenta designada. Se logra la interacción en cadena y las dos cadenas se comunican con éxito.
Los puentes de comunicación como XCM son muy importantes para ecosistemas multicadena como Polkadot.
Después de comprender Cosmos y Polkadot, creo que comprendo su visión y marco. Entonces, a continuación explicaremos en detalle ¿cuáles son las soluciones Stack lanzadas por ETH L2?
三. pila OP
1. Marco estructural
Según la documentación oficial, OP Stack se compone de una serie de componentes y es mantenido por OP Collective, primero aparece como software detrás de la red principal y finalmente aparece como la supercadena Optimism y su gobernanza. L2 desarrollado utilizando OP Stack puede compartir seguridad, capas de comunicación y una pila de desarrollo común. Y los desarrolladores son libres de personalizar la cadena para atender cualquier caso de uso específico de blockchain.
De la figura, podemos entender que todas las hipercadenas de OP Stack se comunicarán a través del puente de supercadena OP Bridge y utilizarán Ethereum como consenso de seguridad subyacente para construir una supercadena L2 y dividir la estructura interna de cada hipercadena.
**1) Capa de disponibilidad de datos: **Las cadenas que usan OP Stack pueden usar este módulo de disponibilidad de datos para obtener sus datos de entrada. Debido a que todas las cadenas obtienen datos de esta capa, esta capa tiene un impacto significativo en la seguridad. Si no se puede recuperar un determinado dato de ella, es posible que no haya forma de sincronizar la cadena.
Como puede ver en esta figura, OP Stack usa Ethereum y EIP-4844. En otras palabras, esencialmente usa la cadena de bloques Ethereum para acceder a los datos.
**2) Capa de secuenciación: **El secuenciador determina cómo recopilar las transacciones de los usuarios y publicarlas en la capa de disponibilidad de datos, que se procesa utilizando un único secuenciador dedicado en OP Stack. Sin embargo, esto puede hacer que el clasificador no pueda retener transacciones durante demasiado tiempo. En el futuro, OP Stack modularizará el clasificador para que la cadena pueda cambiar fácilmente el mecanismo de clasificación.
En la figura puede ver un secuenciador único y un secuenciador múltiple. El secuenciador único permite que cualquiera actúe como secuenciador en cualquier momento (mayor riesgo). El secuenciador múltiple se extrae de un conjunto predefinido de posibles participantes. Luego, si elige varios secuenciadores, cada cadena desarrollada en base a OP Stack se puede seleccionar explícitamente.
3) Capa de derivación: Esta capa determina cómo procesar la entrada procesada de datos sin procesar para la disponibilidad de los datos y la transmite a la capa de ejecución a través de la API de Ethereum. Como se puede ver en la imagen, OP Stack se compone de Rollup e Indexer.
**4) Capa de ejecución: **Esta capa define la estructura de estado dentro del sistema OP Stack. Cuando la API del motor recibe información de la derivación, se activará la transición de estado. Se puede ver en la figura que en OP Stack, la capa de ejecución es EVM. Sin embargo, con una versión ligeramente modificada, también puede admitir otros tipos de VM. Por ejemplo, Pontem Network planea usar OP Stack para desarrollar un Move VM L2.
**5) Capa de liquidación: **Como sugiere el nombre, se utiliza para manejar el retiro de activos de la cadena de bloques, pero dicho retiro requiere demostrar el estado de la cadena objetivo a una cadena de terceros y luego procesar la activos según el estado. El núcleo es permitir que la cadena de terceros comprenda el estado de la cadena de destino.
Una vez que una transacción se publica y finaliza en la capa de disponibilidad de datos correspondiente, la transacción también se finaliza en la cadena OP Stack. Ya no se puede modificar ni eliminar sin destruir la capa de disponibilidad de datos subyacente. Puede ser que la transacción aún no haya sido aceptada por la capa de liquidación, porque la capa de liquidación necesita poder verificar el resultado de la transacción, pero la transacción en sí ya es inmutable.
Este también es un mecanismo para cadenas heterogéneas. Las cadenas heterogéneas tienen diferentes mecanismos de liquidación, por lo que en OP Stack, la capa de liquidación es de solo lectura, lo que permite que las cadenas heterogéneas tomen decisiones basadas en el estado de OP Stack.
En esta capa vemos que OP Stack utiliza la prueba de fallas en OP Rollup. Los proponentes pueden proponer un estado válido que cuestionen y, si no se demuestra que es incorrecto dentro de un período de tiempo, se considerará automáticamente correcto.
**6) Capa de gobernanza: **Como puede ver en la imagen, los tokens de firma múltiple + $OP se utilizan para la gobernanza en OP Stack. Por lo general, se utiliza firma múltiple para gestionar la actualización de los componentes del sistema Stack. Las operaciones se realizarán cuando todos los participantes participen en la firma. Los poseedores de tokens $OP pueden votar en la comunidad DAO para participar en la gobernanza.
**OP Stack es como una combinación de Cosmos y Polkadot: puede personalizar libremente cadenas exclusivas como Cosmos y también puede compartir seguridad y consenso como Polkadot. **
2. Tecnologías clave
2.1 Resumen de OP
OP Rollup garantiza la seguridad a través de desafíos de disponibilidad de datos y permite la ejecución paralela de transacciones. Los siguientes son los pasos de implementación específicos:
El usuario inicia una transacción en L2
El secuenciador empaquetará y procesará en lotes y luego sincronizará los datos de la transacción procesada y la nueva raíz de estado con el contrato inteligente implementado en L1 para verificación de seguridad. Cabe señalar que cuando Sequencer procesa una transacción, también generará su propio estado raíz y lo sincronizará con L1.
Después de la verificación, L1 devuelve los datos y la raíz del estado a L2, y el estado de la transacción del usuario se verifica y procesa de forma segura.
En este momento, OP Rollup considera que el estado raíz generado por Sequencer es optimista y correcto. Y se abrirá una ventana de tiempo para que el verificador cuestione y verifique si la raíz del estado generada por el secuenciador coincide con la raíz del estado de la transacción.
Si no hay ningún validador para verificar durante el período de tiempo, la transacción se considerará correcta automáticamente. Si se verifica un fraude malicioso, el secuenciador que procesa la transacción será sancionado en consecuencia.
2.2 Puente entre cadenas
a) Igual que la mensajería L2
Dado que OP Rollup utiliza prueba de fallas, la transacción debe esperar a que se complete el desafío. Este proceso lleva mucho tiempo y la experiencia del usuario es baja. Sin embargo, ZKP (prueba de conocimiento cero) es costoso y propenso a errores, y llevará algún tiempo implementar ZKP por lotes.
**Por lo tanto, para resolver el problema de comunicación entre las hipercadenas L2 OP, OP Stack propuso una prueba modular: utilizando dos sistemas de prueba para la misma cadena, los desarrolladores que crean pilas L2 pueden elegir libremente cualquier tipo de puente. **
Actualmente el OP proporciona:
Alta seguridad, alto retraso y prevención de fallas (puente estándar de alta seguridad)
Baja seguridad, prueba de errores de baja latencia (breve período de desafío para lograr baja latencia)
Prueba de validez de baja seguridad y baja latencia (use un probador de cadena confiable en lugar de ZKP)
Prueba de validez de alta seguridad y baja latencia (cuando ZKP esté listo)
Los desarrolladores pueden elegir el enfoque del puente de acuerdo con las necesidades de sus propias cadenas. Por ejemplo, para activos de alto valor, pueden elegir puentes de alta seguridad... Diversas tecnologías de puentes permiten el movimiento eficiente de activos y datos entre diferentes cadenas.
b) Transacciones entre cadenas
Las transacciones tradicionales entre cadenas se completan de forma asincrónica, lo que significa que es posible que la transacción no se ejecute por completo.
OP Stack propuso la idea de un clasificador compartido para este tipo de problema. Por ejemplo, si un usuario desea realizar un arbitraje entre cadenas, al compartir el secuenciador en la cadena A y la cadena B, puede llegar a un consenso sobre el momento de la transacción. Las tarifas se pagarán solo después de que las transacciones se carguen en el cadena, y los secuenciadores de ambos lados comparten el riesgo.
c)Transacción de hipervínculo
Debido a que la disponibilidad de datos de Ethereum L1 no es lo suficientemente escalable (la capacidad es limitada), no es escalable para publicar transacciones en la supercadena.
Por lo tanto, en OP Stack, se propone utilizar el protocolo Plasma para expandir la cantidad de datos a los que puede acceder la cadena OP, lo que puede reemplazar DA (disponibilidad de datos) para complementar más datos L1. La disponibilidad de los datos de las transacciones se reduce a la cadena Plasma y los compromisos de datos solo se registran en L1, lo que mejora enormemente la escalabilidad.
4. Pila ZK
1. Marco estructural
ZK Stack es un conjunto de códigos modulares, componibles y de código abierto creados con la misma tecnología subyacente (ZK Rollup) que zkSync Era, lo que permite a los desarrolladores personalizar sus propios hipervínculos L2 y L3 controlados por ZK.
Dado que ZK Stack es gratuito y de código abierto, los desarrolladores pueden personalizar los hipervínculos según sus necesidades específicas. Ya sea que elija una red de Capa 2 que se ejecute en paralelo con zkSync Era o una red de Capa 3 que se ejecute sobre ella, las posibilidades de personalización serán amplias.
Según Matter Labs, los creadores disfrutan de total autonomía para personalizar y dar forma a cada aspecto de la cadena, desde elegir un modelo de disponibilidad de datos hasta utilizar el ordenador descentralizado de tokens propio del proyecto.
Por supuesto, estas hipercadenas ZK Rollup operan de forma independiente, pero solo dependerán de Ethereum L1 para seguridad y verificación.
Fuente: Documento zkSync
Como se puede ver en la figura, cada hipervínculo debe utilizar el motor zkEVM de zkSync L2 para compartir seguridad. Se ejecutan varias cadenas ZKP al mismo tiempo y las pruebas de bloques se agregan en la capa de liquidación de L1. Al igual que los bloques apilados, se puede expandir continuamente para construir más L3, L4...
2. Tecnologías clave
1）Acumulación de ZK
La capa inferior de ZK Stack utiliza ZK Rollup como tecnología central. El siguiente es el proceso principal del usuario:
Los usuarios envían sus propias transacciones y Sequencer recopila las transacciones en lotes ordenados, genera certificados de validez (STARK/SNARK) por sí solo y actualiza el estado. El estado actualizado se enviará al contrato inteligente implementado en L1 y se verificará. Si se supera la verificación, también se actualizará el estado de los activos de la capa L1. La ventaja de ZK Rollup es que tiene la capacidad de realizar verificación matemática mediante prueba de conocimiento cero, que es superior en términos de tecnología y seguridad.
2) Puente de hipervínculo
Como se muestra en el marco estructural anterior, ZK Stack puede lograr una expansión inalámbrica y generar continuamente L3, L 4, etc. Entonces, ¿cómo debería lograrse la interoperabilidad entre hipervínculos?
**ZK Stack presenta el puente de hipercadena. Al implementar el contrato inteligente del puente compartido en L1, verifica la prueba Merkle de las transacciones que ocurren en la hipercadena. Es esencialmente lo mismo que ZK Rollup, excepto que cambia con respecto al L2 original. -L1.Se convirtió en L3-L2. **
ZK Stack admite contratos inteligentes en cada hipercadena y se llama entre sí de forma asíncrona entre cadenas. Los usuarios pueden transferir rápidamente sus activos de manera confiable en cuestión de minutos sin incurrir en ningún costo adicional. Por ejemplo, para procesar un mensaje en el hipervínculo receptor B, el hipervínculo emisor A debe finalizar su estado hasta el primer hipervínculo en el que A y B son comunes. Entonces, en la práctica, la latencia de comunicación de Hyperbridge es solo cuestión de segundos, Hyperchain puede completar bloques por segundo y ser más económico.
No sólo eso, sino que como L3 puede aprovechar la tecnología de compresión, la prueba está empaquetada. L2 expandirá aún más el empaquetado, formando así un factor de compresión más considerable y un costo más bajo (compresión recursiva), que puede lograr transacciones transfronterizas sin confianza, rápidas (en unos pocos minutos) y baratas (costo de transacción única).
5. Polígono 2.0
Polygon es una solución especial L2, técnicamente L1, como cadena lateral de Ethereum. El equipo de Polygon anunció recientemente el plan Polygon 2.0, que ayudará a los desarrolladores a crear sus propias cadenas ZK L2 usando ZK y unificarlas a través de un novedoso protocolo de coordinación entre cadenas, haciendo que los usuarios sientan que toda la red está usando una sola cadena.
Polygon 2.0 se compromete a admitir un número ilimitado de cadenas, y las interacciones entre cadenas pueden ocurrir de forma segura e instantánea sin suposiciones de seguridad o confianza adicionales, lo que permite una escalabilidad ilimitada y liquidez unificada.
1. Marco estructural
Fuente: Blog de polígono
Polygon 2.0 consta de 4 capas de protocolo:
1) Capa de compromiso
La capa de compromiso es un protocolo basado en PoS (Proof of Stake), que utiliza el compromiso $MATIC para lograr una gobernanza descentralizada para gestionar eficientemente los validadores y mejorar la eficiencia de los mineros.
Como puede verse en la figura, Polygon 2.0 propone un administrador de validación y un administrador de cadena en la capa de compromiso.
Validator Manager: Es un grupo de validadores público que administra todas las cadenas de Polygon 2.0. Incluyendo el registro de verificadores, solicitudes de compromiso, solicitudes de liberación de compromiso… se puede imaginar como el departamento administrativo de los verificadores.
Chain Manager: Se utiliza para gestionar el conjunto de validadores de cada cadena Polygon 2.0, comparado con el anterior está más enfocado a la gestión de verificación de la cadena, porque cada cadena Polygon tiene su contrato Chain Manager, a diferencia del gestor de validadores. Servicio Público. Se centra principalmente en el número de validadores por cadena correspondiente (relacionado con el nivel de descentralización), requisitos adicionales para los validadores, otras condiciones, etc.
La capa de participación ya ha formulado la estructura subyacente de las reglas correspondientes para cada cadena, y los desarrolladores solo necesitan centrarse en el desarrollo de sus propias cadenas.
Fuente: Blog de polígono
2) Capa de interoperabilidad
Los protocolos entre cadenas son cruciales para la interoperabilidad de toda la red. Cómo llevar a cabo mensajes entre cadenas de forma segura y sin problemas es algo que cada solución de hipervínculo debería seguir mejorando.
Actualmente, Polygon utiliza dos contratos, el agregador y la cola de mensajes, como soporte.
Cola de mensajes: principalmente modificada y actualizada para el protocolo Polygon zkEVM existente. Cada cadena Polygon mantiene una cola de mensajes local en un formato fijo, y estos mensajes se incluyen en la prueba ZK generada por la cadena. Una vez que se verifica una prueba ZK en Ethereum, cualquier mensaje de esa cola puede ser consumido de forma segura por su cadena de recepción y dirección.
Agregador: El agregador existe con la esperanza de proporcionar servicios más eficientes entre la cadena Polygon y Ethereum. Por ejemplo, se agregan varias pruebas ZK en una sola prueba ZK y se envían a Ethereum para su verificación para reducir los costos de almacenamiento y mejorar el rendimiento.
Una vez que el agregador acepta la prueba ZK, la cadena de recepción puede comenzar a aceptar mensajes de manera optimista, porque toda la cadena de recepción cree en la prueba ZK, logrando así una entrega de mensajes perfecta, etc.
3) Capa de ejecución
La capa de ejecución permite que cualquier cadena Polygon genere lotes de transacciones ordenadas, también llamados bloques. La mayoría de las redes blockchain (Ethereum, Bitcoin, etc.) lo utilizan en un formato similar.
La capa de ejecución tiene múltiples componentes, tales como:
Consenso: Un consenso que permite a los validadores llegar a un consenso.
Mempool: recopila las transacciones enviadas por los usuarios y las sincroniza entre los validadores. Los usuarios también pueden ver el estado de sus transacciones en mempool.
P2P: permite que los validadores y los nodos completos se descubran entre sí e intercambien mensajes;
...
Dado que esta capa está mercantilizada pero es relativamente compleja de implementar, las implementaciones de alto rendimiento existentes (como Erigon) deben reutilizarse siempre que sea posible.
4) Capa de prueba
La capa de prueba genera pruebas para cada polígono. Es un protocolo de prueba ZK flexible y de alto rendimiento que generalmente tiene los siguientes componentes:
Probador común: un probador ZK de alto rendimiento que proporciona una interfaz limpia y está diseñado para admitir cualquier tipo de transacción, es decir, un formato de máquina de estados.
Constructor de máquinas de estados: un marco para definir máquinas de estados y se utiliza para construir el Polygon zkEVM inicial. El marco abstrae la complejidad del mecanismo de prueba y lo simplifica en una interfaz modular fácil de usar, lo que permite a los desarrolladores personalizar parámetros y construir sus propias máquinas de estado a gran escala.
Máquina de estados: una simulación del entorno de ejecución y el formato de transacción que está probando el probador. La máquina de estados se puede implementar utilizando el constructor descrito anteriormente o se puede personalizar completamente, por ejemplo utilizando Rust.
2. Tecnologías clave
Fuente: Blog de polígono
1) Validación de zkEVM
En la actualización Polygon 2.0, el equipo lo actualizó a zkEVM validium conservando el POS Polygon original.
Fuente: Blog de polígono
Según la ciencia popular simple aquí, Validium y Rollup son soluciones de Capa 2 y su propósito es expandir la capacidad de transacción de Ethereum y acortar el tiempo de transacción. Compara los dos:
Rollup empaqueta muchas transacciones y luego las envía a la cadena principal de Ethereum como un lote, utilizando Ethereum para publicar datos de transacciones y verificar la prueba, heredando así completamente su seguridad y descentralización incomparables. Sin embargo, publicar datos de transacciones en Ethereum es costoso y limita el rendimiento.
Validium no necesita enviar todos los datos de la transacción a la cadena principal. Utiliza pruebas de conocimiento cero (ZKP) para demostrar que las transacciones son válidas, y los datos de las transacciones se proporcionan fuera de la cadena. protegiendo al mismo tiempo la privacidad del usuario. Sin embargo, Validium requiere confianza en el entorno de ejecución, que está relativamente centralizado.
Se puede entender que Validium es un Rollup con menor costo y mayor escalabilidad. Sin embargo, el principio operativo de Polygon zkEVM (mecanismo Polygon POS) antes de la actualización era (ZK) Rollup, y también logró resultados considerables. En sólo 4 meses desde su lanzamiento, su TVL se ha disparado a 33 millones de dólares.
Fuente: Defilama
A largo plazo, el costo de generar pruebas para zkEVM basado en Polygon PoS puede convertirse en un obstáculo para una futura expansión. Aunque el equipo de Polygon ha estado trabajando arduamente para reducir el costo de Batch, se ha reducido a una cifra extremadamente impresionante: lo que demuestra que el costo de 10 millones de transacciones es de solo $0,0259. Pero Vailidium cuesta menos, así que ¿por qué no utilizarlo?
Polygon ha publicado documentos oficialmente. En versiones futuras, **Validium asumirá el trabajo de POS anterior y también conservará el POS. La función principal de su verificador de POS es garantizar la disponibilidad de datos y clasificar las transacciones. **
El zkEVM Validium actualizado proporcionará una escalabilidad muy alta y un costo muy bajo. Porque es muy adecuado para aplicaciones con gran volumen de transacciones y bajas tarifas de transacción, como Gamefi, Socialfi y DeFi, etc. Para los desarrolladores, no se requiere ninguna operación, solo necesitan actualizar junto con la red principal para completar la actualización de Validium.
2) resumen de zkEVM
Actualmente, Polygon PoS (que pronto se actualizará a Polygon Validium) y Polygon zkEVM Rollup son las dos redes públicas del ecosistema Polygon. Este sigue siendo el caso después de la actualización, con el beneficio adicional de que ambas redes utilizan tecnología zkEVM de vanguardia, una como agregación y la otra como verificación.
Polygon zkEVM Rollup ya proporciona el más alto nivel de seguridad, pero a costa de un costo ligeramente mayor y un rendimiento limitado. Sin embargo, es muy adecuado para aplicaciones que manejan transacciones de alto valor y priorizan la seguridad, como las DeFi Dapps de alto valor.
六. decisión de órbita
Arbitrum es actualmente la cadena pública L2 más importante, desde su lanzamiento en agosto de 2021, su TVL ha superado los 5.100 millones de dólares y, como L2 líder, ocupa casi el 54% de la cuota de mercado.
Arbitrum lanzó la versión Orbit en marzo de este año. Anteriormente, Arbitrum lanzó una serie de productos ecológicos:
Arbitrum One: el primer y principal paquete acumulativo de red principal del ecosistema Arbitrum.
Arbitrum Nova: Este es el segundo resumen de la red principal de Arbitrum, dirigido a proyectos que son sensibles a los costos y tienen requisitos de alto volumen de transacciones.
Arbitrum Nitro: Esta es la pila de software de tecnología que impulsa Arbitrum L2, haciendo que Rollup sea más rápido, más económico y más compatible con EVM.
Arbitrum Orbit: un marco de desarrollo para crear e implementar L3 en la red principal de Arbitrum.
Hoy nos centraremos en Arbitrum Orbit.
1. Marco estructural
Originalmente, si los desarrolladores querían usar Arbitrum Orbit para crear una red L2, primero emitían una propuesta, que sería votada por Arbitrum DAO. Si se aprobaba, se crearía una nueva cadena L2. Sin embargo, no se requiere permiso para desarrollar L3, 4, 5... en L2. Cualquiera puede proporcionar un marco sin permiso para implementar cadenas personalizadas en Arbitrum L2.
Fuente: documento técnico
Como puede ver, Arbitrum Orbit también se esfuerza por permitir a los desarrolladores personalizar su propia cadena Oribit L3 basada en la Capa 2, como Arbitrum One, Arbitrum Nova o Arbitrum Goerli. Los desarrolladores pueden personalizar el acuerdo de privacidad, la licencia, el modelo económico de tokens, la gestión comunitaria, etc. de esta cadena, brindando a los desarrolladores la mayor autonomía.
Entre ellos, lo que es más notable es que Oribit permite que la cadena L3 utilice el Token de esta cadena como unidad de liquidación de tarifas, desarrollando así efectivamente su propia red.
2. Tecnologías clave
1）Agrupar AnyTrust
Estos dos protocolos admiten Arbitrum One y Arbitrum Nova respectivamente. Como se presentó anteriormente, Arbitrum One es un paquete acumulativo de red principal central; Arbitrum Nova es el segundo paquete acumulativo de red principal, pero está conectado al protocolo AnyTrust. Se puede introducir introduciendo "seguridad supuestos" (Trust Assumption) para acelerar la liquidación y reducir costes.
Entre ellos, Arbitrum Rollup es un OP Rollup, por lo que sin más explicaciones, realizaremos un análisis detallado del protocolo AnyTrust.
El protocolo AnyTrust gestiona principalmente la disponibilidad de datos y está aprobado por una serie de organizaciones de terceros como DAC (Comité de Disponibilidad de Datos). Y al introducir "supuestos de seguridad", los costos de transacción se reducen considerablemente. La cadena AnyTrust se ejecuta en Arbitrum One como una cadena lateral, con costos más bajos y velocidades de transacción más rápidas.
Entonces, ¿qué es exactamente un “supuesto de confianza”? ¿Por qué su existencia reduce los costos de transacción y requiere menos confianza?
Según la documentación oficial de Arbitrum, la cadena AnyTrust es operada por un comité de nodo y utiliza suposiciones mínimas para determinar cuántos miembros del comité son honestos. Por ejemplo, digamos que el comité está formado por 20 personas y se supone que al menos 2 miembros son honestos. En comparación con BFT, que requiere que ⅔ de los miembros sean honestos, AnyTrust reduce el umbral de confianza al mínimo.
En una transacción, dado que el comité promete proporcionar datos de la transacción, el nodo no necesita registrar todos los datos de la transacción L2 en L1, solo necesita registrar el valor hash del lote de transacciones, lo que puede ahorrar en gran medida el costo. de resumen. . Es por eso que la cadena AnyTrust puede reducir los costos de transacción.
Respecto al tema de la confianza, como se mencionó anteriormente, se supone que solo 2 de los 20 miembros son honestos, y la suposición es cierta. Siempre que 19 de los 20 miembros del comité firmen para comprometerse a que el acuerdo sea correcto, se podrá ejecutar de forma segura. Entonces, incluso si el miembro que no firmó es honesto, uno de los 19 miembros que firmaron debe ser honesto.
¿Qué debemos hacer si los miembros no firman o un gran número de miembros se niegan a cooperar, lo que provoca que no funcione correctamente? La cadena AnyTrust aún puede ejecutarse, pero recurrirá al protocolo Rollup original y los datos aún se publican en Ethereum L1. Cuando el comité funcione correctamente, la cadena volverá a un modo más económico y rápido.
Aribtrum lanzó este protocolo con la esperanza de satisfacer las necesidades de aplicaciones que requieren alta velocidad de procesamiento y bajo costo, como el campo Gamefi.
2）Nitro
Nitro es la última versión de la tecnología Arbitrum. Su elemento principal es el Prover, que realiza la tradicional prueba interactiva de fraude en Arbitrum a través del código WASM. Y todos sus componentes están completos. Arbitrum completó la actualización a finales de agosto de 2022, migrando/actualizando sin problemas el Arbitrum One existente a Aribitrum Nitro.
Nitro tiene las siguientes características:
Procesamiento de transacciones en dos etapas: las transacciones del usuario primero se integran en una única secuencia ordenada y luego Nitro envía la secuencia, procesa las transacciones en secuencia y logra transiciones de estado deterministas.
Geth: Nitro utiliza el cliente Ethereum Geth (go-ethereum) más compatible actualmente para admitir la estructura de datos, el formato y la máquina virtual de Ethereum, lo que lo hace mejor compatible con Ethereum.
Ejecución y prueba separadas: Nitro toma el mismo código fuente y lo compila dos veces, una vez en código nativo para ejecutar transacciones en nodos Nitro y otra vez en WASM como prueba.
OP Rollup con pruebas de fraude interactivas: Nitro utiliza OP Rollups, incluidas las primeras pruebas de fraude interactivas de Arbitrum, para liquidar transacciones en la cadena Ethereum de capa 1.
Estas características de Oribit brindan soporte técnico para los casos de uso de Arbitrum L3 y L 4. Arbitrum puede atraer desarrolladores que buscan personalización para crear sus propias cadenas personalizadas.
七. Pila Starknet
El cofundador de StarkWare, Eli Ben-Sasson, dijo en la conferencia EthCC en París que Starknet pronto lanzará Starknet Stack, permitiendo que cualquier aplicación implemente su propia cadena de aplicaciones Starknet sin permiso.
Tecnologías clave como la prueba STARK en Starknet, el lenguaje de programación Cairo y la abstracción de cuentas nativas brindan una garantía poderosa para el rápido desarrollo de Starknet. Cuando los desarrolladores usan Stack para personalizar su propia cadena de aplicaciones Starknet, es escalable y libremente configurable, lo que puede expandir en gran medida el rendimiento de la red y aliviar la congestión de la red principal.
Aunque Starknet es actualmente sólo una idea preliminar, los documentos técnicos oficiales aún no se han publicado. Sin embargo, Madara Sequencer y LambdaClass se están desarrollando como componentes Sequencer y Stack compatibles con Starknet, respectivamente, para adaptarse mejor a Starknet. Los funcionarios también están trabajando arduamente en el próximo Starknet Stack, incluido el desarrollo de nodos completos/motores de ejecución/verificación y otros componentes.
Vale la pena señalar que no hace mucho, StarkNet presentó una propuesta de "Protocolo descentralizado simple", con la esperanza de cambiar el estado actual del secuenciador de operación de punto único actual de L2. Ethereum está descentralizado, pero los L2 no, y sus ingresos MEV hacen que Sequencer sea malo.
StarkNet enumeró algunas soluciones en la propuesta, tales como:
Participación L1 y elección de líder: los miembros de la comunidad pueden apostar en Ethereum sin permiso para unirse a la colección Staker. Luego, según la distribución colectiva de activos y el número aleatorio en la cadena L1, se selecciona aleatoriamente un grupo de Staker como líder responsable de producir un bloque Epoch. Esto no solo reduce el umbral para los usuarios de Staker, sino que su aleatoriedad también puede prevenir eficazmente los ingresos grises de MEV.
Mecanismo de consenso L2: Basado en Tendermint, el mecanismo de consenso bizantino a prueba de consenso en el que Leader participa como nodo. Una vez confirmado el consenso, el votante lo ejecuta y el proponente llama al probador para generar ZKP.
Además, existen planes para la certificación ZK, actualizaciones de estado de L1, etc., combinado con la gran iniciativa anterior para ayudar a la comunidad a operar el código Prover sin permiso, la propuesta de StarkNet busca resolver la falta de descentralización de L2 y tratar de equilibrar la inconsistencia de la cadena de bloques Quizás el problema triangular sea realmente notable.
En este capítulo, a través de la explicación técnica de CP y las principales pilas de capa 2, podemos encontrar que la solución actual de pila de capa 2 puede resolver eficazmente el problema de expansión de Ethereum, pero también trae una serie de desafíos y problemas, especialmente en términos de compatibilidad Sexualmente. La tecnología en la solución Stack de L2 no es tan madura como la de CP, e incluso vale la pena aprender el concepto técnico de CP de hace tres o cuatro años de las L2 actuales. Entonces, a nivel técnico, el CP actual sigue siendo muy superior a la Capa 2. Sin embargo, la tecnología avanzada por sí sola no es suficiente. En el próximo segundo artículo, discutiremos las ventajas, desventajas y características respectivas de CP y L2 Stacks desde los aspectos del valor simbólico y el desarrollo ecológico, para mejorar la perspectiva de los lectores.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Capítulo de pilas Cosmos, Polkadot VS Layer2 (1)
Introducción
Recientemente, Optimism, liderado por ETH Layer 2, y zkSync, Polygon, Arbitrum y StarkNet han lanzado sus propias soluciones Stack, todas con el objetivo de construir un conjunto de códigos modulares de código abierto que permitan a los desarrolladores personalizar su propia Capa 2.
Como todos sabemos, el Ethereum actual es conocido por su bajo rendimiento y alto nivel de Gas. La aparición de Capa 2 como OP y zkSync Era ha resuelto estos problemas. Sin embargo, ya sea que se implemente en una máquina virtual EVM o en la Capa 2, existe esencialmente un problema de "compatibilidad". Este no es solo el código subyacente de Dapp que debe ser compatible con EVM, sino también la soberanía de Dapp.
La primera parte es el nivel de código. Dado que EVM necesita encargarse de varios tipos de aplicaciones implementadas en él, se ha optimizado en el caso de usuario promedio para tener en cuenta todos los tipos de usuarios. Pero no es tan amigable con las Dapps implementadas en él. Por ejemplo, las aplicaciones Gamefi prestarán más atención a la velocidad y el rendimiento, mientras que los usuarios de Socialfi pueden prestar más atención a la privacidad y la seguridad. Sin embargo, debido a la naturaleza integral de EVM, Dapp debe renunciar a algo, que es la compatibilidad a nivel de código.
La segunda parte es el nivel de soberanía. Dado que todas las Dapps comparten infraestructura, han surgido dos conceptos: gobernanza de aplicaciones y gobernanza subyacente. La gobernanza de aplicaciones está sin duda sujeta a la gobernanza subyacente. Las necesidades específicas de algunas Dapps requieren una actualización a través del EVM subyacente. entonces Dapp carece de soberanía. Por ejemplo, las nuevas funciones de Uniswap V4 requieren que el EVM subyacente admita el almacenamiento transitorio y dependa de que EIP-1153 se agregue a la actualización de Cancún.
Para resolver los problemas de soberanía y bajo rendimiento de procesamiento de Ethereum L1 mencionados anteriormente, surgieron Cosmos (2019) y Polkadot (2020). Ambos esperan ayudar a desarrollar y construir sus propias cadenas personalizadas, permitiendo a las Dapps blockchain controlar la autonomía soberana, lograr una interoperabilidad entre cadenas de alto rendimiento y realizar una red de interoperabilidad de cadena completa.
Hoy, 4 años después, las L2 también lanzaron sus propias soluciones de red de hipervínculos, desde OP Stack, ZK Stack, Polygon 2.0, Arbitrum Orbit y finalmente StarkNet, para no quedarse atrás, lanzó el concepto Stack.
¿Qué tipo de colisiones y chispas ocurrirán entre el pionero de la red de cadena completa CP (Cosmos Polkadot) y los L2? Para brindarle una perspectiva integral y profunda, exploraremos este tema en profundidad a través de una serie de tres artículos. **Este artículo, como primer capítulo de esta serie, clasificará las soluciones técnicas de cada empresa, el segundo capítulo clasificará el modelo económico y la ecología de cada solución y resumirá las diferencias entre la Capa 1 y la Capa 1.2 Stack selecciona las características que deben considerarse. En el último capítulo, analizamos cómo Layer 2 desarrolla su propia supercadena y resumimos toda la serie de artículos. **
1. Cosmos
Cosmos es una red descentralizada de cadenas de bloques paralelas independientes. Al proporcionar un SDK de marco de desarrollo común, los desarrolladores pueden construir fácilmente sus propias cadenas de bloques, y múltiples cadenas de bloques independientes y diferentes de aplicaciones específicas pueden interactuar entre sí. Los enlaces se comunican entre sí, formando una red interoperable. y red de cadena completa escalable.
1. Marco estructural
Como se mencionó anteriormente, cuando hay cadenas de aplicaciones a gran escala en el ecosistema y cada cadena utiliza el protocolo IBC para comunicarse y transmitir tokens, toda la red será tan engorrosa y difícil de clasificar como una telaraña.
Entonces, para resolver este problema, Cosmos propuso una arquitectura en capas, que contiene dos tipos de blockchains: Hubs (cadena central) y Zones (cadena regional).
**Las zonas son cadenas de aplicaciones convencionales y los concentradores son cadenas de bloques especialmente diseñadas para conectar zonas entre sí, principalmente sirviendo de comunicación entre zonas. **Cuando una Zona crea una conexión IBC con el Hub, el Hub puede acceder automáticamente (es decir, enviar y recibir) a todas las Zonas conectadas a él. Esta estructura reduce en gran medida la complejidad de la comunicación.
Además, cabe señalar que Cosmos y Cosmos Hub son dos cosas completamente diferentes. Cosmos Hub es solo una de las cadenas que existen en el ecosistema de Cosmos y sirve principalmente como emisor y centro de comunicación de $ATOM. **Puedes entender Hub como el centro del ecosistema, pero en realidad cualquier cadena puede convertirse en un Hub. Si el Hub se convierte en el centro del ecosistema, esto es en realidad contrario a la intención original de Cosmos. ** Debido a que Cosmos está esencialmente comprometido con la autonomía de cada cadena y tiene soberanía absoluta, si el Hub se usa como centro de poder, entonces la soberanía ya no se llama soberanía. Entonces, al comprender Hub, debes prestar especial atención a este punto.
2. Tecnologías clave
2.1 IBC
IBC (Comunicación entre cadenas de bloques), que es comunicación entre cadenas, permite que cadenas heterogéneas transfieran tokens y datos entre sí. En el ecosistema Cosmos, el marco subyacente del SDK es el mismo y se debe utilizar el motor de consenso Tendermint. Sin embargo, todavía existe heterogeneidad, ya que las cadenas pueden tener diferentes funcionalidades, casos de uso y detalles de implementación dentro del marco.
Entonces, ¿cómo lograr la comunicación entre cadenas heterogéneas?
Sólo requiere una finalidad a nivel de consenso. Finalidad instantánea significa que siempre que más de 1/3 de los validadores sean correctos, el bloque no se bifurcará, lo que garantiza que la transacción sea definitiva una vez que se produzca el bloque. Independientemente de las diferencias en los casos de aplicación y el consenso entre cadenas heterogéneas, siempre que se garantice que sus niveles de consenso cumplan con la finalidad, la interoperabilidad entre cadenas estará determinada por reglas unificadas.
El siguiente es un proceso básico de comunicación entre cadenas. Supongamos que desea transferir 10 $ATOM de la cadena A a la cadena B:
En este momento, el $ATOM de la cadena B no es el $ATOM real, sino solo un certificado. El $ATOM bloqueado en la cadena A no se puede utilizar, pero el de la cadena B se puede utilizar normalmente. Cuando el usuario consume las credenciales en B, el $ATOM bloqueado en la cadena A también será destruido.
Sin embargo, el mayor desafío al que se enfrenta la comunicación entre cadenas no es cómo representar los datos de una cadena en otra, sino cómo manejar situaciones como bifurcaciones y reorganizaciones de cadenas.
Porque cada cadena en Cosmos es una cadena individual independiente y autónoma con su propio verificador dedicado. Por lo tanto, es muy probable que haya particiones que hagan el mal. Por ejemplo, si la cadena A transmite mensajes a la cadena B, entonces es necesario verificar los validadores de la cadena B con anticipación antes de decidir si confiar en la cadena.
Por ejemplo, supongamos que el pequeño punto rojo en la imagen representa un token ETM, y todos los usuarios en las tres particiones de ABC quieren usar EVMOS para ejecutar Dapps en las particiones, porque las transferencias de activos se llevan a cabo a través de comunicación entre cadenas. ETM.
Si la partición Ethermint lanza un ataque de doble gasto en este momento, la partición ABC sin duda se verá afectada, pero solo se limitará a esto. Las redes restantes no relacionadas con ETM no recibirán ningún ataque, esto también lo garantiza Cosmos. Incluso si se produce dicha transmisión de información maliciosa, no afectará a toda la red.
2.2 BFT de menta tierna
Cosmos utiliza Tendermint BFT como algoritmo de consenso subyacente y motor de consenso de Cosmos. Combina y empaqueta la infraestructura subyacente y la capa de consenso de la cadena de bloques en una solución de motor universal, y utiliza la tecnología ABCI para soportar la encapsulación de cualquier lenguaje de programación. la capa y la red de consenso subyacentes. **Por lo tanto, los desarrolladores son libres de elegir el idioma que deseen.
2.3 SDK de Cosmos
Cosmos SDK es un marco modular lanzado por Cosmos que simplifica la operación de creación de Dapps en la capa de consenso. Los desarrolladores pueden crear fácilmente aplicaciones/cadenas específicas sin tener que reescribir el código de cada módulo, lo que reduce en gran medida la presión de desarrollo y ahora permite a los desarrolladores portar aplicaciones implementadas en EVM a Cosmos.
Fuente:
Además, las cadenas de bloques creadas con Tendermint y Cosmos SDK también están creando nuevos ecosistemas y nuevas tecnologías que están liderando el desarrollo de la industria, como Nym, la cadena de privacidad, Celestia, que proporciona disponibilidad de datos, etc. Es precisamente gracias a la flexibilidad y facilidad de uso que proporciona Cosmos que los desarrolladores pueden centrarse en la innovación del proyecto sin tener que considerar la duplicación del trabajo.
2.4 Cuenta de seguridad entre cadenas
1) Seguridad entre cadenas
Debido a que Cosmos es diferente del ecosistema Ethereum, tiene L1 y L2. Cada cadena de aplicaciones en el ecosistema Cosmos es igual entre sí y no existe una relación progresiva o superior-inferior. Sin embargo, por esta razón, la seguridad entre cadenas no es tan completa como la de Ethereum. En Ethereum, Ethereum confirma la finalidad de todas las transacciones y hereda el valor subyacente. Pero para una cadena de bloques única que construya su propia seguridad, ¿cómo se debe mantener la seguridad?
Cosmos lanzó Interchain Security, que esencialmente permite la seguridad compartida al compartir una gran cantidad de nodos existentes. Por ejemplo, la cadena monolítica puede compartir un conjunto de nodos de verificación con Cosmos Hub para generar nuevos bloques para la cadena monolítica. Dado que los nodos sirven tanto a Cosmos Hub como a la cadena única, pueden recibir tarifas y recompensas de ambas cadenas.
Fuente:/tokenomics-dao/token-use-cases-part-1-atom-of-true-stake-token-5 fd 21 d 41161 e
Como se muestra en la figura, las transacciones generadas originalmente dentro de la cadena X son generadas por los nodos de X para su verificación. Si comparte un nodo con Cosmos Hub ($ATOM), las transacciones generadas originalmente en la cadena X serán verificadas y calculadas por los nodos de la cadena Hub para generar nuevos bloques para X.
Lógicamente, elegir una cadena relativamente madura con una gran cantidad de nodos, como la cadena Hub, es la primera opción para la seguridad compartida. Porque si quieren atacar una cadena de este tipo, los atacantes necesitan tener una gran cantidad de tokens $ATOM como prenda, lo que aumenta la dificultad del ataque.
No solo eso, el mecanismo de seguridad entre cadenas también reduce en gran medida las barreras para la creación de nuevas cadenas. En términos generales, si una nueva cadena no tiene recursos particularmente excelentes, es posible que deba dedicar mucho tiempo a atraer validadores y cultivar el ecosistema. Pero en Cosmos, debido a que los validadores se pueden compartir con la cadena Hub, esto reduce en gran medida la presión sobre la nueva cadena y acelera el proceso de desarrollo.
2) Cuenta entre cadenas
En el ecosistema Cosmos, debido a que cada cadena de aplicaciones se rige por sí misma, las aplicaciones no pueden acceder entre sí. Por lo tanto, Cosmos proporciona una cuenta entre cadenas que permite a los usuarios acceder directamente a todas las cadenas de Cosmos que admiten IBC desde Cosmos Hub, de modo que los usuarios puedan acceder a las aplicaciones de la cadena B en la cadena A para lograr una interacción de cadena completa.
2.Lunares
Al igual que Cosmos, Polkadot se compromete a construir una infraestructura que permita a los desarrolladores implementar libremente nuevas cadenas y lograr la interoperabilidad entre cadenas.
1. Marco estructural
1.1 Cadena de relevos:
La cadena de relevos también puede denominarse cadena principal, que puede entenderse como el Sol en el sistema solar. Como parte central de toda la red, todas las cadenas secundarias giran a su alrededor. Como se muestra en la figura, una cadena de retransmisión (Relay Chain) está vinculada a muchas cadenas con diferentes funciones, como cadena de transacciones, cadena de almacenamiento de archivos, cadena de Internet de las cosas, etc.
Fuente:/polkadot-network/polkadot-the-foundation-of-a-new-internet-e 8800 ec 81 c 7
Esta es la solución de expansión jerárquica de Polkadot: una cadena de retransmisión se conecta a otra cadena de retransmisión para lograr una escalabilidad ilimitada. (Nota: a finales de junio de este año, el fundador de Polkadot, Gavin, propuso Polkadot 2.0, que puede cambiar una nueva perspectiva sobre la comprensión de Polkadot).
1.2 Paracadena:
La cadena de retransmisión tiene varias ranuras Para-Chain y la parachain está conectada a la cadena de retransmisión a través de estas ranuras, como se muestra en la figura:
Fuente:om/cn/learn/slot-auction-cn
Sin embargo, para obtener un espacio, las paracaídas participantes deben apostar su $DOT. Una vez que se obtiene una ranura, la parachain puede interactuar con la red principal de Polkadot a través de esta ranura y compartir seguridad. Vale la pena mencionar que el número de espacios es limitado y aumentará gradualmente. Inicialmente se espera que admita 100 espacios, y los espacios se reorganizarán periódicamente y se asignarán de acuerdo con el mecanismo de gobernanza para mantener la actividad de la ecología parachain.
Las paracaídas que obtienen tragamonedas pueden disfrutar de la seguridad compartida y la liquidez entre cadenas del ecosistema de Polkadot. Al mismo tiempo, la cadena paralela también debe proporcionar a cambio ciertos beneficios y contribuciones a la red principal de Polkadot, como realizar la mayor parte del procesamiento de transacciones de la red.
1.3 Hilos paralelos:
Los parathreads son otro mecanismo de procesamiento similar a los parachains, la diferencia es que los parachains tienen ranuras una por una y ranuras dedicadas que pueden ejecutarse continuamente sin interrupción. Pero los subprocesos paralelos se refieren a compartir una ranura entre subprocesos paralelos y turnarse para usar esta ranura para ejecutarse. **
Cuando un hilo paralelo obtiene el derecho a usar la ranura, puede funcionar temporalmente como una parachain, procesando transacciones, generando bloques, etc. Pero cuando finaliza este período de tiempo, la ranura debe liberarse para que la utilicen otros subprocesos paralelos.
Por lo tanto, los hilos paralelos no necesitan hipotecar activos durante mucho tiempo, solo necesitan pagar una tarifa determinada al adquirirlos en cada período de tiempo, por lo que se puede decir que es un método de pago por uso para usar la ranura. Por supuesto, si un parathread recibe suficiente apoyo y votos, se puede actualizar a parachain y obtener una ranura fija.
En comparación con las paracaídas, los hilos paralelos tienen costos más bajos y reducen el umbral de entrada para Polkadot, pero no hay garantía de cuándo se puede obtener el derecho a usar la ranura, que no es estable. Por lo tanto, ¿cuáles son más adecuadas para uso temporal o prueba de nuevas cadenas? Aquellas cadenas que esperan operar de manera estable aún deben actualizarse a paracaídas.
1.4 Puente adaptador:
La comunicación entre parachains solo se puede lograr a través de XCMP (se presentará más adelante) y comparten seguridad y el mismo consenso. ¿Y qué pasa si es una cadena heterogénea?
Una cosa que debe tenerse en cuenta aquí es que, aunque el marco proporcionado por Substrate hace que todas las cadenas conectadas al ecosistema de Polkadot sean isomorfas, con el desarrollo del ecosistema, inevitablemente habrá algunas cadenas públicas maduras con grandes sistemas que quieran participar. .en la ecología. Si les pide que vuelvan a implementar usando solo Substrate, es básicamente imposible. Entonces, ¿cómo implementar la transmisión de mensajes entre cadenas heterogéneas?
**Tome un ejemplo de la vida real. Si desea transferir archivos desde un teléfono Apple a un teléfono Android a través de una conexión, los enchufes son diferentes, por lo que necesita un convertidor para conectarse. Esta es la función real del puente de transferencia. ** Es una paracadena que es un intermediario entre la cadena de retransmisión y la cadena heterogénea (cadena externa). Los contratos inteligentes se implementan en la cadena paralela y la cadena heterogénea, lo que permite que la cadena de retransmisión interactúe con la cadena externa y logre operaciones cruzadas. Función de cadena.
2. Tecnologías clave
2.1 NENAAbuelo
BABE (Asignación ciega para extensión Blockchain) es el mecanismo de generación de bloques de Polkadot. En pocas palabras, selecciona validadores al azar para producir nuevos bloques, y a cada validador se le asigna un intervalo de tiempo diferente. Dentro de este intervalo de tiempo, solo los validadores asignados a este intervalo pueden producir bloques.
Instrucciones adicionales:
**Es decir, es un periodo de tiempo exclusivo. En el período de tiempo 1, el validador 1 asignado a este período de tiempo 1 es responsable de producir bloques. Cada validador tiene un período de tiempo y no puede producir bloques repetidamente. **
La ventaja de esto es que la asignación aleatoria maximiza la equidad porque todos tienen la oportunidad de ser asignados. Y como se conoce la franja horaria, todos pueden prepararse con anticipación y no habrá generación de bloques inesperados.
A través de este método de generación de bloques asignados aleatoriamente, se garantiza el funcionamiento ordenado y justo del ecosistema de Polkadot. Entonces, ¿cómo garantizar que todos los bloques adopten el mismo consenso? A continuación, presentaremos otro mecanismo de Polkadot: abuelo.
Grandpa es un mecanismo para finalizar bloques, que puede resolver el problema de bifurcación que puede ocurrir debido a diferentes consensos cuando BABE produce bloques. Por ejemplo, el nodo 1 y el nodo 2 de BABE produjeron bloques diferentes al mismo tiempo, lo que resultó en una bifurcación. En este momento entrará en juego el abuelo, que preguntará a todos los validadores: ¿Qué cadena creen que es mejor?
Los validadores observarán ambas cadenas y votarán por la que consideren mejor. La cadena con más votos eventualmente será confirmada por el abuelo y se convertirá en la cadena final, y la cadena rechazada será abandonada.
Por lo tanto, el abuelo es como el "abuelo" de todos los validadores, desempeñando el papel de quien toma la decisión final, eliminando el riesgo de bifurcaciones que pueda traer BABE. Permite a Blockchain finalizar una cadena en la que todos estén de acuerdo.
En resumen, BABE es responsable de producir bloques al azar y el abuelo es responsable de seleccionar la cadena final. Los dos trabajan juntos para permitir que el ecosistema de Polkadot funcione de forma segura.
2.2 Sustrato
Substrate es un marco de desarrollo escrito en lenguaje Rust, con componentes extensibles subyacentes proporcionados por FRAME, lo que permite a Substrate admitir una variedad de casos de uso diferentes. Cualquier cadena de bloques creada con Substrate no solo es compatible de forma nativa con Polkadot, sino que puede compartir seguridad y ejecutarse simultáneamente con otras cadenas paralelas. También ayuda a los desarrolladores a crear sus propios mecanismos de consenso exclusivos, modelos de gobernanza, etc., y cambia constantemente según las necesidades. de desarrolladores.
Además, Substrate proporciona una gran comodidad a la hora de actualizarse automáticamente, porque es un módulo independiente en tiempo de ejecución y se puede separar de otros componentes. Por lo tanto, este módulo en ejecución se puede reemplazar directamente al actualizar funciones. Como parachain que comparte consenso, siempre que la red y el consenso estén sincronizados con la cadena de retransmisión, la lógica operativa se puede actualizar directamente sin la necesidad de una bifurcación dura.
2.3 XCM
Si pudiera explicar XCM en una oración, sería: **Un formato de comunicación entre cadenas que permite que diferentes cadenas de bloques interactúen. **
Por ejemplo, Polkadot tiene muchas parachains. Si la parachain A quiere comunicarse con la parachain B, necesita empaquetar la información en formato XCM. **XCM es como un protocolo de lenguaje: si todos usan este protocolo para comunicarse, podrán comunicarse sin barreras. **
El formato XCM (Formato de mensajes de consenso cruzado) es el formato de mensaje estándar utilizado para la comunicación entre cadenas en el ecosistema de Polkadot, y de él se derivan tres métodos diferentes de entrega de mensajes:
Por ejemplo, dado que el formato XCM contiene variedad de información, como la cantidad de activos a transferir, la cuenta receptora, etc. Al enviar un mensaje, el canal HRMP o la cadena de retransmisión entregará este mensaje en formato XCM. Después de que la otra cadena paralela recibe el mensaje, verificará si el formato es correcto, luego analizará el contenido del mensaje y luego lo ejecutará de acuerdo con las instrucciones del mensaje, como transferir activos a una cuenta designada. Se logra la interacción en cadena y las dos cadenas se comunican con éxito.
Los puentes de comunicación como XCM son muy importantes para ecosistemas multicadena como Polkadot.
Después de comprender Cosmos y Polkadot, creo que comprendo su visión y marco. Entonces, a continuación explicaremos en detalle ¿cuáles son las soluciones Stack lanzadas por ETH L2?
三. pila OP
1. Marco estructural
Según la documentación oficial, OP Stack se compone de una serie de componentes y es mantenido por OP Collective, primero aparece como software detrás de la red principal y finalmente aparece como la supercadena Optimism y su gobernanza. L2 desarrollado utilizando OP Stack puede compartir seguridad, capas de comunicación y una pila de desarrollo común. Y los desarrolladores son libres de personalizar la cadena para atender cualquier caso de uso específico de blockchain.
De la figura, podemos entender que todas las hipercadenas de OP Stack se comunicarán a través del puente de supercadena OP Bridge y utilizarán Ethereum como consenso de seguridad subyacente para construir una supercadena L2 y dividir la estructura interna de cada hipercadena.
**1) Capa de disponibilidad de datos: **Las cadenas que usan OP Stack pueden usar este módulo de disponibilidad de datos para obtener sus datos de entrada. Debido a que todas las cadenas obtienen datos de esta capa, esta capa tiene un impacto significativo en la seguridad. Si no se puede recuperar un determinado dato de ella, es posible que no haya forma de sincronizar la cadena.
Como puede ver en esta figura, OP Stack usa Ethereum y EIP-4844. En otras palabras, esencialmente usa la cadena de bloques Ethereum para acceder a los datos.
**2) Capa de secuenciación: **El secuenciador determina cómo recopilar las transacciones de los usuarios y publicarlas en la capa de disponibilidad de datos, que se procesa utilizando un único secuenciador dedicado en OP Stack. Sin embargo, esto puede hacer que el clasificador no pueda retener transacciones durante demasiado tiempo. En el futuro, OP Stack modularizará el clasificador para que la cadena pueda cambiar fácilmente el mecanismo de clasificación.
En la figura puede ver un secuenciador único y un secuenciador múltiple. El secuenciador único permite que cualquiera actúe como secuenciador en cualquier momento (mayor riesgo). El secuenciador múltiple se extrae de un conjunto predefinido de posibles participantes. Luego, si elige varios secuenciadores, cada cadena desarrollada en base a OP Stack se puede seleccionar explícitamente.
3) Capa de derivación: Esta capa determina cómo procesar la entrada procesada de datos sin procesar para la disponibilidad de los datos y la transmite a la capa de ejecución a través de la API de Ethereum. Como se puede ver en la imagen, OP Stack se compone de Rollup e Indexer.
**4) Capa de ejecución: **Esta capa define la estructura de estado dentro del sistema OP Stack. Cuando la API del motor recibe información de la derivación, se activará la transición de estado. Se puede ver en la figura que en OP Stack, la capa de ejecución es EVM. Sin embargo, con una versión ligeramente modificada, también puede admitir otros tipos de VM. Por ejemplo, Pontem Network planea usar OP Stack para desarrollar un Move VM L2.
**5) Capa de liquidación: **Como sugiere el nombre, se utiliza para manejar el retiro de activos de la cadena de bloques, pero dicho retiro requiere demostrar el estado de la cadena objetivo a una cadena de terceros y luego procesar la activos según el estado. El núcleo es permitir que la cadena de terceros comprenda el estado de la cadena de destino.
Una vez que una transacción se publica y finaliza en la capa de disponibilidad de datos correspondiente, la transacción también se finaliza en la cadena OP Stack. Ya no se puede modificar ni eliminar sin destruir la capa de disponibilidad de datos subyacente. Puede ser que la transacción aún no haya sido aceptada por la capa de liquidación, porque la capa de liquidación necesita poder verificar el resultado de la transacción, pero la transacción en sí ya es inmutable.
Este también es un mecanismo para cadenas heterogéneas. Las cadenas heterogéneas tienen diferentes mecanismos de liquidación, por lo que en OP Stack, la capa de liquidación es de solo lectura, lo que permite que las cadenas heterogéneas tomen decisiones basadas en el estado de OP Stack.
En esta capa vemos que OP Stack utiliza la prueba de fallas en OP Rollup. Los proponentes pueden proponer un estado válido que cuestionen y, si no se demuestra que es incorrecto dentro de un período de tiempo, se considerará automáticamente correcto.
**6) Capa de gobernanza: **Como puede ver en la imagen, los tokens de firma múltiple + $OP se utilizan para la gobernanza en OP Stack. Por lo general, se utiliza firma múltiple para gestionar la actualización de los componentes del sistema Stack. Las operaciones se realizarán cuando todos los participantes participen en la firma. Los poseedores de tokens $OP pueden votar en la comunidad DAO para participar en la gobernanza.
**OP Stack es como una combinación de Cosmos y Polkadot: puede personalizar libremente cadenas exclusivas como Cosmos y también puede compartir seguridad y consenso como Polkadot. **
2. Tecnologías clave
2.1 Resumen de OP
OP Rollup garantiza la seguridad a través de desafíos de disponibilidad de datos y permite la ejecución paralela de transacciones. Los siguientes son los pasos de implementación específicos:
El usuario inicia una transacción en L2
El secuenciador empaquetará y procesará en lotes y luego sincronizará los datos de la transacción procesada y la nueva raíz de estado con el contrato inteligente implementado en L1 para verificación de seguridad. Cabe señalar que cuando Sequencer procesa una transacción, también generará su propio estado raíz y lo sincronizará con L1.
Después de la verificación, L1 devuelve los datos y la raíz del estado a L2, y el estado de la transacción del usuario se verifica y procesa de forma segura.
En este momento, OP Rollup considera que el estado raíz generado por Sequencer es optimista y correcto. Y se abrirá una ventana de tiempo para que el verificador cuestione y verifique si la raíz del estado generada por el secuenciador coincide con la raíz del estado de la transacción.
Si no hay ningún validador para verificar durante el período de tiempo, la transacción se considerará correcta automáticamente. Si se verifica un fraude malicioso, el secuenciador que procesa la transacción será sancionado en consecuencia.
2.2 Puente entre cadenas
a) Igual que la mensajería L2
Dado que OP Rollup utiliza prueba de fallas, la transacción debe esperar a que se complete el desafío. Este proceso lleva mucho tiempo y la experiencia del usuario es baja. Sin embargo, ZKP (prueba de conocimiento cero) es costoso y propenso a errores, y llevará algún tiempo implementar ZKP por lotes.
**Por lo tanto, para resolver el problema de comunicación entre las hipercadenas L2 OP, OP Stack propuso una prueba modular: utilizando dos sistemas de prueba para la misma cadena, los desarrolladores que crean pilas L2 pueden elegir libremente cualquier tipo de puente. **
Actualmente el OP proporciona:
Los desarrolladores pueden elegir el enfoque del puente de acuerdo con las necesidades de sus propias cadenas. Por ejemplo, para activos de alto valor, pueden elegir puentes de alta seguridad... Diversas tecnologías de puentes permiten el movimiento eficiente de activos y datos entre diferentes cadenas.
b) Transacciones entre cadenas
Las transacciones tradicionales entre cadenas se completan de forma asincrónica, lo que significa que es posible que la transacción no se ejecute por completo.
OP Stack propuso la idea de un clasificador compartido para este tipo de problema. Por ejemplo, si un usuario desea realizar un arbitraje entre cadenas, al compartir el secuenciador en la cadena A y la cadena B, puede llegar a un consenso sobre el momento de la transacción. Las tarifas se pagarán solo después de que las transacciones se carguen en el cadena, y los secuenciadores de ambos lados comparten el riesgo.
c)Transacción de hipervínculo
Debido a que la disponibilidad de datos de Ethereum L1 no es lo suficientemente escalable (la capacidad es limitada), no es escalable para publicar transacciones en la supercadena.
Por lo tanto, en OP Stack, se propone utilizar el protocolo Plasma para expandir la cantidad de datos a los que puede acceder la cadena OP, lo que puede reemplazar DA (disponibilidad de datos) para complementar más datos L1. La disponibilidad de los datos de las transacciones se reduce a la cadena Plasma y los compromisos de datos solo se registran en L1, lo que mejora enormemente la escalabilidad.
4. Pila ZK
1. Marco estructural
ZK Stack es un conjunto de códigos modulares, componibles y de código abierto creados con la misma tecnología subyacente (ZK Rollup) que zkSync Era, lo que permite a los desarrolladores personalizar sus propios hipervínculos L2 y L3 controlados por ZK.
Dado que ZK Stack es gratuito y de código abierto, los desarrolladores pueden personalizar los hipervínculos según sus necesidades específicas. Ya sea que elija una red de Capa 2 que se ejecute en paralelo con zkSync Era o una red de Capa 3 que se ejecute sobre ella, las posibilidades de personalización serán amplias.
Según Matter Labs, los creadores disfrutan de total autonomía para personalizar y dar forma a cada aspecto de la cadena, desde elegir un modelo de disponibilidad de datos hasta utilizar el ordenador descentralizado de tokens propio del proyecto.
Por supuesto, estas hipercadenas ZK Rollup operan de forma independiente, pero solo dependerán de Ethereum L1 para seguridad y verificación.
Fuente: Documento zkSync
Como se puede ver en la figura, cada hipervínculo debe utilizar el motor zkEVM de zkSync L2 para compartir seguridad. Se ejecutan varias cadenas ZKP al mismo tiempo y las pruebas de bloques se agregan en la capa de liquidación de L1. Al igual que los bloques apilados, se puede expandir continuamente para construir más L3, L4...
2. Tecnologías clave
1）Acumulación de ZK
La capa inferior de ZK Stack utiliza ZK Rollup como tecnología central. El siguiente es el proceso principal del usuario:
Los usuarios envían sus propias transacciones y Sequencer recopila las transacciones en lotes ordenados, genera certificados de validez (STARK/SNARK) por sí solo y actualiza el estado. El estado actualizado se enviará al contrato inteligente implementado en L1 y se verificará. Si se supera la verificación, también se actualizará el estado de los activos de la capa L1. La ventaja de ZK Rollup es que tiene la capacidad de realizar verificación matemática mediante prueba de conocimiento cero, que es superior en términos de tecnología y seguridad.
2) Puente de hipervínculo
Como se muestra en el marco estructural anterior, ZK Stack puede lograr una expansión inalámbrica y generar continuamente L3, L 4, etc. Entonces, ¿cómo debería lograrse la interoperabilidad entre hipervínculos?
**ZK Stack presenta el puente de hipercadena. Al implementar el contrato inteligente del puente compartido en L1, verifica la prueba Merkle de las transacciones que ocurren en la hipercadena. Es esencialmente lo mismo que ZK Rollup, excepto que cambia con respecto al L2 original. -L1.Se convirtió en L3-L2. **
ZK Stack admite contratos inteligentes en cada hipercadena y se llama entre sí de forma asíncrona entre cadenas. Los usuarios pueden transferir rápidamente sus activos de manera confiable en cuestión de minutos sin incurrir en ningún costo adicional. Por ejemplo, para procesar un mensaje en el hipervínculo receptor B, el hipervínculo emisor A debe finalizar su estado hasta el primer hipervínculo en el que A y B son comunes. Entonces, en la práctica, la latencia de comunicación de Hyperbridge es solo cuestión de segundos, Hyperchain puede completar bloques por segundo y ser más económico.
Fuente:ocs/reference/concepts/hyperscaling.html#l3s
No sólo eso, sino que como L3 puede aprovechar la tecnología de compresión, la prueba está empaquetada. L2 expandirá aún más el empaquetado, formando así un factor de compresión más considerable y un costo más bajo (compresión recursiva), que puede lograr transacciones transfronterizas sin confianza, rápidas (en unos pocos minutos) y baratas (costo de transacción única).
5. Polígono 2.0
Polygon es una solución especial L2, técnicamente L1, como cadena lateral de Ethereum. El equipo de Polygon anunció recientemente el plan Polygon 2.0, que ayudará a los desarrolladores a crear sus propias cadenas ZK L2 usando ZK y unificarlas a través de un novedoso protocolo de coordinación entre cadenas, haciendo que los usuarios sientan que toda la red está usando una sola cadena.
Polygon 2.0 se compromete a admitir un número ilimitado de cadenas, y las interacciones entre cadenas pueden ocurrir de forma segura e instantánea sin suposiciones de seguridad o confianza adicionales, lo que permite una escalabilidad ilimitada y liquidez unificada.
1. Marco estructural
Fuente: Blog de polígono
Polygon 2.0 consta de 4 capas de protocolo:
1) Capa de compromiso
La capa de compromiso es un protocolo basado en PoS (Proof of Stake), que utiliza el compromiso $MATIC para lograr una gobernanza descentralizada para gestionar eficientemente los validadores y mejorar la eficiencia de los mineros.
Como puede verse en la figura, Polygon 2.0 propone un administrador de validación y un administrador de cadena en la capa de compromiso.
La capa de participación ya ha formulado la estructura subyacente de las reglas correspondientes para cada cadena, y los desarrolladores solo necesitan centrarse en el desarrollo de sus propias cadenas.
Fuente: Blog de polígono
2) Capa de interoperabilidad
Los protocolos entre cadenas son cruciales para la interoperabilidad de toda la red. Cómo llevar a cabo mensajes entre cadenas de forma segura y sin problemas es algo que cada solución de hipervínculo debería seguir mejorando.
Actualmente, Polygon utiliza dos contratos, el agregador y la cola de mensajes, como soporte.
Una vez que el agregador acepta la prueba ZK, la cadena de recepción puede comenzar a aceptar mensajes de manera optimista, porque toda la cadena de recepción cree en la prueba ZK, logrando así una entrega de mensajes perfecta, etc.
3) Capa de ejecución
La capa de ejecución permite que cualquier cadena Polygon genere lotes de transacciones ordenadas, también llamados bloques. La mayoría de las redes blockchain (Ethereum, Bitcoin, etc.) lo utilizan en un formato similar.
La capa de ejecución tiene múltiples componentes, tales como:
Dado que esta capa está mercantilizada pero es relativamente compleja de implementar, las implementaciones de alto rendimiento existentes (como Erigon) deben reutilizarse siempre que sea posible.
4) Capa de prueba
La capa de prueba genera pruebas para cada polígono. Es un protocolo de prueba ZK flexible y de alto rendimiento que generalmente tiene los siguientes componentes:
2. Tecnologías clave
Fuente: Blog de polígono
1) Validación de zkEVM
En la actualización Polygon 2.0, el equipo lo actualizó a zkEVM validium conservando el POS Polygon original.
Fuente: Blog de polígono
Según la ciencia popular simple aquí, Validium y Rollup son soluciones de Capa 2 y su propósito es expandir la capacidad de transacción de Ethereum y acortar el tiempo de transacción. Compara los dos:
Se puede entender que Validium es un Rollup con menor costo y mayor escalabilidad. Sin embargo, el principio operativo de Polygon zkEVM (mecanismo Polygon POS) antes de la actualización era (ZK) Rollup, y también logró resultados considerables. En sólo 4 meses desde su lanzamiento, su TVL se ha disparado a 33 millones de dólares.
Fuente: Defilama
A largo plazo, el costo de generar pruebas para zkEVM basado en Polygon PoS puede convertirse en un obstáculo para una futura expansión. Aunque el equipo de Polygon ha estado trabajando arduamente para reducir el costo de Batch, se ha reducido a una cifra extremadamente impresionante: lo que demuestra que el costo de 10 millones de transacciones es de solo $0,0259. Pero Vailidium cuesta menos, así que ¿por qué no utilizarlo?
Polygon ha publicado documentos oficialmente. En versiones futuras, **Validium asumirá el trabajo de POS anterior y también conservará el POS. La función principal de su verificador de POS es garantizar la disponibilidad de datos y clasificar las transacciones. **
El zkEVM Validium actualizado proporcionará una escalabilidad muy alta y un costo muy bajo. Porque es muy adecuado para aplicaciones con gran volumen de transacciones y bajas tarifas de transacción, como Gamefi, Socialfi y DeFi, etc. Para los desarrolladores, no se requiere ninguna operación, solo necesitan actualizar junto con la red principal para completar la actualización de Validium.
2) resumen de zkEVM
Actualmente, Polygon PoS (que pronto se actualizará a Polygon Validium) y Polygon zkEVM Rollup son las dos redes públicas del ecosistema Polygon. Este sigue siendo el caso después de la actualización, con el beneficio adicional de que ambas redes utilizan tecnología zkEVM de vanguardia, una como agregación y la otra como verificación.
Polygon zkEVM Rollup ya proporciona el más alto nivel de seguridad, pero a costa de un costo ligeramente mayor y un rendimiento limitado. Sin embargo, es muy adecuado para aplicaciones que manejan transacciones de alto valor y priorizan la seguridad, como las DeFi Dapps de alto valor.
六. decisión de órbita
Arbitrum es actualmente la cadena pública L2 más importante, desde su lanzamiento en agosto de 2021, su TVL ha superado los 5.100 millones de dólares y, como L2 líder, ocupa casi el 54% de la cuota de mercado.
Arbitrum lanzó la versión Orbit en marzo de este año. Anteriormente, Arbitrum lanzó una serie de productos ecológicos:
Hoy nos centraremos en Arbitrum Orbit.
1. Marco estructural
Originalmente, si los desarrolladores querían usar Arbitrum Orbit para crear una red L2, primero emitían una propuesta, que sería votada por Arbitrum DAO. Si se aprobaba, se crearía una nueva cadena L2. Sin embargo, no se requiere permiso para desarrollar L3, 4, 5... en L2. Cualquiera puede proporcionar un marco sin permiso para implementar cadenas personalizadas en Arbitrum L2.
Fuente: documento técnico
Como puede ver, Arbitrum Orbit también se esfuerza por permitir a los desarrolladores personalizar su propia cadena Oribit L3 basada en la Capa 2, como Arbitrum One, Arbitrum Nova o Arbitrum Goerli. Los desarrolladores pueden personalizar el acuerdo de privacidad, la licencia, el modelo económico de tokens, la gestión comunitaria, etc. de esta cadena, brindando a los desarrolladores la mayor autonomía.
Entre ellos, lo que es más notable es que Oribit permite que la cadena L3 utilice el Token de esta cadena como unidad de liquidación de tarifas, desarrollando así efectivamente su propia red.
2. Tecnologías clave
1）Agrupar AnyTrust
Estos dos protocolos admiten Arbitrum One y Arbitrum Nova respectivamente. Como se presentó anteriormente, Arbitrum One es un paquete acumulativo de red principal central; Arbitrum Nova es el segundo paquete acumulativo de red principal, pero está conectado al protocolo AnyTrust. Se puede introducir introduciendo "seguridad supuestos" (Trust Assumption) para acelerar la liquidación y reducir costes.
Entre ellos, Arbitrum Rollup es un OP Rollup, por lo que sin más explicaciones, realizaremos un análisis detallado del protocolo AnyTrust.
El protocolo AnyTrust gestiona principalmente la disponibilidad de datos y está aprobado por una serie de organizaciones de terceros como DAC (Comité de Disponibilidad de Datos). Y al introducir "supuestos de seguridad", los costos de transacción se reducen considerablemente. La cadena AnyTrust se ejecuta en Arbitrum One como una cadena lateral, con costos más bajos y velocidades de transacción más rápidas.
Entonces, ¿qué es exactamente un “supuesto de confianza”? ¿Por qué su existencia reduce los costos de transacción y requiere menos confianza?
Según la documentación oficial de Arbitrum, la cadena AnyTrust es operada por un comité de nodo y utiliza suposiciones mínimas para determinar cuántos miembros del comité son honestos. Por ejemplo, digamos que el comité está formado por 20 personas y se supone que al menos 2 miembros son honestos. En comparación con BFT, que requiere que ⅔ de los miembros sean honestos, AnyTrust reduce el umbral de confianza al mínimo.
En una transacción, dado que el comité promete proporcionar datos de la transacción, el nodo no necesita registrar todos los datos de la transacción L2 en L1, solo necesita registrar el valor hash del lote de transacciones, lo que puede ahorrar en gran medida el costo. de resumen. . Es por eso que la cadena AnyTrust puede reducir los costos de transacción.
Respecto al tema de la confianza, como se mencionó anteriormente, se supone que solo 2 de los 20 miembros son honestos, y la suposición es cierta. Siempre que 19 de los 20 miembros del comité firmen para comprometerse a que el acuerdo sea correcto, se podrá ejecutar de forma segura. Entonces, incluso si el miembro que no firmó es honesto, uno de los 19 miembros que firmaron debe ser honesto.
¿Qué debemos hacer si los miembros no firman o un gran número de miembros se niegan a cooperar, lo que provoca que no funcione correctamente? La cadena AnyTrust aún puede ejecutarse, pero recurrirá al protocolo Rollup original y los datos aún se publican en Ethereum L1. Cuando el comité funcione correctamente, la cadena volverá a un modo más económico y rápido.
Aribtrum lanzó este protocolo con la esperanza de satisfacer las necesidades de aplicaciones que requieren alta velocidad de procesamiento y bajo costo, como el campo Gamefi.
2）Nitro
Nitro es la última versión de la tecnología Arbitrum. Su elemento principal es el Prover, que realiza la tradicional prueba interactiva de fraude en Arbitrum a través del código WASM. Y todos sus componentes están completos. Arbitrum completó la actualización a finales de agosto de 2022, migrando/actualizando sin problemas el Arbitrum One existente a Aribitrum Nitro.
Nitro tiene las siguientes características:
Estas características de Oribit brindan soporte técnico para los casos de uso de Arbitrum L3 y L 4. Arbitrum puede atraer desarrolladores que buscan personalización para crear sus propias cadenas personalizadas.
七. Pila Starknet
El cofundador de StarkWare, Eli Ben-Sasson, dijo en la conferencia EthCC en París que Starknet pronto lanzará Starknet Stack, permitiendo que cualquier aplicación implemente su propia cadena de aplicaciones Starknet sin permiso.
Tecnologías clave como la prueba STARK en Starknet, el lenguaje de programación Cairo y la abstracción de cuentas nativas brindan una garantía poderosa para el rápido desarrollo de Starknet. Cuando los desarrolladores usan Stack para personalizar su propia cadena de aplicaciones Starknet, es escalable y libremente configurable, lo que puede expandir en gran medida el rendimiento de la red y aliviar la congestión de la red principal.
Aunque Starknet es actualmente sólo una idea preliminar, los documentos técnicos oficiales aún no se han publicado. Sin embargo, Madara Sequencer y LambdaClass se están desarrollando como componentes Sequencer y Stack compatibles con Starknet, respectivamente, para adaptarse mejor a Starknet. Los funcionarios también están trabajando arduamente en el próximo Starknet Stack, incluido el desarrollo de nodos completos/motores de ejecución/verificación y otros componentes.
Vale la pena señalar que no hace mucho, StarkNet presentó una propuesta de "Protocolo descentralizado simple", con la esperanza de cambiar el estado actual del secuenciador de operación de punto único actual de L2. Ethereum está descentralizado, pero los L2 no, y sus ingresos MEV hacen que Sequencer sea malo.
StarkNet enumeró algunas soluciones en la propuesta, tales como:
Además, existen planes para la certificación ZK, actualizaciones de estado de L1, etc., combinado con la gran iniciativa anterior para ayudar a la comunidad a operar el código Prover sin permiso, la propuesta de StarkNet busca resolver la falta de descentralización de L2 y tratar de equilibrar la inconsistencia de la cadena de bloques Quizás el problema triangular sea realmente notable.
Fuente: fuente electrónica/the-starknet-stacks-growth-spurt/
8. Conclusión
En este capítulo, a través de la explicación técnica de CP y las principales pilas de capa 2, podemos encontrar que la solución actual de pila de capa 2 puede resolver eficazmente el problema de expansión de Ethereum, pero también trae una serie de desafíos y problemas, especialmente en términos de compatibilidad Sexualmente. La tecnología en la solución Stack de L2 no es tan madura como la de CP, e incluso vale la pena aprender el concepto técnico de CP de hace tres o cuatro años de las L2 actuales. Entonces, a nivel técnico, el CP actual sigue siendo muy superior a la Capa 2. Sin embargo, la tecnología avanzada por sí sola no es suficiente. En el próximo segundo artículo, discutiremos las ventajas, desventajas y características respectivas de CP y L2 Stacks desde los aspectos del valor simbólico y el desarrollo ecológico, para mejorar la perspectiva de los lectores.
Referencias:
/@eterno1 997 L
/polkadot-network/un-breve-resumen-de-todo-el-sustrato-y-polkadot-f1f21071499d
ocs/reference/concepts/hyperscaling.html#qué-son-las-hipercadenas
/fuera de la cadena