متوسط مقالات عمومی

مقیاس پذیری بلاک چین چه موانعی پیش رو دارد؟

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

می‌دانم تعجب می‌کنید اگر بدانید که بعضی بلاک چین‌ها مانند بلاک چین credits ادعا کرده‌اند که بیش از یک میلیون تراکنش را در ثانیه پردازش می‌کنند. با استفاده از روش‌های زیر می‌توان چنین اعداد گیج‌کننده‌ای را تولید کرد.

۱- می‌توانید زنجیره را بر روی کامپیوتر شخصی خود راه‌اندازی کنید. شبیه‌ساز‌های تاخیری و ذخیره‌سازی مداوم را خاموش کنید و داده‌های خود را در سریعترین هش‌مپی (hashmap) که پیدا می‌کنید، ذخیره نمایید. حتی بهتر است که همه این آزمایش‌ها را در حافظه انجام دهید و LevelDB را کنار بگذارید.

۲- می‌توانید تراکنش‌ها را با همدیگر جمع کرده و به صورت دسته‌های بزرگ درآورید و سپس تنها در بلاک (block) ترابایت (terabyte) تصمیم‌گیری تصمیم‌گیری کنید. در نهایت، تعداد تراکنش‌ها در آن بلاک را می‌شمارید و عدد بزرگی به دست خواهد آمد.

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

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

۵- تایید امضا و غیره در میان نباشد.

موانع اصلی در برابر مقیاس‌پذیری بلاک چین

بلاک چین

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

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

می‌توان ادعا کرد که یکی از دلایل کندی بیت کوین اجماع ناکاموتو (Nakamoto) است. پروتکل‌های همزمان مانع سختی در برابر پردازش داده در واحد زمان هستند. این در حالی است که در یک شبکه غیر همزمان می‌توان داده‌ها را خیلی سریع‌تر انتشار داد.

در سیستم شاردینگ (sharding) طراحی شده باید موارد زیر را در نظر داشته باشیم:

  • باید Fisherman موجود باشد تا مشکل موجود بودن داده حل شود. Polkadot چنین کاری می‌کند و این در عوض می‌تواند بلاک چین را کند کند.
  • باید چیزی موجود باشد که اعتبارسنج‌ها را منحرف نکند و مانند Cosmos به اعتبارسنج‌ها اعتماد شود.
  • زیلیکا (Zilliqa) اعتبارسنجی را تقسیم کرده اما داده‌ها را تقسیم نکرده است. این باعث می‌شود که هر نود مجبور باشد تمام وضعیت بلاک چین را ذخیره کند که این مانع بزرگی است.
  • طراحی معیوب تعادل بار بین شارد‌ها (shard) مانند اتریوم نسل دوم
  • روش اجماع بین شارد گاهی زمان تایید تراکنش‌ها را بالا می‌برد و این فرآیند را کند می‌کند.

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

چه می‌شود اگر به جای یک دفتر کل دو دفتر کل داشته باشیم؟

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

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

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

حال چه می‌شود اگر ما یک دفتر کل جداگانه برای اجماع داشته باشیم؟ فرض کنید این دفتر کل یک Meta-DAG باشد. یکی از مشکلات DAG سختی محاسبه است. اما می‌توان یک تنوع جدید را در استفاده از DAG طراحی کرد که این مشکلات را کم کند.

معمولا در سیستم‌ها تمایز برجسته‌ای بین اجماع و وضعیت ماشین مبنا موجود است. چیزی که در اکثر سیستم‌ها اتفاق می‌افتد این است که هر یک از نود‌ها مجبور است منتظر شود تا نود‌های دیگر وضعیت خود را به روز کنند و بعد از آن است که این نود در اجماع شرکت می‌کند. اما چه می‌شود اگر یک الگوریتم اجماع BFT داشته باشیم که فاقد رهبری باشد؟

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

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

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

کدام اجماع BFT را به کار ببریم و چگونه؟

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

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

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

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

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

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

تاثیر ادغام گواه اثبات کار و گواه اثبات سهام در شبکه چیست؟

گواه اثبات کار و سهام

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

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

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

این سیستم طراحی مرکب دارای مزایای زیادی است که به برخی از آنها اشاره می‌شود:

۱- محافظت بیشتری در برابر حملات اکثریت ایجاد می‌شود.

۲- مکانیسم گواه اثبات سهام در این سیستم مرکب نیازمند یک نرم افزار کیف پول است که به طور مداوم راه‌اندازی شود و شانس افراد ذینفع برای رای‌گیری از دست نرود.

۳- همچنین به دلیل اینکه احتمالا سرمایه کلی در قدرت هش کاهش می‌یابد، مصرف انرژی شبکه ممکن است نسبتا پایین‌تر از گواه اثبات کار خالص باشد.

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

چگونه قرارداد‌های هوشمند را می‌توان در این ساختار ادغام کرد؟

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

این کار چگونه انجام می‌شود؟

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

منظور از zApp چیست؟

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

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

هدف اصلی zApps، ایجاد یک اکوسیستم باز است که هر توسعه‌دهنده بتواند برنامه خود را از ابتدا بسازد و یا برنامه‌های موجود را تغییر دهد.

این قرارداد‌های هوشمند چکار می‌کنند؟

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

تاثیراتی که بر جا گذاشته می‌شود

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

۲- مالکیت زنجیره اکانت: ثبات وضعیت مهم است اما به روز رسانی کند وضعیت منجر به اجازه‌هایی نادرست می‌شود. اما در این ساختار به کلاینت‌های سبک اجازه داده می‌شود که سریعا به اطلاعات به روز دسترسی داشته باشند و بنابراین وضعیت را حفظ کنند.

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

نتیجه‌گیری

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

منبع
hackernoon

نوشته های مشابه

اشتراک
اطلاع از
0 دیدگاه
Inline Feedbacks
View all comments
دکمه بازگشت به بالا