[release-v2.0] main: Use backported mixing updates. #3391
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The buffers written to during signature creation and validation have a known constant size. Preallocate these buffers to reduce the total number of allocations that are needed as fmt.Sprintf writes to the buffer.
The number of expected messages can be determined by the capacity of the intended message type's slice.
This updates the mixing module to use dcrd/crypto/rand for key and uniform random big integer generation.
Runs are always required to be zero now.
This significantly reduces the number of allocations needed to create a vector of exponential DC-net pads by reusing a digest slice prior to converting the result to a big integer. Specifically, it reduces the allocations for the digest calculation from quadratic in the number of participants to a single alloc. The big integers themselves are still predominantly linear in the number of participants, however, that they are not entirely linear because the big ints involve multiple allocations as the numbers grow larger prior to the modular reduction. For a concrete example, with 15 participants, the total number of overall allocations with this change is reduced from 257 down to 47.
This adds a cache to house mix messages that have recently been removed from the mixpool. It makes use of the new container/lru module to handle automatic expiration of entries and maximum entry limiting. The rationale for this change is that it is considered misbehavior to advertise a mix message and then claim it is not found when the corresponding request arrives. Maintaining a separate cache of mix messages recently removed from the mixpool for a short period of time significantly increases the probability they are available to serve when a request for the advertisement arrives independent of the current status of the mixpool.
In this change, random per-peer (per-identity) and per-message jitter are added to add additional delay to all message broadcasts. The jitter delay will range from 0-3s, with a random 0-2700ms of that being per-peer and 0-300ms being per-message. The total delay is calculated as 1/10 of the stage timeout duration, and the per-message delay is calculated is both the mean and median of dcrd's inventory trickling delay. While here, pair request messages are also submitted to the network with random delays spanning over the entire epoch duration, while avoiding any PR sends during the 30s before and after the epoch.
This updates the 2.0 release branch to use the latest version of the mixing module which includes updates to improve sender privacy through the use of randomized broadcasts and increase performance. In particular, the following updated module version is used: - github.com/decred/dcrd/mixing@v0.4.0
davecgh
force-pushed
the
rel20_mixing_backports
branch
from
e2ddc52
to
70cd1bf
Compare
jrick
approved these changes
Jun 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates the 2.0 release branch to use the latest version of the
mixingmodule which includes updates to improve sender privacy through the use of randomized broadcasts and increase performance.In particular, the following updated module version is used:
Note that it also cherry picks all of the commits included in updates to the
mixingmodule to ensure they are also included in the release branch even though it is not strictly necessary sincego.modhas been updated to require the new release and thus will pull in the new code. However, from past experience, not having code backported to modules available in the release branch too leads to headaches for devs building from source in their local workspace with overrides such as those ingo.work.