It would be interesting to have some concept of remote smart contract proxies in the IC. For example, wrap Ethereum smart contract with IC IDL, then add it to dfx.json as a special proxy canister. So from a developer perspective it will really look like any other canister, just runtime execution will be done remotely. Sure, the canister will need to have an associated wallet with ETH to pay for the gas.
If my understanding of what you have in mind is correct, this functionality is something that the Ethereum integration would bring: IC smart contracts can call Ethereum smart contracts (and also Ethereum smart contracts can call IC smart contracts). What you suggest would be one sleek way of exposing the Ethereum smart contracts to the IC.
Could you elaborate a little more on this idea? From the current text, my understanding is that you would would “authorize” on Ethereum the use of Ethereum assets (tokens) on the IC and then use them on the IC.
In my view this could work as follows, for example: On Ethereum you would transfer some ERC-20 tokens to an IC proxy contract, i.e., authorize their use on the IC. Then, through the native Ethereum integration, we would get those tokens over to the IC, analogous to wrapped tokens, and can use them. At some point the current owner of the wrapped tokens can return them back to the Ethereum network. Is this what you have in mind?
Indeed, it was a tough decision to not pursue this feature from the side of the DFINITY Foundation due to focussing our resources on IC-native DeFi. It would be great if we would be able to find people in the community interested in building this and funding their work through grants.
Anybody here who things they (with a small team) would be interested in taking on a huge project on grants and help make the EVM on the IC a reality?
As bullish as I am with IC defi, the market is definitely showing a MASSIVE amount of interest for EVM chains. With the capabilities of the IC, it would be an absolute monster. I’d imagine more devs and more users coming in, so I really am bummed this is being ignored by Dfinity. Heck, this should be a proposal to let the community decide.
That’s far and at least Dfinity is offering a grant for this. On the other hand, seem as though it’s something that could come sooner if done by Dfinity, but we’ll see if a team takes on the challenge.
Dfinity Grants are excellent way to kickstart the IC project, but I do not think they are long term solution for infrastructure projects like this. First, you need top-notch developers, EVM has to be extremely stable, efficient and secure. Second, long term cost of maintenance (support, patches, upgrades) is much higher than initial development. So now we should talk about business model behind EVM, is there any? It has to be open source, cannot charge for it. Maybe there is other potential source of revenue. I am just asking, because facing similar issue, working on Java Agent SDK. We received Dfinity grant and we are grateful for that, huge help. But looking for sustainable way how to maintain the project long term. I know, SDKs Adapters are not big money makers, nobody makes money on MySql JDBC adapter for example.
The Evm could use something like the ARAMAKME license and get cycles for every transaction that goes through contributed to a development dao. Once cycles get valuable it would be a decent form of capital for maintenance and improvement proposals. Some folks don’t like the idea, but I think this is a perfect example of where it makes sense as long as we can make sure it is decentralized enough.
Interestingly, teams on other platform were able to raise quite some money, but I haven’t dug deep on their model:
So, could be interesting for a team to take on this challenge
Secondly, it might be possible to spread some of the maintenance work, e.g. Aurora uses SputnikVM, the Rust implementation of the EVM (mostly) maintained by ETH Classic. This might be a basis for ICEVM as well.
After giving it some thought I’m not completely sure an icEVM would provide significant benefits and attract devs from other ecosystems, don’t get me wrong I’m very much interested in the possibility of having an EVM on IC, but I can’t help having some skepticism, why is that:
icEVM would be a huge endeavour, it’s most likely a multi year project, time and money that could be spent working on other projects aimed at making the IC dev experience better instead of porting legacy tech, which might potentially fragment the ecosystem and damage interoperability by encouraging newcomers to rely on EVM instead of leveraging the new cutting edge stuff built by Dfinity.
icEVM will have many drawbacks, some fixable other not so much. Dieter explains all of them in the presentation, a brief summary: a single canister icEVM will obviously be limited in tps and scaling it will be complex, some easier solutions are possible (sharding) but at the cost of interoperability, running in a canister means there will be an overhead, tokens will have to be wrapped, etc…
While the idea of having everything you need on 1 chain is compelling, there is always the risk of becoming a jack of all trades and master of none, in case of ICP why would devs want to use our icEVM instead of Polygon’s zkEVM? It inherits ETH’s security and decentralization, which is unmatched and largely superior to ICP’s while providing the same level of scalability as icEVM if not greater.
You might say: ICP has more than that: on chain frontend, file hosting, II, reverse gas model, etc…
But what’s stopping devs from using ETH’s rollups to handle part of their business logic and rely on IC for everything else, effectively getting the best of both worlds? The only benefit of using icEVM might be reverse gas model, but ETH might also get something similar in the future with meta transactions, so I don’t see it as enough to compromise on security.