We need a DeFi subnet

[marc0olo]

@dieter.sommer

One possible mechanism to implement this would be 2-phase commit. This can be implemented as part of the execution layer of the IC. In an example scenario, we would make 2 calls to other canisters and
only if both return with success, we send a commit, otherwise we abort.

what if the called canisters would also call other canisters in such a scenario? I am wondering what happened with this idea

@dieter.sommer

One thing we clearly need to put more attention on is developer experience, guidelines, and best practices. This would likely solve many of the problems addressed in this thread. We recognize this deficiency and are currently putting some efforts into this. Specifically for DeFi, concrete examples, guidelines, and best practices will help the community a lot to write DeFi dApps on the native programming model of the IC.

100% agree. this statement still applies

@dieter.sommer

This example shows that there is no need for system support for atomic transactions over multiple canisters to realize an exchange that closely resembles a real-world exchange as this can be done by regular canisters without any issue. It’s important to note that there is a difference to how things are done in a typical EVM-based DEX implementation, but we can implement a much more real-world exchange than on most other chains. Importantly, there is no weakening of the trust model by the DEX having custody of the funds for some time as it is a smart contract that people can publicly audit and that they need to trust anyway when using the DEX.

I think I am more in the atomic transactions camp. this might be a harsh question, but why would I as a user prefer a DEX on ICP over a CEX if there are more or less the same risks involved? (actually the risk on a DEX might be even much higher)

a similar question comes from the developer side. why go through all the pain and risks involved in developing a reliable DEX in this async world that aims to target the masses? actually I would love to hear (again?) from existing builders what they think about all of this after more than 2 years. (cc @ICPSwap @KongSwap @bitbruce @simpson, @memecake, @timo)

a short summary of (IMO serious) issues that I recognized so far:

• possibility of canister deletion
  • cycle drainage
  • no default possibility to track cycles balance
  • misuse of freezing threshold (set too low)
• lack of knowledge about ICRC-1/2/3 standards and index canisters (that’s a matter of improving docs, libs & guides/explainers/…)
  • specifically the importance of ICRC-3 (block-log) for traceability of the history
  • keep in mind: again, all canisters could be deleted and typically need to be monitored and maintained
  • what ICRC-1/2/3 implementations can I as a DEX (or other DeFi related dapp) “trust”? how to verify the code of “custom” implementations? (I am probably better off only supporting the “official” reference implementation of DFINITY)
  • who is the minting account and can I trust it?
• canister control issues (for ICRC-1/2/3 ledgers and also DEX canisters)
  • what’s the path between single controller & SNS?
  • again the trust issue: can and shall I even “trust” an ICRC-1/2/3 implementation where there is a single controller defined?
  • is blackholing a possibility to “solve” this? what are the possible consequences and risks associated with blackholing? (to a certain extent this depends on the implementation details)
    • is it “safe” to blackhole the my ledger suite (including ICRC-3 archive canisters) if I am certain that I do not want to perform a future upgrade and I assume the community will take care of topping the canisters up with cycles?
• lack of atomicity (I think this has been discussed enough here already)
  • I think the biggest “issue” here is that it is very hard to compose a function set of many independent canisters (why would I even want to rely on a 3rd party canister where I know its code and state can be changed or removed anytime)

there are other things to consider when it comes to adoption, e.g. simplifying the “bridging” experience for ck assets or providing (better) guidlines and tooling how to integrate und use the signer standards.

I am also wondering what happened to the efforts of Annoucement: HPL - a ledger for 10k tps

same question about the idea of user-paid messages.

I think it is time to pick up this topic again and I would love to hear as many opinions as possible on this matter, especially from those that are actively working on DeFi related applications or integrating with ICRC-1/2/3 tokens on the IC. thanks!