Search Results

The above diagram shows BPX network architecture. A single machine can run more than one of these processes. Typical BPX network full node consist of two processes: Beacon Client and Execution Client. Additionally, Farmer and Harvester are activated to farm ne...

Decentralized consensus algorithms require Sybil resistance, using a resource that is both cryptographically verifiable and scarce (not infinite). In previous blockchain systems, two different scarce resources have been used: computing power (Proof of Work) an...

Beacon Client is a BPX Beacon Chain full node. It has several responsibilities: Maintain a copy of the Beacon Chain Validate the Beacon Chain blocks Propagate new beacon blocks and proofs through the peer-to-peer network Provides consensus updates for th...

The execution client is a full node of BPX Execution Chain. It listens to new transactions broadcasted in the network, maintains the mempool, executes transactions in EVM, creates and validates execution blocks and holds the latest state and database of BPX Ex...

BPX farmers are analogous to Bitcoin's miners. They earn block rewards and fees by finding valid proofs of space inside their stored plots. The farmer processes don't maintain a copy of the Beacon Chain, but they trust a beacon client to provide updates. The b...

Harvesters are individual machines controlled by a farmer. In a large farming operation, a farmer may be connected to many harvesters. Harvesters control the actual plot files by retrieving qualities or proofs from disk. The minimum plot size (and by far the ...

Timelords support the network by creating sequential proofs of time (using a Verifiable Delay Function) and broadcasting them approximately every nine seconds. This provides "deterministic randomness", which is used to decide the winning proofs of space. Sinc...

The wallet is responsible for managing private keys, as well as generating, storing and sending transactions. Wallets communicate with the execution clients through the Web3 RPC API. Each execution client exposes the API on TCP port 8445. You can also connect...

A Proof of Space protocol is one in which: A Verifier can send a challenge to a Prover. The Prover can demonstrate to the Verifier that the Prover is reserving a specific amount of storage space at that precise time. The Proof of Space protocol has thre...

A Verifiable Delay Function, also referred to as a Proof of Time or VDF, is a proof that a sequential function was executed a certain number of times. Verifiable: This means that after performing the computation (which takes time), the Prover can create a ver...

The BPX consensus algorithm relies on timelords running VDFs for periods of time called sub-slots, which are adjusted periodically (and automatically) to take around 10 minutes. During every sub-slot, challenges are released by timelords, and a sort of mini lo...

Each sub-slot in both the challenge chain and the reward chain is divided into 64 smaller VDFs. Between each of these smaller VDFs is a point called a signage point. Timelords publish the VDF output and proof when they reach each signage point. The challenge ...

Approximately every 9.375 seconds, the beacon client sends a new signage point to the farmer, who sends it to each harvester. The exact protocol message sent for each signage point is the following: class NewSignagePointHarvester: challenge_hash: bytes3...

If we only used one VDF (for the reward chain), the inclusion or exclusion of blocks would allow control of the challenge for the next slot. This means that an attacker could try many different combinations of blocks, and choose the challenge that suits them b...

For a farmer to create a block, their required_iterations must be less than sub-slot_iterations / 64. This means that infusion_iterations might be greater than the sub-slot_iterations, and therefore the infusion must happen in the next sub-slot. Overflow bloc...

In the previous diagrams, there is no place for farmers to specify their rewards, since all blocks are canonical. There is also no place to include execution layer data. Everything we have talked about so far is the trunk of the blockchain. Farmers have no sa...

Sub-epoch: Sub-epoch N starts when sub-epoch N-1 ends (except for 0th sub-epoch), and it ends at the end of the first slot where 384 * (N+1) blocks have been included since genesis. Epoch: Epoch N starts when epoch N-1 ends (except for 0th epoch), and it ends...

Block validation in BPX is composed of two parts: header validation and body validation. The header validation performs consensus algorithm-related checks, such as proof of space and time, signage points and infusion points, previous block hashes, foliage has...

As soon as the Execution Client receives a new execution block, it starts working on a candidate for the next block, whether it is ever used or not. The potential next execution block is always available for fetch by the beacon client using local RPC connectio...

A timelord keeps track of the current peak of beacon chain, which includes an infused block at a certain height, and signage points from the peak onward. A timelord might receive new blocks to infuse, new peaks (blocks which are already infused), or new signag...