<aside> 💬 This document is open for commenting.

</aside>

Table of contents

Intro

Shards communicate with each other a lot, during transaction execution and rebalancing. This communication requires authorization, because we don’t want for some other canisters or clients to be able to intervine into the protocol. This authorization has to be as efficient as possible, working without making additional inter-canister calls.

One solution would be to introduce some kind of collection, where all known shards are stored. Each shard would maintain a copy of such a collection and each time it receives an inter-canister call, it would look through this collection in order to identify the caller. This would solve the problem, but this solution has limitations:

1. Such a collection takes space, and the more shards we have, the more space it will occupy. This is not a huge problem, but it creates difficulties. For example, what do we do, if we deployed a new shard, but there is not enough memory to hold this list?
2. This solution has to be synchorized across all the shards, meaning that each shard should have the same view of the data stored in the authorization list. Otherwise it just won’t work properly. Synchonization is bad for union-db, because of its “eventual” nature - there are no locks or mutexes, everything just happens when it’s ready, taking as much time as it needs to take. Having such an authorization list would mean, that we would have to stop processing new transactions, until the list is synchronized completely, each time a new shard is deployed.

Certificate chains

Technical details of this solution were also discussed here:

Threshold ECDSA Signatures

There is a better solution to this problem. Each shard has a ECDSA key pair and we could use these keys to build certificate chains! This public key and the principal of the root shard will be our root certificate. When a shard deploys another shard, it will also sign the public key and principal of the new shard with its own certificate, adding one more link to the chain. Then it will supply this data into the new shard as an initialization parameter.

When a shard makes a request to another shard, it will attach its whole certificate chain to that request. The verifier shard will validate three things:

• that the provided certificate chain is valid (each link has a signature from the previous link’s owner);
• that the prover shard has the same principal as stated by the last (leaf) certificate in the provided chain;
• that the provided certificate chain has the same first (root) certificate as the verifier’s certificate chain.

These three checks is enough to be sure, that the remote caller is indeed a shard from the same database as the verifier shard.

<aside> 📖 We don’t need to sign the request itself, because it is already signed by our principal and this signature is checked automatically by the IC. But signing a request with this key would be useful, if we want to extend our database beyound the IC.

</aside>

Scope of required work

• Implement the required utility functions for ECDSA signature/verification;