Open shunjizhan opened 1 year ago
This is how currently the Polkadot/Substrate mechanism works for parachains. https://github.com/paritytech/polkadot/pull/5022 will introduce a new mechanism that will allow shorter block time and bigger blocks also.
Currently, a block is produced when it receives the relay block specifying the previous parachain has been included in the relay. The inclusion of a parachain block takes 2 relay blocks (2* 6s) so 12s but because the parachain block needs to be created as fast as possible to be included, here is what happens:
So every transaction that is sent after the block n°1 (between 0 and 12s) will wait between 12 and 24s before being considered "best" and returned by the API.
gotcha, thanks for your clarification!
So basically it takes 2 extra relay blocks (2 * 6s = 12s) for the para block to be considered "best", before it is returned by api.
I was wondering if it makes sense to consider a tx to be "mined" at step 6, and return the receipt? I am assuming step 7 and 8 is to prevent forking, but in the normal evm context, the tx receipt can be found as soon as it's mined. Current substrate behavior looks like it uses safe tag as the default behavior.
I think a more optimized behavior would be:
In this way users will be able to feel "instant confirmation" by default, whereas projects still have the option for "safe" tag if there business logic requires so.
I think a more optimized behavior would be:
- default: return receipt as soon as it's mined. (similar to "latest" tag)
- safe way: alternatively we can pass "safe" tag when getting a receipt, this will be the current substrate behavior, only return after 2 relay blocks.
- finalize: same for "finalized" tag
@tgmichel or @sorpaas , what do you think about it ? I remember we thought about doing that at the very beginning of frontier but chose not to. I don't see a reason not to do it so now
I personally feel like 'latest' and 'finalized' state would be enough for most use cases:
'safe' state (current behavior) is somehow in the middle: not that smooth, and not that safe :joy:
There are some nuances in the parachain context regarding best - as described in https://github.com/paritytech/frontier/pull/423.
In the above PR, a special SyncStrategy
was introduced to prevent a different pace between the sync worker and the rest of the rpc impl, which mostly uses what's considered to be the best block as a reference. In other words, with the introduction of SyncStrategy
the ethereum data (block and transactions) is mapped on best, and not before, so it will not be available until then.
Give me some time to think if there is a solution for providing faster receipts that is compatible with what I just mentioned.
Edit: the most inmediate/obvious solution I think is to remove SyncStrategy
altogether and do the necessary checks at impl level for eth_getTransactionByHash
, eth_getTransactionReceipt
etc, introduce this non-standard tag param in the necessary rpcs, and then set a default value of this tag to safe. Note that we cannot set a default behaviour to latest because that will break use cases like the one described in the above PR. This way default behaviour should be equivalent to what's currently deployed, and projects with latest needs can still use the optional non-standard param.
If my understanding is correct, after the tx is mined, we will have to wait 12s for relay chain validation before the new state is applied. So even if we support latest
tag, it's different that normal evm latest
tag, which means "tx is mined and state changed". However, in parachain context latest
only means "tx is mined and state will be updated in 12s, please wait 12s for next operation".
So the current behavior in above PR's example is:
X
X + 1
), and relay chain validated it (12s). So receipt is available on block X + 1
+ 12s, which is block X + 2
.X + 2
X + 4
But this doesn't seem to be a "standard" evm behavior, where we should be able to send next tx on next block, with the new state already applied, so the expected behavior is:
X
X + 1
X + 2
I understand that in the engineering point of view, there might be some technical limitation. But just saying in a user's perspective (as a real moonbeam user myself), such X + 2
behavior is very laggy compared to other alternative evm networks (12-24s vs 3-5s confirmation time). So I was wondering if there is any possible solution to achieve the "expected behavior" mentioned above
Problem
When sending tx at block
X
, it is supposed to be mined at blockX + 1
, assuming no congestion. However, there seems to be a shared issue among substrate evms: such tx is usuallly mined at blockX + 2
, which basically mysteriously skipped a block.This causes a terrible UX. For 12s block time, expected confimation time should be 12/2 = 6s on average, which is great. However, with the current issue, expected confirmation time increases to 12/2 + 12 = 18s. This is super slow compared to these alternative evm networks, which usually confirms in less than 5s, sometimes even 2s.
18s confirmation time could be a huge blocker for mass adoption. Users will escape.
Reproduce Script
https://github.com/shunjizhan/tx-confirmation-test