gaspersic/solana
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Move from gitbook to docusaurus, build docs in Travis CI (#10970)

Browse Source 
* 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>
This commit is contained in:
Dan Albert
2020-07-10 23:11:07 -06:00
committed by GitHub
parent 4046f87134
commit ffeac298a2
172 changed files with 2862 additions and 3429 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
docs/src/proposals/tick-verification.md
View File

@@ -1,4 +1,6 @@
# Tick Verification
---
title: Tick Verification
---
This design the criteria and validation of ticks in a slot. It also describes
error handling and slashing conditions encompassing how the system handles
@@ -7,8 +9,8 @@ transmissions that do not meet these requirements.
# Slot structure
Each slot must contain an expected `ticks_per_slot` number of ticks. The last
shred in a slot must contain only the entirety of the last tick, and nothing
else. The leader must also mark this shred containing the last tick with the
shred in a slot must contain only the entirety of the last tick, and nothing
else. The leader must also mark this shred containing the last tick with the
`LAST_SHRED_IN_SLOT` flag. Between ticks, there must be `hashes_per_tick`
number of hashes.
@@ -16,54 +18,53 @@ number of hashes.
Malicious transmissions `T` are handled in two ways:
1) If a leader can generate some erronenous transmission `T` and also some
alternate transmission `T'` for the same slot without violating any slashing
rules for duplicate transmissions (for instance if `T'` is a subset of `T`),
then the cluster must handle the possibility of both transmissions being live.
1. If a leader can generate some erronenous transmission `T` and also some
alternate transmission `T'` for the same slot without violating any slashing
rules for duplicate transmissions (for instance if `T'` is a subset of `T`),
then the cluster must handle the possibility of both transmissions being live.
Thus this means we cannot mark the erronenous transmission `T` as dead because
the cluster may have reached consensus on `T'`. These cases necessitate a
the cluster may have reached consensus on `T'`. These cases necessitate a
slashing proof to punish this bad behavior.
2) Otherwise, we can simply mark the slot as dead and not playable. A slashing
proof may or may not be necessary depending on feasibility.
2. Otherwise, we can simply mark the slot as dead and not playable. A slashing
proof may or may not be necessary depending on feasibility.
# Blockstore receiving shreds
When blockstore receives a new shred `s`, there are two cases:
1) `s` is marked as `LAST_SHRED_IN_SLOT`, then check if there exists a shred
`s'` in blockstore for that slot where `s'.index > s.index` If so, together `s`
and `s'` constitute a slashing proof.
1. `s` is marked as `LAST_SHRED_IN_SLOT`, then check if there exists a shred
`s'` in blockstore for that slot where `s'.index > s.index` If so, together `s`
and `s'` constitute a slashing proof.
2) Blockstore has already received a shred `s'` marked as `LAST_SHRED_IN_SLOT`
with index `i`. If `s.index > i`, then together `s` and `s'`constitute a
slashing proof. In this case, blockstore will also not insert `s`.
3) Duplicate shreds for the same index are ignored. Non-duplicate shreds for
the same index are a slashable condition. Details for this case are covered
in the `Leader Duplicate Block Slashing` section.
2. Blockstore has already received a shred `s'` marked as `LAST_SHRED_IN_SLOT`
with index `i`. If `s.index > i`, then together `s` and `s'`constitute a
slashing proof. In this case, blockstore will also not insert `s`.
3. Duplicate shreds for the same index are ignored. Non-duplicate shreds for
the same index are a slashable condition. Details for this case are covered
in the `Leader Duplicate Block Slashing` section.
# Replaying and validating ticks
1) Replay stage replays entries from blockstore, keeping track of the number of
ticks it has seen per slot, and verifying there are `hashes_per_tick` number of
hashes between ticcks. After the tick from this last shred has been played,
replay stage then checks the total number of ticks.
1. Replay stage replays entries from blockstore, keeping track of the number of
ticks it has seen per slot, and verifying there are `hashes_per_tick` number of
hashes between ticcks. After the tick from this last shred has been played,
replay stage then checks the total number of ticks.
Failure scenario 1: If ever there are two consecutive ticks between which the
number of hashes is `!= hashes_per_tick`, mark this slot as dead.
Failure scenario 2: If the number of ticks != `ticks_per_slot`, mark slot as
dead.
Failure scenario 2: If the number of ticks != `ticks_per_slot`, mark slot as
dead.
Failure scenario 3: If the number of ticks reaches `ticks_per_slot`, but we still
haven't seen the `LAST_SHRED_IN_SLOT`, mark this slot as dead.
haven't seen the `LAST_SHRED_IN_SLOT`, mark this slot as dead.
2) When ReplayStage reaches a shred marked as the last shred, it checks if this
last shred is a tick.
2. When ReplayStage reaches a shred marked as the last shred, it checks if this
last shred is a tick.
Failure scenario: If the signed shred with the `LAST_SHRED_IN_SLOT` flag cannot
be deserialized into a tick (either fails to deserialize or deserializes into
an entry), mark this slot as dead.
be deserialized into a tick (either fails to deserialize or deserializes into
an entry), mark this slot as dead.