به‌روزرسانی Nitro در آربیتروم چیست و چگونه کار می‌کند؟

بسیاری از شما نام کمپین اودیسه آربیتروم (Arbitrum Odyssey) را شنیده‌اید و بسیاری نیز در این کمپین شرکت کرده‌اید. اودیسه در تاریخ ۲۱ ژوئن (۳۱ خرداد ۱۴۰۱) آغاز شد و کمپین بدین صورت بود که شما هر هفته، باید کارهای از پیش تعیین شده‌ای انجام می‌دادید تا واجد شرایط دریافت NFTهای این کمپین شوید. این کمپین به مدت ۸ هفته ادامه داشت و هر هفته، ۲ NFT به کاربران واجد شرایط اعطا می‌شد؛ اما متاسفانه در هفته دوم اودیسه، به دلیل استقبال بسیار زیاد کاربران از این کمپین و ازدحام شدید شبکه آربیتروم، کارمزدهای این شبکه حتی از اتریوم نیز پیشی گرفت و باعث ایجاد مشکلاتی برای شرکت‌کنندگان شد. از این رو، تیم Arbitrum اودیسه را فعلا لغو کردند، تا آپدیتی به نام نیترو را روی این شبکه پیاده‌سازی کنند تا مقیاس‌پذیرتر شود و بتواند شلوغی شبکه را تحمل کند. این آپدیت در تاریخ ۳۱ آگوست ۲۰۲۲ (۹ شهریور ۱۴۰۱) با موفقیت روی شبکه آربیتروم پیاده‌سازی شد. اما به‌روزرسانی Nitro در آربیتروم چیست؟ در این مقاله به معرفی آپدیت نیترو، نحوه کارکرد و تاثیر آن روی شبکه آربیتروم می‌پردازیم. با میهن بلاکچین همراه باشید. 

به‌روزرسانی Nitro در آربیتروم چیست؟

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

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

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

Nitro یک زنجیره سازگار با اتریوم ارائه می‌دهد و قراردادهای هوشمند را اجرا می‌کند؛ در واقع می‌توان گفت که بر اساس کدهای ماشین مجازی اتریوم (EVM) دیپلوی شده است و نودهای آن از همان APIهایی پشتیبانی می‌کنند که در شبکه اتریوم وجود دارند. 

پروتکل نیترو هم امنیت و هم تکامل زنجیره لایه ۲ آربیتروم را تضمین می‌کن؛ البته با این فرض که ۱: زنجیره اتریوم امن و زنده باشد و ۲: حداقل یک مشارکت‌کننده در پروتکل نیترو خوش‌رفتار باشد. این پروتکل به‌عنوان خوشبینانه (Optimistic) شناخته می‌شود؛ زیرا زمانی که طرفین (نودها) رفتار خوبی داشته باشند، عملکرد موثرتر و بهتری خواهد داشت. 

آپدیت نیترو چگونه کار می‌کند؟

طراحی نیترو ۴ ویژگی اصلی دارد: 

• ترتیب‌گذاری و سپس اجرای قطعی: نیترو تراکنش‌های ثبت شده را در دو مرحله انجام می‌دهد؛ ابتدا تراکنش‌ها را در یک توالی قرار می‌دهد تا پردازش شوند و سپس این توالی را منتشر می‌کند. پس از این کار، یک تابع انتقال حالت قطعی (Deterministic State Transition Function) به ترتیب هر تراکنش را اجرا می‌کند.
• استفاده از کدهای Geth اتریوم: توابع اجرای اصلی و حفظ حالت در نیترو، توسط کد متن بازی که از پکیج کلاینت Geth (مخفف Go Ethereum) گرفته می‌شود، انجام می‌شود. Geth محبوب‌ترین نرم‌افزار نود اتریوم است. با کامپایل کردن این کدها به‌عنوان کتابخانه یا Library، نیترو اطمینان حاصل می‌کند که اجرا و حالت شبکه، با اتریوم سازگار باشند. 
• جداسازی اجرا از اثبات: Nitro کدهای تابع انتقال حالت را برای دستیابی به دو بخش مجزا کامپایل می‌‌کند: کدهایی که برای اجرای بومی (در عملیات معمولی نود نیترو) استفاده می‌شوند. این کدها به کدهای مونتاژ وب قابل حمل (Portable Web Assembly یا به اختصار WASM) که برای پروتکل اثبات تقلب (در صورت نیاز) کامپایل می‌شوند. این رویکرد دوگانه، باعث اجرای سریع می‌شود؛ در حالی که همزمان کدهای ساختارمند مستقل از ماشین را نیز اثبات می‌کنند.
• رولاپ آپتیمیستیک با اثبات‌های تقلب تعاملی: نیترو روی طراحی اصلی آربیتروم ساخته شده، اما از پروتکل Optimistic Rollup بهبود یافته (RBlock) که خود این پروتکل نیز بر اساس یک پروتکل اثبات تقلب تعاملی ساخته شده، استفاده می‌کند. 

در ادامه، هر کدام از این ویژگی‌ها را به طور مفصل‌تر بررسی می‌کنیم.

ترتیب‌بندی و سپس اجرای قطعی

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

در اصل، Sequencer می‌تواند توسط سیاست‌های ترتیب‌گذاری تراکنش‌ها اجرا شود. این سیاست‌ها First-Come, First Serve هستند؛ یعنی هر تراکنشی که زودتر ثبت شود، اولویت بالاتری نسبت به بقیه دارد. اجرای این قانون ساده است و لتنسی (Latency) یا تاخیر را نیز کاهش می‌دهد. 

تراکنش‌های ثبت‌شده ممکن است معتبر یا نامعتبر باشند. برای مثال، ممکن است یک تراکنش فاقد امضای معتبر و یا داده‌های زباله (Garbage Data) باشند. یک سیکوئنسر صادق، این تراکنش‌های نامعتبر را حذف می‌کند، اما پروتکل هیچ فرضی در مورد معتبر بودن تراکنش‌های موجود در خروجی Sequencer ندارد؛ اجرای تابع انتقال حالت روی تراکنش‌های نامعتبر، خود به خود آنها را حذف می‌کند.

مولفه Sequencer چیست؟

سیکوئنسر برای تراکنش‌های دریافتی، بر اساس سیاست First Come, First Serve به‌کار می‌رود. در حال حاضر Sequencer یک مولفه متمرکز است، که توسط Offchain Labs اجرا می‌شود. سیکوئنسر به دو صورت تراکنش‌ها را ترتیب‌بندی می‌کند؛ ابتدا یک فید (Feed) با زمان حال حاضر (لحظه‌ای) از تراکنش‌های مرتب شده را منتشر می‌کند که هر کدام از طرفین (نودها) می‌توانند آنها را بردارند. در Feed نیترو، تراکنش‌های ترتیب‌بندی شده و مرتب تحویل داده می‌شوند. Sequencer می‌تواند همیشه این کار را بدون خطا انجام دهد؛ بنابراین انحراف از این ترتیب‌ها، نشان‌دهنده دستکاری یا بدخواهی سیکوئنسر خواهد بود. 

در تصویر بالا، پروسه تراکنش‌ها در نیترو را می‌بینیم؛ سیکوئنسر تراکنش‌ها را ترتیب‌بندی می‌کند و آنها را با زمان واقعی (لحظه‌ای) به Feed ارسال می‌کند و دسته‌های دیتا را در شبکه لایه ۱ اتریوم فشرده‌سازی می‌کند. سپس این تراکنش‌ها به ترتیب، توسط تابع انتقال حالت قطعی پردازش می‌شوند، که حالت زنجیره را آپدیت می‌کند و بلاک‌های لایه ۲ را می‌سازد. این بلاک‌ها سپس در زنجیره لایه ۱ مستقر می‌شوند. 

حالت دوم، سیکوئنسر ترتیب تراکنش‌ها را به‌عنوان کال‌دیتای اتریوم (Ethereum Calldata) به شبکه ارسال می‌کند. این مولفه دسته‌ای از تراکنش‌های متوالی را تجمیع می‌کند، آنها را با استفاده از الگوریتم فشرده‌سازی Brotli (در حال حاضر) فشرده می‌کند و در نهایت، نتیجه را به کانترکت Inbox زنجیره نیترو (که روی لایه ۱ اتریوم اجرا می‌شود) انتقال می‌دهد (درباره اینباکس در ادامه صحبت خواهیم کرد). این دسته تراکنش‌ها نمایانگر سفارش تراکنش نهایی و معتبر هستند؛ بنابراین زمانی که تراکنش سیکوئنسر به اینباکس نهایی شد، تراکنش زنجیره Nitro نیز نهایی می‌شود. 

زمانی که تعداد تراکنش‌های زیادی وارد می‌شوند (شبکه شلوغ می‌شود)، به همان صورت مستقیما به سیکوئنسر فرستاده می‌شوند و در یکی از دسته‌های آن قرار می‌گیرند؛ اما در این مواقع برای ثبت شدن تراکنش‌ها، راه دیگری اتخاذ می‌شود؛ روشی به نام اینباکس تاخیری (Delayed Inbox). این روش دو هدف را دنبال می‌کند. اولی این است که این روش به تراکنش‌ها اجازه می‌دهد که در قراردادهای لایه ۱ اتریومی ثبت شوند که نمی‌توانند امضای دیجیتالی مورد نیاز برای ارسال تراکنش از طریق Sequencer را تولید کنند. هدف دوم این است که اینباکس تاخیری یک روش بک‌آپ برای هر کسی که تراکنشش را ثبت می‌کند، ارائه می‌دهد. سپس سیکوئنسر از بین آنها شروع به جدا کردن تراکنش‌های معتبر می‌کند. 

یک تراکنش با صدا کردن کانترکت‌های اینباکس زنجیره نیترو، ابتدا به اینباکس تاخیری اضافه می‌شود. این قراردادها صف تراکنش‌های دارای برچسب زمانی (Timestamp) را حفظ می‌کنند. سپس سیکوئنسر می‌تواند اولین تراکنش صف Delayed Inbox را در ترتیب‌بندی خود قرار دهد. در اینجا، Sequencer صادق، این کار را پس از یک تاخیر انجام می‌دهد؛ این تاخیر (معمولا ۱۰ دقیقه) برای اطمینان از این انجام می‌شود که تراکنش داخل اینباکس تاخیری با سازماندهی مجدد (تغییر حالت) زنجیره L1 از بین نمی‌رود. با این حال، اگر یک تراکنش در اینباکس تاخیری برای حداقل ۲۴ ساعت باقی بماند، هر نودی می‌تواند این تراکنش را مجبور کند که در اینباکس بعدی زنجیره نیترو قرار بگیرد؛ این موضوع، انجام شدن تراکنش را تضمین می‌کند. 

اجرای قطعی 

پس از آن که تراکنش‌ها مرتب می‌شوند، در زنجیره Nitro از طریق STF (مخفف State Transition Function یا تابع انتقال حالت) پردازش می‌شوند. STF یک حالت و تراکنش را به‌عنوان یک ورودی دریافت می‌کند. خروجی این تابع، حالت آپدیت شده و یک هدر بلاک سازگار با اتریوم است که به زنجیره نیترو ضمیمه شده است.

STF کاملا قطعی است؛ بنابراین نتیجه خروجی آن تنها به دیتاهای تراکنش و حالت قبل از اجرای تراکنش بستگی دارد. به عبارتی دیگر، می‌توان گفت که خروجی تراکنش (T) تنها به حالت اولیه زنجیره نیترو، ترتیب‌بندی تراکنش‌های قبل از T و خودِ T بستگی دارد. 

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

ساختار نرم‌افزار: Geth اتریوم در مرکزیت

دومین ایده کلیدی طراحی نیترو، استفاده از Geth در مرکزیت شبکه است. Geth مخفف Go Ethereum و رایج‌ترین نرم‌افزار نود برای شبکه اتریوم است. این نرم‌افزار و نیترو، با زبان Go نوشته شده‌اند. این نرم‌افزار که نودهای Nitro از آن استفاده می‌کنند، سه لایه اصلی دارد که در تصویر زیر می‌بینیم:

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

• لایه پایینی، هسته Geth است؛ بخش‌هایی از Geth که از اجرای کانترکت‌های EVM تقلید می‌کنند و ساختار داده‌ها را حفظ می‌کنند تا حالت اتریوم را تشکیل دهند. نیترو در این کد و تنها با تعدادی اصلاح به‌عنوان یک کتابخانه کامپایل می‌شود تا بتواند به لایه میانی یعنی ArbOS متصل شود.
• لایه میانی ArbOS نام دارد، که یک نرم‌افزار شخصی‌سازی شده است و توابع اضافی مرتبط با عملکرد لایه ۲ را ارائه می‌دهد؛ مانند ناهمفشرده کردن (دیتاهای فشرده‌سازی شده را از حالت فشرده خارج می‌کند)، تجزیه دسته‌های دیتاهای سیکوئنسر (برای محاسبه هزینه گس لایه ۱ و جمع‌آوری کارمزدها) و پشتیبانی از عملکردهای بریج کراس چین، از جمله واریز اتر و توکن‌ها از لایه ۱ و همچنین برداشت آنها روی لایه ۱ (تبدیل توکن‌ها به شبکه‌های مختلف).
• لایه بالایی در تصویر، شامل نرم‌افزار نود است که بیشتر آن با Geth نوشته شده است. این بخش به کانکشن‌ها و درخواست‌های RPC کلاینت‌ها رسیدگی می‌کند. 

به این دلیل که لایه‌های بالایی و پایینی، به شدت وابسته به کدهای Geth هستند، این ساختار با نام Geth Sandwich شناخته می‌شود.

تابع انتقال حالت شامل لایه بالایی Geth و مقداری از لایه میانی ArbOS می‌شود. در اصل، STF تابعی طراحی شده در سورس کدهاست و به‌طور ضمنی شامل تمام کدهایی است که توسط این تابع صدا زده می‌شوند. تابع انتقال حالت، بایت‌های تراکنش دریافت شده در اینباکس را به عنوان ورودی می‌گیرد و به یک کپی قابل تغییر از درخت حالت اتریوم (Ethereum State Tree) دسترسی دارد. در نهایت، هدر بلاک جدید (با فرمت هدر بلاک اتریوم) را منتشر می‌کند، که این هدر بلاک به زنجیره نیترو ضمیمه می‌شود. درخت حالت اتریوم اغلب با نام «ماشین حالت جهانی» شناخته می‌شود و از ذخایر دیتاهای اصلی برای ثبت حالت‌ها (حساب‌ها) و تراکنش‌ها استفاده می‌کند. 

لایه ArbOS چیست؟

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

این اسلات‌های ویژه برای این اهداف انتخاب شده‌اند: 

• کل حالت ArbOS را در یک اکانت اتریوم ذخیره کنند. 
• به اجزای فرعی ArbOS، اجازه مدیریت حالت خود را به‌صورت جداگانه و بدون برخورد با یکدیگر می‌دهند. 
• حفظ محل معقول در داخل همان جزء فرعی و اجتناب از محدود کردن اضافات آینده به حالت.

تعاملات بین زنجیره‌ای (Cross-Chain)

یکی از نقش‌های ArbOS پشتیبانی از درخواست‌های کراس‌چین (هم از نیترو به لایه ۱ اتریوم و هم برعکس) به‌صورت امن است. یک حساب که روی یکی از این زنجیره‌ها قرار دارد، می‌تواند تراکنش را به زنجیره دیگر ارسال کند و تراکنش به‌صورت ناهمزمان اجرا خواهد شد (در ادامه توضیح می‌دهیم). در این بخش به توضیح Outbox (که درخواست‌ها از زنجیره نیترو به اتریوم ارسال می‌شوند) و دو مکانیزم Inbox‌ و Retryable Tickets (که درخواست‌ها از زنجیره اتریوم به نیترو ارسال می‌شوند) می‌پردازیم. قبل از توضیح Outbox، به نحوه تعامل آدرس‌ها در این دو زنجیره می‌پردازیم.

تعامل با آدرس

زمانی که از شبکه اتریوم یک تراکنش به شبکه نیترو ارسال می‌شود، قاعدتا باید آدرس کانترکت لایه ۱ اتریوم به‌عنوان فرستنده پیوست شود؛‌ اما ممکن است یک کانترکت در همان آدرس زنجیره نیترو نیز وجود داشته باشد و اگر اینطور باشد، این دو کانترکت برای گیرنده در نیترو غیرقابل تشخیص خواهند بود. هر یک از آنها این امکان را دارد که در زنجیره نیترو جعل هویت دیگری باشد و این موضوع خطرناک است. برای جلوگیری از این اتفاق، آدرس فرستنده در لایه ۱ با این فرمول شناسایی می‌شود: f (A) = (A + C) mod ۲_۱۶۰ 

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

Outbox چیست؟

سیستم Outbox‌ نیترو اجازه می‌دهد که درخواست‌های کانترکت‌های L1 و L2 و پیام‌هایی (تراکنش‌ها) که روی لایه ۲ ایجاد شده‌اند و می‌خواهند در لایه ۱ اجرا شوند، انجام شوند. با وجود امنیت ذاتی رولاپ‌های آپتیمیستیک، اجرای پیام‌های خروجی لایه ۱، تنها پس از مقداری اختلاف زمانی (مدت‌زمانی که بلاک رول‌آپ تایید می‌شود) اجرا می‌شوند. 

از نظر منطقی، یک پیغام لایه ۲ به لایه ۱، یک «تیکت» است که روی L2 ایجاد شده و بعدا می‌تواند به لایه ۱ «بازخرید» شود تا در نهایت یک تراکنش لایه یک اجرا شود. گیرنده تراکنش می‌تواند تایید کند که این پیام از L2 به L1 معتبر است؛ گیرنده حتی می‌تواند فرستنده و دیتاهای تراکنش را نیز تایید کند. این عملکرد باعث امنیت ارسال‌های اتر، توکن‌ها یا دیگر انواع دارایی‌ها از لایه ۲ به لایه ۱ می‌شود. 

پیام‌های لایه دو به لایه یک، توسط یک مولفه از پیش کامپایل شده به نام Arbsys که بخشی از ArbOS است، ایجاد می‌شوند. سپس ArbOS آدرس لایه ۲ فرستنده، مقدار اتر ارسالی، آدرس لایه ۱ گیرنده و Calldata را مرتب می‌کند و در نهایت، یک پیام لایه ۲ به لایه ۱ تولید می‌کند. در واقع Outbox‌ مرحله نهایی است که تراکنش‌ها از لایه ۲ به لایه ۱ انتقال می‌یابند.

ما در اینجا، سیستم Outbox‌ را توضیح دادیم که برای ارسال اتر و دیگر رمزارزها از لایه ۲ به لایه ۱ به‌کار می‌رود. اما ارسال از لایه اتریوم به لایه نیترو چگونه انجام می‌شود؟‌ دو مولفه به نام‌‌های Inbox و Retryable Tickets وجود دارند که این کار را انجام می‌دهند.

Inbox چیست؟ 

اینباکس که توسط مجموعه‌ای از کانترکت‌های اتریوم (لایه ۱) مدیریت می‌شود، مسئول ثبت تراکنش‌های ارسالی به زنجیره نیترو است. اینباکس دو بخش دارد؛ Delayed Inbox یا اینباکس تاخیری، پیام‌هایی را دریافت می‌کند که روی لایه ۱ ثبت شده‌اند و Main Inbox یا اینباکس اصلی، پیام‌های ارسالی از سیکوئنسر را دریافت می‌کند و البته پیام‌های اینباکس تاخیری را با یکدیگر ادغام می‌کند. قبلا با این مولفه‌ها آشنا شدیم، اما یک مرور اجمالی از آنها ارائه می‌دهیم تا درک این بخش برای شما راحت‌تر باشد. مراحل درخواست تراکنش‌های لایه ۱ (اتریوم) به لایه ۲ (نیترو) به ترتیب به شرح زیر هستند:

• تراکنش لایه ۱ به لایه ۲ توسط فرستنده ثبت می‌شود.
• این تراکنش پس از صدا کردن مولفه اینباکس، در اینباکس تاخیری قرار می‌گیرد.
• سپس تمام این تراکنش‌های لایه ۱ به لایه ۲ به سیکوئنسر ارسال می‌شوند و مرتب‌سازی می‌شوند.  
• پس از مرتب شدن، در اینباکس اصلی (پس از حدود ۱۰ دقیقه تاخیر برای اطمینان از این که با تغییر حالت شبکه اتریوم، این تراکنش تغییر نمی‌کند) قرار می‌گیرند.
• تراکنش‌های ترتیب‌بندی شده، توسط تابع انتقال حالت یک‌به‌یک اجرا می‌شوند.

به ادامه مبحث بپردازیم: 

اینباکس تاخیری مجموعه‌ای از اسمارت کانترکت‌های اتریوم است که پیام‌هایی را که قرار است به نیترو ارسال شوند، دریافت می‌کند. این اینباکس تنها راهی برای کانترکت‌های لایه ۱ است، تا پیام‌ها را ثبت کنند؛ زیرا این قراردادها نمی‌توانند تراکنش‌ها را امضا کنند یا آنها را در سیکوئنسر قرار دهند. همچنین اینباکس تاخیری راهی برای کاربران است تا تراکنش‌ها را بدون اتکا به Sequencer (در صورتی که سیکوئنسر بدکار باشد یا در دسترس نباشد) ثبت کنند.

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

Retryable Tickets یا تیکت‌های قابل امتحان مجدد

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

برای جلوگیری از این اتفاقات، نیترو یک سیستم تیکت قابل امتحان مجدد ایجاد کرده است که اجازه می‌دهد تراکنش‌ها به صورت قابل تست مجدد، در لایه ۱ ثبت شوند. اگر یک تراکنش ناموفق باشد، ArbOS یک تیکت Retryable‌ برای آن تراکنش ایجاد می‌کند. اگر این تراکنش دارای Callvalue اتر باشد، ArbOS‌ آن را به این تیکت می‌سپارد. تراکنش بعدی که وارد می‌شود، می‌تواند با پرداخت گس این تراکنش، آن را بازخرید کند؛ سپس سیستم Retry این تراکنش را با فرستنده اصلی، CallValue و دیتاها اجرا می‌کند. یعنی به‌طور خلاصه اگر تراکنشی گس کافی نداشته باشد، یک تیکت Retry برای آن ایجاد می‌شود، تراکنش بعدی می‌تواند گس آن را بپردازد و در نهایت این تراکنش تایید شود.

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

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

جداسازی اجرا از اثبات

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

در زمان کامپایل کردن نرم افزار نود Nitro برای اجرا شدن، از کامپایلر معمولی Go استفاده می‌شود که کدهای بومی را برای معماری تارگت تولید می‌کند. نرم‌افزار نود در فرم‌های سورس کد و همچنین به‌عنوان ایمیج داکری که شامل یک کد باینری کامپایل شده است، توزیع می‌شوند.  

به‌طور مجزا، بخشی از کد که همان تابع انتقال حالت است، توسط کامپایلر Go به اسمبلی وب (WASM) کامپایل می‌شود (Wasm یک قالب کد ماشینی و قابل حمل است) و سپس کدهای وسم به فرمتی که با نام WAVM شناخته می‌شود، تبدیل می‌شود. اگر در مورد نتیجه صحیح محاسبه STF (تابع انتقال حالت) اختلاف وجود داشته باشد، با یک پروتکل اثبات تقلب تعاملی و با ارجاع به کد WAVM حل می‌شود. به توضیح WAVM نمی‌پردازیم؛ زیرا مبحث کاملا جدایی است. در این حد که بدانید این قالب کدها برای اثبات‌ها استفاده می‌شوند، کفایت می‌کند. 

پروتکل رولاپ آپتیمیستیک و RBlockها

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

این پروتکل رولاپ، زنجیره‌ای از بلاک‌های رول‌آپ (با نام RBlocks) تولید می‌کند، که با بلاک‌های لایه ۲ متفاوت هستند. به طور خلاصه، یک RBlock معمولا یک ترتیب از بلوک‌های L2 را در بر می‌گیرد؛ بنابراین تعداد RBlockها بسیار کمتر از بلاک‌های لایه ۲ است.

یک RBlock شامل این موارد است: 

• شماره بلاک لایه ۲
• هش هدر بلاک لایه ۲ با همان شماره
• تعداد پیام‌های دریافتی مصرف شده توسط زنجیره تا آن بلوک
• خلاصه‌ای از پیام‌های خروجی زنجیره در آن بلوک و قبل از آن
• یک اشاره‌گر (Pointer) به RBlock قبلی
• اطلاعات حسابداری اضافی در صورت نیاز، برای ردیابی وضعیت RBlock در پروتکل

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

مجموعه RBlockهای تایید شده، به‌صورت یک زنجیره تکی در می‌آیند که درست مانند بلاکچین، یک بلوک جنسیس دارند و در طول زمان گسترش می‌یابند. در واقع نام آن RBlockchain است. هر RBlock در صورتی معتبر است که یا RBlock تایید شده باشد یا همه موارد زیر درست باشند: 

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

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

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

می‌توان از هزینه‌های ارسال پیام‌های بین زنجیره‌ای نیترو، برای ایجاد پل توکن‌ها استفاده کرد؛ یعنی توکن‌ها را بین زنجیره‌های اتریوم و Nitro جابجا کرد. تیم Offchain Labs بریجی با کارکرد Canonical معرفی کرده است (درست مثل اکثر بریج‌ها). توجه داشته باشید که به طور مشابه، Nitro هیچ مفهوم بومی شناخته شده‌ای از توکن‌ها و هیچ استاندارد توکن خاصی ندارد (دقیقا مانند اتریوم). 

در این بریج، شما توکن‌های خود را واریز می‌کنید (چه در نیترو چه در اتریوم) و در زنجیره دیگر، توکن خود را برداشت می‌کنید. برای واریز توکن‌ها از اتریوم، یک تراکنش به شبکه اتریوم ارسال می‌شود که دو عملیات را انجام می‌دهد؛ یکی این که توکن را به کانترکت لایه ۱ ارسال می‌کند (با نام درگاه توکن (Token Gateway) و با علامت n شناخته می‌شود) و یک تراکنش Retryable ایجاد می‌کند که توکن‌های کانترکت همتا را در شبکه لایه ۲ مینت می‌کند (توکن m). این دو کانترکت با یکدیگر همتا هستند، تا تضمین کنند که گیرنده، توکن مشابه را دریافت می‌کند. توکن دریافتی (m) در زنجیره مقابل، از طریق یک تراکنش لایه ۲ (که توکن‌های m را در لایه ۲ می‌سوزاند)، یک پیام L2 به L1 ایجاد می‌کند و به آن می‌گوید که درگاه توکن لایه ۱، توکن m را در همین لایه آزاد کند. پس از تایید تراکنش، پیام در Outbox اجرا می‌شود و توکن m را در لایه ۲ آزاد می‌کند. 

گس و کارمزدها

درست مثل بسیاری از بلاکچین‌ها، آربیتروم فی را از هر تراکنش دریافت می‌کند تا هزینه‌های عملیات زنجیره را پوشش دهد. نیترو از علامت NitroGas برای فی شبکه خود و از L1Gas برای فی شبکه اتریوم استفاده می‌کند. هر کدام از هزینه‌های دستورالعمل‌های ماشین مجازی اتریوم (EVM) همان مقدار گس را در هر دو زنجیره را می‌طلبد؛ برای مثال، دستورالعمل MULMOD به مقدار ۸ نیتروگس و ۸ L1Gas هزینه دارد. 

هر تراکنش نیازمند مقداری نیتروگس (بسته به منابعی که برای تراکنش استفاده می‌شود) دارد. قیمت NitroGas با بیس‌فی (که به‌صورت الگوریتمی تغییر می‌کند) یکسان است. همچنین این گس‌ها به‌صورت اتر پرداخت می‌شوند. در واقع این المان‌های کارمزدهای نیترو، درست مانند اتریوم است؛ اگر گس لیمیت کمتر از حد مورد نیاز باشد، تراکنش Fail می‌شود و اگر بیشتر باشد، مابقی آن به حساب کاربر بازگردانده می‌شود. یک پارامتر دیگر در نیترو اضافه شده که نام آن Speed Limit است. اسپیدلیمیت نشان‌دهنده حداکثر توان عملیاتی پایدار زنجیره است. نیتروگس می‌تواند در کوتاه‌مدت از اسپیدلیمیت پا را فراتر بگذارد، اما الگوریتم قیمت‌گذاری گس اجازه نمی‌دهد که این زمان طولانی شود. 

برخلاف اتریوم، زمان بلاک‌های نیترو متغیر است؛ بنابراین الگوریتم تنظیم‌کننده BaseFee اختلاف یک ثانیه‌ای با بلاک قبلی دارد (در اتریوم، بیس‌فی پس از یک بلاک تنظیم می‌شود). به علاوه، در نیترو، سیکوئنسر تایم استمپ را ضمیمه تراکنش‌ها می‌کند؛ بنابراین ArbOS باید آماده رسیدگی به تعداد زیادی از تراکنش‌ها با تایم استمپ یکسان، یا مقدار زیادی نیتروگس با همان تایم استمپ باشد؛ بنابراین برای جلوگیری از عبور از حد مجاز Speed Limit، اتریوم مصرف L1Gas در یک بلاک را محدود می‌کند تا اسپیدلیمیت آن را دو برابر کند. بنابراین می‌توان گفت که نیترو با اضافه کردن المان اسپیدلیمیت، گس تراکنش‌ها را در زمان‌های شلوغی شبکه، ثابت نگه می‌دارد. 

تاریخچه آپدیت نیترو

همانطور که در ابتدای مقاله اشاره کردیم، پس از آن که شبکه آربیتروم با مشکلات مقیاس پذیری مواجه شد (در هفته دوم اودیسه یعنی ۱ تا ۷ تیر ۱۴۰۱ و پس از شلوغی شبکه)، تیم آربیتروم (آفچین لبز) به فکر ایجاد این ارتقا افتادند، تا بتوانند سرعت انجام تراکنش‌ها را افزایش دهند و کارمزدها را نیز کاهش دهند. 

نحوه استفاده از نیتروی آربیتروم چگونه است؟ 

برای استفاده از Nitro، نیازی نیست که کاری انجام دهیم؛ این آپدیت روی شبکه لایه ۲ آربیتروم انجام شده و همه تراکنش‌ها توسط همین آپدیت پردازش و تایید می‌شوند. 

مزایا و معایب Nitro

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

وضعیت فعلی نیترو

از زمان راه‌اندازی این آپدیت (۹ شهریور ۱۴۰۱)، تعداد تراکنش‌های آربیتروم به‌شدت افزایش یافته است؛ به نقل از وبسایت TheDefiant در تاریخ ۱۷ شهریور، تعداد تراکنش‌های آربیتروم تنها یک روز پس از اجرای موفقیت‌آمیز نیترو (۱ سپتامبر یا ۱۰ شهریور)، به ۳۱۹ هزار رسیده بود. در حال حاضر به‌نظر می‌رسد که نیترو عملکرد خوبی دارد و باید ببینیم که در آینده چگونه خواهد بود. 

پرسش و پاسخ (FAQ)

• ارتقای Arbitrum Nitro چیست؟ 

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

• آپدیت Nitro در آربیتروم چگونه کار می‌کند؟

طراحی نیترو ۴ ویژگی اصلی دارد: ترتیب‌گذاری و سپس اجرای قطعی، استفاده از کدهای Geth اتریوم، جداسازی اجرا از اثبات و رولاپ آپتیمیستیک دومرحله‌ای با اثبات‌های تقلب. در این مقاله این مفاهیم پیچیده را توضیح داده‌ایم. 

جمع‌بندی

آپدیت نیترو آربیتروم برای افزایش سرعت پردازش تراکنش‌ها و کاهش کارمزدهای شبکه لایه ۲ محبوب آربیتروم طراحی شده است. این ارتقا ویژگی‌های جالب و حتی جدیدی دارد که البته درک آنها را مقداری دشوار می‌سازد. در این مقاله سعی کردیم به زبان ساده به پاسخ این سوال بپردازیم که به‌روزرسانی Nitro در آربیتروم چیست و چگونه کار می‌کند. نظر شما درباره آپدیت نیترو چیست؟ آیا می‌تواند در بلندمدت عملکرد خوبی برای آربیتروم داشته باشد؟