Mithril integration

[jeluard]

Mithril is one important part of the cardano ecosystem that could improve amaruin multiple ways.

Simpler bootstrap

mithril provides access to authenticated snapshots of cardano-db. This could serve as a foundation for a simple and secure way to bootstrap amaru from a well-known point. It's not clear yet how easy it is to parse the content of this db and retrieve the relevant data.

Amaru snapshots

The next logical step would be to have mithril support amaru as a first class citizen. Mithril signer would be enhanced to sign mithril dbs, and mithril aggregator would make those available similarly to cardano-node ones.
As mithril is written in rust, it could be directly integrated in amaru.
Alternatively, amaru could implement a propose communication mechanism to not access a local running mithril signer. Amaru would then act as aggregator.

Custom signed assets

Finally, mithril could allow amaru to sign other kind of assets by allowing to easily plug custom logic. This could be leveraged e.g. to allow for faster browser based amaru startup.

cc @abailly @jpraynaud

[jpraynaud]

Hi @jeluard,

Thanks for raising up these subjects. Here are a few thoughts about them:

• The current Cardano database snapshots done by Mithril are based on the internal Cardano node database files. This is fine in a world where there is only one Cardano node implementation, but this will obviously create problems when multiple implementations are available (each with its own way of storing the blockchain state). As you mentioned, new implementations like Amaru will need to parse the data from theses node files (some implementation already exist with pallas-hardano for parsing the immutable files, but I'm not sure that this is easy to do with the ledger state).
• Also, to create a Mithril certificate, all the signers (SPOs) registered in the protocol must sign the same message (which they compute independently). The SPOs running the historical Cardano node would probably not be able to compute the same message (for Cardano database snapshots) as SPOs running on another implementation.
• This probably means that there should exist a canonical format for the Cardano node database that would be easily signed, imported/exported, distributed and certified and adopted by any Cardano node implementation.
• All the other types of data signed by Mithril are based on the Cardano n2c mini-protocols (we use pallas to communicate with the Cardano node), so this should be less of a concern assuming that these mini-protocols are implemented in alternate Cardano node implementations.
• There is no Mithril signer library at the moment, but we could create a crate for that to be easily incorporated in the Amaru node.
• The CIP-137 that you mention is describing the DMQ protocol that will be used by Mithril signers (operated by SPOs) to broadcast their individual signatures to Mithril aggregators which then create the multi-signatures and certificates. Amaru could act as an aggregator by listening to the messages on this queue (but as for the signer, there is no crate available for the aggregator yet, and this part of the network is still centralized at the moment). However, I don't see how this could prevent from accessing the local Mithril signer, could you explain your idea?
• I'm not sure that the "Custom signed assets" feature is possible: Mithril multi-signature can be created only if sufficient share of the stake has signed the message. This means that all the SPOs, and not only a subset of them, participating in the Mithril protocol should be computing the message and contributing with their signature (whichever implementation of the Cardano node they are running).
• Could you describe a bit further the use case of "faster browser based startup"?

cc @rezabaram

[Quantumplation]

With the disclaimer that I'm very much an outsider and I'm 100% sure that the reality is much more complicated than I'm probably giving it credit for:

The ideal setup to me would be:

• A generic "Mithril" protocol is built into the nodes
• An SPO registers their intent to run Mithril on-chain, and that includes a list of plugins they intend to support; and this list can be updated
• The existing "Mithril Protocol" involves the certificate chain as designed, and commits to a global stake snapshot: basically a lookup from signer to stake
• Every mithril signer participates in that root mithril protocol, so it has the maximum security
• However, you can "subset" or "mask" this snapshot based on which plugins you care about; for example, if you care about the Oracle plugin, you can easily identify what the stake snapshot you should use is: verify the root mithril certificate chain to get the current global stake snapshot; then build a stake sub-snapshot by restricting the domain of that snapshot to the SPOs who have declared they are running the Oracle plugin
• Each plugin can be either push or pull;
  • a push based plugin is ideal for scenarios where everyone should organically arrive at the "same" result, and can just build and publish their signature to be aggregated by someone
  • a pull based plugin, on the other hand, allows someone to trigger a request for a signature; this is useful for scenarios where it's hard for everyone to arrive at an identical payload to sign, but other signers can decide whether they "agree" with it; for example, oracle prices, everyone might have slightly different timing on when they hit the APIs to get prices, but if everyone is within 0.1% of the same price, it's likely good enough for most use cases
• The ideal protocol would also come pre-bundled with an incentivization strategy that plugins could use; the simplest setup would be having a smart contract on L1 that allows X tokens to be claimed in return for presenting a valid mithril certificate that includes your signature. So, if someone offers their signature, and it ends up in a finalized aggregated signature, the signers who can be proven to have signed it can go and claim $10 for participating in that process, for example

Evaluating an aggregated signature against the subsetted stake snapshot can then be entirely a policy based decision: in fact, you can build applications that vary their behavior based on how confident the snapshot is! For example, a collateralized lending protocol could define their minimum LTV based on the size of your deposit and the confidence in the reported mithril signed price!

[jpraynaud]

@abailly I also recall these discussions about the security metric for Mithril certificates. We wanted to compute the metric based on the protocol parameters and correlate that to the probability of forging a multi-signature. But even if we use full security parameters (128 bits), there is still a problem with the bias introduced in the Mithril stake distribution versus the full Cardano stake distribution (and its assumptions about the maximum share of adversaries). A collusion attack can be implemented if enough stake is adversarial in the Mithril stake distribution: the malicious actors can coordinate to sign the same tampered information and create a valid Mithril certificate from it.

This is pretty much the same problem that could occur with the plugin mechanism that @Quantumplation is proposing (which I find very interesting though). In that case, there would a high trust assumptions on the signers participating in this plugin to trust the associated Mithril certificate: this is far from ideal. It's also worth mentioning that there is no guarantee that a signature from a signer is included in a certificate, and even the signatures used to create the multi-signature will not be available any more with more sophisticated proof system than the concatenation system currently used (e.g. with an Alba proof).

Maybe a way to see things is how can we make all the SPOs sign the messages that are only computed by the signers running the plugin? I think that this could be possible if the plugin computation is provable and easily verified (e.g. with a SNARK):

• if a signer participate in the plugin, it creates a message (the SNARK) and signs it with Mithril
• if a signer does not participate in the plugin, it verifies that the message was correctly computed and signs it if the is the case
  The signers would probably need to keep a sort of mempool of signatures received from the signers participating in the plugin and they would decide to sign the message when a quorum is reached.

[abailly]

I also recall these discussions about the security metric for Mithril certificates. [..] A collusion attack can be implemented if enough stake is adversarial in the Mithril stake distribution: the malicious actors can coordinate to sign the same tampered information and create a valid Mithril certificate from it.

Sure, but again, that's a problem of trust from the client side because you know who the "scammers" are: If as is the case today, an overwhelming share of the stake distribution used for signing is in the hands of well known entities that have a skin in the game, it's quite different from the situation where you have 1000s of unknown actors.

This is pretty much the same problem that could occur with the plugin mechanism that @Quantumplation is proposing (which I find very interesting though).

Hence why I recalled those discussions.

even the signatures used to create the multi-signature will not be available any more with more sophisticated proof system than the concatenation system currently used (e.g. with an Alba proof).

Note we could increase $k$ (or is it $m$) eg. the threshold to create certificate to a larger number of signatures to increase the security if we wanted.

Maybe a way to see things is how can we make all the SPOs sign the messages that are only computed by the signers running the plugin? I think that this could be possible if the plugin computation is provable and easily verified (e.g. with a SNARK):

• if a signer participate in the plugin, it creates a message (the SNARK) and signs it with Mithril
• if a signer does not participate in the plugin, it verifies that the message was correctly computed and signs it if the is the case
  The signers would probably need to keep a sort of mempool of signatures received from the signers participating in the plugin and they would decide to sign the message when a quorum is reached.

If there were a generic mechanism available to verify computations, you would not need to trust signers would you?

[jpraynaud]

even the signatures used to create the multi-signature will not be available any more with more sophisticated proof system than the concatenation system currently used (e.g. with an Alba proof).

Note we could increase k (or is it m ) eg. the threshold to create certificate to a larger number of signatures to increase the security if we wanted.

This was related to the incentive mechanism that @Quantumplation explained "a smart contract on L1 that allows X tokens to be claimed in return for presenting a valid mithril certificate that includes your signature": the final Mithril certificate will not include all the signatures which makes incentivization based on the signatures not feasible.

If there were a generic mechanism available to verify computations, you would not need to trust signers would you?

If the computation made by the plugin is provable, we could trust it as soon as we can verify it. However, I'm not sure that this could be implemented with any plugin. Also, there may be concerns about the resources needed to operate such provable plugins.

I will ask the question to researchers to get their input on if/how we could implement this plugin mechanism 👍

[jeluard]

Nice discussion! @Quantumplation pretty much describes something similar to what I had in mind. @jpraynaud Great to see you find it interesting! Please let us know if you get feedback from the research team.

This probably means that there should exist a canonical format for the Cardano node database that would be easily signed

Are you aware of some initiative going in that direction?