As our app subnets currently only have IPv6 connectivity, I went through the tedious process of checking all Ethereum RPC API providers I could find for IPv6 connectivity. The table below shows my findings: most of the providers only support IPv4, but there are some that support IPv6 also. Hope this is useful for those who intend to use the Phase 1 integration on an IC app subnet.
Just tried it, indeed the behaviour is that it takes you to your Google Calendar, if you are logged in, and shows the Working Group calendar as well. You need to look for the first meeting, it is on March 22, 7AM CEST. Hope that helps!
For Phase 1, the community has put together some open source code already that allows you to roll your own Ethereum integration based on HTTPS outcalls. Available now, still needs to be tested in practice and possibly tweaked. See above in this topic for further details.
I have a concern about any of the ck Canisters operated by the NNS.
These concerns are both about the security and legality of these canisters. As DFINITY maintains effective voting control over the topics that update these canisters, DFINITY can update them at any time at will in practice. This of course is a central point of failure, and brings up the question of whether or not DFINITY is operating these canisters.
It seems system canisters like ckBTC (I believe itâs a system canister, though I recall some distinction earlier?) and ICP are not held to the same decentralized autonomous smart contract standards as on Ethereum.
I think we should consider the trade-offs of deploying truly autonomous canisters without controllers, or otherwise restricting the unilateral ability to update the Wasm binary.
4 Likes
Yea but they only have the ability to do this because they majority of stakeholders have given it to them.
I wonder how much of the voting power they have comes from the default situation at launch, and how much of the voting power has the ability to follow someone else at will.
Besides that, I think we need more than just a simple liquid democracy vote for such important things as protocol code and system canisters. Deterministic decentralization is not being applied to voting.
That might be a separate topic.
4 Likes
Hi there, any updates on this post? 
These are some good points
Is it substantial effort to implement other chains like COSMOS, MATIC etc?
I picture, natively trading all these coins against one another can be a huge selling point for ICP
Currently in Uniswap, you can swap any coin to any coin, but you could face multiple jumps in the middle, meaning the fees would add up
On ICP, the same can be done but faster and with Negligent fees. Not to mention, adding ckTech - it would mean all tokens backed 1:1
It would be worth considering a streamline of work to onboard multiple big chains
2 Likes
yes, you can build your own ckX token
1 Like
Regarding my earlier post on Ethereum API providers, Iâd like to provide a follow-up.
We had a really interesting discussion with gateway.fm, a startup from Scandinavia that provides APIs for Ethereum and some other chains. They were quite open towards adding functionality to allow API calls to be authorized with subnet signatures instead of API keys. This would solve, at least for this API provider, the problem of API keys being exposed if data of one IC node of the subnet the canister holding the API key is on is exposed.
From what I have seen so far, gateway.fm seems a great option for an API provider for the Phase 1 of the Ethereum integration. They do not have IPv6 (yet), but they may be adding this in the future. Iâd recommend to keep an eye on this provider for integrating with Ethereum.
Gatewayâs API for Ethereum is available at https://rpc.eth.gateway.fm.
6 Likes
Was on vacation and offline, thatâs why the response is so late.
EVM chains can be integrated rather easily using the approach taken for Phase 1. However, this does not provide the strongest possible trust model. The approach taken in Phase 2 provides essentially the strongest trust model, but is a substantial effort for each chain. When getting the architecture right, one can integrate further chains more easily than the first, which is Ethereum.
5 Likes
This sounds really cool, though I hope whoever deploys a phase 1 integration never relies on just one provider.
3 Likes
Indeed, when doing something with more value involved, it is recommended to use multiple independent API providers for each request.
I mentioned this to a guy at stripe as wellâŚI think dfinity should propose an industry wide standard that all api providers could adopt.
4 Likes
I think dfinity should propose an industry wide standard that all api providers could adopt.
This would indeed be a great idea. Main challenge is that the IC is currently the only chain capable of talking to API providers directly. Also, the standard would need to be open for different signature schemes. We should definitely follow up on this once we start this work item. Thanks for the idea!
2 Likes
How would the flow work here? Would they fetch requests from the canister? With HTTPS outcalls you have the issue that the certificate is only available in query calls. If youâd want to use HTTPS outcalls it would be simpler to allow authentication with tECDSA signature, wouldnât it?
1 Like
So is it our fault? 
I think this standardization is a great idea.
The API provider Gateway.fm now supports IPv6 for the Ethereum mainnet API! A big shout out to the gateway.fm team for making this happen for the IC community! 
Definitely worth trying out if you want to connect to Ethereum using HTTPS outcalls!
8 Likes
Does the key share have a witness to prove it is a part of the subnet key? If so this could be handled at the replica level where the calling node signs and provides a witness that they are currently part of the signing group and have rights to call the api. Maybe this exposes the api to attack?
Update calls donât have access to signatures, but is there any reason the replic canât have access after the call is complete? Outcalls are sync anyway. If the requesting contract injects the witness into the header, the replica could inject the root header before sending the outcall?
1 Like
Thatâs an interesting thought. Not my expertise, but I think this could work.
The details have not yet been defined, this is very early thinking and also not a high priority.
Austinâs thinking here is quite spot on I think. A solution might go into this direction.