Crates.io | fuel-relayer |
lib.rs | fuel-relayer |
version | 0.15.3 |
source | src |
created_at | 2022-06-14 12:50:42.218807 |
updated_at | 2023-01-17 22:30:49.947467 |
description | Fuel Relayer |
homepage | https://fuel.network/ |
repository | https://github.com/FuelLabs/fuel-core |
max_upload_size | |
id | 605804 |
size | 82,922 |
The Relayer connects Fuel to the DA (data availability) layer contract. The primary functionality is to track the finality of blocks in the DA layer and download all log messages for blocks that are considered final. Messages are then made available to fuel via the database.
Ethereum blocks are considered final after two epochs. Each epoch contains 32 slots. A slot takes 12s so epoch is around 6.4min and two epochs will take 12.8min. After 13min we are sure that our deposits will not be reverted by some big reorganization. So we are okay to say that everything older then ~100blocks is finalized.
Second finality that we have is related to fuel block attestation time limit, how long are we going to wait until challenge comes. It should be at least longer than ethereum finality. Not relevant for first version.
Problem: Validator deposit to ethereum gets reverted by block reorg. (Eth clients usually have priority for reverted txs but this does not mean it cant happen). It can potentially rearrange order of transactions
Solution: Introduce sliding window, only deposits that are at least eth finality long can be finalized and included in validators leader selection.
Problem: How to choose when bridge message event gets enabled for use in fuel, at what exact fuel block does this happen? (Note that we have sliding window)
Solution: introduce da_height
variable inside fuel block header that will tell at what block we are including token deposits.
The RelayerHandle
type is used to start / stop a background task that runs the actual Relayer
.
The relayer background task is a simple loop that polls the fuel database and DA node to build a picture of the current state.
If the state determines that the relayer is out of sync with the DA layer then log messages from the DA contract are downloaded and written to the database.
The range of blocks is (last_downloaded_height + 1)..=current_finalized_height
.
Logs are paginated into sets of blocks to avoid overloading a single rpc call.
The flake.nix
in this repo has a tool to fetch, compile and generate the abi for the fuel contracts.
While it is not mandatory to use nix to do this the advantage is the exact versions of the contracts that were used to generate the abi files is pinned in the flake.lock
file.
To generate the api files run the following from the fuel-relayer
directory.
nix run .#generate-abi-json abi
To update the version of the contracts that is used run:
nix flake update
nix run .#generate-abi-json abi
You can see the versions that are pinned by running:
nix flake info