Идея софт-форка Биткойн, чтобы помочь сжать блокчейн

Почему бы нам не заставить майнеров встраивать высоту дерева Меркла TX в первые два байта 4-байтовой версии заголовка блока?

Это был бы разумный софтфорк, но он должен учитывать, что из-за BIP65 версия блока (которая представляет собой целое число со знаком) должна быть не менее 4, что ограничивает ее значениями 2 ^ 31-4. Поддержание совместимости с BIP9 и, возможно, BIP340, которые присваивают значение определенным битам в номере версии, еще больше усложнит ситуацию.

Кроме того, трудно убедить майнеров провести софтфорк в изменении, которое усложняет для них ситуацию, а это означает, что в отсутствие успешного давления в стиле UASF маловероятно, что это будет принято.

Это устранит уязвимость листового узла методом грубой силы (CVE-2017-12842), которая в настоящее время устраняется только правилами стандартности, но не правилами консенсуса.

Действительно! Я думаю, что изменение консенсуса, которое обеспечивает минимальный размер транзакции, вероятно, будет гораздо менее инвазивным.

Аналогично описанию в BIP 141, мы можем ввести тип узла, который не является ни сокращенным узлом, ни полным полным узлом, но у них будет txindex=1 для транзакций с неизрасходованными выходами. Эти узлы сначала будут хранить полные блоки. Когда приходит следующий блок, используя свой txindex, они ищут блок, находят транзакцию и проверяют, все ли выходы израсходованы. Если это так, они удалят транзакцию из хранилища этого блока, но сохранят только ее хэш. Это сэкономит много места, поскольку мне кажется, что в большинстве сценариев запроса узла с поддержкой txindex будет использоваться gettransaction для транзакций с неизрасходованными выходами?

Я не понимаю, как это изменение связано с этим потенциальным режимом работы. Независимо от того, что вы предлагаете блокам зафиксировать в своем заголовке, это может быть просто запомнено узлами, когда они впервые проверяют блок, без изменения консенсуса. Для локального узла, если он сам подтвердил, сколько транзакций на самом деле находится в блоке, он никогда не убедит себя ни в чем другом.

Я также не думаю, что этот режим имеет какие-либо преимущества. Он разделяет медлительность проверки модели до UTXO (*) с отсутствием возможности предоставлять полные блоки (например, текущие сокращенные узлы), потребляя при этом гораздо больше дискового пространства (требуется полностью сохранять каждую транзакцию, которая имеет хотя бы одну неизрасходованную транзакцию). выход, а не хранить только неизрасходованные выходы).

(*) До Биткойн 0.8 вместо набора блок-цепочка + UTXO существовала блок-цепочка + индекс в этой цепочке для каждой транзакции + логическое значение для каждого вывода независимо от того, было ли оно потрачено или нет. Это было медленно, потому что это означало, что рабочий набор (данные, к которым часто обращается код) фактически представлял собой всю цепочку блоков (выполняя множество случайных поисков для каждого потраченного ввода). В модели UTXO, представленной в версии 0.8, набор UTXO хранится независимо от блокчейна (он не содержит указателей на блокчейн; он содержит копии всех UTXO), что позволяет эффективно кэшировать только UTXO и делает блокчейн более привлекательным. не требуется для нормальной работы (за исключением подачи блоков другим узлам или повторного сканирования). Эта модель также позволила отсечь, поскольку сама цепочка блоков больше не используется для проверки.