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

cleanup runtime chapter

This commit is contained in:
Anatoly Yakovenko 2019-02-12 08:11:29 -08:00 committed by Greg Fitzgerald
parent e9daf57d7f
commit 7ce9c0a2e9
2 changed files with 64 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
book/art/runtime.bob
View File

@ -1,9 +1,10 @@
.------------. .-----------. .---------------. .--------------. .-----------------------.
| PoH verify +---> | sigverify +--->| lock accounts +--->| validate fee +--->| allocate new accounts +--->
| TVU | `-----------` `---------------` `--------------` `-----------------------`
`------------`
.-----------. .-------------. .--------------. .--------------------. .---------------. .---------. .------------. .-----------------. .-----------------.
| sigverify +--->| lock memory +--->| validate fee +--->| allocate accounts +---> --->| load accounts +--->| execute +--->| PoH record +--->| commit accounts +-->| unlock accounts |
`-----------` `-------------` `--------------` `--------------------` `---------------` `---------` | TPU | `-----------------` `-----------------`
`------------`
.------------. .---------. .--------. .--------------. .--------------.
--->| load data +--->| execute +--->| record +--->| commit data +-->|unlock memory |
`------------` `---------` `--------` `--------------` `--------------`

82
book/src/runtime.md
View File

@ -27,58 +27,88 @@ entrypoint.
## Execution ## Execution
Transactions are batched and processed in a pipeline Transactions are batched and processed in a pipeline. The TPU and TVU follow a
slightly different path. The TPU runtime ensures that PoH record occurs before
memory is committed.
The TVU runtime ensures that PoH verification occurs before the runtime
processes any transactions.
<img alt="Runtime pipeline" src="img/runtime.svg" class="center"/> <img alt="Runtime pipeline" src="img/runtime.svg" class="center"/>
At the *execute* stage, the loaded pages have no data dependencies, so all the At the *execute* stage, the loaded accounts have no data dependencies, so all the
programs can be executed in parallel. programs can be executed in parallel.
The runtime enforces the following rules: The runtime enforces the following rules:
1. Only the *owner* program may modify the contents of an account. This means 1. Only the *owner* program may modify the contents of an account. This means
that upon assignment userdata vector is guaranteed to be zero. that upon assignment userdata vector is guaranteed to be zero.
2. Total balances on all the accounts is equal before and after execution of a 2. Total balances on all the accounts is equal before and after execution of a
transaction. transaction.
3. After the transaction is executed, balances of credit-only accounts must be 3. After the transaction is executed, balances of credit-only accounts must be
greater than or equal to the balances before the transaction. greater than or equal to the balances before the transaction.
4. All instructions in the transaction executed atomically. If one fails, all 4. All instructions in the transaction executed atomically. If one fails, all
account modifications are discarded. account modifications are discarded.
5. Before committing the accounts, the transactions are tagged with a count
from the PoH service, indicating the time transaction processing completed.
If that time falls outside the leader's allotted slot, the transactions
are discarded.
Execution of the program involves mapping the program's public key to an Execution of the program involves mapping the program's public key to an
entrypoint which takes a pointer to the transaction, and an array of loaded entrypoint which takes a pointer to the transaction, and an array of loaded
pages. accounts.
## SystemProgram Interface ## SystemProgram Interface
The interface is best described by the `Instruction::userdata` that the user The interface is best described by the `Instruction::userdata` that the user
encodes. encodes.
* `CreateAccount` - This allows the user to create and assign an account to a * `CreateAccount` - This allows the user to create an account with an allocated
Program. userdata array and assign it to a Program.
* `Assign` - allows the user to assign an existing account to a program.
* `Move` - moves tokens between accounts. * `Assign` - Allows the user to assign an existing account to a program.
* `Move` - Moves tokens between accounts.
## Program State Security
For blockchain to function correctly, the program code must be resilient to user
inputs. That is why in this design the program specific code is the only code
that can change the state of the userdata byte array in the Accounts that are
assigned to it. It is also the reason why `Assign` or `CreateAccount` must zero
out the userdata. Otherwise there would be no possible way for the program to
distinguish the recently assigned account userdata from a natively generated
state transition without some additional metadata from the runtime to indicate
that this memory is assigned instead of natively generated.
To pass messages between programs, the receiving program must accept the message
and copy the state over. But in practice a copy isn't needed and is
undesirable. The receiving program can read the state belonging to other
Accounts without copying it, and during the read it has a guarantee of the
sender program's state.
## Notes ## Notes
1. There is no dynamic memory allocation. Client's need to use `CreateAccount` * There is no dynamic memory allocation. Client's need to use `CreateAccount`
instructions to create memory before passing it to another program. This instructions to create memory before passing it to another program. This
instruction can be composed into a single transaction with the call to the instruction can be composed into a single transaction with the call to the
program itself. program itself.
2. Runtime guarantees that when memory is assigned to the program it is zero
initialized. * `CreateAccount` and `Assign` guarantee that when account is assigned to the
3. Runtime guarantees that a program's code is the only thing that can modify program, the Account's userdata is zero initialized.
memory that its assigned to
4. Runtime guarantees that the program can only spend tokens that are in * Once assigned to program an Account cannot be reassigned.
accounts that are assigned to it
5. Runtime guarantees the balances belonging to accounts are balanced before * Runtime guarantees that a program's code is the only code that can modify
and after the transaction Account userdata that the Account is assigned to.
6. Runtime guarantees that multiple instructions all executed successfully when
a transaction is committed. * Runtime guarantees that the program can only spend tokens that are in
accounts that are assigned to it.
* Runtime guarantees the balances belonging to accounts are balanced before
and after the transaction.
* Runtime guarantees that instructions all executed successfully when a
transaction is committed.
# Future Work # Future Work