I think you are right about general relativity, it really doesn’t matter. However, it is still not clear to me how could we possibly sort correctly (or even approximately) by sending time in a distributed application. If I send a transaction from Brazil and another person sends a transaction from Japan roughly at the same time, what process could be used to decide which transaction is to be included first? People in South America will see my transaction arrive first, while people in Asia will see the exact opposite. Who is to decide?
The best I can think of is having several trusted timestamping servers located all over the world, each of them running an atomic clock, and then have the blocks respect such timestamps, but I don’t see how we could have a decentralized way to assess the accuracy of these clocks.
What I think is the most important disagreement that we have, however, is on the nature of data corruption. You claim that transaction reordering is data corruption, but I think that depends on what the protocol is. If your application is receiving TCP packets out of order, that is data corruption. If, however, your UDP datagrams arrive out of order, this is not corruption, because UDP does not give you ordering guarantees. I think a blockchain like Ethereum does not and probably cannot give you any reliable ordering guarantees, and therefore that applications building on Ethereum should not rely on transaction ordering at all.
Of course, applications are relying on that right now, particularly DEXes, and that is what in my opinion is causing this much frustration. We see an alternative in which trades do not happen on chain, but rather are only settled on it. In this model, waiting even a few extra blocks for the settlement to happen matters very little, because the participants already received an off-chain trade confirmation, meaning that as they wait for settlement the participants already know both the trade amount and trade price. Moreover, it is possible to make sure that other transactions being included first will not cause the settlement transaction to fail. This way, if someone censors their transaction for a few blocks or reorders the block in which they are included, the trade price and amount do not change, and so there is little incentive for doing so.
I understand there might be some resistance to the idea of having to trust a counterparty between trade execution and settlement, but I think that is the natural order of things. When Hanyecz bought the bitcoin pizza, the trade was executed as soon as both agreed to it. The transaction being included on the block (as well as the pizza arriving at his home) was only the settlement part. Until both parts of the settlement were made, they had to trust each other.
One nice thing of smart contracts is that we can enforce settlement rules, so that if one is buying GNO with ETH, we can settle both the GNO and ETH transfers atomically, greatly reducing how much trust is needed. Maybe in the future we can use advanced techniques such as time-lock encryption (that can simultaneously be verified quickly) to allow fully trustless transactions with no frontrunning, but I don’t think we are quite there yet.
That is not true at all. The slippage parameter is just the Uniswap contract enforcing a condition in a simple way for users, but you could create your own smart contract to enforce this condition for you if you wanted. The uniswap pool price and liquidity variables are public, so another contract can just inspect them, calculate what the average price for the desired trade would be, and then decide to call Uniswap or not depending on that. Because regular users would most likely not deploy such contracts for them, they would get screwed with infinite slippage instead.
Even if Uniswap tried to prevent that by making these variables private this would also not work because the smart contract would still be able to make very small trades and look at the execution prices to reverse engineer the variables based on that.
Censorship resistance is an important property of Ethereum, but I think we need to interpret that narrowly. It does not mean that you should expect your transaction to always be included in the next block if you pay a significant tip. Rather, what it means is that, if you pay a reasonable fee, you should expect your transaction to be included eventually, maybe within 10 or 20 blocks. Most often you will indeed get it in the next block, just as UDP packets often arrive with the right order, but you shouldn’t rely on that.
I think I have not managed to explain our proposal correctly. We’ll be executing trades off-chain and then settling the trades on-chain later. Several minutes later may be totally fine, so that is dozens of blocks. A settlement transaction being censored for a few blocks won’t make much difference for us.
An user willing to trade at us will have to deposit his assets at a channel-like contract first. The transaction settling the trade will be using the assets that are ‘frozen’ in this contract. This way we don’t have to worry about the user withdrawing his assets and causing the settlement transaction to fail. Of course he’ll be able to withdraw his assets unilaterally, but that will take some time (like in a channel) to give us opportunity to settle all pending trades first.
So please let me know whether my explanation makes more sense now!