Estándar: Formato de datos para la prueba de Merkle

Promotor: Steve Shadders (nChain)

Patrocinador TSC: Ryan X Charles (Money Button)

Autores: (proponente por defecto) Steve Shadders

Revisores: TBA

Adicional: Según sea necesario, el TSC podrá designar a usuarios, implementadores, expertos técnicos y expertos en estándares para que desempeñen funciones adicionales dentro de un grupo de trabajo.

Revisores especializados: Jurídico, propiedad intelectual, cumplimiento

1. Antecedentes

  1. Exposición del problema

    La prueba de Merkle constituye una rama de un árbol Merkle que suele incrustar una raíz en una cabecera de bloque de Bitcoin. Ejecutar la prueba requiere la recombinación de los elementos de datos suministrados junto con los elementos de datos calculados según un algoritmo específico.

    Un formato de prueba Merkle no solo necesita definir los datos requeridos, sino también cómo interpretar esos datos en el contexto de la ejecución del algoritmo.

  2. Objetivos y justificación

    La prueba de Merkle es fundamental para el modelo de verificación de pago simplificado (SPV por sus siglas en inglés) descrito en el libro blanco original de Bitcoin y que respalda el escalado de Bitcoin. Para que las carteras de SPV puedan utilizarlas, las pruebas de Merkle deben ser proporcionadas a las carteras por los mineros u otros actores que descarguen bloques completos. Como es probable que haya una gran variedad de implementaciones que transmitan y reciban pruebas de Merkle por varias razones, la adopción de un formato estándar simplifica las implementaciones en todo el ecosistema.

    La técnica actual está incorporada en los mensajes p2p de FilteredBlock, que utiliza un vector de bits y una lista de hashes. Esta disposición es innecesariamente confusa, ya que requiere la validación inversa de la prueba, pues no proporciona un mecanismo sencillo para calcular el índice posicional de una transacción en el árbol de Merkle. Además, es probable que este mensaje p2p quede desfasado en favor de otros mecanismos debido a los problemas de escalabilidad inherentes al uso de filtros de bloom para los clientes de SPV.

  3. Alcance

    El caso de uso más habitual para una prueba de Merkle es probar que una transacción ha sido incluida en un bloque, conocido como verificación de pago simplificada (SPV). La propia prueba puede requerir información adicional, como la transacción, el índice de la transacción en un bloque y una referencia a la cabecera del bloque en el que se incluye.

    Asimismo, cuando una transacción aún no está incluida en un bloque o cuando aún no hay disponible una prueba de Merkle para la transacción, la prueba se puede proporcionar presentando una cadena ininterrumpida de transacciones ancestrales que finalizan con una transacción para la que se puede suministrar una prueba de Merkle. En principio, nos referimos a este conjunto de datos ampliado como un «sobre SPV» que contiene pruebas de Merkle y datos adicionales. Como tal, el sobre SPV es un superconjunto del propio formato de pruebas de Merkle.

    Aunque consideramos que el sobre SPV satisface las necesidades del sector, debe tratarse por separado y no está en el ámbito de esta propuesta de estándar, ya que dicho estándar puede encapsular el elemento de prueba Merkle, independientemente de cómo esté formateado.

  4. Beneficios

    Entre los objetivos de la declaración de objetivos del TSC está: «mejorar la utilidad de Bitcoin SV potenciando la interoperabilidad a través de la estandarización». Las pruebas de Merkle son esenciales para las interacciones entre pares en Bitcoin. Por definición, esta interacción requiere la interoperación entre sistemas que probablemente sean distintos y únicos. Por ello, el principal beneficio de desarrollar un formato de datos estándar para la prueba de Merkle está en línea con los objetivos declarados por el TSC y satisface una necesidad que simplificará la implementación en todo el ecosistema de una operación SPV fundamentalmente primitiva.

  5. Entrega

    Un documento de estándares que describe un formato de datos y el algoritmo de ejecución que lo acompaña para recibir y ejecutar una prueba de Merkle.

    El estándar debe describir el formato de forma que pueda implementarse tanto en un formato binario como en un formato legible para el ser humano.

2. Breve descripción del proceso del grupo de trabajo

Externo: Solicitud de manifestaciones de interés en formar parte del panel de revisión

Interno: Borrador >> Revisión >> Iterar (si es necesario)

Interno: Revisión especializada (legal, propiedad intelectual, cumplimiento) >> Iterar al borrador (si es necesario)

Externo: Revisión pública >> Responder a los comentarios >> Iterar al borrador (si es necesario)

Externo: Ratificación por parte del TSC

3. Selección de revisores

Nótese que el proceso de revisión pública abierto a cualquier persona que desee hacer aportaciones es una parte posterior de este proceso de desarrollo de estándares.

  1. Criterios

    Las personas que deseen solicitar unirse a este panel de revisión del grupo de trabajo del TSC deben cumplir los siguientes criterios:

    • Poder demostrar que cumple con al menos uno de los siguientes requisitos:
      1. Tener conocimientos especializados en el ámbito específico del estándar propuesto
        • Poseer un título universitario o experiencia equivalente en un campo de estudio pertinente,
          • por ejemplo, ingeniería, informática, matemáticas, otros campos científicos relevantes
      2. Ser una parte interesada clave en los resultados de este estándar, ya sea como usuario o implementador actual o futuro del estándar.
      3. Tener amplia experiencia en la elaboración de estándares en relación con una institución de estándares reconocida internacionalmente
    • Estar dispuesto a firmar un acuerdo de confidencialidad durante el ciclo de vida del grupo de trabajo
    • Tener tiempo suficiente para comprometerse con el proceso de revisión durante el tiempo de vida previsto del grupo de trabajo (como orientación, se espera que los ciclos de vida de los grupos de trabajo sean de 3 a 4 meses y normalmente requerirán varios días de trabajo de revisión divididos en 2 o 3 iteraciones de un proyecto de estándar)
  2. Solicitud

    La solicitud para participar en la fase de desarrollo interno de este estándar puede hacerse enviando un correo electrónico con los criterios arriba mencionados a: [email protected]. El plazo de recepción de solicitudes finaliza el 3 de julio de 2020.