ARC-0058: Plugin-Based Account Abstraction #269
Conversation
SudoWeezy
changed the title
ARCs/arc-0058.md
Outdated
|
|
||
| **Plugin** - An additional application that adds functionality to the **Abstracted Account App** (and thus the **Abstracted Account**). | ||
|
|
||
| **Admin** - An account, sepererate from the **Abstracted Account**, that controls the **Abstracted Account App**. In patiular, this app can initiate rekeys, add plugins, and transfer admin. |
There was a problem hiding this comment.
| **Admin** - An account, sepererate from the **Abstracted Account**, that controls the **Abstracted Account App**. In patiular, this app can initiate rekeys, add plugins, and transfer admin. | |
| **Admin** - An account, separate from the **Abstracted Account**, that controls the **Abstracted Account App**. In particular, this app can initiate rekeys, add plugins, and transfer admin. |
There was a problem hiding this comment.
Does "transfer admin" simply mean "rekey to another app account"? If so that last sentence is redundantly talking about rekey.
There was a problem hiding this comment.
No transferring admin and rekeying are two separate things. The rekey method will rekey the Abstracted App Account whereas transferring admin will change which account can initiate rekeys (and add plugins).
If Alice has an account ALICE and she wants to turn it into an abstracted account, she needs to do the following:
- Create a new account:
ADMIN - Create an Abstracted Account Application, setting address to
ALICEand admin toADMIN - Rekey
ALICEto the Abstracted Account Application
Now if Alice wants to add a plugin to the Abstracted Account Application she can use her ADMIN account. If Alice wants to rekey ALICE, she uses ADMIN to call rekeyTo which will rekey ALICE.
There was a problem hiding this comment.
The 'abstract account' should have a name here as it's the account actually being transacted (later)
Not necessarily, the abstract account contract may control itself or another account. in Joe's example the account its controlling ( and thus managing rekeys for ) is the standard account ALICE
There was a problem hiding this comment.
Deleted my comment. Strange - I wonder if I saw a different version but I missed ALICE being rekeyed to the AAA prior to the rekeyTo.
There was a problem hiding this comment.
Yeah on creation you can supply the address the app controls. If you give it a zeroAddress then it just uses the app account. This is what's currently shown in the tests
There was a problem hiding this comment.
I will say though I'm back and forth on whether I should just remove that zeroAddress feature. Ie. a address must always be specified on create.
Co-authored-by: John Jannotti <[email protected]>
I really need to enable a spell checker in my VSCode... But the main idea of this ARC is to allow an account to be controlled by a smart contract but still have a safe way to rekey back to an EOA so that it can be used with any application. Taking a look at tests might give an idea on how its used, granted they are bit lacking in comments/explanation. https://github.com/joe-p/account_abstraction/blob/main/__test__/abstract_account_plugins.test.ts |
|
Made some changes today:
|
| #### Supporting EOA Rekeys | ||
|
|
||
| If a user connects to an app with an Abstracted Account the app **SHOULD** allow the user to easily sign transactions with an externally owned account. It is easy for the admin to manually call `rekeyTo` prior to interacting with an app, but this does not gurantee the user will rekey back to the Abstracted Account (this breaking plugin functionality). As such, to improve user experience, applications **SHOULD** be able to send transactions groups that start with a `rekeyTo` call that rekeys to the admin admin account with `flash` set to true. Because `flash` is set to true, the last transaction in the group **MUST** be a rekey from the admin address to the Abstracted Account address. | ||
|
|
||
| This requires wallets to be able to tell apps that the connected account is an Abstracted Account. |
There was a problem hiding this comment.
This is probably one of the hardest problems to tackle to gain adoption of abstracted accounts. Currently, it's not possible to tell a dapp that an account is an abstracted account. But let's assume there is, then every dapp would have to special-case abstracted accounts and sandwich their transactions in between arc58_rekeyTo and arc58_verifyAuthAddr.
This got me thinking if there's a possibility to make abstracted accounts oblivious to dapps. Right now, by default, the auth-addr of the abstracted account is the smart contract, while the admin and plugins can temporarily gain control over the account. Could it be done the other way around? That is, by default the auth-addr of the abstracted account is the admin, while the SC & plugins can temporarily gain control over the account.
This way, the admin could interact with dapps normally and sign on behalf of the abstracted account, and plugins can gain temporary access to the account if needed.
Implementation-wise, I'm not sure what the most elegant solution is, but one approach could be to use logic-sigs. The abstracted account starts as a regular key-based account. Then, the account deploys the ARC-58 smart contract and signs a logic-sig that anyone can use to call arc58_rekeyToPlugin or arc58_rekeyToNamedPlugin. This signed logic-sig could be stored in a box in the smart contract. The admin, and only the admin, can add or remove any (named) plugin as they do now with ARC-58, nothing would change in that regard. If anyone wants to call a plugin, they would have to use the signed logic-sig that would ensure that by the end of the transaction group the admin is again the auth-addr of the abstracted account.
This approach has of course its downsides, too. For one, it requires logic-sigs with all their implied problems. Plugins couldn't be called app-to-app, thus limiting composability. Logic-sigs couldn't be revoked (but plugins could be revoked at any time). I don't know if there's a solution that wouldn't require a logic-sig.
There was a problem hiding this comment.
arc58_rekeyTo doesn't need an atomic rekey back. It can be required by the caller, but not necessary. So wallets can receive an incoming txn group, see that the user will need to sign it and form three different txn groups
arc58_rekeyTo(admin)- ...dappTxns
- Rekey back to app
Since we are rekeying to the admin, its ok that the rekey back isn't atomic since we know the user presumably has control over the admin account. I think the lsig approach would have too many compromises.
There was a problem hiding this comment.
This does add some complexity wallet side though, it will need to wait for dapp txn confirmation prior to submitting the rekey back
There was a problem hiding this comment.
That's true, but I'm afraid the UX isn't great:
- A user may close the wallet midway through the process or the wallet might crash for some reason (OS kills it because of OOM, etc). Then the account is still rekeyed to the admin, which wouldn't be too problematic but the plugins wouldn't work anymore.
- A dapp may gather signatures now but submit a transaction later. Waiting for an unknown amount of time to rekey the transaction back is not good. Right now, some dapps, for example, let users sign a 0-ALGO txn for authentication but never submit it to the network.
- Users are told that rekeying is powerful and potentially dangerous. Wallets can detect
arc58_rekeyTo(admin)and in that case show no / less / different warnings for the rekey back to app, but if the user signs on a hardware ledger, there will always be this warning.
These may be edge cases, but they do happen. I agree that the lsig has many compromises and I was hoping there's a better solution:) I'm just trying to figure out how the smoothest UX could look like for end users to adopt abstracted account (which I hope they do)
|
I've played with ARC-58 and made a couple of changes in this fork:
Recovery PluginThe recovery plugin can be used to change the ownership of the abstracted account to a pre-defined recovery account, which is useful if the account's owner loses access to it. The way this works is that the recovery plugin is able to change the abstracted account's admin account to a different account. The recovery is time-locked, that is, the recovery account can start the recovery at any point in time but needs to wait a pre-defined amount of time before the ownership can actually be transferred. During this time, the existing admin account can reject the recovery in case an attacker gained access to the recovery account. One use case is that a wallet uses a device-bound key to control the abstracted account. The wallet may not offer the ability to export / show this key because, for example, the key is stored in a HSM. The user can add a recovery account to this abstracted account to regain access to the account in case she loses the device-bound key. I changed the Spending-Limit PluginThe spending-limit plugin is intended to allow accounts with different security levels to spend from the abstracted account. For instance, imagine the abstracted account's admin account is a 2/3 multisig that consists of a mobile phone, a desktop wallet, and a hardware ledger. The mobile wallet is the wallet that the user carries around with her all the time, but may be considered least secure. With this plugin, the mobile wallet can spend, say, 500 ALGO (or X USDC) a day without requiring signatures from the desktop or hardware wallet. The plugin stores the spending limits for each configured account and asset in box storage. It is possible to configure a time period after which past spendings are reset such that the user can spend from the abstracted account after every completion of the time period (say, every day). |
|
Amazing work @k13n! Would love to link up and discuss arc58's potential and how you envision it being used even further than these plugins here if you have some time! |
Absolutely, I'd love to. |
|
I've opened a security-relevant issue in my fork, it would be great to get your feedback on that! Maybe I should create the issue in this repo here instead? |
|
Hello everyone, when I first checked this reading of "Rekeying account to stateful contract" was enough to make me very happy but recently I dug in details and have some comments and concerns I list here: |
|
Hey @emg110, appreciate the concerns on this ARC. We definitely need to be careful and thorough with how we approach bringing arc58 wallets onto mainnet & think all these edges through before we proceed with using it for onboarding or just going live as an option for the ecosystem to use. Rekeying can be scary but I believe the foundation that this contract is built on ( rekeying & atomic groups ) inherits the security benefits of the AVM. Delegations is the real biggest feature of this system & compared to delegated logic signatures i feel this is much safer. Dsigs have no inherent revocation system so if you approve a malicious one thats pretty much it for that account whereas for arc58 you can set the what, who & for how long explicitly. Defly & Akita are both already publicly going forward with adoption on this and I expect other wallets will follow because the benefits will be so massive. There's still plenty of work to be done, especially with how plugins get managed, displayed & preemptively verified for use before being suggested to the user at all. I think you're right they probably deserve their own ARC. One other part of this that you may not have thought of is that these delegations need not be to other entities. In fact for Akita the plan at the moment is for the hot path to be delegating to your own spending keys per dapp. Simple sends & asset transfers are definitely more complicated with this setup though, theres no getting around that. Using Algorand with a smart contract wallet will 3x the fees you pay for simple interactions with the network. At our current price this seems fine but could change and will need to be reevaluated when the time comes. I understand utilizing rekeying in this manner can feel risky but i believe the benefits far outweigh any risk involved, in-fact @k13n just created two new plugins that both increase safety and flexibility of these contracts even further. I see the process of adding plugins to your account to be the most risky aspect of this system. Without a good process in place a user could easily add a malicious plugin that drains their account and then revocation doesn't matter much. The process we take users through to add these to their account must be well thought through & hardened so that its very clear which plugin requests are from completely unknown/unvetted contracts vs highly used & trusted ones. It's my opinion that the vast majority of plugins that get used will be created and reviewed by the engineers here like yourselves. Im sure there will be plenty of reasons people make new plugins in the future and they'll need a process for review/audit before ui warnings or indicators about the uncertainty of the plugins code can be removed. Tldr; Your concerns are fair, I strongly believe the benefits massively outweigh the risk & that we have many tools to ensure safety and simplicity for users. |
The rationale for the named plugins was to allow for discoverability for ARC-based plugins. For example, let's say there's
Great! Love seeing more use cases for this ARC as it gives more context into how it can be used
I understand the value here, but I am concerned it opens up a new security risk. Currently, an admin account is always guaranteed to have control over the account regardless of what plugins do. Even if a malicious plugin drains the account, the admin still has the ability to revoke the malicious plugin and get control of the account back. With this change a malicious plugin can completely take control of the account (akin to a delegated lsig being used for a rekey). Perhaps if we want this feature it's an additional flag that exists within ARC58 itself and wallets give an extra warning when a plugin is requesting that permission.
Good catch! I think the solution here is to simply change if (txn.sender === this.controlledAddress.value && txn.rekeyTo === this.getAuthAddr())to txn.sender === this.controlledAddress.value &&
txn.rekeyTo === this.app.addressAs for the logistics of implementation issues, I think linking to an external issue is fine for now. Perhaps make the issue upstream in
Some of the use cases for ARC58 can be done via delegated lsigs, but ARC58 adds additional security and composability benefits. For example, ARC58 enables revocation and timeout-based authorizations. ARC58 is also inherently more transparent because for any given account I can lookup all the plugins that current have authority over the account. This is impossible with delegated lsigs because they are simply signatures. If the lsig hasn't been used yet, there is no way to tell what signatures currently exist for a given address. Because ARC58 is app-based, it enables other apps to leverage plugins, which is something that is not possible with lsigs.
I think the only other technical solution given the tools we currently have are delegated logic signatures, which have the security and composability concerns mentioned above.
I agree. In many cases there are simpler solutions for onboarding an EOA. For example ARC59 for asset opt-ins. This ARC, however, is much more flexible and provides a framework for more advanced onboarding scenarios. The burder of this complexity lies upon the onboarder not the one getting onboarded.
Undoing the account abstraction is simply a matter of rekeying to an EOA. Once the
Agreed. Plugin verification is outside of the scope of this ARC but very important for adoption.
I somewhat agree but I also think it's all about abstraction and UX. When we onboard someone by having them create a keypair they don't need to understand eliptic-curve cryptography. When someone signs into Amazon with passkeys they have no knowledge of the underlying cryptography. The ultimate goal is to abstract away the details of keypair management and ARC58 provides a framework for one piece of that puzzle.
Agreed. This is why the Wallet Council and ATAC exist.
The
Yes agreed. The actual plugins themselves are outside of the scope of ARC58 and should be their own ARCs, but having use-cases for ARC58 makes it easier to discuss what we really need from this ARC. |
|
Thank you for response @kylebeee and @joe-p , I appreciate this and the great work you guys are doing very much. Am I correct to assume the only unique feature this ARC provides is addressing opt-in fricktion? Would you mind kindly list those unique benefits or refer me to them on document (features that are only possible using this ARC)? I just am trying to underestand what that overhead complexity and risk of many rekeys between different plugins and the overhead of maintaining trust between all those is worthing to not having optin. Note: I am 100% in favor of abstract accounts and the initial approach of rekeying an account to smart contract address but the methodology details and excessive use of rekey is what concerns me and I think may be there are more effective ways. may be Million thanks again |
This ARC simply provides a way to safely delegate control of one account to applications. Use cases like opt-in are provided as an example but not within the scope of this ARC.
There are two ways to delegate control of an EOA. Rekeying and signing a logic sig program. Lsigs have the problems mentioned above. This ARC utilizes rekeys but provides a way to ensure specific properties of the delegation, like who can initiate them, when they expire, and revocation. |
Discoverability is an important topic here, but would the name really help? What if a plugin appears to implement an ARC based on its name but does not actually implement it? What if the plugin implements multiple ARCs? I've been thinking how we'd likely implement this in Defly Wallet and this might address discoverability and some of the security issues that have been raised here. From within Defly itself we'd only allow to enable a set of whitelisted plugins (opt-in, recovery, spending limit, etc.). Those plugins have to be open source and they have to be carefully vetted by ourselves (Defly) and the community. In addition, I believe plugins should be immutable. Once a plugin is approved, we'd compute the hashes of its compiled approval and clear-state program and hard-code them in Defly. When we look up the account state of an abstracted account, we'd look at all plugins in this account and show if one is approved according to the plugin's hash or not (if not we'd warn the user that she's got an unrecognized, unapproved plugin). For each whitelisted plugin we'd implement a custom UI in Defly to maximize its utility. For example, for a spending-limit plugin we'd have a UI where the user can set spending limits, monitor them, and delete them. We'd start with a very small set of plugins, but over time we'd hope that developers start writing their own plugins and ask them to be integrated into Defly (always following the process outlined above). Just thinking out loud, but we could even deploy a "registry contract" that implements this whitelist of approved plugins on-chain. The
That's a fair point. My hope was that with the process outlined above where we'd only allow whitelisted plugins, we'd not run into a situation where a plugin maliciously tries to change the admin account. But having this extra permission flag also sounds like a nice approach!
Hard disagree, @emg110. You need to let individual projects push their products and you cannot expect that one project holds back just because other projects don't pull along (immediately). You cannot control everything through committees & standardization bodies because that just kills innovation and slows everything down to a standstill. It's great that these committees exist and I'm a member of some of them because I think it's valuable to have them, but they cannot force individual projects to adopt or not adopt certain features.
Agreed. I think it's good to have one or two example plugins in the ARC to showcase what can be done and how it can be done. In my fork I added two more plugins, but probably it's better if they are outside of this repo. |
|
Thank you for your response @k13n, I cannot find anything mentioning "Committee" or anything supervisory in any of my comments (where did that come from dude?). Those are just comments and concerns of one builder in ecosystem who happened to have witnessed more rainy days than many others. I simply stated: Also just by moving plugins to a separate ARC and concern and also removal of the Onboarding mission for ARC58, 99% of those concerns will be auto-eliminated since no one objects to an innovative feature being available for advanced users who know what they are doing (even if it is just one wallet provider who innovates and deploy it) Thanks again for very productive, non-personal and pure technical conversation we have here, from fruits of which whole community will benefit. |
|
No hard feelings MG, and I hope my writing isn't too blunt. I wasn't directing my statement at you, but wanted to state it more generally that I don't think all wallets need to do the exact same thing even if it concerns more fundamental issues. I made the reference to committees because ATAC and the wallet council was mentioned somewhere in this thread (maybe by someone else). And I think with that I also explained why I disagree with your reasoning. People, especially newcomers, often don't realize that they can bring an account created in one wallet into another wallet. They often say they have a "Defly account" or a "Pera account". Hence, I think it is completely fine that one wallet offers an account type that other's don't. In fact, right now Defly offers multisig accounts whereas most other wallets don't. That's also a fundamental feature, but if we had to wait to deploy multisigs until everybody is on-board, we'd still be waiting right now :) |
|
I agree that is indeed a general issue: The lack of harmony on fundamental features across wallets in Algorand. On that, I agree. |
|
Back to this ARC's main subject and just for the future record : I still firmly believe that smart signatures are the way to go for account abstraction. We cannot leave a foundamental feature of Algorand blockchain unused because it may have risks if not implemented correctly (it's like not using the web because it has obvious risks if not implemented securely). I firmly beleive that we should not hack our way around an available and powerful feature and start using it within wallet providers. Also plugin features as well can be achieved that way by either only using smart signatures templates or a combination of smart contract apps and smart signature templates. it is much safer and more flexible than sandwidching rekey transactions and re-use them over and over , which does not seem to me as a comprehensive architectural solution to abstract account requirements for Algorand. |
|
Hey @emg110, i fundamentally disagree with you and think your point of view on this doesnt properly address the drawbacks and limitations that delegated smart signatures have. I think aside from you we have pretty unanimous agreement on this ARC and why its implemented the way it is |
This ARC proposes a standard for using stateful applications and rekey transactions to enable account abstraction on Algorand. The abstracted account is controlled by a single stateful application which is the auth address of the abstracted account. Other applications can be used as plugin to provide additional functionality to the abstracted account.