I recently considered using pre-authorized transactions, but the minimum reserve cost for having each pre-authorized transaction be a signer was disincentivizing.
Example:
A user wishes to create an account and place funds in the account with a fixed set of outcomes for the funds in that account. A user could create an account, deposit the funds, set several pre-authorized transactions as signers of the account and remove any other signer. An additional 0.5XLM reserve is required in the account to pay for each additional pre-authorized transaction signer. Four pre-authorized transactions are approximately US$0.20 today. The cost becomes more prohibitive if the user wishes to retry transactions. Any pre-authorized transaction may fail consuming its sequence number. To retry a transaction the user would need to add additional transactions as signers, one for each retry. For 10 retries, this increases the minimum reserve cost to US$2.00.
Proposal:
I propose we make using pre-authorized transactions more economical by adding a new signer to accounts and a new signature payload to transactions. The new signer would use a merkle tree to reduce the data needed within ledger entries to a single root hash, and shift the weight of the data required to prove that a transaction is pre-authorized into the transaction signature payload.
A user when building a set of pre-authorized transactions would build a merkle tree where the data blocks are the transactions (or the transaction hashes).
The account signer would be the merkle tree root hash, 32 bytes using SHA256.
The transaction signature payload would be the hashes that make up a merkle branch from the root to the leaf node for the transaction and the transactions index in the tree. The payload size would vary depending on how many transactions were included. For example, 70 bytes if the tree contained a single pre-authorized transaction, 300 bytes for 100 transactions, 650 bytes for 100,000 transactions.
The transaction verification process verifies that the transaction hash lives under the root hash stored in the account, using the hashes stored in the signature payload.
This would make any number of pre-authorized transactions affordable.
There would be some limitations: a maximum depth, to ensure the cost of verification was understood but that depth could probably be sufficiently large. It may be difficult to implement in XDR because signature payloads on transactions do not have an extension point. However, this is not a new issue and we should probably consider how to make it easier to add new signature types in the future anyway.
Does anyone have any thoughts on this?
This is not pressing or blocking anything I'm working on immediately.
Leigh