0023 XLS-23d: Lite Accounts (lower reserve, less features) #56
Replies: 6 comments 9 replies
-
|
Very cool proposal. I have a couple of questions:
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
This proposal text is slightly out of date. There is indeed an Iwill update the proposal to reflect this and the reduction in DeleteAccount fee. Good suggestions. Preliminary code is here, still being debugged. https://github.com/richardah/rippled/tree/liteaccounts We had originally also put in some only loosely unrelated trustline restriction features, however those will probably be going into their own amendment now. If you find something in code related to trustlines that’s why :) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the update |
Beta Was this translation helpful? Give feedback.
-
|
Very interesting suggestion for a solution to a commonly discussed topics: whether to lower reserves or not. It could be solved with hooks and destination tags as has been suggested earlier, with a hook keeping score of who owns what. A “native” solution like this is definitely easier. Some questions for further discussion:
|
Beta Was this translation helpful? Give feedback.
-
|
Xumm Support has closed/resolved over 3,200 tickets since 2020-01-01. There is no tracking by issue topic but, as someone who averages several tickets per day, this is one of the most common pain points. Most are satisfied about the why once it is explained but there are still a non-trivial amount whose response ranges from indignation to anger with some actually accusing us of scamming them. Reducing the reserve requirements will certainly turn down the volume on the issue but, as long as people are expressing surprise, we are not doing a good enough job of communicating on this topic. Agree with the second point re; additional complexity triggering new forms of confusion (and support tickets) but that is the burden of innovation. "making the total reserve dynamic according to how many features are used" Brilliant if done natively. |
Beta Was this translation helpful? Give feedback.
-
|
So, on a first, quick skim, it looks like the size of a "lite account" is no smaller than the size of a regular account, so these are lite in name only. I think that if we're going to implement lite accounts we should, instead, try to reduce the minimum size of such accounts. Unfortunately, with the exception of making the I've given this issue a lot of thought because I tried to draft a standard for "lite accounts" in the past, and my conclusion was that any effort to overload the existing So here's what I would do:
All accounts, lite or not, require an account reserve. We keep the current code for that, and the network can decide on what that reserve should be by voting). I think it should be reduced to at most 10 XRP. An account with the An account with the One alternative here might be do away with "lite account" flag entirely and eliminate the "account reserve", using only the "incremental reserve" (this can be done by simply voting to set the account and incremental reserves to the same value). An account that owns any object is charged a reserve for actually having an owner directory. This would require a bit of extra work: a new flag which determines whether the existing Sponsored accounts are a great idea, but the proposed implementations has some weird corner cases. Maybe they're a problem and maybe they aren't. The primary concern is that the requirement to store the sponsor's address bloats the object: a sponsored lite account, as defined in this spec is 23 bytes larger than a "normal" account. I don't have a good solution to this, but I'd appreciate thoughts on it because I think sponsored wallets are a neat idea. |
Beta Was this translation helpful? Give feedback.
-
|
Sponsored accounts have use cases that span both commercial and specific groups (need based) that could benefit from them. The lower account reserves do make them viable from the context of economies where the wallet reserve (even if lowered) still pose a barrier to entry. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, I agree. I have no problem with making it possible for accounts to be sponsored; I just think that there are a lot of corner cases with the proposed implementation, in addition to the bloating I described. We should think those through carefully and investigate other options. |
Beta Was this translation helpful? Give feedback.
-
|
https://developers.stellar.org/docs/glossary/sponsored-reserves/ I think this is similar , but your proposal limited to activate account only. |
Beta Was this translation helpful? Give feedback.
-
An alternative proposal for "Lite Accounts"The original intention behind the account reserve was to act as as a deterrent to the creation of new accounts with the intention of spamming the ledger, since at the time accounts could not be deleted and the entire reserve was, therefore, unrecoverable. As IntroductionAccounts on the XRP Ledger are stored inside Specifically, as of the time of this writing an
Thus, an account with all the bells and whistles enabled may exceed 500 bytes, although most accounts will be much smaller and likely under 100 bytes. Lite AccountsThis alternative proposal makes several minor changes to the way accounts are structured and by which reserves are calculated. Specifically, this proposal recommends that the Unlike Modifications to
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you @nbougalis! I feel the the proposed modifications could (should) be implemented, not as part of Lite accounts, but simply to optimize XRPL ledger size. With the proposed changes (summary below) I believe most reasons to propose Lite Accounts do no longer apply. Sponsorship then could be another discussion (I agree), although at the mentioned 1 XRP per account (reserve) I doubt if sponsorship is required any time soon based on use cases requiring sponsorship. Something to possibly revisit later.
The one thing not covered (makes sense, we're talking about lite accounts) is the size of Trust Lines, at 1 XRP per account & 1 XRP per trust line, I feel both should be optimized. Trust Lines even consume more ledger space than Accounts. ❗ One thought about base & incremental reserve at 1 XRP: an |
Beta Was this translation helpful? Give feedback.
-
|
I agree re: both the reserve and the comment about trust lines. Unfortunately, tackling trust lines in a way that makes sense is more difficult than this change and must require a bit of hoop-jumping. |
Beta Was this translation helpful? Give feedback.
-
|
This is a great proposal to resolve the "account reserve acting as a barrier of entry to new users" issue. This is debatable, but don't you think lite accounts' account reserve is too low? (0.1 XRP as of now I propose the account reserve for lite accounts to be Reasoning: As the network grows in terms of users, the account reserve for full accounts will gradually be lowered. Adding to this, the network will increase in load as the result of the increase of new users utilizing the network. Not to mention, the ledger's resources is finite, this is not cost effective because only a small amount of XRP will be burnt/froze compared to the resources and load used in the network which is not worth while. If I'm not wrong, the network profits economically by burning a fair amount of XRP. Hence in order to minimize the poor use of the ledger's resources in the future, it would be best that we keep a stable yet economically affordable for the global use of the ledger. |
Beta Was this translation helpful? Give feedback.
-
LiteAccounts Amendment
By @RichardAH, @WietseWind
Introduction
The XRP Ledger is a fast consensus-based blockchain which, unlike competing chains, maintains its user's balances as persistent state rather than as a graph of unspent transaction outputs. This imposes unique per-account storage costs on the network. These costs are passed on to the user.
The cost of creating an account on the ledger is, at time of writing,
5 XRPwith an additional lockup of15 XRP(which is redeemable if the account is later deleted). Collectively this is known as the Account Reserve. It has been argued the Account Reserve acts as a barrier to entry for new users and remains a major impedement to the expansion of the ecosystem.The
AccountRootledger object represents the authoritative state of an XRPL account.It contains the following fields:
^^ Part of this proposal
An XRPL Account which owns no on-ledger objects (i.e: does not have any trustlines, escrows, offers, etc.), does not specify a
regular keyand does not set any of its other optional fields has a serialized size of87 bytes(excluding storage overhead.)We propose that any such minimal account root imposes such a small burden on the ledger that it should be able to be treated differently to full account roots.
Lite Accounts
We propose that a lite account is an XRPL Account with:
asfLiteAccountaccount flag set, and,sfSponsorfield set.Lite accounts have an Account Reserve of
1/5ththe ledger's object reserve (i.e.1 XRPat time of writing.)A lite account cannot:
AccountSeton any fields exceptsfSponsorandsfFlagsNew Fields and Flags
The following changes are made to fields and flags.
sfSponsor— a new optional AccountID field on the acount root which indicates that another account owns the reserve for the account root.tfSponsor— a new transaction flag that indicates the intent of the sender to create and sponsor a new lite account.asfLiteAccount— a new account flag that can be set and unset subject to certain conditions, which indicates that the account is a lite account and subject to the restrictions of a lite account.These are explained in further detail below.
Sponsorship
Lite accounts may be sponsored. Sponsorship provides that another account pays the account reserve and, subject to conditions, is entitled to recover the entire account reserve should the lite account be later deleted. Full accounts cannot be sponsored, only accounts with
asfLiteAccountflag can be sponsored.To sponsor a new account creation:
A
ttPAYMENTtransaction is created and successfully submitted, which:tfSponsorflag, andXRPas the lite account reserve.There is no way for an already established XRPL account (full or lite) to subsequently become a sponsored account. Sponsorship can only occur through account creation.
Reclamation
A sponsor is entitled to reclaim the Account Reserve on a lite account (for which they are the sponsor) subject to certain conditions:
Scenario 1: AccountDelete
If a sponsored lite account:
tesSUCCESSon a validated ledger for more than1 millionledgers,Then the account's sponsor may recover the Account Reserve via an
AccountDeletetransaction. The spsonsor also receives the remaining balance in the lite account.The
AccountDeletetransaction specifies the lite account as thesfAccountfield but is signed by the sponsor.Scenario 2: AccountSet
If a sponsored lite account, at any time:
Then the account's
sponsormay recover the Account Reserve via anAccountSettransaction that clears thesfSponsorfield.The
AccountSettransaction specifies the lite account as thesfAccountfield but is signed by the sponsor and can only be used to delete thesfSponsorfield.Doing so results in a balance mutation on both the lite account and the sponsor account to reflect the return of the lite Account Reserve.
Upgrading
The owner of a lite account can upgrade their account twice:
Scenario 1: Removal of Sponsor
The owner of a lite account may unilaterally unsponsor his or her own account by:
AccountSettransaction that clears thesfSponsorfield.Doing so results in a balance mutation on both the lite account and the sponsor account to reflect the return of the lite Account Reserve.
Scenario 2: Full Account
The owner of an unsponsored lite account may upgrade the account to a full account by:
20 XRP)AccountSettransaction that clears theasfLiteAccountflag.Downgrading
The owner of a full account may opt to downgrade their account to a lite account by:
AccountSettransaction that sets theasfLiteAccountflag. This action frees up the difference between the full Account Reserve and the lite Account Reserve.Deletion of Lite Accounts
The owner of a lite account may delete their account subject to certain conditions:
Scenario 1: Send all to Sponsor
If the lite account is sponsored then the owner of the lite account may:
AccountDeletetransaction, whichsponsoras theDestinationfieldScenario 2: Upgrade and Delete
If the lite account is sponsored then the owner of the lite account may upgrade their account to an unsponsored account.
Once the lite account is unspsonsored, the user may proceed with a normal
AccountDeleteoperation (with the proceeds going to any desiredDestination).Beta Was this translation helpful? Give feedback.
All reactions