TXCast: A High Level Solution to Transaction Scheduling
Transaction Scheduling Solved with Market Mechanics
A few weeks ago I opened an EIP on listener functions (1339), but due to current protocol limitations, it seems to be undoable at the moment. Fortunately, it is possible to realise this improvement at a high level. The solution revolves around creating a scheduling market. Unlike decentralised exchanges or DEXs, the supply and the demand work in different ways. The demand for scheduling markets has a time-based pressure. The buyer of the future transaction will not know if his bid for the scheduling will be enough incentive have it broadcasted on time. On the other hand, the supply side needs to allocate enough resources to be the first to broadcast the transaction and claim the amount bid by the poster.
Even though blockchain initially relied very heavily on users running partial or full nodes, the scalability quest has placed a populated network as a second priority compared to having a better consensus algorithm. This shift was probably unavoidable, considering that in the last few years the interaction with the internet is increasingly mobile-based. This change has also brought new limitations, and in this case specifically, transaction broadcasting. Currently, the most readily accessible public nodes for Ethereum are hosted by etherscan, MyEtherWallet, MyCrypto, and Infura. As of now, whenever a user wishes to broadcast a transaction based on an on-chain event, the accessible solutions are to run a local node and a script to listen for the specific condition, or to manually check for the condition and then broadcast the answer. This is cumbersome and impractical, especially for users and businesses who wish to generate several recurring and conditional transactions.
The Broadcasting Market
To create a timed transaction, users would need to set up a node and listen for events until their condition is met. After this, the transaction, created on the spot or beforehand, is broadcasted, and eventually included. This isn’t practical, especially for a mobile user. The solution could be to either create a dedicated service, or a broadcasting market. While in other cases a dedicated service would be more profitable and possibly reliable, it goes against the spirit of cryptocurrencies. Furthermore, a market version of this solution is more likely to survive over time and find fair prices for transaction queuing.
The buyers are agents supplying a tuple (T, C, P), where T is the transaction, C is the condition set, and P is the reward or price.
- Ethereum transactions, referred to as T, are described in two steps: raw and signed. A raw transaction describes what the transaction needs to do, and a signed transaction includes a cryptographic signature verifying the identity of the creator of the transaction.
- The condition set C supplied by the buyer is a prerequisite or set of prerequisites that need to be fulfilled before the transaction is broadcasted. These conditions might range from a minimum block number to a series of event invocations, balance changes, or general state modifications.
- The reward or price P corresponds to the ETH, DAI, token, or other asset offered to the first user to successfully have a transaction included in a block.
On the other hand, sellers have the resources (S, K(C)), where S is the processing speed and K is the cost to process a request.
- The processing speed S is the average block height that a seller takes between the first block after which the condition set C is fulfilled and the block in which the transaction is included.
- The cost K is the average amount invested to win the reward P of a transaction of with a condition set C. In general, complex condition sets are harder to track and process, making the difficulty of C at least proportional to K.
In order to find a match between buyers and sellers, there needs to be a marginal profit P - K(C) > 0. Since we know that K(C) ≥ αC, the reward offered by buyers need to fulfil P > αC. However, if the market has a high “spread”, we can assume that the processing speed S won’t be minimised to 0, yet the match will still be made. We can also assume that for two sellers i, j with speeds Sᵢ < Sⱼ and a fixed condition set C for transaction T, we also have Kᵢ(C) < Kⱼ(C). This means that after n blocks, some seller will meet the demand P - Kᵢ(C) > 0, even if the seller is the buyer matching itself.
There are still some details to be expanded, such as gas prices and transaction fees. Users, instead of choosing a gas price and figuring out execution gas prices, can set a price on their transaction and let the seller side optimise those parameters for them to include the transaction in the earliest block possible with the resources assigned. For example, a user posting a bid (T , null, 1 ETH) will find the transaction mined as quickly as possible, since the first seller will choose a gas price of G gwei, and keep a profit of 1 ETH minus the transaction fee at G gwei. If the transaction hasn’t been mined at speed 0, then another seller will try to raise the price to G+δg gwei, and so on until the equilibrium is met. Of course, setting a P of 1 ETH is probably excessive, but average users, instead of having to look into gwei prices, remote node availability, transaction cost, etc., they can simply set the price that the transaction represents to them along with the condition set C and let it happen at some point, optimising S under P by the sellers.
As mentioned before, there is an added benefit to creating a generalised transaction scheduler: user transparency to fees. Not only this, but the scheduler system could take some load off from public nodes and distribute that stress, as well as creating a slight incentive to run a validator node.
Beyond the simple cases with an empty condition set, businesses, and more advanced users could create scheduled transactions by block number without having to run a local node, facilitating time-based transactions. Furthermore, DAOs would be able to schedule a dividend payment call for every payout period without having to worry about stakeholders manually invoking the withdrawals.
Moving forward we could see more complex conditional transactions that could evolve into atomic swaps. A condition set specifying that the balance of a wallet W of the blockchain B needs to increase by a certain amount could trigger the release of a transaction. While this application is a holy grail of sorts, the implementation of it might take a long time before it happens, but sellers with good reputation could become oracles at the cost of losing their network status.
At the time of writing, I have developed the core code for on-chain scheduling, but there are many aspects that need to be roughed out. If it comes to it, we might have to do an ICO to create a native currency with the purpose of assigning reputation to the seller side of the market.