Las tarifas de Gas de la red principal de Ethereum han alcanzado nuevamente niveles sorprendentemente bajos, algo inimaginable hace dos años. Sin embargo, detrás de estos bajos costos no está un salto en el rendimiento de la arquitectura original, sino que la liquidez ha sido dividida en decenas de islas de Layer 2. Justo esta semana, para probar una lógica de arbitraje entre cadenas, tuve que reevaluar esa solución de escalabilidad que una vez fue elevada al estrellato por Vitalik y rápidamente cayó en desgracia: Plasma. A decir verdad, antes de abrir el documento, llevaba un fuerte prejuicio, ya que hoy en día, con el Optimistic Rollup y el ZK Rollup prácticamente dividiendo el mundo, volver a mencionar Plasma suena como hurgar en viejas historias. Pero después de realizar una interacción y hasta de verificar la disponibilidad de datos escaneando datos en la cadena, descubrí que la lógica de implementación esta vez es bastante interesante; no se trata de recalentar un plato antiguo, sino de una reconstrucción violenta del modelo UTXO bajo la narrativa modular actual.

Muchos desarrolladores en la capa de aplicación están acostumbrados al modelo de cuentas de EVM, asumiendo que el árbol de estado global es algo natural, pero esta semana la experiencia en la red de prueba $XPL me hizo repensar los límites de los canales de estado. A diferencia de Arbitrum o Optimism, que empaquetan la capa de ejecución y la lanzan a L1, el núcleo de Plasma radica en despojar completamente el cálculo, solo subiendo el Compromiso de Raíz de Merkle. Al desplegar contratos, sentí claramente esta diferencia; la rapidez de respuesta en las interacciones era casi extraña, casi sin la sensación de espera por la confirmación del Sequencer. Esta suavidad no es algo que Solana logre apilando hardware, sino más bien un “esfuerzo lógico” —por supuesto, aquí es un cumplido, solo confirma la transferencia de propiedad sin preocuparse por el estado intermedio de cada cálculo.

Comparándolo con el actual favorito zkSync Era, las ventajas y desventajas son igualmente evidentes. El costo computacional de zkSync al generar pruebas de conocimiento cero es un verdadero desastre para nodos normales, lo que ha hecho que los ordenadores descentralizados sean solo una promesa. Pero al ejecutar un nodo ligero de Plasma en mi máquina local, la tasa de uso de recursos fue sorprendentemente baja, sin interferir con la ejecución de varios contenedores de Docker en segundo plano. Esto significa una reducción extrema en el costo de verificación. No necesitas confiar en que un Sequencer centralizado no haga trampa, porque debido a la naturaleza de UTXO, tú mismo puedes ser el verificador. Realicé más de cien transferencias de alta frecuencia en la red de prueba, y aparte de algunos tiempos de espera en la conexión de nodos RPC (lo mencionaré más adelante), la confirmación final de los fondos fue muy sólida.

Sin embargo, los detalles de la implementación técnica siempre esconden demonios. Al experimentar con el puente entre cadenas, descubrí que la lógica de interacción en el frontend actual sigue siendo demasiado ingenieril. La mayoría de los usuarios no entienden qué es un “Período de Salida”, aunque la nueva arquitectura parece haber optimizado esto al introducir algún mecanismo de proveedor de liquidez, pero en situaciones de congestión extrema, la ruta de retiro de fondos aún me hace sudar. Esto lo distingue esencialmente de Optimistic Rollup; el sistema OP se basa en pruebas de fraude, asumiendo que eres bueno y solo retrocede si alguien desafía; Plasma se basa en pruebas de propiedad de activos, si se pierde datos (Ataque de Retención de Datos), los antiguos usuarios de Plasma deben huir en masa, lo que sería un desastre. Pero tras los tests de estrés de estos días, noté que el equipo del proyecto parece haber hecho algunas concesiones en la capa DA (capa de disponibilidad de datos), introduciendo un mecanismo similar a un DAC (Comité de Disponibilidad de Datos) para asegurar que los datos no se pierdan. Esto podría ser visto como un retroceso por los puristas, pero en la implementación, efectivamente resolvió el problema central que causó la muerte de Plasma en su momento.

Hablando de productos competidores, no puedo dejar de mencionar a StarkNet. Aunque el lenguaje Cairo de StarkNet es poderoso, el costo de migración para los desarrolladores es demasiado alto. Pero el entorno aquí ha demostrado ser sorprendentemente compatible con EVM. Simplemente lancé un código modificado de Uniswap V2, cambié un par de llamadas a la interfaz y funcionó. Sin embargo, la compatibilidad no significa eficiencia. Debido a las diferencias en la estructura de datos subyacente, algunas operaciones que implican lecturas del estado global consumen más Gas de lo esperado. Es como intentar ejecutar consultas SQL complejas en una base de datos NoSQL; puede funcionar, pero es incómodo. Esto también revela una limitación de la arquitectura actual: es más adecuada para escenarios de “propiedad clara” como pagos de alta frecuencia o acuñación de NFT, no para complejas combinaciones de DeFi. Si tu proyecto necesita invocar frecuentemente el estado de otros contratos, la experiencia actual puede no ser tan buena como la de Arbitrum One.

Hablemos ahora de los costos. Así es, de costos. Tras interactuar durante una semana, la impresión más directa es que es barato, incluso más que algunas sidechains que se autodenominan “cero Gas”. Esto se debe a su huella extremadamente simplificada en la cadena. Cada transacción deja una huella en L1 que se ha comprimido al máximo. Miré los datos en el explorador, un Batch contenía miles de transacciones, y el costo por transacción es casi despreciable. Esto es un salvavidas para aquellos proyectos de GameFi o SocialFi. Muchos proyectos de GameFi han fracasado debido a los costos de interacción; los usuarios deben calcular Gas cada vez que hacen clic, lo que resulta en una experiencia muy mala. Aquí, intenté escribir un script que activara cinco mil llamadas de contrato de forma continua, y el saldo de mi billetera casi no se movió. Este bajo costo no se logra mediante subsidios, sino que está determinado por la arquitectura, y eso merece un buen reconocimiento.

Sin embargo, como un viejo en el juego y investigador, debo criticar las herramientas ecológicas actuales. Los exploradores de bloques son horriblemente anticuados, incluso la función de Decodificar Datos de Entrada lleva una eternidad encontrarla, lo que es extremadamente poco amigable para los geeks que aman consultar datos en la cadena. Además, la parte de construcción de nodos en la documentación oficial está escrita de manera extremadamente oscura, muchos parámetros ni siquiera están explicados, dejando todo a mi interpretación adivinando comentarios en el código de GitHub. Por ejemplo, el parámetro `challenge-period`, la documentación dice que es un valor predeterminado, pero al ejecutarlo descubrí que debía configurarlo manualmente, de lo contrario, la sincronización del nodo se colapsaría. Este tipo de errores básicos deben corregirse antes de que se lance en la mainnet, de lo contrario, la comunidad de desarrolladores no podrá despegar.

También hay un fenómeno interesante relacionado con la “vitalidad”. En Solana, si la red se cae, todos se quedan mirando. En la arquitectura de Plasma, incluso si un nodo operador se cae, teóricamente los usuarios aún pueden retirar fondos a través de contratos en L1. Simulé una situación de nodo fuera de línea, intentando forzar una salida a través de un contrato en L1. Aunque el proceso fue engorroso e implicó la presentación de una Prueba Merkle, efectivamente funcionó. Esta “salida sin permiso” es su mejor carta en comparación con las diversas sidechains y Rollups centralizados actuales. Le brinda al usuario una última línea de seguridad: mientras la mainnet de Ethereum no se caiga, mi dinero está seguro. Esta sensación de seguridad se siente especialmente valiosa después del colapso de FTX.

Comparado con Polygon (Matic), aunque este último también en sus inicios se presentaba bajo la bandera de Plasma, más tarde cambió casi completamente a un modelo de sidechain + PoS. El Polygon actual se asemeja más a una cadena independiente, cuya seguridad no se hereda completamente de Ethereum. Y la arquitectura actual parece haber regresado a sus raíces, intentando recuperar ese punto de equilibrio entre escalabilidad y seguridad. No intenta resolver todos los problemas, sino que se centra en “llevar los activos de forma segura fuera de la mainnet y realizar operaciones de alta frecuencia” en un único aspecto. Este enfoque de simplificación se destaca en este mercado ansioso donde todos quieren que una sola cadena haga AI, almacenamiento y privacidad al mismo tiempo.

La innovación técnica a menudo conlleva nuevos riesgos. Al leer el código del contrato, descubrí que para adaptarse a EVM, la lógica de conversión de UTXO subyacente es muy compleja, y aquí es muy fácil esconder vulnerabilidades de ataque de reentrada. Aunque no vi puertas traseras evidentes, no me atrevería a invertir grandes sumas de dinero sin varias rondas de auditoría de primer nivel en este código de complejidad. Especialmente ese contrato precompilado responsable de mapear entre UTXO y el modelo de cuentas, es el sueño de un hacker. Si esta capa de conversión es comprometida, podría resultar en la emisión de activos de la nada o ser bloqueada. Esta es la espada de Damocles que comparten todos los L2 que intentan fusionar dos modelos de cuentas.

Mirando hacia atrás, ¿por qué necesitamos volver a centrarnos en Plasma en 2026? Porque ya han surgido los cuellos de botella de Rollup. Ya sea la ventana de prueba de fraude de OP o el costo de generación de pruebas ZK, ambos limitan la explosión adicional de L2. Especialmente ante la demanda de computación masiva que implica la inferencia de AI en la cadena, la arquitectura actual de Rollup parece estar fuera de su alcance. Y el modelo de Plasma de “solo comprometer, no calcular”, podría convertirse en el mejor vehículo para que los Agentes de AI interactúen en la cadena. Imagina miles de agentes de AI en la cadena jugando a alta frecuencia; si cada transacción necesita consenso total en la red, Ethereum ya habría colapsado. Si solo se intercambian firmas y propiedad, el límite teórico de TPS puede elevarse indefinidamente.

Durante el proceso de prueba, también descubrí un detalle interesante: la capacidad de la red para resistir congestiones. El miércoles por la noche, coincidió con un proyecto de bajo perfil lanzando tokens en la mainnet y en varias L2, causando que el Gas de Base y Arb se disparara, y RPC se congestionara. Pero aquí, debido al aislamiento del entorno de ejecución, casi no se vio afectado. Esta capacidad de aislamiento es crucial para construir un intercambio descentralizado (DEX). No querrás que alguien jugando a CryptoKitties te haga perder tu margen, ¿verdad?

Por supuesto, la experiencia actual está lejos de ser “adopción masiva”. La adaptación de billeteras es un gran problema. Aunque MetaMask puede conectarse, muchos de los formatos de firma son personalizados, y lo que los usuarios ven a menudo es una serie de caracteres Hex que no entienden, lo que representa un gran riesgo para la seguridad. Si no se resuelve el problema de “lo que ves es lo que firmas”, los usuarios comunes pueden ser fácilmente víctimas de phishing. El equipo parece estar impulsando su propio SDK, pero esto aumenta la dificultad de integración para los desarrolladores. Abrirse camino en el actual mar de billeteras es más fácil decirlo que hacerlo.

En general, la profunda interacción de esta semana me mostró una posibilidad: en el desenlace de las blockchains modularizadas, Rollup podría no ser la única respuesta. Para aquellos activos que tienen exigencias extremas de seguridad pero no pueden soportar el rendimiento de la mainnet —como pagos grandes o liquidaciones de bonos— esta arquitectura de Plasma ofrece un compromiso atractivo. No es perfecta, la documentación es deficiente, las herramientas son rudimentarias, e incluso a veces hay errores inexplicables, pero la lógica subyacente de “no confiar en nadie, solo en matemáticas y en la mainnet” es válida.

No recomendaría lanzarse como un contribuyente temprano a menos que seas un desarrollador realmente interesado en la tecnología subyacente. Para los inversores minoristas, entrar ahora probablemente significa ser un conejillo de indias. Pero si eres un investigador en infraestructura, definitivamente vale la pena dedicar tiempo a ejecutar un nodo. En esos caracteres verdes que parpadean constantemente, quizás puedas ver un desenlace diferente en la guerra de escalabilidad. No se trata de quién puede correr más rápido, sino de quién puede sobrevivir más tiempo garantizando la descentralización. Esta industria da vueltas y, al final, se trata de quién puede mantener la línea de “Code is Law”, no de quién hace las presentaciones más atractivas.

\u003cm-37/\u003e\u003cc-38/\u003e\u003ct-39/\u003e