v0.16.4

This update brings pruning, a very important feature, to validators to lower their costs. Additionally, it brings a small security improvement by limiting compilation requests.

Added

Database and State Pruning #3597

Juno now has the --prune-mode flag, which prunes the whole database as well as the state. It will reduce the node's total database size to under 100 GBs.

When --prune-mode is enabled for the first time, it will trigger a migration that will prune the whole database (note that this action is non-reversible). It will take a few seconds on Sepolia and a couple of minutes on Mainnet. After the migration is done, it will take some time for the OS to show the freed space, usually a couple of seconds to a few minutes. Pruned Mainnet snapshots already available!

Usage

You can control how many pruned blocks are kept by Juno by assigning a block number when setting the flag:

• --prune-mode=x, x is 128 by default but can be any non-negative integer.

We've also written the pruning code to be resistant to the worst network conditions. To protect against cases where the network l1 head gets updated very fast, it is possible to control how many blocks in the last few hours (or days) to keep.

• --prune-min-age=1h will always keep at least all the blocks that have been produced in the last hour, regardless where the l1 head is.

Functionality

Juno's prune mode behaves differently based on the current network state:

• The L2 Head: the latest Starknet block that the node has received from the Sequencer.
• The L1 Head: the latest Starknet block that has been included in Ethereum.

If the l1 head is above the current l2 head, the node will keep only the latest 128 blocks. For example:

• If l1 head is at block 2000
• and l2 head` is at block 1000,
• The node only keeps blocks in the 872 to 1000 range.
• As new blocks keep coming, the older ones will be pruned: when block 1001 arrives, block 872 will be pruned.

When the l1 head is behind the l2 head, the node will keep all the blocks up to the l1 head and 128 more blocks. For example:

• If l1 head is at block 2000
• and l2 head is at block 3000,
• the node will keep blocks in the 1872 to 3000 range.
• When l1 head updates again, the node will prune all the blocks below the new head. Using this same example:
  • If l1 head updates to block 2500
  • The node will keep blocks in the 2372 to 3000 range.

If there is a network issue that doesn't allow the node to get a new l1 head for more than 24h passes, a warning will be thrown alerting the user.

Compiler tasks queueing #3744

A new limit was introduced on how many compiler tasks could be queued. The limit set, which is, by default, twice the amount of concurrent compilation requests possible. Can be set via:

• --max-compilation-queue=x where x determines de size of the queue.

Full Changelog: v0.16.3...v0.16.4