Blockchain product traceability system development

Developing a Blockchain Product Traceability System

A typical scenario: a luxury goods manufacturer wants "blockchain for authenticity". They come with a request — a QR code on the packaging, the customer scans it, sees "authentic". The problem is that such a system guarantees nothing: if the product origin data is entered into the blockchain by the manufacturer without physical verification, a record on Ethereum is no different from a record in Excel. Blockchain solves the problem of data immutability after recording, not the problem of data authenticity during recording. This distinction determines the entire architecture of an honest traceability system.

The Oracle Gap Problem and Physical Binding

The central technical problem of supply chain traceability is the so-called oracle gap: the break between the physical world and on-chain data. A product can be substituted while preserving the QR code or RFID tag. Solutions exist, each with its own tradeoffs.

NFC with Cloning Protection

NXP NTAG424 DNA chips implement a protocol with cryptographic challenge-response. Each time the chip is scanned, it generates a unique CMAC (Cipher-based Message Authentication Code), derived from an internal counter and an AES-128 key burned during manufacturing. Cloning a chip without knowing the key is physically impossible. Verification:

Scan → Chip returns (UID, Counter, CMAC) → Backend verifies CMAC with stored key
→ Counter monotonically increasing? → Legit scan
→ Counter same as before? → Replay attack / counterfeit

Keys are stored in an HSM (Hardware Security Module), not in an application. The fact of verification itself is recorded in the blockchain as an event, not static product data — this is an important architectural decision.

Physically Unclonable Functions (PUF)

For high-value goods (jewelry, pharmaceuticals) — microstructural scanning: a unique "fingerprint" of the material, unreproducible during manufacturing. Companies like Alitheon and Certilogo build systems on this principle. The algorithm comes down to computing a hash from a high-resolution surface scan and storing the commitment in the blockchain during manufacturing. Upon verification — re-scanning and comparing features.

IoT Sensors in the Supply Chain

For perishable goods (pharma, food): temperature/humidity sensors with data signed on the device itself (Trusted Execution Environment or secure element). Data is published via MQTT → Kafka → on-chain oracle. De facto standard — integration with Chainlink Functions or custom oracle based on Town Crier (TEE-based).

Architecture of On-Chain Components

Choosing a Network and Data Model

Full on-chain storage for enterprise supply chain is excessive and expensive. Standard hybrid model:

For storing data hashes with availability — IPFS with pinning via Pinata or web3.storage. The contract stores only the CID (Content Identifier) and content hash for integrity verification.

Asset Registry Contract

Minimal architecture — ERC-721 with supply chain extensions:

struct AssetRecord {
    bytes32 physicalId;      // hash of NFC UID or PUF fingerprint
    address currentCustodian;
    uint256 mintedAt;
    bytes32 metadataCID;     // IPFS CID of attribute batch
    uint8 status;            // enum: MANUFACTURED, IN_TRANSIT, CUSTOMS, DELIVERED
}

event CustodyTransferred(
    uint256 indexed tokenId,
    address indexed from,
    address indexed to,
    bytes32 locationHash,
    uint256 timestamp
);

event VerificationEvent(
    uint256 indexed tokenId,
    bytes32 indexed verifierHash,
    bool authentic,
    uint256 nfcCounter
);

For chains with multiple participants (manufacturer → exporter → logistics → customs → retail) — roles via AccessControl. Each participant can only record events for their stage.

Batching to Reduce Gas Costs

With high event volume (thousands of product units per day), direct blockchain recording of each event is uneconomical. Solution — Merkle tree batching: aggregate events over a period (5–15 minutes), build a Merkle tree, publish only the root to the blockchain. Individual events are verified by providing a Merkle proof.

function submitBatch(bytes32 merkleRoot, uint256 eventCount, bytes32 batchCID) 
    external onlyRole(BATCH_SUBMITTER_ROLE) 
{
    batches[batchNonce] = BatchRecord(merkleRoot, eventCount, block.timestamp, batchCID);
    emit BatchSubmitted(batchNonce++, merkleRoot, eventCount);
}

function verifyEvent(uint256 batchId, bytes32 leaf, bytes32[] calldata proof) 
    external view returns (bool) 
{
    return MerkleProof.verify(proof, batches[batchId].merkleRoot, leaf);
}

This approach reduces on-chain costs by 100–1000x while maintaining cryptographic verifiability.

Integration with GS1 and Industry Standards

For a serious enterprise project, you cannot invent identifiers from scratch. GS1 standards (EAN, GTIN, GLN, SGTIN) are used in most supply chain systems globally. The blockchain registry should support mapping SGTIN → tokenId, GLN → participant addresses.

GS1 Digital Link (ISO/IEC 18975) — a standard for QR code URL structure, allowing one code to lead to different resources depending on context. Our system implements a Digital Link resolver that for /01/{gtin}/21/{serial} returns on-chain data.

For pharmaceuticals — compliance with DSCSA (Drug Supply Chain Security Act, USA) and FMD (Falsified Medicines Directive, EU). Both require serialization and verification at each chain stage. The blockchain component replaces (or supplements) centralized registries like NMVS.

Backend and Indexing

On-chain events are the source of truth, but direct on-chain queries are too slow for user interfaces. An indexer is necessary:

The Graph subgraph — declarative event indexing in GraphQL API. For supply chain: handlers handleCustodyTransferred, handleVerificationEvent, handleBatchSubmitted. Data aggregates into entities Product, CustodyEvent, Participant.

Alternative for enterprise — custom indexer in Go/Rust with PostgreSQL. More predictable latency, ability for custom aggregations, no dependency on TheGraph Network.

Stack and Timeline

Technology choice depends on decentralization requirements:

• Permissioned (consortium): Hyperledger Fabric or Besu private network. Fewer gas issues, control over participants, no public verifiability
• Public L2: Polygon PoS or Arbitrum for balance of cost and openness
• Enterprise public: Ethereum mainnet for maximum credibility (jewelry, luxury)

Typical stack: Solidity + Hardhat/Foundry (contracts), Go (backend + indexer), React (verification portal), NFC SDK (iOS/Android), PostgreSQL + Redis.

Realistic MVP timeline with NFC verification, two to three participant roles, and basic portal — 10–14 weeks. Full system with IoT integration, GS1 compatibility, and enterprise SSO — from 6 months.