Learn how to deploy contracts using the JavaScript VM. Learn how to build functions and to use the msg object in Solidity.

By the end of this post, readers will be able to:

• Summarize the requirements needed to deploy a smart contract by using the JavaScript VM.
• Use the Remix IDE to deploy and run transactions.
• Test the JavaScript VM in Solidity using smart contract functions.
• Provide an overview of the Solidity msg object.

So far we have written smart contracts with functions, used getters and setters, learned about memory and gas-fee structure, and explored variable types in Solidity. We have also learned how to write code in Solidity and create smart contracts using the Remix IDE. Now, we will learn the final step of creating a working smart contract: deploying a smart contract by using the Javascript VM and the Remix IDE.

Requirements to Deploy a Smart Contract

It’s crucial to understand the requirements for deploying a smart contract.

Requirement 1: Have a Compiled Smart Contract

When writing Solidity code, business logic errors might exist due to incorrect code implementation. Having a successfully compiled contract ensures that the EVM can run it, and that we can use it in any Ethereum-based network.

Requirement 2: Choose an Execution Environment

An execution environment is a valid blockchain network where the contract will reside and run. The Remix IDE offers the following execution environments:

• JavaScript VM: This sandboxed blockchain is implemented in JavaScript. It runs in the browser to emulate a real Ethereum blockchain. This environment has no associated costs. It’s intended for testing smart contracts in a sandboxed environment before deploying them into a real blockchain. This is the environment we’ll use to deploy our smart contracts in this guide.
• Injected Web3: From this environment, we can deploy our smart contracts in private or public Ethereum networks by using external tools.
• Web3 provider: From this environment, we can deploy our smart contracts directly in any private or public Ethereum network. We do so by using a remote node of the network—without any external tool in the middle. We just need to provide the URL address of the provider that we want.

Requirement 3: Identify the Amount of Gas that You Need

Because we’ll use the JavaScript VM in this guide, we won’t incur any costs. However, we need to learn how to identify the appropriate amount of gas by analyzing the execution log of the contract. The execution log can be compared to the flight logbook of an aircraft.

The execution log records all the activity that relates to the contract. We can thus confirm the operations status of the contract and observe the gas expense for each operation that the smart contract made.

Requirement Summary

The three requirements for deploying a smart contract aren’t complex. Most of the complexity involves understanding the business needs and then writing the contract. Once we successfully compile a smart contract and choose an execution environment, we can deploy the contract in seconds.

1. Define the business scenario where we want to use a smart contract.
2. Architect the functionality of the smart contract, and define the functions.
3. Create the code that implements the solution that we want to build.
4. Compile the smart contract in the Remix IDE. If any errors occur, fix them.
5. Deploy the smart contract in the Ethereum network.

Deploy and Run a Smart Contract in the JavaScript VM

View the sidebar in Remix IDE and click the “Deploy & run transactions” button to display the “Deploy & Run Transactions” pane. The “Deploy & Run Transactions” pane makes several configuration options available. There are two Javascript VM versions available - Berlin and London. The Berlin version of the chain uses the same protocols as the Ethereum mainnet, so we'll be using this option:

Click the Deploy button to deploy our smart contract. After a successful deployment, our deployed contract appears in the “Deploy & Run Transactions” pane and results in the “Remix IDE terminal” pane, as the following image shows:

Since the smart contract is deployed, we can start using its functions. Click the arrow that’s next to the deployed contract to display the functions that can be called. These functions are the ones that are publicly callable from the contract, as the following image shows:

For the contract, the withdraw function has an input box. This box can be used to set the function arguments. Notice that the deposit function doesn’t have an input box. This is because it doesn’t have any arguments. Instead, use the Value box, which is further up in the pane, to specify an amount of ETH.

Note: when we move ether in a blockchain network, we usually work with the smallest denomination of ether, which is wei. Recall that 1 ether is equivalent to 1 × 10 to the 18th power. (That number is 1 followed by 18 zeros.) Remembering how to convert ether to wei and vice versa can be challenging! So, we can use a website like Ethereum Unit Converter to ease doing the conversion.

In the Remix IDE, the functions you observe in the smart contract may have buttons of different colors.

• Constant, or “pure”, functions in Solidity have blue buttons. Clicking this type of button does not create a new transaction; it will only return a value stored in the contract and won’t cost you anything in gas fees.
• Functions that change the state of the contract and do not accept ether are called non-payable functions and have orange buttons. Clicking these will create a transaction and thus cost you gas.
• Payable functions in Solidity have red buttons. Clicking a red button will create a new transaction that can accept a value.

Solidity msg Object

Solidity message (msg) object and its attributes are important concepts for token smart contracts. So, it’s important to take a few minutes to review them.

• The Solidity msg object is a global object. This means that it’s accessible from any smart contract that we write with Solidity—without defining the object within our code.
• The msg object always refers to the current message that’s being sent to the blockchain. That is, it’s the transaction that’s currently being executed or the smart contract that’s currently being deployed.
• The msg object has several attributes, including msg.sender and msg.value, which we’ll use in this module.
• The msg.sender attribute refers to the entity that’s currently sending a message. That is, it’s whoever is executing the current blockchain transaction or deploying the current smart contract.

The msg object represents the transaction call (originated by an Ethereum address), or the message call (originated by a contract's address) that triggers a contract execution.

This object contains the following special attributes which allow access to the blockchain.

• msg.sender: Represents the Ethereum address that initiated the contract call. It can be an Ethereum address or a contract's address.
• msg.value: Represents the value of Ether that is sent in the transaction (expressed in Wei).
• msg.data: Represents the data payload of the call into our contract (expressed in bytes).
• msg.sig: Represents the first four bytes of the data payload.

Until next time, here’s a twitter thread summary of this post: