---
# System prepended metadata

title: 'Albus Dompeldorius CDAP - Dev Update #4'

---

# Albus Dompeldorius CDAP - Dev Update #4

This is the fourth update for my work in the [CDAP](https://github.com/ethereum-cdap/cohort-zero/blob/main/development-updates.md#albus). Until now, I have mainly been focusing on analyzing the existing uses of the `SELFDESTRUCT` opcode in Ethereum. In the last couple of weeks, however, I have in addition started working on defining a new Layer 2 technique, which is similar to zk-rollups but requires less data on-chain.

## `SELFDESTRUCT` analysis

When I wrote my last update, I was still waiting for some feedback on whether the [backwards-incompabilities](https://nbviewer.jupyter.org/github/adompeldorius/selfdestruct-analysis/blob/main/analysis.ipynb) I found were critical enough to try preserving `SELFDESTRUCT` as is. Shortly after, I got feedback that this was probably not enough to outweight the advantages of neutering `SELFDESTRUCT`, and that I should do more analysis on what might break when neutering `SELFDESTRUCT`.

I also talked to the creator of Pine Finance, and it turned out that the situation was a bit different than I first thought. At first, I was thinking that the redeployed contracts were the result of a user using the same vault more than once, but I was told that the front-end creates new vault addresses each time, so this was not the case. Instead, the redeployed contracts were the result of an edge-case where a user tries to cancel an order, but the call runs out of gas when trying to transfer the tokens in the vault. As a result, the call that tries to move the tokens in the vault reverts, but the vault still selfdestructs. If `SELFDESTRUCT` is neutered, the remaining tokens in the vault would be at risk in this edge case.

[Here](https://gist.github.com/adompeldorius/2acf402c384cbcf96d53f1d401968f3e) is a list of redeployments of the same vault. As can be seen on etherscan, all redeployments except the last were the result of a failed cancelOrder.

It is still unclear to me if this problem can be avoided in the front-end, or if it is necessary to deploy a new version of pinecore. If it can be prevented in the front-end, the situation would not be so bad after all.

### What remains to be done

* Do a more detailed analysis on the amount of funds that could be at risk when neutering `SELFDESTRUCT`
* It would be interesting to pull more chain-data from after the London hard fork, where `SELFDESTRUCT`-refunds were removed. This should have lead to less selfdestructing (obviously for gas tokens, but perhaps also in other use cases).

## Layer 2 research

I have started a new project that I will work on along with the `SELFDESTRUCT` analysis. The goal of this project is to define a new Layer 2 solution I have in mind.

This Layer 2 solution is similar to zk-rollups, but needs less on-chain data. This is solved by borrowing some ideas from Plasma, where each user stores some data that is needed for withdrawing in the case where the operator misbehaves. Unlike Plasma, and similar to zk-rollups, users won't have to watch the chain for malicious behavior.

The concept is still in its infancy, but for those interested in getting a rough idea, I have started writing on the document [here](https://hackmd.io/-Uj7YPjYTkmIhuG7-FVmNQ).

### What remains to be done

* Describe deposits and withdrawals in the normal case
* Add examples of how to use the rollup, and what data must be stored by each user
* Add example of how to withdraw in the case of a contract freeze
* Estimate amortized gas costs per transfer
* After the above is done, publish the document to ethresear.ch to get some more feedback
* Do more research to see if the concept can be generalized to contracts, and not just transfers