Clearly, the current IC is not suitable for DeFi applications, lack of atomicity, no history transaction records, these are very important properties for financial applications, I think this is also the reason why DeFi didn’t grow much on the IC.
Developers are lost in these low-level details, been busy handling transaction log storage, async-await call safety, prevent ddos attack, constantly worrying about storage limit and cycles balance, can’t even really focus on the product.
To boost the IC DeFi ecosystem, what we really need is a DeFi subnet, ensured atomicity, with transaction history support(message call history, not ICP tx log), better if EVM compatible. Otherwise we’ll see DeFi still move very slow on IC, and potentially many security incidents at the early stage.
It would be nice to see a community conversation about this. I thought the slow pace for DeFi was related to other stuff on the roadmap like SNS, Bitcoin integration, and HTTPS request. Atomicity shouldn’t be a problem since subnets can talk to each other, right? I find it hard to believe something as important as DeFi were not planned for or figured that not having a dedicated subnet would be a problem. I am not a dev so a rudimentary understanding of the problem you just stated. So I am following.
Atomicity is one of the biggest problems of DeFi on IC.
No atomicity means cannot revert state changes during cross-canister calls, which will result in fund loss, now developers have to handle all this, but devs are very likely to make mistakes in asynchronous programming.
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.
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.
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.
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.
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!
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.
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?
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.
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.
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.
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.
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.
