Don't Trust, Verify

这篇文章试图讨论全节点对于区块链的意义。

角色

我们都知道,区块链网络中的节点有不同的角色。例如:

出块节点

出块节点负责打包交易,生产区块。出块节点在不同的地方有不同的名字,例如比特币和以太坊中的矿工/矿池,Bitshares的Delegator,EOS的Producer, Cardarno的Stakeholder,Tendermint和Casper中的Validator,以及CITA中的共识节点等等。 在这些网络中,出块节点的角色往往与全节点角色重合。最接近纯粹出块节点的例子应该是使用getblocktemplate协议参与挖矿的比特币矿机,他们不验证区块,但是拥有选择交易打包和封装完整区块的权力。

出块节点相对于其他节点往往需要付出更多的资源,包括算力(无论是用于PoW还是用于交易计算),磁盘,网络带宽等等。这些资源要求抬高了出块节点的门槛,容易造成出块节点分布的中心化。

全节点

区块链中的区块由两个部分组成,区块头和区块体。区块头中存放包括区块见证(例如工作量证明或是投票)在内的元数据,区块体中包含交易数据。区块的验证由此也可以分为两部分,对区块头的验证和对区块体的验证。对区块头的验证主要是出块权的检查,例如区块头中包含的工作量证明是否有效;对区块体的验证主要是对交易有效性的检查,确保区块体中每一笔交易都是有效的。

全节点同步交易和区块,对其进行验证,并转发有效的交易和区块。为了能够进行验证,全节点必须有完整的当前世界状态(例如UTXO集合)。由于全节点自行进行所有的验证,因此不需要信任其他第三方。

通常情况下,出块节点构造新区块时需要引用前一个有效区块,为了确认父块的有效性必须对其进行验证。此时出块节点也做了全节点的事情,也是一种全节点。这种角色上的重合不是必然的,不影响后面的讨论。

轻节点

轻节点与全节点不同:轻节点只同步和验证区块头,不会同步和验证区块体以及其中的交易。因此,轻节点只能验证区块头的有效性,无法验证该区块头对应的区块体中交易的有效性,只能相信构造这个区块的出块节点没有打包无效的交易,并且相信将这个看起来合理的区块头发送给自己的全节点对其进行了完整的检查。轻节点是信任其它节点的节点。由于不同步交易,轻节点也无法得知交易处理之后的世界状态,自然也无法验证交易双花或是世界状态的变更。轻节点的验证能力大大弱于全节点。

相信其它节点的好处是,轻节点的开销很小:区块头的体积只占区块的很小一部分,很容易同步和存储。因此轻节点可以运行在笔记本甚至手机等各种有限硬件环境中。

关系

这几种角色之间的关系是一个非常有意思的问题,也是我和朋友们常常会讨论的一个话题。在这样的讨论中,如果你拿出一支笔,请在场的任意一位朋友在白板上画出他心目中的这三种节点组成的区块链网络拓扑,大概率会得到类似这样的图:

图1. 朋友心中的节点拓扑A
图2. 朋友心中的节点拓扑B

在图1中,出块节点在最中心的位置,全节点围绕出块节点形成网络,轻节点连接在全节点上;在图2中,出块节点和全节点混合组成分布式网络位于中心,轻节点连接在全节点或者出块节点上。哪一副图更接近真实情况呢?

谁是守护者

人们通常认为出块节点是守护者(Keeper)一个区块链网络的守护者,这样的观点不无道理。毕竟是出块节点验证交易,生产新的区块,为用户提供服务,这也是为什么人们会把出块节点/矿工画在网络拓扑的中心。看上去,他们已经拥有了定义区块链的权力。然而,如果我们将注意力再下降一层,从P2P网络的观点来看,结果却不是这样。

一般的P2P网络,例如BitTorrent或是Kad Network,目的在于更快的分享数据,这些网络中的节点并不关心自己转发的数据包包含的是什么样的数据。这些节点不需要理解数据,只需要转发数据,帮助数据从网络中的一点流动到另外一个点。它们只是数据的搬运工。

区块链的P2P网络则不仅仅是数据的搬运工,还是数据的验证者。P2P网络由全节点构成,全节点在接收到新的交易或者新的区块时,首先做的事情是验证。这里的验证不仅仅是验证数据本身的完整性(Integrity),还要验证数据在业务逻辑中的有效性,例如这笔交易是否和账本中已经有的交易冲突(双花),或者这个新区块是否包含了无效的交易。验证交易是否双花是业务层(账本)的逻辑,不是网络层的逻辑。在区块链的P2P网络中,节点不仅仅要转发数据,还需要理解数据。数据转发在区块链节点中是一个提升到业务层的概念,而不只是一个网络层的概念。

这种设计所导致的结果就是,全节点组成的网络形成了一道“防火墙”,有效阻止了无效交易和区块的传播。出块节点如果产生一个包含无效交易的区块,这个区块只能够传播到与其相邻的全节点,无法穿透这些相邻节点形成的防火墙传播到更远的地方,无法进入全节点网络维护的区块链主分叉,无效交易也就无法被依赖全节点的轻节点或是钱包接受。

因此,出块节点只是新的区块的提议者,并不能让全节点网络接受无效的区块或是交易。挖出一个新的区块并不是共识的结束,而是共识的开始。如果套用Paxos共识里面的词汇,出块节点是Proposer,全节点是Acceptor。出块节点持续打包交易,提交新的区块,全节点验证新的区块提案,保证新区块和其中交易的正确性。从这个角度看,作为验证者的全节点更应该被称作守护者(Keeper)。

按照这样的理解,我们可以画出这样一个图:

图3. 以全节点为屏障的节点拓扑

在图3中,全节点网络位于中心,形成一个相互验证的去中心化网络,一道安全屏障。轻节点连接这个网络中的全节点,使用全节点提供的服务。轻节点之间也可以形成自己的网络,但需要注意的是,轻节点网络没有验证功能,转发在这里更多的是网络层的概念。轻节点网络和全节点网络是不同的网络。出块节点连接全节点提交新的区块,出块节点之间也可以形成自己的网络,以更好的提供服务,例如比特币的FIBRE就是一个矿池之间的专用网络。

全节点网络对区块链的安全至关重要。全节点数量越多,网络越可靠,加密经济的基础越稳固。全节点的运行成本和长期数量这两个指标在未来的区块链价值评估中应该会扮演越来越重要的作用。区块链发展面临的一个关键问题是,如何激励全节点?这个问题看上去简单,实际上会触及一些非常深层次的(也许是不可调和的)矛盾,例如data availability problem,这里就不展开说了,以后有时间再写文章讨论。

案例分析

当我们理解了全节点的重要性,在脑海中建立了正确的网络拓扑后,就可以用这个框架来分析实际的问题了。这里举两个例子。

FIBRE

FIBRE是比特币快速网络中继引擎(Fast Internet Bitcoin Relay Engine)的缩写,是一个专门给矿工提供服务的区块传输网络。FIBRE在全球不同的位置部署了6个节点,相互之间通过高速网络连接,使用UDP+ForwardErrorCorrection传送数据,几乎实现了无延迟的传输。在FIBRE注册过的矿工可以连接到离自己最近的FIBRE节点,以最短的时间获得新的区块数据。FIBRE和比特币P2P网络传输协议的一系列优化使得比特币的新区块几乎可以在瞬间被全世界的矿工接收,非常有效的降低了孤块率,保证了网络安全。

FIBRE是由Matt Corallo维护的一个需要注册使用的网络,因此是一个中心化管理的系统。这也是FIBRE常为人所诟病的地方。但是如果我们按照图3的拓扑来分析,就会发现FIBRE的中心化对比特币网络并没有负面影响:无论矿工是用中心化还是去中心化的网络加速新区块的传播,这个行为都不会影响全节点对新区块的验证。FIBRE也不是整个网络的单点,如果FIBRE崩溃或者作恶,矿工随时可以切换回比特币自己的P2P网络。

思考题:同样的出块节点间专用加速网络,如果用于提升网络吞吐量解决scalability问题,上述结论依然成立吗?

图4. 出块节点专用网络(虚线)

EOS

EOS的目标是百万级的TPS,为了实现这个目标,EOS使用投票的方式由全网选出21个出块节点(以及一定数量的候选节点),并要求出块节点使用最好的硬件来支撑高性能。EOS是否真的实现了百万级TPS并不重要,重要的是,通过这种方式来提升性能不仅仅要求出块节点付出不菲的成本,也要求全节点付出同样的成本。然而与出块节点不同,EOS网络中的全节点并没有得到网络的补贴,因此用户很难有足够的动力真的去支付几乎与出块节点相同的成本去运行一个全节点。在这种情况下,网络最终会演化成一个没有全节点的结构:

图5. 没有全节点的网络

ByteMaster对21个节点合理性的论证是,比特币的算力也是集中在<10个矿池手中,21个节点其实比10个矿池更加去中心化。我们通过比较网络拓扑应该容易看出,这个辩护并不成立,因为两者的网络结构有很大区别,无法这样直接比较。在EOS网络中,由于去中心化全节点网络的缺失,出块节点缺乏监督,用户只能完全相信出块节点不会作恶。出块和验证的工作最终都集中到出块节点的角色上,出块节点既是运动员,又是裁判。而在比特币的网络中,大量的全节点承担了裁判的角色,矿池仅仅是运动员。用户可以相信大量的全节点,不需要相信矿池。

需要指出的是,这个问题实际上不仅仅是EOS的问题,也是其他要在Layer 1扩容的项目会遇到的问题。

对CKB的启示

出块节点,全节点,轻节点形成了一个动态的网络,网络中的各类角色都可以自由进出(额,出块节点实际上在很多区块链中无法自由进出,这个也不展开了,以后有时间再写文章讨论...),这些角色形成的拓扑结构(例如节点比例、谁和谁连接等等等等)决定了网络的性质,包括性能、安全、中心化程度等各个方面。不同的设计可能会导致网络最终形成不同的结构,而这个最终结构所展现的性质有可能和设计初衷是相违背的。

全节点为了能够不信任任何第三方,选择自行验证所有交易历史。这种做法使全节点不仅仅满足了自己的需求,也为网络安全贡献了力量,体现出一种正外部性。区块链需要这种安全保证,因此全节点对于一个去中心化的网络至关重要。如何内部化这种正外部性是一个需要重视的课题,在这个课题还没有解决的情况下,我们能做的只能是保证全节点可以运行在一个较低的成本,以促进网络保有尽可能多的全节点。

对于希望成为未来加密经济的基础设施的Nervos CKB来说,必须在设计之初就把这些因素考虑在内,以理想中的网络结构为目标,并通过经济激励和其他机制设计来实现。这并不是一件容易的事情,还需要大量的研究和探索。

感谢

谢谢Kevin Wang和李家荪老师参与讨论并提供宝贵意见! <3<3<3

We're hiring!

如果你对创造未来的加密经济感兴趣,对自己的能力有自信,欢迎投简历到 join@cryptape.com 加入我们!

  • Nervos AppChain Team
  • Nervos CKB Team
  • CITA Kernel Team
  • Cryptape Research
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,233评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,013评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,030评论 0 241
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,827评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,221评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,542评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,814评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,513评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,225评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,497评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,998评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,342评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,986评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,055评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,812评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,560评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,461评论 2 266

推荐阅读更多精彩内容