Bitcoin Cash сохраняет базовую Bitcoin-модель UTXO и Proof of Work, но делает другой выбор по scaling policy: сеть старается держать L1 blockspace достаточно свободным, чтобы обычные платежи не превращались в постоянный аукцион за каждый байт. После ручных повышений лимита до 8 MB и 32 MB BCH перешёл к Adaptive Blocksize Limit Algorithm: 32 MB остаются floor, а верхний предел способен плавно расти, если mined blocks устойчиво показывают реальный спрос. Difficulty регулирует отдельный ASERT-контур с 10-минутной целью и двухдневной half-life. Эти механизмы нужно анализировать вместе — как систему пропускной способности, mining economics и требований к node infrastructure.
BCH сохраняет UTXO-модель Bitcoin
Bitcoin Cash transaction потребляет ранее созданные outputs и создаёт новые outputs. Account balance в привычном смысле не хранится как одна mutable цифра: wallet вычисляет доступный balance как сумму подходящих unspent transaction outputs.
Input указывает на конкретный предыдущий output
Каждый non-coinbase input содержит TXID и output index. Это точная ссылка на ранее созданный coin. После успешного spend тот же outpoint нельзя потратить повторно.
Output задаёт value и spending condition
Output содержит количество satoshis и script, который определяет условия будущего расходования. Fee возникает как разница между суммой inputs и суммой outputs.
Change — это новый UTXO, а не возврат старого balance
Если wallet тратит UTXO 1 BCH для платежа 0.2 BCH, transaction обычно создаёт recipient output и change output за вычетом fee. Исходный 1-BCH output исчезает как unspent object.
Coin selection влияет на fee и privacy
Transaction с большим числом inputs занимает больше bytes и обычно дороже при одинаковом feerate. Объединение множества UTXOs также связывает адресные кластеры и ухудшает privacy assumptions.
UTXO set — критичный state full node
Full node не обязан каждый раз пересматривать всю историю chain, чтобы проверить новый spend: ему нужен актуальный набор unspent outputs и доказуемая история consensus до текущего tip.
Размер transaction важнее суммы перевода для fee economics
BCH fee market, как и Bitcoin-family UTXO systems в целом, привязан прежде всего к serialized size и policy feerate, а не к денежной сумме payment.
1 BCH не обязан стоить дороже 0.01 BCH
Если обе transactions используют одинаковое число inputs/outputs и похожие scripts, их byte footprint будет близким. Экономическая value transfer сама по себе не увеличивает размер transaction.
Consolidation может быть выгодна при свободном blockspace
Wallet может объединить мелкие UTXOs в один output, когда fees низкие. Позже это уменьшает число inputs в urgent payment. Но consolidation раскрывает linkability между UTXOs.
Большие blocks уменьшают scarcity pressure, но не отменяют fee
Miner всё равно выбирает transactions и получает fees. Разница policy в том, что BCH стремится не создавать искусственно постоянный дефицит blockspace при обычной нагрузке.
«Низкая комиссия» и «нулевая стоимость инфраструктуры» — разные утверждения. Пользователь может платить мало, пока miners, nodes, explorers и exchanges всё равно обрабатывают, передают и хранят block data.
История лимита: 1 MB → 8 MB → 32 MB
Scaling debate Bitcoin раскололся вокруг вопроса: увеличивать базовый L1 blockspace или строить scarcity-driven settlement layer с большей ролью upper layers.
BCH возник после повышения лимита до 8 MB
В августе 2017 года Bitcoin Cash split принял blocksize rules, допускающие blocks до 8 MB. Это было не просто изменение UI fee policy, а consensus divergence.
В мае 2018 лимит стал 32 MB
Следующее coordinated upgrade увеличило ceiling до 32 MB. Спецификация ABLA отмечает, что сам факт согласованного повышения требовал социальной и технической координации, чтобы избежать случайного split.
Fixed limit является одновременно safety boundary
Block limit защищает не только от congestion. Он задаёт maximum workload, который должны выдерживать node software, indexers, explorers и exchange backends, и ограничивает DoS surface.
Unlimited block size тоже создаёт consensus risk
Если каждый operator выставляет собственный maximum, один очень большой block может быть принят частью сети и отвергнут другой. Consensus-safe scaling требует одинаково вычисляемого правила.
ABLA: blocksize limit теперь адаптируется к mined demand
Adaptive Blocksize Limit Algorithm был принят для May 2024 upgrade. Его идея — убрать необходимость вручную голосовать за каждое следующее повышение ceiling.
32 MB остаются floor
Accepted CHIP прямо сохраняет предыдущие 32 MB как stand-by minimum. При низком usage algorithm не сжимает сеть ниже этого floor.
Control block size следует за EWMA реальных blocks
ABLA использует exponentially weighted moving-average style control function. Входом служит фактический размер mined blocks: устойчивое увеличение block usage постепенно поднимает control size.
Elastic buffer даёт headroom для bursts
К control value добавляется elastic buffer. Если demand растёт достаточно быстро, buffer расширяется, чтобы кратковременный spike не упирался немедленно в новый ceiling.
Снижение происходит медленнее роста
Design намеренно асимметричен. Это уменьшает риск oscillation и сохраняет некоторое время память о недавнем high-demand периоде.
ABLA не означает автоматический бесконечный рост
Алгоритм реагирует на фактически mined block sizes и имеет bounded response parameters. Для устойчивого роста capacity miners должны регулярно включать больший объём реальных transactions.
Почему автоматический limit уменьшает social coordination cost
Раньше очередное увеличение ceiling требовало договорённости: новый number, activation height/time, implementation, testing и synchronized deployment.
Demand становится частью feedback loop
Если пользователи создают больше transactions, miners фактически демонстрируют готовность supply blockspace, а ABLA постепенно отражает это в следующем limit.
Miner не может одним случайным гигантским block мгновенно поднять ceiling
EWMA и bounded adjustment сглаживают short-term spike. Это важно, иначе attacker/miner мог бы быстро навязать node operators резко больший hardware requirement.
Floor сохраняет заранее доступную capacity
Даже при длительном low usage сеть не возвращается к маленьким blocks. 32-MB floor означает, что определённый throughput budget считается базовой инфраструктурной нормой.
ASERT регулирует difficulty отдельно от block-size feedback
Blockspace algorithm отвечает на demand transactions. Difficulty algorithm отвечает на скорость Proof-of-Work production. Это два независимых control loops.
Target interval остаётся 600 секунд
ASERT использует ideal block time **600 seconds**, то есть 10 минут в среднем — тот же high-level target, что исторически у Bitcoin.
Mainnet half-life равна 172800 seconds
Параметр ASERT aserti3-2d — **172800 секунд, или 2 дня**. Если chain оказывается примерно на два дня ahead of schedule относительно anchor trajectory, difficulty удваивается; opposite drift уменьшает difficulty экспоненциально.
ASERT был ответом на hashrate oscillations
Предыдущий DAA 2017 года создавал периодические колебания: bursts быстрых blocks сменялись длинными паузами. Это давало advantage miners, переключающим SHA-256 hashrate между chains.
Difficulty меняется плавно относительно schedule
ASERT привязан к anchor и cumulative time/height trajectory, а не просто к короткому rolling window последних blocks. Это снижает feedback instability.
Random block intervals никуда не исчезают
Даже с идеальной difficulty PoW block arrivals статистически шумные. «10 минут» — long-run target, а не SLA каждого следующего block.
SHA-256 связывает BCH mining economics с BTC
BCH и BTC используют SHA-256 PoW. Одинаковый класс ASIC способен выбирать, какую chain майнить.
Miner сравнивает revenue per hash
Решение зависит от coin price, block subsidy, fees и difficulty. Если относительная profitability меняется, hashpower может мигрировать между chains.
ASERT снижает выгоду timing games
Цель DAA — быстро и плавно вернуть production trajectory к 10-минутной норме без резких oscillations, которые поощряют opportunistic switching.
Security budget зависит не только от nominal hashrate
Важно учитывать стоимость аренды/переключения совместимого SHA-256 equipment и relative size соседней chain. Shared mining hardware market создаёт особый threat model.
BCH vs BTC: спор не о том, нужны ли layers вообще
Упрощённая формула «BCH = on-chain, BTC = Lightning» слишком грубая. Реальный спор — о том, сколько массового payment demand базовый layer должен обслуживать напрямую и какой scarcity допустим на L1.
| Параметр | BCH policy | BTC policy |
|---|---|---|
| Accounting | UTXO | UTXO |
| PoW | SHA-256 | SHA-256 |
| Target block interval | ~10 min | ~10 min |
| L1 capacity stance | Больший/adaptive block ceiling | Более консервативный base-block policy |
| Congestion response | Стараться расширять L1 capacity | Fee market + upper-layer scaling |
| Node trade-off | Выше потенциальный bandwidth/storage workload | Жёстче ограничен base-layer workload |
Больший L1 снижает fee pressure при прочих равных
Если available capacity заметно выше demand, users меньше конкурируют feerate. Но экономическая сторона miners в долгом горизонте зависит от aggregate fees после снижения subsidy.
Малый L1 делает blockspace более редким
Это может усиливать fee market и снижать maximum node workload, но переводит часть high-frequency use cases на off-chain/L2 systems.
Больший L1 повышает требования к периферийной инфраструктуре
Не только validating node, но и explorer, wallet backend, exchange indexer, archive service и analytics pipeline должны переваривать high-throughput blocks.
Scaling trade-off нельзя свести к «больше TPS всегда лучше» или «маленький block всегда децентрализованнее». Нужно измерять hardware cost, propagation, UTXO growth, fee revenue, actual demand и число независимых operators, способных держать полный stack.
Explorer-анализ BCH: что проверять в реальной transaction
BCH explorer следует читать как UTXO graph.
Inputs показывают consumed coins
Для каждого input полезны previous TXID, output index и previous value. Несколько inputs часто означают coin selection или consolidation.
Outputs показывают payment и change
Один output может быть merchant payment, второй — change. Нельзя считать все outputs «получателями бизнеса» без wallet context.
Fee лучше нормализовать по size
Absolute fee малоинформативен без bytes. Сравнивать transactions полезнее через sat/byte или эквивалентный feerate metric.
Block context отделяет mempool от settlement
Проверяйте block height, confirmations, timestamp, size block и current chain tip. Нулевая confirmation и глубоко подтверждённый UTXO — разные risk states.
Экономика масштабирования проявляется в workload, а не в рекламном TPS
Theoretical maximum зависит от average transaction size, script mix, parallel validation, network bandwidth и block interval.
Средний payment size меняет practical TPS
32 MB, заполненные простыми payments, дают другое число transactions, чем block с более тяжёлыми scripts/tokens. Поэтому TPS без workload definition — слабая метрика.
UTXO growth может стать bottleneck отдельно от raw block storage
Миллионы новых small outputs увеличивают state, который нужен для fast validation. Block history можно хранить/архивировать по-разному, но current spendable set нужен active node.
Propagation влияет на miner orphan risk
Чем дольше новый block передаётся и валидируется, тем больше вероятность, что другой miner параллельно найдёт competing block. Efficient propagation protocols уменьшают, но не устраняют trade-off.
Demand должен подтверждать infrastructure cost
Именно поэтому ABLA использует mined block sizes как feedback: capacity расширяется не только по политическому обещанию, а при наблюдаемом использовании.
Главный вывод
Bitcoin Cash — это эксперимент в **demand-responsive L1 scaling** внутри знакомой Bitcoin UTXO/PoW архитектуры. UTXO определяет, как coins расходуются; transaction bytes формируют fee workload; SHA-256 miners создают blocks; ASERT удерживает средний interval около 10 минут; ABLA регулирует maximum block capacity и сохраняет 32 MB как minimum stand-by floor.
Главное отличие BCH от BTC — не cryptography и не UTXO, а engineering policy вокруг scarce blockspace. BCH предпочитает увеличивать доступный L1 capacity по мере фактического demand, принимая более высокий potential workload для nodes и services. BTC держит более консервативный base-layer capacity и сильнее опирается на fee market и upper layers.
Поэтому правильный вопрос звучит не «какой block size лучше», а **какой объём L1 demand существует, сколько независимых operators способны обработать resulting workload, какую fee revenue получают miners и как быстро protocol способен менять capacity без social deadlock или consensus instability.**
FAQ
Bitcoin Cash всё ещё имеет фиксированный лимит 32 MB?
32 MB остаются floor Adaptive Blocksize Limit Algorithm. После May 2024 ceiling способен плавно расти выше этого значения при устойчиво больших mined blocks.
Что такое ASERT?
Это difficulty-adjustment algorithm BCH aserti3-2d. Он использует 600-second target block interval и 172800-second half-life, привязывая difficulty к отклонению chain от anchor schedule.
Почему BCH и BTC могут майниться одинаковыми ASIC?
Обе chains используют SHA-256 Proof of Work. Mining hardware совместим, поэтому часть hashpower может переключаться в зависимости от relative profitability.
Fee зависит от суммы BCH?
Не напрямую. Fee прежде всего связан с serialized transaction size и feerate. Большое число inputs может сделать небольшой денежный перевод дороже крупного transfer с одним input.
Большие blocks автоматически делают BCH централизованным?
Не автоматически. Но больший потенциальный throughput повышает bandwidth, storage, indexing и validation requirements. Реальную decentralization следует измерять по стоимости инфраструктуры и числу независимых operators, а не одному ceiling number.
Зачем вообще нужен maximum block size?
Consensus limit задаёт predictable upper workload, уменьшает DoS surface и не позволяет nodes с разными local limits случайно расходиться по valid chain.
Материал носит образовательный характер и не является финансовой рекомендацией.