This newest version of the compiler brings readiness for the “Cancun” network upgrade, including support for transient storage (EIP-1153), shard blob transactions (EIP-4844), & more. The release binaries for macOS are now also compatible with Apple Silicon chips.
The Cancun Network Upgrade:
The “Cancun” network upgrade provides new features in the form of opcodes and precompiles, which will need to be explicitly used to have any benefits, but also introduces changes in the existing EVM behavior that will automatically affect already deployed contracts. Solidity 0.8.24 adds full Yul-level support for the new opcodes and also Solidity-level builtins for some of them.
Important note:
“Cancun” has not been deployed to the Ethereum mainnet yet. Thus, this new compiler release does not yet make it its default target. In order to use the new opcodes and builtins, users are required to select this version using the --evm-version cancun flag. Note that code compiled with this flag may not work as desired on any network where the hard fork is not yet implemented.
It is important to note that at the moment the code generator does not automatically make use of the new opcodes to improve the emitted code and the optimizer support is minimal. Code generation and optimizer improvements will follow in subsequent releases.
Supported EIPs & Notable Features:
Transient Storage (EIP-1153)
Shard Blob Transactions (EIP-4844)
An Efficient EVM Instruction for Copying Memory Areas (EIP-5656)
No, since sentGifts[msg.sender] = true; would cause the reeantrant function to revert when it is re-entered, thus protect it from reentrancy, while sentGifts[msg.sender] = false; would not.
function claimGift() nonreentrant public {
require(address(this).balance >= 1 ether);
require(!sentGifts[msg.sender]);
(bool success, ) = msg.sender.call{value: 1 ether}("");
require(success);
// In a reentrant function, doing this last would open up the vulnerability
sentGifts[msg.sender] = false;
}
If this function is not protected by nonreentrant (i.e., if this function is reentrant), then setting:
sentGifts[msg.sender] = false;
At the end of this function, means that the next time it is re-entered, it will not revert on:
@filmakarov is right, it should most definitely be sentGifts[msg.sender] = true;, we’ll change the post.
Reentrancy is not concerned with calling the function a second time after it completed (and set sentGifts for msg.sender to true), but with re-entering it while it has not finished, which in the example is possible in the fallback function of msg.sender during msg.sender.call{value: 1 ether}(""); (without the reentrancy-guard that is).
Then you may want to consider rephrasing that whole section into something like:
/*
In the reentrant function below,
doing `sentGifts[msg.sender] = true`
after `msg.sender.call` instead of prior to that,
open this function to a reentrancy-vulnerability
*/
function claimGift() public {
require(address(this).balance >= 1 ether);
require(!sentGifts[msg.sender]);
(bool success, ) = msg.sender.call{value: 1 ether}("");
require(success);
sentGifts[msg.sender] = true;
}
I personally find the current description pretty confusing (even after fixing that specific line of code).
The Cancun Network Upgrade:
Important note:
Blog: Solidity 0.8.24 Release Announcement
GitHub Release Notes: v0.8.24
Help us spread the word by sharing our announcement on Twitter!