mirror of https://github.com/status-im/EIPs.git
Merge branch 'master' into patch-1
This commit is contained in:
Nick Savers
GitHub
commit
6caa168206
|
|
@ -65,10 +65,10 @@ Each status change is requested by the EIP author and reviewed by the EIP editor
|
|||
|
||||
Other exceptional statuses include:
|
||||
|
||||
* Deferred -- This is for core EIPs that have been put off for a future hard fork.
|
||||
* Rejected -- An EIP that is fundamentally broken or a Core EIP that was rejected by the Core Devs and will not be implemented.
|
||||
* Active -- This is similar to Final, but denotes an EIP which which may be updated without changing its EIP number.
|
||||
* Superseded -- An EIP which was previously final but is no longer considered state-of-the-art. Another EIP will be in Final status and reference the Superseded EIP.
|
||||
* **Deferred** -- This is for core EIPs that have been put off for a future hard fork.
|
||||
* **Rejected** -- An EIP that is fundamentally broken or a Core EIP that was rejected by the Core Devs and will not be implemented.
|
||||
* **Active** -- This is similar to Final, but denotes an EIP which which may be updated without changing its EIP number.
|
||||
* **Superseded** -- An EIP which was previously final but is no longer considered state-of-the-art. Another EIP will be in Final status and reference the Superseded EIP.
|
||||
|
||||
## What belongs in a successful EIP?
|
||||
|
||||
|
|
@ -106,9 +106,9 @@ Each EIP must begin with an RFC 822 style header preamble, preceded and followed
|
|||
|
||||
` status:` <Draft | Last Call | Accepted | Final | Active | Deferred | Rejected | Superseded>
|
||||
|
||||
`* review-period-end: YYYY-MM-DD
|
||||
`* review-period-end:` YYYY-MM-DD
|
||||
|
||||
` type: `<Standards Track (Core, Networking, Interface, ERC) | Informational | Meta>
|
||||
` type:` <Standards Track (Core, Networking, Interface, ERC) | Informational | Meta>
|
||||
|
||||
` * category:` <Core | Networking | Interface | ERC>
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ author: Nick Savers (@nicksavers)
|
|||
type: Meta
|
||||
status: Draft
|
||||
created: 2018-04-20
|
||||
requires: 145, 210, 1014, 1052, 1087
|
||||
requires: 145, 1014, 1052, 1234, 1283
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
|
@ -21,15 +21,14 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Cons
|
|||
- `Block >= TBD` on the Ropsten testnet
|
||||
- Included EIPs:
|
||||
- [EIP 145](./eip-145.md): Bitwise shifting instructions in EVM
|
||||
- [EIP 210](./eip-210.md): Blockhash refactoring
|
||||
- [EIP 1014](./eip-1014.md): Skinny CREATE2
|
||||
- [EIP 1052](./eip-1052.md): EXTCODEHASH Opcode
|
||||
- [EIP 1087](./eip-1087.md): Net gas metering for SSTORE operations
|
||||
- TBD: Ice-age delay
|
||||
- [EIP 1234](./eip-1234.md): Delay difficulty bomb, adjust block reward
|
||||
- [EIP 1283](./eip-1283.md): Net gas metering for SSTORE without dirty maps
|
||||
|
||||
## References
|
||||
|
||||
The list above includes the EIPs discussed as candidates for Constantinople at the [All Core Dev Meeting #42](https://github.com/ethereum/pm/blob/c78d7ff147daaafa4dce60ba56cdedbe268a0488/All%20Core%20Devs%20Meetings/Meeting%2042.md#constantinople-hard-fork-and-timing). Final decision is planned for the subsequent meeting #43.
|
||||
The list above includes the EIPs discussed as candidates for Constantinople at the All Core Dev [Constantinople Session #1](https://github.com/ethereum/pm/issues/55). See also [Constantinople Progress Tracker](https://github.com/ethereum/pm/issues/53).
|
||||
|
||||
## Copyright
|
||||
|
||||
|
|
|
|||
|
|
@ -71,11 +71,11 @@ IF provider is undefined
|
|||
|
||||
##### `[1] ENABLE`
|
||||
|
||||
Dapps MUST request a full provider by calling the `enable` method on the default read-only provider. This method MUST trigger a user interface that allows the user to approve or deny full provider access for a given dapp. This method MUST return a Promise that is resolved with an array of the user's public keys if the user approves full provider access or rejected if the user denies full provider access.
|
||||
Dapps MUST request a full provider by calling the `enable` method on the default read-only provider. This method MUST trigger a user interface that allows the user to approve or deny full provider access for a given dapp. This method MUST return a Promise that is resolved with an array of the user's public addresses if the user approves full provider access or rejected if the user denies full provider access.
|
||||
|
||||
##### `[2] RESOLVE`
|
||||
|
||||
If a user approves full provider access, DOM environments MUST expose a fully-enabled provider at `window.ethereum` that is populated with accounts. The Promise returned when calling the `enable` method MUST be resolved with an array of the user's public keys.
|
||||
If a user approves full provider access, DOM environments MUST expose a fully-enabled provider at `window.ethereum` that is populated with accounts. The Promise returned when calling the `enable` method MUST be resolved with an array of the user's public addresses.
|
||||
|
||||
##### `[3] REJECT`
|
||||
|
||||
|
|
|
|||
|
|
@ -13,15 +13,15 @@ created: 2018-08-01
|
|||
|
||||
This EIP proposes net gas metering changes for SSTORE opcode, as an
|
||||
alternative for EIP-1087. It tries to be friendlier to implementations
|
||||
that uses different opetimiazation strategies for storage change
|
||||
that use different optimization strategies for storage change
|
||||
caches.
|
||||
|
||||
## Motivation
|
||||
|
||||
EIP-1087 proposes a way to adjust gas metering for SSTORE opcode,
|
||||
enabling new usages on this opcodes where it is previously too
|
||||
enabling new usages on these opcodes where it is previously too
|
||||
expensive. However, EIP-1087 requires keeping a dirty map for storage
|
||||
changes, and implictly makes the assumption that a transaction's
|
||||
changes, and implicitly makes the assumption that a transaction's
|
||||
storage changes are committed to the storage trie at the end of a
|
||||
transaction. This works well for some implementations, but not for
|
||||
others. After EIP-658, an efficient storage cache implementation would
|
||||
|
|
@ -29,11 +29,11 @@ probably use an in-memory trie (without RLP encoding/decoding) or
|
|||
other immutable data structures to keep track of storage changes, and
|
||||
only commit changes at the end of a block. For them, it is possible to
|
||||
know a storage's original value and current value, but it is not
|
||||
possible to iterate over all storage changes without incur additional
|
||||
possible to iterate over all storage changes without incurring additional
|
||||
memory or processing costs.
|
||||
|
||||
This EIP proposes an alternative way for gas metering on SSTORE, using
|
||||
information that is more universially available to most
|
||||
information that is more universally available to most
|
||||
implementations:
|
||||
|
||||
* *Storage slot's original value*.
|
||||
|
|
@ -43,7 +43,7 @@ implementations:
|
|||
For the specification provided here:
|
||||
|
||||
* We don't suffer from the optimization limitation of EIP-1087, and it
|
||||
never costs more gas compared with current scheme.
|
||||
never costs more gas compared with the current scheme.
|
||||
* It covers all usages for a transient storage. Clients that are easy
|
||||
to implement EIP-1087 will also be easy to implement this
|
||||
specification. Some other clients might require a little bit extra
|
||||
|
|
@ -100,7 +100,7 @@ consumed.
|
|||
|
||||
## Explanation
|
||||
|
||||
The new gas cost scheme for SSTORE is divided to three different
|
||||
The new gas cost scheme for SSTORE is divided into three different
|
||||
types:
|
||||
|
||||
* **No-op**: the virtual machine does not need to do anything. This is
|
||||
|
|
@ -143,7 +143,7 @@ state because that is trivial:
|
|||
|
||||
|
||||
|
||||
Below are table version of the above diagram. Vertical shows the *new
|
||||
Below is table version of the above diagram. Vertical shows the *new
|
||||
value* being set, and horizontal shows the state of *original value*
|
||||
and *current value*.
|
||||
|
||||
|
|
@ -187,7 +187,7 @@ Examine examples provided in EIP-1087's Motivation:
|
|||
## Backwards Compatibility
|
||||
|
||||
This EIP requires a hard fork to implement. No gas cost increase is
|
||||
anticipated, and many contract will see gas reduction.
|
||||
anticipated, and many contracts will see gas reduction.
|
||||
|
||||
## Test Cases
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 1328
|
||||
title: WalletConnect Standard URI Format
|
||||
authors: ligi <ligi@ligi.de>, Pedro Gomes <pedrouid@protonmail.com>
|
||||
author: ligi <ligi@ligi.de>, Pedro Gomes <pedrouid@protonmail.com>
|
||||
type: Standards Track
|
||||
category: ERC
|
||||
status: Draft
|
||||
|
|
@ -24,8 +24,8 @@ This standard defines how the data to connect some application and a wallet can
|
|||
|
||||
Function call URIs follow the ERC-831 URI format, with the following parameters:
|
||||
|
||||
request = "ethereum" ":" [ "wc-" ]sessionID [ "@" version ][ "?" parameters ]
|
||||
sessionID = STRING
|
||||
request = "ethereum" ":" [ "wc-" ]sessionId [ "@" version ][ "?" parameters ]
|
||||
sessionId = STRING
|
||||
version = 1*DIGIT
|
||||
parameters = parameter *( "&" parameter )
|
||||
parameter = key "=" value
|
||||
|
|
@ -36,6 +36,12 @@ Function call URIs follow the ERC-831 URI format, with the following parameters:
|
|||
|
||||
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.
|
||||
|
||||
### Example
|
||||
|
||||
```
|
||||
ethereum:wc-8a5e5bdc-a0e4-4702-ba63-8f1a5655744f@1?name=DappExample&bridge=https://bridge.example.com&symKey=KzpSTk1pezg5eTJRNmhWJmoxdFo6UDk2WlhaOyQ5N0U=
|
||||
```
|
||||
|
||||
## 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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
eip: 1352
|
||||
title: Specify restricted address range for precompiles/system contracts
|
||||
author: Alex Beregszaszi (@axic)
|
||||
discussions-to: https://ethereum-magicians.org/t/eip-1352-specify-restricted-address-range-for-precompiles-system-contracts/1151
|
||||
status: Draft
|
||||
type: Standards Track
|
||||
category: Core
|
||||
created: 2018-07-27
|
||||
---
|
||||
|
||||
## Simple Summary
|
||||
Specify an Ethereum address range occupied by precompiles and future system contracts. Regular accounts and contracts cannot obtain such an address.
|
||||
|
||||
## Abstract
|
||||
The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts.
|
||||
|
||||
## Motivation
|
||||
This will simplify certain future features where unless this is implemented, several exceptions must be specified.
|
||||
|
||||
## Specification
|
||||
The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts.
|
||||
|
||||
Due to the extremely low probability (and lack of adequate testing possibilities) no explicit checks should be added to ensure that external transaction signing or
|
||||
the invoking of the `CREATE` instruction can result in a precompile address.
|
||||
|
||||
## Rationale
|
||||
N/A
|
||||
|
||||
## Backwards Compatibility
|
||||
No contracts on the main network have been created at the specified addresses. As a result it should pose no backwards compatibility problems.
|
||||
|
||||
## Test Cases
|
||||
N/A
|
||||
|
||||
## Implementation
|
||||
N/A
|
||||
|
||||
## Copyright
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 1355
|
||||
title: Ethash 1a
|
||||
author: Paweł Bylica <pawel@ethereum.org>
|
||||
author: Paweł Bylica <pawel@ethereum.org>, Jean M. Cyr [@jean-m-cyr](https://github.com/jean-m-cyr)
|
||||
discussions-to: https://ethereum-magicians.org/t/eip-1355-ethash-1a/1167
|
||||
status: Draft
|
||||
type: Standards Track
|
||||
|
|
@ -21,7 +21,7 @@ Provide minimal set of changes to Ethash algorithm to hinder and delay the adopt
|
|||
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()`.
|
||||
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
|
||||
|
|
|
|||
|
|
@ -0,0 +1,57 @@
|
|||
---
|
||||
eip: 1380
|
||||
title: Reduced gas cost for call to self
|
||||
author: Alex Beregszaszi (@axic), Jacques Wagener (@jacqueswww)
|
||||
discussions-to: https://ethereum-magicians.org/t/eip-1380-reduced-gas-cost-for-call-to-self/1242
|
||||
status: Draft
|
||||
type: Standards Track
|
||||
category: Core
|
||||
created: 2018-08-31
|
||||
requires: 150
|
||||
---
|
||||
|
||||
## Abstract
|
||||
Reduce the gas cost for call instructions, when the goal is to run a new instance of the currently loaded contract.
|
||||
|
||||
## Motivation
|
||||
The current gas cost of 700 for all call types (`CALL`, `DELEGATECALL`, `CALLCODE` and `STATICCALL`) does not take into account that a call to a contract itself
|
||||
does not need to perform additional I/O operations, because the current contract code has already been loaded into memory.
|
||||
|
||||
Reducing the call-to-self gas cost would greatly benefit smart contract languages, such as Solidity and Vyper, who would then be able to utilise `CALL` instead
|
||||
of `JUMP` opcodes for internal function calls. While languages can already utilise `CALL` for internal function calls, they are discouraged to do so due to the
|
||||
gas costs associated with it.
|
||||
|
||||
Using `JUMP` comes at a considerable cost in complexity to the implementation of a smart contract language and/or compiler. The context (including stack and memory)
|
||||
must be swapped in and out of the calling functions context. A desired feature is having *pure* functions, which do not modify the state of memory, and realising
|
||||
them through `JUMP` requires a bigger effort from the compiler as opposed to being able to use `CALL`s.
|
||||
|
||||
Using call-to-self provides the guarentee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both
|
||||
contract writers and contract consumers against potentially undetetected edge cases were memory could poison the context of the internal function.
|
||||
|
||||
Because of the `JUMP` usage for internal functions a smart contract languages are also at risk of reaching the stack depth limit considerbly faster, if nested
|
||||
function calls with many in and/or outputs are required.
|
||||
|
||||
Reducing the gas cost, and thereby incentivising of using call-to-self instead of `JUMP`s for the internal function implementation will also benefit static
|
||||
analyzers and tracers.
|
||||
|
||||
## Specification
|
||||
If `block.number >= FORK_BLKNUM`, then decrease the cost of `CALL`, `DELEGATECALL`, `CALLCODE` and `STATICCALL` from 700 to 40,
|
||||
if and only if, the destination address of the call equals to the address of the caller.
|
||||
|
||||
## Rationale
|
||||
EIP150 has increased the cost of these instructions from 40 to 700 to more fairly charge for loading new contracts from disk, e.g. to reflect the I/O charge more closely.
|
||||
By assuming that 660 is the cost of loading a contract from disk, one can assume that the original 40 gas is a fair cost of creating a new VM instance of an already loaded contract code.
|
||||
|
||||
## Backwards Compatibility
|
||||
This should pose no risk to backwards compatibility. Currently existing contracts should not notice the difference, just see cheaper execution.
|
||||
With EIP150 contract (and language) developers had a lesson that relying on strict gas costs is not feasible as costs may change.
|
||||
The impact of this EIP is even less that of EIP150 because the costs are changing downwards and not upwards.
|
||||
|
||||
## Test Cases
|
||||
TBA
|
||||
|
||||
## Implementation
|
||||
TBA
|
||||
|
||||
## Copyright
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 140
|
||||
title: REVERT instruction
|
||||
author: Alex Beregszaszi, Nikolai Mushegian <nikolai@nexusdev.us>
|
||||
author: Alex Beregszaszi (@axic), Nikolai Mushegian <nikolai@nexusdev.us>
|
||||
type: Standards Track
|
||||
category: Core
|
||||
status: Final
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 141
|
||||
title: Designated invalid EVM instruction
|
||||
author: Alex Beregszaszi
|
||||
author: Alex Beregszaszi (@axic)
|
||||
type: Standards Track
|
||||
category: Core
|
||||
status: Final
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 145
|
||||
title: Bitwise shifting instructions in EVM
|
||||
author: Alex Beregszaszi, Paweł Bylica
|
||||
author: Alex Beregszaszi (@axic), Paweł Bylica
|
||||
type: Standards Track
|
||||
category: Core
|
||||
status: Accepted
|
||||
|
|
|
|||
|
|
@ -62,4 +62,5 @@ This would provide a way to send transactions that work on Ethereum without work
|
|||
| 42 | Kovan |
|
||||
| 61 | Ethereum Classic mainnet |
|
||||
| 62 | Ethereum Classic testnet |
|
||||
| 66 | ewasm testnet |
|
||||
| 1337 | Geth private chains (default) |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
eip: 205
|
||||
title: ENS support for contract ABIs
|
||||
author: Nick Johnson <nick@ethereum.org>
|
||||
type: Standards Track
|
||||
category: ERC
|
||||
status: Draft
|
||||
created: 2017-02-06
|
||||
requires: 137, 181
|
||||
---
|
||||
|
||||
## Simple Summary
|
||||
This EIP proposes a mechanism for storing ABI definitions in ENS, for easy lookup of contract interfaces by callers.
|
||||
|
||||
## Abstract
|
||||
ABIs are important metadata required for interacting with most contracts. At present, they are typically supplied out-of-band, which adds an additional burden to interacting with contracts, particularly on a one-off basis or where the ABI may be updated over time. The small size of ABIs permits an alternative solution, storing them in ENS, permitting name lookup and ABI discovery via the same process.
|
||||
|
||||
ABIs are typically quite compact; the largest in-use ABI we could find, that for the DAO, is 9450 bytes uncompressed JSON, 6920 bytes uncompressed CBOR, and 1128 bytes when the JSON form is compressed with zlib. Further gains on CBOR encoding are possible using a CBOR extension that permits eliminating repeated strings, which feature extensively in ABIs. Most ABIs, however, are far shorter than this, consisting of only a few hundred bytes of uncompressed JSON.
|
||||
|
||||
This EIP defines a resolver profile for retrieving contract ABIs, as well as encoding standards for storing ABIs for different applications, allowing the user to select between different representations based on their need for compactness and other considerations such as onchain access.
|
||||
|
||||
## Specification
|
||||
### ABI encodings
|
||||
In order to allow for different tradeoffs between onchain size and accessibility, several ABI encodings are defined. Each ABI encoding is defined by a unique constant with only a single bit set, allowing for the specification of 256 unique encodings in a single uint.
|
||||
|
||||
The currently recognised encodings are:
|
||||
|
||||
| ID | Description |
|
||||
|----|----------------------|
|
||||
| 1 | JSON |
|
||||
| 2 | zlib-compressed JSON |
|
||||
| 4 | CBOR |
|
||||
| 8 | URI |
|
||||
|
||||
This table may be extended in future through the EIP process.
|
||||
|
||||
Encoding type 1 specifies plaintext JSON, uncompressed; this is the standard format in which ABIs are typically encoded, but also the bulkiest, and is not easily parseable onchain.
|
||||
|
||||
Encoding type 2 specifies zlib-compressed JSON. This is significantly smaller than uncompressed JSON, and is straightforward to decode offchain. However, it is impracticalfor onchain consumers to use.
|
||||
|
||||
Encoding type 4 is [CBOR](http://cbor.io/). CBOR is a binary encoding format that is a superset of JSON, and is both more compact and easier to parse in limited environments such as the EVM. Consumers that support CBOR are strongly encouraged to also support the [stringref extension](http://cbor.schmorp.de/stringref) to CBOR, which provides significant additional reduction in encoded size.
|
||||
|
||||
Encoding type 8 indicates that the ABI can be found elsewhere, at the specified URI. This is typically the most compact of the supported forms, but also adds external dependencies for implementers. The specified URI may use any schema, but HTTP, IPFS, and Swarm are expected to be the most common.
|
||||
|
||||
### Resolver profile
|
||||
A new resolver interface is defined, consisting of the following method:
|
||||
|
||||
function ABI(bytes32 node, uint256 contentType) constant returns (uint256, bytes);
|
||||
|
||||
The interface ID of this interface is 0x2203ab56.
|
||||
|
||||
contentType is a bitfield, and is the bitwise OR of all the encoding types the caller will accept. Resolvers that implement this interface must return an ABI encoded using one of the requested formats, or `(0, "")` if they do not have an ABI for this function, or do not support any of the requested formats.
|
||||
|
||||
The `abi` resolver profile is valid on both forward and reverse records.
|
||||
|
||||
### ABI lookup process
|
||||
|
||||
When attempting to fetch an ABI based on an ENS name, implementers should first attempt an ABI lookup on the name itself. If that lookup returns no results, they should attempt a reverse lookup on the Ethereum address the name resolves to.
|
||||
|
||||
Implementers should support as many of the ABI encoding formats as practical.
|
||||
|
||||
## Rationale
|
||||
|
||||
Storing ABIs onchain avoids the need to introduce additional dependencies for applications wishing to fetch them, such as swarm or HTTP access. Given the typical compactness of ABIs, we believe this is a worthwhile tradeoff in many cases.
|
||||
|
||||
The two-step resolution process permits different names to provide different ABIs for the same contract, such as in the case where it's useful to provide a minimal ABI to some callers, as well as specifying ABIs for contracts that did not specify one of their own. The fallback to looking up an ABI on the reverse record permits contracts to specify their own canonical ABI, and prevents the need for duplication when multiple names reference the same contract without the need for different ABIs.
|
||||
|
||||
## Copyright
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
eip: 233
|
||||
title: Formal process of hard forks
|
||||
author: Alex Beregszaszi (@axic)
|
||||
discussions-to: https://ethereum-magicians.org/t/eip-233-formal-process-of-hard-forks/1387
|
||||
type: Meta
|
||||
status: Draft
|
||||
created: 2017-03-23
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
To describe the formal process of preparing and activating hard forks.
|
||||
|
||||
## Motivation
|
||||
|
||||
Today discussions about hard forks happen at various forums and sometimes in ad-hoc ways.
|
||||
|
||||
## Specification
|
||||
|
||||
A Meta EIP should be created and merged as a *Draft* as soon as a new hard fork is planned. This EIP should contain:
|
||||
- the desired codename of the hard fork,
|
||||
- list of all the EIPs included in the hard fork and
|
||||
- activation block number once decided and
|
||||
- the **Requires** header should point to the previous hard fork meta EIP.
|
||||
|
||||
The draft shall be updated with summaries of the decisions around the hard fork. It should move in to the `Accepted` state once the changes are frozen (i.e. all referenced EIPs are in the `Accepted` state) and in to the `Final` state once the hard fork has been activated.
|
||||
|
||||
## Rationale
|
||||
|
||||
A meta EIP for coordinating the hard fork should help in visibility and traceability of the scope of changes as well as provide a simple name and/or number for referring to the proposed fork.
|
||||
|
||||
## Copyright
|
||||
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
|
@ -2,10 +2,11 @@
|
|||
eip: 5
|
||||
title: Gas Usage for `RETURN` and `CALL*`
|
||||
author: Christian Reitwiessner <c@ethdev.com>
|
||||
status: Draft
|
||||
status: Superseded
|
||||
type: Standards Track
|
||||
category: Core
|
||||
created: 2015-11-22
|
||||
superseded-by: 211
|
||||
---
|
||||
|
||||
### Abstract
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 606
|
||||
title: "Hardfork Meta: Homestead"
|
||||
author: Alex Beregszaszi
|
||||
author: Alex Beregszaszi (@axic)
|
||||
type: Meta
|
||||
status: Final
|
||||
created: 2017-04-23
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 607
|
||||
title: "Hardfork Meta: Spurious Dragon"
|
||||
author: Alex Beregszaszi
|
||||
author: Alex Beregszaszi (@axic)
|
||||
type: Meta
|
||||
status: Final
|
||||
created: 2017-04-23
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 608
|
||||
title: "Hardfork Meta: Tangerine Whistle"
|
||||
author: Alex Beregszaszi
|
||||
author: Alex Beregszaszi (@axic)
|
||||
type: Meta
|
||||
status: Final
|
||||
created: 2017-04-23
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
eip: 609
|
||||
title: "Hardfork Meta: Byzantium"
|
||||
author: Alex Beregszaszi
|
||||
author: Alex Beregszaszi (@axic)
|
||||
type: Meta
|
||||
status: Final
|
||||
created: 2017-04-23
|
||||
|
|
|
|||
120
EIPS/eip-820.md
120
EIPS/eip-820.md
File diff suppressed because one or more lines are too long
|
|
@ -1312,6 +1312,10 @@ Here is an example of what could occur if **from** was not explicitly provided i
|
|||
|
||||
|
||||
### Additional Reading Material
|
||||
[Introducing Crypto Composables](https://medium.com/coinmonks/introducing-crypto-composables-ee5701fde217)
|
||||
|
||||
[Crypto Composables — Building Blocks and Applications](https://medium.com/coinmonks/introducing-crypto-composables-ee5701fde217)
|
||||
|
||||
[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).
|
||||
|
|
|
|||
Loading…
Reference in New Issue