Blockchain Development

01Purpose and scope

• This manual supports the course Blockchain Development. It describes how practitioners design, write, test, deploy, and maintain software that records state on a distributed ledger, with most of the attention on smart contracts and the off-chain applications that call them.
• The scope covers public and permissioned ledgers, but the day-to-day work differs a great deal between them. A public network such as Ethereum exposes every deployed contract to anyone, and a bug can drain real funds within minutes. A permissioned network run by a consortium may allow faster upgrades but puts more weight on governance agreements between members.
• This manual does not replace qualified professional judgment, approved internal procedures, or required authorization. Where a project touches payments, securities, identity, or personal data, legal and compliance review is required. Rules on token classification and data handling depend on jurisdiction, so check the current guidance from the relevant regulator or counsel.

02Core principles

• Blockchain code is hard to change after deployment. Immutable contract code means that fixes often require migration to a new contract, a proxy upgrade pattern, or a coordinated move of users and balances. Design choices made before launch carry more weight than in most software.
• Treat the chain as the source of truth for settled state and keep everything else off it. Storing large files, personal data, or frequently changing values on chain costs gas, expands the public record, and is hard to remove. Store hashes or pointers instead, and keep the authoritative copy of sensitive data in controlled systems.
• Assume every input is hostile. Anyone can call a public function with any arguments, front-run a pending transaction, or re-enter a contract mid-execution. Checks, access control, and reentrancy protection belong in the design from the first draft.
• Prefer simple logic. Each extra branch is another path that auditors must reason about and that users may misunderstand. A contract that does one job with clear state transitions is easier to verify than a general framework built for every future case.

03Planning and preparation

• Begin by writing down what the application must do, who uses it, and what happens when something goes wrong. Specify which data must be on chain, which parties need to write to it, and whether any party should be able to reverse a transaction. These answers decide the ledger type, the token model, and the upgrade policy.
• Choose the platform on evidence rather than habit. Consider the fee environment, the tooling available for the target virtual machine, the maturity of client software, the expected number of users, and whether the team can operate nodes or must rely on hosted node providers. Each option brings different failure modes and cost structures.
• Set up the environment early. Most teams use a local development network, a Solidity compiler pinned to one version, a package manager with lock files, and a test framework such as Hardhat or Foundry. Pin versions and record them in the repository, because compiler differences can change bytecode and gas use.
• Define roles before writing code. Typical roles include the product owner who sets requirements, the smart contract engineer, the back-end or front-end developer who builds the client, the security reviewer, the operations lead who manages keys and deployments, and the legal or compliance contact. A small team may hold several roles, but each duty still needs a named owner.

04Recommended workflow

1. 1
   : Write a short specification with state variables, actors, permitted transitions, and invariants. An invariant such as total supply equals the sum of balances should be written as a plain sentence first and later expressed as a test.
2. 2
   : Draft the contract with explicit access control, clear revert messages or custom errors, and events for every state change that off-chain systems need to observe.
3. 3
   : Write unit tests for each function and each revert path, then add fuzz or property tests for arithmetic and ordering assumptions. Run the full suite on every commit.
4. 4
   : Test against a forked copy of the target network when the contract calls external protocols, so you see real token behavior and liquidity conditions rather than mocks alone.
5. 5
   : Build the off-chain client. Read state through an indexer or a node, verify transaction receipts before showing success, and handle pending, dropped, and replaced transactions in the interface.
6. 6
   : Deploy first to a testnet using the same configuration as production, including the same constructor arguments, owner addresses, and multisig setup. Record deployed addresses and bytecode hashes in a release file.
7. 7
   : Run an external review, fix the findings, and then deploy to production with a staged rollout, limits on value at risk, and a tested pause or migration path. Publish verified source code to the block explorer for each deployed address.

05Quality checks, risk controls and compliance

• Review code against a security checklist that covers reentrancy, integer handling, access control, oracle reliance, signature replay, and denial of service through unbounded loops. Static analysis tools catch some classes of issues quickly, but they produce false positives and miss logic errors, so they supplement manual review rather than replace it.
• Use a multisig or timelock for administrative keys. A single externally owned account with owner rights is a common point of failure. Document who holds each key, how keys are rotated, and what conditions allow an emergency pause.
• Compliance requirements vary. Token sales, custody, lending, and payment features can trigger securities, money transmission, sanctions, or consumer protection obligations depending on where users live and how the product works. Qualified legal guidance is required before launch, and the answer must be rechecked whenever the product changes.
• Independent audits and bug bounties reduce risk but do not certify that a contract is safe. Treat each report as a list of findings to resolve and retest, and record which issues were accepted along with the reason.

06Collaboration and documentation

• Keep the specification, architecture notes, and deployment records in the same repository as the code. Reviewers need to compare what was intended, what was built, and what is live, and that comparison fails when documents drift.
• Use pull requests with at least one reviewer who did not write the change. For contract changes, require the reviewer to read the tests and the invariants, not just the diff, because a passing suite can hide a missing case.
• Publish an interface description for each contract, including function signatures, events, error codes, and expected gas ranges. Front-end teams and external integrators depend on it, and a change without an updated interface breaks them quietly.
• Record incidents and near misses in a shared log with the transaction hash, root cause, and remedy. Over time this log shows which classes of defect recur in the team's work.

07Measures and continuous improvement

• Track indicators such as branch coverage rather than line coverage, the number of open high-severity findings, time from finding to fix, the failed transaction rate in the client, median gas cost per user action, and the share of releases that passed the staged rollout without rollback. These numbers guide decisions but do not prove safety on their own.
• Monitor deployed contracts. Set alerts for unusual volume, large withdrawals, role changes, and paused states. Confirm that off-chain indexers agree with on-chain events after each upgrade.
• Revisit design choices after real usage. If users routinely hit a particular revert path, the interface or the rule may need adjustment. Plan upgrade or migration paths with user communication, since moving balances requires cooperation from wallets, exchanges, and integrators.
• Trade-offs change by context. A public token contract with broad distribution needs conservative upgrade rules and strong disclosure. An internal ledger shared by three known organizations may accept more administrative control in exchange for faster correction, provided the governance agreement is written down and enforced.

08Common mistakes and how to prevent them

• Trusting block timestamps or block hashes for randomness or precise timing. Validators have some influence over these values, so use a verifiable randomness source or design around coarse time windows.
• Forgetting about allowance races and tokens that do not follow the standard closely. Use the pattern the token standard expects and test with tokens that return no value or revert on failure.
• Making external calls before updating state. Follow checks, effects, then interactions, and add reentrancy guards wherever a call leaves the contract.
• Deploying with an unreviewed owner address or a private key stored on a developer laptop. Use a hardware-backed signer or multisig, and compare constructor arguments with the release file before each deployment.
• Ignoring gas limits in loops over user-controlled arrays. Paginate the work or use pull-based withdrawals so that one large input cannot block a function.
• Assuming a testnet result carries over exactly. Differences in fee levels, token contracts, and client versions can change behavior, so repeat critical checks on the target network.

09Practical checklist

• The specification lists state, actors, transitions, and invariants, and each invariant has a matching test.
• Compiler and library versions are pinned and recorded in the repository.
• Access control is explicit for every administrative function.
• Unit, property, and fork tests pass on the latest commit.
• Static analysis output is reviewed and each finding is either resolved or documented with a reason.
• External review findings are closed or formally accepted by the named owner.
• Administrative keys sit behind a multisig or timelock, and the key holder list is current.
• Deployment parameters match the release file, and deployed addresses are recorded.
• The client handles pending, failed, and replaced transactions correctly.
• Monitoring and alerts are active before the staged rollout begins.
• Legal and compliance review is complete for each jurisdiction where the product is offered.

★Learning sources

• Micro Degree: Blockchain Development
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics