cwgoes
commented
3 years ago For the initial version, we should not do this - transactions should come with an outer fee and gas price, not encrypted, and then an encrypted gas limit. When transactions are decrypted and dequeued, they should be executed until the gas limit runs out or execution is complete. Note that this will require a second queue since we do not know the gas limits when first filling a block with encrypted transactions.
It seems nothing can be done about transaction size for the time being, but we can allow inclusion of dummy data at least.
We'll have to order these queues carefully, e.g. first process any decrypted transactions to be executed, then decrypt transactions which can be decrypted, then accept new transactions only if and when the first two queues have been completely processed.
Also for the gas price we should do a second-price auction.
FatemeShirazi
To prevent spam and appropriately price execution costs, the base ledger's trade settlement system must charge fees proportional to the database read/write and compute costs incurred by transaction execution (all phases). Fees merely proportional to transaction execution costs, however, misalign long-term interests of system users and stakeholders, since proof-of-stake consensus security must be greater than (and thus proportional to) the amount of value transacted, since this is what could be gained by subverting intended operations (e.g. by bribing validators). For this reason, we should aim to architect a fee model which is at least in part proportional to the value of a settled trade (more similar to existing custody institutions, in a sense). That way expected long-term value accrual of the staking token will end up being proportional to trade volume (in an approximate sense) instead of execution volume, which is more likely to fund the requisite security.
What exactly the proportion is we can determine later - likely it will be quite small - but the tricky part from the design perspective is to measure the value of a trade in the first place. This problem certainly cannot be solved in general for a ledger which supports arbitrary state transitions and places no constraints on data semantics (i.e. value), and privacy features exacerbate the difficulty, e.g. private MASP transactions provide no information about the value transacted, and any attempt at a proportional charge by circuit change will result in data leakage if the fraction is known and the fee is sent to a public address. That said, it is much less critical to charge value-proportionally for transfers (though we should keep thinking about this), and much critical to charge value-proportionally for trades, which may often have partially public data (e.g. price, amount, tokens) by necessity of counterparty negotiation at the intent discovery layer. If there is some roughly proportional relation between trade volume and value of custodied assets, charging proportionally for most trades should be sufficient to achieve the value-capture / security proportionality which we need (this is a hand-wavy argument that should be formalised).
To that end, keeping in mind the additional design constraints of avoiding hardcoded order semantics on the base ledger and assuming that market conditions will change rapidly, one idea I have is to enact a kind of collective negotiation between the validator set and particular contracts (with particular validity predicates) on a sort of "fee-sharing" based on the particular semantics of that contract. The basic setup is as follows:
This process can happen quite rapidly and requires no ledger upgrades, although we should keep UX in mind. Another point to consider is the particulars of how contracts ought to "fee share" and whether they need to build in some flexibility in advance with this system in mind.
This is just brainstorming, thoughts welcome.
┆Issue is synchronized with this Asana task by Unito