Yep I had the exact same conclusion when I was listening to the research team chatter. The answer I got was that it wasn’t actually gaining the attackers any resources since there is a necessary buy in, in the first place.
However, my first thought was that this could be a censorship attack like you described (stalling consensus) instead of anything to gain resources directly. You can’t move onto the next round since the business logic is dependant on state updates.
I’d think that a forward evaluation would be useful in this case, seeing what state changes are going to be propagated and using a decisive granularity through to the execution stage, where consensus starts taking place at the individual contract execution level. Then you’d figure out where the stalls were, isolate them from the network, continue with everything else as long as everyone is alright with freezing that contract execution, and not being able to access it at a global level for the next block.
Most likely *that* is where the “ethereum-freeze-and-deploy-release” context would be absolutely useful.
- The contract authors design their structures so that this eventual “final audit” case is to be taken care of.
1. For any integration phases between this contract and anything else that it might affect, non-contested integrals are considered absolutely signed from their originating party.
2. Those original signatures of transactions are the pool of individuals that “care” about this contract being able to be executed even a single step further.
3. Thus, any other contract that reads data from this contract, any other contract that accepts delegate calls from this contract, are mutually consenting parties.
- If this contract’s execution phase is halted by this form of censorship attack, the betting on which state changes are the true ones can continue, but the stakes can be raised exponentially at each step as a “freeze”.
- If the coding of this contract is built to cover this case, the original signature pool can elect to force the decision at any step, and disburse the total bet values of the “losing” side onto the entirety of the coded addresses of the network that have been used in the last Nth blocks (potentially going back to genesis). The “winning” side simply gets its bet back, “releasing” the “deployed” ether.
The goal being to create a special case realm inside of this incentivization system, that effectively separates the logic from the variables, such that if the contract is sound, the individuals that have consented to use the logic should be able to determine if the logic is being used correctly.
The subsystem is isolated, stalls, the ones that forced the isolation to be necessary are still fully engaged within the stalled system, but the rules have changed such that they can still posture, but their posturing can only end up being banished into the proverbial ether. Everyone that stands up to them, the original signatures, have the capability to bet fully aware that any energy they have to put into the system to get their logic unstalled, will be returned to them. They have nothing to gain except for the logic unstalling, and the ones that forced the logic to stall can either immediately lose their deposits, or continue posturing in an attempt to stall the rounds for further iterations, which requires a potentially exponential amount of ether per step and gives time for the original signatures to be notified and act.
It should obviously be noted, for the sake of some semblance of humility, that this suggestion is not fully sound as I don’t control the actual external metrics of the casper game in the first place. However, as far as games go, this is effectively the way to do it. If there’s a party attempting to subvert the system, create situations where their subversion is isolated, change the rules to favor those that have the origination codes to the points being subverted. The reward for standing up to subversion must be intrinsically motivated, and always will be if the realm’s rules are designed correctly.