Обновляемые смарт-контракты. Существует ли консенсус между акционерами при обновлении?

Похоже, что обновляемые смарт-контракты — это новая волна будущего, по вполне понятным причинам. Как это работает для смарт-контракта «hello world», где два пользователя делают ставку на то, что погода через 2 месяца будет выше некоторой температуры, и они договариваются об оракуле для временных данных. Что, если сделать из него обновляемый контакт и обновить температурный оракул?

Уведомляются ли все игроки, участвующие в контракте, или стороны контракта должны продолжать просматривать код контракта? Если контракт был обновлен и $ присужден победителю, что, если проигравший не знал, что источник температуры был модернизирован? Такой сценарий вообще возможен?

Можете ли вы описать конкретный механизм, который вы имеете в виду, когда говорите об «обновляемых смарт-контрактах»? Слово «обновляемый» кажется довольно несовместимым с идеей смарт-контракта, но я полагаю, что механизм, требующий согласия между заинтересованными сторонами, может быть приемлемым.
если вы погуглите термин, это очень распространенная идея. medium.com/aigang-network/…
Является ли подход в этом сообщении в блоге тем, о котором вы спрашиваете?
Подход в этом сообщении в блоге кажется односторонним, поэтому я не понимаю, почему кто-то может доверять такому контракту.
Я так понимаю, но «обновляемые» контракты, похоже, сейчас в моде. Похоже, что это уход от смарт-контрактов, а смарт-сервис.
Я не могу прокомментировать, являются ли они «кажущимися самыми модными», но в большинстве форм, которые я видел, представленная идея примерно эквивалентна простому отказу от использования смарт-контракта.

Ответы (1)

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

  • Кто может обновить?
    • никто - невозможно обновить/развить, так как код высечен в камне(e.g.: trust++, complexity++, maintainability--)
    • только владелец - участники вынуждены принять изменение(e.g.: trust--, complexity+, maintainability++)
    • через голосование - участники голосуют за изменение(e.g.: trust+, complexity-, maintainability++)
  • Активация изменения?
    • немедленный
    • отложено
  • Отказаться от изменений?
    • да?
    • нет?
хороший ответ. есть ли какая-либо официальная документация по этому поводу или какие-либо хорошие примеры, где это исследуется? В любом случае это помогает знать его конфигурируемость.
Я не знаю документа, систематически анализирующего аспекты возможности обновления. Хорошо бы почитать. Ответ выше основан на моем опыте и наблюдениях.