RChain and ZB: Toward a Queueless, Leaderless, Limitless Blockchain

RChain and ZB: Toward a Queueless, Leaderless, Limitless Blockchain sponsored

On November 2rd, 2021, RChain‘s blockchain scientist Atticbee visited ZBexchange as an invited guest for a very technical AMA. ZB is a global exchange being in operation for 8 years with a focus on keeping customers’ assets secure. Atticbee discussed the problems of current blockchain technology and RChain’s answer to these challenges, and why one day RChain will be the most user and developer friendly Web 3.0 infrastructure. What is Missing In All Current Public Blockchains

In Atticbee’s view, none of existing public chains has addressed these issues that are critical to Web 3.0: Currently there is NO REAL solution to the scalability problem: the scalability of Layer 2 and ETH 2.0 is an illusion because the individual Layer 2 and shard subsystems are not interoperable – they do not “look and feel” like one logical chain. They are designed for token transfer applications, not data intensive Web 3.0 applications. Contracts cannot safely call each other, lacking the “secure composability” to build large, complex software systems from smaller and simpler building blocks as in Web 2.0.

Greg Meredith, the founder of RChain, realized these pain points in 2015 when he and Vitalik, the founder of Ethereum, were working together to scale Ethereum. So he chose the concurrent, composable Rho-Calculus with on-chain formal verification capability as the computational model for the contract layer at the beginning of the design. Figure 1. A Comparison of Computational Models

This technology route has many features theoretically impossible for other projects: Solves the “blockchain trilemma” with concurrent “queueless” transaction processing. One platform for all: Direct on-chain storage of large data, integrating all the functions of ETH, IPFS and GRT into one single platform. Seamless sharding: shards look and feel like one with atomic cross shard transactions. Fast on-chain formal verification based on its OSLF behavior type system. The Root Cause of the “Blockchain Trilemma” and Its Solution

In Atticbee’s view, the “trilemma of security, performance, and decentralization”, only applies to the current blockchains that require queuing up the transactions, but not applicable to the queueless RChain.

Essentially traditional blockchains require transactions to be processed as a long queue, with all nodes in the network working together to maintain this queue. Then they are doomed to suffer from an impossible triangle of security, performance, and decentralization: For security, more nodes need to be involved in maintaining this queue. For performance (scalability), the queue needs to move forward as fast as possible. For decentralization, all nodes need to have equal opportunity to participate in the management and processing of this queue and monitor each other.

Basic logic tells us one can only choose any two of them and give up the third. Typical examples: Ethereum chooses security and decentralization over performance; Solana, a leader based system, chooses security and performance over decentralization; EOS with 21 equal nodes chooses performance and decentralization over security.

However, when one realizes that “distributedly maintaining a transaction queue is the root cause of the trilemma ”, this problem naturally gets solved if we can eliminate the need for a translation queue like RChain. In RChain’s “block-merge” test network, as more nodes are added, the network achieves higher TPS. It is a solid proof that the trilemma has been solved: more nodes means stronger security; leaderless means decentralized; higher TPS means better performance. Thus RChain reaches all three vertices of the “impossible triangle” simultaneously. RChain VS Solana and PolkaDot — Two Examples of Flawed Solutions

When asked his view on other star projects, Atticbee thinks Solana achieves high TPS at the cost of the blockchain trust model, which is meaningless because any centralized system can have much higher TPS. The idea behind its design is simple: since it is too slow to let many nodes manage the queue together, it simply lets a Proof-of-History node decide the order and write into a tamper resistant PoH ledger. The other nodes just execute and validate the transactions in this ledger. Figure 2. A Comparison of Public Chains

However, by doing this, the job of managing the queue is centralized, and the PoH node can dictate transaction order, or censor transactions at will. These malicious behaviors are almost impossible to detect and prove. Atticbee mentioned Flow as a project with a similar idea but uses a committee to decide the order, making it a more fair version of Solana, but as a cost its TPS is much lower. It is a textbook example of how a “queued system” inevitably suffers from the trilemma.

As for RChain, it doesn’t need to queue up transactions at all, so it can achieve high TPS while keeping a decentralized leaderless architecture.

Atticbee also views PolkaDot as an incomplete cross-chain solution lacking essential coordination capabilities. It has no way to atomically finalize cross chain transactions. Also it does not provide the “composable security” to ensure that when one contract located calls another contract on another para-chain through the relay chain, the permissions given won’t be leaked to others. RChain has atomic finalization of cross-chain transactions, coupled with a behavioral type system as a “on chain firewall”, making it a superior cross-chain solution. A Global Computer with Concurrent Process Orchestration

RChain’s ultimate goal is to build a true global computer to serve as the foundation of Web 3.0. As seen from the Web 2.0 experience, the most valuable asset on the web is the vast amount of data. Therefore all existing blockchains have been built with the wrong design at the beginning: they are exclusively optimized as payment networks. A true Web 3.0 infrastructure must be designed for data-intensive applications. Figure 3. The Knowledge Graph of RChain

In addition, we can see that existing Web 2.0 systems are becoming more complex, but thanks to componentization and containerization, developers can quickly build out large systems with smaller reusable components. However, without a fast formal verification system to ensure safe cooperations between contracts, none of the existing blockchains can achieve this. The Venus phase of the RChain roadmap tries to solve this pain point by introducing a behavior type system support. RChain’s Rho-Calculus is one of the very few models that have this capability. Every Developer Should Start Learning Rholang

Rholang, a language based on process calculus, has long been neglected by the IT industry because of its reluctance to leave the comfort zone of current programming paradigms. However, entering the blockchain era, Rholang has a range of advantages for blockchain by its design. Figure 4. A Mug with the OSLF Algorithm behind Rholang Language

First of all, its immutability makes “queueless” transactions possible. All resources in Rholang are immutable data and codes organized by channels. Atticbee made a metaphor: a contract written in a traditional language like Solidity is like a group of kids drawing on a blackboard: the order in which the kids draw will affect the final state of the board, so they must form a queue. On the other hand, Rholang is more like a group of kids playing with Lego blocks: they can pick up and assemble some blocks and then connect the product back to the common project. Since no one can “mutate” any piece, the order doesn’t matter so the kids can play at the same time.

Another important benefit of being “queuess” is that large data can be stored directly on-chain. Any data intensive transactions have to deal with the high latency of network and disk operations. The prerequisite for such transactions to be done on-chain is that they can be processed simultaneously with other types of transactions.

After the sharding milestone, RChain will have another developer friendly feature: there is no difference between writing a cross-shard contract and writing a single-shard contract.

After the Venus milestone, developers can use the behavioral type system to perform static analysis to answer questions such as: Will this code create a race condition, get into a deadlock, or leak any given permissions to a third party? These analyses can be done at compile time in Rholang, before the code runs. With this feature, now you can organize a group of contracts together on-chain and allow them to call each other safely in a concurrent setting. This advantage completes RChain’s ultimate killer feature: on-chain orchestration of contracts, or “Kubernetes on the blockchain”.

The RChain community has already built DApps that other chains can’t do by taking advantage of its on-chain data storage capability： Dappy: decentralized DNS server and browser, with NFT and wallets integrated in one package. RSong: music streaming DApp with music stored directly on-chain. RPI: a photo NFT platform with photo data stored directly on-chain. RCovid-19 Passport: vaccination certificates stored directly on-chain.

Atticbee predicts that once all the milestones are complete, the benefit of Rholang is sufficient enough to make every DApp developer adopt this new language paradigm.

This is a sponsored post. Learn how to reach our audience here. Read disclaimer below. Polygon Deploys Fiat on-Ramps via Alchemy Pay, Enabling Direct Fiat Payments for DeFi SPONSORED | 10 hours ago International Chess Federation Will Launch the Sport’s Global NFT Marketplace on FreeTON SPONSORED | 18 hours ago Tags in this story RChain

Image Credits: Shutterstock, Pixabay, Wiki Commons Disclaimer: This article is for informational purposes only. It is not a direct offer or solicitation of an offer to buy or sell, or a recommendation or endorsement of any products, services, or companies. Bitcoin.com does not provide investment, tax, legal, or accounting advice. Neither the company nor the author is responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any content, goods or services mentioned in this article. Read disclaimer