Draft: IPLD Timestamp Proof

[zachferland]

Create and verify IPLD based blockchain timestamp proofs.

[bumblefudge]

surely there's a codec for filecoin? should i ask CASA's fil rep or in the filecoin open slack?

[bumblefudge]

i also wonder if there's a link worth adding to the references section at the end pointing to info on how FVM means filecoin nodes can connect to a testnet/quorum/etc "out of the box"...

[oed]

@bumblefudge why is filecoin's codec and FVM relevant in particular here? This is a general way of representing a timestamp from any blockchain.

[bumblefudge]

Neither required nor especially relevant, just wondering if a third example would be nice. Since some ipfs gateways are also fil nodes, might be an appealing option for some users since it's one-stop shopping in that case!

[oed]

I'm not familiar enough with Filecoin to say how easy it would be to add an example from there.

[rvagg]

is equivalent to a standard proof

Yeah, if you're willing to deal with the resolution of the intermediates. The approach of just providing a root and a path is fine if you expect the verifier to navigate through the data but the simple form of a Merkle proof provides the intermediate dependent hashes all the way up to the root so you can reconstruct it from just the data you have. You could do that here if you're just going to build a standard Merkle tree where intermediates are tuples of hashes (as you've suggested above) by providing the paired CIDs that couple with the derived CIDs of the leaf you want to prove - so leaf + CIDs of all non-relevant branches on the way up to the root. Then you can reencode those intermediates from the leaf you have and couple it with the provided CIDs to the original Merkle root which, if it matches is the "proof".
But that's not the approach being taken here, which is fine but assumes the availability and navigability of all intermediates. Is that correct?

[zachferland]

yeah roughly but the intention is to not assume anything about the network (ie just IPLD, not IPFS), this just describing the data structure in IPLD and in IPLD a natural way to verify is just to traverse the path. The data could already be local, over another network, or an implementation may not rely on any intermediaries by packing the entire proof and path subset of the tree (all necessary ipld blocks) in a CAR file if they choose. Probably makes sense to change wording a bit (ie resolving) and maybe add a note. thanks for commenting

[chunningham]

I like this proposal, it is simple and directly addresses a common need. I think that it may be preferable to define additional multicodec values for different type of blocks even within a chain, i.e. a codec for eth-raw and a codec for eth-contract, than to use a string discriminant. Although I acknowledge that may be bloat in the codec list and a breaking change to multicodec I think it would simplify the discriminant and prevent certain possible-but-illegal objects (in general I think string discriminant values are prone to accidents). Overall I think this is as appropriately straightforward as is possible.

[oed]

@chunningham Why would using strings be prone to errors? These strings needs to be registered within the Chain namespace for this CAIP. So each string would map to a description of how to interpret it.
If we use multicodec there wouldn't be a canonical place to describe what each code does.

[oed]

For example, I'm planning to register f(bytes32) for the eip155 namespace, which would map to: "The bytes32 param is the multihash of a dag-cbor CID".

[chunningham]

If there's a registry then that's fine, I was kind of thinking that the role of discriminant would be duplicated here between codec and string, but I suppose that the string is more an indicator of which links in the block actually point to/include the root of the merkle tree than of the structure of the block? By 'errors' I meant blocks with e.g. codec is raw but the discriminant says eth-contract then that's allowed but nonsensical, or at least hard to parse correctly.

[bumblefudge]

Todo before merge as Draft (as discussed on today's call):

• Adding language to specify that per-namespace profiles are needed.
• Add an eip155 profile to namespaces/eip155/caip168
• Tell @bumblefudge on discord or here when ground is broken on the sample implementation to bump to Review

[bumblefudge]

NB @benediktwoelk as per our convo last night

[zachferland]

Minor edits made, references to namespace, txType added, and eip155 namespace PR opened - ChainAgnostic/namespaces#42 cc @bumblefudge

[oed]

Also an implementation of validation of this CAIP can be seen here:
https://github.com/ceramicnetwork/js-ceramic/blob/develop/packages/core/src/anchor/ethereum/ethereum-anchor-validator.ts

Should address all of your points above @bumblefudge :)

[bumblefudge]

Hey guys! Sorry for the delay, I did an editorial pass on both CAIP and Namespaces/eip155/CAIP168. I had to open new PRs against Ceramic's fork, so if you merge those two there I'll merge this PR here and we're GTG

Also note: if there's working code that works against this final version of the spec, we can skip draft and go straight to Review 🎉

[zachferland]

editorial pass merged

[bumblefudge]

oh sorry I didn't link this one, also needed: ceramicnetwork/namespaces#1

[zachferland]

thanks, merged the namespace pass as well now