-
Notifications
You must be signed in to change notification settings - Fork 91
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
pallets: Add Ethereum Transaction pallet #1403
pallets: Add Ethereum Transaction pallet #1403
Conversation
6656fda
to
9613fd6
Compare
signature, | ||
}); | ||
|
||
let (_target, _value, info) = pallet_ethereum::Pallet::<T>::execute( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that we are using pallet_ethereum::execute()
instead of the T::ValidatedTransaction::apply()
used by ethereum-xcm
, as per a previous discussion around this topic.
Where can we find information about the thought process around implementing a custom one instead of using that already solution from PureStake? |
Here is the spec. |
Cool, thank you!
What is the goal behind this feature? Is it so that we have all the substrate calls / blocks accessible in the EVM? And won't it be an issue that all of the mirrored blocks on the EVM are all signed by that mock account? |
value: U256, | ||
gas_price: U256, | ||
gas_limit: U256, | ||
) -> DispatchResultWithPostInfo { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to propagate this and then charge for the fees in one of the callers of this OR do we want to charge all the necessary fees here, in this pallet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upon further testing I noticed that some fees are actually charged by the EVM runner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, the above mentioned fees would be charged from the derived account, meaning that we'll have to ensure that the original caller will have sufficient funds to execute the EVM call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the research. What would happen if the evm fails? Would it roll-back the complete transaction including possible EVM changes?
If this is the case, I would just assume we fail in runtime then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will have to check that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My initial error handling after executing the transaction was incorrect. I updated it now to handle all exit reasons found in there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is an error before this point we will get back a RunnerError
that contains a weight that we should charge. Otherwise, the total fee for the EVM transaction will be charged by the runner and we would only have to charge for reading the nonce.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is an error before this point we will get back a
RunnerError
that contains a weight that we should charge. Otherwise, the total fee for the EVM transaction will be charged by the runner and we would only have to charge for reading the nonce.
Given this, would it make sense to charge for the necessary fees in this pallet? This would the allow us to just use a DispatchResult
here and keep other parts free of fee-related logic. WDYT @mustermeiszer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only think I would clear out is whether we can just fail in runtime/EVM runner if the calley has not enough funds. cc @branan
value: U256, | ||
gas_price: U256, | ||
gas_limit: U256, | ||
) -> DispatchResultWithPostInfo { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the research. What would happen if the evm fails? Would it roll-back the complete transaction including possible EVM changes?
If this is the case, I would just assume we fail in runtime then.
|
||
//TODO(cdamian): Same signature as the one in ethereum-xcm. | ||
let signature = TransactionSignature::new( | ||
42, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^^
As agreed, gonna merge this for now and continue working on the original branch. |
* pallets: Add Ethereum Transaction pallet * ethereum-transaction: Drop origin * ethereum-transaction: Drop weights and origin type * ethereum-transaction: Handle call info exit reasons
* pallets: Add Ethereum Transaction pallet * ethereum-transaction: Drop origin * ethereum-transaction: Drop weights and origin type * ethereum-transaction: Handle call info exit reasons
* pallets: Add Ethereum Transaction pallet * ethereum-transaction: Drop origin * ethereum-transaction: Drop weights and origin type * ethereum-transaction: Handle call info exit reasons
Follow-up for the connectors gateway pallet discussion around EVM found here.
The approach is similar to the one found in ethereum-xcm.
Note this a PR against - #1376, meant to facilitate discussion around this specific topic.