從 BitcoinCore 導入的可信區塊鍊是否要求鏈狀態和區塊來自同一來源？

修剪節點的chainstate文件夾能否與完整節點的blocks文件夾一起使用以提供完整的區塊鏈？假設兩個節點都已經執行了幾個月。

如果blocks文件夾包含對chainstate文件夾中文件名的引用，那麼答案是否定的。我知道這一點，因為完整節點上鍊狀態中的文件名與修剪節點上的文件名不同。

另一方面，如果鏈狀態文件夾是UTXO集的獨立完整記錄，包括解釋它所需的所有指針、文件名和標識符，那麼似乎我不需要從完整的鏈狀態導入節點到雲伺服器。

獎金問題！出於好奇，這裡還有一個問題不會影響我的情況，但如果答案是否定的，那麼理解為什麼答案是否定的會很好。如果全節點上的鏈狀態文件夾損壞，是否可以將修剪節點上的鏈狀態文件夾放入其中進行恢復？

澄清

區塊和鏈狀態文件夾都反映了一個區塊提示，如果這兩個文件夾反映了不同的區塊提示，它們將是不兼容的。我應該明確指出，這個問題假設兩個不同的文件夾來源都將同步到相同的塊高度。

一個有趣的邊緣情況是，如果他們使用相同的塊高度，但他們在該高度使用的塊是兩個有效但不同的塊，會發生什麼情況。

看來答案是肯定的。我還沒有完全確定它是成功的，但看起來它正在朝著那個方向發展。以下是我遵循的步驟：

1. 關閉修剪的節點。
2. 編輯 bitcoin.conf 將 pruned=10000 更改為 pruned=0
3. 更新啟動腳本以指向已包含 blocks 文件夾的新 400GB 卷。
4. 將除塊文件夾之外的所有內容從目前數據目錄複製到新卷。
5. 重新啟動（現在未修剪的）節點。

請注意，這些步驟都不包括在特定塊高度停止任一節點。事實上，我相當確定下面描述的問題都是由於 chainstate 文件夾與 blocks 文件夾處於不同的塊高度。

調試日誌顯示了這一點：

2020-01-02T02:47:48Z : Error initializing block database.
Please restart with -reindex or -reindex-chainstate to recover.
2020-01-02T02:47:48Z Aborted block database rebuild. Exiting.
2020-01-02T02:47:48Z Interrupting HTTP RPC server
2020-01-02T02:47:48Z Interrupting RPC
2020-01-02T02:47:48Z Shutdown: In progress...
2020-01-02T02:47:48Z Stopping HTTP RPC server
2020-01-02T02:47:48Z Stopping RPC
2020-01-02T02:47:48Z RPC stopped.
2020-01-02T02:47:48Z scheduler thread interrupt
2020-01-02T02:47:49Z Shutdown: done

即使在我使用了 -reindex-chainstate 之後也發生了這種情況，所以我改用 -reindex 進行了嘗試，現在它繼續執行，每小時重新索引近 2000 個 blk#.dat 文件中的大約 460 個。如果在大約 4 小時內完成後一切正常，我也會在這里報告。即使在它載入了塊之後，它還有更多的工作要做，儘管我沒有測試它在載入塊後是否更有功能。它開始更新提示： 2020-01-04T05:01:06Z UpdateTip: new best=000000000000000000467af08dc436c11dfe1c49d62510aad9753ea3bcd30dc7 height=509848 version=0x20000000 log2_work=88.159019 tx=300224686 date='2018-02-19T00:41:58Z' progress=0.617787 cache=672.1MiB(5030801txo) 對於有更多交易的區塊，這似乎需要更長的時間，這表明它仍在驗證（除了索引之外）。

以下是修訂後的步驟列表，可以測試這些步驟以回答“是” ：

1. 將塊文件夾從完整節點複製到修剪節點的新數據目錄，但讓兩個節點都執行。
2. 請注意每個節點的 blocks 文件夾中的最新文件時間戳。
3. 驗證每個節點上的塊高度是否相同，然後關閉它們。請注意，如果在關閉任一節點後，其塊文件夾顯示的文件修改時間晚於您在上一步中記錄的時間，則可能已在一個節點上處理了一個塊，而不是在另一個節點上，因此請重新啟動它們，不要’不要忘記重新複製最後一個 blk#####.dat 文件和任何 rev#####.dat 文件，然後返回上一步。
4. 編輯 bitcoin.conf 以將 pruned=[not 0] 更改為 pruned=0
5. 更新您的 .conf 文件或快捷方式以指向修剪節點上數據目錄的新位置。
6. 將除塊文件夾之外的所有內容從修剪節點上的目前數據目錄複製到新目錄。
7. 重新啟動（現在未修剪的）節點。

它不是自給自足的。鏈狀態包含對同步狀態唯一的塊內位置的引用。

引用自：https://bitcoin.stackexchange.com/questions/92530