The Starknet ‘Bolt’ upgrade: 2-second txs are here

TL;DR

• v0.13.2 introduces two features to prepare Starknet for the future.
• “Parallel execution” vastly expands Starknet’s current capacity by enabling independent transactions to be executed simultaneously.
• “Block packing” cuts fixed L1 costs by up to 66% and reduces transaction confirmation times to just 2 seconds and block times to between 20-60 seconds.

Intro

Starknet makes it possible to build any dApp on Ethereum, no matter the computing power required. Dubbed by the community “Bolt,” today’s v0.13.2 upgrade expands this capacity for future use cases by accelerating transaction confirmation times and building on the cost-saving and performance optimizations planned for in Starknet’s updated 2024 roadmap. The two main features of the upgrade? Meet “parallel execution” and “block packing.”

Parallel execution does exactly what the name suggests: It enables transactions within the Starknet sequencer to be executed simultaneously, expanding network capacity way beyond current needs to support future use cases. In short, that means confirmation times will be reduced a lot thanks to the improvement in speed as it takes much less time to execute transitions in parallel than in sequence. Fun fact: Starknet is the first (!!!) L2 on mainnet to simultaneously execute parallel transactions.

Block packing brings faster L2 transaction confirmation times of just 2 seconds for around 80% of transactions and up to a 66% reduction in fixed L1 costs per block. L2 block times will be reduced to around 20-60 seconds. It achieves this by decoupling L2 block frequency from L1 costs.

Sounds pretty cool, right? Let’s dive into the details.

Preparing Starknet for the future

So we said parallel execution expands network capacity even beyond the network’s current needs. But how?

Until now, Starknet’s sequencer executed transactions sequentially before batching them into a block. This execution method functioned efficiently, without weighing too heavily on Starknet’s network capacity.

But Starknet is building the network of the future. A major part of that is expanding network capacity as much as possible to accommodate future activity from applications that will inevitably require higher computational power.

Parallel execution drastically expands network capacity by enabling the sequencer to execute multiple transactions that are independent of one another simultaneously. Here’s an example of transactions that could be executed in parallel:

• Transaction A: Bob sends ETH to Alice.
• Transaction B: Sebastian sends STRK to Bill.

These transactions are independent of each other and do not need to be queued for sequential execution. Instead, they can be executed in parallel. This greatly speeds up the time it takes for the sequencer to execute transactions.

But what if Bob first needs to convert his STRK to ETH before he can send it to Alice?

• Transaction A: Bob converts STRK to ETH.
• Transaction B: Bob sends ETH to Alice.

In this scenario, transaction B is dependent on transaction A, because Bob needs to receive the ETH before he can send it to Alice. If transaction B is executed before transaction A, then Bob may not have enough ETH in his wallet to pass on to Alice, in which case the transaction would fail.

The added network capacity unlocked by parallel execution ensures transactions on Starknet will remain fast and cost-effective even as new use cases are born and network demand rises.

Unlocking higher block frequency

Whereas parallel execution improves efficiency in the transaction-execution stage, block packing improves efficiency in the step that comes after, when transactions are batched together into blocks.

This new feature actually applies the “batching” logic to the blocks themselves, combining multiple blocks into a sort of mega block, therefore spreading the L1 cost across a much greater number of transactions. The result is a decoupling of L2 block frequency from L1 costs.

In plain English, that translates into faster block times and lower cost associated with each transaction.

To understand how this works, it’s important to note that L1 operating costs are fixed and rise linearly with the frequency of blocks L1 receives from L2, regardless of how many transactions they contain. Each block produced and sent to L2 requires a certain amount of gas (currently at least 215k gas fixed per block). So the more frequently an L2 network sends blocks to L1, the higher the cost will be.

If you’re looking to settle blocks on L1 at shorter intervals and don’t want to wait until the block is full (which on Starknet is every 6 minutes, whether the block is full or not), it means you have a cost for speed tradeoff.

So how to get around that tradeoff?

Block packing does exactly that by batching several L2 blocks into one special applicative recursive proof. With block-packing, each Starknet state update handles multiple Starknet blocks, allowing for batching of L1 fixed costs. Now, low block times are unlocked without incurring increased costs.

The result is faster confirmation times and lower L1 costs. With block packing, transaction confirmation will take only 20-60 seconds (the goal is to reduce that to only 2 seconds). On the cost front, the majority of the fixed L1 cost is now spread over all the batched blocks, slashing these costs by between 50-66%.

The added benefit of block packing is that costs will actually drop further-rather than rise-as more users join Starknet, because it means more L2 blocks can be packed into each applicative recursive proof. As more users join the network, each user’s individual L1 footprint is reduced, ensuring Starknet’s impressive scalability is, well, scalable.

Conclusion

The v0.13.2 upgrade pushes the boundaries of scalability today and prepares Starknet for mass adoption tomorrow. Parallel execution enables the simultaneous execution of independent transactions, boosting network capacity even beyond current needs and future proofing the network. Block packing unlocks frequent blocks while optimizing gas consumption.

For more technical details, see the parallel execution and block packing community forum posts, or stay tuned for more Starknet updates on Twitter/X.