New CAIP: Chain-Agnostic Resource Locator (CARL)

[UMR1352]

As part of the IOTA's Identity team, I'm implementing many specifications that relies on URI/URLs to reference arbitrary resources hosted "somewhere" - e.g. DID Configuration Resource, Linked VPs, or Bitstring Status Lists. Although these resources can be hosted anywhere we believe in some cases it makes sense to host them on-chain to leverage the security and privacy preserving properties of DLTs.
For this reason, we are trying to define a specification for a URL-like address able to reference arbitrary data stored on IOTA networks. Though, we'd like to make this specification chain-agnostic, as we believe in the values that drive the CASA initiative.

This discussion is meant to explore whether anyone would be interested in adopting or contributing to this new CAIP we are working on and that we'd like to submit. A very sketchy draft will follow, hoping to receive some feedback.

Abstract

This document defines a new Chain Agnostic Improvement Proposal for a Chain Agnostic Resource Locator, outlining a standardized address to reference and retrieve data stored on any public blockchain network.
Building on top of CAIP-2‘s chain ID, this proposal introduces a URL-like address to uniquely locate data stored on-chain, as well as defining a mechanism to dereference this address in order to fetch the referenced data.

Motivation

This specification is motivated by the need to standardize the access and retrieval of on-chain data in a chain-agnostic manner. Currently, the process of accessing data stored on a blockchain is fragmented and highly specific to the underlying network and the smart contract's implementation. This lack of a unified addressing scheme creates significant friction for developers and applications that need to interact with data across multiple chains.

The primary motivations are:

• Lowering the Barrier for Cross-Chain Interoperability: There is no universal standard for reading on-chain data. Developers must possess a deep understanding of each blockchain's unique data structures and communication protocols to build cross-chain applications. This proposal provides a simple, URL-like address that abstracts away these complexities, allowing a single reference to retrieve data from any supported chain. This dramatically lowers the barrier to entry for building interoperable applications.
• Universal Accessibility: On-chain data is often confined to the domain of the smart contract that stores it. This specification aims to make all on-chain data a first-class resource, accessible to both on-chain and off-chain entities. With a single, standardized address, any application or service can easily read the data without needing to understand the intricate workings of the smart contract or the specific blockchain network.
• Simplifying Decentralized Application (dApp) Development: By providing a consistent way to address on-chain resources, developers can write more modular and maintainable code. Instead of building custom adapters for each new chain or contract they interact with, they can leverage a single, standardized mechanism. This simplifies the development process, accelerates innovation, and reduces the potential for errors.

In essence, this specification aims to treat on-chain data like a web resource, making it universally addressable and retrievable, thereby fostering a more integrated and interoperable blockchain ecosystem.

Rationale for a new CAIP

While CAIP-19 provides a standard for identifying tokens across different chains, it is fundamentally limited in scope and does not fulfill the requirements of this specification. A new CAIP is necessary for the following reasons:

• Limited Scope: CAIP-19's primary function is to address well-known token types, such as ERC-20, ERC-721 (NFTs), or their equivalents on other chains. It does not provide a mechanism to address arbitrary on-chain data or custom smart contracts, such as a single variable within a smart contract, the result of a view function, or a specific field within an object. This new CAIP is designed to be a general-purpose standard for any addressable on-chain resource.
• Lack of Dereferencing Semantics: CAIP-19 is a naming standard, not a data retrieval protocol. It defines how to name a token, but it does not specify how to resolve or dereference that name to fetch the token's data, such as its metadata or current owner. This new CAIP, in contrast, includes a crucial section on "Dereferencing," which outlines the core principles and requirements for retrieving the actual on-chain data, making it a complete solution for data access.

In summary, CAIP-19 is a specialized tool for token identification, whereas this new CAIP is a generalized framework for accessing any on-chain data, complete with a standardized approach to retrieval.

Specification

This specification defines a standard for creating a Chain Agnostic Resource Locator that uniquely identifies and references resources on a blockchain. The address format is a URL that combines the standardized CAIP-2 chain ID with a chain-specific resource locator, and optional query and fragment components.

The address for an on-chain resource is a URL with the following structure:

chain-id / resource-locator

• chain-id: This part of the address follows the CAIP-2 standard and serves as the base for identifying the target blockchain network.
• resource-locator: This part of the address is a variable-length string that is specific to the blockchain identified by the chain-id. It is defined by the implementers for each network and dictates the syntax as well as the semantics for locating a specific resource.

Implementers can make use of both query and fragment URL components as long as they don’t conflict with the standardized query and fragment values of this specification.
The complete address MUST be a valid URL.

Examples

# Fetch object `0x84cf5`d12de2f9731a89bb519bc0c982a941b319a33abefdd5ed2054ad931de08` on IOTA mainnet.
iota:mainnet/0x84cf5d12de2f9731a89bb519bc0c982a941b319a33abefdd5ed2054ad931de08
# Fetch property `did_document` of object `0x84cf5`d12de2f9731a89bb519bc0c982a941b319a33abefdd5ed2054ad931de08` on IOTA mainnet.
iota:mainnet/0x84cf5d12de2f9731a89bb519bc0c982a941b319a33abefdd5ed2054ad931de08/did_document
 
# On Ethereum mainnet invoke function `isRevoked` of contract at address
# `0x534b89b798e45929A24a217d7325EAd0EAF9431` with arguments:
# - `0x325EAd0EAF9431534b89b798e45929A24a217d7`
# - `0x3458b9bfc7963978b7d40ef225177c45193c2889902357db3b043a4e319a9628`
# - `0x89343794d2fb7dd5d0fba9593a4bb13beaff93a61577029176d0117b0c53b8e6`
eip155:1/0x534b89b798e45929A24a217d7325EAd0EAF9431/isRevoked?args=0x325EAd0EAF9431534b89b798e45929A24a217d7,0x3458b9bfc7963978b7d40ef225177c45193c2889902357db3b043a4e319a9628,0x89343794d2fb7dd5d0fba9593a4bb13beaff93a61577029176d0117b0c53b8e6