La disponibilidad de datos es uno de los principales cuellos de botella en la expansión de blockchain.
**Escrito por: **zer0kn0wledge.era
Compilado por: Kate, Marsbit
Nota: este artículo es de @expctchaos Twitter, que es un investigador de @ChaosDAO. El contenido del tweet original está organizado por MarsBit de la siguiente manera:
0/ La disponibilidad de datos (DA) es el principal cuello de botella del escalamiento
Afortunadamente, @CelestiaOrg, @AvailProject y @eigenlayer cambiarán el juego de DA y habilitarán nuevos niveles de escalabilidad.
Pero, ¿cómo funciona y en qué se diferencia #EigenDA de DA 15 como #Celestia y #Avail?
1/ Si no está familiarizado con los problemas de disponibilidad de datos, consulte mi publicación a continuación, donde describo la situación de disponibilidad de datos en detalle 👇
2/ En general, hay dos tipos principales de soluciones de procesamiento de datos
🔷DA en cadena
🔷DA fuera de la cadena
3/ Y "verificación de validez pura" significa que el procesamiento de datos puede estar fuera de la cadena sin garantías, porque los proveedores de servicios de datos fuera de la cadena pueden desconectarse en cualquier momento...
4/ …#StarkEx, #zkPorter y #Arbitrum Nova son ejemplos de escenarios de verificación que dependen de DAC, un grupo de terceros conocidos para garantizar la disponibilidad de datos
5/ Por otro lado, #EigenDA, @CelestiaOrg y @AvailProject son lo que podríamos llamar una solución DA universal
Sin embargo, existen algunas diferencias entre EigenDA y las otras dos soluciones.
6/ Si quieres saber cómo funciona @CelestiaOrg, consulta el siguiente enlace
7/ También he cubierto @AvailProject en el pasado, así que para obtener más información, échale un vistazo aquí.
8/ Si necesita un repaso en @eigenlayer, consulte el hilo a continuación 👇
9/ Así que en la publicación de hoy queremos centrarnos en la comparación entre las cadenas #EigenDA y DA L1 de @eigenlayer como @CelestiaOrg o @AvailProject
10/ Supongamos un resumen basado en Ethereum y usando Celestia para DA (también conocido como Celestium)
Entonces, los contratos L2 en Ethereum verifican la prueba de validez o la prueba de fraude como de costumbre, y Celestia proporciona DA
11/ En @CelestiaOrg y @AvailProject, no hay contratos inteligentes ni cálculos, solo se garantiza que los datos estén disponibles
12/ Pero echemos un vistazo más de cerca
En @CelestiaOrg, los datos de tx se publican en Celestia mediante el clasificador L2, el verificador de Celestia firma la raíz de Merkle de la prueba de DA y luego se envía al contrato de puente de DA en Ethereum para su verificación y almacenamiento.
13/ En comparación con el almacenamiento de DA en la cadena, esto reduce en gran medida el costo de tener una garantía sólida de DA, al mismo tiempo que brinda garantías de seguridad de Celestia (en lugar de un DAC centralizado)
14/ La reducción de costos cambiará las reglas del juego en todo el campo de resumen, porque el costo de los datos de llamadas generados al publicar datos en Ethereum L1 representa el 80-90 % del costo de resumen
Para obtener más información sobre el costo de los datos de llamadas, consulte la publicación a continuación 👇
15/ ¿Pero qué diablos pasó en #Celestia?
Los blobs de datos publicados en @CelestiaOrg (esencialmente como datos sin procesar) se propagan a través de la red P2P y se llega a un consenso sobre el blob de datos mediante el consenso de Tendermint.
16/ Cada nodo completo de #Celestia debe descargar el blob de datos completo. Esto es diferente para los nodos ligeros que pueden usar el muestreo de disponibilidad de datos (DAS) para garantizar la disponibilidad de los datos.
17/ Para obtener más información sobre DAS y nodos de luz, consulte la publicación a continuación
18/ También volveremos a DAS más adelante en este hilo, pero por ahora el enfoque está en los nodos completos.
Volvamos a @CelestiaOrg, que continúa comportándose de manera L1, basándose en la transmisión y el consenso sobre las manchas de datos.
19/ Por lo tanto, exige mucho a los nodos completos de la red (128 MB/s de descarga y 12,5 MB/s de carga).
Aún así, @CelestiaOrg apuntaba a un rendimiento moderado (1,4 MB/s) al principio, lo que parece bajo dados los requisitos de nodo completo
20/ Sin embargo, la red puede escalar el rendimiento agregando nodos ligeros. Cuantos más nodos ligeros de muestreo de datos, mayor puede ser el tamaño del bloque bajo la condición de garantizar la seguridad y la descentralización
21/ Por otro lado, @eigenlayer tiene una arquitectura diferente, sin consenso propio y sin red peer-to-peer
Entonces, ¿cómo funciona esto?
Primero, el nodo EigenDA debe reasignar $ETH en el contrato @eigenlayer. Por lo tanto, los nodos #EigenDA son un subconjunto de validadores de Ethereum
22/ Después de recibir el blob de datos, un comprador de DA (como un resumen, también conocido como dispersor) lo codifica con un código de borrado y genera un compromiso KZG...
23/... donde el tamaño de la prueba depende de la tasa de redundancia del código de borrado y publica el compromiso de KZG con el contrato inteligente #EigenDA
24/ Compromiso KZG codificado distribuido por dispersor a nodos #EigenDA
Después de recibir el compromiso KZG, estos nodos lo comparan con el compromiso KZG del contrato inteligente EigenDA y firman la prueba después de la confirmación.
25/ Después de eso, el dispersor recopila estas firmas una por una, genera una firma agregada y la publica en el contrato inteligente #EigenDA, y el contrato inteligente verifica la firma
26/ Pero si el nodo #EigenDA simplemente firma una prueba que afirma que almacenó el blob de datos codificados en este flujo de trabajo, y el contrato inteligente de EigenDA solo verifica la exactitud de la firma agregada, ¿cómo podemos estar seguros de que el nodo EigenDA realmente almacenó datos?
27/ #EigenDA utiliza un método de prueba de depósito en garantía para lograr esto
Pero demos un paso atrás y miremos esta escena donde se vuelve importante
28/ Supongamos que algunos validadores perezosos no están haciendo las tareas que se les han asignado (por ejemplo, asegurarse de que los datos estén disponibles)
En cambio, fingen que han hecho el trabajo y aprueban el resultado final (informando falsamente la disponibilidad de datos cuando no están disponibles).
29/ Conceptualmente, la prueba de custodia es como prueba de fraude:
Cualquiera puede enviar una prueba (validador perezoso) al contrato inteligente #EigenDA que será verificado por el contrato inteligente
29/ El validador perezoso se corta si la validación es exitosa (porque es un error objetivamente atribuible)
30/ ¿Qué pasa con el consenso?
@CelestiaOrg usa Tendermint como su protocolo de consenso, que tiene una finalidad de ranura única. Es decir, una vez que un bloque pasa el consenso de #Celestia, está listo. Esto significa que la finalidad es básicamente tan rápida como el tiempo de bloque (15 segundos).
31/ @AvailProject usa la composición del protocolo para lograr la finalidad. BABE es un mecanismo de producción de bloques con finalidad probabilística, y GRANDPA es un dispositivo final. Si bien GRANDPA puede completar bloques en una ranura, también puede completar varios bloques en una ronda.
32/ Dado que @eigenlayer es un conjunto de contratos inteligentes en Ethereum, también hereda el mismo tiempo de finalización que Ethereum (12 - 15 minutos) para los datos que deben reenviarse al contrato acumulativo para probar la disponibilidad de los datos.
33/ Sin embargo, si el resumen usa @eigenlayer, podría hacerse más rápido, dependiendo del mecanismo de consenso utilizado, etc.
Además, el middleware asegurado por los validadores de reasignación de @eigenlayer centrados en proporcionar liquidaciones rápidas, como EigenSettle, puede proporcionar sólidas garantías de seguridad económica que permiten la confirmación previa de la finalidad. Sin embargo, las garantías de firmeza de la finalidad aún provienen de Ethereum L1
34/ Hora de revisar los conceptos de muestreo de disponibilidad de datos
En la mayoría de las cadenas de bloques, los nodos necesitan descargar todos los datos de transacciones para verificar la disponibilidad de los datos. El problema que esto crea es que cuando aumenta el tamaño del bloque, también aumenta la cantidad de nodos de datos que deben verificarse.
35/ El muestreo de disponibilidad de datos (DAS) es una técnica que permite a los nodos ligeros verificar la disponibilidad de los datos descargando solo una pequeña porción de los datos del bloque.
36/ Esto proporciona seguridad a los nodos ligeros para que puedan validar bloques no válidos (solo DA y consenso) y permite que la cadena de bloques escale la disponibilidad de datos sin aumentar los requisitos de los nodos.
37/ DAS requiere al menos un nodo completo honesto y una cantidad suficiente de clientes ligeros
38/ Pero, ¿cómo garantizar la seguridad de los nodos de luz?
Los clientes ligeros tradicionales tienen suposiciones de seguridad más débiles en comparación con los nodos completos, ya que solo validan encabezados de bloque
Por lo tanto, los clientes ligeros no pueden detectar si una mayoría deshonesta de productores de bloques produjo un bloque no válido.
39/ Los nodos ligeros con muestreo de disponibilidad de datos se actualizan en seguridad, porque si la capa DA solo hace consenso y disponibilidad de datos, pueden verificar si se producen bloques no válidos
40/ Tanto @CelestiaOrg como @AvailProject tendrán muestreo de disponibilidad de datos, por lo que sus nodos ligeros tendrán seguridad de confianza minimizada.
41/ Esto es diferente de Ethereum y @eigenlayer
Ethereum con #EIP4844 no tiene muestreo de disponibilidad de datos, por lo que sus clientes ligeros no tendrán seguridad de confianza minimizada
42/ Dado que Ethereum también tiene su entorno de contrato inteligente, los clientes ligeros también necesitan verificar la ejecución (a través de fraude o prueba de validez), en lugar de confiar en la mayoría de los supuestos de honestidad.
43/ @eigenlayer (a menos que haya un DAS), el cliente ligero, si es compatible, se basará en una mayoría honesta de nodos de recuperación.
Por lo tanto, la seguridad de #EigenDA se basa principalmente en el conjunto de validadores de Ethereum, que hereda la primitiva de corte de Ethereum y garantiza la seguridad económica de DA
44/ Entonces, más participación de las partes interesadas en #EigenDA significa mayor seguridad. La reducción de los requisitos de los nodos también contribuye a una mejor descentralización
45/ La codificación de borrado es un mecanismo importante que permite el muestreo de disponibilidad de datos. La codificación de borrado expande los bloques haciendo copias adicionales de los datos. Los datos adicionales crean redundancia, proporcionando mayores garantías de seguridad para el proceso de muestreo
46/ Sin embargo, los nodos pueden intentar codificar datos incorrectamente para interrumpir la red. Para defenderse de este ataque, los nodos necesitan una forma de verificar que la codificación sea correcta; aquí es donde entran las pruebas.
47/ Ethereum, @eigenlayer y @AvailProject utilizan un esquema de prueba de validez para garantizar que los bloques estén codificados correctamente. La idea es similar a las pruebas de validez utilizadas por zk rollup. @eigenlayer ha discutido esto anteriormente en este hilo
48/ Cada vez que se genera un bloque, el verificador debe comprometerse con los datos verificados por el nodo utilizando la prueba KZG para demostrar que el bloque está codificado correctamente
49/ Aunque la generación de compromisos para las pruebas KZG requiere más gastos generales de cómputo para los productores de bloques, cuando los bloques son pequeños, la generación de compromisos no genera muchos gastos generales. Sin embargo, esto cambió...
50/... a medida que los bloques se hacen más grandes, la carga del compromiso de la prueba KZG es mucho mayor
Por lo tanto, el tipo de nodo responsable de generar estos compromisos puede tener mayores requisitos de hardware.
51/ Por otro lado, @CelestiaOrg implementa pruebas de fraude para la codificación de borrado. Por lo tanto, los nodos de #Celestia no necesitan verificar que los bloques estén codificados correctamente. por defecto lo tienen correcto
52/ El beneficio es que los productores de bloques no necesitan hacer el costoso trabajo de generar compromisos codificados de borrado
Pero hay una compensación, porque los nodos ligeros tienen que esperar un poco de tiempo antes de asumir que un bloque está codificado correctamente y completarlo en su opinión.
53/ La principal diferencia entre los esquemas de codificación a prueba de fraude y a prueba de validez es la compensación entre la sobrecarga del nodo para generar compromisos y la latencia para los nodos ligeros.
54/ Esta tabla resume muy bien la comparación
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
¿Cómo funcionan las soluciones de disponibilidad de datos y en qué se diferencian?
**Escrito por: **zer0kn0wledge.era
Compilado por: Kate, Marsbit
Nota: este artículo es de @expctchaos Twitter, que es un investigador de @ChaosDAO. El contenido del tweet original está organizado por MarsBit de la siguiente manera:
0/ La disponibilidad de datos (DA) es el principal cuello de botella del escalamiento
Afortunadamente, @CelestiaOrg, @AvailProject y @eigenlayer cambiarán el juego de DA y habilitarán nuevos niveles de escalabilidad.
Pero, ¿cómo funciona y en qué se diferencia #EigenDA de DA 15 como #Celestia y #Avail?
1/ Si no está familiarizado con los problemas de disponibilidad de datos, consulte mi publicación a continuación, donde describo la situación de disponibilidad de datos en detalle 👇
2/ En general, hay dos tipos principales de soluciones de procesamiento de datos
3/ Y "verificación de validez pura" significa que el procesamiento de datos puede estar fuera de la cadena sin garantías, porque los proveedores de servicios de datos fuera de la cadena pueden desconectarse en cualquier momento...
4/ …#StarkEx, #zkPorter y #Arbitrum Nova son ejemplos de escenarios de verificación que dependen de DAC, un grupo de terceros conocidos para garantizar la disponibilidad de datos
5/ Por otro lado, #EigenDA, @CelestiaOrg y @AvailProject son lo que podríamos llamar una solución DA universal
Sin embargo, existen algunas diferencias entre EigenDA y las otras dos soluciones.
6/ Si quieres saber cómo funciona @CelestiaOrg, consulta el siguiente enlace
7/ También he cubierto @AvailProject en el pasado, así que para obtener más información, échale un vistazo aquí.
8/ Si necesita un repaso en @eigenlayer, consulte el hilo a continuación 👇
9/ Así que en la publicación de hoy queremos centrarnos en la comparación entre las cadenas #EigenDA y DA L1 de @eigenlayer como @CelestiaOrg o @AvailProject
10/ Supongamos un resumen basado en Ethereum y usando Celestia para DA (también conocido como Celestium)
Entonces, los contratos L2 en Ethereum verifican la prueba de validez o la prueba de fraude como de costumbre, y Celestia proporciona DA
11/ En @CelestiaOrg y @AvailProject, no hay contratos inteligentes ni cálculos, solo se garantiza que los datos estén disponibles
12/ Pero echemos un vistazo más de cerca
En @CelestiaOrg, los datos de tx se publican en Celestia mediante el clasificador L2, el verificador de Celestia firma la raíz de Merkle de la prueba de DA y luego se envía al contrato de puente de DA en Ethereum para su verificación y almacenamiento.
13/ En comparación con el almacenamiento de DA en la cadena, esto reduce en gran medida el costo de tener una garantía sólida de DA, al mismo tiempo que brinda garantías de seguridad de Celestia (en lugar de un DAC centralizado)
14/ La reducción de costos cambiará las reglas del juego en todo el campo de resumen, porque el costo de los datos de llamadas generados al publicar datos en Ethereum L1 representa el 80-90 % del costo de resumen
Para obtener más información sobre el costo de los datos de llamadas, consulte la publicación a continuación 👇
15/ ¿Pero qué diablos pasó en #Celestia?
Los blobs de datos publicados en @CelestiaOrg (esencialmente como datos sin procesar) se propagan a través de la red P2P y se llega a un consenso sobre el blob de datos mediante el consenso de Tendermint.
16/ Cada nodo completo de #Celestia debe descargar el blob de datos completo. Esto es diferente para los nodos ligeros que pueden usar el muestreo de disponibilidad de datos (DAS) para garantizar la disponibilidad de los datos.
17/ Para obtener más información sobre DAS y nodos de luz, consulte la publicación a continuación
18/ También volveremos a DAS más adelante en este hilo, pero por ahora el enfoque está en los nodos completos.
Volvamos a @CelestiaOrg, que continúa comportándose de manera L1, basándose en la transmisión y el consenso sobre las manchas de datos.
19/ Por lo tanto, exige mucho a los nodos completos de la red (128 MB/s de descarga y 12,5 MB/s de carga).
Aún así, @CelestiaOrg apuntaba a un rendimiento moderado (1,4 MB/s) al principio, lo que parece bajo dados los requisitos de nodo completo
20/ Sin embargo, la red puede escalar el rendimiento agregando nodos ligeros. Cuantos más nodos ligeros de muestreo de datos, mayor puede ser el tamaño del bloque bajo la condición de garantizar la seguridad y la descentralización
21/ Por otro lado, @eigenlayer tiene una arquitectura diferente, sin consenso propio y sin red peer-to-peer
Entonces, ¿cómo funciona esto?
Primero, el nodo EigenDA debe reasignar $ETH en el contrato @eigenlayer. Por lo tanto, los nodos #EigenDA son un subconjunto de validadores de Ethereum
22/ Después de recibir el blob de datos, un comprador de DA (como un resumen, también conocido como dispersor) lo codifica con un código de borrado y genera un compromiso KZG...
23/... donde el tamaño de la prueba depende de la tasa de redundancia del código de borrado y publica el compromiso de KZG con el contrato inteligente #EigenDA
24/ Compromiso KZG codificado distribuido por dispersor a nodos #EigenDA
Después de recibir el compromiso KZG, estos nodos lo comparan con el compromiso KZG del contrato inteligente EigenDA y firman la prueba después de la confirmación.
25/ Después de eso, el dispersor recopila estas firmas una por una, genera una firma agregada y la publica en el contrato inteligente #EigenDA, y el contrato inteligente verifica la firma
26/ Pero si el nodo #EigenDA simplemente firma una prueba que afirma que almacenó el blob de datos codificados en este flujo de trabajo, y el contrato inteligente de EigenDA solo verifica la exactitud de la firma agregada, ¿cómo podemos estar seguros de que el nodo EigenDA realmente almacenó datos?
27/ #EigenDA utiliza un método de prueba de depósito en garantía para lograr esto
Pero demos un paso atrás y miremos esta escena donde se vuelve importante
28/ Supongamos que algunos validadores perezosos no están haciendo las tareas que se les han asignado (por ejemplo, asegurarse de que los datos estén disponibles)
En cambio, fingen que han hecho el trabajo y aprueban el resultado final (informando falsamente la disponibilidad de datos cuando no están disponibles).
29/ Conceptualmente, la prueba de custodia es como prueba de fraude:
Cualquiera puede enviar una prueba (validador perezoso) al contrato inteligente #EigenDA que será verificado por el contrato inteligente
29/ El validador perezoso se corta si la validación es exitosa (porque es un error objetivamente atribuible)
30/ ¿Qué pasa con el consenso?
@CelestiaOrg usa Tendermint como su protocolo de consenso, que tiene una finalidad de ranura única. Es decir, una vez que un bloque pasa el consenso de #Celestia, está listo. Esto significa que la finalidad es básicamente tan rápida como el tiempo de bloque (15 segundos).
31/ @AvailProject usa la composición del protocolo para lograr la finalidad. BABE es un mecanismo de producción de bloques con finalidad probabilística, y GRANDPA es un dispositivo final. Si bien GRANDPA puede completar bloques en una ranura, también puede completar varios bloques en una ronda.
32/ Dado que @eigenlayer es un conjunto de contratos inteligentes en Ethereum, también hereda el mismo tiempo de finalización que Ethereum (12 - 15 minutos) para los datos que deben reenviarse al contrato acumulativo para probar la disponibilidad de los datos.
33/ Sin embargo, si el resumen usa @eigenlayer, podría hacerse más rápido, dependiendo del mecanismo de consenso utilizado, etc.
Además, el middleware asegurado por los validadores de reasignación de @eigenlayer centrados en proporcionar liquidaciones rápidas, como EigenSettle, puede proporcionar sólidas garantías de seguridad económica que permiten la confirmación previa de la finalidad. Sin embargo, las garantías de firmeza de la finalidad aún provienen de Ethereum L1
34/ Hora de revisar los conceptos de muestreo de disponibilidad de datos
En la mayoría de las cadenas de bloques, los nodos necesitan descargar todos los datos de transacciones para verificar la disponibilidad de los datos. El problema que esto crea es que cuando aumenta el tamaño del bloque, también aumenta la cantidad de nodos de datos que deben verificarse.
35/ El muestreo de disponibilidad de datos (DAS) es una técnica que permite a los nodos ligeros verificar la disponibilidad de los datos descargando solo una pequeña porción de los datos del bloque.
36/ Esto proporciona seguridad a los nodos ligeros para que puedan validar bloques no válidos (solo DA y consenso) y permite que la cadena de bloques escale la disponibilidad de datos sin aumentar los requisitos de los nodos.
37/ DAS requiere al menos un nodo completo honesto y una cantidad suficiente de clientes ligeros
38/ Pero, ¿cómo garantizar la seguridad de los nodos de luz?
Los clientes ligeros tradicionales tienen suposiciones de seguridad más débiles en comparación con los nodos completos, ya que solo validan encabezados de bloque
Por lo tanto, los clientes ligeros no pueden detectar si una mayoría deshonesta de productores de bloques produjo un bloque no válido.
39/ Los nodos ligeros con muestreo de disponibilidad de datos se actualizan en seguridad, porque si la capa DA solo hace consenso y disponibilidad de datos, pueden verificar si se producen bloques no válidos
40/ Tanto @CelestiaOrg como @AvailProject tendrán muestreo de disponibilidad de datos, por lo que sus nodos ligeros tendrán seguridad de confianza minimizada.
41/ Esto es diferente de Ethereum y @eigenlayer
Ethereum con #EIP4844 no tiene muestreo de disponibilidad de datos, por lo que sus clientes ligeros no tendrán seguridad de confianza minimizada
42/ Dado que Ethereum también tiene su entorno de contrato inteligente, los clientes ligeros también necesitan verificar la ejecución (a través de fraude o prueba de validez), en lugar de confiar en la mayoría de los supuestos de honestidad.
43/ @eigenlayer (a menos que haya un DAS), el cliente ligero, si es compatible, se basará en una mayoría honesta de nodos de recuperación.
Por lo tanto, la seguridad de #EigenDA se basa principalmente en el conjunto de validadores de Ethereum, que hereda la primitiva de corte de Ethereum y garantiza la seguridad económica de DA
44/ Entonces, más participación de las partes interesadas en #EigenDA significa mayor seguridad. La reducción de los requisitos de los nodos también contribuye a una mejor descentralización
45/ La codificación de borrado es un mecanismo importante que permite el muestreo de disponibilidad de datos. La codificación de borrado expande los bloques haciendo copias adicionales de los datos. Los datos adicionales crean redundancia, proporcionando mayores garantías de seguridad para el proceso de muestreo
46/ Sin embargo, los nodos pueden intentar codificar datos incorrectamente para interrumpir la red. Para defenderse de este ataque, los nodos necesitan una forma de verificar que la codificación sea correcta; aquí es donde entran las pruebas.
47/ Ethereum, @eigenlayer y @AvailProject utilizan un esquema de prueba de validez para garantizar que los bloques estén codificados correctamente. La idea es similar a las pruebas de validez utilizadas por zk rollup. @eigenlayer ha discutido esto anteriormente en este hilo
48/ Cada vez que se genera un bloque, el verificador debe comprometerse con los datos verificados por el nodo utilizando la prueba KZG para demostrar que el bloque está codificado correctamente
49/ Aunque la generación de compromisos para las pruebas KZG requiere más gastos generales de cómputo para los productores de bloques, cuando los bloques son pequeños, la generación de compromisos no genera muchos gastos generales. Sin embargo, esto cambió...
50/... a medida que los bloques se hacen más grandes, la carga del compromiso de la prueba KZG es mucho mayor
Por lo tanto, el tipo de nodo responsable de generar estos compromisos puede tener mayores requisitos de hardware.
51/ Por otro lado, @CelestiaOrg implementa pruebas de fraude para la codificación de borrado. Por lo tanto, los nodos de #Celestia no necesitan verificar que los bloques estén codificados correctamente. por defecto lo tienen correcto
52/ El beneficio es que los productores de bloques no necesitan hacer el costoso trabajo de generar compromisos codificados de borrado
Pero hay una compensación, porque los nodos ligeros tienen que esperar un poco de tiempo antes de asumir que un bloque está codificado correctamente y completarlo en su opinión.
53/ La principal diferencia entre los esquemas de codificación a prueba de fraude y a prueba de validez es la compensación entre la sobrecarga del nodo para generar compromisos y la latencia para los nodos ligeros.
54/ Esta tabla resume muy bien la comparación