Quorum - 跟踪結構中的狀態變數更改（數據沿襲）
我無法在 Quorum 的結構中獲取我的 bytes32 變數狀態轉換。我所做的是建構一個儀表板來循環通過區塊鏈來搜尋一個特定的然後列出塊號、從、到等。
雖然我只能獲取更改狀態變數的事務輸入，但我無法獲取 bytes32 變數更改轉換本身。例如，新 -> 已送出 -> 已關閉
我在這個論壇上閱讀了許多方法——使用事件，添加到另一個數組。我相信所有這些都是解決方法。
是否有任何優雅的解決方案可以在 Quorum 中實現這一目標？要跟踪狀態變數的變化，而不是僅僅獲取改變變數狀態的交易輸入？數據沿襲是分佈式賬本的關鍵屬性。
謝謝你。
Quorum 是乙太坊的專業化。我的回答和方法適用於這兩個平台，因為它不涉及 Quorum-only 問題，例如
privateFor.提出問題的方式暗示了一些需要澄清的概念性問題。讓我們從唾手可得的果實開始。在這兩種情況下，數據沿襲都是給定的。這些是僅附加系統，如果沒有由外部擁有的帳戶簽名的交易鏈（和輸入），則什麼都不會存在。
我認為可以公平地說細節是關於誰/什麼需要血統資訊以及出於什麼目的。正如您所描述的，在原始數據中翻找對開發人員來說並不是特別友好。我的觀點是，從區塊鏈的角度來看，血統是存在的。無論我們建構什麼，都將針對特定的使用者和目的。
我建議你可能低估了日誌的重要性。“日誌”這個詞可能暗示一些非正式和不重要的東西，但它們是一個強大的工具。它們大致類似於具有特定列的表。它們可以被索引。它們是可搜尋的。它們是低成本的不可變儲存。除非合約函式發出它，否則沒有任何東西可以進入日誌。它們使感興趣的客戶能夠“觀看”並做出回應。
一個好的預設設計模式和實踐是為合約中發生的每個狀態更改發出一個事件，這樣理論上可以完全重建合約的狀態歷史，只使用以正確順序讀取的事件日誌。如果您這樣做，則沿襲是給定的，但也方便且圍繞特定應用程序進行組織。
另一個好的預設習慣是使目前狀態完全可發現。也就是說，客戶端應該能夠了解目前狀態的每一個細節，而無需費力地通過日誌來重新組裝所有東西。
由於這兩種方法都作為一種標準操作過程來實現，客戶端軟體有兩種查詢方式，甚至可以探索“目前”狀態在前一個塊中的樣子。事件日誌提供了一種不可變且可靠的方式來發現狀態變化的事務、誰簽署了它們、數據有效負載等，這使得目前狀態成為我們發現它的方式。
有一個限制。契約不能（輕鬆）探索日誌，儘管我已經看到了一些聲稱可以做到這一點的彙程式序的實驗性工作。
這種限制通常不是問題，因為契約本身通常關注目前狀態和接下來會發生什麼。他們很少需要探索過去。正如我試圖描述的那樣，通過將事件發送到日誌中，大多數合約已經完成了他們的任務，使任何感興趣的軟體客戶端能夠在閒暇時探索過去。
以下是一些需要考慮的啟發式方法。
- 如果合約邏輯依賴於一條狀態資訊，那麼日誌儲存是不夠的。數據需要儲存在合約狀態中。
- 合約邏輯主要關注考慮提議的狀態變化，繼續前進。你會開始看到，當涉及到合約邏輯時，它很少涉及過去。
並不是我無法想像如何在契約狀態下組織一個血統結構。我想沒有必要為了實現所有可傳遞成果而這樣做。操作起來可能會不必要地複雜和昂貴。或者，這是一個非常罕見的案例。
希望能幫助到你。