Skip to content

Commit

Permalink
EIP 2400 - Tx hash URI: Move from Stagnant to Review (#5217)
Browse files Browse the repository at this point in the history 
* Create eip-non_wallet_keys

* Update and rename eip-non_wallet_keys to eip-non_wallet_keys.md

* Update eip-non_wallet_keys.md

correct typo

* Update and rename eip-non_wallet_keys.md to eip-1581.md

* Update eip-1581.md

* Transaction Hash URI Draft

* update EIP number

* spellcheck

* rename title, more clear semantics

* grammar fix

* spellcheck

* fix  EIP to valid

* move discussions to ethereum-magicians

* Update EIPS/eip-2400.md

Co-Authored-By: Alex Beregszaszi <[email protected]>

* Update EIPS/eip-2400.md

Co-Authored-By: Alex Beregszaszi <[email protected]>

* Update EIPS/eip-2400.md

Co-Authored-By: Alex Beregszaszi <[email protected]>

* use github usernames

* Use correct term

* adapt eip-831 copied text to 2400 type

* fix duplicated link

* add examples

* better rationale

* submitted transaction

* better abstract

* Update EIPS/eip-2400.md

fix syntax error copied from #681

Co-Authored-By: MrChico <[email protected]>

* tx status, err msgs, event details, + rationale

* error details, some `should`s must be `must`s

* spacing

* fix title

* fix EIP title and add 155 requirement

* move to review status

* Apply suggestions from code review

Co-authored-by: Pandapip1 <[email protected]>

* fixed links

* remove references to ERC-831

* Fix references to EIP-681

* Remove references section

* Remove external links from body

* Rename Title "Simple Summary" to "Description"

* Move use cases to motivation

* Elaborate on motivation

* move description from body to header

* reorder header elements

* reorder header element required to after created

* remove reference to EIP-20

* Update title and description

Co-authored-by: Bitgamma <[email protected]>
Co-authored-by: Nick Johnson <[email protected]>
Co-authored-by: Alex Beregszaszi <[email protected]>
Co-authored-by: MrChico <[email protected]>
Co-authored-by: Pandapip1 <[email protected]>
  • Loading branch information
@3esmit @bitgamma
@Arachnid @axic @MrChico @Pandapip1
6 people authored Jul 22, 2022
1 parent b54a123 commit 7483cdf
Showing 1 changed file with 26 additions and 30 deletions.
56 changes: 26 additions & 30 deletions EIPS/eip-2400.md
View file
Original file line number Diff line number Diff line change
@@ -1,48 +1,43 @@
---
eip: 2400
title: URL Format for Transaction Receipts
title: Transaction Receipt URI
description: URI format for submitted transactions with complete information for transaction decoding
author: Ricardo Guilherme Schmidt (@3esmit), Eric Dvorsak (@yenda)
discussions-to: https://ethereum-magicians.org/t/eip-2400-transaction-receipt-uri/
status: Review
type: Standards Track
category: ERC
status: Stagnant
created: 2019-11-05
requires: 155, 831
requires: 155, 681
---
## Abstract

## Simple Summary

A standardized URI for transaction receipt with complete information about transaction.
A transaction hash is not very meaningful on its own, because it looks just like any other hash, and it might lack important information for reading a transaction.

A standard way of representing a submitted transaction.
This standard includes all needed information for displaying a transaction and its details, such as `chainId`, `method` signature called, and `events` signatures emitted.

## Abstract
## Motivation

A transaction hash is not very meaningful on its own, because it looks just like any other hash, and it might lack important information for reading a transaction.
This standard includes all needed information for displaying a transaction and it's details, such as `chainId`, `method` signature called and `events` signatures emitted.
Interoperability between ethereum clients, allowing different systems to agree on a standard way of representing submitted transactions hashes, optionally with necessary information for decoding transaction details.

### Use-cases

Transaction Receipt URIs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URI format allows for instant invocation of the user’s preferred transaction explorer application. Such as:

- In web3 (dapps, mining pools, exchanges), links would automatically open user's preferred transaction explorer;
- In wallets, for users sharing transaction receipts easier;
- In chat applications, as a reply to an [ERC-681] transaction request;
- In chat applications, as a reply to an [EIP-681] transaction request;
- In crypto vending machines, a QRCode can be displayed when transactions are submitted;
- Anywhere transaction receipts are presented to users.

## Motivation

Interoperability for web3: wallets, browsers and messengers.

## Specification

### Syntax

Transaction receipt URLs contain "ethereum" in their schema (protocol) part and are constructed as follows:

receipt = erc831_part transaction_hash [ "@" chain_id ] [ "?" parameters ]
erc831_part = "ethereum:tx-"
receipt = schema_part transaction_hash [ "@" chain_id ] [ "?" parameters ]
schema_part = "ethereum:tx-"
transaction_hash = "0x" 64*HEXDIG
chain_id = 1*DIGIT
parameters = parameter *( "&" parameter )
Expand All @@ -57,26 +52,32 @@ Transaction receipt URLs contain "ethereum" in their schema (protocol) part and
event_type = ["!"] TYPE


Where `TYPE` is a standard ABI type name, as defined in [Ethereum Contract ABI specification](https://solidity.readthedocs.io/en/develop/abi-spec.html). `STRING` is a URL-encoded unicode string of arbitrary length.
Where `TYPE` is a standard ABI type name, as defined in Ethereum Contract ABI specification. `STRING` is a URL-encoded unicode string of arbitrary length.

The exclamation symbol (`!`), in `event_type`, is used to identify indexed event parameters.

### Semantics

`transaction_hash` is mandatory. The hash must be looked up in the corresponding `chain_id` transaction history, if not found it should be looked into the pending transaction queue and rechecked until is found. If not found anequivalent error as "transaction not found error" should be shown instead of the transaction. When the transaction is pending, it should keep checking until the transaction is included in a block and becomes "unrevertable" (usually 12 blocks after transaction is included).

`chain_id` is optional and contains the decimal chain ID, such that transactions on various test and private networks can be represented as well. If no `chain_id` is present, the $ETH/mainnet (`1`) is considered.

`chain_id` is specified by [EIP-155] optional and contains the decimal chain ID, such that transactions on various test and private networks can be represented as well. If no `chain_id` is present, the $ETH/mainnet (`1`) is considered.

If `method` is not present, this means that the transaction receipt URI does not specify details, or that it was a transaction with no calldata. When present it needs to be validated by comparing the first 4 bytes of transaction calldata with the first 4 bytes of the keccak256 hash of `method`, if invalid, an equivalent error as "method validation error" must be shown instead of the transaction.

If `events` is not present, this means that the transaction receipt URI does not specify details, or that the transaction did not raised any events. Pending and failed transactions don't validate events, however, when transaction is successful (or changes from pending to success) and events are present in URI, each event in the `event_list` must occur at least once in the transaction receipt event logs, otherwise an equivalent error as "event validation error: {event(s) [$event_signature, ...] not found}" should be shown instead of the transaction.
If `events` is not present, this means that the transaction receipt URI does not specify details, or that the transaction did not raised any events. Pending and failed transactions don't validate events, however, when transaction is successful (or changes from pending to success) and events are present in URI, each event in the `event_list` must occur at least once in the transaction receipt event logs, otherwise an equivalent error as "event validation error: {event(s) [$event_signature, ...] not found}" should be shown instead of the transaction. A URI might contain the event signature for all, some or none of the raised events.

#### Examples

Simple ETH transfer:
##### Simple ETH transfer:
`ethereum:tx-0x1143b5e38fe3cf585fb026fb9b5ce35c85a691786397dc8a23a07a62796d8172@1`

[Complex contract transaction](https://etherscan.io/tx/0x4465e7cce3c784f264301bfe26fc17609855305213ec74c716c7561154b76fec#eventlog):
##### Standard Token transfer:

`ethereum:tx-0x5375e805b0c6afa20daab8d37352bf09a533efb03129ba56dee869e2ce4f2f92@1?method="transfer(address,uint256)"&events="Transfer(!address,!address,uint256)"`

##### Complex contract transaction:

`ethereum:tx-0x4465e7cce3c784f264301bfe26fc17609855305213ec74c716c7561154b76fec@1?method="issueAndActivateBounty(address,uint256,string,uint256,address,bool,address,uint256)"&events="Transfer(!address,!address,uint256);BountyIssued(uint256);ContributionAdded(uint256,!address,uint256);BountyActivated(uint256,address)"`

## Rationale
Expand All @@ -89,16 +90,11 @@ In order to decode transaction parameters and events, a part of the ABI is requi

## Backwards Compatibility

Future upgrades that are partially or fully incompatible with this proposal must use a prefix other than `tx-` that is separated by a dash (-) character from whatever follows it, as specified by [ERC-831].

## References

* [ERC-831]
* [ERC-681]
Future upgrades that are partially or fully incompatible with this proposal must use a prefix other than `tx-` that is separated by a dash (-) character from whatever follows it.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

[ERC-831]: ./eip-831.md
[ERC-681]: ./eip-681.md
[EIP-155]: ./eip-155.md
[EIP-681]: ./eip-681.md

0 comments on commit 7483cdf

Please sign in to comment.