You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update versioning scheme. main.go should receive and set a three-element version tuple in the Cmd context, where each element of the tuple is a 20 byte hash (byte array).
Add a new database table that stores valid combinations of these three ID values. Each row represents a valid ID tuple, has an implicit, unique, integer rowid, and the schema is simply:
Add three new extradata fields to config file: genesis-extradata, vm-extradata, protocol-extradata (strings with a max length of 255 chars.)
When the node starts, it should read these three extradata fields from config, zero-pad them and turn them into fixed-length byte arrays. It should then calculate the IDs and ensure that the GENESISID hasn't changed (if it has, or if the extradata fields are missing or too long, it should panic). All three IDs should then be set in the Cmd context, and the database updated with new IDs if necessary. For purposes of calculating new IDs, the row in the versions table with active=true should be used for the "previous" IDs, and then active should be unset on the previous row and set on the new entry.
When a new VMID is detected, the mempool should be cleared, i.e., it should not be loaded from disk at start, and a warning message should be printed for the node operator to this effect.
Update version.txt and Makefile to handle the new scheme. When a new release is cut (e.g., make tag-and-build), the user must specify whether the new release updates VMID and PROTOCOLID, PROTOCOLID only, or none. (We may need to split this into multiple make recipes, e.g., make tag-and-build-new-vmid and make-tag-and-build-new-protocolid). When one of the IDs is changed, the corresponding extradata field in the config file should be set to the git commithash of the current HEAD.
Standardize hash function used to sign messages and data structures. Wrap the underlying hash function in a module or utility function that has access to the active version tuple (via Cmd context).
Every time hash function is called to hash a data structure that is to be signed, the serialized data structure is prepended by the three-element version tuple.
Extend the ATX data structure to contain an explicit VMID and PROTOCOLID. When it's saved to disk (to the DB), the 20 byte IDs can be replaced with shorter pointers to the versions table defined above: 60 bytes (20 x 3 IDs) should be compressable to a one- or two-byte row number. The IDs should be explicitly filled in again when reading an ATX from disk.
Modify Hare to vote against proposals that contain one or more transactions signed using a bad VMID.
Gossip handling:
If a block message is received with a bad GENESISID, i.e., a signature that cannot be verified, it should be dropped and its peer dropped and blacklisted. (Messages with a bad GENESISID are always considered Byzantine as it's never supposed to change.)
If a transaction message is received with a signature that cannot be verified against the current VMID, it should be dropped and should not be gossiped. If the transaction was signed with an old VMID (which requires testing each, or a sliding window of recent VMIDs, in turn), no further action is necessary. If no previous VMID matches, it may be assumed that GENESISID doesn't match (or a very old VMID was used) and the peer should be dropped and blacklisted.
If an ATX message is received with an (explicit) unknown GENESISID, drop it, drop and ban the peer. If the VMID or PROTOCOLID is unknown, they should be added to the versions table. If PROTOCOLID doesn't match the current PROTOCOLID, the ATX's weight should be set to zero for the purpose of voting weight/active set calculations.
The text was updated successfully, but these errors were encountered:
Based on spacemeshos/SMIPS#75:
main.go
should receive and set a three-element version tuple in the Cmd context, where each element of the tuple is a 20 byte hash (byte array).genesis-extradata
,vm-extradata
,protocol-extradata
(strings with a max length of 255 chars.)extradata
fields from config, zero-pad them and turn them into fixed-length byte arrays. It should then calculate the IDs and ensure that theGENESISID
hasn't changed (if it has, or if theextradata
fields are missing or too long, it should panic). All three IDs should then be set in the Cmd context, and the database updated with new IDs if necessary. For purposes of calculating new IDs, the row in the versions table withactive=true
should be used for the "previous" IDs, and then active should be unset on the previous row and set on the new entry.VMID
is detected, the mempool should be cleared, i.e., it should not be loaded from disk at start, and a warning message should be printed for the node operator to this effect.version.txt
andMakefile
to handle the new scheme. When a new release is cut (e.g.,make tag-and-build
), the user must specify whether the new release updatesVMID
andPROTOCOLID
,PROTOCOLID
only, or none. (We may need to split this into multiplemake
recipes, e.g.,make tag-and-build-new-vmid
andmake-tag-and-build-new-protocolid
). When one of the IDs is changed, the correspondingextradata
field in the config file should be set to the git commithash of the current HEAD.VMID
andPROTOCOLID
. When it's saved to disk (to the DB), the 20 byte IDs can be replaced with shorter pointers to the versions table defined above: 60 bytes (20 x 3 IDs) should be compressable to a one- or two-byte row number. The IDs should be explicitly filled in again when reading an ATX from disk.VMID
.GENESISID
, i.e., a signature that cannot be verified, it should be dropped and its peer dropped and blacklisted. (Messages with a badGENESISID
are always considered Byzantine as it's never supposed to change.)VMID
, it should be dropped and should not be gossiped. If the transaction was signed with an oldVMID
(which requires testing each, or a sliding window of recentVMIDs
, in turn), no further action is necessary. If no previousVMID
matches, it may be assumed thatGENESISID
doesn't match (or a very oldVMID
was used) and the peer should be dropped and blacklisted.GENESISID
, drop it, drop and ban the peer. If theVMID
orPROTOCOLID
is unknown, they should be added to the versions table. IfPROTOCOLID
doesn't match the currentPROTOCOLID
, the ATX's weight should be set to zero for the purpose of voting weight/active set calculations.The text was updated successfully, but these errors were encountered: