1小時搞明白以太坊 DAPP 開發 - 熊麗兵 | Jeth 第三期

編者按：本文系 登鏈科技 CTO 的熊麗兵 講師，在由掘金技術社區主辦，以太坊社區基金會、以太坊愛好者與 ConsenSys 協辦的 《開發者的以太坊入門指南 | Jeth 第三期 - 上海場》 活動上的分享整理。Jeth 圍繞以太坊技術開發主題的系列線下活動。每期 Jeth 會邀請以太坊開發領域的優秀技術團隊和工程師在線下分享技術乾貨。旨在爲開發者提供線下技術交流互動機會，幫助開發者成長。

歡迎添加稀土君微信：xitujun，回覆「以太坊」進羣和講師交流。

本場分享視頻回放連接（B 站）

分享整理傳送門

智能合約全棧介紹 - 鍾文斌 | Jeth 第三期

講師介紹

熊麗兵，北京航空航天大學碩士，前後加入創新工場及獵豹移動，全面負責數款千萬級用戶開發及管理工做，2014年做爲技術合夥人參與建立酷吧時代科技。2016年重心投入區塊鏈技術領域，目前在登鏈科技任 CTO ，是全網訪問量最大的區塊鏈技術博客《深刻淺出區塊鏈》博主，對底層公鏈技術，區塊鏈技術落地都有深刻研究。

謝謝你們，很高興可以和你們分享一些知識經驗，今天主題就是 《1小時搞明白以太坊 DAPP 開發》， 咱們直接進入主題，先介紹我本身，以前在創業工場、獵豹移動作工程師，而後如今區塊鏈行業瞎折騰。

這是我分享的內容，第一個先介紹什麼是區塊鏈的應用，再簡單的實現一個DAPP。

什麼是去中心化的應用？

咱們作一個對比，如今咱們先來看一下APP的架構，就是咱們平時接觸到的。平時接觸的是一個個前端，例如APP、H五、小程序等，這個前端後面通常都會有一個相關的服務器，不論是前端顯示的內容或者一些動做,它其實都是會有一些對應的請求發送到服務器裏面，而後服務器收到這個請求以後會有一些迴應，再發到前端的應用，就是這樣一個簡單的架構。

做爲一個去中心化的應用，它的前端表現都是同樣的，其實有時候咱們在跟客戶作應用時，他說：「咦！你這個看上去好像和咱們看到的應用徹底同樣，沒什麼區別啊。 」其實實際也是如此，關鍵他的後端不同。關於這個疑問，咱們有時候會在界面上加一行字，「此數據通過全網同步」，而後他們表示這就是去中心化應用，但其實關鍵是鏈接前端的這個後端的節點，它不可是一個服務器，而是後端它連着的一個網絡，無論你是鏈接到任何一個節點，它在理論上都是同樣的。

實際上你的應用是在一個網絡上面，當前端請求發送到後端的時候，後端鏈接的節點會把這個請求擴散到整個網絡。因此只有當真正的請求達到了全網的一個共識以後，它這個請求才算是真正的生效。這就不像你只有一個服務器時的，只能它說了算。

去中心化的交易所和中心化的交易全部什麼不同？

在中心化的交易所中，你全部的錢都不是在你的錢包裏面，而是在中心化交易所的錢包裏面，理論上它是能夠隨心所欲的，可是去中心化它是不同，你的錢是在大家本身的錢包裏面的，並且你的全部交易都是通過全網共識的，並非說它本身的節點，因此這個交易是受咱們本身控制的，這就是去中心化的應用和中心化的應用的一個最大的不一樣。

在中心化應用裏面，一般咱們發送一個請求是能夠直接拿到結果，而去中心化應用要通過全網的共識，一般當你前端有一個請求發到節點，節點告訴你，由於我收到這個請求，它並不能立馬處理並拿到結果，這也是一個開發去中心化應用裏比較大的不一樣點，因此若是咱們要想拿到這一個請求的相關狀態，通常是經過事件Event。還有一點在去中心化應用裏面，一般這個請求叫交易，這個交易和咱們開發普通應用的時候是不一樣的，它是通過用戶私鑰的簽名，這些就是幾個明顯的不一樣點。

接下來涉及到具體開發的一個過程，下面圖片中展現了 APP 和 DAPP 比較圖。

前端部分和客戶端部分其實基本上是同樣的， 前端用戶：通常經過在知道咱們普通開發APP的時候，它是經過一個HTTP的請求發到服務器再清空某轉發的話，最後它會調用到對應的後臺的程序中；在對應的去中心化中的地位中智能合約大概至關於咱們以前在寫普通應用中一個後端的服務程序這樣的角色。

不一樣點是一般在開發DAPP的時候這個發送請求再也不是HTTP，而是RPC(遠程調用)的一種方式,其中這個節點EVM就至關於咱們平時在寫DAPP中它的Nginx/Apache這樣的一個角色。 智能合約，它實際上是跑在一個節點上，或者說都跑到一個EVM上，固然這個EVM其實它就是在節點上的。

咱們要開發一個去中心化應用最主要作的是三部分 :

• 前端部分的編寫

• 智能合約部分的編寫

• 前端和智能合約的交互

我要實現這樣一個簡單的DAPP，它是在區塊鏈上，保存須要名字和年齡，經過這個更新它會把這個內容同步到區塊鏈中。

如何實現簡單的DAPP？

須要三個部分要寫 ：

• 編寫智能合約部分，至關於咱們在寫後端的服務程序

• 編寫前端的部分，此次展示的是Web形式，其實也有其餘形式

• 實現前端與合約交互

什麼是智能合約？

智能合約實際上是以太坊的一個程序，它是代碼和數據（狀態）的集合。而編寫智能合約的語言是Solidity，若是咱們用圖中舉例，把contract變成一個class，這就和咱們寫其餘的語言基本上是同樣的，就用contract定義hello，用function定義hello這樣的一個函數，這個只有一個簡單功能，它能夠把一個字符串返回出來，這就是一個最簡單的合約。

你既然要編寫一個合約或程序必然須要用到相關的工具 :

• Remix它是編寫Solidity的一個IDE，這是一個Web 形式的IDE.

• MetaMask錢包，它能夠負責幫你把發送的交易作一個簽名

• Ganache節點，在開發中咱們須要鏈接到一個節點，若是咱們每次都直接鏈接到以太坊的節點，這個過程是很是慢的。因此咱們可使用Ganache這樣模擬的一個節點，能夠方便咱們進行開發

我定義了一個合約，剛剛在前面有提到兩個部分，一是保持一個名字，二是保持一個年齡。那麼這個合約就有兩個變量，這兩個變量在智能合約裏面它叫作狀態變量，它的內容就會存在區塊鏈的網絡上，而後由你定義的兩個方法，一個叫set，一個叫get，set就是用來設置這兩個變量的內容，get是用來獲取。

(演示)我如今來教你們合約如何去編譯部署

首先打開Remix裏面（前面說起的工具中IDE Remix），地址：remix.ethereum.org/ , 如今咱們看到的就是IDE，而後中間是編輯代碼的區域，右邊這邊有Compile它實際上是我這邊勾成的，因此它是會自動去部署。部署的時候有一個叫環境的選擇，它其實就是關聯到MetaMaskq提供的一個環境。

咱們如今來部署一下，它其實也是提交交易的一個過程，因此它會彈出來提示讓咱們去付多少錢Gas，而後同時也會完成一個簽名的過程。部署好了以後，咱們就能夠對合約相應的函數進行調用，而此時合約的編譯和部署都已經完成了。而後咱們這邊能夠設置一個內容，它其實會發起一個交易，因此每次發起一個交易的時候，由於這個交易是用戶發起的，因此須要用戶的確認，這也是一個簽名的過程。如今智能合約部分就寫完了，這至關於咱們在寫程序的時後端部分。

如今咱們再來看看前端部分， 上圖中這個info是由我來顯示內容的，兩個input是須要用戶去輸入內容，一個button去更新內容，當用戶點擊這個button更新的時候，咱們就把數據提交到以太坊的網絡中。

須要說起的是潛在部分，有幾個關鍵地方就是引入了幾個庫，其中一個是web3，它是就是用來和節點進行交互的一個庫。而後這部分是咱們須要去編寫的，就是和合約進行交互的部分，web3它就是和合約進行交互的。咱們以前有一個RPC，就是從平時咱們寫應用的時候是用HTTP請求，可是在咱們編寫DAPP的時候，它是RPC的一個請求，其實web3它是對RPC的一個封裝。

web3是和以太坊節點交互的一個庫，它能夠用來獲取到節點的狀態，還有帳號的信息以及調用創建合約事件等等 。

它也是對RPC的一個封裝，它其實有不少個語言的實現，咱們如今要用到的是它的JavaScript版本的實現web3.js，咱們在開發一些其餘的，好比說你開發一個安卓的應用，可能就要須要用到web3j，或者是你開發其餘的就是非web形式的話，可能就要用到其餘版本的封裝。

要實現前端和合約的交互，首先咱們須要把這個web3導入進來，以後咱們要對web3作一個初始化。

以後咱們就須要用到合約的一些信息去初始化實例化合約，這有一個叫web3.eth.contract（ABI）就是智能合約提供的一些接口的描述。

在咱們編譯智能合約的時候，其實編譯器會爲咱們生成ABI。咱們編碼的時候就能夠把這個ABI的信息拷貝出來。咱們在實例化合約的時候須要把這個ABI的信息填入進來，告訴咱們的WEB3要鏈接的這個合約到底有哪些函數？ABI的大概做用就是這些。

咱們須要鏈接到的這個合約的地址是什麼？這個地址就是咱們在部署以後，它會爲咱們生成一個地址，這就是它要關聯的哪個合約的地址。咱們這個初始化合約部分就完成了，接着咱們可使用合約的實例去調用合約的相關函數。

咱們能夠拿到info，它對應的就是一個合約的實例，達到這個合約的實例以後，就能夠用這個實例來調用合約對應的方法，前面說起咱們合約裏面有一個set一個get，如今能夠經過這個實例來調用get，get它實際上是一個info的過程，因此咱們傳播的一個函數，這個函數從這個result裏面就能夠拿到getinfo裏面它返回的結果。

setinfo它有兩個參數，一個name和一個get，這個get和set就是對應咱們剛剛編寫合約的兩個方法。我能夠再次打開合約來作一個比對，剛剛咱們的代碼裏面有個set，一個get。

在web3裏面使用實例的話，它就能夠來調用到這兩個方法，而後我在這個界面的這個app.js裏面，咱們在初始化合約以後就會調用這個getinfo，它其實就是經過合約的實例來調用的，由於getinfo返回的是兩個內容，另外它在js裏面這邊就是一個數組了，而後經過 下標result[0] 拿到名字，下標result [1] 拿到年齡，以後就能夠把它設置到這個頁面上。

Setinfo是當咱們去點擊更新按鈕以後，它會去調用setinfo。如今咱們其經過這麼以上的操做以後，這個最簡單的DAPP就已經實現了。

接下來咱們能夠來運行一下。

(演示)如今保存以後，這個值就已經拿到了區塊鏈上的信息，其實這個信息就是以前我在部署合約時設置的這兩個內容。當咱們的頁面關聯上對應的合約的地址以及鏈接到對應的節點，它就能夠拿到這個數據。這就是一個最簡單的DAPP。但其實這個開發的過程是有點複雜，由於咱們還要去複製它的ABI、節點的信息等，所以有的時候這樣的開發過程很是麻煩，但這可讓咱們去了解DAPP開發的一個流程。因此實際上在開發的時候，咱們可能須要藉助一些其餘的一些框架，就是經常使用的兩框架是一個Truffle，一個叫Embark。

我這邊可使用這個Truffle框架來作個演示，剛剛咱們是在Remix裏面作了這樣一個編譯，其實咱們可使用Truffle來去簡化這個過程，這樣的話就不用說頻繁的去切換這個環境，咱們能夠直接在這個裏面（演示經過命令行 truffle compile 編譯）去完成這個操做。咱們能夠直接在這邊編譯，以後它會在build文件夾下給咱們生成一個對應合約名字的Json文件，這裏面就是有ABI的信息。

咱們使用truffle-contract來初始化合約的時候須要用到ABI的信息，而後咱們也一樣去再作一個部署，部署以後它也會爲咱們在這個編譯好的個Json文件裏面去生成對應的地址，原來咱們在初始化合約的時候在app.js裏面其實須要不少硬編碼的一些內容，包括地址以及ABI的信息，可是咱們使用Truffle提供這樣的contract的一個抽象的話，就可讓咱們免去這些過程。

我這邊把index.html裏面的這個APP.JS換成另一個app_tf.js，也就是它使用Truffle框架的js在這裏面的話，咱們就能夠不用硬編碼的去去複製ABI或者地址，直接使用經過或獲取到它生成的一箇中間的文件，節省時間，很方便，經過這種方式來實例化合約。

咱們接下來再來測試一下，由於剛剛咱們在truffle裏面從新的去部署了合約，因此如今這個合約的狀態是0，由於它默認值是0，而後若是是一個字符串的話，它就是空的一個字符串，咱們隨即可以寫一個來更新測試一下。由於要提交交易，因此要用戶的一個確認。如今這樣的一個DAPP就完成了。

代碼的地址爲： github.com/xilibi2003/…

歡迎你們跟我交流，下面是個人微信，也能夠關注登鏈學院，咱們提供了不少區塊鏈視頻課程，謝謝你們！