If you separate an on-chain order book DEX into n orders (or a hotel reservation contract into n pairs of rooms and dates), doesn’t the UI app must watch up to n shards or potentially all the shards?
Even in the light client model, this requires O(n) network bandwidth, storage, and computation.
In general, I’m curious about what kinds of applications can be “yankable.”
I agree that Uniswap is not separable (i.e., can not be divided into small contracts), so should not be yankable because otherwise, there would be a lot of DoS attacks or nuisances.
However, even if a contract is separable, in some cases, it should not be yankable.
Examples:
- A DEX contract, which returns an average exchange rate of the orders (e.g., for other Defi contracts)
- A hotel reservation contract, which accepts reservations only if there are more than ten rooms available
These contracts have functions that depend on the application-wide state.
Yanking allows the state of each segment of these contracts (orders, rooms) to exist in any shard, so there is no guarantee that the above functions correctly works.
Instead, each segment of these contracts can be lockable (i.e., can be owned by someone temporarily and unlocked by certain conditions, but its state should not be moved to other shards), so we can use two-phase-commit-like schemes for atomic cross-shard operations.