RLP 基本原理問題

我試圖了解為什麼選擇 RLP 並將其開發為內部協議。我偶然發現了這個連結，它提供了一些見解：

https://github.com/ethereum/wiki/wiki/Design-Rationale

試圖理解下面的段落，非常感謝詳細的解釋。

“RLP 的替代方案是使用現有算法，例如 protobuf 或 BSON；但是，我們更喜歡 RLP，因為 (1) 實現簡單，(2) 保證絕對字節完美的一致性。許多語言中的鍵/值映射沒有明確的排序，浮點格式有很多特殊情況，可能會導致相同的數據導致不同的編碼，從而導致不同的雜湊值。”

它說RLP是

• 簡單的
• 明確的

它比其他算法更簡單，因為它沒有定義字節和數組以外的任何數據類型。

這是明確的，因為相同的輸入數據總是被序列化為相同的字節序列。

在許多語言中，鍵/值映射沒有明確的順序。這意味著 2 個條目：

key1: value1
key2: value2

可能被序列化為：

{
 "key1": "value1",
 "key2": "value2"
}

在一種實施方式中，以及

{
 "key2": "value2",
 "key1": "value1"
}

在另一個實現中。相同的輸入數據可以輸出不同的序列化。這在乙太坊中是不可接受的。

另一方面，在使用 RLP 時，需要先將 map 轉換為數組（這種轉換超出了 RLP 的範圍），然後傳遞給 RLP 進行序列化。在我們的範例中，RLP 的輸入結構將是：

[["key1", "value1"],["key2","value2"]]

其中引號中的字元串應首先轉換為字節（也超出 RLP 的範圍）。

基本上，RLP 試圖通過限制支持的數據類型來避免歧義。

引用自：https://ethereum.stackexchange.com/questions/42291