# [WIP] A decentralized ZK-Rollup design based on DankSharding
We are going to design and develop a decentralized ZK-Rollup based on ethereum. Our first design is based on the EIP-4844 solution, which we call [PoVP](https://ethresear.ch/t/a-design-of-decentralized-zk-rollups-based-on-eip-4844/12434/6).

The other design, which is also more long-term, is based on the future DankSharding:

## Core Ideas
Although PoVP achieves complete decentralization of rollup, it does not prevent packing multiple L2 builders’ blob transactions in L1 blocks, which not only causes wasted gas fees, but also an additional cost for L2 builders; in addition, it causes wasted data availability space (multiple blob transactions may store duplicate L2 transaction data).

In DankSharding’s dual-slot PBS scheme, the execution payload of a slot is generated by a “super builder”, then proposed by a proposer, and finally proven by attestations of the slot’s committee. We have made some improvements based on DankSharding The Proposer is given a new function to verify the execution payload of an L1 block: a rollup can have at most 1 L2 builder (but can have multiple blob transactions).

The Proposer needs to know in advance which Rollups are involved in this protocol, so similar to the validator’s deposit contract in Phase 0, there is a contract responsible for managing the currently valid Rollups, and each valid Rollup will occupy 1 RS (Rollup Slot).

Rollups need to pledge a certain amount of ETH in this contract in advance to register a RS, and no permission is required to register. Correspondingly, a new Operation of Rollup registration is added to the beacon chain, and the state of the beacon chain will record the currently valid Rollup IDs.

At each slot, a randomly selected Proposer will check the execution payload to ensure that each Rollup ID has only one L2 builder in the current slot.

## Pros and Cons
### Pros.
- after Rollup registration, the L1 builder selects only one valid batch to pack into the exec block, preventing invalid batches from other L2 builders from being packed and causing gas waste.
- only one valid blob tx is selected, avoiding the waste of storage space for danksharding by invalid batches.
- not compromising the decentralization of the original de-rollup scheme and ensuring that multiple valid batches of a builder can be received in a slot.
- solving the MEV problem of rollup by implementing the PBS of rollup with the PBS of ETH2.
- proposed a scheme to bind the rollup registration system to the consensus, which is convenient to do more adaptations for rollups in the future

### Disadvantages:
- multiple builders are in competition, and there is still the problem of wasted ZK computational power.
- it takes time to generate proof, there is still a lag in the confirmation of transactions, and the subsequent need for zk mining pools to solve this problem

This design is still in draft stage, we are very eager to get your comments and suggestions!