Documentation & Best Practices Flashcards

Which practice keeps Fabric chaincode deterministic when a transaction needs the current time?

Answer: Use the transaction timestamp from the stub (GetTxTimestamp)

The transaction timestamp is identical for every endorsing peer, whereas local clocks differ and cause mismatched read/write sets.

Why should chaincode avoid calling external web services during invocation?

Answer: External responses may differ between endorsers and break determinism

Different endorsing peers may receive different responses, producing inconsistent read/write sets and failed endorsements.

What is the recommended way to support secondary lookups of ledger assets without CouchDB rich queries?

Answer: Use composite keys created with CreateCompositeKey

Composite keys let you range-query by partial attributes efficiently and work with both LevelDB and CouchDB.

When passing sensitive input to a private data transaction, where should the client place it?

Answer: In the transient field of the proposal

Transient data is not recorded in the ledger transaction, so private values do not leak to non-members.

In the Fabric 2.x chaincode lifecycle, what happens after organizations approve a chaincode definition?

Answer: A commit transaction is submitted once enough orgs have approved per the lifecycle endorsement policy

Package, install, approve, then commit; commit succeeds only when the lifecycle endorsement policy is satisfied.

A query could return thousands of results. Which API practice reduces memory pressure in chaincode?

Answer: GetStateByRangeWithPagination with a page size

Paginated queries return bounded result sets and a bookmark for the next page.

Why are rich (CouchDB) queries generally unsafe to use inside transactions that update state?

Answer: They are not re-executed at validation, so phantom reads are not detected

Range query results are re-validated, but rich query results are not, so use them mainly for read-only queries.