There is no blockchain technology in X-Road

Recently there have been multiple writings about the X-Road which have stated that X-Road is a blockchain based technology or it utilizes blockchain internally. Are these claims true, is X-Road based on blockchain? Let’s take a look at the facts.

Blockchain

Blockchain is one of this year’s buzzwords and one of the hottest technologies out there. Blockchain became known as the technology behind bitcoin – the first cryptocurrency launched in 2009. Since then its use has expanded to cover many different business areas and use cases in addition to cryptocurrencies.

Blockchain is a distributed, decentralized and public database that stores transactions in a chain that protects them against alterations and ensures data integrity. Blockchain is a peer-to-peer network where all the nodes are equal and every node has a full copy of the blockchain. The data stored in a blockchain cannot be altered afterwards without altering all the subsequent blocks and replicating the changes to all the nodes of the network. This makes tampering the data stored in a blockchain extremely difficult.

Transaction data is stored in blocks in the form of a Merkle tree. Consecutive blocks are linked to each other so that together they form a chain. Each block contains the cryptographic hash of the preceding block in the chain which makes it possible to verify the order and the integrity of the blocks from the previous block till the very first block of the chain, the genesis block. This makes it possible to audit and verify all the transactions in the chain.

Blockchain does not have a central authority so the nodes need to come to a consensus before a new block can be added to the chain. This is achieved by using a consensus protocol or consensus mechanism. The most common consensus mechanisms are called Proof of Work (PoW) and Proof of Stake (PoS).

X-Road

X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. X-Road is a centrally managed distributed integration layer between Information Systems that provides a standardized and secure way to produce and consume services. X-Road ensures confidentiality, integrity and interoperability between data exchange parties.

The identity of the service producers (i.e. base registries) and consumers (i.e. web portals) is maintained centrally by the X-Road operator and all the data is exchanged directly between the data consumer and provider.  All the evidence regarding the data exchange is stored locally by the data exchange parties, and no third parties have access to the data. Time-stamping and digital signature together guarantee non-repudiation of the data sent via X-Road.

X-Road supports batch signatures and batch time-stamping. Batch signatures are created for messages that contain attachments. Batch time-stamping means that time-stamps are created asynchronously in batches for all the messages that have been processed since the last batch time-stamping. Batch time-stamping is used for reducing the load of time-stamping service. Both these features are based on Merkle hash trees and the messages processed during a single batch are linked to each other through a hash chain. Using the hash chain it is then possible to verify that a selected message is a part of a certain batch signature. However, there is no link between different batches and messages in them so there’s no chain that would link all the batch processed messages together.

The security server stores all the processed messages with their signatures and time-stamps in the message log database. The log records are archived to disk regularly and removed from the database after that. In the message log archive file each message has a cryptographic hash that depends on the previous message that was archived and the chain continues over different archive files. In this way the message log archive files create a chain that contains all the messages processed on a single Security Server. This means that the messages stored in the message log archive files cannot be modified without breaking the chain.

Is X-Road based on blockchain?

Blockchain is a decentralized and distributed database which is updated through a consensus protocol. All the nodes of the network are equal and every node has a full copy of the database. The blocks stored in the database are linked to each other using cryptographic hash functions.

The X-Road Security Server message log archive files contain all the messages processed by a single Security Server. Messages included in the files are linked to each other using cryptographic hash functions. The files are stored locally and the server hosting the files is responsible for creating them. Each Security Server has its own unique chain of processed messages. Other members of the X-Road ecosystem do not have access to the files.

The common factor between blockchain and X-Road is that they both use cryptographic hash functions for linking data items to each other. Besides that there are very few common factors between the two as they serve very different purposes and use cases. Cryptographic hash functions existed well before blockchain so even if the both blockchain and X-Road use them does not mean that X-Road is based on blockchain. Both bicycle and car have wheels, but we don’t say that car is based on bicycle just because the bicycle was the first one to use wheels. The same goes with blockchain and X-Road.

Based on the arguments presented above the outcome is that X-Road is not based on blockchain and does not use it internally.

X-Road and REST

X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. More information about the X-Road is available at:

https://www.niis.org/data-exchange-layer-x-road/

The X-Road and REST have been a topic in public discussion for quite some time already. Today the X-Road does not have a built-in support for REST, but that does not mean anything has happened regarding the topic in the recent years. And there’s even more to come later this year...

At the moment REST services can be produced and consumed over the X-Road using the REST Adapter Service component. The service supports a limited set of use cases so it’s not an answer to all X-Road REST integration questions. However, it is an off-the-shelf component that provides an X-Road compatible REST-SOAP converter, and it can be implemented over configuration – no coding is needed. Compared to a custom-built solution it can save a great deal of effort.

https://github.com/vrk-kpa/REST-adapter-service

How does it work today?

X-Road message exchange protocol is based on SOAP and all the information systems and services that exchange data over the X-Road must implement the protocol. For older SOAP based information systems and systems that have been using the X-Road for years this is not a problem as the systems already have a working implementation of the X-Road message exchange protocol.

For new information systems and new X-Road user organizations things might not be that simple because nowadays the most APIs are RESTful in nature and use JSON instead of XML. This means that an additional REST-SOAP adapter service must be implemented between the information system and the X-Road Security Server. The REST Adapter Service component is one alternative or organizations may implement their own custom-built solutions. Either way, it is technically doable, but not a very compelling alternative for organizations that have already moved away from SOAP and have implemented their APIs using REST and JSON. In addition, all the extra components in the stack bring more overhead, delay, maintenance work, costs etc.

What do the numbers say?

ProgrammableWeb is one of the largest information and news sources about the Web as a programmable platform and it maintains a directory of over 15,500 web APIs. According to its statistics REST is the most common architectural style with the share of 81 % of all the APIs listed in the ProgrammableWeb’s API directory. At the same time RPC’s share, that’s including also SOAP, is only a bit under 9.5 %. These numbers give a good overall picture regarding the popularity of different architectural styles today. The whole article is available at:

http://web.archive.org/web/20220712162418/https://www.programmableweb.com/news/which-api-types-and-architectural-styles-are-most-used/research/2017/11/26

What next?

Based on available statistics and the public discussion in the recent years, it seems obvious that the X-Road needs a better support for REST than the REST Adapter Service is able to provide now. The lack of the REST support is slowing down the adaption of X-Road and generating unwanted additional work for many X-Road user organizations. However, adding support for REST does not mean dropping support for SOAP – not any time soon, at least. Instead, the two architectural styles can co-exist side by side which means that all the current SOAP services must be supported also after the REST support has been implemented. Then it will be another discussion for how long both SOAP and REST must be supported side by side.

Tell us what you think!

What do you think about the X-Road and REST? The Nordic Institute for Interoperability Solutions (NIIS) is doing a survey regarding REST support for the X-Road. The survey is open until the 13th of April, tell us what you think:

https://buff.ly/2G7wtl9