如何在以太坊伊斯坦布尔软末端之后维护你的智能合约不被交接反击。将要于12月初发售的伊斯坦布尔软末端还包括EIP1884：“容许trie大小有关的操作码”。关键字是“容许”，这意味著某些指令现在将花费更好的气体来继续执行。

最近回应展开了很多辩论的原因是现有的可以少量气体运营代码，软末端后有可能多达该容许，并造成不会经常出现“out of gas”错误。“以少量气体运营代码”的一个特例是任何Solidity智能合约中的fallback函数，因为它是由Solidity的transfer函数或Solidity和Vyper的send函数启动时的以太坊传送过程中运营的代码。

transfer和send都只容许以太坊的接收者以2300的气体（实质上是零）。伊斯坦布尔到末端后，相似此容许的fallback函数可能会暂停工作，而任何调用这些函数的智能合约都将在受限的气体中暂停工作。

出于安全性原因，到目前为止，引荐用于transfer和send来传输Ether。它们所容许的气体足以展开轻进反击，因此有论据指出，它将维护智能合约免遭它们的侵犯。显然有……但是以太坊开发者社区现在于是以面对这样一个现实，即操作码定价无法被指出是平稳的，并且如果我们期望建构面向未来的系统，我们应当谋求其他确保安全的方法。即我们应当停止使用transfer，而转而用于其他发送到以太网的方法，而不应倚赖其他安全性技术来避免轻进反击。

本文讲解了可交接性，目前可用作根据它取得智能合约的技术，以及如何用于OpenZeppelin合约精彩在项目中构建它们。尤其值得一提的是我们还没提及的一种技术：付款缴纳法(pull payments)。什么是可交接反击？智能合约在长时间继续执行期间可以通过继续执行函数调用或非常简单地移往以太坊来继续执行对其他智能合约的调用。这些智能合约本身可以称作其他智能合约。

尤其是它们可以消息传递到调用他们的智能合约或消息传递栈中的任何其他智能合约。在这种情况下，我们说道智能合约被新的输出，这种情况被称作可交接性。轻进本身不是问题。当智能合约以“不完全一致”状态新的输出时，就不会经常出现问题。

当智能合约特定的不变量正式成立时，状态被指出是完全一致的。例如对于ERC20主要不变性是所有智能合约余额的总和不多达未知的总供应量。一般来说函数假设它们开始运行时之后以完全一致的状态仔细观察智能合约，并且它们还允诺一旦已完成运营就使智能合约保持一致。

在继续执行过程中，可能会违背不变量，这很好，只要没有人能仔细观察到不完全一致的状态。问题在于通过轻进，这沦为有可能。函数已完成时，不仅要维持不变量，还必需在每个潜在的交接点维持恒定。

当我们调用不不受信任的智能合约或将资金转至不不受信任的帐户时，网卓新闻网，我们的代码更容易受到轻进反击的反击。可以对这些帐户展开类似编程，以在交接调用期间欺诈恒定违规。这里的恒定之处在于，智能合约中的资金额相等余额同构中所有条目的总和。

在第三行继续执行调用期间，由于_amount资金已转出有，但余额仍未改版，因此不变量被毁坏了。由于msg.sender可以是智能合约，因此同一调用容许轻进。如果攻击者此时启动时了交接，他们将需要从碎裂的不变量中利润。function withdraw(uint _amount) public { if (amount = balances[msg.sender]) {msg.sender.call.value(_amount)();balances[msg.sender] -= _amount; }}现在，我们将看见几种抵挡这些反击的方法。

Checks-Effects-Interactions（检查-效果-交互）我们应当提及的第一种技术称作Checks-Effects-Interactions模式。它叙述了一种在函数中的组织语句的方法，以使智能合约的状态在调至其他智能合约之前正处于完全一致的状态。通过将每个语句分类为检查，效果（状态变更）或交互作用，并保证严苛按照此顺序展开操作者来已完成此操作者。

通过在交互之前摆放效果，我们可以保证所有状态变更都在任何潜在的交接点之前已完成，从而使状态保持一致。早已对这种模式展开了很多辩论，您应当在Solidity文档中和ConsenSys的最佳实践中对其展开读者。但是我们应当对这种方法不失望，因为它更容易受到人为错误的影响：程序员必需正确地应用于它，而稿件者必需找到任何错误。否可以减低穷人的这种责任？ReentrancyGuard（轻进维护）如果在继续执行的任何时候不确认智能合约的不变量否正式成立，则不应防止调用其他（不能信）智能合约，因为它们可能会被交接。

如果我们别无选择，可以尝试用于ReentrancyGuard来避免可交接。ReentrancyGuard（轻进维护）是一段代码，当检测到轻入时，该继续执行不会造成继续执行告终。

OpenZeppelin合约中有一个称作ReentrancyGuard（轻进维护）的模式构建，该模式获取了nonReentrant修饰符。将此修饰符应用于函数将使其变成“不能轻进”，并且通过新的调用将拒绝接受新的输出该函数的尝试。

本文来源：中欧体育·(中国)zoty-www.blwebd.com