The last chapter covered Phala’s architecture, whereas this page will touch on Phala’s entities and the types of nodes that make Phala Network.
In Phala Network, there are three kinds of entities:
- Client, which operates on normal devices without any special hardware requirements;
- Worker, which operates on Secure Enclave and serves as the computation nodes for confidential smart contracts;
- Gatekeeper, which operates on Secure Enclave and serves as the authorities and key managers;
The image below visualizes the interaction between Phala’s entities.
The basic design of Phala Network is meant to ensure the security and confidentiality of the blockchain and its Phat Contract. However, with more security improvements, Phala Network can defend against advanced attacks.
In Phala, the communication between any entity should be encrypted, so each entity generates the following entity key pairs with a pseudorandom number generator during initialization:
sr25519key pair to uniquely identify an entity;
sr25519key pair for secure communication;
pRuntimeautomatically generates the entity key pairs above with a random number generator. The generated key pairs are managed in
pRuntimein the Secure Enclave, which means the workers and gatekeepers can only use it with the limited APIs exported by
pRuntime, and can never gain the plaintext key pairs to read the encrypted data out of the Secure Enclave.
EcdhKeypublic key in the
pRuntimeof a worker or gatekeeper is publicly available. Therefore an ECDH key agreement protocol can be applied to establish a secure communication channel between a worker (or a gatekeeper) and any other entity non-interactively.
A channel between two entities,
Bis denoted as
are the public keys of their ECDH key pairs correspondingly. A shared secret can be derived from one’s ECDH private key and the counterpart’s public key via the Diffie Hellman algorithm. Then the final communication key
CommKey(A, B)can be calculated via a one-way function. Finally,
CommKey(A, B)is used to encrypt the messages between the two entities.
The messages are end-to-end encrypted with
The public keys of the entities are registered on-chain. So we can build on-chain or off-chain communication channels:
- On-chain Communication
Bknow each other’s public keys from the blockchain. They can derives
Aposts a cipher message encrypted by
CommKey(A, B)to the blockchain;
Breceives it, and decrypts it with
- Off-chain (
Ais off-chain and
Bis an on-chain worker) Communication
B’s public key from the blockchain and derive
Alearns the API endpoint of
Asends a signed cipher message (encrypted by
CommKey(A, B)) with its public key to
A’s public key from the message, and derives
CommKey(A, B)to decrypt it;
A client communicates with a worker only for contract invocation. An invocation consists of at least the following payloads.
nonceis necessary for defending against Double-spend and Replay Attacks.
fromshows the identity of the caller, and can be verified with
fromwill be further passed to the contract.
- Since a worker can run multiple contracts (or even different instances of the same contract),
tois needed to specify the invocation target.
inputencodes the invoked function and arguments, it should be serialized according to the ABI of contracts.
IdentityKeywhich shows the identity of a worker or gatekeeper thus should not be changed, we recommend a regular rotation of the
EcdhKeyto ensure the security of the communication channels between different entities. In the future,
pRuntimewill automatically rotate the managed
EcdhKeykey after certain time interval.