A Proposal for the Ethereum Reality Service
Authors: ccamrobertson, cadillion, ryanouyang, creeefs, digit, pmg, ramicaza
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:
- Sound cryptographic assets rely on chips where the veracity of the manufacturer’s security claims can be evaluated and challenged.
- 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:
- A canonical ENS-style ChipRegistry which resolves chips and the goods they are embedded within to smart contracts.
- Attestations as to the function and nature of chips in ManufacturerRegistry and the creators, projects and companies in TSMRegistry embedding them in objects.
- 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
- Certificate of authenticity for collectable
- Non-transferable NFT embedded within merchandise
- Point-of-sale on every object, connecting buyer to creator
- Bearer instruments, e.g. cash, gift cards
- One time NFT that can be claimed from a concert ticket
- POAP that you met someone from their business card
- Airdrop token from event organizer
- Signature from object at museum
- 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
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.
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.
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: 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.
- 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.
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.
- 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.
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 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 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.
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.