The BLS signature algorithm upgrade has brought forth a series of crucial advantages, primarily focusing on improvements in validator address management and optimization of block space usage.

Main Objectives of the BLS Upgrade

Elimination of Validator Reward Address Dependency in the Consensus Mechanism

In this upgrade process, significant modifications were made to the signature algorithm used in the consensus mechanism: the validator’s block voting signature algorithm was transitioned from ECDSA to BLS. This implies that validators no longer need to sign blocks using the private key of their rewards address; instead, they utilize their corresponding BLS private key for signing. This change becomes particularly evident after the hard fork: during node startup, users are not required to unlock the rewards address keystore; they only need to unlock the associated BLS keystore. This improvement eradicates the consensus mechanism’s reliance on validator private keys, enhancing operational flexibility and system security.

Optimization of Block Voting Data

Through the utilization of BLS signature technology, validator voting signatures can be aggregated, thereby reducing the voting data within each block. This alteration directly reduces the disk space occupied by each block.

Details of Space Utilization

The following comparison is based on a scenario with 21 validators, each having an equal staking amount (discussing only the data that changed after the rei-dao hard fork):

Before the Hard Fork

Block proposal signature: 65 bytes

Validator voting signature: 65 bytes for each validator, resulting in a disk space range of 910 bytes (minimum) to 1365 bytes (maximum) for 21 validators.

After the Hard Fork

Block proposal signature: 96 bytes

Validator voting data signature aggregation: 96 bytes

Block producer rewards address: 20 bytes

Validator voting bitArray: 3 bytes (minimum) to 4 bytes (maximum)

Therefore, when 21 validators are participating with equal voting power, the per-block disk space savings after the hard fork range from 760 bytes to 1214 bytes.

However, it is worth noting that on the mainnet, due to varying validator voting power and changes in validator count, the actual per-block disk space savings after the hard fork may differ.

In conclusion, the BLS upgrade has significantly improved the efficiency and usability of the blockchain system, providing validators and users with an enhanced experience.

Comparison: the Space Usage of the Validator Before and After the BLS Upgrade was originally published in REI Network Project on Medium, where people are continuing the conversation by highlighting and responding to this story.