Add fees with fee burning

rationale/fees.md

@@ -0,0 +1,40 @@
+Fees
+===
+
+- [Preamble](#preamble)
+- [Background: EIP-1559](#background-eip-1559)
+- [Fee Burning](#fee-burning)
+
+## Preamble
+
+Two desiderata are elastic block size limits—which can smooth out transaction fees and prevent fee spikes—and variable burning of fees—which can respond to market forces and provides intrinsic demand for the burned coin that cannot be replicated by issuance of new supply. Interestingly, these two properties cannot be accomplished independently. Without a negative feedback mechanism that cannot be bypassed, block producers will always produce maximum-size blocks. This negative feedback mechanism is in-protocol variable fee burning. In a similar vein, variable (rather than fixed) fee burning requires a measure of block usage, which happens to exactly be an elastic block size limit.
+
+This document describes the rationale and structure of an elastic block size limit through variable in-protocol fee burning.
+
+## Background: EIP-1559
+
+[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) introduces a concrete proposal for in-protocol variable fee burning for Ethereum, with only a superficial analysis of properties. [This paper](http://timroughgarden.org/papers/eip1559.pdf) provides a rigorous formal analysis of the same.
+
+The essence of EIP-1559 is that, rather than the [first-price auction fee rate](https://arxiv.org/abs/1901.06830) of traditional cryptocurrencies, transactions under EIP-1559 define two fee rate parameters: a maximum base fee rate and a tip rate. The base fee is burned as a mechanism for enabling an elastic block size, and the tip is given to the miner of the block that includes the transaction (and is itself subject to a first-price auction). All transactions in a block burn the same base fee.
+
+The base fee grows if the previous block was more than half-full, and shrinks if the previous block was less than half full, by a parameter. We note, as above, that fee burning is simply a mechanism for making an elastic block size limit viable. This parameter should be chosen with the following in mind:
+1. The target (or, expected) block size should be bounded by the cost to run a full node assuming all blocks are at the target block size (also known as "decentralization").
+1. The maximum block size should bounded by the size of a "poison" block, i.e. one that would disrupt the consensus protocol.
+
+From this, we see that there is nothing inherent in half-fullness, and indeed this parameter should be chosen more carefully through empirical results.
+
+## Fee Burning
+
+The scheme described here is fundamentally identical to EIP-1559, save for the choice of parameters:
+1. Target block size: since blocks grow in size by a power of 4 due to the arrangement of data in a square, a reasonable initial choice would be 1:4 target:maximum block size limits.
+1. Rate of change: there is nothing inherently wrong (or especially right) with the $\frac{1}{8}$ rate of change prescribed by EIP-1559, so this parameter remains unchanged.
+
+We can now define the base fee as
+
+$$
+b_{cur} = b_{prev} \cdot \left( 1 + R \cdot \frac{s_{prev} - S_{target}}{S_{target}} \right)
+$$
+
+, where $b_{cur}$ is the base fee of the current block, $b_{prev}$ is the base fee of the previous block, $R$ is the rate of change in base fee, $s_{prev}$ is the size of the previous block, and $S_{target}$ is the target block size. In other words, the base fee is only dependent on the current and previous blocks.
+
+With $R = \frac{1}{8}$ (the rate defined by EIP-1559 and used here), the base fee can reduce by up to $12.5\%$ if the current block is completely empty and increase by up to $37.5\%$ if the current block is full.

specs/architecture.md

@@ -9,16 +9,16 @@ Architecture
 | name              | description                                                                                                                                                                      |
 | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | App (application) | Alternate name for "[virtual sidechain](https://arxiv.org/abs/1905.09274)." LazyLedger apps are sidechains that post all their data onto the LazyLedger chain to share security. |
-| Transaction       | Requests that modify the consensus-critical state (validator balances and statuses).                                                                                             |
-| Message           | Requests that are executed by non-consensus-critical apps.                                                                                                                       |
+| Transaction       | Request that modifies the consensus-critical state (validator balances and statuses).                                                                                            |
+| Message           | Request that is executed by a non-consensus-critical app.                                                                                                                        |
 
 ## System Architecture
 
 LazyLedger has a minimal state: the validator set (account balances, validator status, etc.). Changes to the validator set are done with native _transactions_, distinct from the _messages_ processed by apps. Transactions are signed and must be processed by clients to determine the validator set, while messages are un-signed data blobs that will usually represent an app's block data.
 
 Transactions pay fees similarly to how they would in a normal blockchain (e.g. Bitcoin), and their side effects are restricted to modifying the validator set and their balances. Transactions can additionally pay fees for the inclusion of a message (identified by a hash) in the same block. The validator set is committed to in the block header, and since the entire system state _is_ the validator set, this is the only state commitment needed in the header.
 
-One desideratum that will most likely be included is burning a non-proportional amount of coins for each transaction as a network fee. This provides baseline demand for the native coin: as the chain is used more, more coins must be bought then burned to pay for fees.
+One desideratum that will most likely be included is [burning a non-proportional amount of coins for each transaction as a network fee](../rationale/fees.md). This provides baseline demand for the native coin: as the chain is used more, more coins must be bought then burned to pay for fees.
 
 This architecture has the benefit of allowing a spectrum of clients. Since different components are made available through commitments, client that are only interested in a portion of the block data do not need to download and process the whole block.