Around Go: blockchain infrastructure · 3 MIN READ

Contract ABI: encoding is not permission and eth_call is not a transaction

Distinguish ABI packing, read simulation, signed transactions and deployment identity.

An ABI describes how to encode a call and decode its result. It does not prove that the target address has the expected code or that a read result will remain true in a future transaction. An eth_call evaluates a call against a selected chain state without committing it. State-changing execution requires a separate signed transaction lifecycle and can fail even after a successful simulation.

blockchain · A MAP OF THE IDEA

Verify chain + contract
Pack reviewed ABI
Select state for read
Validate decoded result

Useful when

Distinguish ABI packing, read simulation, signed transactions and deployment identity.
Makes the owner and the failure boundary explicit.

Watch out

A method name, ABI file or token symbol does not authenticate deployed code, particularly with upgradeable contracts.
Run native service and failure tests in your own development environment.

Implementation & operation cost: Additional state and tests must be justified by the demonstrated failure; this lesson is not a requirement for every Go program.

The contract and the failure

Work through the example

For reads, use ethclient.CallContract with an explicit block, or an appropriate hash-pinned call when reproducibility requires it. Decode with the same ABI and validate the returned shape. Generated bindings can make the Go surface clearer, but review the generated version and deployed contract compatibility; the newer bind/v2 API is not interchangeable with older binding examples.

package main

import (
	"fmt"
	"strings"

	"github.com/ethereum/go-ethereum/accounts/abi"
	"github.com/ethereum/go-ethereum/common"
)

func main() {
	schema := `[{"type":"function","name":"balanceOf","stateMutability":"view","inputs":[{"name":"owner","type":"address"}],"outputs":[{"name":"balance","type":"uint256"}]}]`
	parsed, err := abi.JSON(strings.NewReader(schema))
	if err != nil {
		panic(err)
	}
	raw := "0x0000000000000000000000000000000000000001"
	if !common.IsHexAddress(raw) {
		panic("invalid address")
	}
	data, err := parsed.Pack("balanceOf", common.HexToAddress(raw))
	if err != nil {
		panic(err)
	}
	fmt.Println(len(data)) // 4-byte selector + one 32-byte ABI word = 36
}

Read the code

The example encodes an address into an ABI word without contacting a node or signing anything. HexToAddress is used only after validation, since conversion alone is not an input validator. The encoded bytes must still be paired with a verified chain, contract address and reviewed ABI before a native RPC call.

Production decisions

A method name, ABI file or token symbol does not authenticate deployed code, particularly with upgradeable contracts. A successful simulation is not a promise about inclusion, fees or future state. Test malformed return data, wrong contract/network, a changed implementation, a reverted call and unavailable historical state. Keep signing policy outside a generic ABI helper.

Explain it in an interview

A simulated call succeeds. Does that prove a later signed transaction will succeed? No. Simulation observes selected state; inclusion, changed state, fees, nonce and execution can differ when a transaction is actually processed. Describe the state before the operation, its owner, the failure between steps and the evidence you would test. Distinguish what this example demonstrates from the infrastructure a production service still needs.

TAKE THIS WITH YOU

Distinguish ABI packing, read simulation, signed transactions and deployment identity. No. Simulation observes selected state; inclusion, changed state, fees, nonce and execution can differ when a transaction is actually processed.

Check your understanding

A simulated call succeeds. Does that prove a later signed transaction will succeed?

Go to the source

Progress stays in this browser. No account needed.