Types & classes — github.com/JoshOrndorff/blockchain-from-scratch

CodeHub MCPcopy Create free account

hub / github.com/JoshOrndorff/blockchain-from-scratch / types & classes

Types & classes58 in github.com/JoshOrndorff/blockchain-from-scratch

⨍ Functions 239◇ Types & classes 58

ClassAccountedCurrency

This state machine models a multi-user currency system. It tracks the balance of each user and allows users to send funds to one another.

src/c1_state_machine/p4_accounted_currency.rs:16

EnumAccountingTransaction

The state transitions that users can make in an accounted currency system

src/c1_state_machine/p4_accounted_currency.rs:27

Something you can do to the ATM

src/c1_state_machine/p3_atm.rs:18

ClassAlternatingPowPoa

PoW and PoA each have their own set of strengths and weaknesses. Many chains are happy to choose one of them. But other chains would like consensus pr

src/c3_consensus/p5_interleave.rs:10

src/c1_state_machine/p3_atm.rs:46

src/c1_state_machine/p3_atm.rs:28

src/c1_state_machine/p5_digital_cash.rs:17

src/c4_client/p1_data_structure.rs:46

src/c2_blockchain/p4_batched_extrinsics.rs:71

src/c2_blockchain/p6_rich_state.rs:74

EnumCashTransaction

The state transitions that users can make in a digital cash system

src/c1_state_machine/p5_digital_cash.rs:77

ClassCensoringPool

A transaction pool that censors some transactions. It refuses to queue any transactions that are might be associated with terrorists.

src/c4_client/p4_transaction_pool.rs:134

EnumClothesAction

Something you can do with clothes

src/c1_state_machine/p2_laundry_machine.rs:27

ClassClothesMachine

This state machine models the typical life cycle of clothes as they make their way through the laundry cycle several times before ultimately becoming

src/c1_state_machine/p2_laundry_machine.rs:9

EnumClothesState

src/c1_state_machine/p2_laundry_machine.rs:13

InterfaceConsensus

A Consensus Engine. Responsible for Sealing blocks and verifying their seals Consensus exists independently of execution logic, and therefore operate

src/c3_consensus/mod.rs:38

EnumConsensusAuthority

src/c3_consensus/mod.rs:109

ClassDictatorConsensus

Dictator consensus is an identity-based consensus algorithm. It specifies a single dictator identity who is the only identity authorized to sign valid

src/c3_consensus/p2_dictator.rs:15

ClassDigitalCashSystem

This state machine models a multi-user currency system. It tracks a set of bills in circulation, and updates that set when money is transferred.

src/c1_state_machine/p5_digital_cash.rs:11

A Consensus engine that requires the state root to be even for the header to be valid. Wraps an inner consensus engine whose rules will also be enforc

src/c3_consensus/p4_even_only.rs:11

InterfaceForkChoice

A means for a blockchain client to decide which chain is best among the many that it potentially knows about. Our client is generic over this bit of

src/c4_client/p3_fork_choice.rs:18

InterfaceForkChoice

Judge which blockchain is "best" when there are multiple candidates. There are several meaningful notions of "best" which is why this is a trait inste

src/c2_blockchain/p5_fork_choice.rs:17

A Higher-order consensus engine that represents a change from one set of consensus rules (Before) to another set (After) at a specific block height

src/c3_consensus/p6_forking.rs:15

ClassFullClient

A client represents one view of an evolving blockchain network. It knows of blocks, forks, state, and it also pools transactions waiting to be include

src/c4_client/mod.rs:52

In the Greedy Heaviest Observed Subtree rule, the fork choice is iterative. You start from the genesis block, and at each fork, you choose the side of

src/c4_client/p3_fork_choice.rs:78

src/c3_consensus/mod.rs:27

src/c2_blockchain/p2_extrinsic_state.rs:20

src/c2_blockchain/p4_batched_extrinsics.rs:16

src/c2_blockchain/p3_consensus.rs:27

src/c2_blockchain/p6_rich_state.rs:31

src/c2_blockchain/p1_header_chain.rs:14

ClassHeaviestChain

The chain with the most accumulated proof of work is the best. This fork choice rule only makes sense with the PoW consensus engine and the generics r

src/c4_client/p3_fork_choice.rs:44

ClassHeaviestChainRule

The best chain is the one with the most accumulated work. In Proof of Work chains, each block contains a certain amount of "work". Roughly speaking,

src/c2_blockchain/p5_fork_choice.rs:63

InterfaceImportBlock

A trait that represents the ability to import complete blocks of the chain. The main method here is `import_block` but several other methods are prov

src/c4_client/p2_importing_blocks.rs:10

src/c1_state_machine/p3_atm.rs:9

ClassLightSwitch

This state machine models a single light switch. The internal state, a bool, represents whether the switch is on or not.

src/c1_state_machine/p1_switches.rs:9

ClassLongestChain

The chain with the highest block height is the best

src/c4_client/p3_fork_choice.rs:27

ClassLongestChainRule

The "best" chain is simply the longest chain.

src/c2_blockchain/p5_fork_choice.rs:40

ClassMostAliceSigs

The chain with the most signatures from the Alice authority is the best. This fork choice rule only makes sense with the PoA consensus engine and the

src/c4_client/p3_fork_choice.rs:61

ClassMostBlocksWithEvenHash

The best chain is the one with the most blocks that have even hashes. This exact rule is a bit contrived, but it does model a family of fork choice r

src/c2_blockchain/p5_fork_choice.rs:97

ClassPoaRoundRobinByHeight

A Proof of Authority consensus engine. Only one authority is valid at each block height. As ever, the genesis block does not require a seal. After tha

src/c3_consensus/p3_poa.rs:38

ClassPoaRoundRobinBySlot

Both of the previous PoA schemes have the weakness that a single dishonest authority can corrupt the chain. When allowing any authority to sign, the s

src/c3_consensus/p3_poa.rs:66

A Proof of Work consensus engine. This is the same consensus logic that we implemented in the previous chapter. Here we simply re-implement it in the

src/c3_consensus/p1_pow.rs:12

EnumPowOrPoaDigest

src/c3_consensus/p5_interleave.rs:16

ClassPriorityPool

A transaction pool that assigns a priority to each transaction and then provides them (to the authoring process, presumably) highest priority first.

src/c4_client/p4_transaction_pool.rs:96

A Proof of Authority consensus engine. If any of the authorities have signed the block, it is valid.

src/c3_consensus/p3_poa.rs:15

ClassSimplePool

A simple state machine that is just a first-in-first-out queue.

src/c4_client/p4_transaction_pool.rs:65

ClassSlotDigest

src/c3_consensus/p3_poa.rs:74

src/c1_state_machine/p5_digital_cash.rs:26

src/c1_state_machine/p6_open_ended.rs:25

src/c2_blockchain/p6_rich_state.rs:21

InterfaceStateMachine

A state machine - Generic over the transition type

src/c1_state_machine/mod.rs:12

Now there are two switches so we need a proper type for the transition.

src/c1_state_machine/p1_switches.rs:34

InterfaceTransactionPool

An abstraction over the notion of transaction pool.

src/c4_client/p4_transaction_pool.rs:17

src/c1_state_machine/p6_open_ended.rs:27

ClassTwoSwitches

src/c1_state_machine/p1_switches.rs:28

src/c1_state_machine/mod.rs:32

ClassWeirdSwitchMachine

This second state machine models two light switches with one weird property. Whenever switch one is turned off, switch two also goes off.

src/c1_state_machine/p1_switches.rs:24