Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: typos #1602

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from
Open

Fix: typos #1602

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
3ea50f2
Fix: typo
omahs Jul 20, 2023
caac1f5
Fix: typos
omahs Jul 20, 2023
f302024
Fix: typos
omahs Jul 20, 2023
e394015
Fix: typos
omahs Jul 20, 2023
bbc5d56
Merge branch 'develop' into patch-1
kladkogex Jul 21, 2023
70ac78c
Merge branch 'develop' into patch-1
kladkogex Aug 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,13 +10,13 @@

[![Discord](https://img.shields.io/discord/534485763354787851.svg)](https://discord.gg/vvUtWJB)

Skaled is SKALE Proof-Of-Stake blockchain client, compatible with ETH ecocystem, including EVM, Solidity, Metamask and Truffle. It uses [SKALE BFT Consensus engine](https://github.com/skalenetwork/skale-consensus). It is currently actively developed and maintained by SKALE Labs, and intended to be used for [SKALE blockchains](https://skale.space/technology).
Skaled is SKALE Proof-Of-Stake blockchain client, compatible with ETH ecosystem, including EVM, Solidity, Metamask and Truffle. It uses [SKALE BFT Consensus engine](https://github.com/skalenetwork/skale-consensus). It is currently actively developed and maintained by SKALE Labs, and intended to be used for [SKALE blockchains](https://skale.space/technology).

The SKALE network supports an unlimited number of independent blockchains with zero gas fees, instant finality, and high transaction throughput. SKALE is the first live blockchain with Linear Scaling. As more nodes join the network, the capacity of the network also grows.

## Forklessness

Skaled is forkless, meaning that blockchain a linear chain (and not a tree of forks as with ETH 1.0). Every block is provably finalized within finite time.
Skaled is forkless, meaning that the blockchain is a linear chain (and not a tree of forks as with ETH 1.0). Every block is provably finalized within finite time.


## Asynchronous block production
Expand All @@ -29,7 +29,7 @@ Skaled is the only provably secure ETH compatible PoS client. Security is proven

## Survivability

The network is assumed to bef fully asynchronous meaning that there is no upper limit for the packet delivery time. In case of a temporarily network split, the protocol can wait indefinitely long until the split is resolved and then resume normal block production.
The network is assumed to be fully asynchronous meaning that there is no upper limit for the packet delivery time. In case of a temporary network split, the protocol can wait indefinitely long until the split is resolved and then resume normal block production.

## Historic origins

Expand Down
6 changes: 3 additions & 3 deletions docs/skaled-disk-activity-and-crash-resistance-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ There are 3 parts where skaled can recover:
- storing blocks and extras in blocks_and_extras DB
- managing block rotation (rotation of 4 DBs in blocks_and_extras)

Each place in the code where commit to DB happens has it’s unique ID. We will use these IDs in the program flow description to be sure that crashes can be handled properly.
Each place in the code where commit to DB happens has its unique ID. We will use these IDs in the program flow description to be sure that crashes can be handled properly.



Expand All @@ -18,11 +18,11 @@ Each place in the code where commit to DB happens has it’s unique ID. We will
| 2 | (not used in actual code) if starting from “clean DB” - state DB is explicitly cleared | ` OverlayDB::clearDB` | clearDB | currently irrelevant |
| 3 | If started from empty blockchain - insert genesis block TODO WithExisting::Kill and WithExisting::Verify may introduce another behavior | `BlockChain::open` | insert_genesis | normal program flow |
| 4 | If current DB piece doesn’t contain ‘pieceUsageBytes’ - it means that there was crash in previous rotation - and we need to fix new DB piece: 1. re-insert genesis 2. insert 0 pieceUsageBytes | `BlockChain::open` | fix_bad_rotation | recovery flow |
| 5 | (not relevant, but historically important) If existing DB was created by skaled with broken block rotation - then recompute DB usage by blocks and store it in DB (version appproximately strictly before 3.7.1) | `BlockChain::recomputeExistingOccupiedSpaceForBlockRotation` | recompute_piece_usage | currently irrelevant |
| 5 | (not relevant, but historically important) If existing DB was created by skaled with broken block rotation - then recompute DB usage by blocks and store it in DB (version approximately strictly before 3.7.1) | `BlockChain::recomputeExistingOccupiedSpaceForBlockRotation` | recompute_piece_usage | currently irrelevant |
| 6 | New agreed block comes from consensus | `SkaleHost::createBlock`, `Client::importTransactionsAsBlock → syncTransactions, sealUnconditionally, importWorkingBlock` | | normal program flow |
| 7 | Transactions are executed 1-by-1; some of them are reverted NOTE! When committing 1st transaction, all accumulated “partial” receipts from previous block are cleared up! (safe cache for receipts) | Block::execute, State::execute m_state.` clearPartialTransactionReceipts();` | OverlayDB_comit_N (commit of all state changes from transaction) N = sequential number of commit: 1,2,3….. | normal program flow |
| 8 | Block is written to DB | `BlockChain::insertBlockAndExtras` | insertBlockAndExtras | normal program flow |
| 9 | If block cannot be written to current DB piece - DB rotation is performed before it is written: 1. Directory with the oldest DB is removed 2. new leveldb in this directory is created and opened 3. new DB is marked as “current” 4. old DB is unmarked as current 5. genesis block is re-inserted to new DB piece (to not to rotate it out!) | ` BlockChain::rotateDBIfNeeded rotating_db_io::rotate` | 1. after_remove_oldest 2. after_open_leveldb 3. with_two_keys 4. genesis_after_rotate 5. after_genesis_after_rotate | normal program flow |
| 9 | If block cannot be written to current DB piece - DB rotation is performed before it is written: 1. Directory with the oldest DB is removed 2. new leveldb in this directory is created and opened 3. new DB is marked as “current” 4. old DB is unmarked as current 5. genesis block is re-inserted to new DB piece (to not rotate it out!) | ` BlockChain::rotateDBIfNeeded rotating_db_io::rotate` | 1. after_remove_oldest 2. after_open_leveldb 3. with_two_keys 4. genesis_after_rotate 5. after_genesis_after_rotate | normal program flow |

## Unmanaged disk access

Expand Down
6 changes: 3 additions & 3 deletions docs/snapshots.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,17 +16,17 @@ One of the main features of SKALE Network is node rotation, and this is performe

SKALE Network solves this by periodically performing snapshots of the SKALE chain file system on each node so that nodes can share the latest snapshot with incoming node `B`.

Additionally, a node can be restarted from a snapshot it the node was offline for a long period of time, if it cannot catch up with other nodes using SKALE Consensus' catch-up algorithm.
Additionally, a node can be restarted from a snapshot if the node was offline for a long period of time, if it cannot catch up with other nodes using SKALE Consensus' catch-up algorithm.

## Design

Skaled uses the btrfs file system to create snapshots.

Assumptions:
1. First block on SKALE chain occured at T<sub>firstBlock</sub>
1. First block on SKALE chain occurred at T<sub>firstBlock</sub>
2. node does snapshot every T<sub>snapshotInterval</sub> seconds (configurable number, stored in SKALE chain config, so it is similar for all nodes in SKALE chain )

Assume `k` snapshots were already done. Lets see when `k+1`-th will be done and ready to be used:
Assume `k` snapshots were already done. Let's see when `k+1`-th will be done and ready to be used:
1. `k+1`-th snapshot will be done once another block’s B timestamp crosses boundary (\[T<sub>firstBlock</sub> / T<sub>snapshotInterval</sub>] + 1) \* T<sub>snapshotInterval</sub>.
2. Node updates `last_snapshoted_block_with_hash` with `k`-th snapshot block number.
3. If it is time to do snapshot and node already has 3 snapshots stored it deletes the latest of them.
Expand Down
2 changes: 1 addition & 1 deletion docs/state-root-calculation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# State Root calculation

State Root is used to ensure blockchain state is the same on all the schain nodes.
StateRoot is calculated on each snapshot (after doing [n]-th snapshot we calculate it’s hash and use [n-1] -th snapshot’s hash as StateRoot).
StateRoot is calculated on each snapshot (after doing [n]-th snapshot we calculate its hash and use [n-1] -th snapshot’s hash as StateRoot).

[StateRoot = SHA256(Filestorage's hash, LastPrice's hash, Blocks' hash, State's hash)]

Expand Down