Evaluate zkSync and other L2 scaling technologies for DKG verification

[arjunhassard]

No description provided.

[arjunhassard]

Obviously some of these alternatives are irrelevant but the estimates for zkRollups are a useful starting point

[piotr-roslaniec]

It boils down to whether we want to use an EVM-compatible rollup (Arbitrum, Optimism), or an EVM-incompatible zk-rollup (like zkSync or Starknet).

I could argue that (optimistic) rollups are more interesting for us since we have more experience with Solidity than any other SC language (Cairo etc.). The fast finality they offer is also interesting since the latency in DKG is an essential factor from the user's perspective. Lastly, I think they offer a more mature development environment than zk-rollups.

On another note: "Verification" refers to the verification of aggregated PVSS instances, correct?

[piotr-roslaniec]

Feasibility of BLS-12-381 verification on rollups: #7 (comment)

[arjunhassard]

There are cognizable scenarios/configurations in which the leeway for latency is pretty big – for example, where keys from a very infrequent DKG ceremony are used and reused by all the end-users within the same application (or use case, depending on the homogeneity of risk profile). In that case, one would only need to reinitiate a ceremony if the group has deteriorated past a given threshold of redundancy (e.g. 20-of-30 has effectively become 20-of-25). Even if the ceremony takes 2 minutes, this could be tolerable if it's occurring every 2 years – like scheduled downtime on SaaS products.

Relevant validation issue #78

[piotr-roslaniec]

This issue requires a more precise scoping, i.e., what are the operations we can delegate to L2? Verification may be too costly, what about the synchronization of nodes?