---
# System prepended metadata

title: Synchronization Layer Research
tags: [nucypher]

---

# 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
![](https://i.imgur.com/L3OBZog.png)


### Calldata vs storage
![](https://i.imgur.com/uJfZ6PA.png)


## 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/
