标准:Merkle证明数据格式

提议人:史蒂夫·施德斯(Steve Shadders,nChain)
技术标准委员会(TSC)发起人:瑞安·查尔斯(Ryan X Charles,Money Button)
作者:(默认为提议人)史蒂夫·施德斯
评审人:待定

补充说明:本委员会可根据需要安排用户、实施者、技术专家或标准专家在某个工作组做补充工作。

评审专家:法律、知识产权、合规

1.背景

  1. 问题陈述

    一个Merkle证明代表Merkle树(根通常嵌在比特币区块标头中)的一个分支。执行该证明,要求按照特定的算法将提供的数据元同计算出的数据元作重新组合。

    Merkle证明格式不仅要定义需要什么数据,还要定义如何在算法执行的上下文中解释该数据。

  2. 目标/正当性

    Merkle证明对于原始比特币白皮书中描述的简化支付验证(SPV)模式必不可少,也是比特币扩容的重要基础。为了让SPV钱包有效运作,需要由矿工或其他下载了整个区块的玩家向钱包提供Merkle证明。由于Merkle证明的发送和接收出自各种原因,实施方式可能五花八门,因此采用一种标准格式,可以使整个生态系统的实施简化。

    现有技术体现在FilteredBlock p2p消息中,该模式利用的是一位向量以及哈希表。 这种方式会引起不必要的混乱,需要对证明作反向确认,因为它无法为计算Merkle树中某项交易的位置索引提供简易机制。另外,因为在SPV客户端采用布隆过滤器会产生内在扩容问题,这种p2p消息模式将会被废止。

  3. 范围

    Merkle证明最常见的用例是去证明某项交易已被包含到一个区块中,我们称之为简化支付验证(SPV)。证明本身可能还需提供其他信息,包括交易、交易在某一区块中的索引,以及所在区块标头的参考。

    此外,若一项交易尚未包含到某个区块中或其Merkle证明尚不可用,可提供一个未断的祖先交易链,只要位于终端的那项交易具备Merkle证明即可。我们暂且将这种扩展数据集称为包含Merkle证明及其他数据的SPV信封(SPV envelope)。这样,SPV信封就相当于一个包含Merkle证明格式本身的超集。

    尽管我们认为要达到行业需求,SPV信封必不可少,但该数据集应另作处理,而不在应包括在我们此次标准提案的范围内,原因是,无论该证明采用什么样的格式,这样的标准应该可以包含Merkle证明元素。

  4. 优势

    技术标准委员会使命宣言包含如下目标:“通过标准化措施提高互通性,以此增强比特币SV的实用性。”Merkle证明是比特币点对点(p2p)交互的核心。按照定义,这种交互需要彼此不同,甚至独特的系统之间具有互通性。开发标准的Merkle证明数据格式符合委员会的宗旨,而且也有助于简化原始SPV操作在整个生态系统内的实施。

  5. 交付成果

    发布一份标准文件,说明用于接收和执行Merkle证明的数据格式及相应的执行算法。

    该标准的格式描述应保证既能以二进制格式来实施,也能以人可识读的格式来实施。

2. 简要工作组流程描述

对外:发招聘信息,邀请有意者申请加入评审小组

内部:起草 >> 评审 >> 重复之前流程(如有必要)

内部:专家评审(法律、知识产权、合规)>> 重新起草(如有必要)

对外:公共评议 >> 意见处理 >> 重新起草(如有必要)

对外:技术标准委员会批准

3. 评审人遴选

请注意,对所有人开放的公共评议流程将在日后纳入本标准制定流程中。

  1. 要求

    有兴趣加入本委员会工作组评审小组的人员应符合以下标准:

    • 可证明满足下列至少一项条件:
      1. 本标准提案中特定领域的主题专业知识
        • 相关研究领域学士学位或同等经验
          • (如:工程设计、计算机科学、数学,及其他相关科学领域)
      2. 符合该标准成果的关键干系人(该标准目前或日后的用户或实施者)。
      3. 拥有在国际认可的标准机构里从事标准制定方面工作的丰富经验
    • 愿意在工作组整个生命周期间签署保密协议(NDA)
    • 在工作组预期生命周期内,有充分时间投入到评审流程中(仅供参考:一个工作组的生命周期预计在3-4个月,评审工作通常需要花几天时间,有2-3次重复草拟和循环的过程)
  2. 申请

    如有意申请参加本标准内部制定阶段工作者,可将本人资料发至电子邮箱: [email protected]。申请信息的接收时间截止2020年7月3日。