Implements RIP-7728

[mralj]

RIP-7728

This proposal introduces a new precompiled contract, L1SLOAD, that loads several storage slots from L1, requiring a contract address, storage keys, and RPC connection to L1.

Implementation details

To leverage this precompile node runner on L2; it must have the following:

1. Some Notion of latest L1 block
2. RPC connection to L1 node, preferably "fast one" since we are making L1 RPC call during EVM precompile execution.

Our rollup-geth has a flag --rollup.l1.rpc_endpoint from which it reads the URL of the required L1 RPC.

Overriding the default config

Out of the box, rollup-geth provides the following method for "dealing" with the latest L1 block:

var defaultRollupPrecompilesConfig RollupPrecompileActivationConfig = RollupPrecompileActivationConfig{
	L1SLoad: L1SLoad{
		GetLatestL1BlockNumber: LetRPCDecideLatestL1Number, // CHANGE THIS METHOD
	},
}

The code is located in core/vm/contracts_rollup_overrides. We should pass into the GetLatestL1BlockNumber appropriate method for providing the latest L1 block on the L2 blockchains.

Example:

var defaultRollupPrecompilesConfig RollupPrecompileActivationConfig = RollupPrecompileActivationConfig{
	L1SLoad: L1SLoad{
		GetLatestL1BlockNumber: GetLatestL1BlockNumber
	},
}

func GetLatestL1BlockNumber(state *state.StateDB) func() *big.Int {
	return func() *big.Int {
		addressOfL1BlockContract := common.Address{}
		slotInContractRepresentingL1BlockNumber := common.Hash{}
		return state.GetState(addressOfL1BlockContract, slotInContractRepresentingL1BlockNumber).Big()
	}
}

[Thegaram]

Follower nodes cannot allow timeout when processing blocks, they must retry if the request failed or timed out. Is the idea here that sequencer nodes would enable params.L1SLoadRPCTimeoutInSec, but follower nodes would not?

[mralj]

Yes!. I should've documented this, good catch.
The intent behind this was that, I was "afraid" that if no timeout mechanism was available to the Sequencers , that, even though improbable, this could lead to situation (either caused by some weird bug or even by an "attack") where Sequencer is stalled for a long period of time. And since most (all?) L2s have centralised sequencers this seemed "pretty bad".

And I agree, since followers are "just" processing blocks it makes no sense that they create "local forks" in case of the timeouts.

they must retry if the request failed or timed out

Agreed, I should've added some retry mechanism it makes sense that followers have one.

---

Thinking about this one bit more, I realise the question remains: What if "follower" cannot validate block because it cannot get response from it's RPC (eg. RPC "dies") or just for some reason errors? Do you have some thoughts about this one?

In scenarios where we just wait for RPC or "constantly" retry, the follower will just get stuck here and fall behind.
From UX perspective does it make sense to crash node in this scenario? I'm thinking that people running followers are more likely to notice "dead" node than one fallen behind (which I guess will have to be restarted anyways)?

Alternative is that we can "allow" (by eg. erroring after N retires or even introducing some longer timeout) follower to create "private fork" in hope it will "heal itself" eventually.

[Thegaram]

Sequencer is stalled for a long period of time [...] this seemed "pretty bad"

Exactly, and high latency would also affect sequencer throughput. So a timeout (or some more sophisticated heuristic) is needed for sequencer nodes.

What if "follower" cannot validate block because it cannot get response from it's RPC (eg. RPC "dies") or just for some reason errors?

Follower nodes need reliable access to an L1 node anyway. They should independently verify deposits. Technically this is optional, but not verifying deposits is dangerous as it would allow the sequencer to mint a large amount of tokens and use it with exchanges/apps that don't wait for finalization.

So I think it's reasonable to assume that follower nodes have a reliable L1 RPC connection.

From UX perspective does it make sense to crash node in this scenario?

Yeah, interesting. I think retrying a few times (with maybe exponential backoff) would make sense, but I agree we shouldn't retry forever, better to crash after some tries.

Alternative is that we can "allow" (by eg. erroring after N retires or even introducing some longer timeout) follower to create "private fork" in hope it will "heal itself" eventually.

Hm... generally follower is not authorized to sign blocks, so I'm not sure this would work. And the follower's private chain would not become the canonical, finalized chain.

[mralj]

Cool! Thanks for the feedback :)
I've created the issue for this so that I don't forget it, as I'm currently working on other things. You can check it out here. Given your feedback and this discussion, I think it is a reasonable starting point, and if need be, further improvements can be made later on.