Configuring Madara block times

[apoorvsadana]

Block production on Starknet

Currently, Starknet doesn't have fixed block times. Instead, the sequencer waits for the blocks to be filled to some extent before it seals the blocks and moves on to the next block. As a result, the block times vary depending upon the type of traffic the network sees. You can see the block creation time stats at the bottom here - https://voyager.online/analytics?page=block. The current limitations of the services

• SHARP can only run one SNOS run as a job and create a proof.
• SNOS currently works on a per-block basis.
• The cost of SHARP is on a per-job basis

Given these limitations, the power to be able to modify the block time allows Starknet to adjust its proving costs so that it is always creating blocks that have some txs in it instead of creating empty blocks and spending money. However, a point to mention here is that this only works in a centralized setup and once Starknet decentralizes it will need more consistent block times. For app chains, depending on the use case, it is possible that they want to remain centralized. And at least for the start, till the stack has been matured, Madara app chains will start as centralized chains.

The purpose of this discussion is to highlight some possible ideas we can use to replicate a similar behavior so that app chains only create limited Starknet blocks and don't spend too much money on proving empty blocks.

PS: this discussion is only valid for app chains that plan to use SHARP for proving. If you're running your own Stone then the cost of proving depends on your infra cost.

Controlling Madara block time

1. Modify SNOS to span multiple blocks

In its current setup, SNOS runs for each Starknet block. And each SNOS trace counts as a job in SHARP. If we can modify SNOS so that it can take multiple blocks as their input and create one execution trace which proves the execution of all these blocks, then we can technically aggregate multiple blocks before sending them to SHARP. The assumption here is that the extra steps added to prove empty blocks will not be a lot because the blocks are anyways empty.

Pro:

• no changes are needed in Madara
• already in development by Starkware
• can be combined with the solutions listed bellow

Con:

• no ETA on when we can expect this feature to arrive
• chain size continues to grow because of Substrate blocks.

2. Stop Starknet blocks while Substrate blocks continue

Currently, new Starknet blocks are created in Madara during on_finalize. We can change the logic over here so that Starknet blocks are only created once we've enough transactions or resource consumption. Substrate blocks will still continue to be created, only the Starknet blocks will be controlled by our logic. Since our mappings between Substrate and Starknet blocks are done using block hashes and we don't rely on block numbers, this shouldn't break anything else.

Pro:

• no changes are needed in Substrate
• we can implement this in a few days ideally

Con:

• One substrate block != one Starknet block
• chain size continues to grow because of Substrate blocks
• Unpredictable block time.

3. Only skip empty blocks

A variant of the previous one is to only skip Starknet block production when the is no transaction at all in a substrate block. So users can still expect their TXs to be executed on a short block time, but no resource is wasted when there is no Starknet tx at all.
On the not-so-successful appchain, the great majority of blocks fall under this category.

Pro:

• no changes are needed in Substrate
• we can implement this in a single day

Con:

• One substrate block != one Starknet block
• chain size continues to grow because of Substrate blocks.

4. Use manual sealing

If we run Madara in manual sealing mode, Substrate exposes an endpoint for us to create blocks whenever we like. So we could theoretically write a new service (or maybe this could be somewhere inside the Madara code itself) that keeps listening to new transactions received on Madara and seals the block when we have enough TXs. However, in the current way manual sealing works, storage changes are only applied to the node once we've sealed the block. Before that, pending changes cannot be read by the read RPC calls. For example, if I transfer 1 ETH from 0xA to 0xB and I don't seal the Substrate block, the balance of 0xB when read from an RPC call will be 0.

Pro:

• Every substrate block represents a Starknet block
• chain size does not grow when there are no TXs.

Con:

• need to make changes to Substrate in order to expose the block currently being build to RPCs
• not possible in a decentralized network
• unpredictable block time