Allow ostracon to verify the old r2ishiguro vrf proofs

[0Tech]

Description

This patch would allow ostracon to verify the old r2ishiguro vrf proofs. Basically, it would import:

• the legacy r2ishiguro Verify() and ProofToHash().
• the legacy r2ishiguro prove() INTO the test.

It would also add the routing logic to minimize the changes.
I have checked the patch in finschia in-place migration scenario.

Refer: #633
Closes: #653

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

Merging #652 (4d97976) into main (5a2453e) will increase coverage by 0.02%.
The diff coverage is 82.71%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #652      +/-   ##
==========================================
+ Coverage   66.16%   66.18%   +0.02%     
==========================================
  Files         275      277       +2     
  Lines       36930    37001      +71     
==========================================
+ Hits        24433    24489      +56     
- Misses      10733    10749      +16     
+ Partials     1764     1763       -1     

Impacted Files	Coverage Δ
statesync/stateprovider.go	31.20% <0.00%> (ø)
crypto/ed25519/internal/r2ishiguro/vrf.go	82.35% <82.35%> (ø)
crypto/ed25519/migration.go	83.33% <83.33%> (ø)
crypto/ed25519/ed25519.go	54.16% <100.00%> (+2.77%)	⬆️
state/execution.go	66.58% <100.00%> (ø)
types/validation.go	52.63% <100.00%> (-11.37%)	⬇️

... and 14 files with indirect coverage changes

[ulbqb]

@0Tech
What about using the old ostracon?

[0Tech]

@0Tech What about using the old ostracon?

The new ostracon must be able to verify the old r2ishiguro proof, because the verification is required in the replay of the last block. I have confirmed the replay was required during in-place migration, and the migration failed without this patch.

[ulbqb]

@0Tech
I would like to know where the last block is validated on in-place migration.

[0Tech]

@0Tech I would like to know where the last block is validated on in-place migration.

@ulbqb
Here is the line:

ostracon/consensus/replay.go

Line 418 in 5a2453e

state, err = h.replayBlock(state, storeBlockHeight, proxyApp.Consensus())

[ulbqb]

I am concerned about the following points.

• This implementation means that r2ishiguro keep to be used until validator publish voi vrf.

[0Tech]

I am concerned about the following points.

* [This implementation](https://github.com/Finschia/ostracon/pull/652/files#diff-472d49584a011f21f3257f63be2718a5f462acb603b97be080a37cab81e8e7a9R66) means that r2ishiguro keep to be used until validator publish voi vrf.

That's the point. A node should keep using the old implementation before it applies a block with the new implementation. Also, "good" validators would not create a proof using the old implementation, which means from some point after the upgrade, the proofs would be of the new implementation, voi vrf.

[0Tech]

I've tested in-place migration again at this point.

[ulbqb]

@torao @tnasu
I think libsodium should also be supported. What do you think?

[tnasu]

@ulbqb I don't think so. We know the validator with r2ishiguro on Finschia Network. So this PR is created. But, there is nothing to run the validator with libsodium. I think we don't need to support libsodium at that time.

[Kynea0b]

There was also a bug recently in libsodium. The corresponding costs are not realistic. @ulbqb @tnasu

[ulbqb]

@kokeshiM0chi
Does it mean that migrating from libsodium to voi is very difficult?

[Kynea0b]

It is difficult to manage. Of course, the migration is also difficult. There is no merit to spend the cost here.
Even Algorand's libsodium and libsodium have differences in the border case. @ulbqb

[ulbqb]

It seems better not to support libsodium.

[tnasu]

@ulbqb
As a future correspondence, let's guide spec v3 libsodium as deprecated. Also, libsodium is not compatible between versions, so if there is a node that continues to use something that cannot be upgraded, it will be a problem in the future. r2ishiguro is spec v0, but I believe there is this PR for production Node.
In addition, curve25519-voi is spec v7-v10 and v11+, but it is necessary to keep it in mind carefully including compatibility in future operation.