Capa 3: Arquitectura multinivel y expansión tecnológica

TL;DR1) Dado que tanto la capa 2 como la capa 3 teóricamente dependen de la red principal para el liquidación, una suposición común es que la capa 3 primero comprime los datos y luego los envía a la capa 2 para una compresión secundaria, básicamente colocando un Rollup encima de otro Rollup. Este enfoque ha sido criticado y cuestionado porque si uno imaginara que la capa 4 y la capa 5 usaran una arquitectura similar, llevaría a un callejón sin salida, ya que los datos no se pueden comprimir indefinidamente.

2. En realidad, la interacción entre la capa 3 y la capa 2 no necesariamente implica comprimir y luego volver a comprimir. En las estrategias de capa 3 planificadas por múltiples pilas de capa 2 como Arbitrum y zkSync, la capa 3 se define como una cadena de aplicación específica. Tendrá un alto grado de autonomía en aspectos como mecanismos de consenso, elecciones de tarifas de gas y modelos económicos. Sin embargo, la autonomía no significa independencia completa, ya que es probable que la arquitectura subyacente esté limitada por la infraestructura fundamental construida para la capa 2, como compartir componentes clave como Secuenciadores y Probadores con la cadena de capa 2.

Esto significa que las transacciones en la capa 3 son procesadas directamente por el Secuenciador de la capa 2 y enviadas a la mainnet para su confirmación en estado final. La capa 2 asume más un papel de habilitar funciones de interoperabilidad entre múltiples cadenas de capa 3, donde la llamada "capa de liquidación" es meramente para el empaquetado de datos y no la liquidación final en sentido estricto. Las transacciones en la capa 3 también necesitan hacer cola en la capa 2 para el empaquetado, por lo que tiene sentido tratar la cadena de aplicación de la capa 3 como un tipo especial de canal de Secuenciador.

3. Suponiendo que la capa 3 opera puramente como un anidamiento de cadenas dentro de cadenas limita naturalmente la escalabilidad, pero esta práctica es solo una suposición teórica. Si la capa 2 y la capa 3 comparten componentes críticos como Secuenciadores y Probadores, hay muchas formas de habilitar la escalabilidad horizontal de las cadenas de la capa 3, especialmente cuando se mejora la interoperabilidad entre cadenas.

• Como mencionó el fundador de zkSync, @gluk64, utilizando la tecnología ZK como base para la interoperabilidad entre múltiples blockchains es factible porque la tecnología ZK permite a dos contrapartes verificar la autenticidad de la información sin revelar los detalles. Cuando los activos se transfieren de la Capa 3 a la Capa 2, esto se puede lograr de manera perfecta a través de un puente ZK, lo que permite transferencias atómicas de activos entre cadenas sin la necesidad de un consenso interno adicional u otros procesos.La tecnología de puente mejorada por ZK permite un soporte fundamental para la expansión multi-cadena de la Capa 3 porque, independientemente de cuántas Capas 3 se implementen, se liquidan directamente con la Capa 2 a través de Pruebas ZK, lo que no afecta la relación entre la Capa 2 y la mainnet;

• Como lo describió el fundador de Eigenlayer, @sreeramkannan, tener los nodos activos AVS del consenso de coordenadas Eigenlayer entre diferentes blockchains implica esencialmente el mismo conjunto de nodos participando en la construcción de consenso en múltiples cadenas. Al implementar un mecanismo de recompensa y penalización (Slash) para AVS, teóricamente es posible reducir la probabilidad de que los nodos actúen maliciosamente. Si los nodos aprueban la transferencia de activos de la Capa 3 a la Capa 2 y hay mala conducta, estarían sujetos a penalizaciones.Este tipo de mecanismo económico de recompensa y castigo también se puede aplicar a problemas de confianza en un entorno multi-cadena. Aunque no puede lograr el mismo nivel de confianza que la tecnología ZK, puede crear aproximadamente un entorno confiable basado en un modelo económico.

4. @VitalikButerin, en respuesta a discusiones que a menudo llevan prejuicios inherentes, reiteró su opinión de que la Capa 3 no debe ser vista de forma simplista como solo una pila o extensión de la Capa 2, ya que esto no necesariamente aporta escalabilidad efectiva. Dado que la Capa 3 depende de la Capa 2 como su infraestructura y la Capa 2 en sí misma no puede expandirse indefinidamente, lo mismo ocurre con la Capa 3. Sin embargo, en ciertos escenarios específicos, como la privacidad, aplicaciones específicas de la Capa 3 orientadas a la privacidad pueden abordar algunas de las preferencias transaccionales para la privacidad.

En conclusión, Layer 3 representa una característica altamente personalizable con potencial para una expansión a medida. Desde mi perspectiva, la expansión de Layer 3 debería basarse en las necesidades específicas de la aplicación y desarrollarse de manera personalizada, a diferencia de un paradigma de desarrollo único que no es factible en una dirección multi-cadena para las aplicaciones de Layer 3.

Descargo de responsabilidad：- Este artículo es reimpreso de [Twitter], Todos los derechos de autor pertenecen al autor original [@tmel0211]. If there are objections to this reprint, please contact the Gate Learnequipo, y lo resolverán rápidamente.- Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen ningún consejo de inversión.- Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.