We need a DeFi subnet

[ccyanxyz]

Your understanding is Correct

[dieter.sommer]

@ccyanxyz

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.

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?

[Forreal]

@ccyanxyz

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.

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.

[Maxfinity]

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.

[jzxchiang]

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.

[skilesare]

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.

[dieter.sommer]

@jzxchiang

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.

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.

[dieter.sommer]

@skilesare

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+

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.

[dieter.sommer]

@Maxfinity

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?

@skilesare

We need good tooling, standards, and patterns…but none of those require a new subnet at this time. Just hard work and imagination.

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.

[paulyoung]

@dieter.sommer

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.

This got merged a couple of months back:

feat: upgrade HTTP calls upon canister's request

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.

Feature request: map appropriate HTTP request methods to update calls

Is this live already? If not, what is the ETA? I’m eager to migrate my telegram bot to this interface and disable my own AWS-Bounday-Node (which had this feature for a year now… ;-))

The "Body does not pass verification" error from a Motoko canister

I’m still a bit confused as to if this is natively handled or if it only works with the ICX proxy. Will this get hit for any HTTP request that is not a get natively? My particular use case involves images and having them return in query time is pretty important. Waiting for consensus is going to make the page crawl.

Feature request: map appropriate HTTP request methods to update calls

Hey @paulyoung,I see it has been merged into icx-proxy. But I use the following method to deploy on the main network, but it doesn’t work. Do I need to do anything else? Or must it only be used in icx-proxy? public query func http_request(request : HttpRequest) : async HttpResponse { { status_code = 200; headers = []; body = Text.encodeUtf8("Response to " # request.method # " request (query)"); streaming_strategy = null; }; }; public shared func http_reque…

Feature request: map appropriate HTTP request methods to update calls

I am fairly certain this hasn’t been rolled out. I checked the update logs and I know for sure about an unrelated issue blocking production upgrades. I will pull the built binary to ic stop gap repo. & update this thread when prod is up. (This week)

[Hashimoto]

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.

[dieter.sommer]

@Hashimoto

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

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.

[Hashimoto]

@dieter.sommer

• This settlement layer would host all assets on the IC, i.e., all fungible and non-fungible tokens?

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.

@dieter.sommer

• 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.

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.

@dieter.sommer

• 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.

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

@dieter.sommer

• 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.

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.

[skilesare]

I still don’t understand why all of this can’t be done with the current canister configuration.

@Hashimoto

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.

Deposit an NFT or tokens to a canister, do atomic swaps, Withdraw tokens or NFT.

@Hashimoto

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.

Once these can be wrapped on the IC with ECDSA you can do the same as above.

@Hashimoto

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

Just add fee code to your swap canister. If the ICP is deposited on your server you control it and the contract can take fees.

@Hashimoto

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.

Again…you can do a two phase commit with a canister today. You can even add heartbeat and have withdrawals sent automatically back to the source chains.

I’d be happy to do an architecture session where we hash this out so I can better understand what the perceived issues are.

[dieter.sommer]

Dear forum members!

Triggered by, among other things, the discussions in this forum topic, we decided to start a DeFi initiative for the IC. The higher intent of this initiative is to help the Internet Computer and its community grow and be successful. The concrete goal of the initiative is to fully enable DeFi on the IC. We think a good approach to tackling this is as follows:

• Investigating what is missing for fully enabling DeFi on the Internet Computer, particularly also by considering community use cases and their requirements.
• Proposing different options on how to proceed w.r.t. DeFi on the IC.
• Agreeing on a roadmap for fully enabling DeFi on the IC.
  Once we have an agreed-upon roadmap of prioritized features, we can execute it and implement its features, thereby removing existing barriers to DeFi on the IC.

The forum (you!) will be a major source of input for this initiative – in the end we need to enable you to build the dApps you have in mind. We intend to intensify the discussions here so that everyone who has an opinion can speak up and voice their opinion. We are also planning to run a workshop with the community to go into further details regarding the major issues to address as part of this initiative and get an aligned view on it.

As the IC is an asynchronous system, the architecture of DeFi dApps on the IC will have some inherent differences to that on a synchronous system (unless the community builds an EVM for the IC ), please also keep this in mind. Knowing about those differences will also be instrumental for a deeper understanding of how DeFi on the IC is best done.

Here is a current list of issues we have seen mentioned so far:

• Token standard (WG launched)
• DeFi on asynchronous architecture
• Inherent limitations of asynchronicity
• Atomic multi-canister transactions, 2PC
• Token standard
• Transaction logging facility
• Best practices, HOWTOs, examples
• DEX patterns
• Limitations of asynchronous architectures for DEXs
• Dedicated DeFi subnet
• Stablecoin(s)
• Asset settlement layer
• Integration with Web 2.0: direct HTTP calls from canisters and oracles
• Integrations with other blockchain networks
• X-Chain DEXs
• Making the IC the global DeFi hub
• EVM on the IC
• Ledger DoS protection
• Ledger scalability

Thank you already now for further participating in the discussions!

[jzxchiang]

Whoa, this is a lot of stuff.

I think it’s a great idea to set up this initiative. It will be difficult to move forward on some of these issues without leadership from DFINITY, in my opinion.

[dieter.sommer]

Indeed, this is a long list of potentially relevant / interesting things. The idea is to use this as a starting point for discussions with the goal of figuring out what we need to focus on – we have limited resources that we need to spend in a best-possible manner. The DeFi initiative is something that will have a defined end, so we need to distill a list of features we want to build as part of this initiative in order to improve DeFi on the IC. Input from the community will be crucial to get there.

[ildefons]

@dieter.sommer

The idea is to use this as a starting point for discussions with the goal of figuring out what we need to focus on

Maybe just asking to existing teams developing DEX Dapps like Sonic and others would be more to the point than opening a discussion in the forum

[dieter.sommer]

@ildefons

Maybe just asking to existing teams developing DEX Dapps like Sonic and others would be more to the point than opening a discussion in the forum

Good point! We plan to have discussions with those stakeholders. But it’s important that everyone can voice their opinion in order to get a comprehensive picture and not limit to people already having a large DeFi project going.

[dieter.sommer]

@skilesare

I’d be happy to do an architecture session where we hash this out so I can better understand what the perceived issues are.

This sounds great! I am planning to invite for a DeFi workshop to discuss various aspects of DeFi. Maybe this “architecture session” could be part of this workshop.