Communication Strategies
Dapps' inter-layer communication strategies are based on trade-offs between several parameters:
- Speed
- Cost
- Trust assumptions
An issue related to both speed and decentralization is the L2 state. This state is vulnerable to fault challenges until the fault challenge period (currently one week) passes. If you want to do something that relies on the L2 state prior to that point, you should run a replica yourself to make sure the state you use is correct.
# Fully centralized
If your dapp has a centralized always on server, the easiest solution is to just have two providers, one connected to Ethereum (L1) and the other to OP Mainnet (L2).
| Parameter | Evaluation |
|---|---|
| Speed | Fastest |
| Cost | Cheapest |
| Trust assumption | Centralized |
# Using the client (please don't)
The client (typically a browser with a wallet) can also connect to both Ethereum and OP Mainnet, but it isn't a great mechanism for inter-layer communication. You know what the code in the server is, because you wrote it. You know what the code in the client is supposed to be, but it is possible for users to run a different client that pretends to be the legitimate one. The only time that you can trust the client for inter-layer communication is when it is in the best interest of the user running the client not to lie. And even then, you shouldn't because a hacker can cause a user to run malware.
# Fully decentralized
If you want to keep the same decentralization promises as OP Mainnet and Ethereum, you can rely on our messaging infrastructure. You are already trusting Optimism to run the chain, and the messaging infrastructure goes through the same development process.
# Messages from L1 to L2
If you want L1 code to either tell L2 code to do something, or update L2 code with some information, you just need to issue a single L1 transaction.
| Parameter | Evaluation |
|---|---|
| Speed | About one minute |
| Cost | Cheapish (requires an L1 transaction) |
| Trust assumption | Same as using OP Mainnet |
# Messages from L2 to L1
Sending messages from L2 to L1 is a lot harder. It requires three transactions:
- An initiating transaction on L2, which is pretty cheap.
- After the state root is posted to L1, a proving transaction of L1, which includes a merkle proof (opens new window). This transaction is expensive because merkle proof verification is expensive.
- After the fault challenge period passes, a claiming transaction on L1, which runs the actual transaction on L1.
| Parameter | Evaluation |
|---|---|
| Speed | >7 days |
| Cost | Expensive |
| Trust Assumption | Almost as good as using OP Mainnet, however someone needs to run the proof and claim transactions on L1 (your server can do that for better user experience) |
# Incentivized communication
You can also use incentives, for example using a mechanism such as UMA's. This is similar to the way optimistic rollups work - honest relays get paid, dishonest ones get slashed. However, this mechanism is only truly decentralized if there are enough relayers to make sure there will always be an honest one. Otherwise, it's similar to centralized communications, just with a few extra relayers that can take over.