fix: prev_randao

[constwz]

Summary

• Bug: The PREVRANDAO opcode returns different values during block building vs block validation, causing state root mismatches for any contract that reads PREVRANDAO
• Root cause: Block building path set prevrandao = mix_hash (B256::ZERO or millisecond timestamp), while validation path set prevrandao = header.difficulty() (Parlia INTURN=2 / NOTURN=1)
• Fix: Set prev_randao to the calculated difficulty in prepare_new_attributes, and restore the correct mix_hash in finalize_new_header (since the assembler derives mix_hash from prevrandao)

Details

In BSC's Parlia consensus, the PREVRANDAO EVM opcode returns the block difficulty (not a random value like Ethereum PoS). Two code paths configure the EVM environment:

Path	prevrandao value	Used for
BscEvmConfig::evm_env (validation)	header.difficulty()	Verifying existing blocks
BscEvmConfig::next_evm_env (building)	attributes.prev_randao = mix_hash	Building new blocks

The mix_hash field in BSC is B256::ZERO (pre-Lorentz) or encodes the millisecond timestamp part (post-Lorentz) — neither matches the difficulty value. This causes the PREVRANDAO opcode to return different results during building vs validation.

Changes in src/node/miner/util.rs

1. prepare_new_attributes: Changed prev_randao from new_header.mix_hash to calculate_difficulty(&snapshot, signer).into() — matching the validation path
2. finalize_new_header: Added mix_hash restoration after the assembler sets it from prevrandao. Recomputes the correct value using block_time_for_ramanujan_fork (B256::ZERO pre-Lorentz, millisecond part post-Lorentz)

Test plan

• Verify cargo check passes (confirmed locally)
• Run validator node on testnet and confirm blocks are accepted by peers
• Verify mix_hash in produced block headers matches expected format (zero pre-Lorentz, ms-encoded post-Lorentz)

🤖 Generated with Claude Code