This document aims at explaining how operations issuers can filtrate access to their mempool of operations, using a dedicated server. This feature is scheduled for the Octez v11 release.
Last updated
Was this helpful?
Using --operations-pool argument when launching the baking software, bakers are able to fetch a mempool from a private server in addition to the mempool of any public Tezos node. By controlling which bakers can access the server (the baker's address is known), users can manage those who can bake their transactions. Thus, bakers must pass a KYC to enter the set of allowed bakers but we will not discuss this part in this document. Once bakers have been validated, the server must be able to authenticate them. The authentication mechanism needs to be determined.
Possibilities :
with the URL directly:
with the credentials in the HTTP headers.
It really depends on how the server wants to proceed.
Besides authentication, the server needs to perform multiple checks on the operation sent by the user:
It may only accept manager operations (i.e. transactions, revelation, origination, delegations)
The server must perform a dry-runΒΉ of the operation on its own node (public nodes could be malicious) to verify the validity of the operation and estimate its gas consumption
If one of these checks fails, the server responds back with an appropriate error message. If all is correct, the transaction is added to the pending queue of the server and the server sends back a confirmation that the transaction is waiting to be included in the estimated amount of time.
[1]: A dry-run is a simulation performed with the tezos-client.
Who hosts the server?
Does the server need to send a confirmation that the transaction was baked or is it the user's responsibility to verify it?
Should the server deliver the mempool only if the baker is going to bake soon?
