Submitted transactions (and batches) currently get transformed into AuthenticatedTransactions in the sequencer before they are submitted to the mempool. This authentication:
- rejects double spending early
- authenticates any unauthenticated note IDs that are committed
Once it gets to the mempool, this extra information remains valid so long as the authentication reference block overlaps with the mempool's retained history. In other words, a transaction has N blocks between authentication against the database & being processed by the mempool. If this fails, it is considered an internal error since this means the processing was slow.
Since full nodes have a complete copy of the sequencer data (minus sync delay), we can offload this database IO from the sequencer to full nodes. This authentication data would be trusted since verifying it would require the same database IO we are offloading.. In other words, this can only be done by the network operator's own internal full nodes, and not by external full nodes. Though the latter could still do double spending checks for early rejection.
I propose we add a new gRPC sequencer service, intended only for internal use, which contains the SubmitAuthenticatedTx and SubmitAuthenticatedTxBatch methods.
Internal full nodes which have access to these endpoints should replace the current submission workflow with the workflow performed by the sequencer:
- submit to validator
- authenticate tx
- forward both to the sequencer
Effectively, the current sequencer impl would be split just prior to mempool submission, with the former half going to the trusted full node.
Such trusted full nodes would require an additional:
- validator url and
- sequencer url
note that the latter is not necessarily the same as the upstream url (which could be daisy chaining). Though maybe we shouldn't do this and instead have:
upstream.url for untrusted(sequencer.url, validator.url) for trusted
Submitted transactions (and batches) currently get transformed into
AuthenticatedTransactionsin the sequencer before they are submitted to the mempool. This authentication:Once it gets to the mempool, this extra information remains valid so long as the authentication reference block overlaps with the mempool's retained history. In other words, a transaction has
Nblocks between authentication against the database & being processed by the mempool. If this fails, it is considered an internal error since this means the processing was slow.Since full nodes have a complete copy of the sequencer data (minus sync delay), we can offload this database IO from the sequencer to full nodes. This authentication data would be trusted since verifying it would require the same database IO we are offloading.. In other words, this can only be done by the network operator's own internal full nodes, and not by external full nodes. Though the latter could still do double spending checks for early rejection.
I propose we add a new gRPC sequencer service, intended only for internal use, which contains the
SubmitAuthenticatedTxandSubmitAuthenticatedTxBatchmethods.Internal full nodes which have access to these endpoints should replace the current submission workflow with the workflow performed by the sequencer:
Effectively, the current sequencer impl would be split just prior to mempool submission, with the former half going to the trusted full node.
Such trusted full nodes would require an additional:
note that the latter is not necessarily the same as the upstream url (which could be daisy chaining). Though maybe we shouldn't do this and instead have:
upstream.urlfor untrusted(sequencer.url, validator.url)for trusted