A Proposal for the Ethereum Reality Service

A Proposal for the Ethereum Reality Service

Authors: ccamrobertson, cadillion, ryanouyang, creeefs, digit, pmg, ramicaza

Motivation

Linking physical or “real world” assets with blockchain assets has been a long time goal of various protocols and projects, yet a standardized implementation remains elusive. Successfully doing so would have significant ramifications, unlocking significant collateral for on-chain purposes and enabling novel kinds of property with simultaneous virtual and physical identities.

There are two primary approaches to bringing real world assets onto the blockchain: oracles that leverage pre-existing contract law in traditional jurisdictions, and embedded or derived cryptographic identities from which a thing can assert itself on-chain.

For large and immovable assets oracles will likely remain the most optimal solution for bringing deeds of ownership on chain. Conversely, for high value, movable assets, embedded cryptographic identities can reduce or eliminate oracle risk while creating truly bearer objects that can authenticate themselves on-chain. Through projects like KONG Cash we have demonstrated that the latter is possible using low-cost hardware which can readily sign data on request by a smartphone or NFC-enabled computer.

Since the release of KONG Cash we have begun work to generalize the technology from KONG Cash such that any ‘crypto’ asset or token can be associated with a chip, for example a piece of merchandise, canvas, toy figurine or 3D printed sculpture. There are two important considerations that have arisen from this process:

  1. Sound cryptographic assets rely on chips where the veracity of the manufacturer’s security claims can be evaluated and challenged.
  2. Resolution from a given chip to a smart contract should be generalized so that anyone interacting with a physical crypto asset understands how and what on-chain claims or attestations exist.

We propose the Ethereum Reality Service (ERS) as a public good open to chip manufacturers, creators and their end users to resolve these challenges. The Ethereum Reality Service consists of:

  1. A canonical ENS-style ChipRegistry which resolves chips and the goods they are embedded within to smart contracts.
  2. Attestations as to the function and nature of chips in ManufacturerRegistry and the creators, projects and companies in TSMRegistry embedding them in objects.
  3. A set of well known object-capability (OCAP) schemas whereby smart contract developers indicate what kinds of claims and functions are possible against chips in ChipResolvers.

Example Use Cases

  • Soulbound
    • Certificate of authenticity for collectable
    • Non-transferable NFT embedded within merchandise
    • Point-of-sale on every object, connecting buyer to creator
  • Escrow
    • Bearer instruments, e.g. cash, gift cards
    • One time NFT that can be claimed from a concert ticket
  • Mint
    • POAP that you met someone from their business card
    • Airdrop token from event organizer
    • Signature from object at museum
  • Permissions
    • Off-chain DID controller
    • Payment rail replacement with multisig
    • Access control to a coworking space
    • Prove you own a rare NFT without having to sign from cold wallet
    • Toy which can sign messages in virtual gameplay

Design Philosophy

ERS anticipates the fact that chips are typically mass manufactured and bulk enrolled by service managers. It also presumes a one-way process whereby instantiating a physical object into the real world is an irrevocable fact. Unlike an ENS name where the only notable fact is the name itself, the facts that a chip is created by a manufacturer and is embedded into an object are important to preserve in the registry.

Similar to ENS, ERS divides resolution into two components: a registry which records the existence of a chip and what is embedded in (through linked manufacturer and TSM registry data) and a resolver where content and escrow contracts may be set.

Additionally the registry contains attestation information about the chip. These attestations are intended to be EIP712 signatures generated by manufacturers and TSMs who enroll chips.

Registry

ChipRegistry.sol

The chip registry is a canonical entry point for resolving chips to smart contracts. Once chips are enrolled in the registry by a manufacturer, a trusted service manager may in turn link those chip records to assets or capabilities for end users to claim, deposit or execute. Chip records are immutable upon creation.

  • chipId: a keccak256 identifier for the chip.
  • chipModel: a chip model referenced in ManufacturerRegistry.sol
  • chipContent: a set of content [e.g. hoodie, NFT] created by trusted service manager (TSM) referenced in TSMRegistry.sol. This content is unique from subsequent records in any associated chipResolver in that it presumes a static nature of the object that the chip is embedded within, e.g. a membership card, garment, figurine, etc.
  • manufacturerCertificate: an IPFS cid referencing the manufacturer’s attestation of the chip [off-chain signature]
  • tsmCertificate: an IPFS cid referencing the TSM’s attestation of the chip [off-chain signature]
  • chipResolver: the address of the chip’s associated resolver contract.
  • owner: the address of the chip’s current owner. The owner transitions from manufacturer to TSM to end user. The end user cannot modify facts about the chip such as the chipModel or chipContent, but they can modify the chipResolver and in turn associated records.

ManufacturerRegistry.sol

Stores information about chips including the manufacturer, cryptographic properties and any stakes deposited with respect to claims about the cryptographic properties of the chip.

There are two entities in the ManufacturerRegistry: manufacturers and chipModels.A manufacturer is capable of instantiating one or more chipModels in the registry. They must include their public key used for chip attestations and model information from each chip. They may include an economic stake tied to a given model of chip which implies the strength of the security guarantees of the chip.

Manufacturer:

  • manufacturer: address of the public key of the signing manufacturer which is used to create manufacturerCertificates.
  • manufacturerDomain: ENS-encoded name for the manufacturer; if not set, ENS name from address, where available, is used to name the manufacturer instead.

ChipModel:

  • model [bytes32?]: bytes indicating the model of a given chip, e.g. a keccak256 hash of the model name.
  • ellipticCurve [bytes32?]: a byte indicating the ellipticCurve which the chip uses to generate signatures.
  • stakeContract address: associated stake with that model of chip.
  • bootloaderApp bytes32: IPFS resource that can resolve a chip on tap. At a minimum the resource is an or script capable of looking up a chip against the registry.
  • verifyUrl string: optional; used in the case where a chip requires an external gateway for verification. If set, stakeContract is disallowed.

TSMRegistry.sol

Trusted service managers are the primary parties that enroll chips with assets and capabilities. They include brands, integrators and creators. TSMRegistry.sol has a similar structure to the manufacturer registry except that it is aware of chip content rather than chip models.

Trusted Service Manager:

  • tsm: address of the public key of the signing manufacturer
  • tsmDomain: ENS-encoded name for the manufacturer; if not set, ENS name from address, where available, is used to name the manufacturer instead.

ChipContent:

  • contentApp: IPFS resource of the dapp capable of executing the capabilities indicated by the tsm. When enrolled, this app takes precedence over the manufacturer’s bootloaderApp. This resource is typically one that browsers can interpret information from a given chip via a protocol like NFC, however, it may instead redirect to other apps which have the capability of scanning chips. A contentApp is presumed to be capable of resolving the records from an associated chipResolver. At a minimum the resource is an or script capable of looking up a chip against the registry.
  • stakeContract: address of contract associated stake with the TSM chipApp.

Each chip may have a single primary TSM and multiple secondary TSMs.The primary TSM is always the first one that the chip registry resolves, notably in the case of the tsmApp, however, dapps or wallets may wish to enumerate all the tsmApps and linkedContracts associated with a given chip.

ERC721 Representation

Similar to ENS, the registry may offer an interface such that chips may be represented as ERC721 compatible NFTs by the registry where the tokenId would consist of the chipId and the tokenUri would map to the contentApp. These NFTs would be non-transferable from the perspective of anyone interacting with them, but they could take on other information such as conveying the recorded current owner.

Chip Resolver

ChipResolver.sol

Chip resolvers contain records that relate to the ultimate claims or content that a chip may be linked to. Similar to ENS resolvers, chip resolvers may allow for various record types such as text content, video content or linked smart contracts with escrow functions. While chip resolvers can be fully custom, they need to be able to at a minimum resolve a chipId to a set of records.

  • tokenId: NFT ID for a token associated with the chip distinct from the chipId, for instance Dope Wars Gear NFT #1337.
  • escrowContract: an address which contains an ERC20 token that can be claimed by the chip holder, such as a KONG Cash note containing 50 $KONG token.
  • ipfsCid: the IPFS cid of content relating to the chip.

Chip Certificates

Chip certificates are created by manufacturers and TSMs in order to attest to the manufacture and enrollment of chips. Chip certificates can be stored off-chain and referenced on chain where an interface may interpret the certificates via EIP712.

Chip certificates allow for the creation of chipResolvers which do not need to be explicitly aware of every individual chip in a registry in order to execute an action such as issuing an NFT or airdrop. They also allow for portability of chip attestations easily across various L2s.

Chip Requirements

All chips in the ERS should be representable as a cryptographic identity. This should, ideally, be via the direct creation of keccak256 signatures that can immediately and cheaply be verified on chain.

Given the mixed availability of secure chips, ERS will also accommodate the enrollment of chips that can create signatures based on curves other than secp256k1 and will allow for chips where a manufacturer provides an oracle that can generate signatures on behalf of a chip through an independent authentication mechanism. This could also accommodate other identifiers which are derived from something inherent to an object through characterization.This might be encoded into a field relating to a cryptography contract capable of resolving a given curve or authentication scheme.

Any chips that cannot independently be verified without an oracle will not be eligible for staking as the veracity of their cryptographic identities is not based on the functions of the chips but rather a counterparty and their proprietary process.

ERS is agnostic with respect to the communications protocol used to interact with a given chip. Currently many offerings are NFC, however, it’s also possible to envision QR codes, Bluetooth or USB serving the same purpose.

7 Likes

Awesome first draft here @ccamrobertson, glad to have been able to workshop this with you!

I would also like to propose a potential implementation where TSM stakes occur on the TSM registry instead of the individual chip level. This has a few benefits:

  • A TSM doesn’t have to submit a stake for each chip which can become prohibitively expensive from gas costs alone
  • A challenger can be rewarded with a larger stake if they are the first to find that a chip has been cheated of the content that was originally bonded, or other scaling dynamics can be introduced to incense early challengers where fraud is suspected
  • If a chip’s content is shown to be fraudulent, the TSM registry will show this fraudulent activity instead of merely the cheated chip

Additionally, while this is a fabulous proposal for a basic implementation that satisfies immediate requirements, I think there is some worthwhile discussion about the long-term future of such an implementation, where the permissionless nature of establishing a manufacturer or TSM allows malicious actors to intercept signatures, present fraudulent validity interfaces, and redirect to non-standard contracts. However, others may disagree and believe that this discussion is better scoped for a separate proposal, or better left to the discretion of the end-user.

Since the scheme is vulnerable to all kinds of man-in-the-middle attacks and supply chain attacks where intermediate Trusted Execution Environments (TEEs) are involved, it’s important to identify where each device’s object capabilities (OCAPs) and permissions should be stored. Take for example the following supply chain: Manufacturer > Distributor > TSM > Deliverer > End-User > Scanner TEE > Interface TEE > RPC TEE > Network TEE > Smart Contract TEE:

  • What sorts of OCAPs should the TSM be given vs the End-User?
    • Where are these OCAPs configured by the TSM?
  • How do we ensure that devices of multiple specifications, capabilities, and guarantees can customize the resolvers for their particular set of guarantees?
    • Does this look like an OCAP contract field that specifies alternative OCAP sets, or do we delegate that out to the TSM sub-contracts?
  • How do we validate that to the end-user that they are being presented with a valid TEE that is connecting to the canonical registry?

Just some food for thought.

3 Likes

I would also like to propose a potential implementation where TSM stakes occur on the TSM registry instead of the individual chip level.

Yeah, I think that this is an interesting point for discussion – right now it’s envisioned that stakes occur at a ‘content’ level for a TSM. The idea here is that one brand will issue many batches of chips and that they will likely want to create different dapps relating to those chips, potentially even on behalf of other parties. But I agree that it might also be a bit unruly having the individual stakes here.

Since the scheme is vulnerable to all kinds of man-in-the-middle attacks and supply chain attacks where intermediate Trusted Execution Environments (TEEs) are involved, it’s important to identify where each device’s object capabilities (OCAPs) and permissions should be stored. Take for example the following supply chain: Manufacturer > Distributor > TSM > Deliverer > End-User > Scanner TEE > Interface TEE > RPC TEE > Network TEE > Smart Contract TEE:

Maybe this could be a minimum requirement on a resolver interface whereby it must specify the intended OCAPs?

2 Likes