Risk Management and Business Models on NEO Blockchain

Malcolm Lerider
The Neo Pulse
Published in
6 min readJun 17, 2018

Those of you who have joined a conference where I have been speaking, know that I like to emphasize that NEO is very different from other blockchain platforms in the very core. For those who have not seen any of my presentations; let me explain why.

The adoption of blockchain technology started with Bitcoin; a peer-to-peer electronic cash system. This is very important to keep in mind when we now are working on solutions for Smart Contracts and large scale decentralized applications. Proof of Work (PoW) is an algorithm built for that specific use case: a peer-to-peer electronic cash system. A few intelligent individuals have since then discovered that the same algorithms and protocols can be re-used for writing Turing complete applications. However, as mentioned, PoW was designed for Bitcoin’s use case, and not for running high performance Turing complete applications, which has been quite evident during the last year.

The focus to resolve this problem has mainly been to invent different versions of Proof of Stake (PoS). PoS is an attempt to mimic the PoW protocol, but by using token stake instead of hashing power. This saves energy resources and prevent 51% hashing power attacks, making it a valid option for use cases similar to Bitcoin that suffer from smaller network effect. By mimicking PoW, it is in core a variant of a peer-to-peer electronic cash system, that can still be used for Smart Contracts, but is in essence not designed for that purpose. It fails to fulfill requirements that are of vital importance for real world use cases. One of the main problems in both PoW and PoS is that they suffer from lack of finality in each block, causing both transaction delays and impossibility to implement use cases that rely on finality.

Figure 1: Chain in PoW and PoS

Both PoW and PoS has the possibility to fork during normal operation. Anyone who have ever transferred a token from one wallet to another, or from one exchange to another, have seen the implication of the forking possibility. You are able to track your transaction in a block explorer but need to wait 12–30 “confirmations” before the transaction is complete. Each “confirmation” correspond to a new block in the blockchain. The reason that you have to wait for confirmations is simply because these algorithms may fork during normal operation, and the receiver have to make sure that the transaction is included in the “correct” chain (green blocks in Figure 1) and not one of the branches that will be cut off (blue blocks in Figure 1). This is often referred as ensuring that your transaction is part the “longest chain”. Stating that block time is 5 seconds in a PoW or PoS algorithm is of little importance to the actual application. You need to know how many confirmations that are needed. If for example 20 confirmations are needed, then the actual transaction time will be 100 seconds in a blockchain with 5 second block time.

This is not only a problem in terms of transaction time. From business perspective, it is a risk management decision that has to be made. With x1 number of transactions and with estimated x2 USD value, can we accept that there is a x3 % chance that the transaction is not on the longest chain and will be rejected after x4 number of blocks?

Many use cases cannot even be implemented at all, especially when we discuss blockchain as a solution to build real world Smart Contracts. Take a regular IOU for example; the very core property of an IOU is that there only exists exactly one version of it. With branching and forking in PoW and PoS, that IOU will have multiple valid copies under normal operation; one on each competing fork. One IOU becomes two or more IOU’s. Even if the “wrong” block is rejected after the longest chain has been established, that status of multiplying the IOU is in itself unacceptable when working with this and similar financial use cases.

Figure 2: Chain in dBFT

In opposite to other blockchain platforms, NEO blockchain does not try to change a peer-to-peer electronic cash system into a Smart Contract system. The original blockchain architecture for Bitcoin is not built for Turing complete Smart Contracts; we need another architecture for large scale decentralized applications that fulfill the requirements from business and economic use cases. As such, PoW and PoS are both unsuitable. To meet the requirements, NEO Blockchain is built on delegated Byzantine Fault Tolerance (dBFT), an adapted BFT algorithm by Erik Zhang. The advantage with dBFT is that it cannot branch. There is always one and only one block proposed at any single time. Once the block is signed, it is 100% final. More information on the consensus algorithm can be found here:
http://docs.neo.org/en-us/basic/consensus/whitepaper.html

In practice, it means that you no longer need to wait for several confirmations when sending transactions or invocations. The transaction is completed directly after it is included in a block, in other words in one single confirmation. It also means that the transaction time is actually completely equal to block time; if block time is 5 seconds, then the transaction is received in 5 seconds.

Moreover, there is no risk management needed when sending and receiving large volume and high value transactions. With no branching during operation, all transactions are 100% complete after they are included in a block, so no risk analysis on finality has to be made. The transactions will always be on the correct / longest chain, since there cannot exist a branch chain in dBFT by the nature of the algorithm.

Moreover, IOU and other financial Smart Contracts can be implemented in the NEO blockchain without the awkwardness that it may exist in two branches at the same time. You can deploy the Smart Contract directly on the public MainNet or even run your own NEO blockchain as a private chain; it will still have the same behavior. Large scale applications will also need dependencies and triggers, where chained transactions become a necessity. Chained transactions without finality become very problematic both in terms of risk management and end-to-end time. This is especially true for decentralized exchanges, where we are very likely to see a very large amount of chained transactions.

Another disadvantage of weak finality blockchain is an issue that we have already experienced before, and more than once; the case of voting on special transactions. There will always be occasions where morality stand against “code is law”. One example is if a terrorist group’s wallet address is identified; shall it be frozen or not? Weak finality blockchains may split into two camps, one where the address is frozen and one where it is not. Perfect finality blockchains such as NEO will always only have one outcome, since there never is a simultaneous choice between two blocks.

Further advantages:
To help adoption, NEO Smart Contracts may be written in C#, Python, JavaScript, Golang, and Java; you will get up to speed quickly with the developers you already have access to. Training your team in a new programming language or employing a whole new team of dedicated Smart Contract developers are both very extremely expensive options. If you can cut this expense, then you have a much better starting point for building a profitable business model. The second obstacle to a profitable business model are high transaction fees, and this is the very reason why NEO blockchain has two native tokens: NEO and GAS. This ensures that transaction fees will always be close to zero, see this article for explanation.

Transaction speed is 1000–10 000 transactions per second and continuously increasing, with goal to reach 100 000 transactions per second on-chain before 2020. The plan is to achieve this by two parallel projects that has been running for over 6 months, called neo-sharp and HyperVM. neo-sharp is a re-written implementation of NEO Blockchain which follows the same protocol rules, but with a modular architecture that simplifies both unit testing and integration testing, while also allowing for upgrades of individual modules. HyperVM is a rewritten version of NeoVM, written in C++, which is a lower level programming language that allows for more flexibility in optimizing performance. Second layer scaling is being developed by third-parties and will multiply the transaction speed even far beyond 100 000 tps. NeoX, a cross-chain protocol that will allow sidechains and interaction between any blockchain using NeoVM, will enter testing later this year.

If you have any specific business requirement that NEO Blockchain currently is unable to fulfill, then please leave a comment. Our community is committed to make NEO blockchain the number one blockchain platform in the world.

--

--