A1 - Notes on View and Pure modifiers in Solidity
Research and write a brief explanation of how and why `view` and `pure` modifiers are used in Solidity functions.
Last updated
Research and write a brief explanation of how and why `view` and `pure` modifiers are used in Solidity functions.
Last updated
Why are there so many different modifiers for functions in the Ethereum EVM's programming language Solidity? To answer this question, you must first understand what the Ethereum blockchain is.
The Ethereum blockchain can be accurately described as a 'decentralized immutable distributed ledger'. This may seem a little overwhelming, so let's break it down.
Decentralized - There is no single centralized entity responsible for the ledger, but rather an entire network / community.
Immutable - It cannot be altered.
A distributed ledger - A shared accounting of the information and transactions.
So blockchains are just accounting systems that are openly shared by a wide number of people, where the information cannot be changed.
We see words like view
, pure
or payable appear after the function name. These are called modifiers, but what do they mean?
There are many modifiers to choose from. For example:
payable
allows for ETH to be received by a smart contract address.
immutable
is used for state variables to be written and stored at construction time of the contract and stored on the blockchain forever.
The two that we are talking about today are the pure
and view
modifiers.
The view
modifier declares that the function in question can only view and return blockchain data. It can’t write to or alter the state of the blockchain. One very common use of view functions is a get
or a getter
function.
For example, if you have a state variable that can change, using the contract, you may need access to the information. These are created automatically, with the public modifier on the variable itself. Or if the variable is private, you will have to write your own. Furthermore, if you declare a function as a view function, there is absolutely no way of spending gas when calling that function.
The pure
function declares that you can’t write, alter, or even read the state of the blockchain. These functions are used for calculations carried out, that are not part of transactions that will be recorded on the blockchain.
One thing that they both have in common is that they are free to use, meaning they do not cost any gas. This is because they do not write any data to the blockchain. Of course, you could add some sort of calculation of math to a variable before it is returned, in a view function, if that is appropriate to your smart contract.
In conclusion, the view and pure modifiers are essential building blocks of the solidity (and indeed any blockchain) programming language. Due to the economic incentives of the gas feature, a smart contract wants to try to use as little gas as possible. Smart contract developers can utilize the view modifier to access public blockchain information, without having to write a transaction to do so.
In addition, they can use the pure
modifier to carry out any mathematics off chain at no cost, before only using the return values in write functions, where necessary. The immutable nature of blockchains is certainly an excellent feature, which gives their trustless nature. The gas cost, however, is necessary, as it incentivizes people to write worthy information to the blockchains. pure
and view
functions give the programmer freedom over when and where to write to the blockchain. This allows for the most efficient smart contracts, whilst allowing blockchains to maintain their trustlessness.
Again I prompt chatGpt for feedback using the following prompt:
"please mark my assignment 1, provide me with constructive feedback: {paste the full report here}"
Content and Understanding: Your essay effectively explains the purpose and functionality of the view
and pure
modifiers in Solidity. The introduction provides a good context about the nature of Ethereum blockchain, setting the stage for discussing the modifiers. Your explanations of the view
and pure
modifiers are accurate and clearly articulate their roles in Solidity smart contracts.
Strengths:
Contextual Introduction: The initial discussion about Ethereum's decentralized nature provides a relevant backdrop for the topic.
Clear Explanation of Modifiers: You've accurately described the use cases for both view
and pure
functions and their impact on gas costs.
Real-World Relevance: Relating the modifiers to gas optimization and efficient smart contract development adds practical value to the explanation.
Areas for Improvement:
Structural Clarity: The essay could benefit from more distinct paragraphing to separate the introduction, main discussion, and conclusion. This would enhance readability.
Technical Detail: While the descriptions are accurate, including a few code examples or scenarios where view
and pure
functions are used could deepen the understanding.
Proofreading: There are minor grammatical errors and some informal phrasing ("I know, 'decentralized immutable distributed ledgers' is a bit of a mouthful"). A more formal tone and careful proofreading would make the essay more polished.
Overall Impression: The essay does a commendable job of explaining view
and pure
functions in Solidity. It demonstrates a good understanding of these concepts and their importance in smart contract development. With some structural refinement and the inclusion of specific examples or code snippets, your analysis could become more compelling and informative.
Overall, you've shown a clear grasp of key Solidity concepts, which is crucial for developing efficient and optimized smart contracts. Keep exploring these essential aspects as they form the foundation of effective smart contract programming.