This PR integrate wapod workers to phala chain.
Only the chain runtime changes is included in this PR. The corresponding out-of-tree code of wapod-pherry, wapod-types and the benchmark app can be reviewed here: https://github.com/Phala-Network/wapo/pull/1
Concepts
Wapod
The program running in TEE as a wasm host runtime, it can execute wasm programs by calling it's RPC. It is an implementation of Worker v3.
Worker session
Each time a worker restarts, it will get a new session with associate metrics data reset. A session_id is the unique id identify a session wihch is generated as session_id = hash(rand_nonce, previous_metrics_nonce), where rand_nonce is a random bytes32 generated on-the-fly and previous_metrics_nonce is the nonce in last time a metrics of the worker was reported if any, leave empty if no metrics for the worker was reported yet.
App
The wasm program that be deployed in the worker.
App session
When an app is deployed in a worker, a session is created and a random bytes32 is is generated as session id. If the app is removed from the worker, the session is destroyed and a redeployment will get a new session (id).
App manifest
A description of how to launch an App, including wasm code hash, arguments, env vars, required resources .etc.
App address
Unique id of an App, calulated from hash of App manifest.
Metrics
The worker meters the resource usage, (such as CPU, IO usage) of each App, and output signed metrics for them.
Ticket
A request of app deployment put on-chain. Including the app manifest and the payment info for deployment.
Benchmark app
A special App registered on chain that used to benchmark workers. Wapod-pherry deploys it to the worker and get benchmark score from it then submit to the chain.
HeartbeatV3
Similar to the heartbeat of pruntime v2 but is simulated on-chain when benchmark scores are reported.
The computaion workflow
Worker registeration
Worker v3 share the same chain API as pruntime v2 to register workers, where the remote attestation is done.
Beside the traditional registration, the following extra information is required to be submitted on chain for a worker:
Update worker session. Wapod-pherry initialized the worker with the metrics_none fetched on chain as input. and submit the new session info to the chain.
Set up resource price or the worker. This is an only-once operation for a worker.
Ticket based - market mode
Steps
Register the worker on chain.
Choose workers want to deploy an app to.
Create a worker list and add the workers to the lise or find an exsisting list contains them (A worker list is a collection of workers with the same price).
Create a ticket with some deposit, app manifest and the worker list as arguments.
Pherry will pick up the ticket and deploy the app to corresponding workers.
Related pallet calls: worker_list_create, worker_list_add_workers, ticket_create, ticket_close, ticket_settle.
Benchmark based - v2 compatible mode
Steps
Register the worker on chain.
Build the benchmark app
Set the benchmark app on chain.
Pherry will pick up the benchmark app and deploy it to workers, and report the bench score. The first report will be record as the V2 p_init.
Go to the traditional stakepool v2 operations over the worker.
When a bench score is submitted on chain, it will be converted to a HeartbeatV3 message to the GK if the worker is added to a stakepool.
Related pallet calls: benchmark_app_add, benchmark_app_set_recommended, benchmark_app_set, benchmark_score_submit, benchmark_app_remove.
Changes in GK
Static V switch
A mq message SetStaticV added to switch the GK to static v mode, in which mode the v never increase.
HeartbeatV3
When handling the new added HeartbeatV3 in GK, it is no longer required to be 1:1 map from hearbeat to challenge, any on heartbeat will flush the waiting heartbeat queue.
Introduction
This PR integrate wapod workers to phala chain. Only the chain runtime changes is included in this PR. The corresponding out-of-tree code of
wapod-pherry
,wapod-types
and thebenchmark
app can be reviewed here: https://github.com/Phala-Network/wapo/pull/1Concepts
session_id
is the unique id identify a session wihch is generated assession_id = hash(rand_nonce, previous_metrics_nonce)
, where rand_nonce is a random bytes32 generated on-the-fly andprevious_metrics_nonce
is the nonce in last time a metrics of the worker was reported if any, leave empty if no metrics for the worker was reported yet.session id
. If the app is removed from the worker, the session is destroyed and a redeployment will get a new session (id).wasm code hash
,arguments
,env vars
,required resources
.etc.The computaion workflow
Worker registeration
Worker v3 share the same chain API as pruntime v2 to register workers, where the remote attestation is done.
Beside the traditional registration, the following extra information is required to be submitted on chain for a worker:
metrics_none
fetched on chain as input. and submit the new session info to the chain.Ticket based - market mode
Steps
Related pallet calls:
worker_list_create
,worker_list_add_workers
,ticket_create
,ticket_close
,ticket_settle
.Benchmark based - v2 compatible mode
Steps
p_init
.HeartbeatV3
message to the GK if the worker is added to a stakepool.Related pallet calls:
benchmark_app_add
,benchmark_app_set_recommended
,benchmark_app_set
,benchmark_score_submit
,benchmark_app_remove
.Changes in GK
Static V switch
A mq message
SetStaticV
added to switch the GK to static v mode, in which mode the v never increase.HeartbeatV3
When handling the new added
HeartbeatV3
in GK, it is no longer required to be 1:1 map from hearbeat to challenge, any on heartbeat will flush the waiting heartbeat queue.