Майнинг қиындығы өссе не болады: 5%, 10% және 20% сценарийлері

Bitcoin майнингіне арналған кіріс моделіндегі ең қауіпті қате — бүгінгі бір TH/s түсімін бүкіл иелену мерзіміне өзгеріссіз көшіру. Желі қиындығы артса, сіздің хэшрейтіңіз өзгермесе де, сол хэшрейтке тиесілі күтілетін BTC үлесі азаяды. Сондықтан 5%, 10% және 20% сценарийлері баға болжамы емес, жабдықтың төзімділігін тексеретін stress-test болуы керек.

Дерек 2026-08-09 күні тексерілді. Бұл материал табысқа кепілдік бермейді; нақты шешім алдында difficulty, pool есебі, электр шоты және құрылғы телеметриясын қайта алыңыз.

Мазмұны

Қиындық нені өзгертеді
Бастапқы деректерді қатырыңыз
5%, 10% және 20% сценарийлері
Екі өлшемді матрица
Тоқтату және қайта қарау шектері
Практикалық жаңарту тәртібі
Difficulty, network hashrate және hashprice-ты араластырмау
Жиі қойылатын сұрақтар

Қиындық нені өзгертеді

Bitcoin хаттамасында difficulty блок табу мақсатын реттейді. Бірдей хэшрейтпен жұмыс істейтін ASIC үшін басқа шарттар тұрақты болса, күтілетін өндіріс difficulty-ге кері пропорционал. Қарапайым сценарийлік формула:

жаңа тәуліктік BTC = базалық тәуліктік BTC × базалық difficulty / жаңа difficulty

Егер өсімді пайызбен енгізсеңіз: жаңа BTC = базалық BTC / (1 + өсім). Мысалы, 10% өсім кезінде коэффициент 1/1,10 болады. Бұл дәл болжау емес: транзакциялық алым, pool luck, төлем әдісі және құрылғының нақты uptime көрсеткіші нәтижені ауытқытады.

Бастапқы деректерді қатырыңыз

Бір күндік ең жақсы нәтижені база етпеңіз. Соңғы толық difficulty кезеңіндегі pool-дан түскен BTC, орташа нақты хэшрейт, rejected share, жұмыс сағаты және қабырғадағы kWh көрсеткішін алыңыз. База мерзімінің басы мен соңын жазыңыз. Pool валюталық эквивалент көрсетсе, BTC мөлшерін бөлек сақтаңыз: difficulty әсерін BTC өндірісінен, нарық бағасының әсерін KZT кірісінен бөлек көру керек.

Кестеде кемінде мына жолдар болсын: базалық тәуліктік BTC; +5%, +10%, +20% difficulty; BTC/KZT бағасының төмен, орта және жоғары мәні; электр және міндетті төлем; pool комиссиясы; uptime; жөндеу резерві. Бір жолдағы optimistic BTC бағасын басқа жолдағы conservative difficulty-мен араластырмаңыз.

5%, 10% және 20% сценарийлері

5% сценарийі қысқа мерзімді маржаның қаншалық жұқа екенін көрсетеді. Егер осындай шағын өзгерістің өзі операциялық ақша ағынын теріс етсе, жоба электр бағасына немесе uptime-ға тым тәуелді. 10% сценарийі сатып алу алдындағы негізгі кедергі болуы мүмкін: бұл жағдайда айлық таза ақша, жөндеуден кейінгі резерв және қарыз төлемі қатар тексеріледі. 20% сценарийі «міндетті түрде болады» деген болжам емес; ол жабдықтың тиімсіздену және ерте тоқтау тәуекелін ашады.

Әр сценарийде BTC өндірісін қайта есептеген соң ғана оны бағаға көбейтіңіз. Одан pool комиссиясын, электрді, салқындатуды, hosting немесе орын шығынын, жөндеу резервін алып тастаңыз. Амортизацияны басқарушылық пайдада бөлек көрсетіңіз, өйткені ол ағымдағы айдағы cash outflow емес.

Екі өлшемді матрица

Difficulty жеке қозғалмайды. 3×3 матрица жасаңыз: баға −20%, өзгеріссіз, +20%; difficulty +5%, +10%, +20%. Әр ұяшықта айлық таза ақша ағыны және бір kWh-қа шекті кіріс болсын. Осылайша «BTC бағасы өссе бәрі түзеледі» деген жасырын жорамал көрінеді.

Екінші матрица uptime үшін пайдалы: 98%, 95%, 90%. Жазғы температура, желі ақауы немесе жөндеу difficulty әсерін күшейтеді. Difficulty +10% және uptime 90% бірге болғандағы нәтиже әр факторды жеке қарағаннан нашар; сатып алу шешімі дәл осындай біріктірілген стресс жағдайында тексерілуі тиіс.

Тоқтату және қайта қарау шектері

Үш шек белгілеңіз. Біріншісі — операциялық шек: тәуліктік pool-дан кейінгі кіріс айнымалы электр мен майнинг төлемінен төмендесе, қысқа мерзімді тоқтату қаралады. Екіншісі — жөндеу шегі: күтілетін жөндеу құны жөндеуден кейінгі қалған ақша ағынынан жоғары болса, қосалқы бөлшекке ақша байламаңыз. Үшіншісі — капитал шегі: стресс сценарийінде payback жабдықтың жоспарланған пайдалы мерзімінен асып кетсе, сатып алуды тоқтатыңыз немесе бағаны қайта келісіңіз.

Шектерді тек пайызбен емес, нақты KZT және kWh мәнімен жазыңыз. Сонда оператор difficulty жаңарған күні шешімді қайтадан ойдан шығармайды.

Практикалық жаңарту тәртібі

Difficulty өзгерген сайын базалық кестенің жаңа көшірмесін жасаңыз; бұрынғы нәтижені өшірмеңіз. Pool-дың нақты төлемін модельмен салыстырып, айырманың себебін комиссия, luck, rejected share, downtime немесе транзакциялық алым ретінде белгілеңіз. Үш кезең қатарынан жүйелі айырма болса, модель коэффициентін жаңартыңыз.

Сатып алу ұсынысында тек «ағымдағы табыс» емес, 5/10/20% нәтижесі, ең нашар айдағы өтімділік қажеттілігі және алдын ала бекітілген stop-rule болуы керек. Бұл сценарийді болжамнан басқару құралына айналдырады.

Жиі қойылатын сұрақтар

Difficulty 10% өссе, табыс дәл 10% азая ма?

Басқа шарттар тұрақты болса, BTC өндірісі шамамен 1/1,10 коэффициентіне өзгереді, яғни азаю дәл 10% емес. Нақты pool төлемі luck, fee және транзакциялық алымға байланысты ауытқиды.

BTC бағасын сол сценарийге қосу керек пе?

Иә, бірақ бөлек ось ретінде. Difficulty BTC өндірісін, ал баға сол өндірістің KZT құнын өзгертеді.

Қай аралықты база ету керек?

Кемінде бір толық difficulty кезеңі немесе соған жақын тұрақты жұмыс аралығы. Қысқа, ерекше сәтті күн базаға жарамайды.

Difficulty, network hashrate және hashprice-ты араластырмау

Үш көрсеткіш бір-бірімен байланысты болғанымен, модельде бір баған емес. Difficulty — Bitcoin хаттамасындағы блок табу нысанасының өлшемі; network hashrate — желіге қосылған есептеу қуатына қатысты бағалау; hashprice — белгілі хэшрейттің белгілі уақытта әкелетін ақша немесе BTC кірісін ықшамдайтын нарықтық көрсеткіш. Hashprice-ты кіріс input ретінде алып, оған difficulty әсерін тағы қоссаңыз, бір тәуекелді екі рет шегеруіңіз мүмкін.

Сондықтан бастапқы модельдің қай жолы протокол дерегі, қай жолы pool-дың нақты төлемі, қай жолы нарық бағасы екенін белгілеңіз. Difficulty сценарийі базалық BTC/TH/s production-ға қолданылады. BTC/KZT бөлек валюта осінде қалады. Pool fee, reject және uptime одан кейінгі операциялық түзетулер болады. Осы рет формуланың қай жерде өзгергенін тексеруге мүмкіндік береді.

Network hashrate бағасы қысқа аралықта құбылуы мүмкін және дәл өлшенетін жергілікті электр санауышы сияқты тікелей көрсеткіш емес. Оны жалғыз stop-rule етпеңіз. Шешім үшін өз машиналарыңыздың accepted hashrate-і, pool payout-ы және қабырғадағы kWh басым дәлел болып қалады.

Бір реттік секіру мен тізбекті өсімді ажырату

«Difficulty +20%» деген бір ғана жол екі түрлі жолды жасыра алады. Бірінші жағдайда өсім бір кезеңде бірден болады; екінші жағдайда бірнеше кезең бойы 5% шамасындағы өзгерістер жиналады. Соңғы нәтиже ұқсас көрінгенімен, cash flow уақыты, өндірілген BTC және шешімге әрекет ету мүмкіндігі әртүрлі.

Тізбекті модельде әр кезең жеке есептеледі: алдыңғы кезеңнің difficulty мәні келесі кезеңге база болады, ал сол аралықтағы BTC өндірісі жеке сақталады. Қарапайым құрылым:

кезең BTC = бастапқы BTC × бастапқы difficulty / кезең difficulty × effective uptime × (1 − pool шығындары)

Әр кезеңнің BTC сомасын кейін сол күнге арналған бағалау немесе нақты сату бағамымен KZT-ге айналдырыңыз. Бүкіл алты айға соңғы күннің бағасын қолдану тарихи cash flow-ды бұрмалайды. Сатылмаған BTC үшін есептік баға мен нақты ақша түсімі бөлек болуы керек.

Тізбекті сценарий операторға әрекет нүктесін көрсетеді. Мысалы, бірінші өсімнен кейін қуат режимін төмендету, екінші өсімнен кейін marginal cohort-ты тоқтату, үшінші өсімде сату ұсынысын жинау жоспарлануы мүмкін. Бір үлкен соңғы сан бұл басқару қадамдарын көрсетпейді.

Cohort бойынша шекті экономика

Ферманың орташа J/TH көрсеткіші ескі және жаңа партия айырмасын жасырады. Difficulty өскенде ең тиімсіз cohort алдымен stop-line-ға келеді. Әр модель және қуат режимі үшін accepted TH/s, қабырғадағы kW, all-in kWh, pool шығыны, maintenance reserve және avoidable hosting бөлек есептеледі.

бір kWh маржасы = pool-дан кейінгі кіріс / тұтынған kWh − avoidable kWh құны. Егер нәтиже теріс болса, қысқа мерзімде сол cohort-ты тоқтату жалпы ферма орташа пайда көрсеткен күннің өзінде дұрыс болуы мүмкін. Бірақ тоқтату шешімі restart шығыны, minimum hosting charge, келісім айыбы және суық/ыстық іске қосу тәуекелін де қамтиды.

Қуатты азайту кейде толық тоқтатудан жақсы. Underclock кезінде TH/s төмендейді, бірақ J/TH жақсаруы мүмкін; нақты нәтиже тек қабырғадағы өлшем және pool accepted hashrate арқылы расталады. Өндіруші қолдамайтын режимді қауіпсіздік пен кепілдікке әсерін тексермей қолданбаңыз.

Гипотетикалық cohort мысалы

Бұл сандар нарық болжамы емес, есеп тәртібін көрсетуге арналған. A cohort айына 0,010 BTC өндіріп, effective uptime 96%, pool және reject жиынтық шығыны 3% болсын. Базалық есептік өндіріс 0,010 × 0,96 × 0,97 = 0,009312 BTC болады. Difficulty бір рет 10% өскен сценарийде, басқа шарттар тұрақты болса, өндіріс шамамен 0,009312 / 1,10 = 0,008465 BTC.

Содан кейін ғана BTC/KZT input қолданылады. Егер модельде 1 BTC үшін 50 000 000 KZT деген тек әдістемелік input алынса, gross value шамамен 423 250 KZT болады. Одан нақты all-in электр, майнинг төлемі, cooling, maintenance және басқа avoidable шығын шегеріледі. Бұл баға да, өндіріс те ағымдағы нарық дерегі емес; өзіңіздің күні көрсетілген input-тарыңызды енгізу керек.

Егер B cohort-тың J/TH нашар болып, сол difficulty сценарийінде айнымалы шығыны 430 000 KZT болса, ол теріс маржаға түседі. A cohort әлі оң болса, бүкіл ферманы бірдей шешіммен басқару қате. Құрылғы саны, restart шарты және hosting минимумы рұқсат етсе, B cohort бөлек тоқтатылады немесе басқа қуат режиміне өтеді.

Cash runway-ды кезең-кезеңімен тексеру

Пайда кестесі оң болғанымен, электр шоты BTC payout-тан бұрын келсе, ликвидтілік тапшылығы пайда болады. Әр difficulty кезеңі үшін opening KZT cash, сатуға қолжетімді BTC, күтілетін payout күні, электр/hosting төлем күні, жалақы, жөндеу резерві және closing cash көрсетіледі. Сатылмаған BTC cash емес.

Runway кемінде ең нашар бір есеп айырысу цикліне жетуі керек. Pool threshold, withdrawal review немесе bank settlement кешіксе, төлем орындала ма — бөлек stress жасаңыз. Difficulty өсуі өндірісті баяу төмендеткенде cash reserve-тің таусылуы payback кестесінен ертерек келуі мүмкін.

Сату жоспары да модельмен байланысады: міндетті шығынды жабатын BTC бөлігі, резервті қалпына келтіретін бөлік және ұзақ мерзімге сақталатын бөлік. Бұл үлестер баға болжамы емес, төлем мерзімдері мен risk limit арқылы анықталады.

Сценарийді нақты нәтижемен салыстыру

Әр кезең аяқталғанда model BTC мен actual pool credit салыстырылады. Айырма difficulty-ге бірден жабылмайды. Attribution кемінде бес жолға бөлінеді: accepted hashrate айырмасы; uptime; reject/stale; pool method/luck; transaction fee және басқа reward компоненті. Difficulty input-ының өзі ресми немесе node дерегімен белгіленеді.

Егер actual нәтиже модельден жүйелі төмен болса, алдымен телеметрия мен payout definition тексеріледі. Формула коэффициентін тек себеп дәлелденгенде өзгертіңіз. Бір нашар кезеңге жауап ретінде бүкіл базаны төмендету келесі кезеңдегі мәселелерді жасыруы мүмкін.

Variance журналы бастапқы болжамды өшірмейді. Version, input snapshot, есеп уақыты, өзгеріс авторы және бекіту сақталады. Кейін ASIC сатып алу ұсынысын тексергенде, бұрынғы модельдің қаншалық дәл болғанын көруге болады.

Шешімді қайта бекіту тәртібі

Difficulty жаңарған күні автоматты түрде барлық машинаны тоқтату немесе іске қосу қауіпті. Алдымен дерек completeness тексеріледі: жаңа difficulty, соңғы accepted hashrate, kWh, pool fee, payout status және all-in kWh бағасы бар ма. Бір input жетіспесе, нәтиже «мәлімет жеткіліксіз» деп белгіленеді.

Одан кейін алдын ала жазылған шектер cohort деңгейінде қолданылады. Оператор техникалық қауіпсіз әрекетті орындайды; finance cash runway-ды растайды; жауапты басшы сатып алу, сату немесе ұзақ тоқтату сияқты капитал шешімін бекітеді. Әр шешімнің RFC3339 timezone-ы бар уақыты, қолданылған model version және evidence link сақталады.

Emergency stop электр немесе температура қауіпсіздігіне байланысты болса, экономика есептелгенше күтпейді. Ал экономикалық stop-line қауіпсіздік мәселесі болмаса, келісім, restart және pool payout салдарын есептегеннен кейін орындалады. Бұл екі stop-rule бір-бірін алмастырмайды.

Қате оптимизмді ұстайтын тексерулер

Сатып алу файлын бекітпей тұрып мына сұрақтарға «иә» жауабы қажет: базалық кезең толық па; BTC production мен BTC price бөлек пе; difficulty әсері екі рет енгізілмеген бе; барлық cohort жеке көрсетілген бе; uptime және reject stress бар ма; electric/hosting міндеттемесі нақты мерзіммен тұр ма; шығу құны мен қалдық құн енгізілген бе; шешімді тоқтататын сан анық па.

Егер жоба тек BTC бағасы жоғары, difficulty баяу, uptime мінсіз және қалдық құн жоғары болғанда ғана өтелсе, бұл төрт тәуекел бір optimistic жолға жиналғанын білдіреді. Мұндай модельді «базалық» деп атауға болмайды. Сатып алу бағасын төмендету, тиімді машинаны таңдау немесе capacity-ді кезеңмен қосу қаралады.

Сценарийдің мақсаты келесі difficulty мәнін болжау емес. Ол қандай өзгеріс кезінде қай құрылғының экономикасы бұзылатынын, cash қанша уақытқа жететінін және кім қандай әрекетті жасайтынын алдын ала анықтайды.

Input freeze және дерек жетіспеген кездегі ереже

Сценарийді талқылауға жіберер алдында input freeze жасаңыз. Файлда difficulty мәні мен алынған уақыт, pool export аралығы, accepted hashrate, kWh өлшемі, BTC/KZT бағалау көзі, all-in электр бағасы және қолданылған fee нұсқасы бір snapshot ретінде бекітіледі. Бір адам difficulty-ді жаңартып, екіншісі ескі электр бағасымен есептесе, нәтиже формула дұрыс болған күннің өзінде жарамсыз.

Snapshot атауы немесе version әр шешім хаттамасында қайталанады. Кесте ашылған сайын сыртқы мәндерді үнсіз жаңартатын формула owner approval үшін қолданылмайды: бүгін көрілген нәтиже ертең дәл қайталанбауы мүмкін. Динамикалық дерек бөлек бақылау панелінде қалуы мүмкін, ал шешім пакеті бекітілген мәндермен сақталады.

Дерек жоқ болса, үш әрекеттің бірі таңдалады: шешімді кейінге қалдыру; қолайсыз бірақ дәлелденген шекті мәнді қолдану; капиталға әсер етпейтін шағын pilot жүргізу. Бос мәнді нөлге айналдыруға, ескі ең жақсы айды көшіруге немесе дерек көзін көрсетпей «нарықтық орташа» жазуға болмайды.

Әр жетіспейтін input үшін иесі, ресми не ішкі дерек көзі және timezone бар RFC3339 мерзімі жазылады. Мерзім өткенде шешім автоматты түрде «қабылданды» мәртебесіне өтпейді. Осы бақылау difficulty сценарийінің дәл көрінетін, бірақ әр дәуірден жиналған сандар жиынына айналуын тоқтатады.