Chain Fusion مرز Digest بیتکوین را برای امضاهای سفارشی باز میکند
نسخه v0.5.1 از Chain Fusion Signer تابع btc_sign_prehash را اضافه میکند و به برنامههای ICP اجازه میدهد روی digestهای دلخواه، با کلید بیتکوین، امضا درخواست کنند. این تغییر نقش امضاکننده را از یک ابزار صرفاً تراکنشمحور به یک primitive رمزنگاری قابلاستفاده مجدد نزدیک میکند؛ درحالیکه رمزگذاری و اعتبارسنجی مخصوص هر پروتکل همچنان بر عهده برنامه است.
جدیدترین نسخه Chain Fusion Signer تغییری کوچک در API ایجاد میکند که پیامد معماری بزرگتری دارد: امضای بیتکوین روی ICP دیگر لازم نیست با یک شیء شبیه تراکنش آغاز شود.
نسخه 0.5.1 که در 16 ژوئیه منتشر شد، تابع btc_sign_prehash را اضافه میکند؛ توضیح یادداشت انتشار این است که این تابع یک digest دلخواه را با کلید بیتکوین امضا میکند. همین نسخه، برای پیشنهادهای ارتقا نیز استفاده از variant صریح Upgrade را تغییر داده است؛ اما برای سازندگان Chain Fusion، تابع prehash اهمیت بیشتری دارد، چون مرز امضای سطح پایینتری را در اختیارشان میگذارد.
این مرز مهم است، زیرا بسیاری از جریانهای سازگار با بیتکوین با یک تراکنش کامل شروع نمیشوند. یک برنامه ممکن است ابتدا نیاز داشته باشد یک پیام ساختاریافته، یک درخواست مخصوص پروتکل یا قالبی را امضا کند که سریالسازی آن خارج از امضاکننده انجام میشود. با endpoint مربوط به prehash، برنامه میتواند payload را محلی بسازد و hash کند و سپس از Chain Fusion Signer بخواهد امضای کلید بیتکوین را با پشتوانه threshold تولید کند.
این قابلیت، امضاکننده را به موتور یک پروتکل تبدیل نمیکند. برنامه همچنان مسئول بخشهای حساس است: انتخاب domain separator درست، سریالسازی فیلدها با ترتیب موردنیاز، hash کردن دقیق بایتهایی که verifier انتظار دارد و بررسی معتبر بودن امضا برای کلید و زمینه موردنظر. امضاکننده اجرای رمزنگاری را فراهم میکند، اما معنای digest را تعیین نمیکند.
این جداسازی با مدل Chain Fusion در ICP سازگار است. مستندات ICP توضیح میدهند که canisterها میتوانند کلیدهای مربوط به شبکههای بیرونی را مشتق کنند و بدون بازسازی کلید خصوصی در یک مکان، امضاهای threshold درخواست دهند. Chain Fusion Signer این قابلیت را به شکل یک canister قابلاستفاده مجدد ارائه میکند تا برنامههای وب و کاربران خط فرمان، بدون نگهداری امضاکننده اختصاصی، از آن استفاده کنند.
برای توسعهدهندگان، تغییر عملی عبارت است از گستردهتر شدن سطح یکپارچهسازی. API تراکنشمحور، امضا را آخرین مرحله انتقال بیتکوین نشان میدهد. API مبتنی بر digest میتواند زیرساخت چند جریان مخصوص برنامه باشد؛ البته فقط زمانی که آن جریانها یک طرح امضای مشخص برای بیتکوین داشته باشند. از نظر معماری، امضاکننده به یک لایه سرویس رمزنگاری نزدیکتر میشود و از یک قالب تراکنش واحد فاصله میگیرد.
یک محدودیت مهم نیز وجود دارد. یادداشت انتشار v0.5.1 قابلیت جدید btc_sign_prehash را مستند میکند، اما ادعا نمیکند که این قابلیت از پروتکل، استاندارد کیفپول یا برنامه مشخص جدیدی پشتیبانی میکند. بنابراین کاربردهای پروتکلمحور مطرحشده در این مقاله، امکانهایی برای ارزیابی توسعهدهندگان هستند، نه یک یکپارچهسازی عرضهشده. همچنین کاربردهای گستردهتری که در این متن بررسی میشوند، تحلیل تحریریهاند و نه یکپارچهسازیهای اعلامشده محصول.
پیامد ایمنی روشن است: امضای digest دلخواه انعطافپذیری را افزایش میدهد، اما مسئولیت caller را نیز بیشتر میکند. اگر front end یا canister digest اشتباهی را امضا کند، ممکن است پیام نادرست را مجاز کند؛ حتی اگر خود امضاکننده کاملاً درست کار کرده باشد. سازندگان باید ساخت payload را قابلممیزی کنند، امضاها را به یک domain صریح متصل کنند، آنها را با verifierهای مستقل آزمایش کنند و امضای خام prehash را مانند یک دکمه تأیید عمومی عرضه نکنند.
نتیجه، اتصال جدید به یک شبکه نیست؛ بلکه دقیقتر شدن رابطی موجود است. سازوکار threshold در ICP اکنون میتواند برای digestهای بیتکوینی استفاده شود که خود برنامه تعریف میکند. این ویژگی در مقیاس انتشار، modest است، اما به توسعهدهندگان Chain Fusion فضای بیشتری برای ساخت جریانهای امضای آگاه از پروتکل میدهد؛ بدون آنکه منطق مدیریت کلید را در هر برنامه دوباره پیادهسازی کنند.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.