查看原文
其他

多数人只知中本聪创造了比特币,他的这些帖子却鲜为人知

五火球教主 白话区块链 2020-12-18

每次谈到 BTC、BCH、BSV 的时候,很多人会对后两者不屑一顾,理由是:分叉币凭什么来争“比特币”这个名号?

另一些人则质疑称:忒修斯之船,一路修修补补,船上的每一块木板都换掉之后,这艘船还是出发时的那艘船吗?BTC 在 Core 接手后被一点点修改,还是中本聪所设想的 BTC 吗?

今天,我们先抛开三者理念之争,就单单只说“比特币”这三个字。

让人吃惊的是,绝大多数投资者,甚至包括很多比特币的“信仰者”,并未读过比特币白皮书,更不用提中本聪早期在 Bitcointalk 论坛上发表的那些帖子。由此,很多人对比特币或是中本聪产生了许多错误或是偏离的印象,比如网上不少文章里提到“中本聪完全没有预料到 ASIC 矿机的诞生”。

当然,中本聪最开始的设计,有很多错误之处,需要被后人不断地修正。但不管怎么说,我们至少得先知道中本聪最开始是怎么想的。

中本聪所设想的核心部分都在比特币白皮书里,本文主要介绍他早期在 Bitcointalk 论坛上的重要发言。


 01 
全节点的问题

这可能是导致 BTC 与 BCH、BSV 分家的根本原因,大区块更多的是一个表象,更深层的是谁可以运行全节点的问题。

帖子大意如下:

“每个用户都是网络节点的当前系统并不是规模扩大之后的标配,这就像每个 Usenet 用户运行自己的 NNTP 服务器一样不可取。该设计支持让用户成为用户,运行节点的负担越多,节点就越少。最终的节点们将是大型服务器集群,其余的将是仅执行事务而不生成的客户端节点。”

然后帖子下面,有人问(这个人就是现在的 EOS 创世人 BM):“聪哥,你这个验证付款十分钟也太长了吧?这玩意得跟今天刷信用卡一样快才行啊!”

聪哥霸气地回复道:去看我的“小吃机”贴,我概述了付款处理器如何能够在 10 秒或更短的时间内就足够好地、实际上非常好地(比信用卡低得多的欺诈率)验证付款。(“小吃机”贴我们下文再说)

“如果你不信我或是理解不了,哥没有时间说服你,不好意思。”

后来,BM 又回了个贴,表示“认怂”:

其实我完全相信你,并且看了你的帖子后也得出了和你一样的结论,我在发表之前的回复后就去看了那篇关于 Snackmachine 的帖子。


 02 
ASIC 矿机与 SPV

这其实是上一个问题的延续,中本聪可以说是设计或者说推演出了 ASIC 的理念,却没有料到 ASIC 这么极端的矿机的出现。

帖子大意:

该设计概述了不需要完整区块链的轻客户端,它称为简化付款验证。轻客户端可以发送和接收交易,但不能出块。它不需要信任节点来验证付款,它仍然可以自己验证付款。轻客户端尚未实现,但计划是在需要的时候实现它。

现在,每个人都只运行一个完整的网络节点。我预计不会有超过 10 万个节点,可能更少。它将达到一个平衡,在该平衡下,更多节点无法加入。其余的将是轻客户端,这种客户端可能是数百万。在平衡大小下,许多节点将会是服务器集群,这些集群里一到两个主节点通过局域网跟其他的服务器相连。

所以说,中本聪没有预料到 ASIC 的诞生,也对,也不对。

严格意义上来讲,这种一台顶原先成千上万台 PC 或是服务器的 ASIC 实现形态,中本聪的确是没有料到。但这种比 CPU 或是 GPU 更加高效的算力集群,中本聪是想到并描述了的,其核心理念与现在的各大 ASIC 矿池本质上是一致的。

关于 SPV,中本聪还发过一个贴,大意如下:

不光是下载,主要是还得花很长时间来验证所有块中的所有签名。初始块下载通常需要多长时间?它是下一半的时候慢下来了还是全程速度都差不多?我已经想了检查链的更加简单粗暴的方法,可以一直检查到最后几千个块,但是很费时间,哥还有许多其他更重要的事儿需要处理。

简化的付款验证适用于仅进行交易,且不生成也不参与节点网络的轻量客户端专用用户,他们不需要下载块,只需下载哈希链,哈希链当前约为 2MB,验证速度非常快(验证整个链少于一秒钟)。如果网络变得非常庞大(例如超过 100,000 个节点),这就是我们将用来允许普通用户进行交易而无需成为完整节点的情况。在那个阶段,大多数用户应该开始仅仅运行 SPV 客户端软件,只有专业服务器池才能继续运行完整的网络节点,就像 Usenet 网络如何整合一样。

SPV 尚未实现,并且短期内都不会实现,但是当前所有实现都是围绕支持 SPV 而设计的。

比特币白皮书的第 8 部分就是关于 SPV 的简介,有兴趣的朋友可以自己去翻白皮书。

简单来说,SPV 是一种用户不运行全节点也可验证支付的技术手段,用户只需要保存所有的区块头就可以了。用户虽然不能自己验证交易,但如果能够从区块链的某处找到相符的交易,便知道网络已经认可了这笔交易,而且得到了网络的多少个确认,SPV 干的是“支付验证“,只判断用于“支付”的那笔交易是否已经被验证过,并得到了多少的算力保护(多少个区块确认数),而不是全节点的“交易验证”(涉及到验证是否有足够余额可供支出、是否存在双花、脚本能否通过等)。

目前,市面上的各种比特币“轻钱包”,大多借鉴了 SPV 的思想,但并非是真的 SPV 钱包,更多的是像一个区块链浏览器的前端再加上保存私钥去签名的功能,自己无法验证,需要连接其他的全节点,而不像 SPV 那样可以做到去中心化的独立验证。

BTC 因为坚持个人用户可以运行全节点,所以大概率不会开发 SPV,但对于 BCH 和 BSV 来说,SPV 则是一项极其重要的技术,所以相信不久的未来将会看到成熟的 SPV 版钱包的出现。


 03 
“小吃机”

这是一个关于比特币如何在极短时间内确认的问题,确认并不是 100% 完全确认且交易不可逆,而是“足够好”,好到比信用卡故障率还低就行。

“小吃机”源于一个人的发帖,说要是有一款比特币版的小吃机(无人售货机),会怎么工作?没有人愿意花一个小时等待交易被确认,“小吃机”公司也不想白给那么多免费的零食。

聪哥回复道:

我相信付款处理公司可以在 10 秒或更短的时间内,通过“足够好”的检查来提供快速的交易发布服务。

网络节点仅接受建议的的第一个版本,以将其合并到他们试图生成的块中。当你广播交易时,如果其他人同时广播了一个双花,这就变成一个比拼传播到最多节点的速度竞赛。只要有一方稍有领先,它就会以几何级别更快地网络传播,并获得大多数节点的认可。

粗略的示例:
1  0
4  1
16  4
64  16
80%  20%

因此,哪怕双花必须等一秒钟,那么它也将占据巨大的劣势。

支付处理器与许多节点都有连接。当它得到一笔交易时,它会将它迅速发出去,同时监视网络中是否有双花。如果它在其众多节点中的任何一个上收到双花,则它会警告该交易是错误的.......双花的交易就传播不了很远。双花者将不得不等待,直到侦听阶段结束。但是到那时,支付处理器的广播已到达大多数节点,或者在传播方面遥遥领先,以至于双花者没什么希望抢占到剩余的节点的大多数。

零确认在 BCH 和 BSV 上也是个被研究很多的问题,目前也依旧没有很多商家支持。虽然零确认从技术上说得通,但在绝大多数人心里,交易没有被确认的话就始终觉得不安全。BTC 基本上不太可能走这条技术路线,毕竟零确认和闪电网络完全不是一个路数。


 04 
比特币的未来:20 年后是什么样?

有关比特币的未来,中本聪在多个帖子里给出了他的设想,以下仅摘录部分:

比特币的性质是这样的,一旦 0.1 版本发布,核心设计在其整个生命周期中都是一成不变的。因此,我想设计它以支持我能想到的每种可能的交易类型。问题是,每件事都需要特殊的支持代码和数据字段,无论是否使用,并且一次只涉及一个特殊情况,这将是一个特殊情况的爆炸,解决方案是脚本……

付款接收方在脚本上进行模板匹配。目前,接收方只接受两个模板:直接付款和比特币地址。未来版本可以为更多事务类型添加模板,运行该版本或更高版本的节点将能够接收它们……

该设计支持我多年前设计的各种可能的事务类型:托管交易、保税合同、第三方仲裁、多方签名等。如果比特币大量涌入,这些是我们将来要探索的东西,但它们都必须在开始时设计确保以后可以使用。

相信大多数人对这一句并不陌生:在几十年之后,当区块奖励几乎消失,交易手续费将会是节点的主要收入来源。我非常确信,在 20 年之后,链上交易数要么非常巨大,要么没有。

单就中本聪的设想来看,无论是托管交易,保税合同的支持,还是链上交易数量的设想,都可能与当前 BTC 走“电子黄金储值+闪电网络”的风格南辕北辙。

当然,正如文章一开头所说,中本聪的设想对还是不对,这是个见仁见智的事。本文更多的意义,是展示当年中本聪的一些设想, 支持与否则全凭个人理解。

毕竟,V 神最开始设想的以太坊是个世界计算机,结果一不留神发展成了发 Token 的机器,到现在又成了 DeFi 结算层,世界计算机的梦想早已偏离。

BM 最开始设想的 EOS 是企业操作系统(Enterprise Operation System,EOS 的全称),结果现在成了“菠菜”链,下一步会变成什么还不知道。

所以,从这个角度来讲,BTC 在中本聪眼里的确不是电子黄金,但发展发展着,就莫名其妙地成了“电子黄金”。

留言挖矿 第381期:你支持中本聪一开始的设计吗?你认为比特币未来要朝着什么方向发展?欢迎在留言区分享你的观点。

上一篇:区块链行业众生相:我是一名矿工,毕业4年,成了矿场主

推荐阅读

——End——

『声明:本文为作者独立观点,不代表白话区块链立场,亦不构成任何投资意见或建议,文章版权和最终解释权归白话区块链所有。』

亲,据说99.9%有品位的人都点了「好看」👇

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存