Are Monolithic Smart Contracts Better than Those That Are Decoupled?

Question

The smart contract app I am writing follows what I consider good practice - it is decoupled so that a controller contract calls a logic contract which calls a storage contract. So Contract A calls Contract B calls Contract C.

However, I'm wondering if, because of security, such decoupling is a good idea for smart contracts. That's because I need the onlyOwner modifier to tie down who calls my functions (as describe here: https://github.com/ethereum/wiki/wiki/Solidity-Features). To my mind, it would be great if I could do something like this:

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
   }
}

However, I believe I can't send msg.sender that way. Hence, would I be better bundling Contract A, Contract B and Contract C into a single monolithic contract where msg.sender is valid?

Answer 1

In the comments to your original post, you have estabilished that deployment of a large monolithic contract may fail due to the block gas limit being reached. A dapp that can't be deployed can't be better. :)

---

As to solutions: maybe extend Owned to Authable with:

• mapping (address => bool) public authorised
• modifier onlyAuthed {...}
• function authAdd (address _addr) public onlyOwner {...}
• function authRem (address _addr) public onlyOwner {...}

... and then use Authed+onlyAuthed instead of Owned+onlyOwner in derived dapps?..

You could then deploy the pieces independently. Once there is a "full chain" that can be linked (such as A->B->C[several], you can call C.authAdd(<address-of-B>) from your owner account.

This is a bit tedious, but relatively easy to automate. In addition to that, you don't have to worry about the order of deployment, or whether some dapps fail to deploy.

The scheme can be modified to suit particular needs.

---

As an alternative, you could use Zeppelin's Ownable and its transfer() function.

This would work fine if:

• the "ownership chain" is linear, i.e. no case where a dapp could be called by several others; and
• retaining original ownership (by the deploying account) is not needed (e.g. for nuking purposes).

---

EDIT:

Then again, you could move b = B(b) out of the constructor to a separate function (like function createChildren(...) public onlyOwner onlyOnce {...}), and add some way to propagate the request to already-created children (like function nagForGrandChildren(...) public onlyOwner {...}). But the issue remains: if nFGC() hits the block gas limit, the function call will have to be repeated - triggered from the original external owner account of A.

One way or another, you'll need to foresee that some part of your chain will fail to deploy. The choice here is between "something down the line" or "anything in between".