Junior · Blockchain infrastructure
RPC backend, indexer or blockchain node?
You need a Go service that reads token balances and indexes events. Does it need to implement consensus or import an entire chain-application framework?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
package main
import "fmt"
func main() {
roles := []struct{ job, packages string }{
{"Ethereum RPC", "go-ethereum/ethclient, rpc"},
{"Ethereum encoding", "go-ethereum/common, core/types, accounts/abi"},
{"Bitcoin tooling", "btcsuite/btcd: wire, chaincfg, rpcclient; reviewed versioned submodules"},
{"Application-specific chains", "cosmos-sdk with its compatible CometBFT and SDK modules"},
{"Exact units and keys", "math/big; protocol signing library; external key custody"},
}
for _, role := range roles {
fmt.Printf("%s -> %s\n", role.job, role.packages)
}
}Reveal a strong answer
Go is used for blockchain nodes and infrastructure, but a backend that reads balances is not the same system as a validator or a signing service. Start with the target network and the operation you must perform. Prefer the protocol’s maintained libraries, inspect their module boundaries and pin a reviewed release. Adding every blockchain SDK increases dependencies without proving correctness.
For Ethereum applications, use ethclient for typed RPC and accounts/abi or generated bindings for contract encoding; inspect core/types for transactions and receipts. For Bitcoin, distinguish wire/chaincfg from rpcclient and the reviewed btcec, btcutil and txscript module majors. Cosmos SDK builds chain applications and has release-specific compatible modules; it is not a universal Ethereum client. Check the chosen release’s go.mod and official migration guide. The table assigns a role rather than claiming one universal package is best. go-ethereum common/types/abi are subpackages of its module; btcsuite also has separately versioned modules, whose current major path matters. The example is a selection map, not an installation of these libraries or a blockchain runtime in GopherForge.
An SDK’s address parser does not prove a network, token or contract is legitimate. Package APIs, consensus rules, chain IDs and deployed contract ABIs all matter. Pin versions, run dependency verification and vulnerability analysis, and review transitive requirements. Full node, networking, signing and database workflows belong in your native development environment; these readings add no guest sockets, wallet or investment functionality to the app.
Common trap
A library’s popularity does not make it the right protocol or operational role for every blockchain job.
Try it
Choose package roles for Ethereum RPC/ABI, Bitcoin transaction tooling and an application-specific Cosmos chain, and explain their trust boundaries.
Worked solution
A balance reader and indexer usually need protocol clients, encoding and durable projection logic, not a new consensus implementation. Ethereum ethclient/rpc and abi/types have different roles; Bitcoin and Cosmos ecosystems have their own modules and compatibility rules. Verify network and deployed-contract identity, pin reviewed dependency versions and state the trust placed in RPC providers. The SDK choice does not prove finality, authorization or key security.
Change the constraint
What changes when the job is running a validator or building a new chain application instead?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-28. Use documentation for your pinned runtime, driver and tool version.