(Coming to integration on February 12; testnet dates TBD in the upcoming days.)
Whatâs better than your favorite pizza? A cheeseburger. Your favorite pizza, but cheaper!
Starknet v0.13.1 has rich toppings! First, it adds support for Ethereumâs long-awaited EIP4844 upgrade, expected to massively slash Starknetâs data availability (henceforth DA) costs. Second, it continues the reduction of transaction fees initiated in v0.13.0: not only will DA fees be reduced in accordance with Ethereumâs blob market, but compute fees will also be reduced due to shiny new optimizations! Third, it contains many behind-the-scenes improvements to the code. Finally, it will make transaction receipts more informative, including full resource consumption and fee accounting.
Letâs get our hands in the dough!
Update: v0.13.1 also includes fee reductions. For more information, see here!
EIP4844 Support
EIP4844 is one of the most highly anticipated Ethereum upgrades in a long time. Intended to reduce the data availability costs of rollups, it introduces âblobsâ as an alternative to calldata for sending data to Ethereum. Moreover, the upgrade introduces âblob gasâ â a new resource, separate from gas, that is consumed only by âblob transactionsâ. Consequently, the blob market is expected to mostly consist of rollups, without competition by standard Ethereum users. Thus the demand of rollups (as opposed to all Ethereum users) will determine blob prices and by extension rollup DA costs.
Starknet v0.13.1 will include support for this Ethereum upgrade. In a nutshell, state-diffs which are currently sent as calldata will be sent as blobs. To give some more details:
- The SNOS will output an evaluation of an interpolation of the state-diffs as opposed to its current output of the state-diffs themselves. It will also forward a KZG commitment to the state-diffs that was computed in the backend.
- A separate service will send state-diff blobs.
- Integrity of the state-diff blobs will be verified as part of the state update process by comparing a random sample from the blobâs KZG commitment with a random sample from the commitment output by the OS.
Note that v0.13.1 does not add blob gas as an additional protocol-level resource: for now we remain only with âgasâ. We will review whether or not it should be added (e.g included in the fields submitted in v3 transactions) in the future.
For a lot more detailed, see this great post by @FeedTheFed!
Transaction Fee Reductions
Roughly speaking, Starknet transactions consume two resources: data (for Starknetâs DA), and compute (Cairo steps and various builtins). Transaction fees for both resources will be reduced in v0.13.1. (We purposely disregard L1/L2 message fees for simplicity; details about the fee mechanism can be found in the documentation.)
An obvious source for DA fee reductions is EIP4844 support: reduced DA costs justify a reduction in DA fees charged from users. And indeed, each transactionâs L1DA fee will be computed from its expected blob gas consumption when posted to L1. Going by the prevalent sentiment, this should massively slash DA related fees, which comprise over 80% of the average transactionâs fee!
A less obvious reduction in compute fees comes from some more optimizations of L1 gas consumption both by Starknet and by SHARP that are just around the corner, namely larger blocks, larger SHARP trains and smaller proofs submitted to L1. Resisting the temptation to expand more here, Iâll defer the fascinating topic of fee and cost reduction roadmaps in Starknet to its own post, coming soon!
Stability
Over the past few months, Starknet downtimes prompted the community to call out for stability improvements. We listened and dedicated a lot of engineering resources to improve, clean, and iron out many flows and parts of the code. While this blessed work will be invisible to users it will greatly enhance testing, alerts, metrics, logs, bugs, configs, and more. After all, itâs the quiet ones you have to watch out forâŚ
Quality of Life
Starting from v0.13.1, transaction receipts will display full execution resources, taking syscalls into account. They will also separately report DA resource consumption, making it easy to see how transaction fees are divided between DA and compute.
Summary
The ecosystem guides us on! Fee reductions continue in v0.13.1 with support for the epic EIP4844 to reduce DA fees and SHARP-related optimizations to reduce compute fees. Stability is greatly improved in many senses. Transaction receipts are rounded out.
We want you to share feedback, ask questions, make suggestions, and share criticism!