Writing a collusion contract is easy, achieving collusion is hard. The scenario we’re most worried about here is blind outsourcing of block-building AND blind attestations from validators to a single attacker. In the current mainnet design, it is entirely viable that block-building could be outsourced, but for validators to attest to blocks without checking their validity is another. Have you thought about what the specifics of such a bribing contract? It could be an interesting exercise to discuss what it could look like and the types of bribes that validators would need to accept the bribe.
Borrowing still exposes the borrower to capital loss – more than just owning the tokens in the case of DeFi over-collateralization. However, it does also expose the lender, as most/all(?) lending protocols will incentivize liquidators to re-buy Aztec tokens on behalf of the lender. Lending could be a dangerous game in the early days given this – especially if there is a liquid long/short futures market.
Which auction?
There needs to be some WITHDRAWAL_TAX – the EH proposer will have monopoly sequencing rights for a full epoch. Given the permissionless nature of becoming the EH, the protocol and its underlying applications would prefer this didn’t happen – monopoly sequencing without a strong incentive to do good for the protocol (as is the case in centralized sequencer rollups) is bad for business. The tax charges for this.
We can only make educated guesses here. There are some high-level scenarios to consider:
- Normal proposing good, EH proposers bad: (1- (1/112)) blocks are used for exiting
- Normal proposing broken, EH proposers good: <(1/112) blocks are used for exiting
- Normal proposing broken, EH proposers bad: nothing we can do here.
We need to assume that in the unlikely scenario that normal proposing breaks, honest EH proposers will step up to exit their own funds, as well as including other users’ transactions to help subsidize the reasonably high cost of exiting (token ownership, tax, onboarding as a EH proposer, L1 fees, etc). In this scenario, we have approx (30 x 24 x 60 x 60) *1/122 seconds available for exiting. At 1 TPS, this is 21,000 transactions available for exiting – in the reality of complete failure of normal proposing, 21,000 is an upperbound. However, with the active research path of state migration ongoing, certain apps may have back-up plans for enabling migration to new rollup instances that doesn’t require a per-user exit transaction on the previous rollup instance. That being said, at 1/112 EH frequency, users must be conscious of this – whether their funds/credentials need an exit transaction or not. Interested to see more designs on the migration side 