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
this shows as soon as I click Submit Transaction on the UI (before confirmation)... if I then click Sign and Submit, the error logs show up once again:
====================
Version: 0.0.0-0383d213062
0: backtrace::capture::Backtrace::new
1: sp_panic_handler::set::{{closure}}
2: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/alloc/src/boxed.rs:1999:9
std::panicking::rust_panic_with_hook
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/std/src/panicking.rs:695:13
3: std::panicking::begin_panic_handler::{{closure}}
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/std/src/panicking.rs:582:13
4: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/std/src/sys_common/backtrace.rs:151:18
5: rust_begin_unwind
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/std/src/panicking.rs:578:5
6: core::panicking::panic_fmt
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/core/src/panicking.rs:67:14
7: frontier_template_runtime::api::dispatch
8: environmental::using
9: sc_executor::executor::WasmExecutor<H>::with_instance::{{closure}}
10: sc_executor::wasm_runtime::RuntimeCache::with_instance
11: <sc_executor::executor::NativeElseWasmExecutor<D> as sp_core::traits::CodeExecutor>::call
12: sp_state_machine::execution::StateMachine<B,H,Exec>::execute_aux
13: sp_state_machine::execution::StateMachine<B,H,Exec>::execute_using_consensus_failure_handler
14: <sc_service::client::call_executor::LocalCallExecutor<Block,B,E> as sc_client_api::call_executor::CallExecutor<Block>>::call
15: <sc_rpc::state::state_full::FullState<BE,Block,Client> as sc_rpc::state::StateBackend<Block,Client>>::call
16: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
17: tokio::runtime::task::core::Core<T,S>::poll
18: tokio::runtime::task::harness::Harness<T,S>::poll
19: tokio::runtime::blocking::pool::Inner::run
20: std::sys_common::backtrace::__rust_begin_short_backtrace
21: core::ops::function::FnOnce::call_once{{vtable.shim}}
22: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/alloc/src/boxed.rs:1985:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/alloc/src/boxed.rs:1985:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/8b4b20836b832e91aa605a2faf5e2a55190202c8/library/std/src/sys/unix/thread.rs:108:17
23: __pthread_joiner_wake
Thread 'tokio-runtime-worker' panicked at 'Bad input data provided to query_info: Could not decode `UncheckedExtrinsic.0`:
Could not decode `RuntimeCall::Ethereum.0`:
Could not decode `Call::transact::transaction`:
Could not decode `TransactionV2::Legacy.0`:
Could not decode `LegacyTransaction::signature`:
Invalid signature
', template/runtime/src/lib.rs:564
This is a bug. Please report it at:
support.anonymous.an
2023-09-07 17:29:07 Evicting failed runtime instance error=Runtime panicked: Bad input data provided to query_info: Could not decode `UncheckedExtrinsic.0`:
Could not decode `RuntimeCall::Ethereum.0`:
Could not decode `Call::transact::transaction`:
Could not decode `TransactionV2::Legacy.0`:
Could not decode `LegacyTransaction::signature`:
Invalid signature
Expected vs. Actual Behavior
I would expect a successful execution on the EVM. Or at least the EVM to reject the transaction for some specific reason (e.g.: invalid v,r,s).
The text was updated successfully, but these errors were encountered:
to elaborate a bit more on the methodology to reproduce this issue, first I started the template via ./target/release/frontier-template-node --dev
then I sent a tx via ethersjs and observed its parameters via hardhat
then I re-started the template by killing the previous execution and running ./target/release/frontier-template-node --dev again
for some reason the v == 0 field is being considered invalid there, which is weird since it was taken from a tx that was successfully executed via ethersjs
we did some new tests taking a different tx coming from another EVM, for which v is a big value (403643), and then replaying this tx in a frontier parachain with the same chain_id of this origin EVM... the error does not happen under those circumstances
so we are no longer blocked by this, because our main goal is to simply replay txs from an origin EVM into this Frontier parachain
but it would be good to improve the implementation of the transact extrinsic so that it handles this edge case of invalid signatures gracefully without a runtime panic
Some information to note: I dug a little deeper and found that the error message Invalid signature comes from https://github.com/rust-blockchain/ethereum/blob/master/src/transaction.rs#L166. Fortunately, the transaction causing the runtime panic is be validate false and is not be included in the block. No idea what to do next about this now.
This is expected. If we do not panic on invalid signatures, then the extrinsic will be included in a block but will not be paying any fees.
You should not use ethereum.transact on the Substrate RPC. That'll submit the extrinsic from a signed source, rather than the unsigned Ethereum source. It'll always fail even if you have the correct signature. Use the Ethereum RPC instead.
Description
I am trying to submit a transaction via
pallet-ethereum
'stransact
extrinsic.I encounter errors on PolkadotJS UI as well as on the node's logs.
Steps to Reproduce
master
branch./target/release/frontier-template-node --dev
ethersjs
):See error on PolkadotJS UI:
See error on node logs:
this shows as soon as I click
Submit Transaction
on the UI (before confirmation)... if I then clickSign and Submit
, the error logs show up once again:Expected vs. Actual Behavior
I would expect a successful execution on the EVM. Or at least the EVM to reject the transaction for some specific reason (e.g.: invalid
v,r,s
).The text was updated successfully, but these errors were encountered: