Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Before you write a line of Solidity, you should know what 'deploying' literally means. You sign a transaction that has no recipient (the to field is empty). Inside the transaction's data is the compiled bytecode of your contract. When miners include that transaction, the EVM creates a new address derived from your address and nonce, and stores the bytecode there. That's it. Every other deploy concept — proxies, factories, create2 — is a variation on this one transaction.
When you deploy a contract, the EVM assigns it an address derived from your address and nonce, then stores the compiled bytecode there permanently. The source code never lives on-chain — only the bytecode does, which is why contract verification on Etherscan matters so much for trust.
// A contract you could write in one line:
pragma solidity ^0.8.0;
contract Hello { string public greeting = "hi"; }
// What goes on-chain is the hex bytecode, not this source:
// 0x608060405234801561001057600080fd5b50...
// Deployment transaction fields:
// to: (empty / null)
// data: <bytecode + constructor args>
// value: 0
// gas: ~200k for a small contract
// After inclusion, the contract lives at:
keccak256(rlp([address, nonce])) truncated to 20 bytes. Compare to what your tool reports.Use these three in order. Each builds on the one before.
Explain what a deployment transaction is on Ethereum. What makes it different from a regular 'send' transaction, and what does the network do with it?
Walk me through the exact steps that produce a contract's deployed address. Why `keccak256(rlp([sender, nonce]))`? What would break if the network just assigned sequential addresses?
When is `create2` (the `create2` opcode, introduced in EIP-1014) preferable to the default `create`? Give me a concrete use case and explain what it gives up and gains.