Miner-modifiability of block timestamp after the Merge

Question

Under proof of work, the Ethereum block interval varied, but miners could modify the block timestamp by +/-15 seconds, as long as the modified value was greater than the parent timestamp, without the block getting rejected.

Under proof of stake, the Ethereum block interval is fixed at 12 seconds (or possibly a multiple of 12 seconds, in rare cases).

Does that mean block timestamps can no longer be tweaked or fudged by miners, after the Merge?

Answer 1

Does that mean block timestamps can no longer be tweaked or fudged by miners, after the Merge?

That's correct, (post-Merge) consensus on valid blocks is pre-determined timestamps that are not modifiable.

Each slot has an expected timestamp, and a block without that exact timestamp is not valid. The block after the beacon chain genesis is expected to have a timestamp exactly 12 seconds after the genesis block. The block after it 12 seconds after, and so forth.

The spec defines:

def compute_timestamp_at_slot(state: BeaconState, slot: Slot) -> uint64:
    slots_since_genesis = slot - GENESIS_SLOT
    return uint64(state.genesis_time + slots_since_genesis * SECONDS_PER_SLOT)

and SECONDS_PER_SLOT as:

SECONDS_PER_SLOT: 12

Checking a block is valid is in process_execution_payload:

# Verify timestamp
assert payload.timestamp == compute_timestamp_at_slot(state, state.slot)

---

https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/fork-choice.md#fork-choice also has some notes including:

1. Leap seconds: Slots will last SECONDS_PER_SLOT + 1 or SECONDS_PER_SLOT - 1 seconds around leap seconds. This is automatically handled by UNIX time.
2. Honest clocks: Honest nodes are assumed to have clocks synchronized within SECONDS_PER_SLOT seconds of each other.

Answer 2

Validators (formerly miners) can still modify the block.timestamp. Before miners could manipulate the block.timestamp but if they were able to create the block. If they had 20 percent of hash power, they had a 20 percent of chance to create the block, so that their transaction will be confirmed. Even if they created the block, it is extra hard to pass the valid "timestamp". Let's say, in a contract, there is a gambling function that sends you the entire balance if you pass the correct "timestamp"

if(block.timestamp%11==0){
        (bool sent, )=msg.sender.call{value:address(this).balance}("");
        require(sent,"Failed to send Ether");
    }

Now miner has to find such a "timestamp" that satisfies the "if" condition.

After ethereum merge:

For each slot, a validator is selected at random and is responsible for creating the new block while a committee of validators is randomly chosen to verify the work of the validator creating the new block. The randomly selected validators receive a reward of Ether for their efforts.

So, after the merge, the chance of creating the block for the validator is "1/numberOFNodes". It is not related to hash power anymore. currently, there are about 400.000 validators.

Answer 3

I would consider that manipulation of block timestamp to be difficult after the merge, which employs a different set of consensus rules. It will use more reliable timestamps (at 12 seconds intervals), or avoid the use of difficulty adjusted timestamps entirely.