Smart contracts are the backbone of the blockchain space, especially with its ever-widening domain usage. With the rapidly scaling Blockchain uses, vulnerabilities are probably inevitable.
One such easier but crucial vulnerability is the Floating Pragma
This blog will delve into the nitty gritties of floating pragma vulnerability usually experienced in the solidity code.
Let’s Begin!
What is Floating Pragma?
Table of Contents
Here before talking about the floating Pragma, in particular, let us first understand what Solidity Pragma is
A solidity pragma is most likely the first line of code in a solidity program that determines the compiler’s smart contract version.
Whereas, The floating Pragma specifies an array of compiler versions for smart contract compilation.
A pragma version does not affect the compiler’s version and can only instruct the compiler to check if it matches the Pragma. If the result is negative, the compiler generates an error.
When using a strict pragma function, it is best to specify the compiler version. This prevents the unintentional deployment of a contract with an outdated compiler that contains unresolved bugs.
Example of Floating Pragma
It is an unsaid rule in Ethereum to deploy a code with a locked pragma to a specified compiler version. Following is an example of a floating Pragma with a resolved code using a locked pragma.
How Does Floating Pragma Work?
Solidity Pragma is localized to a source file, and in order to instruct the compiler of the code’s solidity version, each solidity file has to specify the pragma version.
If you leave a floating pragma in your code (pragma solidity 0.4>=0.6.0. ), you won’t know which version was deployed to compile your code, leading to unexpected behavior.
The version pragma has no effect on the compiler’s version. Also, it does not change the default compiler features. It simply instructs the compiler to compare its version to the one specified by the pragma. If it doesn’t, the compiler throws an error.
Security Issues Pertaining to Floating Pragma
- Shifting to an older compiler version
An older compiler version may contain disclosed public vulnerabilities of the latest security checks and fixed vulnerabilities. In the case of floating Pragma, shifting to an older one is a possibility because of the range of compilers compatible with the code.
- Using a very recent compiler version
As an older version can have missing security fixes, a new compiler version can be susceptible to undiscovered vulnerabilities.
- Use of multiple pragma versions across different files
Using different versions across different files can cause code inconsistency leading to unknown security issues.
Must Read: Top 10 Smart Contract Vulnerabilities
How to Mitigate Floating Pragma Vulnerability?
The first and foremost way of coming across floating Pragma is using a strict and locked pragma version for your solidity code across all contracts. Preferably, the version should be neither too old nor too recent to have security bugs attached to them.
Another way of securing your smart contract is to go for a third-party review or smart contract audit. Auditing can be an additional security measure to make your project bug-free and help optimize its functioning.
Sum Up
With Ethereum, it is an unsaid rule to avoid Floating Pragma and use a locked version of the compiler to prevent any sort of unforeseen vulnerabilities with your smart projects.
Moreover, making auditing an integral part of your smart contract deployment helps reduce risks. Alongside this, it also acts as a security stamp for investors, building an additional source of trust among them.
Additional Resources
* What is a Smart Contract Security Audit