I've been thinking recently about how we can benefit from the account abstraction for the cases that would normally be handled by 'anti-patterns' like unlimited persistent allowances (e.g. subscriptions), while still benefitting from the existing accounts and corresponding software.
here is my writeup about this: https://docs.google.com/document/d/1GV-kRdEwc8xWyFTtyNE1JEz3im3STmbgVn8XYPzkBG0/edit#
TL;DR is that I propose adding a way to delegate the account logic to a different account contract, which would allow to e.g. extend the capabilities of the classic stellar accounts without modifying the protocol. it's not dissimilar to e.g. adding one more full-weight key to your classic account for the backup purposes, but here the added account may be actively used to perform various tasks
#Extensible accounts
shell atlas
this probably is not a critical feature and we probably could be ok without it, but I'm curious about the opinions on this and want to maybe gauge some interest
cc @halcyon tinsel @willow pier @hot bough
willow pier
I have a question about this statement in Approach 1:
Schedule a cron job that performs a withdrawal via a simple
xferoperation of the USDC token using the user address and the newly created custom account asdelegatefor that address. No signatures are required to do so
Do you have more details on how that would work? The cron job would call a function in the custom account via InvokeHostFunctionOp and because of the delegation the call does not require a signature and the transfer will go through? I am trying to understand how the cron job would authenticate.
shell atlas
the cron job would just call token.xfer(user_address, target_address, amount) directly. in the signature payload for the user_address they would use delegate_address set to the delegated extension contract address. at the execution time, if the delegation is valid, we will call __check_auth of the delegate contract that supports subscriptions. the implementation can skip the authentication part (and expect signature to be empty) and only verify that the target_address indeed has a subscription and can't overspend.. FWIW the __check_auth implementation is independent of this proposal - the user could just have a funded custom account with the same implementation. the goal is to allow using it without explicit funding and without adding the persisted unlimited allowance to the token (like I proposed in the token discussion that led to this idea)
here for simplicity anyone can call the xfer (as the subscription invariant won't be broken), i.e. only the target_address can receive token. but probably in reality for the sake of accounting the delegation should happen in the scope of some contract that only the subscription service owns and then they would run something like execute_subscription(admin: Address, subscriber: Address) that calls subscriber.xfer(..) - subscription invariant still holds, but now xfer can't be called outside of the specific contract that does execute_subscription
(or events could be used to avoid auth... basically there are different ways to implement this; the main thing is that the withdrawal logic is governed by the contract that belongs to the user and not by the third party)
willow pier
Ok that's great explanation thanks.
I agree that having a scope/allowlist may be better. I agree that in this subscription example the fact that anyone can call the xfer should not be a problem but I would not be surprise if a malicious user finds a way to leverage this for an attack.
shell atlas
this is really contingent on the account implementation - if you wanted a feature like this without the extension/delegation feature I propose, you'd have exactly the same risk scope
willow pier
I think the delegation is a good idea. I was relating to your comment:
in reality for the sake of accounting the delegation should happen in the scope of some contract that only the subscription service owns
I think that's a good idea to have this feature supported. This needs to be implemented at the protocol level right?
shell atlas
yeah, it needs to be at the host level at least to some degree; either generically supported for all the accounts (option 1) or just as a feature supported only for the classic stellar accounts (option 2)
I'd imagine the amount of work is roughly the same, so I'd rather go with 1
willow pier
+1 for 1
hot bough
From a cursory skim, and not really sure I understand the issue. But approach 2 seems like the better option.
I don't understand why we wouldn't want to encourage custom account-abstraction implementations. I was under the impression that was the entire point of account-abstractions.
For example, just yesterday there was an interesting project that came up building on account abstractions: https://github.com/bankisan/zkShield
radiant karma
Wanted to make sure I understood what was being proposed. This is only attempting to essentially provide a delegation extension for all accounts (contracts, keys, and Stellar Accounts)? Where delegation basically means require_auth will pass for whatever address you delegate as an "extension" if they are signing for calls to a contract in the set of context_contracts?
shell atlas
yeah
1 proposes a generic way of doing so independent of account implementation, while 2 proposes to only add the support for the classic accounts (as there is no extension functionality for them)
I don't understand why we wouldn't want to encourage custom account-abstraction implementations.
that's not about discouraging the custom implementation, but about allowing to benefit from the account abstraction without requiring the users to maintain multiple accounts (they can still opt for that approach though; again, we're not restricting anything). this is especially useful for supporting signature-less operations
basically the inspiration for this is something like 'sign in with Google/Microsoft/Facebook' on the websites - instead of going through the daunting registration and sign in process you can use the same account on multiple sites (the analogy is, of course, imperfect, but I hope that helps to understand my intentions here)
radiant karma
Figured I'd add opinions to the stellar dev discussion in here due to hitting the time limit -
I've gone back and forth on if "account A can sign on behalf of account B for calls to contracts in set C" is safer or more efficient than persistent allowances.
Unfortunately, no custom logic can exist around the expiration and/or usage of allowances. If the goal is to solve the subscription use case, some contract needs to be written that the user has to approve (either I delegate a subscription extension signing powers to USDC, or I increase my allowance to some set amount for a subscription implementation). Only then, whatever custom logic that defines the subscription (say, $10 a month), can begin transferring money away from the user.
In both cases I'm stuck trusting the subscription implementation, be it an extension or just a generic contract, and they feel like basically equally complicated. If it has a fatal bug, the user has to complete a transaction to remove this trust, which in the worst case could be frontrun (in the case of an allowance, damages would max out at whatever the allowance balance was).
shell atlas
In both cases I'm stuck trusting the subscription implementation, be it an extension or just a generic contract,
the difference is trusting a single contract that you own vs trusting an arbitrary number of external contracts that you don't own
the account safety is a perfectly valid concern. but it is not specific to this proposal or subscriptions - it is the issue with the custom accounts in general. again, while it is very important for it to be safe, I think the level of trust can be bigger. e.g. even if you have a trusted implementation of a token you still need to trust its issuer/admin. here the trust is limited to implementation only
radiant karma
I suppose I disagree with the conclusion that its a "contract you own". I don't imagine users deploying or writing their own extensions, rather they would all delegate to a common implementation that, say, is immutable and some1 reputable deployed. And, I think this would be the same structure that would occur for allowance based subscriptions too.
In both cases, there would be an immutable implementation that can only modify a users balance for a given token contract, or a set of token contracts, where even having a balance in them (in my opinion) is trusting the issuer/admin.
I might just have to spend more time thinking about this, tho, since I'm sure it has uses outside of subscriptions.
shell atlas
they would all delegate to a common implementation that, say, is immutable and some1 reputable deployed
sure, that's a reasonable expectation. by 'contract you own' I mean that you are the owner of the instance, not necessarily the implementation. e.g. SAC is implemented at the protocol and the implementation can be reasonably trusted. however, that doesn't mean that you can trust every SAC instance to be a reputable token - you need to trust its admin/issuer as well. when we're talking about allowances, you also need to trust the contract that you give allowance to (both implementation and the instance).
, since I'm sure it has uses outside of subscriptions.
sure, most of the use cases for the custom accounts are applicable here as well (e.g. sessions). I can't really vouch for the usefulness of these cases, but there is quite a few articles out there embracing this.
hot bough
If the contracts are immutable, does owning the instance matter?
shell atlas
contracts can be mutable