# Albus Dompeldorius CDAP - Dev Update #6 This is the sixth update for my work in the [CDAP](https://github.com/ethereum-cdap/cohort-zero/blob/main/development-updates.md#albus). ## What I have done since last update ### Springrollup specification Since my [last update](https://hackmd.io/@albus/S1E22SmBF), I have finally figured out how to do deposits/withdrawals in my zk-rollup (called Springrollup), and I have posted [the first description of it on ethresear.ch](https://ethresear.ch/t/springrollup-a-zk-rollup-that-allows-a-sender-to-batch-an-unlimited-number-of-transfers-with-only-6-bytes-of-calldata-per-batch). I realized that because of the differences between my design and regular zk-rollups, deposits and withdrawals were more complicated in comparison with a regular zk-rollups, but I found a way to do it. I figured out that it was much easier to do withdrawals and deposits if we represented each rollup account's balance as a sum of two balances: - one balance which keeps track of the amount deposited on L1 to the account *minus* the amount withdrawn on L1 from the account, and - another balance which keeps track of the amount received *to* the account *minus* the amount sent by L2 transfers *from* the account. The advantage of representing the balance in this way is that we can update the first balance (L1 funds deposited - L1 funds withdrawn) with full on-chain data availability, while the second balance (L2 funds recieved - L2 funds sent) can be updated in the calldata-efficient way. After I posted on ethresear.ch, I got some feedback on the specification, which led to some modifications with regards to how transactions are processed. See the replies to the post for details. ### Smart contract support I also got some feedback concerning the lack of generality (smart contracts) in the current specification. This is understandable, since lack of generality is one of the reasons why people moved from Plasma to rollups in the first place. See eg. this quote from [Vitalik's article on rollups](https://vitalik.ca/general/2021/01/05/rollup.html): > Additionally, Plasma and channels share a key weakness in common: the game theory behind why they are secure relies on the idea that each object controlled by both systems has some logical "owner". If that owner does not care about their asset, then an "invalid" outcome involving that asset may result. This is okay for many applications, but it is a deal breaker for many others (eg. Uniswap). Even systems where the state of an object can be changed without the owner's consent (eg. account-based systems, where you can increase someone's balance without their consent) do not work well with Plasma. This all means that a large amount of "application-specific reasoning" is required in any realistic plasma or channels deployment, and it is not possible to make a plasma or channel system that just simulates the full ethereum environment (or "the EVM"). To get around this problem, we get to... rollups. The good news is that in Springrollup, the assumption that every part of the rollup state has a logical owner is only used to avoid having to publish transfer data on-chain. If we want to add smart contract support, we could do that by simply including all state changes of contracts in the calldata. This would give us a rollup that supports smart contracts, and is just as calldata-efficient for contracts as existing rollups, but much more calldata-efficient for simple transfers. The question is, can we do better than this simple solution? I believe so, and I will try writing down my idea on how to do it. ### Prototype implementation I have started on implementing a prototype of Springrollup. I am using [circom](https://circom.io) for constructing the circuits in the rollup, and I will use PLONK as the proof system. My current plan for making the prototype is to take inspiration from [hermez protocol](https://docs.hermez.io/#/developers/protocol/hermez-protocol/protocol), but remove most of the functionality so we are left with the bare minimum needed for a rollup. I.e. remove, decentralized operator mechanism, token support, fee support, etc. Removing these features will make it easier to implement the Springrollup design. So far I have just started learning how to make circuits, so I don't have anything to share yet. I have played with sparse merkle trees in circom and implemented a circuit that proves a transfer between two rollup accounts (but with no signature checking yet, so anyone can send funds from any account). When I have something more substantial, I will put it in [this repository](https://github.com/adompeldorius/springrollup). # What I will do next I will continue working on the prototype, and also try writing a description of how to extend Springrollup with smart contract support.