За даними Cointelegraph, співавтор Ethereum Віталік Бутерін запропонував кілька заходів для пом’якшення виробництва блоків і централізації ставок під час фази Scourge технічної дорожньої карти Ethereum. У дописі від 20 жовтня Бутерін висловив занепокоєння тим, що економія за рахунок масштабу ставок призвела до злиття менших пулів ставок з більшими, в результаті чого дві організації створили 88% блоків Ethereum за перші два тижні жовтня.

Бутерін підкреслив, що централізація ставок є значним ризиком для Ethereum, що потенційно може призвести до посилення цензури транзакцій та інших криз. Він зазначив, що в той час як 30% ефіру (ETH), на який зараз покладено, достатньо для захисту від атак 51%, подальша централізація може створити додаткові ризики. Він попередив, що стейкінг може стати менш прибутковим і накладе більше зобов’язань на власників ефіру, послаблюючи механізм скорочення та дозволяючи токенам ліквідного стейкінгу домінувати над мережевими ефектами.

Щоб вирішити ці проблеми, Бутерін запропонував обмежити кількість ефіру, який користувач може зробити, і обмежити штрафні санкції до 12,5% від поставленого ефіру. Він запропонував дворівневу модель стейкингу з «ризикованими» (з можливістю скорочення) і «безризиковими» (без можливості скорочення). Його занепокоєння підтвердив дослідник Ethereum Foundation Тоні Вахрштеттер, який підкреслив, що два конструктори блоків, Beaverbuild і Titan Builder, побудували 88,7% блоків Ethereum на початку жовтня.

Бутерін зазначив, що метод поділу пропонента і конструктора Ethereum для створення блоків призвів до проблем централізації. Хоча безпека Ethereum зараз не під загрозою, він попередив, що проблема може погіршити цензуру транзакцій і збільшити час включення блоку з 6 секунд до 114 секунд. Ця затримка може дозволити розробникам блоків отримувати дохід від користувачів за допомогою сендвіч-атак або призвести до значного маніпулювання ринком під час децентралізованих фінансових ліквідацій.

Щоб боротися з цими проблемами, Бутерін запропонував модель «списків включення з примусовим вибором вибору», де завдання вибору транзакцій повертатиметься до пропонента або учасника, а розробник лише визначатиме порядок транзакцій. Іншою альтернативою є пропозиція «BRAID», яка розділяє процес виробництва блоків між кількома учасниками, кожному з яких потрібен лише середній рівень складності для максимізації доходу.