Consensus Check- #REI DAO #7 Proposal # BLS Signature Aggregation

Consensus Check
#1

Quorum

2% of the circulating supply (750 million). The purpose of this quorum is to ensure that the only measures that pass have adequate voter participation.

1
11760×980 56.8 KB

Abstract

REI Network, the new EVM-compatible public chain, plans to introduce BLS signature aggregation in the new version to improve blockchain performance, reduce network latency, improve security, and reduce operating costs.

The community will vote on whether to allow the adoption of BLS signature in the upcoming upgrade. Compared with the original ECDSA-SECP256K1 signature, the BLS signature will significantly reduce the storage space occupied by the block signature.

The goal of this upgrade is to improve the efficiency of block broadcasting, reduce the size of blocks, and increase the security of the private key of the validator account.

Specific goals

The specific goals of the upgraded REI Network using BLS signature aggregation for the consensus level of blocks are:

  1. Improve blockchain performance: BLS signature aggregation can aggregate multiple signatures into a smaller signature, reducing storage and transmission requirements, thereby improving blockchain performance;

  2. Reduce network delay: Due to the small size of the aggregated signature, it can reduce the time required for network transmission, thereby reducing network delay;

  3. Improve security: BLS signature has strong security, making it difficult for attackers to forge signatures or tamper with data;

  4. Reduce costs: By reducing storage and transmission requirements, BLS signature aggregation can reduce system operating costs;

Concrete embodiment:

  1. No random number generator is required, all signatures in the block can be aggregated into one;

  2. It is easy to implement m-n multi-signature, and can also avoid redundant communication between signers;

  3. The length of the signature is shorter (the signature is one point on the elliptic curve instead of two), which is 1/2 of Schnorr or ECDSA.

Necessary decision

The community voted for the next upgrade of REI Network to allow BLS signature aggregation, that is, multiple signatures are aggregated into a single signature, including contract registration, upgrade process, and technical specifications.

First, rei-network core developers will deploy a BLS public key registration contract. Second, for the upcoming hard fork upgrade, validators need to register their own public keys in the BLS public key registration contract.

Finally, when the fork upgrade is completed, the signature algorithm of the proposal and voting will be switched to BLS, and the validator who has registered the BLS public key can participate in the validator election.

The purpose is to reduce the size of the block, improve the efficiency of block broadcasting, and increase the security of the private key of the validator account.

Motivation

In the past, in rei-network, the block header of each block contained signatures from all validators on the block to prove that the block has collected 2/3+ votes. Since the signature algorithm uses ECDSA-SECP256K1, the length of each signature is 65 bytes, and there are at most 21 validators, which leads to a maximum of 1365 bytes for only one signature.

This may cause the validator to occupy too much space, it is not economical, and this may also affect the broadcast efficiency of the block. At the same time, in order to sign the vote, the validator must unlock the private key on its own node. In some cases, this may lead to the loss of user assets, private key leakage, and so on.

This RIP will introduce the BLS signature algorithm. The length of the BLS signature is 96 bytes. Compared with the 65 bytes of ECDSA-SECP256K1, it may increase the pressure on the validator P2P network. However, the length of the aggregated BLS signature is still 96 bytes.

Compared with ECDSA-SECP256K1, it is up to 1365 bytes, which reduces the space occupied by the signature in the block by 92.96%. And the length of the BLS signature aggregation will not increase with the number of validators. More importantly, now the validator can produce blocks when unlocking the BLS private key, which greatly reduces the leakage risk of the account private key.

Specification

Proposal

beforeFORK_BLOCK_NUMBER , the proposal contains the following fields:

  • type : voting type
  • height : height
  • round : round
  • POLRound : proof of lock round
  • hash : block hash

afterFORK_BLOCK_NUMBER , the proposal contains the following fields:

  • type : voting type
  • height : height
  • round : round
  • POLRound : proof of lock round
  • hash : block hash
  • proposer : proposer address

Among which:

  • The reason for adding the proposer address is that when using ECDSA-SECP256K1, the proposer address can be directly restored based on the message hash and signature, but after using the BLS signature, the proposer address cannot be restored. Therefore, each vote requires an additional proposer address, and the person who verifies the proposal also needs to check whether the proposer’s address is legal.

Vote

beforeFORK_BLOCK_NUMBER , the proposal contains the following fields:

  • chainId : chain ID
  • type : voting type
  • height : height
  • round : round
  • hash : block hash
  • index : The validator’s position in the validator set

The hash used when signing isrlphash([chainId, type, height, round, hash, index])

afterFORK_BLOCK_NUMBER , change into:

  • chainId : chain ID
  • type : voting type
  • height : height
  • round : round
  • hash : block hash
  • index : The validator’s position in the validator set
  • validator : validator address

The hash used when signing is rlphash([chainId, type, height, round, hash])

Among which:

  • The address of the validator is added because when using ECDSA-SECP256K1, the validator address can be directly restored based on the message hash and signature. However, after using the BLS signature, the validator address cannot be restored. Therefore, each vote requires an additional validator address, and the person who verifies the vote also needs to check whether the validator’s address is legal.
  • The index field no longer participates in the signature because the signature content of the aggregated BLS signature must be consistent. If the signature content includes the location of the validator, the content of each validator’s signature is different.

BLS public key registration contract

The BLS public key registration contract contains at least the following:

interface IValidatorBLS {
    /**
     * @dev register BLS public key
     * @param key - BLS public key, Length must be 48,
     *              This method can be called repeatedly to update the public key,
     *              Multiple validators cannot register the same public key.
     */
    function setBLSPublicKey(bytes calldata key) external;

    /**
     * @dev Obtain the BLS public key based on the validator address
     * @param validator - validator address
     * @return If the validator has not registered the public key, the return result is empty
     */
    function getBLSPublicKey(address validator) external view returns (bytes memory);
}

Rationale

Upgrade process

1.rei-network core developers deploy BLS public key registration contract

2.The validator generates a BLS public-private key pair through the command line

Example:
rei --datadir /path/to/your/datadir bls new

After running the above command, the validator program will ask the user to set a password to protect the BLS private key. After the generation success, the validator will print out the new BLS public key.

3.And register its own BLS public key in the contract

Visit https://dao.rei.network, unlock the private key of the validator account, and interact with the page to complete the registration

4.The validator upgrades the node version, unlocks the account and the BLS private key at the same time at the startup

Example:
rei --datadir /path/to/your/datadir --mine --coinbase 0x...abc --unlock 0x...abc --password /path/to/your/password --bls-file /your/bls/key/file --bls-password /path/to/your/bls/password

The ECDSA-SECP256K1 signature algorithm is used before the hard fork height, and the BLS signature algorithm is used after the hard fork. Therefore, when the hard fork height is about to be reached, the validator needs to unlock the account private key and the BLS private key at the same time.

5.The block height reaches the hard fork upgrade height, the BLS public key registration contract address becomes 0x0000000000000000000000000000000000001009 , the old contract address becomes invalid, but the registered BLS public key still exists in the contract, and the validator does not need to register again

6.The hard fork upgrade is completed, and now the validator can unlock the BLS private key without unlocking the account private key

Example:
rei --datadir /path/to/your/datadir --mine --coinbase 0x...abc --bls-file /your/bls/key/file --bls-password /path/to/your/bls/password