# RChain®-VS-Solana By [Rchain.eth](https://paragraph.com/@rchain) · 2021-11-14 --- ![](https://storage.googleapis.com/papyrus_images/5ba4dafafe4ecd50715e147c6f49d2494a0a77b7ff8b7fe60649fff315a02f6d.jpg) 作者：莫给机狂 编辑：光之十一 ### Solana 在“不可能三角”中的位置 传统区块链由于采用了需要顺序处理交易的状态机计算模型，因此在逻辑上需要把交易排成一条长队进行处理。既然要去中心化，就必须由一群节点来维护这一条队列。在这个前提下，各种共识协议的改进，就是在去中心化、性能、安全之间的各种折衷： * 为了去中心化：你希望网络每个节点都有机会来管理和处理队列里的交易，而不是由某几个节点说了算，并且这个轮换要足够迅速。 * 为了安全：你希望网络中管理和处理队列里交易的节点数量要越多越好，减少同谋作恶的概率。 * 为了效率：你希望这个队前进的快一点。 然而，在状态机需要排队交易的框架下，不管你如何设计区块链的共识协议，你会发现这三点是不可能同时成立的。如果你选择了其中任何两项，那么必须得抛弃第三项。Solana 是典型的选择了安全+效率，但却舍弃了去中心化的项目。 Solana 是典型的有领袖节点 (leader node) 的网络，在主网中，真正出块的节点是出历史证明 (PoH, Proof of History) 的领袖节点 (leader node) 。这个领袖节点 (leader node) 接受收到的交易请求，然后执行合约，再把合约的执行结果写入历史证明 (PoH,Proof of History) ，发给网络中其他 N 个验证节点。这些验证节点根据收到的历史证明 (PoH, Proof of History) 记录以及其中的交易次序执行合约，验证结果是否对得上号。 从这里可以看到，如果验证节点个数足够多，那么交易可以保证正确执行，即网络的安全性可以保证。而这个领袖节点 (leader node) 可以当多久呢？现有的 Solana 网络中把一个领袖节点 (leader node) 的“任期”设置成大约 3 天，故而在正常的情况下，你会发现 Solana 的网络是一个很奇葩的架构：3 天内一个领袖节点 (leader node) 不停地飞快出块，其他的 N 个“下属”不停地拿小本本记下来验算一下“领导”算的对不对——这可能是币圈最中心化的一个场景了。 对比之下，RChain 是完完全全的无领袖节点 (leaderless node)，网络中所有节点时时刻刻都平等，没有任何领袖 (leader)。这两个不同的架构所带来的五花八门的后果，下面会一一铺展开来详细说明。 ### Solana 满足公链的信任模型吗？ 公链有几个属性：\*\*高度冗余，可信无篡改，公平、抗审查。\*\*Solana 的架构，能保证它的可信、无篡改，但由于 Solana 基于领袖节点 (leader node) 的中心化，把“公平、抗审查”的属性丢掉了，所以我并不认为它符合公链的定义。 因为有领袖节点 (leader node) 节点指定交易次序，这样其他验证节点就不会 PK 交易次序了，大家都按照这个次序来执行交易，更新状态。然而，验证节点是无法检查领袖节点 (leader node) 是否有审查、歧视行为的。比如 A 和 B 抢一个 IDO (Initial DEX Offering, 首次去中心化交易所发行) 的席位，这个领袖节点 (leader node) 认识 A 的公钥，是个熟人，那它完全可以在历史证明 (PoH, Proof of History) 里把 A 的交易放在 B 之前，尽管事实上 B 的交易比 A 的早。 现有的公链圈中，Solana 这种披着区块链的中心化项目是我最不认可的，因为它们抄了捷径，违背了去中心化的本意。相反，Polkadot，Avalance 之类，虽然不看好，倒没上升到“不喜欢”这个程度。这是因为一方面，坏的去中心化比现有的中心化还要糟糕，中心化系统中你受到了歧视和审查，还可以去起诉服务提供商，而在去中心化中，你要起诉都找不到人。我有个对应关系表： * 中心化系统=Dictatorship，乾纲独断 * 区块链=Democracy，大家都需要投票来解决争端 * 不好的去中心化系统（比如：Solana）=军阀、土匪割据 另一方面，这些不符合区块链信任模型的项目混入区块链队伍，误导性极其强，对其它踏踏实实在区块链的框架下建设项目的团队起到了一个“劣币驱逐良币”的负作用。 这里要提一下 V 神的一段博客，它对 Solana 的架构做出未点名的批评：[Why not centralized production and sharded verification?（点击跳转）](https://vitalik.ca/general/2021/04/07/sharding.html) _“在高 TPS 链中检测区块生产者的审查制度要难得多。审查制度的检测需要 (i) 能够看到每一笔交易，并验证是否有明显应该进入的交易莫名其妙地没有进入，或者 (ii)对区块生产者有一个 1-N 的信任模型，并验证是否有区块没有被进入。在中心化的高 TPS 链中，(i) 是不可能的，(ii) 更难，因为小的节点数量使得即使是 1-of-N 的信任模型也更容易被打破，如果链上的区块时间对 DAS 来说太快了（就像大多数中心化的高 TPS 链那样），就很难证明一个节点的区块没有被拒绝，只是因为它们都被发布得太慢。”_ V 神的这段话直指 Solana 的命门。他还没提的是“并验证是否有明显应该进入的交易莫名其妙地没有进入”，这还不够，因为这仅仅是审查，还有歧视的行为，那个更难上加难。 这里要提一下 Flow ，虽然它的架构比较复杂难看，却还是比 Solana 要更符合区块链的信任模型。Flow 本质上就是个更公平的 Solana ，因为它也遵循一个类似的原则：交易次序的共识和交易状态更新的共识分开。和 Solana 不同的是， Flow 的交易次序并不是由一个领袖节点 (leader node) 指定，而是由一群节点组成的委员会指定。那样公平、抗审查性就最大程度保证了。当然代价是 TPS 下降了 90% 直至几千 TPS 的级别。所以，**在“排队交易”的框架下，区块链的每一样属性需要满足，都是需要付出相应代价的！** ### Proof of History 真的是“忠实记录历史”吗？ Solana 的一个理论基础是历史证明 (PoH, Proof of History) 。传统区块链共识效率低的原因是，在“需要把交易排队”的系统中，交易是对次序敏感的，而各个节点看到的交易先后次序由于网络延时等原因可能是不同的。不管怎样的共识协议，节点之间都需要花费大量的同步开销，对它们的次序以及相应的状态更新达成共识。 Solana 表示如果有个全网可信的时钟把每一笔交易发生的时间记下来就解决了，如此节点之间不需要争论谁先谁后。Solana 提出了一个叫历史证明 (PoH, Proof of History) 的概念，则为不断地递归调用哈希函数组成一条长长的哈希序列，中间“编织”入各个交易。这个哈希序列生成的时候很耗时间，因为不能并行，只能单 CPU 运行，而验证的时候因为可以用并行计算，非常快速。这个哈希序列是很难即时的伪造的，比如：一般的计算机需要 1 秒才能生成一条长度为 100 万 的哈希序列，即便这个星球上最强大的计算机，可能最多也就只能生成长度为 200 万的序列，堆算力基本上无法让其成千上万倍的提高单位时间内生成的哈希序列的长度，所以基本上可以用这个哈希序列的长度作为大致的时间流逝的量度。 但是问题出在这个时钟是可信的，这个历史一旦广播了是无法篡改的。这个历史真的是反映了真实吗？不是的，因为别忘了，这个历史是由领袖节点 (leader node) 记录的！所以回到那个例子，A 和 B 一起抢 IDO (Initial DEX Offering, 首次去中心化交易所发行) 的席位，A 其实先发出的交易，但领袖节点 (leader node) 在历史证明 (PoH, Proof of History) 中完全可以把 B 放在 A 之前。所以即便这个时钟可信，这个历史无法篡改，但是可惜无法证明是不是真的。 **反观 RChain 因为应用了并发的 Rho 演算，根本不需要对事务进行排队！所以“可信的时间戳”这个需求从来就不存在。** ### Solana 和 DeFi 是最佳搭档吗？ 2021 年的币圈最魔幻的事件之一是 Solana 由于速度成为很多 DeFi 项目的首选平台，尤其是高频类应用，例如：带订单簿的 DEX ……可是 Solana 不能“抗审查”和保证“公平性”的问题恰恰是最不适合作为高频类 DeFi 项目的平台！ 只要使用过高频交易的都知道在交易中，单子比别人的快、慢一点点都可能是赚大钱还是亏本钱的分界线。慢了人家就会抢先交易 (Front-run) 你的单子，让你的成本上升。前面已经说过，领袖节点 (leader node) 是在很长的时间（3天）内，对交易次序有生杀予夺的权力的，那么完全可以让自己控制的一个账户不断的去抢先交易 (Front-run) 某些大户的单子进行套利。 真正要解决这个问题还是需要 RChain，Avalanche 这种完全的无领袖节点 (leaderless node) 架构，即使 Ethereum，Algorand 这种轮流出块的，轮到出块的节点也有这个调整交易次序为自己牟利的可能，当然由于它们轮转非常快，相比 Solana 这个问题小得多。 ### Solana 在 DDoS 攻击下的脆弱性 2021 年 9 月 14 日 Solana 的断网是由于机器人刷单，短时间内发送了大量的请求导致大部分验证节点内存溢出掉线，Solana 只能紧急发布修复版本，要求网络中的节点重启。直到 20 小时之后，整个区块链才又重新上线。这个算是应用层的非故意 DoS 事故，这是可以通过修复 bug 和加入限流的逻辑来解决的。 网络层针对领袖节点 (leader node) 的 DDoS 攻击，Solana 基本对此无解，这是它中心化架构决定的。出块节点事先选出，而且轮换的频率非常低，导致面对 DDoS 攻击时非常的脆弱，攻击者只要把当前的领袖节点 (leader node) 堵死就行，下一个选出的继续堵。而没有领袖节点 (leader node) 的无领袖 (leaderless) 网络，比如：采用了并发出块机制的 RChain，采用了 PoW 的比特币、以太坊，采用了VRF (可验证的随机函数) 的 Algorand 和 Difinity， 采用了雪崩协议的 Avalanche……要 DDoS 攻击瘫痪整个网络需要攻击网络中很大一个比例 (至少1/3) 的节点。如果网络中节点数量足够多，那么基本可以对这类攻击免疫。需要提及一点的是，VRF (可验证的随机函数) 在设计时就考虑了此类攻击，通过让网络无法提前预知谁是被选上的节点来避免这个问题。 --- *Originally published on [Rchain.eth](https://paragraph.com/@rchain/rchain-vs-solana)*