Increasing the blocksize as a (generalized) softfork.

Summary:

This is a draft by Joe, and it explains how to increase the blocksize limit using a "generalized" softfork instead of a hardfork. This generalized softfork requires only a miner majority (>50% hashpower) rather than global consensus. The document starts with an introduction explaining that most people assume that increasing the blocksize limit requires a hardfork. The paper then moves on to explain standard softforks and how they work. After a softfork, two potential chains exist: the new chain valid under the new rules and old rules, and the old chain valid under the old rules only. Assuming that >50% of the hashpower follow the new rules, the old chain is doomed to be orphaned.Generalized Softforks are introduced next. A *generalized* softfork introduces a transform function f(B)=B' that maps a block B valid under the new rules to a block B' valid under the old rules. After a generalized softfork, three chains may exist -the new chain valid under the new rules only, the mapped chain f(B3), f(B4), f(B5), and the old chain, B3', B4', B5', valid under the old rules only. The paper then gives an example of Segregated Witness as an instance of a generalized softfork. Here the new block format consists of the combined old block and witness data. The function f() simply strips the witness data to reveal a valid block under the old rules. Next, the paper explains how to achieve arbitrary block-size increases via a generalized softfork. The proposal consists of two parts: (a) new rules for valid blocks, and (b) a transformation function f(). The new block rules are very similar to the old block rules but with some small changes. In order to be a generalized softfork, we also need to define a mapping f() from valid new blocks to valid blocks under the old rules. We can define this as follows: NewBlock := BlockHeader ++ NumTx ++ CoinBaseTx ++ Tx1 ++ .. ++ Txn f(NewBlock) := BlockHeader ++ 1 ++ CoinBaseTx. That is, function f() simply truncates the block so that it contains the coinbase transaction only.The proposed new rules combined with the transformation f() comprise a generalized softfork. After the fork, a new chain B3,B4,B5,... will be generated under the new rules defined above, including an increased blocksize limit. This new chain can be mapped to a valid chain f(B3),f(B4),f(B5),...under the old rules. Assuming that >50% of the hashpower has adopted the new rules, the mapped chain will orphan any competing chain under the old rules, just like a standard softfork.An interesting consequence of this design is that since all mapped blocks are empty, old clients will never see transactions confirming. The paper concludes by stating that conventional wisdom suggests that increasing the blocksize limit requires a hardfork but shows that it can instead be achieved using a generalized softfork. The author suggests investigating other kinds of hardforks that can be implemented as generalized softforks and the security implications of such.

Updated on: 2023-06-11T02:38:27.507875+00:00