第 8 章 · Bitcoin、Ethereum、Solana 为什么不一样
除了 TPS,还能怎样比较两条链?
- 练习的能力
- Protocol LiteracySystem Thinking
- 动手
- 查三条链各自的出块时间、最终性时间、节点数与运行节点的硬件要求,做成一张表。
- AI Lab
- 让 AI 生成三条链的对比表,逐项去官方文档核对,把错误的数字标出来。
一个现实问题
你在社交平台上刷到两张图。
第一张说:A 链每秒能处理几万笔交易,B 链每秒只有十几笔,所以 A 链完胜。第二张来自另一拨人:B 链已经安全运行了十几年,从没被攻破过,A 链停过好几次机。
两张图用的都是真实数据,结论完全相反。
更让人困惑的是现实:全世界规模最大的那些链上资产,很多年来一直待在那条「慢」的链上。 如果快就是好,这件事说不通。
于是你会遇到一个每个刚入行的人都会遇到的处境:有人问你「哪条链更好」,你知道答案不该是「看 TPS」,但你说不出该看什么。
这一章要给你的不是答案,是一套问法。
思想实验
忘掉所有链的名字。假设你要从零设计一个全世界共用的记账房间。
房间里的规矩由你定,但你只能调四个旋钮:
- 谁有资格记账:所有人,还是经过挑选的一批人?
- 记账的人需要多好的设备:一台旧笔记本,还是一台专业服务器加一条极好的网络?
- 一条记录多久算数:写下去就算,还是要等所有人都确认过?
- 一条记录能有多复杂:只能记「谁给了谁多少钱」,还是能记任意一段程序的运行结果?
你会很快发现,这四个旋钮是互相咬合的:
- 把设备要求调高 → 房间处理得更快,但买得起设备的人变少,最后可能只剩几十家机构在记账。
- 把记录复杂度调高 → 能做的事变多,但每条记录要花的时间变长,要么更慢,要么又得把设备要求调高。
- 把算数速度调快 → 用户体验变好,但留给大家核对的时间变短,参与者之间的网络必须极好,慢的人被淘汰。
- 把记账资格放开给所有人 → 谁也拦不住你参与,但必须迁就最慢的那一批人。
再往下推一步,你会碰到一个更根本的问题:什么叫「这个房间很安全」?
它的意思不是密码学没被破解。它的意思是:想篡改一条已经写下的记录,攻击者要付出多大代价。 而这个代价来自参与记账的人愿意投入多少资源——他们投入得越多,改写历史越贵。
所以第五个旋钮其实是被前四个决定的:你为安全准备了多大的预算。
现在你手上有了四个能调的旋钮,和一个被它们决定的结果。没有一组设定能让所有旋钮同时调到最大。
你来决定
有三件事要放进房间。你可以为每件事选一个房间,也可以都放同一个。
- 甲:一笔十年不打算动的大额储蓄。
- 乙:一个游戏,玩家每秒都在产生小额操作,单笔价值很低。
- 丙:一套管理着巨额资金的借贷规则,任何一次故障都可能让很多人亏钱。
观察结果
四个选择放在一起,会看到同一件事:
没有一种设定能在三种用途上同时最优。 甲要的是十年不出事,乙要的是便宜和即时,丙要的是永不停机加规则可靠。这三组要求互相冲突。
所以「哪条链更好」这个问题本身就是坏问题。能回答的问题只有一个:给定这个用途,哪条链的取舍更合适。
但在比较之前,还有一件更麻烦的事要先解决:同一个词在不同的链上意思不一样。
| 这个词 | 看起来在说 | 实际可能是 |
|---|---|---|
| 每秒交易数 | 这条链的真实处理能力 | 理论上限、实验室数据,还是过去 30 天的实际中位数?一笔转账和一次复杂合约调用算不算同一笔? |
| 确认时间 | 我的钱多久算到账 | 是「上了一个区块」,还是「再也不会被回滚」?这两者在有的链上差几秒,在有的链上差几十分钟 |
| 节点数 | 有多少人在维护这条链 | 是所有能下载数据的节点,还是真正参与出块与投票的那一批?两个数字经常差一个数量级 |
| 去中心化 | 一个可以打分的指标 | 至少包含四件不同的事:谁能出块、谁能改协议、谁在运行节点、这些人分布在哪里 |
这张表是本章最实用的部分。在统一口径之前,任何跨链对比都不成立。
这也解释了开头那两张图为什么能用真实数据得出相反结论——它们各自选了对自己有利的口径,而且都没有把口径写出来。
建立模型
用六个维度代替一张排行榜。每个维度都要问两件事:它在问什么,以及把它调高要付出什么。
| 维度 | 它在问什么 | 调高它的代价 |
|---|---|---|
| 安全 | 想改写一条已确认的记录,攻击者要付多少钱?这笔预算从哪里来? | 需要持续的真实投入,最终由用户的手续费或代币增发买单 |
| 执行 | 这条链能表达多复杂的规则?单位时间能跑多少? | 更复杂、更快,意味着参与者的硬件与网络要求更高 |
| 状态 | 链上要长期保存的数据有多大?增长速度多快?谁为长期存储付钱? | 状态越大,新参与者加入越难,长期看会削弱去中心化 |
| 延迟 | 从发出到上块要多久?从上块到「再也不会被回滚」要多久? | 追求低延迟会压缩验证与传播的余量,对网络质量提出更高要求 |
| 去中心化 | 谁能出块?谁能改协议?出块者与节点分布在哪里? | 参与者越多越分散,协调越慢,性能上限越低 |
| 硬件门槛 | 跑一个全节点需要什么配置?一个普通人能不能跑? | 门槛越低,能力上限越低;门槛越高,链的命运越掌握在少数人手里 |
第六个维度值得单独强调一次。硬件门槛是前五个维度的现实约束,也是最容易被跳过的一项:一条链如果只有专业机房能参与验证,那么「任何人都能独立核对」这句话在实践中就不成立了,而这恰恰是第 3 章说的那个核心价值。
再给一条把六个维度串起来的思路:
- 先问用途
- 按用途给六个维度排优先级
- 统一口径
- 逐项取数并标注时间
- 给出判断并写明不确定的地方
你可能听过「区块链不可能三角」这个说法——去中心化、安全、可扩展三者不可兼得。它不算错,但它太粗了:三个词里有两个是复合概念,不能直接比较。六个维度的好处是每一项都能对应到具体的可查数据。
最后一句话,是本章想让你带走的判断标准:
链之间的差异是一组取舍,不是一张排行榜。
一条链在某个维度上「差」,通常是因为它把预算花在了别的维度上。问清楚它换来了什么,比记住它的排名有用得多。
它叫什么
在链的语境里,安全指的是改写已确认历史的成本,不是指代码没有漏洞。
它由两部分构成:保护这条链的人投入了多少资源,以及这些资源有多分散。前者决定攻击要花多少钱,后者决定攻击者能不能通过收买少数人绕开这笔钱。
安全预算最终来自真实收入(手续费)或者代币增发。靠增发撑起来的安全,本质上是持有人在付账。
链按规则计算出新状态的那一部分能力:能表达多复杂的逻辑、单位时间能处理多少。
比较执行能力时,一定要先问口径:理论峰值、压测数据、还是真实的持续中位数? 三个数字可以差一个数量级,而公开传播的往往是第一个。
链当前必须保存、并且每个验证者都要能访问的全部数据:每个地址的余额、每个合约的存储内容。
状态和历史记录不是一回事。历史可以归档,状态必须随时可读。 状态持续增长会让新参与者加入的门槛越来越高,这是一个慢性问题,通常要几年才显现,但一旦显现就很难逆转。
从你发出交易到它算数之间的时间。
它至少要拆成两段来看:上块时间(交易被打包进一个区块)和最终性时间(这个区块再也不会被回滚)。第 6 章讲过,后者不是一个瞬间,而是一个逐渐增强的概率。
有的链这两个数字很接近,有的链差得很远。只报第一个数字的对比表,看看就好。
它不是一个数字,至少要分成四问:谁能出块?谁能修改协议?谁在运行独立节点?这些人在地理和司法管辖上怎么分布?
一条链可以在第一问上很分散,在第二问上很集中——几个核心开发者和一个基金会说了算。这种情况非常常见,而且很少出现在对比表里。
去中心化本身不是目的,它是为了让「没有人能改这条记录」这句话真的成立。第 9 章会讲合约层面的同一个问题。
动手
这是你的第一件阶段作品。不要抄任何现成的对比表——这一阶段的导读里已经提醒过:广为流传的数字里有相当一部分是错的或者过期的。
选三条链。 建议选取舍差别明显的三条,比如一条以安全与简单为先的、一条以可编程性为先的、一条以低延迟为先的。
先写口径,再取数。 在表格上方写清楚你的四条口径:
- 「出块时间」指的是目标值还是最近一段时间的实测中位数?
- 「最终性」指的是哪一种确认标准?
- 「节点数」数的是哪一类节点?数据来自哪个页面?
- 「硬件要求」用的是官方推荐配置还是最低配置?
这一步比填表更重要。 口径不写清楚,你的表和网上那些图没有区别。
逐项取数,每一项都记下来源链接和查询时间。
| 链 A | 链 B | 链 C | |
|---|---|---|---|
| 出块时间 | |||
| 最终性时间 | |||
| 参与出块或投票的节点数 | |||
| 可独立验证的节点数 | |||
| 官方推荐硬件配置 | |||
| 历史上有没有停机 | |||
| 协议升级由谁决定 |
最后两行是大多数对比表都没有的,而它们往往比前面几行更能说明问题。
标出你查不到的格子。 有些数据官方就是不提供,或者只提供一个含糊的说法。
查不到就写「未找到」,不要用别人的二手数字填上。 空着的格子本身就是一个发现:它告诉你这条链在哪方面不够透明。
给出三句判断。 用这张表回答三个问题:
- 这三条链各自把预算花在了哪个维度上?
- 如果要放一笔十年不动的资产,你选哪条,为什么?
- 如果要做一个高频小额的应用,你选哪条,为什么?
做完之后把这张表存好。三个月后再取一次数,你会直观地看到哪些数字会变、哪些不会。 这个对比本身就是这一章最有价值的收获。
AI Lab
先让 AI 做一遍:
对比三条区块链,输出一张表,包含以下字段:
- 出块时间(写明是目标值还是实测中位数)
- 最终性时间(写明用的是哪一种确认标准)
- 参与出块或投票的节点数量
- 可独立运行验证的节点数量
- 运行一个全节点的官方推荐硬件配置
- 历史上发生过的停机或重组事件
- 协议升级的决策流程与决定者
规则:
1. 每一个数字后面必须附上来源链接和数据日期
2. 查不到的字段写「未找到」,不要估算,不要用常识补齐
3. 如果不同来源的数字冲突,把冲突列出来,不要自己选一个然后做这个 Lab 真正的部分:打开每一个链接,逐项核对。
把结果记成第二张表:它给的多少项能在官方文档里核实、多少项数字对但时间点不对、多少项链接打不开、多少项它直接编了一个看起来合理的数。
这一步的目的不是难为模型。你要建立的是一个校准过的直觉:在这类问题上,模型的哪一部分输出可以直接用,哪一部分必须自己查。
经验上最容易出问题的三处是:把理论峰值当成实际吞吐、把「上块」当成「最终性」、以及给出一个格式完全正确但并不存在的文档链接。
如果你在第 1 章开始记那份「模型常见错误清单」,这一章会给它添上好几条。
AI 说完之后,你必须自己验证
- 每一个数字,你能不能在它给的链接里找到对应的原文
- 它有没有把「出块时间」和「最终性时间」混成一项
- 它报的节点数,数的是哪一类节点,有没有写清口径
- 它给的硬件要求,是最低配置还是推荐配置,来源是不是官方文档
- 它引用的数据是哪一天的,有没有把不同时间点的数字并排放进同一张表
- 它有没有给出「协议升级由谁决定」这一行,这一项几乎总是被漏掉
- 它给的链接是不是真的能打开,而且真的支持它的说法
真实案例
一部分人主张把区块调大以降低手续费、容纳更多交易;另一部分人认为这会抬高运行节点的门槛,长期削弱「任何人都能独立验证」这个前提。
争论持续了两年多,最终以链的分裂收场。
这件事的价值不在于谁对谁错,而在于它把本章的取舍摆到了台面上:区块大小不是一个技术参数,它是在「便宜」和「谁能参与」之间做选择。 第 7 章的最后一个变量、第 11 章的整章,都是这场争论的延续。
有的链在设计上把延迟和吞吐放在第一优先级。代价在压力时期显现出来:交易洪峰导致验证者之间无法达成一致,整条链停止出块数小时,需要协调重启。
这类事件说明了一个常被忽略的点:可用性和吞吐不是一回事。 一条平时很快、偶尔完全不可用的链,对某些用途(比如清算)比一条一直不快但从不停的链更危险。
同样重要的是后续:这些链随后做了大量工程改进。用两年前的事故评价今天的一条链,和用理论峰值评价它一样不可靠。
可编程的链上,每个新合约、每个新地址都会往状态里添东西,而状态是每个验证者都要能随时访问的那部分数据。
它不会在某一天爆掉,但它会让新参与者加入的成本逐年上升。很多链因此在讨论各种机制:让长期不用的数据过期、对占用状态收取持续费用、或者把历史交给专门的存档节点。
这是一个需要用年来观察的维度,所以它几乎从不出现在对比图里。但对一条准备存在十年的链,它比 TPS 重要得多。
一条主要的链把维护共识的方式从消耗算力改成了质押资产,能耗下降了几个数量级。
对本章来说,关键在于这次改动重写了它的六个维度里的好几项:安全预算的来源变了(从电费和矿机变成了被锁定的资产),参与门槛变了,最终性的定义也变了。
同一条链在不同时期是不同的取舍组合。 这是为什么本章反复要求你给每个数字标注时间。
改一个变量
执行能力和吞吐会明显上升,用户体验变好。
代价是能独立验证的人数下降,最终可能只剩下机构和专业运营方。一旦到了这一步,「不需要信任任何人」就退化成了「需要信任这一小撮人不会串通」。
它仍然可以是一个合理的选择,但你必须知道自己换掉了什么。
支付和交易体验会接近传统系统,这是一个真实的巨大改进。
代价通常藏在两个地方:参与者之间需要更好的网络和更强的协调,因此参与集合会收紧;以及在极端网络状况下,「这么快就确定了」的那个结论更容易被推翻,也就是链停摆或回滚的概率上升。
速度的代价往往不是平时显现,而是在最糟的那一天显现。
状态增长的问题被直接定价了:占着不用的数据会被清掉或者要持续付钱。
好处是节点的长期负担可控,新参与者进来更容易。代价是开发者的心智负担大增——任何一份数据都可能在你不注意的时候消失,所有依赖长期存储的应用都要重新设计。
这是一个很多链讨论过、但很少有链真正全面实施的方案。想想为什么。
去中心化的第一问改善了:更难通过收买少数人来改写历史。
但协调成本随之上升:每一轮要收集和传播的消息变多,达成一致更慢,性能上限下降。同时,参与者多不等于分散——如果他们都跑在同一家云服务商的同一个区域,数量再多也挡不住同时掉线。
数节点的数量很容易,看清它们的分布才是功课。
带走的问题
这一章给了这个问题一个更锋利的版本:你需要的是哪一种链?
如果你的应用不需要十年不可篡改、只需要便宜和快,那么它未必需要今天最安全的那条链,甚至未必需要链。把用途想清楚,比比较链更早一步。
六个维度的优先级,完全由用户决定。
一个跨境结算的用户最在意最终性和抗审查;一个游戏玩家最在意延迟和成本;一个机构最在意停机记录和合规接口。说不清用户是谁,就排不出维度的优先级。
链停摆时,风险由谁承担?答案通常是:当时有未平仓位、正在清算、或者正要提款的那些人。
平时六个维度看起来只是参数,出事那天它们会精确地决定谁亏钱。第 24 章会把这件事列进统一风险模型。
这一问在这里有一个非常直接的答案:链的安全预算和它的代币价格绑在一起。
价格归零意味着保护它的人拿不到报酬,攻击它的成本随之下降。这条链未必立刻停,但它「不可篡改」这个卖点会先失效。判断一条新链时,这是必须问的一条。
本章自测
三个原因,任何一个都足够:
- 口径不统一。 理论峰值、压测值、实测中位数是三个不同的数,公开传播的通常是最大的那个。
- 交易不等价。 一笔简单转账和一次复杂合约调用占用的资源差很远,按「笔」计数会奖励那些交易更简单的链。
- 它只覆盖六个维度里的一个。 一条链在吞吐上领先,往往是因为它在硬件门槛或去中心化上做了让步。
正确的问法不是「谁更快」,而是「它为了快,换掉了什么」。
指改写已确认历史的成本,而不是指代码没有漏洞。
它由两件事决定:保护这条链的人投入了多少资源,以及这些资源有多分散。资源不够,攻击便宜;资源集中,攻击者可以绕过资源直接收买少数人。
顺带记住一件事:这笔安全预算最终有人在付。要么来自用户的手续费,要么来自代币增发——后者意味着现有持有人在被稀释。
上块只说明你的交易被打包进了某个区块,这个区块在某些情况下还可能被替换掉。最终性指的是它再也不会被回滚。
对小额日常支付,上块通常就够了。对大额转账、跨链和交易所充值,等到最终性才安全——这也是为什么交易所对不同链设置了不同的确认数要求。
第 6 章讲过:最终性不是一个瞬间,而是一个逐步增强的概率。不同的链让这个概率上升的速度差别很大。
不一定。至少要再问三件事:
- 这些节点里有多少真正参与出块和投票?只能同步数据的节点不决定共识。
- 它们跑在哪里?如果集中在少数几家云服务商的少数区域,数量再多也可能同时掉线或同时被要求配合。
- 协议升级由谁决定?出块可以很分散,而改规则的权力可以很集中。这一项在对比表里几乎永远缺席。
没有标准答案,但检查你的回答有没有这几件事:
- 你有没有先问用途,再决定维度的优先级?
- 你有没有在取数之前先定口径?
- 你有没有查「协议升级由谁决定」和「有没有停机记录」这两项?
- 你有没有给每个数字标注来源和时间?
- 你有没有诚实地留下「未找到」的格子?
最后一条最容易被跳过,而它恰恰是研究和复述之间的分界线。第 25 章会把这套动作正式化成一个 30 分钟的流程。
一句话带走
链之间的差异是一组取舍,不是一张排行榜。