BTC:金色觀察 | 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代碼。

金色晨訊 | 10月29日隔夜重要動態一覽:21:00-7:00關鍵詞：柬埔寨、加拿大央行、MakerDAO

1.柬埔寨國家銀行正式推出基于DLT技術的支付系統。

2.加拿大央行行長：目前還不需要數字貨幣。

3.CME比特幣期貨10月合約收跌3.7%。

4.美股大跌 區塊鏈概念股普遍收跌。

5.MakerDAO就利用閃電貸操縱治理投票發出警告。

6.廣州反詐高能預警：小心以“比特幣”等為名的虛擬貨幣騙局。

7.tZERO將與TyntonCapital共同發行3億美元的代幣化基金。

8.比特幣夜間反彈上漲，日內最低報13011.27美元，最高報13279.38美元。[2020/10/29]

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

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

第3點的實現

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

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

金色熱搜榜：EKT居于榜首:根據金色財經排行榜數據顯示，過去24小時內，EKT搜索量高居榜首。具體前五名單如下：EKT、BHD、LBA、PAI、ONT。[2020/7/12]

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

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

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

第4點的重要性

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

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

第4點的實現

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

金色財經挖礦收益播報丨今日BTC全網算力下降4.23%:金色財經報道，據OKEx礦池數據顯示，今日BTC全網算力約114.52EH/s，全網難度約16.10T，BTC當前塊高630296。

今日全網算力出現了比較明顯的降幅，降幅達到4.23%。由于目前主流的BTC瀏覽器通常以爆塊數據（出塊數和出塊時間）預估全網算力，因此實際全網實時在線的算力可能會小于預測數據。當前BTC收益：0.00000781BTC/T/天。預測下次難度16.67T（+3.52%），距離調整還剩還有4天。[2020/5/14]

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

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

第1點的重要性

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

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

金色財經現場報道 富礦海外交易所CEO吳波：區塊鏈產業的發展要以合規作為基礎:金色財經現場報道，在世界區塊鏈大會·三點鐘峰會中，富礦海外交易所CEO吳波進行現場演講。區塊鏈是互聯網的價值鏈，區塊鏈本質上分為技術層、社群層等。為了社群更好的運轉，我們需要有經濟模型，一個成功的區塊鏈應用，是離不開更好的設計的，在這些成功的應用中，區塊鏈就完全是分布式的狀態，在區塊鏈整個的生態體系中，中心化的交易所扮演重要的角色。未來，交易所將向著分布式的方向發展，區塊鏈產業的發展要以合規作為基礎的。[2018/4/25]

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

第1點的目前進展

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

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

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

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

金色財經獨家消息：央行內部人士，不鼓勵電力部門為礦場供電:針對1月3日市場傳言央行召開閉門會議，要求限期關停比特幣礦場的傳聞，金色財經獨家獲悉，央行召開的閉門會議，并非要求比特幣礦場全部關停，而是對一些存在用電情況不規范的礦場進行整頓，同時，央行內部人士表態，不鼓勵電力部門為礦場供電。一位四川的比特幣礦場主也透露，目前地方正在進行摸排，要求進行工商登記，同時規范用電行為。[2018/1/3]

這項測試會指定節致密狀態節點連接到一個不同的本地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：BTCTREEREEXEXObtcc幣最新價格TREEB價格REEX價格nexo幣最新行情

NEAR