Move from gitbook to docusaurus, build docs in Travis CI (#10970)
* fix: ignore unknown fields in more RPC responses * Remove mdbook infrastructure * Delete gitattributes and other theme related items Move all docs to /docs folder to support Docusaurus * all docs need to be moved to /docs * can be changed in the future Add Docusaurus infrastructure * initialize docusaurus repo Remove trailing whitespace, add support for eslint Change Docusaurus configuration to support `src` * No need to rename the folder! Change a setting and we're all good to go. * Fixing rebase items * Remove unneccessary markdown file, fix type * Some fonts are hard to read. Others, not so much. Rubik, you've been sidelined. Roboto, into the limelight! * As much as we all love tutorials, I think we all can navigate around a markdown file. Say goodbye, `mdx.md`. * Setup deployment infrastructure * Move docs job from buildkite to travic * Fix travis config * Add vercel token to travis config * Only deploy docs after merge * Docker rust env * Revert "Docker rust env" This reverts commit f84bc208e807aab1c0d97c7588bbfada1fedfa7c. * Build CLI usage from docker * Pacify shellcheck * Run job on PR and new commits for publication * Update README * Fix svg image building * shellcheck Co-authored-by: Michael Vines <mvines@gmail.com> Co-authored-by: Ryan Shea <rmshea@users.noreply.github.com> Co-authored-by: publish-docs.sh <maintainers@solana.com>
This commit is contained in:
Dan Albert
GitHub
@@ -1,4 +1,6 @@
|
||||
# Cluster Economics
|
||||
---
|
||||
title: Cluster Economics
|
||||
---
|
||||
|
||||
**Subject to change.**
|
||||
|
||||
@@ -12,6 +14,6 @@ Transaction fees are market-based participant-to-participant transfers, attached
|
||||
|
||||
A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics/README.md), [State-validation Protocol-based Rewards](ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md). Also, the section titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunities and marketplace. Additionally, in [Storage Rent Economics](ed_storage_rent_economics.md), we describe an implementation of storage rent to account for the externality costs of maintaining the active state of the ledger. An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section.
|
||||
|
||||
|
||||
|
||||
|
||||
**Figure 1**: Schematic overview of Solana economic incentive design.
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# Economic Sustainability
|
||||
---
|
||||
title: Economic Sustainability
|
||||
---
|
||||
|
||||
**Subject to change.**
|
||||
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# Economic Design MVP
|
||||
---
|
||||
title: Economic Design MVP
|
||||
---
|
||||
|
||||
**Subject to change.**
|
||||
|
||||
@@ -6,7 +8,7 @@ The preceding sections, outlined in the [Economic Design Overview](../README.md)
|
||||
|
||||
## 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.
|
||||
- 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.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
# References
|
||||
---
|
||||
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)
|
||||
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
## Storage Rent Economics
|
||||
---
|
||||
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.
|
||||
|
||||
@@ -13,6 +15,3 @@ 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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,8 +1,9 @@
|
||||
# Validation-client Economics
|
||||
---
|
||||
title: Validation-client Economics
|
||||
---
|
||||
|
||||
**Subject to change.**
|
||||
|
||||
Validator-clients are eligible to receive protocol-based \(i.e. inflation-based\) rewards issued via stake-based annual interest rates \(calculated per epoch\) by providing compute \(CPU+GPU\) resources to validate and vote on a given PoH state. These protocol-based rewards are determined through an algorithmic disinflationary schedule as a function of total amount of circulating tokens. The network is expected to launch with an annual inflation rate around 15%, set to decrease by 15% per year until a long-term stable rate of 1-2% is reached. These issuances are to be split and distributed to participating validators, with around 90% of the issued tokens allocated for validator rewards. Because the network will be distributing a fixed amount of inflation rewards across the stake-weighted validator set, any individual validator's interest rate will be a function of the amount of staked SOL in relation to the circulating SOL.
|
||||
|
||||
Additionally, validator clients may earn revenue through fees via state-validation transactions. 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.
|
||||
|
||||
|
||||
@@ -1,33 +1,35 @@
|
||||
# State-validation Protocol-based Rewards
|
||||
---
|
||||
title: State-validation Protocol-based Rewards
|
||||
---
|
||||
|
||||
**Subject to change.**
|
||||
|
||||
Validator-clients have two functional roles in the Solana network:
|
||||
|
||||
* Validate \(vote\) the current global state of that PoH.
|
||||
* Be elected as ‘leader’ on a stake-weighted round-robin schedule during which time they are responsible for collecting outstanding transactions and incorporating them into the PoH, thus updating the global state of the network and providing chain continuity.
|
||||
- Validate \(vote\) the current global state of that PoH.
|
||||
- Be elected as ‘leader’ on a stake-weighted round-robin schedule during which time they are responsible for collecting outstanding transactions and incorporating them into the PoH, thus updating the global state of the network and providing chain continuity.
|
||||
|
||||
Validator-client rewards for these services are to be distributed at the end of each Solana epoch. As previously discussed, compensation for validator-clients is provided via a protocol-based annual inflation rate dispersed in proportion to the stake-weight of each validator \(see below\) along with leader-claimed transaction fees available during each leader rotation. I.e. during the time a given validator-client is elected as leader, it has the opportunity to keep a portion of each transaction fee, less a protocol-specified amount that is destroyed \(see [Validation-client State Transaction Fees](ed_vce_state_validation_transaction_fees.md)\).
|
||||
|
||||
The effective protocol-based annual interest rate \(%\) per epoch received by validation-clients is to be a function of:
|
||||
|
||||
* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](README.md)\)
|
||||
* the fraction of staked SOLs out of the current total circulating supply,
|
||||
* the up-time/participation \[% of available slots that validator had opportunity to vote on\] of a given validator over the previous epoch.
|
||||
- the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](README.md)\)
|
||||
- the fraction of staked SOLs out of the current total circulating supply,
|
||||
- the up-time/participation \[% of available slots that validator had opportunity to vote on\] of a given validator over the previous epoch.
|
||||
|
||||
The first factor is a function of protocol parameters only \(i.e. independent of validator behavior in a given epoch\) and results in a global validation reward schedule designed to incentivize early participation, provide clear monetary stability and provide optimal security in the network.
|
||||
|
||||
At any given point in time, a specific validator's interest rate can be determined based on the proportion of circulating supply that is staked by the network and the validator's uptime/activity in the previous epoch. For example, consider a hypothetical instance of the network with an initial circulating token supply of 250MM tokens with an additional 250MM vesting over 3 years. Additionally an inflation rate is specified at network launch of 7.5%, and a disinflationary schedule of 20% decrease in inflation rate per year \(the actual rates to be implemented are to be worked out during the testnet experimentation phase of mainnet launch\). With these broad assumptions, the 10-year inflation rate \(adjusted daily for this example\) is shown in **Figure 1**, while the total circulating token supply is illustrated in **Figure 2**. Neglected in this toy-model is the inflation suppression due to the portion of each transaction fee that is to be destroyed.
|
||||
|
||||
|
||||
|
||||
|
||||
**Figure 1:** In this example schedule, the annual inflation rate \[%\] reduces at around 20% per year, until it reaches the long-term, fixed, 1.5% rate.
|
||||
|
||||
|
||||
|
||||
|
||||
**Figure 2:** The total token supply over a 10-year period, based on an initial 250MM tokens with the disinflationary inflation schedule as shown in **Figure 1**. Over time, the interest rate, at a fixed network staked percentage, will reduce concordant with network inflation. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. As previously mentioned, the inflation rate is expected to stabilize near 1-2% which also results in a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for state-validation are not accounted for here. Given these example parameters, annualized validator-specific interest rates can be determined based on the global fraction of tokens bonded as stake, as well as their uptime/activity in the previous epoch. For the purpose of this example, we assume 100% uptime for all validators and a split in interest-based rewards between validators nodes of 80%/20%. Additionally, the fraction of staked circulating supply is assumed to be constant. Based on these assumptions, an annualized validation-client interest rate schedule as a function of % circulating token supply that is staked is shown in **Figure 3**.
|
||||
|
||||
|
||||
|
||||
|
||||
**Figure 3:** Shown here are example validator interest rates over time, neglecting transaction fees, segmented by fraction of total circulating supply bonded as stake.
|
||||
|
||||
|
||||
@@ -1,13 +1,15 @@
|
||||
# State-validation Transaction Fees
|
||||
---
|
||||
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.
|
||||
- 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.
|
||||
|
||||
|
||||
@@ -1,27 +1,28 @@
|
||||
# Validation Stake Delegation
|
||||
---
|
||||
title: Validation Stake Delegation
|
||||
---
|
||||
|
||||
**Subject to change.**
|
||||
|
||||
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 |
|
||||
| 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 can become involved in the Solana network/economy via delegation of previously acquired tokens with a reliable validation node to earn a portion of the interest generated.
|
||||
|
||||
Delegation of tokens to validation-clients provides a way for passive Solana token holders to become part of the active Solana economy and earn interest rates proportional to the interest rate generated by the delegated validation-client. Additionally, this feature intends to create a healthy validation-client market, with potential validation-client nodes competing to build reliable, transparent and profitable delegation services.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user