From b78417cd3cca9bdc09865f5bfd58763fabd9e4f6 Mon Sep 17 00:00:00 2001 From: lightclient Date: Sun, 14 Apr 2024 12:14:33 -0600 Subject: [PATCH 1/4] add requests eip --- EIPS/eip-requests.md | 74 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 EIPS/eip-requests.md diff --git a/EIPS/eip-requests.md b/EIPS/eip-requests.md new file mode 100644 index 0000000000000..e0a47f79c2c65 --- /dev/null +++ b/EIPS/eip-requests.md @@ -0,0 +1,74 @@ +--- +title: General purpose exectuion layer requests +description: A general purpose bus for sharing EL triggered requests with the CL +author: lightclient (@lightclient) +status: Draft +type: Standards Track +category: Core +created: 2024-04-14 +--- + +## Abstract + +This proposal defines a general purpose framework for propagating contract-triggered requests from execution layer to the consensus layer. It extends the header and body with only a single field each to store the request information. + +## Motivation + +The proliferation of smart contract controlled validators has caused there to be a demand for additional EL triggered behaviors. By allowing these systems to delegate administrative operations to their governing smart contracts, they can avoid intermediaries needing to step in and ensure certain operations occur. This creates a safer system for end users. + +## Specification + +### Execution Layer + +#### Request + +A `Request` consists of a `RequestType` prepended to an opaque byte array `RequestData`. + +``` +Request = RequestType ++ RequestData +``` + +Let `Requests` be the list of all `Request` objects in the block in ascending order by type. + +#### Header + +Extend the header with a new 32 byte value `RequestsRoot`. + +Let `RequestsRoot` be the root of a Merkle-Patricia trie keyed by the index in the list of `Requests`. This is equivalent to how the transaction trie root is computed. + +### Consensus Layer + +Extend `ExecutionPayload` to include a new field `requests`. Let this value be a union type over all valid request operations. + +A additional processing step is be added to `process_execution_payload` to iterate over and process each`Request` object. + +## Rationale + +### Opaque byte array rather than an RLP array + +By having the second byte on be opaque bytes, rather than an RLP (or other encoding) list, we can support different encoding formats for the transaction payload in the future such as SSZ, LEB128, or a fixed width format. + +### Request source and validity + +This EIP makes no strict requirement where a request may come from nor when/how a request must be validated. This is to provide future protocol designers maximum flexibility. + +The authors' recommendations on source and validity of requests are: + +* The source of requests should be from the execution of transactions. More specifically, transactions which make calls to designated system contracts that store the request in account. The storage would later be retrieved by a post-block system call to the contract. Alternatively, if the system call does not need to be inherently concerned with rate limiting, it could rely simply on emitting an event which is later parsed post-block by the system and converted into a request. +* A request's validity can often not be fully verified at the execution layer. This is why they are referred to merely as "requests"; they do not carry the authority on their own unilaterally catalyze and action. We expect the system contracts to perform whatever validation is possible by the EL and then pass it on to the CL for further validation. + +## Backwards Compatibility + +No backward compatibility issues found. + +## Test Cases + +TODO + +## Security Considerations + +Needs discussion. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From d8dca5c58c7d67ee47e34544c10c3406f03bf9d5 Mon Sep 17 00:00:00 2001 From: lightclient Date: Mon, 15 Apr 2024 06:59:32 -0600 Subject: [PATCH 2/4] 7685: fix typo, add num --- EIPS/{eip-requests.md => eip-7685.md} | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) rename EIPS/{eip-requests.md => eip-7685.md} (98%) diff --git a/EIPS/eip-requests.md b/EIPS/eip-7685.md similarity index 98% rename from EIPS/eip-requests.md rename to EIPS/eip-7685.md index e0a47f79c2c65..56381b2b0d7f8 100644 --- a/EIPS/eip-requests.md +++ b/EIPS/eip-7685.md @@ -1,5 +1,6 @@ --- -title: General purpose exectuion layer requests +eip: 7685 +title: General purpose execution layer requests description: A general purpose bus for sharing EL triggered requests with the CL author: lightclient (@lightclient) status: Draft From c1e31f8a7e5a53373ea1aa6cb3beecbb63d8610a Mon Sep 17 00:00:00 2001 From: lightclient Date: Mon, 15 Apr 2024 08:21:52 -0600 Subject: [PATCH 3/4] 7685: add discussions-to --- EIPS/eip-7685.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-7685.md b/EIPS/eip-7685.md index 56381b2b0d7f8..3313a2f67e95d 100644 --- a/EIPS/eip-7685.md +++ b/EIPS/eip-7685.md @@ -3,6 +3,7 @@ eip: 7685 title: General purpose execution layer requests description: A general purpose bus for sharing EL triggered requests with the CL author: lightclient (@lightclient) +discussions-to: https://ethereum-magicians.org/t/eip-7685-general-purpose-execution-layer-requests/19668 status: Draft type: Standards Track category: Core From e184718271aa91d17659a70143bd816c94e85e64 Mon Sep 17 00:00:00 2001 From: "lightclient@protonmail.com" Date: Mon, 15 Apr 2024 14:00:12 -0600 Subject: [PATCH 4/4] 7685: don't force CL to have requests --- EIPS/eip-7685.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7685.md b/EIPS/eip-7685.md index 3313a2f67e95d..a97f089edf747 100644 --- a/EIPS/eip-7685.md +++ b/EIPS/eip-7685.md @@ -40,9 +40,9 @@ Let `RequestsRoot` be the root of a Merkle-Patricia trie keyed by the index in t ### Consensus Layer -Extend `ExecutionPayload` to include a new field `requests`. Let this value be a union type over all valid request operations. +Each proposal may choose how to extend `ExecutionPayload` to include the new EL request. -A additional processing step is be added to `process_execution_payload` to iterate over and process each`Request` object. +A additional processing step is be added to `process_execution_payload` to iterate over and process all requests. ## Rationale