This project aims to enhance decentralized applications and services by allowing canisters, apps, services, and smart contracts to independently access Ethereum data, ensuring secure data retrieval from Ethereum. It also showcases the unique capabilities of the Internet Computer and its powerful computing environment which allows running applications incomparable to those of other decentralized platforms.
If you have any thoughts or questions, leave a comment below
Very timely contribution to IC, thx. Going to take this for a spin. Any rough edges one should be aware of? Btw: I saw that Aleo is your client, so you have ZK-SNARK / ZK-STARK know-how in your team, huh?
There are some, the project aimed to be a poc to reveal / answer some questions in the area. It only supports a few different calls, tho adding them is quite easy.
On the mainnet https outcalls support only IPv6 and I’m not aware of any publicly hosted consensus node that you can connect to right away. It has to be a node that supports beaconchain api(check helios’s readme for more details) and I don’t think it’s a popular feature in various node providers. You should be fine with the default one hosted by a16z on dev deployments tho.
Also it’s quite expensive and it wasn’t tailored for the cycle usage so eg. you’d be paying for full 2mb response each time any https outcalls are made, you can find more details in the readme.
Btw: I saw that Aleo is your client, so you have ZK-SNARK / ZK-STARK know-how in your team, huh?
We have some experts there but I’m not in it personally. Also our sister company, Equilibrium, just wrote an article about Aleo if you’re interested in reading more: privacy blockchains and aleo deep dive
Just discovered I am not allowed to post links in the replies, maybe because first time posting, sorry for inconvenience
Thx for the heads up regarding cycle usage, 2MB inbound would cost 2.87 cents on 13-nodes today . Requires a good enough justification to shell out this amount.
I didn’t know a16z is even hosting, crazy how hands-on this VC has become, likewise in A.I. they’ve released a ton of things.
I’ll keep an eye on your light client. I also need to better understand how this fits into the picture with ongoing ckETH efforts, as well as other ETH tools already released by the IC community here.
It should be reasonably easy to reduce cycles consumption by setting a more aggressive response size limit generally or making a HEAD call to determine the size for each call and then making the actual call with the according limit.
Currently, the light client is an exploratory project to see whether it works in general.
The ckETH, ckERC-20 implementations require events which are currently not supported by light clients, so the light client cannot provide this functionality. However, it could be used to make all other calls trustless in the light client model, which is stronger than using multiple RPC providers and trusting this group of providers.
For now, this project is expected to move on (or not) independently of the ckETH / ckERC-20 efforts because it’s all too novel to rely on it and light clients do not support events (yet). But an Ethereum light client would be extremely nice to have for many other projects to be used by the community for all calls other than the non-supported ones like getting events.
Great tip on keeping light client costs reasonable.
While we wait (im)patiently for the ckETH 's production release, what would be a poor-man’s IC<->EVM_chain architecture today? I came across these usual suspects :
t-ECDSA & HTTPS Outcalls
ic-web3
EVM Utility Canister
nikolas-con/ic-evm-sign
EVM Witness Library
eigerco/ethereum-canister
My use cases primariy revolve around the basics of ERC-20, ERC-721, nothing fancy.
I didn’t include No Key Wallet projects, although I find them cool, I’m hesitant on how to evolve them while the rest of the dApp/protocol iterates in search of PMF. No offense, to their builders, projects are cool indeed.
@HannesHuitula , @zvolin In making a 3rd-party Rust code compatible with IC’s specifications, how did you go about finding what to refactor, the good old trial and error approach?
Mostly the good old trial and error approach + a lot of the code reading and understanding.
There are a few key things you have to look for, like
will this code work in single threaded environment?
the https requests, you have to substitute them with https_outcalls obviously
making sure the only source of asynchrony is the canister outcalls, you can’t eg rely on any form of async mutexes as awaiting them doesn’t make any outcalls etc
