Staking and Slashing #31
Conversation
updated name and added non POG slashable offenses
Add staking mechanism
| On the L1, the contract verifies that: | ||
| 1) The epoch has indeed re-orged. | ||
| 2) The committee members named in the slashing proposal have signed the specific block in question. | ||
| 3) Validators in control of more than 50% of stake have signed the slashing proposal. |
There was a problem hiding this comment.
If 50% of stake has signed off, do we need the other criteria?
As a technical aside, I'm not sure how we'd check that the block had the named committee members if we're also asserting that the block was reorged out.
There was a problem hiding this comment.
Continuing the above thought, you may want to be explicit that the L1 does not actually care if the people named in the slashing proposal actually signed off on an invalid state root.
That is, I would introduce the generic, PoG slashing function on the rollup contract first, as "part of the protocol", and then give examples of how it could be used, which are explicitly "out of protocol" e.g. punishing signers of an invalid state root.
To that end, I'd suggest that the generic PoG slashing function doesn't concern itself with checking the state of the chain. That can be part of whatever out of protocol evidence is gossiped to convince validators to sign the proposal.
This makes the logic easier, and more flexible in the event of whatever new event one wants to slash for.
There was a problem hiding this comment.
As a technical aside, I'm not sure how we'd check that the block had the named committee members if we're also asserting that the block was reorged out.
I looked this up as I was unsure myself. This post says that calldata gets merkalized in contract storage. So someone needs to present to the contract, the calldata as well as a merkle proof to reference it. I couldn't find an implementation though.
There was a problem hiding this comment.
Im not entirely convinced the clarification in the link posted there is correct. The full calldata will be found in the transactions trie. As far as im aware there is no special location for calldata in a contracts storage, unless they are referring to a specific optimistic rollup implementation that stores the roots of the published calldata when performing batching.
for us to prove it's existence we will need to prove this against the block hash which is accesible in the evm. It is likely enough to just run off of signatures here rather than attempt to prove that the tx existed.
| A ->> E: Propose Block | ||
| D ->> E: Retrieve TxHash | ||
| par | ||
| D ->> B: Request TxEffect + Proofs |
| Since "Ethereum was congested" is a subjective statement, two ways we could implement this: | ||
|
|
||
| 1) Make $t$ larger, giving the prover enough time to convince the validators to manually update their software to vote to unslash the prover. This could be done on the forums or validator community channels for example. | ||
| 2) Add an environment variable `max_eth_base_fee` that clients agree to implement. If `base_gas_fee > max_gas_fee` at the proof submission deadline time, then validator nodes automatically sign votes to unslash prover. |
There was a problem hiding this comment.
Similar to the thoughts above, I would avoid explicitly coding things like this; such an event ought to be a rarity: leave it to the forums.
Further, if the base fee were found to have been low for the majority of the proof submission window, or even more specifically for the period of time during which 95% of proofs land, I wouldn't want everyone to automatically unslash.
There was a problem hiding this comment.
Further still, if there is an auto-unslash clause, provers could be more willing to not submit if fees are even somewhat elevated.
|
|
||
| They are largely equivalent except that the second requires less coordination. | ||
|
|
||
| ### PoG Non-slashable offences |
There was a problem hiding this comment.
If you loosen/simplify the generic slashing function on the rollup, these are all slashable.
I think the goal should be that one is able to post on a forum and say "so and so did X", circulate a slashing proposal via p2p, get the votes via p2p, and effect the consequences.
| Why is this hard to implement? | ||
| - We're designing S&P coordination to be out-of-protocol. The above assumes provers send quotes via the p2p. | ||
| - Provers currently can send quotes even without having the necessary bond. | ||
| - Provers could send the quotes to a partition of the network, excluding the proposers who can activate the quote. This leads to timing games. |
There was a problem hiding this comment.
It is unclear to me what is meant by "timing games" here.
There was a problem hiding this comment.
I think it refers to this type of scenario: You make a case that you submitted the proposal on time, and there is timestamp / log evidence that you did so, but you submitted it late enough that it did not propagate to the sequencers who would have sent it??
I dont think the protocol should be forgiving in these scenarios, Provers should send quotes via p2p or spray it to many validators to avoid this happening to them.
| Upon entering Based Fallback mode, validators can slash the committee members who have not submitted blocks during their slots. Since entering Based Fallback mode requires $T_{\textsf{fallback, enter}}$ time of no activity on the Pending Chain, validators initiate a proposal to slash the inactive committees during that time period. | ||
|
|
||
| Why is this hard to implement? | ||
| - A malicious committee could abuse the Resp/Req module to send attestations to a partition of the network but not the current proposers. While the validators will then gossip the attestations back to the proposer, they may not make it back on time. Again timing games. |
There was a problem hiding this comment.
I don't follow the attack here.
There was a problem hiding this comment.
Presently, Req/Resp is only used for requesting TxObjects that a validator is missing, unless I'm mistaken @Maddiaa0 .
There was a problem hiding this comment.
correct, the protocol describes a message format that honest nodes will follow, they cannot be sent data that does not follow it. And it does not allow for accepting attestations.
When amin asked about this I misunderstood what he was asking, which is why this is present here.
| 1) More precision in slashing. Honest node operators should not be slashed but we need offchain evidence to do this. | ||
| 2) Provers can appeal to the validator set to unslash them in the case they could not submit their proof on time (i.e. Ethereum congestion, or an attack on proving marketplace nodes) | ||
|
|
||
| So we rely on validators to vote to slash dishoneset actors. |
There was a problem hiding this comment.
| So we rely on validators to vote to slash dishoneset actors. | |
| So we rely on validators to vote to slash dishonest actors. |
|
|
||
| ### Migrating Stake | ||
|
|
||
| The `Deposit` contract is owned by the Governance Contract. As such in the event of an upgrade, the Apella can change the `StakedDeposits` mapping so that any `StakeObject` with `followingRegistryBool=true` can be moved to the new Rollup as pointed to by the Registry contract. |
There was a problem hiding this comment.
May want to clarify that this is only an upgrade in the canonical rollup version, not any governance proposal.
|
|
||
| Validators that choose `followingRegistryBool=false`, will have to exit funds and move manually. Note that this does not require block building on the old Rollup instance to be functional. | ||
|
|
||
| In the event of a Migration (i.e. state wipe), a new Deposit contract must be deployed. |
There was a problem hiding this comment.
Can you clarify what these two flows look like?
There was a problem hiding this comment.
particularly interested in how the validators get added to the new instance, will a rollup contract always delegate getting it's validator information from this registry, or will it also store what it's validator set is within the contract.
Do we have a doc on which upgrades will need to be migrations?
| ## Questions to Consider During Review | ||
|
|
||
| 1. Executing Validators can spam the network with slashing proposals in DOS attack on the p2p. Do we need to make this expensive? i.e. stake some TST then initiate the proposal? | ||
| 2. Does a slashing proposal need >50% of the stake? Or >50% of the validators? |
There was a problem hiding this comment.
I'd vote for unrestricted slashing based on >60% stake.
|
|
||
| | | | | ||
| | -------------------- | --------------------------------- | | ||
| | Issue | [title](github.com/link/to/issue) | |
There was a problem hiding this comment.
| | Issue | [title](github.com/link/to/issue) | | |
| | Issue | [title](https://github.com/AztecProtocol/aztec-packages/issues/8754) | |
|
|
||
| ```solidity | ||
|
|
||
| interface IDeposit { |
There was a problem hiding this comment.
nit: this interface could which of these functions are privileged, useful to have this context earlier rather than learning about it later on
e.g. activateValidator is only callable by a rollup contract.
| function slashValidator(address rollupAddress, address validatorAddress) external returns(bool); | ||
| function getRollup() internal view returns(address); | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Later it is stated that apella is able to adjust the rollup contract with followRegistry set, will probably need to be added to the interface. Or will they just call getRollup in this case when calling activateValidator?
| ``` | ||
|
|
||
| ### Deposit Function | ||
|
|
There was a problem hiding this comment.
question: Does min deposit amount imply weighted stake? or will there be some max effective balance too
|
|
||
| * Validators must deposit at least `MIN_DEPOSIT_AMOUNT`. | ||
| * A successful call results in an entry in the `Deposits` mapping. This mapping is a `mapping(address rollupAddress => mapping(address validatorAddress => DepositLib.DepositObject))` | ||
| * A `DepositObject` contains references to the `withdrawalAddress` and `followingRegistryBool` variables. It is unique per rollupAddress / validatorAddress combination. |
There was a problem hiding this comment.
Do we want validators to be able to "unset" the follow registry flag without needing to withdraw and deposit again?
| Based on the offense in question, the rollup contract establishes max slashable stakes. The rollup contract also verifies certain conditions have occured before executing the slash. | ||
|
|
||
| This is more subjective than purely onchain slashing but it enables precision that is not possible with purely onchain slashing. We can adopt Ethereum's principle of "honest validators should not be slashed" at the expense of increased coordination cost. | ||
|
|
There was a problem hiding this comment.
We will need to describe the mechanism / rollup contract function that allows slashing conditions to be added and their max slash-able stakes to be updated
| The Executing Validator prepares a payload containing: | ||
| 1) The offense in question: Invalid state root | ||
| 2) The slot number of the invalid block. | ||
| 3) The list of committee members who signed off on the invalid block. |
There was a problem hiding this comment.
Should a validator accept this proposal if only a subset of mis-signing committee members are included in the proposal, this seems like a decent amount of work here.
Say I controlled some of the nodes who may get slashed for this, since creating a proposal here seems free, I would spam proposals that include my other committe members getting slashed and not my own node. ?
Also in the case we cover this by requiring validators to check all signatures that mis signed, each of these proposals makes nodes do a more work, so they should ideally have a cost associated with them.
| else If state root doesn't match L1 | ||
| C ->> D: Sign slashing proposal | ||
| end | ||
| D ->> D: Aggregate BLS signatures |
There was a problem hiding this comment.
At the moment without sufficient precompiles, there is a non negligible cost to producing the aggregate key for these batched signatures. (additions over the BLS12-381 curve). Are we asssuming the existence of these precompiles to do this or will we brute force do it anyway
| The above scenario describes the "happy path" where a stupid committee coordinates an attack and shares the data with the rest of the validator set. In a sophisticated attack, the committee will plot to withhold the data. | ||
|
|
||
| The question boils down to: Do we punish data withholding attacks given that they cannot be verified by the L1? | ||
|
|
There was a problem hiding this comment.
The mechanism for producing a data witholding attack claim will look different to this. Im not sure there is a way for a validator to make a claim like this without some kind of DAS implementation ( that i am not intimately familiar with ).
I imagine data witholding slashing will make its way to apella rather than being sorted among the validators themselves
|
|
||
| The answer is -> Yes! A majority stake voting incorrectly on a data withholding attack is an even stronger violation of our honest-committee assumption. Honest committee members protect themselves by gossipping the tx data to as many peers possible. | ||
|
|
||
| Therefore the Executing Validators who can't download all `TxObject` and proof data for any given block should initiate a data withholding slashing proposal, which works in exactly the same way as the invalid state root slashing proposal. |
There was a problem hiding this comment.
Ok maybe this can work, but we cannot target who we slash, we slash literally everyone??
( again initiating this one should have a cost associated with it maybe )
|
|
||
| 1. Executing Validators can spam the network with slashing proposals in DOS attack on the p2p. Do we need to make this expensive? i.e. stake some TST then initiate the proposal? | ||
| 2. Does a slashing proposal need >50% of the stake? Or >50% of the validators? | ||
| 3. Do we really want to want to pay a small fee to cover the cost of verifying the BLS signature on L1? Makes slashing someone free. |
There was a problem hiding this comment.
I think incentivizing and paying a bonus to watchers is fine
No description provided.