Unless I am misunderstanding, the security benefit is not that you can continue working with contracts during a malicious majority attack. It is that your contract cannot ever get into a completely irrecoverable state. If a contract uses volition only for index data, the index data for that contract can always be reconstructed from the state that is posted to L1. This is a significant win: it means you can store even more index data to optimize computation elsewhere. The 1.5k gas will be insignificant compared to how much you can save by storing more index data.
I think DA modes should be introduced to most-safe to least-safe. Obviously L1 DA is safest. Next would be L2 DA per-contract. Then would be global L2 DA. I donât find the global L2 DA as useful because a malicious majority could put my contracts in an irrecoverable state, even though I only stored index data in volition, which is not an acceptable tradeoff for gas efficiency.
Evyatarâs point was that in a catastrophic-enough event, enough key L2-relying contracts would have been hit, which leads to most L2-relying contracts becoming unusable.
It is true that if you only stored index data youâre less impacted, but the main benefit from alternative DA modes isnât using index data to save computation. Computation is cheap on SN and will most likely become even cheaper, already today L1 DA costs are > 90% of the fee on most transactions. L2 DA targets at reducing costs for common use cases (e.g. simple transfers).
I understand the point. The issue I have is not that it is temporarily unusableâI understand this would be the case for both the global and account specific version. Itâs that the data would be permanently unavailable for all contracts with the global version; that the only way I can see out the bad situation is to revert the state of the chain to a state with public data; and that I have no way to code my contract to use this global L2 DA mode s.t. it cannot be bricked by loss of data availability.
On coding my contract to be tolerant to loss of DA: you could try allowing a way the contracts can be called to not use the indexes. This will be prohibitively expensive in my case for the functions that read indexes. In addition, since you cannot write to indexes during loss of DA, you cannot actually use the indexes since they are not updated by the no-index code path. It seems impossible to write a contract to be tolerant to loss of DA without introducing an oracle for loss of DA (or more generally just introducing upgradeability)
I would not recommend anyone to use volition with global L2 DA for index data in custodial contracts such as AMMs, lending markets.
I understand your concerns. I believe that in the future, adding another DA mode that publishes all contract state roots on L1 could help reduce costs while maintaining security for contracts that store index data.
The suggested DA mode has the potential to significantly decrease fee costs for users, but it does require careful and secure implementation of contracts. We believe that with a secure contract implementation, the benefits of significantly reduced costs can be obtained while risking only a limited amount of resources.
In hindsight, I agree that starting with global L2 DA mode is better (definitely better to start with, maybe better long term).
If Ekubo uses DA only for index data, we will be competing with AMMs that use it for everything that can offer order of magnitude cheaper interactions. So weâd still have to offer both the volition-only version and the L1-DA version to support all the use cases.