雪花之書 (Snowblossom) v2021.09.13

English: https://tradingt.com/book-of-snowblossom/ 作者： Joseph Gleason / Fireduck

背景介紹 #

2012年，我爲Satoshidice創建了後端交易處理和可證明的公平程序。

2013年，我創建了一個比特幣礦池實現，SockThing。 當然，還有一個礦池，htt。

在2014年，我開始爲當時表現不佳的參考電子書服務器jelectrum做一個java的替代品。

通過這些項目，我對比特幣的內部結構和粗糙的邊緣有了一個非常好的瞭解。 一些關鍵的收穫。

● 爲什麼字節排序的事情會如此奇怪？

● 爲什麼有這麼多方法來構建對一個地址的付款？

● 這段C++代碼相當難讀

目標 #

我對Snowblossom的目標是做一個純粹的加密貨幣，更簡單，有一個更乾淨的代碼基礎。

改進措施 #

雪花辮(分片）/ Snowblossom Braid (Sharding) #

概述 #

一般來說，加密貨幣以單一的順序區塊鏈運作。 只有在充分了解幣的狀態（特別是UTXO集）和順序的情況下才能進行驗證。 這大多限制了任何加密貨幣，使其數據集足夠小，適合在一臺計算機上使用，而且交易率低到可以由一臺計算機處理。 即使你試圖使用多臺計算機，區塊鏈的順序性使得驗證任務無法進行。

Snowblossom Braid是一種升級，使一組相互關聯的順序區塊鏈，這樣的工作可以被分割開來，由多臺計算機處理。 這將使交易率大大增加，但要付出一些開銷。 這通常被稱爲分片。

重要的加密貨幣行爲 #

在討論任何分片方案時，必須強調用戶所依賴的單鏈加密貨幣的行爲，以討論分片方案如何維持這些行爲。

  • 交易的終結性

    用戶似乎大多接受這樣的概念，即一項交易首先是待定的或有風險的，然後稍後它將被確認，然後更多的確認將在隨後的區塊中堆積，直到用戶滿意地認爲該交易不會被逆轉（通過區塊鏈重新組織），並且可以被指望。

    在這個Snowblossom Braid中，這一切仍然是真實的，但最終的評估要更復雜一些。 我們不只是問一個交易有多少個確認，而是要問哪些分片包括了交易的區塊。 將會有一些客戶端工作來使用戶清楚地瞭解這一點。

  • Fire-and-Forget

    當用戶在點對點加密貨幣網絡上發送交易，並且該交易被接受到mempool中時，用戶可以相當自信地認爲該交易最終會被確認。 他們不需要做任何其他事情。 當然，在交易被確認之前，這並不是一種保證，但在大多數情況下，用戶可以簡單地發送交易，然後斷開與網絡的連接，去種植一些花。

    這種行爲在Snowblossom Braid工作中得到了保持，但有一個例外。 在辮子系統中，一個用戶可能在多個分片上有未使用的資金。 這意味着如果他們想發送，但在一個分片上沒有足夠的資金，他們將不得不爲所需的發送做（實際上他們的客戶端軟件會這樣做）多個交易。 這可以通過兩種方式實現。

    1) 根據需要從每個分片中發送部分付款。 這樣一來，收件人就能儘快得到資金，而且 “火燒眉毛 “的效果也很好。

    2) 用戶可以做一個交易，將資金整合到一個分片上，然後再發送交易，將其發送到目的地。 如果沒有一些額外的工作，比如爲等待輸入的交易建立一個特殊的內存池，這在 “先斬後奏 “中是行不通的。

  • 無雙花/Consistent State View

    這與上面的 “Fire-and-Forget “有關，但更多的是在收款人方面。 當你看到一個待定的傳入交易時，你希望能夠知道該交易很可能會被確認。 你至少應該有足夠的信心讓付款人帶着咖啡或烤麪包機離開，但也許不能帶着汽車。 對於汽車，你可能想等待一些確認。

    這部分是由標準的 “先見先得 “行爲完成的。 這意味着第一個使用特定交易輸出的有效交易可以獲得它，其他使用該輸出的交易將不被接受進入mempool。 這並不是一種保證，因爲不同的節點可能對mempool的狀態有不同的看法，或者節點可能被重新啓動而失去mempool的狀態。 然而，在大多數情況下，這工作得很好，可以依靠小交易。 這繼續與Snowblossom Braid一起工作，因爲每個輸出在創建時（當交易進行時）被綁定到一個分片上，所以正常的mempool規則適用於從該分片上花費它的交易。 沒有其他分片可以花費它。

  • 用戶不關心細節

    雖然用戶應該總是被賦予檢查細節的選項，但在大多數情況下他們並不關心。 他們不想做UTXO管理。 他們不關心他們的產出在什麼分片上，他們不應該知道。 雖然還沒有完成，但Snowblossom Braid的面向用戶的客戶端代碼應該考慮到這一點。

開發和部署 #

Snowblossom Braid在testnet上運行，來自snowblossom git的一個名爲’shardo’的分支。 它已經在高達128個分片的網絡中進行了大量的測試，代碼運行良好。

很快我們就會討論將其引入主網的問題。

如果它確實進入了主網，總的區塊獎勵將是相同的。 它更復雜，但最終的總和將是相同的。 與其說一個區塊的獎勵是簡單的50SNOW，不如說是50SNOW分散在當時所有的區塊高度的分片中。 爲了獲得更多的樂趣，獎勵的一部分是包括來自其他分片的區塊。 但它的總和仍然是與單一區塊鏈的每個區塊高度相同的獎勵。 因此，幣的供應將保持不變。

分區是由使用量觸發的，所以最初主網將只是一個單一的分區（就像現在一樣）。 此外，所有現有的歷史，交易和地址將被保留。 這將是一個到位的協議升級，而不是一個新幣。

結構 #

辮子結構之所以被稱爲辮子，是因爲像頭髮的辮子一樣，有一些股在某些方面是獨立的，但也相互聯繫，形成一個單元。 它是一組交織在一起的區塊鏈。 每個分片都會有一個像其他區塊鏈一樣的區塊序列，但有以下變化。

● 每個區塊可能包括來自其他分片的區塊的標題。

● 一個事務只能從當前分片的輸入中支出。 他們可以把輸出寫到任何其他分片上。 輸出被標記爲交易數據的一部分，以便交易創建者可以在哪個分片上花費。

● 每個分片只能領先其他分片這麼遠，這將是一個定義的最大距離。 例如，如果我們將最大距離設置爲4，那麼爲了讓一個分片做出一個高度爲1000的有效塊，它必須包括其他分片的頭，至少高度爲996。

● 其他分片的包含頭必須形成一個連續的區塊鏈。 這意味着如果我們包含了另一條鏈上的區塊的頭，我們必須已經包含了該區塊的父塊。 這就是我們管理UTXO交接的方式，確保我們從其他鏈上獲得每個塊，以便導入相關的UTXO。

  • UTXO管理

    當一個區塊在一個分片上被創建時，除了它自己的內部UTXO管理外，任何去往其他分片的事務輸出都會形成一個導出集。 這些是當其他分片包括這個區塊時需要被編碼的UTXO。

    當一個區塊被包括在內時，從該區塊到該分片的導出集被整合到該分片的UTXO中。

    這樣，我們就有了一個連貫的方法來將UTXO從一個分片區安全地轉移到另一個分片區。 源分片正好包括一次輸出。 UTXO只有在目標分片中包括有它的塊時纔會被導入。

  • 分區ID和創建

    每個區都有自己的PoW難度，只基於該區本身的區塊率。

    我們沒有預先決定分片的數量，因爲每個分片都有一些額外的開銷，我們決定按需製作分片，只在協議中定義分片的最大數量。 爲了使其發揮作用，每個分片都有一個運行的交易規模值，表明最近的區塊有多滿。 當分片超過協議定義的滿度閾值時，分片將分叉。 這個分片將停止獲得新的區塊，兩個新的分片將開始使用舊分片的最後一個區塊作爲父區。 新分片將擁有一半的PoW難度，一半的父分片的區塊獎勵。 其中一個分片將繼承父分片的UTXO。 另一個將從一個空的UTXO開始。 繼承父方UTXO的分片也將導入任何UTXO出口到父分片的ID。

    例如，當分片2分裂時，它創建了分片5和6。 分區5將繼承分區2的UTXO。 任何未來對分片2的出口都將由分片5導入。

    此外，一個分片將把UTXO導入到任何未來的子分片。 例如，如果在分片2分裂之前，有一個輸出到分片5，它將被分片2導入。

    這意味着，一旦網絡上啓用了分片，事務將能夠向任何有效的分片ID寫入輸出。 這些將被映射到當前存在的分片。

    Shard ID結構是在ShardUtil中定義的。 一般來說，其形式是，分片N的子女是。

    N*2+1（繼承UTXO）和N*2+2

    這裏是樹的前幾層。

    0

    1 2

    3 4 5 6

    7 8 9 10 11 12 13 14

    注意：由於分片根據它們自己的內部負荷決定分裂，它們可能不會同時擴展。 例如，該辮子可能由分片組成。{1，5，6}或{1，2}或{3，4，5，6}。

  • 塊狀獎勵

    區塊獎勵比單一區塊鏈的情況要複雜一些，而總和仍爲相同的數字。

    一個分區內的區塊獎勵是。

    讓shard_faction成爲這個分片所代表的整個樹的一部分。 例如，分片0將是1/1（整個樹）。 分片1是(½)。 分片5將是(1/4)。

    讓direct_faction = 0.75

    讓間接派=0.25

    區塊獎勵 = general_block_reward * shard_faction * direct_faction

    • general_block_reward * shard_faction * indirect_faction *

    shard_faction

    • shard_faction * sum( general_block_reward * indirect_faction *

    included_shard_faction)

    換句話說，區塊本身有一個片斷，然後爲我們包括的另一個分片的每個區塊有一個片斷。 這就產生了一個激勵機制，讓我們儘可能多地包括其他分片，形成一個緊密聯繫的辮子。

    下面是它的代碼。ShardUtil.getBlockReward

場景 #

  • 壞塊

    這幾乎是最壞的情況。 這是令人討厭的，但如果礦工們很小心（而且小心會讓他們賺更多的錢），這將永遠不會發生。

    假設有6個區塊，A、B、C、D、E、F。 一個礦工在A區創建了一個高度爲100的區塊（我們將其記爲A100）。 A100有一個有效的頭，但有一個無效的交易。 其他礦工得到了A100的頭，頭是有效的，所以他們使用了它（礦工不應該這樣做，如果他們包括沒有完全驗證的區塊，他們有可能會有大量的無主區塊）。 但他們這樣做了。 因此，分片B-F都得到了新的區塊，包括A100。 但A100的整個區塊沒有得到驗證，所以沒有礦工製作A101，因爲他們不能。 網絡的其他部分並不關心，我們得到了B105到F105的全部數據。 在這一點上，他們不能到106的高度，因爲A100太老了，沒有A101他們就不能再製造任何區塊。

    因此，B-F上的任何採礦都停止了。 他們沒有有用的工作可以做。 礦工們不能從A100上製造A101，因爲它是無效的。 所以礦工們製造了一個新的有效的A100。 然而，B-F 100-106都包括壞的A100。 礦工們不想讓自己的區塊成爲孤兒，所以他們拖着腳步試圖製造任何新的B-F區塊，直到A到了A105，如果不在其他分片上製造更多的區塊就無法繼續。 因此，他們最終開始製造新的B100-F100，重填所有這些區塊，網絡繼續運行。

    這很糟糕，但網絡將重新組織並繼續前進。 希望礦工們不會愚蠢到把他們自己沒有驗證過的區塊包括進來，但即使他們這樣做，也會有結果的。

  • 重組一個區塊

    基於PoW的加密貨幣的一個擔憂是所謂的51%攻擊問題。 這個問題簡單來說就是，一個控制了一半以上挖礦權的實體可以隨意改寫區塊鏈的內容。 那麼有了分片系統，重寫一個分片就會容易得多嗎？ 想象一下，有10個難度大致相同的PoW的分片。 一個只有5%散列能力的攻擊者可以重寫一個分片，因爲只有大約10%的網絡PoW在任何特定的分片上，對嗎？ 在Snowblossom Braid的情況下則不然。 如果攻擊者在一個分片上重新創建一些區塊，礦工會忽略它，因爲預先存在的區塊已經被編入其他分片。 他們會通過不把自己的區塊變成孤兒來跟隨某個區塊的重新分叉來賺取更多的錢，即使這個重新分叉看起來是被攻擊的區塊目前最好的。

    而且，由於礦工通過在他們的區塊中包括其他區塊來賺取更多的錢，這些區塊幾乎總是緊密地交織在一起。

信任/確認 #

在傳統的加密貨幣中，對交易的信心是基於確認的，即一個交易有多少個區塊深。

這個概念仍然是一樣的，但措辭是：已經開採了多少個區塊，必須丟棄才能刪除一個交易。

例如，假設一個交易被包含在一個分片區塊中，然後該區塊被包含在另外兩個分片中。 所有這三個區塊都必須成爲孤兒，該交易纔不會發生。 因此，儘管該交易在自己的區塊中只有一個確認，但從整體上看，它可以被視爲3個確認。 然而，在傳統的加密貨幣中，3次確認意味着在總網絡哈希率下的三個區塊。 而三個分片只是這三個分片的哈希率。

也許確認將成爲一種浮動。 因此，當一半的分片包括你交易的區塊時，你有0.5個確認。 當所有的分片都有，而且其中一些分片上有兩個區塊，那麼就有1.2個確認。

深度阻隔證明 #

假設有一些節點A是分片S的完全驗證者，意味着它已經攝取了

並檢查了所有區塊。

假設有一些節點B不是分片S的完全驗證者，它只是在尋找

在和存儲頭文件。

假設B接受分片S上的塊N是有效的，由於網絡共識。

A可以做一個證明，證明塊N+1對B有效。

這可以通過A提供區塊N+1來實現。 此外，A將提供

足夠多的UTXO內部節點，以證明該區塊所花費的所有交易輸出

是在塊N UTXO哈希中。 A還將提供其他內部節點來證明

塊N+1中的UTXO的變化，突變爲塊N+1中的UTXO散列。

這將是UTXO樹的一個重要部分，但不是幾乎所有的。

B，使用這個數據來驗證區塊，然後可以丟棄而不是存儲驗證的數據。

數據。

這將是一些緊張的代碼，但它是非常可行的。

生態系統 #

我猜想，大多數想要有競爭力的礦池會在所有分片上運行驗證節點。 這樣一來，如果有意義的話，他們可以在任何區塊上挖礦。 此外，他們還可以在所有分片上驗證區塊，以便能夠將最有效的其他區塊納入他們開採的區塊中，從而獲得最多的區塊獎勵。

沒有那麼多硬件的礦工可以與受信任的同行合作進行區塊驗證或使用第三方驗證服務。

我也可以看到第三方服務存在的地址查詢，因爲錢包軟件不一定知道哪些分片可能包含其地址的輸出。

舞蹈 #

當我爲這個辮子編程時，遇到了許多形成辮子的問題。 由於重複的區塊，一些分片跟隨一條鏈子，而另一些則跟隨其他鏈子，它最終處於難以取得進展的狀態，鏈子停滯不前。 應該指出的是，進展總是可能的，即使它必須是一些塊的孤兒，但這並不意味着找到前進的道路是容易的。

總之，在比我更聰明的人解決這個問題之前，舞蹈是一種旁敲側擊的方式。

舞蹈不會*被編碼在驗證規則中，一個節點可以在不破壞協議的情況下建立不遵循舞蹈的區塊，他們只是在其他節點堅持遵循舞蹈創建區塊的情況下有可能成爲孤兒。 這樣一來，如果有些人想出了更好的方法，就不會破壞改善網絡的工作。

總之，隨着舞蹈的進行，目前繼承utxos的分片0的分片應是協調者。

當製作新區塊時，協調者分片可以包括來自其他分片的任何區塊，這些區塊遵循舞蹈（和所有其他網絡規則）。

非協調人只能包括來自的區塊。

● 協調者分片

● 已經被協調者分片包括的其他區塊

這樣一來，代碼就簡單多了。 與其在金集上打轉，並試圖找到難以解決的問題的解決方案，協調者只是。

● 尋找從現有包含的區塊中延伸出來的區塊，只要它們跟隨舞蹈幷包含它們。

對於非協調人區塊，他們簡單。

● 包括最新的已知協調者分片區塊和協調者區塊所包括的任何區塊。

其弊端如下：假設有四個分片。{3,4,5,6}. 3號分片將是協調人分片。 假設第6區正在爲第5區輸出一些UTXO。 爲了使這些UTXO能夠被花費。

● 第6區必須開採一個區塊

● 第3區必須開採一個區塊，幷包括新的第6區塊。

● Shard 5必須開採包括新的Shard 3區塊和新的Shard 6區塊的區塊。

在沒有舞蹈的情況下，只有分片6和5需要開採一個區塊。 有了舞蹈，就必須有這三個，按這個順序。 這增加了轉移UTXO的時間，但這似乎是一個合理的妥協。

UTXO的改進 #

UTXO在地址,txid,out_idx上有索引。 #

在Snowblossom中，UTXO的索引是由收件人地址，然後是交易ID，最後是交易中的輸出索引。 這使得UTXO trie可以用來爲輕型客戶快速生成UTXO證明。服務器可以將證明任何給定地址的UTXO的完整性或缺乏性所需的trie節點一起發送。 爲了使其發揮作用，需要有一種統一的方式來表達地址，並且能夠爲任何交易的輸入或輸出獲得準確的地址。 這是AddressSpec模型的一個優勢，相對於比特幣OP-code方法，它可以用不同的方式表達地址。

區塊頭中的UTXO根哈希值 #

由於UTXO根哈希值是區塊鏈中的一個關鍵組成部分，將其納入區塊頭是有意義的。 這樣一來，輕型客戶端UTXO證明可以直接鏈接到區塊頭。

UTXO存儲在散列的三角形中 #

在區塊鏈中存儲UTXO根哈希值的一個困難是你需要一個絕對一致的方式來表達和存儲它。 正常的方式是使用 trie，一種具有特定規則的樹狀結構，這樣，同一組數據將始終具有相同的樹狀結構。 這樣一來，樹可以被散列，並在所有節點上產生一個單一的散列。 然而，在一個可以有重新排序的區塊鏈中，這可能是一個數據庫的挑戰。 傳統上，要進行重組，你需要回滾已刪除的區塊，然後應用新的區塊。 然而，如果你還沒有驗證新的區塊UTXO根哈希，你不想做這種數據庫的改變。 你還不能確定新區塊是否有效。 因此，我發明了一種新的數據結構，Hashed Trie。 在這個結構中，Trie中的每個節點都被存儲在一個底層的鍵值存儲中，節點（和所有子節點）的哈希值是鍵值。 使用這種方法，每個UTXO根被存儲和保留，數據庫事實上可以同時跟蹤多個區塊鏈。 另外，如果客戶願意，可以查詢之前任何區塊的UTXO。

  • 散列三部曲

    我認爲這很新穎，但如果我錯了，請讓我知道。

    實施–哈希三聯體源測試 雪花三聯體測試

    • 定義

      哈希Trie是一個結構，它是一個Trie，每個節點都有一個基於其內容的哈希值。在我的實現中，有一個哈希值到節點的底層映射。Map<Hash,Node>。樹的狀態被保存爲一個哈希值，它簡單地指向該狀態的根節點。每個節點的子節點是通過它們的哈希值來引用的。任何節點都不會被覆蓋（除了可能被重寫成完全相同的數據），如果它被改變，哈希值也會改變，並被保存在新的哈希值下。這使得它成爲一個空間效率高的寫時複製（CoW）結構。

      每個操作都被賦予根哈希值作爲一個參數。任何修改操作都會爲新樹返回一個新的根哈希值。

      根哈希值代表樹的內容。由於樹的結構有固定的規則，相同的鍵和值總是會產生相同的根哈希值。

    • 優勢

      ● 節省空間。儘管我們最終存儲了同一棵樹的許多變化，但我們只重複了不同的節點。

      ● 只要你有以前的根哈希值，以前版本的樹是可讀的。

      ● 任何突變都可以從以前的任何根節點進行。不需要回退任何變化，只需使用以前的根哈希值。

      ● 寫入時不需要鎖定。讀取和寫入可以同時發生。

    • 劣勢

      ● 任何寫入都會涉及到重寫從根節點到葉節點的所有節點，需要進行log(n)操作。可以通過分批更新來幫助。

      ● 讀取涉及讀取路徑上的所有節點，需要進行log(n)操作（很可能通過緩存得到很大幫助）。

      ● 由於每次突變都涉及到提取舊的根哈希值並返回新的根哈希值，如果在樹中有兩個你想要的寫法，你需要分批或按順序進行。

      ● 所有以前的節點總是被保留。不存在修剪問題。

    • 爲什麼它對區塊鏈來說是可怕的

      ● 根哈希值可以在共識中共享，以確保節點在樹上有相同的數據。例如，在Snowblossom中，UXTO的根哈希值來自UTXO的哈希三角形。

      ● 然後，共享的根哈希和中間節點可以用來向輕型客戶或只有頭的節點證明樹中任何數據的存在和完備性。

      ● 由於結構有固定的規則，證明也可以證明數據不在那裏。例如：通過顯示數據所在的父節點，如果它存在的話。

      ● 如果有一個重組，或潛在的重組，新的根哈希值可以根據以前的塊的根哈希值來更新。不需要回退變化或選擇一個鏈，只需將所有合理的區塊應用於哈希值的三角。使用任何最終獲勝的東西。例如，讓我們說三角形是存儲已確認的交易，截至最近的區塊。假設我們在10000區塊上。假設有一個重組，所以一個新的區塊9997進來了。我們只需從9996區塊中提取根哈希值，並從那裏進行變異，就可以爲其建立交易三角。然後，新的分叉鏈可以獨立於現有的分叉鏈被導入。

      ● 如果我們保存了以前區塊的根哈希值，我們就可以在樹上查詢我們想要的任何以前區塊的狀態。這樣一來，一個正在對一堆東西進行長時間讀取的客戶可以挑選一個塊，並查詢與之相關的所有東西，即使新的塊正在進入。

      ● 因爲對於區塊鏈賬本來說，我們通常不想丟棄數據，所以沒有任何東西被修剪的事實是沒有問題的。

線路信息和網絡協議 #

所有的Snowblossom消息和點對點的網絡互動都是用protobuf定義的，並使用gRPC。 這使得系統的關鍵互動得到很好的定義和一致。

原版文件

點對點通信（和輕型客戶端連接）支持帶有實際證書的TLS。 這是通過客戶端知道服務器節點的密鑰ID來實現的，而不需要由證書頒發機構頒發的證書的麻煩。 p2p網絡流言將密鑰ID與節點流言數據一起發送。 硬編碼的種子節點有硬編碼的密鑰ID。 這使得不依賴任何證書機構的MITM攻擊成爲可能。

客戶端檢查服務器的證書，以確保它是由預期的簽署密鑰簽署的。

TLS來源

StoatPOW - 基於存儲的IO訪問PoW #

  • 概念

    這個工作證明的概念是，各種通用計算用例都喜歡快速訪問大型存儲。 例如：遊戲、數據庫、媒體編輯

    因此，在快速訪問大型存儲方面的任何進展都會相對較快地進入商品部件，從而被普遍使用併發揮作用。 因此，Snowblossom的工作證明是基於對大型存儲的快速訪問。

  • 雪場和難度

    雪場是大型的確定性數據文件。 最小的是1GB，目前的場是256GB。 字段大小隨着哈希率的上升而增加，哈希率每增加4倍，雪域大小就增加一倍。 一旦字段大小增加，它就不會減少。

    對於這些大文件，我們沒有讓每一個只驗證區塊的節點或客戶端都需要訪問它們。 所以字段的merkle根是硬編碼的。 作爲採礦過程的一部分，礦工包括他們從雪域中讀取的數據段的證明，證明這些數據段是正確的，在正確的位置，併產生正確的哈希值。

  • 斯諾菲爾德一代

    雪場的生成很複雜，因爲它們必須具有以下特性。

    ● 確定性的–任何人都應該能夠再生它們

    ● 不可並行–應該不可能按要求只建造雪場的一部分

    爲此，創建雪場的程序被稱爲snowfall。 它對文件進行了多次prng傳遞。 從本質上講，你可以把它看作是一個具有絕對巨大狀態空間的僞隨機數發生器。 這可以防止任何人有效地對生成狀態進行檢查。 我們希望避免這樣一種情況，即礦工可以按需生成雪場的一部分，而不需要從存儲中加載頁面。

多種簽名算法 #

所有的地址都是多符號的（在常見的簡單地址情況下是1的1）。 #

客戶端錢包格式超級安全 #

我總是懷疑那些我無法輕易檢查的二進制文件格式。 特別是對於像加密貨幣錢包這樣的關鍵事物。 幸運的是，由於加密貨幣錢包是一個小的數據集，所有的操作都可以被認爲是追加操作，我們可以做出一些不錯的決定，使其比傳統的 “wallet.dat “方法更安全。 對於一個單一的文件，我總是害怕一些事情，比如如果我用一個新的軟件版本打開錢包，我還能使用舊的軟件嗎？ 如果我不小心導致新的密鑰產生怎麼辦？ 那麼我需要更新我的備份。 如果我把錢包裝在兩臺不同的電腦上，如何合併它們？這有可能嗎？ Snowblossom的方法解決了這一切。

在Snowblossom CLI客戶端以及IceLeaf GUI客戶端，錢包數據被保存在一個目錄中，而不是一個單一的文件。 每次寫入都是以隨機生成的文件名寫成一個新的文件。 在錢包加載時，所有的文件在內存中被讀取和合並，然後寫入一個新的合併文件，只有在新文件被寫入和刷新後，源文件才被刪除。

保存文件本身是protobuf WalletDatabase的實例。 這使得字段可以在功能需要時被添加。 有一個版本字段，如果它高於源代碼WALLET_DB_VERSION，那麼當數據庫文件被合併時，原始文件不會被刪除。 假設可能有新的字段，當前的源代碼不知道如何正確合併。 所以在新舊軟件版本混合的情況下，有可能出現數據庫文件堆積的情況，但一切都應該正常。

在Snowblossom CLI中，有一個導出爲json的操作。 它並不漂亮，但它可以讓用戶檢查正在發生的事情。

鑑於上述合併和文件命名行爲，錢包的使用選擇是廣泛的。

效果很好的東西。

● 通過NFS或共享文件系統在計算機之間進行實時同步，或僅僅在一臺計算機上運行多個客戶端

● 最終像Dropbox或unison之類的東西進行同步

● 合併錢包，只需將文件複製到一個目錄即可

● 混合新老雪花客戶

通常特徵 #

● 塊狀時間 10分鐘的平均數

● Child-pays-for-parent (CPFP)

● 交易的不可更改性

● 雙重消費保護

● 有彈性的點對點網絡

● 分散的設計

● 隨着時間的推移，半截式的獎勵

● 先看先加