Дочерний контракт против структуры

Допустим, мне нужно хранить и обрабатывать набор сложных данных в смарт-контракте. Там могут быть сложные правила, определяющие, кто и как может изменить элемент. В коллекции может быть несколько миллионов предметов.

Есть 2 способа реализации этой логики

  1. Использование дочернего контракта:
контракт DataItem {
    ключ байт32;
    строковое значение;

    функция DataItem (bytes32 k, строка v) {
        ключ = к;
        значение = v;
    }
}
контракт DAppInterface {
    отображение (bytes32 => адрес) общедоступных элементов данных;

    function addDataItem (bytes32 k, string v) external {
        dataItems[k] = новый DataItem(k, v);
    }
}
  1. Использование структуры:
контракт DAppInterface {

    структура DataItem {
        ключ байт32;
        строковое значение;
    }

    отображение (bytes32 => DataItem) общедоступных элементов данных;

    function addDataItem (bytes32 k, string v) external {
        dataItems[k].key = k;
        dataItems[k].value = v;
    }
}

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

Ответы (1)

В большинстве случаев структуры данных, даже сложные, должны быть структурами.

Вот несколько причин для выбора структур:

  • Контракты дороже. Сначала вам придется заплатить за создание контракта, и каждый раз, когда вы обращаетесь к нему, вам нужно будет платить за вызов других контрактов. Это намного, намного дороже, чем sha3 для поиска внутри собственного хранилища контракта.
  • Контракты должны воспроизводить код. Каждый контракт должен содержать логику установки и изменения значений, за которые вы должны платить газом. Структуре нужен только набор функций.
  • Контракты выставлены. Любой желающий может отправить сообщение контракту. Если вы используете контракт для хранения структур данных, вам придется управлять доступом вручную.
  • Библиотеки могут быть тем, что вы на самом деле ищете. Если вы обнаружите, что ищете функции в структуре данных (т.е. foo.bar()), вы можете использовать библиотечный контракт , чтобы сделать это без дополнительной сложности создания контрактов для каждого экземпляра.

Вот несколько причин, по которым контракты были бы лучше:

  • Контракты могут быть полиморфными. Контракт потенциально может содержать произвольный код. Это позволяет смешивать несколько типов или даже предлагать пользователям свою собственную логику.
  • Логика будет разделена. В этом договоре с регистратором каждый акт мог быть структурой. Делая Deeds своими собственными контрактами, у самих Deed меньше возможностей для атаки, что снижает вероятность еще одной катастрофы масштаба TheDAO.
  • Контракты выставлены. Если пользователям необходимо настроить свои структуры данных, наличие уникального адреса, с которым они могут взаимодействовать напрямую, может оказаться проще.
  • Контракты есть контракты. Дочерний контракт может делать все, что может делать контракт. Если структуры данных по какой-то причине будут владеть вещами, как адрес, то наличие контракта будет намного лучше. Контракт может напрямую хранить эфир, в отличие от структуры, разделяющей баланс основного контракта с другими структурами.

Однако они менее распространены. Мой совет: сначала попробуйте со структурами, а в крайнем случае используйте контракты структур данных.

Может ли количество транзакций и объем данных, хранящихся в контракте, повлиять на решение об использовании дочернего контракта или структуры? Скажем, у меня есть аукцион DApp, где каждый предмет для продажи будет иметь ряд связанных с ним транзакций (ставки, оплата, добавленная информация о доставке и т. д.). Это DApp можно реализовать с помощью структур и одного контракта. Но в этом случае будет много транзакций, выполняемых одновременно с этим контрактом, и хранилище для этого контракта будет расти очень быстро. Дочерний контракт позволит изолировать транзакции и хранение проданного товара.
В текущей версии Ethereum нет одновременных транзакций (предполагается, что это изменится). Будь то один контракт или несколько, транзакции все равно происходят по одной. Точно так же одна и та же сумма хранится как в одном контракте, так и в нескольких (кроме накладных расходов). После определенного уровня сложности индивидуальный контракт начинает иметь смысл. Если каждый аукцион представляет собой отдельный контракт, вам будет намного проще работать, например, с балансами пользователей.
Что нужно знать, если использование дочернего контракта будет лучше с точки зрения возможности обновления? Поскольку макет структуры данных не привязан к одному контракту, мы можем обновить что угодно.
Дочерний контракт против структуры
СпросиСетьПолитика конфиденциальности1y, 0v