由于其时的区块 gas 限制无法支持这种局限的智能合约，所以这项改变其时并没有受到重视：
更为完善的例子——Yield
Solidity 在合约层面利用了面向工具的编程技能。我们可以将合约看作是一个具有变量和函数的“工具”，在脑海中将巨大的区块链应用措施想象成多个合约的荟萃，每个合约代表一个单独的实体。
配景常识
从简朴的例子开始——Uniswap 和 Ownable.sol
由于需要确保只有建设配对生意业务合约的工场才气对合约举办初始化，所以他们从头实施了Ownable 模式。2.wards 可以 rely 其他人（usr），并使其同样成为 watds。
巨大性和面向工具措施设计
从审核员和用户的角度出发，我们还开拓了一个收集区块链事件，并揭示合约所有权和调配图的剧本（可以在上线时通过我们的网站获取）。
如何才气确保各智能合约间的安详协作呢？
2. wards可以 rely 其他人并使其成为 wards。在 Yield 中，只有 owner 可以 orchestrate 其他地点并 authorized。
（Spurious Dragon硬分叉：https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/）
每个地点城市与一个函数签名配合注册，从而收紧对函数的会见权限，加强安详性。
“该办理方案为储存在区块链中的工具巨细配置了最高上限，并使其略高于当前gas上限值（在最坏的环境下，可以利用470万gas，23200字节来建设合约）”
此举取得的结果还不错，假如你也碰着了同样的问题，可以警惕这个要领。假如你知道本身的合约只需要给另一个合约开通会见特权的话，可以利用 Ownable.sol。甚至都用不到 Uniswap 这种工场。你可以在一个用户中陈设两个条约（Boss和Minion，Minion担任于Ownable.sol），然后执行 minion.transferOwnership(address(boss))。
譬喻，MakerDAO 的 Vat.sol 合约中的 fold 函数可被用于更新利率累加器，而且只能被其荟萃中的另一函数挪用（Jug.sol合约，drip函数）。假如我们调查一下该函数的话，便会发明用于调配的 auth 修改器，
在将代码解析为多个可操纵的合约后，我们便会发明有的合约中的函数需要通过另一个合约才气举办挪用。
譬喻，在 Uniswap v2 中，只有合约工场（contract factory）可以对 Uniswap Pair 举办初始化。（Uniswap v2：https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts）
从某种水平上来说，auth 和其他调配实现是对 private 和 internal 函数观念的扩展，仅合用于在合约间举办会见节制。
3.函数受限制（auth），因此只有 wards 可以执行受限函数。在 Yield 中，我们提到 onlyOrchestrated 地点可以挪用标志函数。进一步限制对函数的会见。
3.可以限制函数（auth），只有 wards 可以执行函数。
我们可以遵循以上尺度来实现安详有效的调配，但愿各人可以深入领略文中的示例道理，并形成适合本身的办理方案。
在没有此项限制时，进攻者可以在陈设智能合约期间举办无限次的计较。此举固然不会对存储在中的数据发生任何影响，但却是一种针对 Ethereum 节点的拒绝处事（Denial-Of-Service）进攻。
实际上，Object-Oriented Programming（面向工具措施设计）可以提高软件的巨大性。通过界说代表某种观念的“工具”，并将变量和函数看作该工具的属性，开拓人员可以或许在心里更好地描绘和领略需要办理的问题。
实现
Yield 的办理方案就没有 Uniswap v2 那么简朴了。其焦点由五个合约构成，而且特权会见干系并不是一一对应的。部门合约具备的限制成果可以辅佐我们会见其他焦点合约。
因此，我们只需扩展 Ownable.sol 以生成两个会见层，个中一层有多个成员：在相识问题和开拓模式的进程中，我们深入领略了如何借助多个智能合约来构建应用措施，从而使 Yield 越发结实且安详。
我们本身的平台代币 yDai，将从 Orchestrated 担任并限制 mint 在 owner 放弃其特权之前成立的特定合约：
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
