Re: Увеличение размера блока как (обобщенно) softfork.
Принято считать, что увеличение предела BLOCKSIZE требует
hardfork. Вместо этого мы покажем, что увеличение предел может быть достигнут с помощью
"обобщенный" softfork. Как стандартные softforks, обобщенные softforks нужен
просто шахтер большинство (>50% hashpower), а не глобальный консенсус.
Стандартные Softforks
После softfork два потенциальных цепь существует:
* Новая цепь B3, B4, B5, ... действует в соответствии с новыми правилами и старыми правилами.
* Старая цепь B3' , B4' , B5' , ... действует только под старыми правилами.
Например.
Код:
+-- B3 --- B4 --- B5
|
... -- В1 - В2 - +
|
+-- B3' - B4' - B5' - B6'
|
... -- В1 - В2 - +
|
+-- B3' - B4' - B5' - B6'
При условии, что >50% от hashpower следовать новым правилам, старая цепь
обречен быть сиротой:
Код:
+-- B3 --- B4 --- B5 B6 --- --- --- B7 B8 --- ...
|
... -- В1 - В2 - +
|
+-- B3' - B4' - B5' - B6' (сиротой)
|
... -- В1 - В2 - +
|
+-- B3' - B4' - B5' - B6' (сиротой)
Hardforks может привести к двум цепям, которые могут сосуществовать неопределенно:
Код:
+-- B3 --- B4 --- B5 B6 --- --- --- B7 B8 --- ...
|
... -- В1 - В2 - +
|
+-- B3' - B4' - B5' - B6' - B7' - B8' - ...
|
... -- В1 - В2 - +
|
+-- B3' - B4' - B5' - B6' - B7' - B8' - ...
Обобщенные Softforks
A * обобщенный * softfork вводит преобразование функции F (B) = B», отображающей
Блок B действует в соответствии с новыми правилами в блоке B»действительным по старым правилам.
После обобщенного softfork может существовать три цепи:
* Новая цепь B3, B4, B5, ... действует только под новые правила.
* Подключенный цепь F (B3), е (B4), F (B5), ... действует по старым правилам.
* Старая цепь B3' , B4' , B5' , ... действует только под старыми правилами.
Например.
Код:
+-- B3 ---- B4 ---- B5
|
... -- В1 - В2 - + - F (В3) - F (В4) - F (В5)
|
+-- B3' --- B4' --- B5' --- B6'
|
... -- В1 - В2 - + - F (В3) - F (В4) - F (В5)
|
+-- B3' --- B4' --- B5' --- B6'
Это "обобщенный" softfork, так как определение F (B) = B (функция тождества)
сводится к стандартному softfork случае выше.
Как со стандартным softforks, если большинство hashpower следовать новым
правила, то старая цепь B3' , B4' , B5' , ... обречен быть сиротой:
Код:
+-- B3 ---- B4 ---- B5 ---- В6 ---- B7 ---- ...
|
... -- B1 - B2 - + - F (B3) - F (B4) - F (B5) - F (B6) - F (B7) - ...
|
+-- B3' --- B4' --- B5' --- B6' (сиротой)
|
... -- B1 - B2 - + - F (B3) - F (B4) - F (B5) - F (B6) - F (B7) - ...
|
+-- B3' --- B4' --- B5' --- B6' (сиротой)
Пример:
Раздельный Witness можно рассматривать как пример обобщенного softfork.
Здесь новый формат блок состоит из комбинированных блоков и свидетелей данных старыхов.
Функция F () просто удаляет данные свидетелей, чтобы выявить действительный блок под
старые правила:
Код:
NewBlock: = OldBlock ++ Witness
F (NewBlock) = OldBlock
F (NewBlock) = OldBlock
Монолитный Увеличить размер Произвольный Через обобщенным Softfork
Раздельное Свидетель допускает лишь скромное эффективного увеличение блочного
(Хотя могут быть и другие мотивы для SW, но это не по теме).
Вместо этого мы инженер обобщенную softfork, что позволяет произвольно увеличить
предела блочный. Предложение состоит из двух частей: (а) новые правила
действительные блоки, и (б) функция преобразования F ().
Новые правила блока очень похожи на старые правила блока, но с некоторыми
небольшие изменения. В целом эти изменения:
* Предел MAX_BLOCK_SIZE повышается до некоторого нового предела
(Например, 8Mb, BIP101, 2-4-8, BIP202 и т.д., или какой-либо другой предел)
* Поле MerkleRoot в заголовке было переосмыслено.
* The CoinBaseTx должны подчиняться некоторые дополнительные новые правила.
Как и старые блоки, блок в соответствии с новыми правилами, состоит из заголовка блока
за которым следует вектор сделок [CoinBaseTx, Tx1, .., Txn], т.е.
Код:
NewBlock: = BlockHeader ++ NumTx ++ CoinBaseTx ++ Прд1 ++ .. ++ TxN
Формат заголовка блока такой же, как по старым правилам, определенным следующим образом:
Код:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | PrevHash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MerkleRoot | Время |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Биты | Нонс |
+-+-+-+-+-+-+-+-+
| Ver | PrevHash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MerkleRoot | Время |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Биты | Нонс |
+-+-+-+-+-+-+-+-+
По старым правилам MerkleRoot является корнем Merkle из хэшей всех
Операции, включенные в блок, т.е.
Код:
MerkleRoot = merkleRoot ([хэш (CoinBaseTx), хэш (Тх1), .., хэш (Txn)])
В соответствии с новыми правилами, мы вместо того, чтобы определить:
Код:
MerkleRoot = merkleRoot ([хэш (CoinBaseTx)])
То есть, в соответствии с новыми правилами, MerkleRoot является корнем Merkle одноточечного
вектор, содержащий только хеш CoinBaseTx.
Для сохранения свойств безопасности Bitcoin мы дополнительно
требует, чтобы какой-то образом CoinBaseTx кодирует корень Меркла из оставшихся
сделки [Прд1, .., Txn]. Например, это может быть достигнуто путем обязательного
обязательный выход OP_RETURN, который кодирует эту информацию, например,
Код:
OP_RETURN merkleRoot ([хэш (Тх1), .., хэш (Txn)])
В качестве альтернативы корень Меркл может быть закодирована в самой coinbase. Эта
гарантирует, что новые сделки не могут быть добавлены / удалены из блока без
изменяя поле MerkleRoot в заголовке.
Помимо этих изменений и увеличение MAX_BLOCK_SIZE, новый блок должен
подчиняться всем правилам старого формата кадра, например, действительный PoW, иметь действительный блок
вознаграждение, содержат действительные сделки, и т.д., и т.д.
Для того, чтобы быть обобщенной softfork мы также должны определить отображение F ()
от действительных новых блоков на действующие блоки по старым правилам. Мы можем определить это
следующим образом:
Код:
NewBlock: = BlockHeader ++ NumTx ++ CoinBaseTx ++ Прд1 ++ .. ++ TxN
F (NewBlock): = BlockHeader ++ 1 ++ CoinBaseTx
F (NewBlock): = BlockHeader ++ 1 ++ CoinBaseTx
То есть, функция е () просто обрезает блок так, что он содержит
coinbase сделка только. После усечения, то MerkleRoot поле из
Заголовок блока действует по старым правилам.
Предлагаемые новые правила в сочетании с преобразованием F () содержат
Обобщенная softfork. После развилки новой цепи B3, B4, B5, ... будут
генерируются в соответствии с новыми правилами, определенными выше, в том числе повышенного размера блока
предел. Эта новая цепь может быть сопоставлен с действительной цепи F (B3), F (B4), F (B5), ...
по старым правилам. При условии, что >50% от hashpower приняла новый
правила, отображенный цепь сирота любой конкурирующей сети по старым правилам,
так же, как стандартный softfork.
Интересным следствием этой конструкции является то, что, поскольку все отображенные блоки
пустые, старые клиенты никогда не будут видеть сделки подтверждения. Это будет
сильный стимул для пользователей, чтобы обновить их клиентов.
Вывод
Обычные мудрости предполагают, что увеличение лимита BLOCKSIZE требует
hardfork. Покажем, что вместо этого может быть достигнуто с помощью обобщенной
softfork. Как со стандартным softfork, обобщенное softfork просто
требует большинства (>50%) хэш мощности, а не глобального консенсуса.
Опыт показал, что первое значительно легче достичь.
Будущая работа:
Исследовать другие виды hardforks, что вместо этого могут быть реализованы в виде
Обобщенные softforks, и последствия для безопасности таких ...
7943a2934d0be2f96589fdef2b2e00a2a7d8c3b782546bb37625d1669accb9b1
72f018588572ca2786168cb531d10e79b81b86d3fada92298225a0f950eed3a5
