Closed MartinMinkov closed 2 weeks 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!
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.
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
orfetchActions
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.