status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'master' into patch-1

This commit is contained in:
Nick Savers 2018-09-20 21:13:05 +02:00 committed by GitHub
parent 009ab6db1c a15edb61bb
commit 6a2bec60c4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
28 changed files with 701 additions and 263 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
EIPS/eip-1.md
View File

@ -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>

9
EIPS/eip-1013.md
View File

@ -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

111
EIPS/eip-1102.md
View File

@ -11,17 +11,39 @@ created: 2018-05-04
## Simple summary
This proposal describes a way for DOM environments to expose an Ethereum provider API that requires user approval.
This proposal describes a way for DOM environments to expose an Ethereum provider that requires user approval.
## Abstract
The previous generation of Ethereum-enabled DOM environments follows a pattern of directly injecting a provider object into the DOM without user consent. This exposes users of such environments to fingerprinting attacks since untrusted websites can check for the injected provider and reliably identify Ethereum-enabled clients.
The previous generation of Ethereum-enabled DOM environments follows a pattern of injecting a fully-enabled provider into the DOM without user consent. This puts users of such environments at risk because malicious websites can use this provider to view account information and to arbitrarily initiate unwanted Ethereum transactions on a user's behalf.
This proposal outlines a protocol in which dapps request access to an Ethereum provider API.
This proposal outlines a protocol in which DOM environments expose a read-only provider until full provider access is approved by the user.
## Specification
### Typical dapp initialization
### Definitions
1. **Read-only provider**
A read-only provider has no populated accounts and any RPC request that requires an account will fail.
2. **Full provider**
A full provider has populated accounts and any RPC request that requires an account will succeed.
3. **`Provider#enable`**
Providers exposed by DOM environments define a new `enable` method that returns a Promise. Calling this method triggers a user interface that allows the user to approve or deny full provider access for a given dapp. The returned Promise is resolved if the user approves full provider access or rejected if the user denies full provider access.
```js
ethereum.enable(): Promise<any>
```
### Protocol
DOM environments expose a read-only provider globally at `window.ethereum` by default. Before initiating any RPC request that requires an account, like `eth_sendTransaction`, dapps must request a full provider by calling a new provider method, `ethereum.enable()`. This method triggers a user interface that allows the user to approve or deny full provider access for a given dapp. If the user approves full provider access, the provider at `window.ethereum` is populated with accounts and fully-enabled; if the user denies full provider access, the provider at `window.ethereum` is left unchanged.
#### Typical dapp initialization
```
START dapp
@ -31,62 +53,71 @@ IF web3 is undefined
STOP dapp
```
### Proposed dapp initialization
#### Proposed dapp initialization
```
START dapp
REQUEST[1] provider
IF user approves
RESPOND[2] with provider
CONTINUE dapp
IF user rejects
IF non-Ethereum environment
NOOP[3]
IF provider is defined
ENABLE[1] full provider
IF user approves
RESOLVE[2] full provider
CONTINUE dapp
IF user denies
REJECT[3] with error
STOP dapp
IF provider is undefined
STOP dapp
```
#### `[1] REQUEST`
##### `[1] ENABLE`
Dapps MUST request an Ethereum provider API by sending a message using the [`window.postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) API. This message MUST be sent with a payload object containing a `type` property with a value of "ETHEREUM_PROVIDER_REQUEST" and an optional `id` property corresponding to an identifier of a specific wallet provider, such as "METAMASK".
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] RESPOND`
##### `[2] RESOLVE`
Ethereum-enabled DOM environments MUST respond with an Ethereum provider API by emitting an "ethereumprovider" [CustomEvent](https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/CustomEvent) on the `window` object. This custom event MUST pass a provider API as an `ethereum` property on its `detail` data object.
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] NOOP`
##### `[3] REJECT`
If a user rejects access to the Ethereum provider API on an untrusted site, the site itself MUST NOT be notified in any way; notification of a rejection would allow third-party tools to still identify that a client is Ethereum-enabled despite not being granted access to any provider API.
If a user denies full provider access, the Promise returned when calling the `enable` method MUST be rejected with an informative Error.
### Example implementation: `postMessage`
The following example demonstrates one possible implementation of this strategy in a browser-based DOM environment. Note that Ethereum-enabled environments on other platforms would most likely use platform-specific native messaging protocols, not `postMessage`.
### Example initialization
```js
window.addEventListener('load', () => {
// Listen for provider response
window.addEventListener('ethereumprovider', async ({ detail: { ethereum } }) => {
// Provider API exposed, continue
const networkVersion = await ethereum.send('net_version', []);
});
// Request provider
window.postMessage({ type: 'ETHEREUM_PROVIDER_REQUEST' }, '*');
window.addEventListener('load', async () => {
// Read-only provider is exposed by default
console.log(await ethereum.send('net_version'));
try {
// Request full provider if needed
await ethereum.enable();
// Full provider exposed
await ethereum.send('eth_sendTransaction', [/* ... */]);
} catch (error) {
// User denied full provider access
}
});
```
## Rationale
The pattern of provider auto-injection followed by the previous generation of Ethereum-enabled DOM environments failed to protect user privacy by allowing untrusted websites to uniquely identify Ethereum users. This proposal establishes a new pattern wherein dapps must request access to an Ethereum provider API. This protocol directly prevents fingerprinting attacks by giving users the ability to reject provider exposure on a given website.
### Constraints
* A provider API MUST NOT be exposed to websites by default.
* Dapps MUST request a provider API if it does not exist.
* Users MUST be able to approve or reject provider API access.
* A provider API MUST be exposed to websites after user consent.
* Environments MAY continue auto-exposing a provider API if users can opt-out.
* Browsers MUST expose a read-only provider at `window.ethereum` by default.
* Browsers MUST NOT expose a full provider globally by default.
* Dapps MUST request access to a full provider.
* Users MUST be able to approve or deny full provider access.
* A full provider MUST be exposed at `window.ethereum` after user approval.
* Dapps MUST be notified of user approval of full provider access.
* Dapps MUST be notified of user denial of full provider access.
## Rationale
The pattern of full provider auto-injection followed by the previous generation of Ethereum-enabled DOM environments fails to protect user privacy and fails to maintain safe user experience: untrusted websites can both view account information and arbitrarily initiate transactions on a user's behalf. Even though most users may reject unsolicited transactions on untrusted websites, a protocol for provider exposure should make such unsolicited requests impossible.
This proposal establishes a new pattern wherein dapps must request access to a full Ethereum provider. This protocol directly strengthens user privacy by hiding user accounts and preventing unsolicited transaction requests on untrusted sites.
### Immediate value-add
* Users can reject provider API access on untrusted sites to prevent fingerprinting.
* Users can reject full provider access on untrusted sites to hide accounts.
* Users can reject full provider access on untrusted sites to prevent unsolicited transactions.
### Long-term value-add
@ -97,7 +128,7 @@ The pattern of provider auto-injection followed by the previous generation of Et
## Backwards compatibility
This proposal impacts dapp authors and requires that they request access to an Ethereum provider API before using it. This proposal also impacts developers of Ethereum-enabled environments or dapp browsers as these tools should no longer auto-expose any provider API; instead, they should only do so if a website requests a provider API and if the user consents to its access. Environments may continue to auto-expose an Ethereum provider API as long as users have the ability to disable this behavior.
This proposal impacts dapp authors and requires that they request access to a full Ethereum provider before using it to initiate any RPC call that requires an account. This proposal also impacts developers of Ethereum-enabled DOM environments or dapp browsers as these tools should no longer auto-expose a full provider populated with accounts; instead, they should expose a read-only provider and only expose a full provider if a website requests one and a user consents to its access.
## Implementation

34
EIPS/eip-1154.md
View File

@ -34,7 +34,7 @@ Both the ID and the results are intentionally unstructured so that things like t
<dt>Oracle</dt>
<dd>An entity which reports data to the blockchain.</dd>
<dt>Oracle handler</dt>
<dt>Oracle consumer</dt>
<dd>A smart contract which receives data from an oracle.</dd>
<dt>ID</dt>
@ -44,12 +44,12 @@ Both the ID and the results are intentionally unstructured so that things like t
<dd>Data associated with an id which is reported by an oracle. This data oftentimes will be the answer to a question tied to the id. Other equivalent terms that have been used include: answer, data, outcome.</dd>
<dt>Report</dt>
<dd>A pair (ID, result) which an oracle sends to an oracle handler.</dd>
<dd>A pair (ID, result) which an oracle sends to an oracle consumer.</dd>
</dl>
```solidity
interface OracleHandler {
function receiveResult(bytes32 id, bytes32 result) external;
interface OracleConsumer {
function receiveResult(bytes32 id, bytes result) external;
}
```
@ -57,21 +57,23 @@ interface OracleHandler {
`receiveResult` MUST revert if `receiveResult` has been called with the same `id` before.
`receiveResult` MAY revert if the `id` or `result` cannot be handled by the handler.
`receiveResult` MAY revert if the `id` or `result` cannot be handled by the consumer.
Consumers MUST coordinate with oracles to determine how to encode/decode results to and from `bytes`. For example, `abi.encode` and `abi.decode` may be used to implement a codec for results in Solidity. `receiveResult` SHOULD revert if the consumer receives a unexpected result format from the oracle.
The oracle can be any Ethereum account.
## Rationale
The specs are currently very similar to what is implemented by ChainLink (which can use any arbitrarily-named callback) and Oraclize (which uses `__callback`).
With this spec, the oracle _pushes_ state to the handler, which must react accordingly to the updated state. An alternate _pull_-based interface can be prescribed, as follows:
With this spec, the oracle _pushes_ state to the consumer, which must react accordingly to the updated state. An alternate _pull_-based interface can be prescribed, as follows:
### Alternate Pull-based Interface
Here are alternate specs loosely based on Gnosis prediction market contracts v1. Reality Check also exposes a similar endpoint (`getFinalAnswer`).
```solidity
interface Oracle {
function resultFor(bytes32 id) external view returns (bytes32 result);
function resultFor(bytes32 id) external view returns (bytes result);
}
```
@ -80,25 +82,29 @@ interface Oracle {
`resultFor` MUST return the same result for an `id` after that result is available.
### Push vs Pull
Note that push-based interfaces may be adapted into pull-based interfaces. Simply deploy an oracle handler which stores the result received and implements `resultFor` accordingly.
Note that push-based interfaces may be adapted into pull-based interfaces. Simply deploy an oracle consumer which stores the result received and implements `resultFor` accordingly.
Similarly, every pull-based system can be adapted into a push-based system: just add a method on the oracle smart contract which takes an oracle handler address and calls `receiveResult` on that address.
Similarly, every pull-based system can be adapted into a push-based system: just add a method on the oracle smart contract which takes an oracle consumer address and calls `receiveResult` on that address.
In both cases, an additional transaction would have to be performed, so the choice to go with push or pull should be based on the dominant use case for these oracles.
In the simple case where a single account has the authority to decide the outcome of an oracle question, there is no need to deploy an oracle contract and store the outcome on that oracle contract. Similarly, in the case where the outcome comes down to a vote, existing multisignature wallets can be used as the authorized oracle.
#### Multiple Oracle Handlers
In the case that many oracle handlers depend on a single oracle result and all these handlers expect the result to be pushed to them, the push and pull adaptations mentioned before may be combined if the pushing oracle cannot be trusted to send the same result to every handler (in a sense, this forwards the trust to the oracle adaptor implementation).
#### Multiple Oracle Consumers
In the case that many oracle consumers depend on a single oracle result and all these consumers expect the result to be pushed to them, the push and pull adaptations mentioned before may be combined if the pushing oracle cannot be trusted to send the same result to every consumer (in a sense, this forwards the trust to the oracle adaptor implementation).
In a pull-based system, each of the handlers would have to be called to pull the result from the oracle contract, but in the proposed push-based system, the adapted oracle would have to be called to push the results to each of the handlers.
In a pull-based system, each of the consumers would have to be called to pull the result from the oracle contract, but in the proposed push-based system, the adapted oracle would have to be called to push the results to each of the consumers.
Transaction-wise, both systems are roughly equivalent in efficiency in this scenario, but in the push-based system, there's a need for the oracle handlers to store the results again, whereas in the pull-based system, the handlers may continue to refer to the oracle for the results. Although this may be somewhat less efficient, requiring the handlers to store the results can also provide security guarantees, especially with regards to result immutability.
Transaction-wise, both systems are roughly equivalent in efficiency in this scenario, but in the push-based system, there's a need for the oracle consumers to store the results again, whereas in the pull-based system, the consumers may continue to refer to the oracle for the results. Although this may be somewhat less efficient, requiring the consumers to store the results can also provide security guarantees, especially with regards to result immutability.
#### Result Immutability
In both the proposed specification and the alternate specification, results are immutable once they are determined. This is due to the expectation that typical handlers will require results to be immutable in order to determine a resulting state consistently. With the proposed push-based system, the handler enforces the result immutability requirement, whereas in the alternate pull-based system, either the oracle would have to be trusted to implement the spec correctly and enforce the immutability requirement, or the handler would also have to handle result immutability.
In both the proposed specification and the alternate specification, results are immutable once they are determined. This is due to the expectation that typical consumers will require results to be immutable in order to determine a resulting state consistently. With the proposed push-based system, the consumer enforces the result immutability requirement, whereas in the alternate pull-based system, either the oracle would have to be trusted to implement the spec correctly and enforce the immutability requirement, or the consumer would also have to handle result immutability.
For data which mutates over time, the `id` field may be structured to specify "what" and "when" for the data (using 128 bits to specify "when" is still safe for many millenia).
## Implementation
* [Tidbit](https://github.com/levelkdev/tidbit) tracks this EIP.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

3
EIPS/eip-1167.md
View File

@ -3,14 +3,13 @@ eip: 1167
title: Minimal Proxy Contract
author: Peter Murray (@yarrumretep), Nate Welch (@flygoing), Joe Messerman (@JAMesserman)
discussions-to: https://github.com/optionality/clone-factory/issues/10
status: Last Call
status: Final
type: Standards Track
category: ERC
created: 2018-06-22
---
<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
### Last Call Comment Period Ends August 27, 2018 @ 11PM UTC
## Simple Summary
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->

227
EIPS/eip-1193.md
View File

@ -14,12 +14,28 @@ requires: 1102
This EIP formalizes an Ethereum Provider JavaScript API for consistency across clients and applications.
The provider is designed to be minimal, containing 3 methods: `send`, `subscribe`, and `unsubscribe`. It emits 4 types of events: `connect`, `close`, `networkChanged`, and `accountsChanged`.
The provider is designed to be minimal, containing 4 methods: `enable`, `send`, `subscribe`, and `unsubscribe`. It emits 4 types of events: `connect`, `close`, `networkChanged`, and `accountsChanged`.
It is intended to be available on `window.ethereum`.
## API
### Enable
By default a "read-only" provider is supplied to allow access to the blockchain while preserving user privacy.
A full provider can be requested to allow account-level methods:
```js
ethereum.enable(): Promise<[String]>;
```
Promise resolves with an array of the accounts' public keys, or rejects with `Error`.
### Send
Ethereum API methods can be sent and received:
```js
ethereum.send(method: String, params?: Array<any>): Promise<any>;
```
@ -33,7 +49,7 @@ See the [available methods](https://github.com/ethereum/wiki/wiki/JSON-RPC#json-
#### Subscribe
```js
ethereum.subscribe(subscriptionType: String, params?: Array<any>): Promise<String|Error>;
ethereum.subscribe(subscriptionType: String, params?: Array<any>): Promise<String>;
```
Promise resolves with `subscriptionId: String` or rejects with `Error`.
@ -51,7 +67,7 @@ The event emits with `result`, the subscription `result` or an `Error` object.
#### Unsubscribe
```js
ethereum.unsubscribe(subscriptionId: String): Promise<Boolean|Error>;
ethereum.unsubscribe(subscriptionId: String): Promise<Boolean>;
```
Promise resolves with `success: Boolean` or rejects with `Error`.
@ -117,113 +133,131 @@ ethereum.constructor.name;
## Examples
```js
// Request Ethereum Provider (EIP 1102)
window.addEventListener('message', event => {
if (event.data && event.data.type === 'ETHEREUM_PROVIDER_SUCCESS') {
start(window.ethereum);
}
});
window.postMessage({ type: 'ETHEREUM_PROVIDER_REQUEST' }, this.origin);
const ethereum = window.ethereum;
function start(ethereum) {
// A) Primary use case - set provider in web3.js
web3.setProvider(ethereum);
// A) Primary use case - set provider in web3.js
web3.setProvider(ethereum);
// B) Secondary use case - use provider object directly
// Example: Log accounts
ethereum
.send('eth_accounts')
.then(accounts => {
console.log(`Accounts:\n${accounts.join('\n')}`);
})
.catch(error => {
console.error(
`Error fetching accounts: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
// B) Secondary use case - use provider object directly
// Example 1: Log last block
ethereum
.send('eth_getBlockByNumber', ['latest', 'true'])
.then(block => {
console.log(`Block ${block.number}:\n${block}`);
})
.catch(error => {
console.error(
`Error fetching last block: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
// Example: Log last block
ethereum
.send('eth_getBlockByNumber', ['latest', 'true'])
.then(block => {
console.log(`Block ${block.number}:\n${block}`);
})
.catch(error => {
console.error(
`Error fetching last block: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
// Example 2: Enable full provider
ethereum
.enable()
.then(accounts => {
console.log(`Enabled accounts:\n${accounts.join('\n')}`);
})
.catch(error => {
console.error(
`Error enabling provider: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
// Example: Log new blocks
let subId;
ethereum
.subscribe('newHeads')
.then(subscriptionId => {
subId = subscriptionId;
ethereum.on(subscriptionId, block => {
if (result instanceOf Error) {
const error = result;
console.error(
`Error from newHeads subscription: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
} else {
console.log(`New block ${block.number}:\n${block}`);
}
});
})
.catch(error => {
console.error(
`Error making newHeads subscription: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
// to unsubscribe
ethereum
.unsubscribe(subId)
.then(result => {
console.log(`Unsubscribed newHeads subscription ${subscriptionId}`);
})
.catch(error => {
console.error(
`Error unsubscribing newHeads subscription: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
// Example: Log when accounts change
const logAccounts = accounts => {
// Example 3: Log available accounts
ethereum
.send('eth_accounts')
.then(accounts => {
console.log(`Accounts:\n${accounts.join('\n')}`);
};
ethereum.on('accountsChanged', logAccounts);
// to unsubscribe
ethereum.removeListener('accountsChanged', logAccounts);
// Example: Log if connection ends
ethereum.on('close', (code, reason) => {
console.log(
`Ethereum provider connection closed: ${reason}. Code: ${code}`
})
.catch(error => {
console.error(
`Error fetching accounts: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
}
// Example 4: Log new blocks
let subId;
ethereum
.subscribe('newHeads')
.then(subscriptionId => {
subId = subscriptionId;
ethereum.on(subscriptionId, block => {
if (result instanceOf Error) {
const error = result;
console.error(
`Error from newHeads subscription: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
} else {
console.log(`New block ${block.number}:\n${block}`);
}
});
})
.catch(error => {
console.error(
`Error making newHeads subscription: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
// to unsubscribe
ethereum
.unsubscribe(subId)
.then(result => {
console.log(`Unsubscribed newHeads subscription ${subscriptionId}`);
})
.catch(error => {
console.error(
`Error unsubscribing newHeads subscription: ${error.message}.
Code: ${error.code}. Data: ${error.data}`
);
});
// Example 5: Log when accounts change
const logAccounts = accounts => {
console.log(`Accounts:\n${accounts.join('\n')}`);
};
ethereum.on('accountsChanged', logAccounts);
// to unsubscribe
ethereum.removeListener('accountsChanged', logAccounts);
// Example 6: Log if connection ends
ethereum.on('close', (code, reason) => {
console.log(
`Ethereum provider connection closed: ${reason}. Code: ${code}`
);
});
```
## Specification
### Enable
The provider supplied to a new dapp **MUST** be a "read-only" provider: authenticating no accounts by default, returning a blank array for `eth_accounts`, and rejecting any methods that require an account.
If the dapp has been previously authenticated and remembered by the user, then the provider supplied on load **MAY** automatically be enabled with the previously authenticated accounts.
If no accounts are authenticated, the `enable` method **MUST** ask the user which account(s) they would like to authenticate to the dapp. If the request has been previously granted and remembered, the `enable` method **MAY** immediately return with the prior remembered accounts and permissions.
The `enable` method **MUST** return a Promise, resolving with an array of the accounts' public keys, or rejecting with an `Error`. If the accounts enabled by provider change, the `accountsChanged` event **MUST** also emit.
### Send
The `send` method **MUST** send a properly formatted [JSON-RPC request](https://www.jsonrpc.org/specification#request_object).
If the Ethereum JSON-RPC API returns a response object with no error, then the Promise **MUST** resolve with the `response.result` object untouched by the implementing Ethereum Provider.
If the Ethereum JSON-RPC API returns response object that contains an error property then the Promise **MUST** be rejected with an Error object containing the `response.error.message` as the Error message, `response.error.code` as a code property on the error and `response.error.data` as a data property on the error.
If the Ethereum JSON-RPC API returns response object that contains an error property then the Promise **MUST** reject with an Error object containing the `response.error.message` as the Error message, `response.error.code` as a code property on the error and `response.error.data` as a data property on the error.
If an error occurs during processing, such as an HTTP error or internal parsing error, then the Promise **MUST** be rejected with an Error object.
If an error occurs during processing, such as an HTTP error or internal parsing error, then the Promise **MUST** reject with an `Error` object.
If the implementing Ethereum Provider is not talking to an external Ethereum JSON-RPC API provider then it **MUST** resolve with an object that matches the JSON-RPC API object as specified in the [Ethereum JSON-RPC documentation](https://github.com/ethereum/wiki/wiki/JSON-RPC).
If the JSON-RPC request requires an account that is not yet authenticated, the Promise **MUST** reject with an `Error`.
### Subscriptions
The `subscribe` method **MUST** send a properly formatted [JSON-RPC request](https://www.jsonrpc.org/specification#request_object) with method `eth_subscribe` and params `[subscriptionType: String, {...params: Array<any>}]` and **MUST** return a Promise that resolves with `subscriptionId: String` or rejected with an Error object.
@ -262,7 +296,13 @@ The implementing Ethereum Provider **MUST** be compatible as a `web3.js` provide
If an Error object is returned, it **MUST** contain a human readable string message describing the error and **SHOULD** populate the `code` and `data` properties on the error object with additional error details.
Appropriate error codes **SHOULD** follow the table of [`CloseEvent` status codes](https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent#Status_codes).
Appropriate error codes **SHOULD** follow the table of [`CloseEvent` status codes](https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent#Status_codes), along with the following table:
| Status code | Name | Description |
| ----------- | ------------------------- | -------------------------------------------------------------------------------------------------------------- |
| 4001 | User Denied Full Provider | User denied the enabling of the full Ethereum Provider by choosing not to authorize any accounts for the dapp. |
| | | |
| | | |
## Sample Class Implementation
@ -287,6 +327,15 @@ class EthereumProvider extends EventEmitter {
/* Methods */
enable() {
return new Promise((resolve, reject) => {
window.mist
.requestAccounts()
.then(resolve)
.catch(reject);
});
}
send(method, params = []) {
if (!method || typeof method !== 'string') {
return new Error('Method is not a valid string.');

14
EIPS/eip-1234.md
View File

@ -5,24 +5,24 @@ author: Afri Schoedon (@5chdn)
discussions-to: https://ethereum-magicians.org/t/eip-1234-constantinople-difficulty-bomb-delay-and-block-reward-adjustment/833
type: Standards Track
category: Core
status: Draft
status: Accepted
created: 2018-07-19
---
## Simple Summary
The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately one and a half year and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork.
The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately 12 months and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork.
## Abstract
Starting with `CNSTNTNPL_FORK_BLKNUM` the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 6 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly.
Starting with `CNSTNTNPL_FORK_BLKNUM` the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 5 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly.
## Motivation
The Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another one and a half years. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it's going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.
The Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another 12 months. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it's going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.
## Specification
#### Relax Difficulty with Fake Block Number
For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula:
fake_block_number = max(0, block.number - 6_000_000) if block.number >= CNSTNTNPL_FORK_BLKNUM else block.number
fake_block_number = max(0, block.number - 5_000_000) if block.number >= CNSTNTNPL_FORK_BLKNUM else block.number
#### Adjust Block, Uncle, and Nephew rewards
To ensure a constant Ether issuance, adjust the block reward to `new_block_reward`, where
@ -44,9 +44,9 @@ The nephew reward for `block.number >= CNSTNTNPL_FORK_BLKNUM` is
This is the existing pre-Constantinople formula for nephew rewards, simply adjusted with `new_block_reward`.
## Rationale
This will delay the ice age by 42 million seconds (approximately 1.4 years), so the chain would be back at 30 second block times in summer 2020. An alternate proposal was to add special rules to the difficulty calculation to effectively _pause_ the difficulty between different blocks. This would lead to similar results.
This will delay the ice age by 29 million seconds (approximately 12 months), so the chain would be back at 30 second block times in winter 2019. An alternate proposal was to add special rules to the difficulty calculation to effectively _pause_ the difficulty between different blocks. This would lead to similar results.
This was previously discussed at All Core Devs Meeting [#42](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2042.md) without stating any details. This draft can be used to discuss further changes to the difficulty bomb and issuance in subsequent meetings. This EIP-1234 opposes directly the intent of [EIP-1227](https://github.com/ethereum/EIPs/issues/1227) which should be also considered in discussions.
This was previously discussed at All Core Devs Meeting [#42](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2042.md) and subsequent meetings; and accepted in the Constantinople Session [#1](https://github.com/ethereum/pm/issues/55).
## Backwards Compatibility
This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, _Constantinople_.

18
EIPS/eip-1283.md
View File

@ -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:
![State Transition](../assets/eip-1283/state.png)
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

39
EIPS/eip-1295.md
View File

@ -1,6 +1,6 @@
---
eip: 1295
title: Modify Ethereum PoW Incentive Structure and Diffuse Difficulty Bomb
title: Modify Ethereum PoW Incentive Structure and Delay Difficulty Bomb
author: Brian Venturo (@atlanticcrypto)
discussions-to: https://github.com/atlanticcrypto/Discussion/issues/1
status: Draft
@ -12,25 +12,30 @@ created: 2018-08-05
<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
## Simple Summary
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
Network security and overall ecosystem maturity warrants the continued incentivization of Proof of Work participation but allows for a reduction in ancillary ETH issuance and the removal of the Difficulty Bomb. This EIP proposes a reduction of Uncle and removal of Nephew rewards while diffusing and removing the Difficulty Bomb with the Constantinople hard fork.
Network security and overall ecosystem maturity warrants the continued incentivization of Proof of Work participation but may allow for a reduction in ancillary ETH issuance and the delay of the Difficulty Bomb. This EIP proposes a reduction of Uncle and removal of Nephew rewards while delaying the Difficulty Bomb with the Constantinople hard fork.
## Abstract
<!--A short (~200 word) description of the technical issue being addressed.-->
Starting with CNSTNTNPL_FORK_BLKNUM the client will calculate the difficulty without the additional exponential component. Furthermore, Uncle rewards will be adjusted and Nephew rewards will be removed to eliminate excess ancillary ETH issuance. The current ETH block reward of 3 ETH will remain constant.
Starting with CNSTNTNPL_FORK_BLKNUM the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 6 million blocks later than previously specified with the Homestead fork.
Furthermore, Uncle rewards will be adjusted and Nephew rewards will be removed to eliminate excess ancillary ETH issuance. The current ETH block reward of 3 ETH will remain constant.
## Motivation
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
Network scalability and security are at the forefront of risks to the Ethereum protocol. With great strides being made towards on and off chain scalability, the existence of an artificial throughput limiting device in the protocol is no longer warranted. Removing the risk of reducing throughput through the initialization of the Difficulty Bomb is "low-hanging-fruit" to ensure continued operation at a minimum of current throughput into the future.
Network scalability and security are at the forefront of risks to the Ethereum protocol. With great strides being made towards on and off chain scalability, the existence of an artificial throughput limiting device in the protocol is not warranted. Removing the risk of reducing throughput through the initialization of the Difficulty Bomb is "low-hanging-fruit" to ensure continued operation at a minimum of current throughput through the next major hard fork (scheduled for late 2019).
The security layer of the Ethereum network is and should remain robust. Incentives for continued investment into the security of the growing ecosystem are paramount. At the same time, the ancillary issuance benefits of the Ethereum protocol can be adjusted to reduce the overall issuance profile. Aggressively adjusting Uncle and removing Nephew rewards will reduce the inflationary aspect of ETH issuance, while keeping the current block reward constant at 3 ETH will ensure top line incentives stay in place.
The security layer of the Ethereum network is and should remain robust. Incentives for continued operation of the security of the growing ecosystem are paramount.
At the same time, the ancillary issuance benefits of the Ethereum protocol can be adjusted to reduce the overall issuance profile. Aggressively adjusting Uncle and removing Nephew rewards will reduce the inflationary aspect of ETH issuance, while keeping the current block reward constant at 3 ETH will ensure top line incentives stay in place.
## 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)).-->
#### Remove Difficulty Bomb
For the purposes of calc_difficulty, simply remove the exponential difficulty adjustment component, epsilon, i.e. the int(2**((block.number // 100000) - 2)).
#### Relax Difficulty with Fake Block Number
For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula:
fake_block_number = max(0, block.number - 6_000_000) if block.number >= CNSTNTNPL_FORK_BLKNUM else block.number
#### Adjust Uncle and Nephew rewards
If an uncle is included in a block for `block.number >= CNSTNTNPL_FORK_BLKNUM` such that `block.number - uncle.number = k`, the uncle reward is
@ -44,28 +49,38 @@ The nephew reward for `block.number >= CNSTNTNPL_FORK_BLKNUM` is
This is a removal of all rewards for Nephew blocks.
## Rationale
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
The Difficulty Bomb was instituted as a type of planned obsolescence to force the implementation of network upgrades with regular frequency. With the success of and resulting investment in the Ethereum protocol, these network upgrades have been secured through outright adoption and the size of the development community. With a result of the Difficulty Bomb being a reduction in effective network throughput and the risk of inaction inside the development community being reduced substantially, the original purpose of the Difficulty Bomb seems to have been diffused itself. With the focus on scalability for the protocol, eliminating a mechanism whereby the throughput of the network can be limited artificially, due to any circumstance, is a logical step to ensure continued minimum network operation at the current throughput level.
The security layer of the Ethereum network is and should remain robust. Incentives for continued operation of the growing ecosystem’s security are paramount.
At the same time, the ancillary issuance benefits of the Ethereum protocol can be adjusted to reduce the overall issuance profile. Aggressively adjusting Uncle and removing Nephew rewards will reduce the inflationary aspect of ETH issuance, while keeping the current block reward constant at 3 ETH will ensure top line incentives stay in place.
The Difficulty Bomb was instituted as a type of planned obsolescence to force the implementation of network upgrades with regular frequency. With the focus on scalability for the protocol, delaying a mechanism whereby the throughput of the network can be limited artificially, due to any circumstance, is a logical step to ensure continued minimum network operation at the current throughput level. We believe the existence of the Difficulty Bomb has allowed for the inclusion of protocol upgrades in forced hard-forks, and will continue to do so.
Through August 4th, the 2018 year to date reward issued to Uncle blocks totaled over 635,000 ETH. The average reward per Uncle totals 2.27 ETH. The year to date average Uncle rate is 22.49%. Using the year to date metrics, the ongoing average ETH paid as an Uncle reward per block is 0.51 ETH plus the Uncle inclusion reward of 0.021 ETH (0.09375 ETH * .2249), total Uncle related reward per block being over 0.53 ETH. With total year to date block rewards totaling approximately 3,730,000 ETH, the network has paid an additional 17pct in Uncle rewards. This is issuance that can be reduced while still maintaining the overall integrity and incentivization of network security.
Reducing the issuance of ETH in rewarding Uncle blocks (forked blocks caused by latency in propagation, a multi-faceted problem) should directly incentivize the investment in technologies and efficiencies to reduce the overall network Uncle rate which may lead to a reduction in Network wide Uncle rates, reducing ancillary issuance further.
Reducing the issuance of ETH in rewarding Uncle blocks (forked blocks caused by latency in propagation, a multi-faceted problem) should directly incentivize the investment in technologies and efficiencies to reduce block propagation latency which may lead to a reduction in Network wide Uncle rates, reducing ancillary issuance further.
Reducing the Uncle rewards from the current specification to the proposed will yield two levels of ancillary ETH issuance for Uncles:
Level 1 Uncle -> 0.75 ETH
Level 2 Uncle -> 0.375 ETH
These levels are sufficient to continue incentivizing decentralized participation, while also providing an immediate economic incentive for the upgrade of the Ethereum node network and its tangential infrastructure.
We believe that the ETH network has been subsidizing transaction inclusion through the robust Uncle Reward structure since inception. We also believe that a removal of the set subsidy will create a dynamic response mechanism whereby Miners and transaction senders will minimize total costs of transaction inclusion. This dynamic response structure may limit unnecessary layer 1 transaction throughput while providing incentives for layer 2 scaling solutions.
The Nephew reward structure should be entirely eliminated.
Due to current market conditions, and the likelihood of a further USD denominated price decline (50%), we believe that any top line reduction to security incentives will put the Ethereum network at undue risk. Unlike the time of the Byzantium hard fork, current USD denominated economics for securing the Ethereum network threaten the participation of the most decentralized Miner community (at home miners), which we believe make up the largest proportion of the overall network hashrate. We believe eliminating this portion of the community will increase centralization and the probability of an organized network attack.
For a technology so new and with so much potential, we find it extremely irresponsible to increase the likelihood of a network attack by reducing ETH Issuance past this proposal’s level.
With a reduction to the Uncle and removal of the Nephew reward, ancillary ETH issuance should drop (under normal market conditions, i.e. 22.49% uncle rate) by over 75pct and total ETH issuance from the successful sealing and mining of valid blocks should drop over 10pct.
Paired with the diffusal and removal of the Difficulty Bomb, this proposal strikes a balance between ensuring status quo network throughput, reducing overall ETH issuance, and continuing top line incentives for investment in infrastructure and efficiencies to continue expanding the Ethereum protocol's operational security.
Paired with the diffusal of the Difficulty Bomb, this proposal strikes a balance between ensuring status quo network throughput, reducing overall ETH issuance, and continuing top line incentives for investment in infrastructure and efficiencies to continue operating the Ethereum network’s security layer.
## Backwards Compatibility
<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->

12
EIPS/eip-1328.md
View File

@ -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.

40
EIPS/eip-1352.md Normal file
View File

@ -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/).

4
EIPS/eip-1355.md
View File

@ -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

57
EIPS/eip-1380.md Normal file
View File

@ -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/).

2
EIPS/eip-140.md
View File

@ -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

2
EIPS/eip-141.md
View File

@ -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

2
EIPS/eip-145.md
View File

@ -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

1
EIPS/eip-155.md
View File

@ -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) |

69
EIPS/eip-205.md Normal file
View File

@ -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/).

35
EIPS/eip-233.md Normal file
View File

@ -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/).

3
EIPS/eip-5.md
View File

@ -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

2
EIPS/eip-606.md
View File

@ -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

2
EIPS/eip-607.md
View File

@ -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

2
EIPS/eip-608.md
View File

@ -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

2
EIPS/eip-609.md
View File

@ -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

11
EIPS/eip-725.md
View File

@ -241,13 +241,13 @@ MUST be triggered when `approve` was called and the claim was successfully added
## Rationale
This specification was chosen to allow most flexibility and experimention around identity. By having each identity in a separate contract it allows for cross idenity compatibility, but at the same time extra and altered functionality for new use cases.
This specification was chosen to allow most flexibility and experimention around identity. By having each identity in a separate contract it allows for cross identity compatibility, but at the same time extra and altered functionality for new use cases.
The main critic of this standard is the verification where each identity that issues a claim, also should have a separate CLAIM signing key attached. While [#ERC780](https://github.com/ethereum/EIPs/issues/780) uses a standardised registry to assign claims to addresses.
Both systems could work in conjunction and should be explored.
While also off-chain claims using DID verifiable claims and merkle tries can be added as claims and should be explored.
The rationale of this standard is to function as an open and veryf flexible container for idenity.
The rationale of this standard is to function as an open and very flexible container for identity.
## Implementation
@ -281,9 +281,10 @@ contract ERC725 {
}
function getKey(bytes32 _key) public constant returns(uint256[] purposes, uint256 keyType, bytes32 key);
function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists);
function getKeysByPurpose(uint256 _purpose) public constant returns(bytes32[] keys);
function keyHasPurpose(bytes32 _key, uint256 _purpose) public constant returns (bool exists);
function getKeysByPurpose(uint256 _purpose) public constant returns (bytes32[] keys);
function addKey(bytes32 _key, uint256 _purpose, uint256 _keyType) public returns (bool success);
function removeKey(bytes32 _key, uint256 _purpose) public returns (bool success);
function execute(address _to, uint256 _value, bytes _data) public returns (uint256 executionId);
function approve(uint256 _id, bool _approve) public returns (bool success);
}
@ -299,4 +300,4 @@ contract ERC725 {
- [Sovrin Foundation Self Sovereign Identity](https://sovrin.org/wp-content/uploads/2017/06/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf)
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

13
EIPS/eip-777.md
View File

@ -111,9 +111,10 @@ function totalSupply() public view returns (uint256)
Get the total number of minted tokens.
The total supply MUST be equal to the sum of the balances of all addresses&mdash;as returned by the `balanceOf` function.
*NOTE*: The total supply MUST be equal to the sum of the balances of all addresses&mdash;as returned by the `balanceOf` function.
*NOTE*: The total supply MUST be equal to the sum of all the minted tokens as defined in all the `Minted` events minus the sum of all the burned tokens as defined in all the `Burned` events. (This applies as well to [tokens minted when the token contract is created][initial supply].)
The total supply MUST be equal to the sum of all the minted tokens as defined in all the `Minted` events minus the sum of all the burned tokens as defined in all the `Burned` events. One exception is a cloned token (with cloned balances) where the newer token contract MAY have a `totalSupply` greater than the difference of all the `Minted` and `Burned` events.
> <small>**returns:** Total supply of tokens currently in circulation.</small>
@ -157,7 +158,7 @@ The following rules MUST be applied regarding the *granularity*:
*NOTE*: [`defaultOperators`][defaultOperators] and [`isOperatorFor`][isOperatorFor] are also `view` functions, defined under the [operators] for consistency.
*[ERC20] compatibility requirement*:
The decimals of the token MUST always be `18`. For a *pure* ERC777 token the [ERC20] `decimal` function is OPTIONAL, and its existence SHALL NOT be relied upon when interacting with the token contract. (The decimal value of `18` is implied.) For an [ERC20] compatible token, the `decimal` function is REQUIRED and MUST return `18`. (In [ERC20], the `decimals` function is OPTIONAL, but the value if the function is not present, is not clearly defined and may be assumed to be `0`. Hence for compatibility reasons, `decimals` MUST be implemented for [ERC20] compatible tokens.)
The decimals of the token MUST always be `18`. For a *pure* ERC777 token the [ERC20] `decimal` function is OPTIONAL, and its existence SHALL NOT be relied upon when interacting with the token contract. (The decimal value of `18` is implied.) For an [ERC20] compatible token, the `decimal` function is REQUIRED and MUST return `18`. (In [ERC20], the `decimals` function is OPTIONAL. If the function is not present, the `decimals` value is not clearly defined and may be assumed to be `0`. Hence for compatibility reasons, `decimals` MUST be implemented for [ERC20] compatible tokens.)
*[ERC20] compatibility requirement*:
The `name`, `symbol`, `totalSupply`, and `balanceOf` `view` functions MUST be backward compatible with [ERC20].
@ -402,7 +403,8 @@ The token contract MUST `revert` when minting in any of the following cases:
- The *recipient* is a contract, and it does not implement the `ERC777TokensRecipient` interface via [ERC820].
- The address of the *recipient* is `0x0`.
*NOTE*: The initial token supply at the creation of the token contract MUST be considered as minting for the amount of the initial supply to the address (or addresses) receiving the initial supply.
<a id="initialSupply"></a>
*NOTE*: The initial token supply at the creation of the token contract MUST be considered as minting for the amount of the initial supply to the address(es) receiving the initial supply. This means one or more `Minted` events must be emitted and the `tokensReceived` hook of the recipient(s) MUST be called.
*[ERC20] compatibility requirement*:
While a `Sent` event MUST NOT be emitted when minting, if the token contract is [ERC20] backward compatible, a `Transfer` event with the `from` parameter set to `0x0` SHOULD be emitted as defined in the [ERC20] standard.
@ -619,7 +621,7 @@ Notify a send or mint (if `from` is `0x0`) of `amount` tokens from the `from` ad
> <small>`from`: *token holder* for a send and `0x` for a mint.</small>
> <small>`to`: *token recipient*.</small>
> <small>`amount`: Number of tokens the *recipient* balance is increased by.</small>
> <small>`data`: Extra information provided by the *token holder* for a send and nothing (empty bytes) for a mint,.</small>
> <small>`data`: Extra information provided by the *token holder* for a send and nothing (empty bytes) for a mint.</small>
> <small>`operatorData`: Extra information provided by the address which triggered the balance increase.</small>
The following rules apply when calling the `tokensToSend` hook:
@ -759,6 +761,7 @@ Copyright and related rights waived via [CC0].
[sent]: #sent
[minted]: #minted
[burned]: #burned
[initial supply]: #initialSupply
[logos]: https://github.com/ethereum/EIPs/tree/master/assets/eip-777/logo
[beige logo]: ../assets/eip-777/logo/png/ERC-777-logo-beige-48px.png

234
EIPS/eip-820.md
View File

File diff suppressed because one or more lines are too long

4
EIPS/eip-998.md
View File

@ -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).