The Phala Network Blockchain, pRuntime and the bridge.

Phala Network

Last update: Jan 6, 2023

Related tags

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

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

Scripts for storage debugging.

With these scripts, we addressed the resource leak in RmrkCore::Properties this morning.

0x5bef2c5471aa9e955551dc810f5abb 262971099
0xb71c310d8c830d345ee1c1b84566a8 14408022
0x0d746931e7a6bfd47fbcccfd71984a 8226648
0x5e8a19e3cd1b7c148b33880c479c02 7515862
0x75e3ed3f59e45643ed1149ad80929c 4365694
0x26aa394eea5630e07c48ae0c9558ce 3789815
0x2f039a6a7f13e94b9545257e54062a 3390574
0x00f8eafbad3b4a32114491ad7e1249 2171795
0x3a636f6465 1247567
0x66b8232d707a1e10cc0cc5a75b738a 867102
0xfcf02af62786f6514fecf014aae642 669662
0x1466de7f00add77dbab4df042b8c4a 508542
0x43cdcd39d5edb1d16e24fa028edde0 482267
0x682a59d51ab9e48a8c8cc418ff9708 389706
0x5f27b51b5ec208ee9cb25b55d87282 271869
0xc2261276cc9d1f8598ea4b6a74b15c 209702
0xf2794c22e353e9a839f12faab03a91 47571
0x2aeddc77fe58c98d50bd37f1b90840 47489
0x04d3f224a1307398074171146ffc41 37499
0xe2e62dd81c48a88f73b6f6463555fd 25537
0x9708ddcf89326bf4f4428dd135287d 24193
0x1809d78346727a0ef58c0fa03bafa3 16017
0x45323df7cc47150b3930e2666b0aa3 13158
0xcec5070d609dd3497f72bde07fc96b 2998
0xe38f185207498abb5c213d0fb059b3 2821
0xbd2a529379475088d3e29a918cd478 2666
0xf7860e52b3d3660de35c808455ec48 2424
0x15464cac3378d46f113cd5b7a4d71c 1282
0x2c5de123c468aef7f3ac2ab3a76f87 1059
0x7474449cca95dc5d0c00e71735a6d1 671
0x42cbe4fedfc209225dad817c6d0382 511

RmrkCore::Properties 241037438
RmrkCore::Lock 18881679
RmrkCore::Nfts 2682360
RmrkCore::Collections 369536

opened by kvinwang 0

pRuntime v0.2.5 fails to restart with kernel 5.13.0

With the new pRuntime version v0.2.5 we're observing some weird behaviour related to ~~re~~starting the container on Ubuntu 20.04 machines with the HWE kernel (5.13.0) installed. ~~It runs fine when starting it initially, but once you've started it once, subsequent restarts~~ The container terminates with this error message:

Starting pRuntime with extra opts '--cores=6'
PRuntime will running in hardware mode
pRuntime starting... It may take up to 2 minutes.
Waiting for device. Sleep 6s
aesm_service: warning: Turn to daemon. Use "--no-daemon" option to execute in foreground.
[get_driver_type /home/sgx/jenkins/ubuntuServer2004-release-build-trunk-218/build_target/PROD/label/Builder-UbuntuSrv20/label_exp/ubuntu64/linux-trunk-opensource/psw/urts/linux/edmm_utility.cpp:111] Failed to open Intel SGX device.
thread 'main' panicked at '[-] Init Enclave Failed SGX_ERROR_NO_DEVICE!', src/main.rs:637:13
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
   2: app::main::{{closure}}
   3: tokio::park::thread::CachedParkThread::block_on
   4: tokio::runtime::thread_pool::ThreadPool::block_on
   5: tokio::runtime::Runtime::block_on
   6: rocket::async_main
   7: app::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

SGX_ERROR_NO_DEVICE seems inacurate in as far as the /dev/sgx_* devices are still present on the host. Rebooting the machine will fix this issue and allow the pRuntime to start again. Restarts work normally on the same machine with the older version 22051201, and also with v0.2.5 on Ubuntu 20.04 machines that do not have the HWE kernel installed (5.8.0) and hence use Intel's out-of-tree SGX driver (v1.41).

opened by ngrewe 5

Queue support in offchain rollup

In the rollup implementation in the past, the queue is implemented on top of the basic rollup in an ad-hoc way. It's also implemented differently in the initial EVM version and the kv-session based version. A well-designed queue is important to make it really useful.

Let's make a built-in queue to all the offchain rollup setup. We can first design a API on the pallet side, and then adapt it in Phat Contract and the EVM contracts.
library

opened by h4x3rotab 0
Make subrpc as a standard crate

Now there are two version subrpc. The original one made by @tenheadedlion is located here. The revised version by me is located here with some new added features.

Considering subrpc is toward production ready level (tested with our offchain rollup demo and workshop), I think it's good to move the second version to the official pink series library. Ideally the developers can use pink-subprc from [crates.io].
library

opened by h4x3rotab 0
pink: Towards ink-4.0-beta
This PR is attempting to update the pink SDK and drivers to use ink-4.0-beta. There are two major unresolved issues so far:

ink-4.0 requires a stable version of rustc, but pruntime does not compile with stable Rust. Ideally, pruntime would be able to compile with rustc-1.66, which is scheduled to be released on December 15th.

ink-4.0 has changed the way it outputs messages from R to Result<R, LangError>, which cannot yet be correctly decoded by the js-frontend.
opened by kvinwang 0