以太坊nodejs

A. 哪些銀行已經實現區塊鏈應用落地

之前每每提到去中心化應用，我們總是會會想到國外的產品，如以太坊，但是今天再談到這個話題時我更多地會想到中國自己的Asch（阿希），基於側鏈技術的新一代去中心化應用開發。

ASCH是一個去中心化的應用開發，同時它也是中國的第一個去中心化應用，它的目的是幫助開發者快速創建去中心化應用。該具有易用、靈活、安全等特點。
從模式上來說，它跟以太坊類似，都屬於區塊鏈服務，但實現機制大不相同。就拿以太坊來說它最大的特色就是是極大地擴展了這個腳本引擎的功能，加入了讀取區塊鏈、計 費、跳轉等新指令，還解除了棧內存、函數調用深度以及腳本長度限制等。但這種方式 有一個很大的缺點就是，應用代碼本身及應用產生的數據都存在同一個區塊鏈中，造成了 區塊鏈的快速膨脹。
但是ASCH則不同，它的擴展性不是通過交易腳本來實現，而是通過側鏈。ASCH系統中存在一個主鏈和若干個側鏈(主要由開發者提供)，但是每條鏈只支持有限的幾種交易類型，交易或者合約的邏輯直接由宿主語言來編寫，而不是由交易腳本。
這樣的好處一是降低了合約編程的難度，二是避免了區塊鏈膨脹，三是每種應用都可以定製個性化的區塊鏈參數。

ASCH不會直接復制 Crypti（去中心化的,建立在區塊鏈上的應用商店）或Lisk（它是新一代的，允許JavaScript的開發和基於分布的分散的應用程序使用一個易於使用的，功能齊全的生態系統。）， 但是會參考Crypti的架構，也會復用其部分代碼，但不會太多。
不同點主要有兩方面
更安全的共識演算法，Crypti使用的是Dpos，我們在其上增加Pbft演算法，以增強一致性，降低雙重支付風險。
我們使用c++語言編寫了部分關鍵模塊，非性能熱點的部分依舊使用Nodejs來寫。

B. 使用Nodejs部署智能合約

實現智能合約的方式很多種，可以用truffle框架來實現，編譯，部署。
這里介紹一種簡單的使用nodejs來實現，編譯，部署的方法。
創建一個nodejs項目，實現一個簡單的智能合約。

這個合約實現了一個造幣和轉幣的邏輯。
我們的合約是運行在evm上面的位元組碼，solidity是靜態語言，需要通過編譯器生成evm的位元組碼。

調用 node compile.js ,對BaseToken進行編譯，生成位元組碼。web3中提供了一個部署合約的介面，使用如下，

利用編譯生成的abi和bytecode，創建一個合約對象，然後進行發布，等待著非同步執行的方法輸出合約地址 contractAddress ，這樣就完成了部署。不過這種方式有一個問題，就是在發布合約時，你的私鑰處於聯網狀態，
處於安全策略，我們需要盡量避免私鑰在聯網狀態。

以太坊上部署合約是向空地址發送一個附有位元組碼的簽名交易，其中發送者就是這個合約的擁有者。因此我們只需要將合約構建成一筆交易，我們在無網狀態下對這筆交易進行簽名，然後將簽名發送到以太坊網路中。這樣能夠降低我們私鑰被泄漏的風險。
對合約的簽名方法如下：

以上對一個合約簽名，這里需要注意的問題是，to的地址需要是，空地址。
完成簽名之後，我們把這筆交易發送出去就好，最簡單的方法就是使用 etherscan的發送Tx的方式 ，一旦發送完成，部署完成，就可以看到合約地址。

C. 使用Web3J與第三方合約交互——批量轉賬

之前使用NodeJs與智能合約交互，都是訪問的自己部署的合約。最近要對線上第三方合約進行轉賬操作，人數比較多，一筆筆操作起來手指都點斷了還容易出錯。既然代幣Token都遵守ERC20協議，肯定有統一的Transfer(轉賬)方法供客戶端調用，那麼編寫程序實現自動轉賬應該可以實現，去查了相關資料發現web3j是不錯的選擇。

輕量級客戶端與以太坊交互的Java庫。

既然是調用第三方合約那麼肯定需要知道合約地址，合約地址定義了到哪裡去訪問合約；
ABI（Application Binary Interface）: 應用程序二進制介面，定義了智能合約提供的方法功能

若是無法獲取到ABI介面，也可以使用solc編譯生產bin和abi文件。

(生產代理類時可以指定包路徑和類名)

這樣一來，便可以使用程序完成批量轉賬操作。

後來研究發現，使用NodeJs直接調用Web3也可以實現對應功能，不過還是對Java更熟悉一些，就採用了Java的方式。

D. 手機查node怎麼查

可以打開cmd命令行，使用命令來查看。

具體步驟如下：
在開始菜單的搜索框中輸入cmd，點擊cmd.exe打開cmd命令行。
輸入並執行node -v命令，就可查看到node的版本號，例如我的版本號就是10.4.1。
node是一個針對安卓手機的node.js框架。不需要手機ROOT。它將是Nodejs，為了做區塊鏈相關，選擇了以太坊通道平台。雖然互聯網上的信息可以找到一些，但它十分混雜，充滿了重復的錯誤，不夠系統。

E. 目前國內有哪些區塊鏈技術應用開發平台

所謂區塊鏈技術，簡稱BT（Blockchain technology），也被稱之為分布式賬本技術，是一種互聯網資料庫技術，其特點是去中心化、公開透明，讓每個人均可參與資料庫記錄。

F. 以太坊web3.sendRawTransaction離線簽名交易

工作中需要復現短地址攻擊和the重入攻擊，重入攻擊可以直接通過eth.sendTransaction和remix來發送交易，但是短地址攻擊由於錢包和remix這些都對input做了長度檢測，無法通過這些方式來復現，只能通過發離線簽名交易來實現。

1.環境依賴：nodejs , keythereum , ethereumjs-common , ethereumjs-tx 。

2.進入Node控制台，獲取相應賬戶私鑰。

3.簽名交易，進入Node,這里注意nonce問題，需要Nonce是實際可執行的nonce，Nonce不對會發送交易失敗,關於如何獲取input data網路比較多就不詳述了。

4.遇到的坑，網路出來的步驟是有問題的或者過時了，當時是參考的這篇文章， https://www.freebuf.com/articles/blockchain-articles/199903.html
，在控制台通過eth.sendRawTransaction發送簽名好的交易，我遇到了這個錯誤 ** sendRawTransaction invalid sender **

G. 區塊鏈技術入門，涉及哪些編程語言

Go語言

Go語言（Golang）是谷歌2009年推出的一種全新的編程語言，可以在不損失應用程序性能的情況下降低代碼的復雜性。谷歌首席軟體工程師羅布派克(Rob Pike)說：「我們之所以開發Go，是因為過去10多年間軟體開發的難度令人沮喪。」

除比特幣是由C++開發以外，目前最主流坊的客戶端均有go語言開發，足以可見Go語言在整個區塊鏈行業的地位。

C++

C++ 進一步擴充和完善了 C 語言，是一種面向對象的程序設計語言。C++ 可運行於多種平台上，如 Windows、MAC 操作系統以及 UNIX 的各種版本。C++是一種使用十分廣泛的計算機程序設計語言。它是一種通用程序設計語言，支持多重編程模式，例如過程化程序設計、數據抽象、面向對象程序設計、泛型程序設計和設計模式等。

大多數的區塊鏈企業都選擇用C++編寫區塊鏈的底層，最著名的有比特幣、ripple等，主要體現的是強計算性。

Java

Java不同於一般的編譯語言或解釋型語言。它首先將源代碼編譯成位元組碼，然後依賴各種不同平台上的虛擬機來解釋執行位元組碼，從而實現了「一次編寫，到處運行」的跨平台特性。而區塊鏈項目的開發，對Java有著明顯的依賴性。

其他的還有Python、系統架構、以太坊、Linux、hyperledger、JavaScript等都會有涉及。

H. 區塊鏈之聯盟鏈（三） 認識Fabric

Fabric 是超級賬本聯盟推出的核心區塊鏈框架，它適合在復雜的企業內和企業間搭建聯盟鏈。根據超級賬本聯盟的目標， Fabric 被建設為一個模塊化的、支持可插拔組件的基礎聯盟鏈框架。；

與以太坊系的Quorum不同，Fabric從一開始就只考慮企業間的應用。其獨有的channel概念，將企業根據業務目的不同以不同的子網連接起來， 每一個子網對應一個channel，而每個channel有自己獨立的區塊鏈。而Quorum很顯然是只有一個公網（所有企業節點都加入進去），企業與企業間的私有業務是通過Private Manager 完成的。

理解channel的最簡單方法就是，將它類比為一個消息服務提供的Topic，實際上Fabic最早就是基於Kafka 的分布式消息服務來實現。

       在Fabric網路中，一個企業可以有一個或多個節點加入整個聯盟鏈；一個企業可以加入1個或者多個Channel（子網）；  一個節點可以加入1個或者多個channel。每個channel構成一個子網，所以Fabric 是 一種由子網組成的網路。

那麼Fabric是怎麼實現智能合約的執行和完成業務上鏈（將事務結果記錄在區塊鏈里）的呢？

與其它框架不同， Fabric 將整個過程分成了三個階段：

業務背書階段 ： 客戶的請求發送的背書節點，通過智能合約完成業務的計算（但不更新狀態），並完成背書；將背書結果返回個客戶端。

業務的排序階段 ： 客戶端將背書結果通過Channel被發送到排序節點（orderer），在排序節點完成事務的排序，並打包到block里，最後下發給所有連接到channel的節點。

業務驗證並寫入賬本階段 : 通過Gossip 網路，所有Channel的節點都會接收到新的block，節點會驗證block中的每一個事務，確定是否有效：有效地將會跟新world state，無效的將會標志為「無效」，不會更新World state，但整個block會被完整的加入到帳本中（包括無效的事務）。

根據以上的描述，Fabric 節點實際可以分為  ，普通節點和Order節點：

 Peer, 普通節點, 完成背書（包括只能合約的執行）和驗證.

orderer,  排序節點，完成排序。

加入orderer節點的Fabric網路可以被描述如下：

每一個Channel，都定義了所有屬於channel的節點，但是並不需要所有節點都連接到Orderer 節點（節點間可以通過gossip 協議通訊來傳播私有數據或事務）.

       在區塊鏈中，共識是區塊鏈的基礎。與公有鏈不同，聯盟鏈的共識要求所有加入賬本的事務是確定的、最終的，也就是不可以有分叉，區塊與區塊間的順序是一定的，只存在唯一條鏈。在Fabric 中，這個客觀需求正是由排序實現的，所有的事務將被提交給orderer節點獲得確定的順序，並最終打包成block進入帳本。 Fabric 從1.4.1開始支持基於Raft實現排序服務,  可以認為基於Raft實現共識。

基於RAFT的排序服務相對於早期的Kafka 具有更好的分布性，配置更加簡單，是聯盟鏈里常用的一個常用的達成共識的演算法，Quorum就 默認使用RAFT作為共識層。簡單的說，RAFT是一個leader和follower的模式， 所有加入RAFT網路的節點，任意時候都有一個leader,  只有這個leader有權決定事務的順序，並打包成Block，其它節點只能作為follower提交事務和同步block。

基於FAFT網路，每個企業可以有一個或多個節點參與到Orderer中去。在Frabric中企業間的網路連接可以變化成如下形式：

       區塊鏈的使用用戶在乙太網中被稱作EOA（External of Account）, EOA的載體是錢包。我們沿用這個概念，來看看Fabric是如何實現用戶和發起事務的。Fabric中EOA是一個CA中心發布的certificate（x.509），一個Certificate代表一個Identity（這與以太坊還是有很大區別的， 以太坊中一個EOA其實是一個hash地址），EOA能夠參與的channel以及被授權的操作是有channel的MSP（ Membership Service  Provider）決定的（如下圖）。

註：certificate 是一種密碼學上驗證身份的通用做法； certificate包含了個人的信息，公鑰以及發布這個certificate的CA的簽名。驗證方只需要擁有這個CA的證書（包含CA的公鑰），就可以驗證這個簽名是否正確，certificate的內容是否有篡改。簡單的說，通過CA和Certificate，我們可以獲得一個可驗證的的身份和信任鏈。

      如上圖，fabric中通要使用Wallet作為EOA的載體，一個Wallet中可以包含多個Identity（x.509 certificate）。 Identity 通過 CA提供的信任鏈來驗證正確性。

  驗證了身份之後， Fabric 通過MSP在區塊鏈網路中解決該身份是否代表組織的成員和在組織內具有什麼角色。例如，channel首先會驗證當前用戶Identity是否是有效地身份，然後通過MSP查看其所處的企業和具有的角色，最終確定該用戶是否有權執行操作。

可以說，Fabric的訪問控制是通過MSP來完成的。在每一個需要訪問控制的地方都需要定義一個MSP。  例如，每個channel都定義一個MSP，這個MSP規定了在channel范圍內資源的訪問許可權。 MSP 是Fabric里一個晦澀難懂的概念，也是其賦予企業間安全訪問的基礎。

前文提到， Fabric 將業務處理和上網分成了三個部分， 背書，排序，驗證後加入賬本。

其中背書是Fabric執行智能合約的階段。以太坊中，智能合約是在EVM中執行的，有多種語言支持。 在Fabric，智能合約被稱為chaincode： 一個chaincode 可以理解為是智能合約的容器，可以包含一個或多個智能合約， 不用於EVM, chaincode是在 JVM 或NodeJS中執行。

客戶應用程序通過智能合約來訪問賬本，每一個可訪問的智能合約都被安裝在客戶端可以訪問的節點上，並被定義在channel里。（有隻能合約的節點被稱為背書節點，沒有隻能合約的節點被稱未提交節點，提交節點只維護賬本）

客戶應用提交一個交易請求， 請求到達背書節點， 背書節點首先會驗證客戶的簽名，確保客戶的身份有權執行本次交易，接著執行交易提及的智能合約（chaincode），並生成一個背書響應（或者叫做交易提案，tran-proposal）。這個背書響應中通常包含World state 的讀集合，寫集合， 以及節點對本次交易的簽名。這里與以太坊系聯盟鏈最主要的不同是： 背書階段只模擬交易，並不真正更新交易結果。 而真正更新交易在第三階段完成。背書節點最後將生成的背書響應fanhui給客戶端， 智能合約部分的執行就結束了。

通常一個交易的執行需要多方的簽名，所以客戶端需要將一個交易發送給多個背書節點，這些背書節點的選擇需要滿足背書策略的要求。

下圖是一個包含有客戶、背書節點，提交節點的網路示意圖。

根據Fabric官方的參考文檔，客戶交易的正果過程可使用下圖描述。

如上圖，從1到3，為背書階段，4為排序階段，4.1,4,2, 5為驗證提交階段。 參考 Frabic的節點 概念，可以了解更多在交易細節的概念。  

總的來看， Fabric 更專注於企業間，通過上文，可以讓大家對Fabric的基本構成與概念有一個總的了解。  Fabric本身並不神秘，都是使用的現有的企業間的技術。要更好的了解，建議參考閱讀分布式消息系統和企業的安全基礎設施（CA相關）的支持。與以太坊系聯盟鏈實現比較，  Fabric 的子網更概念對於復雜企業間應用適應更強，但是其復雜的安全考量，使得運營成本很高，另外，Fabric 使用Certificate做為用戶身份，有很大的局限性，在新的2.0里，Fabric對於此處將有所改變。

下一篇，我們將來看看Sawtooth , 由Inter 提供的區塊鏈框架。

區塊鏈之聯盟鏈(一) 認識以太坊

區塊鏈之聯盟鏈(二) 認識Quotum

區塊鏈之聯盟鏈(三) 認識Fabric

區塊鏈之聯盟鏈(四) 認識Sawtooth