v0.24.1

FuelLabs/fuel-core

版本发布时间: 2024-03-30 21:12:53

FuelLabs/fuel-core最新发布版本:v0.36.0(2024-09-18 15:11:45)

Version v0.24.1

Added

#1786: Regenesis now includes off-chain tables.
#1716: Added support of WASM state transition along with upgradable execution that works with native(std) and WASM(non-std) executors. The fuel-core now requires a wasm32-unknown-unknown target to build.
#1770: Add the new L1 event type for forced transactions.
#1767: Added consensus parameters version and state transition version to the ApplicationHeader to describe what was used to produce this block.
#1760: Added tests to verify that the network operates with a custom chain id and base asset id.
#1752: Add ProducerGasPrice trait that the Producer depends on to get the gas price for the block.
#1747: The DA block height is now included in the genesis state.
#1740: Remove optional fields from genesis configs
#1737: Remove temporary tables for calculating roots during genesis.
#1731: Expose schema.sdl from fuel-core-client.

Changed

Breaking

#1771: Contract 'states' and 'balances' brought back into ContractConfig. Parquet now writes a file per table.
1779: Modify Relayer service to order Events from L1 by block index
#1783: The PR upgrade fuel-vm to 0.48.0 release. Because of some breaking changes, we also adapted our codebase to follow them:
- Implementation of Default for configs was moved under the test-helpers feature. The fuel-core binary uses testnet configuration instead of Default::default(for cases when ChainConfig was not provided by the user).
- All parameter types are enums now and require corresponding modifications across the codebase(we need to use getters and setters). The GraphQL API remains the same for simplicity, but each parameter now has one more field - version, that can be used to decide how to deserialize.
- The UtxoId type now is 34 bytes instead of 33. It affects hex representation and requires adding 00.
- The block_gas_limit was moved to ConsensusParameters from ChainConfig. It means the block producer doesn't specify the block gas limit anymore, and we don't need to propagate this information.
- The bytecodeLength field is removed from the Create transaction.
- Removed ConsensusParameters from executor config because ConsensusParameters::default is not available anymore. Instead, executors fetch ConsensusParameters from the database.
#1769: Include new field on header for the merkle root of imported events. Rename other message root field.
#1768: Moved ContractsInfo table to the off-chain database. Removed salt field from the ContractConfig.
#1761: Adjustments to the upcoming testnet configs:
- Decreased the max size of the contract/predicate/script to be 100KB.
- Decreased the max size of the transaction to be 110KB.
- Decreased the max number of storage slots to be 1760(110KB / 64).
- Removed fake coins from the genesis state.
- Renamed folders to be "testnet" and "dev-testnet".
- The name of the networks are "Upgradable Testnet" and "Upgradable Dev Testnet".
#1694: The change moves the database transaction logic from the fuel-core to the fuel-core-storage level. The corresponding issue described the reason behind it.

Technical details of implementation
- The change splits the KeyValueStore into KeyValueInspect and KeyValueMutate, as well the Blueprint into BlueprintInspect and BlueprintMutate. It allows requiring less restricted constraints for any read-related operations.
- One of the main ideas of the change is to allow for the actual storage only to implement KeyValueInspect and Modifiable without the KeyValueMutate. It simplifies work with the databases and provides a safe way of interacting with them (Modification into the database can only go through the Modifiable::commit_changes). This feature is used to track the height of each database during commits and even limit how commits are done, providing additional safety. This part of the change was done as a separate commit.
- The StorageTransaction is a StructuredStorage that uses InMemoryTransaction inside to accumulate modifications. Only InMemoryTransaction has a real implementation of the KeyValueMutate(Other types only implement it in tests).
- The implementation of the Modifiable for the Database contains a business logic that provides additional safety but limits the usage of the database. The Database now tracks its height and is responsible for its updates. In the commit_changes function, it analyzes the changes that were done and tries to find a new height(For example, in the case of the OnChain database, we are looking for a new Block in the FuelBlocks table).
- As was planned in the issue, now the executor has full control over how commits to the storage are done.
- All mutation methods now require &mut self - exclusive ownership over the object to be able to write into it. It almost negates the chance of concurrent modification of the storage, but it is still possible since the Database implements the Clone trait. To be sure that we don't corrupt the state of the database, the commit_changes function implements additional safety checks to be sure that we commit updates per each height only once time.
- Side changes:
  - The drop function was moved from Database to RocksDB as a preparation for the state rewind since the read view should also keep the drop function until it is destroyed.
  - The StatisticTable table lives in the off-chain worker.
  - Removed duplication of the Database from the dap::ConcreteStorage since it is already available from the VM.
  - The executor return only produced Changes instead of the storage transaction, which simplifies the interaction between modules and port definition.
  - The logic related to the iteration over the storage is moved to the fuel-core-storage crate and is now reusable. It provides an interator method that duplicates the logic from MemoryStore on iterating over the BTreeMap and methods like iter_all, iter_all_by_prefix, etc. It was done in a separate revivable commit.
  - The MemoryTransactionView is fully replaced by the StorageTransactionInner.
  - Removed flush method from the Database since it is not needed after https://github.com/FuelLabs/fuel-core/pull/1664.
#1693: The change separates the initial chain state from the chain config and stores them in separate files when generating a snapshot. The state snapshot can be generated in a new format where parquet is used for compression and indexing while postcard is used for encoding. This enables importing in a stream like fashion which reduces memory requirements. Json encoding is still supported to enable easy manual setup. However, parquet is prefered for large state files.

Snapshot command

The CLI was expanded to allow customizing the used encoding. Snapshots are now generated along with a metadata file describing the encoding used. The metadata file contains encoding details as well as the location of additional files inside the snapshot directory containing the actual data. The chain config is always generated in the JSON format.

The snapshot command now has the '--output-directory' for specifying where to save the snapshot.

Run command

The run command now includes the 'db_prune' flag which when provided will prune the existing db and start genesis from the provided snapshot metadata file or the local testnet configuration.

The snapshot metadata file contains paths to the chain config file and files containing chain state items (coins, messages, contracts, contract states, and balances), which are loaded via streaming.

Each item group in the genesis process is handled by a separate worker, allowing for parallel loading. Workers stream file contents in batches.

A database transaction is committed every time an item group is succesfully loaded. Resumability is achieved by recording the last loaded group index within the same db tx. If loading is aborted, the remaining workers are shutdown. Upon restart, workers resume from the last processed group.

Contract States and Balances

Using uniform-sized batches may result in batches containing items from multiple contracts. Optimal performance can presumably be achieved by selecting a batch size that typically encompasses an entire contract's state or balance, allowing for immediate initialization of relevant Merkle trees.