From ff946f26bbc59800bbdb7c0f06ec899cebceef11 Mon Sep 17 00:00:00 2001 From: wmjae Date: Mon, 28 Apr 2025 09:52:04 +0800 Subject: [PATCH 1/2] Update EIP-7691: typo fix --- EIPS/eip-712.md | 4 ++-- EIPS/eip-7691.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-712.md b/EIPS/eip-712.md index 0f1fc699b9051a..4ac7f9516a11ca 100644 --- a/EIPS/eip-712.md +++ b/EIPS/eip-712.md @@ -115,7 +115,7 @@ where the type of `eip712Domain` is a struct named `EIP712Domain` with one or mo * `string version` the current major version of the signing domain. Signatures from different versions are not compatible. * `uint256 chainId` the [EIP-155][EIP-155] chain id. The user-agent *should* refuse signing if it does not match the currently active chain. * `address verifyingContract` the address of the contract that will verify the signature. The user-agent *may* do contract specific phishing prevention. -* `bytes32 salt` an disambiguating salt for the protocol. This can be used as a domain separator of last resort. +* `bytes32 salt` a disambiguating salt for the protocol. This can be used as a domain separator of last resort. [EIP-155]: ./eip-155.md @@ -321,7 +321,7 @@ function hashStruct(Mail memory mail) pure returns (bytes32 hash) { The in-place implementation makes strong but reasonable assumptions on the memory layout of structs in memory. Specifically it assumes structs are not allocated below address 32, that members are stored in order, that all values are padded to 32-byte boundaries, and that dynamic and reference types are stored as a 32-byte pointers. -**Alternative 6**: Tight packing. This is the default behaviour in Soldity when calling `keccak256` with multiple arguments. It minimizes the number of bytes to be hashed but requires complicated packing instructions in EVM to do so. It does not allow in-place computation. +**Alternative 6**: Tight packing. This is the default behaviour in Solidity when calling `keccak256` with multiple arguments. It minimizes the number of bytes to be hashed but requires complicated packing instructions in EVM to do so. It does not allow in-place computation. **Alternative 7**: ABIv2 encoding. Especially with the upcoming `abi.encode` it should be easy to use `abi.encode` as the `encodeData` function. The ABIv2 standard by itself fails the determinism security criteria. There are several valid ABIv2 encodings of the same data. ABIv2 does not allow in-place computation. diff --git a/EIPS/eip-7691.md b/EIPS/eip-7691.md index 51ebf0e9dc99ff..76a8a3e6e4341d 100644 --- a/EIPS/eip-7691.md +++ b/EIPS/eip-7691.md @@ -78,7 +78,7 @@ Through the use of big block/blob tests on Ethereum mainnet as well as testnets, ### Stability Around Fork Epoch -A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected co-ordination efforts. +A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected coordination efforts. ## Copyright From a36cec5074848acd56e94425f37b878dfe354038 Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Tue, 27 May 2025 12:22:12 -0400 Subject: [PATCH 2/2] Update eip-7691.md --- EIPS/eip-7691.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7691.md b/EIPS/eip-7691.md index 76a8a3e6e4341d..51ebf0e9dc99ff 100644 --- a/EIPS/eip-7691.md +++ b/EIPS/eip-7691.md @@ -78,7 +78,7 @@ Through the use of big block/blob tests on Ethereum mainnet as well as testnets, ### Stability Around Fork Epoch -A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected coordination efforts. +A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected co-ordination efforts. ## Copyright