修訂

修訂系統提供了一種去中心化的XRP賬本網路引入新功能而不會導致中斷的方法。修訂體系通過利用網路的核心共識流程，通過在變更生效之前顯示持續的支援來批准任何變更。修正案通常需要兩週內獲得80％的支援才能生效。

修訂版啟用後，它將永久應用於所有賬本版本之後的賬本版本。除非您引入新的修正案，否則您不能禁用修正案。

有關已知修訂的完整列表，其狀態和ID，請參閱：已知修訂。

背景

對交易處理的任何更改都可能導致伺服器使用同一組交易構建不同的賬本。如果某些驗證節點（參與共識的rippled伺服器）已升級到新版本的軟體，而其他驗證節點使用舊版本，則這可能會導致任何問題，從小的不便到完全中斷。在較小的情況下，少數伺服器花費更多時間和頻寬獲取實際的共識賬本，因為他們無法使用他們已知的交易處理規則來構建它。在最糟糕的情況下，

修正解決了這個問題，因此只有足夠的驗證節點支援這些功能時才能啟用新功能。

依賴XRP賬本的使用者和企業也可以使用修訂提前通知交易處理中可能影響其業務的變更。但是，不影響交易處理或共識流程的 API更改不需要修訂。

關於修正案

修正是一個全功能的功能或變化，等待對等網路啟用，作為共識流程的一部分。一個rippled想要使用的修正伺服器有兩種模式程式碼：不支援該修正案（舊的行為），支援修正（新的行為）。

每項修訂都有一個唯一的標識十六進位制值和一個簡稱。簡稱目的是使人看起來容易辨認，並未在修改過程中使用。兩臺伺服器可以支援相同的修訂

按照慣例，Ripple的開發人員使用修訂名稱的SHA-512Half雜湊作為修訂ID。

修改過程

每個第256個賬本都稱為“標誌”賬本。審批修正案的過程始於標誌賬本之前的賬本版本。當rippled驗證節點伺服器傳送該賬本的驗證訊息時，這些伺服器也會提交投票以支援特定的修改。如果驗證節點不贊成修正案，這與對修正案投反對票相同。（費用投票也發生在標誌賬本的附近。）

標誌賬本本身沒有特殊的內容。但是，在那段時間內，伺服器會檢視他們信任的驗證節點的投票，並決定是否將交易插入到以下賬本中。EnableAmendment偽交易的標誌顯示伺服器認為發生了什麼：

• 該tfGotMajority標誌意味著對修改的支援已經增加到至少80％的可信驗證節點。
• 該tfLostMajority標誌意味著對修正案的支援減少到不到80％的可信驗證者。
• 沒有標誌的EnableAmendment偽交易意味著已經啟用對修改的支援。（交易處理的變化適用於此後的所有分類帳。）

如果滿足以下所有條件，則伺服器僅插入偽交易以啟用修改：

• 該修正案尚未啟用。
• 以前的賬本包含tfGotMajority啟用標誌的此修訂的EnableAmendment偽交易。
• 有問題的上一個賬本是當前賬本的祖先。
• 有關問題的前一個賬本有一個關閉時間，至少在最近的標誌賬本的結束時間的兩週前。
• 對於此修正案，沒有EnableAmendment偽交易，且tfLostMajority在tfGotMajority偽交易和當前賬本之間的共識賬本中啟用了標誌。

理論上，tfLostMajorityEnableAmendment偽交易可以與偽交易包含在同一賬本中，以啟用修改。在這種情況下，使用偽交易的tfLostMajority偽交易不起作用。

修改投票

每個版本rippled都包含已知修訂列表和實施這些修訂的程式碼。預設情況下，rippled支援已知修正並反對未知修正。rippled驗證節點員的操作員可以以明確支援或反對某些修改，即使這些修改未知其rippled版本。

要啟用，修訂必須持續兩週至少80％的受信任驗證節點支援。如果對修正案的支援低於可信驗證節點的80％，修正案將被暫時拒絕。如果修訂重新獲得至少80％的可信驗證者的支援，那麼兩週時間將重新開始。（如果驗證者投票的方式不同，或者驗證者信任度發生變化，則會發生這種情況。）修改可以在永久啟用之前獲得並失去大多數次數。修正案不能被永久拒絕，但如果新版本rippled在其已知的修改列表中沒有修改，修改就不太可能啟用。

與協商一致過程的所有方面一樣，只有服從信任驗證者傳送投票的伺服器才會考慮修正投票。目前，Ripple（該公司）建議僅信任Ripple執行的預設驗證節點。就目前而言，僅僅信任這些驗證節點就足以與Ripple協調發布新功能。

配置修改投票

您可以使用功能方法臨時配置修訂。要持久更改伺服器對修正的支援，請更改伺服器的rippled.cfg檔案。

使用該[veto_amendments]節列出您不希望伺服器投票支援的修改。每行應包含一個修訂的唯一ID，可選的是修改的簡稱。例如：

[veto_amendments]

C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490Tickets

DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13SusPay

使用該[amendments]節列出要投票的修改。（即使你沒有在這裡列出它們，預設情況下伺服器會投票支援它知道如何應用的所有修改。）每行應包含一個修訂的唯一ID，後面可以選擇修改的簡稱。例如：

[amendments]

4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373MultiSign

42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EEFeeEscalation

修正案被封鎖

如果在投票過程之後為網路啟用了修訂，則執行早期版本的伺服器rippled不知道修改的伺服器會因為不再瞭解網路規則而被“修改阻止”。被阻止的伺服器：

• 無法確定賬本的有效性
• 無法提交或處理交易
• 無法參與共識流程
• 無法對將來的修改進行投票

成為修正被阻止的是一項安全功能，用於保護依賴於XRP賬本資料的應用程式。在應用新規則後，與其猜測並可能誤解賬本rippled，並不報告賬本的狀態，因為它不知道修訂是如何工作的。

一個修正案rippled伺服器配置為投票贊成或反對對伺服器是否變為修正案阻止沒有影響。一個rippled伺服器儘可能始終遵循由網路其餘部分啟用的一套修訂。如果已啟用的修訂未包含在編譯為伺服器原始碼的修訂定義中，換句話說，如果修訂比伺服器更新，則伺服器僅被修改為阻止。

如果您的伺服器遭到修改阻止，您必須才能與網路同步。

如何判斷您的rippled伺服器是否被修改被阻止

返回rippled的amendmentBlocked錯誤是您的伺服器被修改阻止的第一個跡象之一。這是一個示例錯誤：amendmentBlocked

{

"result":{

"error":"amendmentBlocked",

"error_code":14,

"error_message":"Amendment blocked,need upgrade.",

"request":{

"command":"submit",

"tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"

},

"status":"error"

}

}

以下rippled日誌訊息還表示您的伺服器已被修改阻止：

2018-Feb-1219:38:30 賬本Master:ERR One or moreunsupported amendments activated: server blocked.

如果您使用的是rippled版本0.80.0以上版本，則可以rippled使用該命令驗證您的伺服器是否已被修正。在迴應中，尋找result.info.amendment_blocked。如果amendment_blocked設定為true，則表示您的伺服器已被修正。

示例JSON-RPC響應：

{

"result": {

"info": {

"amendment_blocked": true,

"build_version": "0.80.1",

"complete_賬本s": "6658438-6658596",

        "hostid": "ip-10-30-96-212.us-west-2.compute.internal",

"io_latency_ms": 1,

"last_close": {

"converge_time_s": 2,

"proposers": 10

},

...

},

"status": "success"

}

}

如果您的伺服器未被修改阻止，則該amendment_blocked欄位不會在響應中返回。

警告：即使您的伺服器被修改阻止，rippled0.80.0之前的版本也不包含該amendment_blocked欄位。

如何取消阻止修改被阻止的rippled伺服器

升級到rippled支援導致您的伺服器被修改阻止的修改的版本。Ripple建議您升級到最新rippled版本，以解除對伺服器的阻止並使其再次與網路同步。

根據情況，您可以通過升級到rippled比最新版本舊的版本來（並且想要）解鎖伺服器。如果舊版本支援阻止您的rippled伺服器的修改，則可以這樣做。

警告：如果最新rippled版本提供安全性或其他緊急修復，應儘快升級到最新版本。

要確定您是否可以rippled通過升級到比最新版本更舊的版本來解鎖伺服器，請查明哪些功能會阻止您的伺服器，然後查詢rippled支援阻止功能的版本。

要找出哪些功能阻止了您的rippled伺服器，請使用命令。尋找具有"enabled": true和的功能"supported" : false。這些功能的值意味著修訂目前在最新的分類帳中啟用（必需），但您的伺服器不知道如何支援或應用修訂。

示例JSON-RPC響應：

{

"result": {

"features": {

"07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104": {

"enabled": true,

"name": "Escrow",

"supported": true,

"vetoed": false

},

"08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647": {

             "enabled": true,

"name": "PayChan",

"supported": true,

"vetoed": false

},

"1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146": {

"enabled": false,

"name": "CryptoConditions",

"supported": true,

"vetoed": false

},

"157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1": {

"enabled": true,

        "supported": false,

"vetoed": false

},

...

"67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172": {

"enabled": true,

"supported": false,

"vetoed": false

},

...

"F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064": {

"enabled": true,

"supported": false,

"vetoed": false

}

},

"status": "success"

}

}

在這個例子中，與以下功能的衝突導致您的rippled伺服器被修改阻止：

• 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1
• 67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172
• F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064

要查詢哪個rippled版本支援這些功能，請參閱已知修訂。

測試修正案

如果要檢視rippled啟用修訂後的行為，在生產網路上啟用修訂之前，可以執行使用者rippled的配置檔案強制啟用某個功能。這僅用於開發目的。

由於共識網路的其他成員可能沒有啟用該功能，因此在連線到生產網路時不應使用此功能。在強制啟用功能的情況下進行測試時，應該rippled以獨立模式執行。

要強制啟用某個功能，[features]請在rippled.cfg檔案中新增一節。在本節中，新增要啟用的功能的簡稱，每行一個。例如：

[features]

MultiSign

TrustSetAuth

共識原則和規則

XRP賬本是一種通用的支付系統，使使用者能夠像傳送電子郵件一樣無縫地跨境轉移資金（包括法定貨幣，數字貨幣和其他形式的價值）。像其他數字貨幣（如比特幣）一樣，XRP賬本可以通過去中心化的計算機網路實現點對點交易結算。與其他數字貨幣協議不同，XRP賬本還允許使用者以賬本本幣XRP以外的貨幣進行交易。此外，該技術能夠近乎實時地結算（三至六秒），並且可以將每筆國際交易轉換為網路中可用的最便宜的外匯買賣價差。

背景

機械學

核心內容是，XRP賬本是一個共享資料庫，用於記錄賬戶，餘額和交易資產報價等資訊。被稱為“交易”的簽名指令會導致更改，如建立帳戶，進行付款和交易資產。

作為一個加密系統，XRP賬本的所有者由加密身份標識。交易由與這些身份匹配的加密簽名進行授權。每個伺服器根據相同的確定性已知規則處理每個交易。最終目標是網路中的每臺伺服器都擁有完全相同的賬本狀態副本，而無需單箇中央機構仲裁交易。

雙重支出問題

“雙重支出”問題是操作任何支付系統的根本挑戰。問題來自要求，當錢花在一個地方，它不能在另一個地方度過。更一般地說，當你有任何兩個交易時，問題就會發生，即任何一個交易都是有效的，但不是兩個交易。

假設Alice，Bob和Charlie正在使用支付系統，Alice的餘額為10美元。為了使支付系統有用，愛麗絲必須能夠將她的10美元送給鮑勃或查理。但是，如果Alice試圖向Bob傳送10美元並且同時向Charlie傳送10美元，那麼這就是雙重花費問題的來源。

如果Alice可以向Charlie和Bob傳送“相同”10美元，則支付系統不再有用。支付系統需要一種方式來選擇哪個交易應該成功，哪個交易應該失敗，以便所有參與者就發生哪些交易達成一致。這兩項交易中的任何一項都有自己的同等效力。但是，支付系統中的不同參與者可能會對先前交易有不同的看法。

傳統上，支付系統通過讓中央機構跟蹤和批准交易來解決雙重支出問題。例如，銀行決定根據發行人的可用餘額清算支票，其中銀行是唯一的託管人。在這樣一個體系中，所有參與者都遵循中央當局的決定。

分散式賬本技術，如XRP賬簿，沒有中央管理機構。他們必須以其他方式解決雙重花費問題。

如何達成共識

簡化問題

許多雙重花費問題可以通過眾所周知的規則來解決，例如禁止賬戶花費它沒有的資金。事實上，雙重支出問題可以減少到有序交易。

考慮Alice試圖向Bob和Charlie傳送相同的10美元的例子。如果向Bob支付款項是第一次，那麼每個人都可以同意她有資金支付Bob。如果支付給查理的費用是第二，那麼每個人都可以同意，她不能將這些資金髮送給查理，因為這筆錢已經發給了鮑勃。

我們也可以通過決定性規則來排序交易。由於交易是數字資訊的集合，因此計算機對它們排序是瑣碎的。

這足以在沒有中央機構的情況下解決雙重支出問題，但是，在我們確定任何交易結果之前，我們必須先做好每一筆交易（以便我們可以對其進行分類）。顯然，這是不切實際的。

如果我們可以將交易收集到小組並就這些小組達成一致，那麼我們可以對該小組內的交易進行排序。只要每個參與者同意將哪些交易作為一個整體來處理，他們就可以使用確定性規則來解決雙重支出問題，而無需中央當局。參與者根據已知規則對交易進行排序並以確定性方式應用它們。XRP賬本正是以這種方式解決了雙重支出問題。

XRP賬本允許多個相沖突的交易在協議組中。這組交易按照確定性規則執行，因此根據排序規則成功的交易先到達第一個衝突交易第二個失敗。

共識規則

達成共識的主要角色是讓參與者在流程中就哪些交易作為一個整體進行處理以解決雙重支出問題達成一致。這個協議比預期的要容易實現有四個原因：

1. 如果沒有理由交易不應該包含在這樣一組交易中，所有誠實的參與者都同意將其包括在內。如果所有參與者都已經達成一致，那麼共識就沒有工作要做
2. 如果有任何理由，交易不應該包含在這樣一組交易中，所有誠實的參與者都願意排除它。如果交易仍然有效，那麼沒有理由不將其包含在下一輪中，並且他們都應該同意將其包含在內。
3. 參與者特別關心交易如何分組是非常罕見的。當每個人的優先重點都達成一致時，協議是最容易的，只有在存在分歧的利益時才會遇到挑戰。
4. 甚至可以使用確定性規則來形成分組，導致僅在邊緣情況下不一致。例如，如果一輪中存在兩個衝突交易，則可以使用確定性規則來確定下一輪中包含哪些交易。

每位參與者的首要任務是正確。他們必須首先執行規則，以確保沒有任何違反共享賬本的完整性。例如，一個沒有正確簽名的交易決不能被處理（即使其他參與者想要被處理）。然而，每位誠實參與者的第二優先事項是協議。可能的雙重花費網路根本沒有用處。每個誠實的參與者都認為它高於一切而非正確，這一事實促進了協議的實現。

重複共識

協商一致意見是試圖就一組交易達成一致意見，以便對其進行處理。每一位希望這樣做的參與者都會採取初步立場。這是他們看到的一組有效交易。

參與者然後“雪崩”達成共識：如果某項交易沒有多數支援，參與者同意推遲交易。如果特定交易確實擁有多數支援，參與者同意包含交易。因此，輕微的多數迅速獲得全力支援，輕微的少數群體迅速成為本輪的普遍拒絕。

為了防止拖延達到50％的共識，並減少可靠收斂所需的重疊，包含交易所需的閾值隨著時間的推移而增加。最初，如果50％或更多的其他參與者同意，參與者仍然同意包括交易。如果參與者不同意，他們會增加這個門檻，首先增加到60％，然後再增加，直到所有有爭議的交易從當前集合中刪除。以這種方式移除的任何交易都推遲到下一個賬本版本。

當一個參與者看到一個同意這組交易的超級大多數人接下來將被處理時，它宣佈已達成共識。

共識可能失敗

開發一個永遠不能達成完美共識的共識演算法是不現實的。要理解為什麼，請考慮共識過程如何完成。在某些時候，每個參與者必須宣告已達成共識，並且已知某些交易是該過程的結果。作為共識流程的結果，此宣告將該參與者不可撤銷地委託給某些特定的一組交易。

一些參與者必須首先做到這一點，否則參與者永遠不會這樣做，他們永遠不會達成共識。現在，請考慮首先做到這一點的參與者。當這個參與者決定共識完成時，其他參與者還沒有做出這個決定。如果他們不能從他們的觀點來改變商定的集合，他們已經決定完成共識。所以他們必須仍然能夠改變他們同意的設定。

換句話說，為了達成一致的過程，一些參與者必須宣告，即使所有其他參與者在理論上仍然能夠改變商定的交易集合，已經就一系列交易達成了一致意見。

想象一下，一個房間裡的一群人試圖認同他們應該用哪個門退出。無論參與者討論多少，在某個時刻，必須有人成為第一個走出門外的人，儘管這個人背後的人仍然可以改變主意並通過其他門離開。

這種失敗的可能性可能非常低，但不能降為零。工程上的權衡使得這個概率下降到千分之一以下使得共識明顯變慢，並且不能容忍網路和端點故障。

XRP賬簿如何處理共識失敗

在協商一致結束後，每個參與者都應用他們認為已經同意的一組交易。這導致構建他們認為賬本的下一個狀態應該是什麼。

也是驗證者的參與者然後釋出該下一個賬本的加密指紋。我們稱這個指紋為“驗證投票”。如果協商一致成功，絕大多數誠實的驗證者應該釋出相同的指紋。

參與者然後收集這些驗證票。從有效的投票中，他們可以確定先前的協商一致是否導致絕大多數參與者同意一組交易。

然後參與者按照概率順序發現自己處於三種情況之一：

1. 他們建立了同意的絕大多數賬簿。在這種情況下，他們可以認為該賬本已經完全驗證並依賴於其內容。
2. 他們建立了一個不同於大多數人認同的賬本。在這種情況下，他們必須建立並接受絕大多數的賬本。這通常表明他們早期宣佈達成共識，其後許多其他參與者也發生了變化。他們必須“跳躍”到超級大多數賬本才能恢復運作。
3. 收到的驗證中沒有絕對多數。在這種情況下，先前的共識回合被浪費了，並且在任何賬本可以被驗證之前必須發生新一輪。

當然，情況1是最常見的。案例2對網路沒有任何損害。一小部分參與者甚至可能會陷入每一輪的情況2，並且網路將毫無問題地工作。即使那些參與者也可以認識到他們並沒有像超級多數人那樣建立同樣的賬本，所以他們知道不要把他們的結果報告為最終結果，直到他們與超級多數人達成一致為止。

案例3導致網路在幾秒鐘內失去了它可能取得進展的情況，但是非常罕見。在這種情況下，下一輪達成一致意見的可能性大大降低，因為意見分歧在協商一致的過程中得到解決，只有餘下的分歧才能導致失敗。

在極少數情況下，整個網路幾秒鐘內未能取得進展。作為交換，平均交易確認時間很少。

哲學

可靠性的一種形式是即使在一些元件失敗，一些參與者是惡意的情況下系統也能夠提供結果的能力等等。雖然這很重要，但在加密支付系統中還有另一種形式的可靠性 - 系統產生可靠結果的能力。也就是說，當系統向我們報告結果可靠時，我們應該能夠依靠這一結果。

然而，真實世界的系統面臨著兩種可靠性都可能受到損害的執行條件。這些包括硬體故障，通訊故障，甚至是不誠實的參與者。XRP 賬本設計理念的一部分是檢測結果可靠性受損的情況並報告，而不是提供一定不能依賴的結果。

XRP 賬本的一致性演算法為工作系統證明提供了一個強有力的替代方案，而無需耗費計算資源。拜占庭的失敗是可能的，而且確實發生，但後果只是輕微的延誤。在所有情況下，只有在實際情況下，XRP 賬本的一致性演算法才會報告結果的可靠性。

費用投票

驗證節點可以對基本交易成本以及儲備金要求進行投票。如果驗證節點的配置中的首選項與網路的當前設定不同，驗證節點會定期向網路表示其首選項。如果驗證節點的法定人數同意更改，他們可以應用此後生效的更改。驗證節點員可能會出於各種原因來執行此操作，尤其是要適應XRP值的長期變化。

的操作員可以[voting]在rippled.cfg檔案的節中設定他們對交易成本和預留需求的偏好。

警告：如果需求不充分（如果採用可信驗證節點的共識），可能會使XRP分類帳對等網路遭受拒絕服務攻擊。

您可以設定的引數如下所示：

投票過程

每個第256個賬本都稱為“標誌”賬本。（標誌賬本的定義使得賬本_index 模數 256等於0）。在標誌賬本緊前面的賬本中，每個帳戶儲備金或交易成本偏好與當前網路設定不同的驗證節點在分類帳驗證的同時分發“投票”訊息，表明驗證者喜歡的值。

在標誌帳本本身中，沒有任何反應，但驗證節點收到並記下他們信任的其他驗證節點的投票。

在計算其他驗證節點的投票數後，每位驗證節點都會嘗試在其自己的偏好和其信任的大多數驗證節點的偏好之間妥協。（例如，如果一個驗證節點想將最小交易成本從10提高到100，但大多數驗證節點只是想將其從10提高到20，那麼驗證節點就會根據更改將成本提高到20.但是，驗證節點永遠不會落在低於10或高於100的值上。）如果妥協是可能的，驗證節點將插入一個交易納入其關於標誌賬本的賬本的提案。其他需要相同更改的驗證節點將相同的SetFee偽交易插入到他們對相同賬本的提案中。（其偏好與現有網​​絡設定相匹配的驗證節點什麼都不做）。如果SetFee偽交易在共識過程中存在，以包含在驗證分類帳中，則由SetFee偽交易表示的新交易成本和保留設定將開始生效以下賬本。

簡而言之：

• Flag ledger-1：驗證節點提交投票。
• Flag ledger：驗證節點會計票並決定包含哪些SetFee（如果有）。
• Flag ledger+1：驗證節點將SetFee偽交易插入其建議的賬本中。
• Flag ledger+2：如果SetFee psuedotransaction達成了共識，則新設定會生效。

最大費用值

費用的最大可能值受儲存在的內部資料型別的限制。這些值如下所示：