En este artículo, tratamos de examinar en detalle los cambios en el protocolo de Bitcoin que ocurrieron como resultado de la actualización de Softfork de Segregated Witness. Tocamos temas relacionados con la maleabilidad de las transacciones, manteniendo la compatibilidad con versiones anteriores, aumentando el rendimiento, nuevos formatos de serialización de transacciones, nuevas opciones de secuencias de comandos, formato de dirección Bech32 y sus ventajas, conceptos de peso, tamaño y tamaño virtual. Además, a continuación se presentan las estadísticas más importantes sobre la adaptación de la actualización y las respuestas a las preguntas frecuentes sobre el tema de esta actualización.
Antes de continuar con una descripción detallada de todos los cambios en esta actualización, le sugerimos que se familiarice con la idea principal de Testigo segregado. Literalmente, Testigo segregado se traduce del inglés como "testigo separado". El concurso de Bitcoin implica que la evidencia de propiedad de las monedas se almacenará por separado de los datos maestros de la transacción, como se indica en el diagrama.
Si consideramos la actualización completa del protocolo, entonces incluye muchas otras mejoras. SegWit le permite aumentar el ancho de banda de la red, separar la evidencia de la propiedad de las monedas del resto de los datos de la transacción, corregir los defectos en el formato de transacción asociado con la capacidad de modificar los datos en las transacciones firmadas (maleabilidad de la transacción), al tiempo que mantiene la compatibilidad con versiones anteriores del protocolo. Y el mayor valor de esta actualización es que le permite implementar muchas soluciones fuera de la cadena muy importantes además del protocolo Bitcoin.
Problema y solución de maleabilidad de transacciones
La conclusión es que cuando se trabaja en Bitcoin, existe la oportunidad de cambiar la transacción para que permanezca correcta durante la verificación. Estos cambios son muy menores, no afectan las direcciones del remitente y el destinatario, pero son suficientes para cambiar el resultado del hash. En otras palabras, la transacción transferirá las monedas a sus direcciones anteriores, pero su valor hash modificado ya no coincidirá con la transacción modificada con la original.
Obviamente, la situación descrita anteriormente solo puede ocurrir con transacciones que aún no han recibido confirmación. Sin su solución, es imposible lograr un funcionamiento confiable de los protocolos fuera de la cadena, que incluyen la construcción de cadenas de transacciones no confirmadas. Dado que al compilar una transacción, no todos los datos están firmados (por ejemplo, no puede firmar scriptSig), existe la posibilidad de varios tipos de ataques:
- Cambiar el formato de la firma . En el protocolo de Bitcoin, el formato de firma no está estrictamente aprobado y depende de la implementación de la biblioteca OpenSSL, en la cual el formato estricto tampoco está definido para la firma. Un tercero puede modificar la transacción interceptada, lo que implicará un cambio en el valor hash.
- Impacto directamente en scriptSig . Como se señaló anteriormente, scriptSig contiene un conjunto de operaciones para verificar la evidencia de que un usuario en particular es el propietario de las monedas. Pero además de estas operaciones, puede agregarle otras. Algunas operaciones inofensivas que no afectan nada conducirán a un cambio en el valor hash de la transacción.
Por lo tanto, puede cambiar el valor hash de una transacción sin tener acceso a claves privadas. ¿Por qué es tan indeseable cambiar un valor hash?
En primer lugar, debe tenerse en cuenta que es posible crear una copia de la transacción original, agregar cambios que no afecten su corrección durante la verificación y enviarla a la red. Una copia modificada con un valor hash diferente gasta las mismas monedas que el original, por lo que puede competir con la transacción original para su confirmación.
Los protocolos fuera de la cadena se han mencionado anteriormente. Para su implementación, es necesaria una solución al problema de la maleabilidad de las transacciones. En el corazón de su trabajo está la construcción de cadenas de transacciones no confirmadas. Cambiar el valor hash de la primera transacción implicará la invalidez de toda la cadena de las no confirmadas.
La actualización SegWit definió reglas estrictas para completar los campos, por lo que los problemas asociados con la maleabilidad de las transacciones para las transacciones del nuevo formato pueden considerarse resueltos. Esto nos permitió especificar datos y serializarlos sin ambigüedades, eliminando la dualidad.
Compatibilidad con versiones anteriores al distribuir un bloque a través de una red
De acuerdo con las reglas anteriores, el tamaño máximo de bloque es de 1 MB y contiene transacciones con evidencia incorporada. Si bien las nuevas reglas suponen que el tamaño máximo del bloque base es de 1 MB, pero adicionalmente hay una estructura de datos con evidencia. En consecuencia, el tamaño total del nuevo bloque supera 1 MB.
Para la compatibilidad con versiones anteriores, las reglas de protocolo permiten que los nodos antiguos trabajen con bloques nuevos, pero recibirán el bloque solo en la configuración básica con un tamaño máximo de 1 MB. La estructura de testigos no está disponible para ellos. Los nuevos nodos obtienen un bloque completo con transacciones y evidencia. La siguiente figura lo ayudará a familiarizarse con esta pregunta.
A la izquierda hay un diagrama del funcionamiento del protocolo Bitcoin antes de la activación de Testigo segregado. El bloque tenía un tamaño máximo de 1 MB, y se distribuyó entre diferentes nodos de red en una forma.
Dado que el tamaño del bloque es limitado, el número de transacciones que se pueden colocar también es limitado, y la capacidad del sistema depende de esto. Por supuesto, cuando surgió la cuestión de aumentar el rendimiento, lo primero que comenzaron a buscar fue la forma de aumentar el tamaño máximo de bloque.
Formas de aumentar el rendimiento
Considere las dos formas principales de resolver el problema de aumentar el rendimiento del sistema. Cualquier oferta es cuidadosamente revisada y probada por el equipo de desarrollo del protocolo Bitcoin. Si la comunidad llegó a un acuerdo y decidió implementar la propuesta en el protocolo, se emite una actualización.
Actualización de Hardfork. El lugar más común de actualizaciones es aumentar el tamaño del bloque. Se supone que una unidad acomodará más transacciones, aumentando el rendimiento. Sin embargo, dicha unidad no será aceptada por los nodos que operan de acuerdo con el protocolo anterior, cuyas reglas establecen que el tamaño máximo de bloque no puede exceder 1 MV. Tal cambio requiere hardfork, que es organizacionalmente más complejo que softfork.
Actualización de SoftFork. Testigo segregado nos permite resolver este problema con softfork. Como exactamente Nos permite dividir el bloque en dos partes, la primera de las cuales almacena transacciones, y la segunda contiene evidencia. Al mismo tiempo, los nuevos nodos de red reciben ambas partes, mientras que los antiguos reciben solo un bloque de transacción de 1 MB. Los nodos antiguos no pueden recibir bloques con evidencia y, en consecuencia, no pueden validar las transacciones que reciben, pero esto les permite participar en la creación de consenso y no recurrir a hardfork, sino cambiar gradualmente a un nuevo software.
Testigo segregado de innovaciones
Considere lo que se incluye en la actualización de Testigos segregados. La primera y más importante innovación de Segregated Witness es el nuevo formato de serialización de transacciones. Además de los campos ya conocidos, hay tres campos nuevos en la nueva transacción: marcador, bandera, que se utilizan para el control de versiones y en este caso están estrictamente establecidos, pero en los siguientes protocolos pueden cambiar, así como el campo testigo. Testigo (datos de testigos) es en realidad un conjunto de evidencia de propiedad de monedas que se saca de la parte principal de la transacción. Estructuralmente, se ve como un conjunto de entradas, con cada elemento de datos testigo correspondiente a una entrada con un número específico, lo que le permite comparar la evidencia con monedas específicas gastadas.
Identificación de la transacción del testigo
Para obtener el identificador de transacción (id de transacción, txid), debe llevar la transacción a una secuencia de datos en un formato de serialización especial y luego obtener el valor hash de esta secuencia de datos. Con la introducción de Testigo segregado, han aparecido un nuevo identificador, un identificador de transacción de testigo (wtxid) y un nuevo formato de serialización, respectivamente. Para transacciones antiguas que gastan dinero sin usar Testigo segregado, wtxid será lo mismo que txid porque no tendrán nuevos campos agregados a Testigo segregado.
Se necesita Wtxid para construir un árbol de Merkle alternativo como evidencia. Está construido de la misma manera que para las transacciones ordinarias, solo se usa wtxid en lugar del hash de la transacción. En consecuencia, los wtxid se combinan en pares y dan como resultado la raíz de Merkle.
Es importante tener en cuenta que la raíz de Merkle se inserta en una transacción de coinbase, y no en el encabezado del bloque. Si la raíz estuviera en el encabezado del bloque, la estructura del bloque cambiaría. Los nodos que admiten el antiguo protocolo no podrían funcionar con dichos bloques. Y todos los esfuerzos para mantener la compatibilidad con versiones anteriores descansarían en contra de esta inconsistencia. Por lo tanto, la raíz se inserta en una de las salidas de la transacción de coinbase. Cuando todos los nodos cambian a Testigo segregado, esta situación puede cambiar y se considerarán nuevos enfoques.
Programas de testigos para establecer condiciones para gastar monedas
Veamos cómo se construye el script de transacciones de Segregated Witness y cómo permite que los nodos de red más antiguos comprendan que las transacciones de Segregated Witness son correctas, a pesar de que no reciben evidencia de propiedad de monedas.
El script que describe las reglas para gastar monedas de una transacción de nuevo formato consta de dos partes. La primera parte es el byte de la versión testigo (el byte que especifica la versión del programa testigo). Puede tomar valores de 0 a 16 (OP0-OP16), ahora usa OP0. En el futuro, pueden aparecer nuevas versiones del protocolo con soporte para otras versiones del programa de testigos. La segunda parte es el programa de testigos. Esta parte puede tener un tamaño de 2 a 40 bytes.
El programa Testigo es el resultado de trocear un guión testigo. El guión testigo en sí contiene una descripción completa de las condiciones para gastar monedas. Los datos de testigos contienen pruebas de propiedad de monedas que deben cumplir las condiciones del guión de testigos. En consecuencia, los datos de testigos siempre constan de dos partes: un guión de testigos y una prueba de propiedad de las monedas.
Vale la pena señalar que el programa testigo no contiene ninguna operación (coincidencia de valores hash, verificación de firmas electrónicas), y el script en sí comienza con el código OP0, por lo tanto, es válido para todos los nodos antiguos. Además, los nodos que no se han actualizado a SegWit no comprueban la evidencia de propiedad de monedas para nuevos formatos de salida; en cualquier caso, consideran que ese desperdicio es correcto. Estrictamente hablando, los nodos antiguos aceptarán transacciones de un nuevo formato incluso si su remitente no posee las monedas correspondientes. Es por eso que SegWit requiere que los propietarios de la mayor parte de la potencia minera de Bitcoin acepten esta actualización. Otra característica es que el scriptSig de una transacción que gasta monedas de la salida del nuevo formato estará vacío.
Nuevas opciones para establecer las condiciones para gastar monedas
Con la introducción de SegWit, se propusieron dos formatos estándar para scriptPubKey, que se convirtió en una alternativa a los dos formatos más comunes para establecer reglas de gasto de monedas antes de que apareciera esta actualización. Consideremos en orden.
Pagar para presenciar hash de clave pública (P2WPKH) es un análogo del pago estándar para hash de clave pública. Cual es su diferencia? Como se señaló anteriormente, el scriptSig no se llena y permanece vacío. Toda evidencia de propiedad de monedas se transfiere a la estructura de datos de testigos.
En este caso, el script que se consideró anteriormente, la versión y el hash de la clave pública, que es el programa testigo, se inserta en scriptPubKey. Un nodo en la red distingue tal script de gasto de otros debido al hecho de que tiene una versión de uno y un tamaño de datos de 20 bytes. Otra versión y un tamaño diferente llevan diferentes reglas de gasto.
En este caso, scriptPubKey contiene dos partes: el número de versión testigo es cero y el valor hash de la clave pública del destinatario. ScriptSig estará vacío y los datos del testigo contendrán una firma electrónica y una clave pública para verificarlo.
El hash de script de pago a testigo (P2WSH) es un análogo del hash estándar de pago a script. En este caso, se puede usar un script personalizado para establecer las reglas para gastar monedas. ¿Cómo distingue un host tal script del anterior? En este caso, la versión todavía tiene un valor de uno, y el programa testigo toma 32 bytes y es un valor hash del script testigo. Si una transacción llega a un host que contiene un script que tendrá la primera versión, pero su tamaño diferirá de los valores de 20 o 32 bytes, entonces el host rechazará esta transacción porque no sabrá cómo trabajar con ella.
Los datos de los testigos aquí se dividen en dos partes. El primero contiene un conjunto de pruebas de propiedad de monedas, es decir, un conjunto de firmas. En la segunda parte, se coloca un guión testigo, cuyo contenido solo establece las reglas para gastar monedas, pero en este caso se indica al momento de gastar, y al momento de enviar las monedas se indicó su valor hash.
En este caso, scriptPubKey contiene dos partes: el número testigo de la versión es cero y el valor hash del script testigo para el caso de la firma múltiple 1 de 2. ScriptSig estará vacío, y los datos del testigo contendrán la firma electrónica y el guión del testigo original en texto claro.
Envoltura P2SH
El nuevo formato de script es diferente del anterior. En consecuencia, los servicios y billeteras antiguas no sabrán cómo trabajar con este formato de script y cómo componerlo. Para la compatibilidad con versiones anteriores, las transacciones de Testigos segregados que utilizan P2SH utilizan un "envoltorio" especial, que le permite crear una transacción que tiene las propiedades de una transacción de Testigos segregados, pero no difiere de la P2SH habitual para el mundo exterior.
P2SH se utiliza para simplificar el trabajo del remitente y no cargarlo con los detalles de la implementación del Redeem Script del receptor. En este caso, el destinatario le da al remitente solo el valor de hash de Canjear script, y el script mismo pasa a scriptSig junto con la evidencia.
En este caso, scriptPubKey contiene una operación hash, un canje de valor de hash de scrip y una operación de comparación (como en la versión anterior de P2SH). ScriptSig aquí contendrá el valor hash de la clave pública, y los datos del testigo contendrán la firma electrónica y la clave pública.
Este enfoque permite que las billeteras digitales no actualizadas envíen transacciones a direcciones de Testigos Segregados, sin saber nada sobre las nuevas formas de establecer las condiciones para gastar monedas.
Nuevo formato de dirección Bech32
Vale la pena mencionar por separado las direcciones Bech32 que se consideran direcciones SegWit nativas. Durante la mayor parte de su historia, Bitcoin ha utilizado la codificación Base58 para direcciones con la adición de una suma de verificación, que es un resultado truncado de doble hashing utilizando la función hash SHA-256. Formaban parte del software original y su alcance se amplió en BIP13 para P2SH. Pero tanto el conjunto de caracteres como el algoritmo de suma de verificación tienen limitaciones:
- la dirección en Base58 ocupa más memoria en los códigos QR, porque no puede usar el modo de representación alfanumérica;
- base58 es muy inconveniente para escribir en papel de manera confiable, escribir desde un teclado móvil o leer en voz alta;
- el hash de doble suma de comprobación es lento;
- La decodificación base58 es compleja y relativamente lenta.
La actualización de SegWit incluye una nueva clase de salidas (programas de testigos) y dos de sus casos: P2WPKH y P2WSH. Su funcionalidad está disponible indirectamente para los nodos antiguos mediante el uso de P2SH, pero será más óptimo y más seguro usarlo directamente, para esto es necesario introducir un nuevo formato de dirección.
Especificación de dirección Bech32
La dirección Bech32 tiene una longitud de no más de 90 caracteres y contiene:
- Una parte que es legible para los humanos. Esto incluye datos que pueden necesitar ser transmitidos o que tienen algo que ver con el propietario de la dirección, de al menos 1 carácter de largo. Por ejemplo, por defecto para las direcciones de la red principal los caracteres son "bc", y para testnet los caracteres son "tb".
- Un delimitador que siempre es 1. Si se permite "1" dentro de la parte legible por humanos, entonces el separador es el último de los caracteres "1".
- La parte de datos tiene una longitud de al menos 6 caracteres y consta solo de caracteres alfanuméricos, excluyendo "1", "b", "i" y "o". Aquí, la versión del programa testigo y los datos del propio programa testigo (de 2 a 40 bytes) se usan aquí como datos principales.
¿Por qué incluir un separador en las direcciones? Esto le permite separar claramente la parte legible por humanos de la parte legible por datos, evitando posibles colisiones con otras partes legibles por humanos que usan el prefijo. También evita restricciones de juego de caracteres para la parte legible por humanos. El separador es 1 porque el uso de un carácter no alfanumérico dificulta la copia de direcciones (sin hacer doble clic en varias aplicaciones). Por lo tanto, se seleccionó un carácter alfanumérico fuera del conjunto de caracteres principal. Además, el uso del sistema de números base 32 va acompañado de un aumento en la longitud de la dirección en un 15% en comparación con el sistema de números base 58, pero esto no importa al copiar direcciones.
Suma de comprobación Bech32 direcciones
Los últimos 6 caracteres de la dirección son una suma de verificación. La suma de verificación se basa en el código BCH, que garantiza la detección de cualquier error que no afecte más de 4 caracteres, y la posibilidad de que la suma de verificación converja cuando se cometen más de 4 errores es uno de 109.
Una de las ventajas de usar códigos BCH es que pueden usarse para corregir errores. Si se cometieron hasta 4 errores en la dirección, se corregirán automáticamente. Y si se cometen más errores, se detectarán con una alta probabilidad, pero sin la posibilidad de su corrección automática.
Mayúsculas y minúsculas en la dirección
Se utiliza minúscula cuando se requiere un valor de carácter para una suma de verificación.
El software siempre muestra la cadena completa de direcciones Bech32 en minúsculas. (, QR-), . , , , . , QR- , - , 45% , .
, Segregated Witness, , . Segregated Witness . 1 MB. . , .
(weight units). 3, witness data 1. , , witness data 3 , . . .
block weight = base size * 3 + total sizeblock weight – ( )
base size – ( )
total size – ( )
, , . .
, , , , 4 . Segregated Witness , .
, . (virtual size) , , , spb (satoshi per byte).
virtual size = weight units / 4Segregated Witness 4 , , . , . , . , , . , witness data (base size) 1 MB, 4 MB.
: « witness data?». . , 1 MB 4 MB. . 1.8 MB. ? 60% . 1 MB, 40% , .
400000 * 4 = 1600000600000 * 1 = 6000001600000 + 600000 = 22000004000000 / 2200000 = 1.81 MB, , 1.8 MB. , .
2018 SegWit 35% . Segregated Witness (, Electrum Bitxfy).
BitMex Research. 1 MB, 2 MB. , , SegWit .
BitMex Research, .
, Segregated Witness off-chain Bitcoin. , lightning network – SegWit, , .
Preguntas frecuentes
— , Segregated Witness RBF (replace-by-fee)?, replace by fee Segregated Witness , , , , sequence number . , , , , .
— ?- , . ScriptSig, , , . , , - . , , , - .
— witness data?, Segregated Witness . , , , . , . : , , ( ), , Witness data, . .
— , RFC3548 z-base-32 Bech32 ?El conjunto de caracteres se elige para minimizar la ambigüedad asociada con su similitud visual. El orden se selecciona para minimizar el número de pares de caracteres que difieren en menos de un bit de datos. La suma de verificación se elige para maximizar la probabilidad de detectar un pequeño número de errores, lo que mejora su eficiencia para los errores típicos.