EOS-based blockchain network implementation for Remme [REMChain]
Remme holds several products such as Auth, KeyHub, and PKI Protocol. Blaize had to create a new public blockchain for Remme PKI protocol.
Before the Blaize solution, Remme faced a lot of problems using Hyperledger Sawtooth. Therefore, in order to meet the demands of large enterprise clients we had to build more optimal and effective solutions. We needed a scalable, fast, reliable and secure blockchain. At the same time, the blockchain had to support smart contracts.
It was necessary to review the existing solutions on the market that could allow the implementation of a new consensus model and internal economics. EOS blockchain was chosen as the most suitable framework to use as a base for the newborn Remme chain.
Solution Blaize proposed
We have provided a simple and straightforward branching strategy for development in our GitHub repositories. This helped to minimize potential difficulties if the new EOS version is released. Hence, to enhance blockchain operability we decided to implement additional changes to the mechanism of choosing the block producers along with new tokenomics mechanisms different from the one EOS blockchain uses.
The creation of an EOS-based blockchain with a new resource management system, consensus, and tokenomics was not an easy task. We have performed the following stages of the development process:
- Resources management
We needed to simplify the system for users. Generally, EOS has three types of resources: RAM, CPU and NET. In order to make the user experience better and at the same time reduce their unnecessary involvement we combined CPU and NET into one resource.
Additionally, users don’t manage their resources, system allocates the same amount of RAM for every created account;
- Consensus enhancement
In the present EOS environment, there are only 21 block producers picked to produce the next block. In Remme chain, we decided to shuffle the last block producer with one of the top standby producers to keep standby producers involved in block production (and to ensure they are ready to produce blocks). Therefore, we allowed 4 additional users to be engaged in the process one by one replacing the last place of the 21st block producer.
- Tokenomics alternative
For the new Remme chain ecosystem, we decided to change how block rewards are distributed between top 21 and standby producers. In order to do this, we implemented a voting power increment.
In EOS tokenomics system, when 100 tokens are staked – 100 votes are received the same day. In the new Remme chain environment, we wanted to give the voting power gradually from 0 to 100% within the 6 months period. (Broadly speaking, at the beginning of the stake, the user will have less power than at the very end of those 6 months termination).
Main challenges during the Remme chain development
When you deal with blockchain, especially one that is providing Public Key Infrastructure, you should always be aware of the security of the code you write as well as keeping in mind different adversarial usage scenarios. Detecting and managing such scenarios was one of the obstacles we managed to handle.
One of the main challenges, sarcastically, was the difficulty of making things work. Because even if you know your tools, there is always scope for unexpected changes in the blockchain itself or new features’ updates, etc.
EOSIO is constantly evolving and changing its blockchain architecture and something that worked previously could be suddenly broken. One of the problems we faced was a bug in EOSIO.CDT. We had a logic depending on the get_active_producers method in smart contract’s API, which returned partial data, so we had nothing to do but fix a problem by ourselves.
Another important task was meeting business requirements and maintaining high throughput while working within fairly limited blockchain capabilities. This required a combination of previous experience in working with EOS blockchain and knowledge of blockchain optimization for business purposes.
The implementation of such a remarkable project like Remme chain needs a list of skills the team has to possess. Besides the experience and good command in C++, it requires a solid knowledge of the EOSIO testing toolchain and deep knowledge of EOS blockchain ecosystem in general. Thus, a well-skilled team of experienced blockchain developers was a must in this case.
We created a new EOS-based blockchain with a different consensus mechanism, which distributes awards more fairly among block producers, both active and those in standby mode.
We proposed a robust architecture for Remme’s solution and then implemented the entire logic and economy of Remme protocol. Besides dev matters, we also handled DevOps. We used the best fitting branch model, as we had to constantly integrate patches from the EOSIO blockchain, and set up continuous integration and a continuous deployment solution for development and client convenience.
Our experience of working with the EOSIO blockchain and with Remme allows us nowadays to provide expertise and advising on what is possible and what is not regarding such kind of development for our future projects. Contact Blaize experts to get a consultation for your future project!