[oracle/swap] discussion topic on oracle/swap mechanism

[Hyung-bharvest]

1. Current structure of oracle/swap

• Current oracle/swap function execute instant payout of swap transaction with most recent oracle price rate.
• Oracle price is outdated(maximum around 15minutes) when swap execution happens

2. Weak point 1 : unnecessary cost upon LUNA holders from frequent arbitrage opportunities

• Because of short term(<15minutes) volatility of LUNA market price, arbitrage opportunities are frequently created even though when terra tokens stay at target stability price.
• Those arbitrage trades does not help stability of terra token prices.
• Those profit earned by arbitrage traders will result in costs of community caused by minting activities with unfair swap prices.(put it another way : swap price deviated from fair market price)

3. Weak point 2 : relatively easy oracle price manipulation attack vector

• The oracle voting timing and price are fairly observable and predictable in real-time.
• The timing and price are dependent to very instant moment, which is relatively easy for manipulators to intentionally distort the instant market price of LUNA.

4. Possible suggestions on oracle pricing & swap execution mechanism

• Gather swap requests during an oracle period without swap price or immediate execution.
• At the end of the oracle period, determine swap price by VWAP(volume weighted average price) during the recent oracle period and distribute all swap transactions requested during the oracle period.
• Maximum amount of swap requests in given oracle period should not exceed X * current_oracle_period_volume_sum. X can be determined by governance which should be less than 1.0

5. Effect

• Prevent unnecessary arbitrage opportunities which will result in cost of community.
• Prevent market(hence oracle) price manipulation.
• Limit on swap amount for each round for sounder practice of swap functionality.

I hope this topic leads to fruitful discussion among validator community members for better possible adjustment strategies.

[hanjukim]

Oracle update is scheduled in next release. Here's our thoughts:

1. Swapping cap to every denoms as well as luna
2. Introduce swapping spread

Decreasing voting cycle to shorter period is another consideration.

[Hyung-bharvest]

@hanjukim

Thanks for the information. Even though the suggested methods does not ultimately prevent manipulation, it might help to cap the sudden huge swap function manipulation, ONLY IF the cap percentage decrease significantly.

Currently the cap for LUNA minting per day is 1%, which is 30 million dollars based on current LUNA market price in Coinone, which is quite enormous amount for untested functionality. Therefore I still think current cap parameter is very risky to launch the swap market.

[joe-bowman]

Thanks for starting this conversation @dlguddus.

I have also potential vectors for abuse with the current oracle system.

1. There is no incentive presently for the a validator to not wait until immediately before the voting period end, view the current votes and submit a vote that is the mean of the existing votes. This will ensure the validator always receives maximum rewards.

2. As noted in Implement voting right delegation for oracle #148 between @hendrikhofstadt and myself, similar to the above there is no incentive to not centralise the price feed to a single provider. Every validator votes the same, and everyone receives rewards. This is not in the best interest of the network.

With regard to the above, (1) is solved by using blind voting. That is, the votes of other voters are not visible until after the voting period ends. This is trivial to implement in terms of removing output from the cli/lcd, but anyone watching the transactions will still have visibility of this; so we'd need a cryptographic method to do this. And I haven't figured that out yet 👍

In response to (2), rewarding all validators who vote incentivised decentralisation, but doesn't disincentivise attempting to manipulate markets. Slashing would disincentivise this, but feels like a disproportionate punishment for a single awry vote (external services can't be relied upon, of course).

I have some thoughts around this, mostly around temporary bans from voting (and thus reward claims) for repeat offenders and will update later.

[hendrikhofstadt]

With regard to the above, (1) is solved by using blind voting. That is, the votes of other voters are not visible until after the voting period ends. This is trivial to implement in terms of removing output from the cli/lcd, but anyone watching the transactions will still have visibility of this; so we'd need a cryptographic method to do this. And I haven't figured that out yet +1

I could imagine a 2-phase process where,

1. Everyone pushes the hash of their vote
2. Once the phase has ended, everyone reveals the preimage/vote

As long as we include a random nonce in the votes and use a preimage resistance this could mostly solve the issue 1).
We also need to reward every voter for revealing their vote or slash for not revealing.

[Hyung-bharvest]

Thanks for bringing up another pain point. Hendrik's solution generally solve the problem but seems little bit complex. There should exist easy terracli method to mitigate those functionality imo.

We also need the precise target consensus of Oracle price. Because we (will) have various exchanges to trade Luna and also the price changes during the Oracle voting period, we need a consensus that which price rule(something like volume weighted average price of voting period, how to average up different exchanges, how to deal with extremely over/under-priced exchange, etc) we should target to vote. Terra team can just let validators know the price rule.

[joe-bowman]

Once the phase has ended, everyone reveals the preimage/vote

Do you consider breaking the voting period into two phases then? A vote phase, and a reveal phase.

E.g.

Period is p blocks long (where p is currently 140 blocks iirc)

VotinPhase Starts at height h
Validator A votes, sends hash
Validator B through Y vote, send hashes
...
VotingPhase ends at h+0.75p
RevealPhase begins at h+0.75p+1
Validator Z votes, sends hash, is rejected (too late; no penalty, no reward)
Validator A, reveals - matches hash
Validator B, reveals - hash doesn't match (they have been dishonest)
Validator C - X reveal, matches hash
Validator Y doesn't reveal
RevealPhase closes at h+p blocks.

Multiple infractions here:
Validator B is slashed for dishonesty (to the same extent as double signing?)
Validator Y voted but didn't reveal (could have intentionally withheld, but also could be network latency (or some other non-intentional action) - slashing here seems harsh
Validator X vote was valid but outside of +/- 1 * stdev() from mean - slashing here also seems harsh if we want to ensure diversity of input (and exchanges can fluctuate a LOT in a 15 min period too) - we don't want everyone to come from the same source.
Validator Z didn't vote - no punishment

A, C-X should receive some reward for voting (maybe 0,.25 of reward pool / validators), plus A, C-W should some additional element for being within 1 stddev of mean (0.75 of pool / validators)
B should be slashed for dishonesty
X (extreme vote) + Y (withheld reveal) added to a list like downtime, where multiple infractions T over period P incur smaller slashing.

Values are somewhat arbitrary at the moment.

@dlguddus - I do think in needs to be more complex though in order to avoid the kind of attack vectors we see today.

[hendrikhofstadt]

Yes exactly Joe. Very nice write-up 👍

I agree that we should reward everyone who reveals a vote instead of slashing. That incentivizes revealing the true preimage/vote and encouraged diversity. The incentive could still be higher proportionally to how close the vote is to the weighted median.

We probably don't need to slash for revealing the wrong preimage but rather just let the tx fail i.e. be rejected before it is added to the mempool.

[dokwon]

@joe-bowman only problem i have with the bipartite commit / reveal vote scheme is that every oracle price commit has a 1 period delay. So during times of extreme volatility we will likely trade off price-responsiveness for vote confidentiality... can anyone think of a scheme with a more optimal tradeoff?

Suppose trivial way to do this is to drastically shorten oracle vote periods

[Hyung-bharvest]

I close this issue because many of the suggestion has been implemented in the codebase.