ckETH: a canister-issued Ether twin token on the IC

Developers
208

So expect a proposal to replace that provider soon.

Proposal 132415

209

Now it’s llamarpc’s turn to be failed, no?

210

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 a https://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:
    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
    We notified them (among others) on their Discord and opened a ticket.
211

It’s time to push forward our native ethereum nodes and get rid of all those RPCs once for all.

212

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

213

There should be a mechanism that uses another RPC provider if one fails

214

Do you have any response ? their discord seems ghost town

215

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.

216

My deposit has not arrived - it has passed ~ 36 hours

217

Still does not work: https://sv3dd-oaaaa-aaaar-qacoa-cai.raw.icp0.io/dashboard

There are 5 users waiting for ckETH:

218

The minter seems to be back on track since the last proposal 132474 was just adopted.

What happened?

  1. 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.
  2. Unfortunately, at the same time the Ethereum JSON-RPC provider LlamaNodes eth.llamarpc.com was down and constantly replying with no 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.
  3. 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:

  1. 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.
  2. 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.

219

Thank you and the team for all your work

221

Does that mean native ethereum integration is not on the plan anymore?

222

Hi everyone :wave:!

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

Hi everyone :wave:!

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 :tada:. This can for example be seen by the steady tracking of the last finalized block shown below (no plateau is good).

Last finalized block tracked by the minter
Last finalized block tracked by the minter3194×2446 466 KB

  • 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 :green_circle:) that can handle both deposits of ETH and ERC-20, while specifying a full ledger account (principal and subaccount) :tada:

Specify a ledger subaccount for your deposit!
Specify a ledger subaccount for your deposit!2676×802 118 KB

:information_source: As mentioned in the proposal 134264, the other helper smart contracts:

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.

224

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:

1
11476×830 160 KB

Could you please help investigate if there is an issue? Thank you so much for your assistance!

225

I noticed the same error this morning as I was testing OISY and shared the question with the team on internal channels for visibility.

226

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

  1. depositErc20 (0xdb9751af)
  2. 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.

227

It seems there was un unattended breaking change that sneaked in with proposal 134264:

  1. The value of get_minter_info::erc20_helper_contract_address and get_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:

  1. Revert the value of those 2 fields back to the previous helper smart contract addresses.
  2. Add a new field in get_minter_info to give the address of the new helper smart contract address.
228

The issue was treated as an urgent incident and resolved with proposal 134344. I tested a conversion in OISY, and it worked out. Shoutout to @gregory-demay and team for fixing this on a Saturday.