iroha [feature] #4285: Verifiable Random Function in Sumeragi

Description

Adds a crypto primitive and randomization of the topology on block commits.

Linked issue

Closes #4285

Benefits

Checklist

[ ] I've read CONTRIBUTING.md
[ ] I've used the standard signed-off commit format (or will squash just before merging)
[ ] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

Mar 14 '24 22:03 SamHSmith

I'm not sure that i fully understand the purpose of this change.

Since VRFState looks predetermined from the beginning, so peer that submit genesis could manipulate it.

Because it's computed as signature(signature(rand, genesis), leader).

Mar 18 '24 11:03 Erigara

Can you provide any sources you used while implementing this approach?

Mar 18 '24 12:03 Erigara

I'm not sure that i fully understand the purpose of this change.

Since VRFState looks predetermined from the beginning, so peer that submit genesis could manipulate it.

Because it's computed as signature(signature(rand, genesis), leader).

signature(rand, genesis) is in practice random. Because if could be predicted then you could fake signatures. This is the basic verifiable random property. A random number is generated that only the leader can generate. But everyone else can verify the number so the leader cannot tamper with it. This means that the topology evolution cannot be tampered with, but only the leader can know what the next topology will be. This reduces the time for an attacker to coordinate a denial of service attack.

The topology for the next round is known only when a peer receives the block candidate. And nobody is able to predict the topology two blocks ahead. (Unless by random chance the same leader was picked twice.)

Mar 19 '24 23:03 SamHSmith

Also the seed value that the genesis peers submits is completely unimportant. It just needs to be some value. I've thought about @mversic 's suggestion that we should replay topology from the start and not store it on each block. I think it is a good idea and I will make the change in this PR.

Mar 19 '24 23:03 SamHSmith

Afaik for the single pair of payload and private key there is more than one valid signature. For elliptic curve signatures this set is large due to selection of pseudorandom number. So i have a concern that this could be abused by leader to pick itself as leader again. If we consider that signature is in practice random as you said leader will have to try about n (n is total number of peers) different signatures to find the one that allow him to be the leader for the next round.

EDIT: there is some signature schemas like BLS which has unique signature property.

Mar 20 '24 15:03 Erigara

Good point. I will have to investigate that. It might be that I can encrypt the hash with the private key, that way creating a signing scheme that only has one correct answer. This is the behavior I assumed from our signature primitives. Good that you spotted this.

Mar 20 '24 19:03 SamHSmith

Also the seed value that the genesis peers submits is completely unimportant. It just needs to be some value. I've thought about @mversic 's suggestion that we should replay topology from the start and not store it on each block. I think it is a good idea and I will make the change in this PR.

@SamHSmith don't remove commit_topology in the scope of this PR

Mar 25 '24 13:03 mversic

AFAIK using VRFs should provide secrecy property (so it's up to the leader to reveal itself with block proposal and proof of being the leader). Currently i think we don't have such property, because everyone is know what topology for the next round going to look like when they receive the block (window is narrower than knowing topology in advance but still quite large). Byzantine node can even deny such blocks and stay in voting set due to rotation. So i have a question do we need VRFs for doing that?

Mar 29 '24 07:03 Erigara

Pull Request Test Coverage Report for Build 8622562946

Details

159 of 185 (85.95%) changed or added relevant lines in 11 files are covered.
5584 unchanged lines in 96 files lost coverage.
Overall coverage increased (+0.9%) to 57.697%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
core/src/block.rs	33	34	97.06%
config/src/parameters/user.rs	8	10	80.0%
data_model/src/isi.rs	0	2	0.0%
core/test_network/src/lib.rs	0	3	0.0%
core/src/sumeragi/main_loop.rs	18	36	50.0%
<!--	Total:	159	185

Files with Coverage Reduction	New Missed Lines	%
primitives/src/conststr.rs	1	91.14%
crypto/src/hash.rs	1	73.78%
ffi/derive/src/convert.rs	1	84.45%
primitives/src/lib.rs	1	0.0%
core/src/sumeragi/network_topology.rs	1	98.78%
primitives/src/must_use.rs	2	74.29%
crypto/src/signature/bls/mod.rs	2	0.0%
config/src/snapshot.rs	3	78.57%
data_model/derive/src/has_origin.rs	3	95.16%
config/src/kura.rs	3	80.0%
<!--	Total:	5584