El protocolo nativo sin confianza NCRC de Opside en foco

Opside ha implementado con éxito NCRC en la red de prueba. Ahora cualquiera puede experimentarlo en el sitio web oficial en https://pre-alpha-assetshub.opside.network/.

¿Por qué necesitamos una comunicación acumulativa cruzada sin confianza?

Los rollups han ganado mucha atención y adopción por su capacidad para mejorar la escalabilidad de blockchain, reducir los costos de transacción y mejorar la eficiencia general. Opside proporciona servicios ZK-RaaS para aplicaciones Web3, lo que permite a los desarrolladores crear sus propios paquetes acumulativos a través de Opside Rollup Launchbase. En esta era de múltiples Rollups, anticipamos una coexistencia creciente de varios Rollups, lo que hace que la interoperabilidad perfecta entre diferentes soluciones de Capa 2 sea crucial.

Actualmente, las interacciones entre Rollups permanecen relativamente aisladas y carecen de comunicación entre cadenas en tiempo real e interoperabilidad de activos. Este aislamiento ha dado lugar a un panorama fragmentado, donde los activos están confinados en paquetes acumulativos específicos, lo que restringe su libre flujo y utilización en diferentes redes.

La ausencia de una comunicación eficiente entre los Rollups no solo limita el potencial de los Rollups individuales sino que también afecta la experiencia general del usuario. Los usuarios que intentan transferir activos o ejecutar transacciones entre cadenas entre Rollups se enfrentan a procesos engorrosos y que requieren mucho tiempo. Esta experiencia subóptima debilita el atractivo de los Rollups y, hasta cierto punto, obstaculiza la adopción generalizada de soluciones de escalamiento de Capa 2.

Las soluciones puente entre cadenas existentes a menudo implican la implementación de nuevos conjuntos de contratos entre cadenas en cadenas Rollup y la utilización de incentivos de liquidez multicadena para lograr la funcionalidad de activos entre cadenas. Sin embargo, estas soluciones no son universalmente aplicables para las interacciones entre cadenas basadas en mensajes y conllevan riesgos de centralización y confianza.

Para desbloquear plenamente el potencial de la era de múltiples Rollup, existe una necesidad urgente de un protocolo de comunicación entre Rollup universal y sin confianza.

La solución de Opside: comunicación nativa cruzada acumulada

De hecho, cada ZK-Rollup viene inherentemente con un puente L1<>L2, al que nos referimos como puente Nativo. A diferencia de los puentes de terceros que utilizan esquemas basados en liquidez, el puente Native opera como el mecanismo único de cadena cruzada "mint-burn". Garantiza la seguridad a través de pruebas de conocimiento cero mientras mantiene la falta de confianza. Todos los activos en un Rollup se originan a partir de transacciones de depósito a través del puente nativo y reciben el máximo respaldo de seguridad del mismo.

Creemos firmemente en el principio de la Navaja de Occam: "Las entidades no deben multiplicarse más allá de lo necesario". Los puentes de terceros pueden ofrecer experiencias entre cadenas más baratas y rápidas, pero introducen costos de confianza y riesgos de seguridad adicionales. El reciente incidente de Multichain es un ejemplo de ello. Por lo tanto, desde el principio, la inspiración de Opside para la comunicación entre paquetes acumulativos fue sencilla: aprovechar el puente nativo directamente para lograr la interoperabilidad de varios paquetes acumulativos, en lugar de introducir un puente adicional de terceros. Este concepto dio origen al protocolo NCRC (Native Cross Rollup Communication).

Requisitos previos para NCRC

Para habilitar NCRC entre varios paquetes acumulativos, se deben cumplir los dos requisitos previos siguientes:

• Estos Rollups deben pertenecer al tipo ZK-Rollup.

• Estos Rollups deben residir en la misma L1.

  
  

Los rollups que satisfacen estas dos condiciones poseen teóricamente el mismo nivel de seguridad que el L1 subyacente. De manera similar, el nivel de seguridad del puente nativo entre estos Rollups es idéntico y no requiere confianza entre ellos. Todas las transacciones del NCRC se verifican mediante pruebas de validez, lo que sirve como fuente fundamental de garantía de seguridad para el NCRC.

Contrato de reconocimiento acumulativo (RRC)

En agosto de 2023, varios ZK-Rollups se activaron en Mainnet, incluidos Polygon zkEVM, zkSync era, Linea y más. Sin embargo, estos ZK-Rollups son independientes y no están relacionados, lo que lleva a la fragmentación de los activos de los usuarios. La razón fundamental de este problema radica en el hecho de que sus contratos en L1 (Ethereum Mainnet) no están relacionados. Siguen sin ser conscientes de la existencia de los demás y no pueden comunicarse directamente a través de puentes acumulativos nativos.

Por lo tanto, el primer paso que debemos dar es implementar un contrato especializado en L1 para permitir que los Rollups se descubran y reconozcan entre sí. Esto se conoce como RRC (Contrato de reconocimiento acumulativo). El RRC es responsable de gestionar todos los ZK-Rollups participantes en el NCRC, incluidas las adiciones, pausas y salidas de Rollups. A cada resumen dentro del RRC se le asigna un ID de resumen dedicado, mientras que el ID de L1 permanece fijo en 0.

Al iniciar transacciones entre paquetes acumulativos a través del puente nativo en un paquete acumulativo, las direcciones pueden especificar el ID del paquete acumulativo de destino:

• Si el ID del resumen es 0, significa cruzar el mensaje a L1, como un retiro.
• Si el ID del Rollup no es 0, indica que se envía el mensaje a otro Rollup.

Opside implementará un contrato RRC en cada capa L1 y permitirá que los ZK-Rollups correspondientes se unan o salgan sin permiso. Este contrato RRC se utilizará para mantener información para cada ID de Rollup, incluida la dirección del contrato puente en L1. Es importante tener en cuenta que el contrato RRC únicamente proporciona servicios de recuperación de datos y no interactúa directamente con activos entre cadenas.

Compatibilidad con contratos y servicios inteligentes de Native Bridge

Generalmente, el puente nativo de Rollup se divide en tres componentes: el contrato de puente en L1, el contrato de puente en L2 y un servicio de puente responsable de la retransmisión de mensajes. El protocolo NCRC aprovecha estos componentes en el nivel subyacente y agrega encapsulación de nivel superior. Las principales modificaciones son las siguientes:

• Contrato puente en L2: aunque se conservan los métodos originales, se agrega un nuevo método denominado bridgeAsset. Este método permite a los usuarios especificar el ID del paquete acumulativo de destino en el parámetro de red de destino.

• Contrato de puente en L1: se encapsula un nuevo método para manejar los mensajes entre cadenas del nuevo método bridgeAsset. El contrato puente, basado en el ID de Rollup que se encuentra en el contrato RRC, localiza la información del Rollup de destino y transfiere los activos de cadena cruzada al contrato puente del Rollup de destino. Los activos entre cadenas se depositan allí en el Rollup de destino.

• Servicio puente: responsable de la retransmisión de mensajes y cobra tarifas a los usuarios por transacciones entre paquetes acumulativos.

  
  

Una vez que un Rollup completa la adaptación de compatibilidad relacionada con NCRC mencionada anteriormente, puede registrarse en el RRC para unirse a la red de comunicación nativa entre Rollup.

Proceso de transacciones nativas cruzadas

Para los usuarios, el funcionamiento de NCRC es totalmente coherente con el del puente nativo de Rollup. Iniciar una transacción cruzada desde Rollup1 a Rollup2 es un proceso automatizado que incluye los siguientes pasos:

1. El iniciador, Usuario1, en Rollup1, invoca el método bridgeAsset del puente nativo para iniciar la transacción entre cadenas. El parámetro de red de destino en esta transacción se establece en el ID de resumen de Rollup2. Este ID de resumen se utilizará para recuperar la dirección del contrato de puente L1 correspondiente. Si el ID del resumen es 0, significa que la red de destino es L1.

   
   

2. Posteriormente, esta transacción es empaquetada por Sequencer1 de Rollup1. El iniciador, Usuario1, asume el costo de la transacción entre paquetes acumulativos y se lo paga al Secuenciador1 en el Rollup1. El servicio Bridge de Rollup1 luego transfiere el activo de cadena cruzada al contrato puente Rollup1 en L1. En este punto, tanto Rollup1 como L1 completan las operaciones de grabación y liberación del activo.

   
   

3. Para completar la transferencia de activos entre paquetes acumulativos, el servicio Bridge de Rollup1 consulta el contrato RRC para recuperar información sobre el Rollup2 de destino correspondiente al parámetro de red de destino. Esta información proporciona la dirección del contrato puente L1 de Rollup2. Luego, el contrato puente de Rollup2 toma el control de estos activos y los asigna a Rollup2 mediante el método bridgeAsset.

   
   

4. Finalmente, una vez que la transacción se empaqueta exitosamente y se genera la prueba, el servicio Bridge de Rollup2 ejecuta la operación ClaimAsset. En consecuencia, los activos entre cadenas iniciados por Rollup1 llegan de forma segura a la dirección designada en Rollup2.

Vale la pena mencionar que durante todo el proceso entre cadenas, los activos del usuario fluyen a través de la siguiente ruta: Rollup1 -> Contrato puente L1 de Rollup1 -> Contrato puente L1 de Rollup2 -> Rollup2. En otras palabras, los activos del usuario no pasan por ningún protocolo de terceros; aprovechan el puente nativo de Rollup. Todo el proceso es seguro y sin confianza.

Cuando los usuarios ejecutan operaciones entre cadenas en Rollup1 y seleccionan Rollup2 como destino, el proceso técnico en realidad involucra tres entidades: Rollup1, L1 y Rollup2. Sin embargo, no es necesario que los usuarios sean conscientes de la existencia de L1 en este proceso; su experiencia es simplemente un cruce directo de Rollup1 a Rollup2. La realidad subyacente es que los activos entre cadenas se someten a dos operaciones puente en L1, creando una conexión perfecta de Rollup1 a Rollup2 en la percepción del usuario. Durante este proceso, las operaciones en L1 se manejan automáticamente y los usuarios no necesitan realizar ninguna acción adicional. Desde la perspectiva del usuario, su Rollup actual puede realizar operaciones entre cadenas tanto en L1 como en cualquier otro Rollup. Este diseño mejora la fluidez de la experiencia del usuario al tiempo que oculta las complejidades subyacentes.

¡NCRC ya está disponible en la red de prueba de Opside!

Opside ha implementado con éxito la comunicación nativa cruzada en Testnet. Cualquiera puede ahora experimentarlo en el sitio web oficial en

https://pre-alpha-assetshub.opside.network/ También damos la bienvenida a usuarios y desarrolladores para que nos ayuden a identificar posibles errores y riesgos de seguridad y nos brinden sugerencias valiosas.

Creemos que la comunicación cruzada nativa sin confianza no solo compartirá de forma segura la liquidez entre todos los Rollups, sino que también proporcionará una sólida interoperabilidad entre múltiples Rollups, abriendo nuevas posibilidades para aplicaciones descentralizadas y protocolos DeFi .