Обновляемые смарт-контракты в сети Ethereum

    Мотивация


    Контракты сети Ethereum иммутабельны – единожды загруженные в сети (блокчейн), они не могут быть изменены. Специфика бизнеса или разработки могут потребовать обновить код, но при традиционном подходе это становится проблемой.


    Популярные причины необходимости обновления


    • Ошибки в коде
    • Изменение бизнес требований
    • Принятие предложений сообщества об изменении работы контракта

    Описание технического решения


    Реализация требуемого функционала — обновление кода, планируется через разделение кода на составляющие:


    1. Данные — смарт-контракты без логики и предоставляющие исключительно пространство для хранения данных;
    2. Бизнес-логика — смарт-контракты описывающие логику извлечения данных из хранилища и их изменения;
    3. Входные точки — иммутабельные контракты ведут учет обновления бизнес-логики и предоставляют конечному пользователю ссылку на актуальный контракт бизнес-логики

    Обновляемый смарт-контракт счетчика


    Представим абстрактный оторванный от реальности пример – счетчик с обновляемой логикой увеличения.


    • Стадия 1. С каждым вызовом счетчик увеличивается на 1
    • Стадия 2. С каждым вызовом счетчик увеличивается на 10

    При традиционном подходе и изначальном знании о всех стадиях, было бы необходимо сделать в счетчике поле явно указывающее текущую стадию, например: uint public currentState. При каждом вызове метода увеличения счетчика происходила бы проверка текущей стадии и выполнялся код ассоциированной с ней:


    function increaseCounter() public returns (uint) {
      if (currentState == 0) {
        value = value + 1;
      } else if (currentState == 1) {
        value = value + 10;
      }
    
      return value;
    }

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


    Хранилище


    Для реализации слоя данных хранящего текущее значение счетчика и отделенного от бизнес-логики, создаем контракт – ~/contracts/base/UIntStorage.sol:


    Source Url


    pragma solidity ^0.4.18;
    
    contract UIntStorage {
      uint private value;
    
      function setValue(uint _value) external returns (uint) {
        value = _value;
        return value;
      }
    
      function getValue() external view returns (uint) {
        return value;
      }
    }

    Как видно из названия и реализации контракта – хранилище ничего не знает о том как его будут использовать и выполняет задачу инкапсуляции поля uint private value


    Бизнес-логика


    Договоримся, что взаимодействие с нашей бизнес-логикой будет осуществляться через два метода: increaseCounter и getCounter для увеличения счетчика и получения текущего значения соответственно, о чем явно опишем в интерфейсе – ~/contracts/examples/counter/ICounter.sol:


    Source Url


    pragma solidity ^0.4.18;
    
    interface ICounter {
      function increaseCounter() public returns (uint);
      function getCounter() public view returns (uint);
    }

    Далее опишем смарт-контракт бизнес-логики из первой стадии реализующий ICounter интерфейс и использующий ранее описанное хранилище – ~/contracts/examples/counter/IncrementCounter.sol:


    Source Url


    pragma solidity ^0.4.18;
    
    import "./ICounter.sol";
    import "../../base/UIntStorage.sol";
    
    contract IncrementCounter is ICounter {
      UIntStorage public counter;
      function IncrementCounter(address _storage) public {
        counter = UIntStorage(_storage);
      }
      function increaseCounter() public returns (uint) {
        return counter.setValue(getCounter() + 1);
      }
      function getCounter() public view returns (uint) {
        return counter.getValue();
      }
    }

    Важно отметить, что IncrementCounter не имеет внутреннего состояния (не хранит данные), кроме ссылки на хранилище.


    Если договориться передавать в метод increaseCounter и getCounter ссылку на хранилище первым аргуметом, можно реализовать стейт-лесс бизнес-логику


    Вносим изменения в ~/contracts/examples/counter/ICounter.sol:


    Source Url


    pragma solidity ^0.4.18;
    
    interface ICounter {
      function increaseCounter(address _storage) public returns (uint);
      function getCounter(address _storage) public view returns (uint);
      function validateStorage(address _storage) public view returns (bool);
    }

    Теперь методы бизнес-логики ждут первым агрументом ссылку на хранилище, а так же реализуют метод проверки хранилища на валидность: validateStorage(address _storage)


    Внесем изменения в реализацию первой стадии – ~/contracts/examples/counter/IncrementCounter.sol:
    Source Url


    pragma solidity ^0.4.18;
    
    import "./ICounter.sol";
    import "../../base/UIntStorage.sol";
    
    contract IncrementCounter is ICounter {
      modifier validStorage(address _storage) {
        require(validateStorage(_storage));
        _;
      }
    
      function increaseCounter(address _storage) 
        validStorage(_storage) 
        public returns (uint) 
      {
        UIntStorage counter = UIntStorage(_storage);
        require(counter.isUIntStorage());
        return counter.setValue(counter.getValue() + 1);
      }
    
      function getCounter(address _storage) 
        validStorage(_storage) 
        public view returns (uint) 
      {
        UIntStorage counter = UIntStorage(_storage);
        require(counter.isUIntStorage());
        return counter.getValue();
      }
    
      function validateStorage(address _storage) 
        public view returns (bool) 
      {
        return UIntStorage(_storage).isUIntStorage();
      }
    }

    Перед переходом к реализации следующей стадии и обновлению контракта бизнес-логики, напишем пару тестов и убедимся, что бизнес-логика работает как запланировано.


    Тестирование


    Данный репозиторий является проектом фреймворка Truffle и предоставляет удобный функционал для тестирования: truffle test.


    Я не буду подробно описывать процесс написания тестов, но если эта тема вам интересна – напишите мне в телеграм @alerdenisov и я подготовлю статью с best-practice тестирования контрактов.


    ~/test/IncrementCounter.test.js:


    import expectThrow from './utils/expectThrow'
    
    const IncrementCounter = artifacts.require('./IncrementCounter.sol')
    const UIntStorage = artifacts.require('./UIntStorage.sol')
    const BoolStorage = artifacts.require('./BoolStorage.sol')
    
    contract('IncrementCounter', ([owner, user]) => {
      let counter, storage, fakeStorage
      before(async () => {
        storage = await UIntStorage.new()
        fakeStorage = await BoolStorage.new()
        counter = await IncrementCounter.new()
      })
    
      it('Should receive 0 at begin', async () => {
        const currentValue = await counter.getCounter(storage.address)
        assert(currentValue.eq(0), `Uxpected counter value: ${currentValue.toString(10)}`)
      })
    
      it('Should increase value on 1', async () => {
        await counter.increaseCounter(storage.address)
        const newValue = await counter.getCounter(storage.address)
        assert(newValue.eq(1), `Unxpected counter value: ${newValue.toString(10)}`)
      })
    
      it('Should store 1 after increment', async () => {
        const storedValue = await storage.getValue()
        assert(storedValue.eq(1), `Unxpected stored value: ${storedValue.toString(10)}`)
      })
    
      it('Should validate storage', async () => {
        await counter.validateStorage(storage.address)
      })
    
      it('Should unvalidate fake storage', async () => {
        await expectThrow(counter.validateStorage(fakeStorage.address))
      })
    })

    Запуск тестов покажет, что все "прекрасно":


      Contract: IncrementCounter
        ✓ Should receive 0 at begin
        ✓ Should increase value on 1 (63ms)
        ✓ Should store 1 after increment
        ✓ Should validate storage
        ✓ Should unvalidate fake storage
    
      5 passing (301 ms)

    Но на самом деле это не так. Допишем промежуточный тест "неавторизированного" взаимодействия с хранилищем:


      it('Should prevent non-authenticated write', async () => {
        await expectThrow(storage.setValue(100))
      })

      Contract: IncrementCounter
        ✓ Should receive 0 at begin
        ✓ Should increase value on 1 (58ms)
        1) Should prevent non-authenticated write
        2) Should store 1 after increment
        ✓ Should validate storage
        ✓ Should unvalidate fake storage
    
      4 passing (330ms)
      2 failing

    Source Url


    Владение хранилищем


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


    Основное преимущество смарт-контрактов в том, что они гарантируют участникам обмена то, что данные (состояние) не будет изменено никак иначе кроме как декларирует смарт-конракт. Но сейчас изменения ничем не ограничены.


    Задача сделать так, чтобы изменять хранилище мог исключительно актуальный контракт бизнес-логики.


    Для явного ограничения взаимодействия с хранилищем, воспользуемся паттерном Ownable из фреймворка zeppelin-solidity (подробнее c паттерном можно ознакомиться в документации к фреймворку).


    Наследуем хранилище от Ownable контракта и добавим модификатор onlyOwner на метод setValue():


    Source Url


    pragma solidity ^0.4.18;
    
    import "zeppelin-solidity/contracts/ownership/Ownable.sol";
    
    contract UIntStorage is Ownable {
      uint private value;
    
      function setValue(uint _value) onlyOwner external returns (uint) {
        value = _value;
        return value;
      }
    
      function getValue() external view returns (uint) {
        return value;
      }
    
      function isUIntStorage() external pure returns (bool) {
        return true;
      }
    }

    Поздравляю, теперь в наше хранилище может писать только ассоциированный владелец хранилища! Теперь уже 3 из 6 теста проваливаются! Давайте в тестах "в ручную" передадим бизнес-логики управление хранилищем:


    Source Url


      before(async () => {
        storage = await UIntStorage.new()
        fakeStorage = await BoolStorage.new()
        counter = await IncrementCounter.new()
    
        await storage.transferOwnership(counter.address)
      })

    Теперь все тесты проходят, но встает второй вопрос: "Как управлять владением хранилища при обновлении бизнес-логики"


    Общий контроллер


    Перед реализацией общего контроллера сделаем еще один контракт счетчика, но уже второй стадии – ~/contracts/examples/counter/IncrementCounterPhaseTwo.sol:


    Source Url


    pragma solidity ^0.4.18;
    
    import "./IncrementCounter.sol";
    
    contract IncrementCounterPhaseTwo is IncrementCounter {
      function increaseCounter(address _storage) 
        validStorage(_storage) 
        public returns (uint) 
      {
        UIntStorage counter = UIntStorage(_storage);
        return counter.setValue(counter.getValue() + 10);
      }
    }

    Теперь когда у нас есть две реализации счетчика и Ownable хранилище, становится понятно, что необходимо как-то "просить" одну реализацию отдать другой управление хранилищем. Добавим метод transferStorage(address _storage, address _counter) в интерфейс счетчиков – ~/contracts/examples/counter/ICounter.sol:


    Source Url


    pragma solidity ^0.4.18;
    
    interface ICounter {
      function increaseCounter(address _storage) public returns (uint);
    
      function getCounter(address _storage) public view returns (uint);
    
      function validateStorage(address _storage) public view returns (bool);
    
      function transferStorage(address _storage, address _counter) public returns (bool);
    }

    Договоримся, что финальная реализация ICounter должна после вызова метода transferStorage отдавать управление хранилищем адресу переданному в параметр _counter:


    Source Url


      function transferStorage(address _storage, address _counter) validStorage(_storage) public returns (bool) {
        return UIntStorage(_storage).transferOwnership(_counter);
      }

    Давайте допишем тесты передачи прав новой логике и проверим результат increaseCounter метода после смены логики:


      it('Should transfer ownership', async () => {
        await counter.transferStorage(storage.address, secondCounter.address);
      })
    
      it('Should reject increase from outdated counter', async () => {
        await expectThrow(counter.increaseCounter(storage.address));
      })
    
      it('Should increase counter with new logic', async () => {
        await secondCounter.increaseCounter(storage.address)
        const newValue = await secondCounter.getCounter(storage.address)
        assert(newValue.eq(11), `Unxpected counter value: ${newValue.toString(10)}`)
      })

    Выполнение тестов может дать ложное ощущение, что все работает:


      Contract: IncrementCounter
        ✓ Should receive 0 at begin
        ✓ Should increase value on 1 (75ms)
        ✓ Should prevent non-authenticated write
        ✓ Should store 1 after increment
        ✓ Should validate storage
        ✓ Should unvalidate fake storage
        ✓ Should transfer ownership
        ✓ Should reject increase from outdated counter
        ✓ Should increase counter with new logic (47ms)
    
      9 passing (500ms)

    Но спешу вас огорчить, эти изменения опять открыли зеленный свет злоумышленикам:


      it('Should reject non-authenticated transfer storage', async () => {
        await expectThrow(secondCounter.transferStorage(storage.address, user, { from: user }))
      })
    
      it('Should reject increase from user fron previous test', async () => {
        await expectThrow(storage.setValue(100500, { from: user }))
      })
    
      it('Should store 11 as before', async () => {
        const storedValue = await storage.getValue()
        assert(storedValue.eq(11), `Unxpected stored value: ${storedValue.toString(10)}`)
      })

      Contract: IncrementCounter
        ✓ Should receive 0 at begin (46ms)
        ✓ Should increase value on 1 (55ms)
        ✓ Should prevent non-authenticated write
        ✓ Should store 1 after increment
        ✓ Should validate storage
        ✓ Should unvalidate fake storage
        ✓ Should transfer ownership
        ✓ Should reject increase from outdated counter
        ✓ Should increase counter with new logic (46ms)
        1) Should reject non-authenticated transfer storage
        2) Should reject increase from user fron previous test
        3) Should store 11 as before
    
      9 passing (611ms)
      3 failing

    Основная задача общего контроллера будет управлять передачей прав и не допускать кого-угодно к этому процессу. Сначала изменим IncrementCounter по аналогии с UIntStorage, чтобы он тоже наследовал логику Ownable и ограничивал взаимодействие с хранилищем:


    Source Url


    pragma solidity ^0.4.18;
    
    import "./ICounter.sol";
    import "../../base/UIntStorage.sol";
    
    contract IncrementCounter is ICounter, Ownable {
      modifier validStorage(address _storage) {
        require(validateStorage(_storage));
        _;
      }
    
      function increaseCounter(address _storage) 
        onlyOwner validStorage(_storage) 
        public returns (uint) 
      {
        UIntStorage counter = UIntStorage(_storage);
        require(counter.isUIntStorage());
        return counter.setValue(counter.getValue() + 1);
      }
    
      function getCounter(address _storage) 
        validStorage(_storage) 
        public view returns (uint) 
      {
        UIntStorage counter = UIntStorage(_storage);
        require(counter.isUIntStorage());
        return counter.getValue();
      }
    
      function validateStorage(address _storage) 
        public view returns (bool) 
      {
        return UIntStorage(_storage).isUIntStorage();
      }
    
      function transferStorage(address _storage, address _counter)
        onlyOwner validStorage(_storage) 
        public returns (bool) 
      {
        UIntStorage(_storage).transferOwnership(_counter);
        return true;
      }
    }

    Приступим к реализации контроллера. Основные требования к контроллеру:
    1) Учет текущей реализации счетчика
    2) Обновление реализации счетчика
    2) Перемещение прав на хранилище при обновлении реализации
    3) Отклонение попыток неавторизированного обновление реализации


    ~/contracts/examples/counter/CounterContrller.sol:


    Source Url


    pragma solidity ^0.4.18;
    
    import "zeppelin-solidity/contracts/ownership/Ownable.sol";
    import "./ICounter.sol";
    import "../../base/UIntStorage.sol";
    
    contract CounterController is Ownable {
      UIntStorage public store = new UIntStorage();
    
      ICounter public counter;
    
      event CounterUpdate(address previousCounter, address nextCounter);
    
      function updateCounter(address _counter) 
        onlyOwner
        public returns (bool) 
      {
        if (address(counter) != 0x0) {
          counter.transferStorage(store, _counter);
        } else {
          store.transferOwnership(_counter);
        }
    
        CounterUpdate(counter, _counter);
        counter = ICounter(_counter);
      }
    
      function increaseCounter() public returns (uint) {
        return counter.increaseCounter(store);
      }
    
      function getCounter() public view returns (uint) {
        return counter.getCounter(store);
      }
    }

    increaseCounter и getCounter не более, чем просто внешние методы взаимодействия с аналогичными в текущей реализации ICounter. Вся логика контроллера находится в небольшом методе: updateCounter(address _counter).


    Метод updateCounter принимает адресс на реализацию счетчика и перед установкой его как адреса новой реализации счетчика? передает ему права на хранилище (от себя или от предыдущей в зависимости от состояния).


    Помните про третью стадию? Я опущу код ее реализации, тем более, что отличается от второй только одной строчкой. Просто скажу, что в третьей стадии счетчик будет увеличивать значение умножением на самого себя: value = value * value.


    Давайте напишем немного тестов и убедимся, что контроллер работает и выполняет поставленные перед ним задачи:


    import expectThrow from './utils/expectThrow'
    
    const IncrementCounter = artifacts.require('./IncrementCounter.sol')
    const IncrementCounterPhaseTwo = artifacts.require('./IncrementCounterPhaseTwo.sol')
    const MultiplyCounterPhaseThree = artifacts.require('./MultiplyCounterPhaseThree.sol')
    const CounterController = artifacts.require('./CounterController.sol')
    const UIntStorage = artifacts.require('./UIntStorage.sol')
    
    contract('CounterController', ([owner, user]) => {
      let controller, counterOne, counterTwo, counterThree, storage
    
      before(async () => {
        controller = await CounterController.new()
        storage = UIntStorage.at(await controller.store())
        counterOne = await IncrementCounter.new()
        counterTwo = await IncrementCounterPhaseTwo.new()
        counterThree = await MultiplyCounterPhaseThree.new()
    
        await counterOne.transferOwnership(controller.address)
        await counterTwo.transferOwnership(controller.address)
        await counterThree.transferOwnership(controller.address)
      })
    
      it('Shoult create storage', async () => {
        assert(await storage.isUIntStorage(), 'Controller doesn\'t create proper storage')
      })
    
      it('Should change counter implementation', async () => {
        await controller.updateCounter(counterOne.address)
        assert(await controller.counter() === counterOne.address, `Unxpected counter in controller (${await controller.counter()} but expect ${counterOne.address})`)
      })
    
      it('Should increase counter on 1', async () => {
        await controller.increaseCounter()
        const value = await controller.getCounter()
        assert(value.eq(1), `Unxpected counter value: ${value.toString(10)}`)
      })
    
      it('Should update counter', async () => {
        await controller.updateCounter(counterTwo.address)
        assert(await controller.counter() === counterTwo.address, `Unxpected counter in controller (${await controller.counter()} but expect ${counterTwo.address})`)
      })
    
      it('Should increase counter on 10 after update', async () => {
        await controller.increaseCounter()
        const value = await controller.getCounter()
        assert(value.eq(11), `Unxpected counter value: ${value.toString(10)}`)
      })
    
      it('Should reject non-authenticated update', async () => {
        await expectThrow(controller.updateCounter(counterTwo.address, { from: user }))
      })
    
      it('Should update on phase three and increase counter to 11*11 after execution', async () => {
        await controller.updateCounter(counterThree.address)
        await controller.increaseCounter()
        const value = await controller.getCounter()
        assert(value.eq(121), `Unxpected counter value: ${value.toString(10)}`)
      })
    })
    

      Contract: CounterController
        ✓ Shoult create storage
        ✓ Should change counter implementation (53ms)
        ✓ Should increase counter on 1 (52ms)
        ✓ Should update counter (55ms)
        ✓ Should increase counter on 10 after update (56ms)
        ✓ Should reject non-authenticated update
        ✓ Should update on phase three and increase counter to 11*11 after execution (89ms)
    
      7 passing (684ms)

    Как видите контроллер свою задачу выполняет, а код нашего счетчика стал обновляемым.


    Резюме


    Не смотря на абстрактность (и абсурдность) примера, подход можно применять в реальных контрактах. Например, для обеспечения обновляемости игровой логики в проекте Evogame, я использую данный подход в контрактах реализующих карты монстров, логику боя и т.д.


    Но у данного подхода есть ряд существенных недостатков и комментариев:


    • Увеличивается стоимость транзакций (объем потребляемого газа), но не значительно. Если есть желающие провести подсчеты – буду признателен или ожидайте в ближайшем будущем от меня.
    • Появляется роль администратора, но решается передачей прав на контроллер смарт-контракту децентрализованного голосования за принятие обносвлений
    • Сложность проектирования, писать код в одном монолитном контексте в разы проще и требует меньше внимания к потокам данных и сообщений. Реализация state-less требует еще большего внимания от разработчика. Решается вызовом реализации через delegatecall. Напишите мне если нужно написать продолжение с передачей состояния через delegatecall.

    UPD:
    @dzentota в телеграм обсуждении отметил недоработку: лишний вызов isUIntStorage() в методах IncrementCounter. (Исправление)[https://github.com/alerdenisov/upgradable-contracts/blob/master/contracts/examples/counter/IncrementCounter.sol]

    • +16
    • 7,5k
    • 2
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 2

      0
      А что это за evogame? Типа котиков?
        0
        Card Collective Game on Blockchain

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое