powerloom / snapshotter-computes Goto Github PK

Describe the bug

The aave base and aggregate snapshots are failing to recover after a stoppage on the anchor chain. The aggregate snapshots are not being properly built due to inconsistent historical data retrieval across the master nodes.

Additional info:

The retrieval failure for the aggregate snapshots is caused by the lack of finalization for the base snapshots. The base snapshots are being processed correctly, and they are then sent to the conduit relayer, but they are not being seen by the smart contract and therefore can't be finalized.

To Reproduce

Affected versions: aave branch

Expected behavior
The nodes should retrieve past epoch data from ipfs and build correct snapshots when they are reset.

Proposed Solution
Need to look into what is causing the issue. Will update when cause is found.

Update:

Increasing the throughput for the relayer endpoint should allow for all base snapshot submissions to be correctly sent to the protocol state contract. Once finalized, these snapshots will be retrievable by the aggregate processors and fix the data retrieval issue.

Is your feature request related to a problem?
Pooler was built for Uniswap liquidity pools, but the same techniques can be used for snapshotting data for other protocols
like Aave. Expanding functionality to Aave allows for not only snapshotting a new source of liquidity that users may be interested in, but also the potential to combine Aave data with Uniswap data for higher-order aggregates and building advanced trading strategies.

Describe the solution you'd like
I will implement a basic compute library targeting Aave Pool and AToken data. The snapshot will consist of liquidity and debt amounts along with their associated rates and Aave index values. This snapshot should serve as a solid foundation for expanding aggregates in the future.

Describe the bug

The current uniswapv3 implementation does not compute the correct "total value locked" for liquidity pools in ./total_value_locked.py's caclulate_reserves() function. Additionally, calls to the UniswapV3 helper contract's getTicks() function are very expensive, and they will currently be unnecessarily duplicated if called in multiple processes.

To Reproduce

Affected versions: uniswapv3 branch

Steps to reproduce the behavior:
To reproduce, run the pooler/tests/test_tvl.py test. This will fail due to inaccurate computed reserves.

Expected behavior
test_tvl.py should pass, indicating that the tvl calculation is within accepted accuracy.
get_tick_data() in ./total_value_locked.py should successfully store ticks on the first call, and retrieve cached tick data on a duplicate call.

Proposed Solution
The current calculate_reserves() function retrieves and calculates duplicate ticks. I will change it to get each tick only once.
Calculate_reserves() also does not properly combine batched tick retrieval calls, leaving half of the retrieved ticks unprocessed. I will fix the tick processing to include every initialized tick in the pool. Additionally, storing tick data using the given redis connection will be added.

Caveats
None

Additional context
issues brought to my attention by @getjiggy