Как обновить развернутый смарт-контракт? [Дубликат]

    

У этого вопроса уже есть ответ:

    

Я начал разрабатывать смарт-контракты с Трюфелем , и когда я редактирую контракт, я всегда передислоцирую его на добавление другого сценария миграции. Меня интересует две вещи:

  1. Так ли это должно быть сделано, или есть лучший способ?
  2. Когда я передислоцирую контракт с новым сценарием миграции, развернутый контракт также получит новый адрес. Можно ли также перенести смарт-контракт и сохранить существующий адрес?

Все советы приветствуются!

21 голос | спросил kramer65 6 FebruaryEurope/MoscowbMon, 06 Feb 2017 16:50:51 +0300000000pmMon, 06 Feb 2017 16:50:51 +030017 2017, 16:50:51

1 ответ


28

Контрактный код является постоянным. Невозможно изменить код развернутого контракта, за исключением того, что он полностью уничтожил код операции SELFDESTRUCT (selfdestruct()).

Есть четыре способа, более или менее, справиться с этим:

  1. Не. Просто договоритесь, чтобы быть вечным, независимо от того, что происходит.
  2. Используйте некоторую схему, чтобы обойти это ограничение.
  3. Создайте новый контракт и найдите способ подключения к старым пользователям /другим контрактам.
  4. Создание временных контрактов.

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

1 - второй, самый простой, поскольку вам не нужно ничего делать. Это также является самым опасным, так как он в принципе надеется, что никогда не будет критической ошибки. Это почти наверняка ложная надежда.

2 намного сложнее. Существуют способы использования эффекта изменяемого кода контракта. Например, вы можете поместить данные в один неизменный контракт, а затем вызвать библиотеку для ее фактического выполнения. Здесь будет мой совет о том, как сделай это. Однако, как я уже упоминал, это не для слабонервных, и это, вероятно, не стоит в небольших масштабах.

3 - это то, что DAO использовал бы для самосовершенствования, если бы он не подвергся атаке. Один из вариантов заключается в том, чтобы иметь простой контракт, действующий как точка входа в текущий «реальный» контракт.

4 является самым легким, а ИМХО - лучшим, если это возможно. Если ни один из контрактов не нуждается в долгосрочном состоянии, тогда лучше всего создать новый при каждом обновлении. Будильник Ethereum, как я понимаю, просто имеет более новые и более старые версии в цепочке. Там нет необходимости в сложных схемах, и если вам нужна более старая версия, она может остаться.

Лучший вопрос - спросить себя, что вам нужно. Будет ли в контракте «окончательное» состояние? В этом случае вы можете уйти с 1. Если нет, вы можете использовать 4. Если ни один из них, или если вам абсолютно необходимо сохранить один и тот же адрес, тогда, возможно, пришло время посмотреть на 2 или 3.

РЕДАКТИРОВАТЬ: см. также этот вопрос для других идей .

ответил Matthew Schmidt 6 FebruaryEurope/MoscowbMon, 06 Feb 2017 21:47:15 +0300000000pmMon, 06 Feb 2017 21:47:15 +030017 2017, 21:47:15

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132