سری مقالات تخصصی ویتالیک بوترین؛ آیا اتریوم باید از امکانات دیگری استقبال کند؟

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

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

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

رسالت سابق پروتکل

در ایام گذشته، ایده‌ای به نام “اتریوم ۲” وجود داشت که با آرزوی ایجاد یک شبکه ساده، زیبا و بی آلایش ، در تلاش بود تا حجم کاری خود را در کمترین حد ممکن نگه‌دارد و اکثریت فعالیت‌های به‌جا‌مانده را روی دوش کاربران بیندازد! به بیانی دیگر، این پروتکل در نقش یک ماشین مجازی (VM) فعالیت می‌کرد و اعتبارسنجی هر بلاک، یک فراخوان ماشینی (Machine Call) ساده به حساب می‌آمد.

در سال ۲۰۱۵، موارد مذکور به ۲ زمینه مجزا که در ذهن ما وجود داشتند مرتبط می‌شدند:«انتزاع‌سازی حساب‌ها (Account Absraction) و مقیاس‌پذیری (Scalibility)». ابن شیوه فکری به طور مختصر مورد بررسی قرار گرفت امّا چندان دوام نداشت. چرا که در شبکه فضاهای بسیاری با اعتبارسنجی‌های مختلف اشغال شده بودند و مقیاس‌پذیری چندان ممکن به نظر نمی‌رسید.

البته که با ادغام امکاناتِ نمونه‌سازیِ در دسترس بودنِ داده‌ها (Data Availability Sampling) و رول‌آپ‌های دانش صفر در ماشین مجازی اتریوم (ZK-EVM) ، این احتمال وجود دارد که آینده اتریوم، تا حد زیادی به چشم‌اندازی که در ذهن داشتیم شباهت داشته باشد!

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

دستورات فنی مهم در اتریوم

در زیرساخت‌های فعلی اتریوم، کدهای شبکه به گونه‌ای نوشته شده‌اند که دستورات زیرساختی پلتفرم با اهداف شبکه همسو باشند. به عنوان مثال، دستورِ “validate_transcaction” مواردی چون nonce و صحتِ امضای تراکنش‌ها را مورد بررسی قرار می‌دهد.

نانس (nonce) در رمزنگاری چیست؟ در مقاله فرمت آدرس‌های اتریوم به توضیح کامل این مفهوم و نحوه تشخیص آدرس‌های بلاک چین اتریوم پرداخته‌ایم.

در واقع این دستور کمک می‌کند که اموری چون بازیابی اجتماعی (Social Recovery) و استفاده از کیف پول‌های چند امضایی (Multisig Wallets) را با سهولت بیشتری انجام دهند.

معرفی استانداردهای اتریوم

به مرور زمان شاهد ایجاد یک تکامل در انتزاع حساب‌ها (Account Abstraction) بودیم. در واقع پروسه ایجاد انتزاع اکانت‌ها با EIP-86 و در سال ۲۰۱۶ آغاز شد. پس از مدّتی، این استاندارد به EIP-208 تغییر نام یافت. پس از مدّت‌ها کش و قوس بین پروپوزال‌های مختلف اتریوم، استانداردِ EIP-2938 پیشنهاد شد که علی‌رغم کارایی، با رویکرد مینیمالیستی شبکه در تضاد بود و پیچیدگی‌هایی را دارا بود:

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

سرانجام به منظور آغاز انتزاع‌سازی حساب‌ها (البته بدون نیاز به تلاش‌های توسعه‌دهندگان بنیادی اتریوم که مشغول بهینه‌سازی کلاینت‌های اتریوم و آپدیت Merge بودند)، EIP-2938 به طور کامل پایه‌ریزی و به پروتکل متفاوتی تحت عنوان ERC-4337 تبدیل گشت.

از آنجایی که ماحصل این تغییر مجموعه‌ای از قوانین و مقررات (ERC) جدید بود، به اجرای یک هاردفورک نیازی نبود و از بُعد فنی، تغییرات خارج از پروتکل اتریوم قابل اجرا بودند.

دلیل استفاده از ERC-4337

به طور خلاصه، دلایل مختلفی برای استفاده مجدد از ERC-4337 در پروتکل وجود داشته است:

• بهینه‌سازی کارمزدها: تمامی فعالیت‌های انجام شده بر بستر EVM، مقدار معینی از انرژی‌های ماشین مجازی را مصرف می‌کند. هزینه‌هایی چون هزینه ذخیره‌سازی داده‌ها، می‌توانند به افزایش کارمزدهای شبکه منجر شوند. با استفاده از ERC-4337، این هزینه‌ها تا حد زیادی از بین می‌روند.
• ریسک بروز باگ در کدهای شبکه
• پشتیبانی از کدهای دستوری EVM
• مقاومت در برابر سانسور

البته لازم به ذکر است که در برخی موارد، تراکنش‌های ERC-4337 هم می‌توانند از تراکنش‌های عادی اتریوم پر هزینه‌تر تمام شوند. در واقع تراکنش‌های عادی اتریوم ۲۱هزار gas و تراکنش‌های ERC-4337 به طور میانگین ۴۲هزار واحد gas هزینه را در پی خواهند داشت.

به تازگی تدابیر دیگری همچون ZK-EVMها برای گسترش امکانات شبکه اتریوم اندیشیده شده‌اند که امکان ایجاد mempoolهای خصوصی و تامین نقدینگی را فراهم می‌کنند. در ادامه به این تکنولوژی بیشتر می‌پردازیم.

کاربردهای ZK-EVM

در حال حاضر، رول‌آپ‌های دانش صفر (ZK-rollupها) بسیاری وجود دارند که برای اجرای اعتبارسنجی‌ بلاک‌ها، کدهای به نسبت مشابهی را اجرا می‌کنند. همچنین می‌توان اکوسیستم‌های متعددی را به صورت مجزا در شبکه اجرا نمود:

• PSE ZK-EVM
• Kakarot
• ZK-EVM اختصاصی پالیگان
• Linea
• Zeth

یکی از مسائلی که به تازگی در حوزه ZK-Rollupها به آن برخورده‌ایم، به شیوه مقابله با احتمال بروز باگ در کدهای ZK ارتباط دارد. در حال حاضر، تمامی سیستم‌های فعال از برخی قابلیت‌های امنیتی برخوردارند که می‌توانند مشکلاتی چون باگ‌ها را اثبات کنند.

بلاک چین یک کامپیوتر شخصی نیست!

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

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

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

به طور کلی، نکات بسیاری هستند که ما نیاز داریم تا آن‌ها را مورد پذیرش قرار دهیم:

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

به طور خلاصه،استیکینگ شناور (Liquid Staking)، ZK-EVMها و پیش‌پردازنده‌ها (Precompilers)، نشان می‌دهند که امکان پذیرش حد متعادلی از امکانات، تصمیم هوشمندانه‌ای خواهد بود امّا اگر از این حد فراتر رود خیر!

حسن ختامی بر وضعیت اتریوم

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

• می‌توانیم به جای اجرای یک استیکینگ شناور به صورت کامل، کمی قوانین استیکینگ فعلی را تغییر دهیم.
• به جای افزایش تعداد پیش‌پردازنده‌ها، می‌توانیم از EVM-MAX یا SIMD استفاده کنیم تا طیف گسترده‌تری از عملکردها را با بهینگی بیشتری انجام دهیم.
• همچنین این امکان وجود دارد که «پذیرش تمامی رول‌آپ‌ها» را با «اعتبارسنجی EVM» جایگزین کنیم.
• ارائه پروپوزال EIP-5003، به آدر‌س‌های خارجی (EOA) این اجازه را می‌دهد تا حساب‌های خود را با قراردادهایی که از کارایی بهتری برخوردارند جایگزین کنند.

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