La siguiente publicación tiene como objetivo resaltar los hitos de desarrollo que ayudaron a preservar una experiencia confiable para los usuarios del software cliente Bitcoin a lo largo de los años. Presentamos varias actualizaciones que fueron fundamentales para mantener las propiedades descentralizadas de la red y mitigar la carga de recursos de sus participantes. Describimos cómo se realizaron numerosas optimizaciones de órdenes de magnitud para que la red Bitcoin pudiera soportar el crecimiento de la actividad transaccional sin aumentar dramáticamente los costos de participación para los usuarios nuevos y existentes. Finalmente, observamos cómo todas esas mejoras caen dentro de un enfoque más amplio y sistemático para el desarrollo de protocolos que utiliza conocimientos de los conceptos de complejidad de Big-O y aprovecha algoritmos más inteligentes que hacen un uso más eficiente de los recursos de la red.
Almacenamiento en caché de firmas
Lanzamiento: Bitcoin-Qt 0.7.0
La verificación de firmas ECSDA es una de las operaciones más pesadas desde el punto de vista computacional que se realiza a nivel de pares. Debido a que deben verificarse para cada transacción, cualquier validación superflua genera una importante sobrecarga de recursos para el usuario final. Ese fue el caso de las primeras versiones del software que verificaban las firmas antes de ingresar a un grupo de memoria de nodo y después de recibirlas en un bloque.
Para ganar eficiencia, los desarrolladores crearon un caché que permite a los nodos almacenar firmas previamente validadas y omitir el trabajo redundante una vez que las transacciones llegan a un bloque aceptado.
Además, el caché de firmas también mitiga un vector DoS introducido por la posibilidad de que transacciones específicamente diseñadas paralicen a los clientes de Bitcoin.
Más información
Ultrapoda + LevelDB
Lanzamiento: Bitcoin-Qt 0.8.0
Ultraprune fue una de las primeras actualizaciones importantes del software Bitcoin destinada a resolver los gastos generales asociados con la validación de datos de transacciones de la cadena de bloques. Las versiones anteriores del cliente de referencia de Bitcoin mantenían un índice de todos los resultados de las transacciones, gastados o no gastados. Ultraprune redujo significativamente el tamaño de ese índice con la idea de que solo necesitaba realizar un seguimiento de los resultados no gastados, y un resultado, una vez gastado, se puede eliminar de los índices por completo.
Para lograr esto, se implementó un nuevo diseño de base de datos que asigna resultados de transacciones no gastadas a un formato personalizado compacto para reducir el tamaño de la información requerida para el trabajo de validación.
Para optimizar aún más el rendimiento del sistema, se introdujo Ultraprune en paralelo con LevelDB, que dejó obsoleta la antigua tecnología de base de datos BDB. En general, el impacto fue notable: dependiendo de su hardware, los usuarios podrían experimentar al menos una mejora de un orden de magnitud al validar los datos de blockchain. Esta nueva estructura de base de datos también allanaría el camino para futuros trabajos de poda e implementaciones más ligeras de nodos completos de Bitcoin.
Más información
Verificación de script paralelo
Lanzamiento: Bitcoin-Qt 0.8
Si bien se trata de un cambio más sutil, la transición de la verificación del script a un proceso más paralelizado eliminó una sobrecarga significativa de los tiempos de validación de bloques. Las primeras versiones del software validaban los datos del script de las entradas entre cada recuperación de UTXO, creando un problema de rendimiento debido al procesamiento lineal de todas las acciones. Esto viola un principio básico para el diseño de procesos informáticos eficientes, que dicta que el cálculo debe realizarse simultáneamente con los trabajos de E/S, siempre que sea posible. Con eso en mente, el mecanismo de validación de bloques se rediseñó para poder asignar verificaciones de scripts a subprocesos paralelos para que su verificación pueda ocurrir incluso antes de que el cliente termine de recuperar todos los UTXO del bloque. Para lograr esto, las acciones de verificación de secuencias de comandos se almacenan en una cola después de que se procesan las transacciones y se manejan por separado de otros trabajos de validación de entradas.
Como consecuencia, la sincronización con la punta de la cadena ocurre mucho más rápido al hacer un uso más eficiente de los recursos del par. Durante las pruebas de la implementación, los desarrolladores notaron una aceleración del 35% al 100% al realizar comparaciones con versiones anteriores del software.
Más información
Lanzamiento: Bitcoin Core 0.10
En un esfuerzo por mejorar aún más el tiempo de descarga del bloque inicial, el proyecto Core introdujo a finales de 2014 una importante reestructuración del mecanismo utilizado por los nodos para sincronizarse con la cadena válida de mayor trabajo.
Inicialmente, el proceso de arranque de un nuevo cliente Bitcoin implicaría que un usuario obtuviera datos de bloque de un único par con la consecuencia de que cualquier interrupción o disminución en la calidad de la conexión detendría significativamente el proceso. Con un tamaño de cadena de bloques cada vez mayor, esto daría lugar a veces a un tiempo de espera enorme para que se complete la sincronización, y un gran porcentaje de usuarios informan períodos de hasta varios días dependiendo de su hardware.
La primera sincronización de encabezados mitiga por completo este problema utilizando un nuevo método que implica que los nodos primero descarguen y validen encabezados de bloque de un solo par y luego obtengan datos de bloque en paralelo de una multitud de otros.
Las quejas sobre el tiempo de descarga del bloque inicial han prevalecido desde los primeros días de Bitcoin. Con la primera sincronización de los encabezados, el software dio un gran paso adelante en términos de usabilidad para nuevos usuarios. En lugar de perder muchas horas en una sincronización poco confiable, los nodos ahora podrían aprovechar toda su red de pares y reducir significativamente el tiempo de arranque. Con el uso de algoritmos más inteligentes, se logró otra mejora asintótica en este aspecto crucial de la sostenibilidad a largo plazo de Bitcoin.
Más información
Bloquear poda de archivos
Lanzamiento: Bitcoin Core 0.11
La poda de datos antiguos fue un concepto descrito por primera vez por Satoshi Nakamoto en su documento técnico como una posible solución a la escasez de espacio en disco. Desafortunadamente, el diseño original era inadecuado y no pudo implementarse como lo imaginó su creador. Siete años después, cuando la cadena de bloques alcanzó más de cien gigabytes, la introducción de la poda de archivos en bloque tal como la conocemos hoy presenta una gran ayuda para los usuarios con recursos limitados.
La poda de archivos en bloque aprovecha el trabajo previo con ultraprune; Los usuarios que inicialmente descargaron y validaron la cadena de bloques ahora pueden descartar datos sin procesar de más de 288 bloques. Debido a que esos nodos aún conservan el conjunto UTXO completo, siguen siendo capaces de validar los datos no utilizados, lo cual es suficiente para validar completamente nuevos bloques y proteger contra posibles dobles gastos.
Por supuesto, la poda implica que queda una cantidad suficiente de nodos de archivo para servir datos completos de blockchain. Por otro lado, esta innovación amplía la gama de validadores al hacer que sea más rentable seguir siéndolo. En conjunto, la solución es una adición bienvenida a las opciones disponibles para reforzar la diversidad de la red.
Más información
libsecp256k1
Lanzamiento: Bitcoin Core 0.12
Después de las mediciones, se determinó que el siguiente paso después de resolver las ineficiencias de la descarga de blockchain era abordar el cuello de botella de la verificación de transacciones y su pesada carga informática. El proyecto Core se propuso hacer esto mediante el uso de una nueva biblioteca diseñada para optimizar el rendimiento de las operaciones de ECDSA. ECDSA (Algoritmo de firma digital de curva elíptica) es la columna vertebral de la infraestructura de clave pública de Bitcoin y se utiliza cada vez que un usuario mueve monedas firmando un mensaje con sus claves privadas. Estas firmas deben ser verificadas por todos los pares de la red para preservar la integridad del libro mayor.
Los primeros desarrolladores habían considerado durante mucho tiempo abandonar la biblioteca OpenSSL original y, después de 5 años de consideraciones de diseño, pruebas y revisión por pares, se introdujo la biblioteca libsecp256k1 de Pieter Wuille como su reemplazo. Como se esperaba, la implementación aceleró considerablemente el proceso de validación de firmas detrás de cada transacción de Bitcoin. Los puntos de referencia informaron mejoras de entre 5 y 7 veces con respecto a la implementación de OpenSSL. Para los usuarios, esto se traduciría en ahorrar hasta la mitad del tiempo de arranque que normalmente se dedica a las operaciones de ECSDA, uno de los pasos más laboriosos para sincronizar un nuevo nodo desde cero.
Teniendo en cuenta el crecimiento de la actividad de transacciones de Bitcoin, esta actualización fue esencial para preservar una experiencia de usuario razonable para los pares de la red. Una vez más, la reducción de la complejidad algorítmica proporcionó a los usuarios un uso más eficiente de sus recursos y redujo drásticamente la barrera de entrada para nuevos participantes.
Más información
Limitación del grupo de memoria
Lanzamiento: Bitcoin Core 0.12
Una vulnerabilidad de larga data del software Bitcoin fue su incapacidad para lidiar adecuadamente con la inundación del grupo de memoria de un par. De hecho, un atacante podría enviar una gran cantidad de transacciones de bajo valor y tarifas bajas que se acumularían en el grupo de memoria hasta sobrecargar la memoria disponible. Esto provocaría que los nodos con recursos de RAM relativamente bajos fallaran durante períodos de actividad inusual. La única medida eficaz contra esto fue aumentar la tarifa mínima de retransmisión del software, lo que todavía no dejaba un límite superior en el tamaño potencial del mempool.
Para remediar esto, los desarrolladores del proyecto Core implementaron un tamaño máximo estricto del grupo de memoria con políticas de desalojo específicas que clasifican las transacciones por tarifas y desalojan primero a las que pagan menos. Para evitar que transacciones con la misma tarifa vuelvan a ingresar al grupo de memoria, el nodo aumentará su tarifa de retransmisión mínima efectiva para que coincida con la de la última transacción desalojada más la tarifa de retransmisión mínima inicial.
La configuración del tamaño máximo se deja a los usuarios y el tamaño predeterminado es 300 megabytes. Esta actualización proporciona una experiencia mucho más sólida para los usuarios de nodos con recursos limitados y, en general, hace que toda la red sea más confiable.
Más información
En la Parte 2, analizaremos mejoras más recientes que se basan en las tecnologías presentadas anteriormente y mejoran aún más la solidez y el potencial de escalamiento de la red.
