solana-docs 0.0.0 → 1.0.0

package/src/implemented-proposals/abi-management.md

@@ -1,161 +0,0 @@
----
-title: Solana ABI management process
----
-
-This document proposes the Solana ABI management process. The ABI management
-process is an engineering practice and a supporting technical framework to avoid
-introducing unintended incompatible ABI changes.
-
-# Problem
-
-The Solana ABI (binary interface to the cluster) is currently only defined
-implicitly by the implementation and requires a very careful eye to notice
-breaking changes. This makes it extremely difficult to upgrade the software
-on an existing cluster without rebooting the ledger.
-
-# Requirements and objectives
-
-- Unintended ABI changes can be detected as CI failures mechanically.
-- Newer implementation must be able to process the oldest data (since genesis)
-  once we go mainnet.
-- The objective of this proposal is to protect the ABI while sustaining rather
-  rapid development by opting for a mechanical process rather than a very long
-  human-driven auditing process.
-- Once signed cryptographically, data blob must be identical, so no
-  in-place data format update is possible regardless of inbound and outbound of
-  the online system. Also, considering the sheer volume of transactions we're
-  aiming to handle, retrospective in-place update is undesirable at best.
-
-# Solution
-
-Instead of natural human's eye due-diligence, which should be assumed to fail
-regularly, we need a systematic assurance of not breaking the cluster when
-changing the source code.
-
-For that purpose, we introduce a mechanism of marking every ABI-related things
-in source code (`struct`s, `enum`s) with the new `#[frozen_abi]` attribute. This
-takes hard-coded digest value derived from types of its fields via
-`ser::Serialize`. And the attribute automatically generates a unit test to try
-to detect any unsanctioned changes to the marked ABI-related things.
-
-However, the detection cannot be complete; no matter how hard we statically
-analyze the source code, it's still possible to break ABI. For example, this
-includes not-`derive`d hand-written `ser::Serialize`, underlying library's
-implementation changes (for example `bincode`), CPU architecture differences.
-The detection of these possible ABI incompatibilities is out-of-scope for this
-ABI management.
-
-# Definitions
-
-ABI item/type: various types to be used for serialization, which collectively
-comprises the whole ABI for any system components. For example, those types
-include `struct`s and `enum`s.
-
-ABI item digest: Some fixed hash derived from type information of ABI item's
-fields.
-
-# Example
-
-```patch
-+#[frozen_abi(digest="eXSMM7b89VY72V...")]
- #[derive(Serialize, Default, Deserialize, Debug, PartialEq, Eq, Clone)]
- pub struct Vote {
-     /// A stack of votes starting with the oldest vote
-     pub slots: Vec<Slot>,
-     /// signature of the bank's state at the last slot
-     pub hash: Hash,
- }
-```
-
-# Developer's workflow
-
-To know the digest for new ABI items, developers can add `frozen_abi` with a
-random digest value and run the unit tests and replace it with the correct
-digest from the assertion test error message.
-
-In general, once we add `frozen_abi` and its change is published in the stable
-release channel, its digest should never change. If such a change is needed, we
-should opt for defining a new `struct` like `FooV1`. And special release flow
-like hard forks should be approached.
-
-# Implementation remarks
-
-We use some degree of macro machinery to automatically generate unit tests
-and calculate a digest from ABI items. This is doable by clever use of
-`serde::Serialize` (`[1]`) and `any::type_name` (`[2]`). For a precedent for similar
-implementation, `ink` from the Parity Technologies `[3]` could be informational.
-
-# Implementation details
-
-The implementation's goal is to detect unintended ABI changes automatically as
-much as possible. To that end, the digest of structural ABI information is
-calculated with best-effort accuracy and stability.
-
-When the ABI digest check is run, it dynamically computes an ABI digest by
-recursively digesting the ABI of fields of the ABI item, by re-using the
-`serde`'s serialization functionality, proc macro and generic specialization.
-And then, the check `assert!`s that its finalized digest value is identical as
-what is specified in the `frozen_abi` attribute.
-
-To realize that, it creates an example instance of the type and a custom
-`Serializer` instance for `serde` to recursively traverse its fields as if
-serializing the example for real. This traversing must be done via `serde` to
-really capture what kinds of data actually would be serialized by `serde`, even
-considering custom non-`derive`d `Serialize` trait implementations.
-
-# The ABI digesting process
-
-This part is a bit complex. There is three inter-depending parts: `AbiExample`,
-`AbiDigester` and `AbiEnumVisitor`.
-
-First, the generated test creates an example instance of the digested type with
-a trait called `AbiExample`, which should be implemented for all of digested
-types like the `Serialize` and return `Self` like the `Default` trait. Usually,
-it's provided via generic trait specialization for most of common types. Also
-it is possible to `derive` for `struct` and `enum` and can be hand-written if
-needed.
-
-The custom `Serializer` is called `AbiDigester`. And when it's called by `serde`
-to serialize some data, it recursively collects ABI information as much as
-possible. `AbiDigester`'s internal state for the ABI digest is updated
-differentially depending on the type of data. This logic is specifically
-redirected via with a trait called `AbiEnumVisitor` for each `enum` type. As the
-name suggests, there is no need to implement `AbiEnumVisitor` for other types.
-
-To summarize this interplay, `serde` handles the recursive serialization control
-flow in tandem with `AbiDigester`. The initial entry point in tests and child
-`AbiDigester`s use `AbiExample` recursively to create an example object
-hierarchal graph. And `AbiDigester` uses `AbiEnumVisitor` to inquiry the actual
-ABI information using the constructed sample.
-
-`Default` isn't enough for `AbiExample`. Various collection's `::default()` is
-empty, yet, we want to digest them with actual items. And, ABI digesting can't
-be realized only with `AbiEnumVisitor`. `AbiExample` is required because an
-actual instance of type is needed to actually traverse the data via `serde`.
-
-On the other hand, ABI digesting can't be done only with `AbiExample`, either.
-`AbiEnumVisitor` is required because all variants of an `enum` cannot be
-traversed just with a single variant of it as a ABI example.
-
-Digestable information:
-
-- rust's type name
-- `serde`'s data type name
-- all fields in `struct`
-- all variants in `enum`
-- `struct`: normal(`struct {...}`) and tuple-style (`struct(...)`)
-- `enum`: normal variants and `struct`- and `tuple`- styles.
-- attributes: `serde(serialize_with=...)` and `serde(skip)`
-
-Not digestable information:
-
-- Any custom serialize code path not touched by the sample provided by
-  `AbiExample`. (technically not possible)
-- generics (must be a concrete type; use `frozen_abi` on concrete type
-  aliases)
-
-# References
-
-1. [(De)Serialization with type info · Issue #1095 · serde-rs/serde](https://github.com/serde-rs/serde/issues/1095#issuecomment-345483479)
-2. [`std::any::type_name` - Rust](https://doc.rust-lang.org/std/any/fn.type_name.html)
-3. [Parity's ink to write smart contracts](https://github.com/paritytech/ink)

package/src/implemented-proposals/bank-timestamp-correction.md

@@ -1,77 +0,0 @@
----
-title: Bank Timestamp Correction
----
-
-Each Bank has a timestamp that is stashed in the Clock sysvar and used to assess
-time-based stake account lockups. However, since genesis, this value has been
-based on a theoretical slots-per-second instead of reality, so it's quite
-inaccurate. This poses a problem for lockups, since the accounts will not
-register as lockup-free on (or anytime near) the date the lockup is set to
-expire.
-
-Block times are already being estimated to cache in Blockstore and long-term
-storage using a [validator timestamp oracle](validator-timestamp-oracle.md);
-this data provides an opportunity to align the bank timestamp more closely with
-real-world time.
-
-The general outline of the proposed implementation is as follows:
-
-- Correct each Bank timestamp using the validator-provided timestamp.
-- Update the validator-provided timestamp calculation to use a stake-weighted
-  median, rather than a stake-weighted mean.
-- Bound the timestamp correction so that it cannot deviate too far from the
-  expected theoretical estimate
-
-## Timestamp Correction
-
-On every new Bank, the runtime calculates a realistic timestamp estimate using
-validator timestamp-oracle data. The Bank timestamp is corrected to this value
-if it is greater than or equal to the previous Bank's timestamp. That is, time
-should not ever go backward, so that locked up accounts may be released by the
-correction, but once released, accounts can never be relocked by a time
-correction.
-
-### Calculating Stake-Weighted Median Timestamp
-
-In order to calculate the estimated timestamp for a particular Bank, the runtime
-first needs to get the most recent vote timestamps from the active validator
-set. The `Bank::vote_accounts()` method provides the vote accounts state, and
-these can be filtered to all accounts whose most recent timestamp was provided
-within the last epoch.
-
-From each vote timestamp, an estimate for the current Bank is calculated using
-the epoch's target ns_per_slot for any delta between the Bank slot and the
-timestamp slot. Each timestamp estimate is associated with the stake delegated
-to that vote account, and all the timestamps are collected to create a
-stake-weighted timestamp distribution.
-
-From this set, the stake-weighted median timestamp -- that is, the timestamp at
-which 50% of the stake estimates a greater-or-equal timestamp and 50% of the
-stake estimates a lesser-or-equal timestamp -- is selected as the potential
-corrected timestamp.
-
-This stake-weighted median timestamp is preferred over the stake-weighted mean
-because the multiplication of stake by proposed timestamp in the mean
-calculation allows a node with very small stake to still have a large effect on
-the resulting timestamp by proposing a timestamp that is very large or very
-small. For example, using the previous `calculate_stake_weighted_timestamp()`
-method, a node with 0.00003% of the stake proposing a timestamp of `i64::MAX`
-can shift the timestamp forward 97k years!
-
-### Bounding Timestamps
-
-In addition to preventing time moving backward, we can prevent malicious
-activity by bounding the corrected timestamp to an acceptable level of deviation
-from the theoretical expected time.
-
-This proposal suggests that each timestamp be allowed to deviate up to 25% from
-the expected time since the start of the epoch.
-
-In order to calculate the timestamp deviation, each Bank needs to log the
-`epoch_start_timestamp` in the Clock sysvar. This value is set to the
-`Clock::unix_timestamp` on the first slot of each epoch.
-
-Then, the runtime compares the expected elapsed time since the start of the
-epoch with the proposed elapsed time based on the corrected timestamp. If the
-corrected elapsed time is within +/- 25% of expected, the corrected timestamp is
-accepted. Otherwise, it is bounded to the acceptable deviation.

package/src/implemented-proposals/commitment.md

@@ -1,92 +0,0 @@
----
-title: Commitment
----
-
-The commitment metric aims to give clients a measure of the network confirmation
-and stake levels on a particular block. Clients can then use this information to
-derive their own measures of commitment.
-
-# Calculation RPC
-
-Clients can request commitment metrics from a validator for a signature `s`
-through `get_block_commitment(s: Signature) -> BlockCommitment` over RPC. The
-`BlockCommitment` struct contains an array of u64 `[u64, MAX_CONFIRMATIONS]`. This
-array represents the commitment metric for the particular block `N` that
-contains the signature `s` as of the last block `M` that the validator voted on.
-
-An entry `s` at index `i` in the `BlockCommitment` array implies that the
-validator observed `s` total stake in the cluster reaching `i` confirmations on
-block `N` as observed in some block `M`. There will be `MAX_CONFIRMATIONS` elements in
-this array, representing all the possible number of confirmations from 1 to
-`MAX_CONFIRMATIONS`.
-
-# Computation of commitment metric
-
-Building this `BlockCommitment` struct leverages the computations already being
-performed for building consensus. The `collect_vote_lockouts` function in
-`consensus.rs` builds a HashMap, where each entry is of the form `(b, s)`
-where `s` is the amount of stake on a bank `b`.
-
-This computation is performed on a votable candidate bank `b` as follows.
-
-```text
-   let output: HashMap<b, Stake> = HashMap::new();
-   for vote_account in b.vote_accounts {
-       for v in vote_account.vote_stack {
-           for a in ancestors(v) {
-               f(*output.get_mut(a), vote_account, v);
-           }
-       }
-   }
-```
-
-where `f` is some accumulation function that modifies the `Stake` entry
-for slot `a` with some data derivable from vote `v` and `vote_account`
-(stake, lockout, etc.). Note here that the `ancestors` here only includes
-slots that are present in the current status cache. Signatures for banks earlier
-than those present in the status cache would not be queryable anyway, so those
-banks are not included in the commitment calculations here.
-
-Now we can naturally augment the above computation to also build a
-`BlockCommitment` array for every bank `b` by:
-
-1. Adding a `ForkCommitmentCache` to collect the `BlockCommitment` structs
-2. Replacing `f` with `f'` such that the above computation also builds this
-   `BlockCommitment` for every bank `b`.
-
-We will proceed with the details of 2) as 1) is trivial.
-
-Before continuing, it is noteworthy that for some validator's vote account `a`,
-the number of local confirmations for that validator on slot `s` is
-`v.num_confirmations`, where `v` is the smallest vote in the stack of votes
-`a.votes` such that `v.slot >= s` (i.e. there is no need to look at any
-votes > v as the number of confirmations will be lower).
-
-Now more specifically, we augment the above computation to:
-
-```text
-   let output: HashMap<b, Stake> = HashMap::new();
-   let fork_commitment_cache = ForkCommitmentCache::default();
-   for vote_account in b.vote_accounts {
-       // vote stack is sorted from oldest vote to newest vote
-       for (v1, v2) in vote_account.vote_stack.windows(2) {
-           for a in ancestors(v1).difference(ancestors(v2)) {
-               f'(*output.get_mut(a), *fork_commitment_cache.get_mut(a), vote_account, v);
-           }
-       }
-   }
-```
-
-where `f'` is defined as:
-
-```text
-    fn f`(
-        stake: &mut Stake,
-        some_ancestor: &mut BlockCommitment,
-        vote_account: VoteAccount,
-        v: Vote, total_stake: u64
-    ){
-        f(stake, vote_account, v);
-        *some_ancestor.commitment[v.num_confirmations] += vote_account.stake;
-    }
-```

package/src/implemented-proposals/durable-tx-nonces.md

@@ -1,131 +0,0 @@
----
-title: Durable Transaction Nonces
----
-
-## Problem
-
-To prevent replay, Solana transactions contain a nonce field populated with a
-"recent" blockhash value. A transaction containing a blockhash that is too old
-(~2min as of this writing) is rejected by the network as invalid. Unfortunately
-certain use cases, such as custodial services, require more time to produce a
-signature for the transaction. A mechanism is needed to enable these potentially
-offline network participants.
-
-## Requirements
-
-1. The transaction's signature needs to cover the nonce value
-2. The nonce must not be reusable, even in the case of signing key disclosure
-
-## A Contract-based Solution
-
-Here we describe a contract-based solution to the problem, whereby a client can
-"stash" a nonce value for future use in a transaction's `recent_blockhash`
-field. This approach is akin to the Compare and Swap atomic instruction,
-implemented by some CPU ISAs.
-
-When making use of a durable nonce, the client must first query its value from
-account data. A transaction is now constructed in the normal way, but with the
-following additional requirements:
-
-1. The durable nonce value is used in the `recent_blockhash` field
-2. An `AdvanceNonceAccount` instruction is the first issued in the transaction
-
-### Contract Mechanics
-
-TODO: svgbob this into a flowchart
-
-```text
-Start
-Create Account
-  state = Uninitialized
-NonceInstruction
-  if state == Uninitialized
-    if account.balance < rent_exempt
-      error InsufficientFunds
-    state = Initialized
-  elif state != Initialized
-    error BadState
-  if sysvar.recent_blockhashes.is_empty()
-    error EmptyRecentBlockhashes
-  if !sysvar.recent_blockhashes.contains(stored_nonce)
-    error NotReady
-  stored_hash = sysvar.recent_blockhashes[0]
-  success
-WithdrawInstruction(to, lamports)
-  if state == Uninitialized
-    if !signers.contains(owner)
-      error MissingRequiredSignatures
-  elif state == Initialized
-    if !sysvar.recent_blockhashes.contains(stored_nonce)
-      error NotReady
-    if lamports != account.balance && lamports + rent_exempt > account.balance
-      error InsufficientFunds
-  account.balance -= lamports
-  to.balance += lamports
-  success
-```
-
-A client wishing to use this feature starts by creating a nonce account under
-the system program. This account will be in the `Uninitialized` state with no
-stored hash, and thus unusable.
-
-To initialize a newly created account, an `InitializeNonceAccount` instruction must be
-issued. This instruction takes one parameter, the `Pubkey` of the account's
-[authority](../offline-signing/durable-nonce.md#nonce-authority). Nonce accounts
-must be [rent-exempt](rent.md#two-tiered-rent-regime) to meet the data-persistence
-requirements of the feature, and as such, require that sufficient lamports be
-deposited before they can be initialized. Upon successful initialization, the
-cluster's most recent blockhash is stored along with specified nonce authority
-`Pubkey`.
-
-The `AdvanceNonceAccount` instruction is used to manage the account's stored nonce
-value. It stores the cluster's most recent blockhash in the account's state data,
-failing if that matches the value already stored there. This check prevents
-replaying transactions within the same block.
-
-Due to nonce accounts' [rent-exempt](rent.md#two-tiered-rent-regime) requirement,
-a custom withdraw instruction is used to move funds out of the account.
-The `WithdrawNonceAccount` instruction takes a single argument, lamports to withdraw,
-and enforces rent-exemption by preventing the account's balance from falling
-below the rent-exempt minimum. An exception to this check is if the final balance
-would be zero lamports, which makes the account eligible for deletion. This
-account closure detail has an additional requirement that the stored nonce value
-must not match the cluster's most recent blockhash, as per `AdvanceNonceAccount`.
-
-The account's [nonce authority](../offline-signing/durable-nonce.md#nonce-authority)
-can be changed using the `AuthorizeNonceAccount` instruction. It takes one parameter,
-the `Pubkey` of the new authority. Executing this instruction grants full
-control over the account and its balance to the new authority.
-
-> `AdvanceNonceAccount`, `WithdrawNonceAccount` and `AuthorizeNonceAccount` all require the current [nonce authority](../offline-signing/durable-nonce.md#nonce-authority) for the account to sign the transaction.
-
-### Runtime Support
-
-The contract alone is not sufficient for implementing this feature. To enforce
-an extant `recent_blockhash` on the transaction and prevent fee theft via
-failed transaction replay, runtime modifications are necessary.
-
-Any transaction failing the usual `check_hash_age` validation will be tested
-for a Durable Transaction Nonce. This is signaled by including a `AdvanceNonceAccount`
-instruction as the first instruction in the transaction.
-
-If the runtime determines that a Durable Transaction Nonce is in use, it will
-take the following additional actions to validate the transaction:
-
-1. The `NonceAccount` specified in the `Nonce` instruction is loaded.
-2. The `NonceState` is deserialized from the `NonceAccount`'s data field and
-   confirmed to be in the `Initialized` state.
-3. The nonce value stored in the `NonceAccount` is tested to match against the
-   one specified in the transaction's `recent_blockhash` field.
-
-If all three of the above checks succeed, the transaction is allowed to continue
-validation.
-
-Since transactions that fail with an `InstructionError` are charged a fee and
-changes to their state rolled back, there is an opportunity for fee theft if an
-`AdvanceNonceAccount` instruction is reverted. A malicious validator could replay the
-failed transaction until the stored nonce is successfully advanced. Runtime
-changes prevent this behavior. When a durable nonce transaction fails with an
-`InstructionError` aside from the `AdvanceNonceAccount` instruction, the nonce account
-is rolled back to its pre-execution state as usual. Then the runtime advances
-its nonce value and the advanced nonce account stored as if it succeeded.

package/src/implemented-proposals/ed_overview/ed_economic_sustainability.md

@@ -1,9 +0,0 @@
----
-title: Economic Sustainability
----
-
-**Subject to change.**
-
-Long term economic sustainability is one of the guiding principles of Solana’s economic design. While it is impossible to predict how decentralized economies will develop over time, especially economies with flexible decentralized governances, we can arrange economic components such that, under certain conditions, a sustainable economy may take shape in the long term. In the case of Solana’s network, these components take the form of token issuance \(via inflation\) and token burning.
-
-The dominant remittances from the Solana mining pool are validator rewards. The disinflationary mechanism is a flat, protocol-specified and adjusted, % of each transaction fee.

package/src/implemented-proposals/ed_overview/ed_mvp.md

@@ -1,24 +0,0 @@
----
-title: Economic Design MVP
----
-
-**Subject to change.**
-
-The preceding 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 application development.
-- Mechanism by which validators are rewarded via network inflation.
-- Ability to delegate tokens to validator nodes
-- Validator set commission fees on interest from delegated tokens.

package/src/implemented-proposals/ed_overview/ed_overview.md

@@ -1,19 +0,0 @@
----
-title: Cluster Economics
----
-
-**Subject to change. Follow most recent economic discussions in the Solana forums: https://forums.solana.com**
-
-Solana’s crypto-economic system is designed to promote a healthy, long term self-sustaining economy with participant incentives aligned to the security and decentralization of the network. The main participants in this economy are validation-clients. Their contributions to the network, state validation, and their requisite incentive mechanisms are discussed below.
-
-The main channels of participant remittances are referred to as protocol-based (inflationary) rewards and transaction fees. Protocol-based rewards are issuances from a global, protocol-defined, inflation rate. These rewards will constitute the total reward delivered to validation clients, the remaining sourced from transaction fees. In the early days of the network, it is likely that protocol-based rewards, deployed based on predefined issuance schedule, will drive the majority of participant incentives to participate in the network.
-
-These protocol-based rewards, to be distributed across the actively staked tokens on the network, are to be a result of a global supply inflation rate, calculated per Solana epoch and distributed amongst the active validator set. As discussed further below, the per annum inflation rate is based on a pre-determined disinflationary schedule. This provides the network with monetary supply predictability which supports long term economic stability and security.
-
-Transaction fees are market-based participant-to-participant transfers, attached to network interactions as a necessary motivation and compensation for the inclusion and execution of a proposed transaction. A mechanism for long-term economic stability and forking protection through partial burning of each transaction fee is also discussed below.
-
-A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics/ed_vce_overview.md), [Inflation Schedule](ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md), and [Transaction Fees](ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md). Also, the section titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunities and marketplace. Additionally, in [Storage Rent Economics](ed_storage_rent_economics.md), we describe an implementation of storage rent to account for the externality costs of maintaining the active state of the ledger. An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section.
-
-![](/img/economic_design_infl_230719.png)
-
-**Figure 1**: Schematic overview of Solana economic incentive design.

package/src/implemented-proposals/ed_overview/ed_references.md

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

package/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md

@@ -1,17 +0,0 @@
----
-title: Storage Rent Economics
----
-
-Each transaction that is submitted to the Solana ledger imposes costs. Transaction fees paid by the submitter, and collected by a validator, in theory, account for the acute, transactional, costs of validating and adding that data to the ledger. Unaccounted in this process is the mid-term storage of active ledger state, necessarily maintained by the rotating validator set. This type of storage imposes costs not only to validators but also to the broader network as active state grows so does data transmission and validation overhead. To account for these costs, we describe here our preliminary design and implementation of storage rent.
-
-Storage rent can be paid via one of two methods:
-
-Method 1: Set it and forget it
-
-With this approach, accounts with two-years worth of rent deposits secured are exempt from network rent charges. By maintaining this minimum-balance, the broader network benefits from reduced liquidity and the account holder can rest assured that their `Account::data` will be retained for continual access/usage.
-
-Method 2: Pay per byte
-
-If an account has less than two-years worth of deposited rent the network charges rent on a per-epoch basis, in credit for the next epoch. This rent is deducted at a rate specified in genesis, in lamports per kilobyte-year.
-
-For information on the technical implementation details of this design, see the [Rent](../rent.md) section.

package/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_overview.md

@@ -1,9 +0,0 @@
----
-title: Validation-client Economics
----
-
-**Subject to change. Follow most recent economic discussions in the Solana forums: https://forums.solana.com**
-
-Validator-clients are eligible to charge commission on inflationary rewards distributed to staked tokens. This compensation is for providing compute \(CPU+GPU\) resources to validate and vote on a given PoH state. These protocol-based rewards are determined through an algorithmic disinflationary schedule as a function of total token supply. The network is expected to launch with an annual inflation rate around 8%, set to decrease by 15% per year until a long-term stable rate of 1.5% is reached, however these parameters are yet to be finalized by the community. These issuances are to be split and distributed to participating validators, with around 95% of the issued tokens allocated for validator rewards initiall (the remaining 5% reserved for Foundation operating expenses). Because the network will be distributing a fixed amount of inflation rewards across the stake-weighted validator set, the yield observed for staked tokens will be primarily a function of the amount of staked tokens in relation to the total token supply.
-
-Additionally, validator clients may earn revenue through fees via state-validation transactions. For clarity, we separately describe the design and motivation of these revenue distributions for validation-clients below: state-validation protocol-based rewards and state-validation transaction fees and rent.

package/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md

@@ -1,64 +0,0 @@
----
-title: Inflation Schedule
----
-
-**Subject to change. Follow most recent economic discussions in the Solana forums: https://forums.solana.com**
-
-Validator-clients have two functional roles in the Solana network:
-
-- Validate \(vote\) the current global state of their observed PoH.
-- Be elected as ‘leader’ on a stake-weighted round-robin schedule during which time they are responsible for collecting outstanding transactions and incorporating them into their observed PoH, thus updating the global state of the network and providing chain continuity.
-
-Validator-client rewards for these services are to be distributed at the end of each Solana epoch. As previously discussed, compensation for validator-clients is provided via a commission charged on the protocol-based annual inflation rate dispersed in proportion to the stake-weight of each validator-node \(see below\) along with leader-claimed transaction fees available during each leader rotation. I.e. during the time a given validator-client is elected as leader, it has the opportunity to keep a portion of each transaction fee, less a protocol-specified amount that is destroyed \(see [Validation-client State Transaction Fees](ed_vce_state_validation_transaction_fees.md)\).
-
-The effective protocol-based annual staking yield \(%\) per epoch received by validation-clients is to be a function of:
-
-- the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](ed_vce_overview.md)\)
-- the fraction of staked SOLs out of the current total circulating supply,
-- the commission charged by the validation service,
-- the up-time/participation \[% of available slots that validator had opportunity to vote on\] of a given validator over the previous epoch.
-
-The first factor is a function of protocol parameters only \(i.e. independent of validator behavior in a given epoch\) and results in an inflation schedule designed to incentivize early participation, provide clear monetary stability and provide optimal security in the network.
-
-As a first step to understanding the impact of the _Inflation Schedule_ on the Solana economy, we’ve simulated the upper and lower ranges of what token issuance over time might look like given the current ranges of Inflation Schedule parameters under study.
-
-Specifically:
-
-- _Initial Inflation Rate_: 7-9%
-- _Dis-inflation Rate_: -14-16%
-- _Long-term Inflation Rate_: 1-2%
-
-Using these ranges to simulate a number of possible Inflation Schedules, we can explore inflation over time:
-
-![](/img/p_inflation_schedule_ranges_w_comments.png)
-
-In the above graph, the average values of the range are identified to illustrate the contribution of each parameter.
-From these simulated _Inflation Schedules_, we can also project ranges for token issuance over time.
-
-![](/img/p_total_supply_ranges.png)
-
-Finally we can estimate the _Staked Yield_ on staked SOL, if we introduce an additional parameter, previously discussed, _% of Staked SOL_:
-
-$$
-\%~\text{SOL Staked} = \frac{\text{Total SOL Staked}}{\text{Total Current Supply}}
-$$
-
-In this case, because _% of Staked SOL_ is a parameter that must be estimated (unlike the _Inflation Schedule_ parameters), it is easier to use specific _Inflation Schedule_ parameters and explore a range of _% of Staked SOL_. For the below example, we’ve chosen the middle of the parameter ranges explored above:
-
-- _Initial Inflation Rate_: 8%
-- _Dis-inflation Rate_: -15%
-- _Long-term Inflation Rate_: 1.5%
-
-The values of _% of Staked SOL_ range from 60% - 90%, which we feel covers the likely range we expect to observe, based on feedback from the investor and validator communities as well as what is observed on comparable Proof-of-Stake protocols.
-
-![](/img/p_ex_staked_yields.png)
-
-Again, the above shows an example _Staked Yield_ that a staker might expect over time on the Solana network with the _Inflation Schedule_ as specified. This is an idealized _Staked Yield_ as it neglects validator uptime impact on rewards, validator commissions, potential yield throttling and potential slashing incidents. It additionally ignores that _% of Staked SOL_ is dynamic by design - the economic incentives set up by this _Inflation Schedule_.
-
-### Adjusted Staking Yield
-
-A complete appraisal of earning potential from staking tokens should take into account staked _Token Dilution_ and its impact on staking yield. For this, we define _adjusted staking yield_ as the change in fractional token supply ownership of staked tokens due to the distribution of inflation issuance. I.e. the positive dilutive effects of inflation.
-
-We can examine the _adjusted staking yield_ as a function of the inflation rate and the percent of staked tokens on the network. We can see this plotted for various staking fractions here:
-
-![](/img/p_ex_staked_dilution.png)

package/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md

@@ -1,20 +0,0 @@
----
-title: State-validation Transaction Fees
----
-
-**Subject to change.**
-
-Each transaction 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 destroyed, with the remaining fee going to the current leader processing the transaction. A scheduled global inflation rate provides a source for rewards distributed to validation-clients, through the process described above.
-
-Transaction fees are set by the network cluster based on recent historical throughput, see [Congestion Driven Fees](../../transaction-fees.md#congestion-driven-fees). This minimum portion of each transaction fee can be dynamically adjusted depending on historical gas usage. In this way, the protocol can use the minimum fee to target a desired hardware utilization. By monitoring a protocol specified gas usage with respect to a desired, target usage amount, the minimum fee can be raised/lowered which should, in turn, lower/raise the actual gas usage per block until it reaches the target amount. This adjustment process can be thought of as similar to the difficulty adjustment algorithm in the Bitcoin protocol, however in this case it is adjusting the minimum transaction fee to guide the transaction processing hardware usage to a desired level.
-
-As mentioned, a fixed-proportion of each transaction fee is to be destroyed. The intent of this design is to retain leader incentive to include as many transactions as possible within the leader-slot time, while providing an inflation limiting mechanism that protects against "tax evasion" attacks \(i.e. side-channel fee payments\)[1](../ed_references.md).
-
-Additionally, the burnt fees can be a consideration in fork selection. In the case of a PoH fork with a malicious, censoring leader, we would expect the total fees destroyed to be less than a comparable honest fork, due to the fees lost from censoring. If the censoring leader is to compensate for these lost protocol fees, they would have to replace the burnt fees on their fork themselves, thus potentially reducing the incentive to censor in the first place.