mirror of https://github.com/status-im/EIPs.git
Use solidity/javascript highlighting in various EIPs (#2372)
This commit is contained in:
William Entriken
Alex Beregszaszi
parent
53455c7d06
commit
af677b348d
|
|
@ -36,13 +36,13 @@ When mapping the IPFS base58 string to ENS resolver, first we convert the Base58
|
|||
## Rationale
|
||||
To implement the specification, need two methods from ENS public resolver contract, when we want to store IPFS file fingerprint to contract, convert the Base58 string identifier to the hex format and invoke the `setMultihash` method below :
|
||||
|
||||
```
|
||||
```solidity
|
||||
function setMultihash(bytes32 node, bytes hash) public only_owner(node);
|
||||
```
|
||||
|
||||
Whenever users need to visit the ENS content, we call the `multihash` method to get the IPFS hex data, transfer to the Base58 format, and return the IPFS resources to use.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function multihash(bytes32 node) public view returns (bytes);
|
||||
```
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ To implement the way to transfer from base58 to hex format and the reverse one,
|
|||
The library link : [https://www.npmjs.com/package/multihashes](https://www.npmjs.com/package/multihashes)
|
||||
To implement the method transfer from IPFS(Base58) to hex format :
|
||||
|
||||
```
|
||||
```javascript
|
||||
import multihash from 'multihashes'
|
||||
|
||||
export const toHex = function(ipfsHash) {
|
||||
|
|
@ -63,7 +63,7 @@ export const toHex = function(ipfsHash) {
|
|||
|
||||
To implement the method transfer from hex format to IPFS(Base58) :
|
||||
|
||||
```
|
||||
```javascript
|
||||
import multihash from 'multihashes'
|
||||
|
||||
export const toBase58 = function(contentHash) {
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ The intention with this proposal is to enhance the ERC20 standard with token-loc
|
|||
I’ve extended the ERC20 interface with the following enhancements:
|
||||
|
||||
### Locking of tokens
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev Locks a specified amount of tokens against an address,
|
||||
* for a specified reason and time
|
||||
|
|
@ -55,7 +55,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
|
|||
```
|
||||
|
||||
### Fetching number of tokens locked under each utility
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev Returns tokens locked for a specified address for a
|
||||
* specified reason
|
||||
|
|
@ -67,7 +67,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
|
|||
```
|
||||
|
||||
### Fetching number of tokens locked under each utility at a future timestamp
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev Returns tokens locked for a specified address for a
|
||||
* specified reason at a specific time
|
||||
|
|
@ -80,7 +80,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
|
|||
```
|
||||
|
||||
### Fetching number of tokens held by an address
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev @dev Returns total tokens held by an address (locked + transferable)
|
||||
* @param _of The address to query the total balance of
|
||||
|
|
@ -89,7 +89,7 @@ function totalBalanceOf(address _of) view returns (uint256 amount)
|
|||
```
|
||||
|
||||
### Extending lock period
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev Extends lock for a specified reason and time
|
||||
* @param _reason The reason to lock tokens
|
||||
|
|
@ -99,7 +99,7 @@ function totalBalanceOf(address _of) view returns (uint256 amount)
|
|||
```
|
||||
|
||||
### Increasing number of tokens locked
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev Increase number of tokens locked for a specified reason
|
||||
* @param _reason The reason to lock tokens
|
||||
|
|
@ -108,7 +108,7 @@ function totalBalanceOf(address _of) view returns (uint256 amount)
|
|||
function increaseLockAmount(bytes32 _reason, uint256 _amount) public returns (bool)
|
||||
```
|
||||
### Fetching number of unlockable tokens under each utility
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev Returns unlockable tokens for a specified address for a specified reason
|
||||
* @param _of The address to query the the unlockable token count of
|
||||
|
|
@ -117,7 +117,7 @@ function totalBalanceOf(address _of) view returns (uint256 amount)
|
|||
function tokensUnlockable(address _of, bytes32 _reason) public view returns (uint256 amount)
|
||||
```
|
||||
### Fetching number of unlockable tokens
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev Gets the unlockable tokens of a specified address
|
||||
* @param _of The address to query the the unlockable token count of
|
||||
|
|
@ -125,7 +125,7 @@ function totalBalanceOf(address _of) view returns (uint256 amount)
|
|||
function getUnlockableTokens(address _of) public view returns (uint256 unlockableTokens)
|
||||
```
|
||||
### Unlocking tokens
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @dev Unlocks the unlockable tokens of a specified address
|
||||
* @param _of Address of user, claiming back unlockable tokens
|
||||
|
|
|
|||
|
|
@ -53,14 +53,14 @@ Resolving a name in ENS is a two-step process. First, the ENS registry is called
|
|||
|
||||
For example, suppose you wish to find the address of the token contract associated with 'beercoin.eth'. First, get the resolver:
|
||||
|
||||
```
|
||||
```javascript
|
||||
var node = namehash("beercoin.eth");
|
||||
var resolver = ens.resolver(node);
|
||||
```
|
||||
|
||||
Then, ask the resolver for the address for the contract:
|
||||
|
||||
```
|
||||
```javascript
|
||||
var address = resolver.addr(node);
|
||||
```
|
||||
|
||||
|
|
@ -112,43 +112,43 @@ Implementations should conform to the following test vectors for namehash:
|
|||
|
||||
The ENS registry contract exposes the following functions:
|
||||
|
||||
```
|
||||
```solidity
|
||||
function owner(bytes32 node) constant returns (address);
|
||||
```
|
||||
|
||||
Returns the owner (registrar) of the specified node.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function resolver(bytes32 node) constant returns (address);
|
||||
```
|
||||
|
||||
Returns the resolver for the specified node.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function ttl(bytes32 node) constant returns (uint64);
|
||||
```
|
||||
|
||||
Returns the time-to-live (TTL) of the node; that is, the maximum duration for which a node's information may be cached.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function setOwner(bytes32 node, address owner);
|
||||
```
|
||||
|
||||
Transfers ownership of a node to another registrar. This function may only be called by the current owner of `node`. A successful call to this function logs the event `Transfer(bytes32 indexed, address)`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function setSubnodeOwner(bytes32 node, bytes32 label, address owner);
|
||||
```
|
||||
|
||||
Creates a new node, `sha3(node, label)` and sets its owner to `owner`, or updates the node with a new owner if it already exists. This function may only be called by the current owner of `node`. A successful call to this function logs the event `NewOwner(bytes32 indexed, bytes32 indexed, address)`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function setResolver(bytes32 node, address resolver);
|
||||
```
|
||||
|
||||
Sets the resolver address for `node`. This function may only be called by the owner of `node`. A successful call to this function logs the event `NewResolver(bytes32 indexed, address)`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function setTTL(bytes32 node, uint64 ttl);
|
||||
```
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ Resolvers may implement any subset of the record types specified here. Where a r
|
|||
|
||||
Resolvers have one mandatory function:
|
||||
|
||||
```
|
||||
```solidity
|
||||
function supportsInterface(bytes4 interfaceID) constant returns (bool)
|
||||
```
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ EIPs may define new interfaces to be added to this registry.
|
|||
|
||||
Resolvers wishing to support contract address resources must provide the following function:
|
||||
|
||||
```
|
||||
```solidity
|
||||
function addr(bytes32 node) constant returns (address);
|
||||
```
|
||||
|
||||
|
|
@ -194,12 +194,12 @@ Clients resolving the `addr` record MUST check for a zero return value, and trea
|
|||
|
||||
Changes to an address MUST trigger the following event:
|
||||
|
||||
```
|
||||
```solidity
|
||||
event AddrChanged(bytes32 indexed node, address a);
|
||||
```
|
||||
# Appendix A: Registry Implementation
|
||||
|
||||
```
|
||||
```solidity
|
||||
contract ENS {
|
||||
struct Record {
|
||||
address owner;
|
||||
|
|
@ -261,7 +261,7 @@ contract ENS {
|
|||
|
||||
The simplest possible resolver is a contract that acts as its own name resolver by implementing the contract address resource profile:
|
||||
|
||||
```
|
||||
```solidity
|
||||
contract DoSomethingUseful {
|
||||
// Other code
|
||||
|
||||
|
|
@ -285,7 +285,7 @@ Such a contract can be inserted directly into the ENS registry, eliminating the
|
|||
|
||||
A basic resolver that implements the contract address profile, and allows only its owner to update records:
|
||||
|
||||
```
|
||||
```solidity
|
||||
contract Resolver {
|
||||
event AddrChanged(bytes32 indexed node, address a);
|
||||
|
||||
|
|
@ -325,7 +325,7 @@ After deploying this contract, use it by updating the ENS registry to reference
|
|||
|
||||
Similar to the resolver above, this contract only supports the contract address profile, but uses the ENS registry to determine who should be allowed to update entries:
|
||||
|
||||
```
|
||||
```solidity
|
||||
contract PublicResolver {
|
||||
event AddrChanged(bytes32 indexed node, address a);
|
||||
event ContentChanged(bytes32 indexed node, bytes32 hash);
|
||||
|
|
@ -364,7 +364,7 @@ contract PublicResolver {
|
|||
|
||||
This registrar allows users to register names at no cost if they are the first to request them.
|
||||
|
||||
```
|
||||
```solidity
|
||||
contract FIFSRegistrar {
|
||||
ENS ens;
|
||||
bytes32 rootNode;
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ The wine vendors smart contract validates the attestation, checks the payment am
|
|||
When the wine vendor shows up to her apartment with the wine, there is no need to prove her age again.
|
||||
|
||||
### Draft interface
|
||||
```
|
||||
```solidity
|
||||
/* each attestation issuer should provide their own verify() for the
|
||||
* attestations they issued. There are two reasons for this. First, we
|
||||
* need to leave room for new attestation methods other than the
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Unlike previous attempts, we assume that the attestation is signed and issued of
|
|||
This ERC provides an interface and reference implementation for smart contracts that need users to provide an attestation and validate it.
|
||||
|
||||
### Draft implementation
|
||||
```
|
||||
```solidity
|
||||
contract MerkleTreeAttestationInterface {
|
||||
struct Attestation
|
||||
{
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Anyone can publish a list of issuers. Only the most trusted and carefully mainta
|
|||
This ERC provides a smart contract interface for anyone to manage a list of attestation issuers. A smart contract would explicitly trust a list, and therefore all attestations issued by the issuers on the list.
|
||||
|
||||
### Draft implementation
|
||||
```
|
||||
```solidity
|
||||
/* The purpose of this contract is to manage the list of attestation
|
||||
* issuer contracts and their capacity to fulfill requirements
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ For compliance reasons, the `ERC-1450` constructor must specify the issuer (the
|
|||
### ERC-20 Extension
|
||||
`ERC-20` tokens provide the following functionality:
|
||||
|
||||
```
|
||||
```solidity
|
||||
contract ERC20 {
|
||||
function totalSupply() public view returns (uint256);
|
||||
function balanceOf(address who) public view returns (uint256);
|
||||
|
|
@ -67,7 +67,7 @@ contract ERC20 {
|
|||
|
||||
`ERC-20` is extended as follows:
|
||||
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* ERC-1450 is an ERC-20 compatible token that facilitates compliance with one or more of Securities Act Regulations CF, D and A.
|
||||
*
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ FNV Mix Algorithm Analysis for TEthashV1
|
|||
You can compile it with simple in terminal.
|
||||
No additional library needs,
|
||||
|
||||
```
|
||||
```sh
|
||||
gcc -o fnvtest fnvcltest.c
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ The BDI software model is an attempt to solve a problem of plans and planning ch
|
|||
|
||||
|
||||
#### Main Interface
|
||||
```
|
||||
```solidity
|
||||
pragma solidity ^0.4.25;
|
||||
pragma experimental ABIEncoderV2;
|
||||
|
||||
|
|
@ -327,7 +327,7 @@ interface IERC_HUCAP {
|
|||
|
||||
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
|
||||
|
||||
```
|
||||
```solidity
|
||||
|
||||
interface IERC_HUCAP_TYPES {
|
||||
|
||||
|
|
@ -359,7 +359,7 @@ interface IERC_HUCAP_TYPES {
|
|||
|
||||
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
|
||||
|
||||
```
|
||||
```solidity
|
||||
pragma solidity ^0.4.25;
|
||||
pragma experimental ABIEncoderV2;
|
||||
|
||||
|
|
@ -451,7 +451,7 @@ interface IERC_HUCAP_KEYSIGNING_EXTENSION {
|
|||
```
|
||||
#### Human Capital Accounting Extension Interface
|
||||
|
||||
```
|
||||
```solidity
|
||||
pragma solidity ^0.4.25;
|
||||
pragma experimental ABIEncoderV2;
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ Below is the specification of Handler interface. In the Handler interface we def
|
|||
Developers have to define their business-related functions as well.
|
||||
|
||||
|
||||
```
|
||||
```solidity
|
||||
/// Handler interface.
|
||||
/// Handler defines business related functions.
|
||||
/// Use the interface to ensure that your external services are always supported.
|
||||
|
|
@ -105,7 +105,7 @@ Below is the specification of Data contract. There are three parts in the Data c
|
|||
- **Resource Data**: all other resources that the contract needs to keep and manage.
|
||||
|
||||
|
||||
```
|
||||
```solidity
|
||||
/// Data Contract
|
||||
contract DataContract {
|
||||
|
||||
|
|
@ -236,7 +236,7 @@ Note:
|
|||
- Function status() can be called at any time to show caller status of the upgrader.
|
||||
|
||||
|
||||
```
|
||||
```solidity
|
||||
/// Handler upgrader
|
||||
contract Upgrader {
|
||||
// Data contract
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@ For reference, further discussion on this EIP also occurred in the following PRs
|
|||
|
||||
Assuming ecRecover precompile is perfectly priced, we executed a set of benchmarks comparing Blake2b F compression function precompile with ecRecover precompile. For benchmarks, we used 3.1 GHz Intel Core i7 64-bit machine.
|
||||
|
||||
```
|
||||
```sh
|
||||
$ sysctl -n machdep.cpu.brand_string
|
||||
Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
|
||||
```
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ To use rules within a token is as easy as having the token inherit from WithRule
|
|||
|
||||
Below is a template for a rule.
|
||||
|
||||
```
|
||||
```solidity
|
||||
import "../interface/IRule.sol";
|
||||
|
||||
contract TemplateRule is IRule {
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ This EIP proposes a light-weight abstraction layer for a standard account metada
|
|||
## Specification
|
||||
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
|
||||
The Attribute Registry interface contains four functions, outlined as follows:
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @title EIP-1616 Attribute Registry Standard interface. EIP-165 ID: 0x5f46473f
|
||||
*/
|
||||
|
|
@ -53,7 +53,7 @@ interface AttributeRegistryInterface {
|
|||
Contracts that comply with the Attribute Registry EIP MUST implement the above interface.
|
||||
|
||||
As an additional requirement, the ERC-165 interface MUST be included:
|
||||
```
|
||||
```solidity
|
||||
/**
|
||||
* @title EIP-165 interface. EIP-165 ID: 0x01ffc9a7
|
||||
*/
|
||||
|
|
@ -73,7 +73,7 @@ The implementation MUST follow the specifications described below.
|
|||
The view functions detailed below MUST be implemented.
|
||||
|
||||
#### `hasAttribute` function
|
||||
```
|
||||
```solidity
|
||||
function hasAttribute(address account, uint256 attributeTypeID) external view returns (bool)
|
||||
```
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ _**NOTE**_: This function MUST return two equal values when performing two direc
|
|||
|
||||
|
||||
#### `getAttributeValue` function
|
||||
```
|
||||
```solidity
|
||||
function getAttributeValue(address account, uint256 attributeTypeID) external view returns (uint256)
|
||||
```
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ _**NOTE**_: This function MUST revert if a directly preceding or subsequent func
|
|||
_**NOTE**_: This function MUST return two equal values when performing two directly consecutive function calls with identical `account` and `attributeTypeID` parameters, regardless of differences in the caller's address, the transaction origin, or other out-of-band information.
|
||||
|
||||
#### `countAttributeTypes` function
|
||||
```
|
||||
```solidity
|
||||
function countAttributeTypes() external view returns (uint256)
|
||||
```
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ _**NOTE**_: This function MUST return a positive integer value - i.e. calling t
|
|||
_**NOTE**_: This function MUST return a value that encompasses all indexes of attribute type IDs whereby a call to `hasAttribute` on some address with an attribute type ID at the given index would return `true`.
|
||||
|
||||
#### `getAttributeTypeID` function
|
||||
```
|
||||
```solidity
|
||||
function getAttributeTypeID(uint256 index) external view returns (uint256)
|
||||
```
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ Targeted test cases with 100% code coverage can be found at [this repository](ht
|
|||
<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
|
||||
The basic implementation that follows can be found at [this repository](https://github.com/0age/AttributeRegistry) (see [here](https://github.com/TPL-protocol/tpl-contracts/blob/master/contracts/BasicJurisdiction.sol#L399) for an example of a more complex implementing contract):
|
||||
|
||||
```
|
||||
```solidity
|
||||
pragma solidity ^0.4.25;
|
||||
|
||||
/**
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ Smart contracts can be used to embed regulatory requirements with respect to the
|
|||
## Interface
|
||||
|
||||
### Solidity Example
|
||||
```
|
||||
```solidity
|
||||
interface EIP1753 {
|
||||
string public name;
|
||||
uint256 public totalSupply;
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ For example, a token contract may not itself provide any kind of 'atomic swap' f
|
|||
## Specification
|
||||
A new profile for ENS resolvers is defined, consisting of the following method:
|
||||
|
||||
```
|
||||
```solidity
|
||||
function interfaceImplementer(bytes32 node, bytes4 interfaceID) external view returns (address);
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -68,8 +68,7 @@ A pull system is required to keep the application completely decentralized and t
|
|||
|
||||
`tokencontractAddress` : the contract address to which tokens will be minted, default is address(this)
|
||||
|
||||
```
|
||||
SOLIDITY
|
||||
```solidity
|
||||
|
||||
pragma solidity ^0.5.2;
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Currently, computational opcode costs are already too close to the minimum unit
|
|||
A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If increasing `particlesUsed` results in an excess of 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`).
|
||||
|
||||
Where the current gas logic looks like this:
|
||||
```
|
||||
```python
|
||||
def vm_execute(ext, msg, code):
|
||||
# Initialize stack, memory, program counter, etc
|
||||
compustate = Compustate(gas=msg.gas)
|
||||
|
|
@ -52,7 +52,7 @@ def vm_execute(ext, msg, code):
|
|||
```
|
||||
|
||||
The new gas logic using particles might look like this:
|
||||
```
|
||||
```python
|
||||
PARTICLES_PER_GAS = 10000
|
||||
|
||||
def vm_execute(ext, msg, code):
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ This pattern of separating data type definitions and storage allows developers t
|
|||
|
||||
ERC-1900 defines a `contractAddress` field in the type metadata. For the limited purpose of ERC-1900, this field contains the value of the Ethereum type library in which the type definition exists. For the purpose of this ERC, the `contractAddress` will contain the Etherereum address of a `TypeRootContract`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
contract TypeRootContract {
|
||||
address public libraryAddress;
|
||||
address public storageAddress;
|
||||
|
|
@ -66,7 +66,7 @@ We propose a Solidity CRUD pattern, as described in https://medium.com/robhitche
|
|||
|
||||
An stub implementation for the TypeStorageContract would look like:
|
||||
|
||||
```
|
||||
```solidity
|
||||
import './TypeALib.sol';
|
||||
|
||||
contract TypeAStorage {
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ const response = await provider.send({
|
|||
```
|
||||
Would return a value something like this:
|
||||
|
||||
```
|
||||
```json
|
||||
[
|
||||
{
|
||||
invoker: 'ens://your-site.eth',
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ The Atomic Swap-based American Call Option smart contract should follow the synt
|
|||
|
||||
This mapping stores the metadata of the swap contracts, including the parties and tokens involved. Each contract uses different `secretHash`, and is distinguished by `secretHash`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
mapping(bytes32 => Swap) public swap;
|
||||
```
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ mapping(bytes32 => Swap) public swap;
|
|||
|
||||
This mapping stores the detail of the asset initiators want to sell, including the amount, the timelock and the state. It is associated with the swap contract with the same `secretHash`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
mapping(bytes32 => InitiatorAsset) public initiatorAsset;
|
||||
```
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ mapping(bytes32 => InitiatorAsset) public initiatorAsset;
|
|||
|
||||
This mapping stores the details of the asset participants want to sell, including the amount, the timelock and the state. It is associated with the swap contract with the same `secretHash`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
mapping(bytes32 => ParticipantAsset) public participantAsset;
|
||||
```
|
||||
|
||||
|
|
@ -73,7 +73,7 @@ mapping(bytes32 => ParticipantAsset) public participantAsset;
|
|||
|
||||
This mapping stores the details of the premium initiators attach in the swap contract, including the amount, the timelock and the state. It is associated with the swap contract with the same `secretHash`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
mapping(bytes32 => Premium) public premium;
|
||||
```
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ mapping(bytes32 => Premium) public premium;
|
|||
|
||||
This function sets up the swap contract, including the both parties involved, the tokens to exchanged, and so on.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function setup(bytes32 secretHash, address payable initiator, address tokenA, address tokenB, uint256 initiatorAssetAmount, address payable participant, uint256 participantAssetAmount, uint256 premiumAmount) public payable
|
||||
```
|
||||
|
||||
|
|
@ -92,7 +92,7 @@ function setup(bytes32 secretHash, address payable initiator, address tokenA, ad
|
|||
|
||||
The initiator invokes this function to fill and lock the token she/he wants to sell and join the contract.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function initiate(bytes32 secretHash, uint256 assetRefundTime) public payable
|
||||
```
|
||||
|
||||
|
|
@ -100,7 +100,7 @@ function initiate(bytes32 secretHash, uint256 assetRefundTime) public payable
|
|||
|
||||
The initiator invokes this function to fill and lock the premium.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function fillPremium(bytes32 secretHash, uint256 premiumRefundTime) public payable
|
||||
```
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ function fillPremium(bytes32 secretHash, uint256 premiumRefundTime) public payab
|
|||
|
||||
The participant invokes this function to fill and lock the token she/he wants to sell and join the contract.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function participate(bytes32 secretHash, uint256 assetRefundTime) public payable
|
||||
```
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ function participate(bytes32 secretHash, uint256 assetRefundTime) public payable
|
|||
|
||||
One of the parties invokes this function to get the token from the other party, by providing the preimage of the hash lock `secret`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function redeemAsset(bytes32 secret, bytes32 secretHash) public
|
||||
```
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ function redeemAsset(bytes32 secret, bytes32 secretHash) public
|
|||
|
||||
One of the parties invokes this function to get the token back after the timelock expires.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function refundAsset(bytes32 secretHash) public
|
||||
```
|
||||
|
||||
|
|
@ -132,7 +132,7 @@ function refundAsset(bytes32 secretHash) public
|
|||
|
||||
The participant invokes this function to get the premium. This can be invoked only if the participant has already invoked `participate` and the participant's token is redeemed or refunded.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function redeemPremium(bytes32 secretHash) public
|
||||
```
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ function redeemPremium(bytes32 secretHash) public
|
|||
|
||||
The initiator invokes this function to get the premium back after the timelock expires.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function refundPremium(bytes32 secretHash) public
|
||||
```
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ function refundPremium(bytes32 secretHash) public
|
|||
|
||||
This event indicates that one party has set up the contract using the function `setup()`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
event SetUp(bytes32 secretHash, address initiator, address participant, address tokenA, address tokenB, uint256 initiatorAssetAmount, uint256 participantAssetAmount, uint256 premiumAmount);
|
||||
```
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ event SetUp(bytes32 secretHash, address initiator, address participant, address
|
|||
|
||||
This event indicates that `initiator` has filled and locked the token to be exchanged using the function `initiate()`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
event Initiated(uint256 initiateTimestamp, bytes32 secretHash, address initiator, address participant, address initiatorAssetToken, uint256 initiatorAssetAmount, uint256 initiatorAssetRefundTimestamp);
|
||||
```
|
||||
|
||||
|
|
@ -167,7 +167,7 @@ event Initiated(uint256 initiateTimestamp, bytes32 secretHash, address initiator
|
|||
|
||||
This event indicates that `participant` has filled and locked the token to be exchanged using the function `participate()`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
event Participated(uint256 participateTimestamp, bytes32 secretHash, address initiator, address participant, address participantAssetToken, uint256 participantAssetAmount, uint256 participantAssetRefundTimestamp);
|
||||
```
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ event Participated(uint256 participateTimestamp, bytes32 secretHash, address ini
|
|||
|
||||
This event indicates that `initiator` has filled and locked `premium` using the function `fillPremium()`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
event PremiumFilled(uint256 fillPremiumTimestamp, bytes32 secretHash, address initiator, address participant, address premiumToken, uint256 premiumAmount, uint256 premiumRefundTimestamp);
|
||||
```
|
||||
|
||||
|
|
@ -183,11 +183,11 @@ event PremiumFilled(uint256 fillPremiumTimestamp, bytes32 secretHash, address in
|
|||
|
||||
These two events indicate that `asset` has been redeemed by the other party before the timelock by providing `secret`.
|
||||
|
||||
```
|
||||
```solidity
|
||||
event InitiatorAssetRedeemed(uint256 redeemTimestamp, bytes32 secretHash, bytes32 secret, address redeemer, address assetToken, uint256 amount);
|
||||
```
|
||||
|
||||
```
|
||||
```solidity
|
||||
event ParticipantAssetRedeemed(uint256 redeemTimestamp, bytes32 secretHash, bytes32 secret, address redeemer, address assetToken, uint256 amount);
|
||||
```
|
||||
|
||||
|
|
@ -195,11 +195,11 @@ event ParticipantAssetRedeemed(uint256 redeemTimestamp, bytes32 secretHash, byte
|
|||
|
||||
These two events indicate that `asset` has been refunded by the original owner after the timelock expires.
|
||||
|
||||
```
|
||||
```solidity
|
||||
event InitiatorAssetRefunded(uint256 refundTimestamp, bytes32 secretHash, address refunder, address assetToken, uint256 amount);
|
||||
```
|
||||
|
||||
```
|
||||
```solidity
|
||||
event ParticipantAssetRefunded(uint256 refundTimestamp, bytes32 secretHash, address refunder, address assetToken, uint256 amount);
|
||||
```
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ event ParticipantAssetRefunded(uint256 refundTimestamp, bytes32 secretHash, addr
|
|||
|
||||
This event indicates that `premium` has been redeemed by `participant`. This implies that `asset` is either redeemed by `initiator` if it can provide the preimage of `secrectHash` before `asset` timelock expires; or refunded by `participant` if `asset` timelock expires.
|
||||
|
||||
```
|
||||
```solidity
|
||||
event PremiumRedeemed(uint256 redeemTimestamp,bytes32 secretHash,address redeemer,address token,uint256 amount);
|
||||
```
|
||||
|
||||
|
|
@ -215,7 +215,7 @@ event PremiumRedeemed(uint256 redeemTimestamp,bytes32 secretHash,address redeeme
|
|||
|
||||
This event indicates that `premium` has been refunded back to `initiator`, because of `participant` doesn't participate at all, by the time of `premium` timelock expires.
|
||||
|
||||
```
|
||||
```solidity
|
||||
event PremiumRefunded(uint256 refundTimestamp, bytes32 secretHash, address refunder, address token, uint256 amount);
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -22,8 +22,7 @@ With the increasing uptake of ENS by multi-coin wallets, wallet authors have req
|
|||
|
||||
A new accessor function for resolvers is specified:
|
||||
|
||||
```
|
||||
|
||||
```solidity
|
||||
function addr(bytes32 node, uint coinType) external view returns(bytes memory);
|
||||
```
|
||||
|
||||
|
|
@ -37,7 +36,7 @@ The return value is the cryptocurency address in its native binary format. Detai
|
|||
|
||||
A new event for resolvers is defined:
|
||||
|
||||
```
|
||||
```solidity
|
||||
event AddressChanged(bytes32 indexed node, uint coinType, bytes newAddress);
|
||||
```
|
||||
|
||||
|
|
@ -47,7 +46,7 @@ Resolvers MUST emit this event on each change to the address for a name and coin
|
|||
|
||||
The following function provides the recommended interface for changing the addresses stored for a node. Resolvers SHOULD implement this interface for setting addresses unless their needs dictate a different interface.
|
||||
|
||||
```
|
||||
```solidity
|
||||
function setAddr(bytes32 node, uint coinType, bytes calldata addr);
|
||||
```
|
||||
|
||||
|
|
@ -125,7 +124,7 @@ For example, the BNB address `bnb1grpf0955h0ykzq3ar5nmum7y6gdfl6lxfn46h2` decode
|
|||
|
||||
An example implementation of a resolver that supports this EIP is provided here:
|
||||
|
||||
```
|
||||
```solidity
|
||||
pragma solidity ^0.5.8;
|
||||
|
||||
contract AddrResolver is ResolverBase {
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ You can verify that an encoded binary can be decoded into the proper plaintext u
|
|||
|
||||
### Go
|
||||
|
||||
```
|
||||
```sh
|
||||
$ go get https://github.com/golang/snappy
|
||||
```
|
||||
|
||||
|
|
@ -144,7 +144,7 @@ func main() {
|
|||
}
|
||||
```
|
||||
|
||||
```
|
||||
```sh
|
||||
$ go run main.go block.rlp block.go.snappy
|
||||
Yay, decompressed data matched provided plain text!
|
||||
|
||||
|
|
@ -182,7 +182,7 @@ else:
|
|||
print "Yay, decompressed data matched provided plain text!"
|
||||
```
|
||||
|
||||
```
|
||||
```sh
|
||||
$ python main.py block.rlp block.go.snappy
|
||||
Yay, decompressed data matched provided plain text!
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ At block 1880000, the following accounts are encoded into a list `L`:
|
|||
|
||||
At the beginning of block 1920000, all ether throughout all accounts in `L` will be transferred to a contract deployed at `0xbf4ed7b27f1d666546e30d74d50d173d20bca754`. The contract was created from the following Solidity code (compiler version `v0.3.5-2016-07-01-48238c9`):
|
||||
|
||||
```
|
||||
```solidity
|
||||
// Deployed on mainnet at 0xbf4ed7b27f1d666546e30d74d50d173d20bca754
|
||||
|
||||
contract DAO {
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ This interface must be inherited by a ERC20 token contract that wants to exchang
|
|||
##### exchnagedWith
|
||||
This mapping stores the number of tokens exchanged with another token, along with the latter’s address. Every time more tokens are exchanged the integer value is incremented consequently. This mapping acts as a record to denote which target contract holds our tokens.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
mapping ( address => uint ) private exchangedWith;
|
||||
```
|
||||
##### exchangedBy
|
||||
This mapping stores the address of the person who initiated the exchange and the amount of tokens exchanged.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
mapping ( address => uint ) private exhangedBy;
|
||||
```
|
||||
|
||||
|
|
@ -43,14 +43,14 @@ NOTE: Callers MUST handle false from returns (bool success). Callers MUST NOT as
|
|||
##### exchangeToken
|
||||
This function calls the intermediate exchange service contract that handles the exchanges. This function takes the address of the target contract and the amount we want to exchange as parameters and returns boolean `success` and `creditedAmount`.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
function exchangeToken(address _targetContract, uint _amount) public returns(bool success, uint creditedAmount)
|
||||
```
|
||||
|
||||
##### exchangeAndSpend
|
||||
This function calls an intermediate exchange service contract that handles exchange and expenditure. This function takes the address of the target contract, the amount we want to spend in terms of target contract tokens and address of the receiver as parameters and returns boolean `success`.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
function exchangeAndSpend(address _targetContract, uint _amount,address _to) public returns(bool success)
|
||||
```
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ This function is called by the exchange service contract to our token contract t
|
|||
|
||||
NOTE: It is required that only the exchange service contract has the authority to call this function.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
function __exchangerCallback(address _targetContract,address _exchanger, uint _amount) public returns(bool success)
|
||||
```
|
||||
|
||||
|
|
@ -68,14 +68,14 @@ function __exchangerCallback(address _targetContract,address _exchanger, uint _a
|
|||
##### Exchange
|
||||
This event logs any new exchanges that have taken place.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
event Exchange(address _from, address _ targetContract, uint _amount)
|
||||
```
|
||||
|
||||
##### ExchangeSpent
|
||||
This event logs any new exchange that have taken place and have been spent immediately.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
event ExchangeSpent(address _from, address _targetContract, address _to, uint _amount)
|
||||
```
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ This interface must be inherited by a ERC20 token contract that wants to receive
|
|||
##### exchangesRecieved
|
||||
This mapping stores the number of tokens received in terms of another token, along with its address. Every time more tokens are exchanged the integer value is incremented consequently. This mapping acts as a record to denote which tokens do this contract holds apart from its own.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
mapping ( address => uint ) private exchnagesReceived;
|
||||
```
|
||||
#### Methods
|
||||
|
|
@ -98,7 +98,7 @@ This function is called by the intermediate exchange service contract. This func
|
|||
|
||||
NOTE: It is required that only the exchange service contract has the authority to call this function.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
function __targetExchangeCallback (uint _to, uint _amount) public returns(bool success)
|
||||
```
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ This function is called by the intermediate exchange service contract. This func
|
|||
|
||||
NOTE: It is required that only the exchange service contract has the authority to call this function.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
function __targetExchangeAndSpendCallback (address _from, address _to, uint _amount) public returns(bool success)
|
||||
```
|
||||
|
||||
|
|
@ -115,13 +115,13 @@ function __targetExchangeAndSpendCallback (address _from, address _to, uint _amo
|
|||
##### Exchange
|
||||
This event logs any new exchanges that have taken place.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
event Exchange(address _from, address _with, uint _amount)
|
||||
```
|
||||
|
||||
##### ExchangeSpent
|
||||
This event logs any new exchange that have taken place and have been spent immediately.
|
||||
``` js
|
||||
```solidity
|
||||
event ExchangeSpent(address _from, address _ targetContract, address _to, uint _amount)
|
||||
```
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ This is an intermediate contract that provides a gateway for exchanges and expen
|
|||
|
||||
This array stores all the tokens that are registered for exchange. Only register tokens can participate in exhanges.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
address[] private registeredTokens;
|
||||
```
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ This function is called by the owner of the token contract to get it’s tokens
|
|||
|
||||
NOTE: Before any exchange it must be ensured that the token is registered.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
function registerToken(address _token) public returns(bool success)
|
||||
```
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ function registerToken(address _token) public returns(bool success)
|
|||
|
||||
This function is called by the token holder who wants to exchange his token with the `_targetContract` tokens. This function queries the exchange rate, calculates the converted amount, calls `__exchangerCallback` and calls the `__targetExchangeCallback`. It takes address of the target contract and amount to exchange as parameter and returns boolean `success` and amount credited.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
function exchangeToken(address _targetContract, uint _amount, address _from) public returns(bool success, uint creditedAmount)
|
||||
```
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ function exchangeToken(address _targetContract, uint _amount, address _from) pub
|
|||
|
||||
This function is called by the token holder who wants to exchange his token with the `_targetContract` tokens. This function queries the exchange rate, calculates the converted amount, calls `__exchangerCallback` and calls the `__targetExchangeAndSpendCallback`. It takes address of the target contract and amount to exchange as parameter and returns boolean `success` and amount credited.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
function exchangeAndSpend(address _targetContract, uint _amount, address _from, address _to) public returns(bool success)
|
||||
```
|
||||
|
||||
|
|
@ -173,14 +173,14 @@ function exchangeAndSpend(address _targetContract, uint _amount, address _from,
|
|||
|
||||
This event logs any new exchanges that have taken place.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
event Exchange( address _from, address _by, uint _value ,address _target )
|
||||
```
|
||||
##### ExchangeAndSpent
|
||||
|
||||
This event logs any new exchange that have taken place and have been spent immediately.
|
||||
|
||||
``` js
|
||||
```solidity
|
||||
event ExchangeAndSpent ( address _from, address _by, uint _value ,address _target ,address _to)
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ Some protections need to be added to the message such as encoding the chain id,
|
|||
|
||||
## Interface
|
||||
|
||||
```
|
||||
```solidity
|
||||
contract ERC165
|
||||
{
|
||||
/// @notice Query if a contract implements an interface
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ An increasing set of use cases require storage of metadata associated with an ad
|
|||
|
||||
## Specification
|
||||
The metadata registry has the following interface:
|
||||
```
|
||||
```solidity
|
||||
interface AddressMetadataRegistry {
|
||||
function provider(address target) view returns(address);
|
||||
function setProvider(address _provider);
|
||||
|
|
@ -34,7 +34,7 @@ Providers may implement any subset of the metadata record types specified here.
|
|||
|
||||
Providers have one mandatory function:
|
||||
|
||||
```
|
||||
```solidity
|
||||
function supportsInterface(bytes4 interfaceID) constant returns (bool)
|
||||
```
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ There are no backwards compatibility concerns.
|
|||
|
||||
## Implementation
|
||||
The canonical implementation of the metadata registry is as follows:
|
||||
```
|
||||
```solidity
|
||||
contract AddressMetadataRegistry {
|
||||
mapping(address=>address) public provider;
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ The pattern implemented here is inspired by [ds-auth](https://github.com/dapphub
|
|||
## Specification
|
||||
The generalised authorisation interface is implemented as a metadata provider, as specified in EIP 926. The following mandatory function is implemented:
|
||||
|
||||
```
|
||||
```solidity
|
||||
function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool);
|
||||
```
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ As this standard uses EIP 926, the authorisation flow is as follows:
|
|||
|
||||
Commonly, providers will wish to supply a standardised interface for users to set and unset their own authorisations. They SHOULD implement the following interface:
|
||||
|
||||
```
|
||||
```solidity
|
||||
function authoriseCaller(address owner, address caller, address callee, bytes4 func);
|
||||
function revokeCaller(address owner, address caller, address callee, bytes4 func);
|
||||
```
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
10
README.md
10
README.md
|
|
@ -41,7 +41,7 @@ The canonical URL for a EIP that has achieved draft status at any point is at ht
|
|||
EIPs must pass some validation tests. The EIP repository ensures this by running tests using [html-proofer](https://rubygems.org/gems/html-proofer) and [eip_validator](https://rubygems.org/gems/eip_validator).
|
||||
|
||||
It is possible to run the EIP validator locally:
|
||||
```
|
||||
```sh
|
||||
gem install eip_validator
|
||||
eip_validator <INPUT_FILES>
|
||||
```
|
||||
|
|
@ -58,7 +58,7 @@ The EIP repository contains an "auto merge" feature to ease the workload for EIP
|
|||
|
||||
2. Check whether you have Ruby 2.1.0 or higher installed:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ ruby --version
|
||||
```
|
||||
|
||||
|
|
@ -66,13 +66,13 @@ $ ruby --version
|
|||
|
||||
4. Install Bundler:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ gem install bundler
|
||||
```
|
||||
|
||||
5. Install dependencies:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ bundle install
|
||||
```
|
||||
|
||||
|
|
@ -80,7 +80,7 @@ $ bundle install
|
|||
|
||||
1. Bundle assets and start the server:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ bundle exec jekyll serve
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue