چرا اندازه گیری عملکرد بلاک چین سخت است؟

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

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

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

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

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

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

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

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

تأخیر در مقابل توان عملیاتی

به طور کلاسیک، عملکرد سیستم بلاک چین در دو بعد تأخیر و توان عملیاتی ارزیابی می‌شود: تأخیر میزان سرعت تایید یک تراکنش فردی را اندازه‌گیری می‌کند، در حالی که توان عملیاتی نرخ کل تراکنش‌ها را در طول زمان اندازه‌گیری می‌کند. این محورها هم برای سیستم های لایه 1 و لایه 2 و همچنین بسیاری از انواع دیگر سیستم های کامپیوتری (مانند موتورهای جستجو پایگاه داده و سرورهای وب) اعمال می شوند.

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

چالش در اندازه گیری تاخیر

تأخیر در ابتدا ساده به نظر می رسد: تأیید یک تراکنش چقدر طول می کشد؟ اما همیشه چندین راه مختلف برای پاسخ به این سوال وجود دارد.

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

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

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

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

تأخیر یک توزیع است نه یک عدد.

جامعه تحقیقاتی شبکه مدت‌هاست که این را درک کرده‌اند (برای مثال به این موضوع مراجعه کنید سخنرانی عالی گیل تنه). تاکید ویژه بر "دم بلند" توزیع است، زیرا تاخیر بسیار بالا حتی در 0.1٪ از تراکنش ها (یا درخواست های وب سرور) به شدت خواهد بود. ضربه کاربران نهایی

با بلاک چین، تاخیر تایید می تواند به دلایل مختلفی متفاوت باشد:

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

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

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

به این دلایل، یک دستورالعمل خوب این است:

ادعاهای مربوط به تأخیر باید توزیع (یا هیستوگرام) زمان های تأیید را به جای یک عدد واحد مانند میانگین یا میانه ارائه دهند.

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

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

و حتی اگر آمار خوبی در مورد توزیع دقیق تأخیر داشته باشیم، احتمالاً در طول زمان با تغییر سیستم و تقاضا در سیستم تغییر خواهند کرد. همچنین همیشه روشن نیست که چگونه توزیع تاخیر بین سیستم های رقیب را مقایسه کنیم. برای مثال، سیستمی را در نظر بگیرید که تراکنش‌ها را با تأخیر توزیع یکنواخت بین 1 تا 2 دقیقه (با میانگین و میانه 90 ثانیه) تأیید می‌کند. اگر یک سیستم رقیب 95 درصد تراکنش ها را در 1 دقیقه دقیقاً تأیید کند و 5 درصد دیگر را در 11 دقیقه (با میانگین 90 ثانیه و میانه 60 ثانیه) کدام سیستم بهتر است؟ پاسخ احتمالاً این است که برخی از برنامه ها اولی و برخی دومی را ترجیح می دهند.

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

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

چالش در اندازه گیری توان عملیاتی

توان عملیاتی نیز در نگاه اول ساده به نظر می رسد: یک سیستم در هر ثانیه چند تراکنش را می تواند پردازش کند؟ دو مشکل اصلی پیش می‌آید: «معامله» دقیقاً چیست و آیا ما آنچه را که یک سیستم امروز انجام می‌دهد یا ممکن است انجام دهد را اندازه‌گیری می‌کنیم؟

در حالی که "تراکنش در ثانیه" (یا tps) یک استاندارد واقعی برای اندازه گیری عملکرد بلاک چین است، تراکنش ها به عنوان یک واحد اندازه گیری مشکل ساز هستند. برای سیستم‌هایی که قابلیت برنامه‌ریزی با هدف کلی ("قراردادهای هوشمند") یا حتی ویژگی‌های محدودی مانند تراکنش‌های چندگانه بیت‌کوین یا گزینه‌های تأیید چند علامتی را ارائه می‌دهند، مسئله اساسی این است:

همه معاملات برابر نیستند.

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

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

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

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

به طور کلی:

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

معاوضه تاخیر-عملکرد

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

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

هزینه های معامله

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

1. چقدر تقاضا در بازار برای انجام معاملات وجود دارد؟
2. چه توان عملیاتی کلی توسط سیستم به دست می آید؟
3. این سیستم چقدر درآمد کلی برای اعتبار سنجی یا ماینرها فراهم می کند؟
4. چه مقدار از این درآمد بر اساس کارمزد تراکنش در مقابل پاداش های تورمی است؟

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

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

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

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

نتیجه

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

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