gaspersic/solana
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Revert "Move the design proposals to a separate book"

Browse Source 
This reverts commit 4ca18d6b9a.
This commit is contained in:
Greg Fitzgerald
2019-03-23 13:27:09 -06:00
parent 74cea2748c
commit 028b9da0da
40 changed files with 43 additions and 141 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
book/README.md
View File

@@ -1,7 +1,7 @@
Building the Solana book
---
Install the book's dependencies, build, and test the book:
Install the book's dependnecies, build, and test the book:
```bash
$ ./build.sh

27
book/src/SUMMARY.md
View File

@@ -34,3 +34,30 @@
- [JavaScript API](javascript-api.md)
- [solana-wallet CLI](wallet.md)
- [Accepted Design Proposals](proposals.md)
- [Ledger Replication](ledger-replication-to-implement.md)
- [Secure Vote Signing](vote-signing-to-implement.md)
- [Staking Rewards](staking-rewards.md)
- [Passive Stake Delegation and Rewards](passive-stake-delegation-and-rewards.md)
- [Reliable Vote Transmission](reliable-vote-transmission.md)
- [Persistent Account Storage](persistent-account-storage.md)
- [Cluster Economics](ed_overview.md)
- [Validation-client Economics](ed_validation_client_economics.md)
- [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md)
- [State-validation Transaction Fees](ed_vce_state_validation_transaction_fees.md)
- [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md)
- [Validation Stake Delegation](ed_vce_validation_stake_delegation.md)
- [Replication-client Economics](ed_replication_client_economics.md)
- [Storage-replication Rewards](ed_rce_storage_replication_rewards.md)
- [Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md)
- [Economic Sustainability](ed_economic_sustainability.md)
- [Attack Vectors](ed_attack_vectors.md)
- [Economic Design MVP](ed_mvp.md)
- [References](ed_references.md)
- [Cluster Test Framework](cluster-test-framework.md)
- [Testing Programs](testing-programs.md)
- [Implemented Design Proposals](implemented-proposals.md)
- [Leader-to-Leader Transition](leader-leader-transition.md)
- [Leader-to-Validator Transition](leader-validator-transition.md)
- [Fork Selection](fork-selection.md)

122
book/src/cluster-test-framework.md Normal file
View File

@@ -0,0 +1,122 @@
# Cluster Test Framework
This document proposes the Cluster Test Framework (CTF). CTF is a test harness
that allows tests to execute against a local, in-process cluster or a
deployed cluster.
## Motivation
The goal of CTF is to provide a framework for writing tests independent of where
and how the cluster is deployed. Regressions can be captured in these tests and
the tests can be run against deployed clusters to verify the deployment. The
focus of these tests should be on cluster stability, consensus, fault tolerance,
API stability.
Tests should verify a single bug or scenario, and should be written with the
least amount of internal plumbing exposed to the test.
## Design Overview
Tests are provided an entry point, which is a `contact_info::ContactInfo`
structure, and a keypair that has already been funded.
Each node in the cluster is configured with a `fullnode::FullnodeConfig` at boot
time. At boot time this configuration specifies any extra cluster configuration
required for the test. The cluster should boot with the configuration when it
is run in-process or in a data center.
Once booted, the test will discover the cluster through a gossip entry point and
configure any runtime behaviors via fullnode RPC.
## Test Interface
Each CTF test starts with an opaque entry point and a funded keypair. The test
should not depend on how the cluster is deployed, and should be able to exercise
all the cluster functionality through the publicly available interfaces.
```rust,ignore
use crate::contact_info::ContactInfo;
use solana_sdk::signature::{Keypair, KeypairUtil};
pub fn test_this_behavior(
entry_point_info: &ContactInfo,
funding_keypair: &Keypair,
num_nodes: usize,
)
```
## Cluster Discovery
At test start, the cluster has already been established and is fully connected.
The test can discover most of the available nodes over a few second.
```rust,ignore
use crate::gossip_service::discover;
// Discover the cluster over a few seconds.
let cluster_nodes = discover(&entry_point_info, num_nodes);
```
## Cluster Configuration
To enable specific scenarios, the cluster needs to be booted with special
configurations. These configurations can be captured in
`fullnode::FullnodeConfig`.
For example:
```rust,ignore
let mut fullnode_config = FullnodeConfig::default();
fullnode_config.rpc_config.enable_fullnode_exit = true;
let local = LocalCluster::new_with_config(
num_nodes,
10_000,
100,
&fullnode_config
);
```
## How to design a new test
For example, there is a bug that shows that the cluster fails when it is flooded
with invalid advertised gossip nodes. Our gossip library and protocol may
change, but the cluster still needs to stay resilient to floods of invalid
advertised gossip nodes.
Configure the RPC service:
```rust,ignore
let mut fullnode_config = FullnodeConfig::default();
fullnode_config.rpc_config.enable_rpc_gossip_push = true;
fullnode_config.rpc_config.enable_rpc_gossip_refresh_active_set = true;
```
Wire the RPCs and write a new test:
```rust,ignore
pub fn test_large_invalid_gossip_nodes(
entry_point_info: &ContactInfo,
funding_keypair: &Keypair,
num_nodes: usize,
) {
let cluster = discover(&entry_point_info, num_nodes);
// Poison the cluster.
let client = create_client(entry_point_info.client_facing_addr(), FULLNODE_PORT_RANGE);
for _ in 0..(num_nodes * 100) {
client.gossip_push(
cluster_info::invalid_contact_info()
);
}
sleep(Durration::from_millis(1000));
// Force refresh of the active set.
for node in &cluster {
let client = create_client(node.client_facing_addr(), FULLNODE_PORT_RANGE);
client.gossip_refresh_active_set();
}
// Verify that spends still work.
verify_spends(&cluster);
}
```

11
book/src/ed_attack_vectors.md Normal file
View File

@@ -0,0 +1,11 @@
## Attack Vectors
### 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.

18
book/src/ed_economic_sustainability.md Normal file
View File

@@ -0,0 +1,18 @@
## 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**
<!-- ![image alt text](porep_reward.png) -->
<p style="text-align:center;"><img src="img/porep_reward.png" alt="==PoRep Reward Curve ==" width="800"/></p>
**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 [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md) 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) ==**

12
book/src/ed_mvp.md Normal file
View File

@@ -0,0 +1,12 @@
## Proposed MVP of Economic Design
The preceeding sections, outlined in the [Economic Design Overview](ed_overview.md), describe a long-term vision of a sustainable Solana economy. Of course, we don't expect the final implementation to perfectly match what has been described above. We intend to fully engage with network stakeholders throughout the implementation phases (i.e. pre-testnet, testnet, mainnet) to ensure the system supports, and is representative of, the various network participants' interests. The first step toward this goal, however, is outlining a some desired MVP economic features to be available for early pre-testnet and testnet participants. Below is a rough sketch outlining basic economic functionality from which a more complete and functional system can be developed.
### MVP Economic Features
* Faucet to deliver testnet SOLs to validators for staking and dapp development.
* Mechanism by which validators are rewarded in proportion to their stake. Interest rate mechansism (i.e. to be determined by total % staked) to come later.
* Ability to delegate tokens to validator nodes.
* Replicators 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 replicator PoRep transaction fees and weighted distribution to validators based on PoRep verification (see [Replication-validation Transaction Fees](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 replicator rewards to validator.

16
book/src/ed_overview.md Normal file
View File

@@ -0,0 +1,16 @@
## Economic Design 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 are described in sections: [Validation-client Economics](ed_validation_client_economics.md), [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. The [Replication-client Economics](ed_replication_client_economics.md) chapter will review the Solana network design for global ledger storage/redundancy and replicator-client economics ([Storage-replication rewards](ed_rce_storage_replication_rewards.md)) along with a replicator-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md). The [Economic Sustainability](ed_economic_sustainability.md) section dives deeper into Solana’s design for long-term economic sustainability and outlines the constraints and conditions for a self-sustaining economy. 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.
<!-- ![img alt text](solana_economic_design.png) -->
<p style="text-align:center;"><img src="img/solana_economic_design.png" alt="== Solana Economic Design Diagram ==" width="800"/></p>
**Figure 1**: Schematic overview of Solana economic incentive design.

5
book/src/ed_rce_replication_client_reward_auto_delegation.md Normal file
View File

@@ -0,0 +1,5 @@
### Replication-client Reward Auto-delegation
The ability for Solana network participant’s 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, 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.

5
book/src/ed_rce_storage_replication_rewards.md Normal file
View File

@@ -0,0 +1,5 @@
### 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.

7
book/src/ed_references.md Normal file
View File

@@ -0,0 +1,7 @@
## 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)

3
book/src/ed_replication_client_economics.md Normal file
View File

@@ -0,0 +1,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 the [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md) chapter.

3
book/src/ed_validation_client_economics.md Normal file
View File

@@ -0,0 +1,3 @@
## 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.

9
book/src/ed_vce_replication_validation_transaction_fees.md Normal file
View File

@@ -0,0 +1,9 @@
### 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 [Replication-client Economics](ed_replication_client_economics.md)), 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 the [Economic Sustainability](ed_economic_sustainability.md) chapter), 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 [Economic Sustainability](ed_economic_sustainability). 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).

46
book/src/ed_vce_state_validation_protocol_based_rewards.md Normal file
View File

@@ -0,0 +1,46 @@
### State-validation protocol-based rewards
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.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.
Validator-client rewards for these services are to be distributed at the end of each Solana epoch. Compensation for validator-clients is provided via a protocol-based annual interest 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 non-PoRep transaction fee, less a protocol-specified amount that is returned to the mining pool (see [Validation-client State Transaction Fees](ed_vce_state_validation_transaction_fees.md)). PoRep transaction fees are not collected directly by the leader client but pooled and returned to the validator set in proportion to the number of successfully validated PoReps. (see [Replication-client Transaction Fees](ed_vce_replication_validation_transaction_fees.md))
The protocol-based annual interest-rate (%) per epoch to be distributed to validation-clients is to be a function of:
* the current fraction of staked SOLs out of the current total circulating supply,
* the global time since the genesis block instantiation
* the up-time/participation [% of available slots/blocks that validator had opportunity to vote on?] of a given validator over the previous epoch.
The first two factors are protocol parameters only (i.e. independent of validator behavior in a given epoch) and describe a global validation reward schedule designed to both incentivize early participation and optimal security in the network. This schedule sets a maximum annual validator-client interest rate per epoch.
At any given point in time, this interest rate is pegged to a defined value given a specific % staked SOL out of the circulating supply (e.g. 10% interest rate when 66% of circulating SOL is staked). The interest rate adjusts as the square-root [TBD] of the % staked, leading to higher validation-client interest rates as the % staked drops below the targeted goal, thus incentivizing more participation leading to more security in the network. An example of such a schedule, for a specified point in time (e.g. network launch) is shown in **Table 1**.
| Percentage circulating supply staked [%] | Annual validator-client interest rate [%] |
| ---: | ---: |
| 5 | 13.87 |
| 15 | 13.31 |
| 25 | 12.73 |
| 35 | 12.12 |
| 45 | 11.48 |
| 55 | 10.80 |
| **66** | **10.00** |
| 75 | 9.29 |
| 85 | 8.44 |
**Table 1:** Example interest rate schedule based on % SOL staked out of circulating supply. In this case, interest rates are fixed at 10% for 66% of staked circulating supply
Over time, the interest rate, at any network staked percentage, will drop as described by an algorithmic schedule. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. This mining-pool provided interest rate will reduce over time until a network-chosen baseline value is reached. This is 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 both state-validation and ledger storage replication (PoReps) are not accounted for here. A validation-client interest rate schedule as a function of % network staked and time is shown in** Figure 2**.
<!-- ![== Validation Client Interest Rates Figure ==](validation_client_interest_rates.png =250x) -->
<p style="text-align:center;"><img src="img/validation_client_interest_rates.png" alt="drawing" width="800"/></p>
**Figure 2:** In this example schedule, the annual interest rate [%] reduces at around 16.7% per year, until it reaches the long-term, fixed, 4% rate.
This epoch-specific protocol-defined interest rate sets an upper limit of *protocol-generated* annual interest rate (not absolute total interest rate) possible to be delivered to any validator-client per epoch. The distributed interest rate per epoch is then discounted from this value based on the participation of the validator-client during the previous epoch. Each epoch is comprised of XXX slots. The protocol-defined interest rate is then discounted by the log [TBD] of the % of slots a given validator submitted a vote on a PoH branch during that epoch, see **Figure XX**

20
book/src/ed_vce_state_validation_transaction_fees.md Normal file
View File

@@ -0,0 +1,20 @@
### State-validation Transaction Fees
Each message sent through the network, to be processed by the current leader validation-client and confirmed as a global state transaction, must contain a transaction fee. Transaction fees offer many benefits in the Solana economic design, for example they:
* provide unit compensation to the validator network for the CPU/GPU resources necessary to process the state transaction,
* reduce network spam by introducing real cost to transactions,
* 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 sent to the mining pool, with the resulting fee going to the current leader processing the transaction. These pooled fees, then re-enter the system through rewards distributed to validation-clients, through the process described above, and replication-clients, as discussed below.
The intent of this design is to retain leader incentive to include as many transactions as possible within the leader-slot time, while providing a redistribution avenue that protects against "tax evasion" attacks (i.e. side-channel fee payments)<sup>[1](ed_referenced.md)</sup>. Constraints on the fixed portion of transaction fees going to the mining pool, to establish long-term economic sustainability, are established and discussed in detail in the [Economic Sustainability](ed_economic_sustainability.md) section.
This minimum, protocol-earmarked, 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 (e.g. 50% of a block's capacity), 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.
Additionally, the minimum protocol captured fee can be a consideration in fork selection. In the case of a PoH fork with a malicious, censoring leader, we would expect the total procotol captured fee 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 fees on their fork themselves, thus potentially reducing the incentive to censor in the first place.

29
book/src/ed_vce_validation_stake_delegation.md Normal file
View File

@@ -0,0 +1,29 @@
### 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|
**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:
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.md)).
a. This participant has the additional option to directly delegate their earned storage rewards ([Replication-client Reward Auto-delegation](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 creates a healthy validation-client market, with potential validation-client nodes competing to build reliable, transparent and profitable delegation services.

233
book/src/fork-selection.md Normal file
View File

@@ -0,0 +1,233 @@
# Fork Selection
This design describes a *Fork Selection* algorithm. It addresses the following
problems:
* Some forks may not end up accepted by the super-majority of the cluster, and
voters need to recover from voting on such forks.
* Many forks may be votable by different voters, and each voter may see a
different set of votable forks. The selected forks should eventually converge
for the cluster.
* Reward based votes have an associated risk. Voters should have the ability to
configure how much risk they take on.
* The [cost of rollback](#cost-of-rollback) needs to be computable. It is
important to clients that rely on some measurable form of Consistency. The
costs to break consistency need to be computable, and increase super-linearly
for older votes.
* ASIC speeds are different between nodes, and attackers could employ Proof of
History ASICS that are much faster than the rest of the cluster. Consensus
needs to be resistant to attacks that exploit the variability in Proof of
History ASIC speed.
For brevity this design assumes that a single voter with a stake is deployed as
an individual validator in the cluster.
## Time
The Solana cluster generates a source of time via a Verifiable Delay Function we
are calling [Proof of History](book/src/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](fork-generation.md) and [leader rotation](leader-rotation.md).
## Lockouts
The purpose of the lockout is to force a validator to commit opportunity cost to
a specific fork. Lockouts are measured in slots, and therefor represent a
real-time forced delay that a validator needs to wait before breaking the
commitment to a fork.
Validators that violate the lockouts and vote for a diverging fork within the
lockout should be punished. The proposed punishment is to slash the validator
stake if a concurrent vote within a lockout for a non-descendant fork can be
proven to the cluster.
## Algorithm
The basic idea to this approach is to stack consensus votes and double lockouts.
Each vote in the stack is a confirmation of a fork. Each confirmed fork is an
ancestor of the fork above it. Each vote has a `lockout` in units of slots
before the validator can submit a vote that does not contain the confirmed fork
as an ancestor.
When a vote is added to the stack, the lockouts of all the previous votes in the
stack are doubled (more on this in [Rollback](#Rollback)). With each new vote,
a validator commits the previous votes to an ever-increasing lockout. At 32
votes we can consider the vote to be at `max lockout` any votes with a lockout
equal to or above `1<<32` are dequeued (FIFO). Dequeuing a vote is the trigger
for a reward. If a vote expires before it is dequeued, it and all the votes
above it are popped (LIFO) from the vote stack. The validator needs to start
rebuilding the stack from that point.
### Rollback
Before a vote is pushed to the stack, all the votes leading up to vote with a
lower lock time than the new vote are popped. After rollback lockouts are not
doubled until the validator catches up to the rollback height of votes.
For example, a vote stack with the following state:
| vote | vote time | lockout | lock expiration time |
|-----:|----------:|--------:|---------------------:|
| 4 | 4 | 2 | 6 |
| 3 | 3 | 4 | 7 |
| 2 | 2 | 8 | 10 |
| 1 | 1 | 16 | 17 |
*Vote 5* is at time 9, and the resulting state is
| vote | vote time | lockout | lock expiration time |
|-----:|----------:|--------:|---------------------:|
| 5 | 9 | 2 | 11 |
| 2 | 2 | 8 | 10 |
| 1 | 1 | 16 | 17 |
*Vote 6* is at time 10
| vote | vote time | lockout | lock expiration time |
|-----:|----------:|--------:|---------------------:|
| 6 | 10 | 2 | 12 |
| 5 | 9 | 4 | 13 |
| 2 | 2 | 8 | 10 |
| 1 | 1 | 16 | 17 |
At time 10 the new votes caught up to the previous votes. But *vote 2* expires
at 10, so the when *vote 7* at time 11 is applied the votes including and above
*vote 2* will be popped.
| vote | vote time | lockout | lock expiration time |
|-----:|----------:|--------:|---------------------:|
| 7 | 11 | 2 | 13 |
| 1 | 1 | 16 | 17 |
The lockout for vote 1 will not increase from 16 until the stack contains 5
votes.
### Slashing and Rewards
Validators should be rewarded for selecting the fork that the rest of the
cluster selected as often as possible. This is well-aligned with generating a
reward when the vote stack is full and the oldest vote needs to be dequeued.
Thus a reward should be generated for each successful dequeue.
### Cost of Rollback
Cost of rollback of *fork A* is defined as the cost in terms of lockout time to
the validator to confirm any other fork that does not include *fork A* as an
ancestor.
The **Economic Finality** of *fork A* can be calculated as the loss of all the
rewards from rollback of *fork A* and its descendants, plus the opportunity cost
of reward due to the exponentially growing lockout of the votes that have
confirmed *fork A*.
### Thresholds
Each validator can independently set a threshold of cluster commitment to a fork
before that validator commits to a fork. For example, at vote stack index 7,
the lockout is 256 time units. A validator may withhold votes and let votes 0-7
expire unless the vote at index 7 has at greater than 50% commitment in the
cluster. This allows each validator to independently control how much risk to
commit to a fork. Committing to forks at a higher frequency would allow the
validator to earn more rewards.
### Algorithm parameters
The following parameters need to be tuned:
* Number of votes in the stack before dequeue occurs (32).
* Rate of growth for lockouts in the stack (2x).
* Starting default lockout (2).
* Threshold depth for minimum cluster commitment before committing to the fork
(8).
* Minimum cluster commitment size at threshold depth (50%+).
### Free Choice
A "Free Choice" is an unenforcible validator action. There is no way for the
protocol to encode and enforce these actions since each validator can modify the
code and adjust the algorithm. A validator that maximizes self-reward over all
possible futures should behave in such a way that the system is stable, and the
local greedy choice should result in a greedy choice over all possible futures.
A set of validator that are engaging in choices to disrupt the protocol should
be bound by their stake weight to the denial of service. Two options exits for
validator:
* a validator can outrun previous validator in virtual generation and submit a
concurrent fork
* a validator can withhold a vote to observe multiple forks before voting
In both cases, the validator in the cluster have several forks to pick from
concurrently, even though each fork represents a different height. In both
cases it is impossible for the protocol to detect if the validator behavior is
intentional or not.
### Greedy Choice for Concurrent Forks
When evaluating multiple forks, each validator should use the following rules:
1. Forks must satisfy the *Threshold* rule.
2. Pick the fork that maximizes the total cluster lockout time for all the
ancestor forks.
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](book/src/staking-rewards.md) section.
## PoH ASIC Resistance
Votes and lockouts grow exponentially while ASIC speed up is linear. There are
two possible attack vectors involving a faster ASIC.
### ASIC censorship
An attacker generates a concurrent fork that outruns previous leaders in an
effort to censor them. A fork proposed by this attacker will be available
concurrently with the next available leader. For nodes to pick this fork it
must satisfy the *Greedy Choice* rule.
1. Fork must have equal number of votes for the ancestor fork.
2. Fork cannot be so far a head as to cause expired votes.
3. Fork must have a greater amount of cluster transaction fees.
This attack is then limited to censoring the previous leaders fees, and
individual transactions. But it cannot halt the cluster, or reduce the
validator set compared to the concurrent fork. Fee censorship is limited to
access fees going to the leaders but not the validators.
### ASIC Rollback
An attacker generates a concurrent fork from an older block to try to rollback
the cluster. In this attack the concurrent fork is competing with forks that
have already been voted on. This attack is limited by the exponential growth of
the lockouts.
* 1 vote has a lockout of 2 slots. Concurrent fork must be at least 2 slots
ahead, and be produced in 1 slot. Therefore requires an ASIC 2x faster.
* 2 votes have a lockout of 4 slots. Concurrent fork must be at least 4 slots
ahead and produced in 2 slots. Therefore requires an ASIC 2x faster.
* 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.

BIN
book/src/img/porep_reward.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 372 KiB

BIN
book/src/img/solana_economic_design.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 120 KiB

BIN
book/src/img/validation_client_interest_rates.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 401 KiB

3
book/src/implemented-proposals.md Normal file
View File

@@ -0,0 +1,3 @@
# Implemented Design Proposals
The following design proposals are fully implemented.

101
book/src/leader-leader-transition.md Normal file
View File

@@ -0,0 +1,101 @@
# Leader to Leader Transition
This design describes how leaders transition production of the PoH ledger
between each other as each leader generates its own slot.
## Challenges
Current leader and the next leader are both racing to generate the final tick
for the current slot. The next leader may arrive at that slot while still
processing the current leader's entries.
The ideal scenario would be that the next leader generated its own slot right
after it was able to vote for the current leader. It is very likely that the
next leader will arrive at their PoH slot height before the current leader
finishes broadcasting the entire block.
The next leader has to make the decision of attaching its own block to the last
completed block, or wait to finalize the pending block. It is possible that the
next leader will produce a block that proposes that the current leader failed,
even though the rest of the network observes that block succeeding.
The current leader has incentives to start its slot as early as possible to
capture economic rewards. Those incentives need to be balanced by the leader's
need to attach its block to a block that has the most commitment from the rest
of the network.
## Leader timeout
While a leader is actively receiving entries for the previous slot, the leader
can delay broadcasting the start of its block in real time. The delay is
locally configurable by each leader, and can be dynamically based on the
previous leader's behavior. If the previous leader's block is confirmed by the
leader's TVU before the timeout, the PoH is reset to the start of the slot and
this leader produces its block immediately.
The downsides:
* Leader delays its own slot, potentially allowing the next leader more time to
catch up.
The upsides compared to guards:
* All the space in a block is used for entries.
* The timeout is not fixed.
* The timeout is local to the leader, and therefore can be clever. The leader's
heuristic can take into account avalanche performance.
* This design doesn't require a ledger hard fork to update.
* The previous leader can redundantly transmit the last entry in the block to
the next leader, and the next leader can speculatively decide to trust it to
generate its block without verification of the previous block.
* The leader can speculatively generate the last tick from the last received
entry.
* The leader can speculatively process transactions and guess which ones are not
going to be encoded by the previous leader. This is also a censorship attack
vector. The current leader may withhold transactions that it receives from the
clients so it can encode them into its own slot. Once processed, entries can be
replayed into PoH quickly.
## Alternative design options
### Guard tick at the end of the slot
A leader does not produce entries in its block after the *penultimate tick*,
which is the last tick before the first tick of the next slot. The network
votes on the *last tick*, so the time difference between the *penultimate tick*
and the *last tick* is the forced delay for the entire network, as well as the
next leader before a new slot can be generated. The network can produce the
*last tick* from the *penultimate tick*.
If the next leader receives the *penultimate tick* before it produces its own
*first tick*, it will reset its PoH and produce the *first tick* from the
previous leader's *penultimate tick*. The rest of the network will also reset
its PoH to produce the *last tick* as the id to vote on.
The downsides:
* Every vote, and therefore confirmation, is delayed by a fixed timeout. 1 tick,
or around 100ms.
* Average case confirmation time for a transaction would be at least 50ms worse.
* It is part of the ledger definition, so to change this behavior would require
a hard fork.
* Not all the available space is used for entries.
The upsides compared to leader timeout:
* The next leader has received all the previous entries, so it can start
processing transactions without recording them into PoH.
* The previous leader can redundantly transmit the last entry containing the
*penultimate tick* to the next leader. The next leader can speculatively
generate the *last tick* as soon as it receives the *penultimate tick*, even
before verifying it.

84
book/src/leader-validator-transition.md Normal file
View File

@@ -0,0 +1,84 @@
# Leader-to-Validator Transition
A fullnode typically operates as a validator. If, however, a staker delegates
its stake to a fullnode, it will occasionally be selected as a *slot leader*.
As a slot leader, the fullnode is responsible for producing blocks during an
assigned *slot*. A slot has a duration of some number of preconfigured *ticks*.
The duration of those ticks are estimated with a *PoH Recorder* described later
in this document.
## BankFork
BankFork tracks changes to the bank state over a specific slot. Once the final
tick has been registered the state is frozen. Any attempts to write to are
rejected.
## Validator
A validator operates on many different concurrent forks of the bank state until
it generates a PoH hash with a height within its leader slot.
## Slot Leader
A slot leader builds blocks on top of only one fork, the one it last voted on.
## PoH Recorder
Slot leaders and validators use a PoH Recorder for both estimating slot height
and for recording transactions.
### PoH Recorder when Validating
The PoH Recorder acts as a simple VDF when validating. It tells the validator
when it needs to switch to the slot leader role. Every time the validator votes
on a fork, it should use the fork's latest block id to re-seed the VDF.
Re-seeding solves two problems. First, it synchronizes its VDF to the leader's,
allowing it to more accurately determine when its leader slot begins. Second,
if the previous leader goes down, all wallclock time is accounted for in the
next leader's PoH stream. For example, if one block is missing when the leader
starts, the block it produces should have a PoH duration of two blocks. The
longer duration ensures the following leader isn't attempting to snip all the
transactions from the previous leader's slot.
### PoH Recorder when Leading
A slot leader use the PoH Recorder to record transactions, locking their
positions in time. The PoH hash must be derived from a previous leader's last
block. If it isn't, its block will fail PoH verification and be rejected by
the cluster.
The PoH Recorder also serves to inform the slot leader when its slot is over.
The leader needs to take care not to modify its bank if recording the
transaction would generate a PoH height outside its designated slot. The
leader, therefore, should not commit account changes until after it generates
the entry's PoH hash. When the PoH height falls outside its slot any
transactions in its pipeline may be dropped or forwarded to the next leader.
Forwarding is preferred, as it would minimize network congestion, allowing the
cluster to advertise higher TPS capacity.
## Fullnode Loop
The PoH Recorder manages the transition between modes. Once a ledger is
replayed, the validator can run until the recorder indicates it should be
the slot leader. As a slot leader, the node can then execute and record
transactions.
The loop is synchronized to PoH and does a synchronous start and stop of the
slot leader functionality. After stopping, the validator's TVU should find
itself in the same state as if a different leader had sent it the same block.
The following is pseudocode for the loop:
1. Query the LeaderScheduler for the next assigned slot.
2. Run the TVU over all the forks.
1. TVU will send votes to what it believes is the "best" fork.
2. After each vote, restart the PoH Recorder to run until the next assigned
slot.
3. When time to be a slot leader, start the TPU. Point it to the last fork the
TVU voted on.
4. Produce entries until the end of the slot.
1. For the duration of the slot, the TVU must not vote on other forks.
2. After the slot ends, the TPU freezes its BankFork. After freezing,
the TVU may resume voting.
5. Goto 1.

39
book/src/ledger-replication-to-implement.md Normal file
View File

@@ -0,0 +1,39 @@
# Ledger Replication
Replication behavior yet to be implemented.
### Validator behavior
3. Every NUM\_KEY\_ROTATION\_TICKS it also validates samples received from
replicators. 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.
5. 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 replicators party to the proofs.
### Replicator behavior
9. The replicator 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 a replicator hash of a signature of a PoH
value. That way when the replicator reveals the fake proof, it can be
verified on chain.
10. The replicator 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 replicator is rewarded and the validator's staking balance is slashed or
frozen.

212
book/src/passive-stake-delegation-and-rewards.md Normal file
View File

@@ -0,0 +1,212 @@
# Stake Delegation and Reward
This design proposal focuses on the software architecture for the on-chain
voting and staking programs. Incentives for staking is covered in [staking
rewards](staking-rewards.md).
The current architecture requires a vote for each delegated stake from the
validator, and therefore does not scale to allow replicator clients to
automatically delegate their rewards.
The design proposes a new set of programs for voting and stake delegation, The
proposed programs allow many stake accounts to passively earn rewards with a
single validator vote without permission or active involvement from the
validator.
## Current Design Problems
In the current design each staker creates their own VoteState, and assigns a
**delegate** in the VoteState that can submit votes. Since the validator has to
actively vote for each stake delegated to it, validators can censor stakes by
not voting for them.
The number of votes is equal to the number of stakers, and not the number of
validators. Replicator clients are expected to delegate their replication
rewards as they are earned, and therefore the number of stakes is expected to be
large compared to the number of validators in a long running cluster.
## Proposed changes to the current design.
The general idea is that instead of the staker, the validator will own the
VoteState program. In this proposal the VoteState program is there to track
validator votes, count validator generated credits and to provide any
additional validator specific state. The VoteState program is not aware of any
stakes delegated to it, and has no staking weight.
The rewards generated are proportional to the amount of lamports staked. In
this proposal stake state is stored as part of the StakeState program. This
program is owned by the staker only. Lamports stored in this program are the
stake. Unlike the current design, this program contains a new field to indicate
which VoteState program the stake is delegated to.
### VoteState
VoteState is the current state of all the votes the **delegate** has submitted
to the bank. VoteState contains the following state information:
* votes - The submitted votes data structure.
* credits - The total number of rewards this vote program has generated over its
lifetime.
* root\_slot - The last slot to reach the full lockout commitment necessary for
rewards.
* commission - The commission taken by this VoteState for any rewards claimed by
staker's StakeState accounts. This is the percentage ceiling of the reward.
* Account::lamports - The accumulated lamports from the commission. These do not
count as stakes.
* `authorized_vote_signer` - Only this identity is authorized to submit votes, and
this field can only modified by this entity
### VoteInstruction::Initialize
* `account[0]` - RW - The VoteState
`VoteState::authorized_vote_signer` is initialized to `account[0]`
other VoteState members defaulted
### VoteInstruction::AuthorizeVoteSigner(Pubkey)
* `account[0]` - RW - The VoteState
`VoteState::authorized_vote_signer` is set to to `Pubkey`, instruction must by
signed by Pubkey
### StakeState
A StakeState takes one of two forms, StakeState::Delegate and StakeState::MiningPool.
### StakeState::Delegate
StakeState is the current delegation preference of the **staker**. StakeState
contains the following state information:
* Account::lamports - The staked lamports.
* `voter_id` - The pubkey of the VoteState instance the lamports are
delegated to.
* `credits_observed` - The total credits claimed over the lifetime of the
program.
### StakeState::MiningPool
There are two approaches to the mining pool. The bank could allow the
StakeState program to bypass the token balance check, or a program representing
the mining pool could run on the network. To avoid a single network wide lock,
the pool can be split into several mining pools. This design focuses on using a
StakeState::MiningPool as the cluster wide mining pools.
* 256 StakeState::MiningPool are initialized, each with 1/256 number of mining pool
tokens stored as `Account::lamports`.
The stakes and the MiningPool are accounts that are owned by the same `Stake`
program.
### StakeInstruction::Initialize
* `account[0]` - RW - The StakeState::Delegate instance.
`StakeState::Delegate::credits_observed` is initialized to `VoteState::credits`.
`StakeState::Delegate::voter_id` is initialized to `account[1]`
* `account[1]` - R - The VoteState instance.
### StakeInstruction::RedeemVoteCredits
The VoteState program and the StakeState programs maintain a lifetime counter
of total rewards generated and claimed. Therefore an explicit `Clear`
instruction is not necessary. When claiming rewards, the total lamports
deposited into the StakeState and as validator commission is proportional to
`VoteState::credits - StakeState::credits_observed`.
* `account[0]` - RW - The StakeState::MiningPool instance that will fulfill the
reward.
* `account[1]` - RW - The StakeState::Delegate instance that is redeeming votes
credits.
* `account[2]` - R - The VoteState instance, must be the same as
`StakeState::voter_id`
Reward is payed out for the difference between `VoteState::credits` to
`StakeState::Delgate.credits_observed`, and `credits_observed` is updated to
`VoteState::credits`. The commission is deposited into the `VoteState` token
balance, and the reward is deposited to the `StakeState::Delegate` token balance. The
reward and the commission is weighted by the `StakeState::lamports` divided by total lamports staked.
The Staker or the owner of the Stake program sends a transaction with this
instruction to claim the reward.
Any random MiningPool can be used to redeem the credits.
```rust,ignore
let credits_to_claim = vote_state.credits - stake_state.credits_observed;
stake_state.credits_observed = vote_state.credits;
```
`credits_to_claim` is used to compute the reward and commission, and
`StakeState::Delegate::credits_observed` is updated to the latest
`VoteState::credits` value.
### Collecting network fees into the MiningPool
At the end of the block, before the bank is frozen, but after it processed all
the transactions for the block, a virtual instruction is executed to collect
the transaction fees.
* A portion of the fees are deposited into the leader's account.
* A portion of the fees are deposited into the smallest StakeState::MiningPool
account.
### Benefits
* Single vote for all the stakers.
* Clearing of the credit variable is not necessary for claiming rewards.
* Each delegated stake can claim its rewards independently.
* Commission for the work is deposited when a reward is claimed by the delegated
stake.
This proposal would benefit from the `read-only` accounts proposal to allow for
many rewards to be claimed concurrently.
## Passive Delegation
Any number of instances of StakeState::Delegate programs can delegate to a single
VoteState program without an interactive action from the identity controlling
the VoteState program or submitting votes to the program.
The total stake allocated to a VoteState program can be calculated by the sum of
all the StakeState programs that have the VoteState pubkey as the
`StakeState::Delegate::voter_id`.
## Example Callflow
<img alt="Passive Staking Callflow" src="img/passive-staking-callflow.svg" class="center"/>
## Future work
Validators may want to split the stake delegated to them amongst many validator
nodes since stake is used as weight in the network control and data planes. One
way to implement this would be for the StakeState to delegate to a pool of
validators instead of a single one.
Instead of a single `vote_id` and `credits_observed` entry in the StakeState
program, the program can be initialized with a vector of tuples.
```rust,ignore
Voter {
voter_id: Pubkey,
credits_observed: u64,
weight: u8,
}
```
* voters: Vec<Voter> - Array of VoteState accounts that are voting rewards with
this stake.
A StakeState program would claim a fraction of the reward from each voter in
the `voters` array, and each voter would be delegated a fraction of the stake.

153
book/src/persistent-account-storage.md Normal file
View File

@@ -0,0 +1,153 @@
# Persistent Account Storage
The set of Accounts represent the current computed state of all the transactions
that have been processed by a fullnode. Each fullnode needs to maintain this
entire set. Each block that is proposed by the network represents a change to
this set, and since each block is a potential rollback point the changes need to
be reversible.
Persistent storage like NVMEs are 20 to 40 times cheaper than DDR. The problem
with persistent storage is that write and read performance is much slower than
DDR and care must be taken in how data is read or written to. Both reads and
writes can be split between multiple storage drives and accessed in parallel.
This design proposes a data structure that allows for concurrent reads and
concurrent writes of storage. Writes are optimized by using an AppendVec data
structure, which allows a single writer to append while allowing access to many
concurrent readers. The accounts index maintains a pointer to a spot where the
account was appended to every fork, thus removing the need for explicit
checkpointing of state.
# AppendVec
AppendVec is a data structure that allows for random reads concurrent with a
single append-only writer. Growing or resizing the capacity of the AppendVec
requires exclusive access. This is implemented with an atomic `offset`, which
is updated at the end of a completed append.
The underlying memory for an AppendVec is a memory-mapped file. Memory-mapped
files allow for fast random access and paging is handled by the OS.
# Account Index
The account index is designed to support a single index for all the currently
forked Accounts.
```rust,ignore
type AppendVecId = usize;
type Fork = u64;
struct AccountMap(Hashmap<Fork, (AppendVecId, u64)>);
type AccountIndex = HashMap<Pubkey, AccountMap>;
```
The index is a map of account Pubkeys to a map of Forks and the location of the
Account data in an AppendVec. To get the version of an account for a specific Fork:
```rust,ignore
/// Load the account for the pubkey.
/// This function will load the account from the specified fork, falling back to the fork's parents
/// * fork - a virtual Accounts instance, keyed by Fork. Accounts keep track of their parents with Forks,
/// the persistent store
/// * pubkey - The Account's public key.
pub fn load_slow(&self, id: Fork, pubkey: &Pubkey) -> Option<&Account>
```
The read is satisfied by pointing to a memory-mapped location in the
`AppendVecId` at the stored offset. A reference can be returned without a copy.
## Root Forks
The [fork selection algorithm](fork-selection.md) eventually selects a fork as a
root fork and the fork is squashed. A squashed/root fork cannot be rolled back.
When a fork is squashed, all accounts in its parents not already present in the
fork are pulled up into the fork by updating the indexes. Accounts with zero
balance in the squashed fork are removed from fork by updating the indexes.
An account can be *garbage-collected* when squashing makes it unreachable.
Three possible options exist:
* Maintain a HashSet<u64> of root forks. One is expected to be created every
second. The entire tree can be garbage-collected later. Alternatively, if
every fork keeps a reference count of accounts, garbage collection could occur
any time an index location is updated.
* Remove any pruned forks from the index. Any remaining forks lower in number
than the root are can be considered root.
* Scan the index, migrate any old roots into the new one. Any remaining forks
lower than the new root can be deleted later.
# Append-only Writes
All the updates to Accounts occur as append-only updates. For every account
update, a new version is stored in the AppendVec.
It is possible to optimize updates within a single fork by returning a mutable
reference to an already stored account in a fork. The Bank already tracks
concurrent access of accounts and guarantees that a write to a specific account
fork will not be concurrent with a read to an account at that fork. To support
this operation, AppendVec should implement this function:
```rust,ignore
fn get_mut(&self, index: u64) -> &mut T;
```
This API allows for concurrent mutable access to a memory region at `index`. It
relies on the Bank to guarantee exclusive access to that index.
# Garbage collection
As accounts get updated, they move to the end of the AppendVec. Once capacity
has run out, a new AppendVec can be created and updates can be stored there.
Eventually references to an older AppendVec will disappear because all the
accounts have been updated, and the old AppendVec can be deleted.
To speed up this process, it's possible to move Accounts that have not been
recently updated to the front of a new AppendVec. This form of garbage
collection can be done without requiring exclusive locks to any of the data
structures except for the index update.
The initial implementation for garbage collection is that once all the accounts in
an AppendVec become stale versions, it gets reused. The accounts are not updated
or moved around once appended.
# Index Recovery
Each bank thread has exclusive access to the accounts during append, since the
accounts locks cannot be released until the data is committed. But there is no
explicit order of writes between the separate AppendVec files. To create an
ordering, the index maintains an atomic write version counter. Each append to
the AppendVec records the index write version number for that append in the
entry for the Account in the AppendVec.
To recover the index, all the AppendVec files can be read in any order, and the
latest write version for every fork should be stored in the index.
# Snapshots
To snapshot, the underlying memory-mapped files in the AppendVec need to be
flushed to disk. The index can be written out to disk as well.
# Performance
* Append-only writes are fast. SSDs and NVMEs, as well as all the OS level
kernel data structures, allow for appends to run as fast as PCI or NVMe bandwidth
will allow (2,700 MB/s).
* Each replay and banking thread writes concurrently to its own AppendVec.
* Each AppendVec could potentially be hosted on a separate NVMe.
* Each replay and banking thread has concurrent read access to all the
AppendVecs without blocking writes.
* Index requires an exclusive write lock for writes. Single-thread performance
for HashMap updates is on the order of 10m per second.
* Banking and Replay stages should use 32 threads per NVMe. NVMes have
optimal performance with 32 concurrent readers or writers.

7
book/src/proposals.md Normal file
View File

@@ -0,0 +1,7 @@
# Proposed Architectural Changes
The following architectural proposals have been accepted by the Solana team, but
are not yet fully implemented. The proposals may be implemented as described,
implemented differently as issues in the designs become evident, or not
implemented at all. If implemented, the descriptions will be moved from this
section to earlier chapters in a future version of this book.

124
book/src/reliable-vote-transmission.md Normal file
View File

@@ -0,0 +1,124 @@
# Reliable Vote Transmission
Validator votes are messages that have a critical function for consensus and
continuous operation of the network. Therefore it is critical that they are
reliably delivered and encoded into the ledger.
## Challenges
1. Leader rotation is triggered by PoH, which is clock with high drift. So many
nodes are likely to have an incorrect view if the next leader is active in
realtime or not.
2. The next leader may be easily be flooded. Thus a DDOS would not only prevent
delivery of regular transactions, but also consensus messages.
3. UDP is unreliable, and our asynchronous protocol requires any message that is
transmitted to be retransmitted until it is observed in the ledger.
Retransmittion could potentially cause an unintentional *thundering herd*
against the leader with a large number of validators. Worst case flood would be
`(num_nodes * num_retransmits)`.
4. Tracking if the vote has been transmitted or not via the ledger does not
guarantee it will appear in a confirmed block. The current observed block may
be unrolled. Validators would need to maintain state for each vote and fork.
## Design
1. Send votes as a push message through gossip. This ensures delivery of the
vote to all the next leaders, not just the next future one.
2. Leaders will read the Crds table for new votes and encode any new received
votes into the blocks they propose. This allows for validator votes to be
included in rollback forks by all the future leaders.
3. Validators that receive votes in the ledger will add them to their local crds
table, not as a push request, but simply add them to the table. This shortcuts
the push message protocol, so the validation messages do not need to be
retransmitted twice around the network.
4. CrdsValue for vote should look like this ``` Votes(Vec<Transaction>) ```
Each vote transaction should maintain a `wallclock` in its data. The merge
strategy for Votes will keep the last N set of votes as configured by the local
client. For push/pull the vector is traversed recursively and each Transaction
is treated as an individual CrdsValue with its own local wallclock and
signature.
Gossip is designed for efficient propagation of state. Messages that are sent
through gossip-push are batched and propagated with a minimum spanning tree to
the rest of the network. Any partial failures in the tree are actively repaired
with the gossip-pull protocol while minimizing the amount of data transfered
between any nodes.
## How this design solves the Challenges
1. Because there is no easy way for validators to be in sync with leaders on the
leader's "active" state, gossip allows for eventual delivery regardless of that
state.
2. Gossip will deliver the messages to all the subsequent leaders, so if the
current leader is flooded the next leader would have already received these
votes and is able to encode them.
3. Gossip minimizes the number of requests through the network by maintaining an
efficient spanning tree, and using bloom filters to repair state. So retransmit
back-off is not necessary and messages are batched.
4. Leaders that read the crds table for votes will encode all the new valid
votes that appear in the table. Even if this leader's block is unrolled, the
next leader will try to add the same votes without any additional work done by
the validator. Thus ensuring not only eventual delivery, but eventual encoding
into the ledger.
## Performance
1. Worst case propagation time to the next leader is Log(N) hops with a base
depending on the fanout. With our current default fanout of 6, it is about 6
hops to 20k nodes.
2. The leader should receive 20k validation votes aggregated by gossip-push into
64kb blobs. Which would reduce the number of packets for 20k network to 80
blobs.
3. Each validators votes is replicated across the entire network. To maintain a
queue of 5 previous votes the Crds table would grow by 25 megabytes. `(20,000
nodes * 256 bytes * 5)`.
## Two step implementation rollout
Initially the network can perform reliably with just 1 vote transmitted and
maintained through the network with the current Vote implementation. For small
networks a fanout of 6 is sufficient. With small network the memory and push
overhead is minor.
### Sub 1k validator network
1. Crds just maintains the validators latest vote.
2. Votes are pushed and retransmitted regardless if they are appearing in the
ledger.
3. Fanout of 6.
* Worst case 256kb memory overhead per node.
* Worst case 4 hops to propagate to every node.
* Leader should receive the entire validator vote set in 4 push message blobs.
### Sub 20k network
Everything above plus the following:
1. CRDS table maintains a vector of 5 latest validator votes.
2. Votes encode a wallclock. CrdsValue::Votes is a type that recurses into the
transaction vector for all the gossip protocols.
3. Increase fanout to 20.
* Worst case 25mb memory overhead per node.
* Sub 4 hops worst case to deliver to the entire network.
* 80 blobs received by the leader for all the validator messages.

136
book/src/staking-rewards.md Normal file
View File

@@ -0,0 +1,136 @@
# Staking Rewards
Initial Proof of Stake (PoS) (i.e. using in-protocol asset, SOL, to provide
secure consensus) design ideas outlined here. Solana will implement a proof of
stake reward/security scheme for node validators in the cluster. The purpose is
threefold:
- Align validator incentives with that of the greater cluster through
skin-in-the-game deposits at risk
- Avoid 'nothing at stake' fork voting issues by implementing slashing rules
aimed at promoting fork convergence
- Provide an avenue for validator rewards provided as a function of validator
participation in the cluster.
While many of the details of the specific implementation are currently under
consideration and are expected to come into focus through specific modeling
studies and parameter exploration on the Solana testnet, we outline here our
current thinking on the main components of the PoS system. Much of this
thinking is based on the current status of Casper FFG, with optimizations and
specific attributes to be modified as is allowed by Solana's Proof of History
(PoH) blockchain data structure.
### General Overview
Solana's ledger validation design is based on a rotating, stake-weighted selected leader broadcasting transactions in a PoH data
structure to validating nodes. These nodes, upon receiving the leader's
broadcast, have the opportunity to vote on the current state and PoH height by
signing a transaction into the PoH stream.
To become a Solana validator, a fullnode must deposit/lock-up some amount
of SOL in a contract. This SOL will not be accessible for a specific time
period. The precise duration of the staking lockup period has not been
determined. However we can consider three phases of this time for which
specific parameters will be necessary:
- *Warm-up period*: which SOL is deposited and inaccessible to the node,
however PoH transaction validation has not begun. Most likely on the order of
days to weeks
- *Validation period*: a minimum duration for which the deposited SOL will be
inaccessible, at risk of slashing (see slashing rules below) and earning
rewards for the validator participation. Likely duration of months to a
year.
- *Cool-down period*: a duration of time following the submission of a
'withdrawal' transaction. During this period validation responsibilities have
been removed and the funds continue to be inaccessible. Accumulated rewards
should be delivered at the end of this period, along with the return of the
initial deposit.
Solana's trustless sense of time and ordering provided by its PoH data
structure, along with its
[avalanche](https://www.youtube.com/watch?v=qt_gDRXHrHQ&t=1s) data broadcast
and transmission design, should provide sub-second transaction confirmation times that scale
with the log of the number of nodes in the cluster. This means we shouldn't
have to restrict the number of validating nodes with a prohibitive 'minimum
deposits' and expect nodes to be able to become validators with nominal amounts
of SOL staked. At the same time, Solana's focus on high-throughput should create incentive for validation clients to provide high-performant and reliable hardware. Combined with potential a minimum network speed threshold to join as a validation-client, we expect a healthy validation delegation market to emerge. To this end, Solana's testnet will lead into a "Tour de SOL" validation-client competition, focusing on throughput and uptime to rank and reward testnet validators.
### Slashing rules
Unlike Proof of Work (PoW) where off-chain capital expenses are already
deployed at the time of block construction/voting, PoS systems require
capital-at-risk to prevent a logical/optimal strategy of multiple chain voting.
We intend to implement slashing rules which, if broken, result some amount of
the offending validator's deposited stake to be removed from circulation. Given
the ordering properties of the PoH data structure, we believe we can simplify
our slashing rules to the level of a voting lockout time assigned per vote.
I.e. Each vote has an associated lockout time (PoH duration) that represents a
duration by any additional vote from that validator must be in a PoH that
contains the original vote, or a portion of that validator's stake is
slashable. This duration time is a function of the initial vote PoH count and
all additional vote PoH counts. It will likely take the form:
Lockout<sub>i</sub>(PoH<sub>i</sub>, PoH<sub>j</sub>) = PoH<sub>j</sub> + K *
exp((PoH<sub>j</sub> - PoH<sub>i</sub>) / K)
Where PoH<sub>i</sub> is the height of the vote that the lockout is to be
applied to and PoH<sub>j</sub> is the height of the current vote on the same
fork. If the validator submits a vote on a different PoH fork on any
PoH<sub>k</sub> where k > j > i and PoH<sub>k</sub> < Lockout(PoH<sub>i</sub>,
PoH<sub>j</sub>), then a portion of that validator's stake is at risk of being
slashed.
In addition to the functional form lockout described above, early
implementation may be a numerical approximation based on a First In, First Out
(FIFO) data structure and the following logic:
- FIFO queue holding 32 votes per active validator
- new votes are pushed on top of queue (`push_front`)
- expired votes are popped off top (`pop_front`)
- as votes are pushed into the queue, the lockout of each queued vote doubles
- votes are removed from back of queue if `queue.len() > 32`
- the earliest and latest height that has been removed from the back of the
queue should be stored
It is likely that a reward will be offered as a % of the slashed amount to any
node that submits proof of this slashing condition being violated to the PoH.
#### Partial Slashing
In the schema described so far, when a validator votes on a given PoH stream,
they are committing themselves to that fork for a time determined by the vote
lockout. An open question is whether validators will be hesitant to begin
voting on an available fork if the penalties are perceived too harsh for an
honest mistake or flipped bit.
One way to address this concern would be a partial slashing design that results
in a slashable amount as a function of either:
1. the fraction of validators, out of the total validator pool, that were also
slashed during the same time period (ala Casper)
2. the amount of time since the vote was cast (e.g. a linearly increasing % of
total deposited as slashable amount over time), or both.
This is an area currently under exploration
### Penalties
As discussed in the [Economic Design](ed_overview.md) section, annual validator interest rates are to be specified as a
function of total percentage of circulating supply that has been staked. The cluster rewards validators who are online
and actively participating in the validation process throughout the entirety of
their *validation period*. For validators that go offline/fail to validate
transactions during this period, their annual reward is effectively reduced.
Similarly, we may consider an algorithmic reduction in a validator's active
amount staked amount in the case that they are offline. I.e. if a validator is
inactive for some amount of time, either due to a partition or otherwise, the
amount of their stake that is considered ‘active’ (eligible to earn rewards)
may be reduced. This design would be structured to help long-lived partitions
to eventually reach finality on their respective chains as the % of non-voting
total stake is reduced over time until a super-majority can be achieved by the
active validators in each partition. Similarly, upon re-engaging, the ‘active’
amount staked will come back online at some defined rate. Different rates of
stake reduction may be considered depending on the size of the partition/active
set.

64
book/src/testing-programs.md Normal file
View File

@@ -0,0 +1,64 @@
## Testing Programs
Applications send transactions to a Solana cluster and query validators to
confirm the transactions were processed and to check each transaction's result.
When the cluster doesn't behave as anticipated, it could be for a number of
reasons:
* The program is buggy
* The BPF loader rejected an unsafe program instruction
* The transaction was too big
* The transaction was invalid
* The Runtime tried to execute the transaction when another one was accessing
the same account
* The network dropped the transaction
* The cluster rolled back the ledger
* A validator responded to queries maliciously
### The Transact Trait
To troubleshoot, the application should retarget a lower-level component, where
fewer errors are possible. Retargeting can be done with different
implementations of the Transact trait.
When Futures 0.3.0 is released, the Transact trait may look like this:
```rust,ignore
trait Transact {
async fn send_transactions(txs: &[Transaction]) -> Vec<Result<(), TransactionError>>;
}
```
Users send transactions and asynchrounously await their results.
#### Transact with Clusters
The highest level implementation targets a Solana cluster, which may be a
deployed testnet or a local cluster running on a development machine.
#### Transact with the TPU
The next level is the TPU implementation of Transact. At the TPU level, the
application sends transactions over Rust channels, where there can be no
surprises from network queues or dropped packets. The TPU implements all
"normal" transaction errors. It does signature verification, may report
account-in-use errors, and otherwise results in the ledger, complete with proof
of history hashes.
### Low-level testing
### Testing with the Bank
Below the TPU level is the Bank. The Bank doesn't do signature verification or
generate a ledger. The Bank is a convenient layer at which to test new on-chain
programs. It allows developers to toggle between native program implementations
and BPF-compiled variants. No need for the Transact trait here. The Bank's API
is synchronous.
### Unit-testing with the Runtime
Below the Bank is the Runtime. The Runtime is the ideal test environment for
unit-testing. By statically linking the Runtime into a native program
implementation, the developer gains the shortest possible edit-compile-run
loop. Without any dynamic linking, stack traces include debug symbols and
program errors are straightforward to troubleshoot.

107
book/src/vote-signing-to-implement.md Normal file
View File

@@ -0,0 +1,107 @@
# Secure Vote Signing
This design describes additional vote signing behavior that will make the
process more secure.
Currently, Solana implements a vote-signing service that evaluates each vote to
ensure it does not violate a slashing condition. The service could potentially
have different variations, depending on the hardware platform capabilities. In
particular, it could be used in conjunction with a secure enclave (such as SGX).
The enclave could generate an asymmetric key, exposing an API for user
(untrusted) code to sign the vote transactions, while keeping the vote-signing
private key in its protected memory.
The following sections outline how this architecture would work:
## Message Flow
1. The node initializes the enclave at startup
* The enclave generates an asymmetric key and returns the public key to the
node
* The keypair is ephemeral. A new keypair is generated on node bootup. A
new keypair might also be generated at runtime based on some TBD
criteria.
* The enclave returns its attestation report to the node
2. The node performs attestation of the enclave (e.g using Intel's IAS APIs)
* The node ensures that the Secure Enclave is running on a TPM and is
signed by a trusted party
3. The stakeholder of the node grants ephemeral key permission to use its stake.
This process is TBD.
4. The node's untrusted, non-enclave software calls trusted enclave software
using its interface to sign transactions and other data.
* In case of vote signing, the node needs to verify the PoH. The PoH
verification is an integral part of signing. The enclave would be
presented with some verifiable data to check before signing the vote.
* The process of generating the verifiable data in untrusted space is TBD
## PoH Verification
1. When the node votes on an en entry `X`, there's a lockout period `N`, for
which it cannot vote on a fork that does not contain `X` in its history.
2. Every time the node votes on the derivative of `X`, say `X+y`, the lockout
period for `X` increases by a factor `F` (i.e. the duration node cannot vote on
a fork that does not contain `X` increases).
* The lockout period for `X+y` is still `N` until the node votes again.
3. The lockout period increment is capped (e.g. factor `F` applies maximum 32
times).
4. The signing enclave must not sign a vote that violates this policy. This
means
* Enclave is initialized with `N`, `F` and `Factor cap`
* Enclave stores `Factor cap` number of entry IDs on which the node had
previously voted
* The sign request contains the entry ID for the new vote
* Enclave verifies that new vote's entry ID is on the correct fork
(following the rules #1 and #2 above)
## Ancestor Verification
This is alternate, albeit, less certain approach to verifying voting fork.
1. The validator maintains an active set of nodes in the cluster
2. It observes the votes from the active set in the last voting period
3. It stores the ancestor/last_tick at which each node voted
4. It sends new vote request to vote-signing service
* It includes previous votes from nodes in the active set, and their
corresponding ancestors
5. The signer checks if the previous votes contains a vote from the validator,
and the vote ancestor matches with majority of the nodes
* It signs the new vote if the check is successful
* It asserts (raises an alarm of some sort) if the check is unsuccessful
The premise is that the validator can be spoofed at most once to vote on
incorrect data. If someone hijacks the validator and submits a vote request for
bogus data, that vote will not be included in the PoH (as it'll be rejected by
the cluster). The next time the validator sends a request to sign the vote, the
signing service will detect that validator's last vote is missing (as part of
#5 above).
## Fork determination
Due to the fact that the enclave cannot process PoH, it has no direct knowledge
of fork history of a submitted validator vote. Each enclave should be initiated
with the current *active set* of public keys. A validator should submit its
current vote along with the votes of the active set (including itself) that it
observed in the slot of its previous vote. In this way, the enclave can surmise
the votes accompanying the validator's previous vote and thus the fork being
voted on. This is not possible for the validator's initial submitted vote, as
it will not have a 'previous' slot to reference. To account for this, a short
voting freeze should apply until the second vote is submitted containing the
votes within the active set, along with it's own vote, at the height of the
initial vote.
## Enclave configuration
A staking client should be configurable to prevent voting on inactive forks.
This mechanism should use the client's known active set `N_active` along with a
threshold vote `N_vote` and a threshold depth `N_depth` to determine whether or
not to continue voting on a submitted fork. This configuration should take the
form of a rule such that the client will only vote on a fork if it observes
more than `N_vote` at `N_depth`. Practically, this represents the client from
confirming that it has observed some probability of economic finality of the
submitted fork at a depth where an additional vote would create a lockout for
an undesirable amount of time if that fork turns out not to be live.
## Challenges
1. Generation of verifiable data in untrusted space for PoH verification in the
enclave.
2. Need infrastructure for granting stake to an ephemeral key.