# Lazy Strategies ## In Proof of Work We investigate the strategy where miners mine empty blocks to reduce the uncertainty of mining a block which is invalid because it contains a transaction that is already included by another block. In this case, the miner is aware of the new block, already has its hash and/or header, but has not downloaded the rest of the block which contains the transactions. - Constant reward per mined block: $R$ - Time required to mine an empty block: $T_e$ - Time required to mine a full block: $T_f$ - Gas price: $P$ - Gas in a block: $G$ - Block gas limit: $G_\max$ - Average tx fee collected from a block: $F(G) = PG$ A lazy miner mines an empty block every $T_e$ seconds on average, and receives only $R$. An honest miner mines a full block including transactions that add up to $G_\max$ every $T_f$ seconds and receives $R+PG_\max$. The revenue per second of a lazy miner is $$ \rho_\text{lazy} = \frac{R}{T_e} $$ The revenue per second of an honest miner is $$ \rho_\text{honest} = \frac{R+PG_\max}{T_f} $$ In order for a rational miner to choose the honest strategy, $\rho_\text{honest}>\rho_\text{lazy}$ must be satisfied, giving us the following condition for the gas price $$ \boxed{ P > \frac{R}{G_\max} \left(\frac{T_f - T_e}{T_e}\right) } $$ If assume that block time is a linear function of the gas in the block, we get the following formula for block time $$ T(G) = T_e + \frac{G}{G_\max}(T_f-T_e) $$ which also gives us the following formula for the revenue per second $$ \rho(G) = \frac{R+F(G)}{T(G)} $$ For the miners to be incentivized to include as many transactions as possible, the revenue must be an increasing function of the gas amount, i.e. $d\rho/dG > 0$. Taking into account that all variables are positive, this inequality yields the same condition for gas price that we have obtained above. The linearity assumption should not be a problem as long as processing time scales linearly with gas amount, and its effect on the time required to hash the block is negligible. [Research has been done on Ethereum](https://medium.com/@ASvanevik/why-all-these-empty-ethereum-blocks-666acbbf002) that miners used the lazy strategy from time to time. There, empty blocks are mined in ~13.2s and full blocks in ~14.6s, with a difference of ~1.4s on average. From these, we can calculate the minimum gas price that should be attached to the transactions, so that miners are incentivized to include them. We substitute $T_e = 13.2\text{ s}$, $T_f = 14.6\text{ s}$, $R=3\text{ ETH}$, $G_\max=8,000,000\text{ gas}$ (these values are from the time of the article---they have been changed since then, namely 3->2 and 8m->10m), which gives us roughly $$ P > \frac{3}{8\text{e}6}\left(\frac{14.6-13.2}{13.2}\right) \approx 39.7\text{ Gwei} $$ This is close to but higher than the average gas price that we are used to in the last couple of years. In fact, gas price was in the 2-10 Gwei range at nominal demand, but historically went up to 40 Gwei and higher [when demand surged and blocks became full](https://solmaz.io/2019/10/21/gas-price-fee-volatility/). The result is unexpected: the gas price at nominal demand is not enough to incentivize a miner to mine a full block. Let's assume that the gas price stays at 4 Gwei. The difference in revenue between mining an empty block and mining a full block is `3/13.2-(3+4e-9*8e6)/14.6 ≈ 0.0196 ETH/s`. That makes a ~1700 ETH "loss" incurred per day by the totality of Ethereum miners, comparing the case where everyone mines empty blocks with the one where everyone mines full blocks. However, if everyone started mining empty blocks all of a sudden, two things would happen: - There would be no use left for ETH, causing its price to plummet. - Difficulty would be increased to accommodate the change, counteracting the surplus gained by being lazy. In order to have an edge with lazy mining, honest miners need to be present. If everyone followed the lazy strategy, there would be no advantage to being lazy compared to being honest. For these reasons, the number of miners following the lazy strategy has been limited. ## In Proof of Stake (Highway) Formulation of a lazy strategy for Highway is similar to that of Proof of Work, but also fundamentally different. In Proof of Work, the difference between durations required to mine an empty block $T_e$ and a full block $T_f$ are generally smaller than an order of magnitude. Majority of the time between blocks is devoted to hashing, so the spread could never be too high, such as 15s for a full block and 2s for an empty block. In Highway, however, it is the feature of the protocol that round lengths are adaptable. Without hashing, the duration between blocks is only devoted to 1. executing the transactions in the block, 2. propagating the block to the rest of the network, and 3. voting on and finalizing the block. (1) and (2) are directly proportional to block fullness and size, so by proposing empty blocks, validators could dramatically increase the frequency at which they propose. For example, [an empty block on Ethereum](https://etherscan.io/block/0xfb214ead6f4fac45a1736aa7876c85c39d130b0db5319d71b877fef03b05edfe) is around half a kilobyte, whereas the average block is around 25kB. If Highway had a similar distribution of block sizes, validators could collectively choose to propose an empty block every 2 seconds, as opposed to a full block e.g. every 15 seconds. Such a situation would be very destabilizing for a protocol which had constant block rewards. Thankfully, [Highway's reward distribution](https://hackmd.io/@onur/highway_reward_distribution) is designed in a way that mitigates such malicious strategies. To compare lazy and honest strategies, we introduce a similar toy model: - Constant reward per era (1 week): $R_\text{era}$ - Length of an era: $T_\text{era}$ - Time required to propagate and finalize an empty block: $T_e$ - Time required to propagate and ifnalize a full block: $T_f$ - Gas price: $P$ - Gas in a block: $G$ - Block gas limit: $G_\max$ - Average tx fee collected from a block: $F(G) = PG$ - Ratio of the weight of lazy validators to the weight of all validators: $\alpha$ - Normalized weight required to finalize a block on time (e.g. 51% of all weight): $q_{OTF}$ We consider and compare two versions of the validator set: 1. One where validators with $\alpha$ percent of the weight propose empty blocks (lazy), and the remaining $1-\alpha$ percent proposes full blocks (honest). 2. One where all validators propose full blocks (100% honest). We then compare the payouts of a group with weight $\alpha$ with that of the lazy ones from (1). Quantities subscripted with "lazy" will correspond to the group from (1) which proposes empty blocks, whereas quantities subscripted with "honest" will correspond to the group from (2) with the same weight, but proposes full blocks. Also, note that $q_{OTF}$ sets a lower limit to $\alpha$, because a block with an assigned weight smaller than that does not earn any reward. Since $q_{OTF}$ is greater than 1/2 for a nonzero fault tolerance threshold, we can also say that $$\alpha \geq q_{OTF} > 1/2$$ for a rational lazy group [^2]. We assume that validators receive rewards proportional to the number of the blocks that they propose, i.e. $$ N_\text{lazy} = \frac{\alpha T_\text{era}}{T_e} \quad\text{and}\quad N_\text{honest} = \frac{\alpha T_\text{era}}{T_f} $$ The era reward $R_\text{era}$ is shared among the two groups. We also assume that their seigniorage payout is proportional to the number of blocks that they propose[^1]: $$ R_\text{lazy} = \frac{\alpha\frac{T_\text{era}}{T_e}}{\alpha\frac{T_\text{era}}{T_e}+(1-\alpha)\frac{T_\text{era}}{T_f}} R_\text{era} = \frac{\alpha T_f}{\alpha T_f+(1-\alpha)T_e} R_\text{era} $$ whereas $$ R_\text{honest} = \frac{\alpha\frac{T_\text{era}}{T_f}}{\alpha\frac{T_\text{era}}{T_f}+(1-\alpha)\frac{T_\text{era}}{T_f}} R_\text{era} = \alpha R_\text{era} $$ Formulating payouts in such a way will give us the ability to find out for which size of a lazy group $\alpha$ are the payouts to the lazy group $R_\text{lazy}$ is maximized. We define the difference in a way that is independent of the total era reward: $$ \Delta = \frac{R_\text{lazy}-R_\text{honest}}{R_\text{era}} = \frac{\alpha T_f}{\alpha T_f+(1-\alpha)T_e} - \alpha $$ We keep in mind that $T_f > T_e$ and $\Delta > 0$ for a lazy strategy to work. Solving $\partial \Delta/\partial \alpha = 0$ for $\alpha$, we obtain weight of lazy validators which results in the maximum seigniorage payout: $$ \alpha^\ast = \frac{\sqrt{T_fT_e}-T_e}{T_f-T_e} $$ To simplify our model, we define $\beta=T_e/T_f$ and substitute it above: $$\alpha^\ast(\beta) = \frac{\sqrt{\beta}}{\sqrt{\beta}+1}$$ We then explore the values $\alpha^\ast$ takes for $0\leq \beta \leq 1$. The minimum and maximum are $\alpha^\ast(0) = 0$ and $\alpha^\ast(1) = 1/2$ respectively, and $\alpha^\ast$ increases monotonically in between. We can observe this by looking at the maxima (red dots) for different $\beta$ in the figure below: ![](https://i.imgur.com/Qne1I56.png) The result is significant: the lazy group would ideally emerge at a size which maximized their payout, i.e. $0\leq \alpha^\ast \leq 1/2$. However, we also have the restriction $\alpha \geq q_{OTF} > 1/2$ from above. Therefore, if a validator coalition with a lazy strategy were to emerge, they would want to keep their weight just above $q_{OTF}$, because a higher weight would result in diminished payout compared to being honest. For that reason, we will assume that $\alpha = q_{OTF}$ when comparing payouts including transaction fees below. ### Transaction fees: received only by the block proposer *or* assigned validators In addition to their seigniorage payout $R_\text{honest}$, the honest group would receive transaction fees. Total payout for each strategy is then $$ \begin{aligned} \pi_\text{lazy} &= R_\text{lazy} \\ \pi_\text{honest} &= R_\text{honest} + N_\text{honest}PG_\max \\ \end{aligned} $$ Although $q_{OTF} > 1/2$, we will equate it to 1/2 to simplify the equations. Then substituting $\alpha = 1/2$, we obtain $$ \begin{aligned} \pi_\text{lazy} &= R_\text{era} \frac{T_f}{T_f+T_e} \\ \pi_\text{honest} &= \frac{1}{2}\left(R_\text{era} + \frac{T_\text{era}}{T_f} P G_\max\right) \end{aligned} $$ For a rational group of validators to choose the honest strategy, $\pi_\text{honest}>\pi_\text{lazy}$ must be satisfied. This gives us a condition for price similar to the previous section: $$ \boxed{ P > \frac{R_\text{era}T_f(T_f-T_e)}{G_\max T_\text{era}(T_f+T_e)} } $$ ### Transaction fees: received by *all* validators proportional to weight Payouts are similar to the previous case, but this time collected fees $N_\text{honest}PG_\max$ are shared proportional to weight among all validators: $$ \begin{aligned} \pi_\text{lazy} &= R_\text{lazy} + \alpha N_\text{honest}PG_\max \\ \pi_\text{honest} &= R_\text{honest} + (1-\alpha)N_\text{honest}PG_\max \\ \end{aligned} $$ We substitute $\alpha = 1/2$ again: $$ \begin{aligned} \pi_\text{lazy} &= R_\text{era} \frac{T_f}{T_f+T_e} + \frac{T_\text{era}}{4T_f} P G_\max\\ \pi_\text{honest} &= \frac{R_\text{era}}{2} + \frac{T_\text{era}}{4T_f} P G_\max \end{aligned} $$ In that case, the terms with the gas price cancel out and the condition $\pi_\text{honest}>\pi_\text{lazy}$ can never be satisfied for $T_f > T_e$. [^1]: Reward distribution in Highway is actually a bit more complex: we assign reward weights to each block, which determine the amount of block reward for a given block. Since the reward weight is proportional to the weight of validators that have announced to participate on that block, lazy validators would receive less rewards than what is used in the toy model, because they would be going faster than honest validators, participating on blocks with low reward weight. [^2]: See [Highway reward distribution](https://hackmd.io/@onur/highway_reward_distribution)
Last changed by  
 
Onur
462

Read more

[ICortex](https://github.com/textcortex/icortex): Giving Programming Superpowers to Non-Programmers

Introducing ICortex, our new Jupyter kernel that allows you to generate Python code from natural language prompts: {%youtube AtVCBNq48oc %} ICortex is a drop-in replacement for the IPython kernel that powers Jupyter Notebooks. It is open source, fully extensible, and can connect to multiple code generation services, including TextCortex API, OpenAI Codex API, locally-running HuggingFace models, and so on. Whether you are ...

10/13/2022
AutoPrice

Background Control Mechanisms for Trustless Self-Governing Protocols It is a feature of public blockchains, where a protocol parameter needs to adapt to certain conditions, but should not be controlled by a specific participant. The solution is to implement a mechanism where it auto-adjusts, according to quantifiable and objective conditions. The primary example is Bitcoin’s difficulty adjustment. There, variations in average block time are used to dynamically adjust Bitcoin’s block difficulty, every 2016 blocks. Owing to difficulty adjustment, Bitcoin blocks are mined every 10 minutes on average without any external control. Shifts in block time feed back into the difficulty parameter, which then dampens said shifts, creating a negative feedback loop. Here, Bitcoin's designer made use of elementary control theory, setting mean block time as a process variable and difficulty adjustment as the control action: Gas Price Volatility Blockchains have a limited supply, and a vertical supply curve. For that reason, blockchain resources are subjected to very high price volatilities, once user demand surpasses platform capacity. Let's consider Ethereum. Demand for gas isn’t distributed equally around the globe. Ethereum users exist in every inhabited continent, with the highest demand seen in East Asia, primarily China. Europe+Africa and the Americas seem to be on par in terms of demand. This results in predictable patterns that follow the peaks and troughs of human activity in each continent. The correlation between gas usage and price is immediately noticeable, demonstrated by a 5 day period from March 2019. The grid marks the beginnings of the days in UTC, and the points in the graph correspond to hourly averages, calculated as:

6/29/2020
Compensation Fees in Transaction Fee Distribution

Users need to specify a fee when submitting their transactions. When it is a validator’s turn to propose a block, the validator collects transactions from the transaction pool, executes them in a certain order, and publishes them in a new block. Fees in a block are distributed to all validators pro rata. This is to weaken the incentive to steal transactions from other blocks, in case the block proposer receives the whole fee. The protocol has the following parameters: $P$: Average gas price of the previous era. This value is updated at the end of each era, calculated by dividing total collected fees by total consumed gas. $G$: Gas in a block. $G_{\text{max}}$: Block gas limit. $G \leq G_{\text{max}}$ for every block. $F$: Total fee collected from transactions in a block. $N$ is the current number of validators, $w_i$ is the normalized weight of validator $i$.

5/15/2020
Maximizing PoS blockchain throughput

Disclaimer: This is work in progress. Smart contract platforms like Ethereum have network parameters that dictate how often a block is to be produced, and how much computation can be performed in a block or how big a block's size can be. The selection of these parameters determine the maximum amount of computation per second that the overall network can perform. We want to maximize that number by choosing the right parameters. Protocol execution consists of cycles called rounds. Each round has a leader (validator), responsible for proposing a block at the beginning of that round. We mean by block time, denoted by $\Delta$, the length of a round. Block time is spent by first executing transactions and including them in a new block, and then by propagating that block throughout the network. Ideally, a leader should have enough time to receive and verify his predecessor's block before the previous round ends, so that he can declare it as a parent of his block when his round begins. If that is not the case, then the blockchain would fork. To prevent validators from creating arbitrarily large blocks or blocks with arbitrarily many operations, certain limits are imposed on blocks at the protocol level. These protocol parameters are: Block time: Defined above. Block size limit: Maximum size of a block in bytes.

5/5/2020
Read more from Onur
Published on HackMD