4月30日，Block.One 釋出預覽版本 EOSIO V1.8.0-rc1，在此版本中，引入了共識協議的升級，需要出塊節點共同協作，以成功部署升級。目的是增強所有基於 EOSIO 的區塊鏈網路的安全性和可用性。此版本為候選版本，供社羣反饋，在未來幾周內，經過審查測試之後，會正式釋出穩定版。
未來在正式釋出之後，如何對 EOSIO 節點升級，是需要 BP跟專案方注意的事情。因此， BlockOne 釋出了一份升級指南，供社羣參考。在中文社羣還沒有見到此份文件的中文版，因此，分享給大家。
BlockOne 給出的升級指南，見：
https://github.com/EOSIO/eos/issues/7237
編譯: 荊凱|EOS42
期待你能為 EOS42 投票，支援我們持續為 EOS 的未來進行探索，我們賬號是: eos42freedom。
共識協議升級指南
這一指南的目的，在於幫助節點人員知悉在對 EOSIO 網路進行成功的共識升級時所需要採取的相應步驟(即所謂“硬分叉升級”)，目的在於儘量減少對使用者的影響。
對網路進行測試
務必先在測試網路上進行部署與驗證，才可以在正式網路上部署共識升級。支援初始協議升級的nodeos版本將首先作為候選版本釋出， 版本號為: v1.8.0-rc2。現有的 EOSIO 測試網路可以使用這個版本的 nodeos 來執行和測試升級過程。
對升級的測試過程，有助於幫助出塊節點瞭解在各自的 EOSIO 區塊鏈網路實踐與執行首個共識協議升級時所需要的步驟，以便能夠共同協作以成功啟用首個共識協議升級功能(簡稱協議特性)。在啟用時若有節點未升級至最新版本會無法被相容。該過程還會幫助出塊節點知悉將 nodeos 從 v1.7.x 或更早的版本升級至 v1.8.x版本時的要求，幫助他們設定恰當的截止日期，以便告知社羣首個共識協議特性啟用的時間。
在測試網路上對升級過程進行測試，還能夠幫助區塊瀏覽器和其他的dApp測試在啟用了協議特性之後的新規則下，其應用程式的變化與表現。部分協議特性對區塊和交易資料的結構做了若干小的調整（例如 PREACTIVATE_FEATURE 和 NO_DUPLICATE_DEFERRED_ID 特性），因此需要對原先依賴於舊的資料結構的程式進行強制遷移。RESTRICT_ACTION_TO_SELF 這一協議特性對自 v1.5.1 版本開始存在的授權繞行的方式(authorization bypass) 進行了限定，有可能使得繼續依賴於授權繞行功能(authorization bypass) 的智慧合約無法執行。
EOSIO 網路的升級過程(也適用於測試網路)
因為這些步驟需要從創世塊開始重播(replay)，所以在釋出了支援初始一致協議升級的適當版本的nodeos之後(供測試網路使用的v1.8.0-rc2，對所有其他網路而言，是穩定版的 v1.8.0)，所有節點操作者都應該儘快執行以下步驟。這些步驟應在額外的節點伺服器上執行，這些節點可以承受長時間離線（they can afford to be taken offline for an extended period of time）:
1. 確保其現有的節點執行著更新至最新的穩定版本的 nodeos (1.7.x)。然後，關閉 nodeos.
2. 做好備份後，刪除 data 資料夾中的 blocks/reversible 資料夾、state-history 資料夾，以及 state 資料夾。
3. 將 nodeos 的舊版本替換為新版本。
4. 啟動新的 1.8.x 版本的 nodeos, 將其從創世檔案開始進行完全的重播(replay), 與網路同步。節點應接收區塊，LIB 應當提前。執行著 v1.8.x 與 v1.7.x 的節點在啟用首個協議升級特徵之前可以在相同網路中同時存在。
（附上操作步驟的英文，供核對）
1. Ensure that their existing node is running the most recent stable release (1.7.x) of nodeos and then shut down nodeos.
2. Make a backup and delete the blocks/reversible directory, state-history directory, and state directory within the data directory.
3. Replace their old version of nodeos with the new release.
4. Start the new 1.8.x release of nodeos and let it complete replay from genesis and catch up with syncing with the network. The node should receive blocks and LIB should advance. Nodes running v1.8.x and v1.7.x will continue to coexist in the same network prior to the activation of the first protocol upgrade feature.
nodeos 自v1.7.x 升級至 v1.8.x 版本時，需要從創世檔案開始對區塊鏈重播。之後，v1.8.x 的節點可以如之前一樣快速的啟動和停止而無需重放區塊。v1.7.x 版本的節點程式所生成的狀態資料夾(state) 無法與 v1.8.x相容。由 V1.7.x生成的行動式快照(行動式快照版本1)無法相容 v1.8.x的程式版本,後者需要的
快照為版本2的快照。
由於從創世重放區塊耗時甚久(如果執行用於追蹤歷史的外掛，則時間更長)，建議出塊節點預留給社羣足夠的時間用於在第一個協議升級特徵啟用之前對節點程式升級。
如果節點希望進行升級但並不想追蹤自創世塊以來的區塊鏈歷史，可以使用版本二的便攜快照加快速度，該快照可以透過同步 v1.8.x 節點而生成。由於行動式快照所生成的方式具備確定性和可移動性，使用者可以對比從任意來源所所下載的快照檔案的hash值與若干可信任來源所釋出的hash值，不過前提是他們是對同一區塊id所進行的快照。
連結：https://zhuanlan.zhihu.com/p/67620357
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。
針對出塊節點的特別說明
毫無疑問，出塊節點應當在單獨的一臺非出塊伺服器上進行 nodeos 的重播(replay)過程。該伺服器應當做好出塊準備，可以在重放和同步工作完成之後，切換至該伺服器進行出塊。或者，可以在重播（replay）的伺服器上做快照，然後傳輸至另外一臺做好出塊準備的機器上，之後再在該伺服器上從當前的出塊 BP 節點程式 v1.7.x 切換至 v.1.8.x 版本的節點程式。
v1.8 中引入的幾乎所有協議升級特性首先都需要啟用一個特殊的協議特性(程式碼名PREACTIVATE_FEATURE)，並使用該特性引入的功能來部署系統合約的更新版本。出塊節點應當知曉，一旦BPs啟用了 PREACTIVATE_FEATURE 協議特性，所有仍然使用 v1.7.x 版本的節點將無法繼續正常同步，最後一個不可逆塊(LIB)將停止前進。因此，重要的是就啟用發生的時間進行協調，並宣佈預期的啟用日期，提供足夠的時間給社羣，以便及時升級節點。
啟用 PREACTIVATE_FEATURE 並部署更新後的系統合約之後，出塊節點能夠更容易地對進一步的協議特性的啟用進行協調。對於v1.8.x 中的其他協議特性, 可以在任何時候啟用，而不需要給社羣任何準備時間，因為此時，與區塊鏈同步所使用的 nodeos 程式必須至少已經升級至 v1.8.x 版本，因而會支援所有的初始協議特性集。此外，由於 PREACTIVATE_FEATURE協議特性的存在，節點可以透過多籤的方式發起提案，使用新系統合約中的 activate（啟用）指令對其餘的協議特性進行啟用，不需要再對區塊鏈進行重放。
然而，首個協議特性(即PREACTIVATE_FEATURE）的啟用，不能改透過 eosio.msig 多籤提案的方式進行。需要出塊節點更多的協調和人工操作。首先，出塊節點應當就啟用首個協議特徵的最早時間達成一致意見。
之後，出塊節點應當在 JSON 配置檔案中設定好該時間，用於其 v1.8.x 節點程式的 PREACTIVATE_FEATURE 協議升級。具體來說，他們應當對配置資料夾中的 protocol_features/BUILTIN-PREACTIVATE_FEATURE.json 這一檔案中的 earliest_allowed_activation_time 欄位進行修改。
重要的是，應當先對節點程式的配置做好修改之後，才能夠允許該節點在網路上出塊。只要超過2/3的活躍出塊節點(即排名前21的節點)在其BP節點的配置檔案中就 PREACTIVATE_FEATURE 特徵設定好了相同的未來啟用時間，網路就可以保持安全，不會受到其他出塊節點過早啟用的影響。
在所商定的時間點之後，前21名出塊節點中任意一位都可以透過向其 BP 節點的 producer_api_plugin 發起請求的方式啟用 PREACTIVATE_FEATURE 這一協議特性。
為了確定請求命令的特定格式，首先需要確定 PREACTIVATE_FEATURE 合約特性的digest（摘要)資訊。可以透過檢視nodeos啟動log，或者更好的方式是在啟用 producer_api_plugin 後本地執行如下的命令列：
curl -X POST http://127.0.0.1:8888/v1/producer/get_supported_protocol_features -d '{}' | jq
返回陣列中，找到指向PREACTIVATE_FEATURE程式碼名的物件, 例如:
{
"feature_digest": "0ec7e080177b2c02b278d5088611686b49d739925a92d9bfcacd7fc6b74053bd",
"subjective_restrictions": {
"enabled": true,
"preactivation_required": false,
"earliest_allowed_activation_time": "1970-01-01T00:00:00.000"
},
"description_digest": "64fe7df32e9b86be2b296b3f81dfd527f84e82b98e363bc97e40bc7a83733310",
"dependencies": [],
"protocol_feature_type": "builtin",
"specification": [
{
"name": "builtin_feature_codename",
"value": "PREACTIVATE_FEATURE"
}
]
},
連結：https://zhuanlan.zhihu.com/p/67620357
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。
上面例子中，PREACTIVATE_FEATURE 協議特性的digest數值為: 0ec7e080177b2c02b278d5088611686b49d739925a92d9bfcacd7fc6b74053bd. 請注意，由於對特定區塊鏈網路的協議特性配置所做的本地更改的原因，該數值可能會有所變化。
獲取了該數值之後，可以用如下的命令傳送至本地出塊的 nodeos 程式實體，在下一次該節點出塊時啟用 PREACTIVATE_FEATURE 協議:
>
curl -X POST http://127.0.0.1:8888/v1/producer/schedule_protocol_feature_activations -d ‘{“protocol_features_to_activate”: [“0ec7e080177b2c02b278d5088611686b49d739925a92d9bfcacd7fc6b74053bd”]}’ | jq
只能夠在設定的啟用時間之後，才使用上述命令。 PREACTIVATE_FEATURE 協議特徵的啟用時間，是經過 BP 一致同意後，在配置檔案中對earliest_allowed_activation_time這一欄位進行的設定。
Any synced v1.8.x nodes can be used to check which protocol features have been activated using the following command:
任何 v1.8.x 的同步節點可用以下命令檢查已啟用了哪些協議特徵:
curl -X POST http://127.0.0.1:8888/v1/chain/get_activated_protocol_features -d ‘{}’ | jq
例如，若 PREACTIVATE_FEATURE 協議特徵已啟用，可能會得到如下的返回陣列(注意，某些數值，特別是 activation_block_num 該欄位，可能會有所變化):
{
"activated_protocol_features": [
{
"feature_digest": "0ec7e080177b2c02b278d5088611686b49d739925a92d9bfcacd7fc6b74053bd",
"activation_ordinal": 0,
"activation_block_num": 348,
"description_digest": "64fe7df32e9b86be2b296b3f81dfd527f84e82b98e363bc97e40bc7a83733310",
"dependencies": [],
"protocol_feature_type": "builtin",
"specification": [
{
"name": "builtin_feature_codename",
"value": "PREACTIVATE_FEATURE"
}
]
}
]
}
PREACTIVATE_FEATURE 協議特徵啟用之後，可以部署新增了 activate 啟用指令的新的系統合約了。
（注：在新的系統合約中，新增了一項操作：activate, 可用於啟用後續的協議特徵。）
針對區塊瀏覽器、交易所及 dApp 團隊的說明
構建在 EOSIO 區塊鏈上的區塊瀏覽器、交易所和應用程式都可以遵循上面描述的四個步驟，及時對node程式升級，以確保在第一個協議升級啟用時服務能夠正常執行。不過，也請知悉，某些協議特性會改變區塊鏈上現有的操作行為，在某些情況下，還會對區塊和事務的結構進行輕微變動。
首先，v1.8.x 版本在任何協議特徵啟用之前就更改了事務追蹤(transaction traces)的結構。透過歷史外掛、mongo_db_plugin 外掛或者狀態歷史外掛來使用事務和指令追蹤的客戶端程式，需要瞭解這些對追蹤結構的變更(細節參見 #7044 及 #7108)。客戶端程式如果使用來自區塊鏈 API 的 push_transaction RPC 的追蹤輸出，不需要做任何改動，因為該 RPC 的輸出應當會向後相容。但是，我們更建議使用新的 send_transaction RPC 替換 push_transaction，它使用新的扁平式結構來儲存指令跟蹤(action traces)。
在 v1.8.x 中，狀態歷史外掛也更改了 API 及儲存在硬碟上的檔案結構，支援向後相容。這些更改反映了事務跟蹤結構更改和鏈狀態資料庫中為支援新協議特性而進行的資料結構更改。狀態歷史外掛的使用者需要進行更新，以適應 v1.8.x 中的新更改。
其次，所有的協議特徵都是透過在一個塊傳送256位的摘要資訊來啟用的。出塊節點可以將協議特徵的摘要資訊放在區塊頭的一個特殊位置中(稱為區塊頭擴充套件（block head extensions）), 在原先 v1.7.x 的規則下，該部分資料為空。
區塊瀏覽器團隊應該特別注意這一變更，需要確保不會因為在區塊頭資訊中加入這一額外的資料而造成區塊瀏覽器工具出現問題，理想的做法是對區塊瀏覽器升級以反映新的資訊。在啟用 PREACTIVATE_FEATURE 協議特徵期間，區塊瀏覽器或區塊鏈資料的其他使用者會第一次遇到區塊頭擴充套件非空的情形。
第三，啟用 NO_DUPLICATE_DEFERRED_ID 後，合約所生成的延遲事務會包含非空的交易擴充套件欄位。雖然區塊瀏覽器可能有興趣用對使用者友好的方式展示該欄位內容，不過使用者可以忽略這一資訊。不過，對於直接處理這些事務的二進位制序列化形式的程式碼而言，必須能夠成功的將具有擴充套件資料的事務反序列化。注意，這也適用於智慧合約程式碼，合約程式碼可能會讀取使其執行的延時事務，不論是因為在延時交易內執行操作，還是執行因合約傳送了失敗的延遲事務而執行 eosio::onerror 通知處理程式。
第四，RESTRICT_ACTION_TO_SELF 協議特徵啟用後，原本在合約向自身發起內聯操作時可以使用的繞過授權(authorization bypass)的方式會被移除(在 EOSIO的 v1.5.1 版本中繞過授權的方式被設定為不推薦/棄用的操作)。在 BP 啟用 RESTRICT_ACTION_TO_SELF 協議特徵之前，智慧合約開發者應當確保其合約不依賴於這一繞過授權的做法，以保證其應用程式可以正常執行。
EOSIO 版本更新
EOSIO 程式碼庫中，將 eosio 和合約庫分為了不同的repo，所以，通常所說的 eosio 版本，是指的 EOS 該程式碼庫的版本號。最新的穩定版本是v1.7.3。
地址為: https://github.com/EOSIO/eos
4月30日釋出候選版本: V1.8.0-rc1
BlockOne 現在採取了備選版本的釋出方式，提前將一些版本釋出給社羣供反饋，這類釋出版本末尾用rc來表示。
4月30日，Block.One 釋出預覽版本 EOSIO V1.8.0-rc1，在此版本中，引入了共識協議的升級，需要出塊節點共同協作，以成功部署升級。
目的是增強所有基於 EOSIO 的區塊鏈網路的安全性和可用性。
該版本為候選版本，供社羣反饋，在未來幾周內，經過審查測試之後，會正式釋出穩定版。
在 V1.8.0-rc1 版本中，得到關注最大的是提供了功能“僅向事務的首個授權者對 CPU 和網路頻寬計費”。
根據 BlockOne撰文介紹，該功能可以讓企業應用的開發者建立起其他的計費模式，比如，可以對合約進行設定，由 dApp 方為使用其應用的使用者支付 CPU 和 NET 費用。
在 EOSIO v1.8.0-rc1候選版本中的協議升級功能：
- （＃6431）啟用協議功能預啟用
- (＃6333）禁止連結到不存在的許可權
- （＃6672）修復eosio::linkauth的過多限制
- （＃6458）不允許提出空節點排程
- （＃6705）向自己傳送指令時限制授權檢查
- （＃6103）修復與更換延遲交易相關的問題
- （＃6115）避免延遲交易的事務ID衝突
- （＃6105）修改RAM計費限制
- （＃6332）僅向事務的首個授權者收取CPU和網路頻寬費用
- （＃6988）將setcode操作轉發到eosio帳戶上部署的WebAssembly程式碼
- （＃7028）允許智慧合約判定內聯操作的發起者賬號
