ffeac298a2
* 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> |
||
|---|---|---|
| .. | ||
| README.md | ||
README.md
| title |
|---|
| Builtin Programs |
Solana contains a small handful of builtin programs, which are required to run validator nodes. Unlike third-party programs, the builtin programs are part of the validator implementation and can be upgraded as part of cluster upgrades. Upgrades may occur to add features, fix bugs, or improve performance. Interface changes to individual instructions should rarely, if ever, occur. Instead, when change is needed, new instructions are added and previous ones are marked deprecated. Apps can upgrade on their own timeline without concern of breakages across upgrades.
The builtin programs include the System, Config, Stake, Vote, and BPFLoader programs. For each, we provide the program ID and describe each supported instruction. A transaction can mix and match instructions from different programs, as well include instructions from third-party programs.
System Program
Create accounts and transfer lamports between them
- Program ID:
11111111111111111111111111111111 - Instructions: SystemInstruction
Config Program
Add configuration data to the chain and the list of public keys that are permitted to modify it
- Program ID:
Config1111111111111111111111111111111111111 - Instructions: config_instruction
Unlike the other programs, the Config program does not define any individual instructions. It has just one implicit instruction, a "store" instruction. Its instruction data is a set of keys that gate access to the account, and the data to store in it.
Stake Program
Create stake accounts and delegate it to validators
- Program ID:
Stake11111111111111111111111111111111111111 - Instructions: StakeInstruction
Vote Program
Create vote accounts and vote on blocks
- Program ID:
Vote111111111111111111111111111111111111111 - Instructions: VoteInstruction
BPF Loader
Add programs to the chain.
- Program ID:
BPFLoader1111111111111111111111111111111111 - Instructions: LoaderInstruction
The BPF Loader marks itself as its "owner" of the executable account it creates to store your program. When a user invokes an instruction via a program ID, the Solana runtime will load both your executable account and its owner, the BPF Loader. The runtime then passes your program to the BPF Loader to process the instruction.