Add info about event_inbox_root on the header
#571
Conversation
MitchTurner
changed the title
inbox_event_root on the headerevent_inbox_root on the header
src/protocol/block-header.md
Outdated
| | `message_receipt_count` | `uint64` | Number of [output message](../abi/receipts.md#messageout-receipt)s in this block. | | ||
| | `txRoot` | `byte[32]` | [Merkle root](./cryptographic-primitives.md#binary-merkle-tree) of [transaction](../tx-format/transaction.md)s in this block. | | ||
| | `message_outbox_root` | `byte[32]` | [Merkle root](./cryptographic-primitives.md#binary-merkle-tree) of [output message](../abi/receipts.md#messageout-receipt)s [`messageId`](../identifiers/utxo-id.md#message-id) in this block. | | ||
| | `event_inbox_root` | `byte[32]` | [Merkle root](./cryptographic-primitives.md#binary-merkle-tree) of all events imported from L1 in this block. The order of the events added to the Merkle tree is the L1 block order, and the index of each event within each block | |
There was a problem hiding this comment.
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).
src/protocol/relayer.md
Outdated
|
|
||
| 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.
| This is used to move assets between the two blockchains. | |
| This is used to move any data between L1 <> L2. |
src/protocol/relayer.md
Outdated
| |--------------------------|-----------|---------------------------------------------------------------------------------------| | ||
| | `nonce` | `bytes[32]` | Unique identifier of the transaction on L1 | | ||
| | `max_gas` | `uint64` | The maximum amount of gas executing this transaction will cost on the Fuel Blockchain | | ||
| | `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.
Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
src/protocol/relayer.md
Outdated
| |--------------------------|-----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | `nonce` | `bytes[32]` | Unique identifier of the transaction assigned by the L1 contract | | ||
| | `max_gas` | `uint64` | The maximum amount of gas allowed to use on Fuel Blockchain | | ||
| | `serialized_transaction` | `byte[]` | The serialized transaction bytes following canonical serialization. Only supports `Create` and `Script` [transaction](../tx-format/transaction.md), not `Mint` | |
There was a problem hiding this comment.
Now we have two more types of transactions=)
src/protocol/relayer.md
Outdated
|
|
||
| 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 | ||
| their funds in the (unlikely) event that the Fuel blockchain block production is compromised or malicious. |
There was a problem hiding this comment.
Could mention censorship-resistancy here, as that's the primary technical form of compromise this protects against
|
|
||
| ## 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
| 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.
Something was missed in this [PR](#571) and this fixes it. ### Before requesting review - [x] I have reviewed the code myself ### After merging, notify other teams - [ ] [Rust SDK](https://github.com/FuelLabs/fuels-rs/) - [ ] [Sway compiler](https://github.com/FuelLabs/sway/) - [ ] [Platform documentation](https://github.com/FuelLabs/devrel-requests/issues/new?assignees=&labels=new+request&projects=&template=NEW-REQUEST.yml&title=%5BRequest%5D%3A+) (for out-of-organization contributors, the person merging the PR will do this) - [ ] Someone else?
#565