مسیر تازه ckETH برای صرافی‌ها، واریز اتریومی را به یک فرایند ICP تبدیل می‌کند

آخرین ارتقای Chain Fusion در اینترنت کامپیوتر یک نقطه‌ضعف آشنا را هدف گرفته است: صرافی‌های متمرکز معمولاً می‌توانند توکن را به یک آدرس بفرستند، اما نمی‌توانند قرارداد کمکی‌ای را فراخوانی کنند که پیش‌تر واریز اتریوم را به یک پرینسیپال در ICP متصل می‌کرد.

پروپوزال ۱۴۳۸۲۰ انجمن NNS که وضعیت آن «اجراشده» ثبت شده، کانستر مینتر ckETH با شناسه sv3dd-oaaaa-aaaar-qacoa-cai را با هش Wasm برابر da607e433d408192428aaa14373efbd8dcb083a0e7184099b909b7a758971b07 ارتقا می‌دهد. این پروپوزال کامیت faa1a8a77f71e183b37bb9f25907e90cab7516bc را معرفی می‌کند و جریان واریز از صرافی را که در سند طراحی DFINITY توضیح داده شده، به کار می‌گیرد.

تغییر اصلی، مدل نسبت‌دادن واریز بر اساس آدرس است. کاربر روی مینتر متد deposit_erc20 را فراخوانی می‌کند و مینتر برای پرینسیپال و ساب‌اکانت ICP او یک آدرس اختصاصی اتریوم می‌سازد. سپس کاربر می‌تواند توکن ERC-20 پشتیبانی‌شده را از صرافی متمرکز به همان آدرس برداشت کند. صرافی فقط به یک انتقال عادی توکن نیاز دارد و لازم نیست پرینسیپال ICP، ساب‌اکانت یا قرارداد کمکی ckETH را بشناسد.

مینتر آدرس‌های ثبت‌شده را اسکن می‌کند. پس از شناسایی موجودی کافی، مینتر یک attestation می‌سازد که آدرس واریز را به حساب مقصد در ICP متصل می‌کند. در اولین sweep، آدرس واریز همچنین مجوز EIP-7702 را امضا می‌کند تا اجرای خود را به قرارداد sweeper واگذار کند. EIP-7702 استاندارد اتریوم برای قرار دادن یک نشانگر واگذاری دائمی در حساب‌های مالکیت خارجی است؛ مشخصات رسمی آن فهرست مجوزها و مدل اجرای واگذارشده را تعریف می‌کند.

یک آدرس sweeper جداگانه که از قبل تأمین مالی شده، تراکنش را ارسال و کارمزد اتریوم را پرداخت می‌کند. کد واگذارشده بررسی می‌کند که attestation متعلق به خود آدرس واریز باشد، سپس دارایی را از مسیر قرارداد کمکی موجود عبور می‌دهد. به این ترتیب رویداد استاندارد ReceivedEthOrErc20 حفظ می‌شود و سیستم ثبت مبتنی بر لاگ مینتر می‌تواند موجودی ckERC20 متناظر را اعتباردهی کند.

این معماری سه مسئولیت را جدا می‌کند. آدرس اصلی مینتر دارایی‌های پشتوانه را نگه می‌دارد و برداشت‌ها را انجام می‌دهد. آدرس‌های واریز، حساب‌های کاربران را مشخص می‌کنند. آدرس sweeper نیز nonce lane جداگانه‌ای دارد؛ بنابراین یک sweep گیرکرده نباید برداشت‌های آدرس اصلی را متوقف کند. sweep همچنین permissionless است: هر کسی می‌تواند sweep معتبر را ارسال کند، اما attestation حساب دریافت‌کننده را ثابت می‌کند و مقصد همچنان آدرس اصلی مینتر است.

پشتوانه به‌عنوان یک اصل حسابداری صریح مدیریت می‌شود. کارمزد sweep از طریق سوزاندن ckETH از حساب کارمزد مینتر، پیش از خرج‌شدن ETH، تأمین می‌شود؛ بنابراین طراحی الزام می‌کند مجموع ckETH سوزانده‌شده برای کارمزد sweep حداقل برابر مجموع ETH خرج‌شده باشد. این به معنی رایگان‌بودن کارمزد نیست، بلکه تعهد تأمین مالی را به یک مسیر حسابداری مشخص و تحت کنترل مینتر منتقل می‌کند.

این مسیر محدودیت‌های عملی هم دارد. کاربر باید جفت آدرس و توکن را فعال کند و انتقالی که پس از پایان پنجره اسکن برسد، ممکن است تا فعال‌سازی دوباره ثبت منتظر بماند. توکن‌های پشتیبانی‌نشده به‌طور خودکار اعتباردهی نمی‌شوند. مسیر قبلی قرارداد کمکی همچنان در دسترس است و مسیر جدید برای برداشت‌هایی طراحی شده که صرافی نمی‌تواند در آن‌ها داده مخصوص ICP ارسال کند.

بنابراین این ارتقا صرفاً افزودن یک endpoint دیگر برای bridge نیست؛ محل ورود هویت به جریان واریز را تغییر می‌دهد: از فراخوانی قراردادی که کاربر ارسال می‌کند به یک مقصد قطعی که مینتر کنترل می‌کند. این تغییر برای تجربه Chain Fusion مهم است، اما ایمنی آن همچنان به پشتیبانی صحیح توکن‌ها، بررسی آدرس، مدیریت attestation، تأمین حساب کارمزد و ممیزی قرارداد sweeper وابسته است. داشبورد NNS اجرای ارتقا را ثبت کرده، در حالی که سند طراحی رفتار مورد انتظار را توضیح می‌دهد؛ این مقاله throughput تولید یا میزان پذیرش کاربران را به‌طور مستقل اندازه‌گیری نمی‌کند.