Sidetree Batch Size Limit and Proof of Payment

I would like to elaborate on why sidetree has a batch size limit and how the proof of payment works to combat a denial of service attack to the network. Each sidetree node (at least a full node) maintains a mongodb database to store all valid DID operations that are confirmed in the Bitcoin blockchain and written into IPFS. DID operations are basically json documents that contains a DID document and a sidetree operation type. When you think about it the mongodb store acts as a DID and DID document cache that improves the performance of sidetree fetch services. When resolving a DID Document given a DID, sidetree would just read a local database instead of a fetching data from Bitcoin network and IPFS every time. The mongodb store is also known as DID cache.

Suppose a malicious sidetree node wants to harm the network and tries to flood 100M protocol-adherent but bogus DID documents into sidetree network by sending 1M DID operations. Those operations gets queued in a single batch. The batch of operations gets successfully written into both Bitcoin and IPFS. Now all other good sidetree nodes sync their DID cache from Bitcoin and IPFS and now is 100M bigger, making the nodes to fetch slower due to cache size, or making the node unusable at all. 

The first strategy to counter the attack is to add a batch size limit. This does not prevent the malicious nodes to spam Bitcoin and IPFS (since they can always remove limits from the code and build their own version of sidetree), but good nodes when syncing their DID cache will check first the batch size of a batch file before storing DID operations into the DID cache. Great, problem solved. But the malicious node can still send multiple batches with the correct batch size limit. This led sidetree to add a more efficient solution, by introducing the proof of payment. 

 The proof of payment requires a sidetree node to pay a certain fee when writing N number of DID operations, where N is a configurable value. Technically this is implemented by providing a proof of fee to the batch file before writing it into Bitcoin and IPFS. This means that you have to pay more in order to write more. This makes the spamming not an economically viable option.

Comments

Post a Comment

Popular posts from this blog

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 nod...
Read more

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