Post
Topic
Board Кодеры
Re: Решаем проблему с размером блока
by
neiros
on 01/04/2017, 09:23:22 UTC
Один из крайних случаев при таких 5% может стать таким, что при огромной величине мемпула, блоки будут очень маленькими.
Думаете, майнеры не захотят включать транзакции даже с высокой комиссией? В таком случае, придется еще ужесточать требования для содержимого блоков. Но мне кажется такой проблемы не будет.
Я имел ввиду другое. Поток транзакций это непостоянная величина. Количество транзакций может изменяться в очень больших пределах - сегодня очень много, завтра очень мало. Добавим сюда майнеров, которые по какому-либо поводу не желают включать в блоки 5%, предположим, шлака, по их мнению, создавая предпосылки к тому, что при очень малом количестве стандартных транзакций мемпул будет уменьшаться очень долго, а блоки будут очень маленькими. А если добавить сюда ещё каких-нибудь вредителей, которые будут генерировать нестандартные транзакции в количестве немного большим, чем может переварить система, то размер мемпула с нестандартными транзакциями будет стремиться к бесконечности.



Про mempool можно забыть когда консенсус основывается на блоках. Хоть он для всех как бы один, но для каждого разный из-за множества факторов влияющих на скорость прохождения каждой транзакции от узла к узлу, включая константу nMinRelayTxFee и может ещё чего, что сейчас не помню.
Если мы увеличиваем лимит на размер блока, то это уже в любом случае хард-форк. А раз уж мы все-равно изменяем протокол, то можем закрепить и правила формирования mempool как обязательные, и для всех они будут одинаковые. Что касается параметра minRelayTxFee, то логично его поднять до значения 10-20 sat/byte. Все транзакции с меньшей комиссией мы считаем нестандартными и в mempool их включать необязательно. А вот выше 20 sat/byte minRelayTxFee узлам устанавливать нельзя, это да.
А смысл тогда в этих 5% какой? Это уже стоит тогда рассматривать как погрешность между индивидуальными мемпулами узлов?
Даже представить себе не могу каким может быть даже частичный консенсус по мемпулу через консенсус по блокам. Манипулировать мемпулом узлов, по-моему, вполне возможно, если не сказать просто. Да даже и без возможных манипуляций, постоянный и неравномерный приток транзакций нужно будет как то учитывать. А из этого сразу возникает масса проблем с консенсусом по блокам.



И какие-либо задержки в 15-20 секунд никакой роли при этом не играют. Консенсуса по мемпулу в таких условиях не может быть в принципе, особенно при 5% которые подразумевается использовать каким угодно способом.
Вы не поняли. Нам не нужен полный консенсус по содержимому мемпула. Консенсус нужен только по тому, какие транзакции следует считать стандартными. Полные ноды не должны отбрасывать их, иначе просто не смогут проверить блок на валидность. Такой консенсус уже имеется, и я предлагаю добавить к нему еще два условия:
1) транзакция должна попасть в мемпулы большинства полных нод и пробыть там какое-то время до того, как будет включена в блок;
2) комиссия за транзакцию должна быть не менее 20 sat/byte
Другими словами достаточно подождать 15-20 секунд после появления в мемпуле нужных транзакций и любой новый блок считается валидным, при промежутке то между блоками в 600 секунд.

Зачем нам нужны орфан блоки в ещё большем их количестве? - https://blockchain.info/ru/orphaned-blocks



Первое условие необходимо для того, чтобы майнеры не могли бесплатно включать более 5% собственных транзакций в блок - теперь они, наравне со всеми, будут вынуждены сначала разослать их по сети. Второе условие - защита от спама, это ограничивает рост блокчейна.
Противоречие - майнеры не смогут разослать нестандартные транзакции как раз таки по второму условию и  Roll Eyes minRelayTxFee



В любом случае, самая длинная цепочка в конечном итоге строится на PoW, и отбракованные блоки теоретически могут быть включены в блокчейн, но только если большинство майнеров нарушат правила и согласятся их принять. Поэтому, во время оценки PoW для цепочки, ноды и майнеры не должны считать такие блоки, пока за ними не будет построено хотябы 2-3 корректных блока.
Вы представляете себе какое количество орфан блоков может получится при таких условиях?



По этой же причине имеет смысл ограничить единовременное увеличение блока по сравнению со средним размером нескольких предыдущих, скажем не более чем вдвое.
А минимальный размер каким может быть?