We’re building a card payment protocol on CELO and having a faster finality would make a world of difference. For card payments, we need to respond to the card scheme within ~3-5s. In order to confidently process transactions we would ideally need a block time of around 1 second (so that transmit → finalized would be around 2s).
I was wondering if there are any intentions to shorten the block time - and if so what is the protocol team targeting, and when would such a change be expected?
That’s interesting! We were thinking about shortening the block time in the context of increasing throughput, as an alternative to increasing block gas limit. That was discussed as one of the options for the next hardfork but it’s not confirmed yet. Would love to learn more about your specific needs and the full transaction flow. That would definitely help us make educated decision.
Hey @valentin , revisiting this over a year later, as we are planning to start work in the next few months. I’ve noticed the block time has been 1 second for the past 5 months - which is great!
One other parameter we care about is reorgs and finality. With 1 block confirmation, is there any data about the probability of a reorg happening? What is the L2 finality for CELO defined at?
Thanks @aaronmgdr - this is useful. That page is a little short on details, so may I ask a few followups here?
Unsafe blocks - the documentation says “if the user trust the sequencer and its actions it can follow unsafe blocks”. Are the sequencers not distributed, meaning that different sequencers will propose different blocks?
Safe blocks - it is not detailed when blocks are posted to Ethereum. Is it that every block is posted? How quickly does the block get posted?
What is the best way to find how many reorgs have happened for unsafe confirmations in the past?
Our main worry is, if we authorize a card payment within our short time window, and collected it from the user, we want to make sure that collection is not reversed.
Unsafe blocks - the documentation says “if the user trust the sequencer and its actions it can follow unsafe blocks”. Are the sequencers not distributed, meaning that different sequencers will propose different blocks?
A centralized sequencer is used since the L2 migration.
Safe blocks - it is not detailed when blocks are posted to Ethereum. Is it that every block is posted? How quickly does the block get posted?
Commitments for EigenDA blobs get stored on Ethereum. Each blob contains many blocks, so some blocks have they commitments show up faster than other due to this bulk operation. You can see the timing for this difference by comparing the safe block to the latest one. The latest block number will grow continuously while the safe block looks more like a step function.
What is the best way to find how many reorgs have happened for unsafe confirmations in the past?
I’m not aware of any reorgs and there shouldn’t be any reorgs on Celo mainnet, as indicated in the Finality specs.
I don’t know of any data source that provides a history of reorgs (who wants to build this when there are none?). You could regularly store the block-number and tx hash for the latest block and then search for any case where the same block-number shows up with two different hashes. If someone has node logs stored for a long time, you might be able to do this from the logs.