Hi, I’m Colin Platt, co-host of the Blockchain Insider podcast, and a cryptocurrency and distributed ledger researcher and specialist. This is the third in a series of cryptocurrency/blockchain posts that explore some of the topics that Zeth, Shaun and I found interesting and worth exploring further. As always we hope that you enjoy this series of fortnightly posts, and welcome your feedback.

Note: Nothing in this post should be construed as investment advice, or a recommendation of any particular project.

In the last post, we spoke about permissionless, or public, blockchains and their user numbers. Today we are changing tack and looking into the world of enterprise distributed ledger technologies.

Before diving in, it is worth noting what –and why– enterprise distributed ledgers exist.  Though maligned by some as simply marketing terms for distributed databases that sought to cash in on the blockchain hype, distributed ledgers have begun to evolve and mature into no-nonsense codebases designed to meet the needs of large-scale enterprise technology implementations. I stress “begun” here because the job is still incomplete, and as we know, enterprise technology stacks –particularly those relying on distributed networks– tend to move at a different pace when compared to the “move fast and break things” world of technology stacks used, for instance, in consumer web and mobile applications.

This relatively slow maturation process has also revealed a disconnect between the vernacular used to describe these technologies (“permissioned blockchain”) and the reality of what is being developed: distributed datasets, leveraging cryptographic primitives, where linked transactions are validated by a list of identified, or semi-trusted actors, and broadcast to a network of nodes. A mouthful, but hopefully it encapsulates the “what is it?” at a high-level.

The why is more straight-forward, permissionless blockchains (the ones with coins) are relatively expensive to run, throughput is (currently) limited, they rely on game theory for security, transactions can be validated (or not) by anyone, and there is no recourse for errors. This is fine for some use cases, but potentially poses issues for companies looking for the benefits of blockchains, whilst trying to remain compliant with regulations and minimise the risks for their business. In short, the desire for distributed ledgers is not born from ideological roots, nor is it reactionary response to a threat posed by cryptocurrencies, it is a rational decision based on costs and benefits, and it is certainly not a silver bullet.

Now we’re on to the who. There have been multiple attempts at building distributed ledger solutions for enterprise usage, from those attempts five projects have gained broader recognition: R3 Corda, Hyperledger Fabric, Hyperledger Sawtooth Lake, Enterprise Ethereum (including Quorum & Pantheon), and Digital Asset’s GSL.

Comparing these stacks, we look at several aspects in our cross-section of these technologies. Amongst these factors, one of interest to DLT geeks such as myself, is their architecture. I wrote a post about this awhile ago, have a look if you’re interested in details. TL;DR? There are two factors to consider when looking at blockchains, statefulness (stateless or stateful) and data diffusion (universal or selective).

1: Whilst the Corda ledger is stateless, Smart Contract state can be logged into the ledger
2: Additional Enterprise Ethereum implementations include Clearmatics, and Axoni but are not currently open sourced, and/or do not currently have plans to do so
3: Source: https://hub.digitalasset.com/digital-asset-platform-non-technical-whitepaper
4: Dependent on specific use-case requirements

As the table shows, there are still several large differences between the DLT stacks. While it is likely that some of these differences will disappear through convergence as they are put into production use, it will be likely that we’ll see greater entrenchment on other fronts.

One of these notable points is the smart contracting languages, currently there are three camps.  The first is the push towards purpose-built generalised languages, most notably Solidity (the main smart contract language used in the Ethereum public mainnet). The second, is a push towards greater abstraction of smart contract code, e.g., Corda uses a deterministic JVM.

The last moves in the other direction, DAML is a proprietary language, inspired by the functional programming language Haskell, which is specifically intended to not be Turing-complete. Though this remains a relatively new concept, smart contract bugs seen in public blockchains have demonstrated why this decision may be more suitable in some uses. In addition to security concerns, advocates say that these methods may be easier for less experienced developers to work directly with smart contracts.

Consensus mechanisms within enterprise distributed ledger technologies is an example of something that may converge over time as we experiment more in production environments, and a focus on settlement security (i.e. ‘assumed’ immutability) becomes more important than a simple focus on transaction throughput (arguably if this is your principal concern, perhaps DLT is not the optimal technology choice for your use-case). It’s too early to say which one will reign supreme, or if it will be only one model, but there seems to be some momentum gathering around PBFT-inspired algorithms as well as Notary-like mechanisms.

The final note that we’d make is the license for each implementation, Apache 2 has gathered a lot of interest amongst open-source implementations. Several aspects of GNU GPL 3 have shown themselves to be less desirable for enterprise implementation, including “copyleft” provisions. We might speculate that future implementations of Enterprise Ethereum specifically choose to not use GNU GPL 3 licenses, and perhaps even utilise Apache 2.

In summary, this is still an evolving space, but the phase of excessive hype with little progress seems to have passed, and projects have started to deliver on some of the promises made. It’s too early to see the full roadmap, but more things are becoming clear, and better communicated. Releases are becoming more stable, and now rarely even require a full rewrite of your code from scratch!

We encourage anyone looking at these technologies to share their own framework on how they evaluate these technologies, identifying their respective strengths and weaknesses.  Core development teams are always very happy to work closely with their community and jointly develop the project.

Hi, I’m Colin Platt, co-host of the Blockchain Insider podcast, and a cryptocurrency and distributed ledger researcher and specialist. This is the second in a series of cryptocurrency/blockchain posts that explore some of the topics that Zeth, Shaun and I found interesting and worth exploring further. As always we hope that you enjoy this series of fortnightly posts, and welcome your feedback.

Note: Nothing in this post should be construed as investment advice, or a recommendation of any particular project.

Last week we had the pleasure of attending the Blockchain Live conference in London’s Olympia.  The headline sponsor of this event was Block.one, the team behind EOS. EOS is a smart contract cryptocurrency platform, like Ethereum, which implements a delegated proof-of-stake (DPOS) algorithm. The Block.one team includes well known figures in the space including Dan Larimer (CTO), Ian Grigg, and Brock Pierce (Brock has stepped back publicly from the project somewhat). I was able to catch-up with Dan and Block.one CEO Brendan Blumer, you can hear that full interview on my podcast (bi.11fs.com). What was interesting for me was their relentless focus on two things: usability and developer adoption. While this is far from the ony project to realise that you need quality teams and projects in order to create a valuable proposition for average users, it is impressive to see how fast it seems to have come together. What really clinched it for me was a Tweet from Qiao Wang, Head of Product Messari:

Zeth and I first met at an early Ethereum meetup in London, in early 2015 in the months leading up to the launch of the mainnet, the excitement behind Ethereum at that time was impressive, and since we’ve seen a large percentage of new projects focussing in some way around Ethereum and Solidity (its native smart contracting language).  To see a new platform catch-up in a matter of months by daily active users across Dapps is exciting, and definitely worth spending some time on. Speaking for myself, I still have some unanswered questions about EOS from a technical point of view, but I am open minded.

Let’s start with Qiao’s point, Dapp daily active users on both platforms. Dappradar.com has lots of really interesting stats covering 944 Dapps on Ethereum, and 75 on EOS at the time of writing.  These cover figures including the volume in the base currency flowing through the projects, number of transactions and user stats. Projects are broken down into categories, covering things like exchanges, games, collectibles and more. Clearly the 2.5 year headstart that Ethereum has had shows up quite quickly in the number of Dapps (944 vs 75). When we looked at the numbers on 1 October, EOS Dapps collectively had 13,897 active users over the past 24 hours, whilst Ethereum Dapps showed 11,059 active users.  Interestingly, the most used Dapp on each network (PRA CandyBox on EOS, and 333ETH on Ethereum) accounted for a large number of total users, 5 085 vs 1 872, respectively. Some have also suggested that due to the design of EOS, which has low, or zero, transaction fees compared to many other networks, much of these numbers may be overestimated due to “transaction spamming”. We should note that EOS, unlike Ethereum, requires users paying an amount to create a new account (in RAM), which is currently about $1.00.  Even at this, developers coming from non cryptocurrency backgrounds accustomed to more widely adopted technologies will find these DAU numbers low, compared to for instance mobile apps, we concur.

What other numbers can we look at to monitor the success and growth of these networks?  Ethereum, is usually touted as the most widely adopted cryptocurrency by developers with some entities hinting at 250 000 developers apparently based on downloads of a popular open source developer suite (Truffle), though the number feels high. Smart contracts placed on the Ethereum blockchain, and processed by the EVM (Ethereum Virtual Machine) are written in a purpose built language: Solidity.

Looking at Github repositories, at the time of writing, there were 235 public repositories marked as having the Solidity language (though we’ll note that the language search functionality in Github is likely not comprehensive).

If we broaden the search to include Solidity anywhere, this showed a larger number of repositories at 7 359 public repositories. Whereas “Ethereum” returned 19 049 public repositories:

Another datapoint to consider, is that approximately 30 000 people list Solidity on LinkedIn.

While these are not perfect measures, they help give an idea of the number of developers and projects built on one of the most used smart contract platforms.

Beyond Ethereum, and EOS, there are several other smart contract platforms including Tezos, Rootstock.  Outside of the cryptocurrency space, companies like Digital Asset Holdings, R3 and IBM have worked to develop distributed ledger technologies which incorporate smart contracts targeted at enterprise usage.

Though the current numbers of users and developers are lower than the hype around the space would suggest, the growth in EOS over a matter of months shows the demand behind these platforms.  It will certainly be an interesting space to be involved in.