درِ امضای هش دلخواه بیتکوین: نسخه ۰.۵.۱ Chain Fusion Signer چه تغییری میدهد؟
نسخه ۰.۵.۱ ابزار Chain Fusion Signer قابلیت `btc_sign_prehash` را اضافه کرده است؛ قابلیتی که به برنامهها اجازه میدهد با کلید بیتکوین، هشهای دلخواه را امضا کنند. این تغییر نقش امضاکننده را فراتر از ابزارهای آماده تراکنش میبرد، اما انتخاب پروتکل و بررسی هزینه همچنان بر عهده توسعهدهنده است.
یک افزودن کوچک به API با پیامد معماری بزرگتر
آخرین انتشار Chain Fusion Signer، یعنی نسخه ۰.۵.۱، قابلیت btc_sign_prehash را اضافه میکند؛ روشی برای امضای یک هش دلخواه با کلید بیتکوین. این انتشار در ۱۶ ژوئیه منتشر شده و در کنار قابلیت جدید امضای بیتکوین، تغییری در مسیر ارتقا نیز دارد که پیکربندی canister را هنگام ارتقا حفظ میکند.
این تفاوت مهم است. یک ابزار ساخت تراکنش، قالب مشخصی از تراکنش بیتکوین را میشناسد؛ اما نقطه پایانی prehash هشی را میپذیرد که برنامه از قبل ساخته است. در نتیجه، canister یا برنامه وب میتواند ساخت پیام مخصوص هر پروتکل را در کد خود نگه دارد و مدیریت کلید و امضای آستانهای را به زیرساخت Chain Fusion در ICP بسپارد.
توسعهدهندگان چه چیزی به دست میآورند؟
الگوی عملی اکنون روشنتر است: قالب دقیق پیام پروتکل خارجی را تعریف کنید، آن را طبق همان پروتکل هش کنید، از signer امضا بگیرید و سپس امضا را به سازوکار راستیآزمایی یا جریان تراکنشی موردنیاز آن سیستم بدهید. این قابلیت میتواند برای جریانهای مرتبط با بیتکوین که در یک فراخوان ساده ارسال تراکنش جا نمیگیرند مفید باشد؛ از مجوزهای اختصاصی برنامه گرفته تا ابزارهای مرتبط با اسکریپتهای سفارشی. با این حال، یادداشت انتشار مشخص نمیکند btc_sign_prehash دقیقاً برای کدام پروتکلها یا قالبهای کاربردی بیتکوین طراحی شده است؛ بنابراین هر یک از این یکپارچهسازیها به اعتبارسنجی مستقل در سطح پروتکل نیاز دارد.
مرز امنیتی همان مرز قبلی باقی میماند. مستندات ICP، Chain Fusion را بهعنوان امضای آستانهای توضیح میدهند: canister یک کلید برای زنجیره خارجی استخراج میکند و بدون آنکه هیچ گرهای کلید کامل را در اختیار داشته باشد، درخواست امضا میدهد. signer یک canister قابل استفاده مجدد است که این قابلیتها را در اختیار برنامههای وب و کاربران خط فرمان میگذارد؛ بنابراین تیمها برای هر یکپارچهسازی مجبور نیستند canister امضای جداگانهای نگهداری کنند.
این انتشار چه چیزی را حل نمیکند؟
btc_sign_prehash یک primitive امضا است، نه یک خط لوله کامل برای تراکنش بیتکوین. توسعهدهنده همچنان باید ساخت صحیح هش را انتخاب کند، امضا را طبق نیاز پروتکل مقصد کدگذاری کند، جلوی امضای پیامهای ناخواسته را بگیرد و مرحله انتشار یا راستیآزمایی بعدی را مدیریت کند. پس یک نقطه پایانی امضای منعطف، بررسی برنامه را کماهمیت نمیکند؛ برعکس، کدی که هش را میسازد به بخشی از سطح مجوزدهی تبدیل میشود.
برنامهریزی هزینه نیز به دقت نیاز دارد. مستندات فعلی توسعهدهندگان میگویند جدول هزینه منتشرشده مربوط به Chain Fusion Signer نسخه ۰.۴.۰ است. بنابراین پیش از تعیین سقفهای تولید یا هزینههای قابل نمایش به کاربر، باید قیمتگذاری و رفتار پرداخت نسخه ۰.۵.۱ را بررسی کرد.
نتیجه مهم این انتشار بیشتر معماری است تا تبلیغاتی: Chain Fusion Signer به سمت یک رابط سطحپایینتر برای امضای بیتکوین حرکت میکند. این موضوع فضای بیشتری برای ساخت جریانهای سفارشی میانزنجیرهای در اختیار توسعهدهندگان میگذارد، اما مسئولیت معنا و اعتبار پیام را نیز به لایه برنامه منتقل میکند.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.