This is the pseudocode specification of the Carnot consensus algorithm.
In this specification we will omit any cryptographic material, block validity and proof checks. A real implementation is expected to check those before hitting this code.
In addition, all types can be expected to have their invariants checked by the type contract, e.g. in an instance of type `Qc::Aggregate` the `high_qc` field is always the most recent qc among the aggregate qcs and the code can skip this check.
Similar to the Carnot algorithm, this specification will be event-based, prescribing the actions to perform in response to relevant events in the Carnot consensus.
Events should be processed one at a time, picking any from the available ones.
As for ordering between events, there are some constraints (e.g. can't process a proposal before it's parent) which will likely form a DAG of relations. The expectation is that an implementation will respect these requirements by processing only events which have all preconditions satisfied.
A critical piece in the protocol, these are the different kind of messages used by participants during the protocol execution.
*`Block`: propose a new block
*`Vote`: vote for a block proposal
*`Timeout`: propose to jump to a new view after a proposal for the current one was not received before a configurable timeout.
### Block
(sometimes also called proposal)
We assume an unique identifier of the block can be obtained, for example by hashing its contents. We will use the `id()` function to access the identifier of the current block.
We also assume that a unique tree order of blocks can be determined, and in particular each participant can identify the parent of each block. We will use the `parent()` function to access such parent block.
```python
@dataclass
class Block:
view: View
qc: Qc
```
##### View
A monotonically increasing number (considerations about the size?)
```python
View = int
```
##### Qc
There are currently two different types of QC:
```python
Qc = StandardQc | AggregateQc
```
###### Standard
Q: there can only be one block on which consensus in achieved for a view, so maybe the block field is redundant?
```python
class StandardQc:
view: View
block: Id
```
###### Aggregate
`high_qc` is `Qc` for the most recent view among the aggregated ones. The rest of the qcs are ignored in the rest of this algorithm.
We assume there is a `block` function available that returns the block for the Qc. In case of a standard qc, this is trivially qc.block, while for aggregate it can be obtained by accessing `high_qc`. `high_qc` is guaranteed to be a 'Standard' qc.
```python
class AggregateQc:
view: View
qcs: List[Qc]
def high_qc(self) -> Qc:
return max(self.qcs, key=lambda qc: qc.view)
```
##### Id
undef, will assume a 32-byte opaque string
```python
Id: bytes = bytearray(32)
```
### Vote
A vote for `block` in `view`
qc is the optional field containing the QC built by root nodes from 2/3 + 1 votes from their child committees and forwarded the the next view leader.
The following functions are expected to be available to participants during the execution of the protocol:
*`leader(view)`: returns the leader of the view.
*`reset_timer()`: resets timer. If the timer expires the `timeout` routine is triggered.
*`extends(block, ancestor)`: returns true if block is descendant of the ancestor in the chain.
*`download(view)`: Download missing block for the view.
getMaxViewQC(qcs): returns the qc with the highest view number.
*`member_of_leaf_committee()`: returns true if the participant executing the function is in the leaf committee of the committee overlay.
*`member_of_root_com()`: returns true if the participant executing the function is member of the root committee withing the tree overlay.
*`member_of_internal_com()`: returns truee if the participant executing the function is member of internal committees within the committee tree overlay
*`child_committee(participant)`: returns true if the participant passed as argument is member of the child committee of the participant executing the function.
*`supermajority(votes)`: the behavior changes with the position of a participant in the overlay:
* Root committee: returns if the number of distinctive signers of votes for a block in the child committee is equal to the threshold.
*`leader_supermajority(votes)`: returns if the number of distinct voters for a block is 2/3 + 1 for both children committees of root committee and overall 2/3 + 1
*`morethanSsupermajority(votes)`: returns if the number of distinctive signers of votes for a block is is more than the threshold: TODO
*`parent_committe`: return the parent committee of the participant executing the function withing the committee tree overlay. Result is undefined if called from a participant in the root committee.
<!-- #####Supermajority of child votes is 2/3 +1 votes from members of child committees
#####Supermajority for the qc to be included in the block, should have at least 2/3+1 votes from both children of the root committee and overal 2/3 +1
#####combined votes of the root committee+its child committees. -->
These are the core events necessary for the Carnot consensus protocol. In response to such events a participant is expected to execute the corresponding handler action.
* receive block b -> `receive_block(b)`
Preconditions:
*`b.parent() in SAFE_BLOCKS`
* receive a supermajority of votes for block b -> `vote(b, votes)`
Preconditions:
*`b in SAFE_BLOCKS`
*`local_timeout(b.view)` never called
* receive a vote v for block b when a supermajority of votes already exists -> `forward_votes(b, v)`
Preconditions:
*`b in SAFE_BLOCKS`
*`vote(b, some_votes)` already called and `v not in some_votes`
*`local_timeout(b.view)` never called
*`current_time() - time(last view update) > TIMEOUT` and received new overlay -> `local_timeout(last view, new_overlay)`
* leader for view v and leader supermajority for previous proposal -> `propose_block(v, votes)`
* receive a supermajority of timeouts for view v -> `timeout(v, timeouts)`