обновляемые смарт-контракты с Solidity: интерфейс против библиотеки? - PullRequest
0 голосов
/ 25 апреля 2018

В контексте обновляемых интеллектуальных контрактов когда следует использовать интерфейсы, а когда библиотеки ? Я прочитал несколько похожих вопросов и сообщений в блоге, но ни один из них не дает прямого ответа:

Я понимаю, что основными критериями, которые следует учитывать (помимо безопасности) при проектировании для обновляемости, являются:

  • модульность - для возможности повторного использования и упрощения обслуживания
  • газовый лимит - разбить огромные контракты, чтобы их можно было использовать в нескольких транзакциях, чтобы не превышать газовый лимит
  • стоимость обновления - сколько стоит каждое обновление контракта. После (небольшого) изменения в одном контракте, какие другие контракты должны быть повторно развернуты?
  • стоимость исполнения - отдельные контракты могут привести к накладным расходам газа при каждом вызове. Старайтесь держать это над головой низко.

В этом посте Medium предлагается использовать библиотеки для инкапсуляции логики (например, при взаимодействии с «договорами хранения») и использовать интерфейсы для отделения межконтрактной связи. Другие посты предлагают разные методы. Насколько я понимаю, библиотеки связаны с контрактами до развертывания, поэтому, как только контракт меняется, библиотеки должны быть повторно развернуты. Почему не лучше использовать интерфейсы для взаимодействия с договорами хранения?

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

Решение с библиотекой

StorageWithLib.sol

contract StorageWithLib {
    uint public data;

    function getData() public returns(uint) {
        return data;
    }
}

StorageLib.sol

import './StorageWithLib.sol';

library StorageLib {

    function getData(address _storageContract) public view returns(uint) {
        return StorageWithLib(_storageContract).getData();
    }
}

ActionWithLib.sol

import './StorageLib.sol';

contract ActionWithLib {
    using StorageLib for address;
    address public storageContract;

    function ActionWithLib(address _storageContract) public {
        storageContract = _storageContract;
    }

    function doSomething() public {
        uint data = storageContract.getData();
        // do something with data ...
    }
}

Решение с интерфейсом

IStorage.sol

contract IStorage {     
    function getData() public returns(uint);
}

StorageWithInterface.sol

import './IStorage.sol';

contract StorageWithInterface is IStorage {
    uint public data;

    function getData() public returns(uint) {
        return data;
    }
}

ActionWithInterface.sol

import './IStorage.sol';

contract ActionWithInterface {
    IStorage public storageContract;

    function ActionWithInterface(address _storageContract) public {
        storageContract = IStorage(_storageContract);
    }

    function doSomething() public {
        uint data = storageContract.getData();
        // do something with data ...
    }   
}

Учитывая вышеупомянутые критерии, какое решение предпочтительнее для разделения хранилища и логики и почему ? В каких других случаях другое решение лучше?

Ответы [ 2 ]

0 голосов
/ 28 апреля 2018

Библиотеки и интерфейсы действительно разные и используются в разных случаях.Лично я не вижу их взаимозаменяемости в проекте контракта.Ниже я попытался обрисовать ключевые характеристики двух.Обратите внимание, что под interface я подразумеваю абстрактный контракт (это то, что вы имеете в своем примере выше).В Интерфейсах в Солидности все еще есть проблемы, которые я выделил здесь ранее https://medium.com/@elena_di/hi-there-answers-below-6378b08cfcef

Библиотеки :

  • Может содержать логику и использоваться дляизвлекать код из контракта для удобства сопровождения и повторного использования

  • Развертывается один раз, а затем упоминается в контрактах.Их байт-код развернут отдельно и НЕ является частью контрактов, которые на них ссылаются.Это определено как одноэлементное в моей статье выше («Написание обновляемых контрактов в Солидности»), где я объясняю такие преимущества, как более низкая стоимость развертывания.

Абстрактные контракты / Интерфейсы

  • Cannon содержит определение логического интерфейса

  • В основном используется для импорта в другие контракты, обеспечивающие взаимодействие с реализациями контрактов.Интерфейсы имеют гораздо меньший размер развертывания / импорта, чем контракт на реализацию

  • Предоставьте абстракцию для возможности обновления, которую я также описал в своей статье в разделе «Использование« интерфейсов »для разделения взаимодействия.контрактное общение "

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

0 голосов
/ 26 апреля 2018

Я надеюсь, что кто-то может придумать лучший ответ, но это хороший вопрос, и он хотел высказать свое мнение.

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

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

Это не означает, что библиотеки вообще бесполезны. Я часто их использую для повторного использования кода для общих структур данных или операций (например, поскольку итерации в Solidity - это боль, у меня есть библиотека для использования в качестве основной итерируемой коллекции). Я просто не вижу особой ценности в их использовании для интеграции моего договора хранения. Мне любопытно посмотреть, есть ли у экспертов Solidity другое мнение.

...