Skip to content
This repository has been archived by the owner on Jun 6, 2023. It is now read-only.

Randomise partition assignment to equally-full deadlines #432

Open
anorth opened this issue Jun 4, 2020 · 6 comments
Open

Randomise partition assignment to equally-full deadlines #432

anorth opened this issue Jun 4, 2020 · 6 comments
Labels
change-behaviour Changes behaviour or state interpretation, necessitating a network version upgrade enhancement New feature or request P3 Not urgent or important

Comments

@anorth
Copy link
Member

anorth commented Jun 4, 2020

Randomise the assignment of a partition to a new deadline among equally-full candidates. This randomisation should be seeded from chain randomness. We're seeking a really simple pseudo-random shuffle here, it's not first order security-critical. A Fiestel network may work, but is probably way overkill. A simple seeded PRNG that we can implement directly is probably sufficient.

@anorth anorth added enhancement New feature or request P2 Medium priority, beneficial for network functionality and growth changes state labels Jun 4, 2020
@whyrusleeping whyrusleeping added this to the Feature Freeze milestone Jun 11, 2020
@Stebalien
Copy link
Member

I talked with @whyrusleeping about this and he says it's a "nice to have". I'll look into it if there's nothing else of higher priority. I'll look into #266.

@Stebalien
Copy link
Member

Stebalien commented Aug 28, 2020

I'm debating between two options.

  1. Use a simple random offset. That is, assign to random deadline X, then X+1, etc.
  2. Permute the deadlines.

The random offset is nice because it's really simple, and easy to test. However, we could still end up with "runs" of deadlines with partitions. Draft PR: #1054.

The permutation is nice and random, but doing it requires:

  • A random number generator (not something I'd like to write at this point).
  • Repeatedly asking the chain for randomness with different seeds (slow?).
  • Repeatedly asking the chain to hash something (slow?).
  • Stingy use of entropy.

I'm currently going with "stingy use of entropy", but it's a bit nasty. TL;DR: we (theoretically) need log2(48!) = 202 bits of entropy to permute the 48 deadlines. We have 256 bits of entropy. I can squeeze out enough entropy for a Fisher-Yates shuffle by:

  1. Taking 6 bits for each of the first 16 elements.
  2. 5 bits for the next 16 elements.
  3. 4 bits for the next 8 elements.
  4. 3 bits for the next 4 elements.
  5. 2 bits for the next 2 elements.
  6. 1 bit for the final swap.

This takes 225 bits (because I'm not stingy enough to try to use fractional bits).

The question is, is this worth it? Here's the proposed code for this "stingy" permutation algorithm:

func deadlinePermutation(randomness abi.Randomness) [WPoStPeriodDeadlines]int {
	var deadlines [WPoStPeriodDeadlines]int
	for i := range deadlines {
		deadlines[i] = i
	}
	randBits := uint(randomness[0])
	randomness = randomness[1:]
	remaining := 8
	for i := uint(0); i < uint(len(deadlines)-1); i++ {
		reqBits := bits.Len(uint(len(deadlines)) - i - 1)
		rand := uint(0)
		if remaining < reqBits {
			rand = randBits << (reqBits - remaining)
			randBits = uint(randomness[0])
			randomness = randomness[1:]
			reqBits -= remaining
			remaining = 8
		}
		remaining -= reqBits
		rand = randBits & ^((^uint(0)) << reqBits)
		randBits >>= reqBits

		j := rand + i
		deadlines[i], deadlines[j] = deadlines[j], deadlines[i]
	}
	return deadlines
}

Stebalien added a commit that referenced this issue Aug 28, 2020
This commit randomizes deadline assignment by starting to open new partitions

fixes #432
Stebalien added a commit that referenced this issue Aug 28, 2020
This commit randomizes deadline assignment by starting deadline assignment at a
random offset.

fixes #432
@Stebalien
Copy link
Member

(I can probably also implement the above with big.Int for some added sanity)

@Stebalien
Copy link
Member

I talked about this with @nicola, and it's not important for security so we're going to drop it.

@Stebalien Stebalien added P3 Not urgent or important and removed P2 Medium priority, beneficial for network functionality and growth labels Aug 28, 2020
@Stebalien
Copy link
Member

@anorth would you like me to leave this open as a future improvement?

@anorth
Copy link
Member Author

anorth commented Aug 31, 2020

Thanks! I'll re-open and move this to our "later" pipeline so we have your snippet above easily to hand if we decide to do this. I concur it's not important in the near term.

@anorth anorth reopened this Aug 31, 2020
@ZenGround0 ZenGround0 added the change-behaviour Changes behaviour or state interpretation, necessitating a network version upgrade label Oct 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
change-behaviour Changes behaviour or state interpretation, necessitating a network version upgrade enhancement New feature or request P3 Not urgent or important
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants