چالش‌‌های اساسی در بلاکچین‌‌های عمومی (بخش دوم)

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

0 92
برای مطالعه بخش قبل اینجا کلیک کنید.

اوراکل‌‌ها (Oracles)

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

محیط‌‌های اجرایی امن

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

محیط‌‌های اجرایی امن

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

3- نبود تایید قرارداد رسمی

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

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

یک مثال درباره زبان ویژه، ایزابل است؛ ایزابل یک همراه اثبات عمومی است که امکان بیان فرمول‌‌های محاسباتی در زبان رسمی را می‌‌دهد و ابزاری برای اثبات منطقی‌‌بودن این فرمول‌‌ها، ارائه می‌‌کند. یک زبان ویژه دیگر، Coq است که زبان رسمی برای نوشتن تعاریف ریاضیاتی، الگوریتم‌‌های قابل اجرا و برهان‌‌ها محسوب می‌‌شود.

حالا چرا تایید رسمی برای برنامه‌‌ها از طریق قراردادهای هوشمند‌‌، مهم است؟

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

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

راه‌‌حل‌‌های تایید رسمی

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

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

تیم‌‌های دیگری مثل تزوس هم هستند که کاملا از سالیدیتی به عنوان زبان و از EVM به عنوان VM استفاده می‌‌کنند و در عوض زبان برنامه‌‌ریزی قرارداد هوشمند خود را می‌‌سازند تا تایید رسمی را تسهیل کند.

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

4- محدودیت‌‌های ذخیره

اغلب نرم‌‌افزارهایی که بر روی بلاکچین عمومی ساخته می‌‌شوند، نیازمند نوعی راه‌‌حل ذخیره‌‌سازی هستند (تعیین هویت کاربری، اطلاعات مالی و غیره).

هرچند ذخیره‌‌سازی اطلاعات در یک دیتابیس عمومی بلاکچین به این معنا است که این اطلاعات:

1- توسط تمامی گره‌‌های شبکه ذخیره می‌‌شوند.

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

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

راه‌‌حل‌‌های ذخیره‌‌سازی

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

  • Swarm: سوارم یک پروتکل اشتراک فایل همتا به همتا برای اتریوم است که به شما امکان ذخیره کد نرم‌‌افزاری و اطلاعات خارج از بلاکچین اصلی را در گره‌‌های Swarm که به بلاکچین اتریوم متصل هستند را می‌‌دهد. بعدا می‌‌توانید این اطلاعات را در بلاکچین مبادله کنید.
  • استورج (Storj): راه‌‌حلی که در آن فایل‌‌ها و اطلاعات ابتدا تقسیم و رمزنگاری می‌‌شوند و سپس در گره‌‌های مختلف توزیع می‌‌یابند تا هر گره فقط بخشی از اطلاعات را در اختیار داشته باشد؛ به این مسئله، ذخیره توزیع‌‌شده هم می‌‌گویند. سپس سکه استورج (SCJX) برای ذخیره‌‌سازی پرداخت می‌‌شود و به عنوان انگیزه‌‌ای به گره‌‌های ذخیره‌‌کننده اطلاعات کاربری تعلق می‌‌گیرد.
  • IPFS: یک پروتکل جایگزین ابررسانه p2p که خروجی بالا، مدل ذخیره‌‌سازی بلاک حاوی آدرس همراه با هایپرلینک‌‌های حاوی آدرس ارائه می‌‌کند. اساسا این پروتکل به فایل‌‌ها اجازه می‌‌دهد تا در یک حالت دائمی و نامتمرکز ذخیره شوند و نسخه تاریخی برای فایل‌‌ها ارائه و گزینه‌‌های تکراری حذف می‌‌شود.
  • Decent: Decent یک پلتفرم اشتراک محتوای نامتمرکز است که به کاربران امکان آپلود و پوسازی از کارهای خود را می‌‌دهد (مثل ویدئو، موسیقی، کتاب‌‌های الکترونیکی و غیره) و این مسئله بدون نیاز به شخص واسطه متمرکز صورت می‌‌گیرد. کاربران می‌‌توانند به روشی ساده‌‌تر و با حذف واسطه‌‌های همیشگی به محتوا دسترسی داشته‌‌باشند و گره‌‌های میزبان محتوا با کارمزد جایزه و پاداش دریافت می‌‌کنند.
  • و چندین گزینه دیگر…

5- مکانیسم‌‌های توافقی غیرقابل‌‌تحمل

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

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

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

مکانیسم اثبات کار

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

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

مشکلات اثبات کار چیست؟

1- سخت‌‌افزارهای تخصصی برترهستند

یکی از نقاط ضعف اثبات کار، استفاده از سخت‌‌افزار تخصصی است. در سال 2013، دستگاه‌‌هایی با عنوان مدارهای مجتمع با کاربرد خاص (ASICها) فقط به قصد استخراج بیت کوین طراحی شدند و افزایش 10 تا 50 برابری در کارایی به همراه داشتند. از آن زمان، استخراج با CPU و GPU معمولی کاملا غیراقتصادی شده و فقط می‌‌توانید با ASIC تولیدی شخصی یا خریداری‌‌شده از تولیدکننده ASIC اقدام به استخراج کنید. این مسئله فاصله زیادی با ماهیت نامتمرکز بلاکچین‌‌ها دارد و قرار بود همه بتوانند شانس شرکت در امنیت شبکه را داشته باشند.

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

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

2- متمرکزسازی استخرهای استخراج

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

3- هدر رفتن انرژی

استخراج‌‌کنندگان برای اجرای محاسباتی که الگوریتم اثبات کار را می‌‌کند، مقادیر سنگینی نیروی رایانشی هزینه می‌‌کنند اما متاسفانه تمام این کار رایانشی هیچ ارزشی برای جامعه ندارد. طبق شاخص مصرف انرژی بیت کوین Digiconomist، مصرف برق سالانه بیت کوین حدودا 29.05 TWh است که حدود 0.13 درصد کل مصرف برق جهانی را تشکیل می‌‌دهد. برای فهم بیشتر این رقم، استخراج بیت کوین اکنون از 159 کشور جهان، برق بیشتری مصرف می‌‌کند (بخوانید هدر می‌‌دهد)!

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

راه‌‌حل‌‌های توافقی

اثبات کار کاربردی

یکی از روش‌‌های حل مشکل هدر رفتن انرژی، استفاده از عملکرد اثبات کار برای حل مسئله همزمانی است. مثلا فرض کنید استخراج‌‌کنندگان نیروی رایانشی خود را برای حل الگوریتم‌‌های مشکل AI صرف کنند و به فکر حل مشکل تصادفی SHA256 مورد نیاز توسط اثبات کار نباشند.

اثبات سهام

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

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

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

هرچند همانند تمامی فناوری‌‌های دیگر، هیچ چیزی بدون ایراد نیست. الگوریتم‌‌های اثبات کار هم چالش‌‌های اساسی خود را دارند. این چالش‌‌ها مخصوصا شامل موارد زیر می‌‌شود:

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

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

3- ساختار اتحادیه: در یک سیستم نامتمرکز که توسط انگیزه‌‌های اقتصادی مدیریت می‌‌شود، یک خطر بسیار بزرگ، ساختار تلاش‌‌های هماهنگ و چند انحصاری‌‌ها خواهد بود. همانطور که ولاد زامفیر، یک محقق در امور اتریوم می‌‌نویسد:

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

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

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

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

6- نبود مدیریت و استانداردها

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

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

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

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

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

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

7- ابزارهای نامناسب

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

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

من به عنوان یک توسعه‌‌دهنده بلاکچین و سالیدیتی، نقاط ضعف تجهیزات و ابزارهای اکوسیستم را چنین می‌‌دانم:

  • یک IDE که ساختارهای خوب و تمام پلاگین‌‌های ضروری برای قراردادهای هوشمند‌‌ اثربخش و تحلیل بلاکچین را داشته باشد.
  • یک ابزار ساخت و مولف که به خوبی ثبت شده و استفاده آسانی هم داشته باشد.
  • یک ابزار گسترش که مشکلی نداشته باشد.
  • اسناد فنی که وجود داشته باشد یا از نظر APIها و چارچوب‌‌ها، خیلی قدیمی نباشند.
  • آزمایش چارچوب‌‌هایی که ضعیف نیستند. ابزارهای کمی برای اتریوم هستند که ارزش کافی داشته باشند (مثل تروفل) اما گزینه‌‌ها و آزمایش‌‌های بیشتری در رابطه با بررسی چارچوب مورد نیاز است. من قراردادهای هوشمند‌‌ زیادی را دیده‌‌ام که میلیون‌‌ها دلار جابه‌‌جا کرده‌‌اند اما کاملا بدون آزمایش بوده‌‌اند. نبود آزمایش تحت هیچ شرایطی قابل‌‌قبول نیست اما نه زمانی که میزان بالایی پول وجود دارد. مثلا، فروش قراردادهای هوشمند‌‌ توکن BAT هیچ آزمایشی ندارد اما قراردادهایی بودند که برای جمع‌‌آوری 36 میلیون دلار در عرض 24 ثانیه مورد استفاده قرار گرفتند. هر انسان عاقلی می‌‌داند که اگر یک قرارداد بتواند چنین پولی را حرکت دهد، مورد حملات مختلفی قرار خواهد گرفت.
  • ابزارهای اشکال‌‌زدایی: کد اشکال‌‌زدایی سالیدیتی مشابه جستجوی طلا در یک تونل تاریک و با چشمانی بسته است! در کار قبلی، من درباره توسعه وب عمل کردم و توانستم با استفاده از یک اشکال‌‌زدای حیاتی، یک خط کد را اصلاح کنم. از آنجایی که اکنون چنین ابزاری نداریم یا حتی گزینه‌‌های مشابه با آن هم وجود ندارد، توسعه آن در سالیدیتی بسیار خسته‌‌کننده خواهد بود. ما شدیدا به ابزارهایی نیاز داریم که پیداکردن مشکلات را برایمان آسان‌‌تر کند.
  • ابزارهای تعیین‌‌کننده، مشابه مورد بالا.
  • حسابرسی امنیتی. این مسئله شدیدا مهم است. فقط یک سرویس حسابرسی امنیتی قابل‌‌توجه برای اتریوم وجود دارد که با عنوان Open Zepplin شناخته می‌‌شود. با این که آن‌‌ها با سرویس حسابرسی خود، کار فوق‌‌العاده‌‌ای برای اکوسیستم انجام می‌‌دهند، صنعتی که میلیاردها دلار از طریق قراردادهای هوشمند‌‌ کسب می‌‌کند، بیش از یک استارت‌‌آپ نیاز دارد. شرکت‌‌ها و مهندسین باید خدمات و ابزارهای پیشرفته‌‌تر تولید کنند و به کارشناسان امنیتی بیشتری برای کمک به حسابرسی قراردادهای هوشمند‌‌ نیاز است. تنها زمانی که توجه خوبی به امنیت قراردادهای هوشمند‌‌ معطوف می‌‌شود، بعد از حملات هک دو زوجی یا DAO می‌‌‌‌باشد. سپس تمامی تقصیرها به گردن توسعه‌‌دهندگان خواهد بود که قراردادهای هوشمند‌‌ را نوشته‌‌اند یا حتی بدتر از آن، تیم اصلی اتریوم سپر بلا می‌‌شود. من فکر می‌‌کنم این مسئله عادلانه نیست. توسعه‌‌دهندگان نباید مسئول حسابرسی به مسائل امنیتی کدهای خودشان باشند. مثل این است که از استفن کری بخواهید حسابداری خود را انجام دهد. هیچ چیز اینگونه عمل نمی‌‌کند. ما شدیدا به تخصص و کمک مهندسین و محققین امنیتی نیاز داریم. ما به سرمایه‌‌گذارانی نیاز داریم که به پول خود توجه بیشتری داشته باشند و تلاش کنند تا قراردادهای هوشمند‌‌ و بلاکچین‌‌ها ایمن‌‌تر شوند.
  • مرورگرها و تحلیل‌‌گران بلاک. برای اتریوم، ما اتراسکن‌‌ها را داریم که مرورگر بلاک محسوب می‌‌شوند. در بیت کوین ما مرورگرهایی مثل Blockchain.info، Blockexplorer یا Blockcypher را داریم. تمام این موارد برای اجتماع عالی هستند. در حقیقت من از اتر اسکن استفاده می‌‌کنم. اما در زمینه تحلیل زنجیره، هرگز به قدر کافی پیشرفت نکرده‌‌ایم. اطلاعات بسیار زیاد و جذابی است که می‌‌توانیم و باید آن‌‌ها را درباره بلاکچین‌‌های عمومی تحلیل کنیم.

8- تهدید رایانشی کوانتوم

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

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

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

راه‌‌حل‌‌های ضد کوانتومی

با اینکه من اصلا در این زمینه تخصصی ندارم، فهم بسیار محدودم این است که تحقیق کریپتوگرافی پس از کوانتومی در حال حاضر بر روی شش روش مختلف استوار است: کریپتوگرافی مبتنی بر شبکه، کریپتوگرافی متنوع، کریپتوگرافی مبتنی بر هش، کریپتوگرافی مبتنی بر کد، کریپتوگرافی انفرادی منحنی بیضوی و کوانتوم کلید متقارن سیستم‌‌های مقاومی مثل AES و SNOW 3G.

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

چالش‌‌های متنوعی که باید به ذهن بسپاریم:

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

نتیجه‌‌گیری

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

متاسفانه بسیاری از افراد از نظر مالی تمایل به نادیده گرفتن این مشکلات دارند؛ برخی از توسعه‌‌دهندگان و پیشروهای موثر در این فضا هم اینگونه هستند!

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

شاید از این مطالب هم خوشتان بیاید.

ارسال پاسخ

آدرس ایمیل شما منتشر نخواهد شد.