چرا ارقام تیتر TPS اغلب مقیاس پذیری واقعی را تحریف می کنند

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

7 نظرات
چرا ارقام تیتر TPS اغلب مقیاس پذیری واقعی را تحریف می کنند

10 دقیقه

چرا ارقام تیتر TPS اغلب مقیاس‌پذیری واقعی را تحریف می‌کنند

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

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

بسیاری از بنچمارک‌های اولیه یا تست‌های پیش از شبکه اصلی TPS را در شرایط ایده‌آل اندازه می‌گیرند: یک نود منفرد یا یک تست‌نت به‌طور دقیق کنترل‌شده. آن شرایط سرعت ماشین مجازی یا توان اجرایی ایزوله را می‌سنجند تا مقیاس‌پذیری واقعی در سطح شبکه. کارتر فلدمن، بنیان‌گذار Psy Protocol و از هکرها و تولیدکنندگان بلاک سابق، اشاره می‌کند که اندازه‌گیری‌های تک‌نودی گمراه‌کننده هستند زیرا هزینه‌های انتشار (relay) و بررسی تراکنش‌ها در یک توپولوژی توزیع‌شده را حذف می‌کنند.

فلدمن گفته است: «بسیاری از تست‌های پیش‌اصلی، تست‌نت یا بنچمارک ایزوله TPS را با تنها یک نود اجرا شده اندازه می‌گیرند. در آن صورت می‌توانی اینستاگرام را یک بلاک‌چین بنامی که می‌تواند به ۱ میلیارد TPS برسد چون یک مرجع مرکزی هر فراخوان API را تأیید می‌کند.»

اجرای تراکنش تنها بخشی از معما است

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

پروژه‌های جدید TPS بالایی را تبلیغ می‌کنند، در حالی که استفادهٔ زندهٔ شبکه به‌ندرت به این سقف‌ها نزدیک می‌شود.

نمونه‌های تاریخی: EOS و سولانا

EOS سقف نظری TPS را در مقیاس میلیون‌ها اعلام کرد، اما هرگز آن سطح را در شبکه اصلی به‌دست نیاورد. ادعاهای وایت‌پیپر درباره‌ی حدود یک میلیون TPS چشم‌گیر بودند، ولی آزمایش‌های واقع‌گرایانه و پژوهش‌ها تصویر متفاوتی نشان دادند. تست‌های Whiteblock و دیگر تحلیل‌های دنیای واقعی نشان دادند که توان عملیاتی در شرایط شبکهٔ عملیاتی به حدود ۵۰ TPS کاهش می‌یابد.

در نمونه‌ای اخیر، کلاینت ولیدیتور Firedancer از Jump Crypto در تست‌های کنترل‌شده ۱ میلیون TPS را نشان داد. آن دستاورد نشان می‌دهد مهندسی تا چه حد می‌تواند سرعت اجرای خام را فشار دهد. با این حال، شبکه سولانا در شرایط زنده عموماً در محدودهٔ ۳۰۰۰–۴۰۰۰ TPS پردازش می‌کند؛ سهم قابل‌توجهی از آن عدد صرف ترافیک رأی‌دهی یا اجماع می‌شود نه صرفاً تراکنش‌های کاربری. حدود ۴۰٪ از فعالیت‌های زنجیره‌ای در مجموع سولانا می‌تواند ترافیک غیرکاربری یا غیررأی باشد، بنابراین توان عملیاتی رو به کاربر واقعی پایین‌تر است.

سولانا در ۱۰ فوریه بدون تراکنش‌های رأی، ۱٬۳۶۱ TPS ثبت کرده بود.

این مثال‌ها یک الگوی ثابت را نشان می‌دهند: رکوردهای عملکردی ایزوله با توان پایدار شبکهٔ اصلی که در آن غیرمتمرکزسازی، انتشار شبکه و هزینه‌های تأیید همگی در بازی هستند یکسان نیستند.

مشکل مقیاس‌بندی خطی و هزینه‌های غیرمتمرکزسازی

توان عملیاتی معمولاً به‌صورت خطی با بار کاری مقیاس می‌یابد: دو برابر تراکنش به‌طور تقریبی دو برابر کار لازم است. این رابطهٔ خطی مشکل‌ساز می‌شود زیرا هر نود باید حجم افزاینده‌ای از داده‌ها را دریافت و تأیید کند. کلاه‌های پهنای باند، محدودیت‌های CPU، ورودی/خروجی ذخیره‌سازی و تأخیرهای همگام‌سازی در نهایت گلوگاه‌های سختی را تشکیل می‌دهند. هرچه TPS را بدون تغییر مدل تأیید بالاتر ببرید، مجموعه‌ی ماشین‌هایی که قادر به اجرای نود کامل هستند کوچک‌تر می‌شود، قدرت تأیید متمرکزتر می‌شود و غیرمتمرکزسازی تخریب می‌گردد.

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

جداسازی اجرا و تأیید

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

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

اثبات‌های بازگشتی ZK و تجمیع اثبات‌ها

اثبات‌های بازگشتی ZK اجازه می‌دهند اثبات‌های متعدد در یک اثبات واحد ترکیب شوند که صحت بسیاری از اثبات‌های قبلی را تصدیق می‌کند. فلدمن این موضوع را با درخت اثبات تصویر کرد: ۱۶ تراکنش کاربری می‌تواند به هشت اثبات تبدیل شود، که سپس به چهار اثبات فشرده می‌گردند، بعد دو، و در نهایت یک اثبات فشردهٔ واحد. نتیجهٔ نهایی یک شیء کوچک و واحد است که صحت یک دستهٔ بزرگ از تراکنش‌ها را ثابت می‌کند.

چگونگی تبدیل چندین اثبات به یکی.

با استفاده از اثبات‌های بازگشتی، توان عملیاتی می‌تواند بدون افزایش متناسب در هزینه‌های تأیید هر نود افزایش یابد. این بدان معناست که TPS مؤثر شبکه بالاتر می‌رود در حالی که تأیید برای نودهای عادی ارزان باقی می‌ماند. با این وجود، هزینه به‌طور کامل از بین نمی‌رود — بلکه جابه‌جا می‌شود. تولید اثبات‌های ZK می‌تواند محاسباتی گران‌قیمت باشد و معمولاً نیازمند سخت‌افزار یا زیرساخت‌های تخصصی است. کار سنگین به‌عهدهٔ پروورها قرار می‌گیرد که اگر با دقت طراحی نشوند می‌توانند متمرکز شوند و بار دیگر معامله‌هایی با غیرمتمرکزسازی ایجاد کنند.

چرا بیشتر زنجیره‌ها هنوز از مدل‌های سنتی استفاده می‌کنند

پذیرش تأیید مبتنی بر اثبات اغلب به معنای بازطراحی اجزای اصلی یک بلاک‌چین است: نمایش وضعیت، مدل‌های اجرا و نحوهٔ مدیریت در دسترس‌پذیری داده‌ها. افزودن تأیید مبتنی بر ZK به یک EVM مرسوم یا مدل اجرای ترتیبی پیچیده است. این موضوع توضیح می‌دهد که چرا بسیاری از شبکه‌های جاافتاده علی‌رغم مزایای نظری ZK، همچنان بر اجرا و تأیید سنتی تکیه می‌کنند.

فلدمن همچنین به دینامیک‌های تاریخی سرمایه‌گذاری اشاره کرد: سرمایه‌گذاران اولیه و تیم‌ها معمولاً پروژه‌هایی را ترجیح می‌دادند که با مدل‌های اجرای آشنا (مانند زنجیره‌های سازگار با EVM) مطابقت داشتند. ساخت یک پشتهٔ اجرایی ZK-نیتیو نیاز به زمان بیشتر و مهندسی نوآورانه داشت که در ابتدا جمع‌آوری سرمایه را برای برخی تیم‌ها دشوارتر می‌کرد.

شاخص‌های عملکرد فراتر از TPS خام

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

«من قویاً معتقدم TPS دومین معیار عملکرد یک بلاک‌چین است، اما فقط اگر در محیط تولید اندازه‌گیری شده باشد یا در محیطی که تراکنش‌ها نه‌تنها پردازش می‌شوند بلکه توسط نودهای دیگر نیز منتشر و تأیید می‌شوند،» فلدمن تأکید کرده است.

LayerZero Labs و دیگران با ترکیب نوآوری‌های اجرایی با ابتدایی‌های ZK، ادعاهای سقف TPS چشم‌گیری مطرح کرده‌اند. برای مثال، LayerZero یک زنجیرهٔ Zero تبلیغ کرد که مدعی است می‌تواند با بهره‌گیری از فناوری ZK تا میلیون‌ها TPS مقیاس‌پذیری داشته باشد. این رویکردها امیدوارکننده‌اند، اما دوام غیرمتمرکز بلندمدت آن‌ها بستگی به این دارد که تولید و تأیید اثبات‌ها چگونه در سراسر شبکه توزیع شود.

نکات عملی برای توسعه‌دهندگان و کاربران

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

نتیجه‌گیری

اعداد تیتر TPS جذاب اما ناقص‌اند. مقیاس‌پذیری دنیای واقعی باید نحوهٔ پخش، تأیید و انگیزش اقتصادی تراکنش‌ها در یک شبکهٔ غیرمتمرکز را در نظر بگیرد. تکنیک‌هایی مانند جداسازی اجرا از تأیید و استفاده از اثبات‌های صفر دانش — به‌ویژه ZK بازگشتی — مسیرهای امیدوارکننده‌ای برای افزایش توان عملیاتی قابل استفاده ارائه می‌دهند. با این حال، این راه‌حل‌ها بارها را جابه‌جا می‌کنند نه اینکه آن‌ها را حذف کنند، و نیاز به مهندسی دقیق برای حفظ غیرمتمرکزسازی دارند. فعلاً بهترین معیار برای سنجش توانایی یک زنجیره در مقیاس‌پذیری، توان عملیاتی آزمون‌شده در تولید همراه با شاخص‌های اقتصادی مانند کارمزدها و توزیع ولیدیتورها باقی مانده است.

منبع: cointelegraph

ارسال نظر

نظرات

دانیکس

مثال سولانا جالب بود؛ نشون میده مهندسی میتونه اجرا رو فشار بده ولی تولید و ترافیک رأی‌گیری واقعیت رو نشون میدن. اگر پروورها متمرکز شن چی؟

پمپزون

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

ماکس_

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

امیر

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

لابکور

واقعا ZK بازگشتی میتونه مشکل تمرکز رو حل کنه؟ به نظرم تولید اثبات سختیه و ممکنه دوباره متمرکز بشه، سند عملی لازمِ.

بلکتون

معقولِ، TPS فقط روی کاغذ مهم نیست. باید ببینی انتشار، پهنای باند و تایید چطور خرج میکنن، بنچمارک تولیدی رو ببین.

دیتاپالس

وااای یعنی اون عددای میلیونی TPS بیشتر نمایشی هستن، تو شبکه زنده همه چیز فرق میکنه، کاش زودتر می‌فهمیدن...

مطالب مرتبط