Uno de los anuncios más destacados de la Conferencia CoinGeek de Zúrich fue la publicación del formato estandarizado de pruebas de Merkle por parte del Comité de Normas Técnicas de Bitcoin SV (TSC por sus siglas en inglés).
Durante su intervención en el evento, Steve Shadders, director de tecnología de nChain y presidente del TSC, anunció junto con Alex Fauvel, fundador de Two Hop Ventures y miembro fundador del TSC, que el proceso de revisión pública del formato estandarizado de pruebas de Merkle había concluido y que la norma se había publicado bajo la licencia OpenBSV.
Esta es una gran noticia para los desarrolladores y usuarios de Bitcoin SV, ya que permite una interoperabilidad mucho mayor para los pagos de BSV y proporciona una plataforma estable y fiable para el desarrollo de servicios de verificación de pagos simplificada (SPV por sus siglas en inglés) en la cadena de bloques. La SPV es un componente clave en la funcionalidad básica de Bitcoin SV, la cadena de bloques que más se ajusta al libro blanco original del Bitcoin publicado por Satoshi Nakamoto en 2008. En él se describe la aplicación de SPV para permitir a los usuarios recibir y validar pagos sin tener que ejecutar un nodo completo de Bitcoin.
El Comité de Normas Técnicas tiene como objetivo mejorar la interoperabilidad dentro del creciente ecosistema de Bitcoin SV. Para ello, trabaja con los desarrolladores y las partes interesadas en el desarrollo de normas comunes que sean compatibles con distintas aplicaciones. Es importante señalar que el TSC no determina esas normas, sino que proporciona el entorno y el proceso de desarrollo de normas técnicas para mejorar la interoperabilidad y acelerar la adopción de Bitcoin SV.
«El TSC no está aquí para decidir cuáles son las normas. Lo que hace es ayudar al sector a decidir cuáles son esas normas», explicó Shadders.
El formato estandarizado de pruebas de Merkle ha superado el exhaustivo proceso de estandarización del comité. Tras su consideración, redacción, revisión interna y revisión pública, finalmente se ha publicado para su adopción.
Pruebas de Merkle y su funcionamiento con SPV
Para entender las ventajas de un formato estandarizado de pruebas de Merkle, primero debemos comprender la importancia que tiene esta estructura de datos en la verificación de pagos simplificada (SPV). La SPV permite a un vendedor o usuario validar una transacción de Bitcoin SV sin necesidad de descargar toda la cadena de bloques. En su lugar, pueden recibir desde un nodo fiable una cabecera del bloque de Bitcoin que contiene esa transacción. Esta cabecera contiene la raíz Merkle, un hash de todas las transacciones que hay en ese bloque.
Las transacciones de Bitcoin se almacenan en una estructura de datos de Merkle en forma de árbol. Esta actúa de forma similar a un árbol binario, salvo porque sus hojas se componen de los hashes de cada transacción, que a su vez se combinan con sus vecinos en cada capa hasta llegar a la raíz del árbol (la raíz de Merkle). La raíz de Merkle, por lo tanto, contiene la prueba de cada transacción de ese bloque de Bitcoin, lo que permite determinar la existencia de una transacción en la cadena de bloques mediante esta prueba y el hash o ID de dicha transacción.
Las cualidades técnicas de esta validación permiten a los usuarios de Bitcoin SV ejecutar con seguridad un “nodo ligero” SPV para recibir transacciones de otros mediante un hardware ligero y barato, con la confianza de poder comprobar fácilmente que esas transacciones son válidas sin necesidad de una cadena de bloques completa.
«Una prueba de Merkle es, probablemente, una de las estructuras de datos más importantes del Bitcoin junto a la cabecera de un bloque. Es lo que nos permite demostrar que una transacción está conectada a un bloque, es decir, que los mineros han aceptado esa transacción, así que existen muchos motivos para que las partes quieran intercambiar una prueba de Merkle», le explicó Shadders a la Bitcoin Association.
«Esto es algo fundamental para la interacción entre pares, ya que parte de esa interacción implica el envío de bits de información con pruebas de Merkle adjuntas, lo que significa que muchos monederos diferentes tienen que ser compatibles con ellas. Así que, si todo el mundo lo aplica de forma diferente, cada vez que quieras conectarte a un servicio, tendrás que idear una nueva forma de hacerlo».
Gracias al formato estandarizado de pruebas de Merkle, estas pruebas cruciales pueden ser compartidas entre diferentes servicios y usuarios con la garantía de que serán compatibles con sus monederos o nodos SPV, lo que hace que todo el proceso de validación de transacciones sea más autónomo y accesible.
La importancia de las normas técnicas
El formato estandarizado de pruebas de Merkle es la primera norma del TSC que alcanza la fase de publicación. Aunque su grado de desarrollo era ya considerable cuando llegó a la fase de revisión pública, las partes interesadas siguieron mejorando significativamente algunos aspectos de la norma mediante el envío de comentarios previos a su publicación.
Las normas son muy importantes para el fomento de un ecosistema de innovación e interoperabilidad, explicó Shadders, tal y como demuestra su prevalencia en los sectores tradicionales. Estas no reducen la competencia, sino que mejoran la accesibilidad tanto para los competidores como para los usuarios. Shadders utilizó el sector del DVD como ejemplo para describir cómo las normas pueden contribuir a la competencia y mejorar la experiencia del usuario.
«Digamos que yo tengo un reproductor de DVD de Sony y me compro uno de Samsung. Imaginemos que estos tuvieran formatos diferentes. Tendría que comprar una nueva colección de DVD entera para reemplazar todos los que ya tengo. [Esta norma] básicamente resuelve ese problema», aseguró.
«Todos los monederos pueden implementar la norma existente de las pruebas de Merkle, lo que significa que pueden comunicarse instantáneamente con cualquier otro monedero que también lo haya implementado (incluso con alguno en el que ni siquiera habría pensado). Eso incluye los monederos que aún no existen pero que pueden desarrollarse en el futuro».
Sin este tipo de normas, los sectores corren el riesgo de presentar a sus usuarios ecosistemas aislados y dispares, limitando la accesibilidad general a la tecnología subyacente y a las aplicaciones desarrolladas a partir de ella. Al abordar la estandarización del formato de pruebas de Merkle, la comunidad Bitcoin SV se ha asegurado de que la interoperabilidad sea un componente esencial de la competencia y la innovación entre los monederos SPV y los proveedores de datos.
«El elemento esencial de la propia SPV es la prueba de inclusión, la prueba de Merkle. Sin esta norma, cualquiera que quisiese implementar una SPV en un monedero tendría que idear una estructura de datos. El siguiente interesado en hacer lo mismo debería optar entre adoptar esa estructura de datos o no ser compatible con ella, en cuyo caso tendríamos dos monederos de SPV con sus respectivos ecosistemas aislados», explicó Shadders.
Shadders subrayó que las normas publicadas por el TSC reflejan las aportaciones de la comunidad y no las opiniones de los miembros del comité. También añadió que, una vez publicadas, estas normas siguen estando sujetas al escrutinio público y pueden actualizarse, modificarse o incluso retirarse si se encuentran soluciones mejores o se producen cambios en la tecnología circundante.
«El TSC solo funciona en colaboración con el sector. Nosotros desempeñamos el papel de facilitadores y los proveedores de servicios y otras personas son quienes realmente aportan la información», aseguró Shadders.
«Creo que es importante hacer una aclaración en lo que se refiere a los miembros del TSC. Cuando estos actúan en calidad de miembros del propio comité, son independientes y están ahí para actuar como facilitadores. Al margen de eso, por supuesto, todos participan en el sector y tienen intereses en ciertas cosas, por lo que también pueden formar parte de los grupos de trabajo».
Si una norma necesita ser actualizada en el futuro, el proceso de normalización del TSC está diseñado para ello. Es posible que muchas normas requieran actualizaciones y modificaciones a medida que surjan nuevos requisitos o cambie el ecosistema.
«Intentamos animar a los participantes a pensar en la compatibilidad futura y estar abiertos a posibles cambios que puedan producirse más adelante. Sin embargo, es muy posible que una norma resulte inviable u obsoleta porque la tecnología que la rodea haya cambiado, en cuyo caso es más que probable que esa norma sea retirada y sustituida por otra nueva», afirmó Shadders.
«Se trata simplemente de que alguien articule la necesidad del sector de actualizar o sustituir una norma y eso sea evaluado por las partes interesadas, no solo por el TSC».
El formato estandarizado de la prueba de Merkle
Ahora que se ha publicado el formato estandarizado de la prueba de Merkle, los detalles de la norma están disponibles en una página dedicada a ella en el sitio web del TSC.
Este formato especifica la estructura de datos en la que se almacena la información de la prueba de Merkle cuando se transfiere entre usuarios, como los monederos SPV, que el preámbulo de la especificación técnica señala como crucialmente dependiente del intercambio eficiente e interoperable de dicha información.
El formato estandarizado de la prueba de Merkle consta de dos componentes:
- Una representación del formato de estructura de datos propuesto en código binario y en Notación de Objetos de JavaScript (JSON).
- Una explicación del algoritmo utilizado para validar las transacciones usando la prueba de Merkle una vez recibida en este formato.
El ámbito de aplicación de este formato estandarizado para las pruebas de Merkle se refiere únicamente a las pruebas simples, como las requeridas por los monederos SPV que validan las transacciones individuales en el momento de su recepción, mientras que las pruebas compuestas quedarán bajo el paraguas de una futura norma ampliada. También se ha omitido la definición de las llamadas estandarizadas a la API, ya que esta no tiene relación con la estructura de datos central y se beneficiará de una mayor deliberación.
Bajo el formato estandarizado, las pruebas de Merkle se almacenan en una estructura que incluye un único byte de bandera, el índice posicional de la transacción en el árbol de Merkle, una lista de hashes de 32 bytes y un hash o ID de la transacción. Esta información se puede almacenar y proporcionar en formato binario o JSON junto al byte de bandera que describe características adicionales. Quienes utilicen esta norma para cotejar una transacción mediante la prueba de Merkle de un bloque pueden elegir si desean incluir la transacción original o solo el ID de la misma, el tipo de objetivo o el elemento final, el tipo de prueba (de rama o de árbol) y si esta última forma parte de un conjunto de pruebas compuesto.
También se describe el proceso de validación de la prueba de Merkle, que incluye varias comprobaciones para tener en cuenta las banderas mencionadas anteriormente, así como la validación de los nodos sin vecinos en la estructura de datos del árbol de Merkle.
Durante sus procesos de revisión interna y pública, el TSC recibió comentarios sobre la complejidad y las opciones por defecto del formato de la estructura de datos estándar. En particular, muchas partes interesadas sugirieron que el caso de uso común (de validación de transacciones únicas utilizando campos de datos comunes) no debería requerir la interacción con los aspectos más complejos del formato.
«En respuesta a esta preocupación, se han realizado varios cambios, principalmente en el caso de uso de JSON, de manera que el uso de las opciones por defecto da como resultado un objeto JSON mucho más sencillo. De este modo, se mantiene la posibilidad de utilizar las opciones alternativas sin romper la norma, al tiempo que se ocultan los campos de escritura opcionales en el caso por defecto», señala la especificación.
En el sitio web del TSC se puede consultar una descripción técnica completa del formato estandarizado de la prueba de Merkle.
Cómo se hace una norma de Bitcoin SV
El estreno de esta norma demuestra la capacidad del TSC como herramienta de desarrollo comunitario para mejorar el entorno en el que operan los desarrolladores de Bitcoin SV, las startups y las empresas. La revisión interna y pública del formato estandarizado de las pruebas de Merkle condujo a la creación de un formato de estructura de datos y un algoritmo de validación más fáciles de usar, conservando al mismo tiempo la flexibilidad y la compatibilidad futura con tareas como la validación de pruebas compuestas.
El TSC sigue un proceso de normalización en profundidad cuyos diferentes pasos garantizan la interacción con la comunidad y las partes interesadas. Cualquiera puede proponer ideas para las normas de Bitcoin SV. Estas son estudiadas por el comité antes de pasar a la siguiente fase: la redacción de las normas técnicas.
Una vez redactado el borrador de la norma, se somete a una serie de revisiones internas que incluyen un examen de la propiedad intelectual y una revisión jurídica para determinar cualquier problema que pueda surgir a partir de la publicación de dicho borrador. Este proceso se lleva a cabo conforme a un acuerdo de confidencialidad, garantizando así que la norma propuesta no salga del entorno del comité y las partes interesadas.
Una vez completados estos procesos de revisión, la norma vuelve a la fase de borrador si se necesita seguir trabajando en ella o pasa a la fase de revisión pública. Durante la revisión pública, cualquier parte interesada puede aportar sus comentarios sobre la norma propuesta. Estos se tendrán en cuenta y, si se demuestra que son pertinentes, se adaptará la norma para darles cabida.
Solo una vez superada esta revisión pública se publicará la norma, aunque el trabajo no termina ahí. Tras la publicación de una norma, el TSC y las partes interesadas evalúan las reacciones del sector y cómo ha sido su adopción por parte de este. Tras un periodo de tiempo suficiente, pueden recomendar la publicación de la norma o su retirada.
«En el TSC hemos desarrollado un proceso de creación de normas que consta de tres fases. La primera de ellas es la fase de presentación, que permite a cualquier persona ajena al TSC proponer cuestiones que querría ver reguladas, ya sea en su sector o fuera de él. Preferimos que sean parte interesada, para que la adopten y fomenten su necesidad en el sector», explica Alex Fauvel, miembro fundador del TSC.
«En la segunda etapa tenemos el área de redacción de borradores. En ella, elaboramos un primer borrador, luego lo revisamos internamente y, después, hacemos que los especialistas en propiedad intelectual lo examinen. Luego, si es necesario, hacemos que lo examinen también especialistas técnicos».
«Una vez que estamos satisfechos con el primer borrador, algo que se hace a lo largo de varios ciclos, lo publicamos para que el público tenga la oportunidad de comentarlo. Ese periodo dura unos dos meses. Una vez que hayamos incorporado esa información, si es necesario, la publicaremos en la tercera etapa. A continuación, supervisamos su adopción por parte del sector para dar el visto bueno y decir que recomendamos la norma o retirarla (¡aunque esperamos no tener que hacerlo!)».
El TSC emplea este proceso para seguir facilitando la creación de normas útiles y potentes para el desarrollo de Bitcoin SV. Esto incluye la especificación del sobre, que actualmente se encuentra en la fase de revisión pública y está abierto a comentarios. Esta especificación se ocupa del modo de almacenar los datos dentro de las transacciones de Bitcoin, creando un sobre de datos de uso general que permite el procesamiento eficiente de la información y la interoperabilidad con los protocolos de datos existentes y futuros.
Si deseas participar en el desarrollo de normas técnicas para Bitcoin SV, puedes visitar el sitio web del TSC para proponer una nueva norma, hacer comentarios sobre los borradores de normas en revisión pública o enviar sugerencias sobre la hoja de ruta del borrador.