revise rfc31 according to the review comment

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

@@ -15,23 +15,22 @@ This document proposes adding an optional variable length field to the block.
 
 ## Motivation
 
-Currently, the block header is a fixed length structure. Each header consists of 208 bytes.
+In the consensus version before activating this RFC, the block header is a fixed length structure. Each header consists of 208 bytes.
 
-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.
+Many extensions require adding new fields into the block, but there’s no enough reserved bits for them. For example, flyclient requires a 64-byte hash in the header.
+Workaround exists such as storing these data in the cellbase transaction, but it has a big overhead for clients which want to verify the chain using PoW only. Because they have 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 the 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 to interpret the new field 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`.
+There are many 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-byte hash. The block will have a new field `extension`.
 
 There are two important time points to deploy this RFC, activation epoch A and extension application epoch B.
 
-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.
+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 the `uncles` field is empty, or `ckbhash` on all the uncle header hashes concatenated together.
 
 ```
 uncles_hash = 0 when uncles is empty, otherwise
@@ -42,7 +41,7 @@ uncles_hash = ckbhash(U1 || U2 || ... || Un)
 
 See Appendix for the default hash function `ckbhash`. The annotation `||` means bytes concatenation.
 
-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.
+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-byte flyclient hash and an extra 32-byte hash on further extension bytes.
 
 The `extra_hash` is defined as: