Besu Certified Professional: Smart Contract Development and Deployment

This domain tests the full path from Solidity source to a deployed contract on a Besu network, and the transaction mechanics that make deployment succeed or fail.

Core rules

• Compilation produces ABI and bytecode. Deployment is a transaction with no to field, data set to the bytecode plus ABI-encoded constructor arguments, and values for nonce, gas, gas price and chain ID.
• The contract address derives from the sender address and nonce (CREATE) or from a salt and init code (CREATE2). Compute it rather than guessing.
• Sign offline with EIP-155 using the network chain ID, submit with eth_sendRawTransaction, and confirm with eth_getTransactionReceipt where status 0x1 means success and 0x0 means revert.
• eth_estimateGas gives a starting gas limit; add headroom for state changes between estimate and execution.
• Common toolchains are Hardhat, Truffle, ethers.js and web3j. Configure the RPC URL and chain ID to match the target network.
• Predeploy contracts by placing code and storage in genesis alloc, which is useful for permissioning contracts and system contracts.

Worked example

Hardhat is configured with url: http://127.0.0.1:8545 and chainId: 1337. You deploy a contract with a constructor argument, wait for the receipt, then call eth_getCode at the receipt's contractAddress to confirm bytecode exists. A second call reads a stored value with eth_call. If the transaction reverts, --revert-reason-enabled on the node exposes the reason string in the receipt.

Traps

• Forgetting to append ABI-encoded constructor arguments to the bytecode.
• Sending with a chain ID that differs from the network, producing an invalid sender.
• Setting a gas limit below the intrinsic cost plus execution.
• Submitting a zero gas price when --min-gas-price is above zero.