SegWit
¿Qué fue la actualización Segregated Witness?
-
Greg Walker - Atualizado em (Ajustes de Eric de Castro em )
La actualización Segregated Witness (SegWit) en 2017 cambió la estructura de los datos de transacción en Bitcoin.
La principal razón de esta actualización fue corregir la maleabilidad de transacciones (la explicaré en un momento). El otro cambio significativo fue un aumento del tamaño del bloque.
¿Cuál fue el cambio principal?
Transacción legada
En una transacción legada, el código de desbloqueo (y las firmas) se coloca junto a cada entrada, así que el código de desbloqueo queda repartido por todos los datos de la transacción.
El TXID se crea entonces a partir de todos los datos de la transacción:
Transacción SegWit
En una transacción segwit, en cambio, todo el código de desbloqueo (y las firmas) se mueve al final de los datos de la transacción.
El TXID se crea entonces a partir de todos los datos de la transacción, excepto el código de desbloqueo:
Como resultado, el TXID en una transacción segwit solo está influido por los efectos de la transacción (el movimiento de bitcoins) y no por el código necesario para validar la transacción (es decir, las firmas necesarias para desbloquear los bitcoins y gastarlos).
Así que, en esencia, separaste la parte de "validación" (código de desbloqueo) del resto de la transacción.
Si llamaras a ese código de validación de datos de testigo (witness), como podría hacerlo un criptógrafo, se podría decir que "segregaste" el testigo. *guiño*
¿Cuáles son los beneficios?
1. Corrige la maleabilidad de transacciones
En Bitcoin, la maleabilidad de transacciones se refiere al hecho de que el TXID de una transacción puede alterarse modificando las firmas:
Una firma puede alterarse invirtiendo el valor s. La firma sigue siendo válida y la transacción tiene el mismo efecto, pero el TXID es diferente.
Eso significa que, cuando envías una transacción legada a la red, cualquier nodo tiene la capacidad de cambiar el TXID antes de reenviarla:
En algún momento, tu transacción llegará a la blockchain con un TXID distinto del que esperabas, lo que sería un poco molesto.
Sin embargo, si las firmas ya no forman parte del TXID, ya no es posible que otra persona cambie el TXID de tu transacción después:
Así que, en otras palabras, SegWit hace que los TXIDs sean confiables.
2. Aumento de la capacidad del bloque
Debido a que el código de desbloqueo se movió a un nuevo campo de testigo en los datos de la transacción, también se pudo cambiar la forma en que se calculaban los tamaños de los bloques.
Antes, las transacciones se medían en bytes, y el límite de tamaño del bloque era de 1.000.000 bytes (1 MB):
Con SegWit, las transacciones ya no se miden en bytes. En su lugar, transacciones y bloques recibieron una nueva métrica llamada peso (weight):
- Un bloque tiene un tamaño máximo de
4.000.000unidades de peso.- Un byte normal en una transacción equivale a
4unidades de peso. - Un byte de testigo en una transacción equivale a
1unidad de peso.
- Un byte normal en una transacción equivale a
Así que, básicamente, el límite de tamaño del bloque se multiplica por 4 para dar el nuevo límite de peso del bloque.
Cada byte en una transacción se multiplica entonces también por 4 para dar un peso de transacción. Sin embargo, solo multiplicas por 1 los bytes de datos de testigo, lo que básicamente da un descuento del 75% al espacio que ocupa el "código de desbloqueo" en un bloque.
Así que podrías decir que los datos de desbloqueo ocupan un cuarto del espacio que ocupaban antes, lo que significa que hay más espacio en el bloque en general para datos de transacción.
¿SegWit fue un aumento del tamaño del bloque?
Sí, cada bloque ahora puede tener más de 1.000.000 bytes (1 MB) de tamaño.
Así que, aunque el límite de tamaño del bloque no aumentó por un número específico de bytes, el peso con descuento para los datos de desbloqueo significa que los bloques pueden superar el límite anterior de 1 MB.
¿De cuánto fue el aumento del tamaño del bloque con SegWit?
La actualización SegWit aumentó el tamaño máximo para bloques típicos a alrededor de 1,8 MB.
Verás, un bloque típico de transacciones consiste en cerca de 60% de datos de desbloqueo1. Así que, si calculamos el peso de un bloque de 1 MB compuesto por datos de transacción "típicos", obtenemos:
400.000 bytes * 4 = 1.600.000 unidades de peso
600.000 bytes * 1 = 600.000 unidades de peso
Peso total = 2.200.000 unidades de peso
Ahora, si un bloque puede pesar como máximo 4.000.000 unidades de peso, podemos calcular de cuánto fue ese aumento:
4.000.000 / 2.200.000 = 1,81Así que podrías decir que, en la práctica, esto fue un aumento del límite de tamaño del bloque a 1,8 MB.
1. Llegué a ese número del 60% recorriendo los archivos blk.dat y sumando los datos de scriptSig de todas las transacciones de un bloque, comparándolo con el tamaño total del bloque. No hice una prueba exhaustiva, pero 60% parece una media justa.
¿Por qué se implementaron los cambios de esta manera?
O, dicho de otro modo…
Si quieres corregir la maleabilidad de transacciones y aumentar la capacidad del bloque, ¿seguro que no hay una forma más directa de hacerlo? ¿Por qué necesitas reestructurar los datos de la transacción y crear una nueva métrica llamada "peso del bloque"?
Buena pregunta. Y tienes razón: esos cambios podrían haberse hecho de una manera mucho más simple. Por ejemplo, podrías haber hecho simplemente esto:
Sin embargo, si hicieras eso, las transacciones y los bloques se volverían "inválidos" bajo las reglas actuales.
Básicamente, eso significa que los nodos de la red rechazarían esas nuevas transacciones y bloques, porque no cumplen sus reglas de cómo deben "verse" las transacciones y los bloques.
Por ejemplo, una de las reglas era que cada bloque debía tener 1 MB o menos.
Por lo tanto, si quisieras hacer estos cambios, necesitarías que todos en la red actualizaran su software (y, obviamente, aceptaran los cambios).
Porque, si no lo hicieras, acabarías con una red que construye dos blockchains diferentes: nodos actualizados construyendo una blockchain con las nuevas reglas, y nodos antiguos continuando a construir una blockchain con las reglas viejas.
Eso se conoce como hard fork. Puede funcionar, pero es arriesgado y causará problemas para quien no actualice.
¿Cómo evitó SegWit un hard fork?
En vez de ser un hard fork, SegWit se implementó como un soft fork.
Con la actualización SegWit, las transacciones y los bloques todavía siguen las reglas actuales de la red bitcoin, así que todos los nodos siguen viendo los bloques SegWit como válidos. Por lo tanto, los nodos "antiguos" aceptarán esos bloques "nuevos" y los añadirán también a sus blockchains.
Por lo tanto, los nodos antiguos siguen acompañando a los nuevos nodos, aunque no actualicen.
Con un soft fork, todos permanecen sincronizados con una única versión de la blockchain.
La desventaja para los nodos "antiguos" es que no pueden aprovechar las nuevas funciones de SegWit hasta que actualicen. Sin embargo, hasta entonces, pueden seguir haciendo transacciones "al estilo antiguo" normalmente y acompañar la blockchain.
Así que, en resumen, la actualización SegWit puede parecer una forma "parcheada" de corregir la maleabilidad de transacciones y aumentar la capacidad del bloque, pero ese enfoque evita el problema de obligar a todos a actualizar al nuevo software (o quedarse atrás).
¿Cuándo se activó SegWit?
SegWit se activó el , en la altura de bloque 481.824.
Fue cuando los nodos empezaron a aplicar las nuevas reglas de consenso de la actualización SegWit a todos los bloques y transacciones nuevos.
¿Cómo entró en vigor SegWit?
La actualización Segregated Witness entró en vigor cuando 95% de los mineros señalaron que estaban listos para ella.
Los mineros pueden señalar su disposición usando un número de versión designado en los bloques que minan.
El campo de versión forma parte de la cabecera del bloque.
Entonces, cuando el 95% de los bloques tenían ese número de versión, SegWit se programó para su activación:
El umbral del 95% se calcula dentro de un período de reajuste de dificultad. Si se alcanza el umbral del 95%, el soft fork se activa al comienzo del siguiente período de ajuste de dificultad (que es de 2016 bloques, o alrededor de 2 semanas).
¿Había un plazo para la activación?
Sí, esta era la ventana de activación:
| Inicio: | |
|---|---|
| Plazo final: |
Si suficientes mineros no señalaban su disposición para la actualización Segregated Witness antes de la medianoche del 15 de noviembre de 2017, la propuesta habría expirado.
Cronología de la activación
Aquí tienes una tabla que muestra el número de bloques señalando SegWit en cada período objetivo hasta la activación:
| Inicio | Período Objetivo | Bloques Señalando | Porcentaje |
|---|---|---|---|
| 439.488 a 441.503 | 451/2016 | 22,37% | |
| 441.504 a 443.519 | 487/2016 | 24,16% | |
| 443.520 a 445.535 | 520/2016 | 25,79% | |
| 445.536 a 447.551 | 521/2016 | 25,84% | |
| 447.552 a 449.567 | 489/2016 | 24,26% | |
| 449.568 a 451.583 | 468/2016 | 23,21% | |
| 451.584 a 453.599 | 485/2016 | 24,06% | |
| 453.600 a 455.615 | 537/2016 | 26,64% | |
| 455.616 a 457.631 | 532/2016 | 26,39% | |
| 457.632 a 459.647 | 582/2016 | 28,87% | |
| 459.648 a 461.663 | 614/2016 | 30,46% | |
| 461.664 a 463.679 | 671/2016 | 33,28% | |
| 463.680 a 465.695 | 698/2016 | 34,62% | |
| 465.696 a 467.711 | 663/2016 | 32,89% | |
| 467.712 a 469.727 | 622/2016 | 30,85% | |
| 469.728 a 471.743 | 642/2016 | 31,85% | |
| 471.744 a 473.759 | 825/2016 | 40,92% | |
| 473.760 a 475.775 | 917/2016 | 45,49% | |
| 475.776 a 477.791 | 1440/2016 | 71,43% | |
| 477.792 a 479.807 | 2016/2016 | 100,00% |
Como puedes ver, el umbral del 95% de mineros señalando disposición para SegWit se superó durante el período de ajuste de dificultad entre los bloques 477.792 y 479.807.
En consecuencia, la actualización SegWit se activó 2.016 bloques (cerca de 2 semanas) después, en el bloque 481.824:
| Inicio | Período Objetivo | Nota |
|---|---|---|
| 479.808 a 481.823 | SegWit Bloqueado (Locked In) | |
| 481.824 en adelante | SegWit Activado |
¿Por qué se les dio a los mineros la decisión sobre la activación?
Porque, si quieres que un soft fork tenga éxito, necesitas que la mayoría de los mineros minen el tipo "nuevo" de bloque en la blockchain.
Eso es para que la blockchain con los bloques "nuevos" supere cualquier blockchain que esté siendo construida con bloques "viejos" (de cualquier minero no actualizado que aún pudiera estar minando).
Como resultado, la blockchain "nueva" se construirá más rápido que cualquier blockchain construida con bloques "viejos", así que todos los nodos adoptarán naturalmente la misma cadena más larga:
Tener la mayoría del poder de minería mantiene a todos en la red en la misma cadena.
Así que tener una fuerte mayoría de mineros a bordo permite una actualización fluida, ya que garantiza que toda la red convergerá en una única blockchain.
No es necesariamente que los mineros sean el grupo más capacitado para decidir los méritos de una actualización vía soft fork; es más bien que son necesarios para garantizar una actualización fluida para toda la red.
¿Qué pasa si no ejecuto la actualización SegWit?
Si estás ejecutando un nodo antiguo (por ejemplo, Bitcoin Core v0.13.0 o inferior), cualquier nodo SegWit al que estés conectado eliminará todos los datos de testigo de las transacciones antes de enviártelos.
Lo que eso significa es:
- Seguirás recibiendo las mismas transacciones que todos los demás.
- Si recibes una transacción SegWit, verás el movimiento de bitcoins, pero no verás ningún dato del código de desbloqueo.
Así que, básicamente, tu nodo recibirá una versión "ligera" de las transacciones SegWit.
¿Cómo actualizo?
Ese es el espíritu.
- Bitcoin Core – Solo asegúrate de estar usando la versión 0.13.1 o superior.
- Otras Carteras – Casi todas las carteras modernas hoy en día soportan transacciones SegWit.
SegWit lleva tanto tiempo existiendo que es poco probable que te encuentres con algún software que no lo soporte (a menos que sea obviamente antiguo).
Recursos
- BIP 141 (Capa de Consenso)
- BIP 144 (Servicios de Pares)
- Bitcoin.org – Beneficios de Segregated Witness
Agradecimientos
- Pieter Wuille – por explicar la estructura de datos de transacciones SegWit (entre otras cosas).
- Gregory Maxwell y Luke-jr – por explicar el peso del bloque.
- Edil Medeiros (UnB) – por la clase de SegWit en portugués.
Lectura adicional
- Clase de SegWit (UnB) – Una excelente explicación en video (en portugués) de SegWit, por el profesor Edil Medeiros de la UnB.