㈠ 區塊鏈里的加密是什麼意思(區塊鏈加密演算法是什麼)
區塊鏈中的對稱加密是什麼?非對稱加密又是什麼?對稱加密演算法是指在加密和解密時使用的是同一個秘鑰。與對稱加密演算法不同,非對稱加密演算法需要公鑰和私鑰。公鑰和私鑰是一對,如果用公鑰對數據進行加密,只有用對應的私鑰才能解密。
非對稱加密與對稱加密相比,其安全性更好。對稱加密的通信雙方使用相同的秘鑰,如果一方的秘鑰遭泄露,那麼整個通信就會被破解。
而非對稱加密使用一對秘鑰,一個用來加密,一個用來解密,而且公鑰是公開的,秘鑰是自己保存的,在通訊前不需要先同步秘鑰,避免了在同步私鑰過程中被黑客盜取信息的風險。
【深度知識】區塊鏈之加密原理圖示(加密,簽名)先放一張以太坊的架構圖:
在學習的過程中主要是採用單個模塊了學習了解的,包括P2P,密碼學,網路,協議等。直接開始總結:
秘鑰分配問題也就是秘鑰的傳輸問題,如果對稱秘鑰,那麼只能在線下進行秘鑰的交換。如果在線上傳輸秘鑰,那就有可能被攔截。所以採用非對稱加密,兩把鑰匙,一把私鑰自留,一把公鑰公開。公鑰可以在網上傳輸。不用線下交易。保證數據的安全性。
如上圖,A節點發送數據到B節點,此時採用公鑰加密。A節點從自己的公鑰中獲取到B節點的公鑰對明文數據加密,得到密文發送給B節點。而B節點採用自己的私鑰解密。
2、無法解決消息篡改。
如上圖,A節點採用B的公鑰進行加密,然後將密文傳輸給B節點。B節點拿A節點的公鑰將密文解密。
1、由於A的公鑰是公開的,一旦網上黑客攔截消息,密文形同虛設。說白了,這種加密方式,只要攔截消息,就都能解開。
2、同樣存在無法確定消息來源的問題,和消息篡改的問題。
如上圖,A節點在發送數據前,先用B的公鑰加密,得到密文1,再用A的私鑰對密文1加密得到密文2。而B節點得到密文後,先用A的公鑰解密,得到密文1,之後用B的私鑰解密得到明文。
1、當網路上攔截到數據密文2時,由於A的公鑰是公開的,故可以用A的公鑰對密文2解密,就得到了密文1。所以這樣看起來是雙重加密,其實最後一層的私鑰簽名是無效的。一般來講,我們都希望簽名是簽在最原始的數據上。如果簽名放在後面,由於公鑰是公開的,簽名就缺乏安全性。
2、存在性能問題,非對稱加密本身效率就很低下,還進行了兩次加密過程。
如上圖,A節點先用A的私鑰加密,之後用B的公鑰加密。B節點收到消息後,先採用B的私鑰解密,然後再利用A的公鑰解密。
1、當密文數據2被黑客攔截後,由於密文2隻能採用B的私鑰解密,而B的私鑰只有B節點有,其他人無法機密。故安全性最高。
2、當B節點解密得到密文1後,只能採用A的公鑰來解密。而只有經過A的私鑰加密的數據才能用A的公鑰解密成功,A的私鑰只有A節點有,所以可以確定數據是由A節點傳輸過來的。
經兩次非對稱加密,性能問題比較嚴重。
基於以上篡改數據的問題,我們引入了消息認證。經過消息認證後的加密流程如下:
當A節點發送消息前,先對明文數據做一次散列計算。得到一個摘要,之後將照耀與原始數據同時發送給B節點。當B節點接收到消息後,對消息解密。解析出其中的散列摘要和原始數據,然後再對原始數據進行一次同樣的散列計算得到摘要1,比較摘要與摘要1。如果相同則未被篡改,如果不同則表示已經被篡改。
在傳輸過程中,密文2隻要被篡改,最後導致的hash與hash1就會產生不同。
無法解決簽名問題,也就是雙方相互攻擊。A對於自己發送的消息始終不承認。比如A對B發送了一條錯誤消息,導致B有損失。但A抵賴不是自己發送的。
在(三)的過程中,沒有辦法解決交互雙方相互攻擊。什麼意思呢?有可能是因為A發送的消息,對A節點不利,後來A就抵賴這消息不是它發送的。
為了解決這個問題,故引入了簽名。這里我們將(二)-4中的加密方式,與消息簽名合並設計在一起。
在上圖中,我們利用A節點的私鑰對其發送的摘要信息進行簽名,然後將簽名+原文,再利用B的公鑰進行加密。而B得到密文後,先用B的私鑰解密,然後對摘要再用A的公鑰解密,只有比較兩次摘要的內容是否相同。這既避免了防篡改問題,有規避了雙方攻擊問題。因為A對信息進行了簽名,故是無法抵賴的。
為了解決非對稱加密數據時的性能問題,故往往採用混合加密。這里就需要引入對稱加密,如下圖:
在對數據加密時,我們採用了雙方共享的對稱秘鑰來加密。而對稱秘鑰盡量不要在網路上傳輸,以免丟失。這里的共享對稱秘鑰是根據自己的私鑰和對方的公鑰計算出的,然後適用對稱秘鑰對數據加密。而對方接收到數據時,也計算出對稱秘鑰然後對密文解密。
以上這種對稱秘鑰是不安全的,因為A的私鑰和B的公鑰一般短期內固定,所以共享對稱秘鑰也是固定不變的。為了增強安全性,最好的方式是每次交互都生成一個臨時的共享對稱秘鑰。那麼如何才能在每次交互過程中生成一個隨機的對稱秘鑰,且不需要傳輸呢?
那麼如何生成隨機的共享秘鑰進行加密呢?
對於發送方A節點,在每次發送時,都生成一個臨時非對稱秘鑰對,然後根據B節點的公鑰和臨時的非對稱私鑰可以計算出一個對稱秘鑰(KA演算法-KeyAgreement)。然後利用該對稱秘鑰對數據進行加密,針對共享秘鑰這里的流程如下:
對於B節點,當接收到傳輸過來的數據時,解析出其中A節點的隨機公鑰,之後利用A節點的隨機公鑰與B節點自身的私鑰計算出對稱秘鑰(KA演算法)。之後利用對稱秘鑰機密數據。
對於以上加密方式,其實仍然存在很多問題,比如如何避免重放攻擊(在消息中加入Nonce),再比如彩虹表(參考KDF機制解決)之類的問題。由於時間及能力有限,故暫時忽略。
那麼究竟應該採用何種加密呢?
主要還是基於要傳輸的數據的安全等級來考量。不重要的數據其實做好認證和簽名就可以,但是很重要的數據就需要採用安全等級比較高的加密方案了。
密碼套件是一個網路協議的概念。其中主要包括身份認證、加密、消息認證(MAC)、秘鑰交換的演算法組成。
在整個網路的傳輸過程中,根據密碼套件主要分如下幾大類演算法:
秘鑰交換演算法:比如ECDHE、RSA。主要用於客戶端和服務端握手時如何進行身份驗證。
消息認證演算法:比如SHA1、SHA2、SHA3。主要用於消息摘要。
批量加密演算法:比如AES,主要用於加密信息流。
偽隨機數演算法:例如TLS1.2的偽隨機函數使用MAC演算法的散列函數來創建一個主密鑰——連接雙方共享的一個48位元組的私鑰。主密鑰在創建會話密鑰(例如創建MAC)時作為一個熵來源。
在網路中,一次消息的傳輸一般需要在如下4個階段分別進行加密,才能保證消息安全、可靠的傳輸。
握手/網路協商階段:
在雙方進行握手階段,需要進行鏈接的協商。主要的加密演算法包括RSA、DH、ECDH等
身份認證階段:
身份認證階段,需要確定發送的消息的來源來源。主要採用的加密方式包括RSA、DSA、ECDSA(ECC加密,DSA簽名)等。
消息加密階段:
消息加密指對發送的信息流進行加密。主要採用的加密方式包括DES、RC4、AES等。
消息身份認證階段/防篡改階段:
主要是保證消息在傳輸過程中確保沒有被篡改過。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。
ECC:EllipticCurvesCryptography,橢圓曲線密碼編碼學。是一種根據橢圓上點倍積生成公鑰、私鑰的演算法。用於生成公私秘鑰。
ECDSA:用於數字簽名,是一種數字簽名演算法。一種有效的數字簽名使接收者有理由相信消息是由已知的發送者創建的,從而發送者不能否認已經發送了消息(身份驗證和不可否認),並且消息在運輸過程中沒有改變。ECDSA簽名演算法是ECC與DSA的結合,整個簽名過程與DSA類似,所不一樣的是簽名中採取的演算法為ECC,最後簽名出來的值也是分為r,s。主要用於身份認證階段。
ECDH:也是基於ECC演算法的霍夫曼樹秘鑰,通過ECDH,雙方可以在不共享任何秘密的前提下協商出一個共享秘密,並且是這種共享秘鑰是為當前的通信暫時性的隨機生成的,通信一旦中斷秘鑰就消失。主要用於握手磋商階段。
ECIES:是一種集成加密方案,也可稱為一種混合加密方案,它提供了對所選擇的明文和選擇的密碼文本攻擊的語義安全性。ECIES可以使用不同類型的函數:秘鑰協商函數(KA),秘鑰推導函數(KDF),對稱加密方案(ENC),哈希函數(HASH),H-MAC函數(MAC)。
ECC是橢圓加密演算法,主要講述了按照公私鑰怎麼在橢圓上產生,並且不可逆。ECDSA則主要是採用ECC演算法怎麼來做簽名,ECDH則是採用ECC演算法怎麼生成對稱秘鑰。以上三者都是對ECC加密演算法的應用。而現實場景中,我們往往會採用混合加密(對稱加密,非對稱加密結合使用,簽名技術等一起使用)。ECIES就是底層利用ECC演算法提供的一套集成(混合)加密方案。其中包括了非對稱加密,對稱加密和簽名的功能。
metacharset="utf-8"
這個先訂條件是為了保證曲線不包含奇點。
所以,隨著曲線參數a和b的不斷變化,曲線也呈現出了不同的形狀。比如:
所有的非對稱加密的基本原理基本都是基於一個公式K=kG。其中K代表公鑰,k代表私鑰,G代表某一個選取的基點。非對稱加密的演算法就是要保證該公式不可進行逆運算(也就是說G/K是無法計算的)。*
ECC是如何計算出公私鑰呢?這里我按照我自己的理解來描述。
我理解,ECC的核心思想就是:選擇曲線上的一個基點G,之後隨機在ECC曲線上取一個點k(作為私鑰),然後根據kG計算出我們的公鑰K。並且保證公鑰K也要在曲線上。*
那麼kG怎麼計算呢?如何計算kG才能保證最後的結果不可逆呢?這就是ECC演算法要解決的。
首先,我們先隨便選擇一條ECC曲線,a=-3,b=7得到如下曲線:
在這個曲線上,我隨機選取兩個點,這兩個點的乘法怎麼算呢?我們可以簡化下問題,乘法是都可以用加法表示的,比如22=2+2,35=5+5+5。那麼我們只要能在曲線上計算出加法,理論上就能算乘法。所以,只要能在這個曲線上進行加法計算,理論上就可以來計算乘法,理論上也就可以計算k*G這種表達式的值。
曲線上兩點的加法又怎麼算呢?這里ECC為了保證不可逆性,在曲線上自定義了加法體系。
現實中,1+1=2,2+2=4,但在ECC演算法里,我們理解的這種加法體系是不可能。故需要自定義一套適用於該曲線的加法體系。
ECC定義,在圖形中隨機找一條直線,與ECC曲線相交於三個點(也有可能是兩個點),這三點分別是P、Q、R。
那麼P+Q+R=0。其中0不是坐標軸上的0點,而是ECC中的無窮遠點。也就是說定義了無窮遠點為0點。
同樣,我們就能得出P+Q=-R。由於R與-R是關於X軸對稱的,所以我們就能在曲線上找到其坐標。
P+R+Q=0,故P+R=-Q,如上圖。
以上就描述了ECC曲線的世界裡是如何進行加法運算的。
從上圖可看出,直線與曲線只有兩個交點,也就是說直線是曲線的切線。此時P,R重合了。
也就是P=R,根據上述ECC的加法體系,P+R+Q=0,就可以得出P+R+Q=2P+Q=2R+Q=0
於是乎得到2P=-Q(是不是與我們非對稱演算法的公式K=kG越來越近了)。
於是我們得出一個結論,可以算乘法,不過只有在切點的時候才能算乘法,而且只能算2的乘法。
假若2可以變成任意個數進行想乘,那麼就能代表在ECC曲線里可以進行乘法運算,那麼ECC演算法就能滿足非對稱加密演算法的要求了。
那麼我們是不是可以隨機任何一個數的乘法都可以算呢?答案是肯定的。也就是點倍積計算方式。
選一個隨機數k,那麼k*P等於多少呢?
我們知道在計算機的世界裡,所有的都是二進制的,ECC既然能算2的乘法,那麼我們可以將隨機數k描述成二進制然後計算。假若k=151=10010111
由於2P=-Q所以這樣就計算出了kP。這就是點倍積演算法。所以在ECC的曲線體系下是可以來計算乘法,那麼以為這非對稱加密的方式是可行的。
至於為什麼這樣計算是不可逆的。這需要大量的推演,我也不了解。但是我覺得可以這樣理解:
我們的手錶上,一般都有時間刻度。現在如果把1990年01月01日0點0分0秒作為起始點,如果告訴你至起始點為止時間流逝了整1年,那麼我們是可以計算出現在的時間的,也就是能在手錶上將時分秒指針應該指向00:00:00。但是反過來,我說現在手錶上的時分秒指針指向了00:00:00,你能告訴我至起始點算過了有幾年了么?
ECDSA簽名演算法和其他DSA、RSA基本相似,都是採用私鑰簽名,公鑰驗證。只不過演算法體系採用的是ECC的演算法。交互的雙方要採用同一套參數體系。簽名原理如下:
在曲線上選取一個無窮遠點為基點G=(x,y)。隨機在曲線上取一點k作為私鑰,K=k*G計算出公鑰。
簽名過程:
生成隨機數R,計算出RG.
根據隨機數R,消息M的HASH值H,以及私鑰k,計算出簽名S=(H+kx)/R.
將消息M,RG,S發送給接收方。
簽名驗證過程:
接收到消息M,RG,S
根據消息計算出HASH值H
根據發送方的公鑰K,計算HG/S+xK/S,將計算的結果與RG比較。如果相等則驗證成功。
公式推論:
HG/S+xK/S=HG/S+x(kG)/S=(H+xk)/GS=RG
在介紹原理前,說明一下ECC是滿足結合律和交換律的,也就是說A+B+C=A+C+B=(A+C)+B。
這里舉一個WIKI上的例子說明如何生成共享秘鑰,也可以參考AliceAndBob的例子。
Alice與Bob要進行通信,雙方前提都是基於同一參數體系的ECC生成的公鑰和私鑰。所以有ECC有共同的基點G。
生成秘鑰階段:
Alice採用公鑰演算法KA=ka*G,生成了公鑰KA和私鑰ka,並公開公鑰KA。
Bob採用公鑰演算法KB=kb*G,生成了公鑰KB和私鑰kb,並公開公鑰KB。
計算ECDH階段:
Alice利用計算公式Q=ka*KB計算出一個秘鑰Q。
Bob利用計算公式Q'=kb*KA計算出一個秘鑰Q'。
共享秘鑰驗證:
Q=kaKB=ka*kb*G=ka*G*kb=KA*kb=kb*KA=Q'
故雙方分別計算出的共享秘鑰不需要進行公開就可採用Q進行加密。我們將Q稱為共享秘鑰。
在以太坊中,採用的ECIEC的加密套件中的其他內容:
1、其中HASH演算法採用的是最安全的SHA3演算法Keccak。
2、簽名演算法採用的是ECDSA
3、認證方式採用的是H-MAC
4、ECC的參數體系採用了secp256k1,其他參數體系參考這里
H-MAC全程叫做Hash-.其模型如下:
在以太坊的UDP通信時(RPC通信加密方式不同),則採用了以上的實現方式,並擴展化了。
首先,以太坊的UDP通信的結構如下:
其中,sig是經過私鑰加密的簽名信息。mac是可以理解為整個消息的摘要,ptype是消息的事件類型,data則是經過RLP編碼後的傳輸數據。
其UDP的整個的加密,認證,簽名模型如下:
區塊鏈的加密技術數字加密技能是區塊鏈技能使用和開展的關鍵。一旦加密辦法被破解,區塊鏈的數據安全性將受到挑戰,區塊鏈的可篡改性將不復存在。加密演算法分為對稱加密演算法和非對稱加密演算法。區塊鏈首要使用非對稱加密演算法。非對稱加密演算法中的公鑰暗碼體制依據其所依據的問題一般分為三類:大整數分化問題、離散對數問題和橢圓曲線問題。第一,引進區塊鏈加密技能加密演算法一般分為對稱加密和非對稱加密。非對稱加密是指集成到區塊鏈中以滿意安全要求和所有權驗證要求的加密技能。非對稱加密通常在加密和解密進程中使用兩個非對稱暗碼,稱為公鑰和私鑰。非對稱密鑰對有兩個特點:一是其間一個密鑰(公鑰或私鑰)加密信息後,只能解密另一個對應的密鑰。第二,公鑰可以向別人揭露,而私鑰是保密的,別人無法通過公鑰計算出相應的私鑰。非對稱加密一般分為三種首要類型:大整數分化問題、離散對數問題和橢圓曲線問題。大整數分化的問題類是指用兩個大素數的乘積作為加密數。由於素數的出現是沒有規律的,所以只能通過不斷的試算來尋找解決辦法。離散對數問題類是指基於離散對數的困難性和強單向哈希函數的一種非對稱分布式加密演算法。橢圓曲線是指使用平面橢圓曲線來計算一組非對稱的特殊值,比特幣就採用了這種加密演算法。非對稱加密技能在區塊鏈的使用場景首要包含信息加密、數字簽名和登錄認證。(1)在信息加密場景中,發送方(記為A)用接收方(記為B)的公鑰對信息進行加密後發送給
B,B用自己的私鑰對信息進行解密。比特幣交易的加密就屬於這種場景。(2)在數字簽名場景中,發送方A用自己的私鑰對信息進行加密並發送給B,B用A的公鑰對信息進行解密,然後確保信息是由A發送的。(3)登錄認證場景下,客戶端用私鑰加密登錄信息並發送給伺服器,伺服器再用客戶端的公鑰解密認證登錄信息。請注意上述三種加密計劃之間的差異:信息加密是公鑰加密和私鑰解密,確保信息的安全性;數字簽名是私鑰加密,公鑰解密,確保了數字簽名的歸屬。認證私鑰加密,公鑰解密。以比特幣體系為例,其非對稱加密機制如圖1所示:比特幣體系一般通過調用操作體系底層的隨機數生成器生成一個256位的隨機數作為私鑰。比特幣的私鑰總量大,遍歷所有私鑰空間獲取比特幣的私鑰極其困難,所以暗碼學是安全的。為便於辨認,256位二進制比特幣私鑰將通過SHA256哈希演算法和Base58進行轉化,構成50個字元長的私鑰,便於用戶辨認和書寫。比特幣的公鑰是私鑰通過Secp256k1橢圓曲線演算法生成的65位元組隨機數。公鑰可用於生成比特幣交易中使用的地址。生成進程是公鑰先通過SHA256和RIPEMD160哈希處理,生成20位元組的摘要成果(即Hash160的成果),再通過SHA256哈希演算法和Base58轉化,構成33個字元的比特幣地址。公鑰生成進程是不可逆的,即私鑰不能從公鑰推導出來。比特幣的公鑰和私鑰通常存儲在比特幣錢包文件中,其間私鑰最為重要。丟掉私鑰意味著丟掉相應地址的所有比特幣財物。在現有的比特幣和區塊鏈體系中,現已依據實踐使用需求衍生出多私鑰加密技能,以滿意多重簽名等愈加靈敏雜亂的場景。
㈡ metamask使用哪個以太坊節點
metamask使用rpcurl以太坊節點。根據查詢相關的公開信息,當用戶連接到自定義MetaMask網路時,MetaMask將與RPCURL中的以太坊節點通信,並使用它發送交易、從區塊鏈讀取數據以及與智能合約交互。
㈢ 以太坊如何使用web3.js或者rpc介面獲取交易數據交易時間與確認數
對於主網交易記錄的查詢,許多開發者會選擇使用Etherscan,然而在面對自建私鏈時,這一選項不再適用。那麼如何獲取私鏈上的交易數據呢?一種常見的方法是監聽鏈上的日誌,然後將這些日誌存入資料庫,通過資料庫進行查詢。例如,你可以編寫如下代碼:
首先定義一個地址,比如:var addr = "";
接著使用web3庫的eth.filter方法來監聽特定地址上的交易,這一步操作的代碼如下:var filter = web3.eth.filter({fromBlock: 0, toBlock: 'latest', address: addr});
監聽完成後,使用filter.get方法獲取所有交易,遍歷這些交易,通過web3.eth.getTransaction方法獲取具體的交易信息。例如:transactions.forEach(function(tx){ var txInfo = web3.eth.getTransaction(tx.transactionHash); // 將交易信息存入資料庫 })
在這里,web3.eth.filter()用於監聽鏈上的交易日誌,web3.eth.getTransaction()則用於提取特定交易的詳細信息。一旦獲取到交易信息,就可以將其存儲到資料庫中,為後續查詢提供支持。
除了上述方法外,還有其他方式可以實現這一目標,比如使用RPC介面。RPC介面提供了更多功能,包括查詢賬戶余額、調用智能合約等,而不僅僅是監聽交易。例如,你可以使用web3.eth.sendTransaction方法來發送交易,或使用web3.eth.getBalance方法來獲取賬戶余額。
總之,無論是監聽日誌還是使用RPC介面,都是獲取私鏈交易數據的有效方法。選擇哪種方式取決於你的具體需求和場景。當然,如果你想進一步深入學習以太坊技術,我推薦你參考一些實戰教程,例如:以太坊教程。
㈣ Infura API 獲取以太坊當前配置鏈 ID - 區塊鏈數據開發實戰
簡介:Infura 是以太坊和 IPFS 的 API 服務提供商。Infura 一開始只是為 ConsenSys 內部項目提供穩定可靠的 RPC 訪問,後來隨著以太坊生態發展,他們意識到自己可以起到更大作用,於是開始面向開發者提供公共 API 服務。本文整理使用 Infura API 獲取以太坊當前配置鏈 ID 的實現。
Infura 是以太坊和 IPFS 的 API 服務提供商。Infura 一開始只是為 ConsenSys 內部項目提供穩定可靠的 RPC 訪問,後來隨著以太坊生態發展,他們意識到自己可以起到更大作用,於是開始面向開發者提供公共 API 服務。
本文整理使用 Infura API 獲取以太坊當前配置鏈 ID 的實現。
Infura API 官方文檔: https://infura.io/docs
使用 API 需要申請 Project ID ,ID 是免費申請的,申請流程為「注冊 - 登錄 - 創建新項目」,不需要審核,幾分鍾就能搞定。
Infura API 標准請求埠格式:
本例中我們使用基於 HTTP 的以太坊主網 JSON-RPC 埠:
Infura API 獲取以太坊當前配置鏈 ID:
Curl 示例:
Node.js 示例:
返回的 JSON 示例:
返回當前鏈 ID 的大整數。
Infura API 服務思維導圖:
我們有一個區塊鏈知識星球,做區塊鏈前沿資料的歸納整理以方便大家檢索查詢使用,也是國內頂尖區塊鏈技術社區,歡迎感興趣的朋友加入。如果你對上面內容有疑問,也可以加入知識星球提問我:
㈤ Foundry的基本使用總結
本文列舉了 foundry 中常用的命令,方便後續查閱。使用 foundry 的工具主要涉及三大組件,分別對應不同的功能,接下來將詳細介紹每個組件的使用方法和應用場景。
在使用 foundry 之前,需要先安裝。可以通過訪問 foundry 的官方網址 getfoundry.sh 進行安裝。對於 mac 系統用戶,可以使用以下命令進行安裝:
foundry
foundry 工具包含三大組件,分別是 cast、anvil 和 forge。
**cast 使用**
cast 是用於執行以太坊 RPC 調用的命令行工具。它支持智能合約調用、發送交易和檢索鏈數據等操作。cast 與 web3 的交互十分便捷,即使是非代碼開發者也能輕松使用進行鏈上數據查詢。
使用示例:
cast rpc eth_blockNumber --rpc-url=$ETH_RPC_URL
cast 支持環境變數 ETH_RPC_URL,讀取時無需在命令中體現,只需設置該變數即可。
**cast 查詢功能**
- **區塊高度**:使用 `cast rpc eth_blockNumber` 查詢。
- **區塊信息**:使用 `cast block` 查詢。
- **交易信息**:使用 `cast tx` 查詢。
- **交易回執查詢**:使用 `cast receipt` 查詢。
**使用 jq 進行數據處理**
`jq` 是一個靈活的輕量級命令行 JSON 處理器,用於處理 JSON 輸入並生成 JSON 輸出。可應用於處理 cast 查詢結果。
**交易模擬**
`cast run` 命令可用於模擬交易,以進行測試或研究特定交易場景。
**錢包相關功能**
`cast wallet new` 可創建新錢包,通過 `cast wallet sign` 進行簽名操作。此外,`cast resolve-name` 和 `cast lookup-address` 功能用於 ENS 查詢。
**合約相關功能**
在使用查看源代碼功能前,需設置 `ETHERSCAN_API_KEY` 環境變數。`cast etherscan-source` 可用於查看合約源代碼,通過 `-d` 參數保存結果。調用合約函數則使用 `cast call`。
查詢合約存儲位置的 `cast index` 命令可根據類型、鍵和槽位編號計算存儲位置。
**anvil 使用**
`anvil` 提供了模擬從主網 fork 的功能,通過 `casat —fork-url=$ETH_RPC_URL` 實現。常用命令參數包括 `—accounts`、`—balance` 和 `—fork-block-number`。
**forge-智能合約開發框架**
`forge init` 命令初始化項目,`forge build` 編譯代碼,`forge test` 進行自動化測試。日誌列印可通過 `emit log` 或 `console2.log` 實現,確保在使用 `forge test` 時使用 `—vvv` 參數以顯示列印內容。
`cheatcode` 功能允許在測試合約中通過 `vm` 修改虛擬機狀態,如 `vm.warp` 修改時間戳、`vm.startPrank` 和 `vm.stopPrank` 修改發件人、`vm.deal` 修改余額等。
`forge snapshot` 功能允許在每個測試用例的 gas 使用上創建快照,有助於優化 gas 費用。
**代碼示例**
### 修改 ERC20 代幣余額
在進行 ERC20 代幣余額修改時,可以使用 `vm.deal` 函數。如果在測試環境中未部署 ERC20 合約,可通過 fork-url 直接使用主網的 ERC20 合約。
### fork-url 在代碼中的實現
在代碼中實現 fork-url 可以通過 `vm.envAddress` 函數讀取 vm 中的環境變數地址,進而實現針對不同測試網路的靈活測試用例編寫。
本文詳細介紹了 foundry 的基本使用方法,旨在為開發者提供便捷的工具鏈,提高智能合約開發和測試的效率。通過上述指南,開發者能夠更加熟練地掌握 foundry 的核心功能,為區塊鏈項目開發提供有力支持。
㈥ 簡述以太坊P2P網路之UDP
個人認為以太坊是區塊鏈項目中帶來技術重新認識和學習的不錯的項目,特別是在P2P網路這一塊。本文將介紹P2P網路中負責節點之間的通信連接和服務發現,本文的內容主要是對代碼層級的理解,可能存在對其理解的錯誤,歡迎指點。包括以下兩個方面:
種子節點初始化,節點發現
節點連接及相互通信
pending一種延遲處理邏輯,提供一個回調機制當某一個操作發起非同步請求時,就使用pending結構封裝一個閉包,當收到非同步回復後從pending列表取出這個閉包,執行回調,因此在這個回調里可以完成數據包校驗等後處理,如findnode操作將更新k桶的操作暫存,再獲取到非同步回復後執行這個閉包完成k桶更新
提供多個回復接收功能,一個RPC請求可能會對應多個回復包,比如findnode對應多個neigbours回復包,此時可以提供多個pending進行逐個包校驗
種子節點初始化及節點發現這部分的邏輯的實現主要在p2p/discover/table.go中,在udp中newUDP方法調用newTable開始種子節點及節點的發現。
newTable:執行該函數會傳入Bootnodes信息,配置信息在params/bootnodes.go中,為初始連接節點,服務啟動後就從這些節點開始進行節點的發現和擴散。關鍵執行方法
tab.doRefresh:創建goroutine刷新所有節點(30分鍾),並進行連接
tab.lookup:查找距離自己最近的節點
tab.closest:獲取距離target最近的16個節點
tab.findnode:向最近的節點發起findnode請求,並增加處理neighborsPacket閉包的pending,具體實現為udp.go中的findnode,對於超過24小時沒有接收到ping包的節點重新發送ping;對端節點接收到findnode請求後,查找附近的16個節點,並發送neighborsPacket
tab.setFallbackNodes:驗證bootnodes信息,將節點信息賦值給tab.nursery
tab.seedRand:設置隨機seed
tab.loadSeedNodes:將bootnodes加入路由表
tab.loop:創建goroutine發現節點並進行連接
--
findnode-neighbors 時序圖
由於UDP有最大報文數限制,所以能夠發送的鄰近節點數目是有限的,需要拆包發送
節點連接及相互通信P2P服務的啟動位於p2p/server.go 中的Start()。
建立一個UDP連接服務discover.ListenUDP這個方法的關鍵實現是初始化三個通道,2個goroutine 。
三個通道
closing:關閉udp
gotreply:消息回復
addpending:pending消息處理
2個 goroutine
t.handlePacket:執行decodePacket對數據包進行解碼,然後調用相應數據包的handle方法
t.addpending:接收並增加一個閉包
t.gotreply:接收回復遍歷,執行callback通知errC通道
udp.loop():主要監聽t.gotreply和t.addpending
udp.readLoop():讀取UDP數據包,執行t.handlePacket進行數據包處理
網路傳輸四種數據包數據包類型
const(pingPacket=iota+1//zerois'reserved')數據包結構
ping-pong 時序圖
總結區塊鏈技術是一個不錯的技術,以太坊讓我們重新理解了網路的應用。本文簡單介紹了P2P網路的UDP協議這一塊,實際上網路及節點的發現是有一整套演算法,經典的有 Kademlia 網路,這里不做介紹。
㈦ 區塊鏈id是指什麼,區塊鏈lp是什麼
以太坊的ChainId與NetworkIdChainId是EIP-155引入的一個用來區分不同EVM鏈的一個標識。如下圖所示,主要作用就是避免一個交易在簽名之後被重復在不同的鏈上提交。最開始主要是為了防止以太坊交易在以太經典網路上重放或者以太經典交易在以太坊網路上重放。在以太坊網路上是從2675000這個區塊通過SpuriousDragon這個硬分叉升級激活。
引入ChainId後,帶來了哪些影響呢?
NetworkId主要用來在網路層標識當前的區塊鏈網路。NetworkId不一致的兩個節點無法建立連接。
NetworkId無法通過配置文件指定,智能通過參數--networkid來指定。所以我們啟動自己私鏈節點上需要記得加上這個參數。如果不加這個參數也不指定網路類型,默認NetworkId的值和以太坊主網一致。
不是。
這個根據上面的介紹可以很明顯的看出,兩者並沒有非常高的關聯度。
網上幾乎所有提到搭建以太坊私鏈的文章,都要強調NetworkId需要和genesis文件里ChainId的值相同。事實上是沒必要的。
就像下面這張圖展示的這樣,很多已經在主網運行的EVM鏈,它們的ChainId和NetworkId並不相同。比如以太經典,它的ChainId是61,但NetworkId和以太坊主網一樣都是1。
之所以很多文章強調ChainId和NetworkId要保持一致,可能因為在某一段時間內,一些開發工具比如MetaMask,會把NetworkId當作ChainId來用。不過現在MetaMask已經支持自定義ChainId,以太坊也添加了「eth_chainId」這個RPCAPI,相信兩者誤用的情況會越來越少。
區塊鏈交易id在哪查
這里我們用以太坊區塊鏈的錢包作為例子,小狐狸是加密錢包,以及進入區塊鏈APP的出入口。進入之後獲取錢包地址,再使用以太坊區塊鏈的搜索器進入Etherscan官網首頁後,就可以獲取到以下區塊鏈交易id信息:
1.最新產生的區塊
2.最新發生的交易
拓展資料:
區塊鏈的交易過程看似神秘繁瑣,其實真正說起來卻也不見得有那麼難。
第一步:所有者A利用他的私鑰對前一次交易(比特貨來源)和下一位所有者B簽署一個數字簽名,並將這個簽名附加在這枚貨幣的末尾,製作出交易單。此時,B是以公鑰作為接收方地址。
第二步:A將交易單廣播至全網,比特幣就發送給了B,每個節點都將收到交易信息納入一個區塊中
此時,對B而言,該枚比特幣會即時顯示在比特幣錢包中,但直到區塊確認成功後才可以使用。目前一筆比特幣從支付到最終確認成功,得到6個區塊確認之後才能真正的確認到賬。
第三步:每個節點通過解一道數學難題,從而去獲得創建新區塊的權利,並爭取得到比特幣的獎勵(新比特幣會在此過程中產生)
此時節點反復嘗試尋找一個數值,使得將該數值、區塊鏈中最後一個區塊的Hash值以及交易單三部分送入SHA256演算法後能計算出散列值X(256位)滿足一定條件(比如前20位均為0),即找到數學難題的解。
第四步:當一個節點找到解時,它就向全國廣播該區塊記錄的所有蓋時間戳交易,並由全網其他節點核對。
此時時間戳用來證實特定區塊必然於某特定時間是的確存在的。比特幣網路採用從5個以上節點獲取時間,然後取中間值的方式成為時間戳。
第五步:全網其他節點核對該區塊記賬的正確性,沒有錯誤後他們將在該合法區塊之後競爭下一個區塊,這樣就形成了一個合法記賬區塊鏈。
時間條約鏈區塊身份ID是什麼東西?有什麼用?1.區塊身份是用戶在TTC生態社區中的通行證,與區塊身份ID綁定。
區塊身份ID相當於騰訊產品生態內的QQ號。區塊身份ID與QQ號不同的地方有:
a.用戶的個人數據會存儲在各自的區塊地址中,用戶可以通過區塊身份ID登陸進行管理。b.區塊身份ID是基於區塊鏈技術研發的,具備區塊鏈的去中心化、分布式記賬、匿名、安全、可控等特點。
2.區塊身份ID是TTC生態社區的通行證,可以用來一鍵登錄TTC生態內的所有應用,包括後續上線的各種Dapp,無需重復注冊,收付款更便捷,現在注冊更有六位數靚號可以獲得。
區塊鏈ido是什麼意思IDO(是InitialDigitalassetsOffering縮寫),首次區塊鏈數字資產的發行、源自股票市場的首次公開發行(IPO)概念,是企業區塊鏈項目首次以資產數字化產生出來的區塊鏈數字資產,以產品錨定資產債券、眾籌方式募集的通用數字資產的行為。
一、首次公開募股(InitialPublicOffering)是指一家企業第一次將它的股份向公眾出售通常,上市公司的股份是根據相應證監會出具的招股書或登記聲明中約定的條款通過經紀商或做市商進行銷售。一般來說,一旦首次公開上市完成後,這家公司就可以申請到證券交易所或報價系統掛牌交易。?有限責任公司在申請IPO之前,應先變更為股份有限公司。
二、就估值模型而言,不同的行業屬性、成長性、財務特性決定了上市公司適用不同的估值模型。較為常用的估值方式可以分為兩大類:收益折現法與類比法。所謂收益折現法,就是通過合理的方式估計出上市公司未來的經營狀況,並選擇恰當的貼現率與貼現模型,計算出上市公司價值,如最常用的股利折現模型(DDM)、現金流貼現(DCF)模型等。貼現模型並不復雜,關鍵在於如何確定公司未來的現金流和折現率,而這正是體現承銷商的專業價值所在。所謂類比法,就是通過選擇同類上市公司的一些比率,如最常用的市盈率(P/E即股價/每股收益)、市凈率(P/B即股價/每股凈資產),再結合新上市公司的財務指標如每股收益、每股凈資產來確定上市公司價值,一般都採用預測的指標。
三、市盈率法的使用具有許多局限性,例如要求上市公司經營業績要穩定,不能出現虧損等。而市凈率法則沒有這些問題,但同樣也有缺陷,主要是過分依賴公司賬面價值而不是最新的市場價值,因此對於那些流動資產比例高的公司如銀行、保險公司比較適用此方法。在此次建行IPO過程中,按招股說明書中確定的定價區間1.9~2.4港元計算,發行後的每股凈資產約為1.09~1.15港元,則市凈率(P/B)為1.74~2.09倍。除上述指標,還可以通過市值/銷售收入(P/S)、市值/現金流(P/C)等指標來進行估值。通過估值模型,可以合理地估計公司的理論價值,但是要最終確定發行價格,還需要選擇合理的發行方式,以充分發現市場需求,常用的發行方式包括:累計投標方式、固定價格方式、競價方式。一般競價方式更常見於債券發行,這里不做贅述。累計投標是國際上最常用的新股發行方式之一,是指發行人通過詢價機制確定發行價格,並自主分配股份。所謂"詢價機制",是指主承銷商先確定新股發行價格區間,召開路演推介會,根據需求量和需求價格信息對發行價格反復修正,並最終確定發行價格的過程。一般時間為1~2周。例如此次建行最初的詢價區間為1.42~2.27港元,此後收窄至1.65~2.10港元,最終發行價將在10月25日前確定。詢價過程只是投資者的意向表示,一般不代表最終的購買承諾。
區塊鏈的tokenid是什麼一般是用於需要安全登陸驗證的網站,每次訪問創建一個隨機令牌ID,注銷後即吊銷該ID,起到安全防護作用。