docs: Introduce interop nomenclatures #24
Conversation
NOMENCLATURE.md
Outdated
| - **Origin Chain**: The chain where a cross-chain operation originates. | ||
| - **Destination Chain**: The chain where a cross-chain operation is received/executed. |
There was a problem hiding this comment.
A better definition would be for the origin chain to be the chain where the User's funds initially exists, or where the user interaction starts, and for the destination chain to be where the user intends for side effects/state changes to ocurr
| ## Addresses | ||
|
|
||
| - **Chain Identifier**: A unique identifier for a blockchain used as part of the address formated. Do not confuse it with the Chain ID introduced in [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md), even though it may be used as a reference in some cases. |
There was a problem hiding this comment.
is this an abstract concept? or something that's defined at a technical level?
There was a problem hiding this comment.
Currently abstract, it should be adjusted as we move forward
NOMENCLATURE.md
Outdated
| ## Intents | ||
|
|
||
| - **`Fill`/Filling**: The act of executing a user's cross-chain intent on the destination chain. The participant who fulfils a user's intent on the destination chain is called a **filler** or **solver**. | ||
| - **`Leg`**: A portion of the user's intent that can be executed independently from the others. All legs must be executed for an intent to be considered fulfilled. | ||
| - **Settlement**: The process of finalizing an intent operation, for example by managing user deposits and paying fillers. The contract responsible for this is called the **Settler**. |
There was a problem hiding this comment.
could you further explain the difference between Fill and Settlement?
NOMENCLATURE.md
Outdated
| - **`send`**: Used to denote the act of sending a message. Generally, the functions responsible for this are named `sendMessage`. | ||
| - **`receive`**: Used to denote the act of receiving a message. Depending on the context, receiving a message may have its own flow or involve multiple steps. Functions might be named `receiveMessage`, `relayMessage`, `validateMessage`, `executeMessage` or similar. | ||
| - **`Metadata`**: Information about the message (sender, receiver, nonce, etc.) | ||
| - **`ChainId`**: Referes the chain identifier. Others might refer to it as "domain" instead of "chain," or simply as the destination. |
There was a problem hiding this comment.
is this one actually EIP-155? is it the same thing as the Chain Identifier defined above? I believe it makes sense to couple concepts directly in their definition if applicable
There was a problem hiding this comment.
s/Others/Other sources/ ? s/Others/Existing implementations/ ?
There was a problem hiding this comment.
Good question. Currently, it is not, but there could be coincidences, especially if both use the (raw) EIP-155 IDs. Ideally, I do think there should be equivalence at some point.
There was a problem hiding this comment.
Is this a problem that should be resolved with the help of on-chain registries? maybe, it could be useful
NOMENCLATURE.md
Outdated
| ## Messaging | ||
|
|
||
| - **Message**: Data transmitted between chains. | ||
| - **`send`**: Used to denote the act of sending a message. Generally, the functions responsible for this are named `sendMessage`. |
There was a problem hiding this comment.
afaik, locally to one chain, messages are not really sent, instead what send denotes is the act of marking a piece of information (message) as something we would like to appear somewhere else, by means which to the execution layer are completely opaque
sidenote: are messages data or information?
There was a problem hiding this comment.
This is good, improved!
NOMENCLATURE.md
Outdated
|
|
||
| - **Message**: Data transmitted between chains. | ||
| - **`send`**: Used to denote the act of sending a message. Generally, the functions responsible for this are named `sendMessage`. | ||
| - **`receive`**: Used to denote the act of receiving a message. Depending on the context, receiving a message may have its own flow or involve multiple steps. Functions might be named `receiveMessage`, `relayMessage`, `validateMessage`, `executeMessage` or similar. |
There was a problem hiding this comment.
Similarly, receive is the act of making information spawn in the current execution environment in a way that's opaque and implementation-specific. Is there something we should add on polling (eg: calling a contract to relay a message) vs having the bridge call the receiving contract directly?
Also: s/Functions/Functions in existing implementations/ ?
There was a problem hiding this comment.
Good feedback; I think makes sense to add the pull/push-based models definitions that are related to your thought
This PR introduces a set of definitions and common conventions that are relevant for the current interop tracks. All the feedback and suggestions are welcomed.
Address #17