Protocols vs. Software (Part 1) Protocol approach for interoperable systems

Over the course of two posts on the Clearmatics blog, we are going to explore open protocols vs software monopoly from a distributed system perspective.

In this first post, we will show why open protocols as globally accepted standards are necessary for interoperable distributed systems and will prevail over a closed and proprietary model.

Firstly, let’s be clear about what we mean by protocols and what we mean by software. A communication protocol is defined as:

“A set of formal rules describing how to transmit or exchange data, especially across a network.” — (2006, Zheng & Ni, Smart Phone and Next-Generation Mobile Computing, p. 444).

Examples of familiar communication protocols are, of course, TCP, IP, HTTPS, SMTP, FIX. A group of protocols designed to work together is commonly known as a protocol suite or stack (such as TCP/IP).

Open protocols are designed, standardised, and maintained by an accountable body in a community effort, such as W3C, IETF and IEEE in the case of the World Wide Web and Internet protocol suites. In the blockchain space, open source communities such as the Ethereum Foundation have operated largely outside these groups as an independent non-profit organisation, however all three of the aforementioned standards bodies have certainly shown interest in blockchain developments and, in particular, the Ethereum blockchain and community.

The distinction between ‘open’ and ‘closed’ development should be noted — the open development process often sees informal adoption ahead of proposal, refinement and acceptance by a standards body, such as with the ERC20 token standard adopted by the community and, more recently, commercial entities. Open development engages the open community, bridges interests and proceeds by a consensus process (or by ‘rough consensus’ as IETF terms it in RFC 2418). Conversely, the closed development process is often driven by proprietary concerns and commercial interest of its closed community. This is orthogonal to interoperability-first distributed systems and, more broadly, innovation.

The word ‘software’, coined in electronic technology by John Tukey in 1958, comprises the:

“carefully planned interpretive routines, compilers and other aspects of automotive programming”

and is more commonly known as a set of instructions that control what a computer can do.

Software that implements protocols conforms to the protocol specification, ensuring consistent semantics and functionality of the protocol across different software implementations. Just as in scientific methods of experimentation, results need to be replicable and may incorporate standard operating procedures.

Why is this distinction of software and protocols important? Communication protocols documented and maintained by an open standards body ensure first and foremost that multiple implementations can interoperate ab-initio, and that software and hardware can link different networks. In short, formal protocol definitions are required for unrestricted interoperability between different distributed systems. Software implementations that attempt to dominate via a private protocol and customer lock-in can hope for, at best, compatibility.

Take SMTP, defined by RFC 821 in 1982. Without different implementations being able to send and receive emails, and to accurately share and display the information that was sent, would we trust in the data transmission techniques that have developed to build the World Wide Web and its associated free and commercial software? Or, more generally, would a closed protocol, dictated and maintained by a commercial body have generated the community and innovation that led to the successful creation of a decentralised and open value transfer layer over a blockchain?

As before, with blockchain-based value transfer, adoption will be driven by the open creation, discussion, refinement, and standardisation of an open protocol suite. A healthy, competitive market will have many software implementations built to the specification of these protocols. This is why we at Clearmatics are involved in the thriving and engaged Ethereum community, commonly estimated at around 250,000 developers, tooling such as the Truffle development framework with over a million downloads and active formal verification R&D grounded in established methods and languages. We are also heavily involved in the Enterprise Ethereum Alliance technical standards working group, and the International Standards Organisation, where we share and collaborate our research and development.

In the following post, we continue to explore the protocol vs software approach in the blockchain space as a global value transfer layer, by examining resiliency, incentives and some failure scenarios.

In the meantime, drop us a line with any thoughts you might have on protocols vs. software.

Sara Feenan, Product Strategist, Clearmatics

Tweet us @Clearmatics