Scope of note

This note is a supplementary document for DSM 2.0 exploring the risk and possible limitations on executing fron-run deposit attack within guardian collusion.

Original attack

Front-run

An operator might attempt to front-run the deposit transaction with their own deposit transaction but with different withdrawal credentials. In this case, the deposit transaction through DSM will be reverted due to a mismatch of deposit_root on the Deposit Contract, after which the Council Daemon will report the front-run key to the module, and it will be excluded

Guardian Collusion
With the emergence of permissionless modules, it is necessary to reconsider the collusion scenario, as the ability to introduce permissionless modules and modules with FIFO can alter the attack patterns.

Potential scenario:

1. Guardians conspire in sufficient numbers to constitute a quorum to launch an attack
2. Malicious guardians generate valid Deposit Data with Lido Withdrawal Credentials and upload to a module with permisionless entry, blocking a bond for each validator on the module’s contract. In the worst case scenario, when the module implements a FIFO queue, all attack keys will go in order
3. Malicious guardians hold off deposits to other modules by not sending signatures, thereby accumulating a buffer and moving the queue to their keys (assuming the target limit per module allows to hold this amount of stake)
4. After waiting for the queue to reach the attack keys and a large buffer volume, malicious guardians send prepared deposits of 1 ETH each with their own withdrawal credentials to the deposit contract
5. After that they sign the deposit messages and execute the deposit through the DSM contract

At least one honest guardian mitigates the potential attack by:

1. Sending a key invalidation transaction upon detecting an attempt at front-run. May not help, if the attack is done correctly and the transactions are bundled together
2. Pausing the module upon detecting a completed front-run

DSM has limits on the frequency of deposits and the number of deposits at a time. Current values: 25 blocks between transactions and 150 keys at a time. Thus, at least one honest guardian has a sufficient time window to react, and the amount of funds that can be stolen, in the case of guardian collusion, is limited.

In summary: the attack through permisionless modules with FIFO becomes easier than the attack through a curated module. At the same time, the attack becomes more expensive because a bond is required for each validator. The reaction window and the amount of funds under threat does not change.

Observation 1: Buffer requrements

Attack performance requires accomulating large enough buffer (described through steps 3-4).
While this add additional condition for executing it can be bypassed by possible attacker, by staking sufficient enought amoubt of ETH, at the time of attack, therefore guarantiing enogh buffer size.
This requires additional capital to provide the attack, but makes the scenario with permisionless entry un-conditioned on external circumstances.
The cost of capital is insignificant, as stETH minted upon stake could be immidiately swapped to eth on market: as investigated volume of 150 keys is 150 x 32 x 2200(ETH price) ~ 10kk USD.
Within current Liquidity depth that's less than 10 bps

Observation 2: Module speciefic

As described vulnerability is applicable to the protocol as a whole, there are significant differences in conditions required to perform an attack, apart from cguardian collusion and enough buffer (which could be bypassed, desctibed in observation 1)
Curated module additinal crucial conditions are:

1. Collusion with one or a set of the curated NO
2. Ordering the keys to deposits under for the compromised NO

Given that, executing this attack for the curated module require reputational costs form NO (which are already exist if it's one of the guardians) and very speciefic conditions out of control of potential attacker.
Therefore, given the differences between attack cost and conditions it's reasonable to implemet the limits on module level, as that would open up the design to target speciefic risk, minimazing the cost of mitigation for the whole protocol

Observation 3: Attack costs and gains

Parametrs, affecting attack economy:

1. Keys in block - as continious attack is mitigation within an assumtion of one honest council member
2. Bond - as submitting it required for each key under attack
3. Initial frontrun deposit = 1 ETH - the amount to deposit within frontrun attack
4. Deposit amount = 32 ETH - the amount provided by protocol on keys deposited

The profit of the attack would be simple:
Total gain = Keys in block x(Deposit amount - Bond)
With Keys in block = 150 ETH and Bond = 4 ETH
Total gain = 4200 ETH

Adding another parametr:

5. Quorum - number of council members to collide and perform an attack

Gain per compromised member = Total gain / Quorum = 1050 ETH with 4 actors quorum

For the purpose of this note we can assume that this is a zero-sum system, ommiting the losses on exiting validators, thereofre the attack gains is simulatiously a loss for protocol.
The control parametrs, that should be used to limit the attack volume are keys in block and Quorum, as initital and deposit amount are within the spec values and bond is considered as primary risk mitigation for risks involved with perfroming validator duties.

Observation 4: Mitigation with reputation

It's assumed that every council member perfroming the attack is a NO for curated set, adding the cost of being excluded from curated module.
Considering 5% NO fee as a constant, calulating the opportunity cost requres adding three more factors:

6. Curated NO keys - number of keys under the operation
7. Margin operational margin for participating in curated set
8. APR staking APR

For this case Year profit = 5% * Curated NO keys x APR x Margin

Within assumption on 10k keys, and conservative appraoch on APR = 3% and Margin = 20% that leads to 96 ETH year profit for one NO

Attack mitigation

Within obesrvations above, the descision on control parametrs can be derived from comparing the attack gains with reputational cost, with a considiration on the amount of stake that could be processed by protocol.

Reccomendation 1: Implemet limit on keys on the module-level

Recommendation 2: Keys in block recommended value for permisionless module(s) is from 20 - 35 keys in block

Within the values above:

Malicious behavior is heavily disinvetized for curated NO
Gain per compromised member would be 140 - 245 ETH
Which is within the range of 145%-255% of conservative estimation of yearly NO profit
Which is considered low enough as an opprtunity cost, as, for example, to reimburce the opportunity cost of 96 yearly profit 3200 ETH as capital required satked within 3% APR.

Amount of stake that could be processed by protcol is within reasonable boundaries
Assuming depositing once every 26 blocks, 20 keys per block would lead to 277 deposits / day (7200 blocs in day divided by 26) which is enough to process 177k ETH (more than a daily satking limit)
With 35 keys the capacity is even higher: 310k ETH / day (enough to fascilitate daily saking limit simultaneously reached before and after oracle report)

Recommendation 3: Quorum number should be considered to increase, in case greater keys in block value is requred

As within increasing the Quorum the attack gain per member falls: e.g. increasing quorum member by 150% would lead to possibility of increasing keys in block aslo by 150%, as with 6 quorum members the same gain as with 20 keys would be reached with 30 keys (increasing porcees limit)

Recommendation 4: Period between deposiing could be reduced to furher attack gains

As within decreasing Period between depositing the keys in block could be decreaed on the same percantage, keeping the same amount of stake that could be proceeesd:
e.g. decreasing it to 13 blocks (by 50%) would make reducing keys in block by 50% (20 to 10) leading to the same amount of stake that could be procees, but reducing attack gain by 50% (to 76% gain to NO profit ratio)

Calulations on different setups