我们终于实现了中本聪对比特币“点对点”的愿景

“一种纯粹的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工作流程进行广泛探讨，提出并采纳可行的调整方案或完全的替代方案。不过就目前来说， 我们已经有了一个基础，能让用户导向产品的开发者以此作为起点，他们现在就可以在此之上开始构建应用了。

本文来自bitcoinsv.io

发布日期：2020年9月30日

本文首发于微信公众号：BA资讯。文章内容属作者个人观点，不代表和讯网立场。投资者据此操作，风险请自担。