Skip to main content
Advanced Search
Search Terms
Content Type

Exact Matches
Tag Searches
Date Options
Updated after
Updated before
Created after
Created before

Search Results

43 total results found

Documentation

Tutorials

Architecture

Documentation

Consensus

Documentation

Getting Started

Documentation

Usage

Tutorials

Farming

Tutorials

Development

Tutorials

Advanced usage

Tutorials

Architecture Overview

Documentation Architecture

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...

Consensus Introduction

Documentation Consensus

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

Documentation Architecture

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...

Execution client

Documentation Architecture

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...

Farmer

Documentation Architecture

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...

Harvester

Documentation Architecture

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 ...

Timelord

Documentation Architecture

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...

Wallet

Documentation Architecture

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...

Proof of Space

Documentation Consensus

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...

Proof of Time

Documentation Consensus

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...

Challenges

Documentation Consensus

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...

Signage and Infusion Points

Documentation Consensus

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 ...

Harvesting

Documentation Consensus

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...

VDF chains

Documentation Consensus

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...

Overflow Blocks and Weight

Documentation Consensus

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...

Foliage

Documentation Consensus

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...

Epoch and Difficulty

Documentation Consensus

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

Documentation Consensus

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...

Block Creation

Documentation Consensus

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...

Timelord algorithm

Documentation Consensus

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...