آلپنگلو در شبکه اصلی سولانا: نهایی سازی سریع و پیامدها

مقدمه: آلپنگلو در شبکه اصلی فعال است

شبکه سولانا ارتقای آلپنگلو را در شبکه اصلی در تاریخ 21 اکتبر فعال کرد که تغییری بنیادین در سازوکار رسیدن بلوک‌ها به اجماع ایجاد می‌کند. شبکه مکانیزم قدیمی رأی‌دهی درون‌زنجیره‌ای را با جریان رأی‌دهی مبتنی بر گواهی جایگزین کرد تا زمان لازم تا زمانی که یک بلوک غیرقابل بازگشت در نظر گرفته می‌شود را کوتاه‌تر کند. این تغییر، که در اپوک 1064 پس از امضای گواهی پیدایش توسط 446 از 654 اعتبارسنج در اسلات 459,653,000 ثبت شد، هم‌اکنون در حال بازتعریف نحوه فکر کردن توسعه‌دهندگان، کیف‌پول‌ها، صرافی‌ها، ایندکسرها و اعتبارسنج‌ها درباره توان عملیاتی، نهایی‌سازی و داده‌های درون‌زنجیره‌ای است.

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

آلپنگلو چه چیزی را جایگزین می‌کند و چرا اهمیت دارد

از آرا تاور بی‌اف‌تی تا رأی‌دهی مبتنی بر گواهی - وتور

پیش از آلپنگلو، سولانا از تاور بی‌اف‌تی استفاده می‌کرد، پروتکلی که به اعتبارسنج‌ها وابسته بود تا تراکنش‌های رأی را در دفترکل بنویسند. این تراکنش‌های رأی درون‌زنجیره‌ای تنها پس از جمع شدن آراء کافی در چند اسلات بعدی به نهایی شدن یک بلوک کمک می‌کردند. آن مکانیزم عملاً زمان‌های نهایی‌سازی را طولانی‌تر می‌کرد، زیرا زنجیره باید دستورالعمل‌های رأی را شامل می‌شد و منتظر چند اسلات برای تأییدهای کافی می‌ماند.

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

هدف طراحی در برابر واقعیت اندازه‌گیری‌شده

تیم مهندسی بنیاد سولانا هدف طراحی حدود 150 میلی‌ثانیه برای نهایی‌سازی بلوک را اعلام کرده است. مقایسه پیش از راه‌اندازی بنیاد از رفتار پیشین نهایی‌سازی به‌عنوان مرجع عدد 12.8 ثانیه را استفاده کرده بود. اندازه‌گیری‌های مستقل که بلافاصله پس از فعال‌سازی منتشر شدند، میانه نهایی‌سازی مشاهده‌شده را در بازه 24 ساعته برابر 404 میلی‌ثانیه گزارش دادند، با صدک 90 برابر 579 میلی‌ثانیه و صدک 99 برابر 765 میلی‌ثانیه. این ارقام نشان‌دهنده بهبود قابل‌توجه نسبت به رفتار پیشین هستند، اما همچنین تفاوت بین هدف مهندسی و تأخیرهای متنوعی که کاربران واقعا تجربه می‌کنند را نشان می‌دهند.

سه دلیل وجود دارد که اعداد گزارش‌شده متفاوت‌اند:

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

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

آنچه کاربران احساس می‌کنند و آنچه بدون تغییر می‌ماند

سرعت: نهایی‌سازی در برابر پردازش

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

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

مواقعی که نهایی‌سازی سریع‌تر پرداخت را تسریع نمی‌کند

چند بخش از مسیر پرداخت یا تسویه مستقل از زمان‌بندی نهایی‌سازی جدید زنجیره باقی می‌مانند:

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

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

چطور نهایی‌سازی مشاهده می‌شود: ساعت‌های متعدد مهم‌اند

نقاط اندازه‌گیری مختلف به سوالات متفاوت پاسخ می‌دهند

هیچ عدد نهایی‌سازی واحدی وجود ندارد که به هر سؤال عملی پاسخ دهد. این نقاط مشاهده را در نظر بگیرید:

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

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

چرا سیاست‌های کیف‌پول و پذیرنده تاثیر قابل مشاهده را تعیین می‌کنند

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

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

شمارش تراکنش‌ها، توان عملیاتی و نمودارها: چرا اعداد ممکن است کاهش یابند

تراکنش‌های رأی از دفترکل خارج شدند؛ نمودارها باید تطبیق یابند

در زیر تاور بی‌اف‌تی، آراء اعتبارسنج‌ها درون زنجیره بودند و در داشبوردهای تراکنش در ثانیه (TPS) شمارش می‌شدند. با آلپنگلو، آراء خارج از جریان تراکنش‌های عادی تبادل می‌شوند و گواهی‌سازی در پاورقی بلوک‌ها ثبت می‌شود. در نتیجه، عدد سرخط تراکنش در ثانیه ممکن است کاهش یابد حتی وقتی فعالیت کاربران تغییر نکرده باشد.

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

هزینه‌ها، درآمد و بلیط ورود

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

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

ایندکسرها، ارائه‌دهندگان RPC و جریان‌های داده: برای کاندیداهای رقابتی بلوک آماده باشید

شناسه‌های بانک و کاندیداهای رقابتی

آلپنگلو امکان این را معرفی می‌کند که جریان‌های داده چند کاندیدای بانک را برای یک اسلات واحد افشا کنند. آگاوه 4.3 رویدادها را با یک شناسه bank_id برچسب‌گذاری می‌کند تا مشتریان بتوانند کاندیداها را جدا نگه دارند و بعداً بانک برنده را شناسایی کنند. ایندکسرها و مصرف‌کنندگان استریم باید رویدادها را بر اساس جفت اسلات-بانک بافر کنند و بانکی را که به تأیید می‌رسد انتخاب کنند.

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

آمادگی ارائه‌دهنده و فراداده استریم

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

منطق تلاش مجدد، تایم‌اوت‌ها و رفتار کلاینت

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

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

کلاینت‌های خوب طراحی‌شده باید:

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

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

اقتصاد اعتبارسنج و تغییرات عملیاتی

بلیط ورود اعتبارسنج و مکانیک حساب

آلپنگلو هزینه دوره‌ای اعتبارسنج را از تراکنش‌های رأی درون‌زنجیره‌ای که از حساب‌های هویتی پرداخت می‌شد منتقل می‌کند به بلیط ورود اعتبارسنج 0.8 SOL که از حساب رأی سوخته می‌شود. این تغییر چند اثر عملیاتی دارد:

• بلیط به‌صورت پیش‌پرداخت برای اپوک آینده شارژ می‌شود؛ اپراتورها باید مطمئن شوند حساب رأی قبل از مرز اپوک صندوق کافی دارد.
• تأمین مالی حساب هویتی قدیمی دیگر بلیط جدید را پوشش نمی‌دهد؛ مهاجرت‌هایی که فقط به‌صورت ظاهری وجوه را جابه‌جا کرده‌اند ممکن است باعث شوند یک اعتبارسنج هزینه را از دست بدهد و توانایی رأی‌دهی یا تولید بلوک برای اپوک بعدی را از دست بدهد.
• بلیط ثابت 0.8 SOL مستقل از اندازه است، بنابراین اپراتورهای کوچک همان مقدار مطلق را مانند اپراتورهای بزرگ می‌پردازند. این نسبت‌های اقتصادی را برای اعتبارسنج‌های کوچکتر تغییر می‌دهد و ممکن است بر تمرکز بلندمدت قدرت استیک تاثیر بگذارد.

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

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

فعال‌سازی آگاوه 4.3.2 یا کلاینت‌های سازگار جیتو-سولانا یا هارمونیک سالسا را لازم داشت. هر پیاده‌سازی کلاینت جایگزین برای مهاجرت پشتیبانی نشده بود؛ برای مثال فایردنسر و فرانکن‌دنسر بخشی از مسیر فعال‌سازی نبودند. موفقیت مهاجرت نشان‌دهنده هماهنگی اعتبارسنج‌هاست، اما اثبات نمی‌کند که همه پیاده‌سازی‌های کلاینت یا هر اپراتور اعتبارسنج همان روز آماده بودند. تنوع کلاینت همچنان یک شاخص مهم تاب‌آوری است که پس از هر مهاجرت پروتکلی باید پایش شود.

چه چیزهایی ناقص مانده: روتور و توزیع داده

آلپنگلو یک بسته است؛ وتور زنده است، روتور در انتظار

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

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

انتشار، تحویل RPC و تأخیرهای روبه‌کاربر

موارد کند مشاهده‌شده می‌توانند در چند مرحله رخ دهند:

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

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

کیفیت داده و خطر تاریخچه نادرست

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

ایندکسری که رویدادها را از چند ارائه‌دهنده بدون رعایت شناسه‌های بانک ادغام کند در خطر تولید دفترکل کاننیکال نادرست برای برنامه‌های پایین‌دستی قرار دارد. مشکلات شامل موارد زیر است:

• نسبت دادن تراکنش‌ها به کاندیدای بلوک اشتباه.
• مانده حساب‌هایی که به‌صورت جهش‌دار یا بدون مصالحه ظاهر می‌شوند.
• سیستم‌های معاملاتی که به رویدادهایی واکنش نشان می‌دهند که بعداً توسط فرآیند نهایی‌سازی رها شده‌اند.

رویکرد صحیح این است که درون یک فید با کلید اسلات-بانک کار کنید و هنگام مصالحه بین ارائه‌دهندگان از هش بلوک برنده به‌عنوان مرجع قطعی استفاده کنید. این از بازنویسی‌ها و بازسازی‌های غیرممکن بلوک جلوگیری می‌کند.

اثبات تاریخ و تغییرات جریان شرد

آگاوه و آلپنگلو نحوه نمایش زمان‌بندی اثبات تاریخ را در جریان‌ها تغییر می‌دهند. ورودی‌های تیک به همان شکل قبلی در جریان شرد گنجانده نمی‌شوند و برنامه‌هایی که زمان‌سنج ساعت (Clock timestamp) را می‌خوانند ممکن است منبع متفاوتی نسبت به قبل ببینند. این‌ها جزئیات پیاده‌سازی هستند که فرمت تراکنش کاربر را تغییر نمی‌دهند، اما می‌توانند نرم‌افزاری را که بر مفروضات زمان‌بندی قدیمی تکیه کرده است خراب کنند. توسعه‌دهندگان باید کدی را که به ریتم دفترکل یا فرضیات مبتنی بر تیک وابسته است بازبینی کنند.

معیارهایی که باید منتشر و پایش شوند

فهرست پیشنهudiپذیری پیشنهادی برای تیم‌های محصول

برای گزارش بهبودهای معنادار و جلوگیری از ادعاهای گمراه‌کننده، ارائه‌دهندگان باید معیارهای زیر را با تعریف روشن نقاط مشاهده منتشر و پایش کنند:

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

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

راهنمای عملی برای ذی‌نفعان مختلف

توسعه‌دهندگان کیف‌پول

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

صرافی‌ها و نگهدارندگان

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

ایندکسرها و فروشندگان داده

• داخل سیستم از کلیدهای اسلات-بانک استفاده کنید و با استفاده از هش‌های بلوک بین ارائه‌دهندگان مصالحه کنید.
• اعتبار دهید که فیدهای شما فراداده گواهی لازم برای تعیین بانک برنده را فراهم می‌کنند.
• منطق بازگردانی و بازنمایه‌سازی را حسابرسی کنید؛ اطمینان حاصل کنید بازسازی می‌تواند رویدادهای چندبانکی رقابتی را بدون ایجاد ادغام‌های غیرممکن هندل کند.

فروشندگان و اپراتورهای نقطه‌فروش

• سیاست پذیرش خود را بازبینی کنید: آیا منتظر وضعیت نهایی می‌مانید، یا یک تأیید «پردازش‌شده» و یا رویکرد ترکیبی؟
• برای ترمینال‌های آفلاین، اطمینان حاصل کنید رفتار پشتیبان روشن است و رویه‌های مصالحه برای رویدادهای نهایی‌شده بعدی وجود دارد.
• یک بیانیه ساده و مشتری‌پسند درباره زمان‌های تأیید مورد انتظار و معنای آن‌ها برای صدور رسید منتشر کنید.

تفسیر داده‌های نخستین شبکه اصلی و انتظار بعدی

نمونه کوتاه‌مدت در برابر رفتار بلندمدت

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

متغیرهای کلیدی که اندازه‌گیری‌های بعدی را تصحیح خواهند کرد شامل موارد زیرند:

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

یک هفته لغزان از مشاهدات در میان چند ارائه‌دهنده RPC مستقل، از جمله دوره‌های اوج، برای فروشندگان و معامله‌گران ارزشمندتر از اندازه‌گیری‌های جداافتاده از هفته راه‌اندازی خواهد بود.

کدام دم‌های کند بیشتر اهمیت دارند

برنامه‌هایی که انتقالات با ارزش بالا را مدیریت می‌کنند یا نیاز به تسویه میان‌زنجیره‌ای دارند حساس به دم کند - صدک‌های 90 و 99 نهایی‌سازی - خواهند بود تا میانه. بسیاری از موارد را پروتکل می‌تواند بهبود دهد اما به‌خاطر انتشار یا مسائل ارائه‌دهنده حل نشده باقی بماند. این برنامه‌ها باید دم کند را اندازه‌گیری کنند و SLAهای مربوطه را از ارائه‌دهندگان زیرساخت مطالبه نمایند.

چرا زبان دقیق در بازاریابی اهمیت دارد

وسوسه گفتن «فوری» و دلیل اجتناب از آن

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

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

سؤالات عملیاتی باز و حوزه‌هایی که باید زیر نظر بمانند

حضور اعتبارسنج و تمرکز سهام

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

تنوع کلاینت و پیاده‌سازی‌های جایگزین

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

درستی ایندکسینگ و مصالحه بین ارائه‌دهندگان

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

مثال‌های عملی: چطور سناریوهای مختلف تغییر می‌کنند

خرید قهوه خرده‌فروشی

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

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

مثال واریز به صرافی

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

نتیجه‌گیری: صرافی‌ها باید بازه زمانی از رویداد نهایی‌شده درون‌زنجیره تا اعتباردهی به مشتری را منتشر کنند تا کاربران اثر واقعی را درک کنند.

چه مواردی را بعداً اندازه‌گیری کنید: آزمایش‌های پیشنهادی

تیم‌هایی که می‌خواهند مزیت مقابل کاربر آلپنگلو را کمّی کنند باید این آزمایش‌های کنترل‌شده را اجرا کنند:

• آزمایش کیف‌پول: توزیع زمان‌ها را از تأیید کاربر تا نمایش نهایی‌سازی در کیف‌پول هنگام تغییر از تعهدات پردازش‌شده به نهایی‌شده اندازه‌گیری کنید. این آزمایش را در میان چند ارائه‌دهنده RPC و جغرافیا اجرا کنید.
• آزمون مسیر صرافی: هر گام داخلی را از دریافت گواهی درون‌زنجیره تا اعتباردهی مانده ابزارسنجی کنید و میانه‌ها و دم‌ها را برای هر مؤلفه گزارش دهید.
• آزمون مصالحه ایندکسر: فیدها را از دو ارائه‌دهنده مستقل ادغام کنید، رویدادهای چندبانکی را شبیه‌سازی کنید، و تأیید کنید کلیدهای اسلات-بانک بعلاوه هش‌های بلوک نهایی تاریخچه‌های سازگار تولید می‌کنند.
• آزمون بلیط ورود اعتبارسنج: مرزهای اپوک را برای یک اپراتور اعتبارسنج که وجوه را نادرست جابه‌جا کرده شبیه‌سازی کنید و مسیر اصلاح خودکار را برای جلوگیری از از دست دادن بلیط آزمون کنید.

انتشار زمان‌های سرویس قبل و بعد با تعاریف دقیق قانع‌کننده‌ترین شواهد خواهد بود که کاربران واقعاً سود می‌برند.

نتیجه‌گیری: یک بهبود پروتکلی که امکان تغییر محصول را باز می‌کند

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

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

چه چیزهایی را دنبال کنید

• نهایی‌سازی مشاهده‌شده: میانه لغزان و قرائت‌های صدک‌های کند را از داشبورد بنیاد و پایشگران مستقل مقایسه کنید، با تعریف روشن نقاط مشاهده.
• زمان‌های کیف‌پول و صرافی: بازه‌ها از تأیید مشتری تا تأیید قابل‌مشاهده یا مانده اعتباردهی‌شده را پایش و منتشر کنید.
• ترافیک قابل مقایسه: تراکنش‌های کاربر غیر رأی را قبل و بعد از 21 اکتبر دنبال کنید تا حذف رأی را با کاهش تقاضا اشتباه نگیرید.
• خطاهای استریم: بررسی کنید آیا RPC و ارائه‌دهندگان ایندکسر از بازسازی بلوک آگاه از بانک و فراداده نهایی‌سازی پشتیبانی می‌کنند یا نه.
• بلیط ورود اعتبارسنج: تامین مالی حساب رأی، اعتبارسنج‌های فعال و تنوع کلاینت پشتیبانی‌شده را همزمان با تکرار بلیط 0.8 SOL در هر اپوک نظارت کنید.

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