You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: sites/optimism/docs/interoperability/intro-to-interop.md
+10-6Lines changed: 10 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,9 +3,10 @@ id: intro-to-interop
3
3
title: Mental model
4
4
sidebar_label: Mental model
5
5
---
6
-
This section explains the foundational mental model of OP Stack interoperability, from how messages are emitted and consumed to the validation logic that makes them safe.
7
6
8
-
When we say *interoperability*, we are talking about the ability of one chain to read and act on messages from another chain.
7
+
This section explains the foundational mental model of OP Stack interoperability, from how messages are emitted and consumed to the validation logic that makes them safe.
8
+
9
+
When we say _interoperability_, we are talking about the ability of one chain to read and act on messages from another chain.
9
10
10
11
In the OP stack, interop is built into the protocol. Chains should be able to emit logs, call initiating messages, and other chains should be able to consume them as inputs to their own transactions. **This does not require routing through Ethereum L1.**
11
12
@@ -22,6 +23,7 @@ Native interop solves this by allowing chains to read logs from each other witho
22
23
Interop is based on events. One chain emits an event. Another chain sees it and takes action.
23
24
24
25
Each cross-chain message has two parts:
26
+
25
27
-**Initiating message**: A log emitted on the source chain.
26
28
-**Executing message**: A log emitted on the destination chain, pointing to the initiating message.
27
29
@@ -36,17 +38,19 @@ struct Identifier {
36
38
uint256 chainid;
37
39
}
38
40
```
41
+
39
42
This identifier is used to prove that the message exists and that it has not expired.
40
43
41
44
### Validity
42
45
43
46
A message can only be consumed if it is valid. There are three invariants:
47
+
44
48
-**Timestamp**: The initiating message must have a timestamp less than or equal to the executing message.
45
49
-**Chain ID**: The source chain must be in the destination chain’s dependency set.
46
50
-**Expiry**: The message must be consumed within a fixed time window after it is created. This window is currently set to 180 days.
47
51
48
-
:::info
49
-
If this time window elapses, the message can be re-sent on origin to make it available using `L2ToL2CrossDomainMessenger#resendMessage`.
52
+
:::info
53
+
If this time window elapses, the message can be re-sent on origin to make it available using `L2ToL2CrossDomainMessenger#resendMessage`.
50
54
:::
51
55
52
56
If any of these invariants fail, the executing message is invalid. Any block that includes it will be reorged.
@@ -65,12 +69,12 @@ This configuration tells the node **which chains to watch**, **which logs to ind
65
69
66
70
:::info Can I just depend on OP Mainnet?
67
71
68
-
No. Each chain’s dependency set must explicitly include the chains it wants to receive messages from. Depending only on OP Mainnet does *not* automatically grant interoperability with every other OP Chain.
72
+
No. Each chain’s dependency set must explicitly include the chains it wants to receive messages from. Depending only on OP Mainnet does _not_ automatically grant interoperability with every other OP Chain.
69
73
70
74
To enable seamless interop, chains should include all intended counterparties in their dependency set. This is why Superchain clusters aim to configure **fully connected meshes**, where every chain includes all others.
71
75
:::
72
76
73
-
### Who *enforces* interop?
77
+
### Who enforces interop?
74
78
75
79
Most of the interop logic is enforced by the **consensus node software**, not by contracts.
Copy file name to clipboardExpand all lines: sites/wonderland/docs/testing/advanced-testing/overview.md
+16-16Lines changed: 16 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -99,22 +99,22 @@ function testOne() public {
99
99
- Check the coverage to see if the test itself is not (silently) reverting and if the target code is actually covered
100
100
- Make sure both sides of a revert are covered with try - assert - catch - assert.
101
101
- Mutate the property itself or the target code. See [Mutation testing](../mutation-testing.md) for more details
102
-
<aside>
103
-
⚠️
104
-
105
-
Unlike what you could be used to in regular unit or integration tests, only assert with a condition equals to false will make a test revert - without the previous checks, it is therefore easy to take a passing test for granted, especially as most contracts are using require and revert (in other words, if one doesn’t pay attention, one can easily end up testing nothing).
106
-
107
-
```solidity
108
-
function testOne() public {
109
-
require(false);
110
-
}
111
-
112
-
function testTwo public {
113
-
assert(false);
114
-
}
115
-
```
116
-
117
-
</aside>
102
+
103
+
:::warning
104
+
105
+
Unlike what you could be used to in regular unit or integration tests, only assert with a condition equals to false will make a test revert - without the previous checks, it is therefore easy to take a passing test for granted, especially as most contracts are using require and revert (in other words, if one doesn't pay attention, one can easily end up testing nothing).
106
+
107
+
```solidity
108
+
function testOne() public {
109
+
require(false);
110
+
}
111
+
112
+
function testTwo public {
113
+
assert(false);
114
+
}
115
+
```
116
+
117
+
:::
118
118
119
119
- Any state which can be accessed or reconstructed from the target should be (even if some needs to be recomputed, for instance reducing individual balances to a cumulative sum). If there is no way to do so, then a ghost variable should be used (either in the relevant handler, or, usually easier, in a “BaseHandler” contract, with relevant helper functions).
120
120
- Always start with validating the initial setup and sanity checks as “property-0”. For instance, address of the deployed contract ≠ 0, calling some constant variables, etc.
0 commit comments