Hierarchical Consensus CryptoEcon
===
###### tags: `HC`, `B`, `B3`

_@adlrocha -- May 2022_

The aim of this document is to give a high-level overview of the requirements and different mechanisms being explored for the _bottom-up_ design of a cryptoecon model for Hierarchical Consensus (HC).

Related documents:
- [[1] HC cryptoecon Q&A](https://hackmd.io/jQ7W5SMTQs6bkyE1xt5LOQ)
- [[2] Mapping HC Cryptoecon Proposals](https://hackmd.io/QA2ueIIWRB-JBZQNyHLJKg?view)

## Revisions
- `2022-05-30`: Assumptions, requirements and model components
- `2022-05-31`: Addressed comments, remove circulating supply from components, detailed description of collateral and cross-net messages gas price modules after sync.
- `2022-06-14`: [Add agreement equivocation and invalid state transition](#C1-Collateral) as the two types of detectable misbehaviors. Included a `CEL Discussions` section that identifies outstanding discussions that may have arised from comments or previous syncs.
- `2022-06-17`: Applied outcomes of latest sync with CEL. Added a [simulation](#simulation) section.

## CEL Discussions
> List of outstanding discussions for CEL syncs
-

## Assumptions
- Subnets may not have a majority of honest participants.
- Subnets rely on their parents for the interaction with the rest of the hierarchy (e.g. message routing).
- Parents are the anchor of trust of subnets in the system so while misbehaviors in children may have a limited impact in their parent, children rely on the good behavior of their parent for their cross-net operation.
- Any user in the system should be allowed to spawn new subnets and choose their specific rules and governing policies.
- Users should be allowed to interact with any subnet in the system.
- Any subnet can propagate additional checkpoints with proofs of the state to any arbitrary network (e.g. Bitcoin).

## Requirements
This section collects a list of requirements and behaviors we want to enforce through the cryptoecon model _(in bold the ones to be considered for the MVP implementation of the protocol)_.
- __R1: Native token (i.e. rootnet token) supply consistency__: The utility token used for the operation of HC is the native token of the hierarchy's rootnet. The model should ensure the consistency of inbound/outbound token flows to and from subnets in the hierarchy (i.e. a subnet is not allowed to mint or release the rootnet's native token from thin air).
- __R2: Firewall requirement__: The model should ensure that the impact of an attack in a subnet over the native token should be limited by the circulating supply of the token on that subnet.
- __R3: Incentivize checkpoint commitment__: Checkpoints are a key mechanisms for the propagation of cross-net messages and to enforce the security in subnets our model should incentivize it.
- __R4: Incentives cross-message propagation__: Subnets are responsible for routing cross-messages. Our model should be built in a way that rewards every subnet involved in the propagation of a message without harming the UX of the system.
- _R5: Economic Security_: Detectable misbehaviors within a subnet or between different subnets should be punished. Deviating from the protocol shouldn't be economically rational. For this to be possible, misbehaviors need to be detactable. Some examples of this could be:
- Consensus-faults in subnets.
- Illegal atomic executions.
- MEV-like attacks from parents to children.
- See [[C1: Collateral]](#C1-Collateral)
- R6: Flexibility: Subnets are not only spawned to increase the capacity of the rootnet, but to easily create new networks with their own set of requirements that are able to seamlessly interoperate with the rootnet and other subnets in the system. Thus, the HC model should be light and allow for subnets to choose:
- Their gas model
- The reward mechanism.
- The requirements for childrens to spawn.
- etc.

## Model Components
### Overview
Through our discussions with CEL, we've identified a list of different components our model can be comprised of to achieve the aforementioned goals (see [[2]](https://hackmd.io/QA2ueIIWRB-JBZQNyHLJKg?view) for further details and related work):

- [C1] Collateral (R5, R6): Slashable stake provided by peers to become validators in a subnet. This collateral can be used to build mechanisms that penalize misbehaviors in subnets.
- _What is the right amount for the collateral to achieve our goals?_
- _Should the collateral be adjusted dynamically according to the operation and economic significance of the subnet?_
- _How and when is the collateral "filled-up"?_
- _Should all validators be penalized when misbehaviors are detected?_
- _Should all the collateral be burnt or a percentage?_
- _Do we have different levels of misbehaviors?_

- [Implementation detail, not a cryptoecon component we need to worry about] ~~Reserve (a.k.a circulating supply) (R3, R5): Amount of native tokens currently held by a subnet. This amount is used to enforce the firewall requirement (it may be considered an implementation detail and may not be a key element of the model)~~
- _Should there be a "delay function" for the reserve so we can open fraud windows?_

- [C2] Checkpoint gas price and finality threshold (R3, R5, R6): Committing checkpoints is an additional operation introduced by HC. This is the key mechanisms parents have to influence the economics of their children. This price can be adjusted dynamically according to the load or requirements of the parent chain.
- _What is the pricing function and parameters for the checkpoint commitment price?_
- _What is the impact of setting this price incorrectly (too high or to low) for the parent chain?_

- [C3] Cross-net routing gas price (R4, R6): Subnets in the path to the destination of a cross-net message are responsible for the propagation of the message. Cross-net message propagation and execution is an additional operation introduced by HC and that can be priced differently according to our needs. Cross-net routing gas prices should be predictable in order for users to be able to provide the message with enough gas to reach its destination (cross-net messages are funded using native token from the source subnet).
- _Should all subnets have the same cross-net message price or it can be configurable?_
- _Should cross-net messages being routed through a subnet be trated as any other plain message?_
- _What happens if a cross-net message runs out of gas half-way and it can't reach its destination?_

### [C1] Collateral
The collateral is the key component responsible for enforcing requirement `R5`. Validators in a subnet need to stake an amount of collateral to cover for potential misbehaviors and attacks in the subnet. The amount of collateral required needs to be enough to make misbehaviors economically irrational for subnet validators. Collateral has a two-fold purpose: from a technical perspective, the `CollateralThreshold` needs to be enough to cover potential equivocation misbehaviors; from a product perspective, it is a measurement of the _"skin in the game"_ of the validators, and the amount of native tokens that are at stake to cover potential losses in the face of an attack to the subnet.

Collateral works as follows:
- When a subnet is spawned, subnet founders determine the `gas_rate` they want to initially support in their subnet. This parameter determines the "load" the child subnet expects to impose in the parent, and according to it the parent sets the `collateral_threshold` for the subnet. The collateral is also a metric of the _"skin in the game"_ subnet validators have in the subnet. Subnet validators are allowed to add more collateral than the `collateral_threshold` to signal users their "trustworthiness". However, the only requirement imposed by HC for a subnet to be `Active` (i.e. with the ability to commit checkpoints and interact with the rest of the network) is for the collateral to be over the `collateral_threshold`.
- _Q: Should we also impose the minimum amount of collateral per validator?_
- Through the operation of the subnet, the `collateral_threshold` may change according to the `curr_gas_rate` reported by the subnet to the parent (through the commitment of checkpoints), and the `misbehaviors_levels`, a measure of the number of successful fault proofs for the child subnet committed in the parent, requiring validators to update their collateral accordingly.

In the following table we specify a list of detectable misbehaviors that we envisions users to be able to report through the commitment of fault proofs, along with the `impact` of the attack. This `impact` parameter is used to determine the amount from the collateral slashed due to the reported misbehavior.

| Misbehavior | Impact | Description | Fault Proof |
|--------------|-----------|------------|------------|
| (R4.1) Agreement equivocation |1| Deviation on consensus (votes on consensus, checks PoS-based, etc.) | Block checks |
| (R4.2) Invalid state transition |2| Consensus reaches valid blocks with an invalid state transition | State replay |

- __Agreement equivocation__: A malicious majority in a subnet can deviate from the consensus algorithm and propagate as valid a block that should have been considered invalid if the protocol was followed successfully. Agreement equivocations may arise, for instance, in blocks that do not pass all block checks (e.g. blocks are not mined in a different epoch, the block does not includes the right ticket, the block is not signed by the right leader, etc.); if the block doesn't include the right votes in a BFT-like consensus, etc.
To report an agreement equivocation, users need to submit to the parent's SCA the chain of blocks including the equivocated block, and the valid chain replacing the invalid block with a valid one. The SCA perfoms syntactic checks over the inputs and runs the `equivocation_check` function in the corresponding actor of the subnet actor to perform deeper consensus-specific checks. If any of these checks fail, the collateral of the subnet is slashed. The function `equivocation_check` is a mandatory function in the subent actor interface that implements all the consensus-specific checks required to detect agreement equivocations.
Thus, if an agreement equivocation is detected in epoch `n`, a user looking to report the misbehavior needs to report the chain of the latest `n-finality` including the equivocated block, and the valid chain of `n-finality` blocks to the parent SCA. For BFT-like protocols, it may suffice to report the latest block where the equivocation arises, while for sync protocols like Nakamoto consensus --without a clear metric of finality and where long-lasting forks may appear-- reporting agreement equivocations may be impossible.

> NOTE: The use of Lurk proofs as native primitives in subnets' consensus can simplify and generalize the reporting and detection of agreement equivocations (to the extent of, potentially, completely removing them)

- __Invalid state transition__: Any malicious majority of a subnet can also push invalid state transitions in a valid block. Malicious validators can include messages in a valid block that trigger unallowed state changes. Invalid state transitions are a general misbehavior that may impact HC-specific proccesses like the commitment of checkpoints, or the result of atomic executions.
In order to report an invalid state transition in a subnet, users need to submit to the parent SCA the chain of blocks from the closest valid committed checkpoint to the misbehavior, to the block where the invalid state transition happens. The parent SCA replays every state change in the reported chain and verifies that, indeed, an invalid state transition happened in the reported block. If the misbehaviors is reported successfully, the collateral for the subnet is correspondingly slashed.
Thus, if an invalid state transition happens at block `n`, and the latest committed checkpoint was at block `n-x`, a user looking to report the misbheavior needes to submit to the SCA of the parent the chain of `x` blocks from `n-x` to `n` so the state can be replayed and the invalid state transition checked.
>Note: Along with the checkpoint at `n-x` a snapshot of the state at `n-x` may also need to be provided to enable the whole state of the subnet (for every contract) to be replayed.

<!--
|__(Q: Anything else?)__||||

- We sould have a way to fallback to some other subnet if they are censoring us
- We need to embed the checkpoint in the consensus so that the checkpoint forgery falls into these two misbehaviors.
- Choose one instance, generalize the interface and show how it would work for a specific-case and the detectable misbehaviors we may have.
-->

<!--| (R4.3) Delayed/errored cross-net propagation |1.2| Cross-net message not executed or propagated correctly | Submit checkpoint commitment block and message execution |-->
<!--| (R4.3) Forged checkpoint commitment |2| Validators forge data included in checkpoint | Proof of forged data |-->

### [C2] Checkpoint gas price
> WIP
>
### [C3] Cross-net routing gas price
Cross-net messages from a source subnet, `sn_src`, to some other subnet in the hierarchy,`sn_dest`, need to be provided with enough gas for the message to be executed and routeed successfully by every subnet in the path `Path(sn_src, sn_dest)`. Cross-net messages within a subnet are treated as any other message, their execution triggers some state chain that costs certain amoun of gas in the subnet, `gas_cost_sn`. The main difference for cross-net message is that this execution and state change may translate into the propagation of the message to the next subnet in the path. However, for a user to be able to provide the message with enough gas, it needs to have a sense of the cost of execution in each subnet in the path.

To improve the UX and make as predictable as possible this gas estimation, I propose for subnet to publish basic parameters of their gas model when they are spawn:
- `gas_model_type` (if based in miner tipping, EIP1559-like, etc.)
- `curr_base_fee` (if any)
- etc.

With this information, cross-net message will include an array of `gas_limit` amount that the message wants to dedicate to each subnet in the hop. Subnets in the path won't be able to charge over the specified `gas_limit` for the subnet. When a cross-net reaches a subnet for which `gas_limit` is insufficient, it fails and an error message and the outstanding gas is propagated back to the source.

If a subnet wants to change the parameters of its gas model, it'll need to spawn a new subnet and migrate their traffic there. This prevents subnets from being able to manipulate their gas model and charge different gas costs from the ones publically advertised and harming messages (e.g. forcing gas messages to run out of gas). Ideally, these public gas model parameters used to predict the total gas of a message as a cross-net message traverse a subnet can be extracted from the general crypto-econ model CEL is working on for rootnets (and that will be extrapolated as a configurable general model for subnets).

## Simulations
At a high-level the collateral is used to cover for potential misbehaviors and sets a minimum threshold to slash in face of agreement equivocations; the checkpoint gas price signals the "willingness" of a subnet to accept new child subnets; and the cross-net routing price links the core gas model parameters of a subnet in order to provide for gas to cross-net messages.

Once the mechanics of these basic modules is designed, we will perform a set of simulation to understand their behavior under different scenarios and with different target parameters. The outcome of the simulations should give us a sense of:
- Cost of transactions (within a subnet and for cross-net transactions) according to the state of the hierarchy.
- The cost of spawning a new subnet.
- The ROI of validators and other participants in a subnets.
- The behavior of collateral and subnets in the face of an attack.
- The _"sweet-spot"_ for which the load in a network justifies the spawn of a new subnet (this could be an on-chain parameter public for all participants and computer periodically).