implement Flyclient by Benedikt Bunz, Lucianna Kiffer, Loi Luu and Mahdi Zamani's

[tromp]

replacing the prev_hash by the MMR root of all previous block hashes, as presented in
https://www.youtube.com/watch?time_continue=8404&v=BPNs9EVxWrA

[ignopeverell]

To complement, this could have 2 applications:

1. Light clients.
2. Really fast sync, with full headers downloaded in the background afterward.

[ignopeverell]

Marked this for T4 just for the header previous change. Actual sync can come later.

[antiochp]

@tromp @ignopeverell Starting to look a bit closer at this (been thinking about it in the background for a bit as well).

Our current MMRs (output, rangeproofs and kernel) all implement a "data" file and a "hash" file.

Are we thinking of doing something similar here?
Or do we ideally want to try and get away with just a hash file?

We have the block headers in the db/index, so we do not necessarily need a data file?
Or we could put headers in the data file and remove the need to store them all in the db?

The only issue I see with that approach is headers are not a "fixed" size, specifically the PoW.
And our MMR impl assumes/requires data to be of a fixed size.
We get around this with the rangeproof MMR by using a max size - which implies we are "wasting" space in the rangeproof MMR (though not sure how much).

So -

• store just header/pow hashes in the hash file of a modified MMR?, or
• store headers in full MMR and find a solution for variable sized data?

[tromp]

We get around this with the rangeproof MMR by using a max size

I thought bulletproofs are all 674 bytes?
It's of course quite possible that future advances will allow smaller rangeproofs,
so having our MMRs able to handle variable sized data would be beneficial.

For the purpose of verifying accumulated difficulty, we need the sipkeys for each pow.
Assuming we don't want to store those, we need to derive them from the header.

So conceptually, having the data be all headers rather than just all pow is quite attractive.

The header MMR would be the one MMR to rule them all.

[antiochp]

We do this to define the len of a rangeproof in ser.rs -

grin/core/src/ser.rs

Lines 381 to 385 in 11f2d7b

	impl PMMRable for RangeProof {
	fn len() -> usize {
	MAX_PROOF_SIZE + 8
	}
	}

MAX_PROOF_SIZE comes from a const in the underlying rust-secp lib.

I was assuming this was because they are potentially of varying lengths.
Maybe they are technically, but all of our rangeproofs in Grin are the same length?

How much variation is there in the size of pow (solution?) in our headers?
Wondering if we could get away with just defining a MAX_HEADER_SIZE or similar (and just taking the hit on the wasted bytes)?

[tromp]

How much variation is there in the size of pow (solution?) in our headers?

That depends on the choice of 2nd PoW on mainnet obviously, but if we have both
size 29 and size 32 cuckatoo, then there's a 15 bytes difference (between 153 and 168 bytes).

[antiochp]

Actually - its probably not too complex to have a modified PMMRBackend that simply delegates storing of hashes to a "hash file" and storing of the actual data to the database (lmdb).
That way we can store arbitrary data without worrying about the data file format.
We don't actually need the data file backing the PMMR.

To append data to this backend -

• hash the header, store hash in the hash file, note the pos we inserted into
• store the header in the db
• maintain an index in the db of pos (the new pos) to the header hash

We will basically have the existing header_by_height index alongside an additional header_by_pos index. These two indices will be specific to the most work chain.
And all the headers (even outside the most work chain) will be in the db, indexed directly by their hash (same as they are currently).

[tromp]

hash the header, store hash in the hash file, note the pos we inserted into

Note that "hash the header" is already done together with the pos (hash_with_index).

[antiochp]

Yeah - I just mean we need to know the pos to index the header against, based on where we insert the hash into the hash file.

[ignopeverell]

The len() is a leftover from when we had Borromean sigs based range proofs. Maybe some code to remove...? I'm ok with the approach otherwise.

[antiochp]

I carried out some various refactoring to make the header processing (both sync and during block propagation) a bit easier to reason about.

I spiked (a couple of different times) trying to wire a basic "header MMR" into the processing pipeline.
Tried adding this to both the existing txhashset (as a fourth PMMR) and as a standalone txhashset type thing, just for headers.

Each time I came up against roadblocks getting it to work in practice.

Putting down some thoughts here around what I believe to be the complexity here -

Blocks vs. Headers

• We process blocks through either normal propagation via gossip/broadcast or when syncing.
  During normal block propagation a blocks is either increases total work and becomes new head of the chain or exists on a fork.
  • If it is on the head of the chain we do not need to rewind.
  • If it is a fork we rewind our MMRs and apply it as necessary, then discard the rewound MMRs.
• At any given point in time we have one "chain head" (the block with most total work).
• Everything else is a losing fork until such time as any fork increases the total work and becomes the main chain.
• We do not need to track these losing forks other than storing the blocks in the db/index so that we can rewind and reapply to the MMRs as required.
• The input|output|kernel MMRs (on disk) simply track the main chain.

Headers are different though.

• Any peer may advertise a fork with higher total work at any time.
• We do not want to switch over to tracking this new fork until we can verify it is indeed "most work".
  • To facilitate this we track both a "header head" and a "sync head" for headers.
• The "header head" is the header we know to be "most work".
  • This is the chain we are currently tracking.
• During sync we request blocks along the chain toward the "header head" if we do not have them yet.
• The "sync head" allows us to track a potential alternative fork so we can request headers on this fork to verify it.
• Once verified as "most work" we update the "header head", switch to this new chain and request blocks.

The critical point here is we need to support two competing header chains at any given time.
Supporting these with a single header MMR involves either -

1. constant flip-flopping, rewinding and reapplying to a single MMR (which gets prohibitive during sync)
2. choosing a single header fork to track (DoS vector from a mischievous peer lying about competing forks)

So coming to the conclusion that we cannot do a "Header MMR" without actually maintaining two MMRs internally.
Any header received requires us to rebuild (via rewind and reapply if necessary) the full header MMR prior to this.
This would be a lot easier to implement if we maintained a "header head MMR" and a "sync head MMR".

Going to explore this a bit further but I'm pretty sure we cannot do this with a single header MMR.