Automatically merged updates to draft EIP(s) 2831 (#2952)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Gregory Markou 2020-09-07 20:30:40 +03:00 committed by GitHub
parent c5e2c3bf63
commit 7efa703f2f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -87,14 +87,28 @@ Provider.on('tx_cancel', listener: (txCancelInfo: txCancelInfo) => void): Provid
```
This event emits the old transaction hash (`oldTx`), the new transaction hash (`newTx`), the nonce used for both transactions (`nonce`), and the signing address for the transaction (`from`).
A `tx_replacement` is defined as a transaction replacement in which a user has completely replaced a previous transaction with a completely brand new one. The replacement tx must contain the following properties:
- The same nonce as the superseded transaction
```typescript
interface txReplacementInfo {
readonly oldTx: string;
readonly newTx: string;
readonly nonce: string;
readonly from: string;
}
Provider.on('tx_replacement', listener: (txReplacementInfo: txReplacementInfo) => void): Provider;
```
This event emits the old transaction hash (`oldTx`), the new transaction hash (`newTx`), the nonce used for both transactions (`nonce`), and the signing address for the transaction (`from`).
## Rationale
The implementation was chosen to help the ease of implementation for both providers and dapp developers. Since `ProviderMessage` is widely used by dapp developers already it means that the implementation path would be as trivial as adding and additional `if` clause to their existing message listener. This also provides a benefit to dapps in the event that a provider has not yet implemented the `tx_replacement` and will not cause the dapp panic with `undefined` should it be implemented natively (eg: `ethereum.txReplacement(txHash, cb())` which would error with `ethereum.txReplacement()` is not a function).
The implementation was chosen to help the ease of implementation for both providers and dapp developers. Since `ProviderMessage` is widely used by dapp developers already it means that the implementation path would be as trivial as adding and additional `if` clause to their existing message listener. This also provides a benefit to dapps in the event that a provider has not yet implemented the events, it will not cause the dapp panic with `undefined` should it be implemented natively (eg: `ethereum.txCancel(...)` which would error with `ethereum.txReplacement()` is not a function).
## Backwards Compatibility
Many Providers adopted EIP-1193, as this EIP extends the arbitrary `message` event, there should be no breaking changes. All providers that do not support the new `tx_replacement` message should either I) Ignore the message or II) Provide some error to the user (Out of scope).
Many Providers adopted EIP-1193, as this EIP extends the arbitrary `message` event, there should be no breaking changes. All providers that do not support the new events should either I) Ignore the message or II) Provide some error to the user (Out of scope).
## Implementations
@ -139,6 +153,11 @@ ethereum
const { oldTx, newTx, nonce, from } = message.data;
console.log(`Tx ${oldTx} with nonce ${nonce} from ${from} was sped up, the new hash is ${newTx}`)
});
ethereum.on('txReplacementInfo', (info) => {
const { oldTx, newTx, nonce, from } = message.data;
console.log(`Tx ${oldTx} with nonce ${nonce} from ${from} was replaced, the new hash is ${newTx}`)
});
console.log(`Transaction hash ${txHash}`)
})
@ -146,4 +165,4 @@ ethereum
console.error(`Error sending transaction: ${error.code}: ${error.message}`);
});
```
```