EOS ArcLight: The First Solution to High-Performance Blockchain Light Nodes
EOSIO has led the development of blockchain technology from the laboratory to a mass commercial implementation. With the emergence of more high-performance blockchain protocols, the prototype of the trust economy has formed. New problems are brought by the large-scale deployment of high-performance blockchain, such as the high O&M cost of full nodes, the inefficiency in the synchronization of application data, and the infeasibility of sharing data across multiple chains. A solution for lightweight nodes is urgently need in high-performance blockchains to eliminate the final obstacle for the further development of the trust economy.
EOS ArcLight
EOS ArcLight, the first high-performance blockchain light node solution, was launched by EOSForce Development Team recently. This solution is developed based on Golang, and introduces lightweight node solutions for high-performance blockchain protocols such as EOSIO. Unlike the full nodes which are started based on nodeos, EOS ArcLight only need to verify block headers without implementing Action in block.
New Challenges in High-Performance Blockchain
1. High O&M Cost
EOSIO’s block header structure supports lightweight nodes, but there is no reliable light node implemented in EOSIO community.
In Bitcoin Whitepaper, Satoshi Nakamoto mentioned that it is possible to verify payments without running a full network node. The old block can only retain block headers and the transaction data that nodes pay attention to. Even in 2008 when the white paper was released, all block header data could be stored in the memory of the common microcomputer.
In the subsequent discussion, Satoshi Nakamoto believed that there would eventually be only about 100,000 full nodes that can produce blocks in the Bitcoin network. Meanwhile there would be millions of lightweight clients that can send and receive transactions. Although those clients cannot produce blocks, they can still verify the payment for themselves without relying on other nodes.
EOSIO’s blockchain structure also supports lightweight nodes, and it also requires a large number of lightweight nodes in its network and applications.
In EOSIO network, a full node has high requirements for machine performance, network, and operation and maintenance. At present, there are few full nodes available in EOSIO network, which means that the current EOSIO network structure is not decentralized that has a great impact on the network stability and also increases the difficulty of developing and deploying applications on the chain.
Take the EOS network (chainID: aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906) as an example (mid-January 2020), the total RAM is 174G, and the allocated memory is about 74G. Although the actual data used is little, there must be at least 64G of memory configured on a full node, otherwise transaction execution failure will occur due to memory read and write misses.
On the other hand, the current EOSIO block data is very large, which brings great challenges to the maintenance and storage of nodes. At the same time, it takes too long to replay blocks. On some mainstream performance servers, the complete replay takes nearly one month.
2. High Development Difficulty & Cost
Although EOSIO’s plug-in architecture allows nodes to expand functions, nodes have higher requirements for machine performance. Meanwhile, the entry for developing plugins based on C++ is high, so there are few developer tools in EOSIO, indirectly increasing the difficulty of developing DAPP.
Many early query and index services of DAPP relied on EOSIO’s history plugin and mongoDB plugin. However, with the increase of block data, a big performance problem occurred with such history nodes or mongoDB database. Although the community has also proposed some solutions, the cost is quite high because they rely on full nodes, which brings a lot of additional costs to the development and operation of DAPP.
Satoshi Nakamoto’s prediction of Bitcoin network structure is also applicable to other blockchain networks. In addition to full nodes, EOSIO network also needs a large number of lightweight nodes that conform to the cost game.
3. Unable to Meet Cross-Chain Needs
The support of cross-chain function significantly oriented the development of public chains, and EOSIO will support adding sidechains based on IBC. Currently it requires to start IBC based on the full node to enable users to obtain the proof data based on Merkle Tree. However, due to the high cost of building a full node, it is very difficult for even a few validators and phishers to start full nodes, which will make some theoretical support schemes fail economically. If the cross-chain operation depends only on the services provided by a small number of full nodes, the entire system will be very vulnerable.
To sum up the above problems, we need an implementation of the sufficiently lightweight EOSIO node. The light node should be easily expanded and secondarily developed while ensuring the verification of the block.
Technical Principals of EOS ArcLight
EOS ArcLight will not process every transaction, only verify the validity of the block and block header, and confirm that its block is irreversible.
One of the main reasons for EOSIO’s high demand for nodes is its RAM state. The state is very large and has not been verified in the block, so any node that wants to obtain any state needs to completely replay the EOSIO block. Although the node can be restored through the snapshot function, even for nodes that are kept in sync, the recovery time is relatively long in the event of a failure. Due to the busy transactions on the EOSIO chain, the peak value can reach about 4,000 TPS, so the synchronization of real-time EOSIO block will also have higher requirements for the machine.
Not processing every transaction means that most of the work of the light nodes can be completed in parallel, and synchronization can also be started from any block height. In the current prototype implementation, light nodes need only take up very little computing resources to complete verification.
Although not processing each transaction allows light nodes to occupy few resources, it also makes light nodes unable to provide RAM state. In EOSIO, almost all states are stored in RAM. Some actions also need to be triggered by executing transactions. In order to solve this problem, some assertion mechanism is required to ensure that the node can obtain the EOSIO state based on the block data only, which can be achieved through the EOSIO State Assertion Contract and the State Static Assertion Contract.
According to the different roles of EOSIO light nodes, we divide EOSIO light nodes into block nodes and block header nodes. The former includes all or part of EOSIO blocks, and the latter includes only EOSIO block header data.
Considering that EOSIO is under the continuous development, light nodes also need to follow it to iterate, so the design of light nodes should be as homogeneous as possible with EOSIO, and their APIs and actions should be as unified as possible with nodeos.
Use Cases of EOS ArcLight
1. The Real Decentralized Wallet
At present, EOSIO wallets are usually based on the unverified data provided by third parties, which are different from Bitcoin wallets. These EOSIO wallets will not work properly without services provided by third parties. And in these wallets, users cannot get accurate transaction execution feedback. If you want to confirm whether the transaction is completed or not, you can only rely on other services, such as the block explorer to confirm the transaction completion, which actually has a great security risk.
Based on EOS ArcLight, we can embed light nodes into the wallet, so that each wallet is a light node. At this time, the wallet can independently verify the success of the transaction, and it can be used safely even in an insecure network environment.
2. Credible Realtime Block Data Service
Many DAPPs need real-time on-chain data, especially applications with short response and security-oriented applications such as decentralized exchanges. They need to be able to securely and reliably obtain real-time status on the chain, especially EOSIO’s irreversible block determination. Because the current consensus algorithm is still in the initial completion stage, the time interval between the blocks entering the irreversible state is long, which means that many applications need to accept the irreversible blocks that are not entered first, and avoid inconsistent state verification after the fact. This logic requires writing node plugins and deploying full nodes, which will increase the DAPP development and operation costs.
Based on EOS ArcLight, light nodes can be incorporated into existing data services in the form of libraries. Light nodes are developed based on Golang, which are friendly to back-end development and there is no threshold. At the same time, light nodes fully implement consensus algorithms. Therefore, it is very convenient to implement a reliable real-time block data service.
3. High-Performance Cross-Chain Service
If cross-chain interaction between the EOSIO chain and other chains is required, it is often necessary to implement light nodes on both chains. EOS Arclight can be easily embedded in other services or nodes, and can independently verify the nodes to well support such applications.
In fact, the original motivation of EOS ArcLight was being a link in cross-chain services. For example, for many chains that are developed based on the Cosmos SDK, a very common architecture is to use the Cosmos SDK-based chain as the settlement chain and the EOSIO-based chain as the calculation chain. The implementation of Cosmos IBC protocol is used to complete the settlement of cross-chain calculation results. In this system, we only need to integrate EOS ArcLight in the nodes of the settlement chain, so that each node of the settlement chain is a light node of the computing chain. Through the consensus mechanism of the original settlement chain, the calculation chain block data held by each settlement chain node (only the ID of the irreversible block needs to be considered) reaches a consensus. In this way, the data of the calculation chain can be traced back to the settlement chain.
EOS ArcLight Technology Roadmap
EOS ArcLight was developed by EOSForce, the development team of EOSC community. At present, the development work is mainly divided into three directions: node implementation, compatibility with full node API, and optimization of computing performance. EOSForce team has implemented a preliminary version that can complete the synchronization and verification of block data, and a technology roadmap has been released:
2020 Q1: Implement the decision algorithm of irreversible blocks, improve block storage implementation, achieve the compatibility of nodeos’ block db.
2020 Q2: Support other nodes to synchronize blocks and transactions from light nodes, improve API interface to be as compatible as possible with nodeos.
2020 Q3: Optimize concurrent computing capabilities, speed up the synchronization process, and support EOS-VM to implement the execution of some Actions
EOS Arclight is fully open-source, view it on Github:
