Why ICP relays on ANKR - is it not possible to interact with ETH directly ?
This is major flaw… we cannot have DEFI with this performance of chain key - it could be source for so much fud - imagine new account (especially with large followings) comming to ICP swapping big ammount USDC ->ckUSDC to buy lets say BOB
and he waits DAYS for this. ICP will be crucified on socials we must not let this and change design
So expect a proposal to replace that provider soon.
Proposal 132415
Now it’s llamarpc’s turn to be failed, no?
Unfortunately, there is good news and there is bad news:
- The good: Proposal 132415 was adopted and it did fix the problem regarding
Ankr
, (which was replaced by ahttps://eth-pokt.nodies.app
from Pocket Network). Example from the logs:Got response (with 87 bytes): {\"id\":588,\"jsonrpc\":\"2.0\",\"result\":{\"number\":\"0x13c453f\",\"baseFeePerGas\":\"0x72671ea6\"}} from url: https://eth-pokt.nodies.app with status: 200
- The bad: LlamaNodes is down since this morning and always return
no response
. Example from the logs:
We notified them (among others) on their Discord and opened a ticket.Got response (with 74 bytes): {\"id\":593,\"jsonrpc\":\"2.0\",\"error\":{\"code\":-32603,\"message\":\"no response\"}} from url: https://eth.llamarpc.com with status: 200
It’s time to push forward our native ethereum nodes and get rid of all those RPCs once for all.
There should be somekind of announcment people to hold back of interacting with mint/bridge of ck tokens - currently peope are “bridgint” ck tokens and get nothing in return and this is not good experience - having your assets stucked in uncertainity
There should be a mechanism that uses another RPC provider if one fails
Do you have any response ? their discord seems ghost town
I saw all previous deposits have went through 6 hours ago. However new errors can be seen like “Failed to get ERC-20 logs from block 20_722_325 to block 20_723_124” in logs and I assume newly created deposits will still be stuck.
My deposit has not arrived - it has passed ~ 36 hours
Still does not work: https://sv3dd-oaaaa-aaaar-qacoa-cai.raw.icp0.io/dashboard
There are 5 users waiting for ckETH:
The minter seems to be back on track since the last proposal 132474 was just adopted.
What happened?
- Proposal 132415 was executed at 2024.09.11 09:28 (UTC) and successfully replaced the Ethereum JSON-RPC provider Ankr (rpc.ankr.com) with
eth-pokt.nodies.app
from Pocket Network. - Unfortunately, at the same time the Ethereum JSON-RPC provider LlamaNodes
eth.llamarpc.com
was down and constantly replying withno response
. This seems to have been resolved since the ckETH minter did make progress around 2024.09.11 22:00 (UTC) but had stopped since then. - The logs show that responses from the Ethereum JSON-RPC provider Pocket Network (
eth-pokt.nodies.app
) differ between the replicas resulting in consensus failures. Proposal 132474 replaced the Ethereum JSON-RPC provider Pocket Network (eth-pokt.nodies.app
) with the Ethereum JSON-RPC provider BlockPi (`https://ethereum.blockpi.network/v1/rpc/public).
Future Plans
Currently, the ckETH minter uses JSON-RPC providers that do not require API keys and there are unfortunately not that many that also support IPv6 connectivity. Our goal to improve the current situation is to use the EVM-RPC canister, that does use JSON-RPC providers with API keys, to be able to use more providers. This will also allow us to use a more robust strategy (e.g. require consensus between responses from 3 providers when 4 are queried), so that a provider being down would not impact the availability of the ckETH minter. This does require some changes:
- on the ckETH minter, to be able to communicate with the EVM-RPC canister. Those changes are already implemented and could be activated via an upgrade proposal.
- on the EVM-RPC canister (see this post for more details), which are currently on-going.
That means that we are doing steady progress on that front and should be able to use the EVM-RPC canister in the next few weeks.
Thank you and the team for all your work
Does that mean native ethereum integration is not on the plan anymore?
Hi everyone !
A couple of announcements regarding the ckETH minter:
- As mentioned in this post, the ckETH minter is now ready to use the EVM-RPC canister with a 3-out-of-4 consensus strategy. Expect a proposal in the next few days.
- We are now prioritising supporting subaccounts, both for deposits and withdrawals. This should be ready in a couple of weeks.
Hi everyone !
Quick update related to the previous announcements
- As mentioned in this post, the ckETH minter is now ready to use the EVM-RPC canister with a 3-out-of-4 consensus strategy. Expect a proposal in the next few days.
This was successfully rolled out with proposal 133796 that was executed a month ago (2024-10-25). Since then, the ckETH/ckERC20 minter enjoyed a refreshingly problem-free interaction with Ethereum . This can for example be seen by the steady tracking of the last finalized block shown below (no plateau is good).
- We are now prioritising supporting subaccounts, both for deposits and withdrawals. This should be ready in a couple of weeks.
Proposal 134264 was successfully executed today and that means there is now a single helper smart contract (0x18901044688d3756c35ed2b36d93e6a5b8e00e68 ) that can handle both deposits of ETH and ERC-20, while specifying a full ledger account (principal and subaccount)
As mentioned in the proposal 134264, the other helper smart contracts:
- for ETH: 0x7574eB42cA208A4f6960ECCAfDF186D627dCC175
- for ERC-20 0x6abDA0438307733FC299e9C229FD3cc074bD8cC0
are considered deprecated and we invite all developers to switch to using the new contract. The current plan is to reduce the frequency at which the logs of those deprecated smart contracts are scraped in a couple of months.
Dear Grégory @Gotcha and the team,
Thank you so much for the update!
Regarding the latest mint contract, we encountered an issue: when minting ckUSDC, we receive the following error:
Gas estimation failed: Error: cannot estimate gas; transaction may fail or may require manual gas limit.
Additionally, we’ve observed many failed transactions with this latest mint contract:
Could you please help investigate if there is an issue? Thank you so much for your assistance!
I noticed the same error this morning as I was testing OISY and shared the question with the team on internal channels for visibility.
Thanks @ICPSwap and @peterparker for reporting the problem. It seems the faulty transactions, such as this one target a method (deposit
) that doesn’t exist on the new helper smart contract. It should be one of
depositErc20
(0xdb9751af
)depositEth
(0x17c819c4
)
Note that given those methods have an additional parameter (subaccount) in contrast to their equivalent method on the previous helper smart contract (besides having a different name on purpose), they cannot have the same function signature and hence must have a different function selector.
I hope this helps. Feel free to reach out if you have any question.
It seems there was un unattended breaking change that sneaked in with proposal 134264:
- The value of
get_minter_info::erc20_helper_contract_address
andget_minter_info:: eth_helper_contract_address
was changed to point to the new helper smart contract, which is a breaking change because as explained above it cannot expose the same ABI.
We plan on doing the following fixes:
- Revert the value of those 2 fields back to the previous helper smart contract addresses.
- Add a new field in
get_minter_info
to give the address of the new helper smart contract address.