⁉️FAQ
Last updated
Last updated
COPYRIGHT © 2024 PHALA.LTD ALL RIGHTS RESERVED. May Phala be with you!
Currently the Phat Contract Console does not support specifying arguments during contract instantiation
Workaround: you can implement a config(&mut self, argument0, ...) function and set the contract state with transactions after the instantiation
The Phat UI checks the contract’s validity before uploading it to the cluster. However, sometimes the contract output by cargo-contract may be invalid. We’ve listed common errors and solutions below:
or sometimes “use of floating point type in locals is forbidden”
This error occurs when the contract or its dependencies use floating point operations not allowed by the ink runtime.
To find the source of the problem, try recompiling the contract with --keep-debug-symbols, then convert the wasm file to wat using wasm2wat my_contract.wasm > my_contract.wat, and search for f32 or f64 in my_contract.wat to find the function using these instructions.
If the floating point operations are necessary, see the section “How to do floating point calculations” for more information.
Upgrade cargo-contract to version 1.5.2 or higher once this PR has been merged.
A common case that introduces FP instructions is parsing JSON in a contract. Either serde or serde_json are designed to be able to handle FP numbers. In theory, if you don’t use it to deal with FP data, the compiler and wasm-opt should be able to optimize the FP instructions away for many cases. However, in practice, if you use serde_json, it always emits FP instructions in the final output wasm file.
If your JSON document contains FP numbers, you can skip this section and go to “How to do floating point calculations” for solutions. If your JSON document does not contain FP numbers, here are some suggestions for removing the instructions:
Use the crate pink-json instead of serde_json.
Don’t deserialize to json::Value or serde::Value. These are dynamically typed values and make it impossible for the compiler to optimize the code paths that contain FP ops. Instead, mark concrete types with #[derive(Deserialize)] and deserialize to them directly.
If using pink-web3 and loading Contract from its JSON ABI, you may encounter FP problems in a function like _ZN5serde9__private2de7content7Content10unexpected17h5ce9c505c30bc609E from serde. To fix this, you can patch serde as shown below.
After checking the version, it shows:
Solution: upgrade to the latest cargo contract. Reference:
There are two types of method calling:
off-chain query: there is not cost for caller, but someone needs to stake to that contract in advance so it can get the CPU time to process your queries
on-chain transaction: when you send the tx, some transaction fee will be charged directly; also for your tx to be finally executed in our worker, some in-cluster balance will be charged as real gas fee
Contract state is not stored on-chain, it’s volatile in SGX workers’ memory. So to get access to the contract state, there must be at least one active worker to which that contract is deployed
Contracts are deployed to a cluster, and then all the workers in that cluster - We have enabled dynamic cluster: to add workers to a cluster. This is achievable since the root key is in GKs, so they can derive the cluster key any time and share to incoming workers
All the transactions are stored on-chain, including
The transaction to upload the code to workers, such transaction is deliberately kept public so users can easily examine the contract code
The (encrypted) transaction to instantiate code, this contains the constructor function to call and the arguments
All the (encrypted) transactions that update the contract states
No. The stake to a contract does not change with contract calls. You can always have the full refund. But if other contracts get more stake then your computing power percentage will decrease correspondingly. This only applies to the public cluster. If we create dedicated cluster for our partners then any stake can take all the CPU time
Manually pulling deb package and installing fixes issue. Reference from askubuntu.
Note: At the time of writing this, everything below except the Demand L1 tokenomic is up and running
Supply: The contributors (miners in the past) receive reward by keeping serving the network. It follows a model similar to other PoS like Filecoin, which allows the system to punish the bad behavior. The liveness of the worker is checked by on-chain random heartbeat.
Demand L1: The developer can stake to get a percentage of the ownership of the compute resource. Once they stake, they can request to "hire" the workers they prefer to form a cluster, and get the worker assigned automatically by the system. This part is described in the tokenomic paper, but not fully implemented yet.
Demand L2: Once the developer hired some workers in a cluster, they can use the resources. If it's fully used by a single developer, no further tokenomic is required. But if someone wants to create a public cluster, just like the one we launched earlier this year, we need another tokenomic to distribute the resources to individual permissionlessly. As Joshua described, now it's a "stake to compute" model. You can stake some % of the token, and get access to the corresponding portion of the compute resources within the cluster.
Resource Accounting: The last piece of the map is to account the resources, especially when using a public cluster. In Phala Network the major resource is the CPU time. So we run a variant of Completely Fair Scheduler (CFS) used by the Linux kernel to ensure the CPU consumed by each contract is pro rata to their stake in the cluster. It's further combined with WASM gas metering to achieve "time slice" allocation in the cluster.
There are several keys involved in this process, and all these keys are generated inside pRuntime in TEE.
WorkerKey, every pRuntime, no matter it’s worker or GK, generates it during the initialization and publish the pk on-chain during worker registration (GK must be first registered as worker)
All the key sharing between workers are done through encrypted channel. And this channel is established using the WorkerKeys of two parties. Two workers first generate the common working key using ECDH on their WorkerKeys, then using the working key to encrypt the real contents
MasterKey, generated by the first registered GK, and shared to all the other GKs. The MasterKey pk is published on chain, so any GK can sign the messages with MasterKey for others to verify. All the GKs behave exactly the same so they are duplications to each other
MasterKey is the root key for all the following contract-related keys
ClusterKey, generated by GK by deriving the MasterKey with cluster info. The ClusterKey is shared by GK to all the Workers in the cluster during cluster creation through the encrypted channels
ContractKey, generated by cluster workers by deriving the ClusterKey with contract info. Since all the cluster workers have the ClusterKey, they will generate the same ContractKey for each contract.