La escalabilidad de Blockchain y las soluciones propuestas han estado a la vanguardia de las conversaciones en las redes sociales durante media década. Por ejemplo, la empresa de software israelí Starkware y el cofundador de Ethereum, Vitalik Buterin, hablaron recientemente sobre la idea de la "Capa 3" como una de estas soluciones. Starkware dice que múltiples Capas 3 se montarán sobre la Capa 2, y las soluciones de "capas fractales" se pueden construir sobre las Capas 3.
El proyecto Opside lanzó recientemente sus planes para una arquitectura de tres capas. Esto permitirá a los desarrolladores crear aplicaciones de cadena de bloques que tengan acceso a velocidades más rápidas y transacciones más económicas. Esto es posible gracias a la cadena Opside, que se denomina solución de Capa 2 porque se asienta sobre varias plataformas de Capa 1 (como Ethereum, Binance Chain, Bitcoin, etc.) y las utiliza como capa de liquidación. La funcionalidad de "Capa 3" lleva esto aún más lejos, lo que permite a los desarrolladores crear un conjunto de "resumen como servicio". Esta arquitectura brinda a la capa 2 una gama más completa de activos de puentes y la capacidad de crecer indefinidamente a partir de acumulaciones.
Para manejar las llamadas de contrato entre múltiples cadenas, Opuesto desarrolló un protocolo para manejar todas las llamadas de contrato. También está en desarrollo la votación DAO que permite a la comunidad de Opside votar qué cadenas públicas usar para la liquidación de la Capa 1.
Las soluciones de Capa 2 dependen de la descentralización de su contraparte de Capa 1 para proporcionar tiempos de transacción más rápidos y tarifas de gas más bajas. Parece ser aceptable para la mayoría de las comunidades de blockchain tener una capa centralizada encima de su plataforma, siempre que cada transacción se liquide en el nivel de la Capa 1. La eficiencia se logra “agrupando” un conjunto de transacciones y liquidándolas más tarde. La capa 3 amplifica este modelo, lo que permite una rentabilidad aún mayor mientras mantiene la velocidad de la red de la capa 2.
La Capa 3 tiene el potencial de ofrecer costos tan bajos que los proyectos creados incluso en redes de Capa 2 no tendrán que implementar sus propias Capas 1 para reducir las tarifas de liquidación. Estas aplicaciones, como Axie y dYdX Decentralized Exchange, tenían que hacer esto, simplemente porque su modelo dependía de los tiempos de transacción más rápidos y las tarifas más bajas. Si se implementa en un paquete acumulativo de Capa 3, podría evitar la necesidad de otra cadena de bloques.
Capa 1: puentes multicadena
Opside admite un Liquidity-Bridge descentralizado más rápido y económico para lograr la interoperabilidad de activos en más cadenas. Liquidity-Bridge consta de nodos sin permiso que llegan a un consenso sobre los mensajes entre cadenas a través de MPC. El grupo de liquidez brinda una velocidad más rápida y admite más cadenas públicas y sus activos en la cadena.
Además, Opside establecerá conexiones con varias cadenas públicas de la capa de activos a través del ZK-Bridge sin confianza. En comparación con otros esquemas puente, el esquema ZK-Rollup involucra más sistemas a prueba de ZK. En la operación de cadena cruzada, es necesario generar pruebas ZK para garantizar la corrección del proceso de ejecución además de una "ejecución" general. Las operaciones de depósito y retiro de ZK-Bridge se "solidifican" como un circuito, y la lógica del circuito queda completamente expuesta.
Layer2: una cadena compatible con rollup
La cadena Opside, o Capa 2, es una cadena compatible con EVM y fácil de acumular. La cadena Opside hará algunas optimizaciones profundas para los paquetes acumulativos.
El resumen nativo es algo similar a la arquitectura de Polkadot. Una vez que un resumen registra un espacio, el resumen se convierte en un resumen nativo. Por el contrario, la arquitectura Polkadot tiene la desventaja de que el consenso de la parachain depende del conjunto de validadores asignado. Hay una correlación entre la seguridad y el número de validadores. Si algunos validadores se desconectaron, las paracadenas cuyos grupos de validadores son demasiado pequeños para validar un bloque omitirán esos bloques o incluso se detendrán hasta que se resuelva la situación. Opside no tiene este problema porque la capa 2 recopila datos de todos los resúmenes nativos en la capa 3 y verifica todas las pruebas de zk. Opside Chain es más seguro y descentralizado con todos los rollups como un todo más compacto, compartiendo la misma capa de consenso.
Hay 64 contratos implementados previamente como "ranuras acumuladas", que serán llamados directamente por transacciones por lotes y pruebas de acumulaciones. Estos espacios llamarán a un contrato precompilado para la verificación de pruebas y actualizarán las raíces del estado local si tienen éxito. El contrato precompilado puede acelerar la verificación de pruebas de conocimiento cero con optimizaciones en códigos binarios.
La capa 2 y la capa 3 de la arquitectura Opside comparten una mecanismo de consenso con un híbrido de PoS y PoW.
- PoS: en la capa 2, cualquiera puede convertirse en validador haciendo staking y luego tener la oportunidad de producir bloques de Opside Chain. El PoS es comprobable y los validadores envían periódicamente pruebas de PoS a la capa 1. Los validadores pueden obtener la recompensa por bloque y la recompensa por apostar por esta parte del PoS.
- PoW: Los validadores de la capa 2 no solo producirán bloques de Opside Chain, sino que también generarán pruebas zk para cada acumulación nativa de la capa 3 de acuerdo con las reglas de punto de vista. Los validadores obtendrán la recompensa IDE por generar con éxito la prueba zk, que es algo similar a PoW. Los validadores pueden obtener una bonificación adicional por esa parte de la recompensa apostando más tokens en el contrato del sistema.
Más importante aún, en Opside, después de completar el registro de las ranuras, los paquetes acumulativos nativos comparten un árbol de estado mundial entre sí y la misma cola de mensajes global. Por lo tanto, es posible la interoperabilidad nativa de resúmenes cruzados en Opside. Imagine que desea prestar USDC a un contrato de préstamo en el Rollup A y luego ir a DEX en el Rollup B para negociar y comprar BTC. En Opside, ya no necesita retirar activos del Rollup A a L1 y luego recargarlos de L1 al Rollup B. En su lugar, puede llamar al método de contrato del Rollup B directamente en el Rollup A. Esto hará que todo el proceso sea mucho más rápido. más barato y más seguro.
Layer3: ZK-Rollups descentralizados
En la tercera capa, Opside ayuda a los desarrolladores a implementar sus propios paquetes acumulativos, mientras que Opside también proporciona un solución de acumulación descentralizada basado en RaaS mencionado anteriormente. Los desarrolladores pueden elegir libremente cuál adoptar. Esta solución no requiere confianza ni permiso. Cualquiera puede enviar lotes L2 y pruebas a L1.
Para resumir, la arquitectura de "capa base <- opside <- rollup" de Opside tiene la ventaja de la variedad de activos y la escalabilidad infinita. Podría ser otra opción para solucionar los problemas de escalabilidad de las aplicaciones web3. En comparación con las costosas capas 2 basadas en resúmenes, es más adecuado para aplicaciones de alto rendimiento como los juegos.
Descargo de responsabilidad: este artículo se proporciona solo con fines informativos. No se ofrece ni pretende utilizarse como asesoramiento legal, fiscal, de inversión, financiero o de otro tipo.
Fuente: https://cryptodaily.co.uk/2023/01/opside-network-introduces-3-layer-architecture-for-blockchain-applications