NEWS

Blockchain Standards Matter


Standards matter. They enable interoperability, the creation of ecosystems, and facilitate innovation.

Many companies, Zerado included, have remarked that Blockchain resembles the early Internet. There is a fierce debate whether Blockchain resembles 1993 s internet, or maybe 1985 s internet. There is, however, one missing piece of thought leadership around that metaphor and that is standardisation.

The world has grown accustomed to the extreme breadth of the Internet. Within messaging alone, we can choose Gmail or Yahoo!, Firefox or Chrome, to email one s friends, or to Whatsapp them.

We can also connect both wirelessly or through a wired connection. We can do so anywhere around the world, even in the middle of the desert, via use of a satellite phone.

When we re dissatisfied with TalkTalk, we can switch to Relish, or one of the many dozens network providers in the area. We can even become a network provider for our neighbours or friends.

This agnosticism is due to standardisation. We know that our Broadcom wireless card works just as well with an access point provided by TPLink as it does with Meraki.

At the very heart of this phenomenon, is the table below:

AAEAAQAAAAAAAAgrAAAAJDFjMDgzYjg0LTg1NzItNDkzNC04MzQ1LTY3ZGY5N2MwMTgzMQ.png

If the reader has seen this table before it will be immediately recognizable. If not, an explanation of each layer is detailed below.

The Open Source Interconnection (or Open Systems Interconnect) OSI is a 7-layer model, which defines the boundaries between different types of services. To fully understand each layer, a practical example has been selected sending a message on Telegram in which all these layers rely on one another.

First, the top the (7) Application layer. Both the sender and the recipient needs to have a Telegram application which serves as the user interface, allowing the sender to type in his message, and the receiver to get a notification and an interface to read it.

Telegram is an open-standard application. That means, there can be more than one vendor of the application while the official one is dominant, there are plenty unofficial ones that have agreed to follow that standard.

But, let s dive down the OSI stack.

At Layer 6, there is a Presentation layer. This supports translating of the messages across multiple systems and platforms. If I were to send a picture, for instance as a JPEG it would have to be decompressed applying complex mathematical transformations to make it appear again. However, the same JPEG (vendor) software can be used in a browser, or in an email client making the system reusable again. Telegram creators don t have to build or even understand the details of image compression that s what Joint Photographic Experts Group (yes, JPEG actually stands for something) is for.

Sometimes, disagreements on this level cause public debate for instance, a few months ago there was a discussion how a gun emoji is to be shown at different versions of iOS. This was troublesome, because the definition of what constitutes a character (letter, emoji, pictogram) was loosely defined by the Unicode Consortium and this could lead to potentially fatal misunderstandings.

AAEAAQAAAAAAAAeMAAAAJGYzZTU5OWM0LTcyNjUtNGViMy05YWUxLWI5YzkwZTY0ODdjZA.png

Let s keep diving down.

At the (5) Session layer, this starts getting a bit more technical. The application must maintain a steady connection with the server and re-establish it when needed. The rationale is that the application needs to be updated any time a message is received regardless of whether that s a user message, or a service message such as encryption key change. If the application is restarted, it silently logs the user in and potentially picks up any messages that might ve been received while the user was away.

That said, this is accomplished without any awareness of the layers below and is handled transparently to the layers above.

At level 4, we re starting to touch the internet. This is where something called Transport Control Protocol comes into place. This, together with the Internet Protocol of the layer below is the most critical part of the open internet.

At level 4 - Transport, the system concerns itself with the ordering of messages. It concerns itself with the point-to-point connectivity. In our Telegram chat application, one point is in your hand your phone the other point is in the datacentre around the world the cloud . Regardless of that, the TCP works independently of the vendor of the phone, the provider of the datacentre, and infrastructure between. It attempts to retry, reorder, and recover the connection allowing the Session layer to simply focus on the messages re-delivery once connection is established.

Level 3 Network is the part that can be narrowly called Internet. Internet Protocol a series of standards that define how to inter-network connect various private networks in one big quilt of connectivity ensures that the messages (forming part of the Transport layer above) can be, piece-meal delivered from one host to another. It doesn t attempt to make sure they make it in the correct order, or that they are authentic it simply makes sure that the delivery happens effectively.

Let s stop here and consider a different Level 3 and 4 for our Telegram. Let s imagine we simply transfer the messages between hosts on floppy disks. The Level 5 wouldn t care in the slightest and Level 6+ wouldn t be even aware of that. This means that even changing something as fundamental to today s internet as the TCP/IP would still be possible and the existing applications would work as before. This has never been attempted because TCP/IP is a good combination. That said it allows us to introduce the diagram below:

AAEAAQAAAAAAAAf9AAAAJDZmYTUzYmI3LTJhMzUtNDcxMi04OTgzLWFkMDQwNTQyNzA4Yw.png

Conceptually each layer sees itself in communication with its counterparty on the other side of the link. While in practice the messages flow down and up the stack, every row is just concerned with its own duties and assumes that the rows below and above are doing theirs.

If the protocols at each layer are standardised the two stacks might come from different vendors. They would still be able to work together and interoperate. This is precisely why a Telegram application on Android can interact with one on the iOS.

Layer 2 - The Data Link layer- concerns itself with message passing within the same network. This is also standardised but with a large range of different standards some competing, some dominant in their little niches. The dominant ones tend to be relatively open. The WiFi (802.11) standard defines the way radio equipment should parcel data into frames and makes it possible to have different vendors on the same WiFi network.

Layer 1 -The Physical layer is dedicated to the physical infrastructure. This is the question of modems and cables. Again, as per the OSI model the layers above don t even know how long is the cable between one s wall socket and the equipment installed by British Telecom down the street. Not even the Layer 2 it simply provides a series of bits to Layer 1 which is translating it into voltages appropriate for the telephone circuit.

The final observation is the last column the DOD4 Model. It is simpler and slightly easier to follow going forward while less known than the OSI model.

AAEAAQAAAAAAAAg7AAAAJDQ1MWQ1NDhiLWZiNTQtNDQ1Mi04OWJjLTRiNzQwYzgzNTlkMQ.png

With regards to vendors, nothing prevents a single company from offering products across the entire stack, ensuring that they do work well together. For instance, Apple now produces products from Physical to Application from Airport to Safari and this is a perfectly reasonable thing to do. They however benefit from the ecosystem of other vendors.

Now, onto the blockchain.

The best standards are descriptive, rather than prescriptive. Zerado and its partners do not wish to prescribe a way of thinking to the ecosystem but we can start describing similar layers coming up in the Blockchain ecosystem.

In this part of the post, the description will move from the bottom, upwards. The prevailing assumption here is that the Blockchain is built on top of the DOD4 Host-To-Host layer OSI Transport Layer. Although, in some cases it makes sense to include Session or Presentation or Application mechanisms they are, as described previously, standards in their own right and thus can be layered into our Open Blockchain Interconnect model.

Layer 1 Ledger

All blockchains can be summarised as a shared ledger or a shared session. This means, that an abstract but arbitrary log of authenticated activities can be recorded on this ledger and referred to at some future stage.

Even the most rudimentary blockchains, such as Bitcoin, support this functionality. This is manifested by the ability to store arbitrary information within either the special-purpose record fields, or even by taking advantage of the public key infrastructure.

A sombre, but very creative, first evidence of this capability within Bitcoin was an obituary for Len Sassaman engraved in perpetuity in the Bitcoin blockchain by Dan Kaminsky by creating a specially crafted transaction spending 1BTC in late July 2011.

AAEAAQAAAAAAAAdlAAAAJGVjZGFhOGE2LWExOGEtNDc4YS1iYjk5LTEzMjM2MjBkMTlhMQ.png

In a more commercial application, this technique is used to notarize documents, provide proof of existence and more but the fundamental capacity is that of a shared ledger.

Layer 2 Consensus Layer

This layer defines the way a blockchain arrives at consensus. It can involve Proof-of-Work, Proof-of-Stake, or even a centralised validator some implementations might choose to have the distributed, resilient, and self-reliant cryptographic record, but want to control the authority to append to it. As long as blocks are being cryptographically chained, it should be called blockchain but might not be distributed in terms of the ability to modify. Some central records, such as company registries, might choose to follow this approach.

A well-architected solution would allow a consensus layer to be changed at a later point which should not require changes to the underlying chaining of the blocks.

Layer 3 Public Key Infrastructure / Wallet Layer

This is the layer which evaluates the identities of the keys involved. It stores the private keys and signs appropriate transactions. Wallets are also responsible for generating new keys when appropriate, regardless of whether through a random process, hierarchical-deterministic processes, or a fully deterministic brain wallet .

As the ways and means of storing and managing private keys are not necessarily vital to the operation of the blockchain itself, this component can be standardised quite easily and applied to a range of different platforms. It also does not have a substantial requirement for connectivity which is evidenced in a plethora of hardware wallets.

Greater interoperability at this stage would encourage more vendors to adapt a standard. In the Bitcoin world, there is a number of standards, but we believe that some of these standards can be extended to support more than one blockchain with a particular wallet technology.

AAEAAQAAAAAAAAgGAAAAJDA5N2RmNGJjLTIxNDEtNDYxMy1hNDE3LTYxY2ZlMjQ0NTI5Mw.png

Layer 4 Programmability

Two camps started to emerge in this space. One is smart-contract based, ensuring that the blockchain stores the code involved in making a logical determination. This is the basis of Ethereum and related systems. Even in this camp, there is very little standardisation although there are many systems that utilise Ethereum Virtual Machine, there has been no effort to decouple virtual machines from each other and enable interoperable systems.

The second camp is dumb-contract/crypto-condition based. This camp believes that the better way to orchestrate programmability is to keep it outside of blockchain standard itself and merely use the blockchain as a messaging layer. That does not preclude all parties to a contract to record the acceptance of the contract, or the arrival at some shared state but it does not require the blockchain itself to perform complex computation and validation.

Layer 5 Presentation

This is where the abstractions pertaining to the information stored in the underlying blockchains take physical shape. This means, for instance, that the records of issuance and transfer of tokens take form of a real-world meaning. Or for instance, a balance of an account is presented to the user, and the user can perform a transaction.

This layer can be simple obviously, it is already substantially domain specific. That said, Ethereum Tokens are still not compatible at the API level with the Coloured Coins tokens which is a hindrance to development.

Zerado s Trade Finance platform abstracts the passing of tokens at a higher level making it possible to replace the underlying tokenisation engine.

Layer 6 Application

This is the final layer producing exactly the final application demanded by the market. It is responsible for presenting the information to the user; which can be the merchant application, a wallet application, or Zerado Access Control.

Examples of how existing providers fit within this model:

AAEAAQAAAAAAAAjeAAAAJGM3NDY3NDIxLWRkOTgtNDBiNy1hY2Q4LWI5MDZlYzBiYWRmNQ.png

Final Remarks:

In addition to the key standards that should be established along each of these layers, there will be a breadth of ancillary standards just as Internet spawned ancillary video compression, calendar information, and other standards.

One technology that Zerado found to be particularly useful as an ancillary service is our Secure API. This enables forward integration by making sure that each API object contains all the signatures necessary to confirm its origin and authenticity. This formatting mechanism makes it possible to transcend multiple layers and ensures cross-vendor compatibility.

The other key finding from our Disberse subsidiary is the perception that Blockchains necessarily rely on the underlying internet to function. This is only true to the extent of Internet being the best common denominator: carefully architected data layers make it possible to operate a wallet service across SMS, a ledger downlink over a satellite broadcast, and many more.

The creative flexibility of mixing various applications and vendors, and agreeing on common interoperability guidelines, is key to making sure that every application of Blockchain can be easily supported by more than one vendor and that every vendor can hope to support more than one application.

As the industry matures, a complete set of recognized standards will be established and accepted. In the meantime, remaining agnostic of any of the potential directions the distributed ledger ecosystem can take, is a key element of a Blockchain strategy. Zerado is uniquely positioned as an expert advisor and consultant, being aware of the wide range of providers and their offerings.

CONTACT: