I am unable to get my bytes32 variable state transition within a struct in Quorum. What I did is to I build a dashboard to loop through the blockchain to search for a particular then list out the block number, from, to, etc.

Though I am only able to get the transaction input that changed the state variable, I am not able to get the bytes32 variable change transition itself. E.g., NEW -> SUBMITTED --> CLOSED

I read on this forum many approaches -- using events, add to another array. I believe all these to be workarounds.

Are there any elegant solution to achieve this within Quorum? To track the state variable change, instead of just getting the transaction input that changed the variable state? Data Lineage is a key attribute of distributed ledger.

Thank you.

  • If you can give us the contract code...that would be a help – Mr_Hmp Jun 26 '18 at 2:04

Quorum is a specialization of Ethereum. My answer and approach applies to both platforms as it does not touch on Quorum-only matters like privateFor.

The way the question is framed suggests some conceptual matters to clear up. Let's start with the low-hanging fruit. Data lineage is a given in both cases. These are append-only systems where nothing can exist without a chain of transactions (and inputs) signed by externally owned accounts.

I think it's fair to say the details are about who/what needs lineage information and for what purpose. As you have described, it's not especially developer-friendly to rummage around in raw data. My point is that lineage is there, as a given, from a blockchain perspective. Whatever we build out will be aimed at a specific user and purpose.

I would suggest that you possibly underestimate the importance of Logs. The word "Log" might suggest something informal and unimportant but they are a powerful tool. They are roughly analogous to tables with specific columns. They can be indexed. They are searchable. They are low-cost immutable storage. Nothing can get into the Log unless a contract function emits it. They enable interested clients to "watch" and respond.

A good default design pattern and practice is to emit an event for every state change that occurs in the contract such that it would be theoretically possible to completely reconstruct the state history of the contract using nothing but event logs read back in the correct order. If you do that, lineage is a given, but also convenient and organized around a specific application.

Another good default habit is to make the current state completely discoverable. That is, a client should be able to learn every detail of the current state without wading through logs to reassemble everything brick by brick.

With both methods implemented as a sort of standard operating procedure, client software has two ways to inquire and can even explore what the "current" state would have looked like in a prior block. Event logs provide an immutable and reliable way to discover the state-changing transactions, who signed them, the data payload, etc. that made the current state the way we find it.

There is a limitation. Contracts cannot (easily) explore logs, although I've seen some experimental work with assembler that claims to make that possible.

This limitation is not normally a concern because contracts themselves are usually concerned with the present state and what comes next. They seldom need to explore the past. As I've tried to describe, by emitting events into the logs, most contracts have completed their task, enabling any interested software client to explore the past at their leisure.

Here are some heuristics to consider.

  1. If contract logic depends on a piece of state information, then log storage is insufficient. The data needs to be stored in the contract state.

  2. Contract logic is mostly concerned with considering proposed state changes, going forward. You will start to see that when contract logic is involved, it's seldom about the past.

It's not that I can't imagine how to organize a structure of lineage inside contract state. I imagine it isn't necessary to do so in order to achieve all the deliverables. It would probably be unnecessarily complex and expensive to operate. Or, it's a very rare use-case.

Hope it helps.

  • 1
    Hi Rob, it certainly certainly helps. very useful to my understanding. You are a terrific guy. Extraordinary individual. I have marked your answer as correct. Thanks again – Nathan Aw Jun 27 '18 at 1:20
  • Thanks, Nathan. I upvoted your comment to keep the awesome flowing. Best of luck with your pursuit. – Rob Hitchens - B9lab Jun 27 '18 at 1:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.