search

vacp2p / research

Thinking in code
MIT License
62 stars 4 forks source link

SWAP Accounting - suggested next steps #71

Open oskarth opened 3 years ago

oskarth commented 3 years ago

Discussed in https://github.com/vacp2p/research/discussions/61

Originally posted by **oskarth** March 4, 2021 # Context Currently we have a hacky PoC for doing SWAP accounting and settlement. It consists of: 1) Alpha/Raw spec https://specs.vac.dev/specs/waku/v2/waku-swap-accounting 2) Separate swap-contracts-module with JSON API and smart contracts written by Swarm team https://github.com/vacp2p/swap-contracts-module 3) Basic nim-waku integration spike/tests with SwapStore accounting https://github.com/status-im/nim-waku/tree/master/waku/v2/protocol/waku_swap and https://github.com/status-im/nim-waku/blob/master/waku/v2/protocol/waku_store/waku_store.nim#L330 4) Basic nim-waku integration spike with Swap and swap-contracts-module with Hardhat local node https://github.com/status-im/nim-waku/blob/master/tests/v2/test_waku_swap_contracts.nim It shows that the general approach seems reasonable and there are no major technical blockers. ## Problems However, it is quite far from being usable: - Hardcoded assumptions - Not deployed on testnet - More of a spike than something fully integrated - Need more theoretical/rigorous analysis (different states and how to act in various scenarios, etc) ## Suggested approach How should we proceed? Considering the time it has taken to get to this point, and other competing projects/priorities, it seems useful to integrate it tidy it up as chunks that can be integrated more fully and used. We can break down the work into separate phases, with the goal of each making it into a testnet: 1) Soft - accounting only 2) Mock - send mock cheques and take word for it 3) Hard - blockchain integration deployed to testnet (Goerli, Optimism testnet or similar) At each phase, the spec could be essentially in draft mode, with implementation corresponding with spec. For soft mode, we keep track of accounting state. This is already done, but it isn't something that is visible for end users of e.g. chat2 chat and used by default in cluster. This makes it harder for other people to grasp and get an intuition for, and to build together on as a team. Acceptance criteria here would be to show the imbalance in accounting, and print logs when a peer is "out of bounds", either direction. This can then be enabled by default on store protocol, and show the imbalance as part of accounting metrics. This also allows us to see how general this design is, e.g. for using it in combination with other protocols. The theoretical study can probably be done in parallel, and might make sense to have as part of the "mock" phase to make sure the state and transitions are sound (e.g. https://github.com/vacp2p/research/issues/58 or similar). Then the "hard" phase would be more about smart contract deployment, key management and similar, which likely would overlap with similar work re RLN and similar. --- Curious to hear what people's thoughts are on the above, and how to break it down into smaller integration steps. Also welcome any questions or concerns re general approach, how it works and can be extended, etc :)