بازطراحی Sweeper در ckETH؛ تجمیع سپرده‌ها به یک خط لوله امضاشده و مقاوم در برابر تکرار تبدیل می‌شود

تازه‌ترین تحول ckETH درباره ایجاد توکن جدید نیست؛ درباره نظم در تسویه است. بین ۲۷ تا ۲۹ اوت ۲۰۲۶، مجموعه‌ای از تغییرات در مخزن اینترنت کامپیوتر ادغام شد که شیوه تجمیع سپرده‌های خودکار ckETH در اتریوم را بازطراحی می‌کند.

تغییر اصلی معماری است: درخواست sweep اکنون توکن و سپرده‌های مشخصی را که باید جابه‌جا شوند معرفی می‌کند، اما nonce، قیمت گس، مقدار و داده فراخوانی تراکنش بعداً توسط خط لوله ساخته می‌شوند. این جداسازی مرز روشن‌تری میان قصد حسابداری و ساخت تراکنش اتریومی ایجاد می‌کند.

این بازطراحی یک شکاف مهم در سازگاری صف را نیز می‌بندد. پیش از این، batching می‌توانست سپرده‌هایی را ببیند که قبلاً توسط sweep دیگری انتخاب شده بودند؛ در نتیجه یک موجودی می‌توانست به دو تراکنش پیشنهاد شود. طراحی جدید مشخص می‌کند هر سپرده در صف متعلق به کدام sweep است و ورودی‌های در حال پردازش را کنار می‌گذارد. ورودی‌ها تا زمان نهایی‌شدن sweep در صف باقی می‌مانند؛ بنابراین تراکنش ناموفق را می‌توان ثبت و دوباره تلاش کرد، بدون آن‌که اطلاعات مالکیت از بین برود.

کنترل‌های امنیتی نیز صریح‌تر شده‌اند. اگر سپرده فاقد attestation اتصال‌دهنده آدرس سپرده به حساب ICP یا فاقد مجوز لازم برای واگذاری اجرای کد به sweeper باشد، از batch کنار گذاشته می‌شود. همچنین batch برای هر توکن یک sweep جدا دارد و ابهام هنگام پردازش چند دارایی ERC-20 در یک چرخه کاهش می‌یابد.

حسابداری گس هم اصلاح شده است. فرض ثابت ۱۰۰٬۰۰۰ گس می‌توانست batchهایی را که چند آدرس را بررسی و مجوزهای EIP-7702 را نصب می‌کنند ارزان‌تر از واقعیت قیمت‌گذاری کند. در طراحی جدید، سقف گس با تعداد آدرس‌های بررسی‌شده رشد می‌کند و حداکثر کارمزد تراکنش نیز بر اساس همان برآورد محاسبه می‌شود. در عمل، احتمال ساخت تراکنشی که سقف گس خودش مانع ورود آن به شبکه شود کمتر خواهد شد.

برای سازندگان، درس مهم این است که قابلیت اطمینان Chain Fusion فقط به quorum در RPC یا امضاهای threshold محدود نمی‌شود. ماشین حالت پایدار نیز اهمیت دارد: هر سپرده انتخاب‌شده باید مالک داشته باشد، هر مجوز باید با مدرک همراه باشد و هر retry باید مسیر شکست ثبت‌شده‌ای داشته باشد. مستندات ckETH مدل پیرامونی را توضیح می‌دهند: سپرده‌های اتریوم از طریق رویدادهای قرارداد کمکی و دسترسی به EVM RPC شناسایی می‌شوند و برداشت‌ها نیز توسط minter امضا و ارسال می‌شوند.

این نکته مهم است: این موارد commitهای پیاده‌سازی در upstream هستند، نه benchmark عملکرد منتشرشده یا release قطعی برای کاربران؛ بنابراین رفتار نهایی آن‌ها ممکن است پیش از استقرار تغییر کند. توسعه‌دهندگانی که با ckETH یکپارچه می‌شوند باید به رابط Candid منتشرشده و مستندات فعلی تکیه کنند و پیش از وابستگی به رویدادهای منتشرنشده sweep، رابط زنده minter را دوباره بررسی کنند.

اگر این تغییرات به محیط تولید برسند، اثر اصلی آن‌ها احتمالاً برای کاربر نامرئی خواهد بود: فرصت‌های کمتر برای sweep تکراری، retryهای قابل‌پیش‌بینی‌تر و کارمزدهایی که اندازه batch را بهتر منعکس می‌کنند. همین بهداشت سطح پایین حسابداری است که ترکیب‌پذیری یک دارایی میان‌زنجیره‌ای میزبانی‌شده روی ICP را ایمن‌تر می‌کند.