caip: chainproof

[oed]

📃Preview

[oed]

@wyc

[bumblefudge]

This is very interesting! The one thing that this spec makes me wonder about is the precision and universality of block-, transaction- and non-asset-contract- addressing. it feels to me from the diagram provided for the EVM profile that there is a {namespace}:{blockId}:{txnID}:{code/storageslot/etc} URN implicit here... that we could maybe make explicit first. Lord knows people have been proposing their use-cases (linked above) for this URN anyways!

1.) Having been mulling on this for months, I think we probably need two new CAIPs, that chainProofs could extend/require:

• {namespace}:{blockId}:{txnID}{:XOR?}XXX where XXX is an optional (and namespace-specific) syntax for code, storage addressing (including arbitrary transaction "memo" strings, mentioned in the issues above), etc.
  and
• {namespace}:{blockId}{:XOR?}XXX - because blocks themselves have a lot of metadata. this might extend Ligi's block-explorer uniform routing CAIP, since obviously what metadata each block has is extremely namespace-specific.

2.) I say : XOR ? because some masochistic part of me still wants that query parameter chaos in the mix.

3.) And let's just name one elephant in the room: maybe the Ordinals people would be interested in the above. There hasn't been a ton of interest from the BTC family tree so far, this might be a good opportunity for outreach to them!

[oed]

For EVM debug_traceCall will likely be useful when trying to find the appropriate storage slots.

[wyc]

I think txid-based addressing could be useful, but we don't need it to prove NFT ownership on Ethereum for example, so I'm not sure it should be a requirement. It could be useful if you wanted to prove that a particular transaction was included in a specific block or something like that, but you could alternatively define what that means in the EVM profile without a new namespace at CASA. Also, how would you refer to blocks and transactions with graph-based ledgers?

[bumblefudge]

we don't need it to prove NFT ownership on Ethereum for example, so I'm not sure it should be a requirement.

Right, EVM and ERC721 make it pretty easy/standardized to navigate to the storage from the contract address. My question was whether this would be more extensible if there were a CAIP-constrained string that encoded that same navigation for non-EVM contracts/environments. Didn't mean to imply it was a gating requirement! At most a stitch-in-time situation, but more likely me overthinking :D

how would you refer to blocks and transactions with graph-based ledgers?

I'm no expert but most of the DAGs I've looked at have something pretty similar to transactions, it's more the "block"-addressing that would break down (although most DAGs have some form of supernode/milestone/checkpoint/etc). I'm actually working on these two CAIPs today, so maybe it'll be less annoying to discuss with a strawman to point to, but we definitely shouldn't bake the assumption of blocks into the syntax for transactions, since basically everything we want a namespace for has transaction-queryable state... I've crossed "block" out of the micro-strawman above!

[bumblefudge]

FWIW I threw up two strawmen, but it's probably not worth looking at until the attestation-use-case folks have had a look, they might well bring breaking changes or a complete rethink.

[oed]

Updated the PR with an example chainproof for the ownership of an ENS name. See the CAR file in the assets folder.

It doesn't yet use multidid for the iss/aud, other than that I think it should be a fully compliant NFT chainproof.

Created using this script: https://gist.github.com/oed/a590fe2932099310bcbf922d1d25b646

Oh, and the script also shows you how to verify a chainproof using a javascript implementation of the EVM.

[oed]

A note on size:
The ChainProof above for proving ENS name ownership is actually quite big (21 kB). For more complicated proofs size will be even larger. To make ChainProofs more usable it might actually be worth it to compress them using ZKPs. Experimentation needed!

[ligi]

I wonder if this needs a concept of "at certain block height"
Also would love to see some more use-case examples.

[oed]

In the example I provided above the block height is included since the block header is included in the proof! Joel Thorstensson Co-founder, 3Box Labs [image: 3Box Labs] <https://3boxlabs.com>

…

On Tue, Apr 11 2023 at 2:45 PM, ligi ***@***.***> wrote: I wonder if this needs a concept of "at certain block height" Also would love to see some more use-case examples. — Reply to this email directly, view it on GitHub <#218 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA52ONOKWQLX62P5OKEB6WTXAVN73ANCNFSM6AAAAAAVPXAJQM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[oed]

Great news, after a conversation with Richard Meissner of Safe it turns out that there's an easy way to get all storage slots associated with an eth_call.

The method is called eth_createAccessList and returns all the storage slots across all contracts that were accessed by a specific call.

This is all information we need to be able to construct a ChainProof for any EVM smart contract call!

[obstropolos]

@oed - doing some quick housekeeping - where did this end up?

[oed]

@obstropolos It hasn't really gone anywhere. Would still like to keep this around for future reference though!