RChain®-VS-Near Protocol

NEAR 只修炼到了指玄境,因为没突破跨分片原子交易这一关。RChain 当前已经修炼到了天象境,如果并发+无缝分片算是天象境的话,那么形式验证就是地仙境。形式验证完成了是地仙境:链上形式化验证,形式验证还是需要 Rho 演算。实际上 ETH 2.0 和 NEAR、DOT、ATOM,都变得越来越像了。

NEAR 通过信标链做跨分片交易的,比如 shard 1 往 shard 2 发送一个币,先在 shard 1 上扣掉一个币,然后发个 receipt 到信标链,然后 shard 2 再给你一个币。它的跨链合约调用的写法在这个文档里:https://docs.near.org/docs/tutorials/contracts/xcc-receipts,这个调用的方式没办法保证跨链合约的原子性(事务性),原子性的例子:一个 Uniswap 的交易,swap 的两个币都在两个分片上,这个 swap 要不都成功,要不都不成功,不能只 swap 一边。这只是转币的情况。如果通用计算的情况,可能复杂的多,比如一个数据变了,上面的索引也要更新,两个同步,索引可能在专门的高性能分片上,数据可能在存储分片上。如果不能保证这种事务性的话,整个系统的状态就可能是不一致的,这会让你的合约编写非常麻烦。这个索引的例子,很可能在某个时刻,你通过索引找到的数据实际上和索引对不起来,这种乱七八糟的奇葩情况会让你都需要写代码解决。然而区块链上,这种奇葩情况越多,出错的概率越大。

NEAR 牺牲原子性本来就是为了不牺牲 TPS,不然需要所有涉及的分片一起为某个跨分片交易统一投票,这样在没达成并发执行的情况下代价不可接受。如果只是转转币,NEAR 的那套可能够了,但要满足这些事务性要求,能干点更有追求的事情,那就不够。Solidity 编译到 Rholang,一点问题没有,而且也能并发,程序员可以用 Soldiity 或者 Rholang,都行。NEAR 这个技术路径不会有机会,除非达成并发。并发没达成的话,跨分片原子交易会让你损失很多性能,也就失去了通过分片扩容的意义,要用 RChain 的设计思路才行。

金刚、指玄、天象、地仙、天仙,一步步向上。

  • 金刚境:ETH Layer 2

  • 指玄境:NEAR,ETH 2.0

  • 天象境:RChain(并发+无缝分片)

  • 地仙境:RChain(并发+无缝分片+形式验证)

​转载自:

https://www.yuque.com/guangzhishiyi/rchain/gt8dk4