# RChain®-VS-Near Protocol

By [Rchain.eth](https://paragraph.com/@rchain) · 2022-02-09

---

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](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](https://www.yuque.com/guangzhishiyi/rchain/gt8dk4)

---

*Originally published on [Rchain.eth](https://paragraph.com/@rchain/rchain-vs-near-protocol)*