I was wondering through II’s sources and now I finally understand all the buzz around it. Subnet signatures are very cool, absolutely love it.
Now I’m thinking about other use-cases which could be solved with this functionality.
For example, let’s imagine this:
there is a canister A, registering users
there is a canister B, which only serves to users registered at canister A
Me a week ago would come up with this straightforward solution:
each time the user tries to interact with the canister B, it would make an inter-canister call to the canister A, to check whether the user is registered or not.
This solution would work fine, but since it contains an inter-canister interaction, it’s pretty slow.
Now it seems like we could make it much faster (and maybe cheaper) using subnet signatures:
once the user registers at canister A, it saves this fact to a hashtree and updates it’s certified data, which the user then could use to pass it to the canister B as a non-interactive proof of registration.
This solution is much better obviously.
What do you think? Is there something else I missed?
It seems like the only missing piece rn is how could one validate that this proof is actually signed by the real subnet within the IC. I know that IC’s pubkey is known, but this key is in chain-key-technology relations with the actual subnet key (btw, how could one access it?), which I don’t understand well enough. Is there a rust library for that?
Oh I watched some YT videos by Jan Camenisch on that topic an it seems like this key should be a part of the response the user gets alongside with the delegation issued by the NNS subnet, so it should actually be as simple as to perform an on-chain check if the certified data has this delegation and it is valid in terms of BLS verification.
Yes, especially for rust canisters it should be straight forward to include the existing validation code (found in the rust agent library) in a canister. One might wish that the system would provide it as a primitive on the system API, but it’s not really needed. The subnet key is part of the delegation thats part of the certificate, as you say.
I was thinking… but how do you tell if this certificate was created by exactly that canister in this subnet?
I mean… what will happen if I deploy a malicious copy of II to the same subnet to which II is deployed?
I know, the real II is now on NNS subnet and is immune to such an attack, but theoretically speaking?
The certificate of course includes the canister id whose certified data it certifies, and of course you need to check that it is the canister you expect it to be - the same checks that you would do when validating certificates off chain, no difference really.