diff --git a/.gitignore b/.gitignore index d74c31688d..b32fa40870 100644 --- a/.gitignore +++ b/.gitignore @@ -19,3 +19,4 @@ log-*.txt # intellij files /.idea/ /solana.iml + diff --git a/book/src/ed_attack_vectors.md b/book/src/ed_attack_vectors.md new file mode 100644 index 0000000000..edb704ccbc --- /dev/null +++ b/book/src/ed_attack_vectors.md @@ -0,0 +1,11 @@ +## 5. Attack Vectors + +### 5.1 Colluding validation and replication clients + +A colluding validation-client, may take the strategy to mark PoReps from non-colluding replicator nodes as invalid as an attempt to maximize the rewards for the colluding replicator nodes. In this case, it isn’t feasible for the offended-against replicator 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 replicator 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 replicator and vote them as valid. In this case, colluding replicator-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 replicator’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 replicator 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 replicator-client PoReps will find their way to colluding validation-clients, the network can also monitor rates of paired (validator + replicator) discrepancies in voting patterns and censor identified colluders in these cases. diff --git a/book/src/ed_economic_sustainability.md b/book/src/ed_economic_sustainability.md new file mode 100644 index 0000000000..fc580b385c --- /dev/null +++ b/book/src/ed_economic_sustainability.md @@ -0,0 +1,18 @@ +## 4. Economic Sustainability + +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 the remittances and deposits into and out of the reserve ‘mining pool’. + +The dominant remittances from the Solana mining pool are validator and replicator rewards. The deposit mechanism is a flat, protocol-specified and adjusted, % of each transaction fee. + +The Replicator rewards are to be delivered to replicators from the mining pool 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 3** + + + +**Figure 3**: 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 other protocol-based remittance goes to validation-clients as a reward distributed in proportion to stake-weight for voting to validate the ledger state. The functional issuance of this reward is described in **Section 2.1 **and is designed to reduce over time until validators are incentivized solely through collection of transaction fees. Therefore, in the long-run, protocol-based rewards to replication-nodes will be the only remittances from the mining pool, and will have to be countered by the portion of each non-PoRep transaction fee that is directed back into the mining pool. I.e. for a long-term self-sustaining economy, replicator-client rewards must be subsidized through a minimum fee on each non-PoRep transaction pre-allocated to the mining pool. Through this constraint, we can write the following inequality: + +**== WIP [here](https://docs.google.com/document/d/1HBDasdkjS4Ja9wC_tIUsZPVcxGAWTuYOq9zf6xoQNps/edit?usp=sharing) ==** + diff --git a/book/src/ed_overview.md b/book/src/ed_overview.md new file mode 100755 index 0000000000..e0f302cbc9 --- /dev/null +++ b/book/src/ed_overview.md @@ -0,0 +1,15 @@ +## 1. Overview + +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 remittance mechanisms are discussed below. + +The main channels of participant remittances are referred to as protocol-based rewards and transaction fees. Protocol-based rewards are protocol-derived issuances from a network-controlled reserve of tokens (sometimes referred to as the ‘mining pool’). These rewards will constitute the total reward delivered to replication clients and a portion of the total rewards for 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 join the network. + +These protocol-based rewards, to be distributed to participating validation and replication clients, are to be specified as annual interest rates calculated per, real-time, Solana epoch [DEFINITION]. As discussed further below, the issuance rates are determined as a function of total network validator staked percentage and total replication provided by replicators in each previous epoch. The choice for validator and replicator client rewards to be based on participation rates, rather than a global fixed inflation or interest rate, emphasizes a protocol priority of overall economic security, rather than monetary supply predictability. Due to Solana’s hard total supply cap of 1B tokens and the bounds of client participant rates in the protocol, we believe that global interest, and supply issuance, scenarios should be able to be modeled with reasonable uncertainties. + +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 continuous and long-term funding of the mining pool through a pre-dedicated portion of transaction fees 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 is described in [Section 2](ed_validation_client_economics.md) including validation protocol-based rewards ([Section 2.1](ed_vce_state_validation_protocol_based_rewards.md)), validation transaction fee dynamics ([Section 2.2](ed_vce_state_validation_transaction_fees.md)) and validator-client compensation for replication verification ([Section 2.3](ed_vce_replication_validation_transaction_fees.md)). [Section 2.4](ed_vce_validation_stake_delegation.md) closes with a discussion of stake delegation. [Section 3](ed_replication_client_economics.md) will review the Solana network design for global ledger storage/redundancy and replicator-client economics ([Section 3.1](ed_rce_storage_replication_rewards.md)) along with a replicator-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy ([Section 3.2](ed_rce_replication_client_reward_auto_delegation.md)). [Section 4](ed_economic_sustainability.md) dives deeper into Solana’s design for long-term economic sustainability and outlines the constraints and conditions for a self-sustaining economy. Finally, in [Section 5](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_rce_replication_client_reward_auto_delegation.md b/book/src/ed_rce_replication_client_reward_auto_delegation.md new file mode 100644 index 0000000000..5e1065a965 --- /dev/null +++ b/book/src/ed_rce_replication_client_reward_auto_delegation.md @@ -0,0 +1,5 @@ +### 3.2 Replication-client Reward Auto-delegation + +The ability for Solana network participant’s to earn rewards by providing storage service is a unique onboarding 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 onboarding 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, a replicator-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 and therefore earning interest in the validation-client reward pool. diff --git a/book/src/ed_rce_storage_replication_rewards.md b/book/src/ed_rce_storage_replication_rewards.md new file mode 100644 index 0000000000..4c666a0881 --- /dev/null +++ b/book/src/ed_rce_storage_replication_rewards.md @@ -0,0 +1,5 @@ +### 3.1 Storage-replication Rewards + +Replicator-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 replicator client is indeed storing the assigned ledger block sections on local hard drive space as a service to the network. Therefore, replicator 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, replicator clients have the opportunity to capture a portion of slashed bounties [TBD] of dishonest validator clients. This can be accomplished by a replicator 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-replicator collusion attacks, more on this below. diff --git a/book/src/ed_references.md b/book/src/ed_references.md new file mode 100644 index 0000000000..df5db5ff9d --- /dev/null +++ b/book/src/ed_references.md @@ -0,0 +1,7 @@ +## 6. References + +1. [https://blog.ethereum.org/2016/07/27/inflation-transaction-fees-cryptocurrency-monetary-policy/](https://blog.ethereum.org/2016/07/27/inflation-transaction-fees-cryptocurrency-monetary-policy/) + +2. [https://medium.com/solana-labs/how-to-create-decentralized-storage-for-a-multi-petabyte-digital-ledger-2499a3a8c281](https://medium.com/solana-labs/how-to-create-decentralized-storage-for-a-multi-petabyte-digital-ledger-2499a3a8c281) + +3. [https://medium.com/solana-labs/how-to-create-decentralized-storage-for-a-multi-petabyte-digital-ledger-2499a3a8c281](https://medium.com/solana-labs/how-to-create-decentralized-storage-for-a-multi-petabyte-digital-ledger-2499a3a8c281) diff --git a/book/src/ed_replication_client_economics.md b/book/src/ed_replication_client_economics.md new file mode 100644 index 0000000000..a628950141 --- /dev/null +++ b/book/src/ed_replication_client_economics.md @@ -0,0 +1,3 @@ +## 3. Replication-client economics + +Replication-clients should be rewarded for providing the network with storage space. Incentivization of the set of replicators provides data security through redundancy of the historical ledger. Replication nodes are rewarded in proportion to the amount of ledger data storage provided. 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 above in Section 2.3 diff --git a/book/src/ed_validation_client_economics.md b/book/src/ed_validation_client_economics.md new file mode 100644 index 0000000000..2864bfdc38 --- /dev/null +++ b/book/src/ed_validation_client_economics.md @@ -0,0 +1,3 @@ +## 2. Validation-client Economics + +Validator-clients are eligible to receive protocol-based (i.e. via mining pool) rewards issued via stake-based annual interest rates by providing compute (CPU+GPU) resources to validate and vote on a given PoH state. These protocol-based rewards are determined through an algorithmic schedule as a function of total amount of Solana tokens staked in the system and duration since network launch (genesis block). Additionally, these clients may earn revenue through two types of transaction fees: state-validation transaction fees and pooled Proof-of-Replication (PoRep) transaction fees. The distribution of these two types of transaction fees to the participating validation set are designed independently as economic goals and attack vectors are unique between the state- generation/validation mechanism and the ledger replication/validation mechanism. For clarity, we separately describe the design and motivation of the three types of potential revenue streams for validation-clients below: state-validation protocol-based rewards, state-validation transaction fees and PoRep-validation transaction fees. diff --git a/book/src/ed_vcd_replication_validation_transaction_fees.md b/book/src/ed_vcd_replication_validation_transaction_fees.md new file mode 100644 index 0000000000..db43f59a8e --- /dev/null +++ b/book/src/ed_vcd_replication_validation_transaction_fees.md @@ -0,0 +1,9 @@ +### 2.3 Replication-validation Transaction Fees + +As previously mentioned, validator-clients will also be responsible for validating PoReps submitted into the PoH stream by replicator-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.2 + +While replication-clients are incentivized and rewarded through protocol-based rewards schedule (see Section 3), validator-clients will be incentivized to include and validate PoReps in PoH through the distribution of the transaction fees associated with the submitted PoRep. 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). It was chosen not to include a distribution of these rewards to PoRep validators, and to rely only on the collection of PoRep attached transaction fees, due to the fact that the confluence of two participation incentive modes (state-validation inflation rate via global staked % and replication-validation rewards based on global redundancy factor) on the incentives of a single network participant (a validator-client) potentially opened up a significant incentive-driven attack surface area. + +The validation of PoReps by validation-clients is computationally more expensive than state-validation (detail in **Section 4**), thus the transaction fees are expected to be proportionally higher. However, because replication-client rewards are distributed in proportion to and only after submitted PoReps are validated, they are uniquely motivated for the inclusion and validation of their proofs. This pressure is expected to generate an adequate market economy between replication-clients and validation-clients. Additionally, transaction fees submitted with PoReps have no minimum amount pre-allocated to the mining pool, as do state-validation transaction fees. + +There are various attack vectors available for colluding validation and replication clients, as described in detail below in Section 4. To protect against various collusion attack vectors, for a given epoch, PoRep transaction fees are pooled, and redistributed across participating validation-clients in proportion to the number of validated PoReps in the epoch less the number of invalidated PoReps [DIAGRAM]. 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/ed_vcd_validation_stake_delegation.md b/book/src/ed_vcd_validation_stake_delegation.md new file mode 100644 index 0000000000..56778be095 --- /dev/null +++ b/book/src/ed_vcd_validation_stake_delegation.md @@ -0,0 +1,82 @@ +### 2.4 Validation Stake Delegation + +Running a Solana validation-client required relatively modest upfront hardware capital investment. **Table 2** provides an example hardware configuration to support ~1M tx/s with estimated ‘off-the-shelf’ costs: + +
Component | +Example | +Estimated Cost | +
GPU | +2x 2080 Ti | +$2500 | +
or | +4x 1080 Ti | +$2800 | +
OS/Ledger Storage | +Samsung 860 Evo 2TB | +$370 | +
Accounts storage | +2x Samsung 970 Pro M.2 512GB | +$340 | +
RAM | +32 Gb | +$300 | +
Motherboard | +AMD x399 | +$400 | +
CPU | +AMD Threadripper 2920x | +$650 | +
Case | ++ | $100 | +
Power supply | +EVGA 1600W | +$300 | +
Network | +> 500 mbps | ++ |
Network (1) | +Google webpass business bay area 1gbps unlimited | +$5500/mo | +
Network (2) | +Hurricane Electric bay area colo 1gbps | +$500/mo | +