eth的hash地址是什麼意思

Ⅰ 以太坊技術系列-以太坊數據結構

本篇文章和大家介紹一下以太坊的數據結構，上篇文章我們提到，以太坊為了實現智能合約這一功能，使用了基於賬戶的模型。我們來看看以太坊中數據結構。

既然是基於賬戶的模型，我們需要通過賬戶地址找到賬戶的狀態。就像通過銀行卡號可以找到你在銀行中的各種信息一樣。最簡單的想法當然是一個簡單的哈希表 key是賬戶地址 value是賬戶狀態。但這里有個問題解決不了。

輕節點如何校驗賬戶合法性？

上篇我們說過，區塊鏈中有2類節點，全節點和輕節點，輕節點只會存儲block header，所以輕節點如何才能校驗賬號是否合法呢？

這個思路和我們平時用的md5校驗一致，我們會對區塊內的信息進行hash運算從而得出區塊內信息唯一確定的值，區塊鏈所有節點中這個值都是相同的。

在這個過程中我們用到了一種數據結構Merkle Tree（哈希樹），我們先看下Merkle Tree（哈希樹）的示意圖。

上篇文章說到區塊鏈中的鏈表(哈希鏈)和我們平時常見鏈表不同的是將指針從地址改為了hash指，這里也一樣，哈希樹和二叉樹的區別有2個

1.將地址改為了哈希值

2.只有葉子節點存儲數據

回到之前的問題輕節點是如何校驗1個賬戶或交易是否是在鏈上的呢？

整個流程如上圖所示

1.輕節點需要判斷1個賬號是否合法

2.輕節點由於只存儲block header，所以拿到1個賬號的時候會向全節點發出請求

3.全節點存儲了所有賬戶狀態，將賬戶路徑中的需要計算用到的hash值返回給輕節點

4.輕節點本地進行計算根hash值，如果計算結果和自己存儲一致則賬戶合法，不一致則不合法。

那以太坊中的賬戶信息的數據結構就是這樣嗎？

直接用這樣的數據結構來存儲賬戶信息會有2個問題

查找困難

生成hash值不確定

第1個問題應該比較容易發現，在這個樹中尋找1個賬號需要的復雜度是O(n),因為沒有任何順序。

第2個問題其實也是因為無序導致的，無序的組合每個節點針對同一批賬戶生成的hash值不一致，這就導致無法達成共識。

既然2個問題都和順序有關，那我們類似二叉排序樹一樣，使用哈希排序樹是不是就可以解決問題了呢？

使用排序樹後會帶來另外1個問題

插入困難

因為要維持樹是有序的，很可能帶來樹結構的很大變動。

以太坊中使用了另外一種數據結構字典樹。和哈希樹不同，字典樹應該是很多地方都有使用。我們簡單來看下字典樹的結構。

字典樹能夠較好地解決哈希樹的2個缺點1.查找困難 2.生成的hash值不確定以及排序二叉樹的1個缺點 插入困難。

但字典樹我們可以看到可能樹的深度可能由於部分元素導致整棵樹深度非常深。

這時我們可以進一步優化，將相同路徑進行壓縮。這就是壓縮字典樹。

將哈希樹和壓縮字典樹結合，就可以得到以太坊存儲賬戶的最終數據結構-MPT。

將壓縮字典樹裡面的指針從地址改為指針，並且將數據存儲在葉子節點中即可。

介紹完狀態樹的數據結構，我們接下來討論1個問題，區塊中存儲的賬戶狀態是什麼樣的范圍。有2種選擇。

只保存當時區塊中產生交易的賬戶狀態。

保存全局所有的賬戶。

我們可以看下這2種方式，無非就是空間和時間的平衡，只保存當前區塊產生的交易意味著是做懶載入(需要的時候才去尋找賬戶)，在區塊鏈中這個代價是非常大的，因為尋找的賬戶之前從未交易過，這樣會遍歷整個區塊鏈。另外一種保存全局的賬戶方式雖然看起來空間消耗較大，但查找快捷，而且空間的問題我們可以通過其他方式優化。所以最終以太坊選擇了第2種每個區塊都報錯全局所有賬戶的方式。

我們來看下以太坊中是如何保存狀態樹的。

可以看到以太坊中雖然每個區塊都保存了全部賬戶，但是會將未發生變化的賬戶狀態指向前1個節點，本身只存儲發生變化的狀態，這樣可以較大程度優化空間佔用。

介紹完以太坊中比較復雜的狀態樹後，我們繼續來看看以太坊中的另外兩棵樹，交易樹和收據樹。

首先介紹一下，為什麼需要交易樹&收據樹。

1.交易樹

雖然以太坊是基於賬戶的模型，但是就像銀行不僅會存儲銀行卡的余額，還會存儲卡中的每筆錢怎麼來的以及怎麼花的。交易樹中就存儲著當前區塊中的包含的所有交易。

2.收據樹

由於智能合約的引入增加了不少復雜性，所以以太坊用收據樹存儲著一些交易操作的額外信息。比如交易過程中執行日誌就包含在收據樹中方便查詢。收據樹和交易樹是一一對應的。每發生一次交易就會有一次收據。

和狀態樹不同交易樹和收據樹只維護當前區塊內發生的交易，因為當時區塊發生交易時不需要再去查找另外1個交易，也就之前需要可能遍歷整個區塊鏈的查找操作了。

由於以太坊中的出塊速度較快，我們進行一些查詢一些符合條件交易的時候會面臨大量數據遍歷困難的問題。收據樹中引入了布隆過濾器可以幫助我們有效緩解這一困難。

布隆過濾器將大集合中每個元素進行hash運算映射到1個較小的集合，這時再來1個元素要判斷是否在大集合的時候，不需要遍歷整個大集合，而是去進行hash運算去小集合中尋找是否存在，如果不存在，肯定不在大集合中，如果存在則不能說明任何問題。

如上圖所示，布隆過濾器只能證明某1個元素不在集合中，不能證明1個元素在結合中。

以太坊中如果我們要在較多區塊中尋找某1個交易，則可以利用布隆過濾器，過濾掉肯定不存在目標交易的區塊，然後進入收據樹內繼續利用布隆過濾器篩選，剩下的才是可能的目標交易的交易，進行一一比對即可。

我們介紹了以太坊的核心數據結構，狀態樹&交易樹&收據樹，他們都是使用相同的數據結構-哈希壓縮字典樹。但狀態樹是維護1顆全局賬戶樹，交易樹和收據樹則是維護本區塊內的交易或收據。

介紹完數據結構後，後面我們會用幾篇文章來介紹以太坊中的一些核心演算法，比如共識機制，挖礦演算法等。

Ⅱ ETH介面是什麼

ETH介面指的是介面，是目前應用最廣泛的區域網通訊方式，同時也是一種協議。而乙太網介面就是網路數據連接的埠。
乙太網的每個版本都有電纜的最大長度限制（即無須放大的長度），這個范圍內的信號可以正常傳播，超過這個范圍信號將無法傳播。
為了允許建設更大的網路，可以用中繼器把多條電纜連接起來。中繼器是一個物理層設備，它能接收、放大並在兩個方向上重發信號。
(2)eth的hash地址是什麼意思擴展閱讀
幾種常見的乙太網介面類型。
1、SC光纖介面
SC光纖介面在100Base-TX乙太網時代就已經得到了應用，因此當時稱為100Base-FX（F是光纖單詞fiber的縮寫），不過當時由於性能並不比雙絞線突出但是成本卻較高，因此沒有得到普及，現在業界大力推廣千兆網路，SC光纖介面則重新受到重視。
2、RJ-45介面
這種介面就是我們現在最常見的網路設備介面，俗稱「水晶頭」，專業術語為RJ-45連接器，屬於雙絞線乙太網介面類型。RJ-45插頭只能沿固定方向插入，設有一個塑料彈片與RJ-45插槽卡住以防止脫落。
3、FDDI介面
FDDI是目前成熟的LAN技術中傳輸速率最高的一種，具有定時令牌協議的特性，支持多種拓撲結構，傳輸媒體為光纖。光纖分布式數據介面（FDDI）是由美國國家標准化組織（ANSI）制定的在光纜上發送數字信號的一組協議。
參考資料來源：網路-乙太網介面

Ⅲ 以太坊獲取測試鏈代幣

發起以太坊交易時需要消耗以太幣，開發智能合約做測試時如果在主網做測試成本會很高，並且主網的速度也比較慢，以太坊官方考慮到大家的這個需求提供了幾條測試鏈供大家使用，比較知名的有以下這幾個

以太坊的主測試網，環境最接近主網環境，有實際的雷鋒礦工在挖礦，只不過難度會比主網低很多，不過由於 Ropsten 採用與主網完全一樣的 PoW 共識，有時也就會和主網一樣擁堵，在這條鏈上做測試更容易測試出智能合約或者dapp里潛在的問題

用的是 PoA 機制，無需挖礦，所以出塊很快而且很穩定

和Rinkeby同樣使用的是 PoA 機制

打開這個網址 https://faucet.metamask.io/

點擊 request 1 ether from faucet 按鈕會通過web3連接錢包，獲取到錢包當前賬戶的以太坊地址，這個我使用的錢包是MetaMask，如果你沒有裝支持web3訪問的錢包，可以參考這篇文章安裝
https://www.jianshu.com/p/a84fe16f1af7

點擊連接

連接成功後底部會生成一筆交易，hash值

等交易確認後一個以太坊就到賬了

Rinkeby獲取測試幣相對麻煩些，需要注冊twitter賬號(需要翻牆)

打開這個網址 https://twitter.com/intent/tweet?text=Requesting%20faucet%20funds%20into%%20on%20the%20%23Rinkeby%20%23Ethereum%20test%20network

把推文中替換成你的地址點擊TWEET，發送成功後點擊分享圖標選擇Copy link to Tweet，把推文的鏈接復制下來

然後打開Rinkeby測試幣水龍頭網頁 https://www.rinkeby.io/#faucet

把剛才那個推文鏈接復制進輸入框，點擊Give me Ether

根據你的需要選擇要多少個代幣，要的越多到賬越慢😓，到賬時間相對其它的測試鏈很慢，如果著急就用別的鏈做測試

打開這個網址 https://faucet.kovan.network/ ，需要使用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

Ⅳ 交換機中eth0/0,是什麼意思

eth指的是乙太網，0/0指的是0號板卡的0號埠，也就是第一個版卡的第一個埠，總得說來eth0/0指的是那個埠的編號
你說的192.168.2.2指的是那個埠的IP地址，
埠也有地址，跟你主機一樣，他也需要一個地址。

Ⅵ 哈希值是什麼

哈希表類Hashtable

哈希表是一種重要的存儲方式，也是一種常見的檢索方法。其基本思想是將關系碼的值作為自變數，通過一定的函數關系計算出對應的函數值，把這個數值解釋為結點的存儲地址，將結點存入計算得到存儲地址所對應的存儲單元。檢索時採用檢索關鍵碼的方法。現在哈希表有一套完整的演算法來進行插入、刪除和解決沖突。在Java中哈希表用於存儲對象，實現快速檢索。
Java.util.Hashtable提供了種方法讓用戶使用哈希表，而不需要考慮其哈希表真正如何工作。
哈希表類中提供了三種構造方法，分別是：
public Hashtable()
public Hashtable(int initialcapacity)
public Hashtable(int initialCapacity,float loadFactor)
參數initialCapacity是Hashtable的初始容量，它的值應大於0。loadFactor又稱裝載因子，是一個0.0到1之間的float型的浮點數。它是一個百分比，表明了哈希表何時需要擴充，例如，有一哈希表，容量為100，而裝載因子為0.9，那麼當哈希表90%的容量已被使用時，此哈希表會自動擴充成一個更大的哈希表。如果用戶不賦這些參數，系統會自動進行處理，而不需要用戶操心。
Hashtable提供了基本的插入、檢索等方法。
■插入
public synchronized void put(Object key,Object value)
給對象value設定一關鍵字key,並將其加到Hashtable中。若此關鍵字已經存在，則將此關鍵字對應的舊對象更新為新的對象Value。這表明在哈希表中相同的關鍵字不可能對應不同的對象(從哈希表的基本思想來看，這也是顯而易見的)。
■檢索
public synchronized Object get(Object key)
根據給定關鍵字key獲取相對應的對象。
public synchronized boolean containsKey(Object key)
判斷哈希表中是否包含關鍵字key。
public synchronized boolean contains(Object value)
判斷value是否是哈希表中的一個元素。
■刪除
public synchronized object remove(object key)
從哈希表中刪除關鍵字key所對應的對象。
public synchronized void clear()
清除哈希表
另外，Hashtalbe還提供方法獲取相對應的枚舉集合：
public synchronized Enumeration keys()
返回關鍵字對應的枚舉對象。
public synchronized Enumeration elements()
返回元素對應的枚舉對象。
例1.5 Hashtable.java給出了使用Hashtable的例子。
例1.5 Hashtalbe.java。
//import java.lang.*;
import java.util.Hashtable;
import java.util.Enumeration;
public class HashApp{
public static void main(String args[]){
Hashtable hash=new Hashtable(2,(float)0.8);
//創建了一個哈希表的對象hash，初始容量為2，裝載因子為0.8

hash.put("Jiangsu","Nanjing");
//將字元串對象「Jiangsu」給定一關鍵字「Nanjing」,並將它加入hash
hash.put("Beijing","Beijing");
hash.put("Zhejiang","Hangzhou");

System.out.println("The hashtable hash1 is: "+hash);
System.out.println("The size of this hash table is "+hash.size());
//列印hash的內容和大小

Enumeration enum1=hash.elements();
System.out.print("The element of hash is: ");
while(enum1.hasMoreElements())
System.out.print(enum1.nextElement()+" ");
System.out.println();
//依次列印hash中的內容
if(hash.containsKey("Jiangsu"))
System.out.println("The capatial of Jiangsu is "+hash.get("Jiangsu"));
hash.remove("Beijing");
//刪除關鍵字Beijing對應對象
System.out.println("The hashtable hash2 is: "+hash);
System.out.println("The size of this hash table is "+hash.size());
}
}

運行結果：
The hashtable hash1 is: {Beijing=Beijing, Zhejiang=Hangzhou, Jiangsu=Nanjing}
The size of this hash table is 3
The element of hash is: Beijing Hangzhou Nanjing
The capatial of Jiangsu is Nanjing
The hashtable hash2 is: {Zhejiang=Hangzhou, Jiangsu=Nanjing}
The size of this hash table is 2

Hashtable是Dictionary(字典)類的子類。在字典類中就把關鍵字對應到數據值。字典類是一個抽象類。在java.util中還有一個類Properties，它是Hashtable的子類。用它可以進行與對象屬性相關的操作。

Ⅶ 倫敦硬分叉在即，六年前以太坊的創世地址們在幹嘛

撰文：潘致雄

北京時間 2015 年 7 月 30 日晚上 11 點 26 分， 以太坊 0 號 區塊 被正式挖出，該區塊中包含了 8893 筆創世交易 ，為 8893 個地址分配了以太坊網路中初始的 7200 多萬個 ETH 。

剛剛過完 「六歲生日」 的以太坊網路即將在本周迎來 倫敦硬分叉升級 ，此次升級中的 EIP-1559 是 以太坊誕生以來首次經濟模型修改 ，該提案的重要性不言而喻，但也引發了部分礦工和社區的巨大爭議。截止發文時，仍有 35% 的節點未升級支持倫敦硬分叉，不過無論如何，這一切都將在兩天後塵埃落定。

在這個對於以太坊頗具紀念意義的時刻，我們對那幾千個創世地址的特徵和資產持有情況做了些簡單的分析，也發現了一些有意思的結論。

有兩個比較直觀的維度可以參考這 8893 個地址目前持有 ETH 的情況，一個是這些地址總共持有的 ETH 和持有 ETH 數量的分布情況。

據鏈聞統計的數據，這 8893 個地址當前持有的 ETH 總量約為 309 萬 ETH ，相比六年前的 7200 萬 ETH 減少了 近 96% 。

但是如果以美元價值來看，這些地址資產價格提升的幅度很大。參考 CoinMarketCap 上 ETH 在 2015 年 8 月 7 日的開盤價格 2.83 美元，六年前 7200 萬 ETH 的總價值為 2 億美元；但是按照 ETH 目前的 2500 美元的價格計算，309 萬 ETH 的總價值超過 77 億美元，是六年前的近 40 倍，而在不久前以太坊創出 4300 美元 歷史 高點時，這一增幅更加可觀。

另一個維度是持有 ETH 數量的分布情況，特別是余額小於 0.01 ETH 的地址，很可能是被拋棄不用的地址。

經整理發現，目前有 5317 個創世地址 的余額小於 0.01，佔全部創世地址的約 60% 。如果擴大該標准為小於 1 ETH 的地址數量，則佔全部創世地址的約 82% （7248 個） 。

雖然這些地址已經將絕大多數的以太坊轉出，但這並不代表這些地址背後的用戶賣掉了以太坊，因為也很有可能只是轉移到了其他地址，或用戶是在對地址進行整理，不過這些情況無法從鏈上准確判斷。

在這批創世用戶中，仍有 8% 的地址幾乎未挪動手中的 ETH，特別是在這六年的時間里，以太坊的價格從最低不到 1 美元漲到了最高 4000 多美元，這些人的浮盈至少有了幾千倍。

從具體的規則來說，我們獲取了這些地址創世時的余額和當前的余額，如果差值介於 0.01 ETH 至-0.01 ETH 之間，則符合該標准，因為其中不少的地址收到過各種各樣的空投，或創建過智能合約，所以可能會增加或者減少一些 ETH。

所有符合該標準的地址數量為 723 個，更可怕的是，這些地址持有的 ETH 數量超過 200 萬 ETH ，占 8893 個地址當前 ETH 總持有量 （309 萬 ETH） 的 65%。這 200 萬個 ETH 目前的價值約 50 億美元。

在這 8893 個地址中，有一個地址的當前余額相比創世時減少了超過 1190 萬個 ETH，也就是該地址在創世階段的幾乎所有 ETH 都已轉出，只留下了零頭 （不到 10 ETH） 。

該地址 （0x5abfec2…56f9） 在創世時收到了 1190 萬個 ETH （也是創世時余額最大的地址） ，一周後該地址創建了一個智能合約地址 （0xde0B295…7BAe） 用以管理這 1190 萬個 ETH，目前該地址在 Etherscan 上被打上了 「Ethereum Foundation」 （以太坊基金會） 的賬戶標簽和 「EthDev」 （以太坊開發者） 的姓名標簽 （一個賬戶標簽下可能有多個姓名標簽） 。

所以從 EthDev 這個地址來看，目前的余額接近 40 萬 ETH，相比創世時的 1190 萬個 ETH 減少了 97% 的 ETH。不過和上面的情況一樣，其實持有的美元價值是增長了，從創世時的 3368 萬美元 （ETH 以 2.83 美元計） 增長至如今的 10 億美元 （ETH 以 2500 美元計） 。

藍色是 ETH 余額，黑色折線是持有 ETH 的美元總價值

另外在 8893 個地址中，有 40 多個地址 的余額相比創世時的余額還增長了，其中增長最多的一個地址增加了超過 3 萬個 ETH （現在價值 7500 萬美元） 。

該地址 （0xddbd2b9…121a） 在創世時獲得了 1 萬個 ETH，沒過幾天這位未知用戶就把 ETH 全部轉到了 Kraken，或許是在出售這些 ETH，或提供流動性。然後該地址又在 10 天後收到了一筆 8 萬多 ETH 的轉賬，後來又陸陸續續分批轉移出 （部分流向了交易所） ，剩下約 4 萬個 ETH。該地址自 2015 年 10 月以來，余額就再未變化過。

而該地址收到的 8 萬個 ETH，其實最終還是來自於上述的這個 EthDev 的。所以一個比較合理的猜測是，這位用戶 （機構） 除了參與創世之外，還和以太坊基金會有較深的關聯，或許是某個開發者、某個以太坊基金會的內部地址、某個早期投資機構等。

網路中對於該地址的信息極少，不過在 Etherscan 的 開發者文檔 中，使用了該地址作為演示，這也許並不是一個巧合。

Ⅷ bsc eth合約地址

官網：https://metamask.io/。
類型：瀏覽器、安卓Android、蘋果iOS支持主鏈：ETH支持瀏覽器：Chorme、火狐瀏覽器。先復制錢包地址，然後到下面的地址申請測試幣 。
目前來看，領空投時一般需要用到的填寫錢包地址有四個，ETH以太坊錢包地址、火幣生態鏈HECO錢包地址、幣安智能鏈BSC錢包地址，波場TRX錢包地址，這四個是常見的，其它不常用的就不介紹了，獲取和創建方法都跟這四個差不多一樣。創建任何虛擬貨幣錢包，都要備份好助記詞、秘鑰，否則錢包丟了資產就無法恢復！！！先介紹一下BSC和HECO1幣安智能鏈 - BSC，全稱Binance Smart Chain，它的錢包地址格式雖然跟ETH以太坊地址格式一樣，都是0x??開頭，但一般情況下是不能直接使用ETH錢包地址的，否則有可能會接收不到幣。