EN
→ بازگشت به خبرخوان
شمارهٔ ۰۳۱۷Chain Fusion۲ دقیقه۳ منبع

افزوده‌شدن مسیر پیش‌هش به امضاکننده بیت‌کوین ICP برای تعامل‌پذیری کیف‌پول‌ها

نسخه 0.5.1 از Chain Fusion Signer متد `btc_sign_prehash` را اضافه می‌کند؛ متدی که به فراخواننده اجازه می‌دهد یک پیش‌هش ۳۲بایتی را با کلید بیت‌کوین متناظر با آدرس P2WPKH امضا کند. این تغییر مسیر تازه‌ای برای جریان‌های پیام‌امضا و PSBT ایجاد می‌کند، اما ساخت پیش‌هش و مدیریت قالب امضا را در مرز امنیتی توسعه‌دهنده قرار می‌دهد.

افزوده‌شدن مسیر پیش‌هش به امضاکننده بیت‌کوین ICP برای تعامل‌پذیری کیف‌پول‌ها
تصویر: تولید هوش مصنوعی

جدیدترین نسخه فهرست‌شده Chain Fusion Signer، یعنی v0.5.1، یک API کوچک اما مهم اضافه کرده است: btc_sign_prehash می‌تواند یک پیش‌هش دلخواه و ازپیش‌محاسبه‌شده ۳۲بایتی را با کلید بیت‌کوین فراخواننده امضا کند.

این قابلیت با ابزار معمول ارسال تراکنش تفاوت دارد. متدهای قبلی بیت‌کوین در Signer، تراکنش را از UTXOها و خروجی‌های داده‌شده می‌سازند و سپس ورودی‌های تراکنش را امضا می‌کنند. متد جدید یک هش ۳۲بایتی با نمایش هگزادسیمال دریافت می‌کند و یک امضای خام ECDSA به‌شکل r || s برمی‌گرداند. فراخواننده باید شناسه بازیابی را از کلید عمومی شناخته‌شده به‌دست آورد و امضا را با قالب موردنیاز جریان مقصد سازگار کند.

مستندات رابط این مخزن، این قابلیت را همتای بیت‌کوینی متد پیش‌هش اتریوم معرفی می‌کند. همچنین توضیح می‌دهد که فراخوانی عمومی ECDSA جایگزین آن نیست: API عمومی کلیدی با طرح Generic مشتق می‌کند، اما متد جدید از طرح کلید Btc استفاده می‌کند تا امضا بتواند در برابر آدرس P2WPKH فراخواننده اعتبارسنجی شود.

برای سازندگان Chain Fusion، تغییر اصلی در قابلیت ترکیب‌پذیری است. یک کنیستر یا یکپارچه‌سازی کیف‌پول می‌تواند پیش‌هش مخصوص بیت‌کوین را خارج از مسیر ساخت تراکنش Signer آماده کند و فقط امضای رمزنگاری‌شده را از ICP بگیرد. این موضوع راه تمیزتری برای جریان‌هایی مانند تعامل‌پذیری کیف‌پول، امضای پیام و ابزارهای تراکنش نیمه‌امضاشده فراهم می‌کند. Signer همچنان اجرای ECDSA آستانه‌ای را انجام می‌دهد، اما برنامه باید تعیین کند دقیقاً چه بایت‌هایی هش شوند و امضا چگونه بسته‌بندی شود.

همین تفکیک، مرز امنیتی مهم ماجراست. endpoint پیش‌هش معنای digest را نمی‌فهمد. نمی‌تواند تشخیص دهد که هش، یک پیام معتبر بیت‌کوین، یک تراکنش درست‌سریال‌شده یا یک payload ناخواسته است. رابط، مقادیری را که هگزادسیمال معتبر یا digest دقیقاً ۳۲بایتی نباشند رد می‌کند و خطاهای امضا و پرداخت را گزارش می‌دهد؛ اما اعتبار معنایی همچنان بر عهده فراخواننده است.

مستندات فعلی ICP، Chain Fusion Signer را یکی از اجزای قابل‌استفاده مجدد برای برنامه‌هایی معرفی می‌کند که دارایی‌های شبکه‌های دیگر را نگهداری و مدیریت می‌کنند. این مستندات Chain Fusion را تعامل مستقیم با شبکه‌هایی مانند بیت‌کوین، اتریوم و سولانا تحت فرض‌های اعتماد پروتکل ICP توصیف می‌کند و می‌گوید Signer APIهای امضای آستانه‌ای را برای برنامه‌های وب و کاربران CLI ارائه می‌دهد.

بنابراین اهمیت این انتشار، بیشتر از آن‌که یک مسیر انتقال تازه برای بیت‌کوین باشد، گسترش سطح امضاست. توسعه‌دهندگان اکنون می‌توانند ساخت تراکنش یا پیام را از نگهداری کلید جدا کنند؛ اما این انعطاف‌پذیری باید با هش‌سازی دارای جداسازی دامنه، آزمون‌های دقیق سریال‌سازی، بررسی کلید عمومی و آدرس، و تأیید صریح payload توسط کاربر همراه شود.

یک محدودیت باید روشن بماند: یادداشت انتشار و تعریف رابط ثابت نمی‌کنند که همه قالب‌های PSBT یا پیام پشتیبانی می‌شوند. یکپارچه‌ساز باید digest و قالب امضا را خودش بسازد و اعتبارسنجی کند. همچنین مخزن، میزان استفاده یا استقرار این نسخه را در همه برنامه‌های Chain Fusion ثابت نمی‌کند؛ فقط v0.5.1 را جدیدترین انتشار فهرست‌شده معرفی می‌کند و تاریخ ۱۶ ژوئیه را نشان می‌دهد.

برچسب‌هاChain Fusionبیت‌کوینECDSA آستانه‌ایChain Fusion Signer
منابع مستند۳ مرجع
  1. [۰۱]Release v0.5.1 — dfinity/chain-fusion-signergithub.com
  2. [۰۲]Chain Fusion Signer Candid interfaceraw.githubusercontent.com
  3. [۰۳]Chain Fusion — ICP Developer Docsdocs.internetcomputer.org
خواندنی بعدی

خبرخوان را در ایمیل بگیرید

هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.

خوراک RSS در دسترس · بدون هرزنامه