TREE:金色觀察 | Utreexo進展_REEX

Utreexo進展

概要

本文會介紹Utreexo的優點，以及這些優點的實現程度，闡述最新Utreexo應用中取得的重大進展，但是要讓這項科技大眾化，還需要一個漫長的過程。

2020年7月最新的演示發布會中，我們指出，未來Utreexo項目能夠將Utreexo累加器應用到btcd，btcd是Go語言的BTC實現。我很高興，因為該實現已經能夠用于另一個演示版本。這個版本中可以演示一種稱為“致密狀態節點”的新修剪型節點模式。

2020年4月發表了一篇“ELI5:Utreexo——一個擴容解決方案”的文章，這篇文章介紹了以下幾個致密狀態節點的優勢：

1.?新的全節點模式只會占用幾千字節，能夠讓hdd節點像ssd節點一樣快速同步。

2.?能夠實現初始區塊并行下載。

3.?由于目前使用的是谷歌的數據庫，通過致密狀態節點，共識能夠獨立于數據庫實現，加強BTC安全性。

4.?Utreexo的應用不會導致BTC分叉。

就目前的發展狀況而言，第3和第4點現已實現，第1點只有部分實現了，因為非Utreexo數據的存在，節點大小還是不能縮小到千字節，第2點還在努力實現。

第3點為何重要？

幾年來，在提高BTC安全性方面，重點之一是消除它的任何外部依賴性。外部依賴性指的是依靠那些BTC開發者沒有編寫的代碼，而這些又是BTC軟件運行必要的代碼。對于任何高度依賴安全的項目，都要盡量避免依賴外部代碼，因為它們可能會產生漏洞。為了把這種風險降到最低，依賴的外部代碼都要經過審查，然后保留審查后的代碼副本。然而，這種并不是完美的方法，代碼如果由BTC開發者直接編寫、測試和審查會更好。出于這個原因，BTC開發人員已經從中刪除了各種產生外部依賴的代碼，例如OpenSSH代碼。

金色晚報?|?9月7日晚間重要動態一覽:12:00-21:00關鍵詞：北京金融局、SushiSwap、Filecoin測試網、FTX創始人

1. 北京金融局局長：第三批監管沙盒項目將進一步擴大試點范圍。

2. FTX創始人SBF：Sushi是否在Serum上創建副本取決于Sushi社區。

3. Filecoin測試網當前總質押量約為366.95萬枚FIL。

4. 報告：巨鯨在ETH價格暴跌前拋售超100萬枚代幣。

5. 銀保監工作論文：監管機構應密切跟蹤區塊鏈、分布式賬戶等對銀行的影響。

6. OKEx CEO：Jumpstart即將支持“挖礦上幣”。

7. Filecoin太空競賽第三周將進行進一步壓力測試。[2020/9/7]

目前，依賴最大的外部代碼是存儲未花費輸出集合和區塊索引的數據庫。現在BTC使用谷歌的“LevelDB”數據庫。LevelDB必須要沒有代碼漏洞，這對于BTC的安全性至關重要。LevelDB中如果存在漏洞，可能會導致雙花或導致意外分叉。事實上，BTC在LevelDB之前使用的是BerkeleyDB，2013年，BerkeleyDB在比特幣核心節點中的應用出現漏洞，導致舊錢包節點在讀取區塊225430時失敗，導致意外分叉。

上文提到的UTXO是BTC的一套支付系統。UTXO集合對于維護BTC的安全非常重要，因為這直接組成BTC共識，移除LevelDB將極大地提高其抵御風險的能力。

第3點的實現

之所以需要一個數據庫，是因為UTXO集合包含超過6000萬個UTXO，這些UTXO都要記錄，并且能夠快速訪問，因為訪問速度過慢會降低區塊初始下載速度。快速訪問大量細分數據通常會使用數據庫。

金色熱搜榜：TRX居于榜首:根據金色財經排行榜數據顯示，過去24小時內，TRX搜索量高居榜首。具體前五名單如下：TRX、BCD、HC、ELF、ZEC。[2020/7/27]

然而，有了Utreexo致密狀態節點，根本不需要數據庫。相反，我們需要讓UTXO的發送者提供UTXO數據和Utreexo累加器，證明UTXO存在。這樣在Utreexo致密狀態節點實現中，UTXO集合無需保留。這允許從BTC共識的另一個關鍵部分中刪除LevelDB。

針對主鏈擴容，以下是現有區塊驗證方式與Utreexo致密狀態節點區塊驗證的對比：

這里唯一的區別是后者的區塊驗證沒有訪問數據庫。相反，它使用Utreexo來驗證區塊。

代碼變化非常小，因為大多數區塊驗證函數都保持不變。檢查累加器證明后，經過驗證的UTXO數據(驗證塊所需的)會轉換成為“UtxoViewpoint”，也就是現有的UTXO集合緩存結構，這相當于比特幣核心節點的CCoinsView，然后UTXO數據會傳遞給現有的區塊驗證函數。

第4點的重要性

在像BTC這樣的去中心化系統中，加入新功能需要分叉，而分叉會帶來很大風險。BTC硬分叉在很大程度上不可能實現，因為不值得為了一個功能而進行硬分叉。軟分叉也很難實現，因為需要大量社區支持。

另一方面，在無需分叉的條件下，如果可以直接添加一個新功能，那么這個功能的部署就會簡單得多。例如，BIP-152壓縮區塊繼電器得到了廣泛采用，無需分叉。對于BIP-152，節點可以選擇是否加入，因為該提議沒有強制性，沒有選擇加入的節點不用做出任何改變。

金色財經挖礦數據播報 | BSV今日全網算力上漲7.39%:金色財經報道，據蜘蛛礦池數據顯示：

BTC全網算力110.141EH/s，挖礦難度15.78T，目前區塊高度635226，理論收益0.00000840/T/天。

ETH全網算力180.677TH/s，挖礦難度2285.05T，目前區塊高度10286724，理論收益0.00867582/100MH/天。

BSV全網算力1.890EH/s，挖礦難度0.29T，目前區塊高度639847，理論收益0.00047608/T/天。

BCH全網算力2.827EH/s，挖礦難度0.39T，目前區塊高度640073，理論收益0.00031839/T/天。[2020/6/18]

第4點的實現

這是最容易實現的一點，因為TadgeDryja第一次寫Utreexo論文時，它就解決了。我們通過使用稱為“橋接節點”的過渡節點，避免軟分叉，這種節點能夠連接新的Utreexo節點和當前的BTC節點。

當非utreexo節點連接到橋接節點時，橋接節點的功能與當前的BTC全節點相同。然而，一個Utreexo節點連接到橋接節點后，它將提供正常區塊的Utreexo證明，同樣也會將該證明提供給一個非Utreexo節點。

那篇4月發表的文章提到，會對Utreexo二進制文件進行硬編碼，而且只能連接到我們運行的橋接節點，避免干擾BTC測試網。

第1點的重要性

要運行一個完整節點，上文提到的UTXO集合是必要條件。然而，越來越多節點采用這種集合后，再加上BTC的單位能夠越分越細，UTXO集合將會變大。目前，UTXO集合大小約是4GB，但對于價格低廉設備，這個大小可能會繼續增加，超過這些設備的處理能力。BTC如果能夠得到廣泛使用，降低UTXO集合的大小非常重要。

金色晨訊 | 4月10日隔夜重要動態一覽:21:00-7:00關鍵詞：國務院、發改委、富達、比特幣基金

1.中共中央、國務院：培育數字經濟新產業、新業態和新模式。

2.北京市發改委：要布局基于區塊鏈等的全媒體建設。

3.歐盟成員國財長就5900億美元的抗疫救助方案達成協議。

4.跨域審判輔助事務協作機制依據區塊鏈工作原理。

5.CME比特幣期貨4月合約收跌0.61%。

6.富達集團拓展加密交易產品。

7.標普500指數創1974年以來最大單周漲幅。

8.加拿大3iQ公司申請的比特幣基金已在多倫多證券交易所上市。

9.比特幣夜間窄幅震蕩，最低價為7232.06美元，最高價位7318.07美元。[2020/4/10]

在當前BTC節點中，一個區塊引用任何UTXO時，節點需要獲取該UTXO，要么通過硬盤，要么通過緩存。節點如果硬盤速度較慢，就會造成問題，這也是BTC目前的瓶頸之一。對于修剪型節點，這是一個更大的約束，因為當區塊經過修剪后，各個緩存的UTXO會寫入磁盤。BTC開發者PieterWuille也指出了這個問題，修剪型節點的同步速度比未修剪節點慢。

Utreexo致密狀態節點能夠提高同步速度，因為無需對UTXO集合進行磁盤讀取。這說明在任何存儲中，無論是基于NVMe協議的固態硬盤還是其他硬盤，Utreexo致密狀態節點都能發揮出同樣性能。

第1點的目前進展

全節點大小尚未縮小到只有幾千字節，因為區塊頭等元數據就占用了幾百兆字節。盡管chainstate占用空間小，如果要實現目標，其他數據的大小也不容忽視。在這次發布版本中，目標是縮小到幾百兆字節。

金色午報 | 1月10日午間重要動態一覽:7:00-12:00關鍵詞：央行數字貨幣、吳忌寒、以太坊開發者Virgil、DApp

1. 央行：基本完成法定數字貨幣頂層設計、標準制定、功能研發、聯調測試等工作。

2. 河北省政協常委：積極布局區塊鏈技術在實體產業中的扎根落地。

3. 學習時報：區塊鏈最重要的還是在運營。

4. 山東自貿試驗區濟南片區發出三千余張區塊鏈營業執照。

5. 甘肅區塊鏈信任基礎設施平臺啟動上線。

6. 吳忌寒卸任比特大陸全資子公司“創客云”監事一職。

7. 以太坊開發者Virgil Griffith已保釋出獄。

8. 總計不超過461個錢包持有ETH、LTC、ADA、Tether中的至少40％。

9. 以太坊、波場和EOS 2019年上線Dapp共占98%的交易總額。[2020/1/10]

下圖對比了Utreexo致密狀態節點與比特幣核心節點的chainstate。

如上圖所示，Utreexo致密狀態節點的chainstate大小僅為424字節，因此對于節點中的chainstate大小，出現了舍入錯誤。實際上，用于重新連接已知節點進行重啟的peers.json文件占用了205kb，其大小約是chainstate的483倍。

以下對比了修剪型比特幣核心節點和Utreexo致密狀態節點之間的性能差異，觀察基于NVMe協議的固態硬盤和其他硬盤的讀寫速度。

這項測試會指定節致密狀態節點連接到一個不同的本地Utreexo橋接節點，從基于NVMe協議的固態硬盤讀取數據，從而進行基準測試。假設比特幣核心節點中前1864000個區塊都經過了驗證，將同樣的設置應用到致密狀態節點中。測試網3達到1906000區塊高度后，完成測試。

本次測試使用了以下硬件：

CPU:：AMDRyzen3600

內存：三星32GBDDR42666MHz

作為本地服務節點的基于NVMe協議固態硬盤：2TBSandiskULTRA.2NVMe.2

作為測試節點的基于NVMe協議固態硬盤：1TBHPSSDEX950M.2

測試節點硬盤：WesternDigitalWD10EZEX-22BN5A01TB7200RPM

以下是發送到比特幣核心節點的標志：

-prune=550

-connect=127.0.0.1

-disablewallet

-blocksonly?

-testnet

對于比特幣核心節點，在基于NVMe協議的固態硬盤上運行需要784秒，而在其他硬盤上則需要1066秒。對于Utreexo致密狀態節點，在基于NVMe協議的固態硬盤上運行需要1,643秒，而在其他硬盤上需要1,700秒。

請注意，就當前Utreexo致密狀態節點的實現而言，仍然要進行許多性能優化。它目前速度比比特幣核心節點慢，因為我們分叉了一個比后者慢得多的btcd節點。我們后續會發布一個版本和一篇重點說明性能的文章。

為何第2點如此重要？

為了避免混淆，本文提到是指鏈級并行下載。這意味著單個節點將同時驗證多個區塊，比如100001到200000然后是200001到300000。第2點指的不是區塊層級的并行下載，在這種并行下載中，區塊的交易簽名接受并行驗證，這在btcd和比特幣核心節點中已經實現。

在計算機領域，并行化是指同時執行多個進程。這可以提高空閑硬件的使用率，例如CPU，如果硬件處于空閑狀態，性能可能會提高。近年來，由于物理限制，在提高時鐘頻率方面，CPU開發出現了困難。所以，人們更多地關注的是增加核心數量，而不是提高時鐘頻率。針對這種情況，軟件開發也做出了相應改變，越來越強調并行化，目的是充分利用更多CPU核心。

并行化區塊初始下載可以大幅減少同步全節點所需的時間，這樣個人用戶而言，運行一個全節點也更容易。更多的節點將使BTC網絡更能抵御攻擊。從這個角度來看，并行化也能夠增加BTC的安全性。

第2點的目前進展

任何區塊的驗證都需要前一個塊的UTXO集合。例如，如果我們正在驗證區塊501，我們需要區塊500的UTXO集合。然而，要獲得區塊500的UTXO集合，需要區塊499的UTXO集合。這會產生一個問題，那就是要追溯到BTC的硬編碼創世區塊，阻礙著鏈級并行化的實現。

有了Utreexo后，這個問題更加容易解決，因為UTXO集合只有幾百字節，而不是幾千字節。這讓我們可以將整個UTXO集合表示硬編碼到軟件中，作為并行驗證的起點。

請注意一點，有可能會出現惡意節點，發送偽造UTXO集合。然而，這并不會降低我們的安全要求，因為我們有多個CPU核心，能夠驗證從創世區塊開始一直到499區塊高度。在這之后，我們會從501個區塊繼續驗證，充分利用閑置CPU內核。完成前一步后，我們會檢查區塊，驗證區塊499和區塊500的UTXO集合是否匹配。因此，經過硬編碼的UTXO集合表示僅作為提示，以提升處理速度，實際上所有區塊都會經過驗證。

為了支持這種類型的鏈級并行化，代碼庫必須支持多個chainstate保持活躍狀態。對于擁有多個chainstate而言，主要困難在于必須記錄多個UTXO集合。UTXO集合需要一個數據庫，磁盤上也要有該集合的緩存，這樣讀取速度才能加快，在這種條件下，運行節點的硬件要求會變高。但是，Utreexo致密狀態節點即使沒有數據庫，也可以儲存UTXO集合，所以這不是問題。

擁有多個chainstate的目標正在實現。對于Utreexo致密狀態節點，工作量大大降低，因為不需要為每個chainstate建立數據庫，這樣就可以擁有多個chainstate。對于btcd節點，輸入Blockchain即可訪問CChainstate數據庫，

目前，我們仍在研究每個chainstate應該如何處理p2p網絡消息，嘗試不同的方法，例如使用兩個初始區塊下載管理器，或者記錄每個chainstate對區塊發出的請求，但實現這個目標的過程仍然很漫長。

本次發布版本的缺陷

當前版本不支持區塊鏈重組和內存池。因此，節點將以“blocksonly”模式運行，如果發生重組，節點會崩潰。Utreexo尚未能夠實現對這兩者的支持，所以這次發布的只是演示版本。BTC主網不會支持這個版本，它不應該用于實際交易中，因為它仍然是早期版本，也存在漏洞。

展望未來

第1點的目前進展中提到，我們會對Utreexo致密狀態節點進行更多性能優化。這包括加速開發Utreexo累加器和btcd組件。我們目前注意到許多問題，一旦修復這些問題，致密狀態節點的速度能夠得到提升，只是需要進行更多測試來實現。

去年就開始了對區塊鏈重組支持的測試，但出現了許多其他更緊迫的問題，暫停了該測試，在不久的將來，重組會得到實現。雖然還沒有開始內存池支持的測試，但是我們已經計劃了一段時間。我非常期待在今年實現支持內存池。

目前Utreexo累加器需要Go語言來編寫。將累加器代碼移植到Rust和c是一項持久工作。我們不確定要花多長時間，不過現在已經打造了代碼基礎，需要各方通力合作。Utreexo的發展仍然任重而道遠。

本文內容來自于BitMEX

Tags：BTCTREEEXOREEXbtc短線交易騙局treelionPlant ExodusREEX價格

比特幣