为什么和如何“低安全”功能影响最大的多重签名合同？

Question

人们每天都使用这个合同，http://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol，它也是目前大多数空想的合同。

此外，您还可以使用此合同源代码在官方上创建一个multisig帐户。

但是当我进入站点https://etherscan.io/address/0xab7c74abc0c4d48d1bdad5dcb26153fc8780f83e#code时，我们收到了所有这些警告，说明安全性很低。

警告:编译后的契约可能容易受到ZeroFunctionSelector (非常低严重性)、DelegateCallReturnValue (低严重性)、ECRecoverMalformedInput (中度严重性)、SkipEmptyStringLiteral (低严重性)、IdentityPrecompileReturnIgnored (低严重性)、HighOrderByteCleanStorage (高严重性)、SendFailsForZeroEther (低严重性)、DynamicAllocationInfiniteLoop (低严重度)、CleanBytesHigherOrderBits (中/高严重性)、CleanBytesHigherOrderBits(中/高严重度)、HighOrderByteCleanStorage(高严重性)、SendFailsForZeroEther(低严重性)、DynamicAllocationInfiniteLoop(低严重性)、CleanBytesHigherOrderBits(中/高严重性)、IdentityPrecompileReturnIgnored(低严重性)、HighOrderByteCleanStorage(高严重性)、SendFailsForZeroEther(低严重性)、DynamicAllocationInfiniteLoop(低严重性)、CleanBytesHigherOrderBits(中/高严重度)、HighOrderByteCleanStorage(高严重性)、SendFailsForZeroEther(低严重性)、DynamicAllocationInfiniteLoop(低严重性)、CleanBytesHigherOrderBits(中/高严重度)、HighOrderByteCleanStorage(高严重性)、SendFailsForZeroEther(低严重性)、DynamicAllocationInfiniteLoop(低严重性)、CleanBytesHigherOrderBits(中/高严重度)、HighOrderByteCleanStorage(高严重性)、SendFailsForZeroEther(低严重性)

作为一个投资者(以及一个还没有完全学习到稳健性的程序员)，我应该如何使用这一点呢？当然，我听说过奇偶攻击，这让黑客可以自由地只拿30百万美元。

我的问题是:我应该担心吗？我应该注意和注意什么呢？

更新：

我明白你的意思，但我可以看到基本的稳固性，我看不到任何“内部”功能或“守卫”，这是在他们被利用后以平等的方式实施的。

但在这里，我有一个更深入的分析，通过稳健混合模拟器声明重新进入漏洞：https://imgur.com/a/d3x8J。

更新2:

您说过，更高的编译器版本更好，所有使用该代码的契约(我说的是Ethereum钱包中使用的代码)都使用版本0.3.2！0.3.2！那是2016年开始的！

Answer 1

整个观音生态系统正处于起步阶段。错误是可以预料的，但如果涉及到大量的金钱，当然不应容忍错误。

基本上有两种类型的漏洞可能导致资金被盗：

1. 程序员的错误--例如，重新进入的漏洞过去是很常见的.今天，大多数DApp开发人员都意识到了这一点，并且不会犯这个错误。现在，大多数错误都是特定于某个应用程序的逻辑的。只有通过正式的验证、广泛的代码评审和/或时间和金钱的测试，你才能确保没有任何问题。
2. 编译器错误--这是Solidity编译器开发人员所犯的错误。对于DApp开发人员来说，它们几乎是不可能检测或做任何事情的。一旦使用bug编译了智能契约并将其部署到区块链上，bug就会继续存在。合同部署是最终的。重要的是要注意的是，仅仅因为一个编译器有一个bug，这并不意味着所有使用该编译器编译的契约都有一个bug。编译器错误只会在罕见的情况下产生任何负面影响。(否则，在包含错误的编译器版本发布之前，很久以前就已经检测到了它们)

您不应该太注意etherscan.io给出的所有警告。他们只需查看使用了哪个编译器版本，并给出该编译器版本的所有已知错误列表。他们并不是真的对每一份合同都做了深入的分析。很有可能，你正在看的合同没有受到这些错误的影响。

至少在基本水平上学习稳健性是个好主意，只需要阅读代码就可以看出没有明显的错误发生。像重新进入漏洞这样的错误很容易被发现。除此之外，您还应该检查正在查看的特定应用程序的编程中是否存在逻辑错误。

一些一般性建议：

• 较高的编译器版本通常风险较小。
• 与审查过的源代码签订的合同通常风险较小。
• 短期合约的风险一般较小。
• 长期存在、处理大量资金、未被黑客入侵的合同通常风险较小。

不幸的是，对所有合同都没有任何保证。

我希望这能有所帮助。

Answer 2

这是@Jesse的一个很好的答案，但正如您所看到的，solidity编译器声明了一个可能的可重入性漏洞，但是这只是通过静态分析，编译器不检查修饰符。这里有一个可重入的易受攻击的函数，但它是安全的：

function reEnterMe(uint256 etherAmt) onlyOwner {
   if (balances[owner] >= etherAmt){
      owner.send(etherAmt);
      balances[owner] -= etherAmt;
   }
}

由于合同在从余额所有者映射中减去它之前发送以太，这个函数是可重入的。

但是，onlyOwner修饰符可以防止除所有者调用此契约之外的任何人，否则它将抛出。因此，这个功能是比较安全的，因为谁会想重签自己的合同呢？