Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

caip: chainproof #218

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

caip: chainproof #218

wants to merge 2 commits into from

Conversation

oed
Copy link
Collaborator

@oed oed commented Mar 4, 2023

@oed
Copy link
Collaborator Author

oed commented Mar 4, 2023

@wyc

@bumblefudge
Copy link
Collaborator

bumblefudge commented Mar 8, 2023

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
Copy link
Collaborator Author

oed commented Mar 18, 2023

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

@wyc
Copy link

wyc commented Mar 18, 2023

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
Copy link
Collaborator

bumblefudge commented Mar 20, 2023

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
Copy link
Collaborator

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
Copy link
Collaborator Author

oed commented Apr 2, 2023

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
Copy link
Collaborator Author

oed commented Apr 9, 2023

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
Copy link
Member

ligi commented Apr 11, 2023

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

@oed
Copy link
Collaborator Author

oed commented Apr 11, 2023 via email

@oed
Copy link
Collaborator Author

oed commented Sep 11, 2023

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
Copy link
Contributor

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

@oed
Copy link
Collaborator Author

oed commented May 27, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants