# Synchronization Layer Research

## Goals

- Select a platform to deploy synchronization layer primitives
- Candidates:
- L2s (rollups)
- Sidechains (Polygon)
- Propose a framework of trade-offs to support product decisions

## Cost estimation
- Estimation for ETH base fee 20 gwei and 50 gwei
- ETH @ 1600 USD, L2 fees at 0.001 gwei
### Per cohort size

### Calldata vs storage

## Design considerations
- Efficiency of operator replacement
- Affects use cases where DKG initiations cost minimization is preferable without comprmising cohort longevity and collusion-resistance
- Example: Frequent DKG rituals
-

## Designs and tradeoffs
We prefer solutions that minimize gast cost, number of on-chain calls, number of interactions and complexity of contract code.

- Not posting transcripts data to the blockchain, but just a commitment (hash).
- This would drastically reduce the cost, and would also make it grow linearly instead of quadratically on the number of nodes.
- To achieve this, transcripts can be published P2P, but introduces the potential problem of other nodes claiming not having seen the transcript.
- Trade-off between having a single source of truth on-chain and latency/cost/complexity: Without the former, we have to implement optimistic assumptions and failovers
- Initiator doesn't pay for cohort costs
- We limit cohort sizes to, say, 16 nodes.
- One could argue this is in line with CBD value
- Preferable solution for latency-sensitive use-cases that require high probability of ritual success
- We use a sidechain like Matic instead of a rollup
- Publishing transcripts is a small part of a ritual and after transcript aggregation the security of the platform is not so relevant

Optimistic commitments
- Full transcript data published to chain retrospectively by coordinator layer (i.e. after nodes have already completed all rounds), occasionally and ‘randomly’
- These infrequent costly publications are subsidized by the fee collecting mechanism (same one that potentially buys back T)
- If any node pretended that they were not sent transcripts or another node was unresponsive (or any other chicanery) this would prove otherwise
- Appropriately large slashing disincentive for this rare case
- Admittedly there would also be cases of unaccounted misbehavior, but any kind of consistent laziness/malice would eventually be punished

### Rollups vs sidechains

Pro Rollups
- Sellable trust minimization of the coordination layer (i.e., you don't have to trust validators, only ETH)
- In theory, Coordinator TXs can be used in Ethereum L1 as evidence for staking mechanisms (e.g., a faulty TX on Optimism can be looked up in Ethereum L1 and processed by the CBD app contract to slash a staker)

Pro Sidechains (e.g. Matic):
- Roughly 4x cheaper (potentially much more if there's access to Matic full nodes to read TX data). In Matic, the table I showed before would range between $0.05 to $1.5
- Widely accepted, even if the trust assumption is worse than rollups

Both
- Listening to multiple coordinators on client side complicates client-side logic and UX
- Possible solution: Use Porter as an intermediary

# Bad Ideas
- Just build your own rollup - https://blog.celestia.org/introducing-rollkit-a-modular-rollup-framework/