SparseSwap #159

yugure-orca · 2024-06-26T06:37:06Z

Problems

Uninitialised TA problem

The absence of TickArray causes the trade to stop
It is difficult to explain the problems caused by uninitialised TickArrays to users.
It is impractical to initialise a large number of TickArrays in a FullRange pool
It may be not sustainable to initialize many tickarrays by protocol (~ Orca)

Problems with the order of TickArrays passed to instructions

It is necessary to provide a TickArray containing tick_current_index as tick_array_0.
However, if there is a current price near the boundary of the TickArray, this condition may not be met because the price moves; it is a kind of slippage, but even if the slippage is increased, an error occurs in this case.

Solution

Accept uninitialized TickArray

swap, swapV2, twoHopSwap, twoHopSwapV2 will accept uninitialized TickArray account address.

These instructions will treat uninitialized TickArray account as if they are zero padded and process trade.

On-chain TickArray account order adjustment

swap, swapV2, twoHopSwap, twoHopSwapV2 will accept (maybe uninitialized) TickArray account address in any order and sort them as needed. If instruction receive required TickArray accounts, it should work.

Additional TickArray accounts

swapV2 and twoHopSwapV2 will accept additional up to 3 TickArray accounts via remaining_accounts.

This is V2 only because V1 doesn't use remaining_accounts.
The maximum number of accounts received will be six, but the maximum number of TickArrays used in a single trade will remain the same at three. This means that we can provide a backup TickArray in case prices move." The name "supplemental" comes from this use.

Implementation Notes

No breaking change on instruction interface

There will be no change in the accounts received by v1.
There are additions to the remaining_accounts that v2 will receive, but these do not affect the current program.

Switching AccountLoader to UncheckedAccount

AccountLoader can only accept accounts that have been initialized (or at least the owner program has been changed to initialize account).
Therefore, to receive uninitialized accounts, use UncheckedAccount.

The verification that was conventionally done via has_one needs to be done via handler.
Also, the verification done internally by load_mut() needs to be done the same way.

ProxiedTickArray

Add one abstraction layer, ProxiedTickArray, to minimize changes to the current battle-tested SwapTickSequence code.

For TickArrays that have been initialized, the process is delegated to the existing implementation. For uninitialized TickArray, the process is delegated to ZeroedTickArray where all Tick are zero initialized.

Notes: Heap size limination

Initially, we considered placing the entire 0-initialized TickArray account in the Heap and using RefMut to that account, but the Heap size limit is 32 KB, so we were limited to two accounts at most.

Since twoHopSwapV2 handles a maximum of six uninitialized accounts, this method could not be used.

On-chain TickArray account order adjustment

First, calculate up to three start_tick_indexes for the required TickArray and verify if a TickArray account with that start_tick_index is provided.

With this method, if an account is provided that has been initialized as it is now, no PDA calculation or pubkey comparison occurs, since matching is possible only by comparing the start_tick_indexes among themselves.

The PDA calculation is only performed if no account with start_tick_index is found among the initialized accounts.

Uninitialized accounts are verified as uninitialized.
The conditions for uninitialization are that SystemProgram is the owner and the data size is 0.

Whether the uninitialized account is a correct TickArray address or not is not verified because it is impossible to verify (we need to find seend for them). However, it is used only if it matches the correct PDA derived using start_tick_index. So wrong accounts will be simply ignored.

program can use up to 32KB heap

philcchen

Took a pass over the core logic code, will do another pass over edge cases and tests

philcchen · 2024-07-04T11:37:39Z

programs/whirlpool/src/state/tick.rs

    }

    pub fn check_in_array_bounds(&self, tick_index: i32, tick_spacing: u16) -> bool {
        self.in_search_range(tick_index, tick_spacing, false)
    }

    pub fn is_min_tick_array(&self) -> bool {
-        self.start_tick_index <= MIN_TICK_INDEX
+        is_min_tick_array(self.start_tick_index)


nit: I think it'd be possible to define a trait that could help de-duplicate shared code between ZeroedTickArray and TickArray, for example,

pub trait TickArrayType { fn start_tick_index(); fn is_min_tick_array(&self) -> bool { is_min_tick_array(self.start_tick_index()) } fn is_max_tick_array(&self, tick_spacing: u16) -> bool { is_max_tick_array(self.start_tick_index(), tick_spacing) } ... } impl TickArrayType for TickArray { fn start_tick_index(&self) -> i32 { self.start_tick_index } } impl TickArrayType for ZeroedTickArray { fn start_tick_index(&self) -> i32 { self.start_tick_index } }

(could even more the shared functions into the trait, since they aren't being called externally anyways)

cool! 🚀
updated with TickArrayType trait.

philcchen · 2024-07-04T11:56:16Z