Blockchain data provenance for Schneider Electric's data marketplace
a proof of concept
Schneider Electric's product innovation team wanted to test what a blockchain record could prove about files traded on its data marketplace. With its product owner, Aetsoft defined the scope (every version uploaded through the application, the client who registered it and monitored server activity, but not edited copies), then built working software that let sellers and buyers check whether a file matches a recorded version.
In 2020, Schneider Electric Exchange let companies upload datasets and sell them to other companies. The original concern was a buyer changing a purchased dataset and republishing it under another name. Two questions mattered on both sides of a sale: is this the authentic version the seller published, and has anyone changed the stored file since?
001
ClientSchneider Electric, the energy management and automation group. The work was run with its product innovation team, which tested new product ideas.
002
ChallengeSellers and buyers needed independent proof that a dataset was the version its seller published, and that nobody had changed the stored file since.
003
SolutionA permissioned ledger records each uploaded file version and the user account that uploaded it. It also records monitored server activity. A verifier checks whether a copy matches a recorded version.
004
Aetsoft's roleScope and solution design with Schneider Electric's product owner, then architecture, the build of the software and handover.
Aetsoft captured activity in the application and on the storage server and sent the records to a permissioned ledger first. New file records reach the application database only after the ledger has committed them, and each one can be checked in the ledger explorer. Recognising an edited copy uploaded as new needs a different tool, so Aetsoft and the product owner left it out of scope. The proof of concept ran on its own environment, outside the live marketplace. Aetsoft then handed it over to Schneider Electric.
The problem
Nobody outside the platform could prove what was published or changed
The platform's database recorded every upload, but nothing outside Schneider Electric's own systems could confirm which version a seller had published, or whether the file had changed since.
The gap showed up in two places. From outside, a buyer could download a dataset, change a few columns and upload it as a new listing under their own name. The platform's records would show the original upload, but a database the operator can edit is weak evidence in a dispute between two of its customers. An immutable record, kept apart from that database, would carry more weight.
Inside the platform, the question was assurance. Sellers trusted Schneider Electric with their stored files, and a trusted operator still needs a way to show that nobody changed them, by mistake or otherwise.
The business case
The record had to hold up without trusting the storage operator
The record had to be checkable by people outside the team that runs the storage. Schneider Electric's product owner and Aetsoft defined four requirements for evaluating it.
1. Detect a mismatch. Compare a file with its expected recorded version and see whether it differs.
2. Inspect version history. Show recorded uploads and updates with their version numbers, registering accounts and times.
3. Verify a copy. Let a signed-in user check whether a file from any source matches a recorded version.
4. Inspect server activity. Show monitored activity in the storage folder, including activity by administrator accounts.
The platform's records and server logs were held by the storage operator. Independent checking needed a reference that other parties could keep and verify.
Write-once storage with logs sent off the server is the stronger alternative, and it would stop most quiet edits. It still leaves one operator holding both the files and the evidence about them. Sellers, buyers and auditors outside that operator would have to trust it.
The target design for Exchange spread the record across a ledger run by several parties, with an independent auditor, so no single operator could rewrite it. The proof of concept showed version recording, hash lookup and server monitoring working on a single host. Running the record across several parties was left to the production design.
The business case
The record had to hold up without trusting the storage operator
The record had to be checkable by people outside the team that runs the storage. Schneider Electric's product owner and Aetsoft defined four requirements for evaluating it.
1. Detect a mismatch. Compare a file with its expected recorded version and see whether it differs.
2. Inspect version history. Show recorded uploads and updates with their version numbers, registering accounts and times.
3. Verify a copy. Let a signed-in user check whether a file from any source matches a recorded version.
4. Inspect server activity. Show monitored activity in the storage folder, including activity by administrator accounts.
The platform's records and server logs were held by the storage operator. Independent checking needed a reference that other parties could keep and verify.
Before any code was written, Aetsoft and Schneider Electric's product owner settled the scope. The record would prove exact versions, who registered them and monitored server activity, and would not try to recognise edited copies. Three decisions led there, and they were the blockchain consulting work in the engagement.
The first decision was what to prove. Schneider Electric's original concern was a buyer relisting an edited copy, and the first concept answered it with similarity checks on every upload. A file fingerprint cannot do that job. A SHA-256 hash, the fingerprint used here, matches one exact file, and changing a single character produces a different hash. Recognising an edited copy needs content analysis across datasets, a separate capability with its own error rates.
So the scope became provenance: which version existed, when, who changed it, and whether a file in hand is one of those versions. Each recorded hash is tied to the client account that uploaded the file and the server's timestamp for the upload. A buyer can check that the dataset they paid for is the version the seller published.
A match proves that a file is an authentic recorded version and shows which client registered it, with the upload timestamp. That dated record makes tracing ownership easier if a dataset later reappears under another name.
In the proof of concept the platform's own key signed every record, so attribution rested on the client account the platform had authenticated. In the target design, owner wallets would let each client sign with its own key.
The second decision was where to capture activity. Recording what users did in the application would have missed anyone who changed files directly on the server. So the system captures activity on two paths: through the application, and at operating-system level on the storage server, where Linux audit watches the storage folder.
The third decision was how much to build. Aetsoft designed the complete route into Exchange and built four of its parts: capture, ledger, verification and monitoring. Because those parts matched the target design, Schneider Electric could judge the working software against the full design.
The solution
Every uploaded version and monitored event is committed to the ledger first
Two capture paths, one ledger
Aetsoft built the file recording, verification and server monitoring as custom software.
Backend services in Go, a web application in React and TypeScript, and ledger logic on Hyperledger Sawtooth.
Each upload and new version becomes a signed ledger record
When a user uploads a file, the API server calculates its SHA-256 hash and builds a record. It holds the file name, the hash, the operation and the author. It also holds the file's timestamps, its size and its version number. Uploading a file under an existing name through the application creates the next version.
Next, the record goes to a gateway service, which rejects a record missing its hash, author or other required fields, signs it with the platform's key and submits it to Sawtooth.
A transaction processor that Aetsoft wrote in Go then checks the transaction's format and address and adds it to ledger state. Transaction processors are Sawtooth's form of smart contract development: the rules that decide what the ledger accepts.
The file itself stays in storage. Only its fingerprint and metadata go to the ledger, so the dataset is never copied onto a system that other parties run.
Committed ledger records fill the application database
Writing each new record separately to the application database and to the ledger creates two update paths that can drift. Aetsoft used one sequence for new records instead. The API server sends the record towards Sawtooth and does not write it to the database itself.
A separate listener reads each transaction once Sawtooth has committed it and copies the record into MongoDB, which the web application queries for file history, versions and hash matches. Users of the environment can open the matching transaction in the ledger explorer. Editing the application database does not change that ledger record. Deleting a file was the exception in the proof of concept. It hid the file in the database and wrote nothing to the ledger, and version numbers were read from the database.
Signed-in users can check any copy against recorded hashes
A signed-in user selects a file, wherever the copy came from. The application calculates its SHA-256 hash and searches the recorded versions for a match. A match shows the hash, the account, the operation with its version number, and the date.
In the demonstration, version 3 of a sample file, report2019.txt, showed the same hash in the verifier result and in the committed Sawtooth transaction. A match identifies a recorded version. No match means the file does not match any version in the records searched.
Server-level monitoring records activity in the watched storage folder
Access below the application is captured on the storage server itself. Linux audit, the operating system's own audit framework, watches the storage folder and records file access events there. A monitoring service that Aetsoft wrote collects those events and filters out activity from the application server and one configured system account. At regular intervals it writes the remaining events to the same ledger as warnings.
Each warning records the file, the time, the program used and the login account. Linux audit records the original login account, which is designed to stay with a session even after someone switches to administrator rights. A monitoring page lists these events by file, user and time.
The monitoring page shows captured server activity, and the verifier shows whether a file matches a recorded version. A changed file could still match an older recorded version, so users compare the returned version with the one they expect. In the target design, an independent auditor would compare stored data with ledger records automatically.
In the proof of concept the monitoring and the ledger ran on one host, so its administrator could still switch them off. In the target design, other parties would run ledger nodes and an independent auditor, and the storage operator would no longer control the record alone.
Hyperledger Sawtooth let Schneider Electric control who writes to the ledger
Hyperledger Sawtooth is a permissioned ledger, so in a production network Schneider Electric would decide who runs nodes and who writes.
It also accepts custom validation code in Go and deploys with Docker. In the proof of concept a single platform key wrote every record.
How the engagement run
Three stages took the project from concept to handover
The engagement ran in three stages over about ten weeks.
Define
Aetsoft and the product owner in Schneider Electric's product innovation team worked through user journeys for a seller publishing a dataset and a buyer receiving it. The first concept included encryption, owner wallets, an auditor and similarity checks. They kept the first three in the target design, set similarity checks aside, and chose the part the proof of concept would build.
Deliver
Aetsoft drew the target architecture for Exchange and the narrower architecture of the proof of concept, built the system, and demonstrated it to Schneider Electric on a working environment.
Hand over
Aetsoft handed the software to Schneider Electric with a build and deployment guide, so its team could run it independently.
Working software was the
result, with integration
designed but not built
Schneider Electric received a working provenance proof of concept to evaluate. Whether to integrate it into Exchange was Schneider Electric's decision.
Beyond the marketplace
The same checks fit documents that suppliers and manufacturers hand over
- A provenance record like this one applies wherever one company hands a file to another and both need to show later that it has not changed.
- Take a component supplier that issues a test certificate for a batch. The manufacturer can check that the copy in its quality file is the version the supplier issued, before the batch goes into production.
- Drawings and configuration files sent to a contract manufacturer or installer change often. An installer can identify which recorded version matches the file on a laptop, then compare it with the revision required for commissioning.
- Inspection reports matter most after something goes wrong. An insurer reviewing a claim can confirm that its copy is the report the service contractor filed. The monitoring history adds evidence of recorded activity involving the stored copy.
- Sensor readings across a physical supply chain are a different problem, because the record covers measurements rather than files. Aetsoft's IoT blockchain integration for Centaur's crop monitoring records storage conditions for grain as it changes hands.
Frequently asked questions about blockchain data provenance
-
Which blockchain would you use in production?
It depends on the use case. Where a known group of organisations shares the record, a private permissioned network such as Hyperledger Fabric fits, because its channels keep records private to the organisations that share them. Where anyone outside that group must be able to check a file, recording hashes on a public chain can make more sense. Sawtooth suited the 2020 proof of concept. Hyperledger archived the Sawtooth project in 2024, and its maintainers pointed users to the Splinter community.
-
Does a matching hash prove who owns the data?
It proves authenticity and attribution. The file is a recorded version, registered by a named client account at a recorded time, which is strong evidence of who published it and makes ownership easier to trace. Legal title and usage rights are still set by the contracts between the parties.
Decide what your record has to prove, then see it working before it touches a live platform. We define that scope with you and build the proof of concept that tests it.
