یک pool استخراج بیت‌کوین واقعاً چگونه کار می‌کند: از share تا payout

توضیح استاندارد این‌طور است: ماینرها hashrate خود را با هم ترکیب می‌کنند، یک block را با هم پیدا می‌کنند، و reward را تقسیم می‌کنند. چیزی در این جمله نادرست نیست، اما هیچ نتیجه مفیدی هم از آن به دست نمی‌آید. این توضیح نمی‌گوید چرا در روزهایی که pool هیچ block ای پیدا نمی‌کند باز هم پرداخت می‌گیری. توضیح نمی‌دهد چرا dashboard hashrate ای متفاوت از دستگاه تو نشان می‌دهد. توضیح نمی‌دهد luck 78% از کجا می‌آید، یا چرا این عدد گاهی هیچ ربطی به wallet تو ندارد.

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

POOL BTC یک pool نیست. ما شرایط سایر اپراتورها را مقایسه می‌کنیم و محاسبه می‌کنیم چه هزینه‌ای برای ماینر دارند، پس در اینجا نه اپراتوری فروخته می‌شود و نه اپراتوری متهم می‌شود. فقط مکانیزم، و محاسباتی که خودت می‌توانی دوباره انجام دهی.

شش چیزی که اهمیت دارد

1. یک share و یک block یک شیء یکسان هستند. فقط ارتفاع بار متفاوت است.
2. pool یک بار شخصی و آسان به تو اختصاص می‌دهد تا بتواند کار تو را هر چند ثانیه یک‌بار ببیند، نه یک‌بار در قرن.
3. pool است که block را می‌سازد، نه تو. سخت‌افزار تو اعدادی را درون یک header که از قبل کامل رسیده تکرار می‌کند.
4. یک payout scheme قانونی است درباره اینکه چه کسی ریسک بدشانسی را متحمل می‌شود: تو یا اپراتور.
5. fee از reward ناخالص کسر می‌شود، پس در مقادیر مطلق با قیمت و با hashrate تو مقیاس می‌گیرد.
6. luck یک آمار است، نه رفتار اپراتور. در FPPS اصلاً به payout تو دست نمی‌زند.

share چیست، و چه فرقی با یک block معتبر دارد؟

یک share یک header از block است که hash آن پایین‌تر از یک target آسان قرار گرفته که pool مخصوص تو تعیین کرده است. یک block همان header است که hash آن پایین‌تر از target کل شبکه قرار گرفته است. فقط ارتفاع بار متفاوت است: کار، فرمت داده، و اعتبارسنجی یکسان هستند. هر share ای که تصادفاً target شبکه را هم رد کند، به‌طور خودکار به یک block معتبر تبدیل می‌شود.

header یک block بیت‌کوین 80 بایت است و شش فیلد دارد: version، previous block hash، Merkle root، timestamp، nBits، و nonce. nBits یک کدگذاری فشرده از target فعلی شبکه است، و به یک عدد 256 بیتی باز می‌شود که double SHA-256 آن header باید پایین‌تر از آن باشد.

ASIC تو آن header را می‌گیرد و آنچه را که مجاز به تغییر است تغییر می‌دهد: nonce (4 بایت)، extranonce2 (طول آن را pool در زمان اتصال تعیین می‌کند، و از طریق تراکنش coinbase وارد Merkle root می‌شود) و، اگر هم pool و هم firmware از version rolling پشتیبانی کنند، چند بیت از فیلد version. هر header کاندیدا دو بار hash می‌شود و با target مقایسه می‌شود.

pool در هر submission دو target را بررسی می‌کند. share ورودی با target شخصی تو مقایسه می‌شود (اگر رد شود: به حساب تو شمارش می‌شود) و با target شبکه (اگر آن هم رد شود: pool بلافاصله یک block منتشر می‌کند). هیچ عمل جداگانه‌ای برای "جستجوی block" وجود ندارد. block محصول جانبی جریان معمولی share هاست.

یک نتیجه غیربدیهی: pool نمی‌تواند بدون کنار گذاشتن خود share ای که پیدا کرده، آن block را پنهان کند. تراکنش coinbase در template آن آدرس‌ها و tag خود pool را حمل می‌کند، و هر block ای که از آن template ساخته شود با همان نشانه در explorer ها ظاهر می‌شود. روش عملی بررسی این موضوع در مقاله ما درباره تأیید اینکه یک pool منصفانه پرداخت می‌کند آمده است.

طبق محاسبه POOL BTC، در difficulty شبکه 127,450,789,715,843 و difficulty share 65,536، یک block به‌طور میانگین حدود 1.94 میلیارد share نیاز دارد. این یک تخمین سرانگشتی نیست بلکه یک تقسیم ساده است: difficulty شبکه تقسیم بر difficulty share، چون هر دو در واحد یکسانی از expected work بیان شده‌اند.

difficulty share چیست، و چرا pool آن را با دستگاه (vardiff) تنظیم می‌کند؟

difficulty share یک ضریب است که نشان می‌دهد target اختصاص‌یافته به تو چقدر آسان‌تر از base target بیت‌کوین است. در difficulty 1، یک share به‌طور میانگین 2^32 hash نیاز دارد، تقریباً 4.295 میلیارد. در difficulty 65,536، به‌اندازه 65,536 برابر آن نیاز دارد. pool این عدد را تغییر می‌دهد تا جریان submission های تو راحت برای حسابرسی باقی بماند.

مکانیزم تنظیم این عدد vardiff نامیده می‌شود، مخفف variable difficulty. pool کنترل می‌کند که چند وقت یک‌بار submission می‌فرستی و difficulty تو را بالا یا پایین می‌برد، با هدف یک بازه راحت بین share ها. اگر خیلی پایین تنظیم شود، یک farm بزرگ سرور را با ترافیک غرق می‌کند. اگر خیلی بالا تنظیم شود، آمار یک دستگاه کوچک پر نویز می‌شود: اگر یک share هر دو دقیقه یک‌بار ارسال شود، نمودار hashrate ساعتی فقط به‌خاطر تصادفی بودن، ده‌ها درصد نوسان می‌کند.

طبق محاسبه POOL BTC، یک دستگاه 100 TH/s در difficulty share 65,536 حدود 21.3 share در دقیقه می‌فرستد، تقریباً هر 2.8 ثانیه یک‌بار. محاسبه: 100 TH/s برابر 10^14 hash در ثانیه است، تقسیم بر 65,536 × 2^32 = 2.815 × 10^14 expected hash در هر share، که 0.355 share در ثانیه به دست می‌دهد.

همان دستگاه در difficulty share های مختلف:

و در difficulty ثابت 65,536، در hashrate های مختلف:

نکته‌ای که ارزش یادآوری دارد: difficulty share روی درآمد تو تأثیر نمی‌گذارد. آنچه تغییر می‌کند سرعت همگرایی تخمین pool به hashrate واقعی دستگاه توست. difficulty را دوبرابر کن، آن‌وقت نصف تعداد share با وزن دوبرابر می‌فرستی. حاصل تغییر نمی‌کند.

چه کسی block template را می‌سازد، و درون یک block چه چیزی هست؟

در Stratum V1 کلاسیک، pool کل template را می‌سازد. pool node بیت‌کوین خودش را اجرا می‌کند، تراکنش‌ها را از mempool انتخاب می‌کند، یک تراکنش coinbase می‌سازد که به آدرس‌های خودش پرداخت می‌کند، و Merkle tree را محاسبه می‌کند. آنچه به miner می‌رسد فهرست تراکنش‌ها نیست بلکه مجموعه‌ای از Merkle branch به‌علاوه دو نیمه coinbase است. miner از نظر فیزیکی نمی‌تواند تراکنشی را انتخاب یا رد کند.

پیام mining.notify که کار را توزیع می‌کند شامل job id، previous block hash، هر دو نیمه تراکنش coinbase، فهرست Merkle branch، version، nBits، time، و یک flag به نام clean_jobs است. miner extranonce2 خود را بین دو نیمه coinbase قرار می‌دهد، Merkle root را از branch ها دوباره محاسبه می‌کند، و header را می‌سازد.

همان flag به نام clean_jobs نیمی از آنچه در لاگ های miner عجیب به نظر می‌رسد را توضیح می‌دهد. وقتی یک block جدید در شبکه ظاهر می‌شود، pool یک job تازه با clean_jobs برابر true ارسال می‌کند، و از همان لحظه تمام کاری که روی job قبلی انجام شده بی‌ارزش می‌شود. share هایی که بعد از آن روی job قدیمی ارسال شوند، به‌عنوان stale رد می‌شوند.

درون یک block واقعاً چه چیزی هست: تراکنش coinbase (subsidy به‌علاوه مجموع fee همه تراکنش‌های موجود، با subsidy برابر 3.125 BTC از تاریخ 24.09.2026) و مجموعه‌ای از تراکنش‌های mempool، معمولاً مرتب‌شده بر اساس fee per virtual byte. سهم fee از کل block reward در حال حاضر کوچک است. طبق mempool.space در تاریخ 08.09.2026 این عدد در 4,320 block اخیر 0.66% و در 144 block اخیر 0.57% بود، و در طول ماه این عدد بین 0.66% و 0.73% باقی ماند. سایر aggregator ها که پنجره یک‌روزه را بررسی می‌کنند 0.40% تا 0.56% گزارش می‌دهند، چون از مخرج کسر متفاوتی استفاده می‌کنند. اینجا هیچ عدد صحیح واحدی وجود ندارد، فقط عددی با یک بازه زمانی و منبع مشخص.

تنها بخشی از پروتکل که ساخت template را از pool می‌گیرد Job Declaration است، بخشی از Stratum V2. این در حال حاضر روی تعداد انگشت‌شماری pool در production اجرا می‌شود، و نباید با اعلام یک pool که می‌گوید "از Stratum V2 پشتیبانی می‌کند" اشتباه گرفته شود. سه عدد جداگانه پذیرش پشت این اعلامیه‌ها در مقاله ما درباره Stratum V2 و اینکه چه کسی تراکنش‌ها را انتخاب می‌کند باز شده است.

pool چگونه سهم یک miner را اندازه‌گیری می‌کند و آن را به payout تبدیل می‌کند؟

pool یک لاگ از share های پذیرفته‌شده به همراه وزن آن‌ها نگه می‌دارد که به worker تو مرتبط است. در زمان settlement (پایان دوره روزانه برای خانواده PPS، لحظه پیدا شدن یک block برای PPLNS) pool سهم تو را بر اساس فرمول خودش محاسبه می‌کند، fee را کسر می‌کند، به یک balance داخلی اعتبار می‌دهد، و به‌محض اینکه آن balance از payout threshold عبور کند یک تراکنش می‌فرستد.

مسیر کامل یک share، از ASIC تا سکه‌ها در wallet تو:

1. pool پیام mining.notify را همراه با یک job و difficulty فعلی worker تو ارسال می‌کند.
2. ASIC، nonce، extranonce2، و version bits را تکرار می‌کند تا double SHA-256 آن header پایین‌تر از target تو قرار گیرد.
3. ASIC پیام mining.submit را می‌فرستد: job id، extranonce2، time، nonce.
4. pool بررسی می‌کند که آیا job معتبر است، آیا share تکراری نیست، و آیا hash واقعاً پایین‌تر از target توست. در همان زمان آن را با target شبکه هم مقایسه می‌کند.
5. share پذیرفته‌شده با وزنی برابر difficulty آن وارد لاگ می‌شود.
6. pool سهم تو را اعتبار می‌دهد: یا یک نرخ ثابت به‌ازای هر share یا برشی از reward یک block پیدا شده، بسته به scheme.
7. fee pool از آن اعتبار کسر می‌شود، که بر اساس مقدار ناخالص محاسبه می‌شود.
8. آنچه باقی می‌ماند روی balance داخلی می‌نشیند، که معمولاً در dashboard به‌صورت "unpaid" نشان داده می‌شود.
9. به‌محض اینکه balance از threshold عبور کند، pool یک تراکنش می‌سازد، network fee را طبق سیاست خودش کسر می‌کند، و آن را به آدرس تو می‌فرستد.
10. بعد از confirmations، آن مقدار سرانجام مال توست. تا پیش از آن لحظه، این یک بدهی اپراتور است، نه پول تو.

مرحله نه و ده ارزش یک مکث دارند. بین "اعتبار داده شد" و "رسید" یک payout threshold قرار دارد، و در hashrate پایین، آن threshold به یک دوره انتظار تبدیل می‌شود.

طبق محاسبه POOL BTC، یک دستگاه 100 TH/s در hashrate شبکه 930.73 EH/s و subsidy برابر 3.125 BTC روزانه 0.00004835 BTC به‌صورت gross subsidy کسب می‌کند (پارامترهای شبکه: mempool.space، snapshot 08.09.2026). با افزودن سهم fee برابر 0.66%، این عدد به 0.00004867 BTC می‌رسد، و بعد از pool fee برابر 2%، روزانه 0.0000477 BTC باقی می‌ماند. در برابر threshold برابر 0.001 BTC که توسط F2Pool، AntPool، و Luxor منتشر شده، اولین payout حدود روز 21 ام اجرای بدون وقفه می‌رسد. در برابر threshold Ocean، که در منابع ثانویه 0.01048576 BTC ذکر شده، انتظار حدود 220 روز خواهد بود.

این طعنه‌ای به Ocean نیست، که همچنین از طریق Lightning بدون threshold پرداخت می‌کند. این نشان می‌دهد که یک payout threshold برای یک دستگاه تک یک معنا دارد و برای یک farm 10 PH/s معنایی کاملاً متفاوت. می‌توانی threshold را با hashrate خودت تطبیق دهی و فاصله بین payout ها را در ماشین‌حساب POOL BTC محاسبه کنی.

PPS، FPPS، PPLNS، و SOLO از نظر مکانیزم چه فرقی با هم دارند، نه از نظر بازاریابی؟

یک payout scheme دقیقاً به یک سؤال پاسخ می‌دهد: چه کسی ریسک دیرتر رسیدن block از حد انتظار را متحمل می‌شود. در PPS و FPPS، اپراتور آن ریسک را می‌گیرد و قابل پیش‌بینی بودن را با fee بالاتر به تو می‌فروشد. در PPLNS و TIDES، ریسک نزد ماینرها می‌ماند و در یک بازه از share ها پخش می‌شود. در SOLO، ریسک به‌طور کامل مال توست، بدون هیچ‌گونه میانگین‌گیری.

تفاوت مکانیزم در دو جا خودش را نشان می‌دهد. اول، در FPPS نرخ هر share از قبل مشخص است، پس اعتبار روزانه در hashrate ثابت باید صاف باشد، و هر پرش در آن نمودار یا تغییر network difficulty است یا یک مشکل از سمت توست. دوم، یک window در PPLNS بر حسب واحد کار تعریف می‌شود نه زمان، پس با بالا رفتن network difficulty، آن window خودش به‌خودی به‌لحاظ ساعت کوچک‌تر می‌شود.

اینکه اپراتورها واقعاً window های خود را چطور توصیف می‌کنند، بیشتر از آنچه فکر می‌کنی متفاوت است. ViaBTC رسماً می‌گوید "5 دور difficulty اخیر." Ocean window خود را به‌صورت هشت برابر difficulty block در share مستند می‌کند. AntPool و F2Pool از عبارت "N دور difficulty اخیر" بدون انتشار مقدار N استفاده می‌کنند. Braiins از دسامبر 2023 BTC را فقط روی FPPS اجرا کرده و اصلاً هیچ scheme به سبک PPLNS ارائه نمی‌دهد.

فرمول‌های هر scheme، به‌همراه اینکه هنگام ترک یک pool چه اتفاقی برای share های تو می‌افتد، در مقاله اختصاصی ما درباره payout scheme ها پوشش داده شده است. تقسیم ریسک بالا همان بخشی است که اینجا اهمیت دارد.

pool fee از کجا می‌آید و چه چیزی را پوشش می‌دهد؟

pool fee درصدی است که اپراتور پیش از توزیع از reward ناخالص کسر می‌کند. این fee هزینه node های بیت‌کوین و سرورهای stratum در چند منطقه، یک تیم on call، ریسک variance که اپراتور در scheme های PPS متحمل می‌شود، و زیرساخت settlement را پوشش می‌دهد. نرخ‌ها در pool های بزرگ بین 1% و 4% است، و مقایسه مستقیم آن‌ها بین scheme های مختلف کار نمی‌کند.

جزئیاتی که اغلب نادیده گرفته می‌شود: fee از اعتبار ناخالص کسر می‌شود، نه از سود و نه از باقیمانده بعد از برق. پس همان درصد در قیمت‌ها و hashrate های مختلف به پول مطلق متفاوتی تبدیل می‌شود، و این دلیل دیگری است که چرا scheme های PPS هزینه بیشتری می‌گیرند. در آن درصد، قیمت تضمین اپراتور برای payout تو در یک هفته بد نهفته است.

آنچه درباره pool های خاص تا این snapshot تأیید شده است:

طبق محاسبه POOL BTC، فاصله بین fee برابر 2% و 4% روی یک دستگاه 100 TH/s، روزانه 0.00000097 BTC است، تقریباً 0.000355 BTC در سال. این عدد بی‌اهمیت به نظر می‌رسد تا زمانی که آن را در تعداد دستگاه‌ها ضرب کنی: در یک farm با 100 ASIC یکسان، همان دو واحد درصد به 0.0355 BTC در سال می‌رسد.

اینکه چرا رتبه‌بندی pool ها بر اساس یک درصد تنها همچنان نادرست است، در مقاله ما درباره fee و امتیاز چهار عاملی pool بررسی شده است: payout threshold، سیاست network fee، و اسپرد auto conversion بیشتر از خود درصد، فاصله درصدی را شکست می‌دهند.

luck و variance چیستند، و چرا یک pool می‌تواند در طول یک هفته از انتظار عقب بماند؟

luck نسبت هزینه share مورد انتظار به share هایی است که واقعاً برای block های پیدا شده صرف شده‌اند، که به‌صورت درصد نشان داده می‌شود. مقدار 78% یعنی آن block ها کار بیشتری از حد انتظار pool هزینه کرده‌اند، و 130% یعنی کمتر. variance پراکندگی آماری‌ای است که luck از آن بیرون می‌آید. پیدا کردن block یک فرایند Poisson است، پس انحراف اجتناب‌ناپذیر است و فقط با بزرگ‌تر شدن نمونه کوچک می‌شود.

یک ویژگی مفید توزیع Poisson: انحراف معیار برابر ریشه دوم مقدار مورد انتظار است. بنابراین پراکندگی نسبی با ریشه دوم تعداد block ها کاهش می‌یابد، نه به‌نسبت hashrate.

طبق محاسبه POOL BTC، در hashrate شبکه 930.73 EH/s و 1,008 block در هفته:

ردیف بالا همان دستگاه 100 TH/s است که به‌صورت solo استخراج می‌کند: زمان مورد انتظار برای رسیدن به یک block در difficulty برابر 127.45 تریلیون حدود 173 سال است، و احتمال پیدا کردن یکی در یک هفته مشخص تقریباً 0.011% است.

ردیف پایین متعلق به Foundry USA است. طبق جدول ChainBulletin برای 08.09.2026 (بازنشر شده در نوشته 10.09.2026 در KuCoin) این pool حدود 244.6 EH/s در اختیار دارد، حدود 27% از شبکه، در حالی که AntPool نزدیک به 156 EH/s و F2Pool نزدیک به 127 EH/s دارند. ضریب Nakamoto، یعنی تعداد pool هایی که بیش از نیمی از همه block ها را تولید می‌کنند، طبق گزارش D-Central برای نیمه اول 2026 برابر 3 است.

دو نتیجه از آن جدول به دست می‌آید. یک pool کاملاً صادق با hashrate برابر 10 EH/s و بدون هیچ حادثه‌ای، تقریباً یک هفته از هر سه هفته زیر 70% یا بالای 130% luck خواهد بود، و این رفتار عادی برای یک متغیر تصادفی است. در همان حال، اگر روی FPPS باشی، هیچ‌کدام از این ردیف برای تو صدق نمی‌کند، چون تو صرف نظر از اینکه pool یک block پیدا کند یا نه، با یک نرخ به‌ازای هر share پرداخت می‌گیری. luck در FPPS معیار اپراتور است، نه معیار تو.

عکس این هم درست است. یک هفته luck به‌تنهایی در هیچ جهتی چیزی را ثابت نمی‌کند. یک نمونه معنادار برای بحث درباره صداقت یک pool مبتنی بر PPLNS از یک فصل شروع می‌شود.

وقتی قطع می‌شوی چه اتفاقی می‌افتد: stale share، reject rate، failover؟

وقتی اتصال قطع می‌شود، ASIC همچنان روی آخرین job دریافتی hash می‌زند، اما جایی برای فرستادن نتایج وجود ندارد، پس آن کار از دست می‌رود. به‌محض بازگشت اتصال، share های مربوط به job منسوخ به‌عنوان stale رد می‌شوند. balance جمع‌شده تو دست‌نخورده می‌ماند: در حساب می‌ماند و منتظر payout threshold است. آنچه از دست می‌رود کار جاری است، به‌علاوه جایگاه تو در window اگر روی PPLNS باشی.

دلایل رد کردن یک share توسط pool معناهای متفاوتی دارند و ارزش دارد در لاگ‌های تو از هم جدا شوند:

1. Stale، یا job not found: share روی یک job رسیده که دیگر معتبر نیست. معمولاً به‌خاطر شبکه، latency، یا یک block جدید در شبکه.
2. Low difficulty share: hash به target فعلی تو نرسیده. اغلب به‌خاطر desync درست بعد از یک تغییر vardiff.
3. Duplicate share: همان ترکیب nonce و extranonce2 دوبار ارسال شده. نشانه‌ای از مشکل firmware یا خرابی controller.
4. Above target: header کاملاً در اعتبارسنجی رد می‌شود. معمولاً به‌خاطر سخت‌افزاری که در overclock یا دما بیش از حد فشار داده شده.

هر اپراتور استاندارد نرمال خودش را برای reject تعیین می‌کند، و هیچ آستانه صنعتی‌ای وجود ندارد. AntPool زیر 1% را نرمال می‌داند و جداگانه میانگین stale rate برابر 0.5% یا کمتر را ذکر می‌کند. ViaBTC می‌گوید تا 3% قابل قبول است. F2Pool حدود 2% را یک delayed share rate معقول می‌داند. Braiins و Luxor هیچ آستانه عددی منتشر نمی‌کنند.

طبق محاسبه POOL BTC، هر 2 واحد درصد reject rate دقیقاً همان هزینه‌ای را دارد که 2 واحد درصد pool fee دارد، چون هر دو از اعتبار ناخالص کسر می‌شوند. برای یک دستگاه 100 TH/s این معادل همان 0.000355 BTC در سال است. یک pool با reject rate برابر 2% اما مسیر بد به سرور خود، در برابر یک pool با reject rate برابر 3% اما اتصال پایدار می‌بازد.

همین باعث می‌شود failover کمتر از آنچه به نظر می‌رسد اختیاری باشد. تنظیمات stratum یک ASIC چند آدرس pool می‌پذیرد، و firmware وقتی pool اصلی قطع شود به آدرس بعدی می‌رود. همه slot های موجود را پر کن، و حداقل یک backup روی یک اپراتور متفاوت یا حداقل در یک منطقه متفاوت نگه دار، وگرنه هر دو ممکن است در یک لحظه از کار بیفتند. firmware استاندارد Antminer سه slot دارد (Pool 1، 2، و 3، طبق پشتیبانی Bitmain)، و Whatsminer هم همان سه slot را دارد.

یک جزئیات مخصوص PPLNS: ترک کردن یک pool share های تو را به‌عنوان جریمه نمی‌سوزاند. آن‌ها فقط با رسیدن کار جدید از window بیرون می‌روند. Ocean این را صراحتاً مستند کرده و می‌گوید share ها هرگز از share log حذف نمی‌شوند و فقط زمانی که حجم کار آن‌ها را از مرز window عبور دهد، شمارش شدن را متوقف می‌کنند. اثر عملی همان است، اما عبارت "pool share های تو را نگه می‌دارد" توصیف نادرستی است.

یک pool چه فرقی با hosting و با cloud mining دارد؟

pool هماهنگی کار است: سخت‌افزار مال توست، هرجا که نگهش می‌داری، و pool job ها را توزیع می‌کند و برای share های پذیرفته‌شده پرداخت می‌کند. hosting یک سایت است: سخت‌افزار همچنان مال توست، اما برق، خنک‌سازی، و اتصال متعلق به شخص دیگری است، و تو همچنان خودت pool را انتخاب می‌کنی. cloud mining یک قرارداد است: تو اصلاً هیچ سخت‌افزاری نداری، فقط وعده یک طرف مقابل برای پرداخت یک جریان درآمد به تو.

hosting به‌علاوه pool یک ترتیب عادی است، و این دو با هم رقابت نمی‌کنند. cloud mining جدا می‌ایستد چون تنها پیوند قابل‌تأیید در کل زنجیره را حذف می‌کند: تناظر بین سخت‌افزار تو، share های تو، و سکه‌ها در blockchain. با یک pool و با hosting، آن پیوند باقی می‌ماند، و تو می‌توانی خودت دوباره آن را محاسبه کنی.

چگونگی خواندن شرایط pool هنگام انتخاب، و اینکه علاوه بر درصد به چه چیزهایی باید نگاه کرد، در مقایسه 12 pool ما پوشش داده شده است.

سؤالات متداول درباره مکانیزم pool mining

آیا یک pool می‌تواند یک block پیدا شده را بدزدد و چیزی نگوید؟

یک block ساخته‌شده از template یک pool یک تراکنش coinbase با آدرس‌ها و tag همان pool را حمل می‌کند، و در هر explorer ای ظاهر می‌شود. پنهان کردن آن ممکن نیست. آنچه واقعاً از بیرون قابل بررسی نیست، حسابداری داخلی است: سهم یک ماینر خاص در یک window PPLNS و hashrate واقعی pool، همچنان گزارش خود آن باقی می‌ماند.

آیا difficulty share روی درآمد من تأثیر می‌گذارد؟

نه. difficulty share فقط فرکانس و وزن submission ها را تغییر می‌دهد، و حاصل ثابت می‌ماند. difficulty را دوبرابر کن، آن‌وقت نصف تعداد share می‌فرستی، که هرکدام دو برابر ارزش دارند. این واقعاً روی دقت آماری تأثیر می‌گذارد: difficulty بیش از حد بالا نمودار hashrate یک دستگاه کوچک را پرنویز می‌کند.

چرا dashboard pool کمتر از ASIC من hashrate نشان می‌دهد؟

دستگاه تو سرعت hash لحظه‌ای را گزارش می‌دهد، درحالی‌که pool hashrate تو را بعداً، از share های پذیرفته‌شده در طول یک window میانگین، تخمین می‌زند. این دو از نظر ساختاری نمی‌توانند مطابقت داشته باشند. share های رد شده و stale این فاصله را بیشتر می‌کنند، و همچنین latency تا سرور stratum. یک عدد روزانه را با یک عدد روزانه مقایسه کن.

اگر پیش از پیدا کردن block توسط pool آن را ترک کنم، چه اتفاقی برای share های من می‌افتد؟

در PPS و FPPS، هیچ‌چیز: به تو برای هر share پذیرفته‌شده یک نرخ اعتبار داده شده و آن قبلاً روی balance توست. در PPLNS، share های تو در window می‌مانند و در block هایی که بعد از ترک تو پیدا می‌شوند شرکت می‌کنند، تا زمانی که کار جدید آن‌ها را از مرز عبور دهد. balance جمع‌شده نمی‌سوزد، منتظر threshold می‌ماند.

چرا pool به hashrate من نیاز دارد وقتی بابت share پرداخت می‌کند؟

pool hashrate تو را مستقیماً نمی‌داند. pool آن را از جریان share به دست می‌آورد: share های پذیرفته‌شده ضربدر difficulty آن‌ها، تقسیم بر طول window. این یک تخمین است نه یک اندازه‌گیری، و دقیقاً به همین دلیل است که یک نمودار پنج‌دقیقه‌ای بالا و پایین می‌پرد درحالی‌که نمودار روزانه صاف به نظر می‌رسد.

چه چیزی در داده‌های ما تا 24.09.2026 هنوز تأیید نشده است

1. درصدهای fee در Luxor و Foundry USA. هیچ‌کدام یک عدد واحد منتشر نمی‌کنند: Luxor fee خود را تخفیف نسبت به spot FPPS می‌نامد، Foundry بر اساس tier hashrate قیمت‌گذاری می‌کند.
2. payout threshold مربوط به EMCD: مقالات help center ای که باید آن را ذکر می‌کردند در تاریخ 24.09.2026 خطای 404 برمی‌گرداندند.
3. عدد 3% مربوط به Kryptex از بررسی دستی ما در تاریخ 29.08.2026 به دست آمده؛ در تاریخ 24.09.2026 آن درصد در متن صفحات fee عمومی آن ظاهر نمی‌شد.
4. پارامترهای شبکه در محاسبات بالا snapshot ای از 08.09.2026 هستند (hashrate برابر 930.73 EH/s، difficulty برابر 127,450,789,715,843، mempool.space). در 24.09.2026، همان API عدد 917.89 EH/s و difficulty برابر 132,757,073,449,487 را نشان می‌داد، پس یک دستگاه 100 TH/s اکنون روزانه حدود 4% subsidy کمتری نسبت به مثال‌های بالا کسب می‌کند. retarget بعدی در block 969,696 حدود منفی 5.5% تخمین زده شده بود.
5. مقادیر difficulty share در جدول‌های بالا توان‌های دوم رند هستند، که برای خوانا بودن محاسبات انتخاب شده‌اند. F2Pool، AntPool، و Braiins difficulty share پیش‌فرض یا حداقل خود را منتشر نمی‌کنند. ViaBTC مکانیزم را منتشر می‌کند نه یک عدد: پارامتر d= در رمز عبور worker difficulty آغازین را تعیین می‌کند و md= کف آن را تعیین می‌کند.

خلاصه

یک share یک block با یک بار پایین‌آورده‌شده است، نه بیشتر. pool ارتفاع آن بار را متناسب با دستگاه تو انتخاب می‌کند، تا بتواند کار تو را در زمان واقعی ببیند، و این تنظیم به درآمد تو دست نمی‌زند.

pool است که block را می‌سازد، نه تو. در Stratum V1، miner فقط Merkle branch و یک coinbase stub دریافت می‌کند، هرگز فهرست تراکنش را نه. این فقط زیر Job Declaration تغییر می‌کند، و فقط تعداد انگشت‌شماری pool آن را در production اجرا می‌کنند.

یک payout scheme به یک سؤال پاسخ می‌دهد: ریسک مال کیست. PPS و FPPS قابل پیش‌بینی بودن را از طریق درصد به تو می‌فروشند، PPLNS پراکندگی را نزد ماینرها می‌گذارد، SOLO هیچ‌چیز را میانگین نمی‌گیرد. luck معیار pool است، و در FPPS هرگز به payout تو نمی‌رسد.

reject rate دقیقاً همان هزینه‌ای را دارد که fee دارد، چون هر دو از اعتبار ناخالص کسر می‌شوند. دو واحد درصد از دست‌رفته به‌خاطر کیفیت اتصال، همان مقداری را هزینه می‌کند که دو واحد درصد تعرفه هزینه می‌کند، و به همین دلیل یک pool با اتصال خوب در نرخ بالاتر اغلب از یک pool ارزان‌تر اما دور برنده می‌شود.

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