IRC meeting summary for 2018-05-03
概覽
本週會議討論的主題包括:專案成員希望審查者在下週重點關注的拉取請求、是否應將除錯記錄移到單獨的執行緒以便它不會減慢某些使用案例、是否要產生包含一些錯誤修復和標準交易政策變更的 0.16.1 小版本,以及如何允許平行處理從網路上其他對等點接收的訊息。
高優先級審查
背景: 每次會議,Bitcoin Core 開發者都會討論哪些拉取請求(PR)是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關;其他則是阻礙後續工作的 PR,或需要大量維護(重新基底)才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的目前高優先級 PR 列表。
討論(記錄): 會議期間討論的具體 PR 包括:
-
BIP 158:輕量客戶端的緊湊區塊過濾器(#12254),由 Jim Posen 提名加入列表。此 PR 允許 Bitcoin Core 為區塊中包含的一些資訊產生緊湊索引。然後可以與輕量客戶端共享這些索引,以允許它們確定區塊是否包含與客戶端錢包相關的資訊,此時客戶端可以請求下載整個區塊(可能來自不同的對等點)。
-
[wallet]
loadwalletRPC - 在執行時載入錢包(#10740),由 John Newbery 提名加入列表。這是一組 PR 之一,如果被接受,將允許 Bitcoin Core 在 Bitcoin Core 0.15.0 中新增的多錢包模式的背景下,在執行時建立、載入和卸載錢包。 -
UI:支援動態載入的錢包(#13097),由 Joao Barbosa 提名加入列表。建立在前面提到的 PR #10740 之上,這在 Bitcoin Core 圖形使用者介面(GUI)中為動態載入錢包提供支援。
本次會議再次至少第四週提到了一些 GitHub 頁面無法載入(「獨角獸」)的問題。
刪除 0.8、0.9 和 0.10 git 分支
背景: Bitcoin Core 的新開發通常在 Git 儲存庫的 master 分支上進行。要建立穩定版本,主分支會被 git 分叉到一個穩定分支,分支名稱為預期發行版本的名稱,例如對於版本 0.8,分支是 0.8。該分支上的程式碼會被測試、成熟和發布——並且小版本發行版本(例如 0.8.1)的後續錯誤修復也會在該分支上進行。
討論(記錄): Marco Falke 在會議前不久提出了這個主題,並介紹說:「這些分支上最後標記的版本已經終止生命週期超過一年了。標籤可以保留以用於歸檔原因,但不再需要分支。參見 https://bitcoincore.org/en/lifecycle/#schedule。」
所有在會議上對此事發表評論的人都表示同意。Luke Dashjr 建議,如果每個分支上的最終提交沒有附加到發行標籤(表示確切哪些程式碼用於特定發行版本),則應新增標籤以確保需要該特定程式碼的任何人仍然可以獲得它。其他會議參與者表示同意。
結論: 會議結束後不久,這些分支被刪除。
將記錄移到單獨的執行緒
背景: 預設情況下,Bitcoin Core 會將有關其正在執行的操作的某些資訊寫入記錄檔,以防出現問題並且使用者需要找出觸發問題的原因。目前,記錄是作為程式執行中的順序步驟完成的,因此記錄之後的下一步不會執行,直到記錄完成,這被描述為記錄步驟「阻塞」後續步驟。執行緒是一種讓程式告訴作業系統可以平行執行多個步驟的方法,這可以允許程式中的下一步在記錄完成之前開始(描述為「非阻塞」)。
討論(記錄): James O’Beirne 建議並介紹了這個主題,說:「我認為將記錄移到單獨的執行緒可能是值得的。」他參考了兩個最近與記錄相關的 PR,#13099 和 #12970。
Matt Corallo 對這個想法非常熱情,說「ACKACKACKACKACKACKACKACKACKACK」並指出「對於礦工來說,這是一個令人驚訝的高延遲創造者,至少對於那些使用旋轉磁碟支援或雲端託管機器的人來說。」他還連結到了他的專案 Bitcoin FIBRE(不用於共識執行的 Bitcoin Core 軟體分支)的一個提交,該提交為記錄實作了基本執行緒。
其他幾位開發者支援這個想法,討論集中在實作行為的最佳方式,特別是如何確保如果確實出現問題,盡可能多的資訊仍然寫入記錄檔。
一些參與者還討論了如果將記錄移到單獨的執行緒,Bitcoin Core 會快多少。一般意見似乎是它可以在一些時間關鍵的應用程式中提供幫助,例如礦工宣布新發現的區塊,並且在使用者啟用選用的詳細記錄進行除錯時也會有所幫助。後者是開發者經常做的事情,也被 Bitcoin Core 測試套件的部分自動使用。但是,對於其他使用案例,預計不會提供顯著的改進。
結論: James O’Beirne 透過說「除非有人有任何異議,否則我將在不久的將來開始進行執行緒從環形緩衝區消費的實作」來結束討論。
0.16.1
背景: Bitcoin Core 最新的主要版本 0.16.0 版本是在大約兩個月前發布的。通常在發布後,會修復影響該版本的錯誤,並且某些新功能被認為足夠重要以向後移植到該版本,從而產生新的小版本。
討論(記錄): Matt Corallo 提出了這個主題並介紹說:「對於那些沒有注意的人,[Jesse Cohen] 在 #13092 中發現了區塊處理中一些特別新穎的競態條件。因為它們是執行緒問題,它們幾乎肯定不會影響除 submitblock 使用者(即礦工)以外的任何人,並且只會在罕見的競態[情況?]下,但是,我認為鑑於這一點以及我們擁有的其他各種修復,可能值得向後移植。」
引用的問題 #13092 是 Suhas Daftuar 對 Cohen 在 PR #13023 中編寫的整合測試發現的問題的分析。在最壞的情況下,礦工可能認為他們使用 submitblock RPC 向網路發送了新發現的區塊,卻發現 Bitcoin Core 由於競態條件而默默忽略了該區塊,這是程式以與程式設計師預期不同的順序執行步驟的情況。Cohen 的測試發現了這個問題,因為它們在很短的時間內建立了幾個測試區塊(沒有工作量證明)。主網路上的區塊之間幾乎總是有更大的間隔,因此希望到目前為止沒有礦工受到此錯誤的影響。
儘管有 PR 來修復該問題,但 Daftuar 認為需要額外的討論以「確定正確的修復方法」。Cohen 建議 #12988 是「類似類型的錯誤」,也可能應該在小版本中修復。
Corallo 還建議 0.16.1 應包括 Johnson Lau 的 PR #11423,使 CodeSeparator 操作碼在傳統(非 segwit)輸入的花費中成為非標準的。非標準意味著節點不會接受具有這些輸入的交易進入記憶池;如果它們出現在區塊中,它們仍然會接受它們。這應該消除對稱為 FindAndDelete() 的函式的使用,該函式有問題的歷史(參見 1、2)。Segwit 的實作不需要 FindAndDelete,但仍然提供 CodeSeparator 操作碼,NBitcoin 開發者 Nicholas Dorier 一直在使用它作為 Tumblebit 實作的一部分——因此尚未正式提議在 segwit 花費中使 CodeSeparator 成為非標準的。
關於 Lau 的 PR 是否已準備好合併,有一些討論。Corallo 相信 Lau「想要向 [Lau 的 PR] 新增一個更多的政策規則。」Corallo 說他會就此聯繫 Lau。
結論: 所有參與者似乎都贊成組合 0.16.1 版本以修復競態條件並包含額外的標準性規則。在會議期間和之後,討論的各種 PR 被新增到專案的 0.16.1 里程碑中。
非同步呼叫 ProcessNewBlock
背景: Bitcoin Core 目前在單一執行緒中處理它從點對點網路上的對等點接收的訊息。如果可以重寫為使用多執行緒,它可以平行處理一些訊息,這可以提供效能改進。但是,由於它經常從多個對等點接收相同的基本訊息,因此這提出了如何避免重複工作的挑戰。
討論(記錄): Matt Corallo 提出了這個主題並介紹說:「PR #12934 [肯定]還沒有準備好審查,但我們應該討論一下跨對等點的並發性會是什麼樣子。有兩種主要方法,但兩者最終都需要對其大部分工作進行類似的重構。過去我曾研究過平行執行 ProcessMessages();在[先前連結的 PR 中,Jesse Cohen] 將[交易和區塊]的驗證處理移到佇列中,並在單獨的執行緒中執行。在這兩種情況下,我們最終都會建立邏輯來『暫停』處理對等點,直到它剛剛產生的任何訊息都被處理完畢。」
Gregory Maxwell 和 Corallo 簡短討論了系統的哪些部分會發現並發性特別有益。對於 Maxwell 來說,是初始區塊下載(IBD),其中新區塊的下載被延遲「當同時連線多個區塊時(由於 IBD 中的無序獲取)」。對於 Corallo 來說,是在使用 CompactBlocks(BIP152)接收新區塊期間連線期間轉發 gettxn(獲取交易)請求,「對於區塊轉發延遲[改進]來說,剩下的一個大便宜勝利。」
Corallo 接著指出,並發性將允許在具有多個 CPU 核心的系統上同時將來自多個對等點的新接收資料反序列化為可用的資料結構,Maxwell 同意這可能是一個不錯的收穫。他們還同意,過去一年對程式碼所做的許多改進使得實作這種類型的變更變得更簡單和更容易。
結論: Cohen 寫道:「酷——所以,如果沒有強烈的反對或對該方法的擔憂,我將繼續這樣做,並在它更準備好審查時回來。」
幽默時刻
<wumpus> #10740 given me an unicorn though
<jonasschnelli> has also a unicorn, reload solved
<wumpus> yes
<LukeJr> unicorns probably have a high street value
<jnewbery> not any more. The market's been flooded
<LukeJr> shows what I know of unicorn markets
<wumpus> LukeJr: yes, I"m trying to farm them and sell them,
but I have more now than atoms in the knows universe
so you could say the supply is more than the demand...參與者
| IRC 暱稱 | 姓名/化名 |
|---|---|
| BlueMatt | Matt Corallo |
| wumpus | Wladimir van der Laan |
| gmaxwell | Gregory Maxwell |
| LukeJr | Luke Dashjr |
| skeees | Jesse Cohen |
| jamesob | James O’Beirne |
| jnewbery | John Newbery |
| sipa | Pieter Wuille |
| cfields | Cory Fields |
| MarcoFalke | Marco Falke |
| jonasschnelli | Jonas Schnelli |
| sdaftuar | Suhas Daftuar |
| jimpo | Jim Posen |
| promag | Joao Barbosa |
| jtimon | Jorge Timón |
| achow101 | Andrew Chow |
| jcorgan | Johnathan Corgan |
| kanzure | Bryan Bishop |
免責聲明
本摘要是在沒有討論參與者任何輸入的情況下編譯的,因此任何錯誤都是摘要作者的責任,而不是討論參與者的責任。特別是,從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段,以及背景敘述和說明,都是由本摘要的作者新增的,可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義,請聯繫我們,我們將更正錯誤。
