我们终于实现了中本聪对比特币“点对点”的愿景
by Steve Shadders
九月 30, 2020 (1min read)

“一种纯粹的peer-to-peer(点对点)形式的电子现金将允许一方直接向另一方进行线上支付,而无需通过金融机构……”

——中本聪

这是比特币白皮书中的第一句话。

当2009年比特币0.1.0版本发布的时候,它具有一个“概念证明”的特性,但这可能是过去最被忽视的一点,而想要验证的就是过去被称为“IP交易”、在上面那句话中被称为“peer交易”的这一概念。在比特币的世界里我们谈到peer时,通常认定它指的是节点(node),因为节点实际上就是互相连接的peer。然而,比特币上不会只有一类peer,从peer这个词的定义我们就可以看出,当一组事物具有共性时,群组里的事物就是peer。

这意味着不排除存在多个peer群组。其实,白皮书第一句中提到的peer其实是指的是比特币网络的用户,而不是节点。如果没有用户(畅想一下有数十亿用户),比特币网络用处何在呢?

IP交易特性就是用户与用户之间直接的交互,而当它与SPV(全称简易支付验证,请参考比特币白皮书第8章节)轻客户端相结合时,就恰恰是比特币可以扩容的原因。这里是一个非常简单的扩容原则:不要做与你无关的工作。SPV允许用户忽略所有与他们无关的比特币交易历史,同时依然享有比特币的安全保障。

不过这在当时只是个初级实践,你可以对它进行概念证明。甚至中本聪也认为,原始形式下的比特币IP交易,在执行中会存在一些实际的困难:

  • peer之间如何能找到对方
  • 不安全的连接
  • NAT穿越问题
  • 易受到中间人攻击

尤其是,同许多处于雏形阶段的事物一样,比特币IP交易尚不完善,当时它还缺少用于获取、验证或传递SPV merkle证明的设施。

而今天,Bitcoin SV基础架构团队同时发布出三款产品,以及若干其它服务,提供了重新实现“IP2IP愿景”所需的所有工具,并解决了所有IP交易过程中已知存在的问题。

Bitcoin SV节点软件v1.0.6(代号Push)

  • 新增可以提供和验证Merkle证明的功能
  • 探测“双花”的ZeroMQ通知
  • (WIP)探测到“双花”后进行p2p广播,让全网知晓

mAPI v1.2

  • 基于push推送的Merkle证明和“双花”回调通知

SPV信道v1.0.0 

  • 具有push推送功能的端到端加密信息传递的纳米服务(nano-service),可为比特币用户始终在线提供服务,并为在线和离线信息传递的处理提供了统一接口。
  • 作为始终在线的服务,它允许任意两个参与方通过未知中介在专用通道中进行通讯,这时它们只需要向外连接即可,从而解决了NAT穿越问题。这在原理上近似于即便用户都在防火墙后,TeamViewer、Skype和Zoom等产品依然能够无缝地工作,不同的是SPV信道进行了完全的端到端加密。

SPV信道是由Bitcoin SV基础架构团队新发布的产品。你可以把这里的“信道”理解为类似IMAP邮件服务器,当你处于离线状态时,它会为您收集消息;当你再上线时,它会将消息直接传递给你;当你和另一方都在线时,你们的体验类似于直接连接。但与IMAP邮件服务器不同的是,SPV信道的信息默认是端到端加密的,而且没有可怕的邮件头格式要求。它可以与Paymail集成,但服务器看不到信息内容,也完全无法得知内容。除了这一点外,其它技术都不是比特币特有的。但它也确实填补了比特币点对点交互的工作流中的关键空白。

SPV信道的应用不仅限于此,它几乎能够涵盖到比特币甚至比特币之外的任何链下协调问题,例如:

  • 统筹协调多签和门限签名群组
  • 钱包收到付款通知
  • 可对任何事项推送通用型通知
  • 作为新一代自主运营的电子邮件和即时通信产品的基础层

一个使用mAPI的范例

早期版本的mAPI(过去称为Merchant API)解决了两个关键问题——探寻交易费用以及直接向矿工提交交易。从矿工那里得到交易被接受的反馈很简单,因为提交交易时就可以直接获得响应。但是在用户与矿工之间的连接被关闭后还会发生一些事项,比如交易入块时接收到SPV证明,于是此前我们引入了一种通过轮询mAPI来获取交易状态更新的初级机制,但这效率不高,而且对于特定的使用情境,比如要获知是否有人在试图“双花”时,时间紧迫,这时就需要引入一种更好的机制了。

首先先说“push推送”模式。注册事件回调(函数)是一种常见的编程范式。SPV信道允许用户与矿工之间进行交互。当注册了回调后,你通常需要为回调路径提供一个始终在线的URL,但这可不是手机用户能提供的。

现在我们谈谈SPV信道。它是一种托管服务(也可自行托管),能够充当用户接收消息的通道。如果用户在线,他将立即收到消息;如果用户处于脱机状态,则消息会被存储起来并在用户上线后立即转发给他。实际上你想象不到,SPV信道的第一个内部版本被命名为“Store and Forward(存储并转发)”。

SPV信道的工作流如下:

1、顾客和商户通过Paymail服务发现对方,然后通过SPV信道建立双向加密通讯;

2、商户通过MinerID找到一个矿工的mAPI服务;

3、商户通过mAPI向矿工请求交易费报价;

4、商户通过BIP270向顾客发送一个交易单,包括所需的交易费用,支付金额以及交易的其它相关要求;

5、客户发送交易(可能还同时发送了Merkle证明和其它被要求提供的信息)给商家;

6、商户通过mAPI将交易提交给矿工,并注册一个SPV信道的URL用来接收回调;

7、假如矿工探测到了“双花”交易,矿工会向SPV信道发出一条提醒信息,若商户在线,他马上就可以接收到这条信息;

8、一旦这笔交易入块,矿工会向SPV信道发送出Merkle证明,商户的钱包可以对它进行检索并将其存储在其数据库中;

9、或者,商户通过他与顾客的SPV信道,将Merkle证明发回给顾客。

谁为这些服务付费?

在早期,这些服务的运营成本可能很低,因此有人会免费提供这些服务,但最终这类托管服务的成本会上升。不过钱包、矿工和支付运营商可能会吸收其中的部分成本,作为免费服务提供给用户。

除此之外,还有其它选择。以下列示一些创新的服务模式:

1、Paymail托管服务

2、SPV信道托管服务(可以由Paymail服务商提供)

3、提供Merkle证明的服务(Merkle证明并不是必须要由打包该交易入块的矿工提供)

4、“双花”通知服务(这可以由任何一个或多个矿工为你提供监控服务)

观察Bitcoin SV生态系统将如何发展,以及哪些企业会开始提供这些服务,是一件很有趣的事情。

假设出于某种原因,你想从4个不同的服务商那里分别请求其提供以上的4种服务,它们都将基于同一笔交易提供对应的服务,这时就非常适合将纳米支付输出(Nano-payment Output)应用在该交易中了。只需向每个服务商支付1至10聪便可以享受他们提供的一次性服务,且无需被这些服务商暗中绑定,这将极大地刺激服务商们提供出更优的服务。

未来的SPV信道

今天初次发布的SPV信道提供出了一个基本框架,目前只对桌面版进行了优化。我们近期高优先级的任务是开发出移动客户端,从而能够利用iOS和Android设备的推送功能实现SPV信道服务。我们还需要进一步与Paymail集成,当然还要实施横向扩展。我们已经看到了行业里对信道+Paymail综合托管服务的需求很迫切,并期待着第一个提供这种服务的公司出现。

未来的SPV工作流

在我们今天介绍的内容中,我们对此前阻碍SPV的问题提出了解决方案,并完善了SPV工作流。这其中许多解决方案都可以改进和优化,但是现在使用已有的这些组件就可以可以实现端到端的应用了。我们希望Bitcoin SV的业务运营商能够就整个SPV工作流程进行广泛探讨,提出并采纳可行的调整方案或完全的替代方案。不过就目前来说, 我们已经有了一个基础,能让用户导向产品的开发者以此作为起点,他们现在就可以在此之上开始构建应用了。

Articles-zh