شاردینگ در بلاک چین چیست و چطور مقیاس پذیری اتریوم را افزایش می‌دهد؟ (ریدایرکت شد)

مدت زمان : 40

2 سال قبل

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

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

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

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

شاردینگ در بلاک چین چیست؟

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

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

دفتر کل توزیع شده

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

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

مقیاس پذیری در بلاک چین

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

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

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

سازو کار شاردینگ در بلاک چین

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

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

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

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

پارتیشن بندی افقی مورد استفاده در روش شاردینگ

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

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

به اشتراک گذاری شاردها

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

امنیت در شاردینگ و مقابله اتریوم با تهاجم شاردی

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

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

ذخیره داده‌های عظیم در اتریوم بدون استفاده از شاردینگ

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

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

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

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

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

چرا اتریوم به شاردینگ نیاز دارد؟

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

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

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

شاردینگ از زمان ظهور اتریوم در سال 2013 در حد یک ایده بوده است و هنوز مشخص نیست که‌ آیا واقعا کار خواهد کرد یا خیر. همچنین مشخص نیست این ویژگی چه زمانی به اتریوم اضافه خواهد شد. شاردینگ بخشی برنامه ریزی شده از اتریوم 2 است؛ مجموعه‌ای‌ از پروتکل‌های ارتقاء بلاک چین اتریوم که به طور رسمی‌‌ در 1 دسامبر 2020 (11 آذر 1399) شروع به کار کرد. به دلیل خطرات و پیچیدگی احتمالی، شاردینگ به احتمال زیاد در مراحل بعدی آپدیت در آن گنجانده می‌‌شود و طبق گفته وبسایت این پروژه، قرار است بلاک چین آن به 64 قسمت یا شارد (زنجیره‌های مجزا) تقسیم شود.

سازوکار شاردینگ در اتریوم

قبل از اینکه بخواهیم به نحوه عملکرد بلاک چین شارد شده اتریوم بپردازیم، اجازه دهید چند واژگان مهم در این زمینه را تعریف کنیم:

حالت: حالت، وضعیت یا استیت (State) در اصل کل مجموعه اطلاعاتی که یک سیستم را در هر نقطه از زمان توصیف می‌کند. در اتریوم، این مجموعه اطلاعات به عنوان یک حالت در زمانی خاص شامل موجودی‌ یا بالانس در جریان، کد قرارداد هوشمند و غیره است. هر تراکنش جدید این حالت را به یک حالت کاملاً جدید تغییر می‌دهد.

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

تراکنش: به هر عملیاتی که توسط کاربر صادر می‌شود و حالت یک سیستم را تغییر می‌دهد گفته می‌شود.

درخت مرکل (Merkle Tree): ساختار داده‌ای که می‌تواند حجم زیادی از داده‌ها را از طریق هش‌های رمزنگاری ذخیره کند. درخت مرکل بررسی اینکه آیا یک قطعه داده بخشی از ساختاری بزرگ‌تر است را در مدت زمان بسیار کوتاه و با فرآیند محاسباتی آسان‌تر ممکن می‌کند.

رسید: اثر جانبی یک تراکنش است که در حالت سیستم ذخیره نمی‌شود، اما در درخت مرکل نگهداری می‌شود تا به راحتی در یک نود تأیید شود. به عنوان مثال، گزارش قراردادهای هوشمند در اتریوم به عنوان یک رسید (receipt) در Merkle Trees نگهداری می‌شود.

با دانستن این اصطلاحات، بیایید نگاهی به نحوه عملکرد اتریوم 2.0 و پیاده سازی شاردینگ در آن بیندازیم: ابتدا یک زنجیره جانبی به نام بیکن چین (beacon chain) به طور تصادفی ایجاد می‌شود که هش‌های بلاک‌های زنجیره اصلی را در بلاک‌های خود ذخیره می‌کند. این زنجیره جانبی یک سیستم اثبات سهام کامل است که طبق پروتکل کسپر – Casper the Friendly Finality Gadget (Casper FFG) – کار می‌کند و منبعی برای توزیع تصادفی می‌سازد و در نتیجه اجرای شاردینگ را در سیستم ممکن می‌کند. اتریوم همچنین راه حلی برای اتک شاردی، یا همان مشکل بزرگ حمله یک شارد به شارد دیگر و از دست رفتن اطلاعات ارائه می‌دهد که به طور خلاصه با انتخاب تصادفی اعتبار‌سنج‌ها در هر شارد اتفاق می‌افتد.

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

فرض کنید قراردادی را به نام قرارداد ثبت اعتبار سنج یا ولیدیتور (Validator Registration Contract) در بلاک چین اصلی مستقر کنیم. طبق این قرار داد، افراد باید 32 واحد ارز دیجیتال اتریوم (ETH) را در ازای تبدیل شدن به اعتبارسنج در زنجیره جانبی بسوزانند. زنجیره بیکن به صورت دوره‌ای وضعیت اعتبار سنج‌های ثبت شده را بررسی می‌کند و در نتیجه آن‌هایی که ETH کافی سوزانده‌اند را در صفی برای انتخاب شدن به عنوان ولیدیتور در قرارداد قرار می‌دهد. بیکن چین به عنوان یک دستگاهِ هماهنگی در یک سیستم شاردینگ عمل می‌کند، زیرا امکان انتخاب شبه تصادفی و توزیع شده را فراهم می‌کند که در انتخاب گروه اعتبار سنج‌ها در شاردها حیاتی است.

در هر شارد، نودهایی به نام پیشنهادگر (proposers) یا نود رابط (Collators) خواهیم داشت که وظیفه ایجاد یک کراس لینک یا لینک میانه در زنجیره بیکن را بر عهده دارند. لینک میانه ساختار خاصی است که اطلاعات مهمی‌ را در مورد شاردی خاص در بر می‌گیرد و شامل توضیحات مختصری از وضعیت و تراکنش‌های یک شارد خاص هستند. یک کراس لینک معمولا اطلاعات زیر را در بر دارد:

اطلاعاتی در مورد این که نود رابط (کلاتور) با چه شاردی مطابقت دارد؛
اطلاعات مربوط به حالت یا استیت فعلی شارد قبل از اعمال همه تراکنش‌ها؛
اطلاعاتی در مورد حالت شارد پس از اعمال تمام تراکنش‌ها؛
و امضا حداقل دو سوم کل کلاتورها که بلاک‌های تولید شده توسط شارد را تایید می‌کنند.

حال اگر تراکنشی بین شاردها اتفاق بیفتد چطور؟ به عنوان مثال، اگر من از آدرسی که در شارد 1 است به آدرسی در شارد 10 پول ارسال کنم، چطور؟ یکی از مهم‌ترین بخش‌های این سیستم، توانایی برقراری ارتباط بین شاردهاست، که اگر اینطور نباشد در واقع کل این اتفاقات بیهوده است. برای این منظور از مفهوم رسید در سیستم کمک می‌گیریم. فرض کنید علی (آدرسی در شارد اول) می‌خواهد 100 واحد اتریوم به مجتبی (آدرسی در شارد دهم) بفرستد، مطابقا اتفاقاتی به ترتیب زیر در سسیتم به جریان می‌افتند:

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

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

شاردینگ در بلاک چین‌های دیگر

بلاک چین زیلیکا (Zilliqa) یکی از معدود مواردی است که به کارگیری شاردینگ را نوید می‌دهد. ویژگی‌های پروتکل Zilliqa را می‌‌توان در چند نکته خلاصه کرد:

تمام تراکنش‌ها در تک شاردها به صورت موازی اجرا می‌شوند.
تراکنش‌هایی که بر یک قرارداد هوشمند تأثیر می‌گذارد به صورت موازی اجرا نمی‌شوند.
هیچ تراکنشی که بر بیش از یک شارد تاثیر می‌گذارد به موازات تراکنش‌ دیگری اجرا نمی‌شوند.

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

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

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

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

جمع بندی

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

اما پس از دانستن منافعی که شاردینگ برای یک بلاک چین به دنبال دارد، این سوال پیش می‌آید که چرا ما شاهد ظهور پروتکل‌های بلاک چین شارد شده‌ای نیستیم که از تکنیک‌های اثبات شده در این روش پشتیبانی کنند؟

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

برچسب ها: