Integrate stakepool with wapod workers

[kvinwang]

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 the benchmark app can be reviewed here: Phala-Network/wapo#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.