以太坊交易data編碼

幣安鏈上怎麼發幣

1、進入區塊鏈瀏覽器：

2、輸入合約地址，搜索目標合約

該tab頁下的Code、ReadContract都不需要連接錢包，只有WriteContract需要連接錢包。

3、選項WriteContract頁簽，連接metamask錢包

metamask錢包連接成功後:

點擊Write按鈕後會彈出metamask錢包，提示需要消耗BNB，授權確認消耗BNB即可。

執行完成後，區塊鏈瀏覽器上可以查詢到執行結果。

發幣完成後必須開源合約，並且驗證合約代碼完全匹配ABI和bytecode。因此需要上傳代幣的相關信息到BSC區塊鏈瀏覽器上，包括：合約名稱、編譯器版本、license、構造函數參數等。

以下為開源合約代碼的操作步驟：

1、發幣完成後記錄合約的transactionhash：

在BSC區塊鏈瀏覽器上查詢該hash詳情：

代碼的合約地址為：

2、BSC區塊鏈瀏覽器上查看合約詳情

進入合約詳情頁面，選擇contractTAB頁簽

3、點擊「VerifyandPublish」上傳代幣信息到BSC區塊鏈瀏覽器

4、選擇合約創建時相關的信息，填寫如下表單

I、合約地址是自動帶出來的

II、編譯器類型選擇：如果合約代碼是由多個文件組成的就選擇：Solidity(Multi-Partfiles)，如果是單個文件的合約就選擇：Solidity(Singlefile)

III、編譯器版本：要根據合約代碼中的編譯器版本確定，必須和合約代碼編譯時的版本保持一致。本示例合約編譯時版本為：pragmasolidity^0.6.12，因此此處選擇V0.6.12+commit.27d51765

IIIV、license授權類型：合約代碼中是MIT授權，此處選擇MIT即可，這個地方實際上可以隨便選擇。

5、以上信息配置完成後，上傳合約代碼文件

選擇組成合約代碼的所有文件，點擊「ClicktoUploadselectedfiles」

點擊「ClicktoUploadselectedfiles」上傳合約代碼文件到區塊鏈瀏覽器，上傳完成後截圖如下：

6、繼續選擇後面的配置信息，完成合約代碼開源

構造函數傳入參數是合約部署時輸入的，確認沒有問題即可。

本示例沒有調用合約類庫，因此合約類庫地址可以不填。

區塊鏈金融應用區塊鏈債券操作前准備區塊鏈+債券區塊鏈因為具有獨有優勢，有可能取代證券傳統發行方式和交易模式，建立全新的區塊鏈證券市場網路，完成認證、確權、發行、交易、追溯等工作，也有助於消除造假、違約

等行為，實現實時穿透監管。傳統債券與區塊鏈債券傳統債券和區塊鏈債券的最大區別在於，傳統模式是基於中心化的點對點債券，這個中心可能是中介或者電子化賬戶，而區塊鏈債券是去中心化或者去中介化的點對點流通債券，這樣有助於提高效率，解決信息不對稱等問題。區塊鏈+IPO通過區塊鏈將IPO相關信息透明化、公開化，就可使得投資者有跡可循，增加其造假成本。搭建聯盟鏈通過組成聯盟鏈，把債券發行部署到區塊鏈上，實現點對點的發行，可以弱化證券承銷機構的作用，減免承銷費用。智能債券（創建智能合約）當某項交易條件被滿足時，債券交易雙方按照事先約定的證券成交價格和成交數量完成交易。這樣的合約被變為代碼寫入區塊鏈中，一旦條件被觸發，區塊鏈系統會自動啟動智能合約的付款代碼，所涉及的證券等有價資產將被自動按照合約進行交易，並實時完成清算交割。有效簡化了發行者的違約行為智能證券避免了傳統金融交易的手動過程更加節省時間和成本它的設計使得證券交易雙方不再依賴第三方信用中介，還有助於在加快交易速度的同時，減少人為錯誤和運營風險。

舉個栗子：CryptoCountries（加密國家）就是利用以太坊（Ethereum）區塊鏈智能合約而開發的一款分布式游戲Dapp。該游戲允許用戶使用ETH(以太坊）在數字地圖上購買虛擬國家。當一名用戶買下一個國家後，就成為了該虛擬國家的「國王」，但用戶需要謹防其他用戶「搶」自己的國王寶座。如果有人想要購買同一個國家，他只需要比前任國王出價高出一倍即可，只要用戶出價觸發智能合約條款，他就會自動獲得該國家(在智能合約條款下，該交易具有強制性，價高者終究可以獲得虛擬國家「國王」稱號）。當交易完成後，新用戶就成了該虛擬國家的新「國王」。這是一個穩賺不賠的游戲（如果始終有接盤者的話），對第一個購買國家的用戶而言，國家買賣的差價就是自己的利潤。國內的開發公司如方維等現在也可以將智能合約跟區塊鏈游戲結合，需要的話可以關注一下。

區塊鏈是分布式數據存儲、點對點傳輸、共識機制、加密演算法等計算機技術的新型應用模式。所謂共識機制是區塊鏈系統中實現不同節點之間建立信任、獲取權益的數學演算法。

區塊鏈的賺錢方法：

1、推廣賺傭金。

區塊鏈的做法是，首先注冊交易所賬號，生成自己的邀請鏈接，然後推廣，有人通過你的鏈接注冊了交易所並產生交易的話，你就有傭金。

2、炒幣。

炒幣就像炒股。炒幣是區塊鏈賺錢門檻最低的一種方式。

3、挖礦。

比特幣中的「挖礦」就是記賬的過程。這個過程需要搶，搶到記賬權機會就有獎勵，獎勵的東西是比特幣。這個行為就是「挖礦」。

4、開發錢包。

錢包是區塊鏈的基礎設施，就像區塊鏈的「支付寶」或「微信支付」。

拓展資料：

1、區塊鏈（Blockchain）是比特幣的一個重要概念，它本質上是一個去中心化的資料庫，同時作為比特幣的底層技術。區塊鏈是一串使用密碼學方法相關聯產生的數據塊，每一個數據塊中包含了一次比特幣網路交易的信息，用於驗證其信息的有效性（防偽）和生成下一個區塊。

2、區塊鏈誕生自中本聰的比特幣，自2009年以來，出現了各種各樣的類比特幣的數字貨幣，都是基於公有區塊鏈的。

3、2016年1月20日，中國人民銀行數字貨幣研討會宣布對數字貨幣研究取得階段性成果。會議肯定了數字貨幣在降低傳統貨幣發行等方面的價值，並表示央行在探索發行數字貨幣。中國人民銀行數字貨幣研討會的表達大大增強了數字貨幣行業信心。這是繼2013年12月5日央行五部委發布關於防範比特幣風險的通知之後，第一次對數字貨幣表示明確的態度。

區塊鏈——網路

Ⅲ 以太坊的ABI編碼

ABI全稱Application Binary Interface, 是調用智能合約函數以及合約之間函數調用的消息編碼格式定義,也可以理解為智能合約函數調用的介面說明. 類似Webservice里的SOAP協議一樣；也就是定義操作函數簽名，參數編碼，返回結果編碼等。

使用ABI協議時必須要求在編譯時知道類型,即強類型相關.

當一個智能合約編譯出來後, 他的abi介面定義就確定了. 比如下面的智能合約:

生成的位元組碼:

生成的abi定義:

可以看出, 生成abi包含了2個定義: 函數 lotus , 事件 Log_lotus , 各個欄位含義見上. 根據該abi定義,就可以生成調用該智能合約函數的abi格式的數據了.

格式簡單的可以表示為: 函數選擇器+參數編碼

一個函數調用的前四個位元組數據指定了要調用的函數簽名。計算方式是使用函數簽名的 keccak256 的哈希，取4個位元組。

函數名如果有多個參數使用,隔開，要去掉表達式中的所有空格。在geth客戶端,通過命令可以得到hash:

由於前面的函數簽名使用了四個位元組，參數的數據將從第五個位元組開始。

根據參數類型,編碼規則有所區別:

除了bytes,和string, 其他類型的數據不足32位元組長度的需要加0補足32位元組. 動態長度的編碼在例子中介紹.

函數: function baz(uint32 x, bool y) :

調用: baz(69, true)

生成的數據如下:

返回結果是一個bool值，在這里，返回的是false:

函數: f(uint,uint32[],bytes10,bytes)

調用: (0x123, [0x456, 0x789], "1234567890", "Hello, world!")

函數選擇器: bytes4(sha3("f(uint256,uint32[],bytes10,bytes)"))

對於 固定大小的類型 值 uint256 和 bytes10 ，直接編碼值。

對於 動態內容類型 值 uint32[] 和 bytes ，我們先 編碼偏移值 ，偏移值是整個值編碼的開始到真正存這個數據的偏移值（這里不計算頭四個用於表示函數簽名的位元組）。

所以參數編碼數據依次為：

尾部部分的第一個動態參數， [0x456, 0x789] 編碼拆解如下：

最後我們來看看第二個動態參數的的編碼， Hello, world! 。

所以最終結果是:

Ⅳ 比特幣、以太坊地址類型及其生成機制全解析

比特幣與以太坊的地址類型及其生成機制解析如下：

以太坊地址類型及其生成機制： 類型：以太坊地址主要分為EOA與智能合約賬戶。EOA地址關聯私鑰，由用戶控制；智能合約賬戶則關聯合約代碼，由合約邏輯控制。 生成機制： EOA地址生成：涉及私鑰、公鑰與哈希值的計算。私鑰通過加密演算法生成，公鑰由私鑰通過橢圓曲線演算法推導得出，地址則是公鑰的哈希值的特定編碼形式。 智能合約地址生成：結合部署智能合約的EOA的公鑰與nonce生成。當智能合約被部署時，一個新的地址會根據這些參數計算得出。

比特幣地址類型及其生成機制： 類型：比特幣地址類型包括Legacy、PaytoScriptHash、Segwit與Taproot。Legacy地址是比特幣最早的地址類型；P2SH地址用於多重簽名交易；Segwit地址旨在提高交易效率與減少費用；Taproot地址則進一步提升了隱私性與靈活性。 生成機制：比特幣地址的生成遵循與以太坊類似的原理，但使用不同的演算法與編碼方式。私鑰通過加密演算法生成，公鑰由私鑰推導得出，地址則是公鑰經過一系列哈希與編碼操作後得出的結果。不同的地址類型在哈希與編碼階段採用不同的規則以適應其特定的使用場景。

總結：比特幣與以太坊的地址類型及其生成機制均基於加密操作，確保了地址的唯一性與安全性。不同類型的地址適應了不同的使用場景與需求，為用戶提供了靈活、安全的交易方式。

Ⅳ Web3中文｜什麼是以太坊虛擬機(EVM)，它是如何工作的

以太坊虛擬機（EVM）是區塊鏈架構的核心，執行以太坊應用代碼或智能合約，並為它們提供在以太坊網路上運行的環境。它用C++編寫並使用LLVM項目編譯器，是一種可以連續運行的特殊狀態機，決定著以太坊區塊鏈中每個區塊的狀態。EVM不僅管理著節點對分布式賬本的操作范圍，還定義了在不同區塊之間改變狀態的具體規則，是智能合約成功運行的基礎。

以太坊虛擬機在確保網路平穩運行方面的作用在於，它對每個輸入信息產生一個具有確定性的輸出信息，其運行方式類似於將瞬態值推入和推出下推棧的堆棧機器，深度為1024個項，每個項都是256位字。它以位元組數組的形式維護臨時內存，並以140個標准操作碼集合的形式執行已編譯的智能合約代碼，實現其他區塊鏈特有的堆棧操作。

在處理交易過程中，EVM具有本質上不穩定的機器狀態，但同時具備全局或世界狀態以容納以太坊區塊鏈上的不同賬戶信息。所有操作都由EVM代碼管理，自2015年以太坊網路推出以來，EVM代碼經歷了多次迭代，目前存在多種EVM實現工具。

EVM為所有應用提供可靠動力，是運行智能合約的首要程序，為開發人員提供了使用各種編程語言（如Solidity、Vyper、Python和Yul等）編寫這些智能合約的自由。每一個DApp和智能合約都被轉換為位元組碼，這些位元組碼被傳送至EVM並分布在以太坊網路的所有節點中。部署智能合約時，EVM負責與所有節點聯系，並在達成共識後進行狀態更改。

EVM的好處在於為開發人員執行代碼掃清了一些顧慮，不會影響網路的其他部分或影響託管在任意節點的數據或個人文件。開發人員可以在具有分布式共識的不同計算環境中運行復雜的智能合約，確保單個節點的故障不會對DApp或智能合約的整體運行產生任何負面影響。因為賬戶數據在EVM中維持著一種全局狀態，為開發人員創造了良好的條件以編寫自定義智能合約代碼和創建可以訪問全局數據集並產生可靠輸出的獨特DApp。

除了上述提到的，EVM還提供了標准代碼庫、越來越多與之兼容的第2層區塊鏈和大量潛在的EVM用例，使其成為Web3開發的首選平台。然而，EVM存在高額交易費或者說Gas成本的問題，這些費用需要用戶通過ETH進行支付且會根據智能合約的復雜性和當時網路擁塞情況變化。此外，開發人員需要有足夠的經驗和一定的技術專長，才能利用Solidity創建高效的智能合約。如果選擇使用其他語言進行編碼，需要解決任何固有重復問題。

以太坊虛擬機在區塊鏈生態系統中帶來了革命性的變化，許多區塊鏈項目正在改進這種用於讀取和執行代碼的技術。跨鏈互操作性對於開發人員來說是最重要的，許多與EVM兼容的區塊鏈已經發展起來了，提供了比以太坊更低的費用和更快的交易速度。以太坊用戶可以直接與這些區塊鏈進行無縫交互，並通過跨鏈橋將以太坊上的資金轉移到這些區塊鏈。隨著在2022年9月完成合並，以太坊的下一個目標是完成從EVM到以太坊WebAssembly（eWASM）的範式轉變，旨在將eWASM打造成一個高度模塊化並獨立於平台的虛擬指令集體系架構。許多人將eWASM視為以太坊的下一個游戲規則改變者，並認為它可能為其他區塊鏈所使用。然而，eWASM能否取代EVM成為最受信任的智能合約機制，還需要時間來驗證。

Ⅵ 【以太坊易錯概念】nonce, 公私鑰和地址，BASE64/BASE58,

以太坊里的nonce有兩種意思，一個是proof of work nonce，一個是account nonce。

在智能合約里，nonce的值代表的是該合約創建的合約數量。只有當一個合約創建另一個合約的時候才會增加nonce的值。但是當一個合約調用另一個合約中的method時 nonce的值是不變的。
在以太坊中nonce的值可以這樣來獲取（其實也就是屬於一個賬戶的交易數量）：

但是這個方法只能獲取交易once的值。目前是沒有內置方法來訪問contract中的nonce值的

通過橢圓曲線演算法生成鑰匙對（公鑰和私鑰），以太坊採用的是secp256k1曲線,
公鑰採用uncompressed模式，生成的私鑰為長度32位元組的16進制字串，公鑰為長度64的公鑰字串。公鑰04開頭。
把公鑰去掉04，剩下的進行keccak-256的哈希，得到長度64位元組的16進制字串，丟掉前面24個，拿後40個，再加上"0x"，即為以太坊地址。

整個過程可以歸納為：

2）有些網關或系統只能使用ASCII字元。Base64就是用來將非ASCII字元的數據轉換成ASCII字元的一種方法，而且base64特別適合在http，mime協議下快速傳輸數據。Base64使用【字母azAZ數字09和+/】這64個字元編碼。原理是將3個位元組轉換成4個位元組(3 X 8) = 24 = (4 X 6)
當剩下的字元數量不足3個位元組時，則應使用0進行填充，相應的，輸出字元則使用'='佔位，因此編碼後輸出的文本末尾可能會出現1至2個'='。

1）Base58是用於Bitcoin中使用的一種獨特的編碼方式，主要用於產生Bitcoin的錢包地址。相比Base64，Base58不使用數字"0"，字母大寫"O"，字母大寫"I"，和字母小寫"l"，以及"+"和"/"符號。

Base58Check是一種常用在比特幣中的Base58編碼格式，增加了錯誤校驗碼來檢查數據在轉錄中出現的錯誤。 校驗碼長4個位元組，添加到需要編碼的數據之後。校驗碼是從需要編碼的數據的哈希值中得到的，所以可以用來檢測並避免轉錄和輸入中產生的錯誤。使用 Base58check編碼格式時，編碼軟體會計算原始數據的校驗碼並和結果數據中自帶的校驗碼進行對比。二者不匹配則表明有錯誤產生，那麼這個 Base58Check格式的數據就是無效的。例如，一個錯誤比特幣地址就不會被錢包認為是有效的地址，否則這種錯誤會造成資金的丟失。

為了使用Base58Check編碼格式對數據（數字）進行編碼，首先我們要對數據添加一個稱作「版本位元組」的前綴，這個前綴用來明確需要編碼的數 據的類型。例如，比特幣地址的前綴是0（十六進制是0x00），而對私鑰編碼時前綴是128（十六進制是0x80）。 表4-1會列出一些常見版本的前綴。

接下來，我們計算「雙哈希」校驗碼，意味著要對之前的結果（前綴和數據）運行兩次SHA256哈希演算法：

checksum = SHA256(SHA256(prefix+data))
在產生的長32個位元組的哈希值（兩次哈希運算）中，我們只取前4個位元組。這4個位元組就作為校驗碼。校驗碼會添加到數據之後。

結果由三部分組成：前綴、數據和校驗碼。這個結果採用之前描述的Base58字母表編碼。下圖描述了Base58Check編碼的過程。

相同:

1） 哈希演算法、Merkle樹、公鑰密碼演算法
https://blog.csdn.net/s_lisheng/article/details/77937202?from=singlemessage

2）全新的 SHA-3 加密標准 —— Keccak
https://blog.csdn.net/renq_654321/article/details/79797428

3）在線加密演算法
http://tools.jb51.net/password/hash_md5_sha

4）比特幣地址生成演算法詳解
https://www.cnblogs.com/zhaoweiwei/p/address.html

5）Base58Check編碼實現示例
https://blog.csdn.net/QQ604666459/article/details/82419527

6） 比特幣交易中的簽名與驗證
https://www.jianshu.com/p/a21b7d72532f

Ⅶ 以太坊中的國際銀行賬號iban

簡單地說，以太坊中的iban賬號是以太坊為了和傳統的銀行系統對接而引入的概念，web3.js中提供了以太坊地址和iban地址之間的轉換方法。

iban這個概念源於傳統的銀行系統，其英文全稱為 International Bank Account Number ，即國際銀行帳號。iban的作用是為全球任意一家銀行中的任意一個賬戶生成一個全球唯一的賬號，以便進行跨行交易。一個iban賬號看起來像這樣：

iban地址最多可以包含34個字母和數字，其中的字母大小寫不敏感。在iban
中包含以下信息：

以太坊引入了一個新的IBAN國別碼：XE，其中E代表Ethereum，X代表非法幣（non-jurisdictional currencies）。同時，以太坊提出了三種BBAN的編碼格式：direct、basic和indirect。

direct編碼方案中的BBAN為30個字母/數字，只有一個欄位：賬戶編號。例如，以太坊地址 轉換為direct方案的BBAN賬號，就得到 。

可以使用web3.js中的 web3.eth.Iban.fromEthereumAddress()
方法來執行這一轉換：

basic編碼方案與direct方案的唯一區別在於，其BBAN長度為31個字母/數字，因此該方案不兼容IBAN。

indrect編碼方案中的BBAN長度為16個字母/數字，包含三個欄位：

例如，一個採用indrect編碼方案的以太坊iban賬號，看起來是這樣：

前面的 XE 表示國別碼， 81 為校驗和，後面的16個字元就是indrect編碼的BBAN，其中：

如前所述，使用 web3.eth.Iban.fromEthereumAddress() 方法，可以將一個以太坊地址轉換為direct編碼方案的iban賬號。與之對應的，可以使用 web3.eth.Iban.toAddress 方法，將一個採用direct編碼方案的iban賬號，轉換回以太坊地址。例如：

iban賬號中的校驗和用來幫助核驗一個給定字元串是否為有效的iban賬號。可以使用web3.js中的 web3.eth.Iban.isValid()
來進行執行校驗。例如：

原文： http://blog.hubwiz.com/2018/06/03/ethereum-iban/

Ⅷ 【深度知識】以太坊數據序列化RLP編碼/解碼原理

RLP(Recursive Length Prefix)，中文翻譯過來叫遞歸長度前綴編碼，它是以太坊序列化所採用的編碼方式。RLP主要用於以太坊中數據的網路傳輸和持久化存儲。

對象序列化方法有很多種，常見的像JSON編碼，但是JSON有個明顯的缺點：編碼結果比較大。例如有如下的結構：

變數s序列化的結果是{"name":"icattlecoder","sex":"male"},字元串長度35，實際有效數據是icattlecoder 和male，共計16個位元組，我們可以看到JSON的序列化時引入了太多的冗餘信息。假設以太坊採用JSON來序列化，那麼本來50GB的區塊鏈可能現在就要100GB，當然實際沒這么簡單。

所以，以太坊需要設計一種結果更小的編碼方法。

RLP編碼的定義只處理兩類數據：一類是字元串（例如位元組數組），一類是列表。字元串指的是一串二進制數據，列表是一個嵌套遞歸的結構，裡面可以包含字元串和列表，例如["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]就是一個復雜的列表。其他類型的數據需要轉成以上的兩類，轉換的規則不是RLP編碼定義的，可以根據自己的規則轉換，例如struct可以轉成列表，int可以轉成二進制（屬於字元串一類），以太坊中整數都以大端形式存儲。

從RLP編碼的名字可以看出它的特點：一個是遞歸，被編碼的數據是遞歸的結構，編碼演算法也是遞歸進行處理的；二是長度前綴，也就是RLP編碼都帶有一個前綴，這個前綴是跟被編碼數據的長度相關的，從下面的編碼規則中可以看出這一點。

對於值在[0, 127]之間的單個位元組，其編碼是其本身。

例1：a的編碼是97。

如果byte數組長度l <= 55，編碼的結果是數組本身，再加上128+l作為前綴。

例2：空字元串編碼是128，即128 = 128 + 0。

例3：abc編碼結果是131 97 98 99，其中131=128+len("abc")，97 98 99依次是a b c。

如果數組長度大於55， 編碼結果第一個是183加數組長度的編碼的長度，然後是數組長度的本身的編碼，最後是byte數組的編碼。

請把上面的規則多讀幾篇，特別是數組長度的編碼的長度。

例4：編碼下面這段字元串：

The length of this sentence is more than 55 bytes, I know it because I pre-designed it
這段字元串共86個位元組，而86的編碼只需要一個位元組，那就是它自己，因此，編碼的結果如下：

184 86 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前三個位元組的計算方式如下：

184 = 183 + 1，因為數組長度86編碼後僅佔用一個位元組。
86即數組長度86
84是T的編碼
例5：編碼一個重復1024次"a"的字元串，其結果為：185 4 0 97 97 97 97 97 97 ...。
1024按 big endian編碼為004 0，省略掉前面的零，長度為2，因此185 = 183 + 2。

規則1~3定義了byte數組的編碼方案，下面介紹列表的編碼規則。在此之前，我們先定義列表長度是指子列表編碼後的長度之和。

如果列表長度小於55，編碼結果第一位是192加列表長度的編碼的長度，然後依次連接各子列表的編碼。

注意規則4本身是遞歸定義的。
例6：["abc", "def"]的編碼結果是200 131 97 98 99 131 100 101 102。
其中abc的編碼為131 97 98 99,def的編碼為131 100 101 102。兩個子字元串的編碼後總長度是8，因此編碼結果第一位計算得出：192 + 8 = 200。

如果列表長度超過55，編碼結果第一位是247加列表長度的編碼長度，然後是列表長度本身的編碼，最後依次連接各子列表的編碼。

規則5本身也是遞歸定義的，和規則3相似。

例7：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
的編碼結果是:

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前兩個位元組的計算方式如下：

248 = 247 +1
88 = 86 + 2，在規則3的示例中，長度為86，而在此例中，由於有兩個子字元串，每個子字元串本身的長度的編碼各佔1位元組，因此總共佔2位元組。
第3個位元組179依據規則2得出179 = 128 + 51
第55個位元組163同樣依據規則2得出163 = 128 + 35

例8：最後我們再來看個稍復雜點的例子以加深理解遞歸長度前綴，

["abc",["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]]
編碼結果是：

248 94 131 97 98 99 248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
列表第一項字元串abc根據規則2，編碼結果為131 97 98 99,長度為4。
列表第二項也是一個列表項：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
根據規則5，結果為

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
長度為90，因此，整個列表的編碼結果第二位是90 + 4 = 94, 佔用1個位元組，第一位247 + 1 = 248

以上5條就是RPL的全部編碼規則。

各語言在具體實現RLP編碼時，首先需要將對像映射成byte數組或列表兩種形式。以go語言編碼struct為例，會將其映射為列表，例如Student這個對象處理成列表["icattlecoder","male"]

如果編碼map類型，可以採用以下列表形式：

[["",""],["",""],["",""]]

解碼時，首先根據編碼結果第一個位元組f的大小，執行以下的規則判斷：

1.如果f∈ [0,128),那麼它是一個位元組本身。

2.如果f∈[128,184)，那麼它是一個長度不超過55的byte數組，數組的長度為 l=f-128

3.如果f∈[184,192)，那麼它是一個長度超過55的數組，長度本身的編碼長度ll=f-183,然後從第二個位元組開始讀取長度為ll的bytes，按照BigEndian編碼成整數l，l即為數組的長度。

4.如果f∈(192,247]，那麼它是一個編碼後總長度不超過55的列表，列表長度為l=f-192。遞歸使用規則1~4進行解碼。

5.如果f∈(247,256]，那麼它是編碼後長度大於55的列表，其長度本身的編碼長度ll=f-247,然後從第二個位元組讀取長度為ll的bytes,按BigEndian編碼成整數l，l即為子列表長度。然後遞歸根據解碼規則進行解碼。

以上解釋了什麼叫遞歸長度前綴編碼，這個名字本身很好的解釋了編碼規則。

（1） 以太坊源碼學習—RLP編碼( https://segmentfault.com/a/1190000011763339 )
（2）簡單分析RLP編碼原理
( https://blog.csdn.net/itchosen/article/details/78183991 )