A minimal Solidity “Hello World” contract declares a contract and stores a greeting as state. A compatible compiler can process its source into outputs such as bytecode and an ABI, but compilation alone does not create a contract instance on a blockchain. Deployment is the separate step that places the compiled contract into blockchain state. source source

A minimal Solidity greeting contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract HelloWorld {
    string public greeting = "Hello, world!";
}

This short program is an illustration of basic structure, not a production-ready template. In this example, HelloWorld is the contract’s name. The braces enclose its declaration, including the greeting variable. In Ethereum’s model, a smart contract is a reusable program deployed into blockchain state and invoked through transaction requests. source

The variable greeting is declared with the type string, which is used here to hold text. The public modifier makes the variable publicly readable through a Solidity-generated accessor. The assignment = "Hello, world!" gives it an initial value for a contract instance.

The comment beginning // SPDX-License-Identifier records a license identifier in the source file. The next line, pragma solidity ^0.8.0;, declares a range of compiler versions that the source is intended to work with. The pragma constrains compatible compiler versions; it does not install a compiler or select which compiler executable will run. Compiler selection and source compatibility are related but separate matters.

The example uses a variable initializer rather than an explicit constructor. That keeps the code small while still showing stored text. The exact compiler version and settings used to process any Solidity source should be checked against the current Solidity documentation before adapting the example.

What the greeting contract does

A contract’s state is the data it stores. Here, the state includes the greeting text. Once a contract is deployed in the Ethereum model, its code and data are associated with an on-chain address. That address refers to a deployed instance, rather than merely to the source file on a developer’s computer. source

A constructor is a special function used when creating a contract instance to initialize it. The minimal example above does not declare one: it sets the initial greeting directly on the state variable. A version with a constructor could accept a greeting as input during creation, but this article’s code intentionally avoids extra syntax so readers can focus on the key parts: the contract declaration, state variable, and read accessor.

Reading a public variable and changing stored state are different actions. Solidity generates an accessor for greeting, so a caller can retrieve its current value. The accessor does not itself provide a way to replace that value. To change state, a contract would need additional logic that defines when and how the update is allowed.

This distinction matters when interpreting the code: a visible message is not the same as an editable message. The example contains no function that changes the greeting, and it specifies no application interface beyond the generated accessor. It is a small demonstration of stored data and reading, not a complete user-facing application.

Compiling a hello world program in solidity

Compilation is the processing of Solidity source by a compatible compiler. The compiler translates source code into outputs that can be used by later development steps. Common outputs include bytecode, a machine-readable form of contract code, and an ABI, or application binary interface, which defines how an application encodes function calls and interprets outputs when communicating with an EVM contract. source

These outputs have different roles. Bytecode contains executable instructions for the EVM environment. The ABI describes the format for interaction: for example, how function selectors, arguments, return values, errors, and events are represented between an application and a contract. An ABI is not the contract’s executable code, and bytecode by itself is not a user interface.

Compiler outputs can include more than these two artifacts, and the specific outputs depend on the compiler and its configuration. The practical point for a beginner is that compiling takes source and produces machine-readable material for subsequent steps. It does not, on its own, publish that material to a blockchain or create a live instance at an on-chain address.

Compilation can be useful for checking whether source is accepted by a chosen compiler and for generating the artifacts that other tools or applications need. But compiler acceptance alone does not establish that the program behaves as intended. Solidity documentation notes that using Solidity does not by itself guarantee correctness or security; bugs can exist in software, compilers, and platforms, and development practices such as review and testing are recommended.

Compilation is not deployment

Deployment creates a contract instance on a blockchain. In the Ethereum model, deployment involves a transaction carrying contract-creation data, including EVM bytecode; after successful inclusion, the contract is created at a new address. This is distinct from compiling the source, which creates outputs but does not itself make a network state change.

The sequence is therefore conceptually simple: source code is compiled into artifacts, then a deployment process uses the compiled code to create an instance on a selected blockchain. The contract instance has its own address and state. Only after that instance exists on-chain can it be invoked through transaction requests according to its programmed behavior. source source

Local compilation or simulation can help examine code without publishing it to a public network. A local development node, for example, can provide an environment for testing contract behavior, but that is separate from deployment to a public blockchain. The exact tools and steps vary, so this explainer does not prescribe a network, wallet, framework, provider, fee, or deployment command.

It is also useful to separate the source file from the deployed instance. The source is what a person reads and edits; the compiler transforms it into machine-readable outputs; deployment creates a particular instance in blockchain state. These stages are connected, but one does not substitute for another. A compiled file is not evidence that a contract has been published, and a source file alone is not an on-chain contract.

What this beginner example leaves out

The greeting example demonstrates a contract declaration, a text state variable, an initial value, and a generated public read accessor. It does not explain a full decentralized application. An application stack may also include blockchain nodes and smart contracts together with client libraries, wallets, interfaces, data indexing, storage, and other off-chain services. source

It also does not establish that a contract is secure, tested, audited, or appropriate for production. A short example can make syntax easier to recognize, but correctness and security depend on more than the fact that code compiles. The general limitations of Solidity include possible software, compiler, and platform bugs, which is why documentation recommends practices such as review and testing.

Before adapting the code, check the current Solidity documentation for syntax and compiler compatibility, and confirm the compiler configuration used for the build. Keep the distinction clear: compiling processes source and generates artifacts; deploying uses compiled code to create a contract instance on a blockchain. The small greeting is a starting point for understanding that workflow, not a guide to production contract design or deployment.

Sources and references