La estrategia de escalado de Ethereum inicialmente tenía dos enfoques: sharding y Layer2. El sharding permite que cada nodo verifique y almacene solo una pequeña parte de las transacciones, mientras que Layer2 coloca la mayor parte de los datos y cálculos fuera de la cadena principal. Estos dos caminos finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado de Ethereum hasta el día de hoy.
La hoja de ruta centrada en Rollup presenta una división de trabajo simple: Ethereum L1 se enfoca en convertirse en una capa base fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es muy común en la sociedad: el sistema judicial (L1) existe para proteger los contratos y la propiedad, mientras que los emprendedores (L2) construyen sobre esta base, impulsando el desarrollo humano.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes resultados: el lanzamiento de blobs EIP-4844 ha aumentado significativamente el ancho de banda de datos de Ethereum L1, y varios EVM Rollups han entrado en la primera etapa. Cada L2 existe como un "fragmento" con reglas y lógica internas, y la diversidad en la implementación de fragmentos se ha convertido en una realidad. Sin embargo, este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar esta hoja de ruta y resolver estos problemas, mientras mantenemos la robustez y descentralización de Ethereum L1.
The Surge: Objetivos clave
En el futuro, Ethereum podrá alcanzar más de 100,000 TPS a través de L2.
Mantener la descentralización y robustez de L1
Al menos algunos L2 heredan completamente las propiedades centrales de Ethereum: ( de confianza, abiertas, resistentes a la censura ).
Ethereum debería sentirse como un ecosistema unificado, y no como 34 cadenas de bloques diferentes.
Contenido de este capítulo
La paradoja del triángulo de escalabilidad
Avances adicionales en el muestreo de disponibilidad de datos
Compresión de datos
Plasma Generalizado
Sistema de prueba L2 maduro
Mejora de la interoperabilidad entre L2
Ampliar la ejecución en L1
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad sostiene que existe una contradicción entre las tres características de descentralización, escalabilidad y seguridad de la blockchain. No es un teorema, sino que presenta un argumento heurístico: si un nodo amigable con la descentralización puede verificar N transacciones por segundo, y tienes una cadena que puede procesar k*N transacciones por segundo, entonces o cada transacción solo puede ser vista por 1/k nodos, o tus nodos se volverán poderosos, y la cadena no será descentralizada.
Algunas cadenas de alto rendimiento afirman resolver la paradoja de los tres, generalmente optimizando el software de nodos. Pero esto suele ser engañoso, ya que ejecutar nodos en estas cadenas es más difícil que en Ethereum. La ingeniería de software del cliente L1 por sí sola no puede escalar Ethereum.
Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja triangular: permite a los clientes verificar la disponibilidad de grandes cantidades de datos y la correcta ejecución de pasos de cálculo, descargando solo una pequeña cantidad de datos y realizando muy poco cálculo. Los SNARKs no requieren confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características básicas de una cadena no escalable.
La arquitectura Plasma es otra solución que transfiere la responsabilidad de monitorear la disponibilidad de datos a los usuarios. Con la popularización de los SNARKs, Plasma se vuelve viable para una gama más amplia de escenarios.
Avances adicionales en el muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
Después de la actualización Dencun el 13 de marzo de 2024, Ethereum tendrá 3 blobs de aproximadamente 125 kB cada 12 segundos por slot, con un ancho de banda de datos disponible de aproximadamente 375 kB/slot. Suponiendo que los datos de la transacción se publiquen directamente en la cadena, una transferencia ERC20 de aproximadamente 180 bytes, la máxima TPS de Rollup en Ethereum será de 173.6.
Con calldata, se puede alcanzar hasta 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, proporcionando 463-926 TPS para calldata.
Esta es una mejora significativa para L1, pero no es suficiente. Nuestro objetivo a medio plazo es de 16 MB por slot, combinado con la compresión de datos de Rollup, lo que traerá ~58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación simple de "muestreo 1D". En Ethereum, cada blob es un polinomio de 4096 sobre un campo primo de 253 bits. Transmitimos las participaciones del polinomio, cada una de las cuales contiene 16 valores evaluados de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores evaluados, cualquier conjunto de 4096 puede restaurar el blob.
PeerDAS permite que cada cliente escuche una pequeña cantidad de subredes. La i-ésima subred transmite la i-ésima muestra de cualquier blob y solicita blobs en otras subredes preguntando a los pares en la red p2p global. SubnetDAS utiliza únicamente el mecanismo de subred sin consultas adicionales a la capa de pares. La propuesta actual permite que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos utilizan PeerDAS.
Teóricamente, podemos escalar la "muestra 1D" a una gran escala: si aumentamos el número máximo de blobs a 256, se puede alcanzar el objetivo de 16MB, con cada nodo requiriendo 1MB de ancho de banda de datos por slot. Esto es apenas viable, pero los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto aumentará el costo de reconstrucción.
Por lo tanto, al final queremos muestreo 2D, no solo dentro de los blobs, sino también realizando muestreo aleatorio entre los blobs. Utilizando la propiedad lineal del compromiso KZG, se expande el conjunto de blobs de un bloque a través de nuevos blobs virtuales, los cuales codifican redundamente la misma información.
La muestreo 2D es amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan el compromiso KZG de blob y pueden confiar en DAS para verificar la disponibilidad. El DAS 1D también es esencialmente amigable para la construcción de bloques distribuidos.
¿Cuáles son los enlaces con las investigaciones existentes?
Introducción al post original sobre la disponibilidad de datos (2018)
Documento de seguimiento
Artículo explicativo sobre DAS
Disponibilidad 2D con compromiso KZG
PeerDAS y el artículo en ethresear.ch
EIP-7594
SubnetDAS en ethresear.ch
Matices de recuperabilidad en muestreo 2D
¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación se encuentra la implementación y el lanzamiento de PeerDAS. Después, se aumentará constantemente el número de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad. Esperamos más trabajos académicos que regulen PeerDAS y su interacción con cuestiones de seguridad como las reglas de selección de bifurcaciones.
En el futuro, también será necesario determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. Esperamos poder pasar de KZG a soluciones alternativas que sean seguras frente a la cuántica y que no requieran un entorno de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos.
El camino de realidad a largo plazo que creo que es:
Implementar un DAS 2D ideal
Mantener el uso de 1D DAS, sacrificando la eficiencia del ancho de banda de muestreo, aceptando un límite de datos más bajo por simplicidad y robustez.
Renunciar a DA y aceptar completamente Plasma como la principal arquitectura Layer2.
Incluso si decidimos escalar la ejecución directamente en la capa L1, esta opción existe. Porque si L1 tiene que manejar un gran número de TPS, los bloques de L1 se volverán muy grandes, y los clientes necesitarán métodos de verificación eficientes, por lo tanto, tendremos que usar la misma tecnología en la capa L1 que en Rollup.
¿Cómo interactuar con otras partes de la hoja de ruta?
Si se logra la compresión de datos, la demanda de 2D DAS disminuirá o se retrasará, y si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también presenta desafíos para los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica necesita combinarse con propuestas de listas de inclusión de paquetes y los mecanismos de selección de bifurcación asociados.
Compresión de datos
¿Qué problema estamos resolviendo?
Cada transacción en Rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia de ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo Layer. Cada slot es de 16MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos hacer que las transacciones en el Rollup ocupen menos bytes en la cadena?
¿Qué es y cómo funciona?
La mejor explicación es esta imagen de hace dos años:
La compresión de cero bytes implica reemplazar cada larga secuencia de cero bytes con dos bytes que indican cuántos cero bytes hay. Además, hemos aprovechado ciertas propiedades específicas de las transacciones:
Agregación de firmas: cambiar de firmas ECDSA a firmas BLS, donde múltiples firmas pueden combinarse en una única firma, probando la validez de todas las firmas originales. En L1, debido al alto costo de cálculo de verificación, no se considera el uso de BLS, pero en L2, un entorno con escasez de datos, tiene sentido utilizar BLS. Las características de agregación de ERC-4337 proporcionan un camino para implementar esta funcionalidad.
Reemplace la dirección con punteros: si ha utilizado alguna vez una dirección anterior, podemos reemplazar la dirección de 20 bytes por un puntero de 4 bytes que apunte a una posición en el historial.
Serialización personalizada del valor de transacción: La mayoría de los valores de transacción tienen pocos dígitos, como 0.25 Ether representado como 250,000,000,000,000,000 wei. La tarifa base máxima y la tarifa prioritaria también son similares. Por lo tanto, podemos usar un formato de punto flotante decimal personalizado para representar la mayoría de los valores monetarios.
¿Cuáles son los enlaces con la investigación existente?
Explorar sequence.xyz
Contrato de optimización de Calldata L2
Diferencias en el estado de publicación de Rollups basadas en la prueba de validez en lugar de transacciones
BLS Wallet - Implementación de BLS Aggregation a través de ERC-4337
¿Qué más se necesita hacer y qué consideraciones hay?
A continuación, se trata de implementar realmente el plan anterior. Las principales consideraciones incluyen:
Cambiar a la firma BLS requiere un gran esfuerzo y reducirá la compatibilidad con chips de hardware confiables. Se puede utilizar un encapsulamiento ZK-SNARK de otros esquemas de firma como alternativa.
La compresión dinámica (, si se reemplazan las direcciones por punteros ), hará que el código del cliente sea más complejo.
Publicar diferencias de estado en la cadena en lugar de en transacciones reducirá la auditabilidad, lo que hará que muchos softwares (, como exploradores de bloques ), no funcionen.
¿Cómo interactuar con otras partes del mapa de ruta?
Adoptar ERC-4337 y finalmente incorporar parte de él en L2 EVM puede acelerar considerablemente el despliegue de la tecnología de agregación. Colocar parte de ERC-4337 en L1 puede acelerar su implementación en L2.
Plasma Generalizado
¿Qué problema estamos resolviendo?
Incluso con un blob de 16 MB y compresión de datos, 58,000 TPS puede que no satisfaga completamente las necesidades de alto ancho de banda en áreas como pagos de consumidores y redes sociales descentralizadas, especialmente considerando que los factores de privacidad pueden reducir la escalabilidad de 3 a 8 veces. Actualmente, la opción para escenarios de alto volumen de transacciones y bajo valor es Validium, que almacena datos fuera de la cadena y utiliza un modelo de seguridad: el operador no puede robar los fondos de los usuarios, pero puede congelar temporal o permanentemente todos los fondos de los usuarios. Pero podemos hacerlo mejor.
¿Qué es y cómo funciona?
Plasma es una solución de escalado en la que los operadores publican bloques fuera de la cadena y solo colocan la raíz Merkle de estos bloques en la cadena. Para cada bloque, el operador envía a cada usuario una rama Merkle que prueba el cambio o la inmutabilidad de los activos de ese usuario. Los usuarios pueden extraer activos proporcionando la rama Merkle. Es importante destacar que esta rama no tiene que tener el estado más reciente como raíz. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar activos extrayendo el estado más reciente disponible. Si un usuario presenta una rama no válida, se puede determinar la propiedad de los activos a través del mecanismo de desafío en la cadena.
Las versiones tempranas de Plasma solo podían manejar casos de uso de pagos, lo que dificultaba su promoción efectiva. Pero
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Ethereum The Surge: A través de L2 lograr el objetivo de escalabilidad de 100,000 TPS y sus desafíos
Ethereum posible futuro: The Surge
La estrategia de escalado de Ethereum inicialmente tenía dos enfoques: sharding y Layer2. El sharding permite que cada nodo verifique y almacene solo una pequeña parte de las transacciones, mientras que Layer2 coloca la mayor parte de los datos y cálculos fuera de la cadena principal. Estos dos caminos finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado de Ethereum hasta el día de hoy.
La hoja de ruta centrada en Rollup presenta una división de trabajo simple: Ethereum L1 se enfoca en convertirse en una capa base fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es muy común en la sociedad: el sistema judicial (L1) existe para proteger los contratos y la propiedad, mientras que los emprendedores (L2) construyen sobre esta base, impulsando el desarrollo humano.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes resultados: el lanzamiento de blobs EIP-4844 ha aumentado significativamente el ancho de banda de datos de Ethereum L1, y varios EVM Rollups han entrado en la primera etapa. Cada L2 existe como un "fragmento" con reglas y lógica internas, y la diversidad en la implementación de fragmentos se ha convertido en una realidad. Sin embargo, este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar esta hoja de ruta y resolver estos problemas, mientras mantenemos la robustez y descentralización de Ethereum L1.
The Surge: Objetivos clave
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad sostiene que existe una contradicción entre las tres características de descentralización, escalabilidad y seguridad de la blockchain. No es un teorema, sino que presenta un argumento heurístico: si un nodo amigable con la descentralización puede verificar N transacciones por segundo, y tienes una cadena que puede procesar k*N transacciones por segundo, entonces o cada transacción solo puede ser vista por 1/k nodos, o tus nodos se volverán poderosos, y la cadena no será descentralizada.
Algunas cadenas de alto rendimiento afirman resolver la paradoja de los tres, generalmente optimizando el software de nodos. Pero esto suele ser engañoso, ya que ejecutar nodos en estas cadenas es más difícil que en Ethereum. La ingeniería de software del cliente L1 por sí sola no puede escalar Ethereum.
Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja triangular: permite a los clientes verificar la disponibilidad de grandes cantidades de datos y la correcta ejecución de pasos de cálculo, descargando solo una pequeña cantidad de datos y realizando muy poco cálculo. Los SNARKs no requieren confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características básicas de una cadena no escalable.
La arquitectura Plasma es otra solución que transfiere la responsabilidad de monitorear la disponibilidad de datos a los usuarios. Con la popularización de los SNARKs, Plasma se vuelve viable para una gama más amplia de escenarios.
Avances adicionales en el muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
Después de la actualización Dencun el 13 de marzo de 2024, Ethereum tendrá 3 blobs de aproximadamente 125 kB cada 12 segundos por slot, con un ancho de banda de datos disponible de aproximadamente 375 kB/slot. Suponiendo que los datos de la transacción se publiquen directamente en la cadena, una transferencia ERC20 de aproximadamente 180 bytes, la máxima TPS de Rollup en Ethereum será de 173.6.
Con calldata, se puede alcanzar hasta 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, proporcionando 463-926 TPS para calldata.
Esta es una mejora significativa para L1, pero no es suficiente. Nuestro objetivo a medio plazo es de 16 MB por slot, combinado con la compresión de datos de Rollup, lo que traerá ~58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación simple de "muestreo 1D". En Ethereum, cada blob es un polinomio de 4096 sobre un campo primo de 253 bits. Transmitimos las participaciones del polinomio, cada una de las cuales contiene 16 valores evaluados de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores evaluados, cualquier conjunto de 4096 puede restaurar el blob.
PeerDAS permite que cada cliente escuche una pequeña cantidad de subredes. La i-ésima subred transmite la i-ésima muestra de cualquier blob y solicita blobs en otras subredes preguntando a los pares en la red p2p global. SubnetDAS utiliza únicamente el mecanismo de subred sin consultas adicionales a la capa de pares. La propuesta actual permite que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos utilizan PeerDAS.
Teóricamente, podemos escalar la "muestra 1D" a una gran escala: si aumentamos el número máximo de blobs a 256, se puede alcanzar el objetivo de 16MB, con cada nodo requiriendo 1MB de ancho de banda de datos por slot. Esto es apenas viable, pero los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto aumentará el costo de reconstrucción.
Por lo tanto, al final queremos muestreo 2D, no solo dentro de los blobs, sino también realizando muestreo aleatorio entre los blobs. Utilizando la propiedad lineal del compromiso KZG, se expande el conjunto de blobs de un bloque a través de nuevos blobs virtuales, los cuales codifican redundamente la misma información.
La muestreo 2D es amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan el compromiso KZG de blob y pueden confiar en DAS para verificar la disponibilidad. El DAS 1D también es esencialmente amigable para la construcción de bloques distribuidos.
¿Cuáles son los enlaces con las investigaciones existentes?
¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación se encuentra la implementación y el lanzamiento de PeerDAS. Después, se aumentará constantemente el número de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad. Esperamos más trabajos académicos que regulen PeerDAS y su interacción con cuestiones de seguridad como las reglas de selección de bifurcaciones.
En el futuro, también será necesario determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. Esperamos poder pasar de KZG a soluciones alternativas que sean seguras frente a la cuántica y que no requieran un entorno de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos.
El camino de realidad a largo plazo que creo que es:
Incluso si decidimos escalar la ejecución directamente en la capa L1, esta opción existe. Porque si L1 tiene que manejar un gran número de TPS, los bloques de L1 se volverán muy grandes, y los clientes necesitarán métodos de verificación eficientes, por lo tanto, tendremos que usar la misma tecnología en la capa L1 que en Rollup.
¿Cómo interactuar con otras partes de la hoja de ruta?
Si se logra la compresión de datos, la demanda de 2D DAS disminuirá o se retrasará, y si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también presenta desafíos para los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica necesita combinarse con propuestas de listas de inclusión de paquetes y los mecanismos de selección de bifurcación asociados.
Compresión de datos
¿Qué problema estamos resolviendo?
Cada transacción en Rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia de ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo Layer. Cada slot es de 16MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos hacer que las transacciones en el Rollup ocupen menos bytes en la cadena?
¿Qué es y cómo funciona?
La mejor explicación es esta imagen de hace dos años:
La compresión de cero bytes implica reemplazar cada larga secuencia de cero bytes con dos bytes que indican cuántos cero bytes hay. Además, hemos aprovechado ciertas propiedades específicas de las transacciones:
Agregación de firmas: cambiar de firmas ECDSA a firmas BLS, donde múltiples firmas pueden combinarse en una única firma, probando la validez de todas las firmas originales. En L1, debido al alto costo de cálculo de verificación, no se considera el uso de BLS, pero en L2, un entorno con escasez de datos, tiene sentido utilizar BLS. Las características de agregación de ERC-4337 proporcionan un camino para implementar esta funcionalidad.
Reemplace la dirección con punteros: si ha utilizado alguna vez una dirección anterior, podemos reemplazar la dirección de 20 bytes por un puntero de 4 bytes que apunte a una posición en el historial.
Serialización personalizada del valor de transacción: La mayoría de los valores de transacción tienen pocos dígitos, como 0.25 Ether representado como 250,000,000,000,000,000 wei. La tarifa base máxima y la tarifa prioritaria también son similares. Por lo tanto, podemos usar un formato de punto flotante decimal personalizado para representar la mayoría de los valores monetarios.
¿Cuáles son los enlaces con la investigación existente?
¿Qué más se necesita hacer y qué consideraciones hay?
A continuación, se trata de implementar realmente el plan anterior. Las principales consideraciones incluyen:
Cambiar a la firma BLS requiere un gran esfuerzo y reducirá la compatibilidad con chips de hardware confiables. Se puede utilizar un encapsulamiento ZK-SNARK de otros esquemas de firma como alternativa.
La compresión dinámica (, si se reemplazan las direcciones por punteros ), hará que el código del cliente sea más complejo.
Publicar diferencias de estado en la cadena en lugar de en transacciones reducirá la auditabilidad, lo que hará que muchos softwares (, como exploradores de bloques ), no funcionen.
¿Cómo interactuar con otras partes del mapa de ruta?
Adoptar ERC-4337 y finalmente incorporar parte de él en L2 EVM puede acelerar considerablemente el despliegue de la tecnología de agregación. Colocar parte de ERC-4337 en L1 puede acelerar su implementación en L2.
Plasma Generalizado
¿Qué problema estamos resolviendo?
Incluso con un blob de 16 MB y compresión de datos, 58,000 TPS puede que no satisfaga completamente las necesidades de alto ancho de banda en áreas como pagos de consumidores y redes sociales descentralizadas, especialmente considerando que los factores de privacidad pueden reducir la escalabilidad de 3 a 8 veces. Actualmente, la opción para escenarios de alto volumen de transacciones y bajo valor es Validium, que almacena datos fuera de la cadena y utiliza un modelo de seguridad: el operador no puede robar los fondos de los usuarios, pero puede congelar temporal o permanentemente todos los fondos de los usuarios. Pero podemos hacerlo mejor.
¿Qué es y cómo funciona?
Plasma es una solución de escalado en la que los operadores publican bloques fuera de la cadena y solo colocan la raíz Merkle de estos bloques en la cadena. Para cada bloque, el operador envía a cada usuario una rama Merkle que prueba el cambio o la inmutabilidad de los activos de ese usuario. Los usuarios pueden extraer activos proporcionando la rama Merkle. Es importante destacar que esta rama no tiene que tener el estado más reciente como raíz. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar activos extrayendo el estado más reciente disponible. Si un usuario presenta una rama no válida, se puede determinar la propiedad de los activos a través del mecanismo de desafío en la cadena.
Las versiones tempranas de Plasma solo podían manejar casos de uso de pagos, lo que dificultaba su promoción efectiva. Pero