snarkOS
snarkOS copied to clipboard
AleoNet
Round quorum before advancement
Motivation
Closes https://github.com/AleoHQ/snarkOS/issues/2876
Open questions
- we can consider merging
AddressWithCoordinate<N>upstream into snarkVM
Performance
In the tradition of Lukasz brilliance, I'm using Vecs+BinarySearch instead of maps.
In this repo you can find some benchmarks of different constructions. If we don't check quorum, we can do 250 updates per millisecond, if we do check quorum each time because we get increased round numbers, we can do 9 updates per millisecond. I expect on average an update will cost closer to 1/250 milliseconds. Moreover, an update will only be done if any peer actually sends a very high round number.
Also note that currently computing quorum requires us to collect into a HashSet, we could add a version which just uses an iterator (checking along the way if all elements are unique).
Persistence
I'm not storing the cache in the database, we should expect to receive a quorum's worth of updates from other nodes every round.
Nice benches, I'm almost surprised BTreeMap wasn't the fastest with multiple inserts.
Do we usually run all ignore = tests manually, if so how?
Most ignored e2e tests are long running (e.g. manual testing) or are too costly to perform on CI. We run them locally from time to time as a sanity check but ideally, our coverage should be complete with regular tests.
@vicsn in light of major code drift from testnet3, can you rebase this PR onto mainnet-staging and test this PR on a network to confirm its validity/necessity?
Yes, will coordinate and help Michel to first get this related issue over the finish line to see if it resolves the attack: https://github.com/AleoHQ/snarkOS/pull/3119
Deprecating this in favour of https://github.com/AleoHQ/snarkOS/pull/3119 - which has been tested and works