Phala Network Docs
  • Home
    • 👾Phala Network Docs
  • Overview
    • ⚖️Phala Network
      • 💎Phala Cloud
      • 🥷Dstack
      • 🔐GPU TEE
    • 💎PHA Token
      • 🪙Introduction
      • 👐Delegation
        • Delegate to StakePool
        • What is Vault
        • What is Share
        • WrappedBalances & W-PHA
        • Examples of Delegation
        • Use Phala App to Delegate
        • Estimate Your Reward
      • 🗳️Governance
        • Governance Mechanism
        • Join the Council
        • Voting for Councillors
        • Apply for Project Funding
        • Phala Treasury
        • Phala Governance
        • Setting Up an Account Identity
  • Phala Cloud
    • 🚀Getting Started
      • Sign-up for Cloud Account
      • Start from Cloud UI
      • Start from Cloud CLI
      • Start from Template
    • 🟧Launch an Eliza Agent
    • 📦Create CVM
      • Create CVM with Docker Compose
      • Create CVM with Private Docker Image
      • Set Secure Environment Variables
      • Access Your Applications
      • Setting Up Custom Domain
      • Debug Your Application
      • Deployment Cheat Sheet
    • ⚙️CVM Management
      • Upgrade Application
      • Resize Resources
      • Check Logs
      • Private Log Viewer
    • 🔄Deploy Docker App in TEE
      • Expose Service Port
      • Generate RA Report
      • Access Database
      • Create Crypto Wallet
    • 🛳️Setup a CI/CD Pipeline
    • 🛠️Phala Cloud CLI Reference
      • phala
        • auth
        • cvms
        • docker
        • simulator
    • Production Checklist
    • ❓FAQs
    • 🔍Troubleshooting
    • 📖Glossary
    • 📋References
    • 🔒Use Cases
      • TEE with AI
      • TEE with FHE and MPC
      • TEE with ZK and ZKrollup
  • Dstack
    • Overview
    • Getting Started
    • Hardware Requirements
    • Design Documents
      • Decentralized Root-of-Trust
      • Key Management Protocol
      • Zero Trust HTTPs (TLS)
    • Acknowledgement
  • LLM in GPU TEE
    • 👩‍💻Host LLM in GPU TEE
    • 🔐GPU TEE Inference API
    • 🏎️GPU TEE Benchmark
  • Tech Specs
    • ⛓️Blockchain
      • Blockchain Entities
      • Cluster of Workers
      • Secret Key Hierarchy
  • References
    • 🔐Setting Up a Wallet on Phala
      • Acquiring PHA
    • 🌉SubBridge
      • Cross-chain Transfer
      • Supported Assets
      • Asset Integration Guide
      • Technical Details
    • 👷Community Builders
    • 🤹Hackathon Guides
      • ETHGlobal Singapore
      • ETHGlobal San Francisco
      • ETHGlobal Bangkok
    • 🤯Advanced Topics
      • Cross Chain Solutions
      • System Contract and Drivers
      • Run Local Testnet
      • SideVM
    • 🆘Support
      • Available Phala Chains
      • Resource Limits
      • Transaction Costs
      • Compatibility Matrix
      • Block Explorers
      • Faucet
    • ⁉️FAQ
  • Compute Providers
    • 🙃Basic Info
      • Introduction
      • Gemini Tokenomics (Worker Rewards)
      • Budget balancer
      • Staking Mechanism
      • Requirements in Phala
      • Confidence Level & SGX Function
      • Rent Hardware
      • Error Summary
    • 🦿Run Workers on Phala
      • Solo Worker Deployment
      • PRBv3 Deployment
      • Using PRBv3 UI
      • PRB Worker Deployment
      • Switch Workers from Solo to PRB Mode
      • Headers-cache deployment
      • Archive node deployment
    • 🛡️Gatekeeper
      • Collator
      • Gatekeeper
  • Web Directory
    • Discord
    • GitHub
    • Twitter
    • YouTube
    • Forum
    • Medium
    • Telegram
  • Legacy
    • Information
    • ⚒️Phala SDK
    • 👨‍🚀Builders Program
    • 🥷AI Agent Contract
      • WapoJS Functions
      • Phala Agent Gateway
  • AI Agent Contract (Legacy)
    • 👩‍💻Getting Started
      • Build Your First AI Agent Contract
      • Build An Agent to Transact Onchain
      • Build Your AI Agent Contract with OpenAI
      • Build Your AI Agent Contract with LangChain
      • Integrate with 3rd Party API with HTTP Request
      • Run a Local Testnet With Docker
      • AI Agent Contract Templates
    • 🧙‍♂️Examples
      • Create a Weather Agent w/ Function Calling
    • ⛓️Supported Chains
    • FAQ
  • Agent Wars (Legacy)
    • 📜Introduction
    • 💸Tokenomics
    • ▶️Getting Started
      • Wallet Setup & Get PHA
      • Buy and Sell Keys
    • 🧑‍🏫Tutorial
Powered by GitBook
LogoLogo

Participate

  • Compute Providers
  • Node
  • Community
  • About Us

Resources

  • Technical Whitepaper
  • Token Economics
  • Docs
  • GitHub

More

  • Testnet
  • Explorer
  • Careers
  • Responsible Disclosure

COPYRIGHT © 2024 PHALA.LTD ALL RIGHTS RESERVED. May Phala be with you!

On this page
  • Overview
  • Entity Key Initialization
  • Secure Communication Channels
  • Client-worker Payload Example
  • Serialization

Was this helpful?

Edit on GitHub
  1. Tech Specs
  2. Blockchain

Blockchain Entities

PreviousBlockchainNextCluster of Workers

Last updated 1 year ago

Was this helpful?

Overview

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.

Entity Key Initialization

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:

  1. IdentityKey

    • an sr25519 key pair to uniquely identify an entity;

  2. EcdhKey

    • an sr25519 key pair for secure communication;

pRuntime Initialization

During initialization, pRuntime automatically generates the entity key pairs above with a random number generator. The generated key pairs are managed in pRuntime in 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.

Secure Communication Channels

A channel between two entities, A and B is denoted as Channel(PkA,PkB)Channel(Pk_A, Pk_B)Channel(PkA​,PkB​), where PkAPk_APkA​ and PkBPk_BPkB​ 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 aes-gcm-256.

The public keys of the entities are registered on-chain. So we can build on-chain or off-chain communication channels:

  • On-chain Communication

    1. Both A and B know each other’s public keys from the blockchain. They can derives CommKey(A, B);

    2. A posts a cipher message encrypted by CommKey(A, B) to the blockchain;

    3. B receives it, and decrypts it with CommKey(A, B);

  • Off-chain (A is off-chain and B is an on-chain worker) Communication

    1. A can learn B’s public key from the blockchain and derive CommKey(A, B);

    2. A learns the API endpoint of B from its WorkerInfo in WorkerState on chain;

    3. A sends a signed cipher message (encrypted by CommKey(A, B)) with its public key to B directly;

    4. B gets A’s public key from the message, and derives CommKey(A, B) to decrypt it;

Client-worker Payload Example

A client communicates with a worker only for contract invocation. An invocation consists of at least the following payloads.

{
    from: Client_IdentityKey,
    payload: {
        to: Contract_IdentityKey,
        input: "0xdeadbeef",
    },
    nonce: 12345,
    sig: UserSignature,
}
  • nonce is necessary for defending against Double-spend and Replay Attacks.

  • from shows the identity of the caller, and can be verified with sig. from will be further passed to the contract.

  • Since a worker can run multiple contracts (or even different instances of the same contract), to is needed to specify the invocation target.

  • input encodes the invoked function and arguments, it should be serialized according to the ABI of contracts.

Serialization

EcdhKey Rotation

Unlike the IdentityKey which shows the identity of a worker or gatekeeper thus should not be changed, we recommend a regular rotation of the EcdhKey to ensure the security of the communication channels between different entities. In the future, pRuntime will automatically rotate the managed EcdhKey key after certain time interval.

The generated key pairs can be locally encrypted and cached on the disk with and decrypted and loaded when restarting. This applies to both gatekeepers and workers.

The EcdhKey public key in the pRuntime of a worker or gatekeeper is publicly available. Therefore an can be applied to establish a secure communication channel between a worker (or a gatekeeper) and any other entity non-interactively.

In Khala, the EcdhKey is an sr25519 key pair. We can adopt the from Bitcoin BIP32 to derive CommKey(A, B) from the key agreed by ECDH.

⛓️
Sealing
ECDH key agreement protocol
child key derivation (CKD) functions