--recursiveflag when cloning:
tests. The Peerplays implementation is almost entirely defined within various libraries, which are located in the
programssubdirectory contains small wrappers around these libraries, exposing their functionality as executable binaries.
testssubdirectory contains various tests to verify that essential blockchain features and functionality are working, and to detect regressions should they occur during development.
librarieswithin the libraries sub directory of the repository. A high level description of each of the libraries is as follows:
applicationclass, which implements the heart of a Peerplays node
chaincontains the bulk of the blockchain implementation, including all Peerplays specific functionality
dbcontains the database functionality, implementing the in-memory database as well as the persistence layer
egenesisis a small library which embeds the genesis block data into the binary
fcis a library implementing many utility functionalities, including serialization, RPC, concurrency, etc.
netcontains the peer-to-peer networking layer of Peerplays
pluginscontains several plugin libraries which can be utilized within a Peerplays node
utilitiescontains code and data necessary to Peerplays’ implementation, but not critical to the core functionality
walletcontains the reference command-line wallet implementation
chainlibrary, and sometimes
fc. The other libraries remain reasonably stable, seeing comparatively small updates and modifications.
cli_wallet.In addition, the code within these folders exists just to expose library functionality in an executable, and is rarely updated.
witness_nodeprogram is the only maintained Peerplays node executable. The name
witness_nodeis something of a misnomer, as this executable is really just a full node, but it can provide witness (i.e., block producer) functionality by loading the
cli_walletprogram implements a command-line wallet for Peerplays. It requires a network connection to a running
witness_nodeto provide chain state information to it. This program provides a basic UI for all Peerplays functionality.
database_fixture, defined in
tests/common/database_fixture.hpp, as the basis of the tests. This file also defines many macros and functions to reduce the boilerplate of test writing.
tests/testsfolder, and are run by the
chain_testbinary. All tests of core functionality should be included in this directory and binary.
operations. All interactions with the blockchain take place through
operations, and in a sense, they are the blockchain’s API.
evaluator, which implements that operation’s functionality within the Peerplays software implementation. Thus an
operationis like a function prototype, whereas an
evaluatoris the function definition.
objectdefines a group of fields, analogous to columns of a relational database table.
operations charge a fee to execute, and each must specify an account to pay the fee. This account’s ID must be returned by the
fee_payer()method on the
operationmust also provide a stateless consistency check which examines the
operation’s fields and throws an exception if anything is invalid.
operations must provide a
calculate_fee()method which examines the
operationand calculates the fee to execute it. This method may not reference blockchain state, however, each
fee_parameters_typestruct containing settings for the fee calculation defined at runtime, and an instance of this struct is passed to the
operations automatically require the authorization of their fee paying account, but an
operationmay additionally specify other accounts which must authorize their execution by defining the
evaluatorwhich implements that
operation’s modifications to the blockchain database. Each
evaluatormost provide two methods:
operationwith read-only access to the database, and verifies that the
operationcan be applied successfully. The apply step then modifies the database.
evaluatormust also define a type alias,
evaluator::operation_type, which aliases the specific
operationimplemented by that evaluator.
operations which modify the database.
libraries/dbfolder, and it provides persistence to disk as well as undo functionality allowing the rewinding of changes, such as when a partially-applied transaction fails to execute, or blocks are popped due to a chain reorganization (i.e. when switching forks).
objecttypes, each of which defines the columns of a table. The rows of this table represent the individual object instances in the database. Along with each
objecttype is an index type, which, in relational database terms, defines the primary and secondary keys, which can be used to look up object instances.
object_idtype, a unique numerical ID for each object instance known to the blockchain. All
idfield from their base class which contains this ID. This field is set by the database automatically and does not need to be modified manually.
operations which are analogous to API calls provided by the contract.
operations are implemented by
evaluators, which provide code to verify that the operation can execute successfully, and then to perform the requisite modifications to database
objects specify an index, which defines keys which can be used to look up an object instance within the database.
pypeerplaysis to simplify development of products and services that use the Peerplays blockchain. It comes with:
witness_node) or the wallet (
cli_wallet). Both support RPC-JSON. The full node also supports the websocket protocol with notifications.
witness_nodeapplication) can be used to obtain any kind of data stored in the blockchain. Besides data stores in the blockchain itself (blocks, transactions, etc. ..), higher level objects (such as accounts, balances, etc. …) can be retrieved through the full node’s database.
cli_walletbinary, allows you to create and sign transactions and broadcast them.