I was originally going to advocate for something similar to this in a post today (after analyzing the issues around the original relay market). Your timing is impeccable. A few points here.
Why not make it more simple and just use the EE as a hub by which the payment is transferred and call into the appropriately packaged EE for the transactions via a similar staticCallExecutionScript? Standards can be built around this pretty fluidly. This is one of many usecases for making calls into other EEs available synchronously. I’ll put a post up about this later.
Advantages over previous relay markets
Regardless of whether this system is facilitated via the method above or via a receipt claim, this general approach is a huge step forward. A few reasons why:
- Previous relay markets (1 or 2 relayers per block) generally converges into a cheapest hardware, cheapest computation system. It also could centralize transaction broadcasting and make it very difficult for anyone to self publish their own transaction in case a cartel runs the relay market. Other issues listed here from @benjaminion: Exploring the proposer/collator split
- Previous relay markets discouraged peering
- This separate approach of accepting many different packaged transactions does incentivize peering/sharing between validators of the packaged tx’s
- This allows for a user who is being censored by various relayers or broadcasters to send their own transaction into this “mempool” or peering mechanism
- Introduces a better monetization strategy for wallets and infrastructure providers (vs. potential hoarding between a small cartel of proposers on each shard)
- more unified payment model between all EEs
- Fragmented/multiple transaction packages would actually make self-publishing much easier. (ie. bulk transaction transmitters/relayers may offer best fee deals but packaging your own would likely be more expensive and thus discourage just one or two major relayers)
Business Models
I tend to think this approach opens up very strong monetization opportunities for wallet providers and nodes that manage state. Wallet providers are incentivized to keep state and witness data and attach it to each transaction. There can be an additional fee market around adding the witness data on behalf of the tx (separate from a fee differential to the block producer). A lot of different approaches here.
Preliminary Questions
- An approach of multiple packages can complicate the system of others wrapping around the packaged transactions and transmitting it for themselves. (although setting limits on recursive action with the call “proxied” through a fee market EE would remove this concern) - we wouldn’t need a system like this: Optimised proposal commitment scheme
- Providing the appropriate witness data would be signed by the original tx sender to accept this service and have an open market or would we encourage a flat fee and any client can add this data (possibly discouraging peering once again if we go wit the flat fee/any client can add)?
- Would the market end up converging into just a few packaged txs anyways? To elaborate, a general relay/fee cover would likely form in many EEs to avoid tx senders from having to own the pegged eth or canonical currency anyways
These are my preliminary thoughts as a whole - I’ll likely follow up with something more formal later.