The Phala Network Blockchain, pRuntime and the bridge.

Phala Network

Last update: Dec 20, 2022

Related tags

Cryptocurrencies phala-blockchain

Overview

Phala Blockchain

Phala Network is a TEE-Blockchain hybrid architecture implementing Confidential Contract. This repo includes:

node/: the main blockchain built on Substrate
phost/: the bridge daemon to connect the blockchain and pRuntime

Overview

The blockchain is the central compoent of the system. It records commands (confidential contract invocation), serve as the pRuntime registray, runs the native token and on-chain governance modules.

pHost is a daemon program that connects the blockchain and the pRuntime. It passes the block data from the chain to pRuntime and passes pRuntime side effects back to the chain.

Related repos:

phala-docs: The central repo for documentations.
phala-pruntime: The cotract executor running inside TEE enclaves.
phala-polka-apps: The Web UI and SDK to interact with confidential contract. Based on polkadot.js.
plibra-grant-docker: The W3F M2 docker build with the blockchain, pHost and pRuntime.

File structure

.
├── LICENSE
├── README.md
├── node                      Blockchain node
├── pallets
│   └── phala                 Phala pallet
├── phost                     The bridge deamon "pHost"
├── pruntime                  pRuntime, the TEE kernel
├── ring                      Patched ring with wasm support
├── runtime                   Phala Substrate Runtime
└── scripts
    ├── console.sh            Helper script to build & run the blockchain
    └── init.sh

Docker bulid

Plase refer to plibra-grant-docker. It includes both the blockchain and pRuntime.

Native Build

Dependencies

Expand

Rust
```
curl https://sh.rustup.rs -sSf | sh
```
Substrate dependecies:
```
cd node
sh ./scripts/init.sh
```

LLVM 10

wget https://apt.llvm.org/llvm.sh
chmod +x llvm.sh
./llvm.sh 10

Build the blockchain and bridge

Make sure you have Rust and LLVM-10 installed.

Note for Mac users: you also need llvm and binutils from Homebrew or MacPort

cargo build --release

The build script enforces LLVM-9 or newer is used. LLVM-9 is needed because of the wasm port of rust crypto library, ring. We have to compile the C code into wasm while keeping the compatibility with the current rustc.

Run

Launch two local dev nodes Alice and Bob:
```
cd node
./scripts/console.sh start alice
./scripts/console.sh start bob
```
- The datadir is at $HOME/tmp/(alice|bob)
- Can be purged by ./scripts/console.sh purge
- The WebUI can connect to Alice at port 9944.
Run pHost (please start pRuntime first):
```
cd phost
./target/release/phost
```

Run with tmuxp

You can launch the full stack (semi-automatically) by:

tmuxp load ./scripts/tmuxp/three-nodes.yaml

Or a 4-node testnet-poc2 setup:

CHAIN=poc2 tmuxp load ./scripts/tmuxp/four-nodes.yaml

tmuxp is a convinient tool that can bring up a tmux session with the preconfigured commands running in panes. To play with tmuxp, it also need a tmux installed.

Comments

Khala Node get stuck at a block height and Pherry fails to connect to node

I have two nodes, both with same hardware (Intel NUC7PJYH2) and both of them suffer the same behaviour.

Both nodes get stuck at a block height (Khala network, KSM syncs well) and Pherry restarts because it fails to connect to node. It's very random, cos sometimes I restart the processes and all works fine during several hours (12h o 14h) but sometimes I need to restart processes 2, 3 or 4 times until I get all working fine. I have tried reinstalling both nodes from scratch, using databases synced from zero, with and without KSM snapshot and even copying databases from other nodes that are running fine.

NODE1: It has been running smoothly for months, but after a coolingdown period, begins to show the issue. NODE2: It hasn't been running ever, it's a brand new machine installed for the first time.

I have attached a file with logs (from processes start until the fail) and system info from both nodes. Please, don't hesitate to ask for any further info you need.

nodes_info_and_logs.tar.gz

opened by jimiflowers 54
phost] bridge() exited with result: Err(Rpc error: Networking or low-level protocol error: Couldn't find any IP address for this hostname

while try to start phala , got following error: phost] bridge() exited with result: Err(Rpc error: Networking or low-level protocol error: Couldn't find any IP address for this hostname others two node are in "running" status, any idea about this?

opened by fcmfcm01 26

(Unconfirmed) No reward while staying Mining

Examples:

worker: 0xc61a36e1dc2ec0af18dd6cbc8f591628d1cce5b7351edeb3bc25288a2260785b
fee account: 43DBxPRGwWTpNvG99w2JJDEMYGcQmpvP9EvvdRKk2jfMJBGA

worker: 0x3096272db93787abf6b52b60fe8cd79dcf0076544871182b18a6e3be0e53ad35
fee account: 45vgjavfYYzCh34Q8ebsWEUCMcVkYJ3bswXtNWoGe22RrZ6F

mining

opened by h4x3rotab 18

pruntime enclave crashes under Linux 5.15.0

Are there any known incompatibilities between the pruntime and the Linux kernel 5.15.0? We are currently seeing occasional failures under Ubuntu 22.04 using this kernel version and the in-tree SGX driver.

$ uname -a
Linux ubuntu2204-4 5.15.0-39-generic #42-Ubuntu SMP Thu Jun 9 23:42:32 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ ls -r /dev/*sgx*
/dev/sgx_vepc  /dev/sgx_provision  /dev/sgx_enclave

The issue presents itself as follows and seems to happen when dispatching blocks at varying heights, but always after "Taking checkpoint…":

[2022-06-26T11:18:47.798953Z INFO  rocket::server] POST /bin_api/dispatch_block application/octet-stream:

[2022-06-26T11:18:47.798977Z INFO  rocket::server] Matched: (dispatch_block) POST /bin_api/dispatch_block

[2022-06-26T11:18:47.803682Z INFO  phactory::prpc_service] dispatch_block from=Some(877811) to=Some(877811)

[2022-06-26T11:18:47.803730Z INFO  phactory::prpc_service] Dispatching block: 877811

[2022-06-26T11:18:47.806955Z INFO  phactory::prpc_service] State synced

[2022-06-26T11:18:47.807168Z INFO  phactory] Taking checkpoint...

[2022-06-26T11:18:48.138833Z ERROR app] [-] ECALL Enclave Failed SGX_ERROR_ENCLAVE_CRASHED!

[2022-06-26T11:18:48.138863Z INFO  rocket::server] Outcome: Success

[2022-06-26T11:18:48.138888Z INFO  rocket::server] Response succeeded.

thread 'thread 'thread 'thread 'thread 'thread 'thread 'thread 'thread 'thread 'thread 'thread 'bench-6bench-0bench-13bench-3bench-15bench-5bench-4' panicked at '' panicked at 'bench-8' panicked at '' panicked at 'bench-14' panicked at 'Run benchmark 5 failedRun benchmark 4 failedRun benchmark 8 failed', bench-10bench-7' panicked at '' panicked at 'Run benchmark 10 failed' panicked at '', Run benchmark 3 failed' panicked at 'src/main.rsRun benchmark 6 failedRun benchmark 13 failed' panicked at '', ', ', src/main.rs' panicked at 'src/main.rsRun benchmark 0 failed:', 708', Run benchmark 15 failedsrc/main.rs', ::708', 708Run benchmark 14 failedsrc/main.rs', src/main.rssrc/main.rssrc/main.rs::708Run benchmark 7 failed708src/main.rs::src/main.rs25:

25::25:708::708:25', :25:

708

:708::2525



src/main.rsstack backtrace:

:708708:

2525



:25

25



thread 'bench-1' panicked at 'Run benchmark 1 failed', src/main.rs:708:25

thread 'bench-11' panicked at 'Run benchmark 11 failed', src/main.rs:708:25

thread 'thread 'bench-9bench-2' panicked at '' panicked at 'Run benchmark 9 failedRun benchmark 2 failed', ', src/main.rssrc/main.rs::708708:bench-1225' panicked at '

Run benchmark 12 failed:', 25

src/main.rs:708:25

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

stack backtrace:

   0: rust_begin_unwind

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/std/src/panicking.rs:498:5

   1: core::panicking::panic_fmt

             at /rustc/82af160c2cb9c349a0373cba98d8ad7f911f0d34/library/core/src/panicking.rs:106:14

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[2022-06-26T11:18:48.543566Z INFO  rocket::server] GET /get_info:

[2022-06-26T11:18:48.543626Z INFO  rocket::server] Matched: (get_info) GET /get_info

[2022-06-26T11:18:48.547054Z ERROR app] [-] ECALL Enclave Failed SGX_ERROR_ENCLAVE_CRASHED!

[2022-06-26T11:18:48.547103Z INFO  rocket::server] Outcome: Success

[2022-06-26T11:18:48.547161Z INFO  rocket::server] Response succeeded.

The same pool is also serviced by machines running 20.04 (kernel 5.4.0 with Intel's out-of-tree DCAP driver), which do not experience the this problem.

opened by ngrewe 15

Add worker after removing reset CD state to Ready
Tasks

[x] Fix #500 by checking miner CD state before starting mining

This fix stops bleeding

[x] Check all the storage insertion. Make sure there's no unexpected overwriting

[x] Reconcile the missing releasing stake in the past

Whenever a Cooling Down miner is removed by this bug and got started again, it's Stakes record will be wiped. However the wiped stake is supposed to be reclaimed in the future. As a result, the wiped stake will be locked in the pool forever (in the end, locked in the contributors' locked balance, but also reflected in the total_stake and releasing_stake)

To reconcile, we need to find out the affected pools and the amount and trigger on_reclaim by a backfill. We can scan all the remove_worker and start_worker pairs for the same worker in each pool. Every such pair freezes some stakes. (We should only consider the successful extrinsics!)

We add a function backfill_issue500_reclaim(Vec<(miner, stake, slash)>) that can be called only with the signature of half council members. Note that we cannot invoke on_claim directly because we don't want to remove SubAccountAssignment as addressed in #518

[x] Backfill code

[x] Scripts to collect data and produce the reconcile call

[x] Run

[ ] Retire

[x] Examine if other storage migration is required

Example: https://khala.subscan.io/account/44Z4vgVTtAkmA7HuqRqojehMawAsnfM8eEDQAcbw6mSXbBEq
chain P0 mining
opened by h4x3rotab 15
Fast block speed in dev network
Now it's fixed at 6s per-block. However we want a much faster block speed in development to save time. This is especially useful for e2e test, which can easily takes a few minutes to finish.

Substrate offers "Instant Seal" consensus engine, which can produce block every time when it receives a transaction instantly. However it doesn't meet our needs. We heavily depends on GRANDPA consensus and block justification to bridge the blockchain and pRuntime, but instant seal consensus engine doesn't have block justification at all. In theory we can open a hole in pRuntime to short-circuit the light validation logic all together, but it's still an error prone code change.

So an easier way is to just make the consensus engine produce blocks faster (<1s) for dev blockchain.

For Bounty Hunters

Deliverable:

Fast block time while not breaking the existing system (should pass all unit tests & e2e test (under e2e/))

The block time should be adjustable via cli option, and we should figure out the best value for it

Document the changes

Resources

To build the project, follow the wiki tutorial environment section. The wiki is out-of-date, but it generally works expect we use rust nightly-2021-05-11 and llvm-10.

To run the e2e test, enter e2e/ and run yarn && yarn test. You should have phala-node, pherry (phost in the tutorial), and pruntime already compiled before running the e2e test.

enhancement good first issue chain bounty-m
opened by h4x3rotab 15
phost stop cause by os error 104
[2021-06-22T06:55:07Z INFO phost::chain_client] - Stats Online Workers: 20 [2021-06-22T06:55:07Z INFO phost::chain_client] - Stats Compute Workers: 5 [2021-06-22T06:55:07Z INFO phost::pruntime_client] Response: 200 OK [2021-06-22T06:55:07Z INFO phost::pruntime_client] Response: 200 OK [2021-06-22T06:55:07Z INFO phost] sending a batch of 222 headers (last: 210900, change: None) [2021-06-22T06:55:07Z INFO phost] bridge() exited with result: Err(connection error: Connection reset by peer (os error 104)

Caused by: Connection reset by peer (os error 104))
opened by maybeTomorrow 14
Upgrade ChainBridge and BridgeTransfer pallets to FRAME v2
FRAMEv2: https://substrate.dev/docs/en/knowledgebase/runtime/pallets#frame-v2

Substrate has upgraded its FRAME (module framework) to v2 in the past year. However we still have two pallets written in v1 syntax. We should upgrade them to v2.

For Bounty Hunters

Deliverables

A PR to upgrade pallets/{birdge,bridge_transfer} to FRAMEv2

Pass all the unit tests. (Bonus: increase the test coverage as much as possible!)

Resources

To build the project, install llvm-10, clang-10 or above. Then run cargo build --release. We use rust nightly-2021-05-11.

To get the unit test coverage, run ./scripts/coverage-pallets.sh

good first issue help wanted bounty-m bounty-paid
opened by h4x3rotab 11
ERROR：SGX_ERROR_UNRECOGNIZED_PLATFORM

Hi guys,

I found the error below from pRuntime logs, when i started pHost via Phala-Network/solo-mining-scripts:

[2021-07-01T06:57:16Z INFO rocket::rocket] POST /get_info application/json: [2021-07-01T06:57:16Z INFO rocket::rocket] Matched: POST /get_info application/json (get_info) [2021-07-01T06:57:16Z INFO rocket::rocket] Outcome: Success [2021-07-01T06:57:16Z INFO rocket::rocket] Response succeeded. [2021-07-01T06:57:16Z INFO rocket::rocket] POST /init_runtime application/json: [2021-07-01T06:57:16Z INFO rocket::rocket] Matched: POST /init_runtime application/json (init_runtime) [2021-07-01T06:57:16Z INFO enclaveapp] Identity pubkey: "02a422498940155d4e67db253f89ed660c100d013b9c670a2b75be762c9fa87b73" [2021-07-01T06:57:16Z INFO enclaveapp] ECDH pubkey: "04589b893b7f4e5da619336f4593904e030f1e35f71e579ea3693db1d13d887c81159412a381c54c9a4cf1830c1d6ad20dc16dc6dad4d7db3faa4a894a35931fe5" [2021-07-01T06:57:16Z INFO enclaveapp] CPU cores: 2 [2021-07-01T06:57:16Z INFO enclaveapp] CPU Support AVX2 [2021-07-01T06:57:16Z INFO enclaveapp] CPU Support AVX512 [2021-07-01T06:57:16Z INFO enclaveapp] Encoded runtime info [2021-07-01T06:57:16Z INFO enclaveapp] "01000000bbacc4283cedbe2094ef28cd289433eb02a422498940155d4e67db253f89ed660c100d013b9c670a2b75be762c9fa87b73080200000003000000" [2021-07-01T06:57:16Z INFO app] Entering ocall_sgx_init_quote aesm_service[16]: [ADMIN]EPID Provisioning initiated aesm_service[16]: The Request ID is a4db8c8dd3fd407bb89a910ec98c4a81 aesm_service[16]: The Request ID is 4e2d3424395042d18c7f849df5534199 aesm_service[16]: [ADMIN]EPID Provisioning protocol error reported by Backend (6) aesm_service[16]: [ADMIN]EPID Provisioning failed [2021-07-01T06:57:19Z INFO enclaveapp] eg = [0, 0, 0, 0] [2021-07-01T06:57:19Z ERROR enclaveapp] Error in create_attestation_report: SGX_ERROR_UNRECOGNIZED_PLATFORM [2021-07-01T06:57:19Z INFO enclaveapp] {"payload":"{"message":"Error while connecting to IAS"}","signature":"8d79835a41c53bac920941f298f0fa16184fd3d219086a3d21608f9f922192ac1eaaf5660788564d0b722596bcb3c221887da6ad4f0de9d8b41ebcad47874b71","status":"error"} [2021-07-01T06:57:19Z INFO rocket::rocket] Outcome: Success [2021-07-01T06:57:19Z INFO rocket::rocket] Response succeeded.

And i found the details of SGX_ERROR_UNRECOGNIZED_PLATFORM from the sgx_error.h:

SGX_ERROR_UNRECOGNIZED_PLATFORM = SGX_MK_ERROR(0x4012), /* EPID Provisioning failed due to platform not recognized by backend server*/

And this is the output of phala sgx-test:

Docker version 20.10.7, build f0df350 Sleep 6s aesm_service[15]: The server sock is 0x5588aaf9d130 Detecting SGX, this may take a minute... aesm_service[15]: Malformed request received (May be forged for attack) aesm_service[15]: InKernel LE loaded aesm_service[15]: InKernel LE loaded aesm_service[15]: InKernel LE loaded aesm_service[15]: InKernel LE loaded aesm_service[15]: InKernel LE loaded aesm_service[15]: InKernel LE loaded aesm_service[15]: InKernel LE loaded aesm_service[15]: InKernel LE loaded ？ SGX instruction set ✔ CPU support ✔ CPU configuration ✔ Enclave attributes ？ Enclave Page Cache SGX features ✔ SGX2 ✔ EXINFO ✘ ENCLV ✘ OVERSUB ✔ KSS
Total EPC size: 0.0MiB ✔ Flexible launch control ✔ CPU support ？ CPU configuration ✔ Able to launch production mode enclave ✔ SGX system software ✔ SGX kernel device (/dev/sgx/enclave) ✔ libsgx_enclave_common ✔ AESM service ✔ Able to launch enclaves ✔ Debug mode ✔ Production mode ✔ Production mode (Intel whitelisted)

🕮 SGX instruction set > Enclave Page Cache Your hardware supports SGX, but the Enclave Page Cache (EPC) is misconfigured. This could indicate a CPU or hypervisor bug.

debug: CPUID.(EAX=12H,ECX=2H):ECX[3:0] = Unknown

More information: https://edp.fortanix.com/docs/installation/help/#invalid-cpuid Generated machine id: [187, 172, 196, 40, 60, 237, 190, 32, 148, 239, 40, 205, 40, 148, 51, 235]

CPU Cores: 2

Encoded runtime info: [1, 0, 0, 0, 187, 172, 196, 40, 60, 237, 190, 32, 148, 239, 40, 205, 40, 148, 51, 235, 3, 184, 68, 6, 185, 224, 56, 175, 40, 191, 114, 176, 165, 187, 44, 222, 2, 169, 209, 76, 141, 167, 59, 27, 234, 61, 38, 88, 90, 108, 4, 121, 199, 8, 2, 0, 0, 0, 1, 0, 0, 0] Testing RA... aesm_service[15]: [ADMIN]EPID Provisioning initiated aesm_service[15]: The Request ID is 565d229e05fa4a63a2e2fbc77aa48f98 aesm_service[15]: The Request ID is f8b3179c130745d982ccdbed44c30c0c aesm_service[15]: [ADMIN]EPID Provisioning protocol error reported by Backend (6) aesm_service[15]: [ADMIN]EPID Provisioning failed thread '' panicked at 'error while doing remote attestation: SGX_ERROR_UNRECOGNIZED_PLATFORM', src/lib.rs:448:132 note: Call backtrace::enable_backtrace with 'PrintFormat::Short/Full' for a backtrace. fatal runtime error: failed to initiate panic, error 5 ./start_sgx_detect.sh: line 20: 41 Illegal instruction (core dumped) ./app

It seems that my machine support sgx except EPID, is there any way to fix that?

opened by wcw84 10
Use anyhow for error handling in pRuntime and pHost
Fixes #174.

All three core blockchain applications (phala-node, phost and pruntime) builds successfully, but while running phost, the following error message results:

Connected to substrate at: ws://localhost:9944 bridge() exited with result: Err(SubxtRpcError(Metadata(ModuleNotFound("Phala"))))

I don't understand how this is possible when I have phala-node running in the background, and I'm pretty sure it does have the Phala module.
opened by KiChjang 10

Failed to build caused by 'phactory-api'

Error message run 'cargo build --release' in root directory.

error: failed to run custom build command for `phactory-api v0.1.0 (/Users/xxx/phala-blockchain/crates/phactory/api)`

Caused by:
  process didn't exit successfully: `/Users/xxx/phala-blockchain/target/release/build/phactory-api-a284ecbac0d78291/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "protoc failed: Could not make proto path relative: pruntime_rpc.proto: No such file or directory\n" }', crates/phactory/api/build.rs:48:10
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/c2804e6ec2c29a5c7368600ea173b890e2655c3d/library/std/src/panicking.rs:584:5
     1: core::panicking::panic_fmt
               at /rustc/c2804e6ec2c29a5c7368600ea173b890e2655c3d/library/core/src/panicking.rs:142:14
     2: core::result::unwrap_failed
               at /rustc/c2804e6ec2c29a5c7368600ea173b890e2655c3d/library/core/src/result.rs:1785:5
     3: core::result::Result<T,E>::unwrap
     4: build_script_build::main
     5: core::ops::function::FnOnce::call_once

Error message run 'cargo test' in '/phala-blockchain/crates/phactory'

error: failed to run custom build command for `phactory-api v0.1.0 (/Users/xxx/phala-blockchain/crates/phactory/api)`

Caused by:
  process didn't exit successfully: `/Users/xxx/phala-blockchain/target/debug/build/phactory-api-cd77a965d7823081/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "protoc failed: Could not make proto path relative: pruntime_rpc.proto: No such file or directory\n" }', crates/phactory/api/build.rs:48:10
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/c2804e6ec2c29a5c7368600ea173b890e2655c3d/library/std/src/panicking.rs:584:5
     1: core::panicking::panic_fmt
               at /rustc/c2804e6ec2c29a5c7368600ea173b890e2655c3d/library/core/src/panicking.rs:142:14
     2: core::result::unwrap_failed
               at /rustc/c2804e6ec2c29a5c7368600ea173b890e2655c3d/library/core/src/result.rs:1785:5
     3: core::result::Result<T,E>::unwrap
               at /rustc/c2804e6ec2c29a5c7368600ea173b890e2655c3d/library/core/src/result.rs:1107:23
     4: build_script_build::main
               at ./build.rs:46:5
     5: core::ops::function::FnOnce::call_once
               at /rustc/c2804e6ec2c29a5c7368600ea173b890e2655c3d/library/core/src/ops/function.rs:248:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

System information

macOS Monterey
version 12.6(21G115)
chip Apple M2

Dependencies

LLVM

llvm-config --version
15.0.0

Submodule

git submodule update --init
sh ./scripts/init.sh

*** Initializing WASM build environment
info: syncing channel updates for 'nightly-aarch64-apple-darwin'

  nightly-aarch64-apple-darwin unchanged - rustc 1.66.0-nightly (f5193a9fc 2022-09-25)

info: checking for self-updates
info: syncing channel updates for 'stable-aarch64-apple-darwin'

  stable-aarch64-apple-darwin unchanged - rustc 1.64.0 (a55dd71d5 2022-09-19)

info: checking for self-updates
info: component 'rust-std' for target 'wasm32-unknown-unknown' is up to date

Rust

rustup update
info: syncing channel updates for 'stable-aarch64-apple-darwin'
info: syncing channel updates for 'nightly-aarch64-apple-darwin'
info: checking for self-updates

   stable-aarch64-apple-darwin unchanged - rustc 1.64.0 (a55dd71d5 2022-09-19)
  nightly-aarch64-apple-darwin unchanged - rustc 1.66.0-nightly (f5193a9fc 2022-09-25)

info: cleaning up downloads & tmp directories

opened by pencoa 9

Bump tokio from 1.20.1 to 1.24.1 in /standalone/pruntime
Bumps tokio from 1.20.1 to 1.24.1.

Release notes

Sourced from tokio's releases.

Tokio v1.24.1

This release fixes a compilation failure on targets without AtomicU64 when using rustc older than 1.63. (#5356)

#5356: tokio-rs/tokio#5356

Tokio v1.24.0

The highlight of this release is the reduction of lock contention for all I/O operations (#5300). We have received reports of up to a 20% improvement in CPU utilization and increased throughput for real-world I/O heavy applications.

Fixed

rt: improve native AtomicU64 support detection (#5284)

Added

rt: add configuration option for max number of I/O events polled from the OS per tick (#5186)

rt: add an environment variable for configuring the default number of worker threads per runtime instance (#4250)

Changed

sync: reduce MPSC channel stack usage (#5294)

io: reduce lock contention in I/O operations (#5300)

fs: speed up read_dir() by chunking operations (#5309)

rt: use internal ThreadId implementation (#5329)

test: don't auto-advance time when a spawn_blocking task is running (#5115)

#5186: tokio-rs/tokio#5186 #5294: tokio-rs/tokio#5294 #5284: tokio-rs/tokio#5284 #4250: tokio-rs/tokio#4250 #5300: tokio-rs/tokio#5300 #5329: tokio-rs/tokio#5329 #5115: tokio-rs/tokio#5115 #5309: tokio-rs/tokio#5309

Tokio v1.23.1

This release forward ports changes from 1.18.4.

Fixed

net: fix Windows named pipe server builder to maintain option when toggling pipe mode (#5336).

#5336: tokio-rs/tokio#5336

Tokio v1.23.0

Fixed

net: fix Windows named pipe connect (#5208)

io: support vectored writes for ChildStdin (#5216)

io: fix async fn ready() false positive for OS-specific events (#5231)

... (truncated)

Commits

31c7e82 chore: prepare Tokio v1.24.1 (#5357)

8d8db27 tokio: add load and compare_exchange_weak to loom StaticAtomicU64 (#5356)

dfe252d chore: prepare Tokio v1.24.0 release (#5353)

21b233f test: bump version of async-stream (#5347)

7299304 Merge branch 'tokio-1.23.x' into master

1a997ff chore: prepare Tokio v1.23.1 release

a8fe333 Merge branch 'tokio-1.20.x' into tokio-1.23.x

ba81945 chore: prepare Tokio 1.20.3 release

763bdc9 ci: run WASI tasks using latest Rust

9f98535 Merge remote-tracking branch 'origin/tokio-1.18.x' into fix-named-pipes-1.20

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot use these labels will set the current labels as the default for future PRs for this repo and language

@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language

@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language

@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

dependencies rust
opened by dependabot[bot] 0
Bump tokio from 1.20.0 to 1.20.3
Bumps tokio from 1.20.0 to 1.20.3.

Release notes

Sourced from tokio's releases.

Tokio v1.20.2

1.20.2 (September 27, 2022)

This release removes the dependency on the once_cell crate to restore the MSRV of the 1.20.x LTS release. (#5048)

#5048: tokio-rs/tokio#5048

Tokio v1.20.1

1.20.1 (July 25, 2022)

Fixed

chore: fix version detection in build script (#4860)

#4860: tokio-rs/tokio#4860

Commits

ba81945 chore: prepare Tokio 1.20.3 release

763bdc9 ci: run WASI tasks using latest Rust

9f98535 Merge remote-tracking branch 'origin/tokio-1.18.x' into fix-named-pipes-1.20

9241c3e chore: prepare Tokio v1.18.4 release

699573d net: fix named pipes server configuration builder

3d95a46 chore: prepare Tokio v1.20.2 (#5055)

2063d66 Merge 'tokio-1.18.3' into 'tokio-1.20.x' (#5054)

5c76d07 chore: prepare Tokio v1.18.3 (#5051)

05e6614 chore: don't use once_cell for 1.18.x LTS release (#5048)

c0746b6 chore: prepare Tokio v1.20.1 (#4861)

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot use these labels will set the current labels as the default for future PRs for this repo and language

@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language

@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language

@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

dependencies rust
opened by dependabot[bot] 0
Some update for subrpc
[x] Expose ss58, so that we can derive addresses in other modules

[x] Delete unused error definitions, case many of them will never be used in subrpc

[x] Introduce ExtraParams (adding nonce) when creating transactions, this would be very helpful when we want to construct a transaction with a given nonce
opened by tolak 0
[Feature request] Auth and HTTPS to prevent misuse on peer discovery affecting data provider and monitor
Peer discovery on 3000 can be exploitable if a firewall not properly configured.

Tested on a test machine:

nmap -p3000 -Pn ip5b135217.dynamic.kabel-deutschland.de Starting Nmap 7.80 ( https://nmap.org ) at 2023-01-06 12:08 CET Nmap scan report for ip5b135217.dynamic.kabel-deutschland.de (91.61.13.22) Host is up (0.0028s latency).

PORT STATE SERVICE 3000/tcp open ppp Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

This exposes data provider's peerId in the wild.

Is it possible to implement SSL encryption at least locally on the docker container and maybe land on a login prompt on the browser rather than directly on the peer discovery?
opened by aamdevsecops 2
Support assign nonce when construct tranaction

In the current implementation, nonce was fetched from the blockchain every time we construct transaction data. A more practical way is making is optional, only when the user doesn't give nonce, we fetch it from the blockchain.

opened by tolak 1