Releases: NethermindEth/juno
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-jsoninto your juno command. - Kubernetes support for Juno officially out. Read more about it in our docs!
Fixed
- Fixed a bug in
get_storage_proofin 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
Full Changelog: v0.15.19...v0.15.20
v0.15.20-rc.0
Added
- Added support for a new RPC v0.10.1 spec.
- Added an option to output logs in json format. To do so, pass
--log-jsoninto your juno command.
Changed
- various improvements for the internal state and DB structure.
- Fixed a bug in
get_storage_proofin which we were returning an incorrect storage proof hash. - Various small quality of life improvements and refactors.
New Contributors
Full Changelog: v0.15.19-rc.0...v0.15.20-rc.0
v0.15.19
Hot fix recommended for everyone!
Fixed
- Fix a possible state corruption that could happen when reverting migrated Classes to old CASM hashes.
Full Changelog: v0.15.18...v0.15.19
v0.15.19-rc.0
Juno is now compiled with Go 1.26 which brings new benefits by default. Check the release notes for info!
Added
Support for RPC v0.10.0-rc.2
- New flags and capabilities for proof submissions when invoking a transactions.
- Event filtering using multiple contract addresses
- Full change log here
Consensus
- Juno is now be able to participate and communicate with itself when executing consensus. Still experimental!!
- Not compatible with latest specs released from SW which now require a different message protocol ("propeller" instead of gossipsub)
New tuning option
--db-memtable-countdetermines the number of memory tables (memtable) the database can queue before stalling writes.
Changed
- Change all Juno logging instances for a more performant one reducing memory allocations.
- Make contract compilation start on a separate process instead of a thread of Juno
- Add extra validation to incoming RPC request fields.
Full Changelog: v0.15.18...v0.15.19-rc.0
v0.15.18
This update brings a brand new DB architecture that cuts database size by several hundred gigabytes as well as exposing new configuration endpoints for users to tune their node to maximize performance based on their hardware.
New Performance Tuning Settings
Several new endpoints have been created as well as a new detailed documentation page on how to configure them. The default for these are targeted for 4 CPU cores and 8 GBs of RAM – better machines will benefit from updating them.
Notable mention is the --db-compression flag which will set the database compression level. Current compression is called snappy which has been left as default since it is safer to use with the current database layout.
If using the new database layout, zstd compression level is recommended because it enables much more deep compression, reducing DB size significantly at a fraction of the CPU cost. The zstd compression level will become the new default for Juno 0.16.0
Usage example:
--db-compression snappyRemember to take a look at the Performance Tuning section to get more details.
New Database Layout
A new database layout is now available which changes the way we store transaction headers and receipts. Previously, transaction headers and receipts were stored using a key composed of the block number and the transaction’s index within the block. Given the millions of transactions on Starknet Mainnet, this would allot for a total of 500GB of storage.
The new layout, combined with zstd compression, reduces this value from 500 GBs to only 200 GBs.
To apply this new database layout, please run the node with the following flags
<your command to run juno>
...
--transaction-combined-layout
--db-compression zstd
⚠️ Note 1: once this new flag has been applied it won't be possible to revert back to the original database. Syncing from the beginning or from a snapshot is the only possible way for reverting this layout.
⚠️ Note 2: this flag will trigger a migration which we will take around 3 hours on a machine running the minimum specs. Validators beware.
ℹ️ Info: the
--db-compression zstdflag is optional but it is highly recommended since it will get the most benefit for database size reduction. Additionally, from now onward your database growth will be heavily reduced.
The reason this database update is optional through a flag is to make it available sooner and avoid the breaking change. Once Juno 0.16.0 releases this migration will become mandatory and nodes which haven't migrated yet will be required to.
Note that when enabling a new compression, the whole database won't be compressed at once but gradually, as new information is written while existing data will remain stored with the previous compression. However, when updating to this new database layout with zstd compression, storage savings will be immediately noticeable given that 80% of the database is being rewritten. As a result, while a full re-sync is required to achieve maximum reduction, most of the benefits will be seen after the migration.
A fully compressed snapshot will be made available by us in the near future.
Full Changelog: v0.15.17...v0.15.18
v0.15.17
Note 1
⚠️ : This release will update the underlying Juno DB version. This is necessary to get the utmost performance of the DB as well as unlocking several upgrades that will become available in the next release. The estimated time varies on your Juno state: for a node in synced it should be seconds.
Note 2
⚠️ : This release comes with one small migration and a medium sized one. If you're a validator, please make sure to update right after your attestation window. Estimated migration time in total is around 1 hour and 30 minutes on a minimum resource machine (4 cores and 8 GBs of RAM with a slow SSD (~3180 r/w IOPS))
This release focuses on polishing the latest RPC v0.10.release with small fixes as well as improving the metric reporting of Juno. Additionally, many internal changes were also done to reduce the memory allocation and improve the performance of Juno.
Changed
- Update to the latest blockifier (
v0.16.0-rc.3) which comes with important bug fixes. #3371
Fixed
- L1 Handler message hash were being incorrectly stored in Juno. This was causing
starknet_getMessageStatusto fail in some instances for L1 handler transactions. #3367 - The wrong compiled CASM hash was being returned. This is now fixed. #3379
starknet_getMessageStatusreturning an empty error. #3365starknet_getStateUpdatenow omit optional fields. #3332INVALID_CONTINUATION_TOKENerror message. #3368- Consensus block header and signature comments fixed to align with the specs. #3331
- General fixes applied to Juno Database and State when it was being under heavy concurrent use. #3334 #3341 #3344
- Improve overall metric tracking of Juno DB. #3361 #3362 #3364 #3366
New Contributors
- @MozirDmitriy made their first contribution in #3331
Full Changelog: v0.15.16...v0.15.17
v0.15.16
Fixed
- Fixed a possible DB issue, related to migrations in the Paradex network and data reads.
Full Changelog: v0.15.15...v0.15.16
v0.15.15
Fixed
- Fixed an incorrect error code for
estimateMessageFeewhen receiver of the message on L2 is not yet deployed. - Removed redundant
block_numberfield from receipt objects in response fromstarknet_getBlockWithReceipts - Changed default for l1 gas and l1 data gas prices from 0 to 1.
Full Changelog: v0.15.14...v0.15.15