[EIP-4844] Return Modulus From Precompile

[adietrichs]

Modifies the point evaluation precompile to return the BLS modulus as a U256 value.
Motivation / rationale to be provided by @dankrad, draft PR until then.

[eth-bot]

All tests passed; auto-merging...

(pass) eip-4844.md

classification
updateEIP

• passed!

[dankrad]

The idea of the VersionedHash is that it enables upgrading the commitment type (for example, to a post-quantum polynomial commitment) without requiring a smart contract upgrade. The PointEvaluationPrecompile simply takes a versioned hash with a proof, and will continue to work once a new commitment type is introduced, possibly on both old and new commitments (or only new ones depending on circumstances of the upgrade).

The PointEvaluationPrecompile can be used by both Optimistic Rollups and zkRollups. The former use it by simply evaluating it at a point determined by the fraud proof game, the latter use this trick in order to determine equivalence to an internal representation of the polynomial.

However, the 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 use the easiest way possible to add this functionality: Just make the PointEvaluationPrecompile return the modulus as well. 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.

[adietrichs]

I added a short version of the explanation by @dankrad to the EIP rationale section. The PR is now open and should be ready to be merged.

[adietrichs]

Regarding the structuring of return data:
Our approach here does meaningfully deviate from prior precompile precedent:

The bn128 pairing check
https://github.com/ethereum/execution-specs/blob/master/src/ethereum/paris/vm/precompiled_contracts/alt_bn128.py#L154

• explicitly returns the success value (instead of making the precompile call fail if success == False)
• pads the return value to 32 bytes

I personally prefer our approach, but there might be value in sticking with precedent?

[SamWilsn]

I am not qualified to comment on reverting in a precompile (though I can't see why it would be a problem.)

That said, it might be best to format the return value according to Solidity ABI encoding?

uint<M>: enc(X) is the big-endian encoding of X, padded on the higher-order (left) side with zero-bytes such that the length is 32 bytes.

[adietrichs]

That said, it might be best to format the return value according to Solidity ABI encoding?

uint<M>: enc(X) is the big-endian encoding of X, padded on the higher-order (left) side with zero-bytes such that the length is 32 bytes.

Added padding for the degree value, so the precompile returns 2*32 bytes now.

[adietrichs]

Already reviewed by @dankrad and @protolambda, merging now.

[axic]

Is this little or big endian? Should be clarified.

[dankrad]

Should be big endian as the EVM is?

[adietrichs]

Yes, I will clarify in a quick separate PR