solana/src/lib.rs

//! The `solana` library implements the Solana high-performance blockchain architecture.
//! It includes a full Rust implementation of the architecture as well as hooks to GPU
//! implementations of its most paralellizable components. It also includes command-line
//! tools to spin up fullnodes and a Rust library `thin_client` to interact with them.
//!

#![cfg_attr(feature = "unstable", feature(test))]
pub mod bank;
pub mod banking_stage;
pub mod budget;
pub mod crdt;
pub mod data_replicator;
pub mod entry;
pub mod entry_writer;
#[cfg(feature = "erasure")]
pub mod erasure;
pub mod fetch_stage;
pub mod hash;
pub mod ledger;
pub mod logger;
pub mod mint;
pub mod packet;
pub mod payment_plan;
pub mod record_stage;
pub mod recorder;
pub mod replicate_stage;
pub mod request;
pub mod request_processor;
pub mod request_stage;
pub mod result;
pub mod rpu;
pub mod server;
pub mod signature;
pub mod sigverify;
pub mod sigverify_stage;
pub mod streamer;
pub mod thin_client;
pub mod timing;
pub mod tpu;
pub mod transaction;
pub mod tvu;
pub mod write_stage;
extern crate bincode;
extern crate byteorder;
extern crate chrono;
extern crate generic_array;
extern crate libc;
#[macro_use]
extern crate log;
extern crate rayon;
extern crate ring;
extern crate serde;
#[macro_use]
extern crate serde_derive;
extern crate pnet;
extern crate serde_json;
extern crate sha2;
extern crate untrusted;

#[cfg(test)]
#[macro_use]
extern crate matches;

extern crate rand;
Better docs for the bank 2018-06-06 08:49:22 -07:00			//! The `solana` library implements the Solana high-performance blockchain architecture.
			`//! It includes a full Rust implementation of the architecture as well as hooks to GPU`
			`//! implementations of its most paralellizable components. It also includes command-line`
			//! tools to spin up fullnodes and a Rust library `thin_client` to interact with them.
			`//!`

Parallelize verification 2018-02-14 13:19:30 -08:00			`#![cfg_attr(feature = "unstable", feature(test))]`
accountant -> bank 2018-05-14 14:33:11 -07:00			`pub mod bank;`
Extract event processing from request_stage 2018-05-14 16:31:13 -07:00			`pub mod banking_stage;`
Move Budget EDSL into its own module 2018-05-29 12:28:07 -07:00			`pub mod budget;`
initial crdt implementation 2018-04-21 11:02:49 -07:00			`pub mod crdt;`
Crdt pipeline, coalesce window repair requests in the listener by examining all of them at once, and ublock those threads from doing io. 2018-05-27 18:21:39 -07:00			`pub mod data_replicator;`
Move entry into its own module Hmm, Logger doesn't depend on log. 2018-03-06 16:31:17 -08:00			`pub mod entry;`
Move the writer stage's utilities to its own module 2018-05-11 21:36:16 -07:00			`pub mod entry_writer;`
improve the error messages 2018-04-21 06:12:57 -07:00			`#[cfg(feature = "erasure")]`
			`pub mod erasure;`
Finally made fetch happen 2018-05-29 10:18:12 -07:00			`pub mod fetch_stage;`
Nightly rustfmt Format code with the nightly version of rustfmt, which sorts imports. 2018-03-26 21:03:26 -07:00			`pub mod hash;`
log -> ledger Free up namespace for traditional runtime logs. 2018-03-19 09:09:17 -07:00			`pub mod ledger;`
Add broadcast impl 2018-04-28 00:31:20 -07:00			`pub mod logger;`
Rename Genesis to Mint Genesis is a story of creation. We should only use that term to for the event log that bootstraps the system. 2018-03-07 16:08:12 -08:00			`pub mod mint;`
Change for cuda verify integration 2018-03-26 21:07:11 -07:00			`pub mod packet;`
plan.rs -> payment_plan.rs 2018-05-29 12:55:21 -07:00			`pub mod payment_plan;`
Rename Historian to RecordStage Historian was a legacy name. The new name reflects the new pipelined architecture. 2018-05-14 13:19:11 -07:00			`pub mod record_stage;`
logger -> recorder Free up namespace for a traditional runtime logger. 2018-03-19 09:16:16 -07:00			`pub mod recorder;`
fmt 2018-05-22 15:18:07 -07:00			`pub mod replicate_stage;`
Move thin client messages into their own module 2018-05-12 16:41:27 -07:00			`pub mod request;`
Move RequestProcessor into its own module 2018-05-12 16:50:55 -07:00			`pub mod request_processor;`
Free up name 'thin_client_service' 2018-05-12 09:31:28 -07:00			`pub mod request_stage;`
Fast UdpSocket reader * message needs to fit into 256 bytes * allocator to keep track of blocks of messages * udp socket receiver server that fills up the block as fast as possible * udp socket sender server that sends out the block as fast as possible 2018-03-07 13:47:13 -08:00			`pub mod result;`
Free up the name 'tpu' 2018-05-12 09:53:25 -07:00			`pub mod rpu;`
Wrap the RPU with new object Server 2018-05-15 10:00:01 -07:00			`pub mod server;`
Nightly rustfmt Format code with the nightly version of rustfmt, which sorts imports. 2018-03-26 21:03:26 -07:00			`pub mod signature;`
Rename sigverify modules 2018-05-25 15:52:17 -07:00			`pub mod sigverify;`
			`pub mod sigverify_stage;`
Nightly rustfmt Format code with the nightly version of rustfmt, which sorts imports. 2018-03-26 21:03:26 -07:00			`pub mod streamer;`
AccountantSkel -> Tpu The terms Stub and Skel come from OMG IDL and only made sense while the Stub was acting as an RPC client for the the Accountant object. Nowadays, the Stub interface looks nothing like the Accountant and meanwhile we've recognized the multithreaded implementation is more reminiscent of a pipelined CPU. Thus, we finally bite the bullet and rename our modules. AccountantSkel -> Tpu AccountantStub -> ThinClient Up next will be moving much of the TPU code into separate modules, each representing a stage of the pipeline. The interface of each will follow the precedent set by the Historian object. 2018-05-08 16:32:50 -07:00			`pub mod thin_client;`
Rework sig processing threads and add perf for process/verify 2018-05-07 16:49:15 -07:00			`pub mod timing;`
Add TPU 2018-05-14 16:36:19 -07:00			`pub mod tpu;`
cargo +nightly fmt 2018-05-08 17:59:01 -07:00			`pub mod transaction;`
Move validation processor to its own module 2018-05-11 23:31:32 -07:00			`pub mod tvu;`
Move write_service and drain_service into new write_stage module 2018-05-14 15:27:40 -07:00			`pub mod write_stage;`
Allow event log to hold events of any serializable (hashable) type 2018-02-26 15:42:31 -08:00			`extern crate bincode;`
Implement window service Batch out of order blobs until we have a contigious window. 2018-04-02 19:32:58 -07:00			`extern crate byteorder;`
Add DateTime and Cancel conditions Fixes #32, #33 2018-03-07 20:55:49 -08:00			`extern crate chrono;`
Add serialization/deseriation support to event log See bincode and serde_json for usage: https://github.com/TyOverby/bincode Fixes #1 2018-02-20 15:26:11 -08:00			`extern crate generic_array;`
Change for cuda verify integration 2018-03-26 21:07:11 -07:00			`extern crate libc;`
Fast UdpSocket reader * message needs to fit into 256 bytes * allocator to keep track of blocks of messages * udp socket receiver server that fills up the block as fast as possible * udp socket sender server that sends out the block as fast as possible 2018-03-07 13:47:13 -08:00			`#[macro_use]`
No longer rename log crate 2018-03-19 09:18:48 -07:00			`extern crate log;`
Parallelize verification 2018-02-14 13:19:30 -08:00			`extern crate rayon;`
Extend the event log with a Claim event to claim possession Unlike a Discovery event, a Claim event associates a public key with a hash. It's intended to to be used to claim ownership of some hashable data. For example, a graphic designer could claim copyright by hashing some image they created, signing it with their private key, and publishing the hash-signature pair via the historian. If someone else tries to claim it as their own, the designer can point to the historian's log as cryptographically secure evidence that the designer's copy existed before anyone else's. Note there's nothing here that verifies the first claim is the actual content owner, only that the first claim almost certainly happened before a second. 2018-02-24 05:53:36 -08:00			`extern crate ring;`
Add serialization/deseriation support to event log See bincode and serde_json for usage: https://github.com/TyOverby/bincode Fixes #1 2018-02-20 15:26:11 -08:00			`extern crate serde;`
			`#[macro_use]`
			`extern crate serde_derive;`
Make bootstrapping functions accessible to other binaries 2018-05-31 14:11:16 -07:00			`extern crate pnet;`
Initialize the testnode from a log $ cargo run --bin silk-genesis-file-demo > demo-genesis.json $ cat demo-genesis.json \| cargo run --bin silk-genesis-block > demo-genesis.log $ cat demo-genesis.log \| cargo run --bin silk-testnode 2018-03-05 14:34:15 -08:00			`extern crate serde_json;`
Use sha256 hashes instead of Rust's builtin hasher. Causes a 20x performance degradation. Enabling asm did not speed things up. 2018-02-19 15:17:13 -08:00			`extern crate sha2;`
Extend the event log with a Claim event to claim possession Unlike a Discovery event, a Claim event associates a public key with a hash. It's intended to to be used to claim ownership of some hashable data. For example, a graphic designer could claim copyright by hashing some image they created, signing it with their private key, and publishing the hash-signature pair via the historian. If someone else tries to claim it as their own, the designer can point to the historian's log as cryptographically secure evidence that the designer's copy existed before anyone else's. Note there's nothing here that verifies the first claim is the actual content owner, only that the first claim almost certainly happened before a second. 2018-02-24 05:53:36 -08:00			`extern crate untrusted;`
Fast UdpSocket reader * message needs to fit into 256 bytes * allocator to keep track of blocks of messages * udp socket receiver server that fills up the block as fast as possible * udp socket sender server that sends out the block as fast as possible 2018-03-07 13:47:13 -08:00
			`#[cfg(test)]`
			`#[macro_use]`
			`extern crate matches;`
Rework sig processing threads and add perf for process/verify 2018-05-07 16:49:15 -07:00
			`extern crate rand;`