Serious Issues With $NEO: It Does NOT Work!

Foreword

I did a mountain of research on $NEO. I won’t talk about Da Hongfei or relegate this to ‘rumors’ around the internet.

Instead, I’d like to focus on the issues with the codebase of $NEO itself and why it can’t work on a code level.

I think that’s the best approach because code = code and it says what it says. We can prove invalid code.

Now, let’s start with this Reddit post here (don’t worry, I’m bulletproof on this. I did real homework):

Some of the Major Issues Wrong With $NEO’s Blockchain Protocol

I found this post interesting when I came across it and I decided to do my research by reaching out to Cronje as well as the author of the post and other individuals that know how to observe blockchain code.

Remember when I kept putting up those posts about needing someone that can read and analyze blockchain code? Yeah, that’s what that was for.

Reaching Out to the Post’s Author

Responses received in relation to the code itself.

From the famous Andre Cronje; great code auditor and coder in the blockchain community.

Breaking Down the Major Flaws Here: Laymen’s Edition

This is a semantic issue (example: $BTC having a 1 MB block size + 10 min block time limits TPS; no way around that) meaning that this is immutable

I’m not sure it’s even possible to change the digital signature of a protocol without a major hard fork, and there isn’t an alternative digital signature (that I think of), that would make this any more secure.

Therefore, the consensus algo itself would need to be changed to amend this issue.

This, in itself, might be what stops $NEO from ever being able to truly scale.

I have not received responses from people asking for a semantic explanation as to why, but if I do then I’ll take the time to write one up specifically.

Digital signatures are somewhat complex, but not incomprehensible if you really take the time to sit down and understand it. Once again though, it’s going to rely on an understanding of blockchain tech as well to know how this impacts the signing feature of a TX itself as well as pub key creation

This still stands.

Regular PoW algos are already designed to be Byzantine fault-tolerant already

Source: https://arxiv.org/pdf/1703.04057.pdf

Byzantine Fault Tolerance is not an issue though. It’s actually really useful but for private blockchains.

DBfT (The Consensus Protocol That NEO Uses) is Not Designed to Scale!

That’s because Byzantine Fault Tolerance has been used for closed/centralized computing systems for ages like this academic article below shows:

http://zoo.cs.yale.edu/classes/cs426/2012/bib/castro02practical.pdf

Of course, in a decentralized protocol — something like that is very hard to achieve.

This was lightly touched upon by trustnodes (but they didn’t really get into this the way that they should have):

https://www.trustnodes.com/2017/08/17/neo-chinas-fake-matrix

Some information could be outdated, there are certain aspects of $NEO I didn’t look into because it’s not relevant to the core issue at hand that I’m discussing here. DYOR with that ^^

From that other whitepaper I posted, there’s an important excerpt in there, which states,

“At the other extreme, Hyperledger uses the classic PBFT protocol, which is communication bound: O(N²) where N is the number of nodes. PBFT can tolerate fewer than N/3 failures, and works in three phases in which nodes broadcast messages to each other. First, the pre-prepare phase selects a leader which chooses a value to commit. Next, the prepare phase broadcasts the value to be validated. Finally, the commit phase waits for more than two third of the nodes to confirm before announcing that the value is committed. PBFT has been shown to achieve liveness and safety properties in a partially asynchronous model [11], thus, unlike PoW, once the block is appended it is confirmed immediately. It can tolerate more failures than PoW (which is vulnerable to 25% attacks [26]). However, PBFT assumes that node identities are known, therefore it can only work in the permissioned settings. Additionally, the protocol is unlikely to be able to scale to the network size of Ethereum beacuse of its communication overhead.” <- Source: https://arxiv.org/pdf/1703.04057.pdf

Conclusion/TL;DR

TL;DR

1. $NEO codebase is virtually abandoned.

2. This is purportedly in favor of $NEO 3.0, but there’s no GitHub for $NEO 3.0 (at least not any that I’ve found).

3. The idea of it being able to handle 1000 TPS has been thoroughly debunked and it is virtually impossible (probably entirely impossible) for $NEO to create a public blockchain based on DBFT (essentially POS+BFT semantically), that keeps the same encryption signatures (which are probably the only ones that will reliably serve the purpose of crypto where collision resistance must be all but a guarantee).

4. There are actually several other issues in the design of this protocol that I have not even touched upon

The TPS issue is the greatest emergency though, however, and I don’t see any reconcilable means of settling that. Mix that up with the fact that the consensus algo makes it inherently inferior to $ETH (which I’m not even bullish on either) + the virtual abandonment of the codebase and it’s really hard to be bullish on $NEO.