Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-712: Update eip-712.md #8987

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion EIPS/eip-712.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,13 +15,13 @@

This is a standard for hashing and signing of typed structured data as opposed to just bytestrings. It includes a

* theoretical framework for correctness of encoding functions,

Check failure on line 18 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:18:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 18 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:18:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* specification of structured data similar to and compatible with Solidity structs,

Check failure on line 19 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:19:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 19 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:19:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* safe hashing algorithm for instances of those structures,

Check failure on line 20 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:20:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 20 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:20:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* safe inclusion of those instances in the set of signable messages,

Check failure on line 21 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:21:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 21 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:21:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* an extensible mechanism for domain separation,

Check failure on line 22 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:22:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 22 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:22:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* new RPC call `eth_signTypedData`, and

Check failure on line 23 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:23:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 23 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:23:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* an optimized implementation of the hashing algorithm in EVM.

Check failure on line 24 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:24:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 24 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:24:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

It does not include replay protection.

Expand All @@ -42,13 +42,13 @@
## Specification

The set of signable messages is extended from transactions and bytestrings `𝕋 ∪ 𝔹⁸ⁿ` to also include structured data `𝕊`. The new set of signable messages is thus `𝕋 ∪ 𝔹⁸ⁿ ∪ 𝕊`. They are encoded to bytestrings suitable for hashing and signing as follows:
* `encode(transaction : 𝕋) = RLP_encode(transaction)`

Check failure on line 45 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:45:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 45 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* `encode(transaction : 𝕋) ..."]

EIPS/eip-712.md:45 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "* `encode(transaction : 𝕋) ..."]

Check failure on line 45 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:45:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 45 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* `encode(transaction : 𝕋) ..."]

EIPS/eip-712.md:45 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "* `encode(transaction : 𝕋) ..."]
* `encode(message : 𝔹⁸ⁿ) = "\x19Ethereum Signed Message:\n" ‖ len(message) ‖ message` where `len(message)` is the _non-zero-padded_ ascii-decimal encoding of the number of bytes in `message`.

Check failure on line 46 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:46:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 46 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3]

EIPS/eip-712.md:46:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* `encode(domainSeparator : 𝔹²⁵⁶, message : 𝕊) = "\x19\x01" ‖ domainSeparator ‖ hashStruct(message)` where `domainSeparator` and `hashStruct(message)` are defined below.

This encoding is deterministic because the individual components are. The encoding is injective because the three cases always differ in first byte. (`RLP_encode(transaction)` does not start with `\x19`.)

The encoding is compliant with [EIP-191][EIP-191]. The 'version byte' is fixed to `0x01`, the 'version specific data' is the 32-byte domain separator `domainSeparator` and the 'data to sign' is the 32-byte `hashStruct(message)`.

Check failure on line 51 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC`

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> EIPS/eip-712.md | 51 | The encoding is compliant with [EIP-191][EIP-191]. The 'version byte' is fixed to `0x01`, the 'version specific data' is the 32-byte... | = help: see https://ethereum.github.io/eipw/markdown-refs/

Check failure on line 51 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC`

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> EIPS/eip-712.md | 51 | The encoding is compliant with [EIP-191][EIP-191]. The 'version byte' is fixed to `0x01`, the 'version specific data' is the 32-byte... | = help: see https://ethereum.github.io/eipw/markdown-refs/

[EIP-191]: ./eip-191.md

Expand All @@ -70,7 +70,7 @@

**Definition**: The _atomic types_ are `bytes1` to `bytes32`, `uint8` to `uint256`, `int8` to `int256`, `bool` and `address`. These correspond to their definition in Solidity. Note that there are no aliases `uint` and `int`. Note that contract addresses are always plain `address`. Fixed point numbers are not supported by the standard. Future versions of this standard may add new atomic types.

**Definition**: The _dynamic types_ are `bytes` and `string`. These are like the atomic types for the purposed of type declaration, but their treatment in encoding is different.
**Definition**: The _dynamic types_ are `bytes` and `string`. These are like the atomic types for the purpose of type declaration, but their treatment in encoding is different.

**Definition**: The _reference types_ are arrays and structs. Arrays are either fixed size or dynamic and denoted by `Type[n]` or `Type[]` respectively. Structs are references to other structs by their name. The standard supports recursive struct types.

Expand Down Expand Up @@ -267,7 +267,7 @@

**Alternative 2**: Use ABIv2 function signatures. `bytes4` is not enough to be collision resistant. Unlike function signatures, there is negligible runtime cost incurred by using longer hashes.

**Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the semantics other than the function. This is already causing a practical collision between [EIP-20]'s and [EIP-721]'s `transfer(address,uint256)`, where in the former the `uint256` refers to an amount and the latter to a unique id. In general ABIv2 favors compatibility where a hashing standard should prefer incompatibility.

Check failure on line 270 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC`

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> EIPS/eip-712.md | 270 | **Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the ... |

Check failure on line 270 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC`

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> EIPS/eip-712.md | 270 | **Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the ... |

Check failure on line 270 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC`

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> EIPS/eip-712.md | 270 | **Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the ... |

Check failure on line 270 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC`

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> EIPS/eip-712.md | 270 | **Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the ... |

[EIP-20]: ./eip-20.md
[EIP-721]: ./eip-721.md
Expand Down
Loading