mirror of https://github.com/status-im/EIPs.git
Merge branch 'master' into patch-1
This commit is contained in:
Nick Johnson
GitHub
commit
009ab6db1c
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
eip: 1109
|
||||
title: Remove CALL costs for precompiled contracts
|
||||
title: PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts)
|
||||
author: Jordi Baylina (@jbaylina)
|
||||
discussions-to: https://ethereum-magicians.org/t/eip-1109-remove-call-costs-for-precompiled-contracts/447
|
||||
status: Draft
|
||||
|
|
@ -11,45 +11,73 @@ created: 2018-05-22
|
|||
|
||||
## Simple Summary
|
||||
|
||||
This EIP removes the gas costs of the CALL-like opcodes when calling precompiled contracts.
|
||||
This EIP creates a specific OPCODE named "PRECOMPILEDCALL" to call Precompiled contracts without the costs of a normal CALL.
|
||||
|
||||
## Abstract
|
||||
|
||||
This EIP tries to resolve the problem of high gas consumption when calling precompiled contracts with a small gas cost. Setting the gas costs to 0 when calling a precompiled contract allows to define precompiled contracts whose effective cost when calling it is less than 700.
|
||||
This EIP tries to resolve the problem of high gas consumption when calling precompiled contracts with a small gas cost. Using this opcode for calling precompiled contracts allows to define precompiled contracts whose effective cost it is less than 700.
|
||||
|
||||
## Motivation
|
||||
|
||||
Each precompiled contract has an already defined a cost for calling it. It does not make sense to add the implicit extra gas cost of the CALL opcode.
|
||||
Each precompiled contract has an already defined cost for calling it. It does not make sense to add the implicit extra gas cost of the CALL opcode.
|
||||
|
||||
As an example, SHA256 precompiled contract costs 60 and ECADD costs 500 (proposed to costs only 50 in [EIP1108](https://github.com/ethereum/EIPs/pull/1108) . When a precompiled contract is called, 700 gas is consumed just for the CALL opcode besides the costs of the precompiled contract.
|
||||
|
||||
This makes no sense, and right now it's impossible to define a precompiled contract whose effective cost for using it is less than 700.
|
||||
This makes no sense, and right now it's impossible to define a precompiled contract whose effective cost for using it, is less than 700.
|
||||
|
||||
## Specification
|
||||
|
||||
If `block.number >= XXXXX`, for each CALL, DELEGATECALL and CALLCODE opcode with a destination address < 256 use a Gcall (basic cost of the call) of 0 instead of 700.
|
||||
If `block.number >= XXXXX`, define a new opcode named PRECOMPILEDCALL with code value 0xfb .
|
||||
|
||||
The gas cost of the OPCODE is 2 (Gbase) plus the Specific gas cost defined for each specific precompiled smart contract.
|
||||
|
||||
The OPCODE takes 5 words from the stack and returns 1 word to the stack.
|
||||
|
||||
The input stack values are:
|
||||
|
||||
mu_s[0] = The address of the precompiled smart contract that is called.
|
||||
mu_s[1] = Pointer to memory for the input parameters.
|
||||
mu_s[2] = Length of the input parametes in bytes.
|
||||
mu_s[3] = Pointer to memory where the output is stored
|
||||
mu_s[4] = Length of the output buffer.
|
||||
|
||||
|
||||
The return will be 1 in case of success call and 0 in any of the next cases:
|
||||
|
||||
1.- mu_s[0] is an address of an undefined precompiled smart contract.
|
||||
2.- The precompiled smart contract fails (as defined on each smart contract). Invalid input parameters for example.
|
||||
|
||||
Precompiled smart contracs, does not execute opcodes, so there is no need to pass a gas parameter as a normal CALL. If the available gas is less that 2 plus the required gas required for the specific precompiled smart cotract, the context just STOPS executing with an "Out of Gas" error.
|
||||
|
||||
There is no stack check for this call.
|
||||
|
||||
The normal CALLs to the precompiled smart contracts continue to work with the exact same behavior.
|
||||
|
||||
A PRECOMPILEDCALL to a regular address or regular smart contract, is considered a call to an "undefined smart contract", so the VM MUST not execute it and the opcode must return 0x0 .
|
||||
|
||||
The cost of the CALL opcode is calculated in exactly the same way that any normal call, including the cost for using a value different than 0 and for creating a new account. The only difference is that Gcall is not added when calculating Cextra.
|
||||
|
||||
## Rationale
|
||||
|
||||
This implementation is the one that needs less modification of the clients.
|
||||
There was a first proposal for removing the gast consts for the CALL, but it looks that it's easier to implement and test a new opcode just for that.
|
||||
|
||||
The code is just the next opcode available after the STATICCALL opcode.
|
||||
|
||||
## Backwards Compatibility
|
||||
|
||||
This EIP is backwards compatible. Smart contracts that call precompiled contracts will cost less from now on. Smart contracts that relay in a high gas consumption for a specific code are not expected.
|
||||
This EIP is backwards compatible. Smart contracts that call precompiled contracts using this new opcode will cost less from now on.
|
||||
|
||||
Old contracts that call precompiled smart contracts with the CALL method, will continue working.
|
||||
|
||||
## Test Cases
|
||||
|
||||
- Normal call to a defined precompiled contract.
|
||||
- Call to undefined precompiled contract.
|
||||
- Call to defined precompiled contract with a value!=0 on the call.
|
||||
- Call to undefined precompiled contract with a value!=0 on the call.
|
||||
- Normal call to precompiled contract with remaining gas<700 but gas>[the cost of the call].
|
||||
- Call to a precompiled contract which forwards all gas but
|
||||
* 600
|
||||
* 700
|
||||
* 701
|
||||
- Call to a regular contract
|
||||
- Call to a regular account
|
||||
- Call to 0x0 smart contract (Does not exists).
|
||||
- Call with large values for the offste pointers and lenghts
|
||||
- Call with the exact gas remaining needed to call smart contract.
|
||||
- Call with the exact gas remaining minus one needed to call smart contract.
|
||||
|
||||
## Implementation
|
||||
|
||||
|
|
|
|||
426
EIPS/eip-1155.md
426
EIPS/eip-1155.md
|
|
@ -15,9 +15,9 @@ A standard interface for multiple item/token definitions in a single deployed co
|
|||
|
||||
## Abstract
|
||||
|
||||
This standard proposes a new monolithic token contract that can mint any quantity of Fungible and Non-Fungible tokens in the same contract. We call these "Items" as they differ from the existing standards by being full definitions and configurations of multiple tokens inside a single contract. Standards like ERC-20 require deployment of separate contracts per token. The ERC-721 standard's Token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. Instead, the Crypto Item Standard allows for each Item ID to represent a new configurable token type, which may have its own totalSupply value and other such attributes.
|
||||
This standard outlines a smart contract interface where one can represent any number of Fungible and Non-Fungible assets in a single contract. Existing standards such as ERC-20 require deployment of separate contracts per token. The ERC-721 standard's Token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. Instead, the ERC-1155 Crypto Item Standard allows for each Item ID to represent a new configurable token type, which may have its own totalSupply value and other such attributes.
|
||||
|
||||
The `_itemId` parameter is named as such and placed at the beginning of each function.
|
||||
The `_id` parameter is contained in each function's parameters and indicates a specific item or item type in a transaction.
|
||||
|
||||
## Motivation
|
||||
|
||||
|
|
@ -27,126 +27,305 @@ New functionality is possible with this design, such as transferring or approvin
|
|||
|
||||
## Specification
|
||||
|
||||
```
|
||||
solidity
|
||||
interface ICryptoItems {
|
||||
// Events
|
||||
event Transfer(uint256 indexed _itemId, address indexed _from, address indexed _to, uint256 _value);
|
||||
event Approval(uint256 indexed _itemId, address indexed _owner, address indexed _spender, uint256 _value);
|
||||
```solidity
|
||||
pragma solidity ^0.4.24;
|
||||
|
||||
// Required Functions
|
||||
function transfer(uint256[] _itemId, address[] _to, uint256[] _value) external returns (bool success);
|
||||
function transferFrom(uint256[] _itemId, address[] _from, address[] _to, uint256[] _value) external returns (bool success);
|
||||
function approve(uint256[] _itemId, address[] _spender, uint256[] _value) external returns (bool success);
|
||||
function increaseApproval(uint256[] _itemId, address[] _spender, uint256[] _addedValue) external returns (bool success);
|
||||
function decreaseApproval(uint256[] _itemId, address[] _spender, uint256[] _subtractedValue) external returns (bool success);
|
||||
/**
|
||||
@title ERC-1155 Crypto Items Standard
|
||||
@dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
|
||||
Note: the ERC-165 identifier for this interface is 0xf23a6e61.
|
||||
*/
|
||||
interface IERC1155 {
|
||||
/**
|
||||
@dev MUST trigger on any successful call to approve(address _spender, uint256 _value)
|
||||
*/
|
||||
event Approval(address indexed _owner, address indexed _spender, uint256 indexed _id, uint256 _oldValue, uint256 _value);
|
||||
|
||||
/**
|
||||
@dev MUST trigger when tokens are transferred, including zero value transfers
|
||||
This emits when ownership of any NFT changes by any mechanism.
|
||||
This event emits when NFTs are created (`from` == 0) and destroyed
|
||||
(`to` == 0). Exception: during contract creation, any number of NFTs
|
||||
may be created and assigned without emitting Transfer. At the time of
|
||||
any transfer, the approved address for that NFT (if any) is reset to none.
|
||||
*/
|
||||
event Transfer(address _spender, address indexed _from, address indexed _to, uint256 indexed _id, uint256 _value);
|
||||
|
||||
// Required View Functions
|
||||
function totalSupply(uint256 _itemId) external view returns (uint256);
|
||||
function balanceOf(uint256 _itemId, address _owner) external view returns (uint256);
|
||||
function allowance(uint256 _itemId, address _owner, address _spender) external view returns (uint256);
|
||||
|
||||
// Optional View Functions
|
||||
function name(uint256 _itemId) external view returns (string);
|
||||
function symbol(uint256 _itemId) external view returns (string);
|
||||
function decimals(uint256 _itemId) external view returns (uint8);
|
||||
|
||||
// Optional Functions for Non-Fungible Items
|
||||
function ownerOf(uint256 _itemId) external view returns (address);
|
||||
function itemURI(uint256 _itemId) external view returns (string);
|
||||
function itemByIndex(uint256 _itemId, uint256 _index) external view returns (uint256);
|
||||
function itemOfOwnerByIndex(uint256 _itemId, address _owner, uint256 _index) external view returns (uint256);
|
||||
/**
|
||||
@dev Transfers value amount of an _id from the _from address to the _to addresses specified. Each parameter array should be the same length, with each index correlating.
|
||||
Caller must have a sufficient allowance by _from for the _id/_value pair
|
||||
@param _from source addresses
|
||||
@param _to target addresses
|
||||
@param _id ID of the CryptoItem
|
||||
@param _value transfer amounts
|
||||
*/
|
||||
function transferFrom(address _from, address _to, uint256 _id, uint256 _value) external;
|
||||
|
||||
/**
|
||||
@dev Transfers value amount of an _id from the _from address to the _to addresses specified. Each parameter array should be the same length, with each index correlating.
|
||||
Caller must have a sufficient allowance by _from for the _id/_value pair
|
||||
Throws if `_to` is the zero address.
|
||||
Throws if `_id` is not a valid NFT.
|
||||
When transfer is complete, this function checks if `_to` is a smart contract (code size > 0). If so, it calls `onERC1155Received` on `_to` and throws if the return value is not `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))`.
|
||||
@param _from source addresses
|
||||
@param _to target addresses
|
||||
@param _id ID of the CryptoItem
|
||||
@param _value transfer amounts
|
||||
@param _data Additional data with no specified format, sent in call to `_to`
|
||||
*/
|
||||
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes _data) external;
|
||||
|
||||
/**
|
||||
@dev Allow other accounts/contracts to spend tokens on behalf of msg.sender
|
||||
Also, to minimize the risk of the approve/transferFrom attack vector
|
||||
(see https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/), this function will throw if the current approved allowance does not equal the expected _currentValue, unless _value is 0
|
||||
@param _spender Address to approve
|
||||
@param _id ID of the CryptoItem
|
||||
@param _currentValue Expected current value of approved allowance.
|
||||
@param _value Allowance amount
|
||||
*/
|
||||
function approve(address _spender, uint256 _id, uint256 _currentValue, uint256 _value) external;
|
||||
|
||||
/**
|
||||
@dev Get the balance of an account's CryptoItems
|
||||
@param _id ID of the CryptoItem
|
||||
@param _owner The address of the token holder
|
||||
@return The _owner's balance of the CryptoItem type requested
|
||||
*/
|
||||
function balanceOf(uint256 _id, address _owner) external view returns (uint256);
|
||||
|
||||
/**
|
||||
@dev Queries the spending limit approved for an account
|
||||
@param _id ID of the CryptoItem
|
||||
@param _owner The owner allowing the spending
|
||||
@param _spender The address allowed to spend.
|
||||
@return The _spender's allowed spending balance of the CryptoItem requested
|
||||
*/
|
||||
function allowance(uint256 _id, address _owner, address _spender) external view returns (uint256);
|
||||
}
|
||||
```
|
||||
|
||||
### transfer
|
||||
<details>
|
||||
<summary>
|
||||
Simple/Extended Transfers</summary>
|
||||
|
||||
Transfers quantities of each `_itemId[]` to the addresses specified.
|
||||
Each parameter array should be the same length, with each index correlating.
|
||||
```solidity
|
||||
interface IERC1155Extended {
|
||||
/**
|
||||
@dev Send a single type of CryptoItem
|
||||
@param _to Transfer destination address
|
||||
@param _id ID of the CryptoItem
|
||||
@param _value Transfer amount
|
||||
*/
|
||||
function transfer(address _to, uint256 _id, uint256 _value) external;
|
||||
|
||||
/**
|
||||
@dev Send a single type of CryptoItem (with safety call)
|
||||
@param _to Transfer destination address
|
||||
@param _id ID of the CryptoItem
|
||||
@param _value Transfer amount
|
||||
@param _data Additional data with no specified format, sent in call to `_to`
|
||||
*/
|
||||
function safeTransfer(address _to, uint256 _id, uint256 _value, bytes _data) external;
|
||||
}
|
||||
```
|
||||
|
||||
MUST trigger `Transfer` event.
|
||||
</details>
|
||||
|
||||
### transferFrom
|
||||
<details>
|
||||
<summary>
|
||||
Batch Transfers</summary>
|
||||
|
||||
Transfers quantities of each `_itemId[]` from one or more `_from[]` addresses to the `_to[]` addresses specified.
|
||||
Each parameter array should be the same length, with each index correlating.
|
||||
```solidity
|
||||
interface IERC1155BatchTransfer {
|
||||
/**
|
||||
@dev Send multiple types of CryptoItems from a 3rd party in one transfer
|
||||
For the purpose of transfer fees, each id/value pair is counted as a transfer
|
||||
Caller must have a sufficient allowance by _from for each of the _id/_value pairs
|
||||
Throws on any error rather than return a false flag to minimize user errors
|
||||
@param _from Source address
|
||||
@param _to Target address
|
||||
@param _ids Types of CryptoItems
|
||||
@param _values Transfer amounts per item type
|
||||
*/
|
||||
function batchTransferFrom(address _from, address _to, uint256[] _ids, uint256[] _values) external;
|
||||
|
||||
/**
|
||||
@dev Send multiple types of CryptoItems from a 3rd party in one transfer (with safety call)
|
||||
For the purpose of transfer fees, each id/value pair is counted as a transfer
|
||||
Caller must have a sufficient allowance by _from for each of the _id/_value pairs
|
||||
Throws on any error rather than return a false flag to minimize user errors
|
||||
@param _from Source address
|
||||
@param _to Target address
|
||||
@param _ids Types of CryptoItems
|
||||
@param _values Transfer amounts per item type
|
||||
@param _data Additional data with no specified format, sent in call to `_to`
|
||||
*/
|
||||
function safeBatchTransferFrom(address _from, address _to, uint256[] _ids, uint256[] _values, bytes _data) external;
|
||||
|
||||
/**
|
||||
@dev Allow other accounts/contracts to spend tokens on behalf of msg.sender
|
||||
Also, to minimize the risk of the approve/transferFrom attack vector
|
||||
(see https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/), this function will throw if the current approved allowance does not equal the expected _currentValue, unless _value is 0
|
||||
@param _spender Address to approve
|
||||
@param _ids IDs of the CryptoItems
|
||||
@param _currentValues Expected current values of allowances per item type
|
||||
@param _values Allowance amounts per item type
|
||||
*/
|
||||
function batchApprove(address _spender, uint256[] _ids, uint256[] _currentValues, uint256[] _values) external;
|
||||
}
|
||||
```
|
||||
|
||||
MUST trigger `Transfer` event.
|
||||
</details>
|
||||
|
||||
### approve
|
||||
<details>
|
||||
<summary>
|
||||
Simple/Extended Batch Transfers</summary>
|
||||
|
||||
Approves an account for the ability to transfer a maximum quantity of multiple `_itemId[]` on behalf of another account (using transferFrom).
|
||||
Each parameter array should be the same length, with each index correlating.
|
||||
```solidity
|
||||
interface IERC1155BatchTransferExtended {
|
||||
/**
|
||||
@dev Send multiple types of CryptoItems in one transfer
|
||||
For the purpose of transfer fees, each id/value pair is counted as a transfer
|
||||
@param _to Transfer destination address
|
||||
@param _ids IDs of the CryptoItems
|
||||
@param _values Transfer amounts per item type
|
||||
*/
|
||||
function batchTransfer(address _to, uint256[] _ids, uint256[] _values) external;
|
||||
|
||||
/**
|
||||
@dev Send multiple types of CryptoItems in one transfer (with safety call)
|
||||
For the purpose of transfer fees, each id/value pair is counted as a transfer
|
||||
@param _to Transfer destination address
|
||||
@param _ids IDs of the CryptoItems
|
||||
@param _values Transfer amounts per item type
|
||||
@param _data Additional data with no specified format, sent in call to `_to`
|
||||
*/
|
||||
function safeBatchTransfer(address _to, uint256[] _ids, uint256[] _values, bytes _data) external;
|
||||
}
|
||||
```
|
||||
|
||||
MUST trigger `Approval` event.
|
||||
</details>
|
||||
|
||||
### increaseApproval
|
||||
<details>
|
||||
<summary>
|
||||
Extended Approvals</summary>
|
||||
|
||||
Increases the allowance amount of one or more items without requiring a reset to 0.
|
||||
Each parameter array should be the same length, with each index correlating.
|
||||
```solidity
|
||||
interface IERC1155Operators {
|
||||
event OperatorApproval(address indexed _owner, address indexed _operator, uint256 indexed _id, bool _approved);
|
||||
event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
|
||||
|
||||
MUST trigger `Approval` event.
|
||||
/**
|
||||
@notice Enable or disable approval for a third party ("operator") to manage
|
||||
all of `msg.sender`'s assets for a particular CryptoItem types.
|
||||
@dev Emits the OperatorApproval event
|
||||
@param _operator Address to add to the set of authorized operators
|
||||
@param _ids The IDs of the CryptoItems
|
||||
@param _approved True if the operators is approved, false to revoke approval
|
||||
*/
|
||||
function setApproval(address _operator, uint256[] _ids, bool _approved) external;
|
||||
|
||||
/**
|
||||
@dev Queries the approval status of an operator for a given CryptoItem and owner
|
||||
@param _owner The owner of the CryptoItems
|
||||
@param _operator Address of authorized operator
|
||||
@param _id ID of the CryptoItem
|
||||
@return True if the operator is approved, false if not
|
||||
*/
|
||||
function isApproved(address _owner, address _operator, uint256 _id) external view returns (bool);
|
||||
|
||||
/**
|
||||
@notice Enable or disable approval for a third party ("operator") to manage
|
||||
all of `msg.sender`'s assets.
|
||||
@dev Emits the OperatorApproval event
|
||||
@param _operator Address to add to the set of authorized operators
|
||||
@param _approved True if the operator is approved, false to revoke approval
|
||||
*/
|
||||
function setApprovalForAll(address _operator, bool _approved) external;
|
||||
|
||||
/**
|
||||
@dev Queries the approval status of an operator for a given CryptoItem and owner
|
||||
@param _owner The owner of the CryptoItems
|
||||
@param _operator Address of authorized operator
|
||||
@return True if the operator is approved, false if not
|
||||
*/
|
||||
function isApprovedForAll(address _owner, address _operator) external view returns (bool isOperator);
|
||||
}
|
||||
```
|
||||
|
||||
### decreaseApproval
|
||||
</details>
|
||||
|
||||
Decreases the allowance amount of one or more items without requiring a reset to 0.
|
||||
Each parameter array should be the same length, with each index correlating.
|
||||
<details>
|
||||
<summary>
|
||||
Views</summary>
|
||||
|
||||
MUST trigger `Approval` event.
|
||||
```solidity
|
||||
interface IERC1155Views {
|
||||
/**
|
||||
@dev Returns how many of a CryptoItem are deemed or expected to exist in circulation
|
||||
@param _id ID of the CryptoItem
|
||||
@return The number of CryptoItems in circulation
|
||||
*/
|
||||
function totalSupply(uint256 _id) external view returns (uint256);
|
||||
|
||||
/**
|
||||
@dev Returns a human readable string that identifies a CryptoItem, similar to ERC20
|
||||
@param _id ID of the CryptoItem
|
||||
@return The name of the CryptoItem type
|
||||
*/
|
||||
function name(uint256 _id) external view returns (string);
|
||||
|
||||
/**
|
||||
@dev Returns symbol of a CryptoItem, similar to ERC20 and ERC721
|
||||
@param _id ID of the CryptoItem
|
||||
@return The symbol of the CryptoItem
|
||||
*/
|
||||
function symbol(uint256 _id) external view returns (string);
|
||||
|
||||
/**
|
||||
@dev Returns the number of decimal places for a CryptoItem, similar to ERC20
|
||||
@param _id ID of the CryptoItem
|
||||
@return Number of decimals
|
||||
*/
|
||||
function decimals(uint256 _id) external view returns (uint8);
|
||||
|
||||
/**
|
||||
@notice A distinct Uniform Resource Identifier (URI) for a given asset
|
||||
@dev URIs are defined in RFC 3986
|
||||
@return URI string
|
||||
*/
|
||||
function uri(uint256 _id) external view returns (string);
|
||||
}
|
||||
```
|
||||
|
||||
### name
|
||||
</details>
|
||||
|
||||
Returns the Item ID's name.
|
||||
<details>
|
||||
<summary>
|
||||
ERC-1155 Token Receiver</summary>
|
||||
|
||||
This function is OPTIONAL but highly recommended.
|
||||
```solidity
|
||||
interface IERC1155TokenReceiver {
|
||||
/**
|
||||
@notice Handle the receipt of an ERC1155 type
|
||||
@dev The smart contract calls this function on the recipient
|
||||
after a `safeTransfer`. This function MAY throw to revert and reject the
|
||||
transfer. Return of other than the magic value MUST result in the
|
||||
transaction being reverted
|
||||
Note: the contract address is always the message sender
|
||||
@param _operator The address which called `safeTransferFrom` function
|
||||
@param _from The address which previously owned the token
|
||||
@param _id The identifier of the item being transferred
|
||||
@param _value The amount of the item being transferred
|
||||
@param _data Additional data with no specified format
|
||||
@return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))`
|
||||
*/
|
||||
function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes _data) external returns(bytes4);
|
||||
}
|
||||
```
|
||||
|
||||
### symbol
|
||||
|
||||
Returns the Item ID's symbol.
|
||||
|
||||
This function is OPTIONAL.
|
||||
|
||||
### decimals
|
||||
|
||||
Returns the Item ID's decimals.
|
||||
|
||||
This function is OPTIONAL but highly recommended.
|
||||
|
||||
### totalSupply
|
||||
|
||||
Returns the Item ID's totalSupply.
|
||||
|
||||
### balanceOf
|
||||
|
||||
Returns an account's balance of specified Item ID.
|
||||
|
||||
### allowance
|
||||
|
||||
Returns the allowance set by any of the approve functions.
|
||||
|
||||
### ownerOf
|
||||
|
||||
For NFTs, this returns the owner of a specific `_itemId`.
|
||||
|
||||
This function is OPTIONAL.
|
||||
|
||||
### itemURI
|
||||
|
||||
Returns a distinct Uniform Resource Identifier (URI) for a given `_itemId`.
|
||||
|
||||
This function is OPTIONAL.
|
||||
|
||||
### itemByIndex
|
||||
|
||||
Enumerate valid NFTs.
|
||||
|
||||
This function is OPTIONAL.
|
||||
|
||||
### itemOfOwnerByIndex
|
||||
|
||||
Enumerate NFTs assigned to an owner.
|
||||
|
||||
This function is OPTIONAL.
|
||||
</details>
|
||||
|
||||
## Non-Fungible Items
|
||||
|
||||
|
|
@ -156,9 +335,55 @@ Non-Fungible Items can be interacted with using an index based accessor into the
|
|||
|
||||
Inside the contract code the two pieces of data needed to access the individual NFT can be extracted with uint128(~0) and the same mask shifted by 128.
|
||||
|
||||
### Interface
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
Optional Non Fungible Interface</summary>
|
||||
|
||||
```solidity
|
||||
interface IERC1155NonFungible {
|
||||
/**
|
||||
@notice Find the owner of an NFT
|
||||
@dev NFTs assigned to zero address are considered invalid, and queries about them do throw
|
||||
@param _id The identifier for an NFT
|
||||
@return The address of the owner of the NFT
|
||||
*/
|
||||
function ownerOf(uint256 _id) external view returns (address);
|
||||
|
||||
/**
|
||||
@notice Enumerate valid NFs
|
||||
@dev Throws if `_index` >= `totalSupply()`.
|
||||
@param _index A counter less than `totalSupply()`
|
||||
@return The token identifier for the `_index`th NFT (sort order not specified)
|
||||
*/
|
||||
function nonFungibleByIndex(uint256 _id, uint128 _index) external view returns (uint256);
|
||||
|
||||
/**
|
||||
@notice Enumerate NFTs assigned to an owner
|
||||
@dev Throws if `_index` >= `balanceOf(_owner)` or if
|
||||
`_owner` is the zero address, representing invalid NFTs
|
||||
@param _owner An address where we are interested in NFTs owned by them
|
||||
@param _index A counter less than `balanceOf(_owner)`
|
||||
@return The token identifier for the `_index`th NFT assigned to `_owner` (sort order not specified)
|
||||
*/
|
||||
function nonFungibleOfOwnerByIndex(uint256 _id, address _owner, uint128 _index) external view returns (uint256);
|
||||
|
||||
/**
|
||||
@notice Is this token non fungible?
|
||||
@dev If this returns true, the token is non-fungible.
|
||||
@param _id The identifier for a potential non-fungible.
|
||||
@return True if the token is non-fungible
|
||||
*/
|
||||
function isNonFungible(uint256 _id) external view returns (bool);
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Example of split ID bits
|
||||
|
||||
```
|
||||
```solidity
|
||||
uint256 baseToken = 12345 << 128;
|
||||
uint128 index = 50;
|
||||
|
||||
|
|
@ -168,6 +393,7 @@ balanceOf(baseToken + index, msg.sender); // Get balance of the Non-Fungible tok
|
|||
|
||||
## Implementation
|
||||
|
||||
- [ERC-1155 Reference Implementation](https://github.com/enjin/erc-1155)
|
||||
- [Enjin Coin](https://enjincoin.io) ([github](https://github.com/enjin))
|
||||
|
||||
## Copyright
|
||||
|
|
|
|||
|
|
@ -191,11 +191,31 @@ anticipated, and many contract will see gas reduction.
|
|||
|
||||
## Test Cases
|
||||
|
||||
To be added.
|
||||
Below we provide 17 test cases. 15 of them covering consecutive two
|
||||
`SSTORE` operations are based on work [by
|
||||
@chfast](https://github.com/ethereum/tests/issues/483). Two additional
|
||||
case with three `SSTORE` operations is used to test the case when a
|
||||
slot is reset and then set again.
|
||||
|
||||
## Implementation
|
||||
|
||||
To be added.
|
||||
| Code | Used Gas | Refund | Original | 1st | 2nd | 3rd |
|
||||
|------------------------------------|----------|--------|----------|-----|-----|-----|
|
||||
| `0x60006000556000600055` | 412 | 0 | 0 | 0 | 0 | |
|
||||
| `0x60006000556001600055` | 20212 | 0 | 0 | 0 | 1 | |
|
||||
| `0x60016000556000600055` | 20212 | 19800 | 0 | 1 | 0 | |
|
||||
| `0x60016000556002600055` | 20212 | 0 | 0 | 1 | 2 | |
|
||||
| `0x60016000556001600055` | 20212 | 0 | 0 | 1 | 1 | |
|
||||
| `0x60006000556000600055` | 5212 | 15000 | 1 | 0 | 0 | |
|
||||
| `0x60006000556001600055` | 5212 | 4800 | 1 | 0 | 1 | |
|
||||
| `0x60006000556002600055` | 5212 | 0 | 1 | 0 | 2 | |
|
||||
| `0x60026000556000600055` | 5212 | 15000 | 1 | 2 | 0 | |
|
||||
| `0x60026000556003600055` | 5212 | 0 | 1 | 2 | 3 | |
|
||||
| `0x60026000556001600055` | 5212 | 4800 | 1 | 2 | 1 | |
|
||||
| `0x60026000556002600055` | 5212 | 0 | 1 | 2 | 2 | |
|
||||
| `0x60016000556000600055` | 5212 | 15000 | 1 | 1 | 0 | |
|
||||
| `0x60016000556002600055` | 5212 | 0 | 1 | 1 | 2 | |
|
||||
| `0x60016000556001600055` | 412 | 0 | 1 | 1 | 1 | |
|
||||
| `0x600160005560006000556001600055` | 40218 | 19800 | 0 | 1 | 0 | 1 |
|
||||
| `0x600060005560016000556000600055` | 10218 | 19800 | 1 | 0 | 1 | 0 |
|
||||
|
||||
## Copyright
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 1295
|
||||
title: Modify Ethereum PoW Incentive Structure and Diffuse Difficulty Bomb
|
||||
author: <Brian Venturo (@atlanticcrypto)>
|
||||
author: Brian Venturo (@atlanticcrypto)
|
||||
discussions-to: https://github.com/atlanticcrypto/Discussion/issues/1
|
||||
status: Draft
|
||||
type: Standards Track
|
||||
|
|
|
|||
|
|
@ -0,0 +1,160 @@
|
|||
---
|
||||
eip: 1319
|
||||
title: Smart Contract Package Registry Interface
|
||||
author: Piper Merriam <piper@ethereum.org>, Christopher Gewecke <christophergewecke@gmail.com>, g. nicholas d'andrea <nick.dandrea@consensys.net>
|
||||
type: Standards Track
|
||||
category: ERC
|
||||
status: Draft
|
||||
created: 2018-08-13
|
||||
discussions-to: https://github.com/ethereum/EIPs/issues/1319
|
||||
---
|
||||
|
||||
## Simple Summary
|
||||
A standard interface for smart contract package registries.
|
||||
|
||||
## Abstract
|
||||
This EIP specifies an interface for publishing to and retrieving assets from smart contract package registries. It is a companion EIP to [1123](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1123.md) which defines a standard for smart contract package manifests.
|
||||
|
||||
## Motivation
|
||||
The goal is to establish a framework that allows smart contract publishers to design and deploy code registries with arbitrary business logic while exposing a set of common endpoints that tooling can use to retrieve assets for contract consumers.
|
||||
|
||||
A clear standard would help the existing EthPM Package Registry evolve from a centralized, single-project community resource into a decentralized multi-registry system whose constituents are bound together by the proposed interface. In turn, these registries could be ENS name-spaced, enabling installation conventions familiar to users of `npm` and other package managers.
|
||||
|
||||
**Examples**
|
||||
```shell
|
||||
$ ethpm install packages.zeppelin.eth/Ownership
|
||||
```
|
||||
|
||||
```javascript
|
||||
const SimpleToken = await web3.packaging
|
||||
.registry('packages.ethpm.eth')
|
||||
.getPackage('simple-token')
|
||||
.getVersion('^1.1.5');
|
||||
```
|
||||
|
||||
## Specification
|
||||
The specification describes a small read/write API whose components are mandatory. It allows registries to manage versioned releases using the conventions of [semver](https://semver.org/) without imposing this as a requirement. It assumes registries will share the following structure and conventions:
|
||||
|
||||
+ a **registry** is a deployed contract which manages a collection of **packages**.
|
||||
+ a **package** is a collection of **releases**
|
||||
+ a **package** is identified by a unique string name and unique bytes32 **packageId** within a given **registry**
|
||||
+ a **release** is identified by a `bytes32` **releaseId** which must be unique for a given package name and release version string pair.
|
||||
+ a **releaseId** maps to a set of data that includes a **manifestURI** string which describes the location of an [EIP 1123 package manifest](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1123.md). This manifest contains data about the release including the location of its component code assets.
|
||||
+ a **manifestURI** is a URI as defined by [RFC3986](https://tools.ietf.org/html/rfc3986) which can be used to retrieve the contents of the package manifest. In addition to validation against RFC3986, each **manifestURI** must also contain a hash of the content as specified in the [EIP 1123](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1123.md).
|
||||
|
||||
### Examples
|
||||
|
||||
**Package Names / Release Versions**
|
||||
|
||||
```shell
|
||||
"simple-token" # package name
|
||||
"1.0.1" # version string
|
||||
```
|
||||
|
||||
**Release IDs**
|
||||
|
||||
Implementations are free to choose any scheme for generating a **releaseId**. A common approach would be to hash the strings together as below:
|
||||
|
||||
```solidity
|
||||
// Hashes package name and a release version string
|
||||
function generateReleaseId(string packageName, string version)
|
||||
public
|
||||
view
|
||||
returns (bytes32)
|
||||
{
|
||||
return keccak256(abi.encodePacked(packageName, version));
|
||||
}
|
||||
```
|
||||
Implementations **must** expose this id generation logic as part of their public `read` API so
|
||||
tooling can easily map a string based release query to the registry's unique identifier for that release.
|
||||
|
||||
**Manifest URIs**
|
||||
|
||||
Any IPFS or Swarm URI meets the definition of **manifestURI**.
|
||||
|
||||
Another example is content on GitHub addressed by its SHA-1 hash. The Base64 encoded content at this hash can be obtained by running:
|
||||
```shell
|
||||
$ curl https://api.github.com/repos/:owner/:repo/git/blobs/:file_sha
|
||||
|
||||
# Example
|
||||
$ curl https://api.github.com/repos/rstallman/hello/git/blobs/ce013625030ba8dba906f756967f9e9ca394464a
|
||||
```
|
||||
|
||||
The string "hello" can have its GitHub SHA-1 hash independently verified by comparing it to the output of:
|
||||
```shell
|
||||
$ printf "blob 6\000hello\n" | sha1sum
|
||||
> ce013625030ba8dba906f756967f9e9ca394464a
|
||||
```
|
||||
|
||||
### Write API Specification
|
||||
The write API consists of a single method, `release`. It passes the registry the package name, a
|
||||
version identifier for the release, and a URI specifying the location of a manifest which
|
||||
details the contents of the release.
|
||||
```solidity
|
||||
function release(string packageName, string version, string manifestURI) public
|
||||
returns (bytes32 releaseId);
|
||||
```
|
||||
### Read API Specification
|
||||
|
||||
The read API consists of a set of methods that allows tooling to extract all consumable data from a registry.
|
||||
|
||||
```solidity
|
||||
// Retrieves a slice of the list of all unique package identifiers in a registry.
|
||||
// `offset` and `limit` enable paginated responses / retrieval of the complete set. (See note below)
|
||||
function getAllPackageIds(uint offset, uint limit) public view
|
||||
returns (
|
||||
bytes32 packageIds,
|
||||
uint offset
|
||||
);
|
||||
|
||||
// Retrieves the unique string `name` associated with a package's id.
|
||||
function getPackageName(bytes32 packageId) public view returns (string name);
|
||||
|
||||
// Retrieves the registry's unique identifier for an existing release of a package.
|
||||
function getReleaseId(string packageName, string version) public view returns (bytes32);
|
||||
|
||||
// Retrieves a slice of the list of all release ids for a package.
|
||||
// `offset` and `limit` enable paginated responses / retrieval of the complete set. (See note below)
|
||||
function getAllReleaseIds(string packageName, uint offset, uint limit) public view
|
||||
returns (
|
||||
bytes32[] ids,
|
||||
uint offset
|
||||
);
|
||||
|
||||
// Retrieves package name, release version and URI location data for a release id.
|
||||
function getReleaseData(bytes32 releaseId) public view
|
||||
returns (
|
||||
string packageName,
|
||||
string version,
|
||||
string manifestURI
|
||||
);
|
||||
|
||||
// Retrieves the release id a registry *would* generate for a package name and version pair
|
||||
// when executing a release.
|
||||
function generateReleaseId(string packageName, string version)
|
||||
public
|
||||
view
|
||||
returns (bytes32);
|
||||
```
|
||||
**Pagination**
|
||||
|
||||
`getAllPackageIds` and `getAllReleaseIds` support paginated requests because it's possible that the return values for these methods could become quite large. The methods should return an `offset` that is a pointer to the next available item in a list of all items such that a caller can use it to pick up from where the previous request left off. (See [here](https://mixmax.com/blog/api-paging-built-the-right-way) for a discussion of the merits and demerits of various pagination strategies.) The `limit` parameter defines the maximum number of items a registry should return per request.
|
||||
|
||||
## Rationale
|
||||
The proposal hopes to accomplish the following:
|
||||
|
||||
+ Define the smallest set of inputs necessary to allow registries to map package names to a set of
|
||||
release versions while allowing them to use any versioning schema they choose.
|
||||
+ Provide the minimum set of getter methods needed to retrieve package data from a registry so that registry aggregators can read all of their data.
|
||||
+ Define a standard query that synthesizes a release identifier from a package name and version pair so that tooling can resolve specific package version requests without needing to query a registry about all of a package's releases.
|
||||
|
||||
Registries may offer more complex `read` APIs that manage requests for packages within a semver range or at `latest` etc. This EIP is agnostic about how tooling or registries might implement these. It recommends that registries implement [EIP 165](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md) and avail themselves of resources to publish more complex interfaces such as [EIP 926](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-926.md).
|
||||
|
||||
## Backwards Compatibility
|
||||
No existing standard exists for package registries. The package registry currently deployed by EthPM would not comply with the standard since it implements only one of the method signatures described in the specification.
|
||||
|
||||
## Implementation
|
||||
A reference implementation of this proposal is in active development at the EthPM organization on Github [here](https://github.com/ethpm/escape-truffle).
|
||||
|
||||
## Copyright
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
eip: 1328
|
||||
title: WalletConnect Standard URI Format
|
||||
authors: ligi <ligi@ligi.de>, Pedro Gomes <pedrouid@protonmail.com>
|
||||
type: Standards Track
|
||||
category: ERC
|
||||
status: Draft
|
||||
created: 2018-08-15
|
||||
discussions-to: https://ethereum-magicians.org/t/wallet-connect-eip/850
|
||||
requires: 831
|
||||
---
|
||||
|
||||
## Simple Summary
|
||||
|
||||
A standard to create WalletConnect URIs for establishing connections between wallets and applications.
|
||||
|
||||
## Abstract
|
||||
|
||||
This standard defines how the data to connect some application and a wallet can be encoded with a URI. This URI can then be shown either as a QR code or for mobile to mobile as a link.
|
||||
|
||||
## Specification
|
||||
|
||||
### Syntax
|
||||
|
||||
Function call URIs follow the ERC-831 URI format, with the following parameters:
|
||||
|
||||
request = "ethereum" ":" [ "wc-" ]sessionID [ "@" version ][ "?" parameters ]
|
||||
sessionID = STRING
|
||||
version = 1*DIGIT
|
||||
parameters = parameter *( "&" parameter )
|
||||
parameter = key "=" value
|
||||
key = "name" / "bridge" / "symKey"
|
||||
value = NUMBER / STRING
|
||||
|
||||
### Semantics
|
||||
|
||||
Required parameters are dependent on the WalletConnect standard version which currently is specified to only include mobile-to-desktop connection sessions which only require `name` which describes the dapp name, `bridge` which includes the bridge URL, `symKey` which includes the symmetric key in base64.
|
||||
|
||||
## Rationale
|
||||
|
||||
The need for this ERC stems from the discussion to move away from JSON format used in current beta version of the WalletConnect standard which makes for very inneficient parsing of the intent of the QR code, making it easier to create better QR code parsers APIs for Wallets to implement for other compatible EIPs using the ERC-831 URI format for Ethereum. Also by using a URI instead of a JSON inside the QR-Code the Android Intent system can be leveraged.
|
||||
|
||||
## References
|
||||
|
||||
1. ERC-831, http://eips.ethereum.org/EIPS/eip-831
|
||||
|
||||
## Copyright
|
||||
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
---
|
||||
eip: 1355
|
||||
title: Ethash 1a
|
||||
author: Paweł Bylica <pawel@ethereum.org>
|
||||
discussions-to: https://ethereum-magicians.org/t/eip-1355-ethash-1a/1167
|
||||
status: Draft
|
||||
type: Standards Track
|
||||
category: Core
|
||||
created: 2018-08-26
|
||||
---
|
||||
|
||||
## Motivation
|
||||
|
||||
Provide minimal set of changes to Ethash algorithm to hinder and delay the adoption of ASIC based mining.
|
||||
|
||||
## Specification
|
||||
|
||||
1. Define hash function `fnv1a()` as
|
||||
```python
|
||||
def fnv1a(v1, v2):
|
||||
return ((v1 ^ v2) * FNV1A_PRIME) % 2**32
|
||||
```
|
||||
where `FNV1A_PRIME` is 16777499 or 16777639.
|
||||
2. Change the hash function that determines the DAG item index in Ethash algorithm from `fnv() to new `fnv1a()`.
|
||||
In [Main Loop](https://github.com/ethereum/wiki/wiki/Ethash#main-loop) change
|
||||
```python
|
||||
p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
|
||||
```
|
||||
to
|
||||
```python
|
||||
p = fnv1a(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
|
||||
```
|
||||
|
||||
## Rationale
|
||||
|
||||
The usual argument for decentralization and network security.
|
||||
|
||||
Unless programmable, an ASIC is hardwired to perform sequential operations in a given order. fnv1a changes the order in which an exclusive-or and a multiply are applied, effectively disabling the current wave of ASICS. A second objective is minimize ethash changes to be the least disruptive, to facilitate rapid development, and to lower the analysis and test requirements. Minimizing changes to ethash reduces risk associated with updating all affected network components, and also reduces the risk of detuning existing GPUs. It's expected that this specific change would have no effect on existing GPU performance.
|
||||
|
||||
Changing fnv to fnv1a has no cryptographic implications. It is merely an efficient hash function with good dispersion characteristics used to scramble DAG indexing. We remain focused on risk mitigation by reducing the need for rigorous cryptographic analysis.
|
||||
|
||||
|
||||
### FNV Primes
|
||||
|
||||
The 16777639 satisfies all requirements from [Wikipedia](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV_prime).
|
||||
|
||||
The 16777499 is preferred by FNV authors but not used in the reference FNV implementation because of historical reasons.
|
||||
See [A few remarks on FNV primes](http://www.isthe.com/chongo/tech/comp/fnv/index.html#fnv-prime).
|
||||
|
||||
## Copyright
|
||||
|
||||
This work is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/).
|
||||
|
|
@ -61,7 +61,7 @@ var resolver = ens.resolver(node);
|
|||
Then, ask the resolver for the address for the contract:
|
||||
|
||||
```
|
||||
var hash = resolver.addr(node);
|
||||
var address = resolver.addr(node);
|
||||
```
|
||||
|
||||
Because the `namehash` procedure depends only on the name itself, this can be precomputed and inserted into a contract, removing the need for string manipulation, and permitting O(1) lookup of ENS records regardless of the number of components in the raw name.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
eip: 858
|
||||
title: Reduce block reward
|
||||
title: Reduce block reward and delay difficulty bomb
|
||||
author: Carl Larson <cslarson@gmail.com>
|
||||
type: Standards Track
|
||||
category: Core
|
||||
|
|
@ -9,30 +9,34 @@ created: 2018-01-29
|
|||
---
|
||||
|
||||
## Simple Summary
|
||||
Reduce the block reward to 1 ETH.
|
||||
Reduce the block reward to 1 ETH and delay the difficulty bomb.
|
||||
|
||||
## Abstract
|
||||
The current public Ethereum network has a hashrate that corresponds to a tremendous level of energy consumption. As this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. At this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of ETH mining. Unchecked growth in hashrate is also counterproductive from a security standpoint.
|
||||
Recent research developments also now time the switch to POS as sometime in 2019 and as a result there is need to further delay the difficulty bomb so the network doesn't grind to a halt.
|
||||
|
||||
|
||||
## Motivation
|
||||
The current public Ethereum network has a hashrate of 232 TH/s). This hashrate corresponds to a **lower bound** for power usage of roughly [821 MW](../assets/eip-858/calculations.md) and yearly energy consumption of 7.2 TWh (roughly 0.033% of [total](https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption) global electricity consumption). A future switch to full Proof of Stake will solve this issue entirely. Yet that switch remains enough in the future that action should be taken in the interim to limit excess harmful side affects of the present network.
|
||||
The current public Ethereum network has a hashrate of 296 TH/s. This hashrate corresponds to a power usage of roughly [1 TW](../assets/eip-858/calculations.md) and yearly energy consumption of 8.8 TWh (roughly 0.04% of [total](https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption) global electricity consumption). A future switch to full Proof of Stake will solve this issue entirely. Yet that switch remains enough in the future that action should be taken in the interim to limit excess harmful side affects of the present network.
|
||||
|
||||
## Specification
|
||||
Block reward to be changed to 1 ETH / block.
|
||||
If any resulting hard forks need a name for that name to maybe be Perinthos.
|
||||
|
||||
Delay difficulty bomb by 2,000,000 blocks
|
||||
Adjust block, uncle, and nephew rewards to reflect a new block reward of 1 ETH.
|
||||
|
||||
## Rationale
|
||||
partly TBD
|
||||
This will delay the difficulty bomb by roughly a year. The difficulty bomb remains a community supported mechanism to aid a future transition to POS.
|
||||
|
||||
The network hashrate provides security by reducing the likelihood that an adversary could mount a 51% attack. A static block reward means that factors (price) may be such that participation in mining grows unchecked. This growth may be counterproductive and work to also grow and potential pool of adversaries. The means we have to arrest this growth is to reduce the appeal of mining and the most direct way to do that is to reduce the block reward.
|
||||
|
||||
## Backwards Compatibility
|
||||
This EIP is consensus incompatible with the current public Ethereum chain and would cause a hard fork when enacted. The resulting fork would allow users to chose between two chains: a chain with a block reward of 1 ETH/block and another with a block reward of 3 ETH/block. This is a good choice to allow users to make.
|
||||
This EIP is consensus incompatible with the current public Ethereum chain and would cause a hard fork when enacted. The resulting fork would allow users to chose between two chains: a chain with a block reward of 1 ETH/block and another with a block reward of 3 ETH/block. This is a good choice to allow users to make. In addition, the difficulty bomb would be delayed - ensuring the network would not grind to a halt.
|
||||
|
||||
## Test Cases
|
||||
Tests have, as yet, not been completed.
|
||||
|
||||
## Implementation
|
||||
A [fork of the go repo](https://github.com/cslarson/go-ethereum/tree/reduce-block-reward) with changes to reflect a block reward reduced to 1 ETH, activated at a fork to be called Perinthos.
|
||||
No implementation including both block reward and difficulty adjustment is currently available.
|
||||
|
||||
## Copyright
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
|
|
|||
|
|
@ -37,6 +37,13 @@ With composable tokens it is possible to compose lists or trees of ERC721 and ER
|
|||
|
||||
Different composables, top-down and bottom-up, have their advantages and disadvantages which are explained in the [Rational section](#rationale). It is possible for a token to be one or more kinds of composable token.
|
||||
|
||||
A non-fungible token is ERC998 compliant and is an ERC998 Composable if it implements one or more of the following interfaces:
|
||||
|
||||
* ERC998ERC721TopDown
|
||||
* ERC998ERC20TopDown
|
||||
* ERC998ERC721BottomUp
|
||||
* ERC998ERC20BottomUp
|
||||
|
||||
## Specification
|
||||
|
||||
### ERC721
|
||||
|
|
@ -847,7 +854,7 @@ interface ERC998ERC721BottomUp {
|
|||
/// @notice Get the root owner of tokenId.
|
||||
/// @param _tokenId The token to query for a root owner address
|
||||
/// @return rootOwner The root owner at the top of tree of tokens and ERC998 magic value.
|
||||
function rootOwnerOf(uint256 _tokenId) external view returns (bytes rootOwner);
|
||||
function rootOwnerOf(uint256 _tokenId) external view returns (bytes32 rootOwner);
|
||||
|
||||
/// @notice Get the owner addess and parent token (if there is one) of a token
|
||||
/// @param _tokenId The tokenId to query.
|
||||
|
|
@ -1307,6 +1314,8 @@ Here is an example of what could occur if **from** was not explicitly provided i
|
|||
### Additional Reading Material
|
||||
[Top-Down and Bottom-Up Composables, What's the Difference and Which One Should You Use?](https://hackernoon.com/top-down-and-bottom-up-composables-whats-the-difference-and-which-one-should-you-use-db939f6acf1d)
|
||||
|
||||
Join the discussion about composables in the [NFTy Magician's Discord](https://discord.gg/8cuuj2Y).
|
||||
|
||||
## Backwards Compatibility
|
||||
Composables are designed to work with ERC721, ERC223 and ERC20 tokens.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,6 +29,9 @@ header_pages:
|
|||
- erc.html
|
||||
- informational.html
|
||||
- meta.html
|
||||
twitter:
|
||||
card: summary
|
||||
username: ethereum
|
||||
|
||||
# Build settings
|
||||
markdown: kramdown
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
| Variable | Symbol | Value | Unit | Source |
|
||||
| -------------------|--------------|---------------|---------------|--------|
|
||||
| Network Hashrate |H<sub>N</sub> | 232001 | GH/s | https://etherscan.io/chart/hashrate |
|
||||
| Network Hashrate |H<sub>N</sub> | 296000 | GH/s | https://etherscan.io/chart/hashrate |
|
||||
| GPU Hashrate |H<sub>M</sub> | 31.2 | MH/s | http://www.legitreviews.com/geforce-gtx-1070-ethereum-mining-small-tweaks-great-hashrate-low-power_195451 |
|
||||
| GPU Power |P<sub>M</sub> | 110.6 | W | https://www.reddit.com/r/ethereum/comments/7vewys/10000_tons_co2_per_day_and_climbing_eip_858/dtrswyz/ |
|
||||
|
||||
|
|
@ -11,20 +11,14 @@ A baseline value for network power consumption can be found by multiplying the t
|
|||
|
||||
> P<sub>N</sub> = H<sub>N</sub> x P<sub>M</sub> / H<sub>M</sub>
|
||||
>
|
||||
> P<sub>N</sub> = 232001 (GH/s) x 110.6 (W) x 1000 (MH/GH) / ( 31.2 (MH/s) x 10^6 (W/MW) )
|
||||
> P<sub>N</sub> = 296000 (GH/s) x 110.6 (W) x 1000 (MH/GH) / ( 31.2 (MH/s) x 10^6 (W/MW) )
|
||||
>
|
||||
> P<sub>N</sub> = 821 MW
|
||||
> P<sub>N</sub> = 1049 MW
|
||||
|
||||
As a side note, people often confuse power (W) and energy (power x time, eg. Wh). For instance, assuming an average daily P<sub>Nd</sub> of 821 MW we can calculate that days Energy consumption by multiplying by the number of hours in a day.
|
||||
As a side note, people often confuse power (W) and energy (power x time, eg. Wh). For instance, assuming an average daily P<sub>Nd</sub> of 1049 MW we can calculate that days Energy consumption by multiplying by the number of hours in a day.
|
||||
|
||||
> E<sub>Nd</sub> = P<sub>Nd</sub> x T<sub>d</sub>
|
||||
>
|
||||
> E<sub>Nd</sub> = 821 (MW) x 24 (h/d) / 1000 (GW/MW)
|
||||
> E<sub>Nd</sub> = 1049 (MW) x 24 (h/d) / 1000 (GW/MW)
|
||||
>
|
||||
> E<sub>Nd</sub> = 19.7 GWh
|
||||
|
||||
|
||||
|
||||
## Network CO2 contribution
|
||||
|
||||
Work in progress
|
||||
|
|
|
|||
Loading…
Reference in New Issue