بلاکچین‌های ماژولار: رویای لگو یا کابوس یکپارچه‌سازی؟

ماژولار واژه‌ای به‌طور مشکوکی دلنشین است. تصاویری از قطعات لگو، کتابخانه‌های نرم‌افزاری منظم و مبلمانی که درون جعبه‌ها به همراه یک کیسه پیچ در کنار آن تحویل داده می‌شود را تداعی می‌کند. ماژولار بودن بر انعطاف‌پذیری، مدرنیته و درجه خاصی از ظرافت دلالت دارد؛ درست در نقطه مقابل مکانیزم‌های غول‌پیکر و تخریب‌ناپذیری که در آن‌ها هر چرخ‌دنده به دیگری جوش داده شده است. به همین دلیل است که این کلمه زیستگاه طبیعی خود را در مارکتینگ کریپتو پیدا می‌کند. بلاکچین ماژولار چیزی است که در ذهن فرد باید به‌سادگی سر جای خود جفت‌وجور شود: اجرا اینجا، تسویه آنجا، دسترس‌پذیری داده در پایین، یک بریج، مقداری رمزنگاری دانش صفر (zero-knowledge) و ناگهان کل سیستم از جایگزین یکپارچه (monolithic) خود کارآمدتر می‌شود.

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

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

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

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

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

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

پلتفرم EigenDA یک لایه دسترس‌پذیری داده است که بر روی EigenLayer ساخته شده و به رول‌آپ‌های مبتنی بر اتریوم اجازه می‌دهد تا از امنیت ری‌استیک‌شده اتر در EigenDA استفاده کنند، به جای آنکه زنجیره‌های دسترس‌پذیری داده مستقل خود را امن سازند. پروژه Avail، که پیش‌تر بخشی از پالیگان بود و اکنون به یک لایه دسترس‌پذیری داده مستقل تبدیل شده، رقیب دیگری است که وعده دسترس‌پذیری داده فارغ از زنجیره (chain-agnostic) را همراه با تأیید اعتبار کلاینت‌های سبک و قابلیت همکاری متقابل ارائه می‌دهد. این‌ها همگی ایده‌های جالبی هستند که هدفشان جداسازی دسترس‌پذیری داده از تسویه و اجراست تا به رول‌آپ‌ها امکان دهند سبک‌تر و تخصصی‌تر باشند.

برای توسعه‌دهندگان، جذابیت بلاکچین‌های ماژولار کاملاً آشکار است. آنها به جای ساخت همه‌چیز از صفر، می‌توانند از یک فریم‌ورک مشخص یا مجموعه‌ای از مؤلفه‌های ماژولار نام‌آشنا برای ساخت زنجیره خود بهره ببرند. فریم‌ورک‌های OP Stack، Arbitrum Orbit، ZK Stack، Polygon CDK، Agglayer CDK، Rollkit و سرویس‌های مختلف rollup-as-a-service همگی به توسعه‌دهندگان امکان می‌دهند محیط اجرایی مورد نظر خود را ضمن تکیه بر فرضیات امنیتیِ اثبات‌شده بنا نهند. به جای راه‌اندازی یک لایه تسویه کامل با اعتبارسنج‌ها، یک بریج، یک مکانیزم اجماع و مجموعه‌ای از قراردادهای هوشمند، یک تیم می‌تواند یک آپتیمیستیک رول‌آپ یا zk-rollup را با یک چیدمان اولیه مطمئن راه‌اندازی کند و کار را ظرف چند هفته تحویل دهد. یک رول‌آپ به جای ساخت یک لایه دسترس‌پذیری داده، می‌تواند فضایی را روی اتریوم یا زنجیره‌ای دیگر از طریق EigenDA یا Celestia اجاره کند.

برای کاربران، این مزایا کمتر ملموس است. یک برنامه ارزان‌تر مبتنی بر رول‌آپ بهتر از هیچ است، اما وعده واقعی بلاکچین‌های ماژولار در «تخصصی شدن» نهفته است. لایه‌های تسویه و دسترس‌پذیری داده را می‌توان برای دستیابی به سادگی و امنیت بهینه‌سازی کرد، رول‌آپ‌های اجرایی می‌توانند از ابزارهای ارائه‌شده توسط فریم‌ورک انتخابی خود استفاده کنند و بلاکچین‌های ویژه-برنامه (application-specific) می‌توانند تراکنش‌های ارزان‌تر و تجربه کاربری بهتری را نسبت به زنجیره‌های عمومی ارائه دهند. همه این‌ها بسیار تئوریک است، اما گزاره جذاب‌تری که برای توسعه‌دهندگان و کاربران فراهم می‌کند در عین حال یک تهدید نیز به شمار می‌رود؛ تهدیدی برای تسلط بلاکچین‌های یکپارچه.

مسئله زره جنگی

مشکل از زمانی آغاز می‌شود که ماژولار بودن، از یک ساختار مهندسی به یک مُد گذرا تبدیل شود. هیچ‌کس تنها به این دلیل که نمودارهایش کادرهای بیشتری دارد، امن‌تر نیست. در اطراف هر مرز میان این کادرها باید فرضیاتی در نظر گرفته شود، هر پیامِ رد و بدل شده میان لایه‌ها باید بررسی گردد، هر بریج بر مبنای یک مدل اعتمادی طراحی شود، پایداری و زنده‌بودن (liveness) هر ترتیب‌دهنده (sequencer) کنترل شود، هر لایه دسترس‌پذیری داده از نظر نمونه‌برداری صادقانه یا اپراتورها پایش گردد، هر مسیر ارتقا به فرآیند حاکمیت سپرده شود و هر وابستگی خارجی پتانسیل این را دارد که عملکرد نادرستی داشته باشد، در حالی که برنامه ادعای امن بودن می‌کند.

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

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

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

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

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

مشکل تجربه کاربری

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

قطعی‌های رول‌آپ‌ها بارزترین نمونه از این مشکل هستند. شبکه Base، یکی از محبوب‌ترین لایه‌های ۲ اتریوم، زنجیره خود را به مدت ۳۳ دقیقه به دلیل بروز مشکلی در تغییر خودکار ترتیب‌دهنده (sequencer failover) متوقف کرد. خوشبختانه برای کاربرانش، دارایی‌های آن‌ها در هیچ لحظه‌ای از این حادثه از دسترس خارج نشد، اما این اتفاق درسی هشداردهنده باقی می‌ماند. کل اکوسیستم اتریوم بر پایه امنیت تسویه در لایه اصلی اتریوم ساخته شده است، اما این بدان معنا نیست که قطعی‌های اختصاصی رول‌آپ‌ها هرگز رخ نخواهند داد.

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

در حال حاضر، فضای رول‌آپ‌ها با انفجاری از گزینه‌های متنوع در دسترس‌پذیری داده روبه‌روست. بلاکچین‌های ماژولار مختلف به کاربران خود حق انتخاب میان ارائه‌دهندگان rollup-as-a-service، لایه داده Celestia DA، پلتفرم‌های EigenDA، Avail، فضای blobspace اتریوم و سایر گزینه‌ها را می‌دهند. برخی از زنجیره‌ها، از جمله Base، Arbitrum Nova، Linea، Scroll و غیره، روی زنجیره‌های تسویه فعلی اتریوم ساخته شده‌اند و از راهکارهای دسترس‌پذیری داده آن‌ها استفاده می‌کنند. در همین حال، Optimism در حال آماده‌سازی برای راه‌اندازی Superchain خود است که چندین زنجیره OP را در یک لایه تسویه مشترک گردهم خواهد آورد.

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

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

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

پاسخ این صنعت به این چالش کاملاً روشن است: سخت‌گیری بیشتر، ابزارهای بهتر، طراحی ارتقایافته. بریج‌های بهتر با تأیید اعتبار کلاینت سبک. اثبات‌های دانش صفر و امضاهای آستانه‌ای. سیستم‌های محدودکننده نرخ تراکنش (Rate limiting) و مدارشکن‌ها (Circuit breakers). ترتیب‌دهنده‌ها و زنجیره‌های تسویه غیرمتمرکز. اعتبارسنجی رسمی (Formal verification)، مانیتورینگ دقیق و توسعه تجربه کاربری برای توضیح دادن همه‌چیز به کاربران نهاییِ سردرگم. این تنش بنیادی در قلب دنیای ماژولار، نوآوری را در تمامی سطوح، از پایین‌ترین لایه‌های فنی تا بالاترین لایه‌ها، به پیش می‌راند.

بده‌بستان، نه معجزه نجات‌بخش

نرم‌افزار همواره بر پایه بده‌بستان‌ها (Tradeoffs) شکل می‌گیرد. برخی از آن‌ها آشکارند و برخی زیر اسناد و اصطلاحات حقوقی مدفون شده‌اند. برخی از آن‌ها با هر نوآوری بزرگ در این فضا همراه هستند؛ مانند سازش‌هایی که EVM اتریوم را شکل داده‌اند. بلاکچین‌های ماژولار تفاوتی در این زمینه ندارند و انعطاف‌پذیری و امکان آزمون‌وخطا را بدون حذف بارِ ناشی از پیچیدگی مضاعف وعده می‌دهند. زنجیره‌های ماژولار، سادگی فنی نسبیِ یک سیستم تک‌زنجیره‌ای را در ازای دستیابی به فرصت‌هایی برای بهینه‌سازی واگذار می‌کنند. آن‌ها تضمین‌های امنیتیِ ساده را با سطح حمله گسترده‌تر مبادله می‌کنند. آن‌ها شلوغی یک لایه تسویه منفرد را با بار سازمانیِ لایه‌های چندگانه امنیتی معاوضه می‌کنند. آن‌ها آزادی توسعه‌دهنده را با تمرکززدایی، و پتانسیل خام را با افزایش مسئولیت تاخت می‌زنند.

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

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

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

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

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

ارزشش را دارد یا نه؟

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

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

پروژه‌های Celestia و EigenDA، در کنار Avail و blobspace اتریوم، همگی آماده‌اند تا انعطاف‌پذیری بیشتری در زمینه دسترس‌پذیری داده برای زنجیره‌های رول‌آپی که از آن‌ها استفاده می‌کنند، به ارمغان آورند. ابزارهای OP Stack، Arbitrum Orbit، پلتفرم‌های CDK و Agglayer پالیگان، فورک Linea از Optimism و بسیاری دیگر، همگی در جهت کاهش موانع فنی برای توسعه‌دهندگان مستقل و تیم‌ها تلاش می‌کنند و به آن‌ها اجازه می‌دهند زنجیره‌های سازگار با اتریومِ اختصاصی خود را راه‌اندازی کنند. کل این فضا در حال ورود به فاز هیجان‌انگیزی از توسعه است، چراکه عملی بودنِ فنی یک آینده چندزنجیره‌ای به طور فزاینده‌ای آشکار می‌شود.

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

همین اصول در روندهای گسترده‌تر این صنعت نیز صادق است. راهکارهایی که به دنبال خودکارسازی عملیات شبکه TRON برای کسب‌وکارها هستند، با تقاضای فزاینده‌ای از سوی تیم‌هایی روبه‌رو شده‌اند که مایل نیستند مدیریت Energy خود را به صورت دستی سفارشی‌سازی کنند، با حالت‌های Smart Mode و Host Mode کلنجار بروند یا زمان خود را صرف نوشتن اسکریپت و مدیریت API نمایند. پلتفرم Netts Workspace یک رابط بصری و یکپارچه ارائه می‌دهد که اجاره Energy، حالت‌های Smart Mode و Host Mode، تراکنش‌های شبکه TRON و مدیریت Energy، ابزارهای نظارتی، بررسی‌های AML و عملیات مالی را متمرکز می‌سازد؛ و به شرکت‌ها امکان می‌دهد تا ضمن به حداقل رساندن خطرات ناشی از عملیات دستی، هزینه‌های خود را کاهش دهند.