¿Cuáles son las ventajas y desventajas de los testigos segregados?

Los testigos segregados suenan como una victoria en muchos sentidos, solo estoy tratando de entender cómo se aplican a la escalabilidad. Si entiendo correctamente, hay un segundo árbol Merkle de testigos que refleja los datos de la transacción. La raíz del árbol testigo está comprometida en la base de monedas, pero por lo demás, este segundo árbol vive fuera del bloque.

¿Los testigos todavía no tienen que ser retransmitidos a otros nodos para validarlos? ¿Por qué ahora es aceptable enviar más datos, pero aumentar el tamaño del bloque era peligroso y excluyente de los nodos en conexiones lentas antes?

Además, si los testigos están fuera del bloque y se pueden eliminar, ¿cómo se actualizará un nuevo nodo de validación completa? Si un subconjunto más pequeño de nodos completos alberga todos los testigos, ¿eso compensa la seguridad por la cantidad de transacciones en un bloque?

El título hace que parezca un duplicado de bitcoin.stackexchange.com/questions/41764/… , pero creo que las preguntas subyacentes son más profundas.
Editado, avísame si se te ocurre algo mejor.

Respuestas (1)

Si entiendo correctamente, hay un segundo árbol Merkle de testigos que refleja los datos de la transacción. La raíz del árbol testigo está comprometida en la base de monedas, pero por lo demás, este segundo árbol vive fuera del bloque.

Ese es mi entendimiento también.

¿Los testigos todavía no tienen que ser retransmitidos a otros nodos para validarlos?

Solo nodos que realmente se preocupan por las firmas. Hay miles de nodos SPV, por ejemplo, que desean poder calcular el TXID de las transacciones que les interesan, pero que en realidad no necesitan los scriptSigs aparte de eso, ya que los nodos SPV dependen de las confirmaciones por seguridad en lugar de verificar completamente guiones.

¿Por qué ahora es aceptable enviar más datos, pero aumentar el tamaño del bloque era peligroso y excluyente de los nodos en conexiones lentas antes?

Muchas personas rechazaron la idea de aumentar el límite de tamaño de bloque simplemente porque era una bifurcación dura. Los datos adicionales y la exclusión de algunos nodos siguen siendo un problema, y ​​estoy seguro de que todavía habrá muchos argumentos sobre cómo contar los datos testigo. Esto simplemente elimina/pospone el debate sobre el tamaño máximo de bloque de la bifurcación dura .

La propuesta actual de Pieter Wuille es otorgar un 75 % de descuento en los datos de la firma, aumentando el tamaño máximo efectivo del bloque a aproximadamente 4 MB en el peor de los casos, pero eso probablemente nunca se acercaría a realizarse en ninguna circunstancia normal, no maliciosa. Estimaría que un bloque normal completo de 1M sería un bloque de 1,8 MB de transacciones completamente SW.

Además, si los testigos están fuera del bloque y se pueden eliminar, ¿cómo se actualizará un nuevo nodo de validación completa? Si un subconjunto más pequeño de nodos completos alberga todos los testigos, ¿eso compensa la seguridad por la cantidad de transacciones en un bloque?

Cuando un nodo completo se conecta ahora, actualmente ni siquiera verifica las evaluaciones del script en nada más antiguo que el punto de control más reciente. En este sentido, no es un nodo de "validación total", es más un nodo de "validación total desde hace 6 meses en adelante". Pero, desafortunadamente, para construir el conjunto UTXO en este momento, aún necesita descargar scriptSigs, aunque no se usen para ninguna validación. El cambio de testigo segregado hace que, en el caso de las transacciones SW, los scriptSig demasiado antiguos que no se verificarían de todos modos no tengan que descargarse también, porque los TXID no los usan.

Tenga en cuenta que, lamentablemente, algunas transacciones que utilizan testigos segregados no hacen que las transacciones de estilo antiguo sean más fáciles de eliminar por arte de magia. Sin embargo, si el testigo segregado estuviera completamente en uso por todas las transacciones hoy, entonces dentro de 5 años, un nodo que se estaba sincronizando no tendría que descargar muchos de los datos de firma de los últimos 5 años, solo la mayoría datos de firma recientes.

Entonces, hay una compensación de seguridad allí, pero es exactamente la misma compensación que ya existe. Sin embargo, con SW, solo tiene que descargar menos datos (~60% menos de los nuevos datos de transacciones SW) para obtener la misma seguridad.

Para mejorar esa compensación de seguridad, otra opción será posible gracias a SW: puede descargar, por ejemplo, un 1% aleatorio de las firmas más antiguas. Si cada nodo verificó dos veces un conjunto aleatorio diferente de firmas, juntos cubrirán rápidamente estadísticamente el 100%. Y gracias a Fraud Proofs, que también será posible con SW, los nodos pueden informarse entre sí sobre los problemas. Otro esfuerzo de seguridad adicional que puede optar por hacer es, cuando recibe un pago, rastrear y verificar todas las transacciones principales de las que provino la moneda descargando solo esas firmas.
No estoy seguro acerca del número de 2,5 MB. Obtengo 2,22 MB, suponiendo que las firmas solían ser el 60 % del bloque y que obtienen un 75 % de descuento mientras están en SW.
@NickODell, creo que 2,2 MB superarían el límite contado de 1 MB. Intenté hacer los cálculos y obtuve un límite superior típico de 1,82 MB. pastebin.com/u4frCUfb ¿Tal vez podría verificar mis cálculos y una vez que estemos de acuerdo con el número, actualizaré mi respuesta?
@ StephenM347, Re "pero es exactamente la misma compensación que ya existe", ¿a qué te refieres?