You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The LCMP transaction refers to the evm transaction wrapped in the Receive_message_proof call. For example, https://crab.subscan.io/extrinsic/567733-2. Althrough this type of ethereum transaction has no difference to the transactions sent by the Metamask, it is not supported by the evm tracing APIs, etc. debug_transactionByHash.
The reason for this is a bit complicated. The current tracing result is obtained by iterating over all of the extrinsics in a given block, then matching the extrinsic function with Ethereum::transact { transaction } call, If matched, that means the target transaction to execute to obtain the tracing result has been found. If not, it means that no transaction was found in this block that matches the transaction hash in the rpc param. Unfortunately, the LCMP transaction is the case of mismatched.
fntrace_transaction(_extrinsics:Vec<<Blockas sp_runtime::traits::Block>::Extrinsic>,_traced_transaction:&pallet_ethereum::Transaction,) -> Result<(), sp_runtime::DispatchError>{for ext in _extrinsics.into_iter(){let _ = match&ext.0.function{RuntimeCall::Ethereum(transact{ transaction }) => {// hereif transaction == _traced_transaction {EvmTracer::new().trace(|| Executive::apply_extrinsic(ext));returnOk(());}else{Executive::apply_extrinsic(ext)}}
_ => Executive::apply_extrinsic(ext),};}Err(sp_runtime::DispatchError::Other("Failed to find Ethereum transaction among the extrinsics."))}
There are several alternative ways to fix this:
Add another match to the Receive_message_proof, decode the proof and capture the MessageTransact::transact { transaction } call payload. Note that the captured transaction is not identical to the on-chain ethererum transaction obtained via transaction_hash by RPC, because the transaction nonce and gas_price have been modified in the pallet-message-transact before being applied to the Ethereum layer. This means that you cannot directly compare the two transactions or the transaction hash to determine if they are match. To do this, you need to tweak the captured ethereum transaction nonce and gas_price before matching.
Add another runtime api, called trace_extrinsic and take two params, the first is the same as trace_transaction, the second is the extrinsic. You also need to add a dedicated rpc interface, server to work with this runtime api. This is a less worthwhile approach for this problem.
Use the Ethereum transaction instead of the Substrate extrinsic. A clever solution is that you can submit the Receive_message_proof call via dispatch precompile which is an Ethereum::transact{ transaction }. It will always matche in the trace_transaction function. but this is not a perfect way either. You may run into the evm reentrancy hole when you have successfully decoded the proof and try to dispatch the MessageTransact::transact call in the dispatch precompile.
Conclusion:
To be honest, polkadot-evm/frontier#1040 can also satisfy our demand for debugging in most cases. Considering the demand for LCMP tracing is not so high. In a short, we are not going to support this now, close this issue now,
The text was updated successfully, but these errors were encountered:
Related issues: darwinia-network/darwinia-common#1397 and #1018
The LCMP transaction refers to the evm transaction wrapped in the
Receive_message_proof
call. For example, https://crab.subscan.io/extrinsic/567733-2. Althrough this type of ethereum transaction has no difference to the transactions sent by the Metamask, it is not supported by the evm tracing APIs, etc.debug_transactionByHash
.The reason for this is a bit complicated. The current tracing result is obtained by iterating over all of the extrinsics in a given block, then matching the extrinsic function with
Ethereum::transact { transaction }
call, If matched, that means the target transaction to execute to obtain the tracing result has been found. If not, it means that no transaction was found in this block that matches the transaction hash in the rpc param. Unfortunately, the LCMP transaction is the case of mismatched.There are several alternative ways to fix this:
Receive_message_proof
, decode the proof and capture theMessageTransact::transact { transaction }
call payload. Note that the captured transaction is not identical to the on-chain ethererum transaction obtained via transaction_hash by RPC, because the transaction nonce and gas_price have been modified in the pallet-message-transact before being applied to the Ethereum layer. This means that you cannot directly compare the two transactions or the transaction hash to determine if they are match. To do this, you need to tweak the captured ethereum transaction nonce and gas_price before matching.trace_extrinsic
and take two params, the first is the same astrace_transaction
, the second is the extrinsic. You also need to add a dedicated rpc interface, server to work with this runtime api. This is a less worthwhile approach for this problem.Receive_message_proof
call via dispatch precompile which is anEthereum::transact{ transaction }
. It will always matche in thetrace_transaction
function. but this is not a perfect way either. You may run into the evm reentrancy hole when you have successfully decoded the proof and try to dispatch theMessageTransact::transact
call in the dispatch precompile.Conclusion:
To be honest, polkadot-evm/frontier#1040 can also satisfy our demand for debugging in most cases. Considering the demand for LCMP tracing is not so high. In a short, we are not going to support this now, close this issue now,
The text was updated successfully, but these errors were encountered: