rfc224: apply review suggestions

rfcs/0224-variable-length-header-field/0224-variable-length-header-field.md

@@ -19,37 +19,37 @@ Currently, the block header is a fixed length structure. Each header consists of
 
 Many extensions require adding new fields into the block. For example, PoA for testnet requires 65 bytes for each signature, and flyclient also needs to add a 64 bytes hash.
 
-There's no enough reserved bits in the header for these extensions. There's a workaround to store these data in the cellbase transaction, but this solution has a big overhead for clients which wants to quickly verify the data using PoW only. If the data are stored in the cellbase transaction, the client has to download the cellbase transaction and the merkle tree proof of the cellbase transaction, which can be larger than the block header itself.
+There's no enough reserved bits in the header for these extensions. There's a workaround to store these data in the cellbase transaction, but this solution has a big overhead for clients which want to quickly verify the data using PoW only. If the data are stored in the cellbase transaction, the client has to download the cellbase transaction and the merkle tree proof of the cellbase transaction, which can be larger than the block header itself.
 
-This document proposes a solution to add a variable length field in the block. How the new field is interpreted is beyond the scope of this document and must be defined and deployed via a future soft fork. Although the field is added to the block body, nodes can synchronize block header and this field together in the future version.
+This document proposes a solution to add a variable length field in the block. How the new field is interpreted is beyond the scope of this document and must be defined and deployed via a future soft fork. Although the field is added to the block body, nodes can synchronize the block header and this field together in the future version.
 
 ## Specification
 
 The block header is encoded as a molecule struct, which consists of fixed length fields. The header binary is just the concatenation of all the fields in sequence.
 
 There are many different ways to add the variable length field to the block header. This RFC proposes to replace the `uncles_hash` in the header with the new field `extra_hash`, which is also a 32-bytes hash. The block will have a new field `extension`.
 
-The following paragraphs will refer to the current running CKB version as ckb2019, the next fork as ckb2021 and the soft fork introducing the schema of `extension` as ckb2021x.
+There are two important time points to deploy this RFC, activation epoch A and extension application epoch B.
 
-In CKB ckb2019 and blocks generated in ckb2019, `extra_hash` is the same with the `uncles_hash`. So the block headers serialized by molecule are identical. The version `ckb2019` requires that the `extra_hash` is the hash on `uncles` in the block body. It is all zeros when `uncles` is empty, or `ckbhash` on all the uncle header hashes concatenated together.
+In blocks before epoch A, the `extension` must be absent. The value of `extra_hash` is the same as the original `uncles_hash` in these blocks, so this RFC will not change the serialized headers of existing blocks. The field `extra_hash` is all zeros when `uncles` is empty, or `ckbhash` on all the uncle header hashes concatenated together.
 
-    ```
-    uncles_hash = 0 when uncles is empty, otherwise
+```
+uncles_hash = 0 when uncles is empty, otherwise
 
-    uncles_hash = ckbhash(U1 || U2 || ... || Un)
-      where Ui is the header_hash of the i-th uncle in uncles
-    ```
+uncles_hash = ckbhash(U1 || U2 || ... || Un)
+    where Ui is the header_hash of the i-th uncle in uncles
+```
 
 See Appendix for the default hash function `ckbhash`. The annotation `||` means bytes concatenation.
 
-The version ckb2021 does not verify the content of `extension`, it only requires that its length is at most 96 bytes.
+In blocks generated since epoch A, `extension` can be absent, or any binary with 1 to 96 bytes. The upper limit 96 prevents abusing this field because there's no consensus rule to verify the content of `extension`. The 96 bytes limit allows storing the 64-bytes flyclient hash and extra 32-bytes as a hash on further extension bytes.
 
 The `extra_hash` is defined as:
 
-* When `extension` is empty, `extra_hash` is the same with the `uncles_hash`.
+* When `extension` is empty, `extra_hash` is the same as the `uncles_hash`.
 * Otherwise `extra_hash = ckbhash(uncles_hash || ckbhash(extension))`
 
-The version ckb2021x will add consensus rule on the schema of `extension` and nodes must synchronize the field to verify that it is valid.
+Since epoch B, consensus will define the schema of `extension` and verify the content. This is a soft fork if the `extension` is at most 96 bytes, because nodes deployed since epoch A do not verify the content of `extension`.  
 
 ### P2P Protocols Changes
 
@@ -91,7 +91,7 @@ table CompactBlock {
 }
 ```
 
-Before ckb2021 is activated, `extension` must be empty. After activation, the node must verify that `uncles` and `extension` match the `extra_hash` in the header.
+For blocks before the activation epoch A, `extension` must be absent. After activation, the node must verify that `extension` is absent or a binary with 1 to 96 bytes, and `uncles` and `extension` match the `extra_hash` in the header.
 
 Pay attention that the `extension` field will occupy the block size.
 
@@ -106,13 +106,6 @@ Pay attention that the `extension` field will occupy the block size.
 2. [Using Molecule Table in New Block Headers](./2-using-molecule-table-in-new-block-headers.md)
 3. [Appending a Hash At the End](./3-appending-a-hash-at-the-end.md)
 
-## Security
-## Test Vectors
-## Rationale
-## Deployment
-## Backward compatibility
-## Acknowledgments
-
 ## Appendix
 
 ### ckbhash