Decoding the Sidetree Protocol
Sidetree protocol is an open blockchain-agnostic protocol developed by DIF and supported by Microsoft. The core idea of this protocol is to create decentralized identifiers that can run on any distributed ledger system.
This protocol is designed to overcome many technical problems in existing implementations that include high throughput and cost, presence of centralized authorities, lack of scalability, and more. The Sidetree protocol bridges the need for a decentralized and open protocol as it batches together JSON (a standard for representing structured data) operations to lower the associated costs, improve throughput, enhance scalability, and at the same, allow these operations to be anchored to any decentralized identity network.
It also helps to create unique identifiers that are controlled and managed by users with their public key infrastructure. Further, it conforms to the W3C specifications, so developers can use the decentralized identifier (DID) methods. So, now that you have an idea of what is sidetree protocol, let’s delve into its architecture.
Sidetree Protocol Architecture
Sidetree protocols are layer 2 protocols that anchor to the underlying decentralized ledger system. That said, it is ledger agnostic and its primary role is to anchor batches of signed JSON operations to the network.
What this essentially means is that using this protocol, you can create tree nodes that sit side by side on the network and perform CRUD (Create, Recover, Update, and Deactivate) operations according to the W3C specifications. These nodes interact with a Content-Addressable Storage (CAS) like IPFS to create, recover, update, and deactivate a DID document stored in it.
In this sense, the sidetree protocol is wedged between the CAS at the top and the underlying decentralized network at the bottom.
Working of a Sidetree Protocol
Moving on, let’s understand how this protocol works.
A transaction can be any of the CRUD operations that are implemented in JSON and signed by the holder/issuer’s public key. Each of these transactions is batched together and stored in a batch file.
The number of transactions that can be stored in the batch file is limited by the file size. So, developers can determine the size of the batch file depending on the average rate of transactions in the network.
Next, this batch file is connected to an anchor file that has a Merkle root. Here, a Merkle root is something that’s commonly used in cryptography to ensure that data blocks that are transmitted between peers are unaltered. In this implementation, the Merkle root also verifies that a particular transaction was included in a batch file. These anchor files, in turn, are attached to the anchoring networks.
As you may have guessed, the anchor file is the only thing that’s associated with the network and the rest of the implementation are ledger-agnostic. So, depending on the ledger you choose, the anchor file will vary.
An important aspect to note is that the JSON operation is signed by the entity’s public/wallet key while the signed ledger transaction is signed by the sidetree node that’s performing the anchoring operation.
So, this is how a sidetree protocol works.
Now comes an important question — how do you access the contents of your DID document?
Simply reverse the process!
Start with the ledger and get the hash for the anchor file. From here, get the hash for the batch file, and in it, you can find all the operations related to your DID as they get grouped and are replayed in the order in which they were recorded. From this, you can navigate to your DID document.
If you look at this reverse anchoring process, the indexing on the anchor file is the key aspect as it helps to weed out corrupted or bad batch files. In fact, the overall process and workflow greatly reduce the chances of errors.
Next, we’ll explain a bit about how this is implemented in Affinidi.
Affinidi’s Implementation of the Sidetree Protocol
Our infrastructure consists of SidetreeJS integrated into the DID registry with IPFS as the content addressable storage. On top of it, sits the MongoDB as the long term cache while the Ethereum Ledger via ChainStack is the ledger address.
To learn more about Affinidi APIs, check out our Developer resources.