پشته وب ۳

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

0 91

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

Web3 Stack

دوباره می‌گویم، در این مطلب می‌خواهم بخشی از برداشت‌هایی که از این دیاگرام داشته‌ام را با شما در میان بگذارم.

پشته مرکزی

پشته‌ی توسعه‌ی مرکزی قرار است دقیقاً چه چیزی را در اختیار توسعه‌دهندگان اپلیکیشن‌های غیرمتمرکز قرار دهد؟

این پشته باید دفتر کلی متعارف از تراکنش‌های مرتب و معتبر را فراهم کند.

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

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

  • Oasis Labs مشغول ساختن Ekiden است؛ پلتفرمی عصبی که به تعداد زیادی زنجیره اجازه‌ی پشتیبانی از محاسبات خصوصی، برون-زنجیره‌ای، و مبتنی بر TEE را می‌دهد.
  • Handshake مشغول ساختن DNS غیرمتمرکز است. کسب پذیرش با توجه به پیش‌فرض‌های سیستم عامل برای DNS کار بسیار سختی خواهد بود.
  • مونرو مشغول ساختنKovri است تا به بسته‌های حفظ‌کننده‌ی حریم خصوصی که بین گره‌ها جابجا می‌شوند اطمینان دهد که حریم خصوصی سطح IP دارند. Kovri ساخته می‌شود تا از خیلی از زنجیره‌ها پشتیبانی کند.
  • BloxRoute مشغول کار روی شبکه‌ای بدون وابستگی به زنجیره برای تحویل بلاک است.
  • بنیاد اتریوم DevP2P و Protocol Labs کتابخانه‌ی LibP2P را ساخته است. اکثر زنجیره‌های جدید از یکی از این فریم‌ورک‌ها استفاده می‌کنند؛ حتی صحبت‌هایی شنیده می‌شود که اتریوم هم می‌خواهد به استفاده از LibP2P روی بیاورد.
  • اتریوم و Polkadot مشغول کار بر روی کوچک‌سازیِ تمام-وضعیتی هستند.
  • تیم‌های زیادی مشغول انجام آزمایش در لایه‌ی اجماع هستند:
    • اجماع بلاکچین رهبر-محور
      • بیت کوین و بیت‌کوین کش – اثبات کار (POW) بهینه‌شده برای ASIC
      • اتریوم ۱.۰، مونرو، Zcash و بقیه – اثبات کار مقاوم در برابر ASIC
      • Kadena – اثبات کار برهم‌تابیده
      • Chia – اثبات فضا و زمان (POST) و اثبات زمان سپری‌شده (POET)
      • فایل‌کوین – POST همراه با اطلاعات مفید
      • اتریوم ۲.۰ – اثبات سهم Casper TFG
      • تاندر – POS با عقب‌نشینی POW
      • Decred – اثبات کار و سهم ترکیبی
      • Polkadot – اثبات سهم Honeybadger
      • EOS – اثبات سهم محول شده (DPOS)
      • Tezos – گونه‌ی دیگری از DPOS
      • Tendermint – گونه‌ی دیگری از DPOS
      • Solana – اثبات تاریخ (POH)
      • Dfinity – رله‌ی آستانه + اجماع شکاف احتمالی
      • Algorand – توافق بیزانس با انتخاب رهبر (BA*)
    • اجماع بلاکچین بدون رهبر
      • پروتکل اجماع ریپل
      • پروتکل اجماع استلار
      • آوالانچ
    • گراف‌های جهت‌دار غیرمدور بلاک
      • بایت‌بال – اجماع زنجیره‌ی اصلی بایت‌بال
      • هش‌گراف – پروتکل اجماع هش‌گراف
      • DAGlabs – Spectre
      • بلینک – پروتکل اجماع بلینک
      • اسپیس‌مِش – POST برای انتخاب کمیته، و بعد مدل خرگوش و لاک‌پشت
  • چند ماشین انتقال وضعیت اصلی وجود دارد:
    • ماشین مجازی اتریوم (EVM) – اتریوم ۱.۰، اترمینت، هش‌گراف، WANchain و بقیه
    • ماشین مجازی اسمبلی وب (WASM) – دفینیتی، EOS، Polkadot، اتریوم ۲.۰
    • آشکارسازی مستقیم LLVM – کاردانو، سولانا
    • ماشین‌های سفارشی انتقال وضعیت
      • کادنا
      • تزوس
      • آرچین
      • کودا

این فهرست‌بندی سوال تازه‌ای را به وجود می‌آورد: در مقایسه با سایر لایه‌های پشته‌ی مرکزی، چرا این همه تیم روی لایه‌ی اجماع کار می‌کنند؟

پاسخ اصلی این سوال این است که چون پول در این لایه وجود دارد.

با این جواب به سوال بعدی برمی‌خوریم: چرا پول در لایه‌ی اجماع متمرکز شده است؟

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

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

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

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

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

  • Kadena معتقد است که قراردادهای هوشمند باید توسط انسان قابل خواندن باشد.
  • Tezos معتقد است که همه‌ی قراردادهای هوشمند باید به طور رسمی تایید شود.
  • Rchain معتقد است که قراردادهای هوشمند باید به طور همزمان در زنجیره‌های dApp اجرا شده و به طور رسمی تایید شود.
  • Coda معتقد است که همه چیز باید از طریق SNARK اجرا شود تا مطمئن باشیم که حتی کوچک‌ترین گره‌ها هم می‌توانند تمامیت زنجیره‌ها را تایید کنند؛ این کار باعث می‌شود احتمال حفظ بیشترین حد غیرمتمرکز بودن به حداکثر برسد.

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

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

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

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

اگر اثر شبکه‌ایِ پیرامون WASM خودش را نشان دهد، در بلند مدت رقابت برای تیم‌هایی که به دنبال ساختن ماشین‌های انتقال وضعیت یکتا هستند سخت می‌شود.

پشته مرکزی بزرگ‌تر

  • عناصر بسیاری وجود دارد که در زنجیره‌ لایه‌ی پایه نقشی ندارد و نباید داشته باشد، و برای توسعه‌ی اپلیکیشن‌های غیرمتمرکز هم ضروری نیست، ولی به باور من این عناصر می‌توانند اجزا اصلی پشته‌ی توسعه باشند. اگر در پشته به سمت بالا حرکت کنیم:
  • اکثر تیم‌ها مشغول ساختن زنجیره‌های فرعی‌اند. اصلی‌ترین نمونه‌های این موضوع در شبکه‌ی بیت کوین، درایوچین‌ها و Liquid هستند. در دنیای اتریوم، اصلی‌ترین نمونه‌ها SKALE در فریم‌ورک پلاسما، و زنجیره‌های Cosmos Ethermint هستند که به عنوان زنجیره‌های dApp مستقل محسوب می‌شوند.
  • تیم‌هایی وجود دارند که در کانال پرداخت و کانال وضعیت شبکه‌ی بیت کوین مشغول کارند؛ از جمله‌ی مهم‌ترین آن‌ها می‌توانیم به Lightning Labs و Blockstream اشاره کنیم. نمونه‌های مشابه آن در اکوسیستم اتریوم Raiden و Celer است. خیلی‌ها، به‌ویژه آن‌هایی که در جامعه‌ی بیت کوین حضور دارند، این رویکرد را تنها روش ممکن برای مقیاس پذیری می‌دانند.
  • کار پروتکل میان ‌دفترکلی (ILP) چند ماه پیش نهایی شد. تیم‌های زیادی با این پروتکل کار می‌کنند تا به امکان هم‌کنش‌پذیریِ فرا-زنجیره‌ای دست یابند. اکثر توسعه‌دهندگان و سرمایه‌گذاران تا همین اواخر توجه زیادی به ILP نداشتند. ولی کاملا محتمل است که ILP به مهم‌ترین لایه در پشته‌ی وب ۳ تبدیل شود، چون ارزش به زنجیره‌های ایمن‌تر مثل بیت کوین منتقل می‌شود، در حالی که دادوستد به زنجیره‌های کارآمدتری مثل اتریوم می‌رود.
  • تا جایی که اطلاع داریم، The Graph تنها تیمی است که مشغول ساخت لایه‌ی کوئری غیرمتمرکز برای اتریوم است. در گذشته، همه‌ی تیم‌هایی که بر روی اتریوم اپلیکیشن غیرمتمرکز می‌ساختند، مجبور بودند زیرساخت شاخص‌گذاری متناسب با آن را هم بسازند.
    • تعدادی از تیم‌ها از جمله BigchainDB، OrbitDB و Bluezelle مشغول ایجاد پایگاه‌های داده‌ی ساخت‌یافته‌ی تغییرناپذیری (پایین راست دیاگرام وب ۳) به مثابه زنجیره‌های بدون نیاز به مجوز و آزاد هستند. با توجه به عملکرد قدرتمندی که از پایگاه‌های داده‌ی ساخت‌یافته به دست می‌آید، باید ببینیم توسعه‌دهندگان از این سیستم‌ها به طور بومی استفاده خواهند کرد، یا مثل تیم‌هایی نظیر SKALE این سیستم‌های متن باز را به عنوان زنجیره‌های پلاسما به کار می‌گیرند.

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

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

اجزای اختیاری

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

فقط تعداد کمی از خدمات این اجزای اختیاری از جمله Livepeer, 0x, Kyber, Storj, Sia, Oraclize و Civic در شبکه‌ی اصلی فعال هستند. اما اکثر تیم‌هایی که این اجزا را می‌سازند هنوز ابزارهای آماده‌ی خود را منتشر نکرده‌اند.

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

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

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

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

بالای پشته

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

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

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

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

ولی اگر بتوانید میزبان اپلیکیشن را غیرمتمرکز کنید چه اتفاقی می‌افتد؟ Codius پروژه‌ی متن بازی است که توسط ریپل آغاز شد، هرچند تخصیص منابع آن در سال ۲۰۱۵ متوقف گردید. اخیراً استفان توماس، مدیر ارشد فن‌آوری ریپل، این شرکت را ترک کرد تا ادامه‌ی پروژه‌ی Codius را با نام جدید Coil آغاز کند. حال، باید ببینیم این لایه‌ی پشته در عمل چگونه کار خواهد کرد، و چه موانعی بر سر راه این پروژه قرار خواهد گرفت.

سرانجام، در بالای این پشت همان چیزی قرار دارد که کاربر نهایی با آن تعامل برقرار می‌کند: مرورگر dApp. این مرورگر در اتریوم Metamask و Toshi، و در EOS Scatter است.

راهکارهای مقیاس پذیری لایه ۲

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

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

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

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

مشاهدات دیگر

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

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

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

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

ارسال پاسخ

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