{"id":15979,"date":"2022-01-20T18:00:00","date_gmt":"2022-01-20T18:00:00","guid":{"rendered":"https:\/\/hederav2stg.wpenginepowered.com\/blog\/introduction-solidity-smart-contracts\/"},"modified":"2025-12-09T16:40:30","modified_gmt":"2025-12-09T16:40:30","slug":"introduction-solidity-smart-contracts","status":"publish","type":"post","link":"https:\/\/hedera.com\/blog\/introduction-solidity-smart-contracts\/","title":{"rendered":"Introduction to Solidity smart contracts"},"content":{"rendered":"
\n

If you have dabbled in web3, you have likely heard about the programing language Solidity<\/a>.\u00a0Solidity is the world’s most popular way\u00a0to write smart contracts<\/a> which are then\u00a0compiled and deployed to the Ethereum Virtual Machine (EVM).\u00a0After these programs are deployed, they exist on-chain and can be interacted with by anyone. These contracts make up decentralized exchanges, NFT projects, lending protocols, and a plethora of other decentralized applications.\u00a0<\/p>\n

With Hedera\u2019s testnet update today, we\u2019re able to begin using ‘smart contracts 2.0’, the\u00a0EVM compatible Hedera Smart Contract Service<\/a>\u00a0for building scalable decentralized applications. If you\u2019re starting out, here is an overview and\u00a0some helpful resources to jumpstart your journey. If you want to dive in headfirst and get hands-on, check out our deploying your first smart contract tutorial<\/a>.<\/p>\n

Ethereum Virtual Machine (EVM)<\/strong><\/h4>\n

The EVM is a distributed computing environment that executes smart contract logic. It is a virtual machine, an abstraction between executing code and hardware.\u00a0The EVM executes smart contract logic by compiling the smart contract down to a set of opcodes. <\/p>\n

Opcodes are low-level instruction sets used by computers to perform basic operations that make up the functionality of computers. If you are curious about the EVM’s opcodes check out this full list<\/a> of them and what they do or get an idea of the Hedera supported opcodes<\/a>. This is what is happening under the hood when someone is interacting with a smart contract.<\/p>\n

While the EVM did come out of the Ethereum ecosystem it also runs on a variety of other protocols including Hedera. Hedera uses the open-source Hyperledger Besu EVM<\/a>.\u00a0Regardless of the implementation, the demand for distributed computing environments is high. And the demand for developers who can write smart contracts is even higher. The most popular and widely used is solidity, so let’s get into it.<\/p>\n

Development Frameworks<\/strong><\/h4>\n

When writing a smart contract, you likely want to be able to run tests, deploy to testnets, and make sure things are working before you deploy your contract to the mainnet. This is why almost everyone uses a development framework when writing or programmatically interacting with smart contracts. These frameworks provide us with tools to test, deploy, and interact with smart contracts in a variety of languages. One of the most popular frameworks is HardHat<\/a>, a JavaScript framework. Others include Brownie<\/a> (Python) and Foundry<\/a> (Rust). Foundry is neat because it also supports fuzzing tests with your contracts; a great way to look for security vulnerabilities and anomaly behavior.<\/p>\n

To start writing the smart contract, pick a development framework that works for you and learn its available tools.<\/p>\n

Gas<\/strong><\/h4>\n

When smart contracts are executed, a fee must be paid to the network consensus nodes to execute transactions. The computational unit of measurement used to denote this is called gas<\/a>. In Ethereum, the price of gas depends on the congestion of the network. This is subject to change in Eth2 and varies depending on the network. Be sure to learn about how the network you are building on determines its gas price.<\/p>\n

Solidity Contracts<\/strong><\/h4>\n

All Solidity contract files end in a .sol extension and have a line at the top that specifies what version of solidity they are to be compiled with. For example the line<\/p>\n

    pragma solidity >=0.4.16 <0.9.0;<\/pre>\n
is telling the compiler this contract is written for version 0.4.16 up to but not including version 0.9.0.<\/p>\n
After the compiler version is specified each contract starts with the contract keyword followed by the name of your contract and an opening and closing curly brace. It has become common practice to have the contract names be camel case. All the logic of the contract will reside within the curly brace.<\/p>\n<\/div>\n
\n
  
\n  \"code<\/p>\n
\n
<\/div>\n
<\/div>\n<\/p><\/div>\n
 pragma solidity >=0.4.16 <0.9.0;\n\ufeff\ncontract MyContract {\n\t # Logic goes here\n}\n<\/code><\/pre>\n<\/div>\n
\n
State Variables<\/strong><\/h4>\n
State variables are variables that the contract keeps track of internally and change over time as calls are made to the contract. The modification of state variables requires computation and will thus require a transaction fee denominated in gas.<\/p>\n
Types<\/strong><\/h4>\n
Solidity is a typed language and includes a variety of built-in data types for our convenience. Some important ones to note are the address type used to specify wallet addresses, the uint32 used to denote unsigned integers of 32 bytes, a boolean bool, and the familiar string data type. There are more included types and if curious I would look at the documentation<\/a> for a more complete set of the data types included in solidity.<\/p>\n
public, public view and public payable<\/strong><\/h4>\n
Functions in solidity are specified by the function keyword and then the function's name. Parts can be specified to have some additional properties in solidity. For example, with the view keyword, the function can just return the information without modifying any state variables. This is nice because it doesn't use any computation and thus doesn't cost anything. An example would be a getter function that looks like this.<\/p>\n
function get() public view returns(uint32)<\/p>\n
A function with the public keyword is available for anyone on-chain to call, public view means anyone can call it and it will return some value to be viewed usually public view functions are followed by the returns keyword with the type of the value to be returned.<\/p>\n
An example of a simple contract with a setter and getter would look like this.<\/p>\n<\/div>\n
\n
  
\n  \"code<\/p>\n
\n
<\/div>\n
<\/div>\n<\/p><\/div>\n
pragma solidity >=0.7.0 <0.8.9;\n\n\ufeffcontract MyContract {\n\t\/\/ the message we're storing\n    string message;\n\n    function set_message(string memory message_) public {\n    \/\/ only allow the owner to update the message\n   \t\tif (msg.sender != owner) return;\n             message = message_;\n        }\n        \n\ufeff    \/\/ return a string\n    function get_message() public view returns (string memory) {\n         return message;\n     }\n}\n<\/code><\/pre>\n<\/div>\n
\n
Furthermore, if a function deals with transferring erc20 or erc721 digital assets, the payable keyword is used in the function declaration. Note that the payable keyword only applies to tokens in the ERC standards. If you prefer to transfer a different type of digital asset like a Hedera Token Service minted token, you don't have to use this payable keyword.<\/p>\n
Additional Resources<\/strong><\/h4>\n
Solidity is a rapidly evolving ecosystem and growing developer community that we're excited to support. To continue your learning here are a few more recommendations:<\/p>\n<\/p>\n