Support beacon chain full withdrawals

[k1rill-fedoseev]

No description provided.

[k1rill-fedoseev]

Beacon Chain spec defines the withdrawal indices: https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#withdraw

Theses are the indices in the withdrawal queue, they are completely independent from deposit or validator indices.

By maintaining the nextWithdrawalIndex in the blockReward contract, we ensure that user cannot request to process withdrawals which haven't happened yet.

The overall logic behind withdrawal processing is then the following:

1. Validator $A$ exits from the beacon chain or is being slashed
2. After some timeout in the beacon chain, the withdrawal is created and placed onto the queue under index $B$
3. The withdrawal from the queue is included into one of the upcoming proposed EL blocks.
4. While processing EL block, the block reward contract is being called, which records the withdrawal in the contract storage. The nextWithdrawalIndex is being updated to a value larger than $B$
5. User calls depositContract.withdraw([A], wrapper, abi.encode(gno, receiver)). This will unlock/mint additional mGNO, send them to wrapper contract, which will in its turn burn received mGNO and unlock required amount of GNO.
6. If the amount of required GNO is not enough, user can exit to mGNO instead depositContract.withdraw([A], user, '0x').
7. Obtained mGNO can be then swapped to GNO by calling wrapper.unwrapTokens(gno, user, mGNO.balanceOf(user)).

Dedicated third-party that is responsible for GNO refills, monitors the available surplus of locked GNO token by using a read-only Lens contract.

[dapplion]

Current dev team is finalizing the design of withdrawals and wanted to comment on the different trade-offs of this proposal.

Current goals

1. In the happy case, user should not be required to perform any transaction to have credited the final* token at the withdrawal address
2. System should handle insolvency gracefully, respecting goal 1.
3. System should require as little intervention from devops as possible, provided that GNO token is not mintable.

This PR's proposal

Uses POSDAO block processing existing system transaction infra add the withdrawal structs to contract state. Then requires an external actor to call withdrawal to actually credit stakers accounts. This approach breaks goal 1.

Alternative proposal

Use POSDAO block processing existing system transaction infra to credit user's accounts directly. Handle insolvency by queuing pending withdrawals and clear them on a future system transaction. For more details see: https://hackmd.io/@dapplion/gnosiswithdrawals

CC: @Barichek

[dapplion]

• Closing for Withdrawals (smart contract part) #25