Монолитные смарт-контракты лучше, чем те, которые отделены?

Приложение смарт-контракта, которое я пишу, следует тому, что я считаю хорошей практикой - оно развязано, так что контракт с контроллером называет логический контракт, который называет контракт на хранение. Поэтому Contract A вызывает Contract B вызывает Contract C.

Однако мне интересно, из-за безопасности такая развязка - хорошая идея для смарт-контрактов. Это потому, что мне нужен модификатор onlyOwner, который вызывает мои функции (как описано здесь: https://github.com/ethereum/wiki/wiki/Solidity-Features ). На мой взгляд, было бы здорово, если бы я мог сделать что-то вроде этого:

import "Owned.sol";

contract A is Owned {

   B private b;

   function A(address B) {
       b = B(b);
   }

   function myInterface() public onlyOwner {
       a.doStuff({from: msg.sender});
   }
}

contract B is Owned {

   C private c;

   function B(address c) {
       c = C(c);
   }

   function doStuff() public onlyOwner {
       c.store(42,{from: msg.sender});
   }
}

contract C is Owned {

   int private theAnswer;

   function store(int value) public onlyOwner {
       theAnswer = value
   }
}

Однако, я считаю, что я не могу отправить msg.sender таким образом. Следовательно, я бы лучше соединил Contract A, Contract B и Contract C в один монолитный контракт, где msg.sender является действительным?

6 голосов | спросил glowkeeper 25 +03002016-10-25T22:09:47+03:00312016bEurope/MoscowTue, 25 Oct 2016 22:09:47 +0300 2016, 22:09:47

1 ответ


3

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


Что касается решений: возможно, расширение Owned до Authable с помощью:

    mapping (address => bool) public authorised литий> modifier onlyAuthed {...} литий> function authAdd (address _addr) public onlyOwner {...} литий> function authRem (address _addr) public onlyOwner {...} литий>

... и затем используйте Authed + onlyAuthed вместо Owned + onlyOwner в производных dapps? ..

Затем вы можете развернуть куски самостоятельно. Когда есть «полная цепочка», которая может быть связана (например, A->B->C[several]), вы можете вызвать C.authAdd(<address-of-B>) из вашей учетной записи owner.

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

Схема может быть изменена в соответствии с конкретными потребностями.


В качестве альтернативы вы можете использовать Собственный Zeppelin и его transfer().

Это будет работать нормально, если:

  • «цепочка собственности» является линейной, то есть нет случая, когда dapp может быть вызван несколькими другими; и
  • сохранение первоначального права собственности (посредством развертывающей учетной записи) не требуется (например, для целей nuking).

EDIT:

Затем вы можете переместить b = B(b) из конструктора в отдельную функцию (например, function createChildren(...) public onlyOwner onlyOnce {...}) и добавьте способ распространения запроса уже созданным детям (например, function nagForGrandChildren(...) public onlyOwner {...}). Но проблема остается: если nFGC() попадает в предел блока газа, вызов функции должен быть повторен - срабатывает из исходного внешнего owner A.

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

ответил Noel Maersk 9 32016vEurope/Moscow11bEurope/MoscowWed, 09 Nov 2016 01:10:09 +0300 2016, 01:10:09

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

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

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