A new framework for Distributed Ledgers or dare I say Consensus Computers (CC)
Robert Sams inspired this post. As we were discussing stacks (software, IT) and the draw backs of the bitcoin blockchain architecture recently in London, we slowly gravitated towards a new term and discussed the merits of modularity.
First, distributed ledgers or "blockchain" seem to miss the mark as descriptive terms and we gravitated towards the term Consensus Computer (CC). This new term makes sense to me. A distributed ledger, although strong and simple as it evokes a distributed state, seems passive. A ledger is by definition passive. What we have in mind is a system, a machine which is much more dynamic, and which, with the help of smart code, smart contracts to be precise performs dynamic tasks and handles discrete processes. A CC is much more elegant and includes this dynamism via the word "consensus".
All distributed ledgers need some form of consensus computation to update the ledger. This ledger updating needs to draw on a turing-complete mechanism in order to encode the business logic that will solve "real" problems. As such, the CC term shifts the emphasis from ledger state to how that state gets updated which is much more appropriate.
We then focused on how a CC stack should look like. Think .Net stack or LAMP stack or Java stack in software and you get the idea. One has to strive for a simple stack, modular and articulated across several easy to grasp layers which in the aggregate form the stack and individually layers. The advantage of such a construct is obvious: It is much easier to prosecute change management. Change a line of code or an object within one layer and other layers are not impacted. One perfect example is the bitcoin blockchain: No modularity here which is one of the reasons why implementing any type of change is such a pain and why change management is a non-trivial issue. Another added benefit to a CC stack framework is how it will facilitate standardization of business logic coding going forward.
Without further ado, here is the framework we came up with:
Smart Contract Layer: Think of this layer like the Java programming language. This is where the business logic resides and where smart contracts are coded.
Consensus Computer (CC) Layer: The analogy here is the Java Virtual Machine which delivers core functionality for the Java programming language, or maybe the Ethereum Virtual Machine (EVM). In other words, the layer that allows for portability of the code created at the Smart Contract layer. A loose analogy, still it helps creating the picture. The whole idea being having a programming language that compiles down to the CC layer level is to have code that is written without knowing what hardware architecture it will run on. The goal is to arrive at a point where different developers and starts focus on and write business logic at the smart contract layer, ported at the CC layer, which will ensure that any hardware difference between nodes will not cause consensus failures (see the consensus layer below).
Consensus Algorithm Layer: Easy to understand, how transactions get verified or confirmed. The cryptographic part of the stack.
Network Topology Layer: Bitcoin uses p2p broadcasting mechanisms. There are other mechanisms whereby nodes will communicate though.
Truth be told, Robert was advocating a three layer stack by collapsing the Consensus and Topology layers together and I chose to represent a four layer stack in this post.
I repeat myself here. Abstracting the framework of a CC stack is very important. Continuous innovation and core technology roadmaps that project in the future need to encounter as little friction as possible. Change is greatly facilitated with modularity. Replace one module, or change one layer without impacting the whole is the key here.
My take is we will gravitate towards several CC stacks, much like there are several software development stacks out there. Diversity is the spice of life. The Bitcoin stack was evolutionary stack v0.1. Ethereum may be evolutionary stack v1. Surely we should expect Ethereum to evolve along its own track, or maybe morph into different stacks depending on use cases and hacker eco-systems preferences. Surely we should also expect other stacks emerging in the near future.
It used to be that most people thought Bitcoin was it. As Ethereum is emerging out of its stealth mode, many are thinking it is it. I reserve my judgement as the evolutionary road to mature stacks is still unfolding. Fascinating times.
Senior Director, Data Management and Business Intelligence
9 年It is going to be very interesting to watch the development of block-chain (or distributed ledgers). It will be interesting to see if or when this would make inroads into internal corporate ledger processes. Would there be a possible business case based on cost or functionality? At the very least there will be a lot of FinTech start-ups that will be trying to disrupt anything they can. It should be fun.
Blockchain/Web3 Expert and Builder - Owner Aldeia IT - Summoner of Axé DAO - Working in Regenerative Cryptoeconomics: web3 + earth regeneration | transition-aware #ReFi #Regen #RWA #DAO #smartcontracts #ethereum
9 年Permissioned or permissionless would merely be an attribute or feature of the topology layer.
Partner at Strategy&
9 年Interesting framework indeed. Can the same framework be extrapolated to a permissioned distributed ledger by having the CC / consensus engine reside at a central verification agent, signing on updates/ transactions by various nodes and verifying before publishing in the ledger? Do we also need to have a translation layer at the bottom of this stack that integrates the ledger with existing applications / interfaces, and one at the top that affects the changes triggered by smart contracts and feeds back into the existing applications / interfaces?
?? (IP) Strategist ?? Quantum-Ready Real-Time Innovator ? Building Predictive Intelligence & Tokenized Ecosystems ? ??
9 年Fascinating indeed. Thanks for sharing!
Enterprise Architect - Allianz Technology
9 年I would separate the Smart Contract Layer in two layers: Smart Contract and Law. As the "old" legal contracts are made on existing laws that defined - for example - entities involved in the contract (companies, persons, ec.), type of relationships allowed by the law, etc., Smart Contracts can be done instantiate this basic "bricks" and building logic over them. The Law layer would be really the universal, portable, distributed layer. The Law layer can be connected, verified and certified against the actual laws, while smart contract are built upon it. Easier to build, easier to check, certified