En los ojos de muchas personas, "una cadena" es un todo: la generación de bloques, la ejecución, el empaquetado y la actualización del estado están todos atados juntos. Pero un sistema que realmente puede iterar a largo plazo y manejar un tráfico de nivel de pago a menudo separará la arquitectura: la capa de consenso se encarga de "quién decide" (ordenamiento y finalización), la capa de ejecución se encarga de "qué se calcula" (ejecución de transacciones EVM y cambios de estado). Plasma elige desacoplar la capa de ejecución (Reth/EVM) de la capa de consenso (PlasmaBFT) a través de la API de Engine, esencialmente sirviendo a tres objetivos: capacidad de actualización, mantenibilidad y alta fiabilidad.@Plasma $XPL #plasma
En primer lugar, las actualizaciones son más rápidas y seguras.
Cuando la capa de ejecución está separada de la capa de consenso, al querer optimizar el rendimiento de EVM, corregir vulnerabilidades de ejecución o actualizar la implementación del nodo, no es necesario tocar la lógica de consenso; por el contrario, al modificar parámetros de consenso o mecanismos relacionados con los validadores, tampoco es necesario rehacer el cliente de ejecución. Para una "cadena de liquidación de moneda estable", esto es crucial: la red de pagos teme más que nada a "una actualización, y la experiencia del usuario se ve afectada". El desacoplamiento puede reducir el impacto de las actualizaciones, permitiéndote realizar iteraciones de rendimiento más frecuentes, mientras reduces el riesgo en toda la red.
En segundo lugar, la aislamiento de fallas es más claro.
En el escenario de pago, el problema generalmente no es "la cadena se detuvo", sino "fallos ocasionales", "confirmaciones más lentas", "fluctuaciones de RPC", "ejecuciones anómalas en nodos individuales". Si el consenso y la ejecución están fuertemente acoplados, es difícil localizar este tipo de problemas: ¿es un problema de ordenación o un problema de ejecución? Después del desacoplamiento, la cadena puede segmentar más fácilmente las fallas: la capa de consenso se encarga solo de la producción de bloques y la finalización, mientras que la capa de ejecución se encarga solo de la ejecución y el estado, y es más fácil localizar rápidamente, cambiar, revertir o reparar en caliente cuando ocurren excepciones. Para los desarrolladores, esto significa que en el futuro la cadena probablemente logrará "operar de manera estable + reparar rápidamente", en lugar de que un problema cause una conmoción en toda la red.
En tercer lugar, es más fácil realizar optimizaciones de rendimiento y múltiples implementaciones.
Los cuellos de botella en el rendimiento de la ejecución de EVM, lectura y escritura de estados, estrategias de grupos de transacciones, paralelización y otras optimizaciones, a menudo requieren un largo proceso de refinamiento en el cliente de ejecución. Plasma utiliza clientes de Rust como Reth, que ya tienen ventajas en rendimiento e ingeniería; y la forma en que se estructura la API de Engine les permitirá introducir más fácilmente nuevas implementaciones de ejecución en el futuro, realizar pruebas A/B e incluso realizar optimizaciones de ejecución más agresivas para escenarios específicos (como transferencias de alta frecuencia de monedas estables), sin necesidad de rehacer el consenso al mismo tiempo. Para el ecosistema, múltiples implementaciones también significan una mayor robustez: no poner todos los huevos en el mismo cliente.
Desde la perspectiva del desarrollador, el takeaway más práctico de B3 es: la "disponibilidad" de la cadena se parecerá cada vez más a un sistema de pagos Web2, en lugar de ser solo una cadena pública que "funciona". Cuando hagas aplicaciones relacionadas con pagos/billeteras/liquidaciones en Plasma, los hábitos de ingeniería deben acercarse más a los sistemas financieros:
Diseñar idempotencia y reintentos (no asumas que siempre será exitoso)
Utiliza múltiples proveedores de RPC y conmutación por error (no dependas de un solo punto)
Usa confirmaciones y finalizaciones recibidas para construir máquinas de estado (no solo observes los pendientes)
Proporciona a los usuarios retroalimentación de estado más clara (especialmente para transferencias y retiros)
