chore: add restart for the docker services and set L1_RPC_KIND for op-node

[lesterli]

Summary

This PR updates the docker services for L2:

• add restart: unless-stopped to avoid downtime
• add the env var L1_RPC_KIND: "standard" for the op-node to optimize block receipts fetching

more context:

Based on the OP code, the default behavior uses the RPC method eth_getTransactionReceipt to fetch block receipts.

In the case of L1 block 7142979, which includes 878 txs, this would require 878 RPC requests to fetch the block's receipts, potentially hitting RPC limits. To address this, we set the env var L1_RPC_KIND: "standard", which switches to using the eth_getBlockReceipts method, this would only require 1 RPC request which offers better performance in terms of RPC limits.

Test Plan

updated for devnet 7, restart works fine, and will check the op-node's log on the RPC requests for block receipts

[bap2pecs]

add the env var L1_RPC_KIND: "standard" for the op-node to optimize block receipts fetching

Could you add more context why the change?

As discussed with Noderpc, isn't the issue due to rate limiting? Then why does switching the RPC method fix it? Is it because the other RPC has a different limit?

[lesterli]

Could you add more context why the change?

added more context

As discussed with Noderpc, isn't the issue due to rate limiting?

after checking the logs, most of the failed blocks have over 400 txs, so the issue is likely caused by hitting the RPC limit

Then why does switching the RPC method fix it? Is it because the other RPC has a different limit?

eth_getBlockReceipts only requires a single RPC request compared to eth_getTransactionReceipt, even though it has a lower rate limit as it is computationally more intensive.

[bap2pecs]

Could you add more context why the change?

added more context

As discussed with Noderpc, isn't the issue due to rate limiting?

after checking the logs, most of the failed blocks have over 400 txs, so the issue is likely caused by hitting the RPC limit

Then why does switching the RPC method fix it? Is it because the other RPC has a different limit?

eth_getBlockReceipts only requires a single RPC request compared to eth_getTransactionReceipt, even though it has a lower rate limit as it is computationally more intensive.

thanks this context is very clear to understand. all makes sense now.

[bap2pecs]