IOST: Building a Better Blockchain

IOST: Building a Better Blockchain

Recently, a lot of people have asked me, “What does IOST want to achieve?”

It’s simple — the goal for the R&D team is to create a better blockchain application platform.

We want to focus on fixing issues that exist in current blockchain technology and in doing so implement our own solutions that we consider necessary for a successful blockchain application platform.

I want to offer an insight into what we take into consideration when we’re building IOST, talk about what we’re going to do about them and why we do the things we do.

1. The tech we have chosen to develop and why

Naturally, the first question is why we have selected PoB as our scaling solution and why we are developing at our current rate. For all current projects and research, we often see 4 common solutions for scalability: voting, sharding, DAG, and Layer2 (commonly referred to as “off-chain”).

What is PoB, and why have we chosen PoB

PoB is a branch of voting and Proof of Stake. 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 centralized, 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, in order to avoid Sybil attacks, we still utilize a pledge-plus-vote model in the first layer. Implemented and secure public blockchains are branches of either PoW or PoS, and hash power or tokens are still the only access mechanisms to a secure blockchain. All other forms of consensus still face security issues.

PoB is a branch of PoS, the first layer entry requires token-based authentication, requiring a pledge of tokens and accumulation of a certain amount of 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 will achieve two goals:

1. the committee will forcefully enact swift transformation in order to realize better decentralization.
2. we will encourage nodes to make contributions to the network through friendly competition.

To achieve these goals, every trusted node will receive a reputation score — “Servi”. Servi can only be accumulated through verified transactions, packaged transactions, and other network actions.

At the same time, authorized tokens will be exchanged during every time cycle into Servi at according proportions. It is only through the competition created by the consumption of Servi that a node can compete to become a committee member and take part in consensus. Nodes that are elected to the committee will receive reward tokens from the fund.

We will 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.
2. All members must make contributions to the network to receive more Servi, so that the chances of being allocated node incentives increase.
3. Unlike the EOS DPoS, a supernode will not be penalized for inactivity.

Voting is the most direct and, as of right now, the only appropriate scaling solution for large-scale commercial application blockchains. Whether or not a node achieves “super node ” status isn’t the most important factor. Shrinking network scale in order to achieve faster consensus and encouraging nodes to increase computing performance for better incentives is effective.

Off-Chain Solutions, Sharding

Whether it be Lightning Network, Ethereum Plasma, or other emerging new technologies, the general focus is shifting from storing all data on the blockchain to gradually solving issues off-chain.

Off-chain scaling solutions will be able to solve scalability issues in certain circumstances such as processing low security data or small transactions. It is worth noting that off-chain scaling is not all-powerful; loss of data could lead to serious consequences and 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 “second layer scaling solution” to perfecting our main blockchain.

Sharding is also a PoB-based protocol scaling solution. At our current development rate, we also view sharding as a second layer solution. We have done a lot of research and tests on sharding technology, and no matter what the solution, an inevitable issue is that we have to fragment the network. Although this results in impressive numbers, it will drastically lower security.

Blockchain network users must be accumulated continuously. In the early days of our launch, we want IOST to remain pure and simplistic while maintaining security and stability. PoB itself is enough for this initial period, while sharding technology will be developed and continuously updated on our beta network.

Why we don’t use Directed Acyclic Graphs (DAG)

We have done a lot of research on all current DAG related technology, and as of right now, there is no mature and implementable solution.

There are also two more reasons why we did not choose a DAG structure:

1. DAG sacrifices consistency, which results in unavoidably high latencies which do not meet the requirements of our goals.
2. DAG sequences under eventual consistency, which, under extreme circumstances, lead to a computational overload for nodes.

2. Considerations when building IOST

We’re building a blockchain that supports smart contracts which create a decentralized computer with credible and verifiable data. The “computer” is only limited by its performance, so the higher the performance, the better we are at hosting a diverse ecosystem of applications. Specifically, the 3 categories we use to assess performance are as follows:

High Throughput Rate

By far the most mentioned indicator, it 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, we’re also ensuring optimized performance for all tasks in all kinds of situations including network attacks or unstable internet connectivity to name a few.

At the same time, we’re prioritizing throughput rate of single contracts as opposed to 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. However, since the networks are separated, when it comes to single contracts, implementation can still only happen on a single network. In this sense, the throughput rate has not increased.

Low Latency

Low Latency generally refers to the time between the initiation of a transaction and its confirmation. Often overlooked, it is an important indicator related to performance. Higher latency on a transaction-based blockchain network is acceptable, but with IOST, we aim 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. Our expectations for a blockchain application platform does not stop at carrying out simple transactions, it is inevitable that we will run into many complex contracts. As such, we select virtual machines that can handle the load of large-scale applications, not just boast a pretty number for simple transactions.

IOST: faster than Ethereum more decentralized than EOS

Decentralization is the foundation of credibility for blockchains, so we are also working to ensure a certain level of decentralization. EOS was a starting point for blockchain application platforms, with the EOS DPoS mechanism striving to maintain node stability. However, with no rewards in place for voters, anti-bribery efforts decrease the incentives to participate in elections and voting. With little room for change within the council, EOS remains highly centralized. At the same time, 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 “the blockchain” loses some of its purity and simplicity.

IOST is being built so that it will remain a blockchain in its purest form and maintain the essence of blockchain technology. The following are are considerations for achieving this:

Security is Paramount

Security is the foundation of blockchain. Corruption and data loss are the last things we want to see happen on our blockchain. This is why we will ensure that IOST security matches or exceeds that of other mainstream public blockchains.

There have already been multiple issues with Ethereum’s contracts that led to serious consequences. Although we could blame that on the negligence of developers, we think it is more important to run stricter inspections and have a more intuitive interfaces that lower the possibility of errors from developers.

Flexible Access and Update Mechanisms

A good public blockchain is like an operation system: aside from high performance, it must be accessible to users and developers.

Access to accounts and contracts are defined by flexible functions. For example, you could define an election for a proposed update set by developers for the first 3 days to gauge if it will be accepted or not. IOST has created a possibility of consensus for developers on the contract level, which makes the contract insanely badass ( read: 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.There is a higher barrier for registration, which results in an underperforming blockchain ecology. Boiled down to the essentials, this is due to the EOS RAM mechanism.

A high throughput blockchain would naturally lower costs, and the mechanisms we build will allow resources to fall into the hands of those who truly need them. We want to ensure 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 implementing a platform that is easy for developers to build on is high priority.

Programming Language

We want to use the most popular and accessible languages for developers, so C++, Haskell and the like will not be our target languages.

3. Our Development Roadmap

With the release of our first IOST Public Beta in June — Everest v0.5 — we realized a comprehensive blockchain framework and a preliminary verification for Proof of Believability (PoB).

Right now, our team is in the rapid development of the second public beta. With the foundation set in our first beta, we will be rolling out two more versions of public beta and are continuing to focus on optimizing PoB, stability, new features, economic models and the confirmation of other mechanisms.

In other words, for the remainder of this year to Q1 of 2019, 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 implementation of sharding solutions.

More specifically, implementations in the next public beta include:

1. Perfected code modules, increased basic performance and stability
2. A flexible functional access system
3. More confirmed details of PoB
4. The first Economic Model proposal
5. Moving the virtual machine to V8
6. Resolved issues of malicious nodes and other security enhancements
7. A restructured P2P network module
8. implementation of missing basic functions, such as event mechanisms, more RPC ports, etc.

4. Conclusion

Blockchain technology is still in its early days, and aside from the constant discussion around consensus, there are many areas that still require research, testing and development.

This article was written to allow those interested in IOST and blockchain technology to know what we’re working towards. We’re confident IOST can become a blockchain application platform that can truly deliver blockchain technology into large-scale utilization.

There are many technical details yet to be confirmed, and many improvements and innovations we have made that could not be fully demonstrated in this article. In the following months, we will continue to detail our specific designs and solutions in addition to our deeper considerations for the development of the IOST network and the blockchain ecosystem as a whole.