Cleanup programming model doc (#10274)
This commit is contained in:
parent
f9ee97d6f5
commit
c600cfc655
|
@ -1,20 +1,20 @@
|
||||||
|
|
||||||
.----------------------------------------.
|
.-------------------------------------.
|
||||||
| Solana Runtime |
|
| Solana Runtime |
|
||||||
| |
|
| |
|
||||||
| .------------. .------------. |
|
.----------. | .------------. .------------. |
|
||||||
| | | | | |
|
| Program | | | BPF | | Executable | |
|
||||||
.-------->| Verifier +-->| Accounts | |
|
| Author +------>| Bytecode +-->| Account | |
|
||||||
| | | | | | |
|
| | | | Verifier | | | |
|
||||||
.----------. | | `------------` `------------` |
|
`----------` | `------------` `------------` |
|
||||||
| +--------` | ^ |
|
| | |
|
||||||
| Client | | LoadAccounts | |
|
| .----------------` |
|
||||||
| +--------. | .----------------` |
|
| | LoadAccounts |
|
||||||
`----------` | | | |
|
| V |
|
||||||
| | .------+-----. .-------------. |
|
.----------. | .------------. .-------------. |
|
||||||
| | | | | | |
|
| | | | BPF | | BPF | |
|
||||||
`-------->| Loader +-->| Interpreter | |
|
| Client +------>| Loader +-->| Interpreter | |
|
||||||
| | | | | |
|
| | | | | | | |
|
||||||
| `------------` `-------------` |
|
`----------` | `------------` `-------------` |
|
||||||
| |
|
| |
|
||||||
`----------------------------------------`
|
`-------------------------------------`
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
# Programming Model
|
# 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 user-contributed _programs_. 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 transfered. Instructions are executed sequentially and atomically. If any instruction is invalid, any changes made within the transaction are discarded.
|
An _app_ interacts with a Solana cluster by sending it _transactions_ with one or more _instructions_. The Solana _runtime_ passes those instructions to user-contributed _programs_. 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 transfered. Instructions are executed sequentially and atomically. If any instruction is invalid, all account changes are discarded.
|
||||||
|
|
||||||
### Accounts and Signatures
|
### Accounts and Signatures
|
||||||
|
|
||||||
|
@ -10,7 +10,7 @@ The transaction also marks some accounts as _read-only accounts_. The runtime pe
|
||||||
|
|
||||||
### Recent Blockhash
|
### 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.
|
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
|
### Instructions
|
||||||
|
|
||||||
|
@ -22,7 +22,7 @@ Each instruction specifies a single program account \(which must be marked execu
|
||||||
|
|
||||||
As shown in the diagram above a client creates a program and compiles it to an ELF shared object containing BPF bytecode and sends it to the Solana cluster. The cluster stores the program locally and makes it available to clients via a _program ID_. The program ID is a _public key_ generated by the client and is used to reference the program in subsequent transactions.
|
As shown in the diagram above a client creates a program and compiles it to an ELF shared object containing BPF bytecode and sends it to the Solana cluster. The cluster stores the program locally and makes it available to clients via a _program ID_. The program ID is a _public key_ generated by the client 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 programs, which is compiled to BPF using the [LLVM compiler infrastructure](https://llvm.org).
|
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
|
## Storing State between Transactions
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue