Vitalik Buterin：Разработка протокола Ethereum требует внедрения упрощения и функции «сборки мусора», чтобы избежать раздувания

PANews 18 января — сообщение, опубликованное на платформе X, гласит: «Одним из важнейших и давно недооцененных аспектов протокола, связанного с «без доверия», «проходом «отказа теста»» и «самоуправлением», является его простота. Даже если протокол имеет десятки тысяч узлов, обладает 49% б Byzantine Fault Tolerance, и узлы полностью проверяют всё с помощью анти-квантовых peerdas и starks, то если этот протокол — огромный хаос из десятков тысяч строк кода и пяти видов криптографии уровня доктора наук, то он в конечном итоге провалит все три теста: Он не является без доверия, потому что пользователи должны доверять небольшой группе высокопоставленных специалистов, чтобы знать свойства протокола. Он не сможет пройти «тест выхода», потому что если команда текущих клиентов уйдет, новой команде будет очень трудно достичь такого же уровня качества. Он не обладает самоуправлением, потому что даже самые технически подготовленные люди не смогут проверить и понять его полностью, и он не полностью принадлежит пользователям. Кроме того, его безопасность также ниже, поскольку каждая часть протокола, особенно когда она взаимодействует со сложными компонентами, несет риск сбоев протокола. Мое беспокойство относительно разработки протокола Ethereum заключается в том, что мы можем слишком торопиться с добавлением новых функций для удовлетворения очень специфических требований, даже если эти функции сделают протокол громоздким или добавят новые типы взаимодействий или сложную криптографию в качестве ключевых зависимостей. В краткосрочной перспективе это может принести выгоду в виде расширения функциональности, но в долгосрочной — крайне разрушительно для сохранения самоуправления, создания многовековой децентрализованной сверхструктуры, превосходящей империю и идеологические конфликты. Основная проблема в том, что если оценивать изменения протокола с точки зрения «насколько сильно меняется существующий протокол», то желание сохранить обратную совместимость означает, что количество добавлений будет значительно превышать количество удалений, и протокол неизбежно станет раздуваться со временем. Чтобы справиться с этим, процесс разработки Ethereum нуждается в четкой функции «упрощения» или «сброса мусора», и «упрощение» имеет три критерия:

1. Минимизация общего количества строк кода протокола.
2. Избегание ненужных зависимостей от технических компонентов, по сути сложных.
3. Введение дополнительных инвариантов: ключевых свойств, на которые протокол может опираться, например, EIP-6780 (удаление selfdestruct), который ограничивает изменение не более N слотов хранения в каждом блоке, что значительно упрощает разработку клиентов. Сбор мусора может быть как разрозненным, так и масштабным. Разрозненный подход пытается упростить существующие функции, сделав их более лаконичными и логичными. Пример масштабного сброса мусора — замена PoW на PoS. Другой подход — «совместимость по модели Rosetta», при которой сложные, но редко используемые функции остаются доступными, но «понижаются» до уровня смарт-контрактов, а не обязательной части протокола, что освобождает разработчиков новых клиентов от их обработки. Например, после перехода на полностью нативную абстракцию аккаунтов все старые типы транзакций могут быть отменены; существующие предкомпилированные функции могут быть заменены кодом EVM или RISC-V; в конечном итоге виртуальная машина может быть изменена с EVM на RISC-V. В конце концов, хотелось бы, чтобы разработчикам клиентов больше не приходилось работать со всеми старыми версиями протокола Ethereum. В долгосрочной перспективе скорость изменений Ethereum должна замедлиться, и следует стараться избегать превращения ненужных частей в постоянное бремя для протокола Ethereum.