El triángulo de la escalabilidad sostiene que existe una contradicción entre las tres características de la descentralización, la escalabilidad y la seguridad en blockchain. No es un teorema estricto, sino que plantea un argumento matemático 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, lo que significa que un atacante solo necesita comprometer unos pocos nodos para llevar a cabo una transacción maliciosa; o tus nodos se volverán poderosos y tu cadena no estará descentralizada.
Durante años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, a menudo optimizando los nodos mediante técnicas de ingeniería de software. Esto siempre es engañoso, ya que ejecutar nodos en estas cadenas es mucho más difícil que ejecutar nodos en Ethereum.
Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar que una cierta cantidad de datos está disponible y que una cierta cantidad de pasos de cálculo se ejecutan correctamente, con solo descargar una pequeña cantidad de datos y realizar 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 fundamentales de las cadenas no escalables, es decir, incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de los tres caminos es la arquitectura Plasma, que utiliza una tecnología ingeniosa para trasladar la responsabilidad de la disponibilidad de datos de monitoreo a los usuarios de una manera compatible con los incentivos. Con la popularización de los SNARKs, la arquitectura Plasma se vuelve más viable para una gama de casos de uso más amplia que nunca.
Avances adicionales en el muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se active la actualización de Dencun, la blockchain de Ethereum tendrá 3 blobs de aproximadamente 125 kB en cada slot de 12 segundos, o un ancho de banda de datos disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de las transacciones se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el TPS máximo de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si añadimos el calldata de Ethereum, se convierte en 607 TPS. Usando PeerDAS, el número de blobs podría aumentar a 8-16, lo que proporcionaría 463-926 TPS para el calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Queremos más escalabilidad. Nuestro objetivo a medio plazo es de 16 MB por slot, lo que, combinado con mejoras en la compresión de datos de Rollup, traerá ~58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "1D sampling". En Ethereum, cada blob es un polinomio de 4096 en el campo primo de 253 bits. Transmitimos las participaciones del polinomio, donde cada participación contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier conjunto de 4096 puede recuperar el blob.
El funcionamiento de PeerDAS es hacer que cada cliente escuche una pequeña cantidad de subredes, donde la i-ésima subred emite la i-ésima muestra de cualquier blob, y solicita los blobs de otras subredes que necesita consultando a los pares en la red p2p global. Una versión más conservadora, SubnetDAS, utiliza únicamente el mecanismo de subredes, sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en la prueba de participación usen SubnetDAS, mientras que otros nodos usen PeerDAS.
Teóricamente, podemos escalar el "muestreo 1D" bastante grande: si aumentamos el número máximo de blobs a 256, podemos alcanzar el objetivo de 16 MB, y con 16 muestras por nodo en el muestreo de disponibilidad de datos * 128 blobs * 512 bytes por blob y por muestra = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro de nuestro rango de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto hasta cierto punto reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto haría que el costo de reconstrucción fuera más alto.
Por lo tanto, finalmente queremos ir un paso más allá y realizar un muestreo 2D, este método no solo realiza muestreo aleatorio dentro de los blobs, sino también entre los blobs. Aprovechando la propiedad lineal de los compromisos KZG, se expande el conjunto de blobs dentro de un bloque a través de un conjunto de nuevos blobs virtuales, que codifican de manera redundante la misma información.
Es crucial que la expansión del compromiso de cálculo no requiera blobs, por lo que esta solución es fundamentalmente amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG de los blobs, y pueden confiar en el muestreo de disponibilidad de datos para verificar la disponibilidad de los bloques de datos. El muestreo de disponibilidad de datos unidimensional también es esencialmente amigable para la construcción de bloques distribuidos.
¿Qué más se necesita hacer? ¿Y qué compensaciones hay?
A continuación se completará la implementación y lanzamiento de PeerDAS. Después, se aumentará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad; este es un proceso gradual. Al mismo tiempo, esperamos más trabajos académicos para regular PeerDAS y otras versiones de DAS y su interacción con cuestiones de seguridad como las reglas de selección de bifurcación.
En etapas futuras más lejanas, necesitamos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una solución alternativa que sea segura contra cuántica y no requiera configuraciones de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso utilizando la costosa técnica de "fuerza bruta", es decir, utilizando STARK recursivo para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, ya que aunque técnicamente, el tamaño de un STARK es O(log(n) * log(log(n)) hash, en realidad el STARK es casi del tamaño de todo el blob.
El camino de realidad a largo plazo que creo 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 nuestra principal arquitectura Layer2 de interés.
Por favor, ten en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques de L1 se volverán muy grandes, y los clientes querrán tener un método eficiente para verificar su corrección, por lo que tendremos que utilizar la misma tecnología que Rollup en la capa L1.
¿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 al menos se retrasará, y si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea 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 esto necesita combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación circundante.
Compresión de datos
¿Qué problema estamos resolviendo?
Cada transacción en un Rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia 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 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si no solo pudiéramos resolver el problema del numerador, sino también el problema del denominador, haciendo que cada transacción en el Rollup ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En mi opinión, la mejor explicación es esta imagen de hace dos años:
En la compresión de ceros, se reemplaza cada secuencia larga de ceros por dos bytes que indican cuántos ceros hay. Más allá de eso, aprovechamos propiedades específicas de las transacciones:
Agregación de firmas: Hemos cambiado de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, y esta firma puede probar la validez de todas las firmas originales. En la capa L1, debido a que incluso con la agregación, el costo computacional de la verificación sigue siendo alto, no se considera el uso de firmas BLS. Pero en L2, en un entorno de escasez de datos, tiene sentido usar firmas BLS. La característica de agregación de ERC-4337 proporciona un camino para implementar esta función.
Reemplazar direcciones con punteros: Si se ha utilizado una dirección anteriormente, 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 de valores de transacción------La mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 Ether se representa como 250,000,000,000,000,000 wei. Las tarifas base máximas y las tarifas prioritarias son similares. Por lo tanto, podemos usar un formato de punto decimal personalizado para representar la mayoría de los valores monetarios.
¿Qué más se necesita hacer, qué compromisos hay?
Lo que se debe hacer a continuación es implementar realmente el plan mencionado anteriormente. Las principales consideraciones incluyen:
Cambiar a la firma BLS requiere un gran esfuerzo y disminuirá la compatibilidad con los chips de hardware confiables que pueden mejorar la seguridad. Se puede utilizar un encapsulado ZK-SNARK de otros esquemas de firma como alternativa.
Compresión dinámica ( Por ejemplo, reemplazar direcciones ) con punteros haría que el código del cliente se volviera complejo.
Publicar las diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos software (, como los exploradores de bloques ), no funcionen.
¿Cómo interactuar con otras partes de la hoja de ruta?
La adopción de ERC-4337 y la eventual incorporación de parte de su contenido en L2 EVM puede acelerar significativamente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en L1 puede acelerar su implementación en L2.
Plasma Generalizado
¿Qué problema estamos resolviendo?
Incluso utilizando blobs de 16 MB y compresión de datos, 58,000 TPS puede no ser suficiente para satisfacer completamente las demandas de pagos de consumidores, redes sociales descentralizadas u otros campos de alto ancho de banda, especialmente cuando comenzamos a considerar factores de privacidad, lo que podría reducir la escalabilidad de 3 a 8 veces. Para escenarios de aplicaciones de alto volumen de transacciones y bajo valor, una opción actual es utilizar Validium, que almacena datos fuera de la cadena y adopta un modelo de seguridad interesante: los operadores no pueden robar los fondos de los usuarios, pero pueden congelar temporal o permanentemente los fondos de todos los usuarios. Pero podemos hacerlo mejor.
¿Qué es y cómo funciona?
Plasma es una solución de escalabilidad que implica que un operador publique bloques fuera de la cadena y coloque la raíz de Merkle de estos bloques en la cadena. Para cada bloque, el operador enviará a cada usuario una rama de Merkle para demostrar qué cambios han ocurrido en los activos de ese usuario, o que no ha habido cambios. Los usuarios pueden retirar sus activos proporcionando la rama de Merkle. Es importante que esta rama no tenga que ser la raíz del estado más reciente. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo su estado más reciente disponible. Si un usuario presenta una rama no válida, se puede determinar la legitimidad de 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 pago, y no podían escalar de manera efectiva. Sin embargo, si requerimos que cada raíz sea verificada con SNARK, entonces Plasma se volverá mucho más poderoso. Cada juego de desafío se puede simplificar enormemente,
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.
4 me gusta
Recompensa
4
4
Republicar
Compartir
Comentar
0/400
NeverVoteOnDAO
· hace2h
Otra vez hablando tonterías, el nodo no puede funcionar.
Ver originalesResponder0
FancyResearchLab
· hace2h
Valor académico bomba, fui a hacer un pequeño experimento.
Ver originalesResponder0
BlockchainThinkTank
· hace2h
No importa cuán elaboradas sean las palabras, los datos nunca mienten, se sugiere que los tontos observen cómo se desarrolla la situación.
Ver originalesResponder0
FudVaccinator
· hace3h
El trilema de trilema aún no se puede evitar, hay que enfrentarlo.
Ethereum The Surge: Rompiendo los límites de escalabilidad
Futuro de Ethereum: The Surge
Paradoja del triángulo de escalabilidad
El triángulo de la escalabilidad sostiene que existe una contradicción entre las tres características de la descentralización, la escalabilidad y la seguridad en blockchain. No es un teorema estricto, sino que plantea un argumento matemático 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, lo que significa que un atacante solo necesita comprometer unos pocos nodos para llevar a cabo una transacción maliciosa; o tus nodos se volverán poderosos y tu cadena no estará descentralizada.
Durante años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, a menudo optimizando los nodos mediante técnicas de ingeniería de software. Esto siempre es engañoso, ya que ejecutar nodos en estas cadenas es mucho más difícil que ejecutar nodos en Ethereum.
Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar que una cierta cantidad de datos está disponible y que una cierta cantidad de pasos de cálculo se ejecutan correctamente, con solo descargar una pequeña cantidad de datos y realizar 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 fundamentales de las cadenas no escalables, es decir, incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de los tres caminos es la arquitectura Plasma, que utiliza una tecnología ingeniosa para trasladar la responsabilidad de la disponibilidad de datos de monitoreo a los usuarios de una manera compatible con los incentivos. Con la popularización de los SNARKs, la arquitectura Plasma se vuelve más viable para una gama de casos de uso más amplia que nunca.
Avances adicionales en el muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se active la actualización de Dencun, la blockchain de Ethereum tendrá 3 blobs de aproximadamente 125 kB en cada slot de 12 segundos, o un ancho de banda de datos disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de las transacciones se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el TPS máximo de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si añadimos el calldata de Ethereum, se convierte en 607 TPS. Usando PeerDAS, el número de blobs podría aumentar a 8-16, lo que proporcionaría 463-926 TPS para el calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Queremos más escalabilidad. Nuestro objetivo a medio plazo es de 16 MB por slot, lo que, combinado con mejoras en la compresión de datos de Rollup, traerá ~58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "1D sampling". En Ethereum, cada blob es un polinomio de 4096 en el campo primo de 253 bits. Transmitimos las participaciones del polinomio, donde cada participación contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier conjunto de 4096 puede recuperar el blob.
El funcionamiento de PeerDAS es hacer que cada cliente escuche una pequeña cantidad de subredes, donde la i-ésima subred emite la i-ésima muestra de cualquier blob, y solicita los blobs de otras subredes que necesita consultando a los pares en la red p2p global. Una versión más conservadora, SubnetDAS, utiliza únicamente el mecanismo de subredes, sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en la prueba de participación usen SubnetDAS, mientras que otros nodos usen PeerDAS.
Teóricamente, podemos escalar el "muestreo 1D" bastante grande: si aumentamos el número máximo de blobs a 256, podemos alcanzar el objetivo de 16 MB, y con 16 muestras por nodo en el muestreo de disponibilidad de datos * 128 blobs * 512 bytes por blob y por muestra = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro de nuestro rango de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto hasta cierto punto reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto haría que el costo de reconstrucción fuera más alto.
Por lo tanto, finalmente queremos ir un paso más allá y realizar un muestreo 2D, este método no solo realiza muestreo aleatorio dentro de los blobs, sino también entre los blobs. Aprovechando la propiedad lineal de los compromisos KZG, se expande el conjunto de blobs dentro de un bloque a través de un conjunto de nuevos blobs virtuales, que codifican de manera redundante la misma información.
Es crucial que la expansión del compromiso de cálculo no requiera blobs, por lo que esta solución es fundamentalmente amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG de los blobs, y pueden confiar en el muestreo de disponibilidad de datos para verificar la disponibilidad de los bloques de datos. El muestreo de disponibilidad de datos unidimensional también es esencialmente amigable para la construcción de bloques distribuidos.
¿Qué más se necesita hacer? ¿Y qué compensaciones hay?
A continuación se completará la implementación y lanzamiento de PeerDAS. Después, se aumentará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad; este es un proceso gradual. Al mismo tiempo, esperamos más trabajos académicos para regular PeerDAS y otras versiones de DAS y su interacción con cuestiones de seguridad como las reglas de selección de bifurcación.
En etapas futuras más lejanas, necesitamos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una solución alternativa que sea segura contra cuántica y no requiera configuraciones de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso utilizando la costosa técnica de "fuerza bruta", es decir, utilizando STARK recursivo para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, ya que aunque técnicamente, el tamaño de un STARK es O(log(n) * log(log(n)) hash, en realidad el STARK es casi del tamaño de todo el blob.
El camino de realidad a largo plazo que creo es:
Por favor, ten en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques de L1 se volverán muy grandes, y los clientes querrán tener un método eficiente para verificar su corrección, por lo que tendremos que utilizar la misma tecnología que Rollup en la capa L1.
¿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 al menos se retrasará, y si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea 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 esto necesita combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación circundante.
Compresión de datos
¿Qué problema estamos resolviendo?
Cada transacción en un Rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia 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 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si no solo pudiéramos resolver el problema del numerador, sino también el problema del denominador, haciendo que cada transacción en el Rollup ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En mi opinión, la mejor explicación es esta imagen de hace dos años:
En la compresión de ceros, se reemplaza cada secuencia larga de ceros por dos bytes que indican cuántos ceros hay. Más allá de eso, aprovechamos propiedades específicas de las transacciones:
Agregación de firmas: Hemos cambiado de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, y esta firma puede probar la validez de todas las firmas originales. En la capa L1, debido a que incluso con la agregación, el costo computacional de la verificación sigue siendo alto, no se considera el uso de firmas BLS. Pero en L2, en un entorno de escasez de datos, tiene sentido usar firmas BLS. La característica de agregación de ERC-4337 proporciona un camino para implementar esta función.
Reemplazar direcciones con punteros: Si se ha utilizado una dirección anteriormente, 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 de valores de transacción------La mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 Ether se representa como 250,000,000,000,000,000 wei. Las tarifas base máximas y las tarifas prioritarias son similares. Por lo tanto, podemos usar un formato de punto decimal personalizado para representar la mayoría de los valores monetarios.
¿Qué más se necesita hacer, qué compromisos hay?
Lo que se debe hacer a continuación es implementar realmente el plan mencionado anteriormente. Las principales consideraciones incluyen:
Cambiar a la firma BLS requiere un gran esfuerzo y disminuirá la compatibilidad con los chips de hardware confiables que pueden mejorar la seguridad. Se puede utilizar un encapsulado ZK-SNARK de otros esquemas de firma como alternativa.
Compresión dinámica ( Por ejemplo, reemplazar direcciones ) con punteros haría que el código del cliente se volviera complejo.
Publicar las diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos software (, como los exploradores de bloques ), no funcionen.
¿Cómo interactuar con otras partes de la hoja de ruta?
La adopción de ERC-4337 y la eventual incorporación de parte de su contenido en L2 EVM puede acelerar significativamente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en L1 puede acelerar su implementación en L2.
Plasma Generalizado
¿Qué problema estamos resolviendo?
Incluso utilizando blobs de 16 MB y compresión de datos, 58,000 TPS puede no ser suficiente para satisfacer completamente las demandas de pagos de consumidores, redes sociales descentralizadas u otros campos de alto ancho de banda, especialmente cuando comenzamos a considerar factores de privacidad, lo que podría reducir la escalabilidad de 3 a 8 veces. Para escenarios de aplicaciones de alto volumen de transacciones y bajo valor, una opción actual es utilizar Validium, que almacena datos fuera de la cadena y adopta un modelo de seguridad interesante: los operadores no pueden robar los fondos de los usuarios, pero pueden congelar temporal o permanentemente los fondos de todos los usuarios. Pero podemos hacerlo mejor.
¿Qué es y cómo funciona?
Plasma es una solución de escalabilidad que implica que un operador publique bloques fuera de la cadena y coloque la raíz de Merkle de estos bloques en la cadena. Para cada bloque, el operador enviará a cada usuario una rama de Merkle para demostrar qué cambios han ocurrido en los activos de ese usuario, o que no ha habido cambios. Los usuarios pueden retirar sus activos proporcionando la rama de Merkle. Es importante que esta rama no tenga que ser la raíz del estado más reciente. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo su estado más reciente disponible. Si un usuario presenta una rama no válida, se puede determinar la legitimidad de 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 pago, y no podían escalar de manera efectiva. Sin embargo, si requerimos que cada raíz sea verificada con SNARK, entonces Plasma se volverá mucho más poderoso. Cada juego de desafío se puede simplificar enormemente,