Charging Users and Value Reconciliation

[GabrielePicco]

Initial Design for Charging Users and Value Reconciliation

Requirements

We need to:

1. Charge users for compute (transactions CU).
2. Charge users for allocated space.
3. Eventually charge users for fees the validator incurs when performing transactions on the base layer.
   • Investigate if commits/undelegation CPI could increase transaction CU costs, so this is naturally covered by point 1.
   • Determine who should be charged for periodic updates if they are maintained.

Problems

To provide context, these are some use cases we should consider while designing a solution. Ideally, we should support all of them:

1. General Case: A node wants to charge fees in SOL (a fraction of what it would cost on the base layer) and profit from the difference between fees - (costs of infra + commits + security committee + DA).
2. Gasless Transactions: A node operator may choose to remove transaction costs for users and cover the costs of commit/undelegation and resizing themselves. An example of this is Zeebit, which aims to abstract fees as it monetizes through casino games. In this scenario, the node could process only transactions from whitelisted programs (e.g., programs they developed).
3. Alternative Payment Tokens: An entity (e.g.: StarAtlas) want users to pay fees with a different token (e.g. Atlas). See octane: Octane GitHub.

Scenario 1

Assumptions

• Lamports can never "exit" the validator. We don't set lamports resulting from an ER session execution, nor do we perform value reconciliation (i.e., we only commit the data diff of a PDA without updating lamports).
• The only exception is when finalizing/undelegating an account, where data is copied to the original accounts, and the lamports of a PDA need to be increased to make it rent-exempt. (The commit and commit record PDA will be closed, and rent is recovered for the validator.)
  • Even in this case, lamports are not exiting the ER, but someone (currently the validator) needs to pay for the difference.

Possible ways to make someone else pay and prevent any extractive behavior from an attacker targeting the validator keypair:

1. FeeSpace PDA: Have a FeeSpace PDA for each program/ER session to pay the lamports difference to make it rent-exempt. Developers could top up the FeeSpace and set up instructions so that whenever a resize occurs, the FeeSpace has enough lamports; otherwise, the finalization will fail (developers know when an account will increase in size and can decide who pays for it).
2. Undelegation CPI Payer: If undelegation is always done through an undelegation CPI in the ER, whoever runs it can specify a Payer PDA (on the base layer) that will be charged for resizing. This could be optional if no resizing is expected.
3. Cost Splitting: Split the costs of resizing accounts across anyone who updates them. This would require a way to track and charge, which might be challenging to implement.
4. No Resizing: Disallow resizing accounts entirely.

Description

If the assumptions hold, point 2 in the requirements is addressed, and we can focus on implementing a solution for charging users for compute.

Proposed Solution for Charging Users

• Users have a FeeVault PDA, which is a PDA of the delegation program. The FeeVault PDA holds SPL tokens.
• The validator specifies pricing functions through parameters saved in a PDA on the base layer. An example could be (mint_fee_token, ratio to lamports).
• Validators can create an instruction RequestFees to charge users. This instruction could be part of the delegation_program and would transfer tokens from the FeeVault PDA to the validator's identity keypair (on the base layer) once approved. The charge amount is determined using the pricing function. This could be associated with a commit record and approved by the committee along with the state.

Notes:

• This solution requires tracking how much to charge each user (currently, we natively use lamports of system_program owned accounts with 1000 - current lamports).
• It requires periodically creating the charge transaction. Once charging is periodically approved on the base layer, the "fee_counter" in the ER needs to be reset (with the current implementation, set back to 1000).

Scenario 2

Assumptions

• Lamports of delegated accounts are set when the account is committed. On finalization/undelegation, the lamports will be transferred to the original_account.
• Only "transfer of lamports" between delegated accounts is allowed; any other lamports movement will fail (except for paying fees and space). From another perspective, system_owned accounts can never increase the lamports in the ER.
• For each fee-payer in the ER, the initial lamports balance is projected from a FeeVault PDA (instead of the current 1000 initial value).
• Node operators can configure how to charge for compute (e.g., reducing CU cost by 1/10). Space allocation costs remain invariant.
• This configuration is published on-chain (PDA with parameters) so that the security committee can reproduce the cost calculation of the ER session.

Notes

• This scenario may require significant runtime changes to enforce assumption 2.

Proposed Solution for Value Reconciliation

• Value reconciliation requires that lamports are moved from a Bank PDA into the committed PDA.
  • Example 1:
    • Account A: lamports = 100 → commit(a): lamports = 150
    • Transfer 50 lamports from Bank PDA to A.
  • Example 2:
    • Account B: lamports = 100 → commit(a): lamports = 50
    • Transfer 50 lamports from A to Bank PDA.

Proposed Solution for Charging Users

• Users are charged natively by the runtime, which accounts for compute and allocated space, where allocated space costs exactly what it would on Solana.
• Users could be charged with the same mechanism as in Scenario 1. Lamports of accounts that have been fee-payers in some transactions (chargeable accounts) would still act as a reliable counter of how much to charge (including space costs). The accounts will be automatically charged for account resizing as per runtime. The main difference is that fees are accrued in the Bank PDA.

Scenario 3

Assumptions

• Lamports of delegated accounts are set when the account is committed. Upon finalization/undelegation, the lamports will be transferred to the original_account.
• For each fee-payer in the ER, the initial lamports balance is projected from a FeeVault PDA (instead of the current 1000 initial value).
• Node operators can configure how to charge for compute (e.g., reducing CU costs by 1/10). Space allocation costs remain invariant.
• This configuration is published on-chain (PDA with parameters) so that the security committee can reproduce the cost calculation of the ER session.

Notes

• In this scenario, users can transfer native lamports between each other.

Proposed Solution for Charging Users

• WIP

Proposed Solution for Value Reconciliation

• WIP

[thlorenz]

Steps to play in an Ephem Validator

1. Player requests on mainnet to be added to a game inside the validator
2. Chain program creates escrow for player PDA which holds enough lamports to cover prospected cost
   2.1.a. Player will be charged for the escrow amount
   2.1.b. Alternatively another account can be used to pay for the escrow, in that case the escrow record shows that the money left at closing should be transferred there
   2.2. The escrow is delegated to a program that can determine how/when to close the escrow
3. Player enters the ephemeral validator
   3.1. The escrowed account is cloned into our validator
   3.2. The account data and lamports are stored under the public key of the player that entered
4. The player now performs transactions in the ER using the cloned account as normal
   4.1. The player is charged as normal for transactions and account resizes, etc.
5. The player account is committed back (using the escrow address) regularly to reflect lamports spent/gained in the ephemeral
   5.a. Any money gained will be credited to the validator bank PDA
   5.b. Any money lost will be debited from the validator bank PDA
6. The player leaves the ephemeral validator
   6.1. We ensure the latest state/lamports are commmited to the escrow account
   6.2. The escrow account is closed and the remaining lamports are transferred to the player or whichever other address is specified

Nuances around 2.

A program can decide how an escrow can be created to play inside a specific validator/program.
This can entail the following conditions/extra steps performed:

• a) the player has to hold a specific token
• b) the player needs to escrow a certain amount of tokens into another account that the program controls
• c) a PDA of the player, i.e. its game account has to meet certain conditions, i.e. reached a specific level in the game

For b) another account would fund the actual escrow, but when that is closed the token escrow
is closed as well and the tokens that the player should pay or won are tallied up as part
of that operation.

NOTE: this requires that the undelegation goes through the developer's program, i.e. via a CPI
to the program performing the undelegation of the escrow, that way the extra steps/conditions
can be performed/ensured.

[GabrielePicco]

I generally agree with this description of the UX flow, but I don't understand if there is any significant difference compared to the solution proposed in Scenario 2. Is there?

[crypto-vincent]

My thoughts on the proposed approaches:

Note

All the above scenario only solve 1 problem: how to manage lamports in the validator
There is another issue that was discussed that should be handled separately in my opinion: Integration of SPL tokens with the magic block engine. IMO we should NOT attempt to solve both problems here. We can handle those separately

Scenario 1

In this scenario, the lamports never "exit" the validator. I believe this is a huge problem that will have many foreseen and unforseen consequences.

Example where that would be a problem:

Vincent sends lamports to Gabriele in exchange for Ammunition:
 - The ammunition can exit the validator
 - But the lamports cannot
 - Therefore I can print ammunition infinitely without incuring any cost

We could "maybe?" still make this work with figuring out who's gonna pay for resize and commits while forcing everything to NOT use lamports somehow but at a very high complexity cost that is sub-optimal in my opinion.

Scenario 2

First of all quick note that I don't think that lamports should be set when the account is commited, any lamport reconcilation should happen at finalize/undelegate time IMO.

That would be dangerous because:

- User1 has 100 lamports in the validator
- User1 commits to main-chain
- User1 sends 50 lamports to someone else
- A transaction on main-chain verify that User1 have 100 lamports (INVALID!)

I don't understand the difference between scenario 2 and 3, is the only difference that the resize/commits is being paid by a central "Bank" account?

Scenario 3

This is in my opinion the most realistic and feasible option.

I would describe this implementation as "lamports in the validator are real lamports" because:

• You have to delegate/lock/bridge real lamports for the lamports to appear in the validator
• This keeps the validator maximaly compatible with the base solana smart contracts
• This allows us to pay for commits/resize directly like you would on solana without having to worry about it
• You would only be able to get back your lamports once you undelegate your lamports from the validator (so it is fully verified)

This case is superior because it covers all other usecases:

• We can charge payers individually
• The smart contract could also offset all costs to a central bank if it decides to
• Users can transfer SOLs between each other
• Transactions can still be valid when manipulating SOLs
• So it almost looks like a faster solana

[GabrielePicco]

To me, there are actually three high-level problems we are trying to solve (related but not identical):

1. How and with which currency do we charge users for compute (CU) used in the ER?
2. How do validators get reimbursed for the costs they are sustaining (e.g., transaction fees on the base layer and possibly resizing)?
3. How are the movements of lamports in accounts within the ER reconciled on the base layer?

I see "how to manage lamports in the validator" as a sub-problem of these.

Scenario 1

With the provided assumptions, the example you mentioned should fail:

• Vincent has an account V (owned by system_program with an associated private key).
• Gabriele has an account G (owned by system_program with an associated private key).
• Vincent cannot send money from V to G; both V and G are undelegated accounts. Sending lamports from V to G would require changing the state of both V and G, which should fail according to the runtime spec (side note: this currently works)

Notes:

• Users could still send/exchange tokens like WSOL or any other SPL tokens in the ER through a wrapper program.
• I'm not sure I fully understand your example, where "Vincent sends lamports to Gabriele in exchange for Ammunition" requires a custom program and a delegated PDA to perform the exchange. I'm happy to discuss this further.
• I think Scenario 1 implies a potentially significant restriction, but problem 3 (mentioned above) disappears. We just have to solve problems 1 and 2, which seems simpler to me. Taking this to an extreme, a super restrictive version of this would disallow resizing, leaving only problem 1 to solve (though I'm not suggesting we go in this direction).

Scenario 2

Questions:

• At commit time, we create a temporary PDA that represents the proposed state of an account A; let's call it A'.
  Example: A = {[0, 2], lamports = 10}, A' = {[0, 2, 4, 6], lamports = 20}. Who is paying for the temporary account A' (transaction fees + space allocation) at commit time?
  Context: Currently, upon finalize, A' is closed, and we update the state, transfer the necessary lamports to A from A', and return any remaining lamports to the validator on the base chain.

• Related to:

  "A transaction on the main chain verifies that User1 has 100 lamports (INVALID!)"

  Unless the transaction on the main chain checks the lamports in the FeeVault PDA associated with User1 (from which we project initial lamports in the validator), User1's lamports on the main chain would still be correct, assuming we don't allow un-escrowing from the FeeVault before the session ends. We can discuss this further; I may be missing something here.

Scenario 3

Scenario 3 is similar to Scenario 2, except for the missing assumption: users can transfer native lamports between each other in the ER.

• An implementation of Scenario 3 could be very similar to Scenario 2, though with some complications as we have to track/commit all "special" ER fee payers' accounts (system_program owned in the ER, but with balances projected from the FeeVault PDA).
• Note that this is a "special commit." Assuming the user explicitly wants to un-escrow from the FeeVault to their main wallet on the main chain at some point, there could be a custom un-escrow program in the ER with an instruction settle_account that internally commits/undelegates using the normal process (all commit/undelegation actions need to go through CPI).
• This adds an explicit transaction that external users must call to commit/undelegate the FeeVault PDA state.
• Many potential attacks come to mind where a user who lost a session wouldn't do this. In my opinion, the validator should be responsible for proposing FeeVault reconciliation.
• We need to come up with a concrete implementation and flow example for Scenario 3, but I currently think it is more complex than Scenario 2.
• I agree that solving for Scenario 2/3 would be more general.

Notes:

• "Lamports in the validator are real lamports" — to me, this means that every lamport in the validator is backed by real lamports on-chain.

If lamports in the validator are used to:

• Pay for CU (transaction fees),
• Pay for space (only resizing delegated accounts, as creating accounts is disabled in the ER),
• And lamports can be transferred between accounts,

This implies that CU costs are always paid in lamports/SOL. Currently, I cannot think of how we could address Problem 3 (i.e., using other SPL tokens for paying compute/CU) in the future, but I'm open to further discussion and potential solutions.

• The only option I can think of is to not charge lamports for CU in the ER, keep track of consumed CU per user, and then charge a specific amount of a given token per CU at some point afterward (TBD when/how).

[GabrielePicco]

Closing and continuing in #122