# HC notes ## Hierarchical consensus growth Hierarchical consensus (HC) represents a tree of subnets whose structure can change in time. Since it's difficult to reason about economics even on a single network, it's worth trying to understand what the HC network can look like under plausible growth assumptions. To do this, we can note the similarities between the patterns of branching we expect in HC, and structures that arise in fields, such as taxonomy, nuclear fission, and society formation, amongst others. In these fields the mathematics is fairly established. So to describe the dynamics of the HC structure we can use related ideas and some tools from probability theory. This serves both as an exercise to formalize our understanding of HC, and further down the line to model and simulate it. ### Basic Model Let $\mathcal{I}^{*}$ denote the set of progeny, and $\mathcal{I}$ be the set of all networks including the root. The root is endowed with a set of elements \begin{align*} \{\chi^{\tau}(\cdot),\,N^{\tau}(\cdot)\}_{\tau\ge0}\,. \end{align*} Here * $\chi^{\tau}(\cdot)\in\{0,1\}$ is a random characteristic describing its operational status: whether a subnet is functioning or not. * $N(\cdot)\in\mathbb{\mathbb{N}}$ is a counting process, which keeps track of subnets spawned by the root. * $\tau$ denotes time of inception. * Additional elements may be added to this set as it becomes clear what HC means. The HC mechanism, as I understand it, is universal. Since it's the same at each node in the hierarchy, it seems plausible to appeal to a form of Bellman's *first generation principle*. In this context, the principle means that for subnet $i\in\mathcal{I^{*}}$, the set $\{\chi_{i},\,N_{i}(\cdot)\}_{\tau\ge0}$ is an identically distributed copy of $\{\chi,\,N(\cdot)\}_{\tau\ge0}$. Identically distributed because there there's a single protocol, but not independent. A conditional dependence in time arises via the causal relationship the ancestor network existing and its first generation progeny subnets existing and being operational. Now our goal is to provide a formalism that describes the state of the complete HC structure. To this end, we can first start by considering the operational state of subnets under the approximation they're born but do not die \begin{align*} \chi^{\tau}(u):=\begin{cases} 0 & u<0\\ 1 & u>0 \end{cases}\,. \end{align*} We can relax the condition of immortality later. This will make the dynamics substantially more complicated. Now, with operational state as defined, the evolution of the HC network can be characterised as \begin{align*} Z(t,\tau):=\underset{\text{root}}{\underbrace{\chi^{\tau}(t-\tau)}}+\underset{\text{subnets}}{\underbrace{\sum_{i\in\mathcal{I^{*}}}\chi_{_{i}}^{\tau_{i}}(t-\tau_{i})}}\,, \end{align*} Across subnets operational state must respect the causal order that only parents can spawn children. Let the operator $\mathcal{T}$ order $\tau_{i_{k}}$, so that for subnet $i$ spawning at time $\tau$ we have the stratification \begin{align*} \sum_{i\in\mathcal{I^{*}}}\chi_{_{i}}^{\tau_{i}}(t-\tau_{i})=\sum_{k:\mathcal{T}(\tau_{i_{k}})<t}\underset{:=Z_{k}(t)}{\underbrace{\sum_{i\in\mathcal{I}_{k}}\chi_{_{i}}^{\tau_{i}}(t-\tau_{i})}}\,. \end{align*} Conditional on ordering each $Z_{k}(t)$ is independent. It follows using the tower property of conditional expectation that the expected value of operational state for the network at a given time is \begin{align*} \mathbb{E}\left[Z(t,\tau)\right] & =\mathbb{E}\left[\underset{\text{root}}{\underbrace{\chi^{\tau}(t-\tau)}}\right]+\mathbb{E}\left[\sum_{k:\mathcal{T}(\tau_{i_{k}})<t}\underset{\text{subnets}}{\underbrace{Z_{k}(t)}}\right]\,.\\ & =\mathbb{E}\left[\underset{\text{root}}{\underbrace{\chi^{\tau}(t-\tau)}}\right]+\mathbb{E}\left[\sum_{k:\mathcal{T}(\tau_{i_{k}})<t}\underset{\text{subnets}}{\underbrace{\mathbb{E}\left[Z(t,\tau_{i_{k}})\right]}}\right] \end{align*} which leads to the following integral equation for the expected cumulative number of operating subnets \begin{align*} n(t,\tau)=1+\int_{(0,t-\tau]}n(t,u+\tau)d\Lambda^{\tau}(u)\,. \end{align*} Here $d\Lambda^{\tau}=\mathbb{E}\left[\Delta N^{\tau}(\cdot)\right]$ is a measure of time between birth and spawning a new generation. In reality this is a function of demand for consensus. In short, the fundamental relation for growth of operating subnets is simply \begin{align*} n=1+n*\Lambda\,. \end{align*} **Interpretation** * What does this mean? To start, there's a single network operating, Filecoin. As the HC protocol spawns new nodes, the population of subnets across the structure should grow according to the above recursion relation. * Why's this useful to know? It's a general and high-level perspective, but formalises notions of growth in HC. It also gives an equation to simulate the HC network. * What are the limitations? For a start we assumed immortal subnets, and that subnets are alike. All models wrong, some are useful. * Qs: What do we gain from a complicated hierarchical structure? Why shouldn't the structure just be one level deep? HC risks a cascade of failure --- death of a subnet kills all descendents. ### Model with subnet death If subnets can die, we consider a random operating characteristic of the form \begin{align*} \chi^{\tau}(u):=\begin{cases} 0 & u<0\\ 1 & u\in[0,L^{\tau}]\\ 0 & u>L^{\tau} \end{cases} \end{align*} where a node is active for random length of time $L^{\tau}$. Subnet death raises an interesting question. As well time-ordering so that children must be younger than parents, it implies a further causal structure that has to be accounted for. If a parent subnet fails, then I think it's correct to say that all progeny also must die. *tbc* ### Other observables * Can we say anything about the dynamics beyond subnet operational status. Total network value could be an easy one along similar lines. Systemic risk of failure and how thing scales depending on depth vs width growth seems important. * Ideally, understanding HC takes a multiscale perspective. We *do* have a top level model now, but what about the finer scale processes. E.g. a typical approach for block demand is to model it using a Poisson arrival process. How does this gel with the full HC level process. * Maybe now the lowest hanging fruit is look at arrival processes and try to think how these would differ within subnet vs across subnets. *tbc* ## Gas At the top level the gas model should attempts to satisfy three economic goals: 1. Incentivize message validation in the very low congestion regime. 2. Align supply of message validation with demand as congestion increases on a subnet. 3. Ensure net cash flow towards HC root. <!-- ## Gas mechanism #1 <!-- ### Model specification In the gas model set out, the protocol variables are * $f_{ijt}$ [FIL], the fee, denominated in units of FIL, for passing a given message from sender $i$ to receiver $j$ at epoch $t$. * $b_{t}$ [FIL/bytes] is the burn rate. This has a minimum value of $b^{*}$. * $g_{t}$ [bytes] is gas used. * $m$ [FIL] is the minimum miner reward.<!-- * $\mu$ [FIL] is an optional miner tip. --> * $g^{*}\in\mathbb{R}_{+}$ [bytes] is a gas target parameter. * $r_{t}$ is the gas usage to target gas usage ratio, $r_{t}=g_{t}/g^{*}$. * $k\in\mathbb{R}^{+}$ is the attack parameter that defines how reponsive the burn fee is to exceeding the gas usage target ratio. The proposed message fee has three elements. A whole network reward that depends on the amount of gas used, a tip to reward miners individually, and an option to chose the gas mechanism for within subnet messages. --> <!-- \begin{align*} f(g,\,m,\,\cdot) :=\underset{\text{network reward}}{\underbrace{f(g)}}+\underset{\text{miner reward}}{\underbrace{f(m)}}+\underset{\text{subnet defined}}{\underbrace{f(\cdot)}}\,. \end{align*} --> <!-- To price selectively, rather than imposing a single group level mechanism, we distinguish messages by their sender location $i$ and receiver location $j$ on the HC architecture. 1. $\mathcal{A}$: the sender and receiver have a parent child relationship. 3. $\mathcal{B}$: the sender-receiver pair are in the same subnet. 4. $\mathcal{C}$: none of the above, which requires a path composed of parent-child pairs. <!-- The first part rewards the whole network for supporting messaging costs, and depends on gas usage of the message. The second part acts as a tip to reward miners individually. The third component is an optional subnet defined fee that can be set for within subnet messaging. --> For a given message, the cost for transmitting it between sender $i$ and reciever $j$ at time $t$ is given by \begin{align*} f_{ijt}(g,\,m,\,\cdot):=\begin{cases} \underset{\text{network reward}}{\underbrace{b_{t}g_{t}}}+\underset{\text{miner reward}}{\underbrace{m}} & ij\in\mathcal{A}\\ \underset{\text{subnet defined}}{\underbrace{f(\cdot)}} & ij\in\mathcal{B}\\ \sum_{k:{i_k}{j_k}\in\mathcal{A}} f_{{i_k}{j_k}t} & ij\in\mathcal{C} \end{cases}\,. \end{align*} The key features are * between parent and child messages ($\mathcal{A}$), pay a variable gas burn fee $b_{t}g_{t}$ to reward the network, and fixed reward $m$ to incentivize miners. * the gas costs and mechanism for within subnet transactions ($\mathcal{B}$) are decided by the subnet. For example, the subnet may opt but isn't mandated to use the parent-child gas mechanism. * messages in $\mathcal{C}$ occur by traversing a path along parent-child pairs via a common ancestor. * the miner reward $m$ is universal across HC levels and fixed in time. There are arguments both for and against relaxing these conditions. To be discussed below. The burn rate has a minimum value $b^*$. The burn rate can be chosen by the subnet to be static or dynamic. If dynamic, it changes according to the update rule --> <!-- \begin{align*} b_{t+1} :=\text{max}\left(b^{*},\,b_{t}\left(1+k\left(r_{t}-r_{t-1}\right)\right)\right)\,. \end{align*} This update rule is different from 1559. If the subnet has low congestion, we expect the burn fee will default to the minimum $b^{*}$. This can also happen if the parent doesn't support variable block size and sets $k=0$. If the reciever does support variable block size, and has chooses $k>0$, the dynamic burn mechanism brings the advantage of regulating short-term volatility (as opposed to long-term demand where spawning a new new may be preferable). ### Points to discuss **Gas payment denomination** * All parent-child message fees are denominated in FIL. * Within-net, there are no constraints on gas mechanism or transaction fee denomination. --> <!-- **Minimum burn rate** $b^{*}$ * This places a minimum FIL value on the consensus from the parent, even if usage is low. * Ensure a minimum value transfer to Filecoin. * Helps prevent bidding up fees for MEV. Burned fees are less exploitable. * Dynamic burn fee in the $k\to0$ static limit defaults to the $b^*$ minimum. Subnets can make this choice. * Difficult to place figure on what the burn rate should be. **Option to choose a dynamic burn rate** * Supports variable block size. * Useful to regulate short-term usage volatility. Congestion isn't likely to be critical in HC. But there could be short spikes in demand for blocksize, so a first line of defense if subnet does get congested before spawning is useful. * The rate of the attack on the base-fee burn can be set by users. * Note the dynamic burn rate presented here is not 1559. 1559 penalises users tomorrow for volatility today. This burn rate should have no lag. --> <!-- **Fixed miner reward** $m$ * Ensure a minimum level of explicit miner incentive. * On parent child messages, there's no optional extra miner tip. This reduces MEV possibility, but has obvious downsides too. We should decide how much this is valued, compared to being able to prioritize a message using a variable tip. * Risks pricing misalignment. **Free choice on gas mechanism within subnet** * Subnet operators can chose to operate using the default gas protocol, or operate by their own mechanism. * Reason: flexibility, subject to economics goals, is good. For example, subnets with transaction fees in their own token, or by their own burning rules or auction style, contribute valuable diversity. --> <!-- ## Gas mechanism #2 Aggregate message fees in a block $F_t$ [FIL] are priced based on excess demand over block size as \begin{align*} F_{t}=\alpha_{0}+\alpha_{1}\,\text{arctanh}(\rho_{t}/\alpha_{1})\,. \end{align*} where $\alpha_{0}>0$ and $\alpha_{1}>0$ are protocol parameters that define the minimum fee and how quickly fees escalate with demand, and $\rho_{t}=\frac{D_{t}}{B}$, which is the ratio of demand for block space $D_{t}$ [bytes] to blocksize $B$ [bytes]. For $\alpha_{0}=1$ and $\alpha_{1}=2$ this looks like ![](https://i.imgur.com/ZIT7k3A.png) The particular choice of $F_t$ should be discussed. Perhaps exp is better. The key point is it starts from a non-zero value and increases monotically. The fee payable for an inidividual message is the marginal contribution based on the ratio of gas used to blocksize: \begin{align*} f_{t}(g_t)=\frac{g_{t}}{B}F_{t} \end{align*} Depending on the relative sender and receiver location on the HC network, the fee is different: \begin{align*} f_{ijt}(g,\,\cdot):=\begin{cases} \underset{\text{network reward}}{\underbrace{\alpha_{2}f_{t}(g)}}+\underset{\text{miner reward}}{\underbrace{\left(1-\alpha_{2}\right)f_{t}(g)}} & ij\in\mathcal{A}\\ \underset{\text{subnet defined}}{\underbrace{f(\cdot)}} & ij\in\mathcal{B}\\ \sum_{k:i_{k}j_{k}\in\mathcal{A}}f_{i_{k}j_{k}t} & ij\in\mathcal{C}\\ \\ \end{cases}\,. \end{align*} For parent-child messages ($\mathcal{A}$), a fraction $\alpha_{2}$ (protocol parameter) is burned and a fraction $1-\alpha_{2}$ rewarded to miners. For subnet messages, $\mathcal{B}$, the fees and mechanism are subnet defined. For non-parent-child messages, $\mathcal{C}$, fees are made up from a path of parent child fees. --> <!-- ### Advantages and disadvantages * Minimum fees ensures no supply without demand * Fees increasely linearly and slowly to start. * If demand for block space approaches twice the block size, fee quickly start to ramp up. This will trigger lower demand in the short-term or subnet spawning long-term * All fees are mechanistic and based on useage only. No miner tip. No inefficient first price auction. Less MEV exploit. But also no way to prioritise a message if there is temporary congestion. --> -->