这个数字为何如此重要？这样抉择是有原因的。
MAGICCALLWITHOUTREENTRANCYEXPLOITS
首先，我们试着强制Solidity在我们的测试合约的fallback函数中利用STATICCALL：
Transfer位于转译成EVM字节码后如下：
https://github.com/ethereum/EIPs/pull/1706此刻，为了EIP-1283的重入问题而提出的办理方案是EIP-1706［5］。这个提案中的改变可以总结为：净gas值丈量带来的用度淘汰将不会在当前执行的gas limit低于2300时执行。所以，此刻这个神奇常量在以太坊共鸣协议里变得越发根深蒂固。这将会有效地迫使任何将来的EVM语言在合约挪用时也利用硬编码的2300 gas limit来防备重入进攻的危险。
凡是在合约执行的时候，一个变量会被配置成1，表白正在执行。当执行完成后，这个变量会重置成0。这样，假如你在进程中执行一个合约挪用，假如外部合约想要从头进入现有合约，这个合约会看到变量被配置成了1，然后中止执行。然而，假如有些逻辑问题导致执行竣事了变量没被重置回0会奈何？基原来说，这个智能合约就被断绝了，没法再被操纵，因为它一直认为它正在被进攻。
“payable”: false,
但我们冒充Solidity不那么糟糕，而是答允这么做。然后你就可以让Solidity利用STATICCALL向一个合约的fallback转钱，一切正常了吗？照旧不可。STATICCALL的设计很有些非凡。虽然，你可以在逻辑中利用fallback函数，可是STATICCALL的设计用意是答允外部合约挪用而没有副浸染，只返回计较功效的数据。Fallback函数实际上没有返回数据的观念，固然假如你下降到挪用者和被挪用者的汇编层面来看这可以实现。所以，，STATICCALL在这个场景下没什么用，除非你在做什么很少见的操纵。可是假如你要做些不常见的工作，为什么不写一个通例的函数挪用而要用fallback函数呢？好吧，我有些跑题。
这会在当前合约已经在挪用栈里时遏制执行。这个成果只需要一个老道的开拓者事情一晚上就能完成，然后再需要一个白日做安详性测试。这会答允在防备重入进攻时不会涉及到存储，而且能用如下的简朴代码很是低费地实现if callstack.exists(currentAddress) then throw可是说返来，我以为这样一个不足“纯粹”的opcode永远不会被思量采用进以太坊。
并且，有趣的是，并没有明晰的“non-payable“要害字来明晰地标识一个函数为non-payable。让我们从fallback函数里去除view要害字，查抄这个ABI：
“type”: “function”
https://hackernoon.com/what-is-going-on-with-the-ethereum-hard-fork-update-constantinople-f453af698c0c
你能估量到不能变动状态，因为正是从这个角度直接阻止了重入错误的产生。固然，我没预推测在日志里记录事件也被克制了。在日志里记录事件对智能合约来说没有可见的实际副浸染。一旦一个事件被记录在日志里，一个外部（或内部）的智能合约就无法看到这个状态被记录了。这完全是个空输出。你向虚空中发送了数据，可是再也不能收到那些数据，甚至不能调查到那些数据被发送过。这个副浸染只有在区块链外的世界里才可见。事件凡是被用来通知外部界面进入区块链，就像说“这儿产生了你大概会感乐趣的工作”。
{
我会怎么办理重入问题？有两个大概的方案。
动态区块链里的常量
]
诚恳说我不怎么喜欢这个办理方案。我更喜欢办理本质问题，答允重入任何智能合约。抱负环境下，可以存在一个很是简朴的opcode，就像这个：
大概的办理方案
这个神奇的假设根基上隔离了存储变得更自制的大概性，更不消提以太坊未来要修复扩展性问题以及任何此外问题。纵然有一天发现一种神奇要领能将所有存储移到链下，使存储根基免费，存储的实际gas耗费仍然不能低于2300，不然就会袒露在重入进攻的危险中。
contract Tester{
此刻以太坊上阻止重入进攻的设计险些都自己存在安详风险。
^ (Relevant source part starts here and spans across multiple lines).
}
CALL 2300, address, ….
}
4.《Constantinople enables new Reentrancy Attack》：https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9
这确实是个需要读好久的简明的名字。可是严肃的说，这个opcode的浸染与CALL根基一样，除了以下改变：
pragma solidity ^0.5.9;
KILLMEIFREENTRANT
}
“payable”: false,
· 在日志里记录事件
所以，假设以技能纯粹性的名义，STATICCALL很是严格地执行了“无副浸染”这条法则。无副浸染里的副浸染包罗了只有外部可见的副浸染。别的的结果虽然是ETH不能在STATICCALL里举办转移。这有效地冲破了它作为办理重入问题竞争者的排场。凡是来说，当挪用fallback函数时，你可能犯了错，可能想要给一个合约发送ETH。当一个合约收到ETH时，它凡是会在日志里记录一个事件来汇报外部措施”嘿，我收到了一笔钱，你大概想要对此做点什么，给谁人用户发个信息之类的”。在有神奇的2300 gas limit时，没法给另一个合约发送部门ETH，也不能变动合约内的状态，好比更新一下”估量余额“变量之类的。STATICCALL的独一用处是从你不想送出ETH的合约的广义函数哪里阻止重入进攻。
function() external view{
这曾经是防备一类被归为“重入”的智能合约裂痕最有效率的方法。重入的观念是，一个智能合约挪用另一个智能合约，最终（在同一次执行进程中）再一次挪用了本来的智能合约。重入是在污名昭著的the DAO黑客事件中被操作的主要裂痕。其时提出的办理方案不是通过改变以太坊协议来答允合约阻止这种行为，而是最终通过改变Solidity让向智能合约发送ETH的默认行为利用很是少量的gas，这样重入问题就无法再被操作。虽然，也有一个副浸染，这个改变让收钱的智能合约只能在日志里记录一个事件，而不能改变状态可能做任何此外事。
}
魔力数和STATICALL
这意味着，独一有效阻止重入进攻，又能发送ETH、答允缔造事件的方法仍然是以前的要领，利用神奇的gas limit常数——2300。这为什么会是个大问题？这并不是在说硬编码数字在计较机科学里被认为是欠好的（提示：这确实很欠好），而是说硬编码数字实际上使一些合约会在需要以太坊周围的生态情况做一些改变时变得无法运行。
“outputs”: [],
每一个利用transfer函数发送金钱的现代智能合约中（假如我没记错的话，在Solidity3.0之后），都有一个硬编码的常数——2300。譬喻在这个简朴的例子中：
}
这个reddit帖子［1］提供了一些有用的细节，指出了以太坊之前在一次进级中增加了CALL指令和一些其他指令的最小耗费（假如我没记错的话其时最小耗费是100，此刻是500）。这类记挂在将来所有gas price调解的时候多半依然合用。Nick Johnson指出“有明晰gas limit的挪用很是少有“。在这句话提出的时候，Solidity会在做与transfer相等的操纵时把所有能用的gas都转移到一个合约里，于是就留下了操作重入类操纵举办进攻的大概性。Solidity在the DAO进攻产生后引入了2300的gas limit，为了阻止产生雷同事件。此刻，公正地说，在默认环境下挪用外部合约函数（不消transfer）时，Solidity仍然会默认把所有gas都发送已往。并且文档里关于这个操纵的隐患有无数告诫。神奇的2300 gas limit常数仅仅强化了谁人reddit帖子里指出的问题。
相关阅读
STATICCALL强调的是没有副浸染。这意味着你没法做以下操纵：
},
function foo() external view{
1.Reddit帖子：https://www.reddit.com/r/ethereum/comments/57n2ql/why_i_believe_the_eip150_hardfork_may_break/
我说了许多，但这确实是个很难的问题是吧？我们正在接头区块链，有关区块链的所有技能都很难。这也是个事实，但同时，我也更倾向不认同以太坊团队在改造共鸣协议时决心强调的技能纯粹性。实际上，我以为EIP-1706因为硬编码问题不会被以太坊主网接管，它不足纯粹。我小我私家预测EIP-1283会被无限期延期，大概最终会插手到以太坊2.0内里。
browser/test.sol:4:5: TypeError: Fallback function must be payable or non-payable, but is “view”.
3.《What is going on with the Ethereum hard fork update Constantinople?》：
[
· 自我销毁一个合约
· 答允SSTORE（状态变动），就像STATICCALL那样
但最近以太坊引入了STATICCALL，作为防备重入问题的灵丹灵药。它真的是灵丹灵药么？答复是——不全是。
这个2300 gas limit假设不只仅对向后兼容性有害。它也伤害了以太坊协议内的潜在的将来创新。譬喻，EIP-1293［2］，SSTORE的净gas计量，是一个创新的协议改造，将会低落包罗存储在内的很多智能合约行为的本钱。它能使存储的gas耗费能反应出区块链上的实际耗费，这意味着当在一次执行中第二次写入一个存储键值的时候，将会耗费更少gas。这切合常理，因为从区块链的角度来看，第二次状态修改险些没有价钱，而第一次状态修改就险些给区块链付出了足够的用度。这个提案曾经被包罗进了君士坦丁堡分叉，但在最后时刻被移除了［3］，因为发明这会给大量现存的智能合约带来危险隐患［4］。这个判定是对的，这个改造会淘汰状态存储本钱，进而带来重入类的进攻隐患，纵然只有很是守旧的2300点gas limit。这件事件中嘲讽的一点是，提案的设计实际上会淘汰智能合约重入掩护的gas本钱，并且这也是它的主要应用场景。
· 建设合约
{
第一个较量简朴：再加个opcode，可是加一个有用的。我的提议是插手这个opcode:
“name”: “foo”,
当我在写另一篇不相关的文章的时候，打仗了以太坊生态里成立的假设。本篇文章我将会报告为什么以太坊假设是有缺陷的以及给出相应的办理方案。首先，我们需要知道以太坊假设是什么。假设的内容是为了向以太坊智能合约发送ETH，同时为了制止重入进攻，挪用智能合约的 gas limit 应该不多于2300。
“inputs”: [],
5.EIP-1706：
尚有更纯粹的替代性方案，好比把所有的挪用栈袒露给智能合约。假如知道了挪用栈里都有什么，就能简朴地写一个Solidity函数来在栈里迭代，查抄是否它本身的地点被包括在它内里，来证明现有的执行时在重入。并且虽然，假如不在预料之中，合约就会抛出异常来阻止任何不想要的可能预料之外的行为。这也会答允在智能合约里插手其他特性。譬喻，想象你举行了一场智能合约可以或许参加的众筹。可是，你用黑名单拉黑了一些跟可怕分子有关的智能合约。可怕分子能简朴地陈设一个“过路“智能合约，然后让被黑名单否决的智能合约挪用”过路“合约，最后就能挪用你的众筹合约。假如有挪用栈的信息，这种行为就能被发明。此刻在以太坊里，完全无法在链上用智能合约逻辑检测这一点。
function() external view{
https://eips.ethereum.org/EIPS/eip-1283
2.EIP 1283：
· 因为一个合约被STATICCALL而收到ETH
· 其他任何工作都被答允
近期，种种DeFi项目频频蒙受黑客进攻，损失惨重。黑客们有的操作DeFi产物设计和代码实现方面的裂痕实施入侵，有的操作了始终没有彻底办理的重入进攻问题窃取DeFi平台资产。早在去年9月，Qtum的连系首创人Jordan Earls就在博客上对以太坊办理重入进攻问题的办理方案举办相识读，并提出了本身的发起。我们也翻译了这篇干货满满的技能评论，并在本日再次分享出来。在半年后的本日来看，个中概念与发起仍然具有建树性的意义，有助于开拓者和利用者加深对安详的领略。以下为博客内容： 郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
“stateMutability”: “view”,
address payable paymentAddress = 0x5A0b54D5dc17e0AadC383d2db43B0a0D3E029c4c ; paymentAddress.transfer(5);
“stateMutability”: “nonpayable”,
“type”: “fallback”
· 变动状态
“constant”: true,
好比说，想象一个合约有一个payable的fallback函数，这个函数利用了一些在陈设的时候自制到能在2300 gas limit内执行的opcode。可是，为了应对一次进攻可能什么之前没发明的问题，厥后这些opcode的价值大幅提高了。这个合约就会变得没法利用，没法从那些没明晰地将gas limit提高到高于2300（Solidity告诫的行为）的合约哪里接管ETH。更糟糕的是，明晰地提高gas limit会让那些提倡挪用的合约袒露在被重入进攻的危险中。所以，这个合约很大概就必需被弃用了。按照它吸收ETH的实际逻辑（好比依赖一个特定合约给它发送ETH），它很大概像被挡在了墙里一样，内里的钱也没法提取出来。
重入是以太坊生态内的头号，也是被接头得最多的问题，同时也被一些网站列为在建设智能合约时应该小心的第一号安详问题。这是导致了the DAO进攻和一些其他的进攻与异常的元凶。这也是智能合约开拓者最难正确处理惩罚的最难问题之一，所有大大都智能合约就简朴地从来源上杜绝了这个大概。对我来说，以太坊还没有实施什么直接的要领来阻止重入十分不行思议。相反，依靠限制许多的STATICCALL机制可能神奇的2300 gas limit常数好像优先级更高。在我心中，这值得有一个一流的办理方案，而非一个成立在假设之上的丑恶修改。
· 给此外合约发送ETH，可能变动一个合约的余额
所以，Solidity抉择一个fallback函数的stateMutability只能是non-payable可能payable，不答允是“view”。
· 挪用另一个会变动状态的合约
}
然后编译器用以下报错嘉奖了我们的冒险精力：
function() external{
