Our Journey to Find a Blockchain for Our IoT/Smart City Infrastructure.

Prasaga Official

Aug 4, 2019·6 min read

Originally written by Michael Holdman, Founder & CEO of Prasaga

A list of criteria developed during our R&D.

Following is the list of criterium we developed while reviewing as many Native chain White Papers as we could in our exhaustive search for a Blockchain to utilize with our IoT/Smart City messaging bus infrastructure. To quantify, last benchmark on our message bus produced 250,000 concurrent connections sending 60,000- 1k uncompressed XMPP (XML) messages per second (~20ms latency on average added to internet latency) utilizing a 2x4 core with 16gb ram and 10gb NIC (that is extremely fast and very efficient for non-techies).

After thereview of every major chain and project that is publicized, we could only come to one conclusion that, although many revealed innovations, none of the projects meet our specific project needs.

Our Blockchain and Smart Object Model Technical White Paper’s which have been released (both public and under NDA) over the last few months, address each of these issues with a solution, not just a statement that “we will get to it someday”.

For everyone that reads blockchains solutions out there, here are the basics we felt were necessary and to look for:

1: If they claim that they are secure based strictly on signatures of the blocks, then they are ignoring what happens if a majority of keys get compromised.

2: If they claim they are using randomness, but their random source looks like an Oracle external to the chain (such as a TPM, or other hardware), then it likely can be beat with “grinding” (searches for random values that are beneficial to the attacker).

3: If they claim they are sharding, isolating, network sharding, etc. and do not have a means to rebalance among their shards for the variation of the load of transactions, then they do not have a viable model for smart contract execution pricing (i.e. gas pricing)

4: If they claim they are hybrid PoS+PoW, but they do PoW by first randomly selecting using PoS stake weighting, from a small number of nodes, then the PoW does not include enough hashpower to be a significant barrier if the keys are compromised.

5: If they do not address partitioning then likely they fail under real world Internet conditions, except when co-located in data centers.

6: If they claim they are using PoS but generating blocks at a fixed rate, and ignore the fact that an attacker, even with legitimate keys, can simply generate them much faster, they do not have a secure chain.

7: If they claim that should a partition or fork occur, then an external decision outside of the blockchain needs to be made, they are centralized.

8: If they claim all participants need certificates, they are a permissioned chain depending on the security of a certificate authority. Not necessarily a bad thing, but they then need to address their means of authentication, and how this is not a completely centralized system.

9: If they do not consider their token economics beyond a genesis event, they are a simple deflationary chain, which will eventually become useless as a currency for a means of commerce.

10: If they use a decaying or flat incentive model permanently, then they also are not moving towards a currency. Further, if the model depends on miners earning incentives, and are not able to be profitable without those, then the system is basically for the miners, and no one else.

11: If their solutions do things like take small pieces of work to handout to worker nodes, then there is an inherent trust between the worker nodes and the controller node. The controller node becomes the attack surface. If there is no independent means for verifying the controller node, again other than the keys, they become an attack vector.

12: If the block validation consists of a single validator or maybe one backup, with no incentive to actually do the validation, they are depending on social pressure only, and an adversary can easily do at least a DOS.

13: If the claim is that an invalid block or fork will “never happen, with very low probability”, and there is no means to recover for when this even eventually does happen, they will eventually fail. One interesting thing in software is that if an event can happen, it will happen eventually. Further, the dependency on the “oracle” randomness sources pretty much guarantees that an attacker will grind the random values and create such an event.

14: If the design requires that all nodes run a single version of code, the one true code base, signature verified, then any malware that succeeds will at least do a DOS. Thus, a successful blockchain design must not depend on the coding implementation, and instead be based strictly on the inter-node protocol.

15: On the more obvious side, if the blockchain design limits the number of validating/mining nodes to a small number that are selected in any sort of centralized or group centralized (i.e. oligarchy) means, the opportunity for collusion is boundless.

16: If the design makes the assumption that dishonest/byzantine nodes can never collude with each other, and uses this coupled with a randomized selection process, as the means to prove that the blockchain won’t be subverted, then if this assumption is wrong, that is, if there is collusion (e.g. a backchannel between the nodes), do all the security/safety assumptions fail?

17: If the design uses some form of sharding or similar approach for scalability, what are the mechanisms to prevent an attacker from placing multiple conflicting transactions on independent shards?

18: If the design uses some form of sharding, for cross-shard communications, does it use a 3rd chain, such as a “global or beacon chain”, and if so, what is the model for making sure there are sufficient nodes to secure this 3rd chain?

19: Further on the cross-chain communications, given multiple shards, what is the rate that the 3rd chain can manage the interactions, does it become a bottleneck following Amdahl’s distributed computing limit model?

20: Further on the cross-chain communications, if the 3rd chain goes down (i.e. network partitioning), do the chains hang? or create an opportunity for doublespends?

21: Given that the nodes register their public keys, what are the mechanisms to prevent masquerade attacks where a single node registers as many different nodes, with different keys? What is to ensure that the chain actually is decentralized and not controlled by a single adversary?

22: If staking is used as a means to verify the nodes, and for any part of the PoS weighting, if the requirement is the total stake is used strictly for the verification/PoS, how does the staking coin relate to any external value (i.e. other coins)? Further, how does the blockchain design support a coin for transactions, if it does at all?

23: If staking is used, and the coin is also used for regular transactions, how is the amount to stake a node determined? If the stake is used as weighting for PoS algorithms, which increases the likelihood of earning more coins and increasing the stake, how is the strong tendency towards centralizing to a small number of nodes controlling large amounts of stake managed?

24: Given that it is highly unlikely that any given blockchain design will never need to be modified after it is deployed up and running (“MainNet”), what are the mechanisms to update the blockchain without requiring a hardfork to modify the design and a new coin (and related coin swap issues)?

25: If the transaction throughput is measured in transactions per second (TPS) only, it does not take in to account latency. It is possible to have a very large TPS but have a large latency on a per transaction basis. Need a per-transaction throughput number, not just TPS.

26: Given a PoS, how is the nothing-at-stake problem resolved?