# ArcherDAO Private Bundler
© Vulcanize Inc

From the perspective of a searcher, the ideal way to maintain bundle privacy would be to submit each bundle as a ZKP that proved to the miner, and only the miner, how much the miner would be paid if the bundle were included in a block. In this ideal solution, the miner would also want to include this bundle with other bundles that didn’t conflict with it. In order to do this, we’d need to add to the ZKP the final state desired by the searcher. So our final ZKP would include:
1. An ordered set of transactions
2. The final state desired by the searcher if the bundle is applied.
3. The amount the miner would earn if the bundle were included.

We can further imagine the structure of this ZKP such that the miner cannot see the exact value earned, nor can they see the desired state. But instead, they are able to use some sort of Fully Homomorphic Encryption to compare miner payouts. In such an ideal system, it would also be possible to apply conflict-free merges of the desired final states to determine bundle compatibility, which would greatly increase the potential profit for block producers.

I’m not a cryptographer, but this seems like a very complicated set of features that would take a long time to implement if stuck with the existing EVM. Instead, a bonded interactive protocol which can be implemented in a relatively short time and doesn’t require any significant basic research is described below.

Here, we will suggest that there are two entities involved in this interactive game: metabundlers, who have a bundle they would like included in a block; and superbundlers, block producers who wish to maximize their revenue per block by adding as many of the most expensive bundles as possible.

This model assumes that we are working on the Ethereum mainnet. This system will work with many other networks, including ETH2 or L2 systems, but will need to be modified accordingly.

The metabundler will search the global transaction pool for public transactions which, if included with their carefully constructed private transaction, will result in increased revenue. They will also need to include a transaction that somehow results in the superbundler being paid. This results in three transaction types that can be in a metabundle:
1. Public tx
2. Private tx
3. Miner payment.

It’s important to note that the metabundler does not have the ability to modify or generate the public tx, but it is possible that the gas fee of the private tx could be such that it sufficiently pays the miner and a miner payment tx is not required. There can be any number of these transactions in a bundle up to the limits enforced by the Ethereum mainnet, such as the gas limit.

Once the metabundler acquires a set of public transactions they wish to bundle, they construct an ordering of transactions which includes the public transactions as well as the private transaction they have constructed, and will not be broadcasting to the broader ethereum network. If required, the final transaction in the bundle will be the miner payment. The metabundler will then use the EVM and the state from a previous block to create a statediff showing what state they desire after the block producer includes their bundle. They can also generate a gas cost for the bundle. A metabundle contains:
1. An ordering of all the txhashes in the block, public and private
2. The gas cost of the bundle
3. The minimum blockhash to apply the bundle against
4. The maximum blocknumber to apply the bundle against (effectively defining an expiry)
5. A statediff containing only the state updates that are required to consider the bundle successfully applied
6. The value earned by the miner (by pointing to txhashes and updated states)

Prior to the submitting the metabundle, a state channel will be created between the superbundler and the metabundler. Both sides will place value into the channel. The superbundler will specify a minimum value that must be submitted with any metabundle as a form of spam protection; this minimum must be in the channel before a metabundle will be accepted. The superbundler will also provide, in the same channel, insurance to the submitter for the situation where the metabundle was accepted by the superbundler, but no block was produced within the expiry. The metabundler should be mindful of these safety measures when submitting metabundles.

The superbundler will publish minimums to get into the next block. If the metabundler feels these prices are reasonable, they will submit a metabundle in a p2p manner via the state channel; the superbundler is paid when the metabundle is submitted. The superbundler then uses a heuristic to create a supermetabundle. Once the supermetabundle has been created, the superbundler will notify the various submitters that their metabundle was accepted and then request from those submitters their respective private transactions. Once the private transactions are received by the superbundler, the state channel escrows the insurance for the benefit of the submitter. If the metabundlers don't provide their private transactions within some timeout, their payment is kept by the superbundler. If the block is produced within the expiry, then the block results in a payment to both parties, additionally, both escrows within the state channel revert to their respective depositors. If the metabundle is included after the expiry, both parties are paid, but the superbundler’s insurance escrow is paid to the metabundler. If the metabundle is never included, the superbundler’s insurance escrow is paid to the metabundler.

Additional notes:
* How channels are settled on mainnet is grossly underspecified.
* There are a number of timing issues associated with this model.
* It may often make sense for a metabundler to use more gas than strictly required, as a means of achieving a priority among the pending metabundles.
* It may make sense for metabundlers to send more of the results from the eth_call
* It may make sense for superbundlers to also sell Ethereum state objects to metabundlers
* The statediff is effectively a partial-block witness. A light discussion of partial-block witnesses can be found on the Eth R&D discord: https://discord.com/channels/595666850260713488/688085960801648749/824720245763342338