Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ag-solo problem is more backups than powerful objects #3

Closed
dckc opened this issue Jun 15, 2023 · 2 comments
Closed

ag-solo problem is more backups than powerful objects #3

dckc opened this issue Jun 15, 2023 · 2 comments

Comments

@dckc
Copy link
Contributor

dckc commented Jun 15, 2023

The core issue that prompted development of the on-chain smart wallet was really backups:

The market norm is: if you have your 24 words, you can walk up to any computer and start doing business. But with ag-solo, you need the state of all your vats. If your machine crashes and you don't have a backup of your client-side wallet vat, poof! There went your assets. (well, not completely... recovering the vat state isn't as hard as cracking private keys, but it would involve a huge forensics effort.) So we moved the state of the wallet from the client machine on to the blockchain.

Aside: the initial prototype of the smart wallet was a nifty demonstration of the overall distributed object framework: We just changed where the wallet vat was deployed from the client side to on-chain, without changing the code inside the vat at all. I'm pretty sure @michaelfig did it, but I can't find it. Michael? Help?

So this point in the lecture doesn't seem like right thing to emphasize:

* We should not expose objects that powerful to normal users

It comes up at about 19:50 in the recording.

The overall security properties of ag-solo are pretty good. The home object only has capabilities that, in due course, we do want users to have.

There are some security issues that postponing ag-solo access allows us to postpone for the short/medium term:

But by mainnet 3, we do want E(home.zoe).install(...) and E(home.zoe).startInstance(...) (or something equivalent) to be permissionless.

cc @jeetraut @hielo777

@michaelfig
Copy link

michaelfig commented Jun 16, 2023

I think this one is an earlier duplicate of #4. Would you mind closing it @dckc?

@dckc
Copy link
Contributor Author

dckc commented Jun 16, 2023

strange! I wonder how that happened.

@dckc dckc closed this as completed Jun 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants