v0.16.5

We've revamped completely the way we fetch the latest data from the Feeder Gateway, reducing P50 latency from 1 second to a few mili-seconds. The following table compares the latency from an old Juno version versus this new release when tracking a new submitted transaction:

Dimension	Juno old	Juno new
Tx-inclusion latency — p50	1230ms	−87ms*
Tx-inclusion latency — p90	2850ms	349ms
Tx-inclusion latency — p99	4722ms	439ms
Tx-inclusion latency — max	5669ms	1211ms

*negative latency means the observer received the latest data faster from Juno than from the Feeder Gateway

Additionally, this update is packed with security and performance improvements, making the day to day execution of a Juno node safer and cheaper resource wise.

Added

• New way of fetching the pre-confirmed heads reducing latency from the 1 to 4 second range to below 100 mili-second on average #3723 #3730
• New RPC HTTP concurrency limit added (#3753), accessed through flags --rpc-max-concurrent-requests and --rpc-max-request-queue. Current default limits are big enough to avoid a breaking change but will be lowered down in Juno's next major version.
• Every Sequencer responses is now validated. This will protect the Juno node when the Sequencer sends malformed data. #3749

Changed

• Optimized latest-block state reads by avoiding full block header decoding. Getting a latest block nonce, class hash or storage take 50% less time. #3782
• Optimized key flattening, an instruction used for most DB accesses, to be twice as fast, reduce heap allocations by 1/3 and use half the memory. #3783
• Optimized trie access to be lazy. Instead of building the Contract and Class tries every time there is a need to read from the state, they are built on demand, improving the latency for RPC requests that don't need these tries. #3780 #3789
• Optimized Blake2s hash (used when re-computing CASM hash version) making it twice fast and using 1/3 less memory usage and heap allocations.
• Sequencer flags are now correctly marked as experimental. #3802
• Retry getting Chain ID on node startup instead of failing. #3771 #3776

Removed

• Candidate transactions are no longer part of the public API. #3732
• Removed pending endpoint querying. #3806

New Contributors

• @Ehsan-saradar made their first contribution in #3769

Full Changelog: v0.16.4...v0.16.5

v0.16.5-rc.1

We've revamped completely the way we fetch the latest data from the Feeder Gateway, reducing P50 latency from 1 second to a few mili-seconds. The following table compares the latency from an old Juno version versus this new release when tracking a new submitted transaction:

Dimension	Juno old	Juno new
Tx-inclusion latency — p50	1230ms	−87ms*
Tx-inclusion latency — p90	2850ms	349ms
Tx-inclusion latency — p99	4722ms	439ms
Tx-inclusion latency — max	5669ms	1211ms

*negative latency means the observer received the latest data faster from Juno than from the Feeder Gateway

Additionally, this update is packed with security and performance improvements, making the day to day execution of a Juno node safer and cheaper resource wise.

Added

• New way of fetching the pre-confirmed heads reducing latency from the 1 to 4 second range to below 100 mili-second on average #3723 #3730
• New RPC HTTP concurrency limit added (#3753), accessed through flags --rpc-max-concurrent-requests and --rpc-max-request-queue. Current default limits are big enough to avoid a breaking change but will be lowered down in Juno's next major version.
• Every Sequencer responses is now validated. This will protect the Juno node when the Sequencer sends malformed data. #3749

Changed

• Optimized latest-block state reads by avoiding full block header decoding. Getting a latest block nonce, class hash or storage take 50% less time. #3782
• Optimized key flattening, an instruction used for most DB accesses, to be twice as fast, reduce heap allocations by 1/3 and use half the memory. #3783
• Optimized trie access to be lazy. Instead of building the Contract and Class tries every time there is a need to read from the state, they are built on demand, improving the latency for RPC requests that don't need these tries. #3780 #3789
• Optimized Blake2s hash (used when re-computing CASM hash version) making it twice fast and using 1/3 less memory usage and heap allocations.
• Sequencer flags are now correctly marked as experimental. #3802
• Retry getting Chain ID on node startup instead of failing. #3771 #3776

Removed

• Candidate transactions are no longer part of the public API. #3732
• Removed pending endpoint querying. #3806

New Contributors

• @Ehsan-saradar made their first contribution in #3769

Full Changelog: v0.16.4...v0.16.5-rc.1

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

v0.16.3

⚠️ After the postponement of Starknet 0.14.3, this update is now required to support Starknet 0.14.3

This updates bring a security fix as well as a bug fix causing the node to crash on rare instances. Additionally, both performance and UX has been improved. Docs have been revamped to make the information they present much clearer.

Added

Bound compilation requests

Compilation tasks performed by Juno have now CPU and Memory limits. #3722

New Juno flags have been updated to allow user to control this new bounds:

• --max-concurrent-compilations default updated from fixed 8 to the total number of CPU cores divided by 2.
• --max-compilation-cpu-time added with a 10s default. Any compilation needing more CPU time than that will be automatically killed.
• --max-compilation-memory added with 4GBs default. Any compilation trying to reserve more memory than that will fail.

Friendlier JSON responses

Malformed JSON requests have a much more human-friendly response. They now indicate which part of the JSON is wrong and what the expected value is. This is achieved with no performance regression. #3702

Before

json: cannot unmarshal number into Go struct field Request.jsonrpc of type string

After

{"jsonrpc": 5, "method": "x", "id": 1}
            ^
field "jsonrpc" should be string, got number [line 1, column 13]

Changed

• Blockifier version updated to v0.19.0-rc.2 #3733

Fixed

• Juno no longer crashes when the sequencer sends a transaction with a nil StateDiff. #3740
• An open request for L1 subscription doesn't stop Juno from shutting down immediately. #3708

Full Changelog: v0.16.2...v0.16.3

v0.16.2

Hot Fix

• Bump blockifier and starknet_api to the next rc (now v0.19.0-rc.1) due to a bug in the previous one.

Full Changelog: v0.16.1...v0.16.2

v0.16.1

⚠️ This update is required to support Starknet 0.14.3.

Additionally, it brings considerable performance improvements as well as a more streamlined user experience when interacting with the node.

Added

• Feeder client improvements to heavily reduce network bandwidth reducing the cost for all of Starknet users.
• Reduced heap allocations when encoding/decoding field elements (i.e. felts) making RPC requests response parsing 50% cheaper. #3565

---

• Improved UX by grouping flags when --help is used. #3620
  • Additionally, the --help message is no longer displayed when there is an error on node startup. #3613 -

New --help preview:

Network & L1 Flags:
      --disable-l1-verification   Disables L1 verification since an Ethereum node is not provided.
      --eth-node string           WebSocket endpoint of the Ethereum node. To verify the correctness of the L2 chain, Juno must connect to an Ethereum node and parse events in the Starknet contract.
     ...

Sync & Polling Flags:
      --preconfirmed-poll-interval duration   Sets how frequently pre_confirmed block will be updated(0s will disable fetching of pre_confirmed block). (default 500ms)
      --prelatest-poll-interval duration      Sets polling interval for pre-latest block updates. (0s will disable polling). (default 1s)
      ...

Gateway Flags:
      --gw-api-key string    API key for gateway endpoints to avoid throttling
      --gw-timeouts string   Timeouts for requests made to the gateway. Can be specified in three ways:
...

Changed

• L1 head is updated on startup, allowing RPC consumers to see a consistent L1/L2 heads immediately, instead of after a short while. #3594
  • Additionally, when the L1 head is ahead of the L2 chain height (during node sync), an RPC request for the L1 head will return the current chain height to avoid inconsistent responses. #3644
• Removed a core Rust dependency by rewriting the Cairo Zero class hash calculation in pure Go, getting a performance improvement and memory cost reduction of 20%. #3648
• Bump RPC spec version to 0.10.2. #3573

Fixed

• starknet_estimateFee and starknet_simulateTransactions rejecting transactions with a non-zero tip when the account balance could cover the fee. The maximum L2 gas bound now accounts for the tip, matching the blockifier's fee calculation. #3562
• Startup RPC calls are now bounded by per-call timeouts so a slow or unresponsive L1 endpoint cannot hang node startup indefinitely. #3676

New Contributors

• @AvivYossef-starkware made their first contribution in #3562
• @RafaelGranza made their first contribution in #3602
• @ongyimeng made their first contribution in #3648

Full Changelog: v0.16.0...v0.16.1

v0.16.0

This update comes with a migration which was optional since v0.15.18. Small updates may be necessary to your command line configuration when updating from Juno v0.15.x.

⚠️ Warning: This update applies a migration that rewrites the entire database and compresses it to half the size. If you are using a decent SSD and minimum requirements, expected migration time is 40 minutes. Lower SSDs or Disks will experience a longer migration time. This migration was optional since [v0.15.18], if you've already applied it, no migration will trigger.

NOTE: Since the new DB layout is now the default, the db info and db revert commands will fail when run against a database that hasn't been migrated yet. Run the migration first, then these commands will work as expected.

Breaking changes

• Long running migration will kick in after the update. Check Warning note on top for details.
  • The flag--transaction-combined-layout used to trigger the migration has been removed since it is the new default.
• Default Database compression has changed from snappy to zstd.
• The default RPC endpoint of Juno has changed from v0_8 to v0_10. If you're application interacts with a Juno node and doesn't specify the version in the URL this might break it. Add /v0_8 at the end of your URL to fix it.
• RPC versions v6 and v7 are no longer supported.
• RPC field elements can only be specified as hexadecimals (0x1234abcd) and not decimals. A changed designed to follow the Starknet JSON RPC spec more strictly.
• The pending-poll-interval flag is now called prelatest-poll-interval reflecting its actual usage better.

Added

• --disable-received-txn-stream flag which disables RECEIVED alerts, users subscribed to these will no longer get a notification when the nodes receives a transaction.

Fixed

• starknet_estimateFee and starknet_simulateTransactions rejecting transactions with a non-zero tip when the account balance could cover the fee. The maximum L2 gas bound now accounts for the tip, matching the blockifier's fee calculation (max_amount * (max_price_per_unit + tip)).

Full Changelog: v0.15.22...v0.16.0

v0.15.22

This update objective is to reduce the amount of data Juno downloads from the sequencer. It will reduce bandwidth cost for everyone.

Changed

• Blockifier updated to version v0.18.0-rc.1.
• Reduced data downloaded from the Sequencer every time we poll the latest block. From 40 to 500kbs to just a few bytes.
• Reduced data downloaded from the Sequencer when querying a transaction status. Before, we would get the full transaction and discard the rest of the fields. Now, we correctly get only the data we need.

Fixed

• v0.15.21 would sent compress requests to mainnet causing the Gateway to not be able to parse it. This is now disabled until Mainnet hits Starknet version 0.14.2.
  Full Changelog: v0.15.21...v0.15.22

v0.15.21

Added

• Added gzip compression to requests to the feeder gateway when they exceed 1 kilobyte of size. #3505

Changed

• Updated Starknet execution libraries to their latest version. #3507

Fixed

• Fix an issue where Felt values returned in the RPC would be incorrectly serialize as [a, b, c, d] instead of the hexadecimal representation. #3504

Full Changelog: v0.15.20...v0.15.21

v0.15.20

Added

• Support for a new RPC v0.10.1 spec.
• There is now an option to output logs in json format. To do so, pass --log-json into your juno command.
• Kubernetes support for Juno officially out. Read more about it in our docs!

Fixed

• Fixed a bug in get_storage_proof in which we were returning an incorrect storage proof hash.

Changed

• Update to the latest Go version (1.26)
• Small performance optimizations here and there.

New Contributors

• @m-kus made their first contribution in #3445

Full Changelog: v0.15.19...v0.15.20