In the solo mining scenario, pherry plays the part of fetching blocks from the network and send them to the TEE runtime. It works gracefully but enconters some productivity and performance issues in the pool mining scenario. Thus, Phala Runtime Bridge a.k.a.
prb is introduced to take advantage of the mining pool machanism introduced in Tokenomic v0.9 and reduces the complexity of using standalone pherry.
prb is designed to be deployed in a Cloud Native environments but also runs via traditional Linux shell, it provides a RPC interface to manage workers' lifecycle through Redis. It is intended to replace pherry (previous
phost) in both solo and pool mining scenarios.
Both RocksDB and LevelDB are available for the
prb to use as the storage backend, it requires sufficient random I/O performance to support the large number of concurrent workers. Thus, a PCI-E 4.0 x4 SSD with big cache would be preferred. FYI, the space usage for each block in average:
- 50 KiB using LevelDB,
- 40 KiB using RocksDB.
prb sends extrinsics to synchronize between the TEE workers and the blockchain, it does require a full-featured node running in the local network environment for both Phala(
parachain) and the Parent Chain.
prb provides the following services:
io: a simple server to provide internal RocksDB/LevelDB I/O ability. while RocksDB/LevelDB is thread-safe, it can only keep one instance running at the same time.
fetch: it fetches block data the blockchains then processes them for synchronization.
trade: it makes transactions(extrinsics) to the blockchain.
lifecycle: it handles the lifecycle and status of the workers, synchronize message queues and block data between the TEE and the blockchain.
Redis, RPC and the monitor
Redis is used to maintain the internal message queue and to communicate between components. since Redis allows unauthorized access by default, DO NOT EXPOSE IT TO THE INTERNET DIRECTLY.
prb uses Protobuf to define the RPC interface, here is the definitions.
The monitor is a simple web server that provides a simple web interface to manage the workers. It’s also an example of the RPC usage.
Linux kernel tuning
It’s unnecessary to do the tuning during development and testing.
When there are more than ~300 workers in the setup, the machine running the lifecycle component should be tuned to be able to maintain huge amount of TCP connections, an example is provided for referring, be ware that we can not provides support of the Linux kernel and your actual environment.