Кто может подменить код, работающий в Solana: замер 65 119 программ

[0xInnominatus]

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

Нет, такого способа нет. Собственное результаты исследования — наглядная иллюстрация почему от экосистемы Solana стоит держаться подальше, так как никакой команды внутреннего аудита не хватит мониторить все изменения во всех интеграциях (часть из которых вообще с закрытым кодом типа Jupiter). Исследование хорошее, но не используйте, пожалуйста, LLM для написания или постобработки статей (во-первых, читать больно, а во-вторых правила хабра запрещают и могут выдать бан).

[vandriichuk]

да, использую современные средства по причесыванию текста, так как сам талантом графомана не обладаю. (

За подтверждение по MPC спасибо. Значит, эту оговорку можно оставить, как есть.

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

При этом оно считается. Есть solana-verify и реестр verified builds. В следующем проходе добавлю долю верифицируемых сборок среди топ-100 по вызовам. Подозреваю, в связке с остальным это будет самое неприятное число в отчёте.

Насчёт «держаться подальше от Solana» не соглашусь, хотя и без уверенности. Замер не сравнивает сети, и я не думаю, что на других будет заметно лучше - скорее там это просто не так удобно померить. Из данных, по-моему, следует требование к процессу, а не выбор сети: записывать слот деплоя, а не только адрес, и знать класс authority у своих зависимостей. А вот что руками это не отследить - тут я не спорю. Это, собственно, и была причина взяться за замер.