As our ICO adventure ended with insignificant results, we’ll illustrate the technical issues we had with Ethereum while creating our extra data privacy layer, and we’ll explain our move to a new blockchain.
A. The Past
1. Difficulties to get real time events from smart contracts.
Events and logs are the usual way to get some informations out of the smart contracts. They use archaic syntax without genericity or strongly typed event (link). They also proved to be very slow, even when the filter (the where condition for events retrieval) did not match anything. There’s a PR pending review/merge that replaces the event filtering to a different mechanism #14631 (link).
Currently they use Bloom Filters (link) through their package BloomBits (link). Bloom Filters have been there for years (link), implemented in Elastic Search since more than 5 years, for querying distributed data. It seems the Ethereum project development team implemented this regular data structure optimization after 3 years (publicly announced in DevCon3).
2. The costs of running complex smart contracts
For our extra layer, we can’t really expect to be able to load complex code into solidity language for a while. Our code would use too much data which is extremely expensive on Ethereum (It’s 400 millions time more expensive than in Amazon Cloud (link)).
The gas cost also is a real bottleneck, especially with complex data structures. We found several data structures transformations (link) to get the gas costs down by an order of magnitude of 10 to 100. However we really depend on how the Ethereum team delivers an efficient EVM next year. For very basic operations, such as online gambling (throwing a dice or giving a black jack hand) the Ethereum transactions costs are between $1 and $5 (link) (July 2017), probably 50% to 100% higher at today’s Ether prices. It’s totally impossible to maintain a real time infrastructure for micro-services with that level of costs, and the raiden network (link) framework isn’t solving most of the basic transaction patterns we have designed.
3. The abscence of modularity in the EVM
Altough the Ethereum Yellow Paper is technically brilliant and innovative, we don’t see the correlation of the current multibillion Ethereum market capitalization with a constant velocity in the technical architecture innovations brought by the Ethereum team. We are mostly constrained as an ethereum ecosystem contributor to write a new DAPP (distributed application) and wait for Ethereum to update the EVM scalability and gas cost. We would have hopped for a more modular approach, allowing us to submit new modules, as announced in the original Ethereum White Paper goals (Philosophy: modularity).
4. About our general impression while exploring the Ethereum code base
We could wait for the Ethereum team to solve the 3 issues above, but we think the community is still many years away to get a clean and stable platform.
The issues we discovered:
- API breaking changes in code history
- purposely crippled APIs (e.g. key export)
- lack of indication of deprecation of APIs and especially older repositories
- lack of clarity about API layering
- lack of feature parity after years of development
- mutability not well managed
We believe Ethereum is a mismanaged project with people involved not aligned in recognizing that. We don’t think the Ethereum Foundation or any of the people are overtly dishonest, but there’s an elephant in the room that is not being acknowledged.
5. About the ICO phenomena
Scam ICOs or even just legitimate failures are effectively externalizing the cost of their lack of quality to all the projects which do spend efforts on that. These tokens all share mind share. The rest is marketing, as we already explained in our previous blog post (link).
In conclusion, we think the Ethereum development team have too much talk of potentialities and too little internal critique, it’s a form of technical debt that goes unaccounted.
B. The future
We chose to move to more open platforms where our target architecture will be easier to implement. We identified Cosmos Network as the right candidate. Cosmos Network is based in Tendermint infrastructure.
1. Introducing Tendermint
Tendermint is another ambitious platform for distributed ledger solution for machine state replication on a distributed network. It aims to apply the BFT research (achieving distributed agreement over a compromised communications network) in a Proof of Stake public blockchain. All this at a time when ethereum is also developing its own version of proof of stake i.e, consensus by bet. However they differ in some design goals. Casper favors availability over consistency in comparison to Tendermint.
1.1 Why machine state replication ?
The purpose of a consensus algorithm, in general, is to allow a secure state update according to some specific state transition rules, where the rights to perform the state transitions are distributed among some cost-effective set of nodes.
1.2 The CAP theorem
CAP Theorem states that a distributed computer cannot simultaneously provide consistency, availability, and partition tolerance. This theorem is fundamental in understanding the design of distributed database solutions. Distributed systems cannot sacrifice Partition Tolerance (link), which is about allowing failure in the network message delivery (through network failures or nodes failures).
Tendermint differs from Ethereum in their approach of the CAP Theorem. Ethereum Casper favors availability over consistency while Tendermint is doing the opposite. Similarly, HBase favors consistency over availability (Cassendra), and is preferred for big data analysis while Cassendra is better on large interactive real time datasets (link).
1.3 Availability vs Consistency for Rockchain
Tendermint is more suited for cases where participants behave with some commun trust, where the chance of an attack on the blokchain is lower. It is perfect for consortium of companies in private / hybrid blockchains, where most of the participants act non-maliciously most of the time. The validator punishment rules are less strict. This is the case in most of the Rockchain use case scenarios.
1.4 Using Ethereum features on Tendermint
Cosmos Networks ABCI wrapper allows Rockchain to benefit from optimized Proof of Stake features while the Ethermint features allow Rockchain to keep the high level features of the Solidity smart contract languages (although in most of the basic cases, for access rights definitions between DappBoxes, we don’t need those).
2. Deploying Ethermint on our private cloud
Deploying an Ethermint private testsnet is a pretty straight forward process.
Check our next blog to get the technical details of our deployment.