Add info about event_inbox_root on the header
#571
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,61 @@ | ||||||
| # Layer 1 Relayer/Bridge Protocol | ||||||
|
|
||||||
| The Fuel relayer/bridge protocol is a set of rules that govern the interaction between the Fuel blockchain and the | ||||||
| Layer 1 (L1) blockchain (e.g. Ethereum). | ||||||
|
|
||||||
| The Fuel blockchain can emit messages that will be processed by the smart contract on the L1 blockchain. The smart | ||||||
| contract on the L1 can also emit events that will be processed by the Fuel blockchain. | ||||||
| This is used to move assets between the two blockchains. | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| ## Fuel Message Outbox | ||||||
|
|
||||||
| The message outbox is the set of messages sent to the L1 blockchain from the Fuel blockchain. | ||||||
|
There was a problem hiding this comment. I'd still like to see more technical description on how the message sending works. I.e. how can I verify that a message was actually sent on L1? There was a problem hiding this comment. I have intentionally not included a lot of detail on the "outbox" section, since this issue is specifically for the "inbox" stuff. There just wasn't any info on any of this stuff in the specs, so I wanted to set aside some space for the "outbox" stuff as well. I'll create an issue for this: #575 |
||||||
|
|
||||||
| ## Fuel Event Inbox | ||||||
|
|
||||||
| The event inbox is the set of events received from the L1 blockchain by the Fuel blockchain. | ||||||
|
|
||||||
| The block producer will receive the list of events from the L1 by some relayer, and then include both the count and the | ||||||
| merkle root of the events in the block header. | ||||||
|
There was a problem hiding this comment. It doesn't look like we actually put the event count into the header There was a problem hiding this comment. This count is implicitly derived from the da height and reconciling that with L1 data There was a problem hiding this comment. Oh. Whoops. We only include it for the outbox. |
||||||
|
|
||||||
| There are two types of events that can be received from the L1: | ||||||
|
|
||||||
| 1. Messages | ||||||
| 2. Transactions | ||||||
|
|
||||||
| ### Messages | ||||||
|
|
||||||
| An arbitrary message sent from the L1 to the Fuel blockchain. This can be used to move assets from the L1 | ||||||
| to the Fuel blockchain or send other arbitrary information to the Fuel blockchain. | ||||||
|
|
||||||
| | name | type | description | | ||||||
| |-------------|---------|---------------------------------------------------------------------| | ||||||
| | `sender` | `bytes[32]` | The identity of the sender of the message on the L1 | | ||||||
| | `recipient` | `bytes[32]` | The recipient of the message on the Fuel Blockchain | | ||||||
| | `nonce` | `bytes[32]` | Unique identifier of message on L1 | | ||||||
MitchTurner marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| | `amount` | `uint64` | The amount of the base asset transfer | | ||||||
| | `data` | `byte[]` | Arbitrary message data | | ||||||
| | `da_height` | `uint64` | The height of the L1 blockchain when this message event was emitted | | ||||||
xgreenx marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| ### Transactions | ||||||
|
|
||||||
| These are transactions that are submitted on the L1 that must be executed on the Fuel blockchain. | ||||||
| This "Forced Transaction Inclusion" is a security feature that allows participants of the Fuel Blockchain to access | ||||||
| there funds in the (unlikely) event that the Fuel blockchain block production is compromised or malicious. | ||||||
MitchTurner marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| | name | type | description | | ||||||
| |--------------------------|-----------|---------------------------------------------------------------------------------------| | ||||||
| | `nonce` | `bytes[32]` | Unique identifier of the transaction on L1 | | ||||||
MitchTurner marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| | `max_gas` | `uint64` | The maximum amount of gas executing this transaction will cost on the Fuel Blockchain | | ||||||
MitchTurner marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| | `serialized_transaction` | `byte[]` | The serialized transaction bytes | | ||||||
|
There was a problem hiding this comment. Maybe put a link to canonical serialisation and to supported transaction types There was a problem hiding this comment. I don't see any definitions in our specs about canonical serialization, just references to it. So I'll just reference it for now. |
||||||
| | `da_height` | `uint64` | The height of the L1 blockchain when this transaction event was emitted | | ||||||
xgreenx marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| ### Ordering | ||||||
|
|
||||||
| It is important that the L1 events are ordered correctly when they are relayed to the Fuel blockchain. The events will | ||||||
| be ordered by the L1 block height and then by the index of the event within the block. | ||||||
|
|
||||||
| The order is important because a merkle root will be generated each time events from L1 are included in a Fuel block. | ||||||
| This merkle root can later be used to prove that an arbitrary event was included on that block without having to store | ||||||
| every event on the block header explicitly. Just the merkle root will be on the [block header](./block-header.md). | ||||||
| The order of the events affects the value of the merkle root. | ||||||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to put a link to relayer section to describe what events are. And it would be nice to describe over what Merkle tree is created(like hash of the event or hash of all fields).