Remove BLS functionality from the mainstream

[torao]

Description

This PR removes the BLS functionality from the Ostracon mainstream.

Problem settings

There are unresolved issues with signature aggregation in the current Tendermint design. Ostracon has struggled with this issue for a long time, but to improve source compatibility with Tendermint v0.34.19, we are removing support for the BLS key and its signature aggregation until a plan can be developed to avoid this issue.

The followings are a summary of the problems with applying BLS and other signature aggregation algorithm to Ostracon (and Tendermint).

1. The light clients can recognize a block as correct if 2/3+ signature verification pass, even if some of the Validator's public keys are missing. However, for aggregated signatures, the public keys of all Validators are required, and if even one is missing, the verification cannot be achieved. Therefore, each light client must always have the public keys of all Validators, but the current light client of Tendermint isn't designed with such as assumption.
2. BLS signature aggregation can reduce the space complexity of the signature from $O(n)$ to $O(1)$, where $n$ is the number of Voters. However, it takes about 10 times longer than ed25519 to generate and verify the BLS signature respectively and the computational complexity remains $O(n)$ unless used in conjunction with public key aggregation.

Changes

This PR removes the BLS functionality from Ostracon and the same time indicates where Tendermint needs to be modified to support signature aggregation and different key algorithms on the same blockchain instance.

The following external interfaces are affected by this change.

• [cli] The option --priv_key_type has been removed from all ostracon subcommands such as init.
• [protobuf] CompositePubKey type and Commit.aggregated_signature field are removed.

More internally, the following relevant codes are removed or changed.

• Structure definition of BLS key and composite key.
• Fields and procedures related to BLS signature aggregation in struct and ProtocolBuffers.
• Identifiers used to identify the type of key.
• Size or hash value of the structure being tested.
• A few trivial fixes, comments, imports, and docs.

The following points are helpful when reintroducing the BLS signature algorithms or other ones.

• To clarify the identification of the algorithm, we should add the name of the curve to the identifier, e.g., BLS12-381 or bls12381.
• The word composite is the name of the structure for the synthetic key and not the name of the signature algorithm. Thus, the name of structure CompositeKey is fine, but the composite specified in the command-line option should be changed to an algorithm name such as bls.
• It should be tested to work correctly with any key algorithm. However, since it's not practical to verify all key algorithm variations in every unit-test case at this time, it's better to specify the target key algorithm when unit tests are run and ensure that all tests work with that default key.

Closes: #XXX

[codecov]

Codecov Report

Merging #541 (7ccf0fb) into main (220fd05) will decrease coverage by 0.05%.
The diff coverage is 80.32%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #541      +/-   ##
==========================================
- Coverage   66.30%   66.24%   -0.06%     
==========================================
  Files         281      279       -2     
  Lines       38170    37593     -577     
==========================================
- Hits        25307    24904     -403     
+ Misses      11053    10920     -133     
+ Partials     1810     1769      -41     

Impacted Files	Coverage Δ
abci/example/kvstore/persistent_kvstore.go	50.00% <ø> (-1.99%)	⬇️
cmd/ostracon/commands/gen_validator.go	0.00% <0.00%> (-30.00%)	⬇️
cmd/ostracon/commands/testnet.go	18.37% <ø> (-0.78%)	⬇️
config/config.go	78.64% <ø> (+0.27%)	⬆️
config/toml.go	74.19% <ø> (ø)
crypto/ed25519/ed25519.go	46.34% <ø> (+1.21%)	⬆️
crypto/encoding/codec.go	47.61% <ø> (-10.16%)	⬇️
state/execution.go	67.46% <0.00%> (ø)
types/protobuf.go	81.70% <ø> (ø)
types/vote.go	89.31% <ø> (+0.79%)	⬆️
... and 38 more

[tnasu]

I think the PR of #335 also needs to revert. The others look good to me.

[torao]

I'm reverting to the draft because Ostracon documents also need to be corrected.

[torao]

@tnasu
From the looks of #335, most of the fixes made to BLS and CompositeKey in it have already been removed. Do I need to make any additional fixes to the BLS, CompositeKey, or signature aggregation?

[Kynea0b]

LGTM