blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Report and bail on broken links (#13540)

This commit is contained in:
Jack May 2020-11-11 17:46:24 -08:00 committed by GitHub
parent 89b474e192
commit eb306da148
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
16 changed files with 3209 additions and 1288 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/build.sh
View File

@ -16,6 +16,7 @@ source ../ci/rust-version.sh
# Build from /src into /build
npm run build
echo $?
# Publish only from merge commits and release tags
if [[ -n $CI ]]; then

5
docs/docusaurus.config.js
View File

@ -6,7 +6,8 @@ module.exports = {
baseUrl: "/",
favicon: "img/favicon.ico",
organizationName: "solana-labs", // Usually your GitHub org/user name.
projectName: "solana", // Usually your repo name.
projectName: "solana", // Usually your repo name.
onBrokenLinks: 'throw',
themeConfig: {
navbar: {
logo: {
@ -21,7 +22,7 @@ module.exports = {
position: "left",
},
{
to: "apps",
to: "developing/programming-model/overview",
label: "Develop",
position: "left",
},

4358
docs/package-lock.json generated
View File

File diff suppressed because it is too large Load Diff

6
docs/package.json
View File

@ -5,6 +5,8 @@
"scripts": {
"start": "docusaurus start",
"build": "docusaurus build",
"clear": "docusaurus clear",
"help": "docusaurus --help",
"swizzle": "docusaurus swizzle",
"deploy": "docusaurus deploy",
"format": "prettier --check \"**/*.{js,jsx,json,md,scss}\"",
@ -13,8 +15,8 @@
"lint:fix": "npm run lint -- --fix"
},
"dependencies": {
"@docusaurus/core": "^2.0.0-alpha.58",
"@docusaurus/preset-classic": "^2.0.0-alpha.58",
"@docusaurus/core": "^2.0.0-alpha.65",
"@docusaurus/preset-classic": "^2.0.0-alpha.65",
"@docusaurus/theme-search-algolia": "^2.0.0-alpha.32",
"babel-eslint": "^10.1.0",
"clsx": "^1.1.1",

53
docs/src/apps.md
View File

@ -1,53 +0,0 @@
---
title: Programming Model
---
An _app_ interacts with a Solana cluster by sending it _transactions_ with one or more _instructions_. The Solana _runtime_ passes those instructions to _programs_ deployed by app developers beforehand. An instruction might, for example, tell a program to transfer _lamports_ from one _account_ to another or create an interactive contract that governs how lamports are transferred. Instructions are executed sequentially and atomically for each transaction. If any instruction is invalid, all account changes in the transaction are discarded.
### Accounts and Signatures
Each transaction explicitly lists all account public keys referenced by the transaction's instructions. A subset of those public keys are each accompanied by a transaction signature. Those signatures signal on-chain programs that the account holder has authorized the transaction. Typically, the program uses the authorization to permit debiting the account or modifying its data.
The transaction also marks some accounts as _read-only accounts_. The runtime permits read-only accounts to be read concurrently. If a program attempts to modify a read-only account, the transaction is rejected by the runtime.
### Recent Blockhash
A transaction includes a recent blockhash to prevent duplication and to give transactions lifetimes. Any transaction that is completely identical to a previous one is rejected, so adding a newer blockhash allows multiple transactions to repeat the exact same action. Transactions also have lifetimes that are defined by the blockhash, as any transaction whose blockhash is too old will be rejected.
### Instructions
Each instruction specifies a single program account \(which must be marked executable\), a subset of the transaction's accounts that should be passed to the program, and a data byte array instruction that is passed to the program. The program interprets the data array and operates on the accounts specified by the instructions. The program can return successfully, or with an error code. An error return causes the entire transaction to fail immediately.
## Deploying Programs to a Cluster
![SDK tools](/img/sdk-tools.svg)
As shown in the diagram above, a program author creates a program and compiles it to an ELF shared object containing BPF bytecode and uploads it to the Solana cluster with a special _deploy_ transaction. The cluster makes it available to clients via a _program ID_. The program ID is an _address_ specified when deploying and is used to reference the program in subsequent transactions.
A program may be written in any programming language that can target the Berkley Packet Filter \(BPF\) safe execution environment. The Solana SDK offers the best support for C/C++ and Rust programs, which are compiled to BPF using the [LLVM compiler infrastructure](https://llvm.org).
## Storing State between Transactions
If the program needs to store state between transactions, it does so using _accounts_. Accounts are similar to files in operating systems such as Linux. Like a file, an account may hold arbitrary data and that data persists beyond the lifetime of a program. Also like a file, an account includes metadata that tells the runtime who is allowed to access the data and how.
Unlike a file, the account includes metadata for the lifetime of the file. That lifetime is expressed in "tokens", which is a number of fractional native tokens, called _lamports_. Accounts are held in validator memory and pay ["rent"](apps/rent.md) to stay there. Each validator periodically scans all accounts and collects rent. Any account that drops to zero lamports is purged.
In the same way that a Linux user uses a path to look up a file, a Solana client uses an _address_ to look up an account. The address is usually a 256-bit public key. To create an account with a public-key address, the client generates a _keypair_ and registers its public key using the `CreateAccount` instruction with preallocated fixed storage size in bytes. In fact, the account address can be an arbitrary 32 bytes, and there is a mechanism for advanced users to create derived addresses (`CreateAccountWithSeed`). Addresses are presented in Base58 encoding on user interfaces.
## Ownership of Accounts and Assignment to Programs
The created account is initialized to be _owned_ by a built-in program called the System program and is called a _system account_ aptly. An account includes "owner" metadata. The owner is a program ID. The runtime grants the program write access to the account if its ID matches the owner. For the case of the System program, the runtime allows clients to transfer lamports and importantly _assign_ account ownership, meaning changing owner to different program ID. If an account is not owned by a program, the program is only permitted to read its data and credit the account.
Also, if an account is marked "executable" in metadata, it will only be used by a _loader_ to run programs. For example, a BPF-compiled program is marked executable and loaded by the BPF loader when executing its transactions. No program is allowed to modify the contents of an executable account once deployed.
## Runtime Capability of Programs on Accounts
The runtime only permits the owner program to debit the account or modify its data. The program then defines additional rules for whether the client can modify accounts it owns. In the case of the System program, it allows users to transfer lamports by recognizing transaction signatures. If it sees the client signed the transaction using the keypair's _private key_, it knows the client authorized the token transfer.
In other words, the entire set of accounts owned by a given program can be regarded as a key-value store where a key is the account address and value is program-specific arbitrary binary data. A program author can decide how to manage the program's whole state as possibly many accounts.
After the runtime executes each of the transaction's instructions, it uses the account metadata to verify that none of the access rules were violated. If a program violates an access rule, the runtime discards all account changes made by all instructions and marks the transaction as failed.
## Smart Contracts
Programs don't always require transaction signatures, as the System program does. Instead, the program may manage _smart contracts_. A smart contract is a set of constraints that once satisfied, signal to a program that a token transfer or account update is permitted. For example, one could use the Budget program to create a smart contract that authorizes a token transfer only after some date. Once evidence that the date has past, the contract progresses, and token transfer completes.

2
docs/src/developing/clients/jsonrpc-api.md
View File

@ -639,7 +639,7 @@ Result:
#### Transaction Structure
Transactions are quite different from those on other blockchains. Be sure to review [Anatomy of a Transaction](../transaction.md) to learn about transactions on Solana.
Transactions are quite different from those on other blockchains. Be sure to review [Anatomy of a Transaction](developing/programming-model/transactions.md) to learn about transactions on Solana.
The JSON structure of a transaction is defined as follows:

2
docs/src/developing/deployed-programs/developing-rust.md
View File

@ -240,7 +240,7 @@ single-threaded environment, and must be deterministic:
should be used instead.
- The runtime enforces a limit on the number of instructions a program can
execute during the processing of one instruction. See [computation
budget](developing/programming-model/computation-budget.md) for more
budget](developing/programming-model/compute-budget.md) for more
information.
## Logging

2
docs/src/developing/deployed-programs/faq.md
View File

@ -26,7 +26,7 @@ See [call depth](overview.md#call-depth)
## Computational constraints
See [computational
constraints](developing/programming-model/computation-budget.md)
constraints](developing/programming-model/compute-budget.md)
## Float Rust types

6
docs/src/developing/programming-model/accounts.md
View File

@ -13,7 +13,7 @@ tells the runtime who is allowed to access the data and how.
Unlike a file, the account includes metadata for the lifetime of the file. That
lifetime is expressed in "tokens", which is a number of fractional native
tokens, called _lamports_. Accounts are held in validator memory and pay
["rent"](apps/rent.md) to stay there. Each validator periodically scans all
["rent"](#rent) to stay there. Each validator periodically scans all
accounts and collects rent. Any account that drops to zero lamports is purged.
In the same way that a Linux user uses a path to look up a file, a Solana client
@ -149,7 +149,7 @@ rent-exemption is described below.
Note: The rent rate can change in the future.
As of writing, the fixed rent fee is 19.055441478439427 lamports per byte-epoch
on the testnet and mainnet-beta clusters. An [epoch](../terminology.md#epoch) is
on the testnet and mainnet-beta clusters. An [epoch](terminology.md#epoch) is
targeted to be 2 days (For devnet, the rent fee is 0.3608183131797095 lamports
per byte-epoch with its 54m36s-long epoch).
@ -198,7 +198,7 @@ Program executable accounts are required by the runtime to be rent-exempt to
avoid being purged.
Note: Use the [`getMinimumBalanceForRentExemption` RPC
endpoint](jsonrpc-api.md#getminimumbalanceforrentexemption) to calculate the
endpoint](developing/clients/jsonrpc-api.md#getminimumbalanceforrentexemption) to calculate the
minimum balance for a particular account size. The following calculation is
illustrative only.

4
docs/src/developing/programming-model/program-derived-addresses.md
View File

@ -5,7 +5,7 @@ title: Program Derived Addresses
## Problem
Programs cannot generate signatures when issuing instructions to other programs
as defined in the [Cross-Program Invocations](cross-program-invocation.md)
as defined in the [Cross-Program Invocations](cpi.md)
design.
The lack of programmatic signature generation limits the kinds of programs that
@ -42,7 +42,7 @@ The key to the design is two-fold:
2. Allow programs to programmatically sign for programa addresses that are
present in instructions invoked via [Cross-Program
Invocations](cross-program-invocation.md).
Invocations](cpi.md).
Given the two conditions, users can securely transfer or assign the authority of
on-chain assets to program addresses and the program can then assign that

14
docs/src/implemented-proposals/rpc-transaction-history.md
View File

@ -8,14 +8,14 @@ rocksdb ledger will continue to serve as the primary data source, and then will
fall back to the external data store.
The affected RPC endpoints are:
* [getFirstAvailableBlock](https://docs.solana.com/apps/jsonrpc-api#getfirstavailableblock)
* [getConfirmedBlock](https://docs.solana.com/apps/jsonrpc-api#getconfirmedblock)
* [getConfirmedBlocks](https://docs.solana.com/apps/jsonrpc-api#getconfirmedblocks)
* [getConfirmedSignaturesForAddress](https://docs.solana.com/apps/jsonrpc-api#getconfirmedsignaturesforaddress)
* [getConfirmedTransaction](https://docs.solana.com/apps/jsonrpc-api#getconfirmedtransaction)
* [getSignatureStatuses](https://docs.solana.com/apps/jsonrpc-api#getsignaturestatuses)
* [getFirstAvailableBlock](developing/clients/jsonrpc-api.md#getfirstavailableblock)
* [getConfirmedBlock](developing/clients/jsonrpc-api.md#getconfirmedblock)
* [getConfirmedBlocks](developing/clients/jsonrpc-api.md#getconfirmedblocks)
* [getConfirmedSignaturesForAddress](developing/clients/jsonrpc-api.md#getconfirmedsignaturesforaddress)
* [getConfirmedTransaction](developing/clients/jsonrpc-api.md#getconfirmedtransaction)
* [getSignatureStatuses](developing/clients/jsonrpc-api.md#getsignaturestatuses)
Note that [getBlockTime](https://docs.solana.com/apps/jsonrpc-api#getblocktime)
Note that [getBlockTime](developing/clients/jsonrpc-api.md#getblocktime)
is not supported, as once https://github.com/solana-labs/solana/issues/10089 is
fixed then `getBlockTime` can be removed.

28
docs/src/integrations/exchange.md
View File

@ -150,11 +150,11 @@ generate a Solana keypair using any of our [wallet tools](../wallet-guide/cli.md
We recommend using a unique deposit account for each of your users.
Solana accounts are charged [rent](../apps/rent.md) on creation and once per
Solana accounts are charged [rent](developing/programming-model/accounts.md#rent) on creation and once per
epoch, but they can be made rent-exempt if they contain 2-years worth of rent in
SOL. In order to find the minimum rent-exempt balance for your deposit accounts,
query the
[`getMinimumBalanceForRentExemption` endpoint](../apps/jsonrpc-api.md#getminimumbalanceforrentexemption):
[`getMinimumBalanceForRentExemption` endpoint](developing/clients/jsonrpc-api.md#getminimumbalanceforrentexemption):
```bash
curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getMinimumBalanceForRentExemption","params":[0]}' localhost:8899
@ -179,7 +179,7 @@ The easiest way to track all the deposit accounts for your exchange is to poll
for each confirmed block and inspect for addresses of interest, using the
JSON-RPC service of your Solana api node.
- To identify which blocks are available, send a [`getConfirmedBlocks` request](../apps/jsonrpc-api.md#getconfirmedblocks),
- To identify which blocks are available, send a [`getConfirmedBlocks` request](developing/clients/jsonrpc-api.md#getconfirmedblocks),
passing the last block you have already processed as the start-slot parameter:
```bash
@ -190,7 +190,7 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"m
Not every slot produces a block, so there may be gaps in the sequence of integers.
- For each block, request its contents with a [`getConfirmedBlock` request](../apps/jsonrpc-api.md#getconfirmedblock):
- For each block, request its contents with a [`getConfirmedBlock` request](developing/clients/jsonrpc-api.md#getconfirmedblock):
```bash
curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getConfirmedBlock","params":[5, "json"]}' localhost:8899
@ -273,7 +273,7 @@ can request the block from RPC in binary format, and parse it using either our
You can also query the transaction history of a specific address.
- Send a [`getConfirmedSignaturesForAddress`](../apps/jsonrpc-api.md#getconfirmedsignaturesforaddress)
- Send a [`getConfirmedSignaturesForAddress`](developing/clients/jsonrpc-api.md#getconfirmedsignaturesforaddress)
request to the api node, specifying a range of recent slots:
```bash
@ -291,7 +291,7 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"m
```
- For each signature returned, get the transaction details by sending a
[`getConfirmedTransaction`](../apps/jsonrpc-api.md#getconfirmedtransaction) request:
[`getConfirmedTransaction`](developing/clients/jsonrpc-api.md#getconfirmedtransaction) request:
```bash
curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getConfirmedTransaction","params":["dhjhJp2V2ybQGVfELWM1aZy98guVVsxRCB5KhNiXFjCBMK5KEyzV8smhkVvs3xwkAug31KnpzJpiNPtcD5bG1t6", "json"]}' localhost:8899
@ -388,7 +388,7 @@ expires before retrying a withdrawal transfer that does not appear to have been
confirmed or finalized by the cluster. Otherwise, you risk a double spend. See
more on [blockhash expiration](#blockhash-expiration) below.
First, get a recent blockhash using the [`getFees` endpoint](../apps/jsonrpc-api.md#getfees)
First, get a recent blockhash using the [`getFees` endpoint](developing/clients/jsonrpc-api.md#getfees)
or the CLI command:
```bash
@ -403,12 +403,12 @@ solana transfer <USER_ADDRESS> <AMOUNT> --no-wait --blockhash <RECENT_BLOCKHASH>
```
You can also build, sign, and serialize the transaction manually, and fire it off to
the cluster using the JSON-RPC [`sendTransaction` endpoint](../apps/jsonrpc-api.md#sendtransaction).
the cluster using the JSON-RPC [`sendTransaction` endpoint](developing/clients/jsonrpc-api.md#sendtransaction).
#### Transaction Confirmations & Finality
Get the status of a batch of transactions using the
[`getSignatureStatuses` JSON-RPC endpoint](../apps/jsonrpc-api.md#getsignaturestatuses).
[`getSignatureStatuses` JSON-RPC endpoint](developing/clients/jsonrpc-api.md#getsignaturestatuses).
The `confirmations` field reports how many
[confirmed blocks](../terminology.md#confirmed-block) have elapsed since the
transaction was processed. If `confirmations: null`, it is [finalized](../terminology.md#finality).
@ -448,15 +448,15 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "
#### Blockhash Expiration
When you request a recent blockhash for your withdrawal transaction using the
[`getFees` endpoint](../apps/jsonrpc-api.md#getfees) or `solana fees`, the
[`getFees` endpoint](developing/clients/jsonrpc-api.md#getfees) or `solana fees`, the
response will include the `lastValidSlot`, the last slot in which the blockhash
will be valid. You can check the cluster slot with a
[`getSlot` query](../apps/jsonrpc-api.md#getslot); once the cluster slot is
[`getSlot` query](developing/clients/jsonrpc-api.md#getslot); once the cluster slot is
greater than `lastValidSlot`, the withdrawal transaction using that blockhash
should never succeed.
You can also doublecheck whether a particular blockhash is still valid by sending a
[`getFeeCalculatorForBlockhash`](../apps/jsonrpc-api.md#getfeecalculatorforblockhash)
[`getFeeCalculatorForBlockhash`](developing/clients/jsonrpc-api.md#getfeecalculatorforblockhash)
request with the blockhash as a parameter. If the response value is null, the
blockhash is expired, and the withdrawal transaction should never succeed.
@ -580,7 +580,7 @@ accounts do not:
deposited. Token accounts can be created explicitly with the
`spl-token create-account` command, or implicitly by the
`spl-token transfer --fund-recipient ...` command.
1. SPL Token accounts must remain [rent-exempt](https://docs.solana.com/apps/rent#rent-exemption)
1. SPL Token accounts must remain [rent-exempt](developing/programming-model/accounts.md#rent-exemption)
for the duration of their existence and therefore require a small amount of
native SOL tokens be deposited at account creation. For SPL Token v2 accounts,
this amount is 0.00203928 SOL (2,039,280 lamports).
@ -657,7 +657,7 @@ method described above. Each new block should be scanned for successful transact
issuing SPL Token [Transfer](https://github.com/solana-labs/solana-program-library/blob/096d3d4da51a8f63db5160b126ebc56b26346fc8/token/program/src/instruction.rs#L92)
or [Transfer2](https://github.com/solana-labs/solana-program-library/blob/096d3d4da51a8f63db5160b126ebc56b26346fc8/token/program/src/instruction.rs#L252)
instructions referencing user accounts, then querying the
[token account balance](https://docs.solana.com/apps/jsonrpc-api#gettokenaccountbalance)
[token account balance](developing/clients/jsonrpc-api.md#gettokenaccountbalance)
updates.
[Considerations](https://github.com/solana-labs/solana/issues/12318) are being

2
docs/src/offline-signing/durable-nonce.md
View File

@ -48,7 +48,7 @@ solana create-nonce-account nonce-keypair.json 1
2SymGjGV4ksPdpbaqWFiDoBz8okvtiik4KE9cnMQgRHrRLySSdZ6jrEcpPifW4xUpp4z66XM9d9wM48sA7peG2XL
```
> To keep the keypair entirely offline, use the [Paper Wallet](../wallet-guide/paper-wallet.md) keypair generation [instructions](../paper-wallet/paper-wallet-usage.md#seed-phrase-generation.md) instead
> To keep the keypair entirely offline, use the [Paper Wallet](wallet-guide/paper-wallet.md) keypair generation [instructions](wallet-guide/paper-wallet.md#seed-phrase-generation) instead
> [Full usage documentation](../cli/usage.md#solana-create-nonce-account)

2
docs/src/running-validator/validator-stake.md
View File

@ -71,7 +71,7 @@ account.
This is a normal transaction so the standard transaction fee will apply. The
transaction fee range is defined by the genesis block. The actual fee will
fluctuate based on transaction load. You can determine the current fee via the
[RPC API “getRecentBlockhash”](../apps/jsonrpc-api.md#getrecentblockhash)
[RPC API “getRecentBlockhash”](developing/clients/jsonrpc-api.md#getrecentblockhash)
before submitting a transaction.
Learn more about [transaction fees here](../implemented-proposals/transaction-fees.md).

4
docs/src/running-validator/validator-start.md
View File

@ -141,7 +141,7 @@ solana-keygen pubkey ASK
and then entering your seed phrase.
See [Paper Wallet Usage](../paper-wallet/paper-wallet-usage.md) for more info.
See [Paper Wallet Usage](../wallet-guide/paper-wallet.md) for more info.
---
@ -261,7 +261,7 @@ To force validator logging to the console add a `--log -` argument, otherwise
the validator will automatically log to a file.
> Note: You can use a
> [paper wallet seed phrase](../paper-wallet/paper-wallet-usage.md)
> [paper wallet seed phrase](../wallet-guide/paper-wallet.md)
> for your `--identity` and/or
> `--vote-account` keypairs. To use these, pass the respective argument as
> `solana-validator --identity ASK ... --vote-account ASK ...` and you will be

8
docs/src/wallet-guide/solflare.md
View File

@ -113,7 +113,7 @@ and then it will be submitted to the network.
## Staking SOL Tokens
SolFlare supports creating and managing stake accounts and delegations. To learn
about how staking on Solana works in general, check out our
[Staking Guide](../staking.md).
[Staking Guide](../staking).
### Create a Stake Account
You can use some of the SOL tokens in your wallet to create a new stake account.
@ -129,7 +129,7 @@ After you submit and [sign the transaction](#signing-a-transaction) you will see
your new stake account appear in the box labeled "Your Staking Accounts".
Stake accounts created on SolFlare set your wallet address as the
[staking and withdrawing authority](/staking/stake-accounts#understanding-account-authorities)
[staking and withdrawing authority](../staking/stake-accounts#understanding-account-authorities)
for your new account, which gives your wallet's key the authority to sign
for any transactions related to the new stake account.
@ -141,13 +141,13 @@ exist at a different address from your wallet.
SolFlare will locate any display all stake accounts on the
[selected network](#select-a-network)
for which your wallet address is assigned as the
[stake authority](../staking/stake-accounts.md#understanding-account-authorities).
[stake authority](../staking/stake-accounts#understanding-account-authorities).
Stake accounts that were created outside of SolFlare will also be displayed and
can be managed as long as the wallet you logged in with is assigned as the stake
authority.
### Delegate tokens in a Stake Account
Once you have [selected a validator](../staking.md#select-a-validator), you may
Once you have [selected a validator](../staking#select-a-validator), you may
delegate the tokens in one of your stake accounts to them. From the Staking
dashboard, click "Delegate" at the right side of a displayed stake account.
Select the validator you wish to delegate to from the drop down list and click