Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Epic: Implement version information metadata #117

Open
14 tasks
lrettig opened this issue Feb 7, 2022 · 1 comment
Open
14 tasks

Epic: Implement version information metadata #117

lrettig opened this issue Feb 7, 2022 · 1 comment
Assignees
Labels

Comments

@lrettig
Copy link
Member

lrettig commented Feb 7, 2022

Based on spacemeshos/SMIPS#75:

  • 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:
    CREATE TABLE sqlite_schema(
      genesisid blob[20],
      vmid blob[20],
      protocolid blob[20],
      active bool,
    );
    
  • 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.
@lrettig lrettig added the epic label Feb 7, 2022
@lrettig lrettig self-assigned this Feb 7, 2022
@lrettig lrettig changed the title Epic: Implement version information metadata (WIP) Epic: Implement version information metadata Feb 24, 2022
@lrettig
Copy link
Member Author

lrettig commented Jun 22, 2022

We will probably want a simplified version of this for genesis, and the rest can be pushed back. See spacemeshos/SMIPS#75.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant