پیشنهاد امضای آفلاین سولانا، تأییدیه‌ها را پس از تراکنش‌های ناموفق معتبر نگه می‌دارد

برنامه سولانا برای بازنشستگی نانس‌های بادوام، که اجازه می‌دهد تراکنش‌ها به‌صورت آفلاین امضا شده و بعداً پخش شوند، تأیید کلید سرد را حفظ می‌کند در حالی که آدرس‌هایی که دارایی‌های تحت تأثیر را کنترل می‌کنند تغییر می‌کند. برای صرافی‌ها، نگهدارندگان و اپراتورهای خزانه‌داری که از این روش امضا استفاده می‌کنند، جایگزین پیشنهادی یک برنامه بین تأیید کلید سرد و اجرای آن اضافه می‌کند.

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

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

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

کلید همچنان تأیید می‌کند، اما حساب تغییر می‌کند

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

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

در زیر امضاکننده برنامه‌محور، کلید سرد یک پیام مجوز را به جای تراکنش ارسال شده به شبکه امضا می‌کند. یک رله‌کننده آن تأیید را در یک تراکنش بلاک‌هاش تازه قرار می‌دهد. برنامه امضاکننده تأیید را بررسی کرده و دستورات تأیید شده را با آدرس مشتق‌شده کلید به عنوان امضاکننده اجرا می‌کند.

PDA هیچ کلید خصوصی ندارد. توانایی آن برای عمل از تأیید کلید اصلی توسط برنامه امضاکننده ناشی می‌شود. مشتق کردن آدرس هیچ دارایی یا مجوزی را منتقل نمی‌کند: آن‌ها باید به‌صورت جداگانه منتقل شوند.

راهنمای مهاجرت توصیف می‌کند که چگونه SOL بومی را به آدرس مشتق‌شده منتقل کرده، موجودی توکن‌ها را به حساب‌هایی که تحت کنترل آن هستند منتقل کرده و مجوزهای مینت یا فریز را به آن منتقل کند. حساب‌های استیک می‌توانند مجوز استیکر، مجوز برداشت یا هر دو را منتقل کنند، بسته به مجوزی که در حال مهاجرت است. این‌ها کنترل‌های جداگانه‌ای هستند، نه یک سوئیچ کیف پول جهانی.

بنیاد پیشنهاد می‌کند که این انتقال‌ها در حالی که نانس‌های بادوام قدیمی هنوز کار می‌کنند، کامل شوند. برای خزانه تحت تأثیر، تأیید نرم‌افزار امضای جدید تنها بخشی از کار است. موجودی حساب آن و مجوزهایی که هر کلید در حال حاضر دارد، تعیین می‌کند که چه چیزی باید تغییر کند.

دو طراحی نامزد همچنین SOL بومی را به‌طور متفاوتی مدیریت می‌کنند. حساب SOL مشتق‌شده از امضاکننده برنامه‌محور متعلق به سیستم است و می‌تواند SOL را از طریق یک انتقال عادی تأیید شده ارسال کند. وکتور یک حساب متعلق به برنامه را راه‌اندازی کرده و SOL را از طریق برداشت یا عملیات بستن مجاز خود آزاد می‌کند.

چه چیزی امضای سرد به یک رله‌کننده اجازه می‌دهد

انتخاب پیاده‌سازی بر چگونگی محدود کردن تأیید تراکنش اطراف آن تأثیر می‌گذارد.

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

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

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

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

برای اپراتورها، قابلیت تلاش مجدد به این معنی است که یک ارسال ناموفق لزوماً تأیید را باطل نکرده است. بدون یک مهلت اجباری، می‌تواند برای اجرای بعدی در دسترس باقی بماند در حالی که نانس آن تغییر نکرده است.

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

دسترسی به برنامه یک آزمایش نگهداری جداگانه است

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

برنامه‌ها سپس اقدامات تأیید شده را از طریق فراخوانی بین برنامه‌ها، یا CPI دریافت می‌کنند: یک برنامه برنامه دیگری را فراخوانی می‌کند. این می‌تواند با قاعده یک برنامه که یک اقدام باید به‌طور مستقیم به‌عنوان یک دستورالعمل سطح بالا وارد شود، در تضاد باشد. بررسی‌هایی که فقط دستورالعمل‌های بازپرداخت سطح بالا یا تأیید امضا را بررسی می‌کنند، همچنین می‌توانند یک اقدام را که در داخل برنامه امضاکننده قرار دارد، از دست بدهند.

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

نگهبان CPI Token-2022 نشان می‌دهد که چرا سازگاری نیاز به ارزیابی دقیق در سطح حساب دارد. با فعال‌سازی نگهبان، انتقال‌ها و سوزاندن‌های CPI نیاز به مجوز نماینده دارند؛ تأییدها از طریق CPI ممنوع است و تغییر مالک حتی خارج از CPI نیز ممنوع است. نمایندگان دائمی دارای استثنائات در انتقال و سوزاندن هستند.

این قوانین خاص‌تر از یک ممنوعیت کلی بر هر اقدام PDA هستند. ممکن است یک مسیر انتقال مبتنی بر نماینده وجود داشته باشد، اما ایجاد یا استفاده از آن مجوز و تصمیم‌گیری‌های سیاست نگهداری خود را معرفی می‌کند.

نگرانی‌های نهادی که در مارس مطرح شد، بر دسترسی به برنامه و کنترل‌هایی که تحت آن‌ها وجوه ممکن است حرکت کنند، متمرکز بود. در بحث 4 مارس، یک شرکت‌کننده که خود را مایکل از Fireblocks معرفی کرد، از حذف nonce حمایت کرد در حالی که به مهاجرت CPI Passthrough، وابستگی قرارداد و بارهای سازگاری DeFi اعتراض کرد. او به جای مسیر امضای مبتنی بر CPI، به پاکت‌های تراکنش و Sudo به عنوان یک جایگزین تمایل داشت.

گرنت، که خود را در واحد 410 معرفی کرد، همان روز گفت که یک برنامه امضاکننده کوچک و قابل حسابرسی ممکن است مهاجرت مجوز را قابل قبول کند. او یک راه‌حل موقتی که دارایی‌ها را به یک امضاکننده داغ منتقل می‌کند، حتی برای یک عملیات اتمی، رد کرد زیرا وجوه باید با ذخیره‌سازی سرد در مدل غیر نگهداری خود مرتبط باقی بمانند.

یک طراحی قابل آزمایش هنوز به یک مسیر مهاجرت تولید نیاز دارد

مستندات فعلی امضاکننده برنامه‌نویسی، استقرار devnet و حسابرسی‌های در حال پیشرفت را گزارش می‌دهد، با نیاز به اصلاحات قبل از انتشار v1 آن و هر استقرار mainnet. رابط‌های آن ممکن است تغییر کنند. مستندات استفاده هنوز شبیه‌سازی و ارسال رله را به عنوان به زودی علامت‌گذاری می‌کند، در حالی که چندین عملیات مهاجرت به طور مشابه در راهنما ناتمام هستند.

Vector کد پیاده‌سازی و شناسه‌های برنامه را منتشر می‌کند؛ README آن وضعیت حسابرسی یا استقرار mainnet را بیان نمی‌کند.

در همین حال، کیت ورود به پروتکل فعلی Fireblocks هنوز تزریق nonce دائمی خودکار را برای ادغام‌های انتخابی WalletConnect، از جمله Jupiter و Kamino، با یک پنجره اعتبار 15 دقیقه‌ای مدیریت شده توسط تأمین‌کننده پیش‌فرض توصیف می‌کند. این توصیف یک جریان تأیید موجود است که باید یک جایگزین آن را در بر بگیرد.

یک مهاجرت عملی نیاز به یک جایگزین mainnet حسابرسی شده، ابزارهای قابل استفاده و مسیرهای برنامه دارد که کنترل‌های تأیید هر اپراتور را حفظ کند.