امضای بیت‌کوین از سازندهٔ تراکنش جدا می‌شود: نسخهٔ ۰.۵.۱ Chain Fusion Signer چه چیزی اضافه می‌کند؟

آخرین انتشار Chain Fusion Signer مرز میان ICP و بیت‌کوین را تغییر می‌دهد. نسخهٔ ۰.۵.۱ که در ۱۶ ژوئیه منتشر شد، متد btc_sign_prehash را اضافه می‌کند؛ متدی برای امضای یک digest دلخواه با کلید بیت‌کوین signer. این انتشار همچنین proposalهای ارتقا را به استفاده از variant صریح Upgrade تغییر می‌دهد تا پیکربندی canister هنگام ارتقا حفظ شود. این مقاله بر تغییر مربوط به امضا تمرکز دارد.

چرا این متد اهمیت دارد؟

یک API تراکنش‌محور می‌تواند بخش بزرگی از پیچیدگی بیت‌کوین را پنهان کند: ورودی‌ها، خروجی‌ها، کارمزدها و serialization تراکنش در سرویس امضاکننده ساخته می‌شوند. اما endpoint مربوط به prehash سطح پایین‌تری دارد. برنامه می‌تواند digest موردنیاز پروتکل یا جریان تراکنش خود را بسازد و از Chain Fusion Signer بخواهد آن را با کلید مشتق‌شدهٔ بیت‌کوین امضا کند. در نتیجه، signer برای برنامه‌های بیت‌کوینی که در مسیرهای تراکنشی ازپیش‌ساخته نمی‌گنجند، به یک بلوک رمزنگاری عمومی‌تر تبدیل می‌شود.

این یک تغییر معماری است، نه یک شبکهٔ جدید بیت‌کوین. ICP همچنان امضای آستانه‌ای را از طریق یک canister عمومی و تحت کنترل حاکمیتی فراهم می‌کند. مستندات signer، canister اصلی شبکه را با شناسهٔ grghe-syaaa-aaaar-qabyq-cai معرفی می‌کند و توضیح می‌دهد که فراخوانی‌ها از طریق تأیید ICRC-2 در Cycles Ledger پرداخت می‌شوند. کلید خصوصی در اختیار فراخواننده قرار نمی‌گیرد؛ برنامه نتیجهٔ امضا را دریافت می‌کند.

مسئولیت امنیتی به لایهٔ برنامه منتقل می‌شود

انعطاف‌پذیری بیشتر، مرز مسئولیت برنامه را حساس‌تر می‌کند. یک API مربوط به prehash به فراخواننده نمی‌گوید که digest با serialization صحیح بیت‌کوین، شبکهٔ درست، مجموعهٔ ورودی مناسب یا حفاظت در برابر replay ساخته شده است یا نه. این بررسی‌ها همچنان بخشی از سیاست امضای برنامه هستند. بنابراین یک integration امن باید digest را به‌عنوان artifact قابل‌ممیزی در نظر بگیرد: بایت‌های دقیق پیام را تعریف کند، آن‌ها را با ابزار مستقل بیت‌کوین آزمایش کند، به شبکه و زمینهٔ تراکنش موردنظر متصل کند و درخواست‌های مبهم یا تکراری را رد کند.

درس عملی Chain Fusion در نسخهٔ ۰.۵.۱ همین است: رمزنگاری آستانه‌ای می‌تواند custody کلید را محافظت کند، اما پیام نادرست را اصلاح نمی‌کند. signer می‌تواند نتیجهٔ امضا را از نظر عملیات رمزنگاری قابل‌اعتماد کند؛ این برنامه است که باید پیام را از نظر عملیات بیت‌کوین قابل‌اعتماد بسازد.

توسعه‌دهندگان چه چیزهایی را باید ممیزی کنند؟

نخست، interface signer را pin کنید و متد جدید را پیش از انتقال ارزش با بردارهای آزمایشی معتبر بررسی کنید. دوم، ساخت digest را از فراخوانی canister جدا کنید تا preimage و domain آن برای بازبینان قابل مشاهده باشد. سوم، retryها را دقیق مدل کنید: تکرار یک درخواست امضای تراکنش قطعی ممکن است بی‌خطر باشد، اما اگر وضعیت برنامه یا تراکنش موردنظر بین دو تلاش تغییر کند، می‌تواند خطرناک شود. در نهایت، سقف پرداخت چرخه‌ها و هزینهٔ متدها را بخشی از سیاست استقرار قرار دهید.

یک نکتهٔ مستندی در زمان نگارش اهمیت دارد: راهنمای رسمی signer می‌گوید جدول هزینه‌های آن مربوط به نسخهٔ ۰.۴.۰ است و صفحه هنوز btc_sign_prehash را فهرست نکرده است. توسعه‌دهندگان باید پیش از اتکا به این متد در محیط production، Candid interface مستقرشده، نسخهٔ release و جدول هزینهٔ جاری را بررسی کنند. این موضوع انتشار v0.5.1 را بی‌اعتبار نمی‌کند؛ فقط نشان می‌دهد artifact انتشار و مستندات زنده هنوز کاملاً با یکدیگر همگام نیستند.

نتیجهٔ بزرگ‌تر، محدود اما مهم است. Chain Fusion اکنون سطح عمومی‌تری برای امضای بیت‌کوین پیدا می‌کند. این قابلیت می‌تواند نیاز به backendهای امضای اختصاصی را کاهش دهد، اما در عوض ساخت پیام، جداسازی دامنه، مقاومت در برابر replay و pin کردن interface را به مسئولیت‌های اصلی امنیتی توسعه‌دهندگان ICP تبدیل می‌کند.