BLS incompatibility due to non-standard G1/G2 generators

[gupadhyaya]

Summary

Harmony uses herumi bls and mcl libraries for BLS signing the blocks. When these libraries were used, the herumi BLS did not had BLS standardization incorporated. Later when the ETH2.0 specs were made, there was a standardization efforts from multiple projects as noted in this issue. This standardization uses a different G1/G2 generators (or curve base points), when compared to what Harmony is currently using. This has made Harmony's BLS incompatible with other projects (ETH2.0) and libraries (py_ecc, blst, noble_bls12_381). It is important to be compatible with the standard. Especially for cross chain communications. For example, EIP-2537 which is going to be added to Ethereum mainnet is going to support BLS operations natively making it highly efficient. If our BLS signatures are following the standards then our lightclient contract on ethereum can benefit from it, otherwise it is almost impossible to have a gas-efficient lightclient.

Current Design

Current G1 generators:

x = 1490485673189267324327220854985940498515857427639219520252677586669310050426096250529683483057578053845695977302605
y = 1405772507307650904885814159424737301884803741041201599376687588686566229941847930862592328097124042659031385407926

Problems

G1 generators as per standards:

x = 3685416753713387016781088315183077757961620795782546409894578378688607592378376318836054947676345821548104185464507
y = 1339506544944476473020471379941921221584933875938349620426543736416511423956333506472724655353366534992391756441569

Discussion with herumi: issue

Proposal

The proposal is to do a hard fork that requires redoing of all the bls secrets and corresponding public keys. Which means that validators not only have to flush out their old bls secret keys from the signing nodes, but also re-register the new bls public keys for staking. The other major issue with this hard fork is backward compatibility. For any new node syncing the blockchain needs to use old set of libraries (harmony, bls, mcl) to be able to successfully verify signatures in the blocks before this hard fork. Hopefully, the latest upgrades to bls and mcl libraries have a way to make it backwards compatible, in which case, the same set of libraries (harmony, bls, mcl) could be used in two different settings either statically or dynamically to verify previous signatures as well as use the latest standards after the hard fork.