refactor: attester/proposer simplication

[LHerskind]

At the time of writing this, we have a setup where a set of addresses makes up the validator. Namely we got (attester, proposer, withdrawer). Where the proposer could be the same as the attester in most cases, but atm is a separate entity such that it is possible to write a contract that constrain values before proposing.

proposer-eao -> proposer contract -> rollup

This setup meant that you could more easily get around a trustless share of funds between a delegator and a delegatee. However, looking at what users actually value, they don't seem to care about this (based on looking at lido and other kinds of staking setups derivates). Therefore it seems like a potential simplication to just nuke the proposer separation here, and instead just require that the attester have signed the payload.

This have some benefits, since it allow us to not need to go from a specific contract, so you can somewhat easily go through multicall or just use a common generic forwarder contract if desired. This allow for some gas savings in the case where there are only a block proposal hence it don't need to be relayed through a different contract first.

Pros:

• reduce cost
• code is a bit simpler Cons:
• more difficult to constrain

Overall, it seems like it is worth it, because there seem to fairly limited interest in actually using custom forwarders to restrict.

[LHerskind]

An additional thing that sprung out from this when I started. When the block proposal is not required to be emitted using the actual proposer, you are free to separate it from the other proposals if you want and we can more easily just completely bypass any kind of forwarder. Some of it depends a bit on how the slashingproposer and govproposer is made.

So by using an account that is not the proposer to publish the actual block production, you can get away with just doing "normal" calls to make the calls to the governance proposer if desired, which means that as it is much more separated you avoid the issue where it battles with some of your other transactions, you just cast the signals as soon as you can. Though they should likely also be altered to allow a signature to allow not using the proposer and relying a normal multicall (or be fancy and use eoa account code).

[LHerskind]

Further extensions are to be made here for the governance and signalling to work properly. Namely, if the proposer is not longer the forwarder, the calls wont come from the proposer and they will fail when used in the voting.

[aminsammara]

Is this usecase still possible?

1. Network User delegates to Node Operator via picking their attester address.
2. Node Operator does not want to custody any block inflation so they pick COINBASE to be some splits contract.
3. Block inflation is distributed between Network User and Node Operator according to the terms defined in splits contract

Does not matter who initiates a claim tx from the rollup.

[LHerskind]

2. Node Operator does not want to custody any block inflation so they pick COINBASE to be some splits contract.

Attester picks, as they are the proposer. So if they want to pick a split they can do that, the diff is on the ease of enforcability.