【比特币】BIP-0009 軟叉标準bip-0009

switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {

“`

實作應該注意的是，狀态是沿着塊鍊分支來維護的，但是當重組發生時可能需要重新計算。

鑒于特定塊/部署組合的狀态在目前重定目标周期之前完全由其祖先确定（即，直到并包括其高度為block.height - 1 - （block.height％2016）的祖先），這是可能的 通過緩存由父節點索引的每個2016年的每個塊的結果狀态，來有效和安全地實作上述機制。

為了支援更新警告，使用“隐式位”mask =（block.nVersion＆〜expectedVersion）！= 0來跟蹤額外的“未知更新”。隻要在nVersion中設定了一個意外的位，掩碼将不為零。 當檢測到未知更新的LOCKED_IN時，軟體應該大聲警告即将到來的軟叉。 在下一個重新定位期間（當未知更新處于ACTIVE狀态）時，應該更加警惕。

模闆請求對象擴充為包含一個新項目：

| Key | 必須 | 類型 | 描述 |

| ——– | —–: | :—-: | :—-: |

| rules | No | Array of Strings | 按名稱列出受支援的軟體配置 |

模闆對象也被擴充：

| rules | Yes | Array of Strings | 按名稱列出受支援的軟體配置 |

| vbavailable | Yes | Object |一組待處理，支援的軟體部署; 每個使用軟匙名稱作為關鍵字，軟匙位作為其值|

| vbrequired | No | Number | 軟體包部署版本位的位掩碼伺服器需要在送出中啟用 |

模闆的“版本”鍵被保留，用于訓示伺服器對部署的偏好。 如果使用版本比特，“version”必須在[0x20000000 … 0x3FFFFFFF]的版本範圍内。 礦工可以清除或設定塊版本中的位，不帶任何特殊的“可變”鍵，隻要它們列在模闆的“vbavailable”中，并且（當需要清除時）不包括在“vbrequired”中。

“規則”中列出的軟鍵盤部署名稱或“vbavailable”中的鍵可能會以“！”為字首 字元。 沒有這個字首，GBT用戶端可以假定規則不會影響模闆的使用; 典型的例子是先前有效的交易将不再有效，例如BIP 16,65,66,68,112和113.如果用戶端不了解沒有字首的規則，則它可以未修改地用于挖掘。 另一方面，當使用該字首時，它表示對塊結構或生成事務的更微妙的改變; 這樣做的例子是BIP 34（因為它修改了硬币基礎結構）和141（因為它修改了txid哈希，并增加了對代的交易的承諾）。 不明白以’！’為字首的規則的用戶端 不得嘗試處理模闆，也不得嘗試将其用于未修改的挖掘。

上述機制是非常通用的，并且對于未來的軟叉可以進行變化。 以下是可以考慮的一些想法。

修改的門檻 1916年的門檻（基于BIP 34的95％）不需要維護永久，但更改應該對警告系統有影響。 特别地，具有與用于警告系統的鎖定門檻值不相容的鎖定門檻值可能具有長期影響，因為警告系統不再依賴于永久可檢測的狀态。

沖擊軟叉 在某些時候，可以提出兩個互相排斥的軟叉。 處理這種情況的天真的方法是永遠不會建立實作兩者的軟體，但這是打賭，至少有一方保證失去。 更好的是編碼“軟叉X不能被鎖定”作為沖突的軟叉的一緻規則 - 允許支援兩者但不能觸發沖突變化的軟體。

多級軟叉 現在的軟叉通常被視為布爾：它們從一個非活動狀态到一個活動狀态。 也許在某些時候，需要一個具有更多階段的變化，附加的驗證規則逐個啟用。 上述機制可以通過将位的組合解釋為整數而不是隔離位來适應這一點。 警告系統與此相容，因為（nVersion＆〜nExpectedVersion）将始終為非零以增加整數。

故障逾時允許最終重用位，即使軟叉從未被激活，是以很明顯，該位的新用法指的是新的BIP。 考慮到合理的開發和部署延遲，故意非常細分。 不太可能有足夠的失敗的建議造成短缺。

在軟叉嘗試結束時的休閑時間允許檢測到錯誤的用戶端，并允許為成功的軟叉提供警告和軟體更新的時間。

這裡可以找到有關部署建議的生活清單。

本文檔位于公共領域。