Description
There are many entities (Transaction, Block Header, Block, Transaction Receipt) that are serialized as RLP item lists. The serialization is not only used in the persistence storage, but also in the consensus algorithm (ie the hash of a block header, proofs of transactions, etc)
When there is a need for additional information of any entity, a hard fork should be implemented, to support the additional fields.
This proposal describe a way to solve the problem for any ot these entities.
Version field
If an entity have 4 fields, then a fifth field (a byte) could be added. If the value is 0, it is not serialized, then the serialization of the entity is the same than the original serialization at the begnning of the blockchain.
If n additional fields are needed, then the version field will have the value of the new version, ie, one. Each additional field should have defined a default value. If all the additional fields have their default values, the version field is 0, and then, this field and the additional fields are NOT serialized.
This version one for entity X should be implemented in a hard fork. If in the future more additional fields are nedded, the version should have the value TWO, and so on.
Description
There are many entities (Transaction, Block Header, Block, Transaction Receipt) that are serialized as RLP item lists. The serialization is not only used in the persistence storage, but also in the consensus algorithm (ie the hash of a block header, proofs of transactions, etc)
When there is a need for additional information of any entity, a hard fork should be implemented, to support the additional fields.
This proposal describe a way to solve the problem for any ot these entities.
Version field
If an entity have 4 fields, then a fifth field (a byte) could be added. If the value is 0, it is not serialized, then the serialization of the entity is the same than the original serialization at the begnning of the blockchain.
If n additional fields are needed, then the version field will have the value of the new version, ie, one. Each additional field should have defined a default value. If all the additional fields have their default values, the version field is 0, and then, this field and the additional fields are NOT serialized.
This version one for entity X should be implemented in a hard fork. If in the future more additional fields are nedded, the version should have the value TWO, and so on.