OPEN Chain Security and Stability

Hello OPEN Community,

After releasing our End of the Year Update, we wanted to further highlight and provide more details on various important aspects of our technology. In this blog post, we want to touch on security and stability of OPEN Chain.

Security and Stability

Attack vectors are core areas of focus for OPEN Chain. As networks develop and mature, they also become prone to a variety of attacks that place the network and its participants at risk, affecting all stakeholders involved. OPEN is building a secure, scalable blockchain by adhering to security and scalability tests. By describing some of the potential attack vectors, we can begin to explore how OPEN Chain is tackling these problems.

Double Spending
A double spend can occur anytime a blockchain reorganization excludes a transaction previously included. This means that the witnesses had a communication breakdown caused by disruptions in the infrastructure of the Internet. With DPOS, the probability of a communication breakdown enabling a double spend attack is very low.

The network is able to monitor its own health and can immediately detect any loss in communication which shows up as witnesses failing to produce blocks on schedule. When this occurs, it may be necessary for users to wait until half of the witnesses have confirmed their transactions, which could be up to a minute or two.

Sybil Attack and Monopoly
Sybil attacks are another security vulnerability specific to peer-to-peer decentralized networks which are open and therefore allow anonymous entrants.  The main component of the Sybil attack comprises of creating a large number of pseudonymous identities. Once the identities are accepted as peers they try to gain control of the network and subvert the network from within. The network’s resilience depends on how easy it is to create an identity and be accepted as a peer. As there is no 100% fail proof firewall against these types of attacks, the best defence against Sybil attacks is to make it as impractical as possible.

Realization of attack in our network does not make sense. Creating multiple accounts will not bring benefits because the weight of the wallet and its credibility will affect the network.

Nothing-at-Stake Problem
The system locks all transactions of the delegates for their delegate period. If some delegate acted maliciously against the rules of the system, his stake will be blocked for a long period of time.   

Byzantine Fault Tolerance
If there are less than 1/3 in Byzantine voting power and at least one good validator decides on a block B, then no good validator will decide on any block other than B.  Consider the earliest round R where at least one good validator commits block B at round R. This validator received more than 2/3 of precommits for block B at round R. Considering that less than 1/3 are Byzantine, by arithmetic at least 1/3 of good validators must have precommitted block B at round R. These good validators must have a lock on block B at round R. No other block can be committed by good validators unless some of the good validators unlock from B, which is impossible.

Proof of Live
If there are less than 1/3 in Byzantine voting power then this protocol does not deadlock. The only way the consensus process can deadlock is if two different blocks had been locked by some good validators from different rounds (a rare occurrence without an active global adversary). Say that some good validators locked on block B and round R, and some good validators locked on block B′ at round R′, where R < R′. In this case, the proof-of-lock from R′ included in a proposal by a good validator will eventually unlock those validators locked on R allowing the consensus process to continue.

Privacy
Under DPOS, every stakeholder has influence that is directly proportional to their stake, and no stakeholders are excluded from exercising this influence. Every other consensus system on the market excludes the vast majority of stakeholders from participating. Only DPOS ensures that block production is evenly distributed among most people and that everyone has an economically viable way to influence who those people are.

Scalability
While the system is robust against natural chain reorganization events, there is still some potential for software bugs, network interruptions, or incompetent or malicious delegates to create multiple competing histories that are longer than a block or two. The software always selects the blockchain with the highest delegates participation rate. A delegate operating on their own can only produce one block per round and will always have a lower participation rate than the majority. There is nothing that any delegates (or minority group of delegates) can do to produce a blockchain with a higher participation rate. The participation rate is calculated by comparing the expected number of blocks produced vs. the actual number of blocks produced.

Memory Requirements
There are a few basic parameters that determine the scalability of the system:

T_slot  – time slot size in seconds;

E_rounds – a number of rounds for Active Delegates in one Epoch;

N_transactions_per_block – expected number of transactions that could be processed, organized in a block and approved by Delegates in one Slot.

If, for example, we take T_slot = 60, E_rounds = 8, N_transactions_per_block = 1000 and number of Active Delegates Na = 15, then the time Epoch size will be 2 hours and expected number of transactions organized in blockchain during one Epoch could be 120,000.

If we take that the size of one transaction would be 109 bytes, the size of the transactions blockchain for one year will be about 60GB with a total number of expected transactions 525.6 million.

Building a strong and secure network creates a better community and ecosystem for all. Stay tuned for details on our security and load testing in future blog posts.