TPS چیست؟
TPS چیست؟
Transactions Per Second تعداد تراکنش پردازش‌شده در یک بازه زمانی است، اما به‌تنهایی معیار کامل Scalability نیست.
ایران اکسچنج
مقیاس پذیری در بلاک چین چیست؟
فائزه سوری
زمان تقریبی مطالعه: 8 دقیقه
فهرست عناوین
مقیاس‌پذیری بلاکچین یعنی توان یک شبکه برای پاسخ‌گویی به افزایش تقاضا بدون اینکه هزینه، تأخیر، نیاز سخت‌افزاری یا تمرکز شبکه به شکل نامتناسب افزایش پیدا کند. به همین دلیل Scalability فقط «تعداد تراکنش در ثانیه» نیست.
یک شبکه ممکن است TPS بالاتری داشته باشد، اما برای رسیدن به آن Blockهای بسیار بزرگ، Validator Set محدود، سخت‌افزار گران یا Assumptionهای امنیتی بیشتری نیاز داشته باشد. بنابراین ارزیابی مقیاس‌پذیری باید چندبعدی باشد: Throughput، Latency/Finality، Fee، Data Availability، Node Requirements و Decentralization. برای درک بهتر چرخه Transaction و Block قبل از ورود به Scaling، مقاله بلاکچین چگونه کار می‌کند؟ را مطالعه کنید.
مقیاس‌پذیری بلاکچین چیست؟
Scalability توان سیستم برای افزایش ظرفیت در برابر رشد تعداد کاربران، Transactionها، Smart Contractها و حجم Data است. یک معماری مقیاس‌پذیر باید بتواند Load بیشتر را مدیریت کند بدون اینکه Security یا امکان اجرای Node مستقل به‌طور غیرمنطقی قربانی شود.
Ethereum.org نیز مسئله Scalability را در قالب Trade-off میان Scale، Security و Decentralization توضیح می‌دهد و تأکید می‌کند افزایش ساده Data/Execution روی L1 می‌تواند Nodeها را تحت فشار قرار دهد. توضیح رسمی Ethereum درباره Scalability و PeerDAS
مقیاس‌پذیری را با چه معیارهایی اندازه می‌گیریم؟
| معیار | چه چیزی را نشان می‌دهد؟ | محدودیت |
|---|---|---|
| Throughput / TPS | تعداد Transaction پردازش‌شده در بازه زمانی | بدون تعریف Transaction و شرایط تست می‌تواند گمراه‌کننده باشد |
| Latency | زمان مشاهده نتیجه اولیه Transaction | با Finality یکسان نیست |
| Finality | زمان رسیدن به سطح قوی‌تر نهایی‌شدن State | بین Consensusها تعریف متفاوت دارد |
| Fee | هزینه استفاده از ظرفیت شبکه | به Demand، Fee Market و نوع Transaction وابسته است |
| Node Requirements | CPU، RAM، Storage و Bandwidth لازم برای Validation | افزایش شدید منابع می‌تواند تمرکز را بیشتر کند |
| Data Availability | امکان دسترسی مستقل به Data لازم برای Verify کردن State | برای Rollupها بخش مهم Security Model است |
به همین دلیل ادعاهایی مثل «شبکه A سریع‌تر از شبکه B است چون TPS بیشتری دارد» بدون توضیح Finality، Hardware، Batch Size و نوع Transaction مقایسه کاملی نیست.
چرا نباید TPS را با یک عدد ثابت برای همیشه مقایسه کرد؟
ظرفیت Bitcoin به Block Weight، اندازه Transaction و الگوی استفاده از SegWit وابسته است. ظرفیت Ethereum نیز فقط با «Transaction در ثانیه L1» سنجیده نمی‌شود؛ معماری فعلی آن Rollup-centric است و بخش بزرگی از Scaling در L2 انجام می‌شود.
همچنین «Transaction» در یک سیستم پرداخت کارت، Transfer ساده Bitcoin و Smart Contract Call روی Ethereum واحد محاسباتی یکسانی نیست. بنابراین بهتر است به‌جای تکرار اعداد Marketing، Methodology و شرایط Benchmark ذکر شود.
راهکارهای مقیاس‌پذیری Onchain و Offchain چه تفاوتی دارند؟
Onchain / Layer 1 Scaling
تغییراتی که ظرفیت یا کارایی خود Base Layer را افزایش می‌دهند؛ مانند بهینه‌سازی Data Format، Signature Aggregation، Block/Gas Parameters، Parallel Execution یا تغییرات Data Availability در خود Protocol.
Offchain / Layer 2 Scaling
بخشی از Execution یا تعاملات خارج از L1 انجام می‌شود و Settlement/Security به شکلی به Base Layer متصل می‌ماند؛ Rollupها و Payment Channelها نمونه‌های مهم این دسته‌اند.
افزایش Block Size چگونه به Scaling کمک می‌کند؟
بزرگ‌تر کردن Capacity هر Block می‌تواند اجازه دهد Data بیشتری در هر Block ثبت شود، اما این روش Trade-off دارد. Block بزرگ‌تر می‌تواند Bandwidth، Storage و Validation Resource موردنیاز Full Nodeها را افزایش دهد.
بنابراین افزایش Block Size لزوماً «سرعت تأیید Transaction» را مستقیماً بیشتر نمی‌کند و همیشه بهترین راه‌حل نیست. اثر اصلی آن افزایش Capacity هر Block است.
در Bitcoin امروز نیز نباید مسئله را با «افزایش از 1MB به 8MB» توضیح داد؛ پس از SegWit ظرفیت شبکه بر Block Weight استوار است. جزئیات آن در مقاله اندازه بلاک بیت‌کوین چیست؟ توضیح داده شده است.
SegWit چگونه ظرفیت Bitcoin را بهبود داد؟
SegWit ساختار Witness را از Base Transaction Data تفکیک کرد و مفهوم Block Weight را وارد Consensus Bitcoin کرد. این تغییر استفاده کارآمدتری از ظرفیت Block ایجاد کرد بدون اینکه فقط یک عدد ثابت برای Block Size بزرگ‌تر شود. برای بررسی کامل سازوکار آن، مقاله SegWit چیست؟ را مطالعه کنید.
Layer 2 چگونه مقیاس‌پذیری را افزایش می‌دهد؟
Layer 2 با انتقال بخشی از Execution خارج از Base Layer و سپس اتصال Result/Proof/Data لازم به L1، ظرفیت مؤثر سیستم را افزایش می‌دهد.
Ethereum.org نیز Optimistic Rollup، ZK Rollup و State Channel را راهکارهایی می‌داند که Security را از Ethereum می‌گیرند، در حالی که Sidechain و Validium Trust Assumption متفاوتی دارند. راهنمای رسمی Scaling در Ethereum جزئیات معماری Rollup، Sequencer، Data Availability و Sidechain در مقاله لایه دوم بلاکچین چیست؟ توضیح داده شده است.
Lightning Network چگونه Bitcoin را Scale می‌کند؟
Lightning Network از Payment Channelهای متصل به Bitcoin استفاده می‌کند. طرفین می‌توانند تعداد زیادی Update را داخل Channel انجام دهند و فقط Opening/Closing یا Dispute را روی Base Layer ثبت کنند.
مستند Lightning توضیح می‌دهد Payment Channelها Contractهای چندامضایی میان دو Peer هستند و پرداخت‌های داخل Channel می‌توانند در نهایت روی Bitcoin Settlement شوند. مستند رسمی Payment Channels در Lightning
Lightning ظرفیت پرداخت را افزایش می‌دهد، اما محدودیت‌هایی مانند Channel Liquidity، Routing و Online Availability دارد. بنابراین «Offchain = بدون Trade-off» برداشت درستی نیست.
Ethereum در ۲۰۲۶ چگونه مقیاس‌پذیری را افزایش می‌دهد؟
مسیر فعلی Ethereum بر Scaling هم‌زمان L1 و افزایش Data Capacity برای Rollupها تمرکز دارد. EIP-4844 نوع جدیدی از Data به نام Blob ایجاد کرد تا Rollupها بتوانند داده موردنیاز خود را با Fee Market جداگانه و هزینه کمتر نسبت به calldata منتشر کنند.
EIP-4844 این Blob Transactionها را به‌طور رسمی برای افزایش Data Availability و کاهش هزینه Rollupها معرفی کرد. EIP-4844: Shard Blob Transactions
در مرحله بعد، PeerDAS به‌عنوان بخشی از ارتقای Fusaka ظرفیت Data Availability Blobها را تقریباً یک مرتبه بزرگی افزایش داده است؛ بدون اینکه هر Node مجبور باشد همه Blob Data را به‌طور کامل دانلود کند.
Ethereum Foundation نیز در برنامه Protocol برای ۲۰۲۶، Scale L1 و Scale Blobs را همچنان از اولویت‌های اصلی Scaling اعلام کرده است. Protocol Priorities Update for 2026
Data Availability چه ارتباطی با مقیاس‌پذیری دارد؟
Scaling فقط Execution بیشتر نیست. اگر کاربران نتوانند Data لازم برای Verify یا Reconstruct کردن State را به دست آورند، Throughput بالا به‌تنهایی Security مطلوب ایجاد نمی‌کند.
Rollupها برای Permissionless Verification به Data Availability نیاز دارند. Ethereum پس از EIP-4844 از Blobها برای انتشار ارزان‌تر Data رول‌آپ استفاده می‌کند. مستند رسمی Ethereum توضیح می‌دهد دسترسی به این Data برای Challenge یا بازسازی State ضروری است. مستند Data Availability در Ethereum
سه‌گانه بلاکچین یا Blockchain Trilemma چیست؟
Trilemma چارچوبی برای توضیح Trade-off میان: Scalability، Security و Decentralization است.
بهتر است نگوییم «هیچ Blockchainای نمی‌تواند هر سه ویژگی را داشته باشد» یا «بیشتر متخصصان Scalability را بر Security و Decentralization مقدم می‌دانند». چنین ادعاهای مطلقی قابل دفاع نیستند.
مسئله واقعی این است که Design Choiceها می‌توانند هزینه‌هایی برای سایر ویژگی‌ها داشته باشند: Block بزرگ‌تر Node Cost را افزایش می‌دهد؛ Validator Set کوچک‌تر Throughput را ساده‌تر می‌کند اما ممکن است تمرکز بیشتری ایجاد کند؛ L2 ظرفیت را بالا می‌برد ولی Smart Contract/Sequencer/Bridge Risk اضافه می‌کند. برای تفکیک Layer 0 تا Layer 3 و جایگاه Scaling در معماری کلی، مقاله لایه‌های بلاکچین چیست؟ را ببینید.
مهم‌ترین راهکارهای مقیاس‌پذیری بلاکچین
| راهکار | محل اجرا | مزیت | Trade-off |
|---|---|---|---|
| Block/Execution optimization | L1 | Capacity بیشتر در Base Layer | ممکن است Node Requirement افزایش یابد |
| SegWit / Data optimization | L1 | استفاده کارآمدتر از Block Space | محدود به نوع معماری Protocol |
| Rollup | L2 | Batching و Execution خارج از L1 | Sequencer/contract/proof risks |
| Payment Channel | Offchain/L2 | پرداخت‌های متعدد بدون ثبت هر Update روی L1 | Liquidity و routing |
| Data Availability scaling | L1 support for L2 | Data بیشتر برای Rollupها | پیچیدگی Protocol و DA design |
| Sidechain | Chain مستقل | Throughput بالا و Fee کمتر | Security مستقل از L1 |
برای مقایسه مقیاس‌پذیری دو Blockchain چه چیزهایی را بررسی کنیم؟
- Transaction definition: آیا هر دو Benchmark یک نوع Transaction را اندازه گرفته‌اند؟
- Sustained throughput: است یا ظرفیت پایدار؟Peak TPS
- Finality: نتیجه چه زمانی عملاً نهایی محسوب می‌شود؟
- Hardware: اجرای Full Node/Validator چه منابعی می‌خواهد؟
- Validator set: چه تعداد Participant مستقل Consensus را اجرا می‌کنند؟
- Fee under load: هزینه در شرایط شلوغی چگونه تغییر می‌کند؟
- Data availability: داده لازم برای Verify کردن State کجا قرار دارد؟
- Security assumptions: آیا Bridge، Sequencer یا Operator مورد اعتماد اضافه شده است؟
جمع‌بندی؛ Scalability فقط افزایش TPS نیست
مقیاس‌پذیری Blockchain مسئله افزایش ظرفیت در کنار حفظ Security، Decentralization و امکان Verification مستقل است. به همین دلیل نمی‌توان یک شبکه را فقط با عدد TPS «مقیاس‌پذیرتر» دانست.
راهکارها از بهینه‌سازی L1 و Block Space تا Rollup، Payment Channel، Data Availability scaling و معماری‌های چندلایه گسترده‌اند. هر روش Trade-off مخصوص خود را دارد و ارزیابی درست باید Performance را همراه با Node Cost، Finality و Security Assumptions بررسی کند.
مقالات مرتبط
سوالات متداول
آیا TPS بیشتر همیشه بهتر است؟
آیا TPS بیشتر همیشه بهتر است؟
خیر. باید Finality، Node Requirements، Validator decentralization، Fee، Security و نوع Transaction نیز مقایسه شوند.
آیا بزرگ‌تر کردن Block مشکل Scalability را حل می‌کند؟
آیا بزرگ‌تر کردن Block مشکل Scalability را حل می‌کند؟
ظرفیت بیشتری ایجاد می‌کند، اما می‌تواند Bandwidth، Storage و Node Cost را افزایش دهد و مسئله را به‌طور کامل حل نمی‌کند.
Layer 2 چه کاری انجام می‌دهد؟
Layer 2 چه کاری انجام می‌دهد؟
بخشی از Execution را خارج از Base Layer انجام می‌دهد و سپس Result، Proof یا Data لازم را برای Settlement/Security به L1 متصل می‌کند.
آیا Sidechain همان Layer 2 است؟
آیا Sidechain همان Layer 2 است؟
نه در تعریف سخت‌گیرانه. Sidechain Consensus و Security مستقل دارد، در حالی که L2 Security/Settlement خود را از L1 می‌گیرد.
Lightning Network چه مشکلی را حل می‌کند؟
Lightning Network چه مشکلی را حل می‌کند؟
تعداد زیادی پرداخت Bitcoin را داخل Payment Channel انجام می‌دهد تا لازم نباشد هر Update به‌صورت یک Transaction مستقل روی Base Layer ثبت شود.
چرا Data Availability در Scaling مهم است؟
چرا Data Availability در Scaling مهم است؟
چون Verifier مستقل باید بتواند Data لازم برای بازسازی یا Challenge کردن State را دریافت کند؛ Throughput بالا بدون Data قابل دسترس Security کامل ایجاد نمی‌کند.
