مرز تازه هزینه در Chain Fusion عملیاتی است: یا هزینه امضاکننده را تأمین کنید یا ارسال شکست میخورد
یک بحث تازه میان توسعهدهندگان ICP نشان میدهد که امضای حمایتشده فقط مسئله هزینه نیست؛ به یک وابستگی مشترک برای دسترسپذیری تبدیل میشود. راهکار، بودجهبندی صریح چرخهها، پایش مجوزها و جداسازی احراز اختیار کاربر از تسویه در زنجیره مقصد است.
مشکل بعدی Chain Fusion در محیط تولید شاید رمزنگاری نباشد؛ ممکن است موجودی حسابی باشد که هزینه امضاها را میپردازد.
در بحثی که ۲۶ اوت در انجمن توسعهدهندگان Internet Computer منتشر شد، هزینه عملیاتی امضاهای زنجیرهای با تمرکز بر کیف پول OISY بررسی شده است. طبق این نوشته، OISY از مدل پرداخت حامی استفاده میکند و هزینه امضای کاربران را از مسیر PatronPaysIcrc2Cycles در Chain Fusion Signer میپردازد. نکته مهم مهندسی این است که حمایت مالی یک وابستگی مشترک ایجاد میکند: اگر حساب حامی توان پرداخت نداشته باشد، درخواستهای معتبر امضای بیتکوین، EVM و سولانا نیز ممکن است شکست بخورند.
مستندات رسمی Chain Fusion Signer این مرز پرداخت را روشن میکند. هر فراخوانی API چرخه مصرف میکند و روش معمول این است که فراخوانیکننده با استفاده از ICRC-2 در Cycles Ledger، مجوز برداشت برای امضاکننده صادر کند. هزینه مستندشده برای امضای شخصی اتریوم، امضای پیشهش، امضای تراکنش، امضای عمومی ECDSA و امضای Schnorr برابر با ۳۷ میلیارد چرخه است. امضای بیتکوین هزینه بیشتری دارد، زیرا هزینه آن با تعداد ورودیهای UTXO افزایش مییابد؛ فرمول مستندشده شامل هزینه پایه بهاضافه ۳۷ میلیارد چرخه برای هر ورودی است.
این موضوع نحوه مدلسازی قابلیت اطمینان در یک برنامه Chain Fusion را تغییر میدهد. امضا فقط یک خروجی رمزنگاریشده نیست؛ یک درخواست خدمتِ دارای هزینه است که حساب تأمینکننده، مجوز برداشت، سیاست تلاش مجدد و حالت قطعیِ اختلال دارد. حتی اگر یک کیف پول هزینه را از کاربر پنهان کند، باید آن را در خزانهداری و سامانههای پایش خود ببیند.
API پرداخت چند مدل عملیاتی ارائه میدهد: خود فراخوانیکننده میتواند از طریق مجوز هزینه را بپردازد، یک حامی میتواند از طرف او پرداخت کند، یا یک پروکسی چرخهها را مستقیماً به فراخوانی متصل کند. این انعطاف مفید است، اما کنترل خودکار هزینه نیست. توسعهدهنده همچنان باید مشخص کند کدام عملیات به امضای زنجیره مقصد نیاز دارند، سقف هزینه هر عملیات چقدر است و هنگام تمامشدن بودجه چه رفتاری رخ میدهد.
ایمنترین طراحی، سه لایه را جدا میکند. نخست، احراز اختیار برنامه باید تا حد امکان از مجوزهای کوتاهمدت و محدود استفاده کند. دوم، تسویه در زنجیره مقصد باید صفبندی و بودجهبندی شود، زیرا بیتکوین، اتریوم و سولانا همچنان به امضایی نیاز دارند که شبکه خودشان آن را بپذیرد. سوم، مسیر تأمین مالی باید مانند یک وابستگی تولیدی مدیریت شود: موجودیها پایش شوند، پیش از اتمام هشدار صادر شود، سقف مجوز هر کاربر محدود باشد و وضعیت خطای پرداخت بهجای تلاش مجدد بینهایت، برای کاربر و اپراتور قابل مشاهده باشد.
آخرین نسخه تگشده Chain Fusion Signer، یعنی v0.5.1، امضای پیشهش بیتکوین و تغییرات ایمنی در ارتقا را اضافه کرده است، اما یادداشت انتشار آن مدل قیمتگذاری جدیدی اعلام نمیکند. این نکته مهم است، چون گفتوگوی فعلی درباره معماری و اقتصاد است، نه کاهش قطعی هزینهها.
یک caveat مهم درباره شواهد وجود دارد: نوشته ۲۶ اوت یک پرسش از جامعه توسعهدهندگان است، نه اعلامیه رسمی DFINITY درباره قیمتگذاری؛ همچنین مستندات رسمی میگوید جدول هزینه آن بر مبنای v0.4.0 است. این منابع وجود سازوکارهای پرداخت و ارقام مستندشده را پشتیبانی میکنند، اما نقشه راه بلندمدت قیمتگذاری را ثابت نمیکنند.
برای سازندگان، نتیجه فوری و عملی است: تأمین مالی امضاکننده را بخشی از مدل تهدید و اهداف سطح خدمت بدانید. یک برنامه Chain Fusion میتواند از نظر رمزنگاری درست باشد و همچنان به دلیل تعریفنشدن مجوز پرداخت، استخر حامی یا مسیر شارژ چرخهها از دسترس خارج شود.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.