• No products in the cart.

Blueprint of XML Based Blockchain Format

What you will learn:

  • How the blockchain idea can be used within an XML document structure
  • How simple an implementation of an XML based blockchain can be
  • Security means, not in every case, hiding the content


One of the basic elements of blockchain is the idea of having information blocks chained together. The chain can be modelled as a two-side wrapper around the previous block and the following block. Both wrappers are technically built as cryptographic hash codes. If you are analyzing the chains, the hash from the previous and from the following block must be true. Otherwise, you should know that the previous or the following part has changed since creation.

As you can see in the picture above following the earlier description that hash (2) and hash (3) must be the same, the hash identifies only the block content.
How can such a system help us? The main issue is identifying changes on block contents. If you use such a blockchain string within a secure transaction between two systems, you can be sure that no changes have been made – or the whole string was replaced by a “man in the middle” attack. In such a case, you can use a separated transfer of all the hashes to check the consistency.

Using XML

Within the document root of an XML document, you can have as many sibling nodes your XML schema allows. If your schema allows, on this level, having the flow of block- and chain-nodes, then you are free to use a one-to-one map. If we take a closer look at such an XML based blockchain implementation, it can be easily extended with an additional security feature.
Let’s have a look at the following XML:

<?xml version="1.0" encoding="utf-8"?>



  <chain hash="12345678"/>


  <chain hash="34123674"/>


We can go on and define the fact: each chain hash includes the content of all previous sibling nodes. That means, we have the following picture:

The above model reaffirms the fact that we have less hash strings, and when we check the last hash, we are sure that all previous hashes are also OK. But when we check all hashes, we know that the whole content is unchanged.

What we win?

Without any encryption of the XML content, it is readable at any time with minimal tools. The content can be edited at any time – but without creating new hashes, the manipulation can be identified by checking the hash codes. Such a format is predestinated to transfer data stored in XML from one system to another, having a basic security about content manipulations, and being independent of any decryption tool to make the content readable. Based on the chain structure, the manipulation of content can be located within the XML. We can go back from the last chain to the first one, and at the point where the hash generated over the previous siblings is correct, and identify the part which hasn’t changed.

Additional gains

By adding the block and chain structure to an XML, we have not changed the general information structure at all. That means all or at least most of designed xPath queries still work as generated. We can add the XML blockchain design to the already existing XML structures and applications to make the information content consistent. We can go further and add blocks with Base64 encoded code containing PDF documents or other file formats. In such a scenario, we can embed files into their data content to build our archive format for data and files.

You like it more secure?

For those of us who like it more secure, there is no limitation at all. We can use encryption for the hash code. That means we can go on to encrypt the inner XML part of the block with any kind of encryption algorithm. If you use a symmetric or asymmetric key-based encryption, you encounter the same question any time using encryption – how to transfer keys to the receiver in a secure way to get the block content decrypted.

In the real world, start and end point in a data transfer mostly know each other. This therefore means you have other communication channels or methods to exchange encrypting and decrypting keys. There are, in fact, a lot of theories and descriptions available to give you a deeper knowledge.
We can go back to the question on which parts can we use cryptographic methods to help us make the content more secure. Additionally, we can spot the point to encrypt the hash code. That gives us an additional security option. Keep in mind the described part with which we built the hash over all previous siblings. That includes the fact that encrypted parts will be hashed as encrypted content.
We can play around with the question: building the hash block before or after encrypting the block’s inner XML part, only encrypt the hash sections inner XML content or doing both.
Packing all into a secure transportation layer as https REST service or building your secure tunnel brings you the desired security for the XML information transfer.
Overall, it is a question of feeling comfortable with the selected security status.

Here are some code snippets to show you how simple it is:

Create the block around an existing XML-node, generate the chain hash, and add all to the blockchain XML-Document:

public void AddBlock(System.Xml.XmlNode node)


            System.Xml.XmlNode importedNode = obroBlockChain.ImportNode(node, true);

            System.Xml.XmlNode block = obroBlockChain.CreateElement("block");



            // create the chain

            System.Xml.XmlNode chain = obroBlockChain.CreateElement("chain");

            System.Xml.XmlAttribute version = obroBlockChain.CreateAttribute("version");

            version.Value = "MD5";


            System.Xml.XmlAttribute timeStamp = obroBlockChain.CreateAttribute("timestamp");

            version.Value = System.DateTime.Now.ToString("yyyy-MM-dd HH:mm.ss fff");


            chain.InnerText = GetMd5Hash(this.md5Hash, obroBlockChain.DocumentElement.InnerXml);



I hope all these steps to combine XML content and the blockchain structure can give you an idea of your next solution to achieve a more secure data content transfer.

About the Author

Current: CTO at OBRO AG, Switzerland and CEO at CeTris Ltd.

Manfred Jehle has over 30 years experience in computer science. Having served in different positions, he got a deep insight into various aspects of information technology. As CTO at Software Center of Excellence, dieInkasso AG, Switzerland, and CEO of CeTris Ltd. he is responsible for the system concepts of all OBRO and CeTris® products. Through collaboration in the realization and coding, he acquires, again and again, practical experiences which are incorporated automatically into future concepts. Additionally, Manfred Jehle has many years of practical experience on conceiving, production, and application of services from and within different environments. He developed many practical solutions, which are often neglected in theoretical views. For all his solutions, user-friendliness is a top priority. He believes that appropriate technical solutions are oriented to the architectures, which should be considered at an early stage to allow future possible changes. He is the author of various white papers of CeTris Ltd. and numerous articles at SDJ and Object Spectrum.
Contact: [email protected]


March 7, 2018

Leave a Reply

Be the First to Comment!

Notify of
© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013