cic-contracts/doc/texinfo/index/Smart-contract-interfaces.html

118 lines
5.3 KiB
HTML
Raw Permalink Normal View History

2021-01-05 20:22:51 +01:00
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Created by GNU Texinfo 6.7, http://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Smart contract interfaces (Untitled Document)</title>
<meta name="description" content="Smart contract interfaces (Untitled Document)">
<meta name="keywords" content="Smart contract interfaces (Untitled Document)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<link href="#Smart-contract-interfaces" rel="start" title="Smart contract interfaces">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
-->
</style>
</head>
<body lang="en">
<span id="Smart-contract-interfaces"></span><span id="Smart-contract-interfaces-1"></span><h2 class="chapter">1 Smart contract interfaces</h2>
<span id="Smart-Contracts-in-the-CIC-Network"></span><h3 class="section">1.1 Smart Contracts in the CIC Network</h3>
<span id="Technology"></span><h4 class="subsection">1.1.1 Technology</h4>
<p>The long-term aim of the CIC network is to be agnostic of consensus engines. However, since we have to start <em>somewhere</em>, the current state of development only deals with Smart Contracts on the (Ethereum Virtual Machine (EVM).
</p>
<span id="The-registry-contract"></span><h4 class="subsection">1.1.2 The registry contract</h4>
<p>The CICRegistry contract defines the entry-point to the entire CIC network. All other CIC network resources can be discovered through this contract.
</p>
<p>Its implementation is contained in the <samp>cic-registry</samp> repository. Details about it are documented further in that section.
</p>
<span id="Auxiliary-contracts"></span><h4 class="subsection">1.1.3 Auxiliary contracts</h4>
<p>All other Smart Contracts in the network other than CICRegistry are essentially optional, and each applies <em>at least one</em> the interfaces defined in the <code>cic-contracts</code> repository.
</p>
<span id="Contract-interfaces"></span><h4 class="subsection">1.1.4 Contract interfaces</h4>
<p>All contracts interfaces also implement the <strong>EIP165</strong> Standard Interface Detection.
</p>
<span id="Registry"></span><h4 class="subsubsection">1.1.4.1 Registry</h4>
<p>A key-value store, which resolves arbitrary 32-byte pointers to Ethereum addresses. Typically, this is used to resolve an address from a well-known identifier, either as a UTF-8 value or a 256-bit hash.
</p>
<p>It also provides numerical index access to all registered values in order of insertion.
</p>
<span id="Registry-Client"></span><h4 class="subsubsection">1.1.4.2 Registry Client</h4>
<p>A subset of the <code>Registry</code> interface, which defines only the non-transactional methods of the contract. The <code>Registry Client</code> interface is implemented by the <code>CICRegistry</code> contract.
</p>
<span id="Faucet"></span><h4 class="subsubsection">1.1.4.3 Faucet</h4>
<p>Enables disbursement of a set amount of tokens to a requesting address.
</p>
<p>Allows privileged accounts to adjust the amount of tokens to disburse.
</p>
<p>Can be implemented as a periodic or a one-time service per account.
</p>
<span id="Transfer-approval"></span><h4 class="subsubsection">1.1.4.4 Transfer approval</h4>
<p>Enables a third-party approval to spend an ERC20 token allowance.
</p>
<p>This is useful in the case of a custodial key store, where a transaction has been initiated by another entity than the owner of the key.
</p>
<p>The contract allows the third-party address to either allow or reject the transfer.
</p>
<span id="Declarator"></span><h4 class="subsubsection">1.1.4.5 Declarator</h4>
<p>Stores one or more 32-byte entries as a description of an Ethereum address, <em>signed</em> by another Ethereum address.
</p>
<p>This can be used to <em>describe</em> network resources, be it tokens, contracts or user accounts. Examples of uses are KYC documentation proofs for users, token metadata used for display, or fraud alerts.
</p>
<p>Entries are stored by the transacting address that adds address/description pairs. In other words, any address may have different &quot;opinions&quot; registered about it, depending on which signing address it is queried in the context of. This, in turn, allows the quering entity to compile its own &quot;opinion&quot; of an address by combining data from signatures it trusts.
</p>
<p>Entries typically are text strings or content hashes.
</p>
<span id="Address-Index"></span><h4 class="subsubsection">1.1.4.6 Address Index</h4>
<p>A simple append-only list of addresses. Used to check whether an address is part of a particular group.
</p>
<span id="DEX-Index"></span><h4 class="subsubsection">1.1.4.7 DEX Index</h4>
<p>Methods required to convert between tokens.
</p><hr>
</body>
</html>