Skip to content

Add BLS signature support for consensus #159

@naitik-supraoracles

Description

@naitik-supraoracles

Description

This is proposal for adding support of BLS sig in consensus process. Below are the potential primary changes which will be required in order to support bls signatures.

Overview of required changes

  • In vm-genesis/lib.rs, we have this Validator struct which is being used in smr-moonshot , here we have to add field for having BLS publickey.

  • here we have this ed15519 module which wrapper over original type with some implemented required traits to support over other aptos-core structs. so that we also have to implement new module with wrapper struct on blsttc as per aptos-core required traits.

  • in validator_config.rs we have this ValidatorConfig where we need to add field for BLS publickey. it will also require some other changes accordingly. This change also requires changes in move layer, because it will be going to deserialise there, also requires other changes in move layer.

Changes on move side

  • in genesis.move, we have structure ValidatorConfiguration where we need to add field for bls public key.

  • in stake.move, here also we need to add field for having bls public key in ValidatorConfig but it will also requires many other changes.

  • on the move side there is already cryptography implementation of bls12381 but that is not usable as they are made for keys in group1 and signature in group2. but as per our implementation we are looking for signatures in G1 and publickeys in G2, so we need to have move impl for blsttc as per this bls12381.move. But here few verification for verification and signing are vm specific native function, which we need to take a look how to work on it.

  • in committee_map.move , we also have this NodeInfo struct where we need to add field for bls key, but not so sure regarding this.

  • We can also expect other changes on move side with many structs and methods to support new changes for BLS signatures.

  • Other small changes need to be done while implementing to tackle if any other issues may arise.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions