Skip to content

Commit

Permalink
[EIP-4844] Return Modulus From Precompile (#5864)
Browse files Browse the repository at this point in the history
* return modulus from precompile

* add FIELD_ELEMENTS_PER_BLOB to return data

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

* add precompile return data rationale

* add return value padding

* change precompile rationale wording

Co-authored-by: dankrad <[email protected]>
  • Loading branch information
adietrichs and dankrad authored Nov 22, 2022
1 parent cf0e827 commit 1226bfe
Showing 1 changed file with 7 additions and 3 deletions.
10 changes: 7 additions & 3 deletions EIPS/eip-4844.md
Original file line number Diff line number Diff line change
Expand Up @@ -273,7 +273,7 @@ def point_evaluation_precompile(input: Bytes) -> Bytes:
# Quotient kzg: next 48 bytes
quotient_kzg = input[144:192]
assert verify_kzg_proof(data_kzg, x, y, quotient_kzg)
return Bytes([])
return Bytes(U256(FIELD_ELEMENTS_PER_BLOB).to_bytes32() + U256(BLS_MODULUS).to_bytes32())
```

### Gas price of blobs (Simplified version)
Expand Down Expand Up @@ -426,14 +426,18 @@ the kzg in the blob and some commitment using whatever proof system the ZK rollu
They would use a commitment proof of equivalence protocol, using the point evaluation precompile,
to prove that the kzg (which the protocol ensures points to available data) and the ZK rollup's own commitment refer to the same data.

### Versioned hashes
### Versioned hashes & precompile return data

We use versioned hashes (rather than kzgs) as references to blobs in the execution layer to ensure forward compatibility with future changes.
For example, if we need to switch to Merkle trees + STARKs for quantum-safety reasons, then we would add a new version,
allowing the point verification precompile to work with the new format.
allowing the point evaluation precompile to work with the new format.
Rollups would not have to make any EVM-level changes to how they work;
sequencers would simply have to switch over to using a new transaction type at the appropriate time.

However, the point evaluation happens inside a finite field, and it is only well defined if the field modulus is known. Smart contracts could contain a table mapping the commitment version to a modulus, but this would not allow smart contract to take into account future upgrades to a modulus that is not known yet. By allowing access to the modulus inside the EVM, the smart contract can be built so that it can use future commitments and proofs, without ever needing an upgrade.

In the interest of not adding another precompile, we return the modulus and the polynomial degree directly from the point evaluation precompile. It can then be used by the caller. It is also "free" in that the caller can just ignore this part of the return value without incurring an extra cost -- systems that remain upgradable for the foreseeable future will likely use this route for now.

### Data gasprice update rule

The data gasprice update rule is intended to approximate the formula `data_gasprice = MIN_DATA_GASPRICE * e**(excess_data_gas / DATA_GASPRICE_UPDATE_FRACTION)`,
Expand Down

0 comments on commit 1226bfe

Please sign in to comment.