Why We build REI Network
When we had the first idea about blockchain in the year 2016, we wanted to develop a high-performance blockchain that could adapt to the growing business demands, so we adopted the Graphene framework to build the initial version of GXChain 1.0. With the continuous iterative update of the technology, we have introduced the WASM virtual machine on Graphene, which supports mainstream programming languages to write smart contracts, and implements one token - one voting power, and an innovative staking&voting mechanism on the DPoS election mechanism. GXChain 1.0 has completed its historical mission within a period of time and has won support from numerous community users. At the end of 2019, when we witnessed DeFi booming, we considered whether GXChain could provide a more friendly experience for these DeFi projects. When we tried to implement these basic ideas of DeFi on GXChain 1.0, we found some problems:
- A lot of DeFi projects are built on Ethereum/EVM, and most of them adopt Solidity programming language
- Although Ethereum is not very user-friendly (low efficiency and high cost), it seems developers and users care little about it.
So we consider that what really attracts these developers. After a period of research, we found:
- EVM has a more mature and historically tested instruction set, as well as a friendly compiler & editor, and other infrastructure, and has accumulated a large number of developers on these foundations
- The ecology of EVM has better standards, such as ERC20, ERC721, etc., and the combination of these standards is very strong
- The Ethereum community has accumulated a large number of high-quality projects and loyal users in the early days. Although Ethereum is not very user-friendly, it is still the first choice for DeFi projects.
Therefore, we decided to make GXChain 2.0 compatible with EVM and its ecological infrastructure, so that DeFi developers and their applications can seamlessly migrate to GXChain 2.0, maintaining the same experience as the Ethereum blockchain, and improving consensus efficiency (the performance of GXChain2.0), to reduce the cost of use. After having such preliminary ideas, we quickly refined some specific technical solutions, that is, the technical characteristics of GXChain 2.0:
- Compatible with EVM
- Compatible with Ethereum's RPC and Websocket interfaces, and can support GRPC in the future
- Rewrite the network module and use Libp2p instead of Devp2p (current Ethereum client solution), because we believe that Libp2p has better standards and can achieve better versatility and scalability
- Realize Systems contracts that can be soft-forked and upgraded. These contracts include: Staking/Slashing, ResourceManager and IBC contracts, etc.
- Achieve a more efficient and more random consensus: DPoS+BFT, to ensure decentralization and be more green power
- Realize the abstract consensus module, so that the code of REI Network can be easily combined and become a chain-making tool
In the face of the above-mentioned technical ideals, we hope that the code of GXChain 2.0 will no longer be a simple Fork or depending on an open-sourced chain-making framework, but on the basis of EVM, reconstruct the network, consensus, node election, and RPC modules. We hope these codes are more concise and modular so that they have better composability.
Last modified 1yr ago