Decide whether Tipset should include the state root CID

[anorth]

The tipset payload in GossipPBFT messages implies a state root, given access to the full block headers comprising that tipset. But in order to be directly useful to light clients without also syncing the EC block headers, it should include the state root CID directly. Evaluate this trade-off.

[anorth]

The messages root, receipt root, events root would also be really useful for cross-chain things.

[Kubuxu]

This fits my mental model that F3 has a State that is visible when syncing the F3 (currently the state includes Power Table and Keys).

[anorth]

@Kubuxu and I had a long chat about the various values that would be useful to different clients, and the tradeoffs between putting them inline in the ECTipset struct, or putting instead a commitment to those values. We'd like it to be upgradeable to add new things in the future, but putting lots of values immediately inline will add bandwidth cost to Granite.

We've tentatively resolved to include an empty byte array as a placeholder initially. We can design an encoding/commitment scheme for data to put here later. Populating it will require a network upgrade of F3, but should not break any passive consumers/verifiers of finality, including smart contracts on other chains. (It is clients of those smart contracts that may interpret the bytes one day).

[anorth]

Should we include a CID of the f3 state root? Including the representation of the power table? For checking that state computations from finality certificates are correct.

See also #5

[Stebalien]

... state root ...

I guess the question is: Is this the state-root after the tipset is executed, or the tipset's parent? If we're doing eager execution, it's more than just "convenient". If not, I don't really see the issue in asking the user to fetch the first block header in the tipset to retrieve the desired information.

In terms of how to reference it.... Personally, I'd use a CID given that this data is optional, and include everything that would be included in the next tipset.

Should we include a CID of the f3 state root?

I think this also makes it possible to bootstrap without fetching the entire f3 chain (assuming you're willing to start at some trusted point).

[anorth]

The answer to this is "not for now". We will however include an accessory commitment to a simple merkle tree under which we could nest a commitment to the state root in a future iteration of the protocol. See #150 . cc @Stebalien