phala-network / khala-parachain Goto Github PK

View Code? Open in Web Editor NEW

27.0 17.0 19.0 40 MB

Khala parachain

License: Apache License 2.0

Rust 80.41% Shell 0.37% JavaScript 14.04% Nix 2.74% TypeScript 2.44%

khala-parachain's Introduction

Khala Parachain

Khala parachain repo.

Build Note

For production build

cargo build --profile production

For testnet build

cargo build --profile testnet

Build runtime only

cargo build --profile production -p khala-parachain-runtime

Enable on-chain-release-build would reduce ~100 KB

cargo build --profile production --features on-chain-release-build -p khala-parachain-runtime

Special note for macOS

You have to install LLVM from Homebrew because Xcode bundled doesn't have WASM target

brew install llvm

As formula note shows binaries locate at /opt/homebrew/opt/llvm/bin (You can revisit it via brew info llvm, beware Intel Mac has different location)

Make alias for ar and ranlib to ensure use custom installed LLVM instead of Xcode bundled

cd /opt/homebrew/opt/llvm/bin
ln -s llvm-ar ar
ln -s llvm-ar ranlib

NOTE: You have to re-do this step after you upgrade or reinstall LLVM

Before compiling khala-node, add custom installed LLVM to $PATH

export PATH="/opt/homebrew/opt/llvm/bin:$PATH"

Development Note

Run a local testnet cluster

Build

cargo build --release

Prepare binaries

You can get latest Polkadot Linux release from https://github.com/paritytech/polkadot/releases

For macOS, you have to build from source

cp <path-to-polkadot> ./polkadot-launch/bin/
cp ./target/release/khala ./polkadot-launch/bin/

Start a local test net

cd polkadot-launch
yarn
yarn start ./thala_dev.config.json

(Optional) Inject session key.

Only required for *_local.config.json

Please make sure to use the correct session key json file.

cd scripts/js
yarn
KEY_FILE=session_key.json.example node insert_session_key.js

khala-parachain's People

Contributors

Stargazers

Watchers

Forkers

sawvox limichange msghais www222fff index0011 leechael saraswatpuneet tenheadedlion kureus ltfschoen dwellir-public arrudagates maharacha skunert jonathanudd grantimagen ryangrullon helikon-labs

khala-parachain's Issues

node error

====================

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

khala-node crashes and stop sync

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

Spotted in logs

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)

The node stops after running for a few minutes

Phala Scripts Version: v0.2.4

Khala nodes leading to spam on https://telemetry.polkadot.io

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? :)

Crash part2

Version: 0.1.16-dev-3b68cd70487

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

Add support of withdrawing asset from bridge reserve account

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

Who has the permission to withdraw?
Amount limited?

Integrate Assets

Integrate 3rd party bridges

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.

Core Dump on Phala-Node container while syncing Pherry

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)

Question about Docker Hub releases for runtime updates

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!

sudo docker start phala-node 报错

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

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

Error on start node

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

Deterministic WASM build for parachain runtime

Good for a code bounty. Polkadot has set up CI for deterministic (reproducible) runtime build. We should also follow.

TODO

A clear bounty definition
Resources
Post to Gitcoin.co

Retire pallet-ott

pallet-ott was used before launching PHA token transfer. Now it's not used anymore. Let's remove it.

target and finalized not showing for phala testnet

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

Benchmark pallet-index

Write benchmark for pallet-index, currently, Weight is being hard-code as 195_000_000

Correctly interpret chain spec name

Now khala-staging without the explicit parachain id will be interpreted as khala. Instead we should report an error

Upgrade to polkadot-v1.5.0

Just in mind, when we upgrade to polkadot-v1.5.0 ( Phala-Network/phala-blockchain#1494 ) we must do migration for Khala & Phala

XCM execution failed on dest chain when given fee is less than the actually fee spend

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.

Migration storage in xtransfer

With PR59 merged, storage used to store resource id was removed, should clean the storage in migration script.

Fix bounty configuration

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,
    >;

Search results do not appear in the delegated page

In the delegate web page https://app.phala.network/delegate/, the following steps are performed, and the search results do not appear:

Click the Next button at the bottom
Search for pool id or something

Do not execute the first step, directly execute the second step, the result can be displayed

Add Acala kUSD to Khala

Remove the use of `Call::__Ignore` in the runtime base call filter

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

Update msg_routing.rs

Please update Khala's message routing:

https://github.com/Phala-Network/khala-parachain/blob/integrate-phala/runtime/khala/src/msg_routing.rs

to the latest one:

https://github.com/Phala-Network/phala-blockchain/blob/master/standalone/runtime/src/msg_routing.rs

Upgrade Polkadot v0.9.15

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

Can't sync parachain blocks with Docker image

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.

Primitive cast to u8 although underlying u128

Hey Phala team,

I found this

khala-parachain/pallets/subbridge/src/sygma_wrapper.rs

Line 65 in 83ee615

*dest_domain_id as u8,

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.

Crash

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

Error on start node with v0.1.16

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

node crashed

====================                                                                                                           
                                                                                                                               
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

Better bridge reserve account derivation mechanism

What is a bridge reserve account

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.

Limitation of the current mechanism

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.

Advantage of the current mechanism

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

Solution

It seems both advantages are critical, we need to propose a better derivation mechanism.

TODO

启动新版数据结构的khala-node，反复报错

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

Enable 3rd party token support by ChainBridge

Insufficient peers for Phala Parachain syncing -- need correct bootnodes?

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!

Integrate Sygma pallets into SubBridge

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 Wrapper

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.

Sygma Bridge Config

A draft config can be found here. Compared with simple example config in Sygma repo, following items should be highlighted:

AssetTransactor

As we mentioned above, we use SubBridge XTransferAdapter will be configured as asset transactor implementation.

ResourcePairs

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.

Authority management

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 fee

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.

phala-network / khala-parachain Goto Github PK

khala-parachain's Introduction

Khala Parachain

Build Note

For production build

For testnet build

Build runtime only

Special note for macOS

Development Note

Run a local testnet cluster

khala-parachain's People

Contributors

Stargazers

Watchers

Forkers

khala-parachain's Issues

What is a bridge reserve account

Limitation of the current mechanism

Advantage of the current mechanism

Solution

Integrate Sygma pallets into SubBridge

Sygma Wrapper

Sygma Bridge Config

Authority management

Bridge fee

Recommend Projects

Recommend Topics

Recommend Org