Blockchain as a network stack

I’ve personally faced one constant problem in the blockchain landscape: the constant growth in depth and breadth of our technology, such that it takes a long time for even the tech savvy to get a good overview of the current landscape.

This article is by no means authoritative or complete, it is an attempt to use the Open Systems Interconnection (or OSI) model as a conceptual framework to better define the component parts of blockchain, with the hope that this can be refined further through discussion and comments.

6 layer blockchain model

The rapidly expanding landscape in the blockchain ecosystem can be overwhelming, many people are often lost in the vast amount of terminology and technology being introduced on a daily basis. This 6-layer blockchain model visualises the blockchain as a technology stack and classifies different blockchain technologies into broad layers in this complicated ecosystem, very much inspired by how the OSI model brought structure into understanding the networking stack.

P2P networking layer

This is the base networking and connectivity layer, allowing for basic operations like node discovery, robust sharing of dynamic node lists and network connectivity. Examples of such work include libraries like devp2p and libp2p which provide an abstracted node discovery and connectivity layer. Network level attacks such as man-in-the-middle and eclipse attacks would be potential concerns at this layer.

Base & scalability layer

In the traditional approach of Proof of Work (PoW) in bitcoin or Practical Byzantine Fault Tolerance (PBFT) in distributed systems, there is a single layer which handles the consensus mechanism, and this would be termed the base layer.

However, the push towards higher throughput and reduced latency, has seen the bifurcation of a single base consensus layer into a 2 layered approach. Bitcoin and its variants, the incumbent Ethereum chain and many privacy coins like Monero and Zcash provide consensus in the base layer, without a specific scalability layer.

This divide and conquer strategy allows consensus to be tackled at two levels, the synchronisation problem being handled by the base layer, while the performance problem is handled by the scalability layer.

The recent design of Ethereum 2.0 proposes a beacon layer, which can be seen as a base layer that ensures global synchronisation, and a sharding layer, which serves the purpose of a scalability layer. This occurs in Zilliqa as well, with the directory service(DS) committee being the base layer, and shards as the scalability layer.

Even in a PoS system, there is a need for a PoS monitoring to enforce slashing, which would require widely distributed monitoring of the network to prevent double-staking. Such a monitoring system can be perceived as the base layer, where the actual PoS consensus takes place as a scalability layer. DPoS consensus systems exhibit this behaviour too, where a mechanism for a large pool of stakers vote through consensus to choose the block creators as a base layer, while the randomised delegated block creators selection behave like a scalability layer in a tightly coupled network.

In all cases where the scalability layer exists, both base and scalability layers are tightly coupled to perform its highly-scalable consensus mechanism where;

• Base layer = ensure global synchronisation (preventive approach), or global disincentive (punishment approach)
• Scalability layer = transactions are processed in a localised fashion or with a much smaller network of block producers in order to achieve higher total throughput.

Logic layer

The logic layer plays the role of access control and execution logic. Bitcoin’s Script is intentionally non-Turing complete, ensuring no infinite loops can occur. Despite including functionality like a Poker Lobby in its early iterations, Bitcoin’s bias towards security and attack surface minimisation results in very limited logic layer capability through bitcoin scripting and the P2SH mechanism, which allows for a flexible mechanism to unlock UTXOs.

However, this was expanded to a full smart contract language with the introduction of EVM in Ethereum. The logic layer handles the deployment and execution of smart contract, as well as its associated state update. The logic layer is somewhat decoupled with the actual consensus mechanism, as can be seen by the wide adoption of EVM and EVM-based languages like Solidity and Vyper, which is the reason it is usually a pluggable mechanism in many blockchains with generalised states (see Substrate).

In the upcoming iteration of Ethereum 2.0, the EVM sandbox will be replaced by EWASM(an ethereum flavor of WASM), which will enable an even greater set of compilers and development tools that already support the WASM specification. This further decouples the consensus mechanism in the lower layers with the logic, which can be developed in a preferred language.

Storage layer

The storage layer provides decentralised storage of large binary files, mainly because storing large binary data as state data is not as efficient in most cases, and is usually treated differently. This is not unlike the BLOB kind of SQL data types which are generally treated different from data types use for storing meta information and fields.

One notable difference with typical file or document storage solution, is the integration with the adjacent logic layer, which allow smart contracts to interact with the binary data, query for binary hash or check the data version. Another typical feature, is having strong immutability and versioning properties, such as those provided by IPFS and SWARM.

Together with projects like Filecoin and Siacoin, which creates an economic incentive around decentralized storage, this allows for developers to have assurance around the long-term availability of the hosted data.

Peering layer

In addition to application specific chains in the application layer, an alternative method to manipulate user assets in a manner off the base chain (logic layer and below), is creating inter-locked transactions across 2 different blockchain. This usually involves some kind of binding into the logic layer of the connecting blockchains, and forwarding transactions or asset representations from one chain to the other.

The peering layer uses a similar concept to application layer to create a strong binding to the logic layer, but achieves the purpose of inter-chain compatibility, effectively linking multiple blockchains with potentially different base consensus mechanism together into a mesh. Polkadot and Cosmos are some examples of projects which operate in this layer.

Application layer

While B2C blockchain applications can be run if their distributed logic can be represented fully in the smart contract of the logic layer, there are certain situations where a higher application specific chain can be layered on top of the existing public infrastructure. This can be observed in the recent trend of layer-2 chains such as the various variants of Plasma on Ethereum, where a Plasma smart contract is anchored in the public Ethereum (logic layer), but an application-specific plasma chain serves a selected group of participants. Despite the smaller number of participants, the strength of such an application-specific chain is anchored in the consensus of its base consensus achieved via the base and scalability layers.

An application-specific chain allows for a few improvements over its anchored base, such as supporting large numbers of internal transactions which map to a single transaction in the logic layer, effectively creating a transaction ‘compression’ effect by reducing the number of state transitions and related fees, drastically improving effective throughput. This is an alternative method to improve throughput without altering the base consensus mechanism (as seen in the examples in the scalability layer).

Cryptographic primitives such as signing and hashing algorithms and execution primitives like EVM opcodes which are not supported in the logic layer, can also be supported in the application layer. The technology stack used for an application layer can be vastly different from the lower layers, including the use of permissioned or enterprise/consortium chains as an application layer.

In addition to direct participants of the application, there may also be a need for 3rd party ‘watchtower’ participants who will enforce integrity of the chain, on behalf of end-user participants who may not have constant connectivity to the chain. These watchtowers will also participate in the application layer.

For B2B use cases, the application layer also creates a wall of data isolation between this and the publicly accessible layers (logic to network layer), which might be necessary for protecting sensitive information, prevention of anti-competitive situations and compliance with data privacy regulations like GDPR.

Side-chains, state channels or payment channels can be seen as a specific subclass of application layer. Just like plasma, Side-chains and channel conditionally bind assets via the logic layer, and allow these assets to be manipulated and eventually returned to the logic layer. It also achieves the same transaction ‘compression’ effect and solves the scalability problem with blockchains that have slower consensus in its base layer. This subclass of application layer is notable due to its large number of projects, and its specific use case of enabling scalable payment on a slower blockchain.

Additionally, there are situations where highly sensitive or competitive business information or identity information need to be restricted and shared only among a smaller subset of counter-parties involved in a specific business transaction(eg. a business or trade deal). The techniques such as plasma or other application specific blockchains mentioned above, and also be used to ensure controlled visibility of information.

Alternatively, permissioned blockchains which were developed specifically to solve this problem, provides private bilateral or multilateral channels can be created among specific participants within the application layer, using features such as the constellation network in Quorum or multi-channel ordering in Hyperledger Fabric. Both approaches helps to address the problem of privacy, which stacked over the lower layers to harness the transparency provided by public blockchains.

Conclusion

If you’ve made it this far, it’s a safe bet you won’t stop reading here, so here’s some resources you can follow up on depending on what caught your attention.

If you’re curious about our specific implementation of a private/public blockchain model for use as part of an international commodities trade infrastructure, we outline it in detail in our technical white paper.

I speak more on my personal philosophy in this TEDx Talk.

And of course to keep up to date with Kommerce, sign up to our email list at https://mailchi.mp/kommerce/1.