Picking up the thread from our previous blog post, we intend to give you a more detailed insight into Archivum’s unique features. The inspiration and utilization of the Bitcoin blockchain system certainly is the most innovative component of our platform. In this entry to the series, I’ll focus on demonstrating the trustworthiness of our platform. The purpose of this closer look is to provide readers with a clear and concise understanding of Archivum’s loyalty to the ‘Zero-Trust Policy’.

Are you watching closely?

Every great magic show consists of three parts: ‘The Pledge’, ‘The Turn’, and ‘The Prestige’. In accordance with this simple structure, I’ll demonstrate Archivum’s fascinating functionalities.

But before we begin, let me briefly lay out the context in which we are operating here: ‘Security’ is a small word for a gigantic concept. When we talk about organizational data, from our experience ensuring security against fraudulent manipulation and guaranteeing audit-proofness of files are the very first concern. Hence, Archivum’s approach is designed to pay particular attention to these aspects.

With this in mind, let us pull back the curtains and reveal our main act!

The Pledge: A Chain of Operations

As we start the first act of our magic show, let me briefly establish the environment of our actions: Within Archivum, each operation performed on a given document has a solid structure of parameters that altogether differentiate it from all other operations. Mentioned parameters include aspects such as the type of operation, its timestamp, hashed content of the document, and the like. For each operation happening on a document, we generate a hash from the above-mentioned new operation parameters as well as the previous operation hash of the same document.

The Pledge Blockchain Zero Trust Policy

This newly generated hash is the operation hash of the current operation. Due to the characteristics of hash functions and the structure of the operation parameters, each generated hash is completely unique and identifies its corresponding operation. By generating the current operation hash from the current operation’s parameters as well as the previous operation hash, we are able to chain all operations for each document (also known as ‘Audit-Trail’). This approach is practically the same methodology Bitcoin uses for chaining its blocks.

Our centralized chaining of the operations provides us with an unbreakable bond between all of a given document’s operations. To verify a document’s history we now only need to start from the very first operation, calculate the hash (from the operation parameters), and compare it with the already generated operation hash. For the verification of the remaining operations, we then need to match each calculated hash to the previous operation hashes (which are stored inside the next operation of the document).

This comparing and matching process is continued up to the last operation of the document. A document’s total history is only verified in case there are no contradictions between the stored operation hashes and recalculated ones. In this way, illegal manipulations of specific operations have been made trackable and determinable.

The Turn: Bitcoin

Now we are already in the second act of our performance, where we take something ordinary and make it do something extraordinary. In the first act, I described to you our “ordinary” method of chaining blocks in a centralized fashion, but this comes with one big flaw: It is not 100% loyal to the Zero-Trust Policy yet. Thus, the next “extraordinary“ step has already been laid out for us:

We have to decentralize it.

Please pay close attention as I show you how we accomplished this daunting task! Many of you in the audience may be familiar with the technique, but for those of you who aren’t, do not be alarmed:

What you’re about to see is considered safe!

Image 1 1

The basic idea is as follows: To fulfill our commitment to the Zero-Trust Policy, all applied operations are to be submitted as a transaction to a decentralized system (in this case Bitcoin). To approach this matter, we once again utilize the operation hash. In other words: We submit all operation hashes as Bitcoin transactions. Consequently, all operations not only exist as centralized data on the Archivum platform itself but also as decentralized data inside the Bitcoin system. Sounds simple enough, right?

Simple maybe, but not easy.

It’s not as straightforward as it may seem at first glance. Nothing is impossible, it’s just that what we want is usually just too expensive: The key issue is that transactions into the Bitcoin system have a fee attached to them, which means submitting every operation hash as a separate transaction can bring a significant amount of extra cost along with it. This additional cost depends on the number of operations performed, which in turn can increase ad infinitum.

Have we considered the cost?

The Turn Bitcoin

Of course we have! To avoid such unnecessary expenditures, we once again were inspired by the block structure of Bitcoin: On a daily basis, we generate something called a Merkle Tree out of all operation hashes collected throughout the day and only submit the root of said Merkle Tree to be decentralized. The generated Merkle Tree as well as the block information of the submitted transaction (‘Merkle Tree root’) are then stored as a document in the cloud, ready to be accessed when needed.

All in all, this nifty solution not only greatly reduces the total amount of transactions to a single transaction per day, but also keeps the cost independent from the number of operations!

The Prestige: Verification

But you won’t be amazed yet. Why? Because submitting operations as a transaction is not enough! You should be able to prove, verify, and track all operations inside of the Bitcoin system.

That’s why there is the third act.

The hardest part.

The part we call Archivum’s ‘Prestige’.

To verify an operation, we perform the following steps:

  • Firstly, we calculate the operation hash.

  • Secondly, we validate the existence of the calculated operation hash inside the corresponding Merkle hash document stored in the cloud.

  • Finally, we obtain the block information and verify the existence of the Merkle Tree root as a transaction in the corresponding block.

Blog 02

When all is said and done, the combination of all these intricate facets leaves us at a loss for words. It is truly magical. Pulling it all off was quite the task. As our flawless performance draws to an end, it’s any magician longing for the audience to have had a good time and be entertained. Maybe they’ll even tell their friends and family about us, maybe they’ll return for another awesome time… In the end, there’s really only one thing we want to hear them utter in marvel more than anything else in the world:

“It was the greatest magic show I’ve ever seen!”

Closing Thoughts

After all, society tolerates only one change at a time. Disrupting the tried and tested way of archiving won’t happen overnight. At this moment, it’s only a matter of time until organizations and businesses discover the enchanting benefits the utilization of blockchain provides them with!

As far as improvements to our current methodology go, we have some clues already. While Merkle Trees are surely very useful, there may be huge gains of efficiency in the form of Verkle Trees on the horizon. This would make it even more convenient to submit bigger and bigger numbers of operations as transactions into the Bitcoin system. But to write about that too would be another magic show in itself!

Alas, we come to a close. I’m sure you got your money’s worth! Thank you for reading this blog post.

Huge thanks to Chris for the awesome illustrations and Niklas for his help with the text and story structure. Without them, this magic show wouldn’t have been possible!


Milad Navidizadeh

Milad is a Cloud Engineer at MobiLab. He focuses on Cloud Adoption and engineering Cloud-Native Applications.