NEO Smart Economy (R.I.P. AntShares)
Today we shift our focus to one of the more widely talked about cryptocurrencies over the past couple of months AntShares NEO! Last month (June 2017) NEO held a conference to announce some exciting news:
- Rebranding from AntShares to NEO
- Smart Contract 2.0
- White Paper 1.1 Release
Also noted in the article linked above, Da Hongfei (the founder of NEO) revealed the following:
- A collaboration with certificate authorities in China to map real-world assets using smart contracts
- A new patent for cross-chain distributed interoperability
- Their new startup partners Bancor, Agrello, Coindash, Nest Fund, and Binance, with more partner announcements to come
Whether or not the name change was necessary, the rest of the events listed above are steps in the right direction. Queue the Jimmie Schrute Rant, which I commend the NEO team for an appropriate response. Like us, many of you were probably introduced to NEO as the Ethereum of China. The comparison is due to the major hype and expectations attached to it when comparing it to the relatively established Ethereum ecosystem which has 3 years of progress already attached to it. There are certainly similarities to Ethereum and it is an easy way to think about NEO, but there are subtle differences that set the two apart in how they handle blockchain logistics.
Transforming Real-World Assets into Digital Assets
While NEO and Ethereum have similarities NEO's focus, as stated in their whitepaper, is to focus on Asset record keeping with e-contracts. Here is exactly what their whitepaper states:
Antshares is a decentralized and distributed ledger protocol that digitalizes real-world assets into digital ones, enabling registration, depository, transfer, trading, clearing and settlement via a peer-to-peer network.
Antshares uses e-contracts to keep record transfers of digital assets. In Antshares, digital tokens generated by e-contracts function as a general underlying data that could be used for recording titles and assets like equities, creditor’s claims, securities, financial contracts, credit points, bills and currencies, and can be applied for equity crowdfunding, equity trading, employee stock ownership plans, peer-to-peer financing, loyalty programs, private equity funds, supply-chain financing, etc.
The mission of the Antshares is about digital assets for everyone. Bitcoin wants to create a financial system parallel to the existing ones, whereas Antshares is about building a financial system bridging the real-world assets.
Again, this is similar to Ethereum, but Ethereum's whitepaper focuses on being an abstract, foundational layer for other projects to build their DAPPS on top of. Similar to an Operating System or Coding language, it abstracts away most of the work required to build and deploy on top of a blockchain. Whereas NEOs focus is on asset management and exchange. While the health of the NEO ecosystem will certainly rely on other products being deployed on top of it, this is an interesting focus that I believe will gain adoption within the Chinese government so that it meets their strict requirements, but more on that later.
Anticipated Applications of NEO
- CrowdFunding and Trading of Stock Equities
- Employee Stock Ownership Programs
- P2P Financing
- Credit Point Management
- Supply Chain Finance
- Issuance of fund shares and asset vouchers
- Evidence storage and financial contracting
- Commodity exchanges and foreign exchange trading.
There is also this statement sprinkled in amongst the whitepaper:
fiat currency can be directly used as currency on the Antshares Blockchain
Legal Status (i.e. Get the Chinese Government on Board)
Since it’s possible to use fiat currency directly on the blockchain, NEO goes a step further in separating itself from other technologies (cough...Ethereum). By arguing that shares (NEO) are NOT a digital currency, merely a blockchain protocol, NEO eliminates currency-related legal issues,excluding it from the definition of a digital currency.
I am no authority in Chinese sentiment or law (I know next to nothing about it), but it seems obvious that the government sees digital currency as a threat, specifically Bitcoin. NEO has been designed to work around these threats and fit into an approved government structure.
To be sure that it achieves greater government backing NEO claims to have built-in KYC (know your customer) and AML (anti-money laundering) API's. NEO also claims that if you lose your private keys, there is an asset-retrieval mechanism in place to reclaim the assets belonging to the particular address without help from a 3rd party.
Reason for E-Contracts
The NEO project is of the opinion that tokenization is flawed in its current form because:
The transfer of tokens is much like the transfer of money, that is, the tokens could be transferred from the sender to the receiver with or without the latter’s consent. This kind of transfer is fine with currency, which does not carry obligations, not with assets like stock equities and creditor’s claims that do carry complicated rights and obligations. Thus, the transfer on Antshares is conducted in the form the e-contracts. In most cases, the transfer of assets requires the digital signatures signed with the private keys from both the sender and the receiver. In certain cases, an extra signature from the issuer of the asset is required. Recording transfers of assets on the Antshares is merely an onchain solution of the transfer of offchain assets. There are no new legal relationships that parties could enter into, so unlike the tokenization, flaws in laws are eliminated.
With most ERC 20 tokens the receiving address has no say in the transaction. If an entity wants to transfer 20 tokens into wallet ‘x’, wallet ‘x’ has no way in which to decline the transfer, it is forced upon them by the code. This could lead to unintended consequences and unwanted asset transfers. NEO is looking to solve this problem so that entities do not unknowingly or unwillingly enter into a contract or asset they do not want.
Getting further into the focus of legalese, NEO very clearly states:
Real-world identity information is fundamental to confirm rights on real-world assets. In most circumstances, legally binding contracts require signature with autonyms as well.
While this authentication step is optional, when it is required NEO proposes that users apply for a digital certificate from a certificate authority. Much like signing a TLS certificate validates your website so that end users trust it, NEO is proposing a similar solution to identifying/trusting that the entities authenticate themselves, i.e. they are who they say the are.
Division of Labor
NEOs mission is "digital assets for everyone" so designing a system that is simple for people to use is of the utmost importance. To understand this let’s discuss how the blockchain confirms transactions, this is to introduce the different types of nodes that make up the NEO ecosystem.
- Bookkeeping Nodes
- Trusted parties that reach consensus to confirm each block
- Weak-Trust-Based Joint Bookkeeping (i.e. Bookkeeping Nodes digital signatures are included in each block)
- Full Nodes
- Run by service providers and store complete historical data as well as detect and relay transactions
- Users
- Light nodes or client access (i.e. web-browser or app)
- Are not required to download the complete blockchain history
Bookkeeping Nodes
Documentation regarding Bookkeeping Nodes is very minimal and the following topics need clarification.
- Voting process and cadence
- How often does this occur?
- How is each shareholder made aware of the options?
- Amount of collateral required to register
- I have seen references that point to the minimum amount of collateral being 1,000 NEO and this link tends to support this claim
- Definition of minimum technological abilities
- Is this even enforceable?
- Verification process
- How does one get vetted by a CA?
For those interested in contributing resources to the network (can't guarantee any reward yet), this Reddit post is a good place to start for a Windows deployment.
Consensus Mechanism
Practical Byzantine Fault Tolerance (delegated Byzantine Fault Tolerance, or dBFT)
I am sure this comes as a surprise to most out there and probably leaves many of you scratching your heads as to WTF all those words mean or why you care. I would also guess that most of you are looking for Proof of Work or Proof of Stake and asking, “okay so PBFT or dBFT exists, how do I mine that or get rewards for each block generated?” The answer will become clear shortly but let’s first breakdown what this Consensus Mechanism actually does and how it will interact with the blockchain.
Byzantine Fault Tolerance at its core is a fundamental problem of distributed computing. How do distributed nodes, who know nothing about one another and receive information at different times and in different states, come to a Consensus? i.e. how do we make sure assets (data) are valid, in the correct order, and ensure it’s recognized that way on every node across the system, whether that be 2 or a million? An example of how this works in the real world is with Clock Synchronization and time drift.
Every non-atomic clock in the world has a slightly different mechanism for keeping track of time and thus over time has a differing level of precision. This is true for wristwatches (mechanical, quartz, and digital) as well as computers. When you notice that your watch or clock does not match others, you typically check with a trusted or official source (unless you have an atomic clock handy) to adjust your time to fall in line with this trusted source. Computers are able to accomplish this by deploying an NTP daemon or service that is in constant communication with trusted NTP hosts adjusting the system time accordingly (slowing down the system clock if ahead and speeding it up if behind).
For distributed systems, time drift can be a nightmare and can cause cascading outages or various inconsistencies that are complicated to detect. In much the same way, if transactions (or assets in NEOs case) are received by Node 1 in a particular order (A,D,C,B) and Node 2 receives transactions in a different order (B,C,D,A), how do you determine which Node is correct and how do you defend against an incorrect sequence affecting the other nodes in the system?
Enter Practical Byzantine Fault Tolerance and in NEOs particular case delegated Byzantine Fault Tolerance (dBFT). The delegated piece to this title is key and should sound familiar to the watch analogy of going back to a trusted source. I could keep trying to get this point across using analogies or examples, but I think the following infographic will help drive home how this works (credit goes to Altoros blog):
If you are interested in more technical diagrams on this topic you can also reference the Hyperledger Fabric documentation or check out presentations on SlideShare, particularly slides 13-16 presented here.
Delegated Byzantine Fault Tolerance (dBFT)
NEO deploys a slightly altered version of PBFT by featuring 2 blockchain participants: Professional Node Operators (i.e. Bookkeeping Nodes) and the NEO Users. Each are given different controls in the voting process to determine election and approval. In an article published by cryptoinsider.com the co-founder of NEO is quoted as stating:
dBFT’s on-chain voting process dynamically votes in/out transaction validators and allows for universal consensus mechanism on public/permissionless and private/permissioned blockchains.
“Specialized bookkeeping nodes” achieve consensus in a dBFT blockchain thanks to “delegated voting.” Two-thirds approval is needed among nodes to approve a new version of the blockchain. This system, proponents say, protects against forking events, radical changes to the implementation of a blockchain system that can undermine participant confidence.
“After investigating and studying the crypto-industry and blockchain technologies for several years, we came to the conclusion that the delegated Byzantine Fault Tolerance alternative (or dBFT) is best suited for such a system,” Erik Iz, co-founder and core developer at Antshares, stated. “It provides swift transaction verification times, de-incentivises most attack vectors and upholds a single blockchain version with no risk of forks or alternative blockchain records emerging – regardless of how much computing power, or coins an attacker possesses.”
Going back to the NEO whitepaper we also find the following proposal to determine what nodes are elected (i.e. trusted and predetermined) to perform joint-signature confirmation of the blockchain.
Should the One Man mode be considered post-event voting (adding blocks) thus to achieve consensus, the Joint mode is about pre-event decision to generate bookkeeping nodes with certainty. No post-event voting, no uncertainty. In a public blockchain, this kind of pre-set decision could be made with an onchain election. The elected bookkeeping nodes may perform joint-signature on every new block generated. That is to say, in the post-event voting scenario, more confirmations, higher the probability, whereas in the pre-event decision mode, confirmation leads to the ideal simultaneous finality of a trade.
This is a logical argument for electing bookkeeping nodes, but later it appears to indicate that the ability to become a bookkeeping node requires identification and meeting a bar of technological capacity. I may be reading too much into this statement since voting for bookkeeping nodes will clearly be affected by reputation, but I'm concerned having to meet a technological capacity will harm adoption by setting too high a barrier to entry. Logically, if one does not meet some level of knowledge their ability to maintain a node will show and reliability will fall, which would hurt their reputation and in turn hurt their chances of being elected as a bookkeeping node. There also exists a possibility of a cartel pooling votes to gain bookkeeper nodes, so the voting mechanism needs to take this into account, but I will stop overanalyzing this here and save that for another day. Long story short, the network will require trust, which is a good thing, but this raises the barrier to entry. Here is the snippet from the white paper.
In the One Man mode, post-event voting (adding blocks) is about voting on the content of the block, not about the generator of the block, making it suitable for a public blockchain with no identity information. However, in the One Man mode, the finality of a trade is rather weak, making it inappropriate for financial trading. On the other hand, the Joint mode introduces weak trust on the bookkeeping nodes, i.e. to believe that no major (1/3 or more) number of the bookkeeping nodes may gang up and do evil. This requires identity authentication of the controlling parties of the bookkeeping node to some extent, for one thing, to judge on their reputation and technological capacity, for another thing, should the nodes do evil, cryptographic evidence will be available for investigations. This leads to the conclusion that Joint Bookkeeping is suited for public blockchain with identity information or for Consortium/Private blockchains.
We could conclude that the One Man mode chooses Anonymity, and is trust-free on any node. But that comes with the price of consistency and finality. While the Joint mode is advantageous over consistency and finality, it requires nodes to authenticate themselves to achieve a weak trust from other nodes.
Part 2
We hope that this provides a good introduction into what NEO is trying to accomplish and how it will do so. Part 2 dives into the Economics and analysis of the NEO blockchain and is more focused towards traders of the currency and how the blockchain rewards will affect them.
Tip Jar
- Bitcoin - 1CFSxj1dy4a9B4ZYwvDmdds8zB3unNSW2t
- Litecoin - LZxBp3QAZ2SDheN8FaRVHg4nuWPnWAQSdP
- Ethereum - 0x009561fC7CF8656c53EB0874c601DC359E40f76f
- NEO - ANwvg4giWPxrZeJtR3ro9TJf4dUHk5wjKe
- Dash - XkAGSD83Mb9TD4whTeJ6SQawBh56WjwUEM
- Ripple - rEfV4j3Jhzj1BW8948ePHTPEnqCf9cxt7w
- IOTA - YMPFQWXQYHT9DDJVGDGY9SNCSB9F999UDAVWLGXGEIBPHUXJYHQDVWMFFWCTSUTMIUDFNQIBUTQUJGSWZCKMHUOKTB