Request for nonreentrant Decorator in Solidity

[Haripandey21]

Abstract

This issue proposes the addition of nonreentrant decorators to the Solidity programming language. The aim is to simplify the implementation of reentrancy protection by providing a native decorator that eliminates the need for manual imports and function calls from external libraries like OpenZeppelin.

Motivation

Currently, protecting against reentrancy attacks in Solidity requires importing OpenZeppelin and manually invoking the reentrancy guard in vulnerable functions. This process is error-prone and adds unnecessary complexity to codebases. By introducing nonreentrant decorators as a built-in feature, developers can easily annotate functions that require protection, resulting in improved code readability, maintainability, and security.
If reentrancy decorators are already available in Vyper, why not include them in the most popular programming language as well?

Specification

The proposed enhancement involves incorporating nonreentrant decorators directly into the Solidity language. These decorators would function similarly to those available in Vyper, providing a more streamlined and efficient approach to safeguarding against reentrancy vulnerabilities. The decorator syntax would allow developers to annotate specific functions, eliminating the need for manual import statements and explicit guard invocations.

Backwards Compatibility

The introduction of nonreentrant decorators would not break existing Solidity code. The decorators would be optional and backward compatible, meaning that developers can choose to use them selectively in new contracts while existing contracts can continue to function without any modifications.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.