RLP 有很多問題， 但適合區塊鏈
又一個序列化編碼
RLP（“遞歸前綴編碼”）編碼是在以太坊中使用的主要序列化格式，並在所有地方都使用-用於區塊，交易，賬戶狀態數據和有線協議消息。
比特幣的經驗
比特幣協議中存在一個設計缺陷，即第三方可能會進行您的有效交易並對其進行變異，從而使其保持有效且功能相同，但具有不同的交易ID。 這極大地增加了編寫正確的錢包軟件的複雜性，並且可以濫用它來使依賴於非突變交易的未確認交易的長鏈無效（因爲交易通過txid相互引用）。
此問題來自多個來源，其中之一是OpenSSL願意接受並理解具有無效編碼的簽名。 正常的ECDSA簽名會編碼兩個大整數，但編碼長度不是固定的-如果有前導零，則應該丟棄它們。
關鍵是適用性
假設簽名是固定長度，然後在其中保留多餘的前導零，則編寫軟件很容易。
這是一個非常有趣的警示故事，並且尤其重要，因爲此類情況是我們在開發理念中做出某些設計決策的原因之一。具體來說，問題是這樣的：許多人繼續指出，我們在許多地方不必要地重新發明了輪子，創建了自己的序列化格式RLP，而不是使用現有的protobuf，我們正在構建特定於應用程序的腳本語言，而不是“僅使用Lua”。這是一個非常有效的擔憂；非此處發明綜合症是一種常用的貶義詞，因此進行這種內部開發確實需要證明。
上面引用的警示故事恰好提供了上述的辯護的完美示例。外部技術，無論是protobuf，Lua還是OpenSSL，都非常好，並且擁有多年的開發經驗，但是在很多情況下，它們從來沒有考慮到加密貨幣所需的完美共識，確定性和加密完整性。上面的OpenSSL情況就是一個很好的例子。除了加密貨幣之外，實際上沒有其他情況可以使用有效簽名並將其轉換爲具有不同哈希值的另一個有效簽名這一事實，這是一個重大問題，但這是致命的。以太坊的核心原則之一就是簡單。該協議應儘可能簡單，並且該協議不應包含任何黑框。每個子協議的每個功能都應該準確地100％記錄在白皮書或Wiki中，並以該功能作爲規範來實現（即測試驅動的開發）。可以說，對現有的軟件包執行此操作幾乎與從頭開始構建全新的軟件包一樣困難。實際上，這可能甚至更難，因爲現有軟件包通常具有比其完整的功能更復雜的功能，而我們的替代品則不需要-閱讀protobuf規範並將其與RLP規範進行比較以瞭解我的知識。意思。
請注意，上述原則有其侷限性。例如，我們當然不會愚蠢地開始發明自己的哈希算法，而是使用廣受讚譽和經過嚴格審查的SHA3，並且對於簽名，我們使用與比特幣相同的舊secp256k1，儘管我們使用RLP進行存儲v，r，s三元組（v是用於公共密鑰恢復的額外兩位），而不是OpenSSL緩衝區協議。在這種情況下，“僅使用X”就是正確的選擇，因爲X具有清晰易懂的界面，並且不同的實現之間沒有細微的差異。空字符串的SHA3在C ++，Python和Javascript中爲c5d2460186…a470；沒有關於它的辯論。在這兩個極端之間，基本上是要找到適當的平衡。
RLP做出的簡化
RLP的替代品將使用現有的算法，例如protobuf或BSON； 但是，我們更喜歡RLP，因爲
- 實現簡單
- 確保絕對的字節完美一致性。
許多語言中的鍵/值映射沒有明確的順序，浮點格式有很多特殊情況，有可能導致同一數據導致不同的編碼，從而導致不同的哈希。 通過內部開發協議，可以確保在設計這些協議時便牢記這些目標（這是一條通用原則，也適用於代碼的其他部分，例如VM）。 請注意，雖然BitTorrent使用的bencode與長度的十進制編碼相比，它與二進制RLP相比稍差一些，但它可能爲RLP提供了一種可替代的選擇。
參考
RLP規範描述