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 Optimism (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 Optimism, 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 Optimism 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 | ~15 minutes |
| Cost | Cheapish (requires an L1 transaction) |
| Trust assumption | Same as using Optimism |
# Messages from L2 to L1
Sending messages from L2 to L1 is a lot harder. It requires two transactions:
- An initiating transaction on L2, which is pretty cheap.
- Once the fault challenge period passes, a claiming transaction on L1, which includes a merkle proof (opens new window). This transaction is expensive because merkle proof verification is expensive.
| Parameter | Evaluation |
|---|---|
| Speed | >7 days |
| Cost | Expensive |
| Trust Assumption | Almost as good as using Optimism, however someone needs to initiate the claim transaction on L1 |
# 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.