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

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

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

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

این تفاوت در عملکرد و مقیاس‌پذیری بلاکچین بسیار مهم است. بسیاری از رویکردها برای بهبود عملکرد به هیچ‌وجه به بهبود مقیاس‌پذیری نمی‌انجامند. مثال ساده در این خصوص، استفاده از طرح امضای دیجیتال کارآمدتر نظیر امضاهای BLS است که حجم آنها تقریبا نصف حجم امضای ECDSA یا امضای اشنور (Schnorr) است. اگر امضاهای دیجیتال بیت کوین از ECDSA به BLS تغییر کند، تعداد تراکنش‌ها در هر بلاک ۲۰٪ تا ۳۰٪ افزایش یافته و عملکرد شبکه بهبود می‌یابد. اما فقط یکبار می‌توان این کار را انجام داد. گفتنی است طرح امضای دیگری وجود ندارد که فضای کمتری نسبت به امضای BLS نیاز داشته باشد.

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

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

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

مقایسه تاخیر و توان عملیاتی

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

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

چالش‌های موجود در اندازه‌گیری تاخیر

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

اول از همه می‌توانیم به سنجش و اندازه‌گیری تاخیر بین نقطه‌های زمانی مختلف و کسب نتایج متفاوت بپردازیم. برای مثال، آیا باید اندازه‌گیری تاخیر هنگامی آغاز شود که کاربر دکمه «ثبت تراکنش» (Submit) را فشار می‌دهد یا هنگامی که تراکنش به استخر حافظه (Mempool) وارد می‌شود؟ آیا اندازه‌گیری تاخیر را باید هنگامی پایان دهیم که تراکنش در بلاک وارد می‌شود یا هنگامی که یک بلاک با بلاک بعدی خود تایید می‌شود؟

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

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

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

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

جامعه محققان ایجاد شبکه مدت‌ها است که به این موضوع پرداخته‌اند. تاکید ویژه این جامعه بر توزیع Long Tail یا به عبارت دیگر توزیع ادامه‌دار و طولانی بوده است، زیرا تاخیر بسیار زیاد حتی در ۰.۱٪ از کل تراکنش‌ها می‌تواند تاثیر به‌سزایی بر کاربران نهایی بگذارد.

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

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

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

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

صحبت درباره تاخیر باید به صورت یک توزیع (یا نمودار هیستوگرام) از زمان‌های تایید بیان شود، نه یک عدد واحد و مجزا نظیر میانگین (Mean) یا میانه (Median).

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

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

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

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

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

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

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

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

تمام تراکنش‌ها برابر نیستند.

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

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

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

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

به طور کل می‌توان گفت:

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

ارتباط بین تاخیر و توان عملیاتی

تاخیر و توان عملیاتی معمولا ارتباط نزدیکی با یکدیگر دارند. طبق گفته لفتریس کوکوریس کوگیاس (Lefteris Kokoris-Kogias)، این ارتباط همانند یک خط صاف نیست، بلکه دارای نقطه انحنایی است که در آن با افزایش بار سیستم به سمت حداکثر توان عملیاتی خود، تاخیر نیز با افزایش شدیدی مواجه می‌شود.

سیستم‌های رول‌آپ دانش صفر (Zero-Knowledge Rollup) مثال خوبی از ارتباط توان عملیاتی و تاخیر است. بسته‌های بزرگ تراکنش‌ها، زمان تایید را افزایش می‌دهند و این موضوع به افزایش تاخیر منجر می‌شود، اما با افزایش تراکنش‌هایی با حجم بسته بیشتر، تاثیر درون زنجیره‌ای این موضوع کاهش یافته و توان عملیاتی افزایش می‌یابد.

کارمزد تراکنش‌ها

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

• تقاضای بازار برای انجام تراکنش مذکور در چه سطحی است؟

• توان عملیاتی کلی که سیستم مذکور می‌تواند به آن دست یابد در چه سطحی قرار دارد؟

• سیستم مذکور چه مقدار درآمد می‌تواند به تاییدکنندگان و ماینرها ارائه دهد؟

• چه مقدار از این درآمد بر اساس کارمزد تراکنش‌ها است و چه مقدار از آن به پاداش‌ها متکی است؟

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

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

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

به طور کل می‌توان گفت:

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

نتیجه‌گیری

ارزیابی عادلانه و دقیق عملکرد یک سیستم در بلاکچین

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