brucdarc
commented
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.
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.