مرز «دایجست» بیت‌کوین وارد Chain Fusion Signer شد

آخرین نسخهٔ تأییدشدهٔ Chain Fusion Signer یک مرز کوچک اما مهم برای توسعه‌دهندگان بیت‌کوین جابه‌جا می‌کند: نسخهٔ ۰٫۵٫۱ قابلیت btc_sign_prehash را اضافه کرده است؛ APIای برای امضای یک دایجست دلخواه با کلید بیت‌کوینِ signer. این قابلیت برای برنامه‌هایی مهم است که داده یا پیام مخصوص بیت‌کوین را خودشان می‌سازند و هش می‌کنند و می‌خواهند ICP همان دایجست نهایی را مجاز کند، نه این‌که حتماً یک قالب تراکنش سطح‌بالا دریافت کند.

این انتشار همچنین helper کارمزد ارسال بیت‌کوین را بر اساس تعداد خروجی‌های تراکنش مقیاس می‌دهد. این تغییر برای تراکنش‌های UTXO کاربردی است: تراکنشی با چند خروجی معمولاً به برآورد کارمزدی متفاوت از پرداخت ساده به یک گیرنده نیاز دارد. با این حال، توسعه‌دهندگان باید این helper را همچنان یک برآورد بدانند و سیاست خود را برای نرخ کارمزد، خروجی change، هدف تأییدها و رفتار جایگزینی تراکنش حفظ کنند.

تغییر عمیق‌تر، عملیاتی است. پیشنهادهای ارتقا اکنون از variant صریح Upgrade استفاده می‌کنند تا ارتقا پیکربندی canister را حفظ کند و آرگومان‌های مقداردهی اولیه را دوباره اعمال نکند. پروژه همچنین فرایند خودکار انتشار را مستند کرده و کنترل‌هایی برای فایل‌هایی که release bot مجاز به تغییر آن‌هاست افزوده است. برای یک canister عمومیِ امضاکننده، این جزئیات بخشی از امنیت عملیاتی‌اند: ابهام در ارتقا را کم می‌کنند و بررسی مسیر یک تغییر بازبینی‌شده تا artifact مستقرشده را آسان‌تر می‌سازند.

مستندات ICP، این signer را یک canister عمومی و تحت کنترل حاکمیت معرفی می‌کنند که APIهای امضای آستانه‌ای ECDSA و Schnorr را در اختیار برنامه‌های وب و کاربران خط فرمان می‌گذارد. تماس‌ها با cycles پرداخت می‌شوند، معمولاً از طریق allowance استاندارد ICRC-2، و مواد کلید خصوصی همچنان در سامانهٔ امضای آستانه‌ای Internet Computer به‌صورت توزیع‌شده باقی می‌مانند.

برداشت اصلی برای توسعه‌دهندگان از نسخهٔ ۰٫۵٫۱، الگوریتم امضای تازه یا جهش عملکردی نیست؛ بلکه سطح یکپارچه‌سازی دقیق‌تر با بیت‌کوین است. امضای پیش‌هَش به کیف‌پول‌ها، ابزارهای custody و پروتکل‌ها کمک می‌کند منطق serialization را در لایه‌ای نگه دارند که شناخت بهتری از آن دارد. هم‌زمان، تغییرات ارتقا و انتشار، بهره‌برداری محتاطانه‌تر از signer مشترک را ممکن می‌کنند.

نکتهٔ تحریری: آخرین انتشار تأییدشده در ۱۶ ژوئیهٔ ۲۰۲۶ منتشر شده است، هرچند بررسی آن در ۱۵ اوت ۲۰۲۶ انجام شد. یادداشت انتشار ادعایی دربارهٔ افزایش توان عملیاتی امضا یا تغییر مدل امنیتی آستانه‌ای ندارد؛ اهمیت این نسخه در پوشش API و انضباط عملیاتی است، نه در ارتقای پروتکل.