diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d9d30ea47554d0..611cab342dc9f6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -58,7 +58,6 @@ * [Fork Generation](cluster/fork-generation.md) * [Managing Forks](cluster/managing-forks.md) * [Turbine Block Propagation](cluster/turbine-block-propagation.md) - * [Ledger Replication](cluster/ledger-replication.md) * [Secure Vote Signing](cluster/vote-signing.md) * [Stake Delegation and Rewards](cluster/stake-delegation-and-rewards.md) * [Anatomy of a Validator](validator/README.md) @@ -75,14 +74,9 @@ * [Validation-client Economics](implemented-proposals/ed_overview/ed_validation_client_economics/README.md) * [State-validation Protocol-based Rewards](implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md) * [State-validation Transaction Fees](implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md) - * [Replication-validation Transaction Fees](implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md) * [Validation Stake Delegation](implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md) - * [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) * [References](implemented-proposals/ed_overview/ed_references.md) * [Deterministic Transaction Fees](implemented-proposals/transaction-fees.md) @@ -102,7 +96,6 @@ * [Commitment](implemented-proposals/commitment.md) * [Snapshot Verification](implemented-proposals/snapshot-verification.md) * [Accepted Design Proposals](proposals/README.md) - * [Ledger Replication](proposals/ledger-replication-to-implement.md) * [Secure Vote Signing](proposals/vote-signing-to-implement.md) * [Cluster Test Framework](proposals/cluster-test-framework.md) * [Validator](proposals/validator-proposal.md) diff --git a/src/cluster/README.md b/src/cluster/README.md index 298e77744bf4f8..3c34106563239a 100644 --- a/src/cluster/README.md +++ b/src/cluster/README.md @@ -4,17 +4,17 @@ A Solana cluster is a set of validators working together to serve client transac ## Creating a Cluster -Before starting any validators, one first needs to create a _genesis config_. The config references two public keys, a _mint_ and a _bootstrap validator_. The validator holding the bootstrap validator's private key is responsible for appending the first entries to the ledger. It initializes its internal state with the mint's account. That account will hold the number of native tokens defined by the genesis config. The second validator then contacts the bootstrap validator to register as a _validator_ or _archiver_. Additional validators then register with any registered member of the cluster. +Before starting any validators, one first needs to create a _genesis config_. The config references two public keys, a _mint_ and a _bootstrap validator_. The validator holding the bootstrap validator's private key is responsible for appending the first entries to the ledger. It initializes its internal state with the mint's account. That account will hold the number of native tokens defined by the genesis config. The second validator then contacts the bootstrap validator to register as a _validator_. Additional validators then register with any registered member of the cluster. -A validator receives all entries from the leader and submits votes confirming those entries are valid. After voting, the validator is expected to store those entries until archiver nodes submit proofs that they have stored copies of it. Once the validator observes a sufficient number of copies exist, it deletes its copy. +A validator receives all entries from the leader and submits votes confirming those entries are valid. After voting, the validator is expected to store those entries. Once the validator observes a sufficient number of copies exist, it deletes its copy. ## Joining a Cluster -Validators and archivers enter the cluster via registration messages sent to its _control plane_. The control plane is implemented using a _gossip_ protocol, meaning that a node may register with any existing node, and expect its registration to propagate to all nodes in the cluster. The time it takes for all nodes to synchronize is proportional to the square of the number of nodes participating in the cluster. Algorithmically, that's considered very slow, but in exchange for that time, a node is assured that it eventually has all the same information as every other node, and that that information cannot be censored by any one node. +Validators enter the cluster via registration messages sent to its _control plane_. The control plane is implemented using a _gossip_ protocol, meaning that a node may register with any existing node, and expect its registration to propagate to all nodes in the cluster. The time it takes for all nodes to synchronize is proportional to the square of the number of nodes participating in the cluster. Algorithmically, that's considered very slow, but in exchange for that time, a node is assured that it eventually has all the same information as every other node, and that that information cannot be censored by any one node. ## Sending Transactions to a Cluster -Clients send transactions to any validator's Transaction Processing Unit \(TPU\) port. If the node is in the validator role, it forwards the transaction to the designated leader. If in the leader role, the node bundles incoming transactions, timestamps them creating an _entry_, and pushes them onto the cluster's _data plane_. Once on the data plane, the transactions are validated by validator nodes and replicated by archiver nodes, effectively appending them to the ledger. +Clients send transactions to any validator's Transaction Processing Unit \(TPU\) port. If the node is in the validator role, it forwards the transaction to the designated leader. If in the leader role, the node bundles incoming transactions, timestamps them creating an _entry_, and pushes them onto the cluster's _data plane_. Once on the data plane, the transactions are validated by validator nodes, effectively appending them to the ledger. ## Confirming Transactions diff --git a/src/cluster/ledger-replication.md b/src/cluster/ledger-replication.md deleted file mode 100644 index 34792ffd9eda0a..00000000000000 --- a/src/cluster/ledger-replication.md +++ /dev/null @@ -1,269 +0,0 @@ -# Ledger Replication - -At full capacity on a 1gbps network solana will generate 4 petabytes of data per year. To prevent the network from centralizing around validators that have to store the full data set this protocol proposes a way for mining nodes to provide storage capacity for pieces of the data. - -The basic idea to Proof of Replication is encrypting a dataset with a public symmetric key using CBC encryption, then hash the encrypted dataset. The main problem with the naive approach is that a dishonest storage node can stream the encryption and delete the data as it's hashed. The simple solution is to periodically regenerate the hash based on a signed PoH value. This ensures that all the data is present during the generation of the proof and it also requires validators to have the entirety of the encrypted data present for verification of every proof of every identity. So the space required to validate is `number_of_proofs * data_size` - -## Optimization with PoH - -Our improvement on this approach is to randomly sample the encrypted segments faster than it takes to encrypt, and record the hash of those samples into the PoH ledger. Thus the segments stay in the exact same order for every PoRep and verification can stream the data and verify all the proofs in a single batch. This way we can verify multiple proofs concurrently, each one on its own CUDA core. The total space required for verification is `1_ledger_segment + 2_cbc_blocks * number_of_identities` with core count equal to `number_of_identities`. We use a 64-byte chacha CBC block size. - -## Network - -Validators for PoRep are the same validators that are verifying transactions. If an archiver can prove that a validator verified a fake PoRep, then the validator will not receive a reward for that storage epoch. - -Archivers are specialized _light clients_. They download a part of the ledger \(a.k.a Segment\) and store it, and provide PoReps of storing the ledger. For each verified PoRep archivers earn a reward of sol from the mining pool. - -## Constraints - -We have the following constraints: - -* Verification requires generating the CBC blocks. That requires space of 2 - - blocks per identity, and 1 CUDA core per identity for the same dataset. So as - - many identities at once should be batched with as many proofs for those - - identities verified concurrently for the same dataset. - -* Validators will randomly sample the set of storage proofs to the set that - - they can handle, and only the creators of those chosen proofs will be - - rewarded. The validator can run a benchmark whenever its hardware configuration - - changes to determine what rate it can validate storage proofs. - -## Validation and Replication Protocol - -### Constants - -1. SLOTS\_PER\_SEGMENT: Number of slots in a segment of ledger data. The - - unit of storage for an archiver. - -2. NUM\_KEY\_ROTATION\_SEGMENTS: Number of segments after which archivers - - regenerate their encryption keys and select a new dataset to store. - -3. NUM\_STORAGE\_PROOFS: Number of storage proofs required for a storage proof - - claim to be successfully rewarded. - -4. RATIO\_OF\_FAKE\_PROOFS: Ratio of fake proofs to real proofs that a storage - - mining proof claim has to contain to be valid for a reward. - -5. NUM\_STORAGE\_SAMPLES: Number of samples required for a storage mining - - proof. - -6. NUM\_CHACHA\_ROUNDS: Number of encryption rounds performed to generate - - encrypted state. - -7. NUM\_SLOTS\_PER\_TURN: Number of slots that define a single storage epoch or - - a "turn" of the PoRep game. - -### Validator behavior - -1. Validators join the network and begin looking for archiver accounts at each - - storage epoch/turn boundary. - -2. Every turn, Validators sign the PoH value at the boundary and use that signature - - to randomly pick proofs to verify from each storage account found in the turn boundary. - - This signed value is also submitted to the validator's storage account and will be used by - - archivers at a later stage to cross-verify. - -3. Every `NUM_SLOTS_PER_TURN` slots the validator advertises the PoH value. This is value - - is also served to Archivers via RPC interfaces. - -4. For a given turn N, all validations get locked out until turn N+3 \(a gap of 2 turn/epoch\). - - At which point all validations during that turn are available for reward collection. - -5. Any incorrect validations will be marked during the turn in between. - -### Archiver behavior - -1. Since an archiver is somewhat of a light client and not downloading all the - - ledger data, they have to rely on other validators and archivers for information. - - Any given validator may or may not be malicious and give incorrect information, although - - there are not any obvious attack vectors that this could accomplish besides having the - - archiver do extra wasted work. For many of the operations there are a number of options - - depending on how paranoid an archiver is: - - * \(a\) archiver can ask a validator - * \(b\) archiver can ask multiple validators - * \(c\) archiver can ask other archivers - * \(d\) archiver can subscribe to the full transaction stream and generate - - the information itself \(assuming the slot is recent enough\) - - * \(e\) archiver can subscribe to an abbreviated transaction stream to - - generate the information itself \(assuming the slot is recent enough\) - -2. An archiver obtains the PoH hash corresponding to the last turn with its slot. -3. The archiver signs the PoH hash with its keypair. That signature is the - - seed used to pick the segment to replicate and also the encryption key. The - - archiver mods the signature with the slot to get which segment to - - replicate. - -4. The archiver retrives the ledger by asking peer validators and - - archivers. See 6.5. - -5. The archiver then encrypts that segment with the key with chacha algorithm - - in CBC mode with `NUM_CHACHA_ROUNDS` of encryption. - -6. The archiver initializes a chacha rng with the a signed recent PoH value as - - the seed. - -7. The archiver generates `NUM_STORAGE_SAMPLES` samples in the range of the - - entry size and samples the encrypted segment with sha256 for 32-bytes at each - - offset value. Sampling the state should be faster than generating the encrypted - - segment. - -8. The archiver sends a PoRep proof transaction which contains its sha state - - at the end of the sampling operation, its seed and the samples it used to the - - current leader and it is put onto the ledger. - -9. During a given turn the archiver should submit many proofs for the same segment - - and based on the `RATIO_OF_FAKE_PROOFS` some of those proofs must be fake. - -10. As the PoRep game enters the next turn, the archiver must submit a - - transaction with the mask of which proofs were fake during the last turn. This - - transaction will define the rewards for both archivers and validators. - -11. Finally for a turn N, as the PoRep game enters turn N + 3, archiver's proofs for - - turn N will be counted towards their rewards. - -### The PoRep Game - -The Proof of Replication game has 4 primary stages. For each "turn" multiple PoRep games can be in progress but each in a different stage. - -The 4 stages of the PoRep Game are as follows: - -1. Proof submission stage - * Archivers: submit as many proofs as possible during this stage - * Validators: No-op -2. Proof verification stage - * Archivers: No-op - * Validators: Select archivers and verify their proofs from the previous turn -3. Proof challenge stage - * Archivers: Submit the proof mask with justifications \(for fake proofs submitted 2 turns ago\) - * Validators: No-op -4. Reward collection stage - * Archivers: Collect rewards for 3 turns ago - * Validators: Collect rewards for 3 turns ago - -For each turn of the PoRep game, both Validators and Archivers evaluate each stage. The stages are run as separate transactions on the storage program. - -### Finding who has a given block of ledger - -1. Validators monitor the turns in the PoRep game and look at the rooted bank - - at turn boundaries for any proofs. - -2. Validators maintain a map of ledger segments and corresponding archiver public keys. - - The map is updated when a Validator processes an archiver's proofs for a segment. - - The validator provides an RPC interface to access the this map. Using this API, clients - - can map a segment to an archiver's network address \(correlating it via cluster\_info table\). - - The clients can then send repair requests to the archiver to retrieve segments. - -3. Validators would need to invalidate this list every N turns. - -## Sybil attacks - -For any random seed, we force everyone to use a signature that is derived from a PoH hash at the turn boundary. Everyone uses the same count, so the same PoH hash is signed by every participant. The signatures are then each cryptographically tied to the keypair, which prevents a leader from grinding on the resulting value for more than 1 identity. - -Since there are many more client identities then encryption identities, we need to split the reward for multiple clients, and prevent Sybil attacks from generating many clients to acquire the same block of data. To remain BFT we want to avoid a single human entity from storing all the replications of a single chunk of the ledger. - -Our solution to this is to force the clients to continue using the same identity. If the first round is used to acquire the same block for many client identities, the second round for the same client identities will force a redistribution of the signatures, and therefore PoRep identities and blocks. Thus to get a reward for archivers need to store the first block for free and the network can reward long lived client identities more than new ones. - -## Validator attacks - -* If a validator approves fake proofs, archiver can easily out them by - - showing the initial state for the hash. - -* If a validator marks real proofs as fake, no on-chain computation can be done - - to distinguish who is correct. Rewards would have to rely on the results from - - multiple validators to catch bad actors and archivers from being denied rewards. - -* Validator stealing mining proof results for itself. The proofs are derived - - from a signature from an archiver, since the validator does not know the - - private key used to generate the encryption key, it cannot be the generator of - - the proof. - -## Reward incentives - -Fake proofs are easy to generate but difficult to verify. For this reason, PoRep proof transactions generated by archivers may require a higher fee than a normal transaction to represent the computational cost required by validators. - -Some percentage of fake proofs are also necessary to receive a reward from storage mining. - -## Notes - -* We can reduce the costs of verification of PoRep by using PoH, and actually - - make it feasible to verify a large number of proofs for a global dataset. - -* We can eliminate grinding by forcing everyone to sign the same PoH hash and - - use the signatures as the seed - -* The game between validators and archivers is over random blocks and random - - encryption identities and random data samples. The goal of randomization is - - to prevent colluding groups from having overlap on data or validation. - -* Archiver clients fish for lazy validators by submitting fake proofs that - - they can prove are fake. - -* To defend against Sybil client identities that try to store the same block we - - force the clients to store for multiple rounds before receiving a reward. - -* Validators should also get rewarded for validating submitted storage proofs - - as incentive for storing the ledger. They can only validate proofs if they - - are storing that slice of the ledger. - diff --git a/src/cluster/synchronization.md b/src/cluster/synchronization.md index 6394de3fe68d66..cd51d27fe9f759 100644 --- a/src/cluster/synchronization.md +++ b/src/cluster/synchronization.md @@ -18,7 +18,7 @@ Another difference between PoH and VDFs is that a VDF is used only for tracking ## Relationship to Consensus Mechanisms -Proof of History is not a consensus mechanism, but it is used to improve the performance of Solana's Proof of Stake consensus. It is also used to improve the performance of the data plane and replication protocols. +Proof of History is not a consensus mechanism, but it is used to improve the performance of Solana's Proof of Stake consensus. It is also used to improve the performance of the data plane protocols. ## More on Proof of History diff --git a/src/implemented-proposals/ed_overview/README.md b/src/implemented-proposals/ed_overview/README.md index 165c2403c36ee2..d792e7669af7a3 100644 --- a/src/implemented-proposals/ed_overview/README.md +++ b/src/implemented-proposals/ed_overview/README.md @@ -2,15 +2,15 @@ **Subject to change.** -Solana’s crypto-economic system is designed to promote a healthy, long term self-sustaining economy with participant incentives aligned to the security and decentralization of the network. The main participants in this economy are validation-clients and replication-clients. Their contributions to the network, state validation and data storage respectively, and their requisite incentive mechanisms are discussed below. +Solana’s crypto-economic system is designed to promote a healthy, long term self-sustaining economy with participant incentives aligned to the security and decentralization of the network. The main participants in this economy are validation-clients. Their contributions to the network, state validation, and their requisite incentive mechanisms are discussed below. -The main channels of participant remittances are referred to as protocol-based rewards and transaction fees. Protocol-based rewards are issuances from a global, protocol-defined, inflation rate. These rewards will constitute the total reward delivered to replication and validation clients, the remaining sourced from transaction fees. In the early days of the network, it is likely that protocol-based rewards, deployed based on predefined issuance schedule, will drive the majority of participant incentives to participate in the network. +The main channels of participant remittances are referred to as protocol-based rewards and transaction fees. Protocol-based rewards are issuances from a global, protocol-defined, inflation rate. These rewards will constitute the total reward delivered to validation clients, the remaining sourced from transaction fees. In the early days of the network, it is likely that protocol-based rewards, deployed based on predefined issuance schedule, will drive the majority of participant incentives to participate in the network. -These protocol-based rewards, to be distributed to participating validation and replication clients, are to be a result of a global supply inflation rate, calculated per Solana epoch and distributed amongst the active validator set. As discussed further below, the per annum inflation rate is based on a pre-determined disinflationary schedule. This provides the network with monetary supply predictability which supports long term economic stability and security. +These protocol-based rewards, to be distributed to participating validation clients, are to be a result of a global supply inflation rate, calculated per Solana epoch and distributed amongst the active validator set. As discussed further below, the per annum inflation rate is based on a pre-determined disinflationary schedule. This provides the network with monetary supply predictability which supports long term economic stability and security. -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. +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. 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/README.md), [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 section titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunities 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. [Replication-client Economics](ed_replication_client_economics/README.md) 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 [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/README.md), [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). Also, the section titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunities 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. An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section. ![](../../.gitbook/assets/economic_design_infl_230719.png) diff --git a/src/implemented-proposals/ed_overview/ed_attack_vectors.md b/src/implemented-proposals/ed_overview/ed_attack_vectors.md deleted file mode 100644 index 419720f3d534e8..00000000000000 --- a/src/implemented-proposals/ed_overview/ed_attack_vectors.md +++ /dev/null @@ -1,14 +0,0 @@ -# Attack Vectors - -**Subject to change.** - -## Colluding validation and replication clients - -A colluding validation-client, may take the strategy to mark PoReps from non-colluding archiver nodes as invalid as an attempt to maximize the rewards for the colluding archiver nodes. In this case, it isn’t feasible for the offended-against archiver nodes to petition the network for resolution as this would result in a network-wide vote on each offending PoRep and create too much overhead for the network to progress adequately. Also, this mitigation attempt would still be vulnerable to a >= 51% staked colluder. - -Alternatively, transaction fees from submitted PoReps are pooled and distributed across validation-clients in proportion to the number of valid PoReps discounted by the number of invalid PoReps as voted by each validator-client. Thus invalid votes are directly dis-incentivized through this reward channel. Invalid votes that are revealed by archiver nodes as fishing PoReps, will not be discounted from the payout PoRep count. - -Another collusion attack involves a validator-client who may take the strategy to ignore invalid PoReps from colluding archiver and vote them as valid. In this case, colluding archiver-clients would not have to store the data while still receiving rewards for validated PoReps. Additionally, colluding validator nodes would also receive rewards for validating these PoReps. To mitigate this attack, validators must randomly sample PoReps corresponding to the ledger block they are validating and because of this, there will be multiple validators that will receive the colluding archiver’s invalid submissions. These non-colluding validators will be incentivized to mark these PoReps as invalid as they have no way to determine whether the proposed invalid PoRep is actually a fishing PoRep, for which a confirmation vote would result in the validator’s stake being slashed. - -In this case, the proportion of time a colluding pair will be successful has an upper limit determined by the % of stake of the network claimed by the colluding validator. This also sets bounds to the value of such an attack. For example, if a colluding validator controls 10% of the total validator stake, transaction fees will be lost \(likely sent to mining pool\) by the colluding archiver 90% of the time and so the attack vector is only profitable if the per-PoRep reward at least 90% higher than the average PoRep transaction fee. While, probabilistically, some colluding archiver-client PoReps will find their way to colluding validation-clients, the network can also monitor rates of paired \(validator + archiver\) discrepancies in voting patterns and censor identified colluders in these cases. - diff --git a/src/implemented-proposals/ed_overview/ed_economic_sustainability.md b/src/implemented-proposals/ed_overview/ed_economic_sustainability.md index 5f8b06d0550ed7..329ab6957f56f7 100644 --- a/src/implemented-proposals/ed_overview/ed_economic_sustainability.md +++ b/src/implemented-proposals/ed_overview/ed_economic_sustainability.md @@ -4,13 +4,4 @@ Long term economic sustainability is one of the guiding principles of Solana’s economic design. While it is impossible to predict how decentralized economies will develop over time, especially economies with flexible decentralized governances, we can arrange economic components such that, under certain conditions, a sustainable economy may take shape in the long term. In the case of Solana’s network, these components take the form of token issuance \(via inflation\) and token burning. -The dominant remittances from the Solana mining pool are validator and archiver rewards. The disinflationary mechanism is a flat, protocol-specified and adjusted, % of each transaction fee. - -The Archiver rewards are to be delivered to archivers as a portion of the network inflation after successful PoRep validation. The per-PoRep reward amount is determined as a function of the total network storage redundancy at the time of the PoRep validation and the network goal redundancy. This function is likely to take the form of a discount from a base reward to be delivered when the network has achieved and maintained its goal redundancy. An example of such a reward function is shown in **Figure 1** - -![](../../.gitbook/assets/porep_reward.png) - -**Figure 1**: Example PoRep reward design as a function of global network storage redundancy. - -In the example shown in **Figure 1**, multiple per PoRep base rewards are explored \(as a % of Tx Fee\) to be delivered when the global ledger replication redundancy meets 10X. When the global ledger replication redundancy is less than 10X, the base reward is discounted as a function of the square of the ratio of the actual ledger replication redundancy to the goal redundancy \(i.e. 10X\). - +The dominant remittances from the Solana mining pool are validator rewards. The disinflationary mechanism is a flat, protocol-specified and adjusted, % of each transaction fee. diff --git a/src/implemented-proposals/ed_overview/ed_mvp.md b/src/implemented-proposals/ed_overview/ed_mvp.md index 77fb33e3018a8d..a57b3b42e6bb08 100644 --- a/src/implemented-proposals/ed_overview/ed_mvp.md +++ b/src/implemented-proposals/ed_overview/ed_mvp.md @@ -10,7 +10,3 @@ The preceding sections, outlined in the [Economic Design Overview](../README.md) * Mechanism by which validators are rewarded via network inflation. * Ability to delegate tokens to validator nodes * Validator set commission fees on interest from delegated tokens. -* Archivers to receive fixed, arbitrary reward for submitting validated PoReps. Reward size mechanism \(i.e. PoRep reward as a function of total ledger redundancy\) to come later. -* Pooling of archiver PoRep transaction fees and weighted distribution to validators based on PoRep verification \(see [Replication-validation Transaction Fees](ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md). It will be useful to test this protection against attacks on testnet. -* Nice-to-have: auto-delegation of archiver rewards to validator. - diff --git a/src/implemented-proposals/ed_overview/ed_replication_client_economics/README.md b/src/implemented-proposals/ed_overview/ed_replication_client_economics/README.md deleted file mode 100644 index e61d34f265206d..00000000000000 --- a/src/implemented-proposals/ed_overview/ed_replication_client_economics/README.md +++ /dev/null @@ -1,6 +0,0 @@ -# Replication-client Economics - -**Subject to change.** - -Replication-clients should be rewarded for providing the network with storage space. Incentivization of the set of archivers provides data security through redundancy of the historical ledger. Replication nodes are rewarded in proportion to the amount of ledger data storage provided, as proved by successfully submitting Proofs-of-Replication to the cluster.. These rewards are captured by generating and entering Proofs of Replication \(PoReps\) into the PoH stream which can be validated by Validation nodes as described in [Replication-validation Transaction Fees](../ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md). - diff --git a/src/implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md b/src/implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md deleted file mode 100644 index 8d4f5e1c5cbe07..00000000000000 --- a/src/implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md +++ /dev/null @@ -1,8 +0,0 @@ -# Replication-client Reward Auto-delegation - -**Subject to change.** - -The ability for Solana network participants to earn rewards by providing storage service is a unique on-boarding path that requires little hardware overhead and minimal upfront capital. It offers an avenue for individuals with extra-storage space on their home laptops or PCs to contribute to the security of the network and become integrated into the Solana economy. - -To enhance this on-boarding ramp and facilitate further participation and investment in the Solana economy, replication-clients have the opportunity to auto-delegate their rewards to validation-clients of their choice. Much like the automatic reinvestment of stock dividends, in this scenario, an archiver-client can earn Solana tokens by providing some storage capacity to the network \(i.e. via submitting valid PoReps\), have the protocol-based rewards automatically assigned as delegation to a staked validator node of the archiver's choice and earn interest, less a fee, from the validation-client's network participation. - diff --git a/src/implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_storage_replication_rewards.md b/src/implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_storage_replication_rewards.md deleted file mode 100644 index 9deda4cbdef0f1..00000000000000 --- a/src/implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_storage_replication_rewards.md +++ /dev/null @@ -1,8 +0,0 @@ -# Storage-replication Rewards - -**Subject to change.** - -Archiver-clients download, encrypt and submit PoReps for ledger block sections.3 PoReps submitted to the PoH stream, and subsequently validated, function as evidence that the submitting archiver client is indeed storing the assigned ledger block sections on local hard drive space as a service to the network. Therefore, archiver clients should earn protocol rewards proportional to the amount of storage, and the number of successfully validated PoReps, that they are verifiably providing to the network. - -Additionally, archiver clients have the opportunity to capture a portion of slashed bounties \[TBD\] of dishonest validator clients. This can be accomplished by an archiver client submitting a verifiably false PoRep for which a dishonest validator client receives and signs as a valid PoRep. This reward incentive is to prevent lazy validators and minimize validator-archiver collusion attacks, more on this below. - diff --git a/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md b/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md index 0968e3531aff50..40da25e2703b32 100644 --- a/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md +++ b/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md @@ -1,6 +1,6 @@ ## Storage Rent Economics -Each transaction that is submitted to the Solana ledger imposes costs. Transaction fees paid by the submitter, and collected by a validator, in theory, account for the acute, transactional, costs of validating and adding that data to the ledger. At the same time, our compensation design for archivers (see [Replication-client Economics](ed_replication_client_economics/README.md)), in theory, accounts for the long term storage of the historical ledger. Unaccounted in this process is the mid-term storage of active ledger state, necessarily maintained by the rotating validator set. This type of storage imposes costs not only to validators but also to the broader network as active state grows so does data transmission and validation overhead. To account for these costs, we describe here our preliminary design and implementation of storage rent. +Each transaction that is submitted to the Solana ledger imposes costs. Transaction fees paid by the submitter, and collected by a validator, in theory, account for the acute, transactional, costs of validating and adding that data to the ledger. Unaccounted in this process is the mid-term storage of active ledger state, necessarily maintained by the rotating validator set. This type of storage imposes costs not only to validators but also to the broader network as active state grows so does data transmission and validation overhead. To account for these costs, we describe here our preliminary design and implementation of storage rent. Storage rent can be paid via one of two methods: diff --git a/src/implemented-proposals/ed_overview/ed_validation_client_economics/README.md b/src/implemented-proposals/ed_overview/ed_validation_client_economics/README.md index ec5413ed06bde9..b371a0c3fdf52f 100644 --- a/src/implemented-proposals/ed_overview/ed_validation_client_economics/README.md +++ b/src/implemented-proposals/ed_overview/ed_validation_client_economics/README.md @@ -2,7 +2,7 @@ **Subject to change.** -Validator-clients are eligible to receive protocol-based \(i.e. inflation-based\) rewards issued via stake-based annual interest rates \(calculated per epoch\) by providing compute \(CPU+GPU\) resources to validate and vote on a given PoH state. These protocol-based rewards are determined through an algorithmic disinflationary schedule as a function of total amount of circulating tokens. The network is expected to launch with an annual inflation rate around 15%, set to decrease by 15% per year until a long-term stable rate of 1-2% is reached. These issuances are to be split and distributed to participating validators and archivers, with around 90% of the issued tokens allocated for validator rewards. Because the network will be distributing a fixed amount of inflation rewards across the stake-weighted valdiator set, any individual validator's interest rate will be a function of the amount of staked SOL in relation to the circulating SOL. +Validator-clients are eligible to receive protocol-based \(i.e. inflation-based\) rewards issued via stake-based annual interest rates \(calculated per epoch\) by providing compute \(CPU+GPU\) resources to validate and vote on a given PoH state. These protocol-based rewards are determined through an algorithmic disinflationary schedule as a function of total amount of circulating tokens. The network is expected to launch with an annual inflation rate around 15%, set to decrease by 15% per year until a long-term stable rate of 1-2% is reached. These issuances are to be split and distributed to participating validators, with around 90% of the issued tokens allocated for validator rewards. Because the network will be distributing a fixed amount of inflation rewards across the stake-weighted validator set, any individual validator's interest rate will be a function of the amount of staked SOL in relation to the circulating SOL. -Additionally, validator clients may earn revenue through fees via state-validation transactions and Proof-of-Replication \(PoRep\) transactions. For clarity, we separately describe the design and motivation of these revenue distriubutions for validation-clients below: state-validation protocol-based rewards, state-validation transaction fees and rent, and PoRep-validation transaction fees. +Additionally, validator clients may earn revenue through fees via state-validation transactions. For clarity, we separately describe the design and motivation of these revenue distributions for validation-clients below: state-validation protocol-based rewards and state-validation transaction fees and rent. diff --git a/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md b/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md deleted file mode 100644 index a15044890a979c..00000000000000 --- a/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md +++ /dev/null @@ -1,11 +0,0 @@ -# Replication-validation Transaction Fees - -**Subject to change.** - -As previously mentioned, validator-clients will also be responsible for validating PoReps submitted into the PoH stream by archiver-clients. In this case, validators are providing compute \(CPU/GPU\) and light storage resources to confirm that these replication proofs could only be generated by a client that is storing the referenced PoH leger block. - -While replication-clients are incentivize and rewarded through protocol-based rewards schedule \(see [Replication-client Economics](../ed_replication_client_economics/README.md)\), validator-clients will be incentivized to include and validate PoReps in PoH through collection of transaction fees associated with the submitted PoReps and distribution of protocol rewards proportional to the validated PoReps. As will be described in detail in the Section 3.1, replication-client rewards are protocol-based and designed to reward based on a global data redundancy factor. I.e. the protocol will incentivize replication-client participation through rewards based on a target ledger redundancy \(e.g. 10x data redundancy\). - -The validation of PoReps by validation-clients is computationally more expensive than state-validation \(detailed in the [Economic Sustainability](../ed_economic_sustainability.md) section\), 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 in [Economic Sustainability](../ed_economic_sustainability.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](../../../cluster/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/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md b/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md index ea48ef4d414f5e..0e4e9835bcb984 100644 --- a/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md +++ b/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md @@ -4,10 +4,10 @@ Validator-clients have two functional roles in the Solana network: -* Validate \(vote\) the current global state of that PoH along with any Proofs-of-Replication \(see [Replication Client Economics](../ed_replication_client_economics/README.md)\) that they are eligible to validate. -* Be elected as ‘leader’ on a stake-weighted round-robin schedule during which time they are responsible for collecting outstanding transactions and Proofs-of-Replication and incorporating them into the PoH, thus updating the global state of the network and providing chain continuity. +* Validate \(vote\) the current global state of that PoH. +* Be elected as ‘leader’ on a stake-weighted round-robin schedule during which time they are responsible for collecting outstanding transactions and incorporating them into the PoH, thus updating the global state of the network and providing chain continuity. -Validator-client rewards for these services are to be distributed at the end of each Solana epoch. As previously discussed, compensation for validator-clients is provided via a protocol-based annual inflation rate dispersed in proportion to the stake-weight of each validator \(see below\) along with leader-claimed transaction fees available during each leader rotation. I.e. during the time a given validator-client is elected as leader, it has the opportunity to keep a portion of each transaction fee, less a protocol-specified amount that is destroyed \(see [Validation-client State Transaction Fees](ed_vce_state_validation_transaction_fees.md)\). PoRep transaction fees are also collected by the leader client and validator PoRep rewards are distributed in proportion to the number of validated PoReps less the number of PoReps that mismatch an archiver's challenge. \(see [Replication-client Transaction Fees](ed_vce_replication_validation_transaction_fees.md)\) +Validator-client rewards for these services are to be distributed at the end of each Solana epoch. As previously discussed, compensation for validator-clients is provided via a protocol-based annual inflation rate dispersed in proportion to the stake-weight of each validator \(see below\) along with leader-claimed transaction fees available during each leader rotation. I.e. during the time a given validator-client is elected as leader, it has the opportunity to keep a portion of each transaction fee, less a protocol-specified amount that is destroyed \(see [Validation-client State Transaction Fees](ed_vce_state_validation_transaction_fees.md)\). The effective protocol-based annual interest rate \(%\) per epoch received by validation-clients is to be a function of: @@ -25,7 +25,7 @@ At any given point in time, a specific validator's interest rate can be determin ![](../../../.gitbook/assets/p_ex_supply.png) -**Figure 2:** The total token supply over a 10-year period, based on an initial 250MM tokens with the disinflationary inflation schedule as shown in **Figure 1**. Over time, the interest rate, at a fixed network staked percentage, will reduce concordant with network inflation. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. As previously mentioned, the inflation rate is expected to stabilize near 1-2% which also results in a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for state-validation and ledger storage replication \(PoReps\) are not accounted for here. Given these example parameters, annualized validator-specific interest rates can be determined based on the global fraction of tokens bonded as stake, as well as their uptime/activity in the previous epoch. For the purpose of this example, we assume 100% uptime for all validators and a split in interest-based rewards between validators and archiver nodes of 80%/20%. Additionally, the fraction of staked circulating supply is assumed to be constant. Based on these assumptions, an annualized validation-client interest rate schedule as a function of % circulating token supply that is staked is shown in **Figure 3**. +**Figure 2:** The total token supply over a 10-year period, based on an initial 250MM tokens with the disinflationary inflation schedule as shown in **Figure 1**. Over time, the interest rate, at a fixed network staked percentage, will reduce concordant with network inflation. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. As previously mentioned, the inflation rate is expected to stabilize near 1-2% which also results in a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for state-validation are not accounted for here. Given these example parameters, annualized validator-specific interest rates can be determined based on the global fraction of tokens bonded as stake, as well as their uptime/activity in the previous epoch. For the purpose of this example, we assume 100% uptime for all validators and a split in interest-based rewards between validators nodes of 80%/20%. Additionally, the fraction of staked circulating supply is assumed to be constant. Based on these assumptions, an annualized validation-client interest rate schedule as a function of % circulating token supply that is staked is shown in **Figure 3**. ![](../../../.gitbook/assets/p_ex_interest.png) diff --git a/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md b/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md index 2a0fa38a8436cf..0024519b82669d 100644 --- a/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md +++ b/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md @@ -9,7 +9,7 @@ Each transaction sent through the network, to be processed by the current leader * open avenues for a transaction market to incentivize validation-client to collect and process submitted transactions in their function as leader, * and provide potential long-term economic stability of the network through a protocol-captured minimum fee amount per transaction, as described below. -Many current blockchain economies \(e.g. Bitcoin, Ethereum\), rely on protocol-based rewards to support the economy in the short term, with the assumption that the revenue generated through transaction fees will support the economy in the long term, when the protocol derived rewards expire. In an attempt to create a sustainable economy through protocol-based rewards and transaction fees, a fixed portion of each transaction fee is destroyed, with the remaining fee going to the current leader processing the transaction. A scheduled global inflation rate provides a source for rewards distributed to validation-clients, through the process described above, and replication-clients, as discussed below. +Many current blockchain economies \(e.g. Bitcoin, Ethereum\), rely on protocol-based rewards to support the economy in the short term, with the assumption that the revenue generated through transaction fees will support the economy in the long term, when the protocol derived rewards expire. In an attempt to create a sustainable economy through protocol-based rewards and transaction fees, a fixed portion of each transaction fee is destroyed, with the remaining fee going to the current leader processing the transaction. A scheduled global inflation rate provides a source for rewards distributed to validation-clients, through the process described above. 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 utilization. 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. diff --git a/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md b/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md index 9490875102df98..186440613c743b 100644 --- a/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md +++ b/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md @@ -21,12 +21,7 @@ Running a Solana validation-client required relatively modest upfront hardware c **Table 2** example high-end hardware setup for running a Solana client. -Despite the low-barrier to entry as a validation-client, from a capital investment perspective, as in any developing economy, there will be much opportunity and need for trusted validation services as evidenced by node reliability, UX/UI, APIs and other software accessibility tools. Additionally, although Solana’s validator node startup costs are nominal when compared to similar networks, they may still be somewhat restrictive for some potential participants. In the spirit of developing a true decentralized, permissionless network, these interested parties still have two options to become involved in the Solana network/economy: +Despite the low-barrier to entry as a validation-client, from a capital investment perspective, as in any developing economy, there will be much opportunity and need for trusted validation services as evidenced by node reliability, UX/UI, APIs and other software accessibility tools. Additionally, although Solana’s validator node startup costs are nominal when compared to similar networks, they may still be somewhat restrictive for some potential participants. In the spirit of developing a true decentralized, permissionless network, these interested parties can become involved in the Solana network/economy via delegation of previously acquired tokens with a reliable validation node to earn a portion of the interest generated. -1. Delegation of previously acquired tokens with a reliable validation node to earn a portion of interest generated -2. Provide local storage space as a replication-client and receive rewards by submitting Proof-of-Replication \(see [Replication-client Economics](../ed_replication_client_economics/README.md)\). - - a. This participant has the additional option to directly delegate their earned storage rewards \([Replication-client Reward Auto-delegation](../ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md)\) - -Delegation of tokens to validation-clients, via option 1, provides a way for passive Solana token holders to become part of the active Solana economy and earn interest rates proportional to the interest rate generated by the delegated validation-client. Additionally, this feature intends to create a healthy validation-client market, with potential validation-client nodes competing to build reliable, transparent and profitable delegation services. +Delegation of tokens to validation-clients provides a way for passive Solana token holders to become part of the active Solana economy and earn interest rates proportional to the interest rate generated by the delegated validation-client. Additionally, this feature intends to create a healthy validation-client market, with potential validation-client nodes competing to build reliable, transparent and profitable delegation services. diff --git a/src/proposals/ledger-replication-to-implement.md b/src/proposals/ledger-replication-to-implement.md deleted file mode 100644 index b228d9dc990e6f..00000000000000 --- a/src/proposals/ledger-replication-to-implement.md +++ /dev/null @@ -1,137 +0,0 @@ -# Ledger Replication - -Replication behavior yet to be implemented. - -## Storage epoch - -The storage epoch should be the number of slots which results in around 100GB-1TB of ledger to be generated for archivers to store. Archivers will start storing ledger when a given fork has a high probability of not being rolled back. - -## Validator behavior - -1. Every NUM\_KEY\_ROTATION\_TICKS it also validates samples received from - - archivers. It signs the PoH hash at that point and uses the following - - algorithm with the signature as the input: - - * The low 5 bits of the first byte of the signature creates an index into - - another starting byte of the signature. - - * The validator then looks at the set of storage proofs where the byte of - - the proof's sha state vector starting from the low byte matches exactly - - with the chosen byte\(s\) of the signature. - - * If the set of proofs is larger than the validator can handle, then it - - increases to matching 2 bytes in the signature. - - * Validator continues to increase the number of matching bytes until a - - workable set is found. - - * It then creates a mask of valid proofs and fake proofs and sends it to - - the leader. This is a storage proof confirmation transaction. - -2. After a lockout period of NUM\_SECONDS\_STORAGE\_LOCKOUT seconds, the - - validator then submits a storage proof claim transaction which then causes the - - distribution of the storage reward if no challenges were seen for the proof to - - the validators and archivers party to the proofs. - -## Archiver behavior - -1. The archiver then generates another set of offsets which it submits a fake - - proof with an incorrect sha state. It can be proven to be fake by providing the - - seed for the hash result. - - * A fake proof should consist of an archiver hash of a signature of a PoH - - value. That way when the archiver reveals the fake proof, it can be - - verified on chain. - -2. The archiver monitors the ledger, if it sees a fake proof integrated, it - - creates a challenge transaction and submits it to the current leader. The - - transacation proves the validator incorrectly validated a fake storage proof. - - The archiver is rewarded and the validator's staking balance is slashed or - - frozen. - -## Storage proof contract logic - -Each archiver and validator will have their own storage account. The validator's account would be separate from their gossip id similiar to their vote account. These should be implemented as two programs one which handles the validator as the keysigner and one for the archiver. In that way when the programs reference other accounts, they can check the program id to ensure it is a validator or archiver account they are referencing. - -### SubmitMiningProof - -```text -SubmitMiningProof { - slot: u64, - sha_state: Hash, - signature: Signature, -}; -keys = [archiver_keypair] -``` - -Archivers create these after mining their stored ledger data for a certain hash value. The slot is the end slot of the segment of ledger they are storing, the sha\_state the result of the archiver using the hash function to sample their encrypted ledger segment. The signature is the signature that was created when they signed a PoH value for the current storage epoch. The list of proofs from the current storage epoch should be saved in the account state, and then transfered to a list of proofs for the previous epoch when the epoch passes. In a given storage epoch a given archiver should only submit proofs for one segment. - -The program should have a list of slots which are valid storage mining slots. This list should be maintained by keeping track of slots which are rooted slots in which a significant portion of the network has voted on with a high lockout value, maybe 32-votes old. Every SLOTS\_PER\_SEGMENT number of slots would be added to this set. The program should check that the slot is in this set. The set can be maintained by receiving a AdvertiseStorageRecentBlockHash and checking with its bank/Tower BFT state. - -The program should do a signature verify check on the signature, public key from the transaction submitter and the message of the previous storage epoch PoH value. - -### ProofValidation - -```text -ProofValidation { - proof_mask: Vec, -} -keys = [validator_keypair, archiver_keypair(s) (unsigned)] -``` - -A validator will submit this transaction to indicate that a set of proofs for a given segment are valid/not-valid or skipped where the validator did not look at it. The keypairs for the archivers that it looked at should be referenced in the keys so the program logic can go to those accounts and see that the proofs are generated in the previous epoch. The sampling of the storage proofs should be verified ensuring that the correct proofs are skipped by the validator according to the logic outlined in the validator behavior of sampling. - -The included archiver keys will indicate the the storage samples which are being referenced; the length of the proof\_mask should be verified against the set of storage proofs in the referenced archiver account\(s\), and should match with the number of proofs submitted in the previous storage epoch in the state of said archiver account. - -### ClaimStorageReward - -```text -ClaimStorageReward { -} -keys = [validator_keypair or archiver_keypair, validator/archiver_keypairs (unsigned)] -``` - -Archivers and validators will use this transaction to get paid tokens from a program state where SubmitStorageProof, ProofValidation and ChallengeProofValidations are in a state where proofs have been submitted and validated and there are no ChallengeProofValidations referencing those proofs. For a validator, it should reference the archiver keypairs to which it has validated proofs in the relevant epoch. And for an archiver it should reference validator keypairs for which it has validated and wants to be rewarded. - -### ChallengeProofValidation - -```text -ChallengeProofValidation { - proof_index: u64, - hash_seed_value: Vec, -} -keys = [archiver_keypair, validator_keypair] -``` - -This transaction is for catching lazy validators who are not doing the work to validate proofs. An archiver will submit this transaction when it sees a validator has approved a fake SubmitMiningProof transaction. Since the archiver is a light client not looking at the full chain, it will have to ask a validator or some set of validators for this information maybe via RPC call to obtain all ProofValidations for a certain segment in the previous storage epoch. The program will look in the validator account state see that a ProofValidation is submitted in the previous storage epoch and hash the hash\_seed\_value and see that the hash matches the SubmitMiningProof transaction and that the validator marked it as valid. If so, then it will save the challenge to the list of challenges that it has in its state. - -### AdvertiseStorageRecentBlockhash - -```text -AdvertiseStorageRecentBlockhash { - hash: Hash, - slot: u64, -} -``` - -Validators and archivers will submit this to indicate that a new storage epoch has passed and that the storage proofs which are current proofs should now be for the previous epoch. Other transactions should check to see that the epoch that they are referencing is accurate according to current chain state. - diff --git a/src/terminology.md b/src/terminology.md index 1f9ecccd458bee..e695c8755604d8 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -88,10 +88,6 @@ See [Proof of History](terminology.md#proof-of-history). The time, i.e. number of [slots](terminology.md#slot), for which a [leader schedule](terminology.md#leader-schedule) is valid. -## fake storage proof - -A proof which has the same format as a storage proof, but the sha state is actually from hashing a known ledger value which the storage client can reveal and is also easily verifiable by the network on-chain. - ## fee account The fee account in the transaction is the account pays for the cost of including the transaction in the ledger. This is the first account in the transaction. This account must be declared as Read-Write (writable) in the transaction since paying for the transaction reduces the account balance. @@ -118,7 +114,7 @@ A digital fingerprint of a sequence of bytes. ## inflation -An increase in token supply over time used to fund rewards for validation and replication and to fund continued development of Solana. +An increase in token supply over time used to fund rewards for validation and to fund continued development of Solana. ## instruction @@ -144,10 +140,6 @@ A sequence of [validator](terminology.md#validator) [public keys](terminology.md A list of [entries](terminology.md#entry) containing [transactions](terminology.md#transaction) signed by [clients](terminology.md#client). -## ledger segment - -Portion of the ledger which is downloaded by the archiver where storage proof data is derived. - ## ledger vote A [hash](terminology.md#hash) of the [validator's state](terminology.md#bank-state) at a given [tick height](terminology.md#tick-height). It comprises a validator's affirmation that a [block](terminology.md#block) it has received has been verified, as well as a promise not to vote for a conflicting [block](terminology.md#block) \(i.e. [fork](terminology.md#fork)\) for a specific amount of time, the [lockout](terminology.md#lockout) period. @@ -204,10 +196,6 @@ A stack of proofs, each which proves that some data existed before the proof was The public key of a [keypair](terminology.md#keypair). -## archiver - -Storage mining client, stores some part of the ledger enumerated in blocks and submits storage proofs to the chain. Not a validator. - ## root A [block](terminology.md#block) or [slot](terminology.md#slot) that has reached maximum [lockout](terminology.md#lockout) on a validator. The root is the highest block that is an ancestor of all active forks on a validator. All ancestor blocks of a root are also transitively a root. Blocks that are not an ancestor and not a descendant of the root are excluded from consideration for consensus and can be discarded. @@ -236,26 +224,6 @@ The [native token](terminology.md#native-token) tracked by a [cluster](terminolo Tokens forfeit to the [cluster](terminology.md#cluster) if malicious [validator](terminology.md#validator) behavior can be proven. -## storage proof - -A set of sha hash state which is constructed by sampling the encrypted version of the stored ledger segment at certain offsets. - -## storage proof challenge - -A transaction from an archiver that verifiably proves that a validator confirmed a fake proof. - -## storage proof claim - -A transaction from a validator which is after the timeout period given from the storage proof confirmation and which no successful challenges have been observed which rewards the parties of the storage proofs and confirmations. - -## storage proof confirmation - -A transaction by a validator which indicates the set of real and fake proofs submitted by a storage miner. The transaction would contain a list of proof hash values and a bit which says if this hash is valid or fake. - -## storage validation capacity - -The number of keys and samples that a validator can verify each storage epoch. - ## supermajority 2/3 of a [cluster](terminology.md#cluster). diff --git a/src/validator/blockstore.md b/src/validator/blockstore.md index 1c51648c47ae6e..d199340f3437db 100644 --- a/src/validator/blockstore.md +++ b/src/validator/blockstore.md @@ -85,6 +85,3 @@ Replay stage uses Blockstore APIs to find the longest chain of entries it can ha ## Pruning Blockstore Once Blockstore entries are old enough, representing all the possible forks becomes less useful, perhaps even problematic for replay upon restart. Once a validator's votes have reached max lockout, however, any Blockstore contents that are not on the PoH chain for that vote for can be pruned, expunged. - -Archiver nodes will be responsible for storing really old ledger contents, and validators need only persist their bank periodically. -