Data Availability در بلاکچین چیست و چرا برای رول آپ ها مهم است؟

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

Data Availability دقیقا چیست؟

Data Availability (دسترسی پذیری داده) ویژگی ای است که تضمین می کند داده های ورودی محاسبات یک بلوک واقعا منتشر شده و هر ناظر مستقلی می تواند آن را دریافت کند. این داده معمولا شامل تراکنش ها، اختلاف های تجمیع شده و هر اطلاعاتی است که برای بازاجرا و راستی آزمایی حالت نهایی لازم است.

تفاوت مهم: اجماع فقط می گوید «این بلوک پذیرفته شد»، اعتبارسنجی می گوید «محاسبات سازگار است»، اما Data Availability می گوید «داده های لازم برای بررسی محاسبات منتشر و قابل دریافت است». اگر داده منتشر نشود، حتی یک سیستم صحیح هم قابل بررسی و بازسازی نیست.

چرا Data Availability برای رول آپ ها حیاتی است؟

پاسخ کوتاه: چون امنیت خروجی رول آپ (پل ها، برداشت ها، اثبات ها) به دسترسی عموم به داده های دسته های L2 وابسته است.

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

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

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

روش های تامین Data Availability

انتشار روی لایه یک (calldata یا معادل آن)

ساده ترین و امن ترین روش، انتشار داده مستقیم روی زنجیره پایه (مثل ثبت به صورت calldata در اتریوم) است. چون داده به اجماع لایه یک متکی است، هر ناظر می تواند آن را از آرشیو گره ها دریافت کند. نقطه ضعف اصلی هزینه نسبتا بالای هر بایت است.

blobs و داده های موقتی در اتریوم (EIP-4844)

در اتریوم مکانیزم blob فضایی اختصاصی و ارزان تر برای داده های موقتی رول آپ ها فراهم می کند. داده ها در بازه زمانی مشخصی نگه داشته می شوند و با تعهدات رمزنگاری (commitments) محافظت می شوند. این روش هزینه DA را به شکل محسوسی کاهش می دهد اما باید در طراحی خروج و دسترس پذیری بلندمدت به «زمان نگهداری محدود» توجه کرد.

زنجیره های تخصصی DA

برخی شبکه ها صرفا برای Data Availability طراحی شده اند و با تکنیک هایی مثل کدگذاری پاک کننده و نمونه برداری در دسترس بودن (DAS) به ناظران سبک اجازه می دهند با احتمال بسیار بالا مطمئن شوند داده واقعا منتشر شده است. هزینه هر بایت معمولا پایین تر و مقیاس پذیری بهتر است، اما مدل اعتماد و پیوند امنیتی با لایه یک انتخاب شده باید شفاف بررسی شود.

کمیته Data Availability (DAC)

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

طرح های ترکیبی

برخی رول آپ ها داده حیاتی را روی لایه یک می گذارند و داده کم اهمیت را روی DA خارجی یا DAC. یا ابتدا روی DA ارزان منتشر می کنند و اگر ظرف زمانی مشخص در دسترس نبود، به حالت اضطراری انتشار روی لایه یک سوییچ می کنند. موفقیت این الگو به طراحی درست «مسیر اضطراری» و نظارت خودکار بستگی دارد.

تکنیک های کلیدی پشت Data Availability

کدگذاری پاک کننده (Erasure Coding)

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

نمونه برداری در دسترس بودن داده (DAS)

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

تعهدات رمزنگاری به داده

تعهدات مانند KZG یا Merkle commitment امکان می دهد یک بلوک به طور فشرده به داده متعهد شود و هرکس بتواند درستی تکه های دریافتی را تایید کند. این تعهدات پایه اثبات های سبک و بازیابی صادقانه داده است.

مثال عملی: اگر داده در دسترس نباشد چه رخ می دهد؟

فرض کنید رول آپ خوشبینانه یک دسته تراکنش را منتشر می کند ولی سکوئنسر داده کامل آن را جایی قرار نمی دهد. وضعیت L2 به نفع مهاجم به روز می شود و پل L1 یک ریشه وضعیت جدید می بیند. کاربری که می خواهد برداشت کند باید در دوره چالش اثبات تقلب ارائه کند، اما چون ورودی ها در دسترس عموم نیست، هیچ کس نمی تواند اجرای اشتباه را بازاجرا کند. نتیجه: دوره چالش می گذرد، برداشت اشتباه نهایی می شود یا دارایی ها برای مدت طولانی قفل می مانند. اگر همان رول آپ داده را حداقل در لایه یک یا لایه DA با DAS منتشر می کرد، هر ناظر می توانست داده را بگیرد و چالش معتبر ارائه دهد.

معیارهای انتخاب لایه Data Availability برای رول آپ

• فرض های امنیتی: به چه کسی اعتماد می کنید؟ لایه یک، اقتصاد یک DA chain، کمیته محدود یا ترکیبی؟
• هزینه هر بایت: بودجه تیم و کاربران با چه هزینه ای سازگار است؟ قیمت پایین تر نباید به بهای افت امنیت حیاتی تمام شود.
• زمان نگهداری داده: داده چقدر روی لایه انتخابی حفظ می شود؟ آیا برای خروج های دیرهنگام یا بازیابی آرشیو برنامه دارید؟
• قطعیت و زنده بودن: انتشار داده چقدر سریع نهایی می شود و چه سطحی از سانسور را می تواند تحمل کند؟
• پشتیبانی از کلاینت سبک و DAS: آیا کاربران عادی می توانند بدون گره کامل صحت در دسترس بودن را بررسی کنند؟
• ادغام با پل و مسیر خروج: اگر DA موقتی یا خارجی است، مسیر خروج مبتنی بر لایه یک چگونه ایمن می ماند؟
• قابلیت نظارت و ابزار: آیا می توانید انتشار ناقص را به سرعت تشخیص دهید و سوییچ اضطراری را فعال کنید؟
• الزامات حقوقی و عملیاتی: در استفاده از DAC خصوصی، مسئولیت ها و ریسک های عملیاتی را شفاف کنید.

چطور مطمئن شویم یک رول آپ DA امنی دارد؟ (برای کاربر و توسعه دهنده)

1. منبع DA را شناسایی کنید: مستندات پروژه باید واضح بگوید داده کجا منتشر می شود (calldata، blob، DA chain یا DAC).
2. قابلیت بازیابی مستقل: بررسی کنید آیا می توان دسته ها را صرفا از لایه یک یا DA عمومی دانلود کرد، بدون نیاز به گره اختصاصی تیم.
3. بازبینی پل و خروج: به دنبال مسیر خروج اجباری باشید که صرفا به داده عمومی متکی باشد. اگر فقط امضای کمیته شرط خروج است، ریسک بالاست.
4. مانیتورینگ: سرویس یا اسکریپتی داشته باشید که تاخیر یا عدم انتشار دسته ها را روی منبع DA رصد کند و آلارم بدهد.
5. پنجره نگهداری: اگر از blobs یا DA موقتی استفاده می شود، مطمئن شوید ابزار آرشیو برای نگهداری بلندمدت داده وجود دارد.
6. کلاینت سبک: وجود یا نقشه راه کلاینت سبک با DAS نشانه بلوغ طراحی DA است.

اشتباهات رایج و سوتفاهم ها

• یکی دانستن اعتبارسنجی با Data Availability: اثبات اعتبار یا اجماع کافی نیست؛ اگر داده منتشر نشود، امنیت عملی از بین می رود.
• اعتماد کامل به DAC خصوصی: حتی با امضای چند موسسه، ریسک تبانی یا خاموشی وجود دارد. برای مبالغ جدی به مسیر خروج مبتنی بر داده عمومی نیاز دارید.
• نادیده گرفتن زمان نگهداری: داده های موقتی بدون آرشیو، بعد از انقضا بازیابی نمی شوند و مسیرهای خروج دیرهنگام می شکنند.
• فرض کفایت درج ریشه وضعیت در L1: ریشه بدون داده ورودی به درد بازاجرا و چالش نمی خورد.

جدول مقایسه کوتاه گزینه های متداول DA

نکات طراحی برای تیم های رول آپ

• سیاست انتشار روشن: چه داده ای، کجا و با چه فرکانسی منتشر می شود. این سیاست را در قراردادهای L1 کدگذاری کنید، نه فقط مستندات.
• حالت اضطراری: اگر منبع DA اولیه از کار افتاد یا تاخیر داشت، سوییچ خودکار به L1 یا منبع ثانویه تعریف کنید.
• بازیابی و خروج: مسیر خروج اجباری با تکیه بر داده عمومی را پیاده سازی و تست کنید. بازه های زمانی را با نگهداری داده هماهنگ کنید.
• نظارت غیرمتمرکز: به جامعه امکان راستی آزمایی بدهید؛ ایندکس های عمومی، ابزار بازیابی دسته ها و کلاینت سبک منتشر کنید.
• ارتقای تدریجی: می توانید از DAC آغاز و به DA عمومی مهاجرت کنید، اما مکانیزم حاکمیتی و طرح مهاجرت را از روز اول مشخص کنید.

گام بعدی چیست؟

اگر در حال ارزیابی یا طراحی رول آپ هستید، ابتدا مدل تهدید خود را بنویسید: چه کسی می تواند داده را پنهان یا سانسور کند و پیامد آن برای خروج و پل چیست. سپس یک منبع DA انتخاب کنید که با این تهدیدها، بودجه و تجربه فنی شما سازگار باشد. در نهایت، با مانیتورینگ انتشار دسته ها و تمرین سوییچ اضطراری، مطمئن شوید وقتی Data Availability حیاتی می شود، فقط به نیت خوب یک سکوئنسر تکیه نکرده اید.