以太坊私鑰編碼規格

Ⅰ 以太坊怎麼根據地址獲取私鑰

安裝metamask metamask是可以安裝在瀏覽器上的擴展程序,可以在進行安裝。建議在安裝在虛擬機中
以太坊的私鑰生成是通過secp256k1橢圓曲線演算法生成的,secp256k1是一個橢圓曲線演算法,同比特幣。公鑰推導地址和比特幣相比,在私鑰生成公鑰這一步其實是一樣的,區別在公鑰推導地
以太坊錢包地址就是你的銀行卡號,倘若你把地址忘了,可以用私鑰、助記詞、keystore+密碼,導入錢包找回。首先注冊登錄bitz,找到資產下面的以太坊,點擊充值,這時候就能獲取充值地址了。然後把錢包里的以太坊直接充到這個地址就行了。

Ⅱ 以太坊精度是幾位

以太坊的私鑰是一個256位的二進制數,因此猜對它的概率是2的256次方分之一,數值上大約是10的77次方分之一,也就是說分母是1後面77個0。
1、以太坊的單位,沿襲了科學界的傳統,用做過傑出貢獻的數學、密碼學專家的名字命名。一次性向六位專家致敬,並且未來可能引入更多單位。以太坊的最小單位是Wei。
2、以太坊的私鑰是一個256位的二進制數,因此猜對它的概率是2的256次方分之一,數值上大約是10的77次方分之一,也就是說分母是1後面77個0。
3、1個以太幣=10的18次方Wei，但因為這個單位太小，好像Byte位元組與KB、MB、GB的電腦存儲單位一樣，以太坊還有其他的單位：
Kwei（Babbage）=10的3次方Wei
Mwei（Lovelace）=10的6次方Wei
Gwei（Shannon）=10的9次方Wei
MicroEther（Szabo）=10的12次方Wei
MilliEther（Finney）=10的15次方Wei
Ether=10的18次方Wei
每個單位都還有個別名，即括弧里的那個，每個別名又各有來歷。老鏈哥找機會再逐個介紹。通常，小額支付使用Finney，計算Gas價格使用GWei。

Ⅲ 【概念】私鑰、助記詞和keystore到底是什麼關系

使用了很久的錢包，用得有點誠惶誠恐，錢包除了用於轉賬外，都不怎麼敢動它，怕誤操作搞不好就空了，所以大部分都在交易所，不敢提。這也間接印證了李笑來老師的一句話：

在申請錢包時，當然看過不少資料，老老實實地記下了私鑰、助記詞，備份了keystore，還放在兩個U盤里備份。但對私鑰、助記詞和keystore是一知半解的，也不知道他們到底什麼關系。如果不是要了解EOS映射，我可能一直不會動錢包，也不會去了解它們。

下面就一個個來好好學習一下這些概念。

私鑰是由64位十六進制的字元組成，每個私鑰是隨機生成的，隨機生成這樣的字元串有2的256次方種可能，這個數字已經超過了宇宙中原子的個數，用「暴力破解」的方式逐一遍歷可能的私鑰，幻想能碰到一個有效的且有幣的私鑰，可以說是不可能，就算是量子計算機也沒用。

一個錢包只有一個私鑰且不能修改。

在導入錢包中，輸入私鑰並設置一個密碼（不用輸入原密碼），就能進入錢包並擁有這個錢包的掌控權，就可以把錢包中的代幣轉移走。

由於私鑰64位，長得太難看，沒有可讀性，而私鑰的備份在電腦上復制起來容易，手抄下來就比較麻煩，但私鑰保存在聯網的電腦上不安全，有被其他人看到的風險，於是有了助記詞工具。

助記詞是明文私鑰的另一種表現形式，最早是由BIP39提案提出，其目的是為了幫助用戶記憶復雜的私鑰 (64位的哈希值)。助記詞一般由12、15、18、21個單詞構成，這些單詞都取自一個固定詞庫, 其生成順序也是按照一定演算法而來，所以用戶沒必要擔心隨便輸入12個單詞就會生成一個地址。助記詞是未經加密的私鑰, 沒有任何安全性可言，任何人得到了你的助記詞，可以不費吹灰之力的奪走你的資產。所以在用戶在備份助記詞之後，一定要注意三點：

助記詞一般會在你創建新錢包的時候出現一次，後面就再也不會出現了，所以創建新錢包時一定要把助記詞抄下來，想辦法備份。最好不要用屏幕截圖或保存在電腦里，因為只要泄露，獲取了你的助記詞就等於獲取了私鑰，你的錢包就成了別人的錢包。

簡而言之：助記詞等於私鑰，絕對不能泄露。

keystore常見於以太坊錢包，是你獨有的、用於簽署交易的以太坊私鑰的加密文件。keystore是一串Json格式的字元串，可以用任何以太坊錢包打開它。keystore必須配合你的錢包密碼來使用，備份了keystore同時別忘了備份錢包的密碼。

用戶可以使用備份的助記詞，重新導入imToken之類的錢包工具，用新的密碼生成一個新的Keystore，可以用這種方法來修改錢包密碼。

助記詞=密鑰=keystore+密碼 ！保管好私鑰或者助記詞不被泄露，或是保存好keystore+記住密碼，你才真正擁有了虛擬資產。

再來一個比較形象的比喻。

概念清楚之後，瞬間感覺輕松多了。再也不用擔心因為不明白而擔心操作失誤的問題。最重要的是將私鑰、助記詞和keystore備份好，盡量離線備份多份，這樣才能保證賬號的安全。

1、 科普 | 什麼是以太坊私鑰儲存（Keystore）文件？
2、 如何妥善備份你的以太坊錢包？
3、 幣圈名詞：地址、密碼、私鑰、助記詞，你真的分清楚了嗎
4、 「地址、密碼、私鑰、助記詞、Keystore 」那些事

Ⅳ 2.在以太坊中,為了得到唯一的公鑰,對私鑰應用哪種演算法

在以太坊中，為了得到唯一的公鑰，對私鑰應用演算法：
1、生成一個隨機的私鑰（32位元組）。
2、通過私鑰生成公鑰（64位元組）。
3、通過公鑰得到地址（20位元組）。

Ⅳ 【深度知識】以太坊數據序列化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 )

Ⅵ 以太坊的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! 。

所以最終結果是:

Ⅶ 以太坊之賬戶

外部賬戶創建流程:

當使用 geth account new 命令新建賬戶，最終調用 accountCreate(accountcmd.go)=>keystore.StoreKey=>storeNewKey(key.go)

storeNewKey完成私鑰、公鑰、地址的生產，最後保存成keystore文件到指定路徑。

最後保存的keystore文件為json格式，如下:

以下為用密碼可以推出私鑰的流程

對交易發起人的地址和nonce進行RLP編碼，再算出Keccak哈希值，取後20個位元組作為該合約的地址,即: Keccak-256(RLP(sender, nonce))[12:]
函數位於: crypto/crypto.go

賬戶在區塊鏈上的存儲結構，內外賬戶的結構都是一樣

文章github地址

Ⅷ 【以太坊易錯概念】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

Ⅸ imtoken錢包私鑰導入格式64進16什麼意思

私鑰=銀行卡+銀行卡密碼。
私鑰是一個長度為64位的字元串，一個錢包只能擁有一個私鑰並且不能修改。為什麼說私鑰=銀行卡+銀行卡密碼呢？因為在imToken中直接導入私鑰可以生成新的密碼，將所有的區塊鏈資產全部轉移走。私鑰作為最高保密級別，應該妥善保管在物理設備上，例如抄在紙上，備份多份並且存放在安全的地方，萬萬不可將私鑰在聯網設備上進行傳輸，避免被黑客截取。

助記詞=私鑰。
助記詞又是什麼東西呢？助記詞既然等於私鑰，那麼其應該是私鑰的另外一種表現形式，並且具有私鑰同等的功能。在imToken中創建錢包，會出來一個助記詞，助記詞的個數一般為12、15、18、21個單詞構成。這些詞都取自一個固定詞庫，其生成順序也是按照一定的演算法得到，且助記詞不能修改。助記詞的主要作用是幫助用戶記憶繁瑣的私鑰。同樣助記詞也要妥善保管好，切勿在聯網設備中傳輸，任何人得到了你的助記詞都可以輕松的轉移你的區塊鏈資產。

keystore+密碼=私鑰。
keyStore文件是以太坊錢包存儲私鑰的一種文件格式（JSON格式）。它使用用戶自定義密碼對私鑰進行加密，在一定程度上keystore=加密後的私鑰，拿到keystore和密碼後照樣可以轉移走所有的區塊鏈資產。keystore密碼是唯一不可修改的，那麼錢包密碼修改之後，keystore也會相應修改。一定要記住加密keystore的密碼，一旦忘記密碼，就相當於遺失了該錢包所有的區塊鏈資產。

————————————————
版權聲明：本文為CSDN博主「懶區塊」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lanqukuai/article/details/81035995

Ⅹ 以太坊中的國際銀行賬號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/