0064 XLS - 64d: Pseudo-Account

[Tapanito]

    
Title:        Pseudo-Account
Revision:     1 (2024-04-05)

  Authors:    
  Aanchal Malhotra
  Vytautas Vito Tumas

Affiliation: 
  Ripple

Pseudo-Account

Abstract

In this document, we propose a standard for a pseudo-account, an AccountRoot object that can be associated with one or more other ledger entries. This feature allows one to link an account with multiple ledger entries to track XRP and Token Balances or issue Fungible Tokens on behalf of the linked ledger entries.

1. Introduction

The XLS-30 specification introduced an AMMID field to the AccountRoot ledger entry. It associates a pseudo-account with an AMM instance to track XRP and Token balances in the pool and issue LPTokens on behalf of the AMM Instance. However, the AMMID DOES NOT allow us to associate the AccountRoot with other ledger entries.

This proposal addresses this limitation by introducing a new PseudoOwner field to the AccountRoot that allows linking the object with one another ledger entry. Implementing this specification will deprecate the AMMID.

Furthermore, the proposal introduces minimum requirements for any protocol creating a pseudo-account.

2. Changes to the AccountRoot

The PseudoOwner field links the AccountRoot object with one ledger object entry..

2.1 New fields

---

Field Name	Required?	JSON Type	Internal Type	Description
PseudoOwner	No	string	HASH256	An ID of a ledger object with which the AccountRoot is associated.

---

3. Creating a pseudo-account

The address of the AccountRoot must be randomized to prevent users from identifying and funding the address before its creation. The protocol that creates an AccountRoot must ensure the account address is unoccupied.

The AccountRoot object for a pseudo-account MUST have the following settings:

• lsfDisableMaster enabled to ensure that no one can control the account directly and send transactions on its behalf.

• lsfDepositAuth enabled to ensure that the only way to add funds to the account is by using a deposit transaction.

The unique ID of the AccountRoot object, a.k.a. AccountRootID is computed as follows:

• for (i = 0; i <= 256; i--)
  • Compute AccountRootID = SHA512-Half(i || Parent Ledger Hash || PseudoOwner)
  • If the computed AccountRootID exists, repeat
    • else, return AccountRootID

4. Special Creation Cost

A transaction that creates a _pseudo-account_ MUST charge a higher than usual transaction fee to deter ledger spam. The transaction MUST destroy at least the incremental owner reserve amount, currently 2 XRP.

[dangell7]

Why do you need LedgerEntries? Can you not just use the ownerDir?

[mvadari]

The owner directory can have many additional objects in it. For example, an AMM account has one AMM object and lots of trustlines.

[gregtatcam]

There are a number of cases where AMMID is used as a flag to indicate that the pseudo-account is AMM's account. Once AMMID is replaced with PseudoOwner, all these checks need another call to check if AMM exists for this ID. This level of indirection might be ok for transactions like Clawback, CreateCheck, or Escrow, which are not submitted at high frequency. But it might impact Payment transaction throughput. I think it makes sense to have the associated ledger object type.

[ximinez]

Unpopular opinions:

1. If we're going to include a ledger object type field for the PseudoOwner, then we may as well instead use separate fields for each pseudo-owner object type. Reasoning:
   1. It will actually take less space in the Account Root, because only one of those fields will be populated at a time (this should be enforced by an Invariant). Optional fields take no space on disk or the protocol message, whereas a type field will take a non-zero amount of space.
   2. There is basically no overhead to read multiple fields from the Account Root object compared to reading another ledger object off of disk.
   3. I suspect that many transactions that need to check for a pseudo-owner are not going to need to check for all possible pseudo-owners. (e.g. Don't create a trust line to a X, but Y and Z are ok.) I also suspect that many of the checks will be a simple is it a pseudo-account and not care about the type at all, or the checks can be enforced by other existing functionality. (e.g. If we don't want trust lines created to an X pseudo-account, set the disallow trust lines flag on the account when it's created.)
   4. A minor benefit will be that there will be no need to deprecate AMMID.
2. If we use a single PseudoOwner without a type field, I suspect that caching will negate most or all of the real world overhead of loading the pseudo-owner from the node store to check its type. e.g. If 1,000 payments all touch the same AMM in a relatively short amount of time, then only the first one to load the AMM will actually hit disk. The remaining will just read it from cache, which has negligible overhead. Similarly, if a transaction modifies the same AMM object, it'll also be in cache.

Speculation aside, the only way to really be sure is to implement a proof of concept and test the different options to see which has the best performance properties.

[mvadari]

One additional advantage to having an AMMID-like concept is you can easily check what kind of pseudo-account an account is - e.g. AMM vs loan - without needing to iterate through this list.