By Kevin Tan, Co-Founder IOST:
A lot of people have asked me about what IOST wants to achieve, and I think the goal for the R&D team is actually very simple: we want to create a better blockchain application platform. We want to do our best in fixing issues that exist in current blockchain technology, and hope to realize some of our own solutions in achieving goals we consider necessary for a blockchain application platform. So in this article, I want to start off with the issues that we’re focused on, talk about what we’re going to do about them and why we do the things we do.
1. What we’re focused on
Or, more specifically, what we consider when we’re building IOST:
A blockchain that supports smart contracts creates a decentralized computer with credible computing and data. The limit of said “computer” is determined by its performance, so the higher the limit, the better we can realize difference kinds of applications. To be specific, we can categorize performance indicators into 3 key categories:
- Diverse High Throughput Rate
This is the most mentioned indicator, and is also one of the most widely used measurement standards for new generation blockchains. However, our R&D team is not solely focused on maximizing the throughput rate, but also ensuring optimized performance for all tasks in all kinds of situations (such as attacks, or unstable internet connectivity, etc.).
At the same time, we’re also more focused on the throughput rate of single contracts instead of how many transactions a blockchain can process per second. For example, we could operate two Ethereum networks at the same time, resulting in a network with twice the throughput rate of Ethereum, but since the computing and status of the networks are separated, when it comes to single contracts, implementation still only happen on a single network. In this sense, the throughput rate has not increased.
- Low Latency
This generally refers to the time between the initiation of a transaction to its confirmation, and it is also an important indicator related to performance, yet it is often overlooked. Higher latency on a transaction-based blockchain network is acceptable, but for blockchain application platforms like IOST, we want to do our best to lower latency, and maximize the speed of feedback.
- High Performance Virtual Machines
The time it takes for different virtualization technology to perform the same tasks can vary greatly. As mentioned above, our expectations for a blockchain application platform obviously does not stop at carrying out simple transactions, therefore, it is inevitable that we will run into many complex contracts. We hope that the virtual machines we select perform well enough to handle the load of large-scale application, not just boast a pretty number for simple transactions.
We, of course, are also very focused on decentralization and security.
- More decentralized than EOS
Decentralization is the foundation of credibility for blockchains, so we hope to maintain a certain scale of decentralization on the foundation of expansion. EOS was a beginning for blockchain application platforms, and the mechanisms of the EOS DPOS strive for the stability of nodes, with no reward in place for voters while anti-bribery efforts decrease the incentives for elections/voting. With little room for change within the council, EOS remains highly centralized. At the same time, although some issues can be resolved under the forceful governance of EOS, since the data on a blockchain can be intercepted at any time by any organization, the concept of blockchain loses some of its purity/simplicity. We hope that IOST will remain a blockchain and maintain the essence of blockchains.
- Still Secure
Security is the foundation of blockchain, and the loss or corruption of data in the last thing we would like to see on our blockchain. This is why we want to ensure that IOST security matches that of all other mainstream public blockchains.
A good public blockchain is like an operation system: aside from quality performance, it must be accessible to users and developers.
- More Flexible Access and Update Mechanism
Access to account and contract is defined by flexible functions. You could always go back to false, indicating that a contract can never be updated; or you could configure the contracts to update, fork, or even rollback, so long as you meet the requirements of the function. For example, you could define an election, or update by developers for the first 3 days, which means that IOST has created a possibility of consensus for developers on the contract level, which makes the contract insanely badass. (OR: extremely powerful)
- Low-to-No Fees for Users
To a certain extent, EOS has realized the goal of going fee-free, yet we can see that at certain times, it is more expensive to develop on or use EOS than it is for Ethereum. Also, there is a higher for registration, which results in its current underperforming blockchain ecology. Boiled down to the essentials, this is due to the EOS RAM mechanism. We hope that a high throughput blockchain would naturally lower cost, and that the mechanisms we build will allow resources to fall into the hands of those who truly need them. We want to insure that paid usage, paid development, and other mechanisms can be applied to different blockchains.
- Developer Friendly
A healthy developer ecology is especially important to us, so we want to build a platform that is easy for developers to develop upon. This includes the following factors:
Security: There have been multiple issues on Ethereum’s contract level that led to serious consequences, and although we could blame that on the negligence of developers, as developers on a public blockchain, we think it is more important to run stricter inspections and have a more reasonable interface to lower the possibility of error for developers.
Programming Language: We want to use the most popular and accessible language for developers, so C++, Haskall and the like will not be our target languages.
Third-Party Tools: One of our goals is to continuously perfect our developer tools.
2. Our Development Roadmap
With our first IOST Public Beta, Everest v0.5, launched in the end of June, we realized a comprehensive blockchain network frame and a preliminary verification for PoB. As of right now, our development team is in the rapid development of the second public beta. With the foundation of the first beta, we are looking at two more versions of public beta, and will focus more on the perfection of PoB, stability, new features, economic models and the confirmation of other mechanisms. In other words, from the remainder of this year to Q1 of next year, we will focus on perfecting protocol stacks on individual fragmented internal chains. Throughout the next year, we will be conducting research on off-chain scaling solutions and the realization of sharding technology.
More specifically, what you’ll see realized in the next public beta are as follows:
1. Perfected code modules, increasing basic performance and stability
2. A flexible functional access system
3. More confirmed details of PoB
4. The first Economic Model proposal
5. After tuning and testing a mainstream virtual machine, we have decided to move the virtual machine to V8
6. Resolved issues of malicious nodes and other security enhancements
7. Restructured the P2P network module
8. Realization of missing basic functions, such as event mechanisms, more RPC ports, etc.
3. Why have we chosen to develop the way we do
Naturally, the next question is why we have selected PoB as our scaling solution and why we are developing at our current rate. As of right now, for all projects and research out on the market, we often see 4 common solutions for scalibility: voting, sharding, DAG, and Layer2 (commonly referred to as “off-chain”)
- What is PoB, and why have we chosen PoB
For IOST, PoB is a branch of voting. In the future, we will use sharding and off-chain solutions to further enhance our system’s throughput rate.
What’s worth mentioning is, although the EOS DPoS is relatively centralized, it doesn’t necessarily mean that voting is centralization, as for some traditional consensus mechanisms, only a single Leader has the authority to produce data within a time cycle. DPoS is just one of the solutions under the general voting scalability branch, so we could, to a certain extent, define the degree of decentralization as the distribution of block producers within a certain unit of time. The solution we have chosen in our current internal beta uses a layer 2 scaling solution.
Although we have selected PoB, but in order to avoid Sybil attacks, we still utilize a pledge-plus-vote model on the first layer. It isn’t hard to find that implemented and secure public blockchains are branches of either PoW or PoS, because hash power or tokens are still the only access mechanisms to a secure blockchain. All other forms of consensus still face security issues: are there possibilities of forgery, is the data centered, can it be verified that data-based consensus happens on the blockchain and not off-chain, can a new network node take part in the consensus, etc. PoB is also a branch of PoS, so first layer entry requires a token-based authentication, requiring a pledge of Tokens and accumulation of a certain amount authentication Tokens before becoming a “trusted node,” and authorized to take part in the consensus.
The second layer is the core of PoB, because it is on this layer that a production block committee is elected. On this layer, we hope to achieve two goals: 1) the committee will forcefully enact swift transformation in order to realize better decentralization, and 2) we hope to encourage nodes to make contributions to the network amidst friendly competition. To achieve the aforementioned goals, every trusted node will receive a point, aka the Servi. The servi can only be accumulated through verified transactions, packaged transactions, and such network actions. At the same time, authorized tokens will be exchanged during every time cycle into Servi at according proportions. Only through the competition of the consumption of Servi can a node compete to become a committee member that takes part in consensus, while nodes that are elected to the committee will receive reward tokens from the fund. We will also frequently hold committee elections, which will result in 1) elected committee members will have to consume Servi so that unelected nodes will receive more points and gain opportunities to be elected next time, and 2) all members must make contributions to the network to receive more Servi, so that the chances of being allocated node incentives increase. With the EOS DPoS, a supernode will not be penalized for inactivity.
Voting is the most direct and, as of right now, only appropriate scaling solution for large-scale commercial application blockchains. Whether or not a node achieves “super” isn’t the most important factor, but shrinking network scale in order to achieve faster consensus and encouraging nodes to increase computing performance for better incentives.
- Step Two — Off-Chain Solutions, Sharding
Whether it be Lightning Network, Ethereum Plasma, or other emerging new technology, the general focus is shifting from storing all data on a blockchain to gradually solving issues off-chain. This is one of the major directions we’re headed in for step two. We hope off-chain scaling solutions will be able to solve scalability issues in certain circumstances, for example processing small funds of low-security data. However, it is worth noting that off-chain scaling is not all-powerful; loss of data could lead to serious consequences, therefore, should still be processed on the main blockchain. On the coding level, a simple pledge model cannot compensate users who sustain real loss, nor can it match the true value of data. We see off-chain solutions as a step two scaling solution after overall perfection of our main blockchain.
Sharding is also a PoB-based protocol stack scaling solution. At our current development rate, we view it also as a step two solution. Although we have done a lot of research and tests on sharding technology, no matter what solution or advertisement, an inevitable issue is that we have to fragment the network. Although this results in prettier numbers, it will lower security drastically. Blockchain network users must be accumulated continuously. In the early days of our launch, we want IOST to remain pure/simplistic, while maintaining security and stability. PoB itself is enough for the initial period, while sharding technology will remain active and updated on our beta network.
- Why do don’t use DAG
We have done a lot of research on all current DAG related technology, and as of right now, there is no relatively mature and implementable solution. Aside from this, there are also two more reasons why we did not choose or research DAG structure: 1) DAG sacrifices strong consistency, which results in unavoidably high latencies which does not meet the requirements of our goals, and 2) DAG sequences under eventual consistency, which, under extreme circumstances, lead to an overload of computation for nodes.
4. Conclusion
As we see it, blockchain technology is still in its early days, so aside from the constant discussion around consensus, there are many areas that still require perfection. This article was written in hopes of allowing those who are interested in IOST and blockchain technology to know what we’re doing. We hope IOST can become a blockchain application platform that can be truly put into large-scale utilization. However, due to the word limit, there are many technical details that we have confirmed, and many improvements and innovations we have made that could not be fully demonstrated in this article. In the following months, you will gradually come to know our front-line researchers, and they will explain in detail, our specific designs and solutions in addition to our deeper considerations.