That makes sense. Could the foundation choose one decentralized stablecoin - perhaps ckDAI - to roll out in Q4 alongside ckETH? I do believe it would be incredibly important to prioritize some type of stablecoin on the IC @Manu
1 Like
The balance table stores (account, amount) pairs; each account occupies at least 62 bytes (up to 29 bytes for the principal + 1 byte for the principal size + 32 bytes of the subaccount). Hence, using 128bit vs. 256bits saves 1 - (62 + 16) / (62 + 32) ~ 17% of storage, a minor difference given other inefficiencies in the current ledger storage technology.
Even if all the Ethereum in existence fits in 128bits, some other ERC20 tokens we might want to support in the future might not. Using EVM’s native integer width simplifies the code understanding and helps us avoid future surprises.
2 Likes
Do we store the principal repeatedly for each subaccount of the same owner?
Yes, currently, the key in the map is the entire Account (principal + subaccount).
We also plan to migrate the stable structures library to stable storage, where we must keep the same approach because stable structures don’t support nesting by design.
One optimization we could do is to store accounts with default subaccounts separately:
DEFAULT_ACCOUNTS: StableMap<Principal, Amount>;
ACCOUNTS: StableMap<(Principal, Subaccount), Amount>;
We could also use variable-size encoding (leb128) for amounts to support up to u256 without wasting too much space.
1 Like
We absolutely agree on how useful ckERC20 would be, and in particular a ckStablecoin, and are working hard to get it as quickly as we can. We think it makes sense to start with ckETH, and then do ckERC20 as quickly as we can after that.
Why not build both at the same time? If we would launch them together, it would mainly mean that one simply launches later because its waiting for the other one, which does not make sense to me.
Why start with ckETH? we think starting with ckETH makes sense, because ETH is the native token, and gas has to be paid in ETH also for ckERC20. We think that we may be able to use ckETH for gas fees in ckERC20. Additionally, the approach of passing in a principal via a call argument is possible for ETH but cannot be done for ERC20. We may be able to build on ckETH to link ETH accounts and IC principals, which we can then use in ckERC20.
7 Likes
ckDAI is one option. ckFRAX would be cool too.
Even better imho is ckCHAI, this is the yield bearing version of DAI!
1 Like
Thanks so much for the detailed response. I understand your rationale and agree. We all appreciate your hard work and know that it is a trying time in the depths of the bear market.
It is sometimes difficult for non-technical folks to understand how long it takes for complex features to be rolled out. I want to stress just how grateful the community is for all your hard work!
4 Likes
It’s hard to say something confidently as it’s so far out, but that timeline seems realistic to me.
2 Likes
Hello, are you sure it’s December 2024? Is the integration we’re looking forward to in Q4 2023 going to be delayed by another year?
dfisher asked about the “phase 2” integration, where ICP nodes also act as Ethereum mainnet nodes, and canisters can request ethereum state directly from ICP nodes. This feature will not be done in 2023, but come later.
For ckETH, so the topic of discussion in this thread, we hope that this will launch in 2023. This will build on HTTPS outcalls first (and may later be upgraded to build on the “phase 2” native ethereum integration when that’s available).