比特币的设计初衷从来就不是为了抵御审查

本文首次发表于克雷格·怀特博士(Dr. Craig Wright)的博客,https://craigwright.net/

您永远都不会发现我在以中本聪的身份发表的声明中,有提到过比特币是专为‘抵御审查制度’而设计的。没有提到它的原因很简单:这不是我设计比特币的初衷。不幸的是,包括电子前沿基金会(EFF)在内的几个虚伪的跳梁小丑,干脆自作主张改变了我原本的说法。最近,BTC Core系统的开发人员开始要求进行更加彻底的变革——使这个系统与比特币系统的差异越来越大。Jonas Schnelli试图利用BIP 324,实现传输层加密,传输层的设计目的在于隐藏交易信息,不让执法部门和其他试图监控比特币交易的系统发现。

出于同样的目的,与BTC Core相关的媒体团队正在继续散播并进行虚假宣传。《比特币杂志》的作者Tony Sanak在一篇关于BIP 324的文章中,写道:

“比特币:一种点对点的电子现金系统”是《比特币白皮书》的标题,正如标题所言,P2P层是比特币网络的主要组成部分之一, 但它也是一个显著低效并遭到现有的理论攻击的系统。

这篇文章进行了错误的类比,它将比特币与Napster进行了比较,这才使得他们的错误说法能够自圆其说。

就像其他系统的开发者团体试图助长犯罪活动一样(以前的Napster网络就是这种情况),BTC Core团体试图掩盖他们系统中的犯罪活动。为此,他们不得不逐步改变BTC Core协议,并尽量远离他们已复制的比特币协议(现指BSV协议),越远越好。这是因为,他们想要试图将BTC Core冒充为比特币,从事欺诈活动。然而,比特币的核心协议是有很强的弹性的。无论开发者团体多么积极地试图更改复制的比特币协议,他们都无法删除比特币的主要功能。因此,BTC Core将保持分层结构,系统的节点将始终受到法律的约束。

在文章中,又有一处试图欺骗读者的部分,作者接着说:“在理想的配置中,P2P网络不应该有任何层级结构(所有节点都是平等的),节点应该均匀地分担网络负载”。当然,比特币系统并不是这样设计的。更重要的是,作者试图误导文章的缺乏相关技术知识的读者,让他们相信不挖区块的“节点”也是节点。我的《比特币白皮书》第5节中有着对于节点的定义的详细清晰的说明。

1. 新的交易消息会被广播至所有的节点。

2. 每个节点将新交易收集到一个区块中。

3. 每个节点都努力为自己的区块寻找一个有难度的工作量证明。

4. 当一个节点找到工作量证明时,它需将该区块广播给所有的节点。

5. 只有当区块中的所有交易都有效且尚未被花费时,节点才会接受该区块。

6. 节点通过努力创建区块链中的下一个区块来表达它们已接受了新区块,同时将被接受的新区块的哈希值用作前一个哈希值。

比特币系统内唯一的共识机制在于,通过竞争方式创建并分配经过验证的交易区块。任何不创建区块的系统都不会对网络产生影响。比特币被设计成一个小世界系统(small-world system),它不是一个网状结构。如果我们有两个不直接相连的节点A和节点B,需记住,每个节点都具有高度连结性,虽然有些节点(也就是矿工)彼此间不相连,但其自身却拥有上千条连接(或网络边缘)。换句话说,在极少数情况下,节点A和B没有直接连接(如图1所示),它们之间不会只有一条连接路径,而是会有很多路径通过网络相互连接。就算我们假设A和B之间的红色结点试图阻止交易,也总会有其他交易出现,从而让节点A将交易传递到节点B。 在图1中,一小部分节点子集向节点A提供直接和同步的通信,并连接到节点B。

图1:节点A和B并不直接相连。

如果图1中红色的节点试图抵制交易,也不会产生任何影响,这些红色结点好像不存在一样,交易会继续向其他节点进行传播。这种状态与上述网络图中的状态一样:红色节点只负责验证区块而不创建区块。如果一个实体不创建区块,那么它是无关紧要的,这不能算作是一个节点。需要记住,比特币系统中唯一的共识机制在于创建经过验证的区块。如果不通过交易创建区块,你是无法阻止交易发生或区块创建的。所以,有关比特币系统上“验证节点”的整个概念都大错特错。

图2中更准确地展示了节点的连接方式。对于任何一个节点来说,想要不与其他节点连接是不太可能的。在使其成为节点的这一过程中,对于该投资,一般来说这都会包含构建充足的网络映射,这样才能确保它够通知到所有其他节点。比特币中哈希函数的功能产生了一种去匿名化协议。任何重要的节点都会被激励,以使其区块和交易尽可能快地分发到所有其他节点。这样的系统只关心其他节点的情况,这个节点所有者并不关心所谓的“验证系统”。

 

 

图2:节点A和B相连。

在图2,也就是代表了比特币网络中的一个子集的图像中,根据我在《比特币白皮书》中第5节的规定,我们将绿色节点表示为节点,红色实体是BTC Core社区中很多人喜欢称之为的“验证节点”,我们看到红色系统完全与绿色节点不相关。无论哪个“验证节点”试图说明某笔交易无效,所有节点(也就是矿工)之间都存在一条路径。实际上,所谓的“验证节点”无法采取任何行动与比特币网络产生任何关联。

所以,圈内关于路由攻击和劫持比特币的说法是没有道理的。更关键的是,由于比特币没有被加密而可以被劫持的说法是错误的。最初的比特币系统源代码中的README文件包含以下内容:

比特币不使用任何加密技术。如果你不想完全构建OpenSSL以排除加密过程,则需要一些补丁程序。(OpenSSL v0.9.8h)。

比特币被设计成未被加密的。比特币被设计成作为一个明文系统运行。

在有关BIP 324的文章中,其作者写道:

在理想的配置中,P2P网络不应该有任何层级结构(所有节点都是平等的),并且节点应该统一分担网络负载。这个由网状互联节点组成的基础层可以帮助比特币抵抗审查制度。

这种说法的问题在于,比特币系统不是一种网状结构,比特币的设计也不是为了“抵抗审查制度”。

更关键的是,比特币从来就没有被设计成一个没有层级结构的扁平网络。比特币有意设计,让节点之间能够相互竞争,因此节点之间是不平等的。当我发布比特币时,我已经相当清楚地解释了该系统的本质(着重强调):

1. 一开始,大多数用户都可以运行网络节点,但当网络发展到一定程度后,会有越来越多的空间留给拥有专业硬件服务器集群的专家。— 2008年(网址

2. 在均衡的规模下,许多节点将会是具有一个或两个网络节点的服务器集群,这些网络节点通过局域网向群组的其他节点提供服务。— 2010年(网址

3. 该设计支持让用户只做用户。运行一个节点的负担越重,节点就会越少。这几个节点将是大型服务器群。其余的将是仅执行交易而不会生成区块的客户端节点。— 2010年(网址

比特币在被设计时,结合了针对用户的简易支付验证(SPV)并且包含了作为节点来收费获利的能力。比特币系统在其基础级别上是分层的。节点竞相创建验证交易的区块。在它们的区块中,它们试图包含尽可能多的交易。另外,在2008年,我曾说过比特币在同年已经可以扩容至Visa的水平。以平均每天144个区块和100GB的交易量计算,2008年交易区块的平均大小可达到695MB。其次,交易的分配不会是均匀的。Visa网络中的交易分配遵循帕累托原理,因此,我们可以计算出,节点必须能够处理高达11GB的区块。在任何特定时间段内,一个节点将必须处理最重要的可能出现的区块大小这种情况。这样做是符合节点的利益的,因为较大的区块会带来更多的费用。处理包含费用最多的区块的节点获得的利润最大。节点的分层分布是我创建比特币时的设计。我所展示的分层结构,甚至到现在仍然是被遵循的。

2008年,当我解释比特币可以扩容时,我特别指出

早在网络规模变得这么大之前,用户就可以安全地使用简易支付验证SPV(第8节)来检查是否存在双花,这只需要拥有包含区块头的链条,或者说每天大约12KB的数据就可以了。

如果比特币系统被设计成保持较小规模而不是可以扩容的,那么就不需要二叉树或Merkle树结构。这样的结构会使上述比特币系统的效率降低。白皮书第4节中提出的不使用Merkle树进行交易排序的模型会更安全,这需要进行的处理更少,因此在区块规模小于32MB时的效率会更高。因此,比特币系统不是为扩容而设计的说法很容易被否定的。我始终表示,比特币系统是被设计成可扩容的,我始终说它最终会在服务器集群(或数据中心)中运行。

幸运的是,通过诸如BIP 324提出的“隐私”解决方案都不会奏效。在比特币系统中达成共识的唯一方式是创建区块。对于任何规模较大的节点来说,如果其节点的运营者试图隐藏其连接性,它都会损失大量的投资金额。这样做会限制他们广播区块进而获利的能力。在这里,工作量证明机制被用于联合节点并且取消匿名节点。在比特币系统中,节点并非被设计成私有的,只有用户才是。重要的是,隐私不等同于匿名。

202024日的“创世”协议升级是比特币历史上的一大里程碑,将见证BSV最大程度地回归到中本聪原先设想的协议。请访问“创世”硬分叉页面以了解更多信息。

要直接在您的收件箱接获CoinGeek.com最新消息,CoinGeek会议特别优惠以及其他内部信息,请加入我们的邮件列表

[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]