Rename Anonymous Proxy to Something Else

[wpank]

"Anonymous Proxy" is a bit of a confusing name. There's not really anything anonymous about it. We should rename it to something a bit more descriptive, such as "Pure Proxy", "Shell Proxy", "Dynamic Proxy", or "Keyless Proxy"

[nuke-web3]

The wiki article on this likely should be updated to reflect more of what you can do with one. Once this is very well established, the name may become more clear.

IMHO the aspect that is critical and novel is that a keyed account (shown in the diagram as the "anon proxy") creates and controls a full account that has no key. To others this "user primary account" looks to be just like any regular single owner account, but no one could ever construct a key to sign on it's behalf . The only way this account can do anything is by the "anon proxy/proxies" sign on behalf of the "user primary account".

So I would propose we have a graphic that replaces:

• "anon proxy" with a dynamic set of keyed accounts (not sure how to illustrate this)
• "user primary account" with a keyless account

Then give examples of use cases and analogies like:

• A "keyless account" is akin to a "shell company" that looks and acts like an individual / person on chain (keyed accounts), but in reality is controlled by a dynamic set of "real" keyed accounts.
• Contrast with multisigs (MS):
  • MS do have a single master key (that you technically could find and use to make a MS -> single key control) this "user primary account" does not have a key.
  • MS are constructed one and set permanently - the keys needed and thresholds are all set at creation. "user primary accounts" can set multiple parties dynamically over time that have various levels of control over it.

Open to thoughts/comments. I am still trying to grasp the concept and have not looked at how this is implemented at all 😅 ... Who does have insight into the code behind this? We should ping them 🙏🏼

[wpank]

Tagging @laboon for wiki changes

[kirushik]

@nukemandan I think the code you're referring to is located in the frame/proxy/src/lib.rs file.

that you technically could find and use to make a MS

I wouldn't agree with the word technically here; there's no technical way to do that other than bruteforcing 2 to power two-hundred-something keys. I would call this probability theoretical at best.

I think I also misled everyone during today's call mentioning that multisig accounts differ from anonymous proxies in the way they addresses are generated (here is the multisig generation, and here is the anonymous proxy one).|
They both rely on BLAKE2 encoding of some deterministic seed values, and the only difference in there is that the proxy-related code also uses block height and extrinsic index as its inputs (thus requiring attacker to also have control over block authoring to have any predicting power over what the account address is going to be like — in multisig theoretically a malicious party can theoretically get at least some sort of a "vanity address" by submitting a carefully-chosen member account address).

[kianenigma]

"Keyless Proxy" 👍

[joepetrowski]

I'm not a fan of "Keyless Proxy" and prefer "Pure Proxy" because other accounts could be "keyless" proxies. For example, multisig and derivative* accounts are keyless, but they could be proxies. Those are, in a sense, keyless proxies, but does not fully convey the meaning of anon proxy.

The most difficult hurdle for me was that the anon proxy is actually the proxied account (which is why I explicitly centered the Polkadot Wiki section around this fact). I think I would call the dispatchable generate_proxied to generate the new account ID, and then you just call it a "pure proxied account" to express the fact that proxy is the only means of accessing it.

* Talking about utility.as_derivative, not key derivation, here.

[bkchr]

"Pure proxy" convey as much information as anonymous proxy to the user. Probably even less and again require the user to read through a lot of docs to understand them... IMHO this does not help in understanding the proxy in any way.

[kirushik]

Maybe we can drop the word "proxy" here altogether (since it's not doing that great job in conveying the direction of the proxying relation), and call this feature something completely different, like "virtualized account"?

[wpank]

Maybe we can drop the word "proxy" here altogether (since it's not doing that great job in conveying the direction of the proxying relation), and call this feature something completely different, like "virtualized account"?

Indeed - I think the proxy part of the name adds to the confusion. Maybe something like "Pure Keyless Account", "Shell Account", or similar.

[h4x3rotab]

"Pure Account" and "Keyless Account" are both confusing to me. I think we sometimes mixed two different things:

• Proxy, or Anonymous Proxy, refers to a relation between two accounts where the delegator can act on behalf of the proxied account
• As a result of Anonymous Proxy creation, a new account is generated and can be used as a regular account, but controlled by some delegator

I suggest to name the account generated by Anonymous Proxy as Agent Account, or Automated Agent, to address the fact it's not controlled by any key but by the blockchain itself (the blockchain defines how the permission is delegated).

As I pointed out, the Proxy itself is not an entity, but a relation which grants some other account the permission to behalf on the creator (or a generated keyless account). Therefore I would call it Account Permission.

Example 1

With this setting, we can turn the following statement:

Alice creates an All Proxy and assign Bob as the delegator. So Bob can act as Alice.

into a much better one:

Alice create a new All Permission and grant it to Bob. So Bob can act as Alice.

Example 2

A more sophisticated example:

Alice and Bob own a company. To jointly control a Polkadot account to stake DOTs with the flexibility, they created a 2-of-2 multisig account.
Then Alice creates an Anonymous All Proxy, and assign the multisig account as the delegator. Now, they can use the generated keyless account to hold assets and stake. They can operate the account only when they both agree.

will be changed to:

Alice and Bob own a company. To jointly control a Polkadot account to stake DOTs with the flexibility, they created a 2-of-2 multisig account.
Then Alice creates an Agent Account and grant the All Permission to the multisig account to make it the controller. Now, they can use the generated Agent Account to hold assets and stake. They can operate the account only when they both agree.

[emostov]

Throwing one into the ring: "Proxy Contingent Account" - communicating the account is 1) born into existence only by an account (initially) proxying it and 2) generally dependent on proxies to operate.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[kianenigma]

Should stay.

[DrW3RK]

Transferable Keyless Account?

Trying to make a video tutorial on Proxies and stumbled on to this issue through Technical discussion at W3F. I'll make sure I summarize this discussion concisely (and add it to Polkadot Wiki as well)

[bjornwgnr]

Has there been any movement on this issue? My observations indicate that this remains a topic of great confusion to our users.

[nuke-web3]

For consideration: https://forum.polkadot.network/t/parachain-technical-summit-next-steps/51/14
Pure proxy 🤔

[dzmitry-lahoda]

For me any names are both same. They do not speak me what they will do. Official docs lack scenarios, may be like this https://github.com/ComposableFi/composable/blob/main/docs/governance.md#multisignature-proxy-setup

[olanod]

I don't think pure proxy really solves the problem, if anything it might confuse people more 🤷🏽