The Sidetree Protocol

Blockchain scalability is a non-trivial problem, but there is now a promising strategy for scaling blockchain-based systems known as ‘Layer 2’ protocols, or L2s, for short (example: Bitcoin’s Lightning Network). L2s achieve scalability through deterministic processing and transaction schemes that take place ‘above’ the blockchain, with zero or minimal consensus requirements beyond small points of interaction with the underlying chain. For decentralized identity to become a reality, it requires a system that operates at massive scale, while still delivering on important features, such as deterministic state resolution and differential persistence.

Using blockchains for anchoring and tracking unique, non-transferable, digital entities is a useful primitive, but the current strategies for doing so suffer from severely limited transactional performance constraints. Sidetree Entities is a Layer 2 protocol for anchoring and tracking entities across blockchains. Sidetree Enities, and nodes that implement the protocol, are not another blockchain, and do not require a consensus layer, they run atop any existing blockchain that supports the ability to embed a small amount of data in a transaction.

The central idea involves batching multiple DID Document operations into a single blockchain transaction. This allows Sidetree to inherit the immutability and verifiability guarantees of the blockchain without being limited by its transaction rate

The sidetree protocol is a mechanism utilized by Microsoft Ion to optimize read and write operations to Bitcoin blockchain. Bitcoin suffers from low throughput, processing only an average of 7 transactions per second. This inherent weakness of Bitcoin led the development of more efficient ways make transactions to bitcoin. Sidetree send transactions to Bitcoin in "batches" by creating a layer-2 blockchain. Sidetree queues transactions written and send them into the blockchain by batch. Sidetree first create an anchor file and a batch file. The batch file is made up of Sidetree operations which in turn made up of DID Documents. The anchor file consists of the batch file hash and the list of DIDs included into the batch file. Both anchor file and batch file are written into IPFS. Then the anchor file is written into Bitcoin.

There is a blockchain processor that runs periodically to resolve DID documents from the blockchain. The processor fetches sidetree anchor file hashes from bitcoin. It reads an anchor file hash and then fetches both anchor file and batch file from IPFS. It validates the files if they adhere to the protocol rules. It reads the DID Documents from the batch file. One by one it verifies the signature of the DID Operation. If everything is ok, it stores in a MongoDB store. Whenever users try to resolve a DID Document, sidetree just fetches the DID document from the Mongodb.

Sidetree has its built-in denial of service mechanisms to block potential attacks to the network. Sidetree limits the batch size to a configurable value. Whenever it fetches a batch file from IPFS, it checks the batch file size against a configurable value. Sidetree also implements a proof of fee algorithm. To prevent malicious nodes to flood the did cache of trusted nodes, every node that would write to the bitcoin blockchain would need to pay a fee if it needs to process N number of operations, where N is a configurable value.

Comments

Post a Comment

Popular posts from this blog

On the IoT Exchange - DID integration

One of the challenges of introducing Decentralized Identifiers (DID) into Internet of Things (IoT) is the proprietary nature of the IoT ecosystem. Most IoT devices use proprietary technology. The ideal way of integrating DIDs is to put the keys and some cryptographic operations directly into the device. The assumption here is (1.) the manufacturer themselves can either generate and embed the keys from a secure or "offline" environment or (2.) manufacturer can embed cryptographic logic into the device and the device would generate the keys themselves, given that the device has enough power to execute the operations. If we are going create a service from DIDs and we do not have any access to the device manufacturing process, we may need to generate and maintain the keys elsewhere, but we need to make sure the pathway from that "elsewhere" to the device is _secure_, and how that secured pathway is implemented is *out* of the scope of this post. That "elsewher...
Read more

Smartkey Overview

Whenever we write applications, we need to keep our _secrets_ in a single central secure place. These secrets can be your password to your database, your api key, or your cryptographic keys used for signing messages. There are two major reasons why we want to do this. The first one is we want these secrets to be fetched by multiple instances of the application from a single place, instead of duplicating or hardcoding them in the application. This secure place may be a keystore stored in a directory in a file server, but making it reachable across different environments, specially when dealing with software development in the cloud, ultimately becomes a challenge. Nowadays, this is implemented as a service, where it expose endpoints easily accessible to applications for fetching the secrets themselves. Aside from key access, these type of services often offer key management solutions such as key rotation and key revocation. These solutions are sometimes referred as key management servi...
Read more