Sw Syncing RFC

RFC/src/Glossary.md

@@ -5,55 +5,62 @@ glossary to disambiguate ideas, and work towards a
 [ubiquitous language](https://blog.carbonfive.com/2016/10/04/ubiquitous-language-the-joy-of-naming/) for this project.
 
 ## Asset Issuer
-[Asset Issuer]: #asset-issuer 'An entity that creates digital assets on the Tari DAN'
+[Asset Issuer]: #asset-issuer "An entity that creates digital assets on the Tari DAN"
 
 An entity that creates digital assets on the Tari DAN. The Asset Issuer will specify the parameters of the contract template
 that defines the rules that govern the asset and the number and nature of its constituent tokens on issuance. The Asset Issuer
 will, generally, be the initial owner of the tokens.
 
 ## Bad Actor
-[Bad Actor]: #bad-actor 'A participant that acts maliciously or negligently to the detriment of the network or another participant'
+[Bad Actor]: #bad-actor "A participant that acts maliciously or negligently to the detriment of the network or another participant"
 
 A participant that acts maliciously or negligently to the detriment of the network or another participant.
 
 ## Base layer
-[Base Layer]: #base-layer 'The Tari layer handling payments and secured by proof of work'
+[Base Layer]: #base-layer "The Tari layer handling payments and secured by proof of work"
 
 
 The Tari Base layer is a merge-mined [blockchain] secured by proof-of-work. The base layer is primarily responsible for
 the emission of new Tari, for securing and managing [Tari coin] transfers.
 
 
 ## Base Node
-[base node]: #base-node 'A full Tari node running on the base layer, validating and propagating Tari coin transactions and blocks'
+[base node]: #base-node "A full Tari node running on the base layer, validating and propagating Tari coin transactions and blocks"
 
 A full Tari node running on the base layer. It's primary role is validating and propagating [Tari coin] transactions
 and blocks to the rest of the network.
 
 
 ## Block
-[block]: #block 'A collection transactions and associated metadata recorded as a single entity in the Tari blockchain'
+[block]: #block "A collection transactions and associated metadata recorded as a single entity in the Tari blockchain"
 
 A collection transactions and associated metadata recorded as a single entity in the Tari blockchain. The ordering of
  Tari transactions is set purely by the block height of the block they are recorded in. 
 
 
 ## Block reward
-[block reward]: #block-reward 'The amount of Tari created in every block'
+[block reward]: #block-reward "The amount of Tari created in every block"
 
 The amount of Tari created by the coinbase transaction in every block. The block reward is set by the 
 [emission schedule].
 
 
 ## Blockchain
-[blockchain]: #blockchain 'The linked sequence of Tari blocks on the Tari base layer'
+[blockchain]: #blockchain "The linked sequence of Tari blocks on the Tari base layer"
 
 A sequence of tari [block]s. Each block contains a hash of the previous valid block. Thus the blocks form a chain 
 with the property that changing anything in a block other than the head block requires rewriting the entire 
 blockchain from that point on.
 
+## Current head
+
+[currenthead]: #currenthead	"The last valid block of the longest chain"
+
+The last [block] of the base layer that represents the latest valid block. This [block] must be from the longest proof of work chain to be the current head. 
+
 ## Checkpoint
-[checkpoint]: #checkpoint 'A summary of the state of a Digital Asset that is recorded on the base layer'
+
+[checkpoint]: #checkpoint "A summary of the state of a Digital Asset that is recorded on the base layer"
 
 A hash of the state of a Digital Asset that is recorded on the base layer.
 
@@ -69,17 +76,17 @@ The first transaction in every Tari block yields a [Block Reward] according to t
 awarded to the miner that performed the Proof of Work for the block.
 
 ## Committee
-[committee]: #committee 'A group of validator nodes that are responsible for managing a specific Digital Asset'
+[committee]: #committee "A group of validator nodes that are responsible for managing a specific Digital Asset"
 
 A group of [Validator Node]s that are responsible for managing the state of a specific [Digital Asset]. A committee is selected
 during asset issuance and can be updated at [Checkpoint]s.
 
 ## CommitteeSelectionStrategy
-[CommitteeSelectionStrategy]: #committeeselectionstrategy 'A strategy for the DAN to select candidates for the committee from the available registered Validator Nodes'
+[CommitteeSelectionStrategy]: #committeeselectionstrategy "A strategy for the DAN to select candidates for the committee from the available registered Validator Nodes"
 A strategy for the DAN to algorithmically select candidates for the committee from the available registered Validator Nodes. The VNs will need accept the nomination to become part of the committee.
 
 ## ConsensusStrategy
-[ConsensusStrategy]: #consensusstrategy 'The approach that will be taken for a committee to reach consensus on instructions'
+[ConsensusStrategy]: #consensusstrategy "The approach that will be taken for a committee to reach consensus on instructions"
 
 The approach that will be taken for a committee to reach consensus on the validity of instructions that are performed on a
 given Digital Asset.
@@ -102,13 +109,13 @@ created by [asset issuer]s on the Tari 2nd layer. For example, a promoter might
 
 
 ## Digital Asset Network
-[Digital Asset Network]: #digital-asset-network 'The Tari second layer. All digital asset interactions are managed here.'
+[Digital Asset Network]: #digital-asset-network "The Tari second layer. All digital asset interactions are managed here."
 
 The Tari second layer. All digital asset interactions are managed on the Tari Digital Assets Network (DAN). These
 interactions (defined in [instruction]s) are processed and validated by [Validator Node]s.
 
 ## DigitalAssetTemplate
-[DigitalAssetTemplate]: #digitalassettemplate 'A set of non-turing complete contract types supported by the DAN'
+[DigitalAssetTemplate]: #digitalassettemplate "A set of non-turing complete contract types supported by the DAN"
 
 A DigitalAssetTemplate is one of a set of contract types supported by the DAN. These contracts are non-turing complete and consist of
 rigid rule-sets with parameters that can be set by Asset Issuers.
@@ -123,7 +130,7 @@ asset. Depending on the DA created, tokens can represent tickets, in-game items,
 
 
 ## Instructions
-[instruction]: #instructions 'Second-layer network commands for managing digital asset state'
+[instruction]: #instructions "Second-layer network commands for managing digital asset state"
 
 Instructions are the [digital asset network] equivalent of [transaction]s. Instructions are issued by asset issuers and
 client applications and are relayed by the DAN to the [validator node]s that are managing the associated
@@ -145,7 +152,7 @@ longest proof-of-work chain. Miners usually draw from the mempool to build up tr
 
 
 ## Mimblewimble
-[mimblewimble]: #mimblewimble 'a privacy-centric cryptocurrency protocol'
+[mimblewimble]: #mimblewimble "a privacy-centric cryptocurrency protocol"
 
 Mimblewimble is a privacy-centric cryptocurrency protocol. It was
 [dropped](https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.txt) in the Bitcoin Developers chatroom by an
@@ -168,14 +175,14 @@ A mathematical demonstration that a value inside a [commitment] (i.e. it is hidd
 [Mimblewimble], range proofs are used to prove that outputs are positive values.
 
 ## RegistrationCollateral
-[RegistrationCollateral]: #registrationcollateral 'An amount of tari coin that is locked up on the base layer when a [Validator Node] is registered'
+[RegistrationCollateral]: #registrationcollateral "An amount of tari coin that is locked up on the base layer when a [Validator Node] is registered"
 
 An amount of tari coin that is locked up on the base layer when a [Validator Node] is registered. In order to make Sybil attacks expensive and to
 provide an authorative base layer registry of [validator node]s they will need to lock up a amount of [Tari Coin] on the [Base Layer] using a
 registration transaction to begin acting as a VN on the DAN.
 
 ## RegistrationTerm
-[RegistrationTerm]: #registrationterm 'The minimum amount of time that a VN registration lasts'
+[RegistrationTerm]: #registrationterm "The minimum amount of time that a VN registration lasts"
 
 The minimum amount of time that a VN registration lasts, the RegistrationCollateral can only be released after this minimum period has elapsed.
 
@@ -195,7 +202,7 @@ The current synchronisation state of a [Base Node]. This can either be
   transactions.
 
 ## Transaction
-[transaction]: #transaction 'Base layer tari coin transfers.'
+[transaction]: #transaction "Base layer tari coin transfers."
 
 Transactions are activities recorded on the Tari [blockchain] running on the [base layer]. Transactions always involve a
 transfer of [Tari coin]s.
@@ -210,13 +217,13 @@ Transactions or blocks are `unvalidated` when first received by a [Base Node]. A
 `Validated` blocks are added to the [blockchain] and propagated to peers.
 
 ## Tari Coin
-[tari coin]: #tari-coin 'The base layer token'
+[tari coin]: #tari-coin "The base layer token"
 
 The base layer token. Tari coins are released according to the [emission schedule] on the Tari [base layer] 
 [blockchain] in [coinbase transaction]s.
 
 ## Trusted Node
-[trusted node]: #trusted-node 'A permissioned Validator Node nominated by an Asset Issuer'
+[trusted node]: #trusted-node "A permissioned Validator Node nominated by an Asset Issuer"
 
 A permissioned Validator Node nominated by an Asset Issuer that will form part of the committee for that Digital Asset.
 
@@ -232,7 +239,7 @@ UTXO values are hidden by their [commitment]s. Only the owner of the UTXO and (p
 
 
 ## Validator Node
-[validator node]: #validator-node 'A second-layer node that manages and validates digital asset state transitions'
+[validator node]: #validator-node "A second-layer node that manages and validates digital asset state transitions"
 
 Validator nodes (VNs) make up the Tari second layer, or [Digital Asset Network]. VNs are responsible for creating and
 updating [digital asset]s living on the Tari network.
@@ -242,6 +249,24 @@ updating [digital asset]s living on the Tari network.
 
 A Tari Wallet is responsible for managing key pairs, and for constructing and negotiating [transaction]s for transferring and receiving [tari coin]s on the [Base Layer]. 
 
+## Pruning horizon
+
+[pruninghorizon]: #pruninghorizon	"Block height at which pruning will commence"
+
+This is a local setting for each node to help reduce syncing time and bandwidth. This is the number of blocks from the chain tip beyond which a chain will be pruned.
+
+## Archive node
+
+[archivenode]: #archivenode	"a full history node"
+
+This is a full history [base node]. It will keep a complete history of every transaction ever received and it will not implement pruning.
+
+## Blockchain state
+
+[blockchainstate]: #blockchainstate	"This is a snapshot of how the blockchain looks"
+
+This is a complete snapshot of the blockchain at a spesific block height. This means pruned [utxo], complete set of kernals and headers up to that block height from genesis block is known.
+
 # Disclaimer
 
-This document is subject to the [disclaimer](../DISCLAIMER.md).
+This document is subject to the [disclaimer](../DISCLAIMER.md).

RFC/src/RFC-0110_BaseNodes.md

@@ -162,56 +162,17 @@ In addition, when a block has been validated and added to the blockchain:
 * The mempool MUST also remove all transactions that are present in the newly validated block.
 * The UTXO set MUST be updated; removing all inputs in the block, and adding all the new outputs in it.
 
-### Seeding nodes and Synchronising the chain
+### Synchronising and pruning of the chain
 
-When base nodes start up, they need to synchronize the blockchain with their peers.
+Syncing, pruning and cut-through is discussed in detail in [RFC-0140](RFC-0140_Syncing.md)
 
-Base Nodes that have just started up MUST perform the following in order to synchronize their blockchain state with the
-network:
+### Archival nodes
 
-1. The Base Node's [SynchronisationState] is set to `Synchronising`.
-1. Load a bootstrap list of peers from a configuration file, or a cached list, if this is not the first time that the
-   node has started.
-1. For each peer in this list:
-   1. Establish a connection with the peer.
-   1. Request a peer list from that peer.
-   1. Request information about the most recent chain state (total accumulated work, block height, etc.) from the peer.
-
-The Base Node will now be able to build a strategy for catching up to the network. The Base Node will implement its
-[SynchronisationStrategy], which reduces load on any single peer and optimises bandwidth usage to synchronise the
-blockchain as quickly as possible.
-
-In particular, Mimblewimble has some unique properties that could lead to very fast synchronisation strategies. For
-example, because of cut-through and pruning, the entire blockchain state can be represented by the current [UTXO] set
-and all the coinbase transaction inputs.
-
-The upshot of this is that a new node can be perfectly sure of the current blockchain state and not download any block
-history at all. All that is required is downloading the block _header_ history and the current UTXO set. Then
-verification is achieved by
-
-1. The UTXO set and knowledge of the emission rate are used to verify the coin supply.
-1. The transaction kernel history (present in the block headers) and the UTXO range proofs are used to verify that every
-   UTXO is legitimate.
-1. The proof of work can be verified from the block headers. Furthermore, if a commitment (e.g. a Merkle tree root) for
-   the UTXO set is stored in the block headers, it is straightforward to verify that the UTXO set corresponds to a block
-   in the chain.
-
-When Base Nodes receive blocks from peers while synchronizing, the usual
-[block validation](#block-validation-and-propagation) process is followed.
-
-### Pruning and cut-through
-[Pruning and cut-through]: #Pruning-and-cut-through "Remove already spent outputs from the [utxo]"
-
-In MimbleWimble, the state can be completely verified using the current [UTXO](utxo) set, the set of excess signatures (contained in the transaction kernels) and the proof-of-work. The full block and transaction history is not required. This allows base layer nodes to remove old used inputs from the [blockchain] and or the [mempool]. [Cut-through](cut-through) happens in the [mempool] while pruning happens in the [blockchain] with already confirmed transactions. This will remove the inputs and outputs, but will retain the excesses  of each [transaction]. 
-
-Pruning is only for the benefit of the local base node as it reduces the local blockchain size. A Base node will either run in archive mode or prune mode, if the base node is running in archive mode it should not prune. Pruned nodes will not be able to safely handle a sufficiently deep re-org. Only Archival nodes can roll back arbitrarily to handle large re-orgs, and so the network cannot run on pruned nodes alone.
-
-When running in pruning mode, [base node]s have the following responsibilities:
-
-1. MUST remove all spent outputs in it's current stored [UTXO](utxo) when a new block is received from another [base node].
+[Archival nodes](archivenode) are used to keep a complete history of the blockchain since genesis block, they do not employ pruning at all. These nodes will allow full syncing of the blockchain because normal nodes will not keep the full history to enable this. 
 
 
 
+[archivenode]: Glossary.md#archivenode
 
 [tari coin]: Glossary.md#tari-coin
 [blockchain]: Glossary.md#blockchain
@@ -227,4 +188,4 @@ When running in pruning mode, [base node]s have the following responsibilities:
 [SynchronisationStrategy]: Glossary.md#synchronisationstrategy
 [SynchronisationState]: Glossary.md#synchronisationstate
 [mining server]: Glossary.md#mining-server
-[cut-through]: RFC-0110_BaseNodes.md#Pruning-and-cut-through
+[cut-through]: RFC-0140_Syncing.md#Pruning-and-cut-through

RFC/src/RFC-0130_Mining.md

@@ -151,4 +151,4 @@ and Auxiliary blockchain is provided in the [Merged Mining TLU report] (https://
 [block]: Glossary.md#block
 [mempool]: Glossary.md#mempool
 
-[cut-through]: RFC-0110_BaseNodes.md#Pruning-and-cut-through
+[cut-through]: RFC-0140_Syncing.md#Pruning-and-cut-through