Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Substrate TransactionTag usage and usecae #15

Closed
hackfisher opened this issue May 27, 2020 · 5 comments
Closed

Substrate TransactionTag usage and usecae #15

hackfisher opened this issue May 27, 2020 · 5 comments

Comments

@hackfisher
Copy link
Collaborator

Need a solution to resolve the coordination of extrinsics relayed from different relayers.

@hackfisher
Copy link
Collaborator Author

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.

@hackfisher
Copy link
Collaborator Author

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,
		})

@hackfisher
Copy link
Collaborator Author

Waiting darwinia's eth-relay module to do a runtime upgrade to supporting this.

@hackfisher
Copy link
Collaborator Author


/// 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.

@hackfisher hackfisher changed the title The solution for multiple relayers coordination? Substrate TransactionTag usage and usecae Sep 2, 2020
@hackfisher hackfisher transferred this issue from darwinia-network/dj Sep 2, 2020
@hackfisher
Copy link
Collaborator Author

Replaced by darwinia-network/bridger#239

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant