Thanks for surfacing that proposal. I think a merkle tree signer for signing a large number of transactions is interesting. That concept has been discussed more recently on the mailing list here
Issue #92 is brief so I could be missing something, but there still has to be a way to require a specific merkle tree signer root for the transaction batch so that a participant doesn't use their regular signer. The extraSigners is inside the transaction signature payload so it can't introduce a cyclic dependency and a transaction can't include itself in the merkle tree. This means there wouldn't be one merkle tree signer for the batch, but one per transaction that contained all subsequent transactions.
I think it would work but it has different trade offs:
- A signed payload is rather simple to create and verify using primitives available in most standard libraries, both for core and for contract participants. A merkle tree signer requires merkle tree building and path verification in every implementation of the contract, not just core.
- A signed payload adds one 64 bytes to the extraSigners precondition of the first transaction for every transaction after the first, e.g. for three transactions the first has two extraSigners, the second and third have none. A merkle tree signer would add 32 bytes to every transaction in the batch, except maybe the last. The storage cost here is nominally higher for the signed payload, but building and verification are a higher cost may be significant for the merkle tree.
- A signed payload signature adds 32 bytes per transaction disclosed to the first transaction. A merkle tree signer would add 32 bytes to every transaction, maybe except the last, for any number of transactions. The cost here is equivalent.
- A signed payload signature probably won't affect utilization with a limited number of extraSigners and so I think we can defer changes to fees until a day where more than two extraSigners are required. Nicolas mentioned here
previously a merkle tree signer requires a redesign of fees.
- A signed payload is very generic and may have other applications outside transaction hashes and doesn't need to contain any logic specific to transaction hashes. A merkle tree signer could also have other applications, but would require logic specific to transaction hashes.
I think the trade offs of the simpler signed payload are preferred, and both signers can coexist if we discover a need for merkle tree signers, but I'm interested to hear what you and others think.