Reorg Origin & Account Abstraction

[filippoweb3]

I suggest to create two pages:

• Origin Abstraction
• Account Abstraction

[filippoweb3]

@shawntabrizi comment from the previous PR #5263

I don't think there is anything fundamentally wrong here, but it just doesn't read to me in the way that I understand these concepts in my own head.

Firstly, I am not a big fan of the use of "persona" in the first and second paragraphs. Origins are most concisely described as literally where a call originated from.

Ultimately, I would think about origins as one half of an access control system. All dispatched calls have a contained origin, and all functions which are dispatched to have an origin check.

Because this system is left open to be customized (versus having a hardcoded list of origins that substrate only supports), it allows you to design many different sytems, like the ones you see in Open Gov.

---

I see the title of this page is named "account abstractions", and I believe that means the content here should be able to answer questions and curiosities of people coming from the Ethereum world and understanding the account abstraction system which exists on that side, and comparing it to ours.

In this case, I think the page, as written, is not the right format. Here is how I might imagine the content to look like:

Title: Account Abstractions and Access Controls (probably can be tuned)

Section 1: Origins

• Signed Origin
  • High level view onto a raw account origin, which can be expanded on in section 2.
  • An account id is ultimately just some unique set of bytes, usually representing a public key.
• Root Origin
• None Origin
• Custom Origins
  • Treasury Examples
    • Explaining small, medium, and big spender origins and the access to different spending amounts in treasury.
  • DAOs / Fellowship Examples
    • Examples of N of M origins
      - including simple math which can help identify simple majority, super majority, etc...
    • Examples of rank based origins / extrinsics
    • Expressing inclusion of being in a organization via wrapper origins
  • Parachain and other System Examples

Section 2: Account Abstractions

Many tools on top of which we can generate and control signed origins in Substrate / Polkadot

• Utility Pallet
  • Derivative Accounts
  • Batching
  • Dispatch as (for root control)
• Multisig Pallet
• Proxy Pallet
  • Keyless Proxies
  • Delayed Proxies
• Sudo Pallet

---

Probably I should review the Ethereum account abstractions story again myself to see where we can better draw lines which connect ideas and functionalities we provide, but really this is the kind of comprehensive story which describes the state of Susbtrate / Polkadot.

---

As a note, I took the perspective of looking at technical design, and working up to the features that they provide.

An alternative approach could be looking at the features provided (as top level section titles), and then working your way down to the pallet / feature which enables it to work.

I think the former reads better to me as an engineer, but the latter may be better for a user who may not be that technical.