Question: Extension of CAIP-10 for smart contract and operation hashes?

[jdsika]

The did:pkh method, along with the CAIP-10 specification, could provide a standardized way to represent blockchain addresses, including those for smart contracts and operations. However, the current specifications may not fully cover all use cases, such as Tezos KT1 accounts and operation hashes (or for Ethereum).

Issues with KT1 Accounts and Operation Hashes

1. KT1 Accounts:

   • KT1 addresses on Tezos are originated accounts that can hold smart contracts. They are computed from an origination nonce and are unique to the chain they are created on .
   • The CAIP-10 specification for Tezos primarily focuses on implicit accounts (tz1, tz2, tz3, tz4), which are derived from public key hashes. It does not explicitly define how to handle KT1 addresses, which are derived differently .

2. Operation Hashes:

   • Operation hashes are unique identifiers for operations on the Tezos blockchain, such as transactions or smart contract calls. The CAIP-10 specification does not currently define a standard way to represent these hashes within the did:pkh method .

Potential Solutions

To address these gaps, you could consider the following approaches:

1. Extend CAIP-10:

   • Propose an extension to the CAIP-10 specification that includes a standardized way to represent KT1 addresses and operation hashes. This would involve defining new formats and ensuring they are consistent with the existing specification.

2. Custom URN Schema:

   • Develop a custom URN schema that can represent KT1 addresses and operation hashes in a way that is compatible with the did:pkh method. This schema should be designed to be flexible and extensible to accommodate future changes.

Example Custom URN Schema

Here's an example of how you might define a custom URN schema for Tezos:

• Smart Contracts (KT1 Addresses): urn:tezos:contract:<chain-id>:<kt1-address>
• Operation Hashes: urn:tezos:operation:<chain-id>:<operation-hash>

These URNs would provide a clear and consistent way to identify smart contracts and operations across different Tezos networks.

By addressing these issues, you can create a more comprehensive and standardized way to represent Tezos-specific identifiers within the did:pkh method and CAIP-10 specification.

The question is to extend CAIP-10 and therefore the did:pkh method to better represent Tezos KT1 accounts and operation hashes. However, there are some potential challenges and alternative considerations based on existing standards in Ethereum and other blockchain ecosystems.

1. Existing Standardized Approaches for Identifiers in Ethereum

• Ethereum Smart Contracts:

  • Ethereum smart contract addresses are simply Ethereum addresses (0x prefixed, 160-bit identifiers).
  • They are referenced in transactions, logs, and contract calls without any additional encoding in Ethereum standards.
  • Ethereum Name Service (ENS) provides a human-readable identifier (contract.eth).
  • ERC-681 defines a URI scheme for smart contract calls (ethereum:<address>), but it doesn’t natively handle operation hashes.

• Ethereum Transaction Hashes (Operation Identifiers)

  • Ethereum transaction hashes (operation hashes) are 256-bit Keccak hashes.
  • There is no widely accepted URI format for Ethereum transaction references beyond Etherscan-style URLs.
  • Some projects use ethereum:tx:<tx-hash> informally, but it isn’t standardized.

• Ethereum’s did:pkh Implementation

  • The did:pkh method follows CAIP-10 to represent blockchain accounts as DIDs.
  • The format did:pkh:eip155:1:0xabc123... is used for Ethereum addresses.
  • It does not inherently support contract or transaction hashes, but it could be extended.

2. Challenges with Extending CAIP-10

• Implicit vs. Explicit Accounts

  • CAIP-10 focuses on account-based identities rather than operational or contract-based references.
  • Adding smart contracts (KT1 addresses) into CAIP-10 would require defining whether they are treated as identities or simply as objects referenced by identities.

• Operation Hashes Are Ephemeral

  • Unlike accounts, operation hashes (transaction IDs) are one-time-use identifiers.
  • While CAIP-10 extends to blockchain namespaces, it was not designed for ephemeral, one-time transaction identifiers.
  • This could require a separate DID method or another approach.

3. Potential Alternative Solutions

• Leverage did:pkh for Smart Contracts

  • Extending did:pkh with an optional contract identifier could work.
  • Example:

    did:pkh:tezos:NetXnHfVqm9iesp:KT1PCaD2kmgCHy15wQ1gpqZUy9RLxyBVJdTF
    

  • This follows the existing pattern of did:pkh but includes smart contract addresses.

• Use a Custom did:tezos Method for Operation Hashes

  • Since operations are more akin to ephemeral proofs than persistent identities, a new DID method could be warranted.
  • Example:

    did:tezos:NetXnHfVqm9iesp:oojtGLnHuS8og5WGf8jF8EoxTbegfrXvpxzvyPiW2GYZFGbFLaJ
    

  • This approach isolates transaction references from account-based DIDs.

• Adopt a TZIP-21-Like URI Schema

  • The Tezos ecosystem could define a URI standard similar to TZIP-21 for contracts and operations.
  • Example URNs:

    urn:tezos:contract:NetXnHfVqm9iesp:KT1PCaD2kmgCHy15wQ1gpqZUy9RLxyBVJdTF
    urn:tezos:operation:NetXnHfVqm9iesp:oojtGLnHuS8og5WGf8jF8EoxTbegfrXvpxzvyPiW2GYZFGbFLaJ
    

  • This aligns well with structured metadata and ensures interoperability across different tools.

5. Conclusion

The idea to extend CAIP-10 and did:pkh is logical, but the challenges of handling smart contracts and operation hashes in an identity-based system suggest alternative approaches. Using did:pkh for KT1 addresses and a custom URN (urn:tezos:operation:<chain-id>:<operation-hash>) for transaction references might be the most practical way forward.

Question

What are the thoughts and experiences of the maintainers here?

[bumblefudge]

Hey, sorry I missed this last month. To me the crux of the issue lies here:

Adding smart contracts (KT1 addresses) into CAIP-10 would require defining whether they are treated as identities or simply as objects referenced by identities.

I think the ethereum community is also doing lots of "smart account"/onchain-account design lately, and I may have been too simplistically assuming that existing CAIP-10 usage sufficed, i.e., that an on-chain account (whether a classic EIP-4337 account or some kind of hybrid/smart account) could just be referred to as a CAIP-10 with no need to annotate or differentiate it from an EOA or a hardware-wallet-controlled account. Maybe @chris13524 or @lukaisailovic can comment if they've seen any cases where it feels like dapp developers would NOT want a CAIP-10 to remain opaque, or where a middlebox like the walletconnect network would want to (internally, for logging, etc) annotate a CAIP-10 with some kind of #type=smartAccount query parameter or other decorator.

But you weren't asking if Eth needs this, you were telling us that Tezos already does need this! It is interesting to hear that Tezos has incorporated this distinct, marked accoutn type into the account system. My first instinct is just to update the Tezos namespace's CAIP-10 entry, since it would be good to be able to address kt1 addresses with CAIP-10s ASAP. But maybe you're onto something that this isn't just a Tezos issue? Updating the CASA stuff seems more useful that updating the did:pkh or making new did method, IMHO, although I'll merge the PR there if you'd like to add or edit a tezos example after updating the underlying CASA records here.

I would still encourage you to open an issue on did:tezos, although I'm not sure who maintains that these days-- Spruce's repo seems a little historical and I don't think they're still active in Tezos dev, and the younger GravityID repo also seems a little stale.

[chris13524]

KT1 Accounts: Maybe I'm missing something (not familiar with Tezos), but to me, simply extending the Tezos CAIP-10 profile with an additional kt1 prefix (like the existing tz1-4 prefixes) makes the most sense. Profile is still in draft, so it can be extended with the new address variant. did:pkh always uses CAIP-10 btw.

Operation hashes: CAIP-10 is only for account IDs, not operations or other identifiers. I'd suggest opening a new CAIP for representing operation hashes. Perhaps the format would be very similar to CAIP-10 though? IMO using a did for operation hashes doesn't really make sense. Personally not sure if I need this standard, but I think it makes sense to have and standardize around vs bespoke implementations.

EVM version of the KT1 issue: I haven't seen problems (yet) with needing to represent smart accounts differently in CAIP-10. Usually the on-chain data is just used to tell if an account is an EOA or smart account (eth_getCode).

[bumblefudge]

Yeah, that's how I was leaning too-- let me know if you want any help adding the kt1 stuff to the tezos/caip10 ?

As for operation hashes, I should mention this has been brought up in the past-- I would actually love for there to be a transaction CAIP or even a block CAIP (which would of course have to be profiled heavily for each VM data model). It comes up every once in a while but to date no one has felt strongly enough to actually write the CAIP

[jdsika]

For now I have just created a domain specific urn:schema to address the issue here: https://ascs-ev.github.io/EVES/EVES-007/eves-007.html

I have to check what different Tezos devs think about the introduction of Kt accounts in CAIP-10. Maybe you can raise this topic and associated questions in one of your maintainer calls to gather more input. I think it is kind of interesting considering the strict use of CAIP-10 in did:pkh.

The did:tezos method is not used or maintained anymore. I am just using did:pkh instead.

[bumblefudge]

I think it is kind of interesting considering the strict use of CAIP-10 in did:pkh.

I'm not sure I understand what you mean here, tho. Why not just add |kt1 to the regex in the tezos profile for CAIP-10 and be done with it? i don't understand what "strict" means in this case.