---
title: Forward Embedded Inclusion Bonds - FEIB
created: 2022-08-12T10:54:25 (UTC -07:00)
tags: []
source:
author:
version: draft.v02, v0.3, v0.4 (latest)
---

# Forward Embedded Inclusion Bonds - FEIB

_Turning OpEx ("gas") into CapEx (for DApps/Protocols) and Hedging volatility for validators and block constructors_

## 10/31/2022

As of the 31st of 10/2022 This Specification is depreciated with noted mechanism changes including new market implementation not requiring a 3 step scheme, different mechanics, and stronger

## Abstract

> This is an updated version of this draft proposal: https://solmaz.io/2020/05/20/inclusion-bonds/

This proposal aims to solve the 'Malicous Relay'[^1] issue, along with achieving the goal of shifting the problem of transaction inclusion in block construction away from the block constructor current level (100% determined by the block constructor) to some percentage determined by the validator-bond holder market (bond holders being dapps/protocols).

[^1]: https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177#malicious-relay-6

**This would make Ether more like a currency than currently is, as rewards would be created from the offsetting future liability**.

## Blockspace Inclusion Forward Market

Free gas is not 'free': there is no free lunch. It is free in the sense of uncertainity

> Free Gas = maxFeePerGas + baseFeePerGas + Price

> Total Gas = maxPriorityFeePerGas(2) + Free Gas

> This means user still pays at least the `maxPriorityFeePerGas(2)`

Let’s assume a generic Proof of Stake protocol where validators take turns proposing blocks.[^1] The number of blocks proposed by a validator is directly proportional to (or a linear function of) his weight:
[^1]: Ethereum PoS has a more complicated arrangement for how blocks are proposed and constructed. For the purposes of this draft proposal the nuances are not materially significant.

- Alice staked X tokens, and Bob staked 2X tokens.[^3]
- → Alice proposes Y blocks per unit time, and Bob proposes 2Y blocks per unit time.
[^3]: Tokens in this proposal mean the Native Currency, in our cases ETH. Wrapped Ether can be substituted. However expanding to having any ERC20 token is problematic as the unit of account for computation is measured in 'gas' (which compromises ETH/WETH). For our purposes we ignore all other issuances and only consider WETH as the 'token'.

Moreover, number of transactions included on average is calculated by multiplying with weight:

- Network processed 10m txs last month. Alice’s weight is 5%.
- → Alice included 10m \* 5% = 500k txs last month

Let’s assume that the transaction fee distribution scheme in this protocol is proposer-gets-all, that is, the block proposer receives the fees attached to transactions that he included in the block.

Alice, as a validator, can get 'free' gas. She signs some transactions, but doesn’t publish them. Instead, when it’s her turn to propose a block, she just includes them. Since it’s Alice collecting the transaction fees, she essentially pays herself for the transaction, getting _free gas_.[^2]
[^2]: This is a fiction, in that post EIP-1559, the `maxPriorityFeePerGas` is burned apart of the transaction. The user bears this cost as part of this proposed inclusion market system.

Alice can be a dapp developer, paying for the usage of the dapp’s users. Given her `weight`, she would have the right to include `weight * total_tps` many transactions per second. If the number of users increases and she needs more throughput, she simply increases her weight by staking more.

Moreover, delegators can also get _free gas_ with implicit agreements. Let’s assume Dan, a dapp developer, also wants to get _free gas_, but he doesn’t want to become a validator.

Dan can simply delegate tokens to Alice, increasing her weight and throughput allocation. Dan enters an agreement with Alice: Dan will share his transactions only with Alice. Then, when Alice includes them, she will relay the tx fees back to Dan, after getting a commission. As a result, Dan gets _highly discounted_ or _free gas_ without becoming a validator, depending on Alice’s commission rate.

## OpEx into CapEx

It’s easy to see what’s happening here: Alice and Dan are converting their **OPEX** into **CAPEX**. Instead of paying for their users’ transactions regularly, they make a one time investment to cover their users’ expenses.

Well, “one time” considering your demand for transaction stays the same. If Alice or Dan has a growing user base, however, their path may look like this:

1. Develop a protocol/DApp. Make initial investment: delegate 100 users’ throughput worth of tokens.
2. You found product-market fit and now have 10x more users.
3. Top-up delegation 10x to offset increased demand.
4. Rinse and Repeat.

Still, with this model, one doesn’t have to pay for gas, AND one can receive issuance rewards on top of it.

However, a problem becomes apparent. **Alice has to wait until it’s her turn to propose, in order to include transactions. Also, Dan has to wait until it’s the validator’s turn whom he delegated to**.

Say that Alice has 1% weight. Then, Alice can propose every 1 in 100 blocks, and the time to finality has increased 100-fold. Alice has to wait for a long time, if a subsequent transaction depends on the inclusion of a preceding transaction.

A *possible* alternative for getting _free gas_ could be to make validators exempt of paying fees for transactions, i.e. allow them to get zero gas price. However, in such a scenario, there is no incentive for a validator to include another validator’s transaction, since they could be filling the same block space with a regular user’s paying transactions.

## FEIB - Instrumenting Transaction Inclusion Incentives

To solve this problem, we can devise an instrument called **Forward Embedded Inclusion Bond**, or FEIB for short. With an FEIB, Alice and Bob can include each other’s transactions, and eventually have their respective transaction fees routed back to them.

> Here is a simple example:

1. Alice publishes her transaction.
2. It’s Bob’s turn, and he includes it immediately. Transaction fee is calculated as F.
3. However, Bob doesn’t receive the transaction fee. Instead, an FEIB is created, within which the fee is locked.
- Alice owes Bob transaction inclusion worth of F tokens.
- Neither Alice nor Bob can use the tokens, until Alice settles the FEIB by including one of Bob’s transactions.
4. The FEIB sits for a while. Then, Bob publishes a tx, and Alice includes it. Resulting fee is `G` tokens. Depending on the amount, we have 3 options:
- Case `G < F` (Bob spends less than Alice): Bob immediately receives back the G tokens which he has just paid. G tokens are released from the FEIB, and returned to Alice. The FEIB has `F - G` outstanding.
- Case `G = F` (Bob spends the same amount as Alice): Bob immediately receives back `G = F` tokens which he has just paid. All `G = F` tokens are released from the bond, and returned to Alice. The FEIB is settled.
- Case `G > F` (Bob spends more than Alice): Bob immediately receives back F (a portion of) the tokens which he has just paid. All F tokens are released from the bond, and returned to Alice. While the FEIB is settled, a new one is created, where Bob owes Alice an inclusion worth of `G - F` tokens.

> TODO; Graph

## Opt-in Validator Mechanics

FEIB are opt-in, that is, if a validator is OK with generating an FEIB, he can set a flag in the transaction header.

- 0: _FEIB not allowed._ Proposer directly receives the resulting fee.
- 1: _FEIB allowed_, but not enforced. Proposer can choose to receive the fee directly, or create an FEIB.
- 2: _FEIB enforced._ If the proposer chooses to include, he won’t be able to receive the fee directly, and an FEIB will be created.

Validators generate FEIBs based on their own throughput allocation. At any given time, a validator is expected to have many outstanding FEIBs with most other validators, where they keep track of each other’s throughput allocation and outstanding FEIBs. If Bob sees that Alice’s outstanding FEIBs are close to her throughput allocation, then Bob does not enter into any more FEIBs with Alice, because there is a high chance she will not be able to return the favor.

Also, there is a certain lag until a tx fee is relayed back to its originator, since Alice has to wait until Bob publishes a transaction, for the FEIB to be settled.

FEIBs function similarly with delegators:

1. Dan specifies Alice as the issuer of the FEIB in his tx header.
2. Bob includes Alice’s tx, generating an FEIB between Alice and Bob.
3. Later, Alice includes one of Bob’s tx, settling the FEIB and receiving the tx fee back.
4. Alice takes a commission and relays the rest of the back to Dan.

Caveat: While inter-validator agreements are enforced by the protocol, validator-delegator agreements do not have to be. Alice can track whether Dan’s delegation is enough to cover the tx fee, and not relay the fee if it’s not.

### Determining Timespan: 3 Epochs

> https://lighthouse-blog.sigmaprime.io/attestation-packing.html (4)

By maintaining a list of validators which have had attestations included in a window spanning the last 3 epochs, we can create an estimate for the number of long-standing offline validators at epoch e: Oe.

This allows us to calculate a new normalized efficiency Nn where:

\begin{equation}
N_n=\frac{\left|I_n\right|}{\left|A_n-O_e\right|}
\end{equation}

To understand why a 3 epoch window was selected, consider the effect of changing the window size. As the window size decreases (say to 1 epoch), the size of $Oe$ increases, $|An−Oe|$ approaches $|In|$ and thus the normalized efficiencies would converge to 100%. Likewise, as the window increases to infinity, $|Oe|$ approaches $0$ and thus the normalized efficiencies would converge onto the original calculated efficiencies. A window of 3 epochs was chosen as a reasonable middle ground.

## Technical Implemtation Details (WIP)

##### Non-Myopic

Players are non-myopic if they are concerned for presents and future payoffs.
Given an infinite sequence of payoffs $$r_{0}, r_{1}, r_{2}, \ldots$$ for a player
$i$ and a discount factor $$\delta$$ with $$0 \leq \delta<1, i^{\prime}$$ s future
discounted reward is \begin{equation*} \sum*{i=0}^{\infty} \delta^{i} r*{i}
\end{equation*} Intuition on discount factor:

- The agent values about near term profits than future profits.
- The discount factor models the players' patience.

\begin{equation*} \sum*{i=0}^{\infty} \delta^{i} r*{i} \end{equation*}

### Repeated game

#### Repeated games

The stage game is played indefinitely many times. Players can observe past
actions. All player: share the same discount factor $\delta$. Player's utility
Let $x_{t}$ be the tuple of actions played at round $t$, then the utility of a
player $i$ with discount factor $\delta$ is: \begin{equation*}
U*{i}=\sum*{t=0}^{\infty} \delta^{t} u*{i}\left(x*{t}\right) \end{equation*}

- $EV =$ The value that can be extracted if players know the content of txs per
block.
- $CR =$ Commit and Reveal. If possible, slash the other player.
- RC $=$ Reveal and Commit. If possible, extract EV.
- $R =$ Reward per Block.
- $S =$ Slashing value s.t. $S >> EV$.

### Tx Type

A new transaction type which adds two predicates
Only apply the transaction against these merkle leaves
Only include the transaction if this set of merkle leaves has these values
These are tricky predicates to use, but very easy to implement. More complex comparators (<,>,<=,>=, etc) are theoretically possible and reasonable to use/verify. (If we are going to implement them, we’d probably need to muck around with merklization…)
Now block producers/builders (and other transactors!) know which transactions will be contentious without needing to execute them.
Slowly/Safely moves us from a “contentious-first” transaction model

## Summary

To summarize, FEIBs allow validators to keep an account of inclusion of each other’s transactions. The fee is locked up until the favor is returned, so the issuer has an incentive to include the holder’s transaction to receive the fee back. In a functioning system, validators keep track of FEIBs: They favor the txs of validators who have returned the favor in the past, and refrain from including the txs of validators that don’t return the favor.

## Market Design

### Requirements

TODO

### Overview

Defining the exact details of a decentralised auction is of course a subject in itself. In order to prevent front-running by validating nodes, the auction will have to take place over three periods. In the first period, bids are hashed and broadcast, and consensus is achieved on the existence of the encrypted orders. In the second period, bidders will broadcast the unencrypted order contents and nonce, and consensus is achieved on those by validating that the submissions in the second period hash to the digests submitted in the first period. In the third period, validating nodes validate the spends and and apply the auction protocol to determine winning bids and $P^{S}$.

We define $P_{i}$ in terms of information that is purely \emph{endogenous} to the network itself: *BaseFee*

Without specifying what types of values $P_{i}$ could be, we've sort of assumed the \emph{exogenous} design in this note. The idea here is that, $P_{i}$ would be defined as some specific price index,

\begin{equation}
P_{i} = \frac{p^{1}_{1}w^{1} + \dots + p^{n}_{1}w^{n}}{p^{1}_{i}w^{1} + \dots + p^{n}_{i}w^{n}}
\end{equation}

where $p^{j}$ is the coin market price one of $n$ specific goods/assets and $w^{j}$ is its index weight. For example, the index might consist of the coin prices of a basket of commodities (crude oil, wheat, copper, etc). The goal here is to make the value of coin stable \emph{with respect to} some pre-defined target level of $P_{i}$, e.g., $P_{i} \approx 1$ for all times $i$.

## Notes

see https://github.com/ethereum/consensus-specs/issues/2749 Proposed attnets revamp #2749

https://github.com/sigp/lighthouse/issues/2847 Shift subnet backbone structure #2847

## Citations

TODO

## Appendix:

### Intro: Two Types of Money

| Attribute | CBM | CoBM |
|--- |--- |--- |
| Who issues it? | central bank | comm. bank |
| Who can own it? | banks, some FMI | everyone |
| How is it transferred? | CB RTGS system | various systems |
| How is it created? | asset purchases | bank loans |
| Does it have credit risk? | no | yes |
| What does it yield? | policy rate | LIBOR +//- |

Transactional coin demand $C D_{T}$ is inversely related to coin volatility.
The more volatile the coin, the less useful it is as a medium of exchange.

o Volatility raises transaction costs for merchants.
o Volatility renders coin useless as a unit-of-account.
o Volatility increases need for re-balancing.