Prerrequisitos y compatibilidad

Prerrequisitos del NCRC

Para habilitar el NCRC entre múltiples Rollups, se deben cumplir los siguientes dos prerrequisitos:

• Estos Rollups deben pertenecer al tipo ZK-Rollup.

• Estos Rollups deben residir en el mismo L1.

Los Rollups que cumplen estas dos condiciones teóricamente poseen 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, que sirven como la fuente fundamental de garantía de seguridad para el NCRC.

Contrato de Reconocimiento de Rollup (RRC)

Hasta agosto de 2023, varios ZK-Rollups se han lanzado en la mainnet, incluyendo Polygon zkEVM, zkSync era, Linea y otros 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. No tienen conocimiento de la existencia del otro y no pueden comunicarse directamente a través de los puentes nativos de Rollup.

Por lo tanto, el primer paso que debemos tomar es implementar un contrato especializado en L1 para permitir que los Rollups descubran y reconozcan a los demás. Esto se conoce como el Contrato de Reconocimiento de Rollup (RRC, por sus siglas en inglés). El RRC es responsable de gestionar todos los ZK-Rollups participantes en el NCRC, incluyendo adiciones, pausas y salidas de Rollups. A cada Rollup dentro del RRC se le asigna un ID de Rollup dedicado, mientras que el ID para L1 permanece fijo en 0.

Al iniciar transacciones entre Rollups a través del puente nativo en un Rollup, las direcciones pueden especificar el ID del Rollup de destino:

• Si el ID del Rollup es 0, significa que se está enviando el mensaje a L1, como por ejemplo una retirada.

• Si el ID del Rollup no es 0, indica que se está enviando el mensaje a otro Rollup.

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

Compatibilidad con contratos inteligentes y servicios de puente nativo

En general, el puente nativo de un 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 relé de mensajes. El protocolo NCRC aprovecha estos componentes a nivel subyacente y agrega una encapsulación a nivel superior. Las principales modificaciones son las siguientes:

• Contrato de puente en L2: Manteniendo los métodos originales, se agrega un nuevo método llamado bridgeAsset. Este método permite a los usuarios especificar el ID del Rollup de destino en el parámetro destinationNetwork.

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

• Servicio de puente: Responsable del relé de mensajes y cobra a los usuarios tarifas por las transacciones entre Rollups.

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