Недавно решил вложиться в какую-то децентрализованную платформу и начал разбираться, как работают смарт-контракты. Слышал, что они — это как такие автоматические программы, которые выполняются без вмешательства человека. Но сразу появился вопрос — а что, если потом нужно что-то исправить или обновить? У меня есть опасения, что после запуска их уже нельзя изменить. Это действительно так? Или есть способы подстраховаться или обновлять их?
Я бы хотел понять, насколько это реально — создать такой контракт, который нельзя взломать или изменить, и при этом иметь возможность в будущем исправлять ошибки или добавлять новые функции. Посоветуйте, стоит ли вообще так рисковать или лучше искать другие решения. Спасибо заранее!
Discussion
.png)
Прокси — это контракт, который ссылается на другую реализацию. Можно менять логику, меняя адрес целевого контракта, а сам прокси остается.
.png)
Я делал пару проектов, там использовал паттерн Upgradable. Но это сложнее и требует аккуратности.
.png)
А если контракт без таких прокси, то он точно уже не изменится? Какие есть риски?
.png)
Правильно ли я понимаю, что если контракт без специально реализованных механизмов, то его уже никак не исправить?
.png)
Да, именно так. Но есть и исключения, например, если контракт содержит функции для отмены или обновления, прописанные заранее.
.png)
А как насчет багов? Лучше сразу писать очень аккуратно, чтобы не было уязвимостей?
.png)
Я считаю, что лучше использовать прокси и делать контракт обновляемым, иначе риски очень большие.
.png)
Павел, а не кажется, что это усложняет архитектуру и увеличивает риск ошибок?
Возможно, но это дает возможность исправлять ошибки и добавлять функции в будущем.
Можно ли вообще полностью обезопасить контракт от изменений? Или всегда есть риск взлома?
Взломать контракт сложно, если он хорошо написан и залит с правильными настройками.
.png)
А что значит 'неизменяемость'? Это значит, что нельзя его вообще изменить, или что нельзя его взломать?
.png)
Обычно под 'неизменяемостью' понимают невозможность изменить код после деплоя, но можно создавать обновляемые через прокси.
.png)
Какой лучший подход — делать контракт полностью статичным или с возможностью апгрейда?
.png)
Я бы выбрала обновляемость, особенно для долгосрочных проектов, чтобы исправлять баги.
А есть ли случаи, когда лучше делать контракт полностью статичным?
.png)
Да, например, для очень простых или очень важных контрактов, где изменение недопустимо.
Олег, а как тогда исправлять ошибки? В таких случаях это рискованные решения.
.png)
В целом, я считаю, что лучше предусматривать обновляемость, чтобы не оказаться в ловушке.
А как узнать, что контракт действительно безопасен и не содержит уязвимостей?
Лучше всего доверять проверенным разработчикам и проводить аудит кода.
Да, в обычной форме смарт-контракт считается неизменяемым после деплоя, но есть способы его обновлять через прокси-контракты.
Иван, что такое прокси-контракт и как он помогает?