phala-network / khala-parachain Goto Github PK
View Code? Open in Web Editor NEWKhala parachain
License: Apache License 2.0
Khala parachain
License: Apache License 2.0
A Bridge reserve account is a dedicated account used to hold the reserve asset on our blockchain when transferring asset to a non-reserve location. For example, if we transfer PHA
to Ethereum through our bridge, after the PHA withdrew from user account, it will be deposited to reserve account, when user transfers back from Ethereum, asset will be withdrawn from reserve account and deposited to user account.
We derive bridge reserve accounts in this way (convert location to an account), as we can see, the location is determined by bridge_type
and dest_chain_id
. The problem is same bridge can not share the liquidity of the same asset when bridging to different bridges. This will lead to a bad experience when people transfer from Phala to Chain1 and Chain2, then some people transfer from Chain1 to Chain2, and in the end, people can not transfer the whole asset back from Chain1 to Phala.
The consideration of the current implementation is that we isolate reserve accounts according to different dest chains, which can limit the influence when the bridge got to hack on one blockchain. That means only the amount of the asset in the reserve account will be exploited
It seems both advantages are critical, we need to propose a better derivation mechanism.
TODO
Hey Phala team,
I found this
The GeneralIndex
is u128
from here. How do you ensure the cast is valid? I mean u128 as u8
uses modulo, but it has collisions.
Now khala-staging
without the explicit parachain id will be interpreted as khala
. Instead we should report an error
Hello Khala+Phala developers,
I'm with Dwellir, a web3 infrastructure provider which runs both Khala and Phala nodes. I have a question for you:
Are there any plans to start releasing Dockers image for every latest release, e.g. v0.1.26-2 at the moment?
Checking the Docker Hub page, v0.1.26
is still the latest one available even though there's a newer one here on GitHub. Since my team, and probably many others, use these images to upgrade our nodes it would be very nice if all the latest releases could be made available there. I understand this might mean extra work on your part, but on the other hand it would likely result in more nodes on the network running the latest runtimes.
Thank you for your time!
This issue describes the technical details of how we integrate Sygma pallets into SubBridge.
SubBridge core module xtransfer support assembles any bridge that implements trait BridgeTransact. The bridge can be configured as a bridge instance of SubBridge routing protocol, here is the configuration in Khala network. SubBridge can forward messages between those bridges.
Sygma bridge pallet only provides the primitives and extrinsic to transfer assets between Substrate chains and EVM chains, to make the Sygma protocol adapts SubBridge routing protocol, we need to introduce a wrapper pallet that mainly implements the trait BridgeTransact
. A draft implementation can be found here.
The simple logic of transferring assets to EVM chains can be described as:
xtransfer.transfer() -> sygma_wrapper.transfer_fungible() -> sygma_bridge.deposit()
The draft code can be found here
The simple logic of transferring assets from EVM chains to other parachains (including local Substrate chains) can be described as:
sygma_bridge.relayers -> sygma_bridge.execute_proposal() -> sygma_bridge.AssetTransactor.deposit_asset() -> XTransferAdapter.deposit_asset() -> other bridges
Note that we configured XTransferAdapter as the AssetTransactor
of Sygma bridge, it makes SubBridge routing protocol take over the asset transactor. See draft code here.
Besides, the Sygma wrapper also implements traits ExtractRecipient
and ExtractDomainID
, so the dest location identification will depend on the format that SubBridge used.
Sygma Wrapper does not contains any extrinsic, we don't need to config any authority strategy.
A draft config can be found here. Compared with simple example config in Sygma repo, following items should be highlighted:
As we mentioned above, we use SubBridge XTransferAdapter
will be configured as asset transactor implementation.
We configured ResourcePairs
with AssetsRegistry
, the latter implements Get<Vec<(XcmAssetId, ResourceId)>>
which returns the resource id pair information for all registered assets in Khala network. In other words, it is dynamic instead of hard code in runtime. See draft code here.
Like the example configuration in the Sygma repo, the BridgeCommitteeOrigin
of sygma_access_segregator
, sygma_basic_feehandler
, sygma_fee_handler_router
and sygma_bridge
are configured as EnsureRootOrHalfCouncil
. On the production network (Khala and Phala), there is no root exists, on-chain governance (council) will be the role that management bridges.
We still can use sygma_access_segregator
to apply different permission to a specific account.
Bridge still can be set through sygma_basic_feehandler
and be routed by sygma_fee_handler_router
. SubBridge routing protocol doesn't impact fee logic.
====================
Version: 0.1.16-82d9a956a2b
0: sp_panic_handler::set::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:702:17
2: std::panicking::begin_panic::{{closure}}
3: std::sys_common::backtrace::__rust_end_short_backtrace
4: std::panicking::begin_panic
5: <quicksink::SinkImpl<S,F,T,A,E> as futures_sink::Sink<A>>::poll_flush
6: <libp2p::bandwidth::BandwidthConnecLogging<TInner> as futures_io::if_std::AsyncWrite>::poll_flush
7: <libp2p_noise::io::framed::NoiseFramed<T,S> as futures_sink::Sink<&alloc::vec::Vec<u8>>>::poll_flush
8: <libp2p_noise::io::NoiseOutput<T> as futures_io::if_std::AsyncWrite>::poll_flush
9: multistream_select::negotiated::Negotiated<TInner>::poll
10: <multistream_select::negotiated::Negotiated<TInner> as futures_io::if_std::AsyncWrite>::poll_close
11: yamux::connection::into_stream::{{closure}}::{{closure}}
12: <futures_util::stream::try_stream::ErrInto<St,E> as futures_core::stream::Stream>::poll_next
13: <libp2p_core::muxing::Wrap<T> as libp2p_core::muxing::StreamMuxer>::poll_close
14: <futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll
15: tokio::runtime::task::harness::poll_future
16: tokio::runtime::task::raw::poll
17: tokio::runtime::thread_pool::worker::Context::run_task
18: tokio::runtime::thread_pool::worker::run
19: tokio::runtime::task::raw::poll
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 [4/933]
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/alloc/src/boxed.rs:1861:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/alloc/src/boxed.rs:1861:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/sys/unix/thread.rs:108:17
23: start_thread
24: clone
Thread 'tokio-runtime-worker' panicked at 'SinkImpl::poll_flush called after error.', /root/.cargo/registry/src/github.com-1ecc
6299db9ec823/quicksink-0.1.2/src/lib.rs:225
This is a bug. Please report it at:
https://github.com/Phala-Network/khala-parachain/issues/new
./start_node.sh: line 70: 9 Segmentation fault (core dumped) /usr/local/bin/khala-node --chain $PARACHAIN --base-path
$DATA_PATH --name $NODE_NAME --port $PARACHAIN_PORT --prometheus-port 9615 --rpc-port 9933 --ws-port 9944 --prometheus-external
--ws-external --rpc-cors all --no-hardware-benchmarks $PARACHAIN_ROLE_ARGS $PARACHAIN_EXTRA_ARGS -- --chain $RELAYCHAIN --port
$RELAYCHAIN_PORT --prometheus-port 9616 --rpc-port 9934 --ws-port 9945 --prometheus-external --ws-external --rpc-cors all --no
-hardware-benchmarks $RELAYCHAIN_ROLE_ARGS $RELAYCHAIN_EXTRA_ARGS
Compare https://github.com/paritytech/substrate/commits/polkadot-v0.9.15 with https://github.com/paritytech/substrate/commits/polkadot-v0.9.13 there is no commit labled E1-runtimemigration
so it looks there's no migration need to care
Compare https://github.com/paritytech/cumulus/commits/polkadot-v0.9.15 with https://github.com/paritytech/cumulus/commits/polkadot-v0.9.13 no migration needed too
One PR needs mention paritytech/polkadot#4181 which followed in 19f9862
Polkadot just released v0.9.15-1 which not provide cumulus branch has reverted this PR (see https://github.com/paritytech/polkadot/releases/tag/v0.9.15-1 ) so please double confirm this one is no harm for us
I already update main to polkadot-v0.9.15 and bump version, if it's OK, feel free to tag latest commit as v0.1.10
and prepare runtime upgrade.
Remember this time Khala introduced XCM-relates pallets
Version: 0.1.16-dev-3b68cd70487
0: sp_panic_handler::set::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:702:17
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:588:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/sys_common/backtrace.rs:138:18
4: rust_begin_unwind
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:584:5
5: core::panicking::panic_fmt
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/core/src/panicking.rs:143:14
6: <sp_database::kvdb::DbAdapter as sp_database::Database>::get
7: <sc_client_db::StorageDb as sp_state_machine::trie_backend_essence::Storage<<::Header as sp_runtime::traits::Header>::Hashing>>::get
8: <sc_client_db::Backend as sc_client_api::backend::Backend>::have_state_at
9: sc_client_db::Backend::try_commit_operation
10: <sc_client_db::Backend as sc_client_api::backend::Backend>::commit_operation
11: cumulus_client_consensus_common::parachain_consensus::run_parachain_consensus::{{closure}}::{{closure}}::{{closure}}
12: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
13: tokio::runtime::task::harness::poll_future
14: tokio::runtime::task::raw::poll
15: tokio::runtime::thread_pool::worker::Context::run_task
16: tokio::runtime::thread_pool::worker::run
17: tokio::runtime::task::raw::poll
18: std::sys_common::backtrace::__rust_begin_short_backtrace
19: core::ops::function::FnOnce::call_once{{vtable.shim}}
20: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/alloc/src/boxed.rs:1861:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/alloc/src/boxed.rs:1861:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/sys/unix/thread.rs:108:17
21: start_thread
22: clone
Thread 'tokio-runtime-worker' panicked at 'Critical database error: Custom { kind: Other, error: Error { message: "IO error: While pread offset 38788880 len 13883: /root/data/chains/khala/db/full/033868.sst: Input/output error" } }', /root/.cargo/git/checkouts/substrate-7e08433d4c370a21/257cdb5/primitives/database/src/kvdb.rs:29
Version: 0.1.16-dev-3b68cd70487
0: sp_panic_handler::set::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:702:17
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:588:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/sys_common/backtrace.rs:138:18
4: rust_begin_unwind
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:584:5
5: core::panicking::panic_fmt
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/core/src/panicking.rs:143:14
6: <sp_database::kvdb::DbAdapter as sp_database::Database>::get
7: <sc_client_db::StorageDb as sp_state_machine::trie_backend_essence::Storage<<::Header as sp_runtime::traits::Header>::Hashing>>::get
8: <sp_state_machine::trie_backend_essence::TrieBackendEssence<S,H> as hash_db::HashDB<H,alloc::vec::Vec>>::get
9: <sp_state_machine::trie_backend_essence::TrieBackendEssence<S,H> as hash_db::HashDBRef<H,alloc::vec::Vec>>::get
10: trie_db::Trie::get
11: sp_state_machine::trie_backend_essence::TrieBackendEssence<S,H>::storage
12: <sc_client_db::storage_cache::CachingState<S,B> as sp_state_machine::backend::Backend<<::Header as sp_runtime::traits::Header>::Hashing>>::storage
13: <sp_state_machine::ext::Ext<H,B> as sp_externalities::Externalities>::storage
14: sp_io::storage::get_version_1
15: sp_io::storage::ExtStorageGetVersion1::call
16: <F as wasmtime::func::IntoFunc<T,(wasmtime::func::Caller,A1),R>>::into_func::wasm_to_host_shim
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28: wasmtime_runtime::traphandlers::catch_traps::call_closure
29: wasmtime_setjmp
30: sc_executor_wasmtime::runtime::perform_call
31: <sc_executor_wasmtime::runtime::WasmtimeInstance as sc_executor_common::wasm_runtime::WasmInstance>::call
32: sc_executor_common::wasm_runtime::WasmInstance::call_export
33: sc_executor::native_executor::WasmExecutor::with_instance::{{closure}}
34: sp_state_machine::execution::StateMachine<B,H,Exec>::execute_aux
35: <polkadot_runtime::RuntimeApiImpl<SR_API_BLOCK,RuntimeApiImplCall> as sp_api::Core<SR_API_BLOCK>>::Core_execute_block_runtime_api_impl
36: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
37: <sc_finality_grandpa::import::GrandpaBlockImport<BE,Block,Client,SC> as sc_consensus::block_import::BlockImport>::import_block::{{closure}}
38: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
39: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
40: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
41: sc_consensus::import_queue::basic_queue::block_import_process::{{closure}}
42: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
43: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
44: <tracing_futures::Instrumented as core::future::future::Future>::poll
45: tokio::runtime::task::raw::poll
46: std::sys_common::backtrace::__rust_begin_short_backtrace
47: core::ops::function::FnOnce::call_once{{vtable.shim}}
48: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/alloc/src/boxed.rs:1861:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/alloc/src/boxed.rs:1861:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/sys/unix/thread.rs:108:17
49: start_thread
50: clone
Thread 'tokio-runtime-worker' panicked at 'Critical database error: Custom { kind: Other, error: Error { message: "IO error: While pread offset 12611434 len 8673: /root/data/polkadot/chains/ksmcc3/db/full/193983.sst: Input/output error" } }', /root/.cargo/git/checkouts/substrate-7e08433d4c370a21/257cdb5/primitives/database/src/kvdb.rs:29
I'm trying to run an archival node with following docker-compose.yml:
version: '2'
services:
khala:
image: phalanetwork/khala-node
ports:
- 19948:9944
volumes:
- ./khala:/root/data
environment:
NODE_ROLE: ARCHIVE
Relay chain blocks are synced, but not parachain blocks for some reason:
khala_1 | 2021-10-22 22:38:30 [Parachain] 💤 Idle (0 peers), best: #0 (0xd435…be8d), finalized #0 (0xd435…be8d), ⬇ 1.0kiB/s ⬆ 0.6kiB/s
khala_1 | 2021-10-22 22:38:30 [Relaychain] ⚙️ Syncing 70.1 bps, target=#9772297 (32 peers), best: #29789 (0x9012…29cc), finalized #29696 (0xfdd0…790c), ⬇ 42.2kiB/s ⬆ 5.4kiB/s
I have a bunch of full nodes of other parachains and they work fine, I only found an issue with Khala.
====================
Version: 0.1.4-1-8cb47b9-x86_64-linux-gnu
0: sp_panic_handler::set::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:626:17
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:519:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/sys_common/backtrace.rs:141:18
4: rust_begin_unwind
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:515:5
5: std::panicking::begin_panic_fmt
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:457:5
6: frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPallets,COnRuntimeUpgrade>::execute_extrinsics_with_book_keeping
7: tracing::span::Span::in_scope
8: frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPallets,COnRuntimeUpgrade>::execute_block
9: <khala_parachain_runtime::Runtime as sp_api::runtime_decl_for_Core::Core<sp_runtime::generic::block::Block<sp_runtime::generic::header::Header<u32,sp_runtime::traits::BlakeTwo256>,sp_runtime::generic::unchecked_extrinsic::UncheckedExtrinsic<sp_runtime::multiaddress::MultiAddress<<<sp_runtime::MultiSignature as sp_runtime::traits::Verify>::Signer as sp_runtime::traits::IdentifyAccount>::AccountId,()>,khala_parachain_runtime::Call,sp_runtime::MultiSignature,(frame_system::extensions::check_spec_version::CheckSpecVersion<khala_parachain_runtime::Runtime>,frame_system::extensions::check_tx_version::CheckTxVersion<khala_parachain_runtime::Runtime>,frame_system::extensions::check_genesis::CheckGenesis<khala_parachain_runtime::Runtime>,frame_system::extensions::check_mortality::CheckMortality<khala_parachain_runtime::Runtime>,frame_system::extensions::check_nonce::CheckNonce<khala_parachain_runtime::Runtime>,frame_system::extensions::check_weight::CheckWeight<khala_parachain_runtime::Runtime>,phala_pallets::mq::check_seq::CheckMqSequence<khala_parachain_runtime::Runtime>,pallet_transaction_payment::ChargeTransactionPayment<khala_parachain_runtime::Runtime>)>>>>::execute_block
10: std::panicking::try
11: std::thread::local::LocalKey::with
12: sc_executor::native_executor::WasmExecutor::with_instance::{{closure}}
13: sc_executor::wasm_runtime::RuntimeCache::with_instance
14: <sc_executor::native_executor::NativeExecutor as sp_core::traits::CodeExecutor>::call
15: sp_state_machine::execution::StateMachine<B,H,N,Exec>::execute_aux
16: sp_state_machine::execution::StateMachine<B,H,N,Exec>::execute_using_consensus_failure_handler
17: <sc_service::client::call_executor::LocalCallExecutor<Block,B,E> as sc_client_api::call_executor::CallExecutor>::contextual_call
18: <sc_service::client::client::Client<B,E,Block,RA> as sp_api::CallApiAt>::call_api_at
19: sp_api::runtime_decl_for_Core::execute_block_call_api_at
20: <khala_parachain_runtime::RuntimeApiImpl<SR_API_BLOCK,RuntimeApiImplCall> as sp_api::Core<SR_API_BLOCK>>::Core_execute_block_runtime_api_impl
21: sc_service::client::client::Client<B,E,Block,RA>::prepare_block_storage_changes
22: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
23: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
24: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
25: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
26: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
27: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
28: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
29: <sc_service::task_manager::prometheus_future::PrometheusFuture as core::future::future::Future>::poll
30: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
31: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
32: <tracing_futures::Instrumented as core::future::future::Future>::poll
33: std::thread::local::LocalKey::with
34: futures_executor::local_pool::block_on
35: tokio::runtime::task::core::Core<T,S>::poll
36: <std::panic::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once
37: tokio::runtime::task::harness::Harness<T,S>::poll
38: tokio::runtime::blocking::pool::Inner::run
39: tokio::runtime::context::enter
40: std::sys_common::backtrace::__rust_begin_short_backtrace
41: core::ops::function::FnOnce::call_once{{vtable.shim}}
42: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/alloc/src/boxed.rs:1575:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/alloc/src/boxed.rs:1575:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/sys/unix/thread.rs:72:17
43: start_thread
44: clone
Thread 'tokio-runtime-worker' panicked at 'Transaction will be valid in the future', /root/.cargo/git/checkouts/substrate-7e08433d4c370a21/91061a7/frame/executive/src/lib.rs:363
This is a bug. Please report it at:
https://github.com/Phala-Network/khala-parachain/issues/new
Please update Khala's message routing:
to the latest one:
https://github.com/Phala-Network/phala-blockchain/blob/master/standalone/runtime/src/msg_routing.rs
Starting Khala node as role 'MINER' with extra parachain args '--state-cache-size 671088640 --db-cache 2048 --max-runtime-instances 16' extra relaychain args '--state-cache-size 671088640 --db-cache 2048 --max-runtime-instances 16'
====================
Version: 0.1.4-1-8cb47b9-x86_64-linux-gnu
0: sp_panic_handler::set::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:626:17
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:519:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/sys_common/backtrace.rs:141:18
4: rust_begin_unwind
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:515:5
5: std::panicking::begin_panic_fmt
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:457:5
6: fdlimit::raise_fd_limit
7: sc_cli::config::CliConfiguration::init
8: khala_node::command::run
9: khala_node::main
10: std::sys_common::backtrace::__rust_begin_short_backtrace
11: std::rt::lang_start::{{closure}}
12: core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/core/src/ops/function.rs:259:13
std::panicking::try::do_call
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:401:40
std::panicking::try
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:365:19
std::panic::catch_unwind
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panic.rs:434:14
std::rt::lang_start_internal::{{closure}}
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/rt.rs:45:48
std::panicking::try::do_call
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:401:40
std::panicking::try
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panicking.rs:365:19
std::panic::catch_unwind
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/panic.rs:434:14
std::rt::lang_start_internal
at /rustc/798baebde1fe77e5a660490ec64e727a5d79970d/library/std/src/rt.rs:45:20
13: main
14: __libc_start_main
15: _start
Thread 'main' panicked at 'raise_fd_limit: error calling setrlimit: Operation not permitted (os error 1)', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/fdlimit-0.2.1/src/lib.rs:105
This is a bug. Please report it at:
https://github.com/Phala-Network/khala-parachain/issues/new
__Ignore
exists for some internal reason. However it's never constructed in the code (its parameter has a "never" type). Therefore we can safely ignore this variant when defining the base call filter. In Polkadot codebase, there's no __Ignore
variant mentioned in any match clause as well.
According to the Issue reported by Acala, when transfer asset from Khala to Karura, if the fee set in XCM message by Khala XCM module is less than the actually fee spend in karura, XCM execution will failed on Karura.
The reason why this happened is because we have the following code that always set half of the tranfer amount as fee. So far when we transfer PHA, the actually fee is 0.0512 PHA on Karura, that means if user transfer amount is less than 0.1024, the fee we set in Khala will less than 0.0512, we willl get TooExpensive
error on Karura.
let fee = if T::FeeAssets::get().contains(&asset)
|| T::NativeAssetChecker::is_native_asset(&asset)
{
match asset.fun {
// So far only half of amount are allowed to be used as fee
Fungible(amount) => MultiAsset {
fun: Fungible(amount / 2),
id: asset.id.clone(),
},
// We do not support unfungible asset transfer, nor support it as fee
_ => return Err(Error::<T>::AssetNotFound.into()),
}
} else {
// Basiclly, if the asset is supported as fee in our system, it should be also supported in the dest
// parachain, so if we are not support use this asset as fee, try use PHA as fee asset instead
MultiAsset {
fun: Fungible(T::DefaultFee::get()),
id: T::NativeAssetChecker::native_asset_id().into(),
}
};
We need to update the fee calculation mechanism to make sure the given fee will never less than actually fee spend on destination chain.
Our phala node isn't syncing to the tip and is stuck on block 90051 for 18+ hours:
2022-07-31 16:44:23 [Relaychain] 💤 Idle (50 peers), best: #11404419 (0xb0af…67fd), finalized #11404415 (0x709b…8792), ⬇ 158.3kiB/s ⬆ 155.6kiB/s
2022-07-31 16:44:23 [Parachain] 💤 Idle (1 peers), best: #90051 (0x5d96…2488), finalized #90051 (0x5d96…2488), ⬇ 1.0kiB/s ⬆ 1.3kiB/s
Repeated restarts are not helping. The blockhashes are correct on both relaychain + parachain so I believe the spec is correct.
Our invocation, which we believe to be correct, is:
./target/release/khala-node --name phala --base-path /root/.local/share/phala/ --chain /khala/khala-parachain/node/res/phala.json --state-cache-size 1 --db-cache 2048 --runtime-cache-size 32 --rpc-methods Unsafe --unsafe-rpc-external --rpc-port 9100 --rpc-external --ws-external --ws-port 9944 --unsafe-ws-external --rpc-max-payload 64 --collator --pruning archive --no-prometheus --rpc-cors all
Our goal is to run full node to support trace / XCM transfer indexing in https://phala.polkaholic.io --
Are the correct bootnodes specified here in the chain spec and used?
# head /khala/khala-parachain/node/res/phala.json
{
"name": "Phala",
"id": "phala",
"chainType": "Live",
"bootNodes": [
"/dns4/phala-node-hk.phala.network/tcp/30333/ws/p2p/12D3KooWAPkEheyc7QcP3Mhf4iJdmCaPN9aHUofyKTE1an4g2PCK",
"/dns4/phala-node-eu.phala.network/tcp/30333/ws/p2p/12D3KooWGSQvEFii28GeN1EKG7vWj6VEfM3Md8Z25nEpbzR6k3yc",
"/dns4/phala-node-us.phala.network/tcp/30333/ws/p2p/12D3KooWKzDSCdMpLEKCR9nEfS7arW7mmH2VyVur4XM4GgaffjeY"
],
Please advise -- Thank you!
2024-01-11 09:37:00 Khala Node
2024-01-11 09:37:00 ✌️ version 0.1.26-399a7ef7c3e
2024-01-11 09:37:00 ❤️ by Phala Network, 2018-2024
2024-01-11 09:37:00 📋 Chain specification: Khala
2024-01-11 09:37:00 🏷 Node name: khala-node
2024-01-11 09:37:00 👤 Role: FULL
2024-01-11 09:37:00 💾 Database: ParityDb at /root/data/chains/khala/paritydb/full
--state-cache-size
was deprecated. Please switch to --trie-cache-size
.
2024-01-11 09:37:04 It isn't safe to expose RPC publicly without a proxy server that filters available set of RPC methods.
2024-01-11 09:37:04 Parachain id: Id(2004)
2024-01-11 09:37:04 Parachain Account: 5Ec4AhPVjsshXjh8ynp6MwaJTJBnen3pkHiiyDhHfie5VWkN
2024-01-11 09:37:04 Is collating: no
2024-01-11 09:37:27 [Relaychain] 🏷 Local node identity is: 12D3KooWKDBHyLQcJ4oAvBaomukBJfBD94WkEu3smak6V71EtMNU
2024-01-11 09:37:27 [Relaychain] 💻 Operating system: linux
2024-01-11 09:37:27 [Relaychain] 💻 CPU architecture: x86_64
2024-01-11 09:37:27 [Relaychain] 💻 Target environment: gnu
2024-01-11 09:37:27 [Relaychain] 💻 CPU: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
2024-01-11 09:37:27 [Relaychain] 💻 CPU cores: 4
2024-01-11 09:37:27 [Relaychain] 💻 Memory: 7948MB
2024-01-11 09:37:27 [Relaychain] 💻 Kernel: 5.15.0-73-generic
2024-01-11 09:37:27 [Relaychain] 💻 Linux distribution: Ubuntu 22.04.3 LTS
2024-01-11 09:37:27 [Relaychain] 💻 Virtual machine: yes
2024-01-11 09:37:27 [Relaychain] 📦 Highest known block at #21266639
2024-01-11 09:37:27 [Relaychain] 〽️ Prometheus exporter started at 0.0.0.0:9616
2024-01-11 09:37:27 [Relaychain] Running JSON-RPC server: addr=0.0.0.0:9945, allowed origins=[""]
2024-01-11 09:37:27 [Relaychain] Starting with an empty approval vote DB.
2024-01-11 09:37:27 [Parachain] 🏷 Local node identity is: 12D3KooWLsnTwzN6q6yc5yvEH19ecQXw8U7C13DYRR3qoj5Snveh
2024-01-11 09:37:27 [Parachain] 💻 Operating system: linux
2024-01-11 09:37:27 [Parachain] 💻 CPU architecture: x86_64
2024-01-11 09:37:27 [Parachain] 💻 Target environment: gnu
2024-01-11 09:37:27 [Parachain] 💻 CPU: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
2024-01-11 09:37:27 [Parachain] 💻 CPU cores: 4
2024-01-11 09:37:27 [Parachain] 💻 Memory: 7948MB
2024-01-11 09:37:27 [Parachain] 💻 Kernel: 5.15.0-73-generic
2024-01-11 09:37:27 [Parachain] 💻 Linux distribution: Ubuntu 22.04.3 LTS
2024-01-11 09:37:27 [Parachain] 💻 Virtual machine: yes
2024-01-11 09:37:27 [Parachain] 📦 Highest known block at #5263414
2024-01-11 09:37:27 [Parachain] Running JSON-RPC server: addr=0.0.0.0:9944, allowed origins=[""]
2024-01-11 09:37:27 [Parachain] 〽️ Prometheus exporter started at 0.0.0.0:9615
2024-01-11 09:37:27 [Relaychain] discovered: 12D3KooWLsnTwzN6q6yc5yvEH19ecQXw8U7C13DYRR3qoj5Snveh /ip4/172.23.0.2/tcp/30333/ws
2024-01-11 09:37:27 [Parachain] discovered: 12D3KooWKDBHyLQcJ4oAvBaomukBJfBD94WkEu3smak6V71EtMNU /ip4/172.23.0.2/tcp/30334/ws
2024-01-11 09:37:28 [Parachain] 🔍 Discovered new external address for our node: /ip4/116.136.130.138/tcp/30333/ws/p2p/12D3KooWLsnTwzN6q6yc5yvEH19ecQXw8U7C13DYRR3qoj5Snveh
2024-01-11 09:37:28 [Relaychain] 🔍 Discovered new external address for our node: /ip4/116.136.130.138/tcp/30334/ws/p2p/12D3KooWKDBHyLQcJ4oAvBaomukBJfBD94WkEu3smak6V71EtMNU
====================
Version: 0.1.26-399a7ef7c3e
0: sp_panic_handler::set::{{closure}}
1: <alloc::boxed::Box<F,A> as core::ops::function::Fn>::call
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2021:9
std::panicking::rust_panic_with_hook
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:711:13
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:599:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:170:18
4: rust_begin_unwind
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
5: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
6: core::result::unwrap_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/result.rs:1652:5
7: <sp_state_machine::ext::Ext<H,B> as sp_externalities::Externalities>::storage
8: sp_io::storage::get_version_1
9: sp_io::storage::ExtStorageGetVersion1::call
10: <F as wasmtime::func::IntoFunc<T,(wasmtime::func::Caller,A1),R>>::into_func::wasm_to_host_shim
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22: wasmtime_runtime::traphandlers::catch_traps::call_closure
23: wasmtime_setjmp
24: sc_executor_wasmtime::runtime::WasmtimeInstance::call_impl
25: sc_executor_common::wasm_runtime::WasmInstance::call_export
26: sc_executor::executor::WasmExecutor::with_instance::{{closure}}
27: <sc_executor::executor::WasmExecutor as sp_core::traits::CodeExecutor>::call
28: sp_state_machine::execution::StateMachine<B,H,Exec>::execute
29: <sc_service::client::client::Client<B,E,Block,RA> as sp_api::CallApiAt>::call_api_at
30: <khala_parachain_runtime::RuntimeApiImpl<SrApiBlock,RuntimeApiImplCall> as sp_api::Core<SrApiBlock>>::__runtime_api_internal_call_api_at
31: <&sc_service::client::client::Client<B,E,Block,RA> as sc_consensus::block_import::BlockImport>::import_block::{{closure}}
32: <alloc::sync::Arc as sc_consensus::block_import::BlockImport>::import_block::{{closure}}
33: <cumulus_client_consensus_common::ParachainBlockImport<Block,BI,BE> as sc_consensus::block_import::BlockImport>::import_block::{{closure}}
34: <alloc::boxed::Box<dyn sc_consensus::block_import::BlockImport+Error = sp_consensus::error::Error+core::marker::Sync+core::marker::Send> as sc_consensus::block_import::BlockImport>::import_block::{{closure}}
35: sc_consensus::import_queue::basic_queue::BlockImportWorker::new::{{closure}}
36: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
37: <tracing_futures::Instrumented as core::future::future::Future>::poll
38: tokio::runtime::task::raw::poll
39: std::sys_common::backtrace::__rust_begin_short_backtrace
40: core::ops::function::FnOnce::call_once{{vtable.shim}}
41: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2007:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2007:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys/unix/thread.rs:108:17
42:
43: __clone
Thread 'tokio-runtime-worker' panicked at 'Externalities not allowed to fail within runtime: "Trie lookup error: Database missing expected key: 0xfece5216d2677951509e74a6ba5b990fce918a36dee3fdc9aecb336ac21a6760"', /root/.cargo/git/checkouts/polkadot-sdk-cff69157b985ed76/72c4535/substrate/primitives/state-machine/src/ext.rs:176
This is a bug. Please report it at:
https://github.com/Phala-Network/khala-parachain/issues/new
With PR59 merged, storage used to store resource id was removed, should clean the storage in migration script.
docker logs 322428f9acb9 -f --tail 10
24: clone
Thread 'tokio-runtime-worker' panicked at 'SinkImpl::poll_flush called after error.', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/quicksink-0.1.2/src/lib.rs:225
This is a bug. Please report it at:
https://github.com/Phala-Network/khala-parachain/issues/new
./start_node.sh: line 70: 8 Segmentation fault (core dumped) /usr/local/bin/khala-node --chain $PARACHAIN --base-path $DATA_PATH --name $NODE_NAME --port $PARACHAIN_PORT --prometheus-port 9615 --rpc-port 9933 --ws-port 9944 --prometheus-external --ws-external --rpc-cors all --no-hardware-benchmarks $PARACHAIN_ROLE_ARGS $PARACHAIN_EXTRA_ARGS -- --chain $RELAYCHAIN --port $RELAYCHAIN_PORT --prometheus-port 9616 --rpc-port 9934 --ws-port 9945 --prometheus-external --ws-external --rpc-cors all --no-hardware-benchmarks $RELAYCHAIN_ROLE_ARGS $RELAYCHAIN_EXTRA_ARGS
When proposing a bounty, there's a config type SpendOrigin
in treasury config to approve the bounty. So far the config at Khala & Phala is frame_support::traits::NeverEnsureOrigin<u128>
, which means nobody can approve the bounty.
Suggested to change it to:
type SpendOrigin = frame_system::EnsureWithSuccess<
frame_support::traits::EitherOf<
EnsureRoot<AccountId>,
pallet_collective::EnsureProportionMoreThan<AccountId, CouncilCollective, 1, 2>,
>,
AccountId, MaxBalance,
>;
Good for a code bounty. Polkadot has set up CI for deterministic (reproducible) runtime build. We should also follow.
TODO
phala-node |
phala-node | 0: sp_panic_handler::set::{{closure}}
phala-node | 1: std::panicking::rust_panic_with_hook
phala-node | at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:610:17
phala-node | 2: std::panicking::begin_panic_handler::{{closure}}
phala-node | at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:500:13
phala-node | 3: std::sys_common::backtrace::__rust_end_short_backtrace
phala-node | at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/sys_common/backtrace.rs:139:18
phala-node | 4: rust_begin_unwind
phala-node | at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5
phala-node | 5: core::panicking::panic_fmt
phala-node | at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14
phala-node | 6: <khala_parachain_runtime::Runtime as sp_api::runtime_decl_for_Core::Core<sp_runtime::generic::block::Block<sp_runtime::generic::header::Header<u32,sp_runtime::traits::BlakeTwo256>,sp_runtime::generic::unchecked_extrinsic::UncheckedExtrinsic<sp_runtime::multiaddress::MultiAddress<<<sp_runtime::MultiSignature as sp_runtime::traits::Verify>::Signer as sp_runtime::traits::IdentifyAccount>::AccountId,()>,khala_parachain_runtime::Call,sp_runtime::MultiSignature,(frame_system::extensions::check_spec_version::CheckSpecVersion<khala_parachain_runtime::Runtime>,frame_system::extensions::check_tx_version::CheckTxVersion<khala_parachain_runtime::Runtime>,frame_system::extensions::check_genesis::CheckGenesis<khala_parachain_runtime::Runtime>,frame_system::extensions::check_mortality::CheckMortality<khala_parachain_runtime::Runtime>,frame_system::extensions::check_nonce::CheckNonce<khala_parachain_runtime::Runtime>,frame_system::extensions::check_weight::CheckWeight<khala_parachain_runtime::Runtime>,phala_pallets::mq::check_seq::CheckMqSequence<khala_parachain_runtime::Runtime>,pallet_transaction_payment::ChargeTransactionPayment<khala_parachain_runtime::Runtime>)>>>>::execute_block
phala-node | 7: std::panicking::try
phala-node | 8: sp_externalities::scope_limited::set_and_run_with_externalities
phala-node | 9: sc_executor::native_executor::WasmExecutor::with_instance::{{closure}}
phala-node | 10: sc_executor::wasm_runtime::RuntimeCache::with_instance
phala-node | 11: sp_state_machine::execution::StateMachine<B,H,Exec>::execute_aux
phala-node | 12: sp_state_machine::execution::StateMachine<B,H,Exec>::execute_using_consensus_failure_handler
phala-node | 13: <sc_service::client::call_executor::LocalCallExecutor<Block,B,E> as sc_client_api::call_executor::CallExecutor<Block>>::contextual_call
phala-node | 14: <khala_parachain_runtime::RuntimeApiImpl<__SR_API_BLOCK__,RuntimeApiImplCall> as sp_api::Core<__SR_API_BLOCK__>>::Core_execute_block_runtime_api_impl
phala-node | 15: sc_service::client::client::Client<B,E,Block,RA>::prepare_block_storage_changes
phala-node | 16: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
phala-node | 17: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
phala-node | 18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
phala-node | 19: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
phala-node | 20: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
phala-node | 21: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
phala-node | 22: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
phala-node | 23: tokio::park::thread::CachedParkThread::block_on
phala-node | 24: tokio::runtime::task::raw::poll
phala-node | 25: std::sys_common::backtrace::__rust_begin_short_backtrace
phala-node | 26: core::ops::function::FnOnce::call_once{{vtable.shim}}
phala-node | 27: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
phala-node | at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/alloc/src/boxed.rs:1694:9
phala-node | <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
phala-node | at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/alloc/src/boxed.rs:1694:9
phala-node | std::sys::unix::thread::Thread::new::thread_start
phala-node | at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/sys/unix/thread.rs:106:17
phala-node | 28: start_thread
phala-node | 29: clone
phala-node |
phala-node |
phala-node | Thread 'tokio-runtime-worker' panicked at 'Storage root must match that calculated.', /root/.cargo/git/checkouts/substrate-7e08433d4c370a21/d36550a/frame/executive/src/lib.rs:488
phala-node |
phala-node | This is a bug. Please report it at:
phala-node |
phala-node | https://github.com/Phala-Network/khala-parachain/issues/new
phala-node |
phala-node | 2022-02-08 22:27:11 [Parachain] panicked at 'Storage root must match that calculated.', /home/h4x/.cargo/git/checkouts/substrate-7e08433d4c370a21/d36550a/frame/executive/src/lib.rs:488:9
phala-node | 2022-02-08 22:27:11 [Parachain] Block prepare storage changes error:
phala-node | RuntimeApiError(Application(Execution(Other("Wasm execution trapped: wasm trap: unreachable\nwasm backtrace:\n 0: 0x5ce8 - <unknown>!rust_begin_unwind\n 1: 0x274a - <unknown>!core::panicking::panic_fmt::h8f11323637b4db3b\n 2: 0xdbfc9 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::h8614e9cd1ce2fa16\n 3: 0x2c46a9 - <unknown>!Core_execute_block\n"))))
phala-node | 2022-02-08 22:27:11 [Parachain] 💔 Error importing block 0x56653de29abadc78ec179faa40ace1ac6956f34cb784439bcc770f7f747f1fd3: Err(Other(ClientImport("Error at calling runtime api: Execution failed: Other(\"Wasm execution trapped: wasm trap: unreachable\\nwasm backtrace:\\n 0: 0x5ce8 - <unknown>!rust_begin_unwind\\n 1: 0x274a - <unknown>!core::panicking::panic_fmt::h8f11323637b4db3b\\n 2: 0xdbfc9 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::h8614e9cd1ce2fa16\\n 3: 0x2c46a9 - <unknown>!Core_execute_block\\n\")")))
phala-node | 2022-02-08 22:27:12 [Relaychain] ✨ Imported #11323789 (0xa206…7daa)
Hi. I'm getting these errors on phala-node while trying to sync pherry. I'm running solo-mining on latest version and docker images are updated as well. I don't know if it's a specific error or it's a bug:
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:10 [Relaychain] 💤 Idle (30 peers), best: #12391689 (0xc13e…48dc), finalized #12391686 (0xd44a…c88a), ⬇ 104.9kiB/s ⬆ 268.1kiB/s
phala-node | 2022-04-24 11:48:12 [Relaychain] ✨ Imported #12391690 (0x3407…51f0)
phala-node | 2022-04-24 11:48:13 [Parachain] ⚙️ Syncing 0.0 bps, target=#1521786 (17 peers), best: #1521700 (0x4a8f…1f73), finalized #1521700 (0x4a8f…1f73), ⬇ 155.1kiB/s ⬆ 3.1kiB/s
phala-node | 2022-04-24 11:48:15 [Relaychain] 💤 Idle (29 peers), best: #12391690 (0x3407…51f0), finalized #12391686 (0xd44a…c88a), ⬇ 187.1kiB/s ⬆ 349.6kiB/s
phala-node | 2022-04-24 11:48:16 [Parachain] panicked at 'Transaction will be valid in the future', /home/h4x/.cargo/git/checkouts/substrate-7e08433d4c370a21/fc3fd07/frame/executive/src/lib.rs:388:17
phala-node | 2022-04-24 11:48:16 [Parachain] Block prepare storage changes error: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
phala-node | WASM backtrace:
phala-node |
phala-node | 0: 0x9b7b - <unknown>!rust_begin_unwind
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:16 [Parachain] 💔 Error importing block 0x3a7213b5f5203ce5be1656dc67a55817e49e749493d21cb1973cec2d5adf85db: consensus error: Import failed: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
phala-node | WASM backtrace:
phala-node |
phala-node | 0: 0x9b7b - <unknown>!rust_begin_unwind
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:18 [Relaychain] ✨ Imported #12391691 (0x548f…ec34)
phala-node | 2022-04-24 11:48:18 [Parachain] ⚙️ Syncing 0.0 bps, target=#1521787 (17 peers), best: #1521700 (0x4a8f…1f73), finalized #1521700 (0x4a8f…1f73), ⬇ 347.2kiB/s ⬆ 3.1kiB/s
phala-node | 2022-04-24 11:48:18 [Parachain] panicked at 'Transaction will be valid in the future', /home/h4x/.cargo/git/checkouts/substrate-7e08433d4c370a21/fc3fd07/frame/executive/src/lib.rs:388:17
phala-node | 2022-04-24 11:48:18 [Parachain] Block prepare storage changes error: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
phala-node | WASM backtrace:
phala-node |
phala-node | 0: 0x9b7b - <unknown>!rust_begin_unwind
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:18 [Parachain] 💔 Error importing block 0x3a7213b5f5203ce5be1656dc67a55817e49e749493d21cb1973cec2d5adf85db: consensus error: Import failed: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
phala-node | WASM backtrace:
phala-node |
phala-node | 0: 0x9b7b - <unknown>!rust_begin_unwind
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:20 [Relaychain] 💤 Idle (30 peers), best: #12391691 (0x548f…ec34), finalized #12391687 (0x10b7…d18d), ⬇ 267.7kiB/s ⬆ 408.1kiB/s
phala-node | 2022-04-24 11:48:23 [Parachain] ⚙️ Syncing 0.0 bps, target=#1521786 (17 peers), best: #1521700 (0x4a8f…1f73), finalized #1521700 (0x4a8f…1f73), ⬇ 82.7kiB/s ⬆ 2.4kiB/s
phala-node | 2022-04-24 11:48:24 [Relaychain] ✨ Imported #12391692 (0x37e9…ebbc)
phala-node | 2022-04-24 11:48:25 [Parachain] panicked at 'Transaction will be valid in the future', /home/h4x/.cargo/git/checkouts/substrate-7e08433d4c370a21/fc3fd07/frame/executive/src/lib.rs:388:17
phala-node | 2022-04-24 11:48:25 [Parachain] Block prepare storage changes error: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
phala-node | WASM backtrace:
phala-node |
phala-node | 0: 0x9b7b - <unknown>!rust_begin_unwind
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:25 [Parachain] 💔 Error importing block 0x3a7213b5f5203ce5be1656dc67a55817e49e749493d21cb1973cec2d5adf85db: consensus error: Import failed: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
phala-node | WASM backtrace:
phala-node |
phala-node | 0: 0x9b7b - <unknown>!rust_begin_unwind
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:25 [Relaychain] 💤 Idle (30 peers), best: #12391692 (0x37e9…ebbc), finalized #12391689 (0xc13e…48dc), ⬇ 750.9kiB/s ⬆ 635.7kiB/s
phala-node | 2022-04-24 11:48:27 [Parachain] panicked at 'Transaction will be valid in the future', /home/h4x/.cargo/git/checkouts/substrate-7e08433d4c370a21/fc3fd07/frame/executive/src/lib.rs:388:17
phala-node | 2022-04-24 11:48:27 [Parachain] Block prepare storage changes error: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
phala-node | WASM backtrace:
phala-node |
phala-node | 0: 0x9b7b - <unknown>!rust_begin_unwind
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:27 [Parachain] 💔 Error importing block 0x3a7213b5f5203ce5be1656dc67a55817e49e749493d21cb1973cec2d5adf85db: consensus error: Import failed: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
phala-node | WASM backtrace:
phala-node |
phala-node | 0: 0x9b7b - <unknown>!rust_begin_unwind
phala-node | 1: 0x1d43 - <unknown>!core::panicking::panic_fmt::h038028a9926e2771
phala-node | 2: 0x27aea4 - <unknown>!core::panicking::panic_display::h656450c1cd186e0e
phala-node | 3: 0x2782a1 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::execute_block::hcbf439b5561e9f9f
phala-node | 4: 0x298902 - <unknown>!Core_execute_block
phala-node |
phala-node | 2022-04-24 11:48:28 [Parachain] ⚙️ Syncing 0.0 bps, target=#1521786 (17 peers), best: #1521700 (0x4a8f…1f73), finalized #1521700 (0x4a8f…1f73), ⬇ 473.5kiB/s ⬆ 3.0kiB/s
phala-node | 2022-04-24 11:48:30 [Relaychain] ✨ Imported #12391693 (0x96c7…ee0c)
phala-node | 2022-04-24 11:48:30 [Relaychain] ♻️ Reorg on #12391693,0x96c7…ee0c to #12391693,0xf191…1ff0, common ancestor #12391692,0x37e9…ebbc
phala-node | 2022-04-24 11:48:30 [Relaychain] ✨ Imported #12391693 (0xf191…1ff0)
Write benchmark for pallet-index, currently, Weight is being hard-code as 195_000_000
Hi, I'm trying to run phala testnet node using docker, however, I am unable to get the target and finalized blocks.
Here are the logs for reference:
2024-01-25 13:00:36 Khala Node
2024-01-25 13:00:36 ✌️ version 0.1.26-399a7ef7c3e
2024-01-25 13:00:36 ❤️ by Phala Network, 2018-2024
2024-01-25 13:00:36 📋 Chain specification: Khala
2024-01-25 13:00:36 🏷 Node name: bob
2024-01-25 13:00:36 👤 Role: FULL
2024-01-25 13:00:36 💾 Database: RocksDb at /root/.local/share/khala-node/chains/khala/db/full
2024-01-25 13:00:38 Parachain id: Id(2004)
2024-01-25 13:00:38 Parachain Account: 5Ec4AhPVjsshXjh8ynp6MwaJTJBnen3pkHiiyDhHfie5VWkN
2024-01-25 13:00:38 Is collating: no
2024-01-25 13:00:40 [Parachain] 🔨 Initializing Genesis block/state (state: 0x740f…308a, header-hash: 0x2c0c…b6bf)
2024-01-25 13:00:42 [Relaychain] 🔨 Initializing Genesis block/state (state: 0x8ad9…f0da, header-hash: 0x6408…063e)
2024-01-25 13:00:42 [Relaychain] 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2024-01-25 13:00:43 [Relaychain] 👶 Creating empty BABE epoch changes on what appears to be first startup.
2024-01-25 13:00:43 [Relaychain] 🏷 Local node identity is: 12D3KooWEUde1JR6K7mst8bEyMjkbPdLQCBu5XMgcDAu6putCD3c
2024-01-25 13:00:43 [Relaychain] 💻 Operating system: linux
2024-01-25 13:00:43 [Relaychain] 💻 CPU architecture: x86_64
2024-01-25 13:00:43 [Relaychain] 💻 Target environment: gnu
2024-01-25 13:00:43 [Relaychain] 💻 CPU: AMD Ryzen 5 5500U with Radeon Graphics
2024-01-25 13:00:43 [Relaychain] 💻 CPU cores: 6
2024-01-25 13:00:43 [Relaychain] 💻 Memory: 5775MB
2024-01-25 13:00:43 [Relaychain] 💻 Kernel: 6.5.0-14-generic
2024-01-25 13:00:43 [Relaychain] 💻 Linux distribution: Ubuntu 22.04.3 LTS
2024-01-25 13:00:43 [Relaychain] 💻 Virtual machine: no
2024-01-25 13:00:43 [Relaychain] 📦 Highest known block at #0
2024-01-25 13:00:43 [Relaychain] 〽️ Prometheus exporter started at 127.0.0.1:9616
2024-01-25 13:00:43 [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9945, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"]
2024-01-25 13:00:43 [Relaychain] 🏁 CPU score: 1.17 GiBs
2024-01-25 13:00:43 [Relaychain] 🏁 Memory score: 8.39 GiBs
2024-01-25 13:00:43 [Relaychain] 🏁 Disk score (seq. writes): 793.16 MiBs
2024-01-25 13:00:43 [Relaychain] 🏁 Disk score (rand. writes): 321.76 MiBs
2024-01-25 13:00:43 [Relaychain] Starting with an empty approval vote DB.
2024-01-25 13:00:43 [Parachain] 🏷 Local node identity is: 12D3KooWExyw8mAK8XD1F3KBsa59xTLrqsXeyMMLDPgKnT3RoVkS
2024-01-25 13:00:43 [Relaychain] discovered: 12D3KooWM32Ld2HfKwcHBPBfXqeXiNyqwUJcRpYvBCNkeqBX7NNt /ip4/172.16.4.5/tcp/30333
2024-01-25 13:00:43 [Relaychain] discovered: 12D3KooWPZobB1hZ5T4pGJ5EcCbKUqHox6byQ8s2z5uq6VC35Y9C /ip4/172.16.4.5/tcp/30334/ws
2024-01-25 13:00:43 [Parachain] 💻 Operating system: linux
2024-01-25 13:00:43 [Parachain] 💻 CPU architecture: x86_64
2024-01-25 13:00:43 [Parachain] 💻 Target environment: gnu
2024-01-25 13:00:43 [Parachain] 💻 CPU: AMD Ryzen 5 5500U with Radeon Graphics
2024-01-25 13:00:43 [Parachain] 💻 CPU cores: 6
2024-01-25 13:00:43 [Parachain] 💻 Memory: 5775MB
2024-01-25 13:00:43 [Parachain] 💻 Kernel: 6.5.0-14-generic
2024-01-25 13:00:43 [Parachain] 💻 Linux distribution: Ubuntu 22.04.3 LTS
2024-01-25 13:00:43 [Parachain] 💻 Virtual machine: no
2024-01-25 13:00:43 [Parachain] 📦 Highest known block at #0
2024-01-25 13:00:43 [Parachain] 〽️ Prometheus exporter started at 0.0.0.0:9615
2024-01-25 13:00:43 [Parachain] Running JSON-RPC server: addr=0.0.0.0:9947, allowed origins=["*"]
2024-01-25 13:00:43 [Parachain] 🏁 CPU score: 1.17 GiBs
2024-01-25 13:00:43 [Parachain] 🏁 Memory score: 8.39 GiBs
2024-01-25 13:00:43 [Parachain] 🏁 Disk score (seq. writes): 793.16 MiBs
2024-01-25 13:00:43 [Parachain] 🏁 Disk score (rand. writes): 321.76 MiBs
2024-01-25 13:00:43 [Parachain] discovered: 12D3KooWEUde1JR6K7mst8bEyMjkbPdLQCBu5XMgcDAu6putCD3c /ip4/172.16.4.6/tcp/30334/ws
2024-01-25 13:00:43 [Relaychain] discovered: 12D3KooWExyw8mAK8XD1F3KBsa59xTLrqsXeyMMLDPgKnT3RoVkS /ip4/172.16.4.6/tcp/30333/ws
2024-01-25 13:00:43 [Parachain] discovered: 12D3KooWM32Ld2HfKwcHBPBfXqeXiNyqwUJcRpYvBCNkeqBX7NNt /ip4/172.16.4.5/tcp/30333
2024-01-25 13:00:43 [Parachain] discovered: 12D3KooWPZobB1hZ5T4pGJ5EcCbKUqHox6byQ8s2z5uq6VC35Y9C /ip4/172.16.4.5/tcp/30334/ws
2024-01-25 13:00:43 Accepting new connection 1/100
2024-01-25 13:00:46 [Relaychain] 🔍 Discovered new external address for our node: /ip4/103.171.98.49/tcp/30334/ws/p2p/12D3KooWEUde1JR6K7mst8bEyMjkbPdLQCBu5XMgcDAu6putCD3c
2024-01-25 13:00:48 [Relaychain] ⚙️ Syncing, target=#8900478 (10 peers), best: #960 (0xf788…fe2d), finalized #512 (0x18dd…4b3c), ⬇ 546.2kiB/s ⬆ 68.5kiB/s
2024-01-25 13:00:48 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:00:49 [Relaychain] CurrentBlockRandomness did not provide entropy
2024-01-25 13:00:53 [Relaychain] ⚙️ Syncing 302.6 bps, target=#8900478 (9 peers), best: #2473 (0xd6d6…7259), finalized #2379 (0x5ea6…cff8), ⬇ 906.8kiB/s ⬆ 23.8kiB/s
2024-01-25 13:00:53 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:00:58 [Relaychain] ⚙️ Syncing 293.8 bps, target=#8900479 (10 peers), best: #3942 (0xab94…f5cc), finalized #3584 (0xbde7…c04d), ⬇ 578.4kiB/s ⬆ 29.4kiB/s
2024-01-25 13:00:58 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:03 [Relaychain] ⚙️ Syncing 263.0 bps, target=#8900480 (10 peers), best: #5257 (0xa03a…44d2), finalized #5120 (0x141b…4f75), ⬇ 954.8kiB/s ⬆ 37.0kiB/s
2024-01-25 13:01:03 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:08 [Relaychain] ⚙️ Syncing 177.4 bps, target=#8900481 (10 peers), best: #6144 (0x7f10…b7d7), finalized #6144 (0x7f10…b7d7), ⬇ 800.4kiB/s ⬆ 10.1kiB/s
2024-01-25 13:01:08 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:13 [Relaychain] ⚙️ Syncing 121.2 bps, target=#8900482 (10 peers), best: #6750 (0x5ee0…10a6), finalized #6656 (0xc613…4098), ⬇ 354.1kiB/s ⬆ 7.6kiB/s
2024-01-25 13:01:13 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:18 [Relaychain] ⚙️ Syncing 45.0 bps, target=#8900483 (10 peers), best: #6975 (0x3892…ac92), finalized #6656 (0xc613…4098), ⬇ 423.8kiB/s ⬆ 9.4kiB/s
2024-01-25 13:01:18 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:23 [Relaychain] ⚙️ Syncing 141.0 bps, target=#8900483 (10 peers), best: #7680 (0x3f07…2e90), finalized #7680 (0x3f07…2e90), ⬇ 429.5kiB/s ⬆ 5.8kiB/s
2024-01-25 13:01:23 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:28 [Relaychain] ⚙️ Syncing 96.0 bps, target=#8900484 (10 peers), best: #8160 (0xb65e…2a8b), finalized #7726 (0xd40d…fc22), ⬇ 660.5kiB/s ⬆ 12.1kiB/s
2024-01-25 13:01:28 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:33 [Relaychain] ⚙️ Syncing 108.8 bps, target=#8900485 (11 peers), best: #8704 (0x7bf2…05d5), finalized #8704 (0x7bf2…05d5), ⬇ 835.5kiB/s ⬆ 12.4kiB/s
2024-01-25 13:01:33 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:38 [Relaychain] ⚙️ Syncing 177.4 bps, target=#8900486 (11 peers), best: #9591 (0xa4e0…be84), finalized #9445 (0x6890…0942), ⬇ 852.4kiB/s ⬆ 7.4kiB/s
2024-01-25 13:01:38 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:43 [Relaychain] ⚙️ Syncing 155.4 bps, target=#8900486 (11 peers), best: #10368 (0x15b4…3ea0), finalized #10240 (0x24a5…cba6), ⬇ 1.1MiB/s ⬆ 12.7kiB/s
2024-01-25 13:01:43 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:48 [Relaychain] ⚙️ Syncing 0.0 bps, target=#8900487 (11 peers), best: #10368 (0x15b4…3ea0), finalized #10240 (0x24a5…cba6), ⬇ 1.1MiB/s ⬆ 13.7kiB/s
2024-01-25 13:01:48 [Parachain] 💤 Idle (0 peers), best: #0 (0x2c0c…b6bf), finalized #0 (0x2c0c…b6bf), ⬇ 0 ⬆ 0
2024-01-25 13:01:53 [Relaychain] ⚙️ Syncing 0.0 bps, target=#8900488 (10 peers), best: #10368 (0x15b4…3ea0), finalized #10240 (0x24a5…cba6), ⬇ 1.3MiB/s ⬆ 17.8kiB/s
In the delegate web page https://app.phala.network/delegate/, the following steps are performed, and the search results do not appear:
Do not execute the first step, directly execute the second step, the result can be displayed
Just in mind, when we upgrade to polkadot-v1.5.0 ( Phala-Network/phala-blockchain#1494 ) we must do migration for Khala & Phala
SubBridge intends to run as a bridge hub instead of running our own bridges. We are working on integrating with mature 3rd bridges and retire the team owned bridge as soon as possible.
Hey guys,
It looks like nodes advertising themselves as "Khala Node v0.1.2-ae5d185(..)" are clogging up the telemetry page (https://telemetry.polkadot.io/#list/0xb0a8d493285c2df73290dfb7e61f870f17b41801197a149ca93654499ea3dafe), as they are sending telemetry with continually changing message and network IDs on the same persistent telemetry connection, leading to an endlessly growing list of "stale" nodes being displayed there.
I'm not sure where the issue lies, but perhaps it's worth redirecting the node telemetry elsewhere to avoid overwhelming the telemetry server until the issue has been resolved? :)
pallet-ott
was used before launching PHA token transfer. Now it's not used anymore. Let's remove it.
Hi. I'm having this error before a khala-node crash and stop sync:
{"log":"2022-03-24 19:34:56 [Parachain] Block prepare storage changes error:\n","stream":"stderr","time":"2022-03-24T19:34:56.152741038Z"}
{"log":"RuntimeApiError(Application(Execution(Other(\"Wasm execution trapped: wasm trap: wasm 'unreachable' instruction executed\\nwasm backtrace:\\n 0: 0xa09a - \u003cunknown\u003e!rust_begin_unwind\\n 1: 0x2579 - \u003cunknown\u003e!core::panicking::panic_fmt::h8f11323637b4db3b\\n 2: 0x28c925 - \u003cunknown\u003e!core::panicking::panic_display::hedf123f608c6d14b\\n 3: 0x28a5d1 - \u003cunknown\u003e!frame_executive::Executive\u003cSystem,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade\u003e::execute_block::hd5fa63f32fff0cdb\\n 4: 0x2add8a - \u003cunknown\u003e!Core_execute_block\\n\")))) \n","stream":"stderr","time":"2022-03-24T19:34:56.152756782Z"}
{"log":"2022-03-24 19:34:56 [Parachain] 💔 Error importing block 0x52607a6bd7da05150d6134df8bd86e4fdb54b27e2289dc5ce97b1c3df97f038c: Err(Other(ClientImport(\"Error at calling runtime api: Execution failed: Other(\\\"Wasm execution trapped: wasm trap: wasm 'unreachable' instruction executed\\\\nwasm backtrace:\\\\n 0: 0xa09a - \u003cunknown\u003e!rust_begin_unwind\\\\n 1: 0x2579 - \u003cunknown\u003e!core::panicking::panic_fmt::h8f11323637b4db3b\\\\n 2: 0x28c925 - \u003cunknown\u003e!core::panicking::panic_display::hedf123f608c6d14b\\\\n 3: 0x28a5d1 - \u003cunknown\u003e!frame_executive::Executive\u003cSystem,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade\u003e::execute_block::hd5fa63f32fff0cdb\\\\n 4: 0x2add8a - \u003cunknown\u003e!Core_execute_block\\\\n\\\")\"))) \n","stream":"stderr","time":"2022-03-24T19:34:56.152760848Z"}
The only way to recover from error is restart khala-node container.
I'm using solo-mining-scripts and running v1110.
Lastest blocks that caused this kind of error:
1383708, 1384714, 1384921, 1397861, 1402958, 1410103 and 1413384
I tried node restart and set --restart=always
When I restart a node, the error repeats..
pherry syne is not decreasing but increasing
====================
Version: 0.1.16-82d9a956a2b
0: sp_panic_handler::set::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:702:17
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:588:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/sys_common/backtrace.rs:138:18
4: rust_begin_unwind
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/panicking.rs:584:5
5: core::panicking::panic_fmt
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/core/src/panicking.rs:143:14
6: core::result::unwrap_failed
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/core/src/result.rs:1785:5
7: <sp_state_machine::ext::Ext<H,B> as sp_externalities::Externalities>::storage
8: sp_io::storage::get_version_1
9: sp_io::storage::ExtStorageGetVersion1::call
10: <F as wasmtime::func::IntoFunc<T,(wasmtime::func::Caller,A1),R>>::into_func::wasm_to_host_shim
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22: wasmtime_runtime::traphandlers::catch_traps::call_closure
23: wasmtime_setjmp
24: sc_executor_wasmtime::runtime::perform_call
25: <sc_executor_wasmtime::runtime::WasmtimeInstance as sc_executor_common::wasm_runtime::WasmInstance>::call
26: sc_executor_common::wasm_runtime::WasmInstance::call_export
27: sc_executor::native_executor::WasmExecutor::with_instance::{{closure}}
28: sp_state_machine::execution::StateMachine<B,H,Exec>::execute_aux
29: <khala_parachain_runtime::RuntimeApiImpl<SR_API_BLOCK,RuntimeApiImplCall> as sp_api::Core<SR_API_BLOCK>>::Core_execute_block_runtime_api_impl
30: sp_api::Core::execute_block
31: rayon::iter::plumbing::bridge_producer_consumer::helper
32: <phala_node_rpc_ext::NodeRpcExt<BE,Block,Client,P> as phala_node_rpc_ext::NodeRpcExtApiServer<::Hash>>::get_storage_changes
33: jsonrpsee_core::server::rpc_module::RpcModule::register_method::{{closure}}
34: jsonrpsee_ws_server::server::background_task::{{closure}}
35: tokio::runtime::task::harness::poll_future
36: tokio::runtime::task::raw::poll
37: tokio::runtime::thread_pool::worker::Context::run_task
38: tokio::runtime::thread_pool::worker::run
39: tokio::runtime::task::raw::poll
40: std::sys_common::backtrace::__rust_begin_short_backtrace
41: core::ops::function::FnOnce::call_once{{vtable.shim}}
42: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/alloc/src/boxed.rs:1861:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/alloc/src/boxed.rs:1861:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/0677edc86e342f333d4828b0ee1ef395a4e70fe5/library/std/src/sys/unix/thread.rs:108:17
43: start_thread
44: clone
Thread 'tokio-runtime-worker' panicked at 'Externalities not allowed to fail within runtime: "Trie lookup error: Database missing expected key: 0x5e5f9c2927451056342eaa077c19af27cafc93e3162098e7c4bf8f3ea9bd25c9"', /root/.cargo/git/checkouts/substrate-7e08433d4c370a21/814752f/primitives/state-machine/src/ext.rs:189
This is a bug. Please report it at:
https://github.com/Phala-Network/khala-parachain/issues/new
When doing crosschain transfer, some of the scenarios need teem deposit assets into reserve account in advance, e.g. ZLK transfer between parachain and moonriver EVM. It's better to also have a method that can withdraw the assets from reserve account.
TBD
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.