Theorem: Solving Multisig/threshold accounts and Cron are equivalent to a Pupeteer

[jon-chuang]

Problem

We need to delegate ownership of single-owner accounts, whether they be created directly by a user, or are program derived, to a generic on-chain program.

This "pupeteer" can then choose if, and when to sign transactions (i.e. schedule txs), based on (generic) logic chosen for that account about who has access control.

One can stipulate what this more specific access control is - whether that be multisig, single sig, or threshold sig (manual count by shares mode). By delegating control to an on-chain program, signing and executing transactions can be completely asynchronous, and the program itself can be told when to schedule the transaction, recurrence of the tx, the expiry of that transaction etc.

related: #17145 #16404 https://github.com/project-serum/multisig/

My proposed name for this program is a DAU (Decentralised Autonomous User)

Solution

The program should be a system program. As opposed to the direction pursued in the Serum multisig program, which isn't generic over the transaction type, as a generic program, this ought to be a bit more flexible, able to store a vec of different TransactionAccounts, etc (the active set), being able to point to other generic bits of logic like transaction rescheduling.

Proposed Development Pathway

Here is my proposed development/merge pathway:

1. develop a prototype in Anchor that requires a wake command. We can put up a reward everytime you call wake first for a slot to ensure it's constantly being called 🙂 The reward is derived from fee-paying programs.
2. If this program is shown to be stable and works well, we can experiment with reimplementing as a standard program and having it live solana/programs, as well as the bank.rs/TPU-specific logic required to execute the cron program wake transaction automatically at the beginning of every block.

Unfortunately, a cron program is "Turing complete", meaning that it needs to execute logic before it can say which accounts its transactions will touch.

Thus, it cannot be an ordinary program in the sense that it needs to be able to atomically schedule individual transactions after waking etc. Most of the time, it's going to go to back to sleep immediately. I think the transaction needs to be completely atomic as it needs to check which transactions that were submitted were successful, whether they've enough fees to reschedule, etc. and following that gracefully shutdown/cleanup by resetting its next_job pointer etc.

So I think the way it could be done cheaply is - the wake command aggregates all the programs the cron program might touch, by a one-level recursion to those declared by the programs it is scheduled to invoke. Since it owns access to all of the derived accounts involved, it always has required write access - and only requires read access (from perspective on runtime). Then, it executes the entire wake, submission and sleep logic atomically.

The reason why I think this program should be a system program is that we have a smaller attack surface for generic/common functionality - the program needs to be scrutinised and tested to the same level as the runtime itself, so that others can trust and use it rather than implementing or creating their own non-generic programs, worrying it has a defunctive implementation.

Cron, as mentioned elsewhere, can also schedule transactions on your behalf instantly and atomically - it's not limited to scheduling some number of slots in the future.