We need a DeFi subnet

You likely know about this than me. Have we discussed this anywhere and is Dfinity not consider the issues you raise a priority? I am looking forward to reading what the rest of the community thinks. As an investor I will support whatecer is best for the protocol.

2 Likes

Its so weird the IC has so many dApps other chains don’t have (DSCVR, Distrikt, Taggr, etc…), but DeFi, the feature literally every L1 worth mentioning has, still is in an embrional stage. So many features missing and there is a lack of official support for it: no DEXes, no standard for tokens and NFTs, plus the stuff OP mentioned.

Its a bit disappointing Dfinity seems not to care about it, it almost seems from their point of view things are fine as they are considering the mid Q1 release on the roadmap is labeled as DeFi.

The community is coming up with its own standards for tokens and while its good to experiment with different solutions for the same problem I’m afraid the fragmentation it will create is going to be an issue in the future.

5 Likes

Perhaps the community should come up with a proposal to ensure that emphasis is put on DeFi. A mature DeFi ecosystem is just important as regular non financial dAPPs. I was under the impression that SNS would have the official standard for tokenization and atomicity wasn’t issues.

@dominicwilliams @diegop @dieter.sommer can one of y’all address the concerns here?

2 Likes

By looking at the roadmap it seems DeFi will become viable end of Q2: Full DeFi support and Single transaction / atomicity for swaps are listed a tasks for the Carbon release.

2 Likes

Would you mind explaining a bit more how that would work? Is the following correct?

If I create a defi app on a canister and it requires to call another canister I‘d await it‘s response. But if something would go wrong there, then I‘d need to handle that case and set back every state change that has already occurred on my app when the user called the public function on my canister.

Thanks everybody here on this topic for sharing your concerns regarding DeFi.
I can add some context to questions and comments on this thread:

Why is there not much DeFi on the IC so far?

One main reason for this is that it has not been possible for a long time after launch that canisters can transfer ICP tokens. The reason has been that we wanted to get certain security mechanisms in place before enabling this feature.
Currently there are multiple DeFi projects being actively worked on, e.g., InfinitySwap and Sonic.

The lack of a token standard

This is critique that we definitely need to consider. We consider the way that our ICP ledger handles tokens a way well aligned with how the IC works. It’s sort of an implicit standard. However, there is indeed no explicit token standard and others have come up with standards that are closer to ERC-20. Those standards are motivated by the similarity to what people know from the EVM universe, but have their own issues.
We are currently also thinking of how to make our ledger support an ERC-20-like interface in addition.
Overall, I agree that we should consider defining an explicit token standard to avoid further fragmentation of the market and give people a clear starting point when launching their own tokens. To my knowledge, a working group for a token standard will be formed.
In a later release (Carbon), as also mentioned in a post above, we plan to enable atomic swaps to better enable DeFi.

Asynchronous programming model

That’s how the Internet Computer works, and it is the only way to get a scalable blockchain. Chains that follow the synchronous programming paradigm have essentially inherent limits on how far they can scale. The Internet Computer, thanks to its multi-subnet approach and resulting asynchronous programming model, has solved those scalability problems.
Granted, programming in the asynchronous model is quite different than programming in the synchronous model. Developers would need to learn how to write secure smart contracts in the asynchronous programming model, and cope with the added complexity. Here, I think, it is also very valid, that we do not yet have good enough material to explain this to the developer community. This is probably something we should work on. We will have a sample dApp (a DEX) coming out shortly that showcases how one can build DeFi on the IC.

Getting to a synchronous programming model would be possible only by enabling one or a few specific DeFi subnets (maybe in the form of an EVM subnet) as proposed in a post, but of course at the cost of giving up other properties of the IC in those subnets.

Subnet with transaction history and atomicity

Actually, I am currently working with a small team on the question of how we can enable EVM support on the IC. Current thinking gravitates around one EVM-enabled subnet where people can run their EVM smart contracts with all the guarantees the EVM provides (synchronicity, transaction history etc.). This would allow for running existing EVM smart contracts on the IC or write your new ones in Solidity if you wanted to. More information on this feature will be provided on the forum.

At a high level, the reasons for DeFi not being strong yet on the IC are a combination of the following:

  • Defi has only recently been enabled on the IC
  • Defi is very early and has not taken off
  • Some of the friction points for DeFi listed in the comments of this topic are already being addressed
  • We are not sure some of the friction points for DeFi listed in socials should be addressed by the Foundation (maybe better via community)
  • Some of the friction points for DeFi listed in socials are already addressed but clearly sample dapps and docs are not good enough yet

Does this help address some of the concerns? Do you think the lack of synchronicity is an inherent problem in that it makes writing secure smart contracts impossible or just too hard (and error prone) for the typical smart contract developer? Maybe the latter is really also mainly caused by a lack of documentation, best practices, and examples.

How important is a record of all transactions, not just ledger transactions, for DeFi applications? Posts here imply very much. We would like to get more insight into the thinking of the community here. Also, it is clear that it is just not possible to keep such record for all of the IC, this can again be something that is only provided for a specific DeFi subnet, however this will materialize.

We are looking forward to continue this discussion with you with the goal of addressing your concerns and possibly getting further input on which work we need to prioritize!

17 Likes

Thanks for the reply! Glad to hear the foundation is working towards this direction.

The asynchronous nature makes it difficult to write secure smart contracts, sure more documentation and best practices can help with this. Also this makes defi on ic less composable, assume you want to build a defi app on top of 2 other defi protocols, once a specific operation needs to go through more than 2 canisters it’s hard to ensure atomicity, so we probably won’t see services like 1inch on ic.
Another problem is it’s hard to scale your service due to atomicity issue and storage limit, currently storage limit is 8g, hopefully one day the storage capacity will be high enough.

About tx record, I think it’s pretty important for defi applications, with a reliable tx log you can reconstruct the canister state of any given time, this is very important in case of hacking or canister data corruption/loss, you’ll be able to recover the state so funds can be safe. Though developers can build dedicated canisters for tx record storage and there’s existing service like CAP, but it’s still very possible to lose records, e.g. one day your storage canister is out of cycles. So native support for tx log is best and most reliable.

2 Likes

Your understanding is Correct

1 Like

The storage limit per canister is expected to grow over time, so this should not be an issue in the longer term. This 8GB limit is a conservative limit set currently, but more memory would be possible already technically AFAIK. The final per-canister limit is the subnet replicated state size, currently at multiple 100 GB.

Also I think 8GB is not so bad compared with other chains: Which other blockchain would give you close to 8GB of storage per smart contract for that price? :wink:

2 Likes

Your storage canister stay in a frozen state for a while before deletion though. So this shouldn’t be problem, unless the devs aren’t actively managing their dAPPs for a while. Thanks for starting the conversation.

think solutions to these problems exist within the IC without a need for a subnet that could fragment the attention and resources. Shouldn’t the focus be on improving the IC now rather than making it into another Ethereum?

lack of atomicity: Most real world financial transations are non-atomic. In fact Ethereum transactions are one of the few things that are synchronous. Synchronous blockchain are a limit to scalability. Yet the world is a distributed super-computer not just one thread of execution.

No history transaction records: Some form of scalable storage on the IC would solve this issue, why not implement this for the IC and improve the whole IC experience, rather than just a subnet. Lots of apps need scalable storage.

Agree on the async issues, we really need safe async calls, and why doesn’t this have a timeout for safety?

I think the other issues are challenging but they can be worked out, and will strengthen the IC. Build one IC, stronger together and less so with fragmentation. DeFi on the real IC and DeFi on the subnet will surely fragment the ecosystem.

11 Likes

In a later release (Carbon), as also mentioned in a post above, we plan to enable atomic swaps to better enable DeFi.

Could you explain how you plan on enabling atomic swaps? My understanding is that the asynchronous programming model inherent to canisters (i.e. cross-canister calls need to be manually rolled back) prevents purely atomic swaps.

1 Like

This one is a head scratcher to me. From what I’ve seen the only thing standing in the way of de-fi is proper architectural imagination and implementation. We have a piece of general purpose computing that can be programmed to do pretty much anything. There are a few things we still need exposed in motoko, but all the pieces are there. We need good tooling, standards, and patterns…but none of those require a new subnet at this time. Just hard work and imagination.

If you want transaction history, build it into your canister, merklize it, and publish an endpoint. If you want atomicity then create a canister where that can happen and interact with it.

If you want an EVM, build it. There are 0 impediments from building an EVM in a canister today. You just have to write keckkak in motoko, a Patricia tree in motoko, RLP encoding in motoko, write the op codes in motoko, and the precompiles. The list is long, but you can get paid to get started: ICDevs.org - Bounty #16 - EVM Witness Library - $8,000+

De-fi is coming. But what comes after will make you forget about it.

15 Likes

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.

There is another idea around that would use orthogonal persistence to address the issue: Only once both transactions are committed, the state changes are persisted. However, this has the huge drawback that an actor cannot process other messages until the state change gets persisted, so this does not really scale in my opinion.

2 Likes

Agreed, you can do most part of an EVM as an IC smart contract. However, it becomes tricky when we want to expose an Ethereum JSON RPC API to the outside world. This requires extensions to parts of the IC in order to accept ordinary HTTP(S) calls as update calls. Currently this only works for queries. However, an extension of the icx-proxy is currently being built that will allow a canister to “upgrade” a HTTP request from a query to an update call. Once this is in place, a fully EVM-compatible EVM can be built as a canister or set of canisters.

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.

3 Likes

This got merged a couple of months back:

There is some uncertainty around whether is functionality is live yet. I’ve been focused on other things and haven’t gotten around to trying it on the IC proper.

2 Likes

I’m not a great fan of Cardano but I wonder if it might make sense to borrow their idea of having an distinct asset settlement layer: Such a layer would

  • Hold ledger information about ownership of assets.
  • Hold Tx History
  • Execute transfers atomically e.g. by:
    • Checking pre-conditions. (existence, ownership, signature, agreement on pre-and post state)
    • Package all changes as Atomic commit. (exact mechanism ideally lock free TBD)
    • Checking post-conditions. (Actual transfer resulted in expected balance changes)
    • Success or rollback notification.

Rationale:

  1. Makes it easier to reason about ownership of assets.
  2. Atomic swap logic (pre and post condition checks) could be cleanly enforced at the interface.
  3. The settlement layer / computational layer distinction is likely to happen anyway due to BTC and Ethereum integration, so pattern is likely to evolve anyway and it is nice to have common way of doing all transfers regardless of whether they are native or non-native.
  4. Settlement layer can be optimised as pure settlement layer. In terms of performance, security, decentralisation, (optional) privacy and (optional) traceability and so on.
  5. Enforces standard and can be integrated at lower level.
  6. Governance is not necessary for a pure asset ledger. We can thus make it easier to reason about security risks of governance, as asset ownership would be cleanly separated from the ability of owners/SNS to upgrade canisters. The NNS itself could even be excluded from arbitrarily altering asset distribution.
  7. Storage costs of ledger entries could be free (with fee levied per transaction) ensuring that asset balances are not at risk of being erased if canister cycle balance falls to zero.

I imagine that the asset settlement layer would thus operate a bit more like a traditional blockchain, and could be designed to give people confidence that it is a rock solid extremely decentralised, immutable and censorship resistant settlement layer, while more advanced capabilities would exist in other layers.

2 Likes

Thank you for your thoughts on the settlement layer. Apologies for not coming back to this earlier, but I was too diverted with other work. When now trying to grasp the full understanding of what you had in mind, I do need to ask some clarifying questions back to you, hope you have some time to clarify where needed. The topic you are talking about may be core to DeFi on the IC.

Questions:

  • This settlement layer would host all assets on the IC, i.e., all fungible and non-fungible tokens?
  • When you talk about atomic transactions and atomic swaps, this particularly includes transactions between different tokens (ledgers) and tokens from different chains? If you could elaborate a bit more on what your scope here is, this would be extremely helpful.
  • In (7) you talk about canisters running out of cycles. Is your intention that the settlement layer be implemented in user space as canisters? Or do you have in mind to implement such settlement layer as an extension / modification of the IC stack? Some more insights into your thought process may be very helpful for getting a better view.
  • Assume we implemented a protocol that allows us to realize atomic transactions over multiple ledgers, would this be something that would realize (part of) the functionality of this settlement layer? I have been talking to some people about 2-phase commit and how we could realize this in the IC.
2 Likes

I was mainly thinking about fungible tokens. Simple Ethereum ERC-721 (single) and ERC-1155 (collections) like NFTs could be handled as well. But their metadata would be restricted to being a simple pointer to another canister so that all complex logic for content and so on would be hosted on another subnet.

I was mainly thinking about swaps within the settlement layer. But some kind of abstraction layer which allows a similar interface to be called atomic swaps between IC tokens and tokens on other chains would be very useful, though the logic there is likely to be different due to different latency and security assumptions.

Yes so the IC has a reverse gas model whereas most token or DeFi orientated blockchains have a fee / gas model. I’m advocating for the settlement subnet to have a fee model because:

  1. It is unacceptable for ownership records to be wiped because someone failed to pay the gas fee.
  2. Canisters running on normal subnets can pay fees for settlement layer transactions so users don’t actually have to think about gas.
  3. Without any form of fees we open the door to spam.

In terms of how it could be implemented. The easiest way short term is just to copy the ICP ledger subnet which AFAK operates in a zero cycle cost manner. Then add fees to message it. Long term I would see the settlement subnet having a radically different design for example a zero knowledge token ledger similar to Aztec

Atomic swaps within the settlement layer would be by a 2 phase commit mechanism built into the settlement subnet. For swaps with other chains I’m thinking of this as a separate feature of a convenience wrapper library built over the settlement layer.

1 Like