Closed hackfisher closed 2 years ago
For example,
Assuming that there are at least three relayers relaying at the same time/period, they can coordinate and avoid conflict by choosing a random eth_header to relay.
But the problem here is that the relay extrinsic will fail if it's previous eth_header is not relayed, does substrate support a kind of pending extrinsic for it to stay in the extrinsic pool for a period to waiting its foregoing eth_headers to confirmed.
Assuming substrate support such feature, then for each eth_header in future(we can assuming that there at most M headers need confirming if the relayer is able to catch up), there might be multiple relayers' extrinsics waiting and competing the position in the extrinsic pool.
requires
and provides
from ValidTransaction
define TransactionTag
can be used to support such feature.
dispatch(applying the extrinsic) and validate could be different.
Example from CheckNonce
let provides = vec![Encode::encode(&(who, self.0))];
let requires = if account.nonce < self.0 {
vec![Encode::encode(&(who, self.0 - One::one()))]
} else {
vec![]
};
Ok(ValidTransaction {
priority: info.weight as TransactionPriority,
requires,
provides,
longevity: TransactionLongevity::max_value(),
propagate: true,
})
Waiting darwinia's eth-relay module to do a runtime upgrade to supporting this.
/// Tag for a transaction. No two transactions with the same tag should be placed on-chain.
pub type TransactionTag = Vec<u8>;
Caution:
Why no two transactions with same tag should be placed on chain?
If we use eth block height as tag, relay requires multiple headers with same height on chain!
Or we can use eth header previous hash as requires and head hash as provides? That's better.
Need a solution to resolve the coordination of extrinsics relayed from different relayers.