NethermindEth/juno v0.17.0 on GitHub

This release expands on the way Juno interacts with the pre-confirmed blocks, deprecates RPC v8, and removes database migration support for Juno versions older than v0.15.17. Additionally, we reworked tracing block logic, so partial results are re-utilized; traceTransaction calls no longer execute the whole transaction but only up to the required transaction. Finally, this update will run an 8-minute migration (measured with AWS slowest SSD) that will improve overall node performance. Read below for full details.

New Pre-Confirmed Polling

ℹ️Optional section describing new Juno feature. For Breaking Changes, skip to the bottom. New documentation for this new feature is already available.

Two new flags have been added (together with --preconfirmed-poll-interval) to control the way pre-confirmed is polled:

--preconfirmed-stale-after marks how long the pre-confirmed data is considered old.
--preoconfirmed-on-demand-wait sets how long an RPC request for pre-confirmed data waits to get the latest information.

To better explain their usage, is better to understand how the old behaviour (prior to this release) works and what the new behaviour brings.

Before Juno v0.17.0

Only the flag --preconfirmed-poll-interval existed to indicate the frequency for polling the Feeder Gateway every 500ms. Every RPC request tagged with pre_confirmed would just return whatever data Juno had in memory. The response latency time was always minimal, but the data could be too old in certain cases. The worst-case scenario is a request that arrives after a poll started but before it had finished (500ms + <poll_completion_time>).

This behaviour would also always poll for the data at designated frequency, regardless if there was high demand for it or not.

After Juno v0.17.0

With this new version, two new concepts are introduced:

How old is the pre-confirmed data in Juno
How much is the user willing to sacrifice latency to get the most recent data.

The new behaviour maintains --preconfirmed-poll-interval, and it will still poll the data on a timely basis. Additionally, the node can perform extra polls based on user interaction with the node.

Stale After

The user can now define how old a pre-confirmed data is considered too old via the --preconfirmed-stale-after flag. If set to 100ms, an RPC request with the pre_confirmed tag will generate an extra poll to the sequencer if the last polled pre-confirmed data is older than 100ms.

If the stale after time is greater than or equal to the interval polling time, no additional requests for pre-confirmed data will be sent to the sequencer, only on the set frequency.

Request Wait

Every time there is an ongoing poll for pre-confirmed data (via a normal interval, or generated via an RPC request), the user can define how much it is willing to wait for it. For example, with --preconfirmed-on-demand-wait set to 250ms, requests for this information will wait for the node to query this data from the sequencer up to 250ms. If the poll doesn't finish in that time, whatever is in the node's memory will be returned.

Note that these requests will only be triggered when the pre-confirmed data in the node has passed the expiration time set via --preconfirmed-stale-after flag. A request wait time of 0s could possibly create a request for fresh data but not wait for its response.

Risks and Presets

By adding a wait-on-request mechanism, there is an inherent danger that open public nodes to DoS attacks. For that reason, we've kept the defaults, simulating Juno's pre v0.17.0 behaviour:

--preconfirmed-poll-interval 500ms
--preconfirmed-stale-after 500ms
--preconfirmed-on-demand-wait 0ms

Whilst this is the safest configuration, it is not the best. After testing different combinations on Mainnet, these are the presets that the team suggests based on the node use case:

1s, 250ms, 300ms for App Developers, Stakers, and Explorers.
500ms, 250ms, 0ms for RPC Providers.
500ms, 250ms, 1s for Bots and MEV.

There is much more to this update; be sure to read this new section in the docs to optimize your Juno node.

As always, reach out to the team with any questions or doubts you may have about this new feature.

Breaking Changes

RPC v8 is no longer supported. #4208
Lowered defaults for RPC concurrency to 1024 concurrent RPC requests and a queue of 2048. Prior defaults were 256000/256000.
Old databases from Juno v0.15.17 and before are no longer supported. To update a node from v0.15.17 or before, update first to v0.16.8 and run the migrations. Then, update to Juno's latest released version.

Added

New Progressive Trace Cache that makes traceTransaction calls only trace to the specified transaction and store those results. The next traceTransactions will use the cached result if possible, or continue the execution where the last trace ended. Similarly, traceBlock can re-use the results of an earlier traceTransaction for that same block. #4079 #4080
New Pre-confirmed Polling logic. #4118 #4124 #4137 #4158
New bench profiles to guarantee Juno's optimal performance are part of CI. #4165 #4167
New distroless Docker images for safety. #4187
New state can be pruned as well. #4192

Changed

Removed bloom filter from header, optimizing every DB load that uses a header. Bloom filters now have their own bucket. #3854
Updated JSON marshallers to v2 for better performance. #4119 #4131 #4186
Updated State Trie node proving, improving performance when proving multiple nodes. #4084
Reduced storage proof allocation overhead. #4097

Fixed

Fix to_address on messages to l1 to be coded as FELT (as per the spec). #4122
Suppress error responses for notifications. #4146
Replace dead HTTP/2 connections after network failover. #4227
Return contract storage proofs in request order. #4233
Storage nodes unrelated to the proof are no longer shown. #4237
Some bugs in new state migration. #4106

New Contributors

@arunimshukla made their first contribution in #4146

Full Changelog: v0.16.8...v0.17.0