Concepto de preconfirmación explicado: ¿cómo hacer que las transacciones de Ethereum sean más eficientes?

Este artículo parte de las limitaciones existentes en el ecosistema L2 actual, a través del análisis en profundidad de proyectos como Taiko, para mostrar cómo el concepto innovador de preconfirmación optimiza el proceso de confirmación de transacciones y mejora la experiencia del usuario. Al mismo tiempo, también revela los desafíos duales que la tecnología de preconfirmación actual todavía enfrenta en su desarrollo, incluyendo la mejora tecnológica y la sostenibilidad del ecosistema.

Título original:「Preconfirmación (feat. Taiko): ¡Haz que Ethereum FAST por primera vez!」

**Autor original: Ingeun Kim : : FP

Resumen clave

• Taiko es una red Layer2 basada en Based Rollup que tiene como objetivo lograr una completa interoperabilidad con Ethereum, al tiempo que impulsa la Descentralización del secuenciador (Sequencer). Para resolver el problema de latencia en la confirmación final de transacciones en el mecanismo Rollup, Taiko introduce el concepto de “Preconfirmación”. Al garantizar de antemano la inclusión y secuencia de las transacciones para los usuarios, la preconfirmación resuelve eficazmente el problema de la ineficiencia en el proceso de confirmación de transacciones en el mecanismo Rollup, mejorando significativamente la experiencia del usuario.
• En el modelo de preconfirmación basado en L1, los validadores proporcionan garantía de resultados de transacciones a los usuarios. Los preconfirmadores deben hacer stake de margen y cumplir con el mecanismo de reducción (slashing) para garantizar la confiabilidad del sistema. Proyectos como Taiko en L2 establecen una finalidad de transacción confiable al introducir un mecanismo de preconfirmación, creando un entorno operativo más conveniente para las finanzas descentralizadas y otros servicios que requieren confirmación en tiempo real.
• En la actualidad, varios proyectos han participado en la construcción del ecosistema de preconfirmación. Este avance tecnológico tiene el potencial de mejorar la eficiencia del ecosistema de capa 2 de Ethereum, fortalecer la interoperabilidad con Ethereum y impulsar la expansión general del ecosistema.

Taiko se está acercando constantemente a su objetivo final como solución de capa 2 para Ethereum (ETH). Para lograr esto, Taiko prioriza la interoperabilidad total con Ethereum, la descentralización de los secuenciadores y el apoyo a los desarrolladores. Cabe destacar que Taiko logra la interoperabilidad total con Ethereum a través de la arquitectura de Based Rollup, permitiendo al mismo tiempo que cualquiera participe como secuenciador, logrando así la descentralización de los secuenciadores. Sin embargo, a pesar de las ventajas del modelo Based Rollup, aún existen algunos problemas inherentes de eficiencia en su estructura.

Este artículo analizará en detalle el concepto de preconfirmación utilizando Taiko como ejemplo. Como parte fundamental de la pila tecnológica de Layer2, la preconfirmación es un paso importante para el desarrollo continuo de Rollup.

Problema actual de eficiencia L2

Con la expansión del ecosistema L2, han surgido numerosos proyectos que traen consigo muchos nuevos conceptos y pilas tecnológicas. Sin embargo, a pesar de estos avances significativos, L2 todavía enfrenta algunos problemas pendientes en términos de eficiencia, especialmente en áreas clave que afectan la experiencia del usuario, por lo que mejorar la eficiencia se vuelve especialmente importante.

Limitaciones intrínsecas de Rollup: proceso ineficiente de determinación de la finalidad de las transacciones

L2 logra escalabilidad mediante Rollup, dependiendo de la disponibilidad de datos y el procesamiento de transacciones en plataformas L1 como Ethereum. Sin embargo, Rollup tiene una limitación inherente: aunque puede realizar la clasificación y ejecución de transacciones de forma independiente, todos los demás procesos aún deben esperar la confirmación final de L1.

Esta arquitectura garantiza la seguridad y la inmutabilidad de los datos al utilizar directamente el Bloquear de L1 para la generación y disponibilidad de datos. Sin embargo, la dependencia de L1 para la confirmación final resulta en una velocidad de procesamiento de transacciones más lenta y una capacidad limitada de confirmación en tiempo real, lo que dificulta satisfacer las demandas en tiempo real desde la perspectiva del usuario.

Además, muchos secuenciadores y validadores L2 Nodo siguen siendo centralizados. Esta centralización puede conducir a una eficiencia deficiente, como tiempos de confirmación de transacciones más largos y posibles interrupciones en las operaciones, lo que afecta la eficiencia del procesamiento de transacciones de algunos Rollup, causando latencia de confirmación.

Presentación del concepto de preconfirmación

La introducción del concepto de preconfirmación tiene como objetivo resolver el problema de la baja eficiencia de la confirmación final de las transacciones en la red L2. La preconfirmación permite a los usuarios obtener confirmaciones de transacciones más rápidamente, aliviando así la latencia y la ineficiencia comunes en el mecanismo de Rollup.

¿Para qué problemas está diseñada la Preconfirmación?**

En el mecanismo Rollup, el proceso de confirmación después de que el usuario envía transacciones a L2 siempre tiene problemas de eficiencia. Debido a que el secuenciador centralizado de L2 no puede garantizar con precisión cuándo se confirmarán las transacciones en L1, los usuarios a menudo no están seguros del orden y el resultado de las transacciones. Por ejemplo, es posible que los usuarios deban esperar mucho tiempo para que las transacciones se incluyan en L1, lo que podría resultar en pérdidas financieras si el orden de las transacciones es incorrecto o si el resultado no es el deseado.

En un entorno de mercado con fluctuaciones significativas, los problemas de latencia y cambios de secuencia son más prominentes, ya que los usuarios dependen de servicios de arbitraje y finanzas descentralizadas. En estos casos, la latencia o los cambios de secuencia en las transacciones pueden resultar en la pérdida de oportunidades. Incluso los usuarios que realizan transacciones habituales pueden tener dudas sobre la confiabilidad y la facilidad de uso de la cadena de bloques debido a la falta de confianza en los tiempos de confirmación y la secuencia en L1.

Por lo tanto, el objetivo de diseño de la confirmación previa es remediar estas deficiencias, especialmente para aquellos usuarios más afectados por la ineficiencia de Rollup, y proporcionar una experiencia de transacción más conveniente y confiable.

¿Cómo resolver estos problemas de preconfirmación?

La preconfirmación aborda estos problemas al proporcionar a los usuarios garantías de inclusión, ordenación y ejecución de las transacciones. Proporciona a los usuarios una “confirmación suave” a través de un secuenciador L2 centralizado y emite certificados de preconfirmación para garantizar que las transacciones se incluyan finalmente en L1.

La principal ventaja de la confirmación suave es mejorar la experiencia del usuario. Después de enviar una transacción, el usuario puede recibir inmediatamente un comprobante de confirmación para asegurarse de que la transacción se incluya en L1 en el orden esperado, lo que reduce la incertidumbre, especialmente en transacciones que requieren una respuesta rápida, como Arbitraje. Además, la confirmación previa también aumenta la confianza del usuario en el sistema L2. A medida que la confianza del usuario en el manejo seguro de las transacciones aumenta, también aumenta la utilización general del ecosistema L2. Por lo tanto, la confirmación previa juega un papel clave en mejorar la eficiencia y conveniencia del procesamiento de Rollup.

¿Es la pre-confirmación la solución final?

Aunque las confirmaciones de software de los secuenciadores centralizados pueden mejorar la experiencia del usuario mediante la ordenación y los resultados esperados, dependen de la confianza en el secuenciador. Sin medidas coercitivas legales o técnicas, los usuarios solo pueden confiar en la fiabilidad del secuenciador. Esta dependencia conlleva la posibilidad de que las transacciones no se incluyan en el orden correcto, e incluso que no se incluyan en L1, lo que impide ofrecer la estabilidad garantizada que los usuarios esperan.

Interpretación del concepto y práctica de la preconfirmación basada en el ejemplo de Taiko

Taiko ha dedicado una gran cantidad de esfuerzo a la implementación basada en preconfirmación, ya que este método se alinea estrechamente con las características fundamentales de Based Rollup. Si Based Preconfirmation puede ser exitosamente introducido en el marco de Taiko, no solo reducirá significativamente la latencia de confirmación final de las transacciones, sino que también mejorará la experiencia del usuario. Además, esta mejora también activará una variedad de servicios previamente restringidos, permitiéndoles operar de manera eficiente en la red de Taiko.

Antes de profundizar en la Preconfirmación Basada en Base, es necesario revisar algunas características clave de Taiko para comprender mejor la aplicabilidad y las ventajas de este método.

Análisis de casos de Taiko

Taiko muestra plenamente las características principales de Based Rollup. No solo logra una interoperabilidad completa con la infraestructura de ETH, sino que también se compromete a alinearse completamente con el mecanismo de seguridad de ETH. Taiko adopta la arquitectura de Based Rollup, lo que significa que no depende de un ordenador centralizado, sino que depende de validadores de ETH para actuar como ordenadores, ordenando las transacciones y los bloques.

Es decir, el secuenciador de Taiko y los proponentes de Bloquear en Ethereum son roles similares. Este diseño les otorga responsabilidades especiales y mecanismos de incentivos, como la obtención de recompensas máximas por extracción de valor (MEV) y otros beneficios derivados de ser secuenciador. Por lo tanto, cuando surgen problemas en el proceso de secuenciación de L2 de Taiko, estos secuenciadores asumen naturalmente la responsabilidad correspondiente debido a su interés en el ecosistema de Ethereum. Este mecanismo hace que Taiko se diferencie significativamente de otros proyectos L2 de Ethereum en términos de responsabilidad operativa.

Además, es importante tener en cuenta que el modelo Based Rollup de Taiko está diseñado como “Rollup Contencioso Basado en la Competencia (BCR)”, esta estructura tiene como objetivo incentivar la competencia justa. A través de un diseño abierto y sin permisos, Taiko garantiza la descentralización del sistema y permite la participación de cualquier persona, lo que hace que el sistema sea más justo y transparente.

Confirmación previa basada en Rollup

Entonces, ¿cómo es el modelo de preconfirmación diseñado específicamente para Based Rollup? La respuesta es “Based Preconfirmation”. Este modelo tiene como objetivo reemplazar los mecanismos de confirmación suave tradicionales mediante la verificación directa en L1.

Based Preconfirmation proporciona un sistema en el que algunos validadores de L1 participan voluntariamente y proporcionan servicios de preconfirmación. Como secuenciadores, estos validadores proporcionan predicciones verificables de los resultados de transacciones de Rollup a los usuarios. Este método proporciona a los usuarios una garantía de confianza en la inclusión y el orden de las transacciones, y estas garantías se basan directamente en L1, lo que aumenta la confiabilidad y la fiabilidad del proceso de Rollup.

Justin Drake propuso por primera vez el concepto de Based Preconfirmation, y presentó un papel específico llamado “Preconfer”, que puede proporcionar a los usuarios garantías de firma para confirmar el orden y el estado de ejecución de las transacciones. Para garantizar la fiabilidad de los compromisos, cada Preconfer debe stake una cantidad específica de Margen. Si no cumplen con los compromisos sobre el orden de las transacciones o el estado de ejecución, se enfrentarán a penalizaciones del mecanismo de Slashing, es decir, la pérdida parcial o total de Margen.

El mecanismo de Slashing se ha aplicado ampliamente en el PoS stake de Ethereum para controlar eficazmente el comportamiento malicioso. Este mecanismo no solo fortalece la responsabilidad de los prevalidadores, sino que también establece una cierta base de confianza entre los usuarios y los prevalidadores.

Hay dos escenarios en los que un validador previo puede recibir una penalización por Slashing:

1. Fallas de activación (Liveness Faults): Si el preconfirmador, por cualquier motivo, no incluye la transacción preconfirmada del usuario en la cadena, se produce una falla de activación. Debido a que las fallas de activación no siempre son intencionales, su castigo es relativamente leve. Este tipo de fallas puede originarse en problemas de red o interrupciones en la cadena de bloques L1 o L2, lo que impide que la transacción se incluya correctamente en la cadena. Para proteger a los preconfirmadores honestos de ser castigados indebidamente, el monto del castigo por la falla de activación generalmente se determina mediante negociación entre el usuario y el preconfirmador.
2. Fallos de seguridad (Safety Faults): Si una transacción preconfirmada se incluye en la cadena, pero el resultado no coincide con la solicitud original del usuario, se produce un fallo de seguridad. Esta discrepancia es totalmente responsabilidad del preconfirmador, por lo que las sanciones por fallos de seguridad suelen ser más severas. El margen del preconfirmador será confiscado en su totalidad, independientemente de si el problema fue intencional o no.

Para convertirse en un preconfirmador del modelo Based Preconfirmation, un Nodo (generalmente un proponente de Bloquear L1) debe aceptar las condiciones de estos mecanismos de Margen y stake requeridos. Una vez aprobado, el preconfirmador puede proporcionar servicios a los usuarios y obtener ingresos cobrando tarifas de servicio.

Este modelo de tarifas proporciona una gran conveniencia a los usuarios, permitiéndoles evitar la latencia inherente en la confirmación final de las transacciones de Rollup. Por ejemplo, después de que los usuarios envíen transacciones previas a través de sus billeteras personales, pueden recibir inmediatamente un comprobante de confirmación del preconfirmador.

Los preconfirmadores que participan en Based Preconfirmation no solo pueden obtener ingresos adicionales mediante el cobro de tarifas, sino que también pueden ayudar a optimizar el proceso de confirmación de transacciones de Rollup. Este modelo no solo mejora la experiencia del usuario, sino que también proporciona una solución confiable y eficiente para la confirmación final de transacciones en todo el ecosistema L2, lo que aumenta aún más su atractivo y utilidad.

¿Por qué los usuarios están dispuestos a pagar tarifas de preconfirmación?

Esto está estrechamente relacionado con el propósito central de la preconfirmación. Los usuarios están dispuestos a pagar por la preconfirmación porque resuelve directamente el problema de la baja eficiencia de Rollup en el proceso de confirmación final de la transacción, lo que brinda a los usuarios una gran conveniencia.

Por ejemplo, cuando un usuario envía una transacción previa a través de su billetera personal en la capa 2 de la cadena bloquear-on, las transacciones estándar pueden requerir una confirmación final mientras que los usuarios que solicitan una confirmación previa pueden recibir una garantía inmediata del validador previo para completar la transacción sin latencia. En este momento, el usuario incluso puede ver una marca de verificación verde en la interfaz de la billetera, indicando claramente que la transacción se ha completado con éxito.

Tomemos el servicio de Finanzas descentralizadas como ejemplo. Cuando los usuarios realizan intercambios de Token en la plataforma L2 Finanzas descentralizadas, la confirmación previa puede proporcionar seguridad adicional para las transacciones relacionadas. Normalmente, las cotizaciones de intercambio o los costos de las transacciones pueden no coincidir con los resultados reales debido a la latencia. Sin embargo, con la confirmación previa, los usuarios pueden disfrutar de un proceso de confirmación de transacciones rápido y eficiente, reduciendo las discrepancias entre las condiciones previstas y los resultados reales, lo que permite obtener una experiencia de servicio más confiable.

Estos casos de uso no solo permiten a los desarrolladores proporcionar servicios más precisos, sino que también brindan a los usuarios una experiencia de uso más fluida y conveniente. Esta dinámica también apoya aún más la expansión del ecosistema L2, mientras contribuye a subir el sistema ecológico más amplio de L1. Además, para los secuenciadores de Based Rollup, la confirmación previa proporciona un modelo de ingresos significativo. Este diseño resuelve eficazmente algunas de las debilidades tradicionales de Based Rollup, convirtiéndolo en la elección ideal para los secuenciadores en términos de confiabilidad y atractivo.

¿Cuáles son los desafíos de la preconfirmación basada?

Basado en Preconfirmación sigue siendo un área de investigación muy seguida en proyectos de Capa 2 impulsados por Rollup, representados por Taiko. A pesar de que este mecanismo proporciona una solución clara para mejorar el rendimiento y la escalabilidad de L2, y al mismo tiempo mantener la descentralización, todavía enfrenta algunos desafíos pendientes en la aplicación práctica para lograr una adopción más amplia.

En primer lugar, cuando los usuarios envían transacciones a Bloquear en Preconfer, es posible que no tengan la garantía absoluta de que la transacción será incluida. Aunque los validadores garantizan la transacción mediante el margen de apuesta, este mecanismo aún no puede resolver completamente el problema de la exclusión de transacciones debido a interrupciones externas. Especialmente cuando el valor de la transacción es mayor que la cantidad apostada por los validadores, estos pueden abusar de sus privilegios y elegir selectivamente incluir o excluir ciertas transacciones, lo que conlleva riesgos potenciales.

Otro desafío significativo es el modelo de ganancias basado en la confirmación previa. La principal fuente de ingresos para los confirmadores previos son las tarifas pagadas por los usuarios. Sin embargo, si el número de confirmadores previos es insuficiente o la participación no es lo suficientemente alta, puede dar lugar a la centralización del mercado y a tendencias monopolísticas. En este caso, las tarifas de confirmación previa podrían ser artificialmente elevadas, lo que aumentaría el costo de las transacciones rápidas y eficientes para los usuarios, representando así una amenaza para el desarrollo saludable del ecosistema de confirmación previa.

Es importante tener en cuenta que el concepto de Based Preconfirmation es relativamente nuevo, y solo se propuso hace aproximadamente un año. Todavía se necesita tiempo y mejora en la práctica para convertirlo en una herramienta clave para maximizar la velocidad y eficiencia de las soluciones L2 impulsadas por Rollup. Sin embargo, a medida que Rollup se ha establecido firmemente como un componente central de la escalabilidad de Ethereum, la exploración adicional de la preconfirmación para mejorar el rendimiento marca un paso importante en el desarrollo de la tecnología L2.

Especialmente Taiko, ha logrado avances importantes en la implementación de Based Preconfirmation. Al mismo tiempo, Taiko ha colaborado con varios socios, como Taiko Gwyneth, Nethermind, Chainbound, Limechain, Primev y Espresso, para explorar y desarrollar aplicaciones de Based Preconfirmation. Estas colaboraciones tienen como objetivo impulsar la evolución del ecosistema L2, y se discutirán más detalles relacionados en capítulos posteriores.

Vista panorámica del ecosistema de confirmación previa: interpretación de diagramas y exploración de proyectos

En este capítulo, discutiremos qué proyectos están investigando y promoviendo activamente el desarrollo tecnológico de la preconfirmación en el ecosistema L2 impulsado por Rollup. Dado que este ecosistema todavía está en una etapa temprana de desarrollo, utilizaremos un diagrama de flujo para mostrar y comprender más claramente el proceso específico de preconfirmación.

Diagrama de flujo de preconfirmación

La confirmación previa es un proceso complejo que requiere una estrecha colaboración entre L1 y L2, que implica múltiples roles, cada uno con responsabilidades específicas. Para comprender mejor este proceso de manera más intuitiva, he creado un diagrama de flujo para proporcionar un resumen breve. Es importante tener en cuenta que este diagrama de flujo tiene como objetivo ayudar a explicar la lógica general y, por lo tanto, no hace una distinción estricta entre las diferentes características de Rollup y Based Rollup, sino que se centra principalmente en el flujo general a nivel base.

Antes de conocer los pasos específicos del diagrama de flujo, primero conozcamos los roles y funciones de los participantes en el proceso de confirmación previa.

• Usuarios (User): Los usuarios individuales que utilizan la red L1 o L2 y son responsables de crear y enviar transacciones. Si los usuarios desean obtener una confirmación previa, enviarán la transacción completada a los confirmadores previos.
• Preconfirmador: Durante el proceso de preconfirmación, el preconfirmador es responsable de auditar y verificar la validez de las transacciones, y luego proporcionar una garantía de preconfirmación al usuario. A través de la preconfirmación, los usuarios pueden obtener rápidamente un estado de seguridad de la transacción antes del Asentamiento final. Si un Nodo no tiene derecho a la preconfirmación, actúa como un participante no preconfirmado (Actores no preconfirmados), manejando principalmente transacciones normales en lugar de transacciones preconfirmadas, similar a un Nodo de verificación estándar.
• L1 validadores（L1 Validator）： Responsable de validar finalmente las transacciones y los bloques en la red L1. Una vez que los prevalidadores envían los datos de la transacción, los L1 validadores los validan y registran los datos finales en la cadena de bloques L1, garantizando la integridad de la transacción y el cumplimiento de las reglas de consenso.
• Gestor de Desafíos de Preconfirmación: Cuando surge una disputa o problema en el proceso de preconfirmación, este rol es responsable de investigar el problema y tomar medidas apropiadas para resolver la disputa. Este rol juega un papel crucial en mantener la imparcialidad y confiabilidad del proceso de preconfirmación.

Ahora, vamos a organizar el proceso de confirmación previa de acuerdo con el orden del diagrama de flujo:

1. El usuario envía la solicitud de transacción al pre-confirmador en el pre-confirmador para iniciar el proceso de pre-confirmación.
2. Los prevalidadores revisan y envían un recibo de preconfirmación de la transacción, comprometiéndose a incluirla en el Bloquear L1, lo que brinda una garantía preliminar de confirmación final al usuario.
3. Los preconfirmadores enviarán los datos de transacción que deben incluirse en el Bloquear L1 a los validadores L1. Estos datos pueden ser una sola transacción o datos consolidados procesados por el secuenciador L2.
4. Los validadores de L1 validan los datos de transacción o los datos resumidos presentados, y los registran en el Bloquear de L1 para asegurarse de que cumplan con las reglas de consenso de la cadena de Bloquear.
5. Después de un período de tiempo, el Bloquear L1 que contiene datos de transacciones o datos resumidos alcanza la finalidad y la transacción se confirma oficialmente.
6. Los usuarios pueden verificar los resultados finales de las transacciones a través del Nodo L1 y, si es necesario, plantear cualquier posible controversia o desafío de preconfirmación utilizando la información relevante.
7. Si ocurre una transacción que no cumple con la promesa de estar correctamente incluida en L1, el pre-validador enfrentará la penalización del administrador de desafíos previos, como el margen de corte o la congelación de sus activos de stake.

Exploración de proyectos relacionados

A continuación se analizarán en detalle los principales proyectos que participan activamente en el ecosistema de confirmación previa y sus roles relacionados en el proceso. Aunque estos proyectos ocupan roles específicos en el diagrama de flujo, es posible que sus responsabilidades reales sean ligeramente diferentes. Por lo tanto, este resumen tiene como objetivo proporcionar una comprensión fundamental y servir como guía general. Para mantener la claridad, los proyectos en cada categoría se enumeran en orden alfabético.

Validadores Preconfer (Preconfer Validators)

• Astria：Astria se dedica a reemplazar los secuenciadores centralizados con una red de secuenciadores Descentralización, y permite que múltiples Rollup compartan esta red. Este diseño proporciona a Rollup una mayor capacidad de resistencia a la censura, una finalidad de Bloquear más rápida y una interacción sin problemas entre Rollup. Para lograr una finalidad de Bloquear más rápida, Astria introduce una función de preconfirmación que permite a Rollup ofrecer confirmaciones de transacciones rápidas y mejorar la resistencia a la censura, lo que mejora significativamente la experiencia del usuario.
• Bolt by Chainbound: Bolt es un protocolo de pre-confirmación desarrollado por Chainbound que proporciona a los usuarios de ETH una confirmación de transacción casi instantánea. Su funcionamiento se basa en un mecanismo de participación sin confianza y un depósito económico, al mismo tiempo que es compatible con el canal MEV-Boost PBS existente, lo que crea nuevas oportunidades de ingresos para los proponentes. La función principal de Bolt es la pre-confirmación de L1, que proporciona finalidad inmediata a transacciones básicas como transferencias y autorizaciones, mejorando así la experiencia del usuario. Al transferir la responsabilidad de la inclusión de transacciones de los constructores de bloques centralizados a los proponentes, Bolt mejora la resistencia a la censura del sistema. Al mismo tiempo, el mecanismo de registro de proponentes con depósito garantiza un entorno sin confianza y es compatible con diversos tipos de Contratos inteligentes.
• **Espresso **：Espresso es un protocolo que se dedica a mejorar la interoperabilidad del ecosistema blockchain. Adopta el protocolo de Tolerancia Byzantine a fallos (BFT) HotShot Consenso, logrando la secuencia de transacciones entre múltiples cadenas y la finalidad rápida de los datos. Espresso incluye la Red de Espresso y el Mercado de Espresso, que trabajan juntos para proporcionar una finalidad rápida de las transacciones y una interoperabilidad eficiente, con el objetivo de mejorar la escalabilidad y la seguridad del ecosistema blockchain.
• Ethgas: Ethgas es un mercado para el espacio de bloqueo de transacciones, donde la coincidencia de transacciones es gestionada por un sistema centralizado y los procesos on-chain son ejecutados a través de contratos inteligentes. Ethgas proporciona dos funciones principales: Confirmación previa (asegurando que las transacciones estén incluidas dentro de los límites de Gas especificados) y Ejecución de confirmación previa (asegurando que las transacciones alcancen un estado o resultado específico). Ethgas se centra en proteger la privacidad de las transacciones en el espacio de bloqueo y es conocido por sus objetivos de operación imparciales.
• Luban：Luban se centra en el desarrollo de una capa de secuenciación Descentralización para conectar los datos de transacciones entre la red Ethereum y Rollup. Esta capa de secuenciación está diseñada como un sistema Descentralización que separa las funciones de propuesta y ejecución. La función de preconfirmación de Luban mejora significativamente la fiabilidad de las transacciones al garantizar su ejecutabilidad antes de ser incluidas en la red Ethereum, al tiempo que ayuda a optimizar factores clave como el blanqueo de capitales, el precio del gas y MEV.
• Primev：Primev está desarrollando una red de proponentes integrada con MEV, que combina la preconfirmación con las funciones de MEV para construir una red punto a punto eficiente y confiable. Esta red registra los compromisos de ejecución de transacciones en la cadena ETH y motiva a los proponentes mediante un mecanismo de recompensa o castigo. Primev permite a los participantes de MEV establecer condiciones específicas de ejecución para sus transacciones, mientras que los constructores de bloques y los validadores pueden comprometerse a cumplir con estas condiciones para asegurar la preconfirmación de las transacciones. Basado en EIP-4337, Primev admite opciones flexibles de preconfirmación y tarifas de gas, lo que no solo mejora la eficiencia del procesamiento de transacciones, sino que también optimiza aún más la experiencia del usuario.
• Puffer Unifi: El servicio de validación activa (Actively Validated Services, AVS) de Puffer Unifi está construido sobre EigenLayer y se enfoca en resolver los desafíos de preconfirmación en el ecosistema de Ethereum, especialmente en la arquitectura de Based Rollup. Puffer Unifi AVS utiliza la función de stake de EigenLayer para respaldar el mecanismo de participación en la preconfirmación, con el objetivo de mejorar la eficiencia de la confirmación final de transacciones. Con el desarrollo de Based Rollup, la demanda de proveedores confiables de preconfirmación sigue subiendo, y el objetivo de Puffer Unifi AVS es satisfacer esta demanda. Su visión final es lograr una preconfirmación eficiente sin cambiar el protocolo central, promoviendo así la sostenibilidad de la subida del ecosistema de Ethereum.
• Skate: La confirmación previa de Skate AVS se basa en los activos de stake en EigenLayer para proporcionar seguridad económica a todas las operaciones de intercambio cross-chain de Interacción. El AVS verifica los datos y la información de enlace requeridos para el intercambio cross-chain de Interacción, que luego son firmados y preparados para su ejecución por el relé de Skate. A través de este proceso, el AVS de Skate logra una confirmación previa de los datos, lo que mejora significativamente la confiabilidad y eficiencia de las transacciones de intercambio cross-chain de Interacción.
• Spire：El marco Based Stack de Spire es un marco Rollup basado en Ethereum, diseñado específicamente para brindar soporte a las AppChain. Este marco permite que las AppChain interactúen directamente con Ethereum y personalicen sus métodos de secuenciación, admitiendo funciones de intercambio cross-chain, optimizando la experiencia del usuario a través de preconfirmaciones. Based Stack admite múltiples entornos de ejecución, garantiza los ingresos de secuenciación de AppChain y es compatible con secuenciadores compartidos tradicionales. Como proyecto de Código abierto, Based Stack proporciona a los desarrolladores todas las herramientas y recursos necesarios para construir y gestionar AppChain, fomentando así el desarrollo de AppChain y la interoperabilidad con el ecosistema de Ethereum.
• Taiko Gwyneth：Taiko Gwyneth es un diseño de Rollup desarrollado por Taiko, clasificado como una arquitectura Rollup basada. Su objetivo es lograr plena interoperabilidad con la cadena de bloques de ETH, al mismo tiempo que gestiona la secuenciación de transacciones directamente en la cadena de bloques de ETH. Este diseño aprovecha al máximo la seguridad y las características de Descentralización de la cadena de bloques de ETH, a la vez que proporciona un alto rendimiento y confirmaciones finales rápidas. Actualmente, Taiko está ejecutando un mecanismo de proponentes para ayudar en la creación de Bloquear, y está explorando un mecanismo de preconfirmación para fomentar la producción rentable de Bloquear en la comunidad. Este mecanismo tiene como objetivo optimizar la programación del tiempo de Bloquear y la eficiencia en la publicación de datos. Para lograr estos objetivos, Taiko está colaborando estrechamente con proyectos como Nethermind y Gattaca.

L1 validadores

• Chorus One: Chorus One es un proyecto que ofrece servicios de validación e infraestructura para redes blockchain, enfocado en servicios de stake en varios protocolos para mejorar la estabilidad y seguridad de la red. Como validadores L1, la responsabilidad de Chorus One es verificar transacciones y generar bloques para mejorar la confiabilidad y eficiencia de toda la red. Recientemente, Chorus One ha mostrado un gran interés en la tecnología de pre-confirmación, incluso organizando eventos temáticos durante Devcon 2024.

Investigación

• Nethermind：Nethermind es un proyecto dedicado al desarrollo de clientes y herramientas para la red Ethereum, con el objetivo principal de mejorar el rendimiento y la estabilidad de la Cadena de bloques. Mediante la introducción de tecnologías avanzadas de optimización, Nethermind impulsa activamente la capacidad de procesamiento de transacciones en la red Ethereum. En cuanto a la tecnología de preconfirmación, Nethermind ha estado llevando a cabo investigaciones exhaustivas y ha presentado una propuesta al programa de financiamiento de Taiko, con el fin de acelerar la implementación de la función de preconfirmación en la Mainnet de Taiko. Esta propuesta se basa en el proyecto RFP-001 de Nethermind, y se implementará en dos fases: la primera fase probará la función de preconfirmación con un grupo limitado de participantes autorizados; la segunda fase tiene como objetivo expandir gradualmente el alcance de la preconfirmación.

Mirando hacia el futuro

Proyectos de Layer2 como Taiko y muchos otros Based Rollup, ya sea que utilicen la arquitectura Based Rollup o no, están trabajando arduamente para optimizar el proceso de confirmación de transacciones ineficiente en los tradicionales Rollup. A través de la introducción del concepto de pre-confirmación (Preconfirmation), estos proyectos están construyendo un sistema de confirmación de transacciones que permitirá a los usuarios confirmar transacciones de manera más rápida y confiable. Con esta metodología, estos proyectos están explorando constantemente cómo mejorar la experiencia del usuario y establecer la confianza del mismo.

Taiko aprovecha al máximo su posición como proyecto Capa 2 basado en Based Rollup, promoviendo activamente la implementación del mecanismo de preconfirmación basado, logrando así una interoperabilidad total con Ethereum y descentralización. Al ofrecer a los usuarios una garantía de confirmación final de transacciones rápida y confiable, Taiko mejora significativamente la velocidad y confiabilidad del procesamiento de transacciones, mejorando notablemente la experiencia del usuario.

Sin embargo, varios expertos de la industria, incluido Ed Felten de Arbitrum, señalan que todavía hay una falta de middleware maduro que pueda admitir completamente la preconfirmación. Esto indica que la madurez de la tecnología de preconfirmación y el modelo de negocio de los preconfirmadores todavía enfrentan desafíos que deben abordarse.

Como se describe en este artículo, cada vez más proyectos y participantes están entrando activamente en el campo de la preconfirmación, cada uno con su propio enfoque innovador, con el objetivo de mejorar el rendimiento y la eficiencia de la capa 2 de Ethereum. Esta tendencia también se alinea con la norma general de la optimización continua de los conceptos del sistema después de su implementación inicial. Creo que esta etapa marca un importante Nodo en la evolución del sistema L2 y también es un emocionante desarrollo positivo en el actual ecosistema L2.

Al mejorar la conveniencia del usuario mediante la confirmación previa, no solo puede tener un impacto significativo en áreas como las finanzas descentralizadas y los juegos que enfocan la velocidad y la eficiencia, sino que también puede reconectar las partes dispersas previamente del ecosistema de Ethereum Layer2 al mejorar el rendimiento de Ethereum Layer2. Esta mejora de rendimiento puede permitir que más proyectos de Ethereum Layer2 Tipo-1 se integren con la Profundidad de Ethereum, liberando así el potencial que antes era difícil de alcanzar debido a las limitaciones de velocidad. Estos avances sin duda tendrán un impacto significativo en todo el ecosistema de Ethereum.

La confirmación previa sigue siendo un camino lleno de desafíos. Sin embargo, pioneros como Taiko están enfrentando valientemente el desafío, centrándose en proporcionar más comodidad a los usuarios. La innovación nunca es fácil, pero como partidario de Ethereum y su ecosistema Layer2, les doy mi sincero respeto y ánimo por sus esfuerzos.