以太坊預編譯曲線

『壹』 用Go來做以太坊開發⑤事件日誌

智能合約具有在執行期間「發出」事件的能力。 事件在以太坊中也稱為「日誌」。 事件的輸出存儲在日誌部分下的事務處理中。 事件已經在以太坊智能合約中被廣泛使用，以便在發生相對重要的動作時記錄，特別是在代幣合約（即ERC-20）中，以指示代幣轉賬已經發生。 這些部分將引導您完成從區塊鏈中讀取事件以及訂閱事件的過程，以便交易事務被礦工打包入塊的時候及時收到通知。

為了訂閱事件日誌，我們需要做的第一件事就是撥打啟用websocket的以太坊客戶端。 幸運的是，Infura支持websockets。

下一步是創建篩選查詢。 在這個例子中，我們將閱讀來自我們在之前課程中創建的示例合約中的所有事件。

我們接收事件的方式是通過Go channel。 讓我們從go-ethereum core/types 包創建一個類型為 Log 的channel。

現在我們所要做的就是通過從客戶端調用 SubscribeFilterLogs 來訂閱，它接收查詢選項和輸出通道。 這將返回包含unsubscribe和error方法的訂閱結構。

最後，我們要做的就是使用select語句設置一個連續循環來讀入新的日誌事件或訂閱錯誤。

我們會在下個章節介紹如何解析日誌。

Commands

Store.sol

event_subscribe.go

智能合約可以可選地釋放「事件」，其作為交易收據的一部分存儲日誌。讀取這些事件相當簡單。首先我們需要構造一個過濾查詢。我們從go-ethereum包中導入 FilterQuery 結構體並用過濾選項初始化它。我們告訴它我們想過濾的區塊范圍並指定從中讀取此日誌的合約地址。在示例中，我們將從在 智能合約章節 創建的智能合約中讀取特定區塊所有日誌。

下一步是調用ethclient的 FilterLogs ，它接收我們的查詢並將返回所有的匹配事件日誌。

返回的所有日誌將是ABI編碼，因此它們本身不會非常易讀。為了解碼日誌，我們需要導入我們智能合約的ABI。為此，我們導入編譯好的智能合約Go包，它將包含名稱格式為 <Contract>ABI 的外部屬性。之後，我們使用go-ethereum中的 accounts/abi 包的 abi.JSON 函數返回一個我們可以在Go應用程序中使用的解析過的ABI介面。

現在我們可以通過日誌進行迭代並將它們解碼為我么可以使用的類型。若您回憶起我們的樣例合約釋放的日誌在Solidity中是類型為 bytes32 ，那麼Go中的等價物將是 [32]byte 。我們可以使用這些類型創建一個匿名結構體，並將指針作為第一個參數傳遞給解析後的ABI介面的 Unpack 函數，以解碼原始的日誌數據。第二個參數是我們嘗試解碼的事件名稱，最後一個參數是編碼的日誌數據。

此外，日誌結構體包含附加信息，例如，區塊摘要，區塊號和交易摘要。

若您的solidity事件包含 indexed 事件類型，那麼它們將成為 主題 而不是日誌的數據屬性的一部分。在solidity中您最多隻能有4個主題，但只有3個可索引的事件類型。第一個主題總是事件的簽名。我們的示例合約不包含可索引的事件，但如果它確實包含，這是如何讀取事件主題。

正如您所見，首個主題只是被哈希過的事件簽名。

這就是閱讀和解析日誌的全部內容。要學習如何訂閱日誌，閱讀上個章節。

命令

Store.sol

event_read.go

首先，創建ERC-20智能合約的事件日誌的interface文件 erc20.sol :

然後在給定abi使用 abigen 創建Go包

現在在我們的Go應用程序中，讓我們創建與ERC-20事件日誌簽名類型相匹配的結構類型：

初始化以太坊客戶端

按照ERC-20智能合約地址和所需的塊范圍創建一個「FilterQuery」。這個例子我們會用 ZRX 代幣:

用 FilterLogs 來過濾日誌：

接下來我們將解析JSON abi，稍後我們將使用解壓縮原始日誌數據：

為了按某種日誌類型進行過濾，我們需要弄清楚每個事件日誌函數簽名的keccak256哈希值。 事件日誌函數簽名哈希始終是 topic [0] ，我們很快就會看到。 以下是使用go-ethereum crypto 包計算keccak256哈希的方法：

現在我們將遍歷所有日誌並設置switch語句以按事件日誌類型進行過濾：

現在要解析 Transfer 事件日誌，我們將使用 abi.Unpack 將原始日誌數據解析為我們的日誌類型結構。 解包不會解析 indexed 事件類型，因為它們存儲在 topics 下，所以對於那些我們必須單獨解析，如下例所示：

Approval 日誌也是類似的方法：

最後，把所有的步驟放一起：

我們可以把解析的日誌與etherscan的數據對比: https://etherscan.io/tx/#eventlog

Commands

erc20.sol

event_read_erc20.go

solc version used for these examples

要讀取 0x Protocol 事件日誌，我們必須首先將solidity智能合約編譯為一個Go包。

安裝solc版本 0.4.11

為例如 Exchange.sol 的事件日誌創建0x Protocol交易所智能合約介面:

Create the 0x protocol exchange smart contract interface for event logs as Exchange.sol :

接著給定abi，使用 abigen 來創建Go exchange 包：

Then use abigen to create the Go exchange package given the abi:

現在在我們的Go應用程序中，讓我們創建與0xProtocol事件日誌簽名類型匹配的結構體類型：

初始化以太坊客戶端：

創建一個 FilterQuery ，並為其傳遞0x Protocol智能合約地址和所需的區塊范圍：

用 FilterLogs 查詢日誌：

接下來我們將解析JSON abi，我們後續將使用解壓縮原始日誌數據：

為了按某種日誌類型過濾，我們需要知曉每個事件日誌函數簽名的keccak256摘要。正如我們很快所見到的那樣，事件日誌函數簽名摘要總是 topic[0] ：

現在我們迭代所有的日誌並設置一個switch語句來按事件日誌類型過濾：

現在要解析 LogFill ，我們將使用 abi.Unpack 將原始數據類型解析為我們自定義的日誌類型結構體。Unpack不會解析 indexed 事件類型，因為這些它們存儲在 topics 下，所以對於那些我們必須單獨解析，如下例所示：

對於 LogCancel 類似：

最後是 LogError ：

將它們放在一起並運行我們將看到以下輸出：

將解析後的日誌輸出與etherscan上的內容進行比較： https://etherscan.io/tx/

命令

Exchange.sol

event_read_0xprotocol.go

這些示例使用的solc版本

『貳』 以太坊源碼分析--p2p節點發現

節點發現功能主要涉及 Server Table udp 這幾個數據結構，它們有獨自的事件響應循環，節點發現功能便是它們互相協作完成的。其中，每個以太坊客戶端啟動後都會在本地運行一個 Server ，並將網路拓撲中相鄰的節點視為 Node ，而 Table 是 Node 的容器， udp 則是負責維持底層的連接。下面重點描述它們中重要的欄位和事件循環處理的關鍵部分。

PrivateKey - 本節點的私鑰，用於與其他節點建立時的握手協商
Protocols - 支持的所有上層協議
StaticNodes - 預設的靜態 Peer ，節點啟動時會首先去向它們發起連接，建立鄰居關系
newTransport - 下層傳輸層實現，定義握手過程中的數據加密解密方式，默認的傳輸層實現是用 newRLPX() 創建的 rlpx ，這不是本文的重點
ntab - 典型實現是 Table ，所有 peer 以 Node 的形式存放在 Table
ourHandshake - 與其他節點建立連接時的握手信息，包含本地節點的版本號以及支持的上層協議
addpeer － 連接握手完成後，連接過程通過這個通道通知 Server

Server 的監聽循環，啟動底層監聽socket，當收到連接請求時，Accept後調用 setupConn() 開始連接建立過程

Server的主要事件處理和功能實現循環

Node 唯一表示網路上的一個節點

IP - IP地址
UDP/TCP - 連接使用的UDP/TCP埠號
ID - 以太坊網路中唯一標識一個節點，本質上是一個橢圓曲線公鑰(PublicKey)，與 Server 的 PrivateKey 對應。一個節點的IP地址不一定是固定的，但ID是唯一的。
sha - 用於節點間的距離計算

Table 主要用來管理與本節點與其他節點的連接的建立更新刪除

bucket - 所有 peer 按與本節點的距離遠近放在不同的桶(bucket)中，詳見之後的 節點維護
refreshReq - 更新 Table 請求通道

Table 的主要事件循環，主要負責控制 refresh 和 revalidate 過程。
refresh.C - 定時(30s)啟動Peer刷新過程的定時器
refreshReq - 接收其他線程投遞到 Table 的 刷新Peer連接 的通知，當收到該通知時啟動更新，詳見之後的 更新鄰居關系
revalidate.C - 定時重新檢查以連接節點的有效性的定時器，詳見之後的 探活檢測

udp 負責節點間通信的底層消息控制，是 Table 運行的 Kademlia 協議的底層組件

conn - 底層監聽埠的連接
addpending － udp 用來接收 pending 的channel。使用場景為：當我們向其他節點發送數據包後(packet)後可能會期待收到它的回復，pending用來記錄一次這種還沒有到來的回復。舉個例子，當我們發送ping包時，總是期待對方回復pong包。這時就可以將構造一個pending結構，其中包含期待接收的pong包的信息以及對應的callback函數，將這個pengding投遞到udp的這個channel。 udp 在收到匹配的pong後，執行預設的callback。
gotreply - udp 用來接收其他節點回復的通道，配合上面的addpending，收到回復後，遍歷已有的pending鏈表，看是否有匹配的pending。
Table - 和 Server 中的ntab是同一個 Table

udp 的處理循環，負責控制消息的向上遞交和收發控制

udp 的底層接受數據包循環，負責接收其他節點的 packet

以太坊使用 Kademlia 分布式路由存儲協議來進行網路拓撲維護，了解該協議建議先閱讀 易懂分布式 。更權威的資料可以查看 wiki 。總的來說該協議：

源碼中由 Table 結構保存所有 bucket ， bucket 結構如下

節點可以在 entries 和 replacements 互相轉化，一個 entries 節點如果 Validate 失敗，那麼它會被原本將一個原本在 replacements 數組的節點替換。

有效性檢測就是利用 ping 消息進行探活操作。 Table.loop() 啟動了一個定時器（0~10s），定期隨機選擇一個bucket，向其 entries 中末尾的節點發送 ping 消息，如果對方回應了 pong ，則探活成功。

Table.loop() 會定期（定時器超時）或不定期（收到refreshReq）地進行更新鄰居關系（發現新鄰居），兩者都調用 doRefresh() 方法，該方法對在網路上查找離自身和三個隨機節點最近的若干個節點。

Table 的 lookup() 方法用來實現節點查找目標節點，它的實現就是 Kademlia 協議，通過節點間的接力，一步一步接近目標。

當一個節點啟動後，它會首先向配置的靜態節點發起連接，發起連接的過程稱為 Dial ，源碼中通過創建 dialTask 跟蹤這個過程

dialTask表示一次向其他節點主動發起連接的任務

在 Server 啟動時，會調用 newDialState() 根據預配置的 StaticNodes 初始化一批 dialTask ， 並在 Server.run() 方法中，啟動這些這些任務。

Dial 過程需要知道目標節點( dest )的IP地址，如果不知道的話，就要先使用 recolve() 解析出目標的IP地址，怎麼解析？就是先要用藉助 Kademlia 協議在網路中查找目標節點。

當得到目標節點的IP後，下一步便是建立連接，這是通過 dialTask.dial() 建立連接

連接建立的握手過程分為兩個階段，在在 SetupConn() 中實現
第一階段為 ECDH密鑰建立 ：

第二階段為協議握手,互相交換支持的上層協議

如果兩次握手都通過，dialTask將向 Server 的 addpeer 通道發送 peer 的信息

『叄』 以太坊怎麼根據地址獲取私鑰

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

『肆』 以太坊交易(tx) 分析

更多請參考: Github: https://github.com/xianfeng92/ethereum-code-analysis

其中 object 和 opcodes 是相對應的，比如 60 對應就是 operation PUSH1,合約編譯後的位元組碼即為一組的 operation 。

合約部署其實就是實例化一個 contract 對象，並將 data 的值設給 Code屬性 。

創建合約的tx中，input欄位對應的是合約的位元組碼，即指令數組。

其中 input 欄位對應所要調用的函數簽名的前四個位元組（771602f7）以及對應的參數（1,2）

其中 input 欄位為所要調用的合約函數簽名的前四個位元組（72a099b7）

關於函數調用，Call會把對應的Code讀出來，依次解析，Code中會把所有的public簽名的函數標志（4位元組）push到棧里。然後依據 input 中需要調用函數的簽名標志（前4位元組）來匹配 Code， 匹配之後跳轉到對應的 opcode 。

『伍』 【深度知識】區塊鏈之加密原理圖示(加密,簽名)

先放一張以太坊的架構圖：

在學習的過程中主要是採用單個模塊了學習了解的，包括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演算法-Key Agreement)。然後利用該對稱秘鑰對數據進行加密，針對共享秘鑰這里的流程如下：

對於B節點，當接收到傳輸過來的數據時，解析出其中A節點的隨機公鑰，之後利用A節點的隨機公鑰 與 B節點自身的私鑰 計算出對稱秘鑰(KA演算法)。之後利用對稱秘鑰機密數據。

對於以上加密方式，其實仍然存在很多問題，比如如何避免重放攻擊(在消息中加入 Nonce )，再比如彩虹表(參考 KDF機制解決 )之類的問題。由於時間及能力有限，故暫時忽略。

那麼究竟應該採用何種加密呢？

主要還是基於要傳輸的數據的安全等級來考量。不重要的數據其實做好認證和簽名就可以，但是很重要的數據就需要採用安全等級比較高的加密方案了。

密碼套件 是一個網路協議的概念。其中主要包括身份認證、加密、消息認證(MAC)、秘鑰交換的演算法組成。

在整個網路的傳輸過程中，根據密碼套件主要分如下幾大類演算法：

秘鑰交換演算法：比如ECDHE、RSA。主要用於客戶端和服務端握手時如何進行身份驗證。

消息認證演算法：比如SHA1、SHA2、SHA3。主要用於消息摘要。

批量加密演算法：比如AES, 主要用於加密信息流。

偽隨機數演算法：例如TLS 1.2的偽隨機函數使用MAC演算法的散列函數來創建一個 主密鑰 ——連接雙方共享的一個48位元組的私鑰。主密鑰在創建會話密鑰（例如創建MAC）時作為一個熵來源。

在網路中，一次消息的傳輸一般需要在如下4個階段分別進行加密，才能保證消息安全、可靠的傳輸。

握手/網路協商階段：

在雙方進行握手階段，需要進行鏈接的協商。主要的加密演算法包括RSA、DH、ECDH等

身份認證階段：

身份認證階段，需要確定發送的消息的來源來源。主要採用的加密方式包括RSA、DSA、ECDSA(ECC加密，DSA簽名)等。

消息加密階段：

消息加密指對發送的信息流進行加密。主要採用的加密方式包括DES、RC4、AES等。

消息身份認證階段/防篡改階段：

主要是保證消息在傳輸過程中確保沒有被篡改過。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。

ECC ：Elliptic Curves Cryptography，橢圓曲線密碼編碼學。是一種根據橢圓上點倍積生成 公鑰、私鑰的演算法。用於生成公私秘鑰。

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演算法提供的一套集成(混合)加密方案。其中包括了非對稱加密，對稱加密和簽名的功能。

<meta charset="utf-8">

這個先訂條件是為了保證曲線不包含奇點。

所以，隨著曲線參數a和b的不斷變化，曲線也呈現出了不同的形狀。比如:

所有的非對稱加密的基本原理基本都是基於一個公式 K = k G。其中K代表公鑰，k代表私鑰，G代表某一個選取的基點。非對稱加密的演算法 就是要保證 該公式 不可進行逆運算( 也就是說G/K是無法計算的 )。 *

ECC是如何計算出公私鑰呢？這里我按照我自己的理解來描述。

我理解，ECC的核心思想就是：選擇曲線上的一個基點G，之後隨機在ECC曲線上取一個點k(作為私鑰)，然後根據k G計算出我們的公鑰K。並且保證公鑰K也要在曲線上。*

那麼k G怎麼計算呢？如何計算k G才能保證最後的結果不可逆呢？這就是ECC演算法要解決的。

首先，我們先隨便選擇一條ECC曲線，a = -3, b = 7 得到如下曲線：

在這個曲線上，我隨機選取兩個點，這兩個點的乘法怎麼算呢？我們可以簡化下問題，乘法是都可以用加法表示的，比如2 2 = 2+2，3 5 = 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

於是乎得到 2 P = -Q (是不是與我們非對稱演算法的公式 K = k G 越來越近了)。

於是我們得出一個結論，可以算乘法，不過只有在切點的時候才能算乘法，而且只能算2的乘法。

假若 2 可以變成任意個數進行想乘，那麼就能代表在ECC曲線里可以進行乘法運算，那麼ECC演算法就能滿足非對稱加密演算法的要求了。

那麼我們是不是可以隨機任何一個數的乘法都可以算呢？ 答案是肯定的。 也就是點倍積 計算方式。

選一個隨機數 k, 那麼k * P等於多少呢？

我們知道在計算機的世界裡，所有的都是二進制的，ECC既然能算2的乘法，那麼我們可以將隨機數k描 述成二進制然後計算。假若k = 151 = 10010111

由於2 P = -Q 所以 這樣就計算出了k P。 這就是點倍積演算法 。所以在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上的例子說明如何生成共享秘鑰，也可以參考 Alice And Bob 的例子。

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 = ka KB = 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-based Message Authentication Code. 其模型如下：

在 以太坊 的 UDP通信時(RPC通信加密方式不同)，則採用了以上的實現方式，並擴展化了。

首先，以太坊的UDP通信的結構如下：

其中，sig是 經過 私鑰加密的簽名信息。mac是可以理解為整個消息的摘要， ptype是消息的事件類型，data則是經過RLP編碼後的傳輸數據。

其UDP的整個的加密，認證，簽名模型如下：

『陸』 DApp開發入門

本文僅介紹以太坊系列的DApp開發，其他鏈原理差不太多。

MetaMask安裝完成並運行後，可以在Chrome控制台列印 MetaMask注入的window.ethereum對象

關於ethereum對象，我們只需要關心 ethereum.request 就足夠了，MetaMask 使用 ethereum.request(args) 方法 來包裝 RPC API。這些 API 基於所有以太坊客戶端公開的介面。 簡單來說錢包交互的大部分操作都是由 request() 方法實現，通過傳入不同的方法名來區分。

⚠️ 即使ethereum對象中提供了chainId，isMetaMask，selectAddress屬性，我們也不能完全相信這些屬性，他們是不穩定或不標准，不建議使用。我們可以通過上面說的request方法，拿到可靠的數據 。

錢包通過method方法名，進行對應的實現 以獲取錢包地址為例

調用 ethereum.request({ method: "eth_requestAccounts" }) ，錢包實現了該方法，那麼就可以拿到錢包的地址了。

MetaMask注入的 window.ethereum 就是一個Provider，一個RPC節點也是一個Provider，通過Provider，我們有了訪問區塊鏈的能力。 在連接到錢包的情況下，通常使用錢包的Provider就可以了， ethers.providers.Web3Provider(ethereum)

如果只需要查詢一些區塊鏈數據，可以使用EtherscanProvider 和 InfuraProvider 連接公開的 第三方節點服務提供商 。JsonRpcProvider 和 IpcProvider 允許連接到我們控制或可以訪問的以太坊節點。

獲取當前賬戶余額

獲取最新區塊號

其他RPC操作，可以通過 JSON-RPC 查看。

通過 ethers.js 可以連接ERC20的合約，合約編譯後會生成ABI，合約部署後，會生成合約地址，開發者通過 ABI和合約地址 ，對合約發送消息。

合約中的方法大致分為兩種： 視圖方法(免費)，非視圖方法(消耗Gas) ，可以通過ABI查看方法類型。

⚠️ ERC20需要多加關注的是 Approve() 方法以及 transfer() 和 transferFrom() 的區別 ，授權過的代幣，被授權的那一方，可以通過調用 transferFrom() 方法,轉走你授權數量內的代幣，所以授權是一個很危險的操作，假設你授權了一個不良的合約，那你會面臨授權的token被轉走的風險，即使你沒有泄露私鑰助記詞。

便利三方庫： web3-react use-wallet

文檔： doc.metamask.io ethers

『柒』 加密貨幣的J曲線，帶你深度了解加密行業

什麼是 J 曲線？

「 J曲線」是涉及經濟、私募股權到政治科學等各個領域的圖表，它甚至可被用來分析一個國家的穩定程度和開放程度。

J曲線也可以應用到加密資產的投資過程，以作為一種辨別手段去了解具有交付巨大收益能力的潛在低估加密貨幣。

J 曲線的三個階段

讓我使用下面的圖表向您介紹，該圖表分為三個階段：

第一階段：ICO（Initial Coin Offering）首次代幣發行

加密貨幣進入市場的目的是快速籌集資金，並且通常會伴隨著大量的宣傳。在此過程會有很多炒作，也許有些名人參與其中。一般來說，短期投機者會在代幣發行時大量地購買。

但是第一階段的令牌通常沒有任何效用。通常情況下，這些令牌在以太坊區塊鏈上啟動。但是該公司正在籌集資金的潛在價值主張或產品尚未建立。

因此，我們經常會看到投機活動出現短期飆升，然後進行修正。

第二階段：低迷期

地理學上講，「低迷期」描述了受赤道周圍低壓影響的大西洋和太平洋的部分地區。盡管這些地區可能會出現狂風和雷暴，但通常會有漫長而平靜的時期，連續數周沒有風。

這通常是在第二階段中發生的。

最初的ICO和後ICO的炒作和媒體報道基本已經平息。投機者往往進進出出，與此同時，開發人員正在努力地工作、調試和開發，一般每個項目需要幾個月甚至一年的時間才能投入使用。

可以看出的是：價格反映出投機者缺乏興趣，市場中「雜訊」還不多。第二階段中，一切還是安靜的。

貝瑞研究認為：從J曲線的分析來看，對投資者來說，第二階段是入場持有的理想時機。

第三階段：能量發動

隨著時間的流逝，加密項目將更接近達到關鍵的里程碑和推出加密貨幣（無論是貨幣，協議還是企業）。當我們開始接近該領域時，我們會看到市場對該項目會再次產生興趣，而價格也反映了這一點。

購買一個項目的令牌需要一個星期，而不是六個月，這之間存在很大的差異。

我希望讀者很清楚我們要在哪個階段持有加密貨幣：第二階段，一個項目開始受到關注的時候。因為在第二階段它不受大部分投機者的喜愛，也沒有鋪天蓋地地出現在新聞和博客上，更沒有太多要報告的內容。

這是我們離盈利項目很近的時候，我們正在尋找定期的開發更新，且確保團隊正在達到其里程碑。確定他們是領先還是落後與既定的計劃？他們是在組建團隊還是開發人員打算離開？

這些J曲線交易為我們提供了尋找巨額回報的最佳可能性。

J曲線意味著潛在的機會交易

我們會不時地發現難得的機會，快速涉足加密資產，並且不必等待每月的出版，甚至每周的更新。

這些交易通常是由事件驅動的：例如，當某種情況發生在市場上時，引起了巨大的調整並創造了巨大的購買機會。

其他機會交易將是由於特定加密資產的潛在上行催化劑：例如主要合作夥伴公告或列出代幣的主要交易所（通常會在上市後將更多的交易量注入特定代幣）。

加密貨幣復雜度等級

有些加密貨幣比其他加密貨幣更容易購買和存儲。

例如，可以在交易所（可讓您用美元交易加密貨幣的交易所）在加密貨幣處購買比特幣。可以購買其他加密貨幣並將其存儲在集成交換錢包（也稱為「多資產錢包」）中。這些是易於使用的錢包，可讓您在同一位置存儲和交換幾十個不同的加密貨幣（有關更多信息，請參閱有關加密貨幣交換和加密貨幣錢包的指南）。

然而，有些加密貨幣只能在特定的加密貨幣交易所購買，這需要使用自己的錢包才能安全存儲。

在事物發展如此之快的加密空間中，不可能進行完美的分類，但是我們的「復雜性等級」旨在讓您了解購買和存儲加密的難度。

除了J曲線之外，還有其他相關技術指標可以預見加密貨幣的發展趨勢，例如S曲線等。貝瑞研究曾發布 《比特幣的S曲線，遠比你想像得性感》 ，根據分析S曲線，深度剖析比特幣的長期發展趨勢。

想知道我們是如何劃分加密貨幣的復雜程度嗎？想了解我們如何解決和管理復雜的加密貨幣難題嗎？貝瑞後續會發布更多加密貨幣投資機會的內容，讓您實時把握行業風向，深度了解加密圈！

貝瑞研究分析師： Eric Wade

編譯： Lois Li

『捌』 關於以太坊預編譯合約的一些使用方法

誠如以太坊黃皮書所言，這八個所謂的'預編譯'合約，意味著可能在以後成為原生擴展的初步體系結構。它是使用通用EVM執行框架的八個例外，用於評估消息調用。

『玖』 CentOS 6.5上搭建以太坊私有鏈，編譯時報錯： make: *** [geth] Error 1，請各位大神指教

build/env.sh go run build/ci.go install ./cmd/geth
make: *** [geth] Error 1
沒有這個目錄，或者這個目錄許可權不夠