Choosing the right blockchain platform is essential for every crypto project. It’s imperative that businesses operating in the cryptocurrency sector select a blockchain whose multifunctionality, adaptability, scalability, security and community support match their requirements.
Like any startup, we devoted significant time to evaluate the options and, after extensive research and testing, settled upon Hyperledger Sawtooth as our blockchain framework and starting point. The key advantages of the platform were parallel transaction execution, private network support with permissioning features, pub-sub events system, modularity, and pluggable consensus algorithms. In addition, Hyperledger allowed for flexibility in language choice during the development process.
Having chosen the platform, our dev team worked hard on developing the Remme ecosystem. To support our tech community so that they could easily embed Remme PKI(d) Protocol into their projects, we developed programming libraries to wrap its application programming interface. We developed our custom consensus algorithm, released JavaScript, .NET and Java libraries and Remme Block Explorer to allow our dev community to view information about blocks and transactions on the Remme blockchain.
As we geared up for the launch of our mainnet, we intended to introduce a testing playground for masternode owners, developers and future clients, giving them the means to experiment and run tests.
Challenges and obstacles
Every journey has its share of obstacles that must be navigated, and it would be fair to say we encountered more than a few along the way. As the date of the first testnet releases loomed, we found ourselves transitioning from a romantic, idealistic phase to a less glamorous one called reality. Being among the very first companies to construct a public blockchain on Sawtooth, we realized that the solutions we had built on top of it were still not ready to face real-world use cases because the platform’s fundamental framework and tools are not ready to handle a multi-million dollar economy out of the box. We dedicated a major portion of our engineering capacity to troubleshooting Sawtooth components, building fixes and workarounds to make it possible to use the solution and operate our network in a public permissionless fashion.
We’re now able to identify the primary challenges that we faced, namely: Lightning Memory-Mapped Database (LMDB), Command Line Interface (CLI), and custom ZeroMQ implementation of Sawtooth.
Some examples of the issues we encountered:
- The Sawtooth command line interface is not designed to be extended with other modules. Unlike the pluggable consensus approach, there is no possibility for adding custom operations to the Sawtooth CLI to interact with the custom consensus components.
- Configuring the solution for a public network use case where the list of validators may change often (switching their roles between being a block producer and a regular read-only/full-history node) based on the consensus mechanics was not trivial.
- Sawtooth does not have a solution for efficiently hosting the full blockchain history and efficiently serving it to clients. The default implementation in the Sawtooth validator gets quickly overloaded.
- As a result of the previous point, on long chains, new nodes are not able to sync with the network. After downloading a certain number of blocks, it fills all the available memory so the sync process becomes very slow and the fresh node never gets synced.
- On a longer time scale, a validator’s connection handling is suboptimal which leads to a crash due to growing memory consumption, which we eventually helped to fix in collaboration with the Sawtooth team.
Challenges along the way usually are not rare or unique, especially in relation to emerging technologies. We expect this and when problems arose we were always more than willing to tackle them. However, addressing the scale of the points highlighted above was something that we could not have foreseen when we embarked on our original journey. At some point, we took a pause to reflect and reevaluated whether our efforts were guiding us closer to our core goals.
We realized that if we were to continue building on Sawtooth it would require us to direct our energies towards improving the Sawtooth ecosystem itself so it can operate a network our use cases require rather than on our core development (Remme Auth and other PKI(d) apps). Given this reality, we concluded that the best thing would be to explore alternative blockchain options.
New platform for REMChain
Given the situation we found ourselves in, we started to evaluate alternative ways to finish our protocol layer and start building applications. One of the key requirements for us was the maturity of the chain’s ecosystem, with a desire for strong industry experience and support to shorten the learning path and avoid pitfalls. And most critically of all, there must be a proven operational track record.
After thorough consideration, we have settled upon the EOSIO codebase as being the ideal fit for Remme. There are numerous reasons why we have arrived at this conclusion, including the following:
- The EOSIO codebase is currently powering the EOS ecosystem, which is among the top known cryptocurrencies. As a consequence, it has been adversarially tested at a very high level and has significant industry recognition.
- Besides its economic characteristics, from a technical standpoint, EOSIO components have been tested and stabilized on the mainnet for almost a year. And even more importantly, it just works on a global scale, supporting hundreds of commercial-scale dApps.
- Designed to scale, EOSIO is capable of processing thousands of transactions per second, free rate limited transactions, low latency block confirmation (0.5 seconds), low-overhead Byzantine Fault Tolerant finality, hierarchical role based permissions, designed for Inter Blockchain Communication.
- Unlike Sawtooth, EOSIO offers various tools like block explorers, client libraries, mobile frameworks for developers, etc. All these make it easier to build, deploy and run apps on top of it.
- The EOS ecosystem has a tremendous developer community that expands the codebase towards every possible use case with strongly typed tech documentation. EOSIO repository ranked with over 10k stars.
- The fact that EOS and other tokens issued on the EOS blockchain have over $6 billion dollars market cap has further helped raise awareness and instill trust in the underlying EOSIO software.
For Remme, forking the EOSIO codebase begins with customizing it for our specific use cases and token economy. With REMChain being built on the EOSIO codebase, it will not depend on the EOS mainnet. So REMChain will remain an independent blockchain fueled by the REM token. Unique consensus features like masternode priorities, holding requirements (to have at least 250K REM) and staking will remain intact on the new chain.
It is important to mention, that with this change we will borrow the best aspects of the EOSIO consensus. From now on, REMChain will inherit the EOSIO DPOS consensus model, which will allow us to significantly reduce the amount of work that needs to be accomplished before launching the mainnet and at the same time achieve relatively the same level of decentralization that our previous consensus would have delivered.
In the following days, we will continue the series of blogs and will describe the differences REMChain is going to introduce compared to EOSIO. In brief, the changes will cover these items:
- In the new concept, a Masternode (MN) is now called a Block Producer (BP). To get a status of a Block Producer an accocunt has to stake minimum 250k REM.
- There will be no betting aspect in the consensus any longer. According to our new reward distribution model, there will be no need for it. What’s more important is that this will ease the process of operating a Block Producer node.
- The reward proportion (BPs receive for their service) will dominantly depend on the stake they own themselves.
- Unlike with EOS, there will be no inflation of REM token. As it was originally designed, the rewards will come from the commission users pay to consume different PKI(d) services the network will provide.
- REMChain will have a significantly easier resource economy model. Managing Network, CPU and RAM as separate resources on EOS blockchain has been proven to be tricky and cumbersome for newcomers. Unlike EOS, Remme use cases are not that broad, so we will be able to make resource management more straightforward from the UX and economic perspective.
Mainnet projections
Choosing to switch blockchains, especially this far into the development process, is a decision that didn’t come easy. We’ve carefully evaluated both scenarios (staying with Sawtooth and forking the EOSIO codebase) as well as timeframes which turned out to be about the same. We are certain that we have made the right decision for the right reasons and have every confidence that this will be borne out in the months to come.
On account of the transition to a new blockchain platform, it will take additional time to set everything up and thoroughly test our implementation. As a consequence, the Remme mainnet is now scheduled to launch in Q4 2019.
We believe that the advantages of moving to a faster and more scalable EOSIO codebase significantly outweigh the short-term time losses that this trade-off entails. Knowing that we will be building upon a codebase that is capable of growing as we grow, and providing ongoing support, is invaluable.
We’d like to extend our thanks to the Remme developer community for all their support, ideas and participation so far. We look forward to having you join us on this next stage of our journey.
Stay tuned for major updates on our consensus algorithm and new blockchain details which will be coming soon. Rest assured, the best is yet to come.
.png)
