Design Incentives

How do we deal with incentives for participation in an interaction?

What can be automated off-chain or on-chain, statically or dynamically? What interface do we provide for those bits that cannot be automated?

How do we deal with an event that multiple people may send, but only a few may be interested to actually send? Consider the closing of an auction, possibly a multiple-item auction with multiple winners. The seller and the top bidder(s) are the only parties left, so it's a closed interaction. Any of them are (or should be) interested in doing the final transfer. How do we align incentives in posting such a transaction?

We could somehow reward whoever posts the transaction to compensate for their gas fees. But if the reward is too high, there's race to post, with high fees. If the reward is too low, there's a chicken game, with high delays. If the reward is made proportional to the actual fee, a participant who colludes with a miner will vastly overpay. If the reward is made proportional to some fee estimation, then the chances that things will go wrong increase with volatility, which increases as interactions grow longer, even worse when they are indefinite open interactions. Furthermore, in any case where it is not clear who has duty to post, the uncertainty as to who will post and be rewarded or punished (depending on reward vs gas costs) itself increases the a priori economic transaction costs. For all the reasons, it's better if we always break the symmetry and assign the duty to post to some specific participant, whether statically determined by their role and/or dynamically determined by some PRNG (e.g. the latest block hash), and punish them based on collateral if they fail.

What do we do if there were more than two participants there? Do we pick some arbitrary order between participants, so that if one times out, there is a clear "next" participant? If there are lots of participants (tens? hundreds?), plus a timeout long enough to let them survive targeted DoS attacks (days? hours only with sufficient redundancy?), this can lead to very long timeouts. In this case, do we then allow anyone in a hurry to short-circuit someone else's turn and post the damn transaction? But then not punish the one whose turn it would have been? But then force the short-circuiter out of the rest of the interaction?

Whichever way the symmetry is broken, some participants may end up with the duty to pay a lot of gas for transactions that benefit others, and may legitimately ask the others to pay him some fee to compensate as part of the interaction. In a short closed interaction, the fee schedule (that may depend on future dynamic behavior) can all be negotiated offchain, together with timeouts, and then be enforced by contract. Or on more complex contracts can there be some dynamic on-chain auction for who's next? Can we automatically generate the software to negotiate the collaterals, timeouts, etc.? Can we then use economic modelling to automatically play this negotiation auction game based on expectations for gas costs?

There are issues here in language design and implementation, in economic mechanism design and modelling, etc.