Большинство, кто смотрит на движок Piecrust от Dusk, сразу сосредотачивается на том, что он может делать при запуске — смарт-контракты, WASM, криптографию для приватности. Но меня постоянно цепляет меньшая деталь: Dusk решает сделать свой самое скучное и при этом самое критичное программное обеспечение — контрактами Genesis, которые обрабатывают проверку транзакций и стейкинг — постоянным уже с первого дня. Никаких тихих патчей, никаких «починим в v2». Именно в этом стоит задержаться, больше, чем на диаграммах архитектуры.
Неизменяемые базовые контракты — это не просто инженерный «гибкий» ход, это решение о доверии. Логика, похоже, такая: если самый важный код нельзя будет незаметно изменить позже, то пользователям не нужно доверять будущим намерениям команды — достаточно доверять тому коду, который уже запущен. Это другой тип верификации, чем предлагают большинство сетей. Ты не доверяешь дорожной карте или решению по управлению, которое появится потом — ты доверяешь тому, что можно один раз проверить и на что можно полагаться. Вынесение piecrust-uplink в качестве тестовой среды до того, как что-либо коснётся продакшена, соответствует тому же инстинкту: перенести неопределённость на этап до запуска, чтобы в работающей системе её было как можно меньше.
Но постоянство — это компромисс, а не бесплатная победа, и именно этот момент люди часто пропускают. Код, который нельзя незаметно поменять, — это также код, который нельзя незаметно исправить. Каждая сеть, которая выпустила окончательную логику core, в итоге сталкивалась с чем-то, чего не покрыли симуляции: например, предположение о газе, которое ломалось под реальной нагрузкой, или параметр стейкинга, который выглядел нормально на бумаге и был успешно использован на практике. Поэтому реальный вопрос с Piecrust — не «безопасность против гибкости» как абстрактные величины. Вопрос в том, правильно ли Dusk выбрал Genesis-контракты в первый и единственный реальный заход, потому что, возможно, второго не будет.
#dusk @Dusk $DUSK
Неизменяемые базовые контракты — это не просто инженерный «гибкий» ход, это решение о доверии. Логика, похоже, такая: если самый важный код нельзя будет незаметно изменить позже, то пользователям не нужно доверять будущим намерениям команды — достаточно доверять тому коду, который уже запущен. Это другой тип верификации, чем предлагают большинство сетей. Ты не доверяешь дорожной карте или решению по управлению, которое появится потом — ты доверяешь тому, что можно один раз проверить и на что можно полагаться. Вынесение piecrust-uplink в качестве тестовой среды до того, как что-либо коснётся продакшена, соответствует тому же инстинкту: перенести неопределённость на этап до запуска, чтобы в работающей системе её было как можно меньше.
Но постоянство — это компромисс, а не бесплатная победа, и именно этот момент люди часто пропускают. Код, который нельзя незаметно поменять, — это также код, который нельзя незаметно исправить. Каждая сеть, которая выпустила окончательную логику core, в итоге сталкивалась с чем-то, чего не покрыли симуляции: например, предположение о газе, которое ломалось под реальной нагрузкой, или параметр стейкинга, который выглядел нормально на бумаге и был успешно использован на практике. Поэтому реальный вопрос с Piecrust — не «безопасность против гибкости» как абстрактные величины. Вопрос в том, правильно ли Dusk выбрал Genesis-контракты в первый и единственный реальный заход, потому что, возможно, второго не будет.
#dusk @Dusk $DUSK