Add to Home Screen — iOS
Tap the Share button at the bottom of Safari (or top on iPad).
Scroll through the share sheet and tap "Add to Home Screen".
Tap "Add" in the top-right corner. The brief appears as an app icon on your home screen.
This briefing explains sharding and private blockchain in plain terms — what each does, what problems each solves generically, how they interact, and how to evaluate whether any given project is a good fit. No project has been assumed. That decision is yours.
Before evaluating an alternative, you need a clear picture of what you already have and what its inherent limits are. These are not implementation failures — they are architectural constraints built into centralized design.
| Attribute | Centralized Server | Sharding + Private Blockchain |
|---|---|---|
| Where is the data? | One database on one server (or a mirror of the same server) | Split across 5 separate physical nodes in different locations |
| What happens if one location fails? | Everything fails — all users lose access until the server is restored | System continues — 2 of 5 nodes can be offline and the quorum still works |
| Can a database administrator alter a record? | Yes — anyone with database access can change or delete records, often without a trace | No — a record change is a new block. Previous state is permanently preserved and any change is visible |
| Can a single employee see an entire sensitive file? | Yes — server admin sees all data. Access logs can also be deleted by an admin | No — each node holds only an encrypted fragment. Seeing the full file requires a quorum of nodes to agree |
| Is there an audit trail? | Only if you build one separately — and the same admin who can edit data can also edit the log | Yes — every action is a block on the chain. The log is the data structure itself. It cannot be separated or selectively deleted |
| How do two organizations verify a shared fact? | One organization emails the other. The receiving party trusts the document because there is no alternative | The receiving party queries the blockchain. A cryptographic proof answers the question without sharing the raw database |
| What does a hacker gain from a breach? | The entire dataset — every record, every field, every historical version | One encrypted shard fragment — unreadable without 2 other fragments from different nodes they would also need to breach |
| Setup complexity | Lower — one server, one team, one database | Higher — multiple nodes, distributed infrastructure, chaincode business logic |
| Operational cost | Lower — one server to maintain | Higher — 5+ nodes to maintain, but shared across participating organizations |
| Right choice when… | Data is internal to one organization, non-sensitive, and regulatory audit is not required | Data crosses organizations, carries legal/financial weight, and tamper-evidence is a requirement |
A centralized server is not "wrong." It is simpler, cheaper, and perfectly adequate for many use cases. Sharding and blockchain add genuine value only when the problem involves cross-organization trust, tamper-evidence requirements, or sensitivity that prohibits any single administrator having full access. Applying this architecture to a simple internal database is unnecessary complexity. The decision should be driven by the specific problem — not by the technology's sophistication.
A blockchain is a sequence of records where each entry is mathematically linked to the one before it. Altering any past entry breaks every subsequent link — making tampering immediately detectable. A private blockchain restricts who can participate.
Imagine a physical logbook where each page has a unique fingerprint printed on the next page. If you tear out page 5 and replace it, page 6's fingerprint no longer matches — and every subsequent page becomes invalid. The blockchain is that logbook, but digital — and enforced by mathematics rather than by physical seals.
A private (or "permissioned") blockchain adds an access layer: only approved participants can join, read, or write. This is different from a public blockchain like Bitcoin, where anyone can participate anonymously. In a private blockchain, every participant is known and authenticated.
Every node on the network is known, authenticated, and authorized. Unlike public blockchains, there is no anonymous participation. Participants can be organizations, offices, or departments — each with a digital identity (certificate) issued by a central authority.
Every write, every read request, every approval, every change — all go into the chain as new blocks with timestamps. No one can remove a log entry. No one can claim an action happened at a different time. The history is the history.
When two or more organizations need to agree on a shared fact — a payment was made, a record was verified, an approval was given — the blockchain is their single source of truth. Neither party controls it; both can audit it.
Traditional systems have one database that, if breached, exposes everything. A blockchain is replicated across all participating nodes. There is no single server whose compromise corrupts the whole record. An attacker must control more than half of all nodes simultaneously.
These are technology-neutral. Any domain — public sector, private enterprise, healthcare, logistics, finance — where these conditions exist is a potential fit.
If the loss of one server, one building, or one office should not mean the loss of critical data — sharding distributes so that 2 of 5 can fail completely and the system still runs.
Where document integrity is critical — certificates, approvals, financial records, identity documents — a blockchain provides proof that a record has not changed since it was written. Tampering is immediately detectable.
Personnel records, medical files, financial data — where a single administrator having full access is a liability. Sharding enforces that no individual node, and no single employee with access to one node, can read a complete file.
Two departments or two organizations need to verify facts about a shared subject but cannot legally or practically share their raw databases. Blockchain proofs let one side verify a claim ("this person is eligible") without receiving the underlying data.
Any process requiring a provable, ordered sequence of events — approvals, payments, inspections, access logs — benefits from a blockchain's immutable chronological record. No one can rewrite the timeline after the fact.
When a person, asset, or document moves from one location to another and the receiving location must trust the record without calling the sender, sharding enables cryptographic proof that the record is genuine — no phone call, no paper, no delay.
Mr. Kashif's two questions are answered first. Four additional questions — the ones any informed Director should raise — follow with the same level of technical honesty.
A district's office loses its internet connection but local devices can still communicate with each other over the internal network. Work continues. When connectivity is restored, what happens to everything that was done during the outage?
Yes — but the behaviour during the outage depends on a deliberate design choice made upfront. There are two fundamentally different modes, each with a different trade-off. Neither is universally "correct" — the right choice depends on what the data represents.
Normal operation. The district node reads and writes. Every transaction goes to the orderer, gets sequenced, and is confirmed across all nodes.
Intranet only. District devices still talk to each other. The local node still holds all historical data. Design decision applies here (see below).
Automatic sync. The node connects to any peer, requests all blocks produced during the outage, and replays them to reach the current state. This is called ledger catch-up.
How it works: The district node can read all historical data from its local copy but cannot write new records until it reconnects to the main orderer. Write requests are queued and submitted when back online.
Trade-off: No work can be recorded during an outage. Staff can view records but cannot make changes. Zero risk of conflicting writes.
Best for: Critical records where a conflict would be very costly — financial approvals, eligibility decisions, legal documents.
How it works: The district node writes to a local buffer during the outage. When reconnected, local writes are submitted to the orderer, which sequences them against any changes made elsewhere during the same period.
Trade-off: Work continues during outage. Risk of conflicting writes (see Q2 below).
Best for: Non-critical updates — contact information, attendance logs, notes — where minor conflicts are manageable.
When a node reconnects, the blockchain's gossip protocol automatically finds the closest peer node with a more recent chain state. It requests all blocks from the point of disconnection onward. These blocks are cryptographically verified (each hash chains to the previous) and applied in order. The process is automatic — no human intervention required. On a typical government network with modest data volumes, a node that was offline for 8 hours would catch up in under a minute.
Use Mode A (read-only during outage) for any field that affects entitlements, approvals, or payments. Use Mode B (write locally, sync later) for administrative fields like contact details and notes. This gives you operational continuity without risking conflicting decisions on critical data. The system can enforce different modes per field type in chaincode (the business logic layer of the blockchain).
District A updates a record while offline. District B, also offline or connected, updates the same record at the same time. When they reconnect, the system has two different versions of the same record. Which one is correct, and what happens?
In a properly designed private blockchain, this conflict is either prevented by architecture, or detected and resolved by a defined rule. There is no scenario where the system silently picks a version without a traceable, auditable decision. Both versions are always preserved in the chain history.
Updates Record #1247.
Sets status = "Approved"
At 10:34 AM
Updates Record #1247.
Sets status = "Rejected"
At 10:41 AM
Record #1247 cannot simultaneously be "Approved" and "Rejected". The orderer must make a deterministic decision.
Hyperledger Fabric uses a mechanism called MVCC — Multi-Version Concurrency Control, borrowed from traditional databases. Every record has a version number. A transaction records what version it read before making a change. When the orderer sequences two conflicting transactions, it checks: "Both transactions claim to update version 3. But version 3 can only have one successor." The first transaction to arrive becomes version 4. The second transaction is rejected because its "read version" (3) no longer matches the committed state (now 4). The rejected transaction is logged. The submitting node is notified. A retry can be triggered manually or automatically.
This means: no data is silently overwritten, both attempts are on the chain forever, and exactly one version is the accepted state.
Classify every data field as either critical (status, eligibility, payment, approval) or administrative (address, phone, notes). Apply Strategy 1 (no offline writes) to critical fields. Apply Strategy 2 (orderer sequences) to administrative fields where a later overwrite is acceptable. For any field where both conflicting values need human review, apply Strategy 3 and define the review workflow in the chaincode before deployment. This classification should be done at the project design stage — retrofitting conflict resolution logic is significantly harder.
An adversary gains full access to one of the five nodes — they can read everything on that server and write anything they want to its local copy. What damage can they do to the chain's history?
No — they cannot alter past records and have them accepted by the network. They can damage their local copy, but every other node immediately detects the inconsistency and isolates the compromised node. History on the blockchain is protected by mathematics, not just by access controls.
Every block in the chain contains a cryptographic hash of the previous block. A hash is a fixed-length mathematical fingerprint: change a single character in the source data, and the fingerprint changes completely and unpredictably. If an attacker edits Block #47 on their local node, Block #47's hash changes. But every block after it — Block #48, #49, #50 — still contains the old hash of Block #47 in their "previous" field. The chain on the compromised node is now mathematically inconsistent with every other node.
When the network's gossip protocol compares chain states (which it does continuously), every other node sees the mismatch and rejects the compromised node's version. The attacker would need to simultaneously recompute every block from #47 onward — a computationally infeasible task — AND convince the majority of other nodes to accept their version. With a 5-node network, they would need to control 3 nodes simultaneously.
One encrypted shard fragment — which is one piece of 5. Without the other pieces from other nodes, it decrypts to nothing. Access to the blockchain log on that node — which they can read but cannot alter in a way the network accepts.
Read any complete record — they only have 1 of 5 fragments. Alter any historical record across the network. Forge a new block that other nodes will accept. Cover their tracks — the intrusion itself becomes a visible chain event.
A compromised node should be detected, quarantined, and replaced before it can influence future consensus rounds. This requires monitoring — each node's heartbeat and chain state should be checked continuously. The response playbook (who is notified, how the node is isolated, how it is restored with a verified chain copy) should be defined before deployment, not after an incident.
In a traditional database, writing a record takes milliseconds. If consensus across multiple network nodes is required, does this add a delay that would make the system unusable in practice?
No — for the types of records government systems handle, the speed is completely adequate. The key distinction is between reading (fast, local) and writing (slightly slower, requires consensus). In practice, both are fast enough that users do not notice the difference.
Local node reads from its copy of the ledger. No network consensus needed. Faster than most web page loads.
Transaction submitted to orderer, sequenced, confirmed across quorum nodes. Noticeable but acceptable for record-level operations.
Checking that a record has not changed is a local hash comparison. Instant. This is the most common operation for audit and verification use cases.
Hyperledger Fabric (the private blockchain used in this architecture) is benchmarked at roughly 3,500 transactions per second in typical enterprise configurations. A government record system handling thousands of records per day operates far below this ceiling. Slow performance would only become a concern at the scale of a national bank processing millions of transactions per minute — not at government department scale.
The 1–3 second write time is comparable to a user clicking "Submit" on a web form and waiting for a confirmation page. In a well-designed interface, this is invisible — the user sees a loading indicator and the confirmation arrives before they notice a delay.
Many government records include scanned documents, photographs, certificates as images, and medical reports as PDFs. Can these be stored in the sharded blockchain system, or is it limited to database-style structured records?
Large binary files should not go directly on the blockchain or into the shard structure — but they can be securely linked to it. The correct architecture stores the file on regular storage and stores only its cryptographic fingerprint on the chain. The fingerprint is small, fast, and proves the file is genuine and unchanged.
Putting a 5MB scanned PDF directly into a blockchain transaction bloats the chain rapidly. A 1,000-record system with PDF attachments would produce gigabytes of chain data. Every node must store a full copy. Performance degrades. The blockchain becomes unmanageable within months.
Store the PDF on a regular file server or cloud storage. Store the file's SHA-256 hash (a 64-character fingerprint) on the blockchain. When anyone downloads the file and checks its hash against the chain, they instantly know whether the file is the original or has been modified — without the chain ever holding the file itself.
SHA-256 produces a unique fingerprint for any file. Change a single pixel in a photograph or a single character in a PDF and the fingerprint changes completely. It is computationally impossible to produce two different files with the same SHA-256 fingerprint. This means: the hash is the proof of authenticity. Storing it on an immutable blockchain means the proof is permanent, auditable, and independent of the file storage system.
Practical example: A medical assessment PDF is uploaded. The system computes its SHA-256 hash and records it on the blockchain along with a timestamp and the uploading officer's identity certificate. Three months later, someone queries the file. They download the PDF, recompute its hash, and compare against the chain. If the hashes match, the file is provably the original. If they differ, the file has been altered — and the chain record shows when and by whom the original was certified.
Use the blockchain to store record metadata and hashes (fast, small, permanent). Store the actual binary files (PDFs, images, scans) on a government-approved file server or secure cloud storage. Link the two with the hash. This gives you tamper-evidence for files without making the blockchain unmanageable.
Lock-in is a legitimate concern for any director. If the organization decides to stop using this architecture, or if the technology partner is unavailable, what happens to the records that are stored in the shards and blockchain?
The data is yours, in open formats, with no dependency on the technology vendor. Hyperledger Fabric is open-source software maintained by the Linux Foundation — not a proprietary product that can be switched off. The ledger data is stored in standard database formats that any system can read.
Hyperledger Fabric is maintained by IBM, Red Hat, Walmart, SAP, and over 200 other organizations under the Linux Foundation. No single company controls it. If any one implementation partner disappears, the software continues to exist, continues to be supported, and any other developer can pick up and operate the existing nodes. Contrast this with a proprietary cloud database service — if that vendor shuts down or stops supporting the product, your data and your system are at risk.
The one area where exit complexity is real: the chaincode (business logic) written specifically for your use case will need to be re-implemented or maintained by whoever takes over. This is the custom code layer — the rules about what quorum thresholds apply, what conflict resolution strategy is used, what fields require validation. This code should be fully documented and owned by your organization from day one.
A QR code on a document does not store the document. It stores a pointer — a record ID and a fingerprint — that allows anyone with the right access level to verify authenticity against the blockchain. No personal data ever enters the QR code itself.
Think of a QR code in this system the way you think of a passport number. The number on its own tells you nothing about the person — but it lets the right authority look up the verified record in a trusted system. The QR code does the same: it's a verifiable reference, not a data store. What the scanner sees depends entirely on their access level — not on what's in the QR.
Access is tiered. The QR is the same for everyone. What the verification API returns depends entirely on who is asking and what credentials they present.
A stranger who scans the QR on a printed certificate using their phone camera learns: this document is authentic (or not). That is all. They learn no name, no identification number, no address, no medical or personal details. The QR is mathematically equivalent to a barcode on a product — it references a record without containing one.
Tier 0 scans are blinded: the verification API records that a record was queried (for rate-limiting) but does not log the scanner's IP address or device identity. Tier 1–3 scans are logged with the querying organisation's certificate, but individual employee identities are not stored.
No. The verification API enforces per-IP and per-API-key rate limits. A Tier 0 scanner can perform a limited number of queries per hour. Tier 1+ scanners are rate-limited by their API agreement. Even at maximum rate, a scan returns only a validity confirmation — no data accumulates. There is nothing to harvest at Tier 0.
No. Decoding the QR with any standard QR reader produces only a record UUID, a hash string, a timestamp, and a URL. None of these are reversible into personal data. The UUID is randomly generated. The hash cannot be reversed. The URL simply points to the verification API, which enforces the same tier controls as any other scan.
Copying a QR from one document to another: The QR contains a hash of the original document's contents. If a QR from Document A is placed on Document B, the verification API recomputes the hash of Document B and compares it against the hash stored on-chain for that record ID. The hashes won't match — the scan returns ✗ INVALID immediately.
Generating a fake QR with a valid-looking record ID: The QR includes a digital signature from the issuing node's private key. Forging this signature would require breaking the node's cryptographic key — computationally infeasible with standard 256-bit elliptic curve cryptography. The verification API checks the signature on every scan before querying the chain. A QR that fails signature verification is rejected before the blockchain is even consulted.
Replaying an old QR after a record is revoked: The blockchain holds the current version and revocation status. An old QR that points to a revoked or superseded record returns a clear "REVOKED — superseded on [date]" response at all tiers, regardless of when the QR was originally generated.
These technologies are not the right answer for every problem. This framework gives you the criteria to evaluate a candidate project before committing to the architecture.
| Problem type | Sharding | Private Blockchain | Verdict |
|---|---|---|---|
| Single server holds critical records — one failure loses everything | Solves this | Complements | Sharding is the primary fix |
| Documents or records are being forged or tampered with | Partial | Solves this | Blockchain is the primary fix |
| No single person should see a complete sensitive file | Solves this | Not relevant | Sharding only |
| Two organizations must verify shared facts without sharing databases | Partial | Solves this | Blockchain proof layer |
| An immutable, auditable log of every action is required by law or policy | Not relevant | Solves this | Blockchain only |
| Records must be verifiable across multiple physical locations without phone calls | Enables this | Proves authenticity | Both together |
| Records must survive the failure of up to 2 locations simultaneously | Solves this | Partial | Sharding is primary |
| Offline district needs to continue working and sync when reconnected | Local copy helps | Gossip sync | Both — with design choice on write mode |
Understanding what physically sits on each server — and what each encrypted fragment actually contains — is the foundation for sizing, costing, and designing a large-scale deployment.
A complete, chronological record of every transaction ever committed to the network — from the genesis block to now. Every peer holds the same ledger. No single node's copy is more authoritative than any other's.
Storage: ~500 bytes/tx · Grows ~5GB/month at 300K txs/dayA fast-access index of the current value of every record — the "latest version" derived by replaying all ledger transactions. Enables instant queries without re-reading the entire chain history.
Engine: CouchDB 3.x (supports rich JSON queries) or LevelDBThe encrypted data pieces for records assigned to this node. Each node holds exactly one fragment per record (e.g., Shard S2 of every record in its scope). The fragment is an encrypted binary blob — unreadable without the key and the other pieces.
Format: AES-256-GCM encrypted blobs · Indexed by record UUIDA cryptographic certificate issued by the network's Certificate Authority. It proves which organization this node belongs to. Used to sign every transaction and authenticate every peer-to-peer message. Cannot be forged without the CA's private key.
Standard: X.509 TLS certificate · Managed by Fabric MSPThe executable code that defines business rules — quorum thresholds, eligibility checks, conflict resolution policies. Runs in an isolated Docker container. When a transaction arrives, the chaincode validates it against the rules and produces an endorsement response.
Language: Go · Container: Docker Engine 24+ · Isolated sandboxThe peer-to-peer communication layer. Continuously shares new blocks with all known peers, detects nodes that go offline, and orchestrates ledger catch-up when a node reconnects. No central coordinator — nodes find each other and self-organize.
Protocol: Hyperledger Fabric Gossip (TCP over TLS)These specifications are based on Hyperledger Fabric production deployments and scaled for government-grade reliability. All figures assume 3-of-5 shard architecture with Raft consensus ordering.