It uses big.Int. See this, this and this.

It does, but it probably doesn't need to if we're willing to lose some precision.

Is there a benefit to losing precision? I do not see it currently

Smaller power table updates. E.g., if I can truncate to the nearest 32GiB, I can save ~4 bytes per entry. I can save 5 bytes per entry if I can limit power increments to 1TiB.

This will also let us limit the number of power table updates (as long as an update wouldn't cross over a 1TiB boundary).

Truncating power is a good design question which has occurred to us, but not been investigated in depth. I'll retitle this issue to reflect that, and add to our meeting agenda.

I think changing the go-f3 representation to big int right now is the safest thing to do. Even if we truncate, we might still want a bigint to future-proof it.

So, goals are are:

1. Small power-table diffs: small power values, fewer power updates.
2. Avoid "rewrite everything" updates to power tables stored, e.g., in bridge smart contracts.

One interesting issue will be, e.g., if power shrinks appreciably. We'd need some way to "add back" precision and probably want some way to avoid constantly changing how we truncate.

If we truncate the power by one byte (divide by 256) each time we reach some threshold, we can:

1. Remove precision in smart contracts by masking power values (avoids expensive state updates).
2. Add precision back by transmitting a single byte-array (least significant bytes for all powers). However, this update will be expensive to process.

I'd like to avoid having any unstable points where it's possible to repeatedly trigger steps 1 & 2, but that's going to require some hysteresis. I guess that's fine?

See also #5 , which will probably resolve this too

For completeness, I looked into scaling power to the range 0x0-0xFFFF based on the total fraction of power. The idea was to avoid "cliffs" where we'd need to suddenly "add back" precision.

Unfortunately:

1. By scaling this way, we get some epochs with > 600 power changes (over the course of 1000 epochs). Not unexpected, but unfortunate.
2. If we don't scale at all, we get 0-4 power changes over that same 1000 epochs.

So I'm going to discount scaling as a possible solution to reducing the size of the deltas, but it may still have a place...

Additionally, given the low frequency of power changes, I'm inclined to discard truncation as well (for now). If necessary, we can smooth out power changes in the Filecoin protocol itself at some later point.

So, current thoughts on scaling/truncation:

1. Represent power changes, new keys, etc. in terms of raw (unscaled, untruncated) power changes. Do NOT commit to these.
2. Commit to a full power table (unscaled/untruncated) for now.
3. Make consensus decisions after scaling all power to the range 0-0xFFFF. Specifically, truncate((0xFFFF * Power)/TotalPower). The cost of scaling power on the fly should be minimal and it'll make some future optimizations possible.

Specifically, I want to scale power for consensus decisions because it'll let us (eventually) commit to a scaled power table which:

1. Will be small (2 bytes per participant). This will make it a good fixed-ish size fallback in case we get large power swings.
2. May work better in zero knowledge proofs (fixed size)?