Add new proposal process
And move replication and enclave proposals there to get a feel for how it'd look.
This commit is contained in:
Greg Fitzgerald
parent
13d4e3f29f
commit
c83538a60c
|
|
@ -30,7 +30,7 @@ Rust coding conventions
|
|||
|
||||
* For function and method names, use `<verb>_<subject>`. For unit tests, that verb should
|
||||
always be `test` and for benchmarks the verb should always be `bench`. Avoid namespacing
|
||||
function names with some arbitrary word. Avoid abreviating words in function names.
|
||||
function names with some arbitrary word. Avoid abbreviating words in function names.
|
||||
|
||||
* As they say, "When in Rome, do as the Romans do." A good patch should acknowledge the coding
|
||||
conventions of the code that surrounds it, even in the case where that code has not yet been
|
||||
|
|
@ -43,31 +43,27 @@ Terminology
|
|||
Inventing new terms is allowed, but should only be done when the term is widely used and
|
||||
understood. Avoid introducing new 3-letter terms, which can be confused with 3-letter acronyms.
|
||||
|
||||
Some terms we currently use regularly in the codebase:
|
||||
|
||||
* fullnode: n. A fully participating network node.
|
||||
* hash: n. A SHA-256 Hash.
|
||||
* keypair: n. A Ed25519 key-pair, containing a public and private key.
|
||||
* pubkey: n. The public key of a Ed25519 key-pair.
|
||||
* sigverify: v. To verify a Ed25519 digital signature.
|
||||
[Terms currently in use](book/src/terminology.md)
|
||||
|
||||
|
||||
Proposing architectural changes
|
||||
---
|
||||
|
||||
Solana's architecture is described by a book generated from markdown files in the `src/` directory,
|
||||
currently maintained by @garious. To change the architecture, you'll need to at least propose a change
|
||||
with an RFC document, and create an issue to track its implementation. Here's the full process:
|
||||
Solana's architecture is described by a book generated from markdown files in
|
||||
the `book/src/` directory, maintained by an *editor* (currently @garious). To
|
||||
change the architecture, you'll need to at least propose a change the content
|
||||
under the [Proposed
|
||||
Changes](https://solana-labs.github.io/solana/proposals.html) chapter. Here's
|
||||
the full process:
|
||||
|
||||
1. Propose to a change to the architecture by creating a PR that adds a markdown document called an RFC
|
||||
(standing for "request for comments") to the directory `rfcs/`. Add at least the maintainer of the
|
||||
markdown book as a reviewer.
|
||||
2. The PR being merged indicates your proposed change was accepted and that the Solana maintainers
|
||||
support your plan of attack. Next, create an issue to track its implementation and create a PR
|
||||
that updates the RFC with a link to the issue. This link allows anyone to quickly check the
|
||||
implementation status of any RFC.
|
||||
3. Submit PRs that implement the RFC. Be sure to reference the issue created above in your PR description.
|
||||
Feel free to update the RFC as the implementation reveals the need for tweaks to the architecture,
|
||||
but if you do, be sure to add the maintainer of the markdown book as a reviewer to your PR.
|
||||
4. Once the implementation is complete, close the issue. Depending on the scope of the RFC, the maintainer
|
||||
of markdown book may then create a separate ticket to integrate the RFC into the book.
|
||||
1. Propose to a change to the architecture by creating a PR that adds a
|
||||
markdown document to the directory `book/src/` and references it from the
|
||||
[table of contents](book/src/SUMMARY.md). Add the editor and any relevant
|
||||
*maintainers* to the PR review.
|
||||
2. The PR being merged indicates your proposed change was accepted and that the
|
||||
editor and maintainers support your plan of attack.
|
||||
3. Submit PRs that implement the proposal. When the implementation reveals the
|
||||
need for tweaks to the architecture, be sure to update the proposal and have
|
||||
that change reviewed by the same people as in step 1.
|
||||
4. Once the implementation is complete, the editor will then work to integrate
|
||||
the document into the book.
|
||||
|
|
|
|||
|
|
@ -19,6 +19,10 @@
|
|||
- [Gossip Service](gossip.md)
|
||||
- [The Runtime](runtime.md)
|
||||
|
||||
- [Proposed Architectural Changes](proposals.md)
|
||||
- [Ledger Replication](ledger-replication.md)
|
||||
- [Secure Enclave](enclave.md)
|
||||
|
||||
## Appendix
|
||||
|
||||
- [Appendix](appendix.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
# Proposed Architectural Changes
|
||||
|
||||
The following architectural proposals have been accepted by the Solana team, but
|
||||
are not yet fully implemented. The proposals may be implemented as described,
|
||||
implemented differently as issues in the designs become evident, or not
|
||||
implemented at all. If implemented, the descriptions will be moved from this
|
||||
section to earlier chapters in a future version of this book.
|
||||
|
|
@ -152,11 +152,10 @@ The public key of the [account](#account) containing a [program](#program).
|
|||
|
||||
The public key of a [keypair](#keypair).
|
||||
|
||||
#### replicator
|
||||
#### runtime
|
||||
|
||||
A type of [client](#client) that stores [ledger](#ledger) segments and
|
||||
periodically submits storage proofs to the cluster; not a
|
||||
[fullnode](#fullnode).
|
||||
The component of a [fullnode](#fullnode) responsible for [program](#program)
|
||||
execution.
|
||||
|
||||
#### secret key
|
||||
|
||||
|
|
@ -225,11 +224,6 @@ for potential future use.
|
|||
A fraction of a [block](#block); the smallest unit sent between
|
||||
[fullnodes](#fullnode).
|
||||
|
||||
#### CBC block
|
||||
|
||||
Smallest encrypted chunk of ledger, an encrypted ledger segment would be made of
|
||||
many CBC blocks; `ledger_segment_size / cbc_block_size` to be exact.
|
||||
|
||||
#### curio
|
||||
|
||||
A scarce, non-fungible member of a set of curios.
|
||||
|
|
@ -239,16 +233,6 @@ A scarce, non-fungible member of a set of curios.
|
|||
The time, i.e. number of [slots](#slot), for which a [leader
|
||||
schedule](#leader-schedule) is valid.
|
||||
|
||||
#### fake storage proof
|
||||
|
||||
A proof which has the same format as a storage proof, but the sha state is
|
||||
actually from hashing a known ledger value which the storage client can reveal
|
||||
and is also easily verifiable by the network on-chain.
|
||||
|
||||
#### ledger segment
|
||||
|
||||
A sequence of [blocks](#block).
|
||||
|
||||
#### light client
|
||||
|
||||
A type of [client](#client) that can verify it's pointing to a valid
|
||||
|
|
@ -258,42 +242,6 @@ A type of [client](#client) that can verify it's pointing to a valid
|
|||
|
||||
Millions of [instructions](#instruction) per second.
|
||||
|
||||
#### runtime
|
||||
|
||||
The component of a [fullnode](#fullnode) responsible for [program](#program)
|
||||
execution.
|
||||
|
||||
#### storage proof
|
||||
|
||||
A set of SHA hash states which is constructed by sampling the encrypted version
|
||||
of the stored [ledger segment](#ledger-segment) at certain offsets.
|
||||
|
||||
#### storage proof challenge
|
||||
|
||||
A [transaction](#transaction) from a [replicator](#replicator) that verifiably
|
||||
proves that a [validator](#validator) [confirmed](#storage-proof-confirmation)
|
||||
a [fake proof](#fake-storage-proof).
|
||||
|
||||
#### storage proof claim
|
||||
|
||||
A [transaction](#transaction) from a [validator](#validator) which is after the
|
||||
timeout period given from the [storage proof
|
||||
confirmation](#storage-proof-confirmation) and which no successful
|
||||
[challenges](#storage-proof-challenge) have been observed which rewards the
|
||||
parties of the [storage proofs](#storage-proof) and confirmations.
|
||||
|
||||
#### storage proof confirmation
|
||||
|
||||
A [transaction](#transaction) from a [validator](#validator) which indicates
|
||||
the set of [real](#storage-proof) and [fake proofs](#fake-storage-proof)
|
||||
submitted by a [replicator](#replicator). The transaction would contain a list
|
||||
of proof hash values and a bit which says if this hash is valid or fake.
|
||||
|
||||
#### storage validation capacity
|
||||
|
||||
The number of keys and samples that a [validator](#validator) can verify each
|
||||
storage epoch.
|
||||
|
||||
#### thin client
|
||||
|
||||
A type of [client](#client) that trusts it is communicating with a valid
|
||||
|
|
|
|||
Loading…
Reference in New Issue