شبکه بیس تاریخ ۵ نوامبر را در ساعت ۱۸:۰۰ UTC برای ارتقاء شبکه اصلی خود تعیین کرده است. این ارتقاء که دنیم نام دارد، معرفی بلاک‌های نیتیو با فرکانس ۲۰۰ میلی‌ثانیه را به همراه خواهد داشت.
برنامه‌های کاربردی که از Flashblocks استفاده می‌کنند، باید خود را برای یک جریان داده متفاوت آماده کنند. اطلاعیه وضعیت شبکه بیس اعلام کرده است که انتظار می‌رود شبکه اصلی در طول دوره نگهداری دنیم فعال بماند و از اپراتورهای نود خواسته شده است که قبل از فعال‌سازی، نسخه مورد نیاز را نصب کنند.
تغییر پارادایم بلاک‌های بیس
برای برنامه‌های کاربردی، تغییر کلیدی، جابجایی به بلاک‌های نیتیو هر ۲۰۰ میلی‌ثانیه است. این موضوع فراتر از یک شاخص پیشرفت سریع است؛ نرم‌افزارهایی که بلاک‌ها، رسیدها و مُهرهای زمانی را می‌خوانند، باید معنای این فرکانس جدید را درک کنند. مستندات دنیم بیس، حرکت از یک بلاک واحد هر دو ثانیه به پنج بلاک کامل در هر ثانیه را توصیف می‌کند که جایگزین Flashblocks می‌شود. برنامه‌های کاربردی که جریان قبلی را دنبال می‌کنند، نیاز دارند تا به جریان‌های بلاک نیتیو و RPC مهاجرت کنند.
پیامدهای فنی برای برنامه‌ها
این تمایز مهم است زیرا برنامه‌های کاربردی بر اساس داده‌هایی که دریافت می‌کنند، فرضیاتی را بنا می‌کنند. شناسه بلاک می‌تواند برای سازماندهی رسیدها، به‌روزرسانی موجودی یا تصمیم‌گیری برای تازه‌سازی صفحه معاملات استفاده شود. افزایش فرکانس، حتی اگر اقدام تجاری اصلی یکسان بماند، نحوه اجرای این فرآیندها را تغییر می‌دهد. برای یک صرافی، این می‌تواند به معنای پردازش به‌روزرسانی‌های بیشتر بین دو تعامل کاربر باشد. برای یک ایندکسر، به معنای رکوردهای بلاک بیشتر و تغییرات وضعیت مکرر است. چالش اصلی، حفظ پاسخگویی برنامه بدون تبدیل یک بلاک‌چین سریع‌تر به یک صف انتظار در زیرساخت داخلی آن است.
ملاحظات مربوط به نهایی شدن تراکنش‌ها
کاربران اغلب چندین نوع تأیید را مشاهده می‌کنند که در رابط کاربری مشابه به نظر می‌رسند. یک برنامه کاربردی می‌تواند تراکنش ارسالی را نمایش دهد، نشان دهد که وارد یک بلاک شده است و بعداً نتیجه را به اندازه کافی نهایی شده برای هدف خود تلقی کند. اینها تصمیمات جداگانه‌ای هستند. یک بازه زمانی کوتاه‌تر برای بلاک‌ها ممکن است زمان مشاهده اجرای تراکنش را بهبود بخشد، اما به خودی خود، نحوه مدیریت نهایی شدن در هر بریج، صرافی یا برنامه مالی را مشخص نمی‌کند. این خدمات دارای قوانین اضافی برای زمان قابل اتکا بودن نتایج یا آزادسازی موجودی هستند. بنابراین، آزمون عملی، سرتاسری است. یک کیف پول که به‌روزرسانی سریع‌تر شبکه را دریافت می‌کند اما منتظر یک بک‌اند کند می‌ماند، ممکن است بهبود کمی را نشان دهد. یک برنامه معاملاتی که از جریان جدید به درستی استفاده می‌کند، می‌تواند تجربه‌ای فوری‌تر ارائه دهد بدون اینکه ادعا کند تمام ریسک‌های نهایی شدن از بین رفته‌اند.
زمان‌بندی دقیق و سازگاری
دنیم همچنین اطلاعات زمانی با دقت میلی‌ثانیه را معرفی می‌کند و فیلدهای موجود مبتنی بر ثانیه را حفظ می‌کند. این امر مشکل سازگاری را برای سیستم‌هایی ایجاد می‌کند که منطق آنها فرض می‌کند که هر بلاک جدید همیشه یک مُهر زمانی تمام ثانیه را به همراه دارد. فرض کنید یک برنامه کاربردی رویدادها را صرفاً بر اساس مُهر زمانی که همیشه ذخیره کرده است، گروه‌بندی می‌کند. چندین بلاک می‌توانند در همان ثانیه قرار گیرند. اگر برنامه این مقدار مشترک را با یک کلید مرتب‌سازی منحصربه‌فرد اشتباه بگیرد، می‌تواند سوابق نامرتبط را ادغام کند یا آنها را به ترتیب نادرست پردازش کند. این یک مثال از طراحی برنامه است، نه گزارشی از یک نقص موجود در بیس. این نشان می‌دهد که چرا پشتیبانی از یک شبکه سریع‌تر به بیش از تغییر یک عدد نمایش داده شده نیاز دارد. طرح‌های ذخیره‌سازی، قوانین مرتب‌سازی و نظارت باید همگی داده‌های ارائه شده را منعکس کنند.
پیامدهای آمادگی برای کاربران
اپراتورها باید الزامات رسمی انتشار را دنبال کنند، در حالی که تیم‌های محصول باید مفروضات موجود در یکپارچه‌سازی‌های خود را بررسی کنند. اطلاعیه نود و مستندات برنامه به بخش‌های مختلفی از این آمادگی پاسخ می‌دهند. قوی‌ترین شواهد پس از فعال‌سازی، تولید پایدار بلاک، فعالیت به درستی ایندکس شده و مدیریت عادی سپرده‌ها، برداشت‌ها و تعاملات قراردادها خواهد بود. این نتایج برای کاربران مهم‌تر از یک مقایسه نظری توان عملیاتی هستند. دنیم یک کار زیرساختی برنامه‌ریزی شده است، نه رویدادی که قبلاً رخ داده است. اگر فعال‌سازی طبق برنامه پیش برود، برنامه‌های بیس پایه‌ای متفاوت برای نمایش پیشرفت تراکنش خواهند داشت. اینکه آیا کاربران متوجه سرویس روان‌تری می‌شوند یا خیر، به میزان موفقیت نرم‌افزارهای اطراف در همگام شدن با آن بستگی دارد.
