From 5d2158792c0b221daaf65646e0d592f4e96877a9 Mon Sep 17 00:00:00 2001 From: Rob Walker Date: Sun, 29 Dec 2019 18:15:32 -0800 Subject: [PATCH] Add inflation to book, cleanup dead links, include orphaned documents (#7638) * Add inflation as implemented proposal * grab another orphan and add orphan-proofing --- book/build-cli-usage.sh | 2 +- book/build.sh | 10 ++++++++++ book/src/SUMMARY.md | 5 +++++ book/src/api-reference/{.cli.md => .cli.md.header} | 0 book/src/api-reference/transaction-api.md | 2 +- book/src/cluster/README.md | 2 +- book/src/cluster/stake-delegation-and-rewards.md | 6 +++--- book/src/implemented-proposals/commitment.md | 6 +++--- book/src/implemented-proposals/ed_overview/README.md | 3 +-- .../ed_overview}/ed_storage_rent_economics.md | 0 .../ed_vce_replication_validation_transaction_fees.md | 3 +-- .../ed_vce_state_validation_protocol_based_rewards.md | 2 +- .../ed_vce_state_validation_transaction_fees.md | 3 +-- book/src/implemented-proposals/tower-bft.md | 5 ++--- book/src/proposals/bankless-leader.md | 3 +-- book/src/{ => proposals}/block-confirmation.md | 0 .../proposals/simple-payment-and-state-verification.md | 4 ++-- .../{tick_verification.md => tick-verification.md} | 0 book/src/terminology.md | 4 ++++ 19 files changed, 37 insertions(+), 23 deletions(-) rename book/src/api-reference/{.cli.md => .cli.md.header} (100%) rename book/src/{ => implemented-proposals/ed_overview}/ed_storage_rent_economics.md (100%) rename book/src/{ => proposals}/block-confirmation.md (100%) rename book/src/proposals/{tick_verification.md => tick-verification.md} (100%) diff --git a/book/build-cli-usage.sh b/book/build-cli-usage.sh index c9af63896..f46a5e36c 100755 --- a/book/build-cli-usage.sh +++ b/book/build-cli-usage.sh @@ -7,7 +7,7 @@ usage=$(cargo -q run -p solana-cli -- -C ~/.foo --help | sed 's|'"$HOME"'|~|g') out=${1:-src/api-reference/cli.md} -cat src/api-reference/.cli.md > "$out" +cat src/api-reference/.cli.md.header > "$out" section() { declare mark=${2:-"###"} diff --git a/book/build.sh b/book/build.sh index fc1b391f1..27273f1de 100755 --- a/book/build.sh +++ b/book/build.sh @@ -3,4 +3,14 @@ set -e cd "$(dirname "$0")" +# md check +find src -name '*.md' -a \! -name SUMMARY.md | + while read -r file; do + if ! grep -q '('"${file#src/}"')' src/SUMMARY.md; then + echo "Error: $file missing from SUMMARY.md" + exit 1 + fi + done + + make -j"$(nproc)" test diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 9a2b988e9..c65f45c91 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -57,6 +57,8 @@ * [Snapshot Verification](proposals/snapshot-verification.md) * [Bankless Leader](proposals/bankless-leader.md) * [Slashing](proposals/slashing.md) + * [Tick Verification](proposals/tick-verification.md) + * [Block Confirmation](proposals/block-confirmation.md) * [Implemented Design Proposals](implemented-proposals/README.md) * [Blocktree](implemented-proposals/blocktree.md) * [Cluster Software Installation and Updates](implemented-proposals/installer.md) @@ -69,6 +71,7 @@ * [Replication-client Economics](implemented-proposals/ed_overview/ed_replication_client_economics/README.md) * [Storage-replication Rewards](implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_storage_replication_rewards.md) * [Replication-client Reward Auto-delegation](implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md) + * [Storage Rent Economics](implemented-proposals/ed_overview/ed_storage_rent_economics.md) * [Economic Sustainability](implemented-proposals/ed_overview/ed_economic_sustainability.md) * [Attack Vectors](implemented-proposals/ed_overview/ed_attack_vectors.md) * [Economic Design MVP](implemented-proposals/ed_overview/ed_mvp.md) @@ -87,3 +90,5 @@ * [Rent](implemented-proposals/rent.md) * [Durable Transaction Nonces](implemented-proposals/durable-tx-nonces.md) * [Validator Timestamp Oracle](implemented-proposals/validator-timestamp-oracle.md) + * [Commitment](implemented-proposals/commitment.md) + * [Snapshot Verification](implemented-proposals/snapshot-verification.md) diff --git a/book/src/api-reference/.cli.md b/book/src/api-reference/.cli.md.header similarity index 100% rename from book/src/api-reference/.cli.md rename to book/src/api-reference/.cli.md.header diff --git a/book/src/api-reference/transaction-api.md b/book/src/api-reference/transaction-api.md index 540ac6cf6..0b40a15e1 100644 --- a/book/src/api-reference/transaction-api.md +++ b/book/src/api-reference/transaction-api.md @@ -38,7 +38,7 @@ reject transactions with a `recent_blockhash` that is too old. - * **instructions:** A list of [instructions](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/instruction.md) that are + * **instructions:** A list of [instructions](instruction-api.md) that are run sequentially and committed in one atomic transaction if all diff --git a/book/src/cluster/README.md b/book/src/cluster/README.md index 3e7c93779..7da53176c 100644 --- a/book/src/cluster/README.md +++ b/book/src/cluster/README.md @@ -37,4 +37,4 @@ Solana rotates leaders at fixed intervals, called _slots_. Each leader may only Next, transactions are broken into batches so that a node can send transactions to multiple parties without making multiple copies. If, for example, the leader needed to send 60 transactions to 6 nodes, it would break that collection of 60 into batches of 10 transactions and send one to each node. This allows the leader to put 60 transactions on the wire, not 60 transactions for each node. Each node then shares its batch with its peers. Once the node has collected all 6 batches, it reconstructs the original set of 60 transactions. -A batch of transactions can only be split so many times before it is so small that header information becomes the primary consumer of network bandwidth. At the time of this writing, the approach is scaling well up to about 150 validators. To scale up to hundreds of thousands of validators, each node can apply the same technique as the leader node to another set of nodes of equal size. We call the technique _data plane fanout_; learn more in the [data plan fanout](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/data-plane-fanout.md) section. +A batch of transactions can only be split so many times before it is so small that header information becomes the primary consumer of network bandwidth. At the time of this writing, the approach is scaling well up to about 150 validators. To scale up to hundreds of thousands of validators, each node can apply the same technique as the leader node to another set of nodes of equal size. We call the technique [_Turbine Block Propogation_](turbine-block-propagation.md). diff --git a/book/src/cluster/stake-delegation-and-rewards.md b/book/src/cluster/stake-delegation-and-rewards.md index f830b1b4c..91e68eef4 100644 --- a/book/src/cluster/stake-delegation-and-rewards.md +++ b/book/src/cluster/stake-delegation-and-rewards.md @@ -1,6 +1,6 @@ # Stake Delegation and Rewards -Stakers are rewarded for helping to validate the ledger. They do this by delegating their stake to validator nodes. Those validators do the legwork of replaying the ledger and send votes to a per-node vote account to which stakers can delegate their stakes. The rest of the cluster uses those stake-weighted votes to select a block when forks arise. Both the validator and staker need some economic incentive to play their part. The validator needs to be compensated for its hardware and the staker needs to be compensated for the risk of getting its stake slashed. The economics are covered in [staking rewards](../proposals/staking-rewards.md). This chapter, on the other hand, describes the underlying mechanics of its implementation. +Stakers are rewarded for helping to validate the ledger. They do this by delegating their stake to validator nodes. Those validators do the legwork of replaying the ledger and send votes to a per-node vote account to which stakers can delegate their stakes. The rest of the cluster uses those stake-weighted votes to select a block when forks arise. Both the validator and staker need some economic incentive to play their part. The validator needs to be compensated for its hardware and the staker needs to be compensated for the risk of getting its stake slashed. The economics are covered in [staking rewards](../implemented-proposals/staking-rewards.md). This chapter, on the other hand, describes the underlying mechanics of its implementation. ## Basic Design @@ -162,11 +162,11 @@ Lamports build up over time in a Stake account and any excess over activated sta ## Staking Rewards -The specific mechanics and rules of the validator rewards regime is outlined here. Rewards are earned by delegating stake to a validator that is voting correctly. Voting incorrectly exposes that validator's stakes to [slashing](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/staking-and-rewards.md). +The specific mechanics and rules of the validator rewards regime is outlined here. Rewards are earned by delegating stake to a validator that is voting correctly. Voting incorrectly exposes that validator's stakes to [slashing](../proposals/slashing.md). ### Basics -The network pays rewards from a portion of network [inflation](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/inflation.md). The number of lamports available to pay rewards for an epoch is fixed and must be evenly divided among all staked nodes according to their relative stake weight and participation. The weighting unit is called a [point](../terminology.md#point). +The network pays rewards from a portion of network [inflation](../terminology.md#inflation). The number of lamports available to pay rewards for an epoch is fixed and must be evenly divided among all staked nodes according to their relative stake weight and participation. The weighting unit is called a [point](../terminology.md#point). Rewards for an epoch are not available until the end of that epoch. diff --git a/book/src/implemented-proposals/commitment.md b/book/src/implemented-proposals/commitment.md index 72f274ac1..4bd86c42f 100644 --- a/book/src/implemented-proposals/commitment.md +++ b/book/src/implemented-proposals/commitment.md @@ -28,7 +28,7 @@ lockout on a bank `b`. This computation is performed on a votable candidate bank `b` as follows. -``` +```text let output: HashMap = HashMap::new(); for vote_account in b.vote_accounts { for v in vote_account.vote_stack { @@ -62,7 +62,7 @@ votes > v as the number of confirmations will be lower). Now more specifically, we augment the above computation to: -``` +```text let output: HashMap = HashMap::new(); let fork_commitment_cache = ForkCommitmentCache::default(); for vote_account in b.vote_accounts { @@ -76,7 +76,7 @@ Now more specifically, we augment the above computation to: ``` where `f'` is defined as: -``` +```text fn f`( stake_lockout: &mut StakeLockout, some_ancestor: &mut BlockCommitment, diff --git a/book/src/implemented-proposals/ed_overview/README.md b/book/src/implemented-proposals/ed_overview/README.md index 090c16bca..b732d5665 100644 --- a/book/src/implemented-proposals/ed_overview/README.md +++ b/book/src/implemented-proposals/ed_overview/README.md @@ -10,7 +10,6 @@ These protocol-based rewards, to be distributed to participating validation and Transaction fees are market-based participant-to-participant transfers, attached to network interactions as a necessary motivation and compensation for the inclusion and execution of a proposed transaction \(be it a state execution or proof-of-replication verification\). A mechanism for long-term economic stability and forking protection through partial burning of each transaction fee is also discussed below. -A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics/), [State-validation Protocol-based Rewards](ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. Additionally, in [Storage Rent Economics](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_storage_rent_economics.md), we describe an implementation of storage rent to account for the externality costs of maintaining the active state of the ledger. The [Replication-client Economics](ed_replication_client_economics/) chapter will review the Solana network design for global ledger storage/redundancy and archiver-client economics \([Storage-replication rewards](ed_replication_client_economics/ed_rce_storage_replication_rewards.md)\) along with an archiver-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md). An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section. Finally, in chapter [Attack Vectors](ed_attack_vectors.md), various attack vectors will be described and potential vulnerabilities explored and parameterized. +A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics/), [State-validation Protocol-based Rewards](ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. Additionally, in [Storage Rent Economics](ed_storage_rent_economics.md), we describe an implementation of storage rent to account for the externality costs of maintaining the active state of the ledger. The [Replication-client Economics](ed_replication_client_economics/) chapter will review the Solana network design for global ledger storage/redundancy and archiver-client economics \([Storage-replication rewards](ed_replication_client_economics/ed_rce_storage_replication_rewards.md)\) along with an archiver-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md). An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section. Finally, in chapter [Attack Vectors](ed_attack_vectors.md), various attack vectors will be described and potential vulnerabilities explored and parameterized. **Figure 1**: Schematic overview of Solana economic incentive design. - diff --git a/book/src/ed_storage_rent_economics.md b/book/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md similarity index 100% rename from book/src/ed_storage_rent_economics.md rename to book/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md diff --git a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md b/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md index a4a2d0ac6..dfeddbf99 100644 --- a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md +++ b/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md @@ -8,5 +8,4 @@ While replication-clients are incentivized and rewarded through protocol-based r The validation of PoReps by validation-clients is computationally more expensive than state-validation \(detail in the [Economic Sustainability](../ed_economic_sustainability.md) chapter\), thus the transaction fees are expected to be proportionally higher. -There are various attack vectors available for colluding validation and replication clients, also described in detail below in [Economic Sustainability](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_economic_sustainability/README.md). To protect against various collusion attack vectors, for a given epoch, validator rewards are distributed across participating validation-clients in proportion to the number of validated PoReps in the epoch less the number of PoReps that mismatch the archivers challenge. The PoRep challenge game is described in [Ledger Replication](https://github.com/solana-labs/solana/blob/master/book/src/ledger-replication.md#the-porep-game). This design rewards validators proportional to the number of PoReps they process and validate, while providing negative pressure for validation-clients to submit lazy or malicious invalid votes on submitted PoReps \(note that it is computationally prohibitive to determine whether a validator-client has marked a valid PoRep as invalid\). - +There are various attack vectors available for colluding validation and replication clients, also described in detail below in [Economic Sustainability](../ed_economic_sustainability/README.md). To protect against various collusion attack vectors, for a given epoch, validator rewards are distributed across participating validation-clients in proportion to the number of validated PoReps in the epoch less the number of PoReps that mismatch the archivers challenge. The PoRep challenge game is described in [Ledger Replication](https://github.com/solana-labs/solana/blob/master/book/src/ledger-replication.md#the-porep-game). This design rewards validators proportional to the number of PoReps they process and validate, while providing negative pressure for validation-clients to submit lazy or malicious invalid votes on submitted PoReps \(note that it is computationally prohibitive to determine whether a validator-client has marked a valid PoRep as invalid\). diff --git a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md b/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md index a9903cb45..231f7c404 100644 --- a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md +++ b/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md @@ -11,7 +11,7 @@ Validator-client rewards for these services are to be distributed at the end of The effective protocol-based annual interest rate \(%\) per epoch received by validation-clients is to be a function of: -* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_validartion_client_economics.md)\) +* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](.)\) * the fraction of staked SOLs out of the current total circulating supply, * the up-time/participation \[% of available slots that validator had opportunity to vote on\] of a given validator over the previous epoch. diff --git a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md b/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md index 2c82158fa..fdb35a61b 100644 --- a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md +++ b/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md @@ -13,7 +13,6 @@ Many current blockchain economies \(e.g. Bitcoin, Ethereum\), rely on protocol-b Transaction fees are set by the network cluster based on recent historical throughput, see [Congestion Driven Fees](../../transaction-fees.md#congestion-driven-fees). This minimum portion of each transaction fee can be dynamically adjusted depending on historical gas usage. In this way, the protocol can use the minimum fee to target a desired hardware utilisation. By monitoring a protocol specified gas usage with respect to a desired, target usage amount, the minimum fee can be raised/lowered which should, in turn, lower/raise the actual gas usage per block until it reaches the target amount. This adjustment process can be thought of as similar to the difficulty adjustment algorithm in the Bitcoin protocol, however in this case it is adjusting the minimum transaction fee to guide the transaction processing hardware usage to a desired level. -As mentioned, a fixed-proportion of each transaction fee is to be destroyed. The intent of this design is to retain leader incentive to include as many transactions as possible within the leader-slot time, while providing an inflation limiting mechansim that protects against "tax evasion" attacks \(i.e. side-channel fee payments\)[1](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_referenced.md). +As mentioned, a fixed-proportion of each transaction fee is to be destroyed. The intent of this design is to retain leader incentive to include as many transactions as possible within the leader-slot time, while providing an inflation limiting mechansim that protects against "tax evasion" attacks \(i.e. side-channel fee payments\)[1](../ed_references.md). Additionally, the burnt fees can be a consideration in fork selection. In the case of a PoH fork with a malicious, censoring leader, we would expect the total fees destroyed to be less than a comparable honest fork, due to the fees lost from censoring. If the censoring leader is to compensate for these lost protocol fees, they would have to replace the burnt fees on their fork themselves, thus potentially reducing the incentive to censor in the first place. - diff --git a/book/src/implemented-proposals/tower-bft.md b/book/src/implemented-proposals/tower-bft.md index 8acf2f12b..f09cdd9e8 100644 --- a/book/src/implemented-proposals/tower-bft.md +++ b/book/src/implemented-proposals/tower-bft.md @@ -12,7 +12,7 @@ For brevity this design assumes that a single voter with a stake is deployed as ## Time -The Solana cluster generates a source of time via a Verifiable Delay Function we are calling [Proof of History](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/book/src/synchronization.md). +The Solana cluster generates a source of time via a Verifiable Delay Function we are calling [Proof of History](../cluster/synchronization.md). Proof of History is used to create a deterministic round robin schedule for all the active leaders. At any given time only 1 leader, which can be computed from the ledger itself, can propose a fork. For more details, see [fork generation](../cluster/fork-generation.md) and [leader rotation](../cluster/leader-rotation.md). @@ -109,7 +109,7 @@ When evaluating multiple forks, each validator should use the following rules: 3. Pick the fork that has the greatest amount of cluster transaction fees. 4. Pick the latest fork in terms of PoH. -Cluster transaction fees are fees that are deposited to the mining pool as described in the [Staking Rewards](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/book/src/staking-rewards.md) section. +Cluster transaction fees are fees that are deposited to the mining pool as described in the [Staking Rewards](staking-rewards.md) section. ## PoH ASIC Resistance @@ -134,4 +134,3 @@ An attacker generates a concurrent fork from an older block to try to rollback t * 3 votes have a lockout of 8 slots. Concurrent fork must be at least 8 slots ahead and produced in 3 slots. Therefore requires an ASIC 2.6x faster. * 10 votes have a lockout of 1024 slots. 1024/10, or 102.4x faster ASIC. * 20 votes have a lockout of 2^20 slots. 2^20/20, or 52,428.8x faster ASIC. - diff --git a/book/src/proposals/bankless-leader.md b/book/src/proposals/bankless-leader.md index 53334a0fb..889266ad2 100644 --- a/book/src/proposals/bankless-leader.md +++ b/book/src/proposals/bankless-leader.md @@ -10,7 +10,7 @@ When replay stage starts processing the same transactions, it can assume that Po ## Fee Account -The [fee account](https://github.com/solana-labs/solana/tree/b5f7a4bff9953415b1f3d385bd59bc65c1ec11a4/book/src/proposals/terminology.md#fee_account) pays for the transaction to be included in the block. The leader only needs to validate that the fee account has the balance to pay for the fee. +The [fee account](../terminology.md#fee_account) pays for the transaction to be included in the block. The leader only needs to validate that the fee account has the balance to pay for the fee. ## Balance Cache @@ -53,4 +53,3 @@ The same fee account can be reused many times in the same block until it is used Clients that transmit a large number of transactions per second should use a dedicated fee account that is not used as Credit-Debit in any instruction. Once an account fee is used as Credit-Debit, it will fail the balance check until the balance cache is reset. - diff --git a/book/src/block-confirmation.md b/book/src/proposals/block-confirmation.md similarity index 100% rename from book/src/block-confirmation.md rename to book/src/proposals/block-confirmation.md diff --git a/book/src/proposals/simple-payment-and-state-verification.md b/book/src/proposals/simple-payment-and-state-verification.md index 3e15fb252..641bb11db 100644 --- a/book/src/proposals/simple-payment-and-state-verification.md +++ b/book/src/proposals/simple-payment-and-state-verification.md @@ -91,11 +91,11 @@ LightEntry { The light entries are reconstructed from Entries and simply show the entry Merkle Root that was mixed in to the PoH hash, instead of the full transaction set. -Clients do not need the starting vote state. The [fork selection](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/book/src/fork-selection.md) algorithm is defined such that only votes that appear after the transaction provide finality for the transaction, and finality is independent of the starting state. +Clients do not need the starting vote state. The [fork selection](../implemented-proposals/tower-bft.md) algorithm is defined such that only votes that appear after the transaction provide finality for the transaction, and finality is independent of the starting state. ### Verification -A light client that is aware of the supermajority set validators can verify a receipt by following the Merkle Path to the PoH chain. The Bank-Merkle is the Merkle Root and will appear in votes included in an Entry. The light client can simulate [fork selection](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/book/src/fork-selection.md) for the consecutive votes and verify that the receipt is confirmed at the desired lockout threshold. +A light client that is aware of the supermajority set validators can verify a receipt by following the Merkle Path to the PoH chain. The Bank-Merkle is the Merkle Root and will appear in votes included in an Entry. The light client can simulate [fork selection](../implemented-proposals/tower-bft.md) for the consecutive votes and verify that the receipt is confirmed at the desired lockout threshold. ### Synthetic State diff --git a/book/src/proposals/tick_verification.md b/book/src/proposals/tick-verification.md similarity index 100% rename from book/src/proposals/tick_verification.md rename to book/src/proposals/tick-verification.md diff --git a/book/src/terminology.md b/book/src/terminology.md index 648b7258a..43bdd6e4f 100644 --- a/book/src/terminology.md +++ b/book/src/terminology.md @@ -112,6 +112,10 @@ The configuration file that prepares the [ledger](terminology.md#ledger) for the A digital fingerprint of a sequence of bytes. +## inflation + +The increase in token supply over time used by the network to incentivize validation and replication, and to fund continued development of the network. + ## instruction The smallest unit of a [program](terminology.md#program) that a [client](terminology.md#client) can include in a [transaction](terminology.md#instruction).