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.

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

Add EIP: Verkle proof verification precompile #7926

Merged
merged 9 commits into from
Nov 10, 2023
Merged
Changes from 7 commits
Commits
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
93 changes: 93 additions & 0 deletions EIPS/eip-7545.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
---
eip: 7545
title: Verkle proof verification precompile
description: Add a precompile to help dapps verify verkle proofs
author: Guillaume Ballet (@gballet), ...
discussions-to: https://ethereum-magicians.org/t/verkle-proof-verification-precompile/16274
status: Draft
type: Standards Track
category: Core
created: 2023-10-13
---

## Abstract

This EIP proposes the addition of a precompiled contract to provide up-to-date state proof verification capabilities to smart contracts in a stateless Ethereum context.

## Motivation

The proposed proof systems for stateless Ethereum require an upgrade to many tools and applications, that need a simple path to keep their proving systems up-to-date, without having to develop and deploy new proving libraries each time another proof format must be supported.

## Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

A precompiled contract is added at address 0x21, wrapping the stateless ethereum proof verification function.
gballet marked this conversation as resolved.
Show resolved Hide resolved

The precompile requites 4 inputs, tightly encoded:
Copy link
Contributor

@g11tech g11tech Nov 10, 2023

Choose a reason for hiding this comment

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

Suggested change
The precompile requites 4 inputs, tightly encoded:
The precompile requires 4 fixed size inputs concatenated as below:


* `version` specifies which version of the stateless proof verification function should be used
* `proof_data_location` is a memory address where the start of the proof data can be found
* `proof_data_size` specifies the length of the proof data.
* `state_root` specifies the state root that the proof is proving against.
gballet marked this conversation as resolved.
Show resolved Hide resolved

Pseudo-code behavior of the precompile:

```python
def proof_verification_precompile(version, loc, size, root):
if version == 0:
proof = deserialize_proof(root, memory[loc:loc+size])
return verify_multiproof_pcs(proof)

return 0
```

If `version` is `0` then the proof is expected to follow the SSZ format described in "the verge" proposal in the consensus spec.

If the precompile returns `1` if it was able to verify the proof, and `0` otherwise.
gballet marked this conversation as resolved.
Show resolved Hide resolved

### Gas costs

|Constant name|cost|
|-|-|
|`POINT_COST`|TBD|
|`POLY_EVAL_COST`|TBD|

The precompile cost is:

`cost = (POINT_COST + 1)*len(get_commitments(input)) + POLY_EVAL_COST * [leaf_depth(key, get_tree(input)) for key in get_keys(input))]`

where:

* `get_commitments` extracts the list of commitments in the proof, as encoded in `input`
* `get_keys` extracts the list of keys in the proof, as encoded in `input`
* `leaf_depth` returns the depth of the leaf in the tree
* `get tree` reconstruct a stateless view of the tree from `input`

## Rationale

Stateless Ethereum relies on proofs using advanced mathematical concepts and tools from a fast-moving area of cryptography. As a result, a soft-fork approach is currently favored in the choice of the proof format: proofs are going to be distributed outside of consensus, and in the future, stateless clients will be able to chose their favorite proof format.

This introduces a burden on several application, e.g. bridges, as they will potentially need to support proof formats designed after the release of the bridge contract.

Delegating the proof verification burden to a version-aware precompile will ensure that these applications can support newer proving primitives without having to upgrade their contracts.

## Backwards Compatibility

No backward compatibility issues found.

## Test Cases

TODO

## Reference Implementation

TODO

## Security Considerations

Needs discussion.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading