A Proposal for the Ethereum Reality Service

[ccamrobertson]

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.

[cadillion]

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.

[ccamrobertson]

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?

[leeren]

Amazing job @ccamrobertson! I truly believe this is the best approach to building the future bridge between physical & digital worlds, and cannot wait to integrate with ERS.

A few questions:

• What is the process by which chipId is generated for a registered chip? I’m assuming the public key coordinates are stored in the secure chip element, so would this be something like the last X bytes of the keccak256 hash of the public key?

• For the registry, could you elaborate on what it means for chip records to be immutable on creation? Besides the case of chipId, which would likely be generated deterministically, there may be good reasons to have other attributes modifiable. For example, having an expiration date for the TSM / manufacturer cert, or updating the chipContent to another application domain due to faulty configuration. Either way, I think it would be a good idea to allow these fields to be capable of being made immutable, just not necessarily from the get-go. Thoughts?

• What is the reason for including chipContent in the registry? In cases where resolver records are dynamic, enforcing a static nature for the chip content itself here might make it hard to ensure semantic consistency between the chip content and its resolved contract records down the line. Instead, why not just have the option of making the chipResolver immutable, and aggregating all content there?

• Is the intention of the bootloaderApp IPFS resource included in the manufacturer registry ChipModel to point a manufacturer’s chip to its registered TSM application logic (contentApp)? Is it correct then that the chips themselves would have to point to this domain initially? How can this be proven publicly, given that initial translation I’d assume is done at the firmware level? Also, I personally think redirectApp might be a more logical name.

• To add on to the prior question, how do you envision the process by which the TSM contentApp supersedes the bootloaderApp? Would there be an interface by which TSMs can mass enroll their new contentApp? Or would this be as simple as having the bootloaderApp always resolve to the contentApp in the case that the chips’ TSM registry record is defined. In either case, it seems like the bootloaderApp wouldn’t be replaced per se, but just used to redirect in different ways?

• For the project I’m building, using the Chip Resolver as an NFT itself seems like a very appealing model. This would especially simplify cases where the desired outcome is statically resolved content. Because of this, for flexibility purposes, I’m assuming ERS is not attempting to standardize how the chip resolver itself should be designed?

• Would the bootloaderApp be responsible for verifying TSM and manufacturer certificates? In either case, it seems like the bootloaderApp should only be responsible for verification of records that are stored primarily on-chain following ERS’ standards. Why not, then make this a universally trusted IPFS / Arweave link and put all application-specific logic into the contentApp?

Thanks again!

[ccamrobertson]

@leeren thanks for the feedback! Some thoughts below –

• What is the process by which chipId is generated for a registered chip? I’m assuming the public key coordinates are stored in the secure chip element, so would this be something like the last X bytes of the keccak256 hash of the public key?

The chipId is a keccack256 hash if the raw x and y coordinates of the chip’s public key. We expect that some chips will offer multiple key slots, however, it’s expected that there is a primary public key which serves this function. There has been some debate here around concatenating the keccack256 hash into an Ethereum address, however, I believe that this is risky.

The nature of the SiLo or “Silicon Locked” model that we proposed with Kong Cash is that the chips are too simple for a secure interface and thus the expectation is that anyone should be able to get a signature from the chip at any time. If we treat the chips as EOAs (by casting chipId as an address) there is the implication that it’s safe to treat a chip in this way when in reality a single tap by a malicious party could pull assets off or carry out some other undesirable action.

Additionally we would like to support other ECDSA curves that aren’t natively supported in Ethereum today to mirror the secure elements that exist on the market (namely P256). An address for this kind of chip would be completely nonsensical and any assets sent there would be lost.

• For the registry, could you elaborate on what it means for chip records to be immutable on creation? Besides the case of chipId, which would likely be generated deterministically, there may be good reasons to have other attributes modifiable. For example, having an expiration date for the TSM / manufacturer cert, or updating the chipContent to another application domain due to faulty configuration. Either way, I think it would be a good idea to allow these fields to be capable of being made immutable, just not necessarily from the get-go. Thoughts?

This is a great question – I believe that apart from the chipId itself there are reasonable arguments on both sides as to what should and should not be immutable. I think that if we come up with some more nuanced control structures (e.g. a controller or operator for chips), then chipContent mutability relative to the TSM is reasonable. In theory a stake of some sort here should help to deter the TSM from bricking chips or doing something malicious.

I’m interesting in exploring expiring certificates here – is the idea that it protects a TSM in the case where they lose control of an address?

• What is the reason for including chipContent in the registry? In cases where resolver records are dynamic, enforcing a static nature for the chip content itself here might make it hard to ensure semantic consistency between the chip content and its resolved contract records down the line. Instead, why not just have the option of making the chipResolver immutable, and aggregating all content there?

chipContent might not be an ideal name here; perhaps we should modify to tsmApp. This is intended to represent a dedicated dapp deployed by the TSM which the chip is redirected to, not necessarily multimedia or metadata which I envision the chipResolver handles.

• Is the intention of the bootloaderApp IPFS resource included in the manufacturer registry ChipModel to point a manufacturer’s chip to its registered TSM application logic (contentApp)? Is it correct then that the chips themselves would have to point to this domain initially? How can this be proven publicly, given that initial translation I’d assume is done at the firmware level? Also, I personally think redirectApp might be a more logical name.

Hmm not quite sure I follow regarding a public proof, however, the bootloaderApp is meant to be a placeholder in the event that someone encounters a chip that has not been enrolled by a TSM. It is expected that this will be superseded in nearly all cases by the TSM and chipContent.

That’s a good question regarding domain – we’re currently hosting a long lived Swiss domain, eth.vrfy.ch which is intended as an entrypoint for chips. We have a minimal script which lives there (see GitHub - arx-research/halo-director) and is a prototype of the bootloaderApp. I expect that other manufacturers may wish to use other domains, however, our biggest concern around this is longevity and stability. vrfy.ch is registered through 2030 and the plan is to point the domain to halo-director hosted and pinned on IPFS across multiple services.

• To add on to the prior question, how do you envision the process by which the TSM contentApp supersedes the bootloaderApp? Would there be an interface by which TSMs can mass enroll their new contentApp? Or would this be as simple as having the bootloaderApp always resolve to the contentApp in the case that the chips’ TSM registry record is defined. In either case, it seems like the bootloaderApp wouldn’t be replaced per se, but just used to redirect in different ways?

We could always return contentApp in the event it has been set by an initial TSM in response to a call for the bootloaderApp. My preference would be to allow for independent calls (getBootloaderApp, getContentApp) and simple have a generic getChipApp which directs to the correct app depending on what is set.

I would imagine that an ideal bootloaderApp would have an interface which allows a TSM to add content, however, for bulk chip enrolled a TSM will likely not use this interface at all and rather make calls directly against the registry.

• For the project I’m building, using the Chip Resolver as an NFT itself seems like a very appealing model. This would especially simplify cases where the desired outcome is statically resolved content. Because of this, for flexibility purposes, I’m assuming ERS is not attempting to standardize how the chip resolver itself should be designed?

I can see arguments for where the registry treats the chip as an NFT as well as the chipResolver. Every chip is indeed its own unique entity which in my mind maps well with EIP721, however, I can see cases where the NFT here is superseded by whatever a chipResolver associates with the chip.

I’m 100% in agreement that ERS should not be prescriptive with respect to how a chipResolver should work, however, I do believe that we could devise some standard interfaces that would make chipResolution easier. This is what’s intended w.r.t OCAP schemas. In comparison to something like ENS, I think that its far more likely that chips will route to custom chipResolvers with very different record types and interactions rather than a singular public resolver.

• Would the bootloaderApp be responsible for verifying TSM and manufacturer certificates? In either case, it seems like the bootloaderApp should only be responsible for verification of records that are stored primarily on-chain following ERS’ standards. Why not, then make this a universally trusted IPFS / Arweave link and put all application-specific logic into the contentApp?

No, I see certificates as being for the benefit of smart contracts rather than dapps which carry out on-chain lookups.

I think I understand the second part and I believe that is in fact the intention with the caveat that I envision certain manufacturers may desire/need distinct apps here given that we aren’t standardizing things like NDEF records and how they are parsed. But maybe it would be desirable to devise a schema or set of schemas.

[Oba-One]

Hi!

Replying to see if there’s any movement on ERS? I feel with tools like EAS https://attest.sh/ and Tokenbound Accounts https://tokenbound.org/ growing in adoption they can help to facilitate a lot of the core architecture of ERS.

[ccamrobertson]

@Oba-One I’ve been poor about updating this thread – we’re on testnet internally and working towards mainnet soon. We’re very close to dropping our repos and doc; I will link here when ready. Most of our work has been focused on doing things gas efficiently on L1 Ethereum.

Agreed re EAS and TBAs; ERS doesn’t use EAS formatted attestations natively BUT there is a lot of room for iteration here as TSMs could leverage EAS attestations if desired.

Re TBAs specifically; what were you thinking here? I’ve been imagining that a TBA registry would be perfect to enroll as a service in ERS when deployed to indicate that a TBA is a core experience associated with something IRL. Curious to hear any other ideas on where they might intersect.

Are you going to make it out to devconnect?