Capability Details

Consortium Chain

FISCO BCOS consortium chain: transcripts and key records are attested on-chain, verifiable and tamper-proof.

01 / Technology decisions

Three trade-offs you cannot avoid

Each has its own cost; here is which side we chose and why.

Whether to use a chain: a real need or just the concept

Common practicePutting every kind of data on-chain

AlternativePut data on chain only when multiple distrustful parties need a shared ledger

Our approachStructured data hashed on-chain, original file kept locally

The chain solves the problem of multiple parties not trusting a centralized ledger. If only one entity writes the data, a database plus an audit log is enough; going on-chain only adds cost. Our criterion is this: it is worth going on-chain only when 3 or more mutually independent parties jointly produce or consume the same record.

What goes on chain: the original text or a hash

Common practiceWrite the full data on chain

AlternativeOnly the hash goes on chain, the original stays in the business database

Our approachKey fields plus a hash on chain, everything else stays local

Putting full text on chain means storage and sync costs grow linearly with data volume, and on-chain data cannot be deleted — once wrong information is written it cannot be corrected. The practical approach: write the key fields that uniquely identify the record (number, timestamp, subject) plus a content hash to the chain, and keep the original text in the business database. Verification compares hashes — same effect, an order of magnitude cheaper.

How to place nodes: who provides the machines, who maintains them

Common practiceAll nodes hosted by us

AlternativeEach participant contributes one node and maintains it independently

Our approachRegulator and key participants each run a node; we provide operations support

Fully hosted means recentralisation and defeats the point of a chain. Ideally every participant runs a node, but in practice many organisations will not maintain a server for a single chain. The compromise: key participants — regulators above all — each run a node, and everyone else connects to hosted nodes.

02 / Option comparison

One problem, three approaches

There is no optimal solution, only solutions that fit the scenario.

Solution	Trustworthiness	Cost	Use cases
Database + audit log	Depends on trust in the central party	Low	Internal traceability within a single entity
Consortium Chain (from 3 nodes)	Co-attested by multiple parties	Medium (needs 3 machines + operations)	Multi-party collaboration with tamper resistance
Public chain	Fully open	High (gas costs + poor performance)	Scenarios that need open, external verification

The vast majority of government and enterprise scenarios use consortium chains, not public chains.

What we do

3-node consortium chain · PBFT consensus
Transcript SHA-256 fingerprint anchoring
7 assessment systems · 9 software modules
On-chain verification API · Tamper-proof and traceable

Discuss requirements

Delivery format

Deployment modelOn-Premise / Private Cloud / Intranet

Scope of deliverySystem + Documentation + Training

Maintenance supportRemote + on-site

Source Code DeliveryNegotiable

Related Cases

Proven systems

Client names are anonymized per confidentiality requirements.

Government / consortium chain + assessment system

Provincial Work Safety Assessment Platform

Background: Provincial assessment needs trustworthy records; paper transcripts can be altered and cannot be verified across institutions.
Solution: AI Integrated Assessment System: 7 assessment systems, 9 software modules, transcript fingerprints anchored on-chain.
Technology: FISCO BCOS 3 nodes · SHA-256 fingerprint anchoring · on-chain verification interface · multi-party collaboration
Outcomes: Transcripts can be verified independently on chain, recognised across institutions and cannot be tampered with.

Port / Agent + Consortium Chain + App

Large Container Port · Smart Safety Training Centre

Background: A container port ranked among the top in China by annual throughput. Its existing training was mostly classroom lectures and could not cover hands-on practice for high-risk operations.
Solution: Comprehensive safety training centre + training and assessment platform + mobile learning. 7 assessment systems, 9 software modules, a 3-node consortium chain.
Technology: FISCO BCOS consortium chain (PBFT) · transcripts anchored on-chain via SHA-256 · node.js back end · Android client · 3D model interaction
Outcomes: Training records verifiable on chain and tamper-proof transcripts; covers 55 equipment categories and 66 equipment ledger entries.

View all case studies

03 / Implementation path

How many steps from zero to launch

The order cannot be reversed: starting with write operations or multi-step orchestration makes errors very hard to trace.

Confirm the multiple parties

Ask first: how many independent parties are involved? If there is only one, do not put it on a chain.

Choose the consensus and node count

3 nodes with PBFT is the minimum viable configuration and tolerates 1 node failure. Add more according to the number of participants.

Design the on-chain data structure

Decide which fields go on chain, which stay local and how the hash is computed. Once fixed, this is hard to change.

Connect business systems

Map business operations to on-chain transactions through the SDK, and build in asynchronous handling and retry on failure: chain writes are slower than database writes.

Provide a verification entry point

Give end users a page they can check: enter an ID and get the on-chain record plus the hash comparison. A chain without a verification entry point is as good as none.

04 / Key metrics

Verifiable Numbers

No adjectives; write the specifications.

Number of NodesFrom 3　PBFT consensus, tolerates 1 node failure

Time per on-chain write1–3 seconds　Consortium chain, non-high-concurrency scenarios

Hash algorithmSHA-256　Content fingerprint

Verification methodLook up on chain by number + hash comparison　Publicly verifiable

05 / FAQ

What technical leads ask most often

These are questions we have actually been asked, answered without marketing spin.

Are 3 nodes enough?

Enough for small-scale scenarios. PBFT tolerates one faulty node out of three (including Byzantine behaviour), which meets the availability needs of most internal systems. Scale the node count when there are more than three participants.

Can on-chain data be deleted?

No. That is the nature of a chain, and also its problem — so before going on-chain you must confirm the data is final. We put only confirmed results on-chain and keep process data in the business database.

Will performance be slow?

Consortium chain writes typically take seconds, one or two orders of magnitude slower than a database. Hence the asynchronous design: the business operation is written to the database first and pushed on-chain asynchronously, so what users see at verification is the eventually consistent record.

Can it integrate with existing business systems?

Yes, via an SDK or a middleware service. We have integrated three kinds of data: transcripts, equipment ledgers and assessment records.

Should we buy a third-party BaaS?

For small scale, self-hosting is more controllable and cheaper (three machines). BaaS saves on operations, but scenarios with sensitive data usually do not want to hand the chain to a third party.