Аргументы против использования Биткойн адаптивных размеров блоков

Помимо риска того, что майнеры намеренно искусственно увеличат средний размер блока, каковы потенциальные недостатки адаптивных размеров блоков?

Есть ли какие-то преимущества у установленных человеком жестких ограничений? Есть ли какие-либо преимущества в том, чтобы требовать периодического вмешательства человека для оценки и изменения пределов размера блока вместо того, чтобы систематизировать эту задачу?

Такое ощущение, что вы уже ответили на 90% вопроса. Возможно, вам следует вместо этого разделить часть своего вопроса на ответ на вопрос.
@Murch Основываясь на вашем комментарии и на том факте, что прошло 16 часов с тех пор, как я разместил вопрос, я внес предложенные вами корректировки.

Ответы (1)

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

Если майнеры, устанавливающие размер блока, имеют хорошее оборудование и соединения, они могут захотеть, чтобы блоки были настолько большими, что другие были вынуждены отключиться от сети. Это может включать в себя крупные майнеры (с лучшим оборудованием и сетевым подключением), вытесняющие более мелких майнеров из сети. С другой стороны, (некоторые) майнеры могут захотеть иметь небольшой размер блока, в то время как другие предпочтут больший, но не смогут оказать никакого реального влияния.

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

Резюмируя, важно:

  • Сложность разработки адаптивной формулы размера блока, которую нельзя «обыграть».
  • Сложность создания наилучшей модели для минимизации стоимости узла-опции (CONOP)
  • Сложность проектирования системы, которая может эффективно масштабироваться как вверх, так и вниз.
  • Время и затраты на сравнение альтернативных формул и их тщательное тестирование

Поиск оптимальной модели CONOP, которая может удовлетворить вышеуказанные проблемы, будет трудным и трудоемким. До тех пор ограничения размера блока, ранее установленные людьми (и, возможно, скорректированные людьми, чтобы дать больше времени для изучения/исследования кодифицированных адаптивных решений по размеру блока), являются лучшим доступным вариантом.

CONOP был представлен в этой статье Полом Шторком:

http://www.truthcoin.info/blog/measuring-decentralization/

Эта концепция в контексте адаптивных размеров блоков также недавно обсуждалась Риккардо Спаньи на конференции Bitcoin On Chain Scaling:

https://www.youtube.com/watch?v=mM2ra-LzMQk

Не совсем связано, но я чувствую, что использование аббревиатуры CONOP для обозначения «стоимости узла-варианта» является плохим выбором. Эта аббревиатура уже очень широко используется для обозначения «концепции операций». Я предполагаю, что CON для стоимости узла не очень привлекателен. Может быть, COSUN для стоимости установки узла или что-то в этом роде. Я понимаю, что это был выбор г-на Шторца, а не ваш, просто комментарий.
Я думал, что это "Стоимость работы узла"? Вероятно, вы имеете в виду презентацию @fluffyponyza на конференции On Chain Scaling?
Аргументы против использования Биткойн адаптивных размеров блоков
СпросиСетьПолитика конфиденциальности1y, 0v