Remove Message union, specifying SignedMessage or UnsignedMessage explicitly.

[anorth]

The deleted file was empty.

The reformat is from gofmt.

[jzimmerman]

See inline question re: the Block struct -- I agree that in general we should use SignedMessage or UnsignedMessage rather than the union, whenever possible, but am not sure this is possible everywhere.

[jzimmerman]

Does this match with what we expect on-chain? My impression was that the Block struct was the motivation for the union -- i.e., some of the messages are BLS signed and appear as UnsignedMessages in the list (with the signature aggregated), while some are Secp signed and appear as SignedMessages.

[anorth]

The Block type does not go on chain at all. This is an internal implementation detail that's in the spec only because we're trying to write implementation code in it.

But ok, I've added SECPMessages and BLSMessages separately, which is closer to what an implementation might actually use.

[jzimmerman]

This particular definition of the Block struct may not go on-chain, but some version of it must. In particular, the MessageRoot and ReceiptRoot fields in BlockHeader are currently uninterpreted CIDs, which really should be modified to refer to the actual underlying algebraic datatype (respectively, [Message] and [MessageReceipt]). Then the question becomes what to do with that [Message].

In principle we could replace it with two separate arrays as you've done with SECPMessages and BLSMessages, but then we would lose the ordering of messages within the block (i.e., either all BLS messages must hit the VM before all Secp messages, or vice versa). This seems potentially problematic, and the on-chain union type a cleaner solution.

[anorth]

yes, they must be replaced with two different arrays, the spec already had that at one point and both implementations do it.

[anorth]

Edit: the spec already has that in the other BlockHeader definition (tho it's also wrong for different reasons). I intend to clean those up as part of block validation, for which this is pre-work.

[jzimmerman]

OK, sounds good.

[anorth]

FYI @jzimmerman I separated BLS and SECP messages in the interpreter's BlockMessages input structure, to aid your measuring their weight in #685