Block Rewards and the Gateway to Free Transactions
Bitcoin and Ethereum contain transactions that get by with no gas fees. In fact, they’re part of the system.
When first learning that some consensus and governance could be done on-chain, my initial question was why? It doesn’t make much sense considering that nodes would be forced to pay a gas fee just to propose a block. Furthermore, what utility is there for storing data on the blockchain anyway? We typically think of the consensus operations as the “backend” operations. Where state information is embedded directly into the consensus engine. The philosophy for moving the data on-chain is similar in concept to the way that language designers often write large chunks of their programming language, in that language. Rust, for instance, is 97.7% Rust.
By moving consensus logic into the blockchain state, the wallets and validator software is simplified. There is no need for validator nodes to explicitly track the block hash history, or the current validator set in a PoS engine, when it is already on the blockchain.
But there is an obvious downside to tracking state on-chain — gas fees. We don’t want to force the validators/miners of a network to pay gas fees every block. That would dis-incentivize their participation and seems totally unnecessary.
To understand how this problem can be solved, let’s look at how Bitcoin issues block rewards to the miner that solves a block (PoW). The winning miner is allowed to prepend a transaction to the block list, called a coinbase. The coinbase is the block reward to the miner for their work. Here is the code in the Bitcoin Github repository that creates and attaches the coinbase. Let’s dissect the important lines.
Instantiate a coinbase transaction.
CMutableTransaction coinbaseTx;Assign the value to GetBlockSubsidy(nHeight, ..) which gets the reward amount in Btc for block at nHeight, plus nFees, which is the sum of transaction fees for the block. This should be familiar if you understand PoW.
coinbaseTx.vout[0].nValue = nFees + GetBlockSubsidy(nHeight, chainparams.GetConsensus());Move the transaction to the 0th index of the block transaction list.
pblock->vtx[0] = MakeTransactionRef(std::move(coinbaseTx));Set the coinbase transaction fee to negate the sum of all transactions in the block. The convention here is a little strange. The transaction fee is not considered at all for the coinbase in the validity checks. Also, making the fee negative does not mean the proposer gets the fee amount added to their balance. It just means there is no fee.
pblocktemplate->vTxFees[0] = -nFees;So Bitcoin makes the block reward a natural part of the system. Miners accept the free transaction as part of the protocol to make things easy. Sure enough, if you inspect any block on blockexplorer.com (like this one), the first transaction will be the Bitcoin reward to the proposer.
You can see that a coinbase transaction is defined by its single input, who’s previous output is null. Effectively, the transaction does not come from any specific account.
bool IsCoinBase() const
{
return (vin.size() == 1 && vin[0].prevout.IsNull()); }On the contrary, the Ethereum protocol tracks block rewards as part of the off-chain state management. There is no direct record of a block reward inside a block’s transaction list. In fact, the Ethereum source code defines a coinbase to be an address instead of a transaction. Specifically, the address of the block proposer. That way, each node upon receiving a valid block, can update its local state to assign a reward to the coinbase (as seen here and here).
Still, Ethereum does utilize on-chain state management. Enter the SYSTEM address. Proposed by Vitalik Buterin in EIP 96, SYSTEM (which he calls SUPERUSER), is a standardized account located at 2¹⁶⁰-2 or 0xfffffffffffffffffffffffffffffffffffffffe . SYSTEM transactions are “transactions that are enforced by block validity rules (i.e. if the transaction is not included, it is considered invalid) …”, as it is described in ECIP 1030. By requiring a certain SYSTEM transaction in a given block, the EIP 96 design can ensure that the blockhash contract will be updated on every new block proposal. Similarly, we could be sure that each block contains a block reward. Essentially, SYSTEM transactions represent regular consensus maintenance operations that are encoded as transactions on the blockchain. The magic of the SYSTEM transaction is that “This SYSTEM transaction would have its gas_price set to 0”-ECIP 1030. Because it is convenient for all validators to update important consensus work on-chain and free of charge, there is no problem accepting the 0 gas fee. I see the SYSTEM transaction as an abstraction of the original Bitcoin block reward that comes from nowhere. By giving it a name, we can use the transaction type for all sorts of fun things.
I stumbled upon this feature when looking for a way to manage the C4Coin’s validator set on-chain, and further, to enforce the token burn as specified in our PoB consensus protocol. SYSTEM transactions are the perfect tool to bake necessary consensus operations directly into the blockchain. Keep it in mind if you happen to be modifying the EVM’s protocol for your own consensus algorithm.