El desarrollador Peter Todd, miembro activo del cliente Bitcoin Core, ha publicado una serie de observaciones sobre el pasado hard-fork realizado a la plataforma de contratos inteligentes de Ethereum. Considerando también escenarios próximos a la implementación de Segregated Witness en Bitcoin, donde la realización de una bifurcación para el agrandamiento del tamaño del bloque sea necesaria para la red.
El protocolo de Bitcoin está próximo a recibir las primeras pruebas previas a la implementación definitiva de Segregated Witness (SegWit), una técnica para reducir la cantidad de datos de las transacciones que se registran en los bloques de la red Bitcoin.
Con la llegada de SegWit, se espera que puedan registrarse inclusive cuatro veces más transacciones en los bloques de Bitcoin, prescindiendo además de información referente a las claves de usuarios utilizadas en las transacciones que puede ser usada para perpetrar ataques de maleabilidad a la red.
La experiencia reciente de Ethereum
Todd confiesa que considera el hard-fork realizado en Ethereum como un “rescate” a la Organización Autónoma Descentralizada (DAO), pero dejando las opiniones políticas a un lado, el desarrollador se enfoca en las consecuencias derivadas de este evento que, a su juicio, deben ser evitadas en la red de Bitcoin en el caso de la ejecución de una bifurcación.
El fenómeno de las transacciones repetidas o replicadas (replay transactions) fue sin duda el efecto negativo más notable en la ejecución del hard-fork de Ethereum, a lo cual Todd denomina un “completo desastre” que pudo evitarse y que precisamente los desarrolladores de Ethereum estaban al tanto de dichos riesgos.
.@petertoddbtc we knew it would happen weeks before launch, we didn't want to implement replay-protection b.c. of implementation complexity
— Vlad Zamfir (@VladZamfir) 31 de julio de 2016
Para quienes no están al tanto, este fenómeno de transacciones repetidas se refiere al caso en que luego de una bifurcación en una cadena de bloques, los usuarios pueden realizar una transacción a una cartera cualquiera y este movimiento será repetido, replicado o “copiado” en la otra cadena de bloques recién creada. Logrando de esta forma generar de la nada la misma cantidad de criptomonedas en otra cartera correspondiente a la nueva red.
Estas transacciones, que son consideradas como “ataques”, fueron realizadas por numerosos usuarios que, utilizando Ethers (ETH) minados antes del hard-fork, los transferían a carteras en las casas de cambio para obtener por duplicada la misma cantidad de criptomonedas (ETH y ETC) en ambas cadenas.
Por supuesto, esta característica era desconocida para muchos usuarios e inclusive para diversas casas de cambio como BTC-e y Coinbase, que sin estar debidamente preparadas ante el fenómeno, sufrieron significativas pérdidas monetarias debido al mal manejo de esta característica en sus plataformas.
Garantizando una bifurcación segura
Para Todd, ejecutar una bifurcación de forma segura es posible utilizando diversos algoritmos que ya han sido propuestos, y algunos desarrollados, por varios de los programadores que forman parte del equipo del cliente Bitcoin Core.
La principal alternativa es una que fue desarrollada por Luke Dashjr en trabajos previos a los que Todd hace referencia en su publicación y le llama un “soft-fork forzado”. En términos básicos, esta propuesta “envuelve” una bifurcación en un soft-fork y obliga a los nodos a seguir la cadena principal sugerida o de lo contrario estarán completamente inhabilitados para procesar y realizar transacciones, incluso en la cadena de bloques alternativa.
En esta opción, los usuarios que deseen oponerse a operar en la cadena de bloques propuesta, deberán ejecutar un nuevo hard-fork para recuperar la operabilidad y así poder realizar transacciones en la cadena de bloques alterna.
Todd destaca que esta propuesta evitaría los inconvenientes experimentados con la bifurcación de Ethereum, como los ya mencionados ataques con transacciones replicadas y la migración de muchos usuarios hacia la cadena de bloques minoritaria, hoy llamada Ethereum Classic.
Además, Todd menciona otros mecanismos para evitar los ataques por transacciones replicadas luego de un hard-fork, mencionando las propuestas de Tom Harding y Gregory Maxwell, quienes respectivamente declaran que a través del uso de bits en las transacciones y hashes en determinados bloques, puede evitarse este tipo de ataques.
Mientras que la propuesta de Harding configura las carteras para identificar determinados bits en las transacciones para bloquear las replicadas, la alternativa de Maxwell en cambio hace inválidas todas las transacciones realizadas en un rango de bloques determinado que garantice que la posibilidad de replicar transacciones no exista.
Entre otras medidas consideradas en la publicación de Todd para reducir riesgos en la ejecución de un hard-fork, destaca la propuesta de Matt Corallo de Compact Blocks. Esta es una técnica para reducir los tiempos de propagación de los bloques en la red de nodos, al mismo tiempo que se disminuye el ancho de banda utilizado para tal tarea. Se espera que Compact Blocks sea incluida en la versión 0.13.0 del cliente Bitcoin Core.
Bitcoin Core divisa la posibilidad del hard-fork
Aunque la publicación fue realizada de manera personal por Peter Todd y no en el blog oficial de Bitcoin Core, son obvias las referencias a distintos trabajos y propuestas que ya están siendo desarrolladas por otros programadores y contribuyentes al código fuente de Bitcoin. Esto nos dice que Bitcoin Core tiene en mente el escenario posterior a la implementación de SegWit, donde la aplicación de un hard-fork sea una medida necesaria para agrandar el tamaño de los bloques de la red.
En la hoja de ruta de Bitcoin Core esta posibilidad de la bifurcación también está presente, pero con los efectos ya vividos en la comunidad de Ethereum con la pasada bifurcación a su cadena de bloques, es obvio que Bitcoin Core no quiere correr los mismos riesgos para el protocolo y está considerando diversas alternativas para evitarlo.
5