Move tracking Earn assets from DB to EarnManager

[matevz]

While reviewing #78 the following needs to be done to track user's shares on-chain instead of inside the ROFL database. This makes the chain the source of truth, avoids data loss in case of ROFL crash, improves privacy, because the backend doesn't have access to the complete history in the local DB anymore and having any discrepancy between the db and actual on-chain shares/assets calculation.

Proposed changes to EarnManager contract:

• add private mapping(address => EarnHistoryEntry[]) history similar to what we have in Accounting
  EarnHistoryEntry should have:
  • EarnHistoryKind kind
  • uint64 timestamp
  • bytes payload
• add getHistory() that is gated for specific user the same way as in Accounting.
• for EarnHistoryKind.DepositToPool and EarnHistoryKind.WithdrawFromPool the payload is ABI-encoded:
  • uint256 accountingHistoryIdx obtained by calling accounting.HistoryEntry[] _, uint256 total = accounting.getHistory(0, 0, token); accountingHistoryIdx = total - 1;. This binds the EarnHistoryEntry with the Accounting's HistoryEntry that contains amount, poolAddress and tokenId.
  • uint256 shares the change in user shares. Always positive. Check EarnHistoryKind to determine whether to increase or decrease the total users' shares value.
• push EarnHistoryEntry to user's history for each deposit here

  privana-services/solidity/contracts/EarnManager.sol

  Line 240 in 8677b91

  }

• push EarnHistoryEntry to user's history for withdrawal here

  privana-services/solidity/contracts/EarnManager.sol

  Line 302 in 8677b91

  }

• each time Pool's totalShares and totalAssets change (i.e. inside syncTotalAssets, withdraw, deposit), also record this in the pool's address history. The EarnHistoryKind.SyncPoolAssets payload is ABI-encoded:
  • uint256 totalShares
  • uint256 totalAssets
• While user's history is private, add getPoolHistory() public getter that returns pool's history entries. This way the privana-services backend can cache these values or UI can read it directly to compute the earned amount.

Ideally, we can then remove earn_transactions and compute cashflow data exclusively on the client side. The pool history is quite data-intensive, but it is public, so the backend can cache it.