Анализ предложение Parity по спасению замороженных эфиров.

Как я писал в своей статье “Hack Parity MultiSig кошелька” 7 ноября 2017 произошла очередная катастрофа в мире смарт контрактов на Ethereum. Еще одна атака закончилась заморозкой 514 774 Ether на кошельках Parity MultiSig.

И вот через месяц раздумий Parity выложили свой вариант решения проблемы

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

Но нам интересно разобрать, что они предлагали и чем это могло закончиться.

Разбирая предложение Parity и ответы от комьюнити Ethereum, я увидел и хочу донести до вас одну из самых важных мыслей:

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

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

Разработчики пишут свою функциональность предполагают именно такой вариант работы сети и если вводятся такие изменения протокола, которые дают возможности появиться на адресе чему то другому, то это нарушает неизменность сети и это даже не хард форк DAO. В отличие от хард форка DAO, предложенные изменения носят постоянный характер, и что совсем критично, что такие изменения имеют обратную силу, влияя на контракты, которые были написаны и развернуты в соответствии с предыдущим набором допущений.

Такие изменения протокола нарушают одну из основных концепций сети семантическую совместимость. Все разработчики всех инструментов и приложений для Ethereum и Solidity действуют согласно этой концепции ожидая, что контракты будут действовать в соответствии с определенной и документированной семантикой основного языка и платформы (и любых основных существующих контрактов). Изменения такого уровня могут привести еще к более серьезным уязвимостям чем заморозка кошельков по причине плохого контракта ( потеря токенов, контракт может быть перенесен и тд )

Это так же нарушает пару таких существенных архитектурных решений, инвариантов Ethereum:

- Код по адресу контракта никогда не изменится, за исключением того, что он будет удален (контракт self destructs).

- У создателя контракта нет специального доступа или привилегий в отношении созданного контракта.

Исходя же из предложений Parity следует, что владелец имеет право просто изменить код контракта, притом это право должно быть зашито в сам протокол сети.

Конечно иногда изменения инвариантов могут принести пользу, но к этому нужно относиться с большой осторожностью. Например одноразовые изменения, что мы видели с решением проблемы DAO намного легче просчитать и оценить, чем совсем казалось бы безобидные но постоянные изменения. Если мы не можем глубоко проанализировать последствия изменений мы должны быть ОЧЕНЬ осторожны.

(пост в блоге Parity, некоторые ответы из комьюнити Ethereum: Hacking Distributed, Nick Johnson )