Mithril registration procedure

Mithril registration procedure

One of the most important aspects to decentralise in Mithril is that of the registration procedure. While other aspects such as aggregation, or even communication of signatures can be centralised without affecting the security assumptions, a centralised registration would require full trust on whoever is running the registration. This is because the output of the registration, AVK, is essentially what enables the SPOs to participate in a signing generation procedure, meaning that if a single entity owns the power to create whatever outcome it wants from the registration, it can forge valid Mithril certificates. Even if we were to provide evidence that the AVK is the output of running the registration on valid requests, the registrar can always choose to leave certain SPOs out of the game, and can do so selectively.

In this page we cover four possible solutions, and their trade-offs. We describe in more detail on-chain registration, which is the solution that the engineering team is currently considering as the more complete.

Centralised Registration

A centralised registration would consist of parties registering to IOG uniquely. Once the registration window is closed, IOG would generate the AVK which would be redistributed to all parties.

This could be seen as a progressive step in our path to provide a full security Mithril service. However, it is important that while registration is centralised, we fully rely on the correct behaviour of the registration authority. The control that this entity has over the mithril signers is such that it could completely fake mithril participants and their corresponding keys, being able to create a valid mithril certificate mimicking full participation. Even if we have full levels of participation (~95%), the security of Mithril will completely rely on the assumption that IOG is honest.

Pros:

• Easy to implement
• Easy to run in production Cons:
• Full trust on IOG
• No progress for a production-level solution

IOG as a broadcast channel

Running IOG as a broadcast channel would consist of signers sending their registration request to IOG. However, contrary to the solution above, IOG would not be the unique entity running the registration, but it would share the registration requests with all signers that decide to participate.

The trust assumptions in this solution are also high for IOG. However, the main benefit in comparison with a centralised registration is that this solution guarantees that the only possible attack IOG can make is to leave Mithril signers out for a particular epoch.

Pros:

• Easy to implement
• Easy to run in production
• Attack window of centralised entity is smaller than centralised registration Cons:
• Capability of leaving signers out undetectably
• Little similarity with production-ready solution

Running a consensus algorithm for registration

After a discussion with the consensus team, this solution seems very hard to achieve in practice. Nonetheless, for completeness purposes we have decided to include it in this document.

The only alternative to achieve consensus on who has registered without running the registration on main-net seems to be to deploy a new consensus algorithm for registration. This does not mean that we need to design a new consensus algorithm, but simply that we need to run a different instance of it (e.g. Praos) in parallel to what is run on main-net.

Pros:

• Trustless solution
• Candidate for full security Mithril Cons:
• Hard to implement (thought we could probably piggy back on the current consensus implementation)
• Hard to run in production

Main-net registration

Running registration on main-net is the highest valued candidate for a production-ready solution by technical experts. After a discussion with the consensus team this seems the most viable solution with the important drawback that it would cost ADA to register as a Mithril signer. Apart from the cost constraint, this seems to be the solution with best decentralisation and deployment complexity offerings.

Pros:

• Trustless solution
• Easy to implement
• Easy to run in production
• Candidate for full security Mithril
• Registration events are visible to anyone with a view to the Cardano main-net Cons:
• Signers need to pay the transaction fees everytime they want to register (which seems to be at each epoch), and therefore handle a wallet to pay these fees.

Cost

It is important to look a bit closer to what is the main technical difficulties of registering in main-net. There are two aspects that are important to recall from the original paper to understand the problem here:

1. The signers are changing their signing keys at each Mithril epoch
2. When a player creates a public key it needs to prove its correctness, via a Proof of Possession (PoP) of the private counterpart.

Or in other words, signers need to send a registration request at each Mithril epoch, and a PoP needs to be verified at each epoch. This turns out to be very expensive. A back-of-the-envelop calculation gives us that we will be expecting registration of around 2K people. If we assume blocks every 20s, block execution budget of 50ms, and 1ms verification time of PoP, we need 40 full blocks. Or, in other words, we need 8 minutes of Cardano to run the registration (assuming full usage of main-net exclusively for mithril…). This is clearly not viable. To overcome this, we are exploring the following solution:

• Not verifying PoP on-chain, and delegate that verification to individual signers when they are creating the AVK. This would considerably reduce the cost of the transaction, as the script does not need to do anything, and we only use the ledger as a storage service rather than computation. The latter is offloaded to the mithril participants.

Discarding KES

Another option was to use KES, so that registration needs to be performed only once. The downside of this is twofold:

1. The PoP needs to be verified during the certificate verification instead of during registration (as when registering the KES parent key we don't have the PoP of each child-key)
2. The individual signatures and, by consequence, the concatenation certificates (our goal for release) would be larger and more expensive to verify. We would have to include: a. The PoP, and verify it b. The KES path for each signer