Preparing for Smart Contract Development

3.4 — Preparing for Smart Contract Development

Recall first. A Solidity source file is not yet a contract that users can call. List the missing stages between source code and a usable deployed contract. Your answer should contain at least: compile, deploy, address, and test.

The development pipeline

The book’s minimum workflow is:

write Solidity → compile → deploy → run/test

Deployment is itself a blockchain transaction. The compiler produces machine-oriented output, and the deployed contract receives an address that clients use to interact with it.¹

A practical mental model is:

.sol source
   │ compiler
   ├── ABI       → how a client describes callable functions/events
   └── bytecode  → code used for deployment/execution
                         │ deployment transaction + gas
                         ▼
                  contract address + on-chain code/state
                         │
                 calls and state-changing transactions

The three deployment artifacts

ABI

The Application Binary Interface (ABI) is the interface description between an external application and deployed contract bytecode. It describes callable functions, inputs, outputs, and events in a machine-readable form. The client needs the ABI to encode a call or decode a result/log.²

The book emphasises that the ABI contains information about functions and events, not the contract’s state-variable values. To interact with a deployed contract, a web application needs the ABI and the corresponding contract address.²

Bytecode

Bytecode is the compiler output used by the EVM. Deployment sends creation bytecode in a transaction; the resulting runtime code is stored at the new contract address. The book’s appendices describe copying compiler-produced ABI and bytecode when connecting a separate wallet/application to a local chain.³

Contract address

The contract address identifies the deployed instance on a particular network. The same source may produce different addresses on different deployments or networks. ABI without an address does not identify which deployed instance to call; an address without the correct ABI does not tell a client how to encode the interaction.¹²

Calls versus transactions

A read call can be executed against the latest state without adding a new block. A transaction must be signed by an account, propagated, included in a block, and executed by the network. If it succeeds, state changes; if a checked condition fails, execution reverts according to the contract’s error rules.

Gas: executing EVM work consumes gas. State-changing calls and deployment need a gas limit and a fee paid in the network’s native currency. A transaction can fail because the contract rejects its conditions, because the gas/fee is insufficient, or because the environment is misconfigured. A failed transaction may still consume gas for work already performed; the state change itself is not committed.⁴

Tool roles

The book’s examples divide responsibility across tools:¹³

Use the simplest environment that proves the concept. Start with Remix JavaScript VM; move to Ganache when you need a local node and visible block/account monitoring; use MetaMask with a test network when you need a browser wallet and external network connection.

Workflow A — Remix JavaScript VM

The book’s Remix sequence is:¹

1. Open Remix.
2. Set the environment to JavaScript VM.
3. Create a .sol file.
4. Write the contract.
5. Select a compiler compatible with the pragma line and compile.
6. Select the contract and click Deploy.
7. Open the deployed contract.
8. Call read functions and submit test inputs to write functions.
9. Check returned values, logs, transaction status, and state after each action.

JavaScript VM is useful because it supplies temporary accounts and dummy ether. It is isolated from real funds and resets when the local VM is reset.

Minimal test checklist

For any small contract, test both the happy path and the rejection path:

initial state → valid write → read changed state
             → invalid input → confirm revert and unchanged state
             → second account → confirm access/voter rule
             → event/log → confirm expected fields

For the voting contract in 3.3, this means: deploy two candidates, vote from Account 1, read the count, try Account 1 again, try an invalid candidate index, and vote from Account 2.

Workflow B — Remix with Ganache

Ganache is a personal/local Ethereum blockchain for development and tests. The book’s Appendix A assigns Remix to development, compilation, deployment, and running; Ganache supplies accounts and monitors blocks and transactions.³

1. Start Ganache and note its RPC server URL.
2. Use its preloaded development accounts for testing only.
3. In Remix, select the Web3 Provider environment.
4. Enter the Ganache RPC URL.
5. Confirm that Ganache accounts appear in Remix.
6. Compile in Remix.
7. Deploy from Remix using a Ganache account.
8. Run functions and inspect new blocks, transactions, accounts, and logs in Ganache.

Security boundary: never treat development private keys or preloaded local funds as production secrets. Ganache is for a local test chain.

Workflow C — Remix with MetaMask and a test network

MetaMask holds accounts and connects a browser to a chosen Ethereum network. The book’s Appendix C describes writing and compiling in Remix, selecting an injected Web3 environment, confirming the connection in MetaMask, and approving deployment and later transactions.³

1. Create or import a wallet safely; never disclose the seed phrase or private key.
2. Select a test network, not a production network, and obtain test funds from the network’s supported faucet.
3. Write and compile the contract in Remix.
4. Select the injected Web3/MetaMask environment.
5. Confirm the account and network shown in both tools.
6. Deploy and approve the MetaMask transaction.
7. Approve subsequent state-changing calls.
8. Check the transaction status and contract address in the wallet or network explorer.

The book names Ropsten as its historical example. Test-network names and wallet interfaces change, so use a currently supported test network in practice while preserving the same workflow. The learning objective is the connection and approval flow, not dependence on an obsolete network name.

Worked example — deploy and test EducationalVoting

Step 1: Write. Paste the 3.3 contract into EducationalVoting.sol.

Step 2: Compile. Select a Solidity 0.5.x compiler compatible with pragma solidity ^0.5.1. Confirm that compilation produces the ABI and bytecode.

Step 3: Deploy. In Remix JavaScript VM, enter Alice and Bob as constructor arguments and click Deploy. Record the displayed contract address.

Step 4: Read initial state. Call candidateCount(); expect 2. Inspect the candidate getter for indexes 0 and 1.

Step 5: Write. From Account 1, submit vote(1). Confirm the transaction succeeds, gas is displayed, the VoteCast event appears, and Bob’s count becomes 1.

Step 6: Test rejection. From the same account, submit vote(0). The hasVoted check should revert; Alice’s count remains 0 and no successful vote event is emitted.

Step 7: Test another account. Select Account 2 and submit vote(0). The transaction succeeds; both candidates now have one vote. leadingCandidate() returns index 0 under this implementation’s first-on-tie rule.

Step 8: Inspect the environment. In Ganache, look for the deployment and vote transactions as blocks. With MetaMask, inspect the approved transaction and selected network. In a client application, use the ABI plus recorded address to encode the same interactions.

Common setup failures

Exercise

1. Put these in order: deploy, write, compile, test, obtain ABI/bytecode.
2. Why does a client need both ABI and contract address?
3. Classify getName() as a call or transaction if it is view; classify setName() if it changes state.
4. Give one reason to choose JavaScript VM over Ganache, and one reason to choose Ganache over JavaScript VM.
5. A vote transaction reverts. Name two different causes that must be distinguished.
6. Why should the book’s Ropsten example be treated as historical rather than a required modern network choice?

Exam lens

Draw this pipeline for a “prepare/deploy a smart contract” answer:

Solidity source
  → compiler
  → ABI + bytecode
  → deployment transaction + gas
  → contract address
  → wallet/client uses ABI + address
  → call (read) or transaction (write)

Required vocabulary: Remix, JavaScript VM, Ganache, MetaMask, test network, ABI, bytecode, address, transaction, call, gas, compile, deploy, test.

Short-answer distinctions:

• ABI: interface description; not the deployed contract state.
• Bytecode: compiled EVM-oriented code; not the human-readable source.
• Address: location of one deployed instance on one network.
• Call: read-only interaction that does not change chain state.
• Transaction: signed state-changing action or deployment that consumes gas.
• Ganache: local personal blockchain; MetaMask: wallet/network connector.

Rapid revision

• Can I write the full source → ABI/bytecode → address pipeline?
• Can I list the Remix JavaScript VM steps?
• Can I explain Remix’s role versus Ganache’s role?
• Can I explain how MetaMask approves a test-network transaction?
• Can I distinguish a call, transaction, and deployment?
• Can I explain why gas is needed?
• Can I diagnose wrong compiler, wrong network, wrong address, and failed require?

Key takeaways

• Smart-contract development is write → compile → deploy → test, with version compatibility checked at compile time.
• Compilation produces ABI and bytecode; deployment creates a network-specific contract address.
• ABI plus address lets an external application interact with the deployed instance.
• Reads/calls do not change state; deployments and writes are signed transactions that consume gas.
• Remix JavaScript VM is the smallest safe test environment; Ganache adds a local node and monitoring; MetaMask connects Remix to a wallet and test network.
• The book’s Ropsten instructions are historically useful; use a currently supported test network in practice.

Sources