From 983f41092a57d2bd03400714a7787b6a06cd9f8a Mon Sep 17 00:00:00 2001 From: Matteo Sumberaz Date: Tue, 23 Apr 2019 14:14:54 +0200 Subject: [PATCH] Remove old and irrelevant files Signed-off-by: Matteo Sumberaz --- code-guides/particl/create_tx.md | 164 ------------- code-guides/signal_callback_system.md | 54 ----- specs/spec_v1.0.md | 322 -------------------------- 3 files changed, 540 deletions(-) delete mode 100644 code-guides/particl/create_tx.md delete mode 100644 code-guides/signal_callback_system.md delete mode 100644 specs/spec_v1.0.md diff --git a/code-guides/particl/create_tx.md b/code-guides/particl/create_tx.md deleted file mode 100644 index 209906558..000000000 --- a/code-guides/particl/create_tx.md +++ /dev/null @@ -1,164 +0,0 @@ -# Description - -This document should give an introduction and serve as a guideline in understanding the process of creating a transaction and committing it to the network. -The process is explained trying to mediate between readability, completeness and relevance that lead into omitting some minor parts. - -# Create transaction - -The following is a detailed description of the steps at the moment utilized for creating a `STANDARD` non-witness transaction. - -```c++ -CHDWallet::CreateTransaction(std::vector& vecSend, - CWalletTx& wtxNew, - CReserveKey& reservekey, - CAmount& nFeeRet, - int& nChangePosInOut, - std::string& strFailReason, - const CCoinControl& coin_control, - bool sign - ) -``` - -- `AddStandardInputs` - Add inputs and outputs - - check that there are recipients - - `InspectOutputs` - count the total output amount and check that is valid - - `ExpandTempRecipients` - populates the scriptPubkey for the vector of recipients - - `AvailableCoins` - return which coin are spendable from the wallet - - for each element in the `mapWallet`: - - `CheckFinalTx` - Check if the transaction is final in the sense of having lockTime in the past - - checks in case of a coinstake that the coinMaturity is appropriate - - for each standard output: - - check if the coin is locked or spent - - `IsMine` - check if the coin corresponding to the output is mine by looking at the key contained in the script - - `Solver` - identifies the type of the script and returns it's solution (pubkey for most cases) - - if the key corresponding to the solution is part of the wallet then return true, false otherwise - - add the output to the coins to return - - create a `CMutableTransaction` `txNew` representing the transaction to create and init it - - Until successful (while true): - - `SelectCoins` - selects coins with the required amount - - check if there are coin_control preset coins, if so add them to the result list - - `SelectCoinsMinConf` - return the best fitting coin for the given amount randomly selecting from the ones available - - if there is change set the change destination - - create a tempRecipient for the change - - `SetChangeDest` - selects the next key from the keypool - - create a tempOutput with current scriptPubkey and change - - check if the change remaining is so small that it should be added to the fees - - `InsertChangeAddress` - insert the change output along with the other recipients - - for each selected coin: - - insert a new `CTxIn` in the `txNew.vin` - - if the all the outputs are not standard then add a `CTxOutData` to `txNew.vpout` - - for each recipient: - - create and `CTxOutBase` of the right subtype with the given pubkey and amount - - `CheckOutputValue` - check if the transaction is too small - - add the output to `txNew.vpout` - - create a dummy signature of the transaction to estimate a fee value for the transaction - - create `CTransaction txNewConst(txNew)` - - `GetMinimumFee` - calculates the minimum fee given size, a feeEstimator and some constants - - if the fee is more than needed try to select new coins to get closer with less excess fee - - if the fee needed is actually more than the one given at the beginning then increase it using the change amount - - if the previous step succeed break the loop, otherwise include more fee and continue from the beginning of the loop - - if the sing input param was set then sign the transaction - - `TransactionSignatureCreator` - initialize a sig creator - - `ProduceSignature` - create a signature for the whole transaction - - `SignStep` - - `Solver` - solve the scriptPubKey if possible and return a solution for it (a pubkey usually) - - `Sign1` - use the creator to create a signature - - `TransactionSignatureCreator::CreateSig` - - get the pubkey for a given address and keystore (wallet) - - `SignatureHash` - return the sha256 of the serialized transaction - - `Sign` - sing with ECDSA and serialize the signature data - - `VerifyScript` - verify the script generated - - `EvalScript` - run the scriptpubkey script with the scriptsig generated before - - check that the stack contains TRUE at the end of the script execution - - `UpdateTransaction` - add scriptsig and scriptwitness to `newTx` - - there is a big chunk of logic run in case #ENABLE_USBDEVICE is set, here is not explained to maintain brevity and relevance - - `PreAcceptMempoolTx` - check that the transaction is not too big (bytes) and that it passes ancestors/descendents limits - - - - # Commit transaction - After creating the transaction (event though I believe that the steps above go a bit further than that), the next step is to broadcast it to the peers. - - ```c++ - bool CHDWallet::CommitTransaction(CWalletTx& wtxNew, - CReserveKey& reservekey, - CConnman* connman, - CValidationState& state - ) - ``` - - - `AddToWallet` - - create a `CWalletDB` that is nothing else but a wrapper for a DB transaction - - if is not already there insert the input transaction into `mapWallet` - - `AddToSpends` - add the input spent in this transaction to `mapTxSpent` - - for each input: - - add the `prevout` to the `mapTxSpent` - - in case an equivalent element was already there then - - SyncMetaData - copy fields from the new `prevout` to the one found - - write the transaction to DB - - break debit/credit balance caches - - send a notification about a transaction being added to the wallet - - broadcast a `MSG_HASHWTX` message - - for each input of the committed transaction present in `mapWallet`: - - `NotifyTransactionChanged` - mostly tells the transactiontablemodel to update the `prevout` transactions - - `AcceptToMemoryPool` - run the full transaction validation, for brevity this method is explained separately later - - `RelayWalletTransaction` - broadcast a `MSG_TX` to peers - -# Add to memory pool - -```c++ -bool CWalletTx::AcceptToMemoryPool(const CAmount& nAbsurdFee, CValidationState& state) -``` - -The above function is through some delegation calling the function below where most of the validation -of a transaction happens, this is the barrier for a transaction to be included in the mempool. - -```c++ -static bool AcceptToMemoryPoolWorker(const CChainParams& chainparams, - CTxMemPool& pool, - CValidationState& state, - const CTransactionRef& ptx, - bool* pfMissingInputs, - int64_t nAcceptTime, - std::list* plTxnReplaced, - bool bypass_limits, - const CAmount& nAbsurdFee, - std::vector& coins_to_uncache - ) -``` - - `CheckTransaction` - - check that the size of the transaction does not exceed `MAX_BLOCK_WEIGHT` - - for each output `tx.vpout`: - - `CheckStandardOutput` - - `CheckValue` - check that the output amount is positive and < `MAX_MONEY` - - `MoneyRange` check that the total amount of the transaction is > 0 and < `MAX_MONEY` - - check that there are no duplicated outputs - - check that the `prevouts` are not null - - `IsStandardTx` - check `tx.vout` and `tx.pvout` to infer their type (a standard script is any normally accepted pay script see txnouttype in standard.h for more details) - - `CheckFinalTx` - Check if the transaction is final in the sense of having lockTime in the past - - check that the transaction is not already in the mempool - - for each input `tx.vin`: - - check if there is any conflicting `prevout` in `pool.mapNextTx` and save a set of them - - check if there is any input we mentioned that we do not have in our local view and set `pfMissingInputs` accordingly - - `CheckSequenceLocks` - only accepts transactions that can be mined in the next block - - `Consensus::CheckTxInputs` - validates the inputs - - for each `tx.vin`: - - if is a coinbase check that is mature to be spent - - check for negative or overflow values in the `prevout` amount - - check that the fees are well formed and above the minimum expected fee for the transaction - - `AreInputsStandard` - check that the scripts inside the input are not ill formed and very expensive to compute (to avoid a DoS) - - `GetTransactionSigOpCost` - count how many operations does the `scriptPubKey` - - check that this value is not > `MAX_STANDARD_TX_SIGOPS_COST` (16000) - - create `CTxMemPoolEntry` - - check fees > `mempoolRejectFee` and > `minRelayTxFee` and not incredibly high - - `CalculateMemPoolAncestors` - check for parents and ancestors in the mempool and make sure that they are not too many or too big - - check for spending of conflicting transactions intersecting ancestors and the conflicting set from before - - handle replacements if any - the logic here is omitted for brevity cause is quite complex and handles different scenarios including transactions re-sent with different fees from the previous copy - - `CheckInputs` - check whether all inputs of this transaction are valid (no double spends, scripts & sigs, amounts) - - `CheckInputsFromMempoolAndCache` - check that no input is already spent and call `CheckInputs` again - - remove conflicting transactions from the mempool - - store transaction in memory (various caches) - - add transaction to memory address index - - add transaction to memory spent index - - `LimitMempoolSize` - remove the transaction if expired - - `AddKeyImagesToMempool` - add all the `tx.vin` pubkeys to the `mapKeyImages` of the pool diff --git a/code-guides/signal_callback_system.md b/code-guides/signal_callback_system.md deleted file mode 100644 index d9e5cbaeb..000000000 --- a/code-guides/signal_callback_system.md +++ /dev/null @@ -1,54 +0,0 @@ -# Synchronous message interface in Bitcoin client - -Bitcoin internally uses a synchronous message delivery system. It is mainly -used to decouple the wallet (wallet.a) functionalities from the validation (included in - server.a). - -The pattern used an observer pattern where a class that wants to receive a specific -message has just to extend `CValidationInterface` (in validatorinterface.h), - override the methods for which it wants to receive the messages and register - itself calling `RegisterValidationInterface()` passing the listener instance - during the application initialization. - -## Class structure - -`CValidationInterface` in validatorinterface.h: -this class expose an extendable interface for callbacks. - -`MainSignalsInstance` in validatorinterface.h: -this struct contains a list of the existing callbacks that are each bound to a -`boost::signals2::signal`[1]. This the way how calls from `CMainSignals` are connected -to the equivalent in `CValidationInterface`. -It also contains an instance of `SingleThreadedSchedulerClient` as messaging queue. - -`CMainSignals` in validatorinterface.h: -this class takes care of registering the callback functions. - -The call flow unfolds like this: - -1. a call to `CMainSignals::SomeFunction()` is made, this function is the sender -entry point. - -2. the previous function just delegates the call to `m_internals->CMainSignals::SomeFunction()`, -where `m_internals` is a pointer to the instance of `MainSignalsInstance`. - -3. The call is now redirected to the right `CValidationInterface` method that has -been defined in the mapping created in `RegisterValidationInterface()`. - -4. The final recipient method in each class implementing `CValidationInterface` and -overriding it, it is then executed. - -## ZMQ support -Since there was a lack of an easy way to notify external entities of events happening -inside the node, bitcoin added support for ZMQ[2]. ZMQ[3] is used as one-direction -queuing system to broadcast notifications to listeners. - -This support is brought through the registration of `CZMQNotificationInterface`, -using `CZMQNotificationInterface::Create()` during the startup of the node using -again `RegisterValidationInterface()`. - - -## References -[1] Boost documentation, URL https://www.boost.org/doc/libs/1_47_0/doc/html/boost/signals2/signal.html. -[2] ZMQ usage in bitcoin, https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md. -[3] ZMQ website, URL http://zeromq.org/. diff --git a/specs/spec_v1.0.md b/specs/spec_v1.0.md deleted file mode 100644 index e0f2ce3aa..000000000 --- a/specs/spec_v1.0.md +++ /dev/null @@ -1,322 +0,0 @@ -# **Summary** -The goal of this document is to explain with a reasonable level of detail the specification for Unit-e v1.0 . - -# **Block proposal** -The block proposal is the process to create the next block of the blockchain and it is constituted of three parts: **management of valid proposers**, **selection of block proposer**, and **block proposal** itself. - -## Proposer permissioning -As a safeguard, we will initially use permissioning to whitelist eligible proposers. This will gradually be relaxed. For initial development, we will have a hardcoded list in the codebase of public keys for eligible proposers. The PKI will be managed by administrative transactions. - -## Proposer selection -We will use a distributed mechanism for choosing proposer, where every proposer node (that owns one of the public key registered in the proposer whitelist) will hash key, next block height, and previous block hash. The node is elected for the current round if the hash result is below a certain threshold (defined so that every whitelisted proposer has the same chance to be elected). - -Following some pseudo-code that illustrates the election algorithm. -```python -blockHeight = curBlockHeight # round counter -difficulty = 1/numValidators # probability of a node being elected leader (chosen to avoid collisions as much as possible) - -while (true) { - nNow = GetTime() # current time - nextRoundTime = nNow + BLOCK_TIME # time of next round - myRandNum = Hash(myKey, block_height, prev_block_hash) - normRandNum = myRandNum / MAX_HASH # define MAX_HASH so that 0 <= normRandNum <= 1 - if (normRandNum < difficulty) { - # propose a block (details in next subsection) - ... - } - - # wait until the next round starts - nNow = GetTime() - wait(nextRoundTime - nNow) - blockHeight += 1 -} -``` -MAX_HASH should change over time to account for a change in number of active proposer. - -## Block proposal -The elected proposer now has the duty to: - -* build a new block including transactions from his mempool -* create a new coinbase transaction (still to define how this is used) -* broadcast the new block to the peers - -Is not yet defined exactly how rewards to validators and proposers are composed or what is their magnitude, if relative to the total stake at a given time or relative to the staked amount. Such details need to be defined, if not immediately, at least before release. - -To prove that a proposer has been rightfully elected any node can simply recompute the hash explained above and check it against the difficulty parameter of the previous block. - -```python -# activeChains = data structure with existing, unfinalized chains - -chosenChain = null -# proposer builds on the longest justified chain -for (chain in activeChains): - if (isJustified(chain.lastCheckpoint)) and (length(chain) > length(chosenChain)): - chosenChain = chain -} -myBlock = BuildBlock(chosenChain, transactions) -chosenChain.append(myBlock) -broadcast(myBlock) -``` - -# **Block finalization** -Blocks are not finalized in Particl or Bitcoin, so this portion of the algorithm will require the most changes. To support this we need few basic functionalities or primitives: (1) deposit, (2) voting, (3) slashing, (4) logout, (5) withdraw. Our design choices are modeled heavily on Casper implementation. - -At the moment we don't foresee any changes to the block header or internal structure. - -This implementation relies heavily on statefulness of the consensus. This means that all the nodes in order to be able to accept blocks and transactions need to have an up-to-date view of the whole consensus state. The state structure is drafted with big contributions from the Casper contract code base with some simplifications. - -```bash -class Validator { - deposit: decimal, # current validator deposit - start_dynasty: int, # index of the dynasty since the validator is included - end_dynasty: int, # index of the dynasty till the validator is included - is_slashed: boolean, # if the validator has been slashed - total_deposits_at_logout: int, # the value of the - addr: address # validator address -} -``` - -```bash -class Checkpoint{ - cur_deposits: int, # total deposit for this checkpoint - cur_votes: int, # total deposit that has voted for this checkpoint - votes_map: map, # map of which validator IDs have already voted - is_justified: bool, # is the checkpoint justified - is_finalized: bool # is the checkpoint finalized -} -``` -a possible casper state implementation inside Particl - -```bash -validators[] # list of the current validators -checkpoint_hashes # map -validator_addr # map -total_cur_dyn_deposit # total deposit for the current dynasty -dynasty # the index of the current dynasty -dystay_in_epoch # map -``` - -## 1. Deposit transactions - -Casper validators deposit funds into a smart contract. Since we do not directly support smart contracts, we will instead implement a new "deposit" transaction type that locks the funds for a certain amount of `dynasties` and proves that the node is participating in the voting process. There is no other way to spend this transaction than using a logout transaction or a vote transaction. - -### 1.1 Deposit transaction data - -* `version` - is used to distinguish this transaction as a separate type. Its value is 3 for this transaction type. -* `Input(s)` - as any normal transaction, no special rules or limitations here. -* `Output` - the transaction has one single output and the `ScriptPubKey` must contain a specific script. The minimum value must be `MIN_DEPOSIT_SIZE`. Fees are allowed as usual. It makes sense to pay the transaction to an address under the depositor control. - * `ScriptPubKey` this field has to contain a special script that allows slashing (see 1.2). The content of the script must be validated at least by the `proposers`. -* `Locktime` - is not used. - - -#### 1.2 Deposit script -In order to provide vote and slash functionalities on top of a deposit transaction we need to extend the current script language with new op_codes. - -Let's define `VTXn` is the tuple `` so that -``` -t is the TXID of any descendant of 's' ("target") -h(s) the block height of s -h(t) the block height of t -``` -and `SIGn` is the signature from the validator private key of `VTXn`. - -`OP_CHECKVOTESIG`: -- consumes the first 3 elements of the stack as -- pushes back the result of PUBKEY_DECRYPT(SIG) == HASH256(VTX) - -`OP_SLASHABLE`: -- consumes the first 5 elements of the stack as -- executes OP_CHECKSIG(SIG1,VTX1,PUBKEY) -- executes OP_CHECKSIG(SIG2,VTX2,PUBKEY) -- executes SIG1 == SIG2 -- checks -```python -height(VTX1) == height(VTX2) or -(target(VTX1) > target(VTX2) and source(VTX1) < source(VTX2) or target(VTX2) > target(VTX1) and source(VTX2) > source(VTX1)) -``` -- pushes back `TRUE` if all the previous checks succeeded, `FALSE` otherwise. - -``` -# Vote verification script -OP_OVER -OP_OVER -OP_PUSHDATA1 PUBKEY -OP_CHECKVOTESIG - -OP_IF -OP_TRUE - -OP_ELSE -# Common P2PKH -OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG - -OP_ELSE -# The script that allows this tx to be spent by a violation reporter -OP_PUSHDATA1 PUBKEY -OP_SLASHABLE -OP_ENDIF -``` -using this script in the deposit for someone to slash the deposit is sufficient to provide a `scriptSig` like -``` - -``` -for vote and logout operations is simply -``` - -``` -for withdrawing instead a normal P2PKH is sufficient -``` - -``` - -## 1.3 Validating a deposit transaction -When receiving a deposit transaction a node should in addition to the regular transaction checks do the following: - -* check if the address from where the deposit is sent is already a validator. -* check that the deposit output value is >= MIN_DEPOSIT_SIZE. -* save a new validator object to store the state information of this new validator. - -``` -{ - "deposit" : output_value, - "start_dynasty": cur_dynasty + 3, - "end_dynasty": infinity, - "is_slashed": false, - "total_deposit_at_logout": 0, - "address": addr -} -``` -* save the validator withdrawal address for future reference. -* update the current dynasty total deposit. - -The `"start_dynasty": cur_dynasty + 3` should give enough time to the deposit to be included in a block and broadcasted to all the nodes. -See more details in [dtr-org/unit-e#743](https://github.com/dtr-org/unit-e/pull/743) - -## 2. Vote transactions - -Votes will be casted with a new type of transaction. All votes should be added to the blockchain, regardless of which fork they support. -We have not yet considered how to incentivize proposers to include votes in their blocks; most likely, we will have to set apart separate space in each block for votes (as opposed to regular transactions). -For now, we are assuming that the (permissioned) proposers will behave properly and include votes in blocks. - -A validator is supposed to vote once per epoch; if this does not happen then it will be charged of s penalty for being offline. -The accumulated `offline penalty` over time will be applied when a node tries to rightfully spend its deposit after logout. -At withdrawal a validator will be able only to retrieve the portion of the deposit remaining after the total `offline penalties` are applied. - -Votes can either spend a deposit transaction, another vote transaction, a logout transaction or a withdraw; for the vote transaction to be valid it is necessary for the only output to have the same `ScriptPubKey` of the spent transaction and a value equal to the spent transaction plus the reward for the vote performed. -In this way we will create a chain of transactions with at the beginning a deposit transaction and at the end a withdraw or a slash transaction. -Such chain will allow to compound deposit and rewards at each round till a slash or a withdraw happens. - -### 2.1 Vote transactions data -Vote transactions are a special type of transaction. - -* `version` - is used to distinguish this transaction as a separate type. Its value is 4 for this transaction type. -* `Input(s)` - the transaction is going to have only one input. - * `TXID` - is the reference to the previous deposit, vote or logout transaction. - * `VOUT` - this should be 0, since logout, deposit and vote transactions have only one output. - * `ScriptSig` - this field contains the data `` serialized in this order as consecutive bytes. -* `Output` - the transaction has a single output and the `ScriptPubKey` must contain a specific script. The value has to be the same as the deposit plus the calculated reward. Fees are not allowed. - * `ScriptPubKey` this field has to contain a special script that allows slashing (see 1.2). The content of the script must be validated at least by the `proposers`. -* `Locktime` - is not used. - -Furthermore a vote transaction can be spent only by a logout transaction, another vote transaction, a slash transaction or a withdraw transaction. - -### 2.2 Validating a vote transaction - -In order to validate a vote transaction a node should: - -* check if the validator already voted for this target epoch. -* check that the target epoch and the target hash are the ones expected. -* check that the source epoch is justified. -* check that the validator is part of validator set of the current or previous dynasty (if not logged out and has an active deposit). -* record the vote. -* increment the `total_cur_dyn_deposit`. -* if enough votes are registered justify the checkpoint and finalize the previous one. - -For each valid vote a validator should receive a reward, this is compounded along with the deposit and is part of the stake of the validator. At withdrawal the validator will be able to claim the deposit and all the vote rewards. - -## 3. Slashing transaction - -In Casper, it is up to the block proposers to include slashing transactions that punish bad actors, and the first node that reports the bad behaviour gets the bounty. We will again implement a special transaction that provides evidence of the slashing conditions being violated (see deposit transactions). - -## 3.1 Slashing transaction data - -This transaction simply needs to provide the correct inputs to the validator’s deposit transaction, and the outputs are as normal. We are calling this a separate transaction type mainly for readability and ease of parsing in the blockchain; its functionality is not different from standard transactions. - -* `version` - is used to distinguish this transaction as a separate type. Its value is 5 for this transaction type. -* `Input(s)` - the transaction is going to have only one input and this will be a deposit, vote or logout transaction. - * `TXID` - is the reference to a deposit, vote or logout transaction which output is unspent. - * `VOUT` - this should be 0. - * `ScriptSig` - this should include the proof of the offending votes (see 1.2). -* `Output` - as a normal transaction the outputs can be multiple but the first output must "burn" using an `OP_RETURN` in the pubkey at least `SLASHING_BURN_FRACTION` of the deposit. -* `Locktime` - is not used. - -### 3.2 Validating a slashing transaction - -* execute the script as usual to verify that the deposit is unlocked. -* mark the validator as slashed and log it out forcefully. - -## 4. Logout transaction -In order to get back the deposit a validator has to send a logout transaction. -The block in which this transaction is included is used to set the `end_dynasty` for the validator using `cur_dinasty + LOGOUT_DELAY`. - -## 4.1 Logout transaction data -This transaction is basically the same as a deposit transaction with the exception that only a deposit or a vote transaction can be the input. - -* `version` - is used to distinguish this transaction as a separate type. Its value is 6 for this transaction type. -* `Input(s)` - the deposit or vote transaction. -* `Output` - the transaction has one single output and the `ScriptPubKey` must contain a specific script. The value has to be the same as the deposit or vote used. Fees are allowed as usual. It makes sense to pay the transaction to an address under the depositor control. - * `ScriptPubKey` this field has to contain a special script that allows slashing (see 1.2). The content of the script must be validated at least by the `proposers`. -* `Locktime` - is not used. - -## 5. Withdrawing transaction -This transaction is a special transaction that spends the logout transaction. The only difference is that in order to be valid it has to happen after `WITHDRAWAL_DELAY` and its value has to be equal to the `deposit - non_voter_penalties + vote_rewards`. - -## 5.1 Withdrawing transaction data -This transaction is basically a normal transaction except the fact that has to have a logout transaction as input and that the total amount payed in the output can be different from the original deposit because of penalties and rewards. - -* `version` - is used to distinguish this transaction as a separate type. Its value is 7 for this transaction type. -* `Input(s)` - the logout transaction. -* `Output` - as a normal transaction the outputs can be multiple. -* `Locktime` - is not used. - - -# Parameters values - -* `BLOCK_TIME`: 4 seconds - -* `MIN_DEPOSIT_SIZE`: TBD - -* `NON_REVERT_MIN_DEPOSIT`: TBD - -* `LOGOUT_DELAY`: TBD - -* `WITHDRAWAL_DELAY`: TBD - -* `SLASHING_BURN_FRACTION`: 0.96 - - -# **Glossary** - -* **epoch:** The span of blocks between checkpoints. Epochs are numbered starting at the hybrid casper fork, incrementing by one at the start of each epoch. - -* **finality:** The point at which a block has been decided upon by a client to never revert. Proof of Work does not have the concept of finality, only of further deep block confirmations. - -* **checkpoint:** The block/hash under consideration for finality for a given epoch. This block is the last block of the previous epoch. When a checkpoint is explicitly finalized, all ancestor blocks of the checkpoint are implicitly finalized. - -* **validator:** A participant in the consensus protocol that has deposited *ees* on the blockchain and has the responsibility to vote and finalize checkpoints. - -* **validator set:** The set of validators for a given dynasty. - -* **block proposer:** A node whose role is to participate in the proposer's election. When elected for the current round it proceeds to create a new block and broadcast it to the other nodes. This function is very similar to the one miners are fulfilling in a PoW protocol. - -* **block proposer set:** The set of proposers allowed to be elected for a proposing round. - -* **proposing round:** A time slot in which one block proposer is elected to propose the next block. - -* **block proposer whitelist:** A predefined list public key of allowed block proposers. - -* **dynasty:** The number of finalized checkpoints in the chain from root to the parent of a block. The dynasty is used to define when a validator starts and ends validating. The current dynasty only increments when a checkpoint is finalized as opposed to epoch numbers that increment regardless of finality. - -* **slash:** The burning of some amount of a validator's deposit along with an immediate logout from the validator set. Slashing occurs when a validator signs two conflicting vote messages that violate a slashing condition. - -* **offline penalty:** In the case that a validator doesn't vote during an epoch then it should be punished removing a penalty from its deposit.