Open brucdarc opened 2 years ago
In this model, all waiting users will share an additional portion of the total fees others have elected to pay. This "Ante" would start at 0 and increase linearly with time, starting after a Δt time later after another participant pays a fee. (This wait time before the ante starts increasing is to prevent attacks where a malicious party would add a super large fee, then relay the block themselves, causing them to gain the immediate increase in ante by everyone else.) This ante would increase up until a maximum value per waiting participant. (My thoughts on what this value might be: 2-5% of the total paid fees per user at maximum timestamp.) By fixing this value per participant, this also means that the bridge would operate faster with additional users, and if the bridge had few users, they would not be charged exorbitant amounts for the ante. Participants would only need to pay the difference between the ante and their paid fee. I.e., the user pays nothing additional if the ante is bellow their paid fee, and pays the ante value if the ante is above their paid fee. The ramp up of the ante over time allows the relayer market to find the optimal value for relaying, and also means that waiting users will contribute less overall if some particular participant puts a high fee to get the block relayed quickly. Said another way, the longer someone who has paid a moderate or high fee waits, the more the other waiting participants help contribute them contribute to the block being relayed. Of course this needs a maximum per user so that in cases of very few users waiting those users are not made to pay exorbitant fee by another participant who wants to get their transaction through very quickly.
This fee model helps to solve the tragedy of the commons problem by creating a more direct impact on the fee amount paid and how quickly the next block is relayed. If someone has a high willingness to pay to cross the bridge faster, their fee will contribute to the ante increasing faster, directly causing the block to be worth relaying sooner. This is also not unfair to those paying the ante, since they pay a much smaller amount towards the relaying than the participant who had a higher demand for their transaction to be relayed.
Additional mechanisms could be introduced to improve this model. Such as discounting the ante on those who do pay a fee to further incentivize contributing to the relay. However, I do believe that when it comes to smart contract systems, making the solution simpler instead of more complex is often better for the protocol, so perhaps the most bare bones implementation of this approach could be best.
As I stated earlier, I plan to add more examples and visual aids to this proposed model. If you're reading this and have any questions, please shoot them at me! A text and theory only explanation is often the worst in my experience, but I am throwing this up here so I can expand on this from here.
Lets run an example.
Alice wants to cross the bridge.
The current cost for a relayer to be willing to relay a block is 100 tokens.
There are 40 other people waiting to cross the bridge currently. For simplicity's sake lets assume to worst case senario and say that they are all freeloaders and do not care at all when their transaction crosses the bridge.
The maximum charge for the ante is 5% of the fee pool. The time to reach maximum is 3 hours.
Alice submits her transaction with a fee of 50 tokens.
A grace period of 5 minutes is extended. (This period allows for relayers to relay the block if Alice had contributed enough for the block to be relayed on her own. This prevents attacks by submitting large fees then relaying the block yourself.)
After 5 minutes, the ante starts to increase linearly for all waiting users.
After 45 minutes, the other 40 users are paying 1.25% to match toward Alice's fee. This totals to 25 tokens, or .625 for each user. The total relay bounty is now 75 tokens.
After 90 minutes, the other 40 users are paying 2.5% to match toward Alice's fee. This totals to 100 tokens, or 1.25 tokens for each user. The total relay bounty is now 100 tokens.
A relayer picks up and relays the current block from the harmony blockchain. All 41 users including Alice are now able to verify their transactions using the MMR of the harmony epoch, and the merkle root of each block.
The users call in on the ethereum side of the bridge to complete the bridge crossing and unlock their tokens on etheruem.
The total fee paid by Alice was 50 tokens. Each other user only paid 1.25 tokens.
Alice's fee had a multiplier of 200% toward the bridge fee.
Alice still paid significantly more than the other users in the system. This reflects her high willingness to pay to have her transaction relayed.
The amount Alice paid for her fee had a direct impact on how soon her transaction crossed the bridge. Alice's transaction would have been relayed later if she paid 40 tokens and earlier if she paid 60 tokens.
Other users only paid a small portion of what Alice paid, while still contributing to the fee.
All the numbers in this example could be adjusted as necessary to find what we think is an optimal setup for efficient bridging. Don't necessarily think of the times, prices, or number of users as what we might see in the real operation of this system.
Due to the efficient nature of merkle mountain ranges, transactions on harmony only need one block relayed later in the epoch in order to be verified. This introduces a tragedy of the commons situation to the game theory/economics/incentives of the bridge under a traditional fee model. The severity of this problem would depend how exactly how expensive relaying harmony blocks to ethereum is.
Unless the fee from a user is enough to bring the total bounty for a block relay over the threshold where a relayer will then relay it, the fee amount only indirectly has an impact on when the transaction is relayed. This situation is at its worst for the first transaction after a block has been relayed.
Conversely, a user paying the lowest possible fee will still have their transaction relayed if others come in paying higher fees. The most extreme example being one participant paying the whole relay fee alone to confirm that an important transaction will cross the bridge as fast as possible, and the others crossing the bridge for free.
This is in essence, the freeloader problem associated with the tragedy of the commons, with the commons being the combined bridge fee that needs to add up to enough to incentivize a relay to relay the block to ethereum. Even if this does not happen significantly and the relay threshold is low, this still has the potential to add latency to the bridge if some participants fully understand the economics of the fee model.
The fee model I am proposing solves this problem with an "Ante" type of system to boost incentives for users to pay higher fees. More details on this including examples and perhaps some graphs to follow on this issue page soon.