真正的点对点交易在如今的比特币SV上仍然很少见，尽管它在将近12年前撰写的白皮书的标题中出现过。

[caption id="attachment_262019" align="aligncenter" width="624"] 来源： BitcoinSV.io[/caption]

如今，几乎所有应用程序都采用以下方式处理交易：

用户 =>“全节点”=> 矿工 => 应用程序

1. 用户将交易发送到某个所谓的“全节点”（可能在某个大型高科技企业集团的云服务器上运行）
2. “全节点”（如果配置正确）将交易转发给矿工（这是它们唯一能做的事情）
3. 矿工将用户的交易排队，以便放入下一个区块，这就是所谓的“零确认交易”
4. 应用程序询问其他“全节点”，或者更糟的是，询问它们自己的“全节点”，然后再最终解释交易并在其平台上呈现数据

这种方法的效率极低，并且依赖于两个潜在的故障点。

更合理、更简单的方法如下：

用户 => 应用程序 => 矿工

1. 用户直接将交易发送到应用程序
2. 应用程序直接向矿工广播交易
3. 矿工将交易排队以便放入下一个区块

在下面带有时间戳的链接中，克雷格·怀特（Craig Wright）澄清了“点对点”的真正含义，并阐述了长期以来这个词是如何被误解的。这种误解导致所实现的应用程序无法随网络一起扩展。

[caption id="attachment_262014" align="aligncenter" width="624"] 来源：YouTube[/caption]

&t=1003

BTC Core从一开始就在推动一种错误的说法，称个人需要运行自己的节点，这甚至导致了那些在比特币SV上构建应用程序的人仅凭一己之力去做开发。此外，由于扩容的失败，使得这种架构得以继续存在，也让应用程序开发人员满足于这种次优环境。

即使在实施创世升级后，我们仍然不具备能够让我们充分利用新网络特性的强大工具，因此这种扩容需求尚不明显。

[caption id="attachment_262011" align="aligncenter" width="593"] 来源： Twetch[/caption]

不过，扩容也可能会突然发生，考虑到EHR项目在上个月CoinGeek伦敦会议上的宣布，应用程序需要随时做好准备。

那些仍然基于低效率架构的应用程序很可能会在一夜之间变得过时和无法使用。

P2P交易还能为服务提供商带来更好的用户体验和更精简的应用程序开发。例如，Twetch SDK/API就实现了这种方法。用户只需向Twetch的服务器发送一个简单的HTTP请求，Twetch便会代表用户广播其交易。

通过这种方法，Twetch可以即时在站点上显示来自交易的数据，而无需执行额外的询问和处理操作，从而降低风险和复杂性，实现更快的速度。此外，Twetch现在可以在内容发送到网络之前进行审核，而不是接受网络认为有效的内容。

还有很多其他令人关注的应用场景也能得益于这种方法变成现实，读者们不妨尽情发挥想象！

针对这种方法，一些人反驳的论点是，为什么？既然服务在交易发送到网络之前就接受它们，那为什么还要发送它们呢？这与如今的应用程序又有什么不同？

其实，采用这种方法的一个原因是提供冗余，例如，由于数据都存储在账本中，用户可以很容易地从账本中获取Twetch客户端应用程序。

另一个原因是确保应用程序的互操作性，这个概念已经讨论过，但在比特币SV上尚未完全实现。由于数据可以写入公共账本，现在，其他应用程序也可以在他们的平台上解释和使用这些数据。在这方面，一个简单但有说服力的例子就是unwriter的Bitpic。

[caption id="attachment_262008" align="aligncenter" width="624"] 来源： Bitpic[/caption]

仔细想想就会发现，在我们使用的每一款社交媒体应用程序中都上传头像是一种相当愚蠢的做法。我们为什么不能只上传一次，然后让其他应用程序引用这张图片呢？

Baemail就使用了Bitpic来获取其用户的头像。这既节省了用户的时间，又降低了服务提供商的总成本、开发时间和风险，因为大部分工作已经由另一个提供商完成。发现其中的趋势了吗？

[caption id="attachment_262005" align="aligncenter" width="624"] 来源： Baemail[/caption]

为了充分发挥比特币SV网络的潜力，应用程序必须实现点对点交易。它带来的优势很明显，成本节约也显而易见，合作的机会更是无可限量。