From 269c180c646961ef517997cb1a32f87128088dfa Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Fri, 31 Mar 2023 16:04:53 -0700 Subject: [PATCH 01/24] Initial Commit for PR - Added Readme.md - Updated glossary with new terms - Added Abstract and 1.1 Overview - Added Section 2 with subsections - Section 3: Started adding requirements and testablity statements --- workitems/l2-transaction-fees/README.md | 35 ++++ .../l2-transaction-fees-v1.0-psd01.md | 188 ++++++++++++++++-- 2 files changed, 202 insertions(+), 21 deletions(-) create mode 100644 workitems/l2-transaction-fees/README.md diff --git a/workitems/l2-transaction-fees/README.md b/workitems/l2-transaction-fees/README.md new file mode 100644 index 0000000..d961212 --- /dev/null +++ b/workitems/l2-transaction-fees/README.md @@ -0,0 +1,35 @@ +# L2 WG: Layer 2 Transaction Fee Specification + + +## Layer 2 Transaction Fee Specification + +The document describes the minimal set of business and technical prerequisites, functional and non-functional requirements for Layer 2 Transaction Fees that when implemented ensures that Layer 2 solutions are transparently and consistently calculating and displaying transaction fees. + +## Status + +The Layer 2 Transaction Fee Specification has no status yet. + +## Components + + + + + + + + + + + + + + +
ComponentComponent Description
Definitions, key concepts, and overview of the elements of a compliant Layer 2 Transaction Fee.Layer 2 Transaction Fee Specification
ConformanceDescribes the conformance clauses and tests required to achieve compliant implementations.
+ +## License + +All contribution in this repo is released under the CC0 1.0 Universal public domain dedication. For the full license text, refer to [LICENSE](ttps://github.com/eea-oasis/L2/blob/main/LICENSE.md). + +## Contributions + +To participate in the evolution of this and other L2 working group specifications, please see our [Contributors Guidelines](https://github.com/eea-oasis/L2/blob/main/CONTRIBUTING.md). diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 1134e0a..0c53717 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -2,7 +2,7 @@ ![EEA Logo](../l2-transaction-fees/images/eea-symbol.png) ------- -# L2 Token List Version 1.0 +# Layer 2 Transaction Fee Specification Version 1.0 ## Project Specification Draft @@ -120,36 +120,59 @@ The work is an [EEA Community Project](https://entethalliance.org/eeacommunitypr ## 1.1 Overview -TBD +Layer 2 (L2) Transaction Fees are a crucial element of financing the operations of L2 platforms apart from rewards given to participants for providing economic security guarantees such as validators in consensus protocols. Yet how these transaction fees are derived, to whom they are paid, how and where they are displayed to any of the participants in L2 platforms varies greatly between L2 platforms. + +Given the above, the need for transparency in a open ecosystem to build trust, and the evolving legal and regulatory landscape around fee transparency and what type of fees can be charged, this document sets out to define the different types of L2 transaction fees and then define requirements around transaction fee transparency for L2 platforms. + +Note, that fees associated with asset and data bridges between L2 platforms is beyond the scope of this document, as well as between L2 platforms and centralized exchanges. ## 1.2 Glossary -**Blockchain:** +**Account:** -An open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. +A unit that is minimally comprised of a unique account identifier, a deterministic ordering parameter, also referred to as a nonce, a balance of a Layer 1, Layer 2 or Sidechain unit of exchange, also referred to as a protocol token. Changes to an account are controlled by a unique cryptographic public and private key pair. There are typically additional account elements referring to instructions and data associated to the account that determine account changes. -**Gas** +**Base Fee:** -Refers to the unit that measures the amount of computational and storage effort required to execute specific operations on an EVM-compatible network. +The minimum amount of gas or a Layer 2 gas equivalent unit of compute and storage consumption required to include a transaction on a Layer 2. -**Fee Price** +**Blockchain:** -A Layer 2 gas price or a price of a Layer 2 gas equivalent unit of compute and storage consumption. +An open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. -Note that a gas price or a price of a Layer 2 gas equivalent unit of compute and storage consumption is typically variable and changes with the level of usage of a Layer 2 network. Note, that a gas price is expressed in Giga Wei (GWEI) for EVM-compatible networks, where Wei represents the smallest unit of gas; 1 Wei = 10-18 Eth in Ethereum's native token. +**Bridge:** -**Base Fee** +The means for the transfer of information and digital assets between between Layer 2s, Layer 1s, and Sidechains. -The minimum amount of gas or a Layer 2 gas equivalent unit of compute and storage consumption required to include a transaction on a Layer 2. +**Developer:** + +An individual writing computer code for software applications that operate on a Layer 1, Layer 2 or Sidechain. + +**Direct Transaction:** +A transaction where the transaction originator is also the transaction sender. -**Execution Fee** +**Execution Fee:** A fee to be paid by the transaction originator sufficient to cover both the Layer 2 and Layer 1 transaction fees. An example calculation of such an Execution Fee is: $$L2\space Gas\space Limit + {L1\space Transaction\space Fee \over L2\space Gas\space Price}$$ +**Fee Price:** + +A Layer 2 gas price or a price of a Layer 2 gas equivalent unit of compute and storage consumption. + +Note that a gas price or a price of a Layer 2 gas equivalent unit of compute and storage consumption is typically variable and changes with the level of usage of a Layer 2 network. Note, that a gas price is expressed in Giga Wei (GWEI) for EVM-compatible networks, where Wei represents the smallest unit of gas; 1 Wei = 10-18 Eth in Ethereum's native token. + +**Gas:** + +Refers to the unit that measures the amount of computational and storage effort required to execute specific operations on an EVM-compatible network. + +**Intermediary:** + +An entity that is the sender of a transaction for which it is not the transaction originator. + **Layer 1:** A base network, such as Bitcoin, or Ethereum, and its underlying infrastructure that validates and finalizes transactions without the need of another network. @@ -158,29 +181,57 @@ A base network, such as Bitcoin, or Ethereum, and its underlying infrastructure A secondary framework or protocol that is built on top of an existing Layer 1 system in such a way that it inherits the security properties of the Layer 1 system while allowing for a higher transaction throughput that the Layer 1 system. -**Maximal Extractable Value** +**Layer 2 Operator:** + +An entity responsible for the operation of a Layer 2. + +**Maximal Extractable Value:** Refers to the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. -**Priority Fee** +**Meta Transaction:** + +A transaction where the transaction sender is not the transaction originator, and the transaction fee for the transaction originator is different if the same transaction was a direct transaction. + +**Priority Fee:** To be paid by the transaction originator to a Layer 2 sequencer to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. -**Sequencer** +**Sequencer:** Collects transactions, publishes them in a batch to the Layer 1 on which the Layer 2 operates, receives transaction fees from the published transactions, pays Layer 2 fees to other Layer 2 protocol participants, and, if required, participates in a consensus algorithm with other sequencers to determine transaction ordering in a block. - **Sidechain:** A secondary blockchain connected to the main blockchain with a two-way peg and using its own trust assumptions. -**Transaction Fee** +**State:** + +The set of all accounts on a Layer 2 that are mapped to one another using a cryptographic data structure. + +**State Transition:** + +An event that deterministically changes one or more accounts in the set of all accounts that comprise the complete state of a Layer 2. + +**Transaction:** + +A digitally signed message sent from an Layer 2 account that contains instructions and data that result in a Layer 2 state transition. + +**Transaction Fee:** The fee in a Layer 2 network or protocol token to be paid by a transaction originator comprised of the sum of a Base Fee, an Execution Fee and a Priority Fee. +**Transaction Originator:** + +The account that created a transaction for a Layer 1, Layer 2, or Sidechain. + +**Transaction Sender:** + +The account that sent a transaction to a Layer 1, Layer 2, or Sidechain. + + ## 1.3 Typographical Conventions ### 1.3.1 Requirement Ids @@ -196,18 +247,113 @@ Note that requirements are uniquely numbered in ascending order within each requ Example : It should be read that [R1] is an absolute requirement of the specification whereas [D1] is a recommendation and [O1] is truly optional. - ------- # 2 Concepts and Design -TBD +To specify requirements about L2 transaction fees, this document will first: +- Define the meaning of a transaction fee and its components +- Define the roles relevant to transaction fees +- Define transaction types and their relationship to transaction fees + +Note, that all definitions can be found in the [Glossary](#12-glossary) + +Subsequently, the specification section will define requirements around fee transparency, fee estimation, final fees, and how, when and where fees are communicated to the different roles. The specification will also discuss requirements around responsibilities and accountability of roles towards one another. + +## 2.1 Definition of Transaction Fee and its Components + +This document defines Transaction Fee as the fee in a Layer 2 network or protocol token to be paid by a transaction originator comprised of the sum of a Base Fee, an Execution Fee and a Priority Fee. + +Note that this document defines as Transaction as a digitally signed message sent from an Layer 2 account that contains instructions and data that result in a Layer 2 state transition. Also note that this document defines State and State Transition as follows: +- State: The set of all accounts on a Layer 2 that are mapped to one another using a cryptographic data structure. +- State Transition: An event that deterministically changes one or more accounts in the set of all accounts that comprise the complete state of a Layer 2. + +Further note that this document defines Account as a unit that is minimally comprised of a unique account identifier, a deterministic ordering parameter, also referred to as a nonce, a balance of a Layer 1, Layer 2 or Sidechain unit of exchange, also referred to as a protocol token. Changes to an account are controlled by a unique cryptographic public and private key pair. There are typically additional account elements referring to instructions and data associated to the account that determine account changes. + +In formula form the Transaction Fee is given as: + +**Transaction Fee = Base Fee + Execution Fee + Priority Fee** + +The different components are defined as follows: +- **Base Fee:** The minimum amount of Gas or a Layer 2 gas equivalent unit of compute and storage consumption required to include a transaction on a Layer 2. +- **Execution Fee:** A fee to be paid by the transaction originator sufficient to cover both the Layer 2 and Layer 1 transaction fees. +- **Priority Fee:** To be paid by the transaction originator to a Layer 2 sequencer to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction, a slot, in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. And that MEV is defined as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. + +Note that a Transaction Fee has a Transaction Fee Price which is defined in the context of this document as a Layer 2 Gas price or a price of a Layer 2 gas equivalent unit of compute and storage consumption. + +Note that a Gas price or a price of a Layer 2 gas equivalent unit of compute and storage consumption is typically variable and changes with the level of usage of a Layer 2 network. Note, that a gas price is expressed in Giga Wei (GWEI) for EVM-compatible networks, where Wei represents the smallest unit of gas; 1 Wei = 10-18 Eth in Ethereum's native token. + +Furthermore, note that Gas in this document refers to the unit that measures the amount of computational and storage effort required to execute specific operations on an EVM-compatible network. + +## 2.2 Definition of L2 Roles relevant to Transaction Fees + +The following roles are relevant to transaction fees, their calculation and how, when and where they are presented: +- **Transaction Originator:** The account that created a transaction for a Layer 1, Layer 2, or Sidechain. +- **Transaction Sender:** The account that sent a transaction to a Layer 1, Layer 2, or Sidechain. +- **Intermediary:** An entity that is the sender of a transaction for which it is not the transaction originator. +- **Sequencer:** Collects transactions, publishes them in a batch to the Layer 1 on which the Layer 2 operates, receives transaction fees from the published transactions, pays Layer 2 fees to other Layer 2 protocol participants, and, if required, participates in a consensus algorithm with other sequencers to determine transaction ordering in a block. +- **Layer 2 Operator:** An entity responsible for the operation of a Layer 2. +- **Developer:** An individual writing computer code for software applications that operate on a Layer 1, Layer 2 or Sidechain. + +## 2.3 Definition of Transaction Types + +There are different types of transactions, and depending on the context transaction fees are paid for differently and by different roles. + +There are two types of transactions in the context of this document: +- **Direct Transaction:** A transaction where the transaction originator is also the transaction sender. +- **Meta Transaction:** A transaction where the transaction sender is not the transaction originator, and the transaction fee for the transaction originator is different if the same transaction was a direct transaction. + +In the case of a Direct Transaction the Transaction Originator pays for the Transaction Fee based on the Transaction Fee Price the Transaction Originator is maximally willing to pay. + +In the case of a Meta Transaction, the Transaction Originator may pay only a portion or no transaction fees at all. Instead, an Intermediary pays all or part of the Transaction Fee. Note that the Intermediary may be the Transaction Sender, or pay the Transaction Sender for the Transaction Fees incurred. Also note that the Transaction Originator may pre-pay Transaction Fees to the Intermediary or the Transaction Sender or both, or submit payment together with the Transaction sent to the Intermediary. + +Therefore, the communication of a Transaction Fee and its components is different for different business scenarios. This document will not break down requirements by business scenario but rather by role and if that role is responsible to pay part or all of a Transaction Fee. ------- -# 3 Layer 2 Transaction Fees Specification +# 3 Layer 2 Transaction Fee Specification + +In this section we will formulate requirements in the following areas: +- Transparency +- Visibility +- Roles and Transactions + +## 3.1 Transaction Fee Transparency Requirements + +#### **[R1]** + +A L2 Transaction Fee MUST be comprised of the Base Fee, the Execution Fee, an the Priority Fee. + +[[R1]](#r1) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable. Therefore, the requirement is testable. + +#### **[R2]** + +All components of a L2 Transaction Fee MUST NOT be less than zero. + +[[R2]](#r2) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable for specific conditions such as the sum of three elements, or each individual element being less than zero. Therefore, the requirement is testable. + +#### **[O1]** + +A L2 Transaction Fee or any of its components MAY BE zero. + +[[O1]](#o1) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable for specific conditions such as the sum of three elements, or each individual element being zero. Therefore, the requirement is testable. + +#### **[R3]** + +The setting or calculation of a Base Fee MUST be well documented and verifiable. + +[[R3]](#r3) Testability: Documentation about the setting or calculation of a Base Fee can be reviewed by individuals, and subsequently compared to computer code the sets or calculates a Base Fee. And computer code is always testable. Therefore, the requirement is testable. + + + + +## 3.2 Transaction Fee Visibility Requirements + + +## 3.3 Requirements for Roles and Transactions + + -TBD ------- # 4 Conformance From 430769bba80782766601d9a04163b5334c3a5101 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Fri, 31 Mar 2023 16:36:05 -0700 Subject: [PATCH 02/24] added more transparency requirements --- .../l2-transaction-fees-v1.0-psd01.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 0c53717..f53114e 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -322,7 +322,7 @@ In this section we will formulate requirements in the following areas: #### **[R1]** -A L2 Transaction Fee MUST be comprised of the Base Fee, the Execution Fee, an the Priority Fee. +A L2 Transaction Fee MUST be comprised as the sum of the Base Fee, the Execution Fee, and the Priority Fee. [[R1]](#r1) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable. Therefore, the requirement is testable. @@ -340,10 +340,21 @@ A L2 Transaction Fee or any of its components MAY BE zero. #### **[R3]** -The setting or calculation of a Base Fee MUST be well documented and verifiable. +The setting and/or calculation of a Base Fee MUST be well documented and verifiable. -[[R3]](#r3) Testability: Documentation about the setting or calculation of a Base Fee can be reviewed by individuals, and subsequently compared to computer code the sets or calculates a Base Fee. And computer code is always testable. Therefore, the requirement is testable. +[[R3]](#r3) Testability: Documentation about the setting and/or calculation of a Base Fee can be reviewed by individuals, and subsequently compared to computer code that sets and/or calculates a Base Fee. And computer code is always testable. Therefore, the requirement is testable. +#### **[R4]** + +The setting and/or calculation of an Execution Fee MUST be well documented and verifiable. + +[[R4]](#r4) Testability: Documentation about the setting and/or calculation of an Execution can be reviewed by individuals, and subsequently compared to computer code that sets and/or calculates an Execution Fee. And computer code is always testable. Therefore, the requirement is testable. + +#### **[R5]** + +The setting of a Priority Fee MUST be well documented and verifiable. + +[[R5]](#r5) Testability: Documentation about the setting of a Priority Fee can be reviewed by individuals, and subsequently compared to computer code that sets a Priority Fee. And computer code is always testable. Therefore, the requirement is testable. From 2efa0bc720f5fd9c911d91e27ea2caa304f59110 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Mon, 3 Apr 2023 14:38:01 -0700 Subject: [PATCH 03/24] Update l2-transaction-fees-v1.0-psd01.md - completed section 3.1 - sections 3.2 and 3.3 are still to do --- .../l2-transaction-fees-v1.0-psd01.md | 53 ++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index f53114e..cf197d9 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -223,6 +223,10 @@ A digitally signed message sent from an Layer 2 account that contains instructio The fee in a Layer 2 network or protocol token to be paid by a transaction originator comprised of the sum of a Base Fee, an Execution Fee and a Priority Fee. +**Transaction Fee Refund:** + +The difference between the Transaction Fee that the Transaction Sender has included in the Transaction when sent to the Layer 2 and the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on the Layer 2 + **Transaction Originator:** The account that created a transaction for a Layer 1, Layer 2, or Sidechain. @@ -322,7 +326,7 @@ In this section we will formulate requirements in the following areas: #### **[R1]** -A L2 Transaction Fee MUST be comprised as the sum of the Base Fee, the Execution Fee, and the Priority Fee. +A L2 Transaction Fee MUST be comprised as the sum of a Base Fee, a Execution Fee, and a Priority Fee. [[R1]](#r1) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable. Therefore, the requirement is testable. @@ -356,6 +360,53 @@ The setting of a Priority Fee MUST be well documented and verifiable. [[R5]](#r5) Testability: Documentation about the setting of a Priority Fee can be reviewed by individuals, and subsequently compared to computer code that sets a Priority Fee. And computer code is always testable. Therefore, the requirement is testable. +#### **[R6]** + +A Layer 2 implementation MUST provide a capability to estimate a Transaction Fee based on a given Transaction and the current state of the L2. + +[[R6]](#r6) Testability: Given a transaction for whom a resource consumption can be calculated based on a software emulation of the relevant L2 State Transition function which is testable, and given a Fee price based on the state of current resource consumption of the L2, and given that the testable requirements [[R1]](#r1) through [[R5]](#r5) are required to be implemented for [[R6]](#r6), the requirement [[R6]](#r6) itself is testable. + +#### **[R7]** + +A Layer 2 implementation MUST record and provide access to the Transaction Fee that the Transaction Sender has included in the Transaction when a Transaction has been sent to the Layer 2. + +[[R7]](#r7) Testability: A Layer 2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since Layer 2 transactions are recorded on a Sequencer until they are recorded and finalized on both the Layer 2 and the Layer 1, and since a Sequencer is open to a transactions sender, and since a Sequencer is part of a Layer 2 protocol, and since Layer 2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. + +#### **[R8]** + +A Layer 2 implementation MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been processed by the Layer 2. + +[[R8]](#r8) Testability: A Layer 2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since Layer 2 transactions are recorded on a Sequencer until they are recorded and finalized on both the Layer 2 and the Layer 1, and since Layer 2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. + + +#### **[R9]** + +A Layer 2 implementation MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on the Layer 2. + +Transaction finality in the context of this document is defined as the condition when a transaction can no longer be reverted on a Layer 2. Not that the finality condition will vary by Layer 2. Layer 2 finality requirements are outside of the scope of this document. + +[[R9]](#r9) Testability: A Layer 2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since Layer 2 transactions are recorded on a Sequencer until they are recorded and finalized on both the Layer 2 and the Layer 1, and since Layer 2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. + + +#### **[R10]** + +If there is a Transaction Fee Refund, a Layer 2 implementation MUST record and provide access to the Transaction Fee Refund when a Transaction has been finalized on the Layer 2. + +A Transaction Fee Refund in the context of this document is defined as the difference between the Transaction Fee that the Transaction Sender has included in the Transaction sent to the Layer 2 and the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on the Layer 2. + +[[R10]](#r10) Testability: A Layer 2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since Layer 2 transactions are recorded on a Sequencer until they are recorded and finalized on both the Layer 2 and the Layer 1, and since Layer 2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. + +#### **[R11]** + +A Layer 2 MUST provide continuous access to the Transaction Fee, the Transaction Fee components, and Transaction Fee Refund, if applicable, of all Transaction finalized on the Layer 2. + +[[R11]](#r11) Testability: Since Layer 2 protocols record all transactions and their fees, and are open to access by any 3rd party, and have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. + +#### **[R12]** + +A Layer 2 MUST provide a capability that delivers a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on. + +[[R12]](#r12) Testability: Layer 2 protocols typically provide Fee Prices to transactions senders which may or may not be dynamic such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests) with its test suite. Therefore, the requirement is testable. ## 3.2 Transaction Fee Visibility Requirements From 5e4e00261f70fcb86e01a87f3affef5bb186126a Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Tue, 4 Apr 2023 11:29:53 -0700 Subject: [PATCH 04/24] updated references and fixed link --- .../l2-transaction-fees-v1.0-psd01.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index cf197d9..8834609 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -462,7 +462,10 @@ The following documents are referenced in such a way that some or all of their c ## A.2 Non-Normative References -TBD +#### **[W3C-String-Meta]** + +Strings on the Web: Language and Direction Metadata, R. Ishida, A. Phillips, August 2022, +https://www.w3.org/TR/string-meta/ # Appendix B - Security Considerations @@ -477,6 +480,10 @@ The standard does not set any requirements for compliance to jurisdiction legisl The standard does not set any requirements for the use of specific applications/tools/libraries etc. The implementer should perform due diligence when selecting specific applications/tools/libraries. +## B.3 Internationalization and Localization Reference + +The standard encourages implementers to follow the [W3C "Strings on the Web: Language and Direction Metadata" best practices guide](#w3c-string-meta) for identifying language and base direction for strings used on the Web wherever appropriate. + @@ -630,12 +659,14 @@ Andreas Freund \ ------- # Appendix D - Revision History +###### L2TFSPECAPD Revisions made since the initial stage of this numbered Version of this document have been tracked on [Github](https://github.com/eea-oasis/L2/tree/main/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md). ------- # Appendix E - Notices +###### L2TFSPECAPBE Copyright © OASIS Open 2022. All Rights Reserved. From ff49b748adb67d1a7cc7386ef1c318320ca9d25b Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Thu, 20 Apr 2023 10:51:07 -0700 Subject: [PATCH 15/24] Fixing typos and minor wording changes after 4/19/23 WG review --- .../l2-transaction-fees-v1.0-psd01.md | 42 +++++++++---------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 2886ee7..8bb4887 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -147,7 +147,7 @@ An open, distributed ledger that can record transactions between two parties eff **Bridge:** -The means for the transfer of information and digital assets between between Layer 2s, Layer 1s, and Sidechains. +The means for the transfer of information and digital assets between Layer 2s, Layer 1s, and Sidechains. **Developer:** @@ -155,7 +155,7 @@ An individual writing computer code for software applications that operate on a **Direct Transaction:** -A transaction where the Transaction Originator is also the transaction sender. +A transaction where the Transaction Originator is also the Transaction Sender. **Execution Fee:** @@ -184,15 +184,15 @@ A base network, such as Bitcoin, or Ethereum, and its underlying infrastructure **Layer 2:** -A secondary framework or protocol that is built on top of an existing Layer 1 system in such a way that it inherits the security properties of the Layer 1 system while allowing for a higher transaction throughput that the Layer 1 system. +A secondary framework or protocol that is built on top of an existing Layer 1 system in such a way that it inherits the security properties of the Layer 1 system while allowing for a higher transaction throughput than the Layer 1 system. **Layer 2 Operator:** -An entity responsible for the development and/or operation of a Layer 2 network or single Layer 2 node. +An entity responsible for the development and/or operation of a Layer 2 network or single Layer 2 network node, except for entities that only provide access to a Layer 2. **Layer 2 Block:** -A Layer 2 data object typically comprised of a set of Layer 2 Transactions or their compressed representations and/or a cryptographic representation of the Layer 2 State due to the set of Layer 2 Transactions and cryptographically linked to the previous Layer 2 Block where the cryptographic link is derived using only the previous Layer 2 Block's data, and where such a Layer 2 data object is stored on a Layer 1. +A Layer 2 data object stored on a Layer 1 and typically comprised of a set of Layer 2 Transactions or their compressed representations and/or a cryptographic representation of the Layer 2 State after applying the set of Layer 2 Transactions to the Layer 2 state. This Layer 2 data object is also cryptographically linked to the previous Layer 2 Block where the cryptographic link is derived using only the previous Layer 2 Block's data. **Layer 2 Operating Condition:** @@ -214,7 +214,7 @@ Note that the exact position of a transaction in a new block may be determined b **Sequencer:** -Collects transactions, publishes them in a batch to the Layer 1 on which the Layer 2 operates, receives transaction fees from the published transactions, pays Layer 2 fees to other Layer 2 protocol participants, and, if required, participates in a consensus algorithm with other sequencers to determine transaction ordering in a block. +Collects transactions, publishes them in a batch to the Layer 1 on which the Layer 2 operates, receives transaction fees from the published transactions, pays Layer 2 fees to other Layer 2 protocol participants, and, if required, participates in a consensus algorithm with other sequencers to determine transaction ordering in a Layer 2 block. **Sidechain:** @@ -328,8 +328,8 @@ There are different types of transactions, and depending on the context transact There are two types of transactions in the context of this document: -* **Direct Transaction:** A transaction where the Transaction Originator is also the transaction sender. -* **Meta Transaction:** A transaction where the transaction sender is not the Transaction Originator, and the transaction fee for the Transaction Originator is different if the same transaction was a direct transaction. +* **Direct Transaction:** A transaction where the Transaction Originator is also the Transaction Sender. +* **Meta Transaction:** A transaction where the Transaction Sender is not the Transaction Originator, and the transaction fee for the Transaction Originator is different if the same transaction was a direct transaction. In the case of a Direct Transaction the Transaction Originator pays for the Transaction Fee based on the Transaction Fee Price the Transaction Originator is maximally willing to pay. @@ -353,7 +353,7 @@ In this section we will formulate requirements in the following areas: #### **[R1]** -A L2 Transaction Fee MUST be comprised as the sum of a Base Fee, a Execution Fee, and a Priority Fee. +An L2 Transaction Fee MUST be comprised as the sum of a Base Fee, a Execution Fee, and a Priority Fee. [[R1]](#r1) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable. Therefore, the requirement is testable. @@ -365,7 +365,7 @@ All components of a L2 Transaction Fee MUST NOT be less than zero. #### **[O1]** -A L2 Transaction Fee or any of its components MAY BE zero. +An L2 Transaction Fee or any of its components MAY BE zero. [[O1]](#o1) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable for specific conditions such as the sum of three elements, or each individual element being zero. Therefore, the requirement is testable. @@ -397,24 +397,24 @@ Note that L2 Operating Conditions refer to a combination of the current volume o #### **[R7]** -A L2 MUST record and provide access to the Transaction Fee that the Transaction Sender has included in the Transaction when a Transaction has been sent to the L2. +An L2 MUST record and provide access to the Transaction Fee that the Transaction Sender has included in the Transaction when a Transaction has been sent to the L2. -[[R7]](#r7) Testability: A L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since a Sequencer is open to a transaction's sender, and since a Sequencer is part of a L2 protocol, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R7]](#r7) Testability: An L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since a Sequencer is open to a transaction's sender, and since a Sequencer is part of a L2 protocol, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. #### **[R8]** -A L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been processed by the L2. +An L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been processed by the L2. -[[R8]](#r8) Testability: A L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R8]](#r8) Testability: An L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. #### **[R9]** -A L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on theL2. +An L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on theL2. -Transaction finality in the context of this document is defined as the condition when a transaction can no longer be reverted on a L2. Not that the finality condition will vary by L2. L2 finality requirements are outside of the scope of this document. +Transaction finality in the context of this document is defined as the condition when a transaction can no longer be reverted on a L2. Note that the finality condition will vary by L2, and that L2 finality requirements are outside of the scope of this document. -[[R9]](#r9) Testability: A L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R9]](#r9) Testability: An L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. #### **[R10]** @@ -423,19 +423,19 @@ If there is a Transaction Fee Refund, a L2 implementation MUST record and provid A Transaction Fee Refund in the context of this document is defined as the difference between the Transaction Fee that the Transaction Sender has included in the Transaction sent to the L2 and the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on the L2. -[[R10]](#r10) Testability: A L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R10]](#r10) Testability: An L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. #### **[R11]** -A L2 MUST provide continuous access to the Transaction Fee, the Transaction Fee components, and Transaction Fee Refund, if applicable, of all Transaction finalized on the L2. +An L2 MUST provide continuous access to the Transaction Fee, the Transaction Fee components, and Transaction Fee Refund, if applicable, of all Transaction finalized on the L2. [[R11]](#r11) Testability: Since L2 protocols record all transactions and their fees, and are open to access by any 3rd party, and have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. #### **[R12]** -A L2 MUST provide a capability that delivers a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on. +An L2 MUST provide a capability that delivers a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on. [[R12]](#r12) Testability: L2 protocols typically provide Fee Prices to transactions senders which may or may not be dynamic such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests) with its test suite. Therefore, the requirement is testable. @@ -492,7 +492,7 @@ If there is a Transaction Fee Refund, an Intermediary and a Developer MUST be ab #### **[R20]** -A L2 MUST provide an Intermediary with a capability to display the Transaction Fee and its components of a L2 Meta Transaction after it has been processed on the L2 to 3rd parties. +An L2 MUST provide an Intermediary with a capability to display the Transaction Fee and its components of a L2 Meta Transaction after it has been processed on the L2 to 3rd parties. [[R20]](#r20) Testability: Given that [[R17]](#r17) that provides the necessary capability for [[R20]](#r20) to be realized is testable, and given that the ability to display a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. From 875b023349e371a0767e3d240c409babc437a518 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Tue, 25 Apr 2023 18:48:53 -0700 Subject: [PATCH 16/24] Updated Testability Statements based on guidance from the PGB --- .../l2-transaction-fees-v1.0-psd01.md | 563 +++++++++++++++++- 1 file changed, 535 insertions(+), 28 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 8bb4887..bf28fdd 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -355,37 +355,106 @@ In this section we will formulate requirements in the following areas: An L2 Transaction Fee MUST be comprised as the sum of a Base Fee, a Execution Fee, and a Priority Fee. -[[R1]](#r1) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable. Therefore, the requirement is testable. +[[R1]](#r1) Testability: Mathematical equality equations can be tested as the sum of the equations elements equaling a desired output is a passing test, and the sum of the equations element not equaling the desired output a failing test.. #### **[R2]** All components of a L2 Transaction Fee MUST NOT be less than zero. -[[R2]](#r2) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable for specific conditions such as the sum of three elements, or each individual element being less than zero. Therefore, the requirement is testable. +[[R2]](#r2) Testability: Mathematical equality or inequality equations can be expressed as testable conditions. A passing test condition is that each individual element of a transaction fee is equal to or larger than zero. A failing test condition is that one or more transaction fee elements is less than zero. #### **[O1]** An L2 Transaction Fee or any of its components MAY BE zero. -[[O1]](#o1) Testability: Mathematical equality equations can be translated into computer code, and any computer code is testable for specific conditions such as the sum of three elements, or each individual element being zero. Therefore, the requirement is testable. +[[O1]](#o1) Testability: Mathematical equality equations can be expressed as testable conditions. A test for [[R2]](#r2) also tests this optional requirement since zero values are allowed in tests for [[R2]](#r2). #### **[R3]** The setting and/or calculation of a Base Fee MUST be well documented and verifiable. -[[R3]](#r3) Testability: Documentation about the setting and/or calculation of a Base Fee can be reviewed by individuals, and subsequently compared to computer code that sets and/or calculates a Base Fee. And computer code is always testable. Therefore, the requirement is testable. +[[R3]](#r3) Testability: + +Preconditions: + +* The L2 must have a defined Base Fee. +* There must be documentation available for the current Base Fee. +* An test L2 is up and running. + +Test Steps: + +1. Verify that there is a documented process for setting and/or calculating the Base Fee. +2. Verify that the documentation includes the value, specific formula or calculation used to determine the Base Fee. +3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the calculation. +4. Verify that the documentation is up-to-date and accurate, and that it matches the current Base Fee being charged. +5. Attempt to independently calculate the Base Fee using the information provided in the documentation. +6. Verify that the calculated Base Fee matches the currently charged Base Fee. + +Test Passing Criteria: + +* The documented process for setting and/or calculating the Base Fee must be clear and unambiguous. +* The documentation must include the specific value, formula or calculation used to determine the Base Fee, as well as any relevant assumptions or dependencies. +* The documentation must be up-to-date and accurate. +* The calculated Base Fee must match the currently charged Base Fee. #### **[R4]** The setting and/or calculation of an Execution Fee MUST be well documented and verifiable. -[[R4]](#r4) Testability: Documentation about the setting and/or calculation of an Execution can be reviewed by individuals, and subsequently compared to computer code that sets and/or calculates an Execution Fee. And computer code is always testable. Therefore, the requirement is testable. +[[R4]](#r4) Testability: + +Preconditions: + +* The L2 must have a defined Execution Fee. +* There must be documentation available for the current Execution Fee. +* An test L2 is up and running. + +Test Steps: + +1. Verify that there is a documented process for setting and/or calculating the Execution Fee. +2. Verify that the documentation includes the value, specific formula or calculation used to determine the Execution Fee. +3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the calculation. +4. Verify that the documentation is up-to-date and accurate, and that it matches the current Execution Fee being charged. +5. Attempt to independently calculate the Execution Fee using the information provided in the documentation. +6. Verify that the calculated Execution Fee matches the currently charged Execution Fee. + +Test Passing Criteria: + +* The documented process for setting and/or calculating the Execution Fee must be clear and unambiguous. +* The documentation must include the specific value, formula or calculation used to determine the Execution Fee, as well as any relevant assumptions or dependencies. +* The documentation must be up-to-date and accurate. +* The calculated Execution Fee must match the currently charged Execution Fee. #### **[R5]** The setting of a Priority Fee MUST be well documented and verifiable. -[[R5]](#r5) Testability: Documentation about the setting of a Priority Fee can be reviewed by individuals, and subsequently compared to computer code that sets a Priority Fee. And computer code is always testable. Therefore, the requirement is testable. +[[R5]](#r5) Testability: + +Preconditions: + +* The L2 must have a defined Base Fee and Execution Fee. +* There must be documentation available for the current Priority Fee. +* An L2 test system must be up and running. +* An L2 user is configured. + +Test Steps: + +1. Verify that there is a documented process for setting the Priority Fee by the L2 user. +2. Verify that the documentation includes the specific factors or criteria used to determine and set the Priority Fee. +3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the determination and setting of the Priority Fee. +4. Verify that the documentation is up-to-date and accurate. +5. An L2 test user sets a priority fee for a transaction. +6. Verify that the set Priority Fee is correctly added to the Base Fee and Execution Fee to calculate the Transaction Fee. +7. Verify that the calculated Transaction Fee matches the currently charged Transaction Fee for the set Priority Fee. + +Test Passing Criteria: + +* The documented process for setting the Priority Fee by the L2 user must be clear and unambiguous. +* The documentation must include the specific factors or criteria used to determine the Priority Fee, as well as any relevant assumptions or dependencies. +* The documentation must be up-to-date and accurate. +* The set Priority Fee must be correctly added to the Base Fee and Execution Fee to calculate the Transaction Fee. +* The calculated Transaction Fee must match the currently charged Transaction Fee for the set Priority Fee. #### **[R6]** @@ -393,20 +462,89 @@ An L2 MUST provide a capability to estimate a Transaction Fee based on a given T Note that L2 Operating Conditions refer to a combination of the current volume of L2 transactions waiting to be processed on an L2 and all the transactions currently being processed on an L2. -[[R6]](#r6) Testability: Given a transaction for whom a resource consumption can be calculated based on a software emulation of the relevant L2 State Transition function which is testable, and given a Fee price based on the state of current resource consumption of the L2, and given that the testable requirements [[R1]](#r1) through [[R5]](#r5) are required to be implemented for [[R6]](#r6), the requirement [[R6]](#r6) itself is testable. +[[R6]](#r6) Testability: + +Preconditions: + +* An L2 test system is up and running. +* The L2 must have a defined process for estimating a Transaction Fee based on varying Operating Conditions. +* Operating Conditions must be measurable for the L2, including: + * The current number of transactions waiting to be processed on the L2. + * The current number of transactions currently being processed on the L2. + * The current available L2 resources (e.g. CPU, memory, network bandwidth). +* The L2 must be configured to adjust the Transaction Fee estimation based on varying Operating Conditions. +* Different sets of test Transactions with varying levels of complexity and number of transactions must be available. + +Test Steps: + +1. Verify that the L2 can provide a Transaction Fee estimate. +2. Submit a simple test Transaction to the L2 after the first set of test transactions has been submitted to the L2. +3. Record the estimated Transaction Fee provided by the L2. +4. Verify that the estimated Transaction Fee is within an acceptable range of the actual Transaction Fee charged after the L2 transaction has been finalized on the L1. +5. Increase the number of transactions waiting to be processed on the L2 by submitting another test data set with more transactions and submit a complex test Transaction. +6. Record the estimated Transaction Fee provided by the L2. +7. Verify that the estimated Transaction Fee has increased in response to the increase in the number of transactions waiting to be processed and currently being processed. +8 Verify that the estimated Transaction Fee has increased in response to the increase in the number of transactions currently being processed and waiting to be processed. +9. Repeat the test with different test Transactions of varying complexity to ensure that the Transaction Fee estimation process is accurately responsive to changes in Operating Conditions and transaction complexity. + +Test Passing Criteria: + +* The L2 must provide a Transaction Fee estimate in response to a test transaction. +* The estimation process must take into account the current Operating Conditions of the L2. +* The estimated Transaction Fee must be within an acceptable range of the actual Transaction Fee charged. +* The Transaction Fee estimation process must be accurately responsive to changes in Operating Conditions, with higher Operating Conditions leading to higher estimated Transaction Fees. #### **[R7]** An L2 MUST record and provide access to the Transaction Fee that the Transaction Sender has included in the Transaction when a Transaction has been sent to the L2. -[[R7]](#r7) Testability: An L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since a Sequencer is open to a transaction's sender, and since a Sequencer is part of a L2 protocol, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R7]](#r7) Testability: + +Preconditions: + +* An L2 test system is up and running. +* The L2 must have a defined process for recording and storing the Transaction Fee included by the Transaction Sender. +* A test Transaction must be available with a known Transaction Fee included by the Transaction Sender. + +Test Steps: + +1. Submit the test Transaction to the L2. +2. Verify that the L2 has recorded the Transaction Fee included by the Transaction Sender. +3. Retrieve the recorded Transaction Fee from the L2. +4. Compare the retrieved Transaction Fee with the known Transaction Fee included by the Transaction Sender. +5. Verify that the recorded Transaction Fee matches the known Transaction Fee included by the Transaction Sender. + +Test Passing Criteria: + +* The L2 must have recorded the Transaction Fee included by the Transaction Sender. +* The recorded Transaction Fee must be accessible by the user. +* The recorded Transaction Fee must match the known Transaction Fee included by the Transaction Sender. #### **[R8]** An L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been processed by the L2. -[[R8]](#r8) Testability: An L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R8]](#r8) Testability: + +Preconditions: + +* An L2 test system is up and running. +* The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender. +* A test Transaction must be available with a known Transaction Fee charged to the Transaction Sender. + +Test Steps: + +1. Submit the test Transaction to the L2. +2. Wait for the Transaction to be processed by the L2, and the L2 return a message to the Transaction Sender with the processing result of the test transaction including the transaction fee. +3. Retrieve the Transaction Fee charged to the Transaction Sender from the L2 message. +4. Compare the retrieved Transaction Fee with the known Transaction Fee submitted by the Transaction Sender. +5. Verify that the recorded Transaction Fee matches or is less than the known Transaction Fee submitted by the Transaction Sender. + +Test Passing Criteria: +* The L2 must have calculated and recorded the Transaction Fee charged to the Transaction Sender. +* The recorded Transaction Fee must be accessible by the user. +* The recorded Transaction Fee must match or is less than the Transaction Fee submitted by the Transaction Sender. #### **[R9]** @@ -414,7 +552,27 @@ An L2 MUST record and provide access to the Transaction Fee that has been charge Transaction finality in the context of this document is defined as the condition when a transaction can no longer be reverted on a L2. Note that the finality condition will vary by L2, and that L2 finality requirements are outside of the scope of this document. -[[R9]](#r9) Testability: An L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R9]](#r9) Testability: + +Preconditions: + +* The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender. +* An L2 test system is up and running. +* A test Transaction must be available with a known, estimated Transaction Fee to be charged to the Transaction Sender. +* The test environment must have finalized the test Transaction on the L2 according to the L2 finality conditions. + +Test Steps: + +1. Retrieve the Transaction ID for the test Transaction. +2. Retrieve the Transaction Fee charged to the Transaction Sender from the L2. +3. Compare the retrieved Transaction Fee with the known, estimated Transaction Fee to be charged to the Transaction Sender. +4. Verify that the recorded Transaction Fee matches or is less than the known Transaction Fee to be charged to the Transaction Sender. + +Test Passing Criteria: + +* The L2 must have calculated and recorded the Transaction Fee charged to the Transaction Sender. +* The recorded and finalized Transaction Fee must be accessible by the user. +* The recorded Transaction Fee must match or be less than the known, estimated Transaction Fee to be charged to the Transaction Sender. #### **[R10]** @@ -423,21 +581,79 @@ If there is a Transaction Fee Refund, a L2 implementation MUST record and provid A Transaction Fee Refund in the context of this document is defined as the difference between the Transaction Fee that the Transaction Sender has included in the Transaction sent to the L2 and the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on the L2. -[[R10]](#r10) Testability: An L2 transaction always contains a Transaction Fee as this is necessary to pay for the resource use of a submitted Transaction. Since L2 transactions are recorded on a Sequencer until they are recorded and finalized on both the L2 and the Layer 1, and since L2 protocols have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R10]](#r10) Testability: + +Preconditions: + +* The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender and the Transaction Fee Refund. +* An L2 test system is up and running. +* A test Transaction must be available with a known Transaction Fee estimate to be charged to the Transaction Sender. +* The test environment must have finalized the test Transaction on the L2 based on its finality conditions. + +Test Steps: +1. Retrieve the Transaction ID for the finalized test Transaction. +2. Retrieve the Transaction Fee charged to the Transaction Sender from the L2. +3. Calculate the Transaction Fee Refund as the difference between the Transaction Fee that the Transaction Sender included in the Transaction and the Transaction Fee charged to the Transaction Sender when the Transaction was finalized. +4. Compare the balance of the users' account protocol token balance minus the estimate Transaction Fee with the balance of the users' account protocol token balance minus the Transaction Fee of the finalized test transaction. +5. Verify that the Transaction Fee Refund from step 3. equals the comparison value in step 4. + +Test Passing Criteria: + +* The L2 must have calculated the Transaction Fee Refund. +* The Transaction Fee Refund must be accessible by the user. +* The Transaction Fee Refund must match the comparison result of step 4. #### **[R11]** An L2 MUST provide continuous access to the Transaction Fee, the Transaction Fee components, and Transaction Fee Refund, if applicable, of all Transaction finalized on the L2. -[[R11]](#r11) Testability: Since L2 protocols record all transactions and their fees, and are open to access by any 3rd party, and have test suits to validate, write and read transactions and their fees such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests), the requirement is testable. +[[R11]](#r11) Testability: + +Preconditions: + +* A test L2 is up and running. +* The L2 must have a defined process for submitting and finalizing Transactions. +* There is a set of test L2 transactions. + +Test Steps: + +1. Submit a set of Transactions to the L2. +2. Wait for the L2 to finalize the Transactions using transaction confirmation notifications as finalization confirmations. +3. Query the L2 for a Transaction ID from the set of finalized test transactions. +4. For a given Transaction ID, retrieve the Transaction ID, Transaction Fee, Transaction Fee components (Base Fee, Execution Fee, and Priority Fee), and Transaction Fee Refund (if applicable). +5. Verify that the retrieved Transaction Fee, Transaction Fee components, and Transaction Fee Refund (if applicable) match the values recorded in the transaction confirmations. +6. Repeat steps 3. through 5. for each Transaction ID in the set of test transactions at random time intervals during a 24 hour period for the entire test transaction set. + +Test Passing Criteria: + +* Steps 3. through 5. are successfully completed for every transaction in the test transaction set, otherwise the test fails. #### **[R12]** An L2 MUST provide a capability that delivers a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on. -[[R12]](#r12) Testability: L2 protocols typically provide Fee Prices to transactions senders which may or may not be dynamic such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests) with its test suite. Therefore, the requirement is testable. +[[R12]](#r12) Testability: + +Preconditions: + +* A test L2 is running and operational +* The L2 has a current Fee Price available +* A Transaction Sender or Transaction Originator is ready to send a transaction on the L2 + +Test steps: + +1. Retrieve the current Fee Price from the L2. +2. Calculate a Transaction Fee based on the Fee Price obtained in step 1. +3. Send a transaction to the L2 with the calculated Transaction Fee. +4. Retrieve the Transaction Fee recorded by the L2 for the transaction sent in step 3. +5. Verify that the Transaction Fee recorded by the L2 matches the calculated Transaction Fee in step 2. + +Test Passing criteria: + +* The current Fee Price is successfully retrieved from the L2 in step 1. +* The calculated Transaction Fee matches the Transaction Fee recorded by the L2 in step 5. ## 3.2 Layer 2 Transaction Fee Visibility Requirements @@ -448,67 +664,272 @@ In this section, this document discusses the visibility requirements for differe A Transaction Originator, a Transaction Sender and a Developer MUST be able to view an estimated Transaction Fee and its components before a L2 Transaction is submitted. -[[R13]](#r13) Testability: Given that [[R6]](#r6) that provides the necessary capability for [[R13]](#r13) to be realized is testable, and given that the ability to view a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. +[[R13]](#r13) Testability: + +Preconditions: + +* An L2 test instance is set up and running. +* A Transaction Originator, a Transaction Sender, and a Developer have access to the L2 and can interact with it. +* The L2 provides a capability to estimate Transaction Fees based on current operating conditions and other relevant factors. + +Test Steps: + +1. The Transaction Originator, the Transaction Sender, and the Developer navigate to the L2 interface and initiate the process of creating a new transaction. +2. The L2 interface displays the estimated Transaction Fee and its components (Base Fee, Execution Fee, and Priority Fee) to the Transaction Originator, the Transaction Sender, and the Developer. +3. The Transaction Originator, the Transaction Sender, and the Developer proceed to submit the Transaction to the L2. + +Test Passing Criteria: + +* The L2 interface displays the estimated Transaction Fee and its components accurately. +* The Transaction Originator, the Transaction Sender, and the Developer are able to review and verify the estimated Transaction Fee and its components before submitting the Transaction. #### **[R14]** A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after a L2 Direct Transaction has been processed on the L2. -[[R14]](#r14) Testability: Given that [[R8]](#r8) that provides the necessary capability for [[R14]](#r14) to be realized is testable, and given that the ability to view a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. +[[R14]](#r14) Testability: + +Preconditions: + +* An L2 test instance is operational and available for use. +* The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. +* At least one Direct Transaction has been submitted and processed on the L2. +* The L2 has a defined method to notify L2 users that a L2 transaction has been processed. + +Test Steps: + +1.Transaction Sender or Developer submit a Direct Transaction to the L2. +2. The L2 processes the Direct Transaction and charges a Transaction Fee. +3. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been processed on the L2 using the Transaction ID from the transaction processing confirmation notification from the L2. +4. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +5. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +6. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. + +Test Passing Criteria: The test passes if, + +* The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been processed. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. #### **[R15]** An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after a L2 Meta Transaction has been processed on the L2. -[[R15]](#r15) Testability: Given that [[R8]](#r8) that provides the necessary capability for [[R15]](#r15) to be realized is testable, and given that the ability to view a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. +[[R15]](#r15) Testability: + +Preconditions: + +* An L2 instance is operational and accepting transactions. +* The Intermediary and Developer have access to the L2. +* The Intermediary and Developer have a Meta Transaction ready to submit to the L2. +* The L2 has a defined method to notify L2 users that a L2 transaction has been processed. + +Test Steps: + +1. The Intermediary and Developer submit a Meta Transaction to the L2. +2. The L2 processes the Meta Transaction and charges a Transaction Fee. +3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction processing confirmation notification from the L2. +4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. + +Test Passing Criteria: The test passes if, + +* The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been processed. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. #### **[R16]** A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after a L2 Direct Transaction has been finalized on the L2. -[[R16]](#r16) Testability: Given that [[R9]](#r9) that provides the necessary capability for [[R16]](#r16) to be realized is testable, and given that the ability to view a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. +[[R16]](#r16) Testability: + +Preconditions: + +* An L2 test instance is operational and available for use. +* The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. +* At least one Direct Transaction has been submitted, processed and finalized on the L2. +* The L2 has a defined method to notify L2 users that a L2 transaction has been finalized. + +Test Steps: +1. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been finalized on the L2 using the Transaction ID from the transaction finalization confirmation notification from the L2. +2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +3. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +4. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. + +Test Passing Criteria: The test passes if, + +* The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been finalized. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account, if applicable. #### **[R17]** An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after a L2 Meta Transaction has been finalized on the L2. -[[R17]](#r17) Testability: Given that [[R9]](#r9) that provides the necessary capability for [[R17]](#r17) to be realized is testable, and given that the ability to view a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. +[[R17]](#r17) Testability: + +Preconditions: + +* An L2 instance is operational and accepting transactions. +* The Intermediary and Developer have access to the L2. +* The Intermediary and Developer have a Meta Transaction ready to submit to the L2. +* The L2 has a defined method to notify L2 users that a L2 transaction has been finalized. + +Test Steps: + +1. The Intermediary and Developer submit a Meta Transaction to the L2. +2. The L2 processes, and finalizes the Meta Transaction and charges a Transaction Fee. +3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction finalization confirmation notification from the L2. +4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. + +Test Passing Criteria: The test passes if, + +* The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been finalized. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. #### **[R18]** If there is a Transaction Fee Refund, a Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee Refund after a L2 Direct Transaction has been finalized on the L2. -[[R18]](#r18) Testability: Given that [[R10]](#r10) that provides the necessary capability for [[R18]](#r18) to be realized is testable, and given that the ability to view a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. +[[R18]](#r18) Testability: + +Preconditions: + +* An L2 test instance is operational and available for use. +* The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. +* At least one Direct Transaction has been submitted, processed and finalized on the L2. +* The L2 has a defined method to notify L2 users that a L2 transaction has been finalized. + +Test Steps: + +1. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been finalized on the L2 using the Transaction ID from the transaction finalization confirmation notification from the L2. +2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +3. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 is less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +4. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account. + +Test Passing Criteria: The test passes if, + +* The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been finalized. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account, if applicable. #### **[R19]** If there is a Transaction Fee Refund, an Intermediary and a Developer MUST be able to view a Transaction Fee Refund after a L2 Meta Transaction has been finalized on the L2. -[[R19]](#r19) Testability: Given that [[R10]](#r10) that provides the necessary capability for [[R19]](#r19) to be realized is testable, and given that the ability to view a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. +[[R19]](#r19) Testability: + +Preconditions: + +* An L2 instance is operational and accepting transactions. +* The Intermediary and Developer have access to the L2. +* The Intermediary and Developer have a Meta Transaction ready to submit to the L2. +* The L2 has a defined method to notify L2 users that a L2 transaction has been finalized. + +Test Steps: + +1. The Intermediary and Developer submit a Meta Transaction to the L2. +2. The L2 processes, and finalizes the Meta Transaction and charges a Transaction Fee. +3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction finalization confirmation notification from the L2. +4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account. +Test Passing Criteria: The test passes if, + +* The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been finalized. +* The Transaction Fee and its components displayed on the L2 are less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +* The Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account. #### **[R20]** An L2 MUST provide an Intermediary with a capability to display the Transaction Fee and its components of a L2 Meta Transaction after it has been processed on the L2 to 3rd parties. -[[R20]](#r20) Testability: Given that [[R17]](#r17) that provides the necessary capability for [[R20]](#r20) to be realized is testable, and given that the ability to display a data object such as a Transaction Fee and its components can be realized in computer code, and since computer code is testable, the requirement is testable. +[[R20]](#r20) Testability: + +Preconditions: + +* A L2 test instance is operational and accessible. +* There is at least one Intermediary operating on the L2. +* At least one L2 Meta Transaction has been submitted and processed on the L2. +* The Intermediary can access the Transaction with its Transaction Fee and its Fee components. +* The L2 is accessible by any 3rd party. + +Test Steps: +1. The Intermediary logs into their account on the L2. +2. The Intermediary selects the L2 Meta Transaction they wish to view the Transaction Fee and its components for using the Transaction ID from the transaction processing confirmation notification from the L2. +3. The L2 displays the Transaction Fee and its components of the selected L2 Meta Transaction to the Intermediary. +4. The Intermediary verifies that the displayed Transaction Fee and its components match or are less than process the Transaction Fee and its components. +5. The Intermediary attempts to display the Transaction Fee and its components of the selected L2 Meta Transaction to a 3rd party. +6. The 3rd party verifies that it can view displayed Transaction Fee and its components match the Transaction Fee and its components for the Transaction ID of the Meta Transaction when accessed directly on the L2 using the Transaction ID. + +Test Passing Criteria: + +* The Intermediary is able to view the Transaction Fee and its components of the selected L2 Meta Transaction. +* The displayed Transaction Fee and its components are accurate and match the actual Transaction Fee and its components of the selected L2 Meta Transaction. +* The Intermediary is able to display the Transaction Fee and its components of the selected L2 Meta Transaction to a 3rd party. +* The displayed Transaction Fee and its components match the actual Transaction Fee and its components of the selected L2 Meta Transaction as verified by the 3rd party. #### **[R21]** -If there is a Transaction Fee Refund, a L2 MUST provide an Intermediary with a capability to display the Transaction Fee Refund of a L2 Meta Transaction to its Transaction Originator after it has been finalized on the L2 to 3rd parties. +If there is a Transaction Fee Refund, a L2 MUST provide an Intermediary with a capability to display the Transaction Fee Refund of a L2 Meta Transaction to its Transaction Originator after it has been finalized on the L2. + +[[R21]](#r21) Testability: + +Preconditions: -[[R21]](#r21) Testability: Given that [[R18]](#r18) that provides the necessary capability for [[R21]](#r21) to be realized is testable, and given that the ability to display a data object such as a Fee Price can be realized in computer code, and since computer code is testable, the requirement is testable. +* An L2 test instance is deployed and running. +* An Intermediary is operating on the L2 and has the necessary permissions to view Transaction Fee Refunds. +* A set of L2 Meta Transactions has been submitted and processed on the L2, resulting in at least one Transaction Fee Refund. +Test steps: + +1. The Intermediary sends a request to the L2 to display the Transaction Fee Refund of a specific L2 Meta Transaction using the Transaction ID from the transaction finalization confirmation notification from the L2.. +2. The L2 receives the request and verifies that the Intermediary has the necessary permissions to view Transaction Fee Refunds. +3. The L2 retrieves the Transaction Fee Refund information for the requested L2 Meta Transaction. +4. The L2 sends the Transaction Fee Refund information to the Intermediary. +5. The Intermediary receives the Transaction Fee Refund information. +6. The Intermediary verifies that the Transaction Fee Refund information matches the expected values based on the difference in the L2 Meta Transaction Transaction Fee between the submitted and finalized L2 Meta Transaction. +7. The Intermediary displays the Transaction Fee Refund information to the Transaction Originator. +8. The Transaction Originator verifies that it can view displayed Transaction Fee and its components match the Transaction Fee and its components for the Transaction ID of the Meta Transaction when accessed directly on the L2 using the Transaction ID. + +Test Passing criteria: + +* The Intermediary is able to successfully retrieve and display the Transaction Fee Refund information for the requested L2 Meta Transaction. +* The displayed Transaction Fee Refund information matches the expected values based on the L2 Meta Transaction. #### **[R22]** A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on. -[R22]](#r22) Testability: Given that [[R12]](#r12) that provides the necessary capability for [[R22]](#r22) to be realized is testable, and given that the ability to view a data object such as a Fee Price in computer code, and since computer code is testable, the requirement is testable. +[R22]](#r22) Testability: + +Preconditions: + +* An L2 test instance is live and operational. +* The Transaction Originator, Transaction Sender, and Developer have access to the L2. +* The Fee Price calculation is based on the current Operating Condition of the L2. +* A Fee Price Emulator that can accurately calculate a Fee Price based on current Operating Conditions on the L2. + +Test steps: + +1. The Transaction Originator, Transaction Sender, or Developer access the current Fee Price from the L2. +2. The L2 responds to the request by providing the current Fee Price. +3. The Transaction Originator, Transaction Sender, or Developer verifies that the Fee Price provided by the L2 network matches the Fee Price estimate using the Fee Price Emulator. + +Test Passing criteria: + +* The current Fee Price is successfully retrieved from the L2. +* The Fee Price provided by the L2 matches the Fee Price estimate using the Fee Price Emulator. ## 3.3 Transaction Fee Requirements for Layer 2 Transactions @@ -519,14 +940,52 @@ In this section, the documents details Transaction Fee requirements for a L2 Tra Every L2 Transaction MUST contain a Transaction Fee and its components. -[[R23]](#r23) Testability: L2 protocols include a Transaction Fee in a L2 Transaction such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests) with its test suite. Therefore, the requirement is testable. +[[R23]](#r23) Testability: + +Preconditions: + +* An L2 test instance is set up and functional. +* There is a user account on the L2 with the necessary permissions to submit a transaction. +* There is a sufficient balance of funds available in the user's account to cover the transaction fee. + +Test Steps: + +1. Log in to the user account on the L2. +2. Create a new L2 transaction. +3. Verify that the transaction contains a transaction fee and its components. +4. Submit the transaction. +5. Wait for the transaction to be processed and finalized on the L2. +6. Retrieve the details of the processed and finalized transaction using using the Transaction ID from the transaction finalization confirmation notification from the L2. +7. Verify that the transaction fee and its components are still present and accurate. + +Test Passing Criteria: + +* The L2 transaction contains a transaction fee and its components. +* The transaction fee and its components remain present and accurate after the transaction is processed and finalized on the L2. #### **[R24]** Every L2 Block MUST contain one or more L2 account addresses to which the accumulated Transaction Fees in said L2 Block are transferred either whole or in proportion based on the specification of the L2 protocol. -[[R24]](#r24) Testability: L2 protocols include one or more L2 addresses to which Transaction Fees in a L2 Block are transferred such as [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests) with its test suite. Therefore, the requirement is testable. +[[R24]](#r24) Testability: + +Preconditions: + +* The L2 protocol and its specifications have been implemented and tested. +* An L2 test instance is set up and functional. +* A set of L2 transactions have been created and finalized on the L2. +Test steps: + +1. Verify that every L2 block has one or more L2 account +addresses specified to receive the accumulated Transaction Fees. +2. Verify that the accumulated Transaction Fees from each L2 transaction in the block have been transferred to the specified L2 account address(es). +3. Verify that the transfer of the accumulated Transaction Fees is done either whole or in proportion to the account +addresses specified to receive the accumulated Transaction Fees in the L2 Block. + +Test Passing criteria: + +* Step 1, 2, and 3 must pass for all L2 blocks that have been finalized on the L2 that contain the test L2 transactions. #### **[R25]** @@ -534,22 +993,69 @@ If one or more L2 Transactions are reverted before they are finalized on the L2' Note that it is not important why a L2 Transactions has been reverted before it is finalized. -[[R25]](#r25) Testability: Reverting one or more L2 Transactions means that the L2 State is reverted to a previous L2 State which is recorded on both the L2 and its corresponding L1, and this means that the reverted L2 transaction are removed from the L2 State. Since [[R11]](#r11) is testable and allows to view the history of all L2 Transactions and their Transactions Fees, it can be tested if a L2 transaction has been reverted, in other words has been removed from the L2, and, therefore, if a Transaction Fee has been charged to a Transaction Sender. +[[R25]](#r25) Testability: + +Preconditions: + +* An L2 test instance is set up and functional. +* There are at least two valid L2 Transactions that have not been finalized on the L2's Layer 1. +* Each L2 Transaction has a valid Transaction Sender. +* The L2 Transactions have Transaction Fees associated with them. +* The L2 protocol supports the reversion of Transactions before they are finalized on Layer 1. +Test Steps: + +1. Verify that the initial balances of the Transaction Senders are recorded. +2. Submit the L2 Transactions to the L2. +3. Verify that the L2 Transactions are valid and the Transaction Fees are calculated correctly. +4. Attempt to revert one of the L2 Transactions before it is finalized on the L2's Layer 1. +5. Verify that the reverted L2 Transaction's Transaction Fees are not charged to the Transaction Sender. +6. Finalize the remaining L2 Transactions on the L2's Layer 1. +7. Verify that the Transaction Fees are charged to the Transaction Senders for the finalized L2 Transactions. +8. Verify that the balances of the Transaction Senders have been updated accordingly. + +Test Passing Criteria: + +* The balances of the Transaction Senders are updated correctly after the L2 Transactions are finalized. +* The Transaction Fees for the finalized L2 Transactions are charged to the corresponding Transaction Senders. +* The Transaction Fees for the reverted L2 Transactions are not charged to the corresponding Transaction Senders. #### **[D1]** If one or more L2 Meta Transactions are reverted before they are finalized on the L2's Layer 1, the Transaction Fees in the affected Meta Transactions SHOULD be returned to the Transaction Originator by the Intermediary as a Transaction Fee Refund. -[[D1]](#d1) Testability: Unless the Intermediary is paid through a L2 Transactions submitted as part of a Meta Transaction, in which case the Meta Transaction reversion would also reverse the Transaction Fee paid by the Transaction Originator to the Intermediary, the Transaction Fee has been prepaid to the Intermediary by the Transaction Originator. This means the prepayment is included in a finalized L2 State. Therefore, the Intermediary must submit a new L2 Transaction which pays back the Transaction Fee of the reversed L2 Meta Transaction to the Tranaction Originator. Since L2 Transactions and their recording on a L2 are testable such as with [Arbitrum One/Nitro](https://github.com/OffchainLabs/nitro/tree/master/system_tests) with its test suite, the requirement is testable. +[[D1]](#d1) Testability: + +Preconditions: + +* An L2 test instance is set up and available for testing. +* A set of L2 Meta Transactions has been submitted by the Transaction Sender and processed on the L2. +* Some of the L2 Meta Transactions have been reverted before being finalized on the L2's Layer 1. + +Test steps: + +1. Submit a set of L2 Meta Transactions to the L2. +2. Verify that the Transaction Sender and Developer can view the estimated Transaction Fees and their components before submitting the L2 Meta Transactions. +3. Verify that the Intermediary can view and record the Transaction Fees and their components after the L2 Meta Transactions have been processed on the L2. +5. Revert some of the L2 Meta Transactions before they are finalized on the L2's Layer 1. +6. The Intermediary returns the recorded Transaction Fees for the reverted Meta Transactions from the Transaction Sender Account or the account of the Intermediary to the account of the Transaction Originator. +7. Verify that the Transaction Originator received the Transaction Fee Refund and it has the right value. + +Test passing criteria: + +* The Intermediary, Transaction Sender and Developer can view the estimated Transaction Fees and their components before submitting the L2 Meta Transactions. +* The Intermediary can view the Transaction Fees and their components after the L2 Meta Transactions have been processed on the L2. +* The Intermediary returns the right amount of Transaction Fees as a refund to the Transaction Originator when L2 Meta Transactions are reverted. ------- # 4 Conformance + ###### L2TFSPECCONF This section describes the conformance clauses and tests required to achieve an implementation that is provably conformant with the requirements in this document. ## 4.1 Conformance Targets + ###### L2TFSPECCONFT This document does not yet define a standardized set of test-fixtures with test inputs for all MUST, SHOULD, and MAY requirements with conditional MUST or SHOULD requirements. @@ -557,6 +1063,7 @@ This document does not yet define a standardized set of test-fixtures with test A standardized set of test-fixtures with test inputs for all MUST, SHOULD, and MAY requirements with conditional MUST or SHOULD requirements is intended to be published with the next version of the standard. ## 4.2 Conformance Levels + ###### L2TFSPECCONFL This section specifies the conformance levels of this standard. The conformance levels offer implementers several levels of conformance. These can be used to establish competitive differentiation. From 21ba179b1ecbe78b447d882606a0894d757e5431 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Wed, 3 May 2023 17:43:46 -0700 Subject: [PATCH 17/24] minor editorial updates after PR review during 5/3 WG meeting --- .../l2-transaction-fees-v1.0-psd01.md | 62 +++++++++---------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index bf28fdd..c2d028c 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -286,10 +286,10 @@ Subsequently, the specification section will define requirements around fee tran This document defines Transaction Fee as the fee in a Layer 2 (L2) network or protocol token to be paid by a Transaction Originator or Transaction Sender comprised of the sum of a Base Fee, an Execution Fee and a Priority Fee. -Note that this document defines as Transaction as a digitally signed message sent from a L2 account that contains instructions and data that result in a L2 state transition. Also note that this document defines State and State Transition as follows: +Note that this document defines as Transaction as a digitally signed message sent from an L2 account that contains instructions and data that result in an L2 state transition. Also note that this document defines State and State Transition as follows: -* State: The set of all accounts on a L2 that are mapped to one another using a cryptographic data structure. -* State Transition: An event that deterministically changes one or more accounts in the set of all accounts that comprise the complete state of a L2. +* State: The set of all accounts on an L2 that are mapped to one another using a cryptographic data structure. +* State Transition: An event that deterministically changes one or more accounts in the set of all accounts that comprise the complete state of an L2. Further note that this document defines Account as a unit that is minimally comprised of a unique account identifier, a deterministic ordering parameter, also referred to as a nonce, a balance of a Layer 1, Layer 2 or Sidechain unit of exchange, also referred to as a protocol token. Changes to an account are controlled by a unique cryptographic public and private key pair. There are typically additional account elements referring to instructions and data associated to the account that determine account changes. @@ -299,13 +299,13 @@ In formula form the Transaction Fee is given as: The different components are defined as follows: -* **Base Fee:** The minimum amount of Gas or a L2 gas equivalent unit of compute and storage consumption required to include a transaction on a L2. +* **Base Fee:** The minimum amount of Gas or an L2 gas equivalent unit of compute and storage consumption required to include a transaction on an L2. * **Execution Fee:** A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover both the L2 and Layer 1 transaction fees. -* **Priority Fee:** To be paid by the Transaction Originator or Transaction Sender to a L2 sequencer to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction, a slot, in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. And that MEV is defined as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. +* **Priority Fee:** To be paid by the Transaction Originator or Transaction Sender to an L2 sequencer to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction, a slot, in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. And that MEV is defined as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. -Note that a Transaction Fee has a Transaction Fee Price which is defined in the context of this document as a L2 Gas price or a price of a L2 gas equivalent unit of compute and storage consumption. +Note that a Transaction Fee has a Transaction Fee Price which is defined in the context of this document as an L2 Gas price or a price of an L2 gas equivalent unit of compute and storage consumption. -Note that a Gas price or a price of a L2 gas equivalent unit of compute and storage consumption is typically variable and changes with the level of usage of a L2 network. Note that a gas price is expressed in Giga Wei (GWEI) for EVM-compatible networks, where Wei represents the smallest unit of gas; 1 Wei = 10-18 Eth in Ethereum's native token. +Note that a Gas price or a price of an L2 gas equivalent unit of compute and storage consumption is typically variable and changes with the level of usage of an L2 network. Note that a gas price is expressed in Giga Wei (GWEI) for EVM-compatible networks, where Wei represents the smallest unit of gas; 1 Wei = 10-18 Eth in Ethereum's native token. Furthermore, note that Gas in this document refers to the unit that measures the amount of computational and storage effort required to execute specific operations on an EVM-compatible network. @@ -318,7 +318,7 @@ The following roles are relevant to transaction fees, their calculation and how, * **Transaction Sender:** The account that sent a transaction to a Layer 1, L2, or Sidechain. * **Intermediary:** An entity that is the sender of a transaction for which it is not the Transaction Originator. * **Sequencer:** Collects transactions, publishes them in a batch to the Layer 1 on which the L2 operates, receives transaction fees from the published transactions, pays L2 fees to other L2 protocol participants, and, if required, participates in a consensus algorithm with other sequencers to determine transaction ordering in a block. -* **L2 Operator:** An entity responsible for the operation of a L2. +* **L2 Operator:** An entity responsible for the operation of an L2. * **Developer:** An individual writing computer code for software applications that operate on a Layer 1, L2 or Sidechain. ## 2.3 Definition of Transaction Types @@ -359,7 +359,7 @@ An L2 Transaction Fee MUST be comprised as the sum of a Base Fee, a Execution Fe #### **[R2]** -All components of a L2 Transaction Fee MUST NOT be less than zero. +All components of an L2 Transaction Fee MUST NOT be less than zero. [[R2]](#r2) Testability: Mathematical equality or inequality equations can be expressed as testable conditions. A passing test condition is that each individual element of a transaction fee is equal to or larger than zero. A failing test condition is that one or more transaction fee elements is less than zero. @@ -550,7 +550,7 @@ Test Passing Criteria: An L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on theL2. -Transaction finality in the context of this document is defined as the condition when a transaction can no longer be reverted on a L2. Note that the finality condition will vary by L2, and that L2 finality requirements are outside of the scope of this document. +Transaction finality in the context of this document is defined as the condition when a transaction can no longer be reverted on an L2. Note that the finality condition will vary by L2, and that L2 finality requirements are outside of the scope of this document. [[R9]](#r9) Testability: @@ -577,7 +577,7 @@ Test Passing Criteria: #### **[R10]** -If there is a Transaction Fee Refund, a L2 implementation MUST record and provide access to the Transaction Fee Refund when a Transaction has been finalized on the L2. +If there is a Transaction Fee Refund, an L2 implementation MUST record and provide access to the Transaction Fee Refund when a Transaction has been finalized on the L2. A Transaction Fee Refund in the context of this document is defined as the difference between the Transaction Fee that the Transaction Sender has included in the Transaction sent to the L2 and the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on the L2. @@ -662,7 +662,7 @@ In this section, this document discusses the visibility requirements for differe #### **[R13]** -A Transaction Originator, a Transaction Sender and a Developer MUST be able to view an estimated Transaction Fee and its components before a L2 Transaction is submitted. +A Transaction Originator, a Transaction Sender and a Developer MUST be able to view an estimated Transaction Fee and its components before an L2 Transaction is submitted. [[R13]](#r13) Testability: @@ -685,7 +685,7 @@ Test Passing Criteria: #### **[R14]** -A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after a L2 Direct Transaction has been processed on the L2. +A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after an L2 Direct Transaction has been processed on the L2. [[R14]](#r14) Testability: @@ -694,7 +694,7 @@ Preconditions: * An L2 test instance is operational and available for use. * The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. * At least one Direct Transaction has been submitted and processed on the L2. -* The L2 has a defined method to notify L2 users that a L2 transaction has been processed. +* The L2 has a defined method to notify L2 users that an L2 transaction has been processed. Test Steps: @@ -714,7 +714,7 @@ Test Passing Criteria: The test passes if, #### **[R15]** -An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after a L2 Meta Transaction has been processed on the L2. +An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after an L2 Meta Transaction has been processed on the L2. [[R15]](#r15) Testability: @@ -723,7 +723,7 @@ Preconditions: * An L2 instance is operational and accepting transactions. * The Intermediary and Developer have access to the L2. * The Intermediary and Developer have a Meta Transaction ready to submit to the L2. -* The L2 has a defined method to notify L2 users that a L2 transaction has been processed. +* The L2 has a defined method to notify L2 users that an L2 transaction has been processed. Test Steps: @@ -742,7 +742,7 @@ Test Passing Criteria: The test passes if, #### **[R16]** -A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after a L2 Direct Transaction has been finalized on the L2. +A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after an L2 Direct Transaction has been finalized on the L2. [[R16]](#r16) Testability: @@ -751,7 +751,7 @@ Preconditions: * An L2 test instance is operational and available for use. * The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. * At least one Direct Transaction has been submitted, processed and finalized on the L2. -* The L2 has a defined method to notify L2 users that a L2 transaction has been finalized. +* The L2 has a defined method to notify L2 users that an L2 transaction has been finalized. Test Steps: @@ -768,7 +768,7 @@ Test Passing Criteria: The test passes if, #### **[R17]** -An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after a L2 Meta Transaction has been finalized on the L2. +An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after an L2 Meta Transaction has been finalized on the L2. [[R17]](#r17) Testability: @@ -777,7 +777,7 @@ Preconditions: * An L2 instance is operational and accepting transactions. * The Intermediary and Developer have access to the L2. * The Intermediary and Developer have a Meta Transaction ready to submit to the L2. -* The L2 has a defined method to notify L2 users that a L2 transaction has been finalized. +* The L2 has a defined method to notify L2 users that an L2 transaction has been finalized. Test Steps: @@ -797,7 +797,7 @@ Test Passing Criteria: The test passes if, #### **[R18]** -If there is a Transaction Fee Refund, a Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee Refund after a L2 Direct Transaction has been finalized on the L2. +If there is a Transaction Fee Refund, a Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee Refund after an L2 Direct Transaction has been finalized on the L2. [[R18]](#r18) Testability: @@ -806,7 +806,7 @@ Preconditions: * An L2 test instance is operational and available for use. * The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. * At least one Direct Transaction has been submitted, processed and finalized on the L2. -* The L2 has a defined method to notify L2 users that a L2 transaction has been finalized. +* The L2 has a defined method to notify L2 users that an L2 transaction has been finalized. Test Steps: @@ -823,7 +823,7 @@ Test Passing Criteria: The test passes if, #### **[R19]** -If there is a Transaction Fee Refund, an Intermediary and a Developer MUST be able to view a Transaction Fee Refund after a L2 Meta Transaction has been finalized on the L2. +If there is a Transaction Fee Refund, an Intermediary and a Developer MUST be able to view a Transaction Fee Refund after an L2 Meta Transaction has been finalized on the L2. [[R19]](#r19) Testability: @@ -832,7 +832,7 @@ Preconditions: * An L2 instance is operational and accepting transactions. * The Intermediary and Developer have access to the L2. * The Intermediary and Developer have a Meta Transaction ready to submit to the L2. -* The L2 has a defined method to notify L2 users that a L2 transaction has been finalized. +* The L2 has a defined method to notify L2 users that an L2 transaction has been finalized. Test Steps: @@ -851,7 +851,7 @@ Test Passing Criteria: The test passes if, #### **[R20]** -An L2 MUST provide an Intermediary with a capability to display the Transaction Fee and its components of a L2 Meta Transaction after it has been processed on the L2 to 3rd parties. +An L2 MUST provide an Intermediary with a capability to display the Transaction Fee and its components of an L2 Meta Transaction after it has been processed on the L2 to 3rd parties. [[R20]](#r20) Testability: @@ -881,7 +881,7 @@ Test Passing Criteria: #### **[R21]** -If there is a Transaction Fee Refund, a L2 MUST provide an Intermediary with a capability to display the Transaction Fee Refund of a L2 Meta Transaction to its Transaction Originator after it has been finalized on the L2. +If there is a Transaction Fee Refund, an L2 MUST provide an Intermediary with a capability to display the Transaction Fee Refund of an L2 Meta Transaction to a 3rd party after it has been finalized on the L2. [[R21]](#r21) Testability: @@ -911,7 +911,7 @@ Test Passing criteria: A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on. -[R22]](#r22) Testability: +[[R22]](#r22) Testability: Preconditions: @@ -933,7 +933,7 @@ Test Passing criteria: ## 3.3 Transaction Fee Requirements for Layer 2 Transactions -In this section, the documents details Transaction Fee requirements for a L2 Transaction and its processing. +In this section, the documents details Transaction Fee requirements for an L2 Transaction and its processing. #### **[R23]** @@ -991,7 +991,7 @@ Test Passing criteria: If one or more L2 Transactions are reverted before they are finalized on the L2's Layer 1, the Transaction Fees in the affected Transactions MUST not be charged to the Transaction Senders. -Note that it is not important why a L2 Transactions has been reverted before it is finalized. +Note, that it is not important why an L2 Transaction has been reverted before it is finalized. [[R25]](#r25) Testability: @@ -1022,7 +1022,7 @@ Test Passing Criteria: #### **[D1]** -If one or more L2 Meta Transactions are reverted before they are finalized on the L2's Layer 1, the Transaction Fees in the affected Meta Transactions SHOULD be returned to the Transaction Originator by the Intermediary as a Transaction Fee Refund. +If an L2 Meta Transactions is reverted before it is finalized on the processing L2's Layer 1 and the Transaction Originator has been charged the Transaction Fee by the Intermediary, the Transaction Fee in the reverted Meta Transaction SHOULD be refunded to the Transaction Originator by the Intermediary. [[D1]](#d1) Testability: @@ -1073,7 +1073,7 @@ This document defines the conformance levels of L2 Transaction Fees as follows: * **Level 2:** All MUST and SHOULD requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs. * **Level 3:** All MUST, SHOULD, and MAY requirements with conditional MUST or SHOULD requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs. -### **[D2]** +#### **[D2]** A claim that a Transaction Fee conforms to this specification SHOULD describe a testing procedure carried out for each requirement to which conformance is claimed, that justifies the claim with respect to that requirement. [[D2]](#d2) Testability: Since each of the non-conformance-target requirements in this documents is testable, so must be the totality of the requirements in this document. Therefore, conformance tests for all requirements can exist, and can be described as required in [[D2]](#d2). From 417d4d2cb7d79c225ab2544f94d14a54ce79d305 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Wed, 3 May 2023 17:55:58 -0700 Subject: [PATCH 18/24] Editorial update - fixing wording in testability for R1 - fixed layout of test steps in testability for R14 --- .../l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index c2d028c..0e00541 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -355,7 +355,7 @@ In this section we will formulate requirements in the following areas: An L2 Transaction Fee MUST be comprised as the sum of a Base Fee, a Execution Fee, and a Priority Fee. -[[R1]](#r1) Testability: Mathematical equality equations can be tested as the sum of the equations elements equaling a desired output is a passing test, and the sum of the equations element not equaling the desired output a failing test.. +[[R1]](#r1) Testability: Mathematical equality equations can be tested as the sum of the equations elements equaling a desired output. The test is passed if the sum of the elements as inputs is equal to the desired output. If the sum of the equations element do not equal the desired output the test fails. #### **[R2]** @@ -367,7 +367,7 @@ All components of an L2 Transaction Fee MUST NOT be less than zero. An L2 Transaction Fee or any of its components MAY BE zero. -[[O1]](#o1) Testability: Mathematical equality equations can be expressed as testable conditions. A test for [[R2]](#r2) also tests this optional requirement since zero values are allowed in tests for [[R2]](#r2). +[[O1]](#o1) Testability: Mathematical equality equations can be expressed as testable conditions. A test for [[R2]](#r2) also tests this optional requirement since zero values are allowed in tests for [[R2]](#r2). #### **[R3]** @@ -698,7 +698,7 @@ Preconditions: Test Steps: -1.Transaction Sender or Developer submit a Direct Transaction to the L2. +1. Transaction Sender or Developer submit a Direct Transaction to the L2. 2. The L2 processes the Direct Transaction and charges a Transaction Fee. 3. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been processed on the L2 using the Transaction ID from the transaction processing confirmation notification from the L2. 4. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. From bab8cde93e4fdddf89f6dfa91d832189712d8061 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Wed, 17 May 2023 13:40:32 -0700 Subject: [PATCH 19/24] two minor editorial changes after 5/17 WG meeting --- .../l2-transaction-fees-v1.0-psd01.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 0e00541..8f1adf8 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -353,7 +353,7 @@ In this section we will formulate requirements in the following areas: #### **[R1]** -An L2 Transaction Fee MUST be comprised as the sum of a Base Fee, a Execution Fee, and a Priority Fee. +An L2 Transaction Fee MUST be comprised as the sum of a Base Fee, an Execution Fee, and a Priority Fee. [[R1]](#r1) Testability: Mathematical equality equations can be tested as the sum of the equations elements equaling a desired output. The test is passed if the sum of the elements as inputs is equal to the desired output. If the sum of the equations element do not equal the desired output the test fails. @@ -379,7 +379,7 @@ Preconditions: * The L2 must have a defined Base Fee. * There must be documentation available for the current Base Fee. -* An test L2 is up and running. +* An L2 test instance is up and running. Test Steps: @@ -407,7 +407,7 @@ Preconditions: * The L2 must have a defined Execution Fee. * There must be documentation available for the current Execution Fee. -* An test L2 is up and running. +* An L2 test instance is up and running. Test Steps: @@ -484,7 +484,7 @@ Test Steps: 5. Increase the number of transactions waiting to be processed on the L2 by submitting another test data set with more transactions and submit a complex test Transaction. 6. Record the estimated Transaction Fee provided by the L2. 7. Verify that the estimated Transaction Fee has increased in response to the increase in the number of transactions waiting to be processed and currently being processed. -8 Verify that the estimated Transaction Fee has increased in response to the increase in the number of transactions currently being processed and waiting to be processed. +8. Verify that the estimated Transaction Fee has increased in response to the increase in the number of transactions currently being processed and waiting to be processed. 9. Repeat the test with different test Transactions of varying complexity to ensure that the Transaction Fee estimation process is accurately responsive to changes in Operating Conditions and transaction complexity. Test Passing Criteria: @@ -498,7 +498,7 @@ Test Passing Criteria: An L2 MUST record and provide access to the Transaction Fee that the Transaction Sender has included in the Transaction when a Transaction has been sent to the L2. -[[R7]](#r7) Testability: +[[R7]](#r7) Testability: Preconditions: From 995131c185fdda6eb02330f1f77a7091587f4476 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Fri, 16 Jun 2023 10:57:50 -0700 Subject: [PATCH 20/24] Update to draft based on suggestions from 06/14/23 WG meeting --- .../l2-transaction-fees-v1.0-psd01.md | 60 +++++++++---------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 8f1adf8..6fcf280 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -379,7 +379,7 @@ Preconditions: * The L2 must have a defined Base Fee. * There must be documentation available for the current Base Fee. -* An L2 test instance is up and running. +* An L2 instance is up and running. Test Steps: @@ -407,7 +407,7 @@ Preconditions: * The L2 must have a defined Execution Fee. * There must be documentation available for the current Execution Fee. -* An L2 test instance is up and running. +* An L2 instance is up and running. Test Steps: @@ -435,7 +435,7 @@ Preconditions: * The L2 must have a defined Base Fee and Execution Fee. * There must be documentation available for the current Priority Fee. -* An L2 test system must be up and running. +* An L2 system must be up and running. * An L2 user is configured. Test Steps: @@ -444,7 +444,7 @@ Test Steps: 2. Verify that the documentation includes the specific factors or criteria used to determine and set the Priority Fee. 3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the determination and setting of the Priority Fee. 4. Verify that the documentation is up-to-date and accurate. -5. An L2 test user sets a priority fee for a transaction. +5. An L2 user sets a priority fee for a transaction. 6. Verify that the set Priority Fee is correctly added to the Base Fee and Execution Fee to calculate the Transaction Fee. 7. Verify that the calculated Transaction Fee matches the currently charged Transaction Fee for the set Priority Fee. @@ -466,7 +466,7 @@ Note that L2 Operating Conditions refer to a combination of the current volume o Preconditions: -* An L2 test system is up and running. +* An L2 system is up and running. * The L2 must have a defined process for estimating a Transaction Fee based on varying Operating Conditions. * Operating Conditions must be measurable for the L2, including: * The current number of transactions waiting to be processed on the L2. @@ -502,7 +502,7 @@ An L2 MUST record and provide access to the Transaction Fee that the Transaction Preconditions: -* An L2 test system is up and running. +* An L2 system is up and running. * The L2 must have a defined process for recording and storing the Transaction Fee included by the Transaction Sender. * A test Transaction must be available with a known Transaction Fee included by the Transaction Sender. @@ -528,7 +528,7 @@ An L2 MUST record and provide access to the Transaction Fee that has been charge Preconditions: -* An L2 test system is up and running. +* An L2 system is up and running. * The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender. * A test Transaction must be available with a known Transaction Fee charged to the Transaction Sender. @@ -543,7 +543,7 @@ Test Steps: Test Passing Criteria: * The L2 must have calculated and recorded the Transaction Fee charged to the Transaction Sender. -* The recorded Transaction Fee must be accessible by the user. +* The recorded Transaction Fee must be accessible by the Transaction Sender. * The recorded Transaction Fee must match or is less than the Transaction Fee submitted by the Transaction Sender. #### **[R9]** @@ -557,7 +557,7 @@ Transaction finality in the context of this document is defined as the condition Preconditions: * The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender. -* An L2 test system is up and running. +* An L2 system is up and running. * A test Transaction must be available with a known, estimated Transaction Fee to be charged to the Transaction Sender. * The test environment must have finalized the test Transaction on the L2 according to the L2 finality conditions. @@ -586,7 +586,7 @@ A Transaction Fee Refund in the context of this document is defined as the diffe Preconditions: * The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender and the Transaction Fee Refund. -* An L2 test system is up and running. +* An L2 system is up and running. * A test Transaction must be available with a known Transaction Fee estimate to be charged to the Transaction Sender. * The test environment must have finalized the test Transaction on the L2 based on its finality conditions. @@ -623,7 +623,7 @@ Test Steps: 3. Query the L2 for a Transaction ID from the set of finalized test transactions. 4. For a given Transaction ID, retrieve the Transaction ID, Transaction Fee, Transaction Fee components (Base Fee, Execution Fee, and Priority Fee), and Transaction Fee Refund (if applicable). 5. Verify that the retrieved Transaction Fee, Transaction Fee components, and Transaction Fee Refund (if applicable) match the values recorded in the transaction confirmations. -6. Repeat steps 3. through 5. for each Transaction ID in the set of test transactions at random time intervals during a 24 hour period for the entire test transaction set. +6. Repeat steps 3. through 5. for each Transaction ID in the set of test transactions at random time intervals during the test for the entire test transaction set. Test Passing Criteria: @@ -668,7 +668,7 @@ A Transaction Originator, a Transaction Sender and a Developer MUST be able to v Preconditions: -* An L2 test instance is set up and running. +* An L2 instance is set up and running. * A Transaction Originator, a Transaction Sender, and a Developer have access to the L2 and can interact with it. * The L2 provides a capability to estimate Transaction Fees based on current operating conditions and other relevant factors. @@ -691,7 +691,7 @@ A Transaction Originator, a Transaction Sender and a Developer MUST be able to v Preconditions: -* An L2 test instance is operational and available for use. +* An L2 instance is operational and available for use. * The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. * At least one Direct Transaction has been submitted and processed on the L2. * The L2 has a defined method to notify L2 users that an L2 transaction has been processed. @@ -708,7 +708,7 @@ Test Steps: Test Passing Criteria: The test passes if, * The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been processed. -* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction. * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. @@ -737,7 +737,7 @@ Test Steps: Test Passing Criteria: The test passes if, * The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been processed. -* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Meta Transaction. * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. #### **[R16]** @@ -748,7 +748,7 @@ A Transaction Originator, a Transaction Sender and a Developer MUST be able to v Preconditions: -* An L2 test instance is operational and available for use. +* An L2 instance is operational and available for use. * The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. * At least one Direct Transaction has been submitted, processed and finalized on the L2. * The L2 has a defined method to notify L2 users that an L2 transaction has been finalized. @@ -763,8 +763,8 @@ Test Steps: Test Passing Criteria: The test passes if, * The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been finalized. -* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. -* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account, if applicable. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. #### **[R17]** @@ -791,7 +791,7 @@ Test Steps: Test Passing Criteria: The test passes if, * The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been finalized. -* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Meta Transaction. * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. @@ -803,7 +803,7 @@ If there is a Transaction Fee Refund, a Transaction Originator, a Transaction Se Preconditions: -* An L2 test instance is operational and available for use. +* An L2 instance is operational and available for use. * The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information. * At least one Direct Transaction has been submitted, processed and finalized on the L2. * The L2 has a defined method to notify L2 users that an L2 transaction has been finalized. @@ -812,13 +812,13 @@ Test Steps: 1. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been finalized on the L2 using the Transaction ID from the transaction finalization confirmation notification from the L2. 2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. -3. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 is less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +3. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 is equal to or less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction. 4. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account. Test Passing Criteria: The test passes if, * The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been finalized. -* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. +* The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction. * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account, if applicable. #### **[R19]** @@ -846,7 +846,7 @@ Test Steps: Test Passing Criteria: The test passes if, * The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been finalized. -* The Transaction Fee and its components displayed on the L2 are less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. +* The Transaction Fee and its components displayed on the L2 are less than the Transaction Fee and its components displayed to the Intermediary and Develope before submitting the Meta Transaction. * The Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account. #### **[R20]** @@ -857,7 +857,7 @@ An L2 MUST provide an Intermediary with a capability to display the Transaction Preconditions: -* A L2 test instance is operational and accessible. +* A L2 instance is operational and accessible. * There is at least one Intermediary operating on the L2. * At least one L2 Meta Transaction has been submitted and processed on the L2. * The Intermediary can access the Transaction with its Transaction Fee and its Fee components. @@ -887,7 +887,7 @@ If there is a Transaction Fee Refund, an L2 MUST provide an Intermediary with a Preconditions: -* An L2 test instance is deployed and running. +* An L2 instance is deployed and running. * An Intermediary is operating on the L2 and has the necessary permissions to view Transaction Fee Refunds. * A set of L2 Meta Transactions has been submitted and processed on the L2, resulting in at least one Transaction Fee Refund. @@ -915,7 +915,7 @@ A Transaction Originator, a Transaction Sender and a Developer MUST be able to v Preconditions: -* An L2 test instance is live and operational. +* An L2 instance is live and operational. * The Transaction Originator, Transaction Sender, and Developer have access to the L2. * The Fee Price calculation is based on the current Operating Condition of the L2. * A Fee Price Emulator that can accurately calculate a Fee Price based on current Operating Conditions on the L2. @@ -944,7 +944,7 @@ Every L2 Transaction MUST contain a Transaction Fee and its components. Preconditions: -* An L2 test instance is set up and functional. +* An L2 instance is set up and functional. * There is a user account on the L2 with the necessary permissions to submit a transaction. * There is a sufficient balance of funds available in the user's account to cover the transaction fee. @@ -972,7 +972,7 @@ Every L2 Block MUST contain one or more L2 account addresses to which the accumu Preconditions: * The L2 protocol and its specifications have been implemented and tested. -* An L2 test instance is set up and functional. +* An L2 instance is set up and functional. * A set of L2 transactions have been created and finalized on the L2. Test steps: @@ -997,7 +997,7 @@ Note, that it is not important why an L2 Transaction has been reverted before it Preconditions: -* An L2 test instance is set up and functional. +* An L2 instance is set up and functional. * There are at least two valid L2 Transactions that have not been finalized on the L2's Layer 1. * Each L2 Transaction has a valid Transaction Sender. * The L2 Transactions have Transaction Fees associated with them. @@ -1028,7 +1028,7 @@ If an L2 Meta Transactions is reverted before it is finalized on the processing Preconditions: -* An L2 test instance is set up and available for testing. +* An L2 instance is set up and available for testing. * A set of L2 Meta Transactions has been submitted by the Transaction Sender and processed on the L2. * Some of the L2 Meta Transactions have been reverted before being finalized on the L2's Layer 1. From eff72b2fc7fbce1c7ae9ab62d862432e8ff8bc58 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Fri, 21 Jul 2023 16:42:59 -0700 Subject: [PATCH 21/24] Updates based on WG review on 7/12/2023 --- .../l2-transaction-fees-v1.0-psd01.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 6fcf280..49b6c9e 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -868,9 +868,9 @@ Test Steps: 1. The Intermediary logs into their account on the L2. 2. The Intermediary selects the L2 Meta Transaction they wish to view the Transaction Fee and its components for using the Transaction ID from the transaction processing confirmation notification from the L2. 3. The L2 displays the Transaction Fee and its components of the selected L2 Meta Transaction to the Intermediary. -4. The Intermediary verifies that the displayed Transaction Fee and its components match or are less than process the Transaction Fee and its components. +4. The Intermediary verifies that the displayed Transaction Fee and its components match or are less than the submitted Transaction Fee and its components. 5. The Intermediary attempts to display the Transaction Fee and its components of the selected L2 Meta Transaction to a 3rd party. -6. The 3rd party verifies that it can view displayed Transaction Fee and its components match the Transaction Fee and its components for the Transaction ID of the Meta Transaction when accessed directly on the L2 using the Transaction ID. +6. The 3rd party verifies that the displayed Transaction Fee and its components match the Transaction Fee and its components for the Transaction ID of the Meta Transaction when accessed directly on the L2 using the Transaction ID. Test Passing Criteria: @@ -893,14 +893,14 @@ Preconditions: Test steps: -1. The Intermediary sends a request to the L2 to display the Transaction Fee Refund of a specific L2 Meta Transaction using the Transaction ID from the transaction finalization confirmation notification from the L2.. +1. The Intermediary sends a request to the L2 to display the Transaction Fee Refund of a specific L2 Meta Transaction using the Transaction ID from the L2's transaction finalization confirmation notification. 2. The L2 receives the request and verifies that the Intermediary has the necessary permissions to view Transaction Fee Refunds. 3. The L2 retrieves the Transaction Fee Refund information for the requested L2 Meta Transaction. 4. The L2 sends the Transaction Fee Refund information to the Intermediary. 5. The Intermediary receives the Transaction Fee Refund information. 6. The Intermediary verifies that the Transaction Fee Refund information matches the expected values based on the difference in the L2 Meta Transaction Transaction Fee between the submitted and finalized L2 Meta Transaction. -7. The Intermediary displays the Transaction Fee Refund information to the Transaction Originator. -8. The Transaction Originator verifies that it can view displayed Transaction Fee and its components match the Transaction Fee and its components for the Transaction ID of the Meta Transaction when accessed directly on the L2 using the Transaction ID. +7. The Intermediary displays the Transaction Fee Refund information to the requesting 3rd party. +8. The requesting 3rd party verifies that the displayed Transaction Fee and its components match the Transaction Fee and its components for the Transaction ID of the Meta Transaction when accessed directly on the L2 using the Transaction ID. Test Passing criteria: @@ -1022,7 +1022,7 @@ Test Passing Criteria: #### **[D1]** -If an L2 Meta Transactions is reverted before it is finalized on the processing L2's Layer 1 and the Transaction Originator has been charged the Transaction Fee by the Intermediary, the Transaction Fee in the reverted Meta Transaction SHOULD be refunded to the Transaction Originator by the Intermediary. +If an L2 Meta Transaction is reverted before it is finalized on the processing L2's Layer 1 and the Transaction Originator has been charged the Transaction Fee by the Intermediary, the Transaction Fee in the reverted Meta Transaction SHOULD be refunded to the Transaction Originator by the Intermediary. [[D1]](#d1) Testability: From 334f293e549812f39c6f5e176522cdc7337da22b Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Tue, 24 Oct 2023 07:58:06 -0700 Subject: [PATCH 22/24] Definitions Update per @DZGoldman feedback Updated the following definitions: - Execution Fee - Priority Fee - Sequencer --- .../l2-transaction-fees-v1.0-psd01.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 49b6c9e..25732db 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -159,7 +159,7 @@ A transaction where the Transaction Originator is also the Transaction Sender. **Execution Fee:** -A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover both the Layer 2 and Layer 1 transaction fees. +A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover both the Layer 2 and Layer 1 transaction fees excluding a Base Fee, or a Priority Fee. An example calculation of such an Execution Fee is: $$L2\space Gas\space Limit + {L1\space Transaction\space Fee \over L2\space Gas\space Price}$$ @@ -208,13 +208,13 @@ A transaction where the Transaction Sender is not the Transaction Originator, an **Priority Fee:** -To be paid by the Transaction Originator or Transaction Sender to a Layer 2 sequencer to obtain a desired slot for its transaction in a new block. +Paid by the Transaction Originator or Transaction Sender to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. **Sequencer:** -Collects transactions, publishes them in a batch to the Layer 1 on which the Layer 2 operates, receives transaction fees from the published transactions, pays Layer 2 fees to other Layer 2 protocol participants, and, if required, participates in a consensus algorithm with other sequencers to determine transaction ordering in a Layer 2 block. +Collects L2 transactions, publishes them in a batch to the Layer 1 on which the Layer 2 operates, and, if required, participates in a consensus algorithm with other sequencers to determine transaction ordering in a Layer 2 block. It may collect transaction fees from the published transactions, pay Layer 2 fees to other Layer 2 protocol participants, or distribute transaction fees to 3rd parties as designated. **Sidechain:** @@ -300,8 +300,8 @@ In formula form the Transaction Fee is given as: The different components are defined as follows: * **Base Fee:** The minimum amount of Gas or an L2 gas equivalent unit of compute and storage consumption required to include a transaction on an L2. -* **Execution Fee:** A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover both the L2 and Layer 1 transaction fees. -* **Priority Fee:** To be paid by the Transaction Originator or Transaction Sender to an L2 sequencer to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction, a slot, in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. And that MEV is defined as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. +* **Execution Fee:** A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover both the Layer 2 and Layer 1 transaction fees excluding a Base Fee, or a Priority Fee. +* **Priority Fee:** Paid by the Transaction Originator or Transaction Sender to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction, a slot, in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. And that MEV is defined as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. Note that a Transaction Fee has a Transaction Fee Price which is defined in the context of this document as an L2 Gas price or a price of an L2 gas equivalent unit of compute and storage consumption. From 31f88ba0a712600fc0c9fe19eb13b8c66a9cf7ce Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Mon, 4 Dec 2023 14:01:14 -0800 Subject: [PATCH 23/24] Merging PR 43 and PR 50 - Removed Base Fee definition and updated spec accordingly - Reworded Execution Fee definition and updated spec accordingly - Added Data Fee definition and updated spec accordingly - Added 6 new requirements on L1 and L2 gas price, gas cost and calculation transparency and verification including testability statement. - Updated requirements numbers. --- .../l2-transaction-fees-v1.0-psd01.md | 288 +++++++++++++----- 1 file changed, 218 insertions(+), 70 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 25732db..513a3f5 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -137,10 +137,6 @@ Note, that fees associated with asset and data bridges between L2 platforms as w A unit that is minimally comprised of a unique account identifier, a deterministic ordering parameter, also referred to as a nonce, a balance of a Layer 1, Layer 2 or Sidechain unit of exchange, also referred to as a protocol token. Changes to an account are controlled by a unique cryptographic public and private key pair. There are typically additional account elements referring to instructions and data associated to the account that determine account changes. -**Base Fee:** - -The minimum amount of gas or a Layer 2 gas equivalent unit of compute and storage consumption required to include a transaction on a Layer 2. - **Blockchain:** An open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. @@ -157,12 +153,13 @@ An individual writing computer code for software applications that operate on a A transaction where the Transaction Originator is also the Transaction Sender. -**Execution Fee:** +**Data Fee:** -A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover both the Layer 2 and Layer 1 transaction fees excluding a Base Fee, or a Priority Fee. +A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover the Layer 1 transaction fees, and any other transaction data fees related to non-Layer 1 data storage, and excluding a Priority Fee and an Execution Fee. + +**Execution Fee:** -An example calculation of such an Execution Fee is: -$$L2\space Gas\space Limit + {L1\space Transaction\space Fee \over L2\space Gas\space Price}$$ +A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover the Layer 2 transaction fees excluding a Priority Fee and a Data Fee. **Fee Price:** @@ -234,7 +231,7 @@ A digitally signed message sent from a Layer 2 account that contains instruction **Transaction Fee:** -The fee in a Layer 2 network or protocol token to be paid by a transaction Originator or Transaction Sender comprised of the sum of a Base Fee, an Execution Fee and a Priority Fee. +The fee in a Layer 2 network or protocol token to be paid by a transaction Originator or Transaction Sender comprised of the sum of an Execution Fee, a Data Fee and a Priority Fee. **Transaction Fee Refund:** @@ -284,7 +281,7 @@ Subsequently, the specification section will define requirements around fee tran ## 2.1 Definition of Transaction Fee and its Components ###### L2TFSPECDEF -This document defines Transaction Fee as the fee in a Layer 2 (L2) network or protocol token to be paid by a Transaction Originator or Transaction Sender comprised of the sum of a Base Fee, an Execution Fee and a Priority Fee. +This document defines Transaction Fee as the fee in a Layer 2 (L2) network or protocol token to be paid by a Transaction Originator or Transaction Sender comprised of the sum of an Execution Fee, a Data Fee, and a Priority Fee. Note that this document defines as Transaction as a digitally signed message sent from an L2 account that contains instructions and data that result in an L2 state transition. Also note that this document defines State and State Transition as follows: @@ -295,12 +292,14 @@ Further note that this document defines Account as a unit that is minimally comp In formula form the Transaction Fee is given as: -**Transaction Fee = Base Fee + Execution Fee + Priority Fee** +**Transaction Fee = Execution Fee + Data Fee + Priority Fee** The different components are defined as follows: -* **Base Fee:** The minimum amount of Gas or an L2 gas equivalent unit of compute and storage consumption required to include a transaction on an L2. -* **Execution Fee:** A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover both the Layer 2 and Layer 1 transaction fees excluding a Base Fee, or a Priority Fee. +* **Execution Fee:** A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover the Layer 2 transaction fees excluding a Priority Fee and a Data Fee. + +* **Data Fee:** A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover the Layer 1 transaction fees, and any other transaction data fees related to non-Layer 1 data storage, and excluding a Priority Fee and an Execution Fee. + * **Priority Fee:** Paid by the Transaction Originator or Transaction Sender to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction, a slot, in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. And that MEV is defined as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. Note that a Transaction Fee has a Transaction Fee Price which is defined in the context of this document as an L2 Gas price or a price of an L2 gas equivalent unit of compute and storage consumption. @@ -353,7 +352,7 @@ In this section we will formulate requirements in the following areas: #### **[R1]** -An L2 Transaction Fee MUST be comprised as the sum of a Base Fee, an Execution Fee, and a Priority Fee. +An L2 Transaction Fee MUST be comprised as the sum of an Execution Fee, a Data Fee, and a Priority Fee. [[R1]](#r1) Testability: Mathematical equality equations can be tested as the sum of the equations elements equaling a desired output. The test is passed if the sum of the elements as inputs is equal to the desired output. If the sum of the equations element do not equal the desired output the test fails. @@ -371,59 +370,59 @@ An L2 Transaction Fee or any of its components MAY BE zero. #### **[R3]** -The setting and/or calculation of a Base Fee MUST be well documented and verifiable. +The setting and/or calculation of an Execution Fee MUST be well documented and verifiable. [[R3]](#r3) Testability: Preconditions: -* The L2 must have a defined Base Fee. -* There must be documentation available for the current Base Fee. +* The L2 must have a defined Execution Fee. +* There must be documentation available for the current Execution Fee. * An L2 instance is up and running. Test Steps: -1. Verify that there is a documented process for setting and/or calculating the Base Fee. -2. Verify that the documentation includes the value, specific formula or calculation used to determine the Base Fee. +1. Verify that there is a documented process for setting and/or calculating the Execution Fee. +2. Verify that the documentation includes the value, specific formula or calculation used to determine the Execution Fee. 3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the calculation. -4. Verify that the documentation is up-to-date and accurate, and that it matches the current Base Fee being charged. -5. Attempt to independently calculate the Base Fee using the information provided in the documentation. -6. Verify that the calculated Base Fee matches the currently charged Base Fee. +4. Verify that the documentation is up-to-date and accurate, and that it matches the current Execution Fee being charged. +5. Attempt to independently calculate the Execution Fee using the information provided in the documentation. +6. Verify that the calculated Execution Fee matches the currently charged Execution Fee. Test Passing Criteria: -* The documented process for setting and/or calculating the Base Fee must be clear and unambiguous. -* The documentation must include the specific value, formula or calculation used to determine the Base Fee, as well as any relevant assumptions or dependencies. +* The documented process for setting and/or calculating the Execution Fee must be clear and unambiguous. +* The documentation must include the specific value, formula or calculation used to determine the Execution Fee, as well as any relevant assumptions or dependencies. * The documentation must be up-to-date and accurate. -* The calculated Base Fee must match the currently charged Base Fee. +* The calculated Execution Fee must match the currently charged Execution Fee. #### **[R4]** -The setting and/or calculation of an Execution Fee MUST be well documented and verifiable. +The setting and/or calculation of a Data Fee MUST be well documented and verifiable. [[R4]](#r4) Testability: Preconditions: -* The L2 must have a defined Execution Fee. -* There must be documentation available for the current Execution Fee. +* The L2 must have a defined Data Fee. +* There must be documentation available for the current Data Fee. * An L2 instance is up and running. Test Steps: -1. Verify that there is a documented process for setting and/or calculating the Execution Fee. -2. Verify that the documentation includes the value, specific formula or calculation used to determine the Execution Fee. +1. Verify that there is a documented process for setting and/or calculating the Data Fee. +2. Verify that the documentation includes the value, specific formula or calculation used to determine the Data Fee. 3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the calculation. -4. Verify that the documentation is up-to-date and accurate, and that it matches the current Execution Fee being charged. -5. Attempt to independently calculate the Execution Fee using the information provided in the documentation. -6. Verify that the calculated Execution Fee matches the currently charged Execution Fee. +4. Verify that the documentation is up-to-date and accurate, and that it matches the current Data Fee being charged. +5. Attempt to independently calculate the Data Fee using the information provided in the documentation. +6. Verify that the calculated Data Fee matches the currently charged Data Fee. Test Passing Criteria: -* The documented process for setting and/or calculating the Execution Fee must be clear and unambiguous. -* The documentation must include the specific value, formula or calculation used to determine the Execution Fee, as well as any relevant assumptions or dependencies. +* The documented process for setting and/or calculating the Data Fee must be clear and unambiguous. +* The documentation must include the specific value, formula or calculation used to determine the Data Fee, as well as any relevant assumptions or dependencies. * The documentation must be up-to-date and accurate. -* The calculated Execution Fee must match the currently charged Execution Fee. +* The calculated Data Fee must match the currently charged Data Fee. #### **[R5]** @@ -433,7 +432,7 @@ The setting of a Priority Fee MUST be well documented and verifiable. Preconditions: -* The L2 must have a defined Base Fee and Execution Fee. +* The L2 must have a defined Execution Fee and Data Fee. * There must be documentation available for the current Priority Fee. * An L2 system must be up and running. * An L2 user is configured. @@ -445,7 +444,7 @@ Test Steps: 3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the determination and setting of the Priority Fee. 4. Verify that the documentation is up-to-date and accurate. 5. An L2 user sets a priority fee for a transaction. -6. Verify that the set Priority Fee is correctly added to the Base Fee and Execution Fee to calculate the Transaction Fee. +6. Verify that the set Priority Fee is correctly added to the Execution Fee and Data Fee to calculate the Transaction Fee. 7. Verify that the calculated Transaction Fee matches the currently charged Transaction Fee for the set Priority Fee. Test Passing Criteria: @@ -453,16 +452,164 @@ Test Passing Criteria: * The documented process for setting the Priority Fee by the L2 user must be clear and unambiguous. * The documentation must include the specific factors or criteria used to determine the Priority Fee, as well as any relevant assumptions or dependencies. * The documentation must be up-to-date and accurate. -* The set Priority Fee must be correctly added to the Base Fee and Execution Fee to calculate the Transaction Fee. +* The set Priority Fee must be correctly added to the Execution Fee and Data Fee to calculate the Transaction Fee. * The calculated Transaction Fee must match the currently charged Transaction Fee for the set Priority Fee. #### **[R6]** +The L1 Gas Price and the L1 gas cost of an L2 transaction posted to the L1 and/or to a Data Availability capability as part of a Data Fee derivation MUST be displayed as part of a Data Fee. + +[[R6]](#r6) Testability: + +Preconditions: + +1. An L2 application is running in a valid environment. +2. Appropriate user credentials are available for accessing Data Fee information. +3. L1 Gas Price, L1 gas cost, and the estimated data size for an L2 transaction are available and valid. + +Test Steps: + +1. Navigate to the L2 application's Transaction display section. +2. Initiate the process to post an L2 transaction. +3. Verify that the L1 Gas Price is displayed as part of the Data Fee. +4. Verify that the L1 gas cost is displayed as part of the Data Fee. + +Passing Criteria: + +* The L1 Gas Price is accurately displayed as part of the Data Fee. +* The L1 gas cost is accurately displayed as part of the Data Fee. + +#### **[R7]** + +The L1 Gas Price calculation or method used in a Data Fee derivation MUST be published and verifiable. + +[[R7]](#r7) Testability: + +Preconditions: + +1. An L2 application is running in a valid environment. +2. The L1 Gas Price calculation or method is accessible. + +Test Steps: + +1. Navigate to the L2 application section responsible for L1 Gas Price calculation. +2. Inspect and identify the calculation or method used in the Data Fee derivation for L1 Gas Price. +3. Ensure that the L1 Gas Price calculation or method is accessible and can be reviewed. +4. Verify that the published L1 Gas Price calculation or method aligns with the documented specifications. + +Passing Criteria: + +* The L2 application section responsible for L1 Gas Price calculation is successfully accessed. +* The calculation or method used in the Data Fee derivation for L1 Gas Price is identified. +* The L1 Gas Price calculation or method is accessible for review. +* The published L1 Gas Price calculation or method aligns with the documented specifications. + +#### **[R8]** + +The utilized L1 Gas Price in an L2 Transaction MUST indicate if it was derived based on a calculation or a Gas Price Data Oracle, or a combination of both. + +[[R8]](#r8) Testability: + +Preconditions: + +1. An L2 application is running in a valid environment. +2. An L2 Transaction is in progress, and the utilized L1 Gas Price is available for verification. + +Test Steps: + +1. Access the details of the ongoing L2 Transaction. +2. Locate and examine the information related to the utilized L1 Gas Price. +3. Verify that the indication specifying whether the L1 Gas Price was derived from a calculation, a Gas Price Data Oracle, or a combination of both is present. +4. Confirm that the indication aligns with the actual method used for deriving the L1 Gas Price. + +Passing Criteria: + +* The details of the ongoing L2 Transaction are successfully accessed. +* The information about the utilized L1 Gas Price is identified and available for examination. +* The indication regarding the derivation method (calculation, Gas Price Data Oracle, or a combination) is clearly present. +* The indicated derivation method aligns accurately with the actual method used for deriving the L1 Gas Price. + +#### **[R9]** + +The L2 Gas Price and the L2 gas cost of an L2 transaction MUST be displayed as part of an Execution Fee. + +[[R9]](#r9) Testability: + +Preconditions: + +1. An L2 application is running in a valid environment. +2. Appropriate user credentials are available for accessing Execution Fee information. +3. L2 Gas Price and L2 gas cost of an L2 transaction are available and valid. + +Test Steps: + +1. Navigate to the L2 application's Transaction display section. +2. Initiate the process to post an L2 transaction. +3. Verify that the L2 Gas Price is displayed as part of the Execution Fee. +4. Verify that the L2 gas cost is displayed as part of the Execution Fee. + +Passing Criteria: + +* The L2 Gas Price is accurately displayed as part of the Execution Fee. +* The L2 gas cost is accurately displayed as part of the Execution Fee. + +#### **[R10]** + +The L2 Gas Price calculation or method used in an Execution Fee derivation MUST be published and verifiable. + +[[R10]](#r10) Testability: + +Preconditions: + +1. An L2 application is running in a valid environment. +2. The L2 Gas Price calculation or method is accessible. + +Test Steps: + +1. Navigate to the L2 application section responsible for L2 Gas Price calculation. +2. Inspect and identify the calculation or method used in the Execution Fee derivation for L2 Gas Price. +3. Ensure that the L2 Gas Price calculation or method is accessible and can be reviewed. +4. Verify that the published L2 Gas Price calculation or method aligns with the documented specifications. + +Passing Criteria: + +* The L2 application section responsible for L2 Gas Price calculation is successfully accessed. +* The calculation or method used in the Execution Fee derivation for L2 Gas Price is identified. +* The L2 Gas Price calculation or method is accessible for review. +* The published L2 Gas Price calculation or method aligns with the documented specifications. + +#### **[R11]** + +The utilized L2 Gas Price MUST indicate if it was derived based on a calculation or a Gas Price Data Oracle, or a combination of both. + +[[R11]](#r11) Testability: + +Preconditions: + +1. An L2 application is running in a valid environment. +2. An L2 Transaction is in progress, and the utilized L2 Gas Price is available for verification. + +Test Steps: + +1. Access the details of the ongoing L2 Transaction. +2. Locate and examine the information related to the utilized L2 Gas Price. +3. Verify that the indication specifying whether the L2 Gas Price was derived from a calculation, a Gas Price Data Oracle, or a combination of both is present. +4. Confirm that the indication aligns with the actual method used for deriving the L2 Gas Price. + +Passing Criteria: + +* The details of the ongoing L2 Transaction are successfully accessed. +* The information about the utilized L2 Gas Price is identified and available for examination. +* The indication regarding the derivation method (calculation, Gas Price Data Oracle, or a combination) is clearly present. +* The indicated derivation method aligns accurately with the actual method used for deriving the L2 Gas Price. + +#### **[R12]** + An L2 MUST provide a capability to estimate a Transaction Fee based on a given Transaction and the current Operating Conditions of the L2. Note that L2 Operating Conditions refer to a combination of the current volume of L2 transactions waiting to be processed on an L2 and all the transactions currently being processed on an L2. -[[R6]](#r6) Testability: +[[R12]](#r12) Testability: Preconditions: @@ -472,6 +619,7 @@ Preconditions: * The current number of transactions waiting to be processed on the L2. * The current number of transactions currently being processed on the L2. * The current available L2 resources (e.g. CPU, memory, network bandwidth). + * The current L2 and L1 gas prices * The L2 must be configured to adjust the Transaction Fee estimation based on varying Operating Conditions. * Different sets of test Transactions with varying levels of complexity and number of transactions must be available. @@ -494,11 +642,11 @@ Test Passing Criteria: * The estimated Transaction Fee must be within an acceptable range of the actual Transaction Fee charged. * The Transaction Fee estimation process must be accurately responsive to changes in Operating Conditions, with higher Operating Conditions leading to higher estimated Transaction Fees. -#### **[R7]** +#### **[R13]** An L2 MUST record and provide access to the Transaction Fee that the Transaction Sender has included in the Transaction when a Transaction has been sent to the L2. -[[R7]](#r7) Testability: +[[R13]](#r13) Testability: Preconditions: @@ -520,11 +668,11 @@ Test Passing Criteria: * The recorded Transaction Fee must be accessible by the user. * The recorded Transaction Fee must match the known Transaction Fee included by the Transaction Sender. -#### **[R8]** +#### **[R14]** An L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been processed by the L2. -[[R8]](#r8) Testability: +[[R14]](#r14) Testability: Preconditions: @@ -546,13 +694,13 @@ Test Passing Criteria: * The recorded Transaction Fee must be accessible by the Transaction Sender. * The recorded Transaction Fee must match or is less than the Transaction Fee submitted by the Transaction Sender. -#### **[R9]** +#### **[R15]** An L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on theL2. Transaction finality in the context of this document is defined as the condition when a transaction can no longer be reverted on an L2. Note that the finality condition will vary by L2, and that L2 finality requirements are outside of the scope of this document. -[[R9]](#r9) Testability: +[[R15]](#r15) Testability: Preconditions: @@ -575,13 +723,13 @@ Test Passing Criteria: * The recorded Transaction Fee must match or be less than the known, estimated Transaction Fee to be charged to the Transaction Sender. -#### **[R10]** +#### **[R16]** If there is a Transaction Fee Refund, an L2 implementation MUST record and provide access to the Transaction Fee Refund when a Transaction has been finalized on the L2. A Transaction Fee Refund in the context of this document is defined as the difference between the Transaction Fee that the Transaction Sender has included in the Transaction sent to the L2 and the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on the L2. -[[R10]](#r10) Testability: +[[R16]](#r16) Testability: Preconditions: @@ -604,11 +752,11 @@ Test Passing Criteria: * The Transaction Fee Refund must be accessible by the user. * The Transaction Fee Refund must match the comparison result of step 4. -#### **[R11]** +#### **[R17]** An L2 MUST provide continuous access to the Transaction Fee, the Transaction Fee components, and Transaction Fee Refund, if applicable, of all Transaction finalized on the L2. -[[R11]](#r11) Testability: +[[R17]](#r17) Testability: Preconditions: @@ -621,7 +769,7 @@ Test Steps: 1. Submit a set of Transactions to the L2. 2. Wait for the L2 to finalize the Transactions using transaction confirmation notifications as finalization confirmations. 3. Query the L2 for a Transaction ID from the set of finalized test transactions. -4. For a given Transaction ID, retrieve the Transaction ID, Transaction Fee, Transaction Fee components (Base Fee, Execution Fee, and Priority Fee), and Transaction Fee Refund (if applicable). +4. For a given Transaction ID, retrieve the Transaction ID, Transaction Fee, Transaction Fee components (Execution Fee, Data Fee, and Priority Fee), and Transaction Fee Refund (if applicable). 5. Verify that the retrieved Transaction Fee, Transaction Fee components, and Transaction Fee Refund (if applicable) match the values recorded in the transaction confirmations. 6. Repeat steps 3. through 5. for each Transaction ID in the set of test transactions at random time intervals during the test for the entire test transaction set. @@ -630,11 +778,11 @@ Test Passing Criteria: * Steps 3. through 5. are successfully completed for every transaction in the test transaction set, otherwise the test fails. -#### **[R12]** +#### **[R18]** An L2 MUST provide a capability that delivers a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on. -[[R12]](#r12) Testability: +[[R18]](#r18) Testability: Preconditions: @@ -660,11 +808,11 @@ Test Passing criteria: In this section, this document discusses the visibility requirements for different L2 Transaction Types and Roles. -#### **[R13]** +#### **[R19]** A Transaction Originator, a Transaction Sender and a Developer MUST be able to view an estimated Transaction Fee and its components before an L2 Transaction is submitted. -[[R13]](#r13) Testability: +[[R19]](#r19) Testability: Preconditions: @@ -675,7 +823,7 @@ Preconditions: Test Steps: 1. The Transaction Originator, the Transaction Sender, and the Developer navigate to the L2 interface and initiate the process of creating a new transaction. -2. The L2 interface displays the estimated Transaction Fee and its components (Base Fee, Execution Fee, and Priority Fee) to the Transaction Originator, the Transaction Sender, and the Developer. +2. The L2 interface displays the estimated Transaction Fee and its components (Execution Fee, Data Fee, and Priority Fee) to the Transaction Originator, the Transaction Sender, and the Developer. 3. The Transaction Originator, the Transaction Sender, and the Developer proceed to submit the Transaction to the L2. Test Passing Criteria: @@ -683,11 +831,11 @@ Test Passing Criteria: * The L2 interface displays the estimated Transaction Fee and its components accurately. * The Transaction Originator, the Transaction Sender, and the Developer are able to review and verify the estimated Transaction Fee and its components before submitting the Transaction. -#### **[R14]** +#### **[R20]** A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after an L2 Direct Transaction has been processed on the L2. -[[R14]](#r14) Testability: +[[R20]](#r20) Testability: Preconditions: @@ -701,7 +849,7 @@ Test Steps: 1. Transaction Sender or Developer submit a Direct Transaction to the L2. 2. The L2 processes the Direct Transaction and charges a Transaction Fee. 3. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been processed on the L2 using the Transaction ID from the transaction processing confirmation notification from the L2. -4. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +4. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee. 5. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. 6. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. @@ -712,11 +860,11 @@ Test Passing Criteria: The test passes if, * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. -#### **[R15]** +#### **[R21]** An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after an L2 Meta Transaction has been processed on the L2. -[[R15]](#r15) Testability: +[[R21]](#r21) Testability: Preconditions: @@ -730,7 +878,7 @@ Test Steps: 1. The Intermediary and Developer submit a Meta Transaction to the L2. 2. The L2 processes the Meta Transaction and charges a Transaction Fee. 3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction processing confirmation notification from the L2. -4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee. 5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. 6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. @@ -740,11 +888,11 @@ Test Passing Criteria: The test passes if, * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Meta Transaction. * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. -#### **[R16]** +#### **[R22]** A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after an L2 Direct Transaction has been finalized on the L2. -[[R16]](#r16) Testability: +[[R22]](#r22) Testability: Preconditions: @@ -756,7 +904,7 @@ Preconditions: Test Steps: 1. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been finalized on the L2 using the Transaction ID from the transaction finalization confirmation notification from the L2. -2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, Priority Fee. 3. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction. 4. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. @@ -766,11 +914,11 @@ Test Passing Criteria: The test passes if, * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction. * The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. -#### **[R17]** +#### **[R23]** An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after an L2 Meta Transaction has been finalized on the L2. -[[R17]](#r17) Testability: +[[R23]](#r23) Testability: Preconditions: @@ -784,7 +932,7 @@ Test Steps: 1. The Intermediary and Developer submit a Meta Transaction to the L2. 2. The L2 processes, and finalizes the Meta Transaction and charges a Transaction Fee. 3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction finalization confirmation notification from the L2. -4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee. 5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. 6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account. @@ -811,7 +959,7 @@ Preconditions: Test Steps: 1. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been finalized on the L2 using the Transaction ID from the transaction finalization confirmation notification from the L2. -2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee. 3. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 is equal to or less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction. 4. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account. @@ -839,7 +987,7 @@ Test Steps: 1. The Intermediary and Developer submit a Meta Transaction to the L2. 2. The L2 processes, and finalizes the Meta Transaction and charges a Transaction Fee. 3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction finalization confirmation notification from the L2. -4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Base Fee, Execution Fee, Priority Fee. +4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee. 5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction. 6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account. From d6b8dd0b20ba0cd8506abf947fd79128d7db9652 Mon Sep 17 00:00:00 2001 From: Therecanbeonlyone1969 Date: Wed, 13 Dec 2023 08:12:25 -0800 Subject: [PATCH 24/24] Minor edits in R6 and R9 based on L2 WG discussion on 12/13/23 --- .../l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md index 513a3f5..a28612f 100644 --- a/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md +++ b/workitems/l2-transaction-fees/l2-transaction-fees-v1.0-psd01.md @@ -457,7 +457,9 @@ Test Passing Criteria: #### **[R6]** -The L1 Gas Price and the L1 gas cost of an L2 transaction posted to the L1 and/or to a Data Availability capability as part of a Data Fee derivation MUST be displayed as part of a Data Fee. +The L1 Gas Price charged by an L2 and the L1 gas cost of an L2 transaction posted to the L1 and/or to a Data Availability capability as part of a Data Fee derivation MUST be displayed as part of a Data Fee. + +Note that the L1 Gas Price charge by an L2 for an L2 transaction may deviate from the L1 Gas Price o the L1 at the time of the L2 transaction. [[R6]](#r6) Testability: @@ -531,7 +533,7 @@ Passing Criteria: #### **[R9]** -The L2 Gas Price and the L2 gas cost of an L2 transaction MUST be displayed as part of an Execution Fee. +The L2 Gas Price as charged by an L2 and the L2 gas cost of an L2 transaction MUST be displayed as part of an Execution Fee. [[R9]](#r9) Testability: