This standard is co-authored by @tina1998612

Preamble

EIP: <to be assigned>
Title: Custodian-Client Contract Standard
Author: Lee Ting-Ting <tingtinglee.codingirl@gmail.com>, Hu Yao-Chieh <cs.yaochieh.hu@gmail.com>
Type: Standard
Category: ERC
Status: Draft
Created: 2018-01-30

Simple Summary

A standard interface of custodian smart contracts that allows on-chain creating and tracking of client smart contract instances. A two-level smart contract hierarchy is therefore constructed. A typical use case is valuable asset management, ranging from digital coupons and concert tickets to high-value commodities such as diamond grading certificates.

The paper of this standard specification has been recognized and accepted by the 16th ACM International Conference on Mobile Systems, Applications, and Services - Cryptocurrencies and Blockchains for Distributed Systems. (Munich, Germany)

ACM Reference Format:
Yao-Chieh Hu, Ting-Ting Lee, Dimitris Chatzopoulos, and Pan Hui. 2018. Hierarchical interactions between Ethereum smart contracts across Testnets. In Proceedings of MobiSys’18. ACM, New York, NY, USA, 6 pages. https: //doi.org/http://dx.doi.org/XXXX.XXXX (To be published)

Abstract

This standard allows for the implementation of a standard API for Custodian-Client Contracts (henceforth referred to as "CCCs") within smart contracts. This standard also proposes a two-level hierarchical architecture that is composed of two types of smart contracts: custodian and client. A custodian contract can deploy on-demand client contract, access their data and call their methods to perform specific updates. Furthermore, a framework is developed to allow client contracts to share common variables among all or partial group of the contracts, which may only be mutated by its creator, custodian contracts. Specifically, this standard provides basic functionality to establish associations between a custodian smart contract and multiple client smart contracts.

Motivation

Compared to ERC721, this standard creates the new entity as a smart contract instead of an instance of Struct in view of the following reasons:

1. Provide flexible independence. Client contracts are independent from each other in terms of direct association, yet connected with shared states which are traceable by the custodian contract.
2. Minimize loss when attacks take place. Since smart contracts are independent from each other once created, the stakes of attacks are restrained in one single contract rather than exposing the entire contract system as an attack interface.
3. Least control and zero knowledge from upstream. Custodian contract can have no knowledge to any of the client contract except its deployed contract address while preserving sufficient controls and traceable records of it.
4. Flexibility on the newly created entity. As new instances are created in the form of smart contracts, it can be made compatible with ERC20 or other standards without limitations.

To summarize, ERC860 can be viewed as an extended standard from ERC721 with a different implementation that preserves the specialty and independence of each token instance, improves the fraud resistance, and provides flexible compatibility with other standards in the meantime.

Use Case

A representative example of smart contracts that interact in a hierarchical way is the one of a ticket selling contract. Each ticket is created automatically by the contract of the higher level. As shown in the following figure, whenever a customer buys a ticket, the ticket seller creates a new ticket and gives it to the customer (i.e., deploys a new smart contract and assigns as owner the id of the customer). As whom to distribute tickets to its customers, the ticket seller performs the role of a Custodian smart contract. Client smart contract will be created and owned by the customer once the ticket is purchased. Customers are allowed to exchange or sell tickets to others by transferring the ownership of his/her Client smart contract. The ticket seller is able to retrieve the updated information when querying since the Client contracts can be restored by the deployment address which the Custodian smart contract keeps track of. If as time passes by, the ticket seller wishes to update the shared random seed to boost security, the Custodian smart contract will call the Client contracts again by its deployed address and perform the update accordingly.

Specification

Custodian Contract

getClient

A phonebook-like mapping from a given client ID to the corresponding client contract address.

mapping (uint256 => address) clients;   // client IDs --> client contract addresses

createClient

Create a client with a generated ID (generation mechanism specified below) and return the ID.

function createClient() public returns (uint256);

generateID

Generate an ID based on the created client contract address.

function generateID(address _clientAddress) returns (uint256);

Event: CreateClient

MUST be triggered when createClient was successfully called.

event CreateClient(uint256 _clientId, address _clientAddress);

Client Contract

Smart contracts associated with ownership that can be obtained and transferred. Here is a concrete example of Digital Coupon Smart Contract.

Solidity Interface

pragma solidity ^0.4.18;

contract Custodian {
    event CreateClient(uint256 _clientId, address _clientAddress);

    mapping (uint256 => address) clients;
    
    function createClient() public returns (uint256);
    function generateID(address _clientAddress) returns (uint256);
}

A sample implementation of Digital Coupon Application.

Copyright

Copyright and related rights waived via CC0.