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.

Sign up for GitHub

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

Jump to bottom

[EIP-4844] Return Modulus From Precompile #5864

Merged
merged 5 commits into from
Nov 22, 2022
Merged

[EIP-4844] Return Modulus From Precompile #5864

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e6c9a89
return modulus from precompile
adietrichs Nov 1, 2022
e61cb64
add FIELD_ELEMENTS_PER_BLOB to return data
adietrichs Nov 8, 2022
56bab3e
add precompile return data rationale
adietrichs Nov 8, 2022
49156d0
add return value padding
adietrichs Nov 22, 2022
43f6cda
change precompile rationale wording
adietrichs Nov 22, 2022
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
10 changes: 7 additions & 3 deletions EIPS/eip-4844.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -271,7 +271,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())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this little or big endian? Should be clarified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be big endian as the EVM is?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I will clarify in a quick separate PR

```

### Gas price of blobs (Simplified version)
Expand Down Expand Up @@ -424,14 +424,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