Skip to content

Commit

Permalink
Merge branch 'ethereum:master' into patch-1
Browse files Browse the repository at this point in the history
  • Loading branch information
GAEAlimited authored Jun 21, 2024
2 parents 775c7bf + 62419ca commit 2a3c174
Show file tree
Hide file tree
Showing 4 changed files with 40 additions and 9 deletions.
22 changes: 22 additions & 0 deletions EIPS/eip-1.md
Original file line number Diff line number Diff line change
Expand Up @@ -216,6 +216,28 @@ Permitted Execution Client Specifications URLs must anchor to a specific commit,
^(https://github.com/ethereum/execution-specs/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-specs/tree/[0-9a-f]{40}/.*)$
```

### Execution Specification Tests

Links to the Ethereum Execution Specification Tests (EEST) may be included using normal markdown syntax, such as:

```markdown
[Ethereum Execution Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/c9b9307ff320c9bb0ecb9a951aeab0da4d9d1684/README.md)
```

Which renders to:

[Ethereum Execution Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/c9b9307ff320c9bb0ecb9a951aeab0da4d9d1684/README.md)

Permitted Execution Specification Tests URLs must anchor to a specific commit, and so must match one of these regular expressions:

```regex
^https://(www\.)?github\.com/ethereum/execution-spec-tests/(blob|tree)/[a-f0-9]{40}/.+$
```

```regex
^https://(www\.)?github\.com/ethereum/execution-spec-tests/commit/[a-f0-9]{40}$
```

### Consensus Layer Specifications

Links to specific commits of files within the Ethereum Consensus Layer Specifications may be included using normal markdown syntax, such as:
Expand Down
14 changes: 7 additions & 7 deletions EIPS/eip-2537.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ The motivation of this precompile is to add a cryptographic primitive that allow
| BLS12_G2ADD | 0x0e | precompile address |
| BLS12_G2MUL | 0x0f | precompile address |
| BLS12_G2MSM | 0x10 | precompile address |
| BLS12_PAIRING | 0x11 | precompile address |
| BLS12_PAIRING_CHECK | 0x11 | precompile address |
| BLS12_MAP_FP_TO_G1 | 0x12 | precompile address |
| BLS12_MAP_FP2_TO_G2 | 0x13 | precompile address |

Expand All @@ -45,7 +45,7 @@ If `block.timestamp >= FORK_TIMESTAMP` we introduce *nine* separate precompiles
- BLS12_G2ADD - to perform point addition in G2 (curve over quadratic extension of the base prime field) with a gas cost of `800` gas
- BLS12_G2MUL - to perform point multiplication in G2 (curve over quadratic extension of the base prime field) with a gas cost of `45000` gas
- BLS12_G2MSM - to perform multi-scalar-multiplication (MSM) in G2 (curve over quadratic extension of the base prime field) with a gas cost formula defined in the corresponding section
- BLS12_PAIRING - to perform a pairing operations between a set of *pairs* of (G1, G2) points a gas cost formula defined in the corresponding section
- BLS12_PAIRING_CHECK - to perform a pairing operations between a set of *pairs* of (G1, G2) points a gas cost formula defined in the corresponding section
- BLS12_MAP_FP_TO_G1 - maps base field element into the G1 point with a gas cost of `5500` gas
- BLS12_MAP_FP2_TO_G2 - maps extension field element into the G2 point with a gas cost of `75000` gas

Expand Down Expand Up @@ -115,7 +115,7 @@ On inputs that can not be a valid encodings of field elements the precompile *mu

#### Encoding of points in G1/G2:

Points of G1 and G2 are encoded as byte concatenation of the respective encodings of the `x` and `y` coordinates. Total encoding length for a G1 point is thus `128` bytes and for a G2 point is `256` bytes.
Points of G1 and G2 are encoded as byte concatenation of the respective encodings of the `x` and `y` coordinates. Total encoding length for a G1 point is thus `128` bytes and for a G2 point is `256` bytes.

#### Point of infinity encoding:

Expand Down Expand Up @@ -203,9 +203,9 @@ Error cases:
- An input is on the G2 elliptic curve but not in the correct subgroup
- Input has invalid length

#### ABI for pairing
#### ABI for pairing check

Pairing call expects `384*k` (`k` being a **positive** integer) bytes as an inputs that is interpreted as byte concatenation of `k` slices. Each slice has the following structure:
Pairing check call expects `384*k` (`k` being a **positive** integer) bytes as an inputs that is interpreted as byte concatenation of `k` slices. Each slice has the following structure:

- `128` bytes of G1 point encoding
- `256` bytes of G2 point encoding
Expand Down Expand Up @@ -285,9 +285,9 @@ Discounts table as a vector of pairs `[k, discount]`:

`max_discount = 174`

#### Pairing operation
#### Pairing check operation

The cost of the pairing operation is `43000*k + 65000` where `k` is a number of pairs.
The cost of the pairing check operation is `43000*k + 65000` where `k` is a number of pairs.

#### Fp-to-G1 mapping operation

Expand Down
4 changes: 2 additions & 2 deletions EIPS/eip-2982.md
Original file line number Diff line number Diff line change
Expand Up @@ -212,8 +212,8 @@ Censorship of transactions can potentially be detected by clients in a consensus

Here is the current expected security properties expressed in a table:

|| Network delay <3s |Network delay 3s - 6 min|Network delay > 6 min|
|---|---|---|---|---|
| | Network delay <3s |Network delay 3s - 6 min|Network delay > 6 min|
|---|---|---|---|
|>2/3 validators honest|Perfect operation|Imperfect but acceptable operation. No rigorous proof of liveness, but liveness expected in practice.|Likely intermittent liveness failures, no safety failures|
|>2/3 validators rational, <1/3 coordinated|Perfect operation|Imperfect but acceptable operation, heightened centralization risk|Likely intermittent liveness failures, no safety failures, very high centralization risk|
|51% attacker|Can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains|Can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains|Can revert finality or censor; cannot force through invalid or unavailable chains|
Expand Down
9 changes: 9 additions & 0 deletions EIPS/eip-3540.md
Original file line number Diff line number Diff line change
Expand Up @@ -164,6 +164,7 @@ The following validity constraints are placed on the container format:
- `container_size` may not be `0`
- data section is mandatory, but `data_size` may be `0`
- data body length may be shorter than `data_size` for a not yet deployed container
- the total size of a container must not exceed `MAX_INITCODE_SIZE` (as defined in [EIP-3860](./eip-3860.md))

### Changes to execution semantics

Expand All @@ -180,6 +181,8 @@ For a legacy contract:
- If the target account of `EXTCODEHASH` is an EOF contract, then it will return `0x9dbf3648db8210552e9c4f75c6a1c3057c0ca432043bd648be15fe7be05646f5` (the hash of `EF00`, as if that would be the code).
- If the target account of `EXTCODESIZE` is an EOF contract, then it will return 2.

**NOTE** Like for legacy targets, the aforementioned behavior of `EXTCODECOPY`, `EXTCODEHASH` and `EXTCODESIZE` does not apply to EOF contract targets mid-creation, i.e. those report same as accounts without code.

## Rationale

EVM and/or account versioning has been discussed numerous times over the past years. This proposal aims to learn from them.
Expand Down Expand Up @@ -236,6 +239,12 @@ See section [Lack of `EXTDATACOPY` in EIP-7480](./eip-7480.md#lack-of-extdatacop

Currently contracts can selfdestruct in three different ways (directly through `SELFDESTRUCT`, indirectly through `CALLCODE` and indirectly through `DELEGATECALL`). [EIP-3670](./eip-3670.md) disables the first two possibilities, however the third possibility remains. Allowing EOF1 contracts to only `DELEGATECALL` other EOF1 contracts allows the following strong statement: EOF1 contract can never be destructed. Attacks based on `SELFDESTRUCT` completely disappear for EOF1 contracts. These include destructed library contracts (e.g. Parity Multisig).

### EOF1 containers have a size limit

Imposing an EOF-validation time limit for the size of EOF containers provides a reference limit of how large the containers should EVM implementations be able to handle when validating and processing containers. `MAX_INITCODE_SIZE` was chosen for EOF1, as it is what contract creation currently allows for.

Given one of the main reasons for the limit is to avoid attack vectors on `JUMPDEST`-analysis, and EOF removes the need for `JUMPDEST`-analysis and introduces a cost structure for deploy-time analysis, in the future this limit could be increased or even lifted for EOF.

## Backwards Compatibility

This is a breaking change given that any code starting with `0xEF` was not deployable before (and resulted in exceptional abort if executed), but now some subset of such codes can be deployed and executed successfully.
Expand Down

0 comments on commit 2a3c174

Please sign in to comment.