o1-labs / o1js

TypeScript framework for zk-SNARKs and zkApps
https://docs.minaprotocol.com/en/zkapps/how-to-write-a-zkapp
Apache License 2.0
513 stars 116 forks source link

Discussion: Filter out all blocks at the tip of the network if there is more than 1 #763

Closed MartinMinkov closed 2 weeks ago

MartinMinkov commented 1 year ago

Description

Related too https://github.com/o1-labs/snarkyjs/pull/749

Should we filter out all blocks at the max height of the network?

The issue with blocks at the tip of the network is that since Mina's finality cannot guarantee that a fork will not happen at the tip of the network, a block that contains event/action data could be replaced with one that doesn't, changing the state of the network in the viewpoint of the caller of fetchEvents/fetchActions.

To give a higher probability that a block will be considered canonical as part of the chain, we will filter out all blocks at the best tip of the network if multiple ones are being considered. This will introduce a delay of maxBlockHeight - 1 for fetching events/actions data to give a higher probality that the transaction will be part of the network.

Impact

By filtering out blocks at the tip of the network, users of fetchEvents or fetchActions will have to wait for an additional block to give a higher probability that their transaction will not be forked by another block that replaces it. It trades off the speed of receiving events/actions data for more reliance on the data being part of the network.

If we do not want to filter out blocks at the highest tip, we will have to return a block that can be replaced, which gives an inconsistent view of a user of a zkApp depending on events/actions data, but users will not have to wait for an additional block to be included.

mitschabaude commented 1 year ago

One concern I have is that, for all the other network and account state, we currently fetch the latest block (bestChain(maxLength: 1)), so we would be using a view on the chain that's inconsistent with other data we use.

On the other hand, it might not be a problem if events and actions are lagging behind a bit, and in contrast to other state they don't get invalidated by newer blocks -- they just get appended to. The increased reliability of the events that are returned is definitely a good point.

I'd vote for making this a config option, with the default probably being what you suggested @MartinMinkov!

MartinMinkov commented 1 year ago

In light of this PR: https://github.com/MinaProtocol/mina/pull/12750

The Archive API will be able to use the data in the new schema to return the block with the highest chain strength.