頭條楓林網“ 比大多數人更早的學習區塊鏈開發 ”
課程預告
—
今晚8點，不見不散
今晚8點，待字閨中首次嘗試直播課程，為大家帶來《區塊鏈時代，你不願錯過的機會》。 莊家瘋狂收割、投資人的瘋狂宣傳，一時間狂歡、焦慮各種情緒充斥著整個行業。 那到底我們的機會在哪裡呢？ 如果你不了解區塊鏈，想進入這個行業卻不知道從哪裡入手；如果你是工程師，在這樣一個工程師主導的浪潮裡沒有找到自己的位置；都應該來聽一下這個課程。 課程鏈接點擊【閱讀原文】，掃碼加微信群，聯繫：待字閨中-小助手獲取高額優惠。
正文
—
前幾個月，負責了一個基於ETH的區塊鏈項目，整個開發過程中，雖然能查到很多中文區塊鏈資料，但其中大量都只是翻譯國外的文檔，一方面不是特別新，另外一 方面就是缺乏實際落地應用支撐，所以才有了這篇文章的想法，希望能對正在參與ETH開發的同學有點點幫助。
01
—
關於區塊鏈
區塊鏈最近很火，但其實區塊鏈的本質沒那麼複雜，BTC也沒有解決特別神奇的問題， 最主要的就是一個不安全的P2P網絡環境下，解決了一個獨立系統內部的貨幣流動問題（貨幣產生以及雙花） 。
這個其實很重要，目前我接觸到的大部分區塊鏈系統也都是如此，只處理自己系統內部的問題，而且是單鏈序列化的方式處理業務邏輯，就算是智能合約，為了保障智能合約 的受信，也不允許任何外部數據的引用，然後，因為具體實現的分佈性，甚至不能有和運行時間運行節點相關的操作。
而ETH呢，則是在BTC的基礎上更進一步，是 一台超級單線程計算機 。
因為區塊鏈最初的解釋是分佈式賬本，所以可以理解為一個分佈式的受信數據庫，在BTC階段，這裡存放的數據都是事先約定好的（貨幣==），而到了ETH階段，這裡可以 用來存放任意數據了，那麼智能合約可以理解為在這個分佈式數據庫裡的存儲過程，他們暴露了一組接口來訪問和修改各種數據。
所以在ETH裡面，賬戶、實例化後的智能合約、數據等，其實都是這台超級計算機裡的一段內存地址而已。
區塊鏈的受信是基於怎樣的原理產生的呢？ 其實很簡單，就是通過記賬權（寫入權）的不確定性來達成的，每個節點都進行同樣的運算，因為不知道最終以誰的結果為準，所以作弊成本很高而已。
02
—
ETH應用最簡模型
如果把ETH網絡整體想像成類Facebook這樣的平台，其實DAPP和普通APP沒什麼區別，web3就相當於是一組平台API接口，智能合約，也就是用來存放需要上鍊的核心數據以及權限控制腳本而已 。 其餘該用數據庫的還是應該用數據庫，畢竟上鍊是有成本的（GAS和運行延遲）。
下面是我們項目最基本的結構圖：
上圖是一個簡單的ETH應用結構，其中ETH網絡就是現有的ETH網絡，當然，開發階段，也能用私鍊或測試鏈的（一開始就直接上公鏈的話，GAS開銷太不合算了 ）。
ETH節點最好是一個我們自己部署的ETH節點，啟動時需要開啟RPC就好，用到的域都要開啟的，這塊如果用過geth控制台應該都知道。 因為我們的項目其實有一些中心化的部分，所以需要用到的關鍵ETH私鑰也是要導入進去，重要的里面還要有ETH餘額（很多操作都會有GAS開銷）。
DAPP服務器，是我們最主要的開發服務器，前面也提過，因為DAPP的特殊性，不太可能把所有東西都放ETH鏈上，效率開銷等都不合算，所以這裡做規劃時需要考慮清楚。 這裡除了通過web3來驅動ETH外，其它的和普通應用沒太大區別，該有緩存該有自己的中心數據庫的，最好都有，高並發高可用即可。
和ETH對接的就是web3，也就是一組RPC接口，接口方面和對接別的平台沒什麼特別的。
ETH的每個寫入操作（消耗GAS的）幾乎都是分2部分的，第一步是發佈到鏈上，這時會得到一個地址，然後通過檢查地址狀態，確定該操作是否完成，可能很久 才完成，這裡需要考慮各種異常，以及服務器進程重啟等。
DAPP客戶端，這個沒啥好說的，如果是web應用，建議還要接MetaMask，這樣對用戶來說會安全一些。
智能合約模塊，這部分其實算是真正DAPP的核心了，最好只把需要放鏈上的部分放智能合約模塊裡，並儘可能精簡。 智能合約雖然說是圖靈完整，但成本和限制都很大，前期項目規劃非常重要。 還是那句話，搞清楚項目為什麼用區塊鏈來做，哪部分一定要上鍊，哪些部分不需要上鍊。
03
—
ETH開發環境的搭建
ETH現在環境搭建已經很簡單了，基本上就是裝個golang，然後下載geth代碼編譯就好。
如果是測試的話，建議自己做個私鏈就好，網上隨便找個創世塊配置，需要注意的是，運行geth的時候，有個數據目錄，如果一台機器上，既有測試私鏈又 有公鏈，只是這個目錄配置成不一樣的即可。 熟悉一下geth的控制台操作，你會發現web3的接口基本上就是這些的封裝。
然後就是智能合約的開發環境，我們這邊本地編碼用的是VSCode（有Solidity插件），然後開發階段會用Remix來測試，最後用Solc編譯，通過自己的服務器用web3接口來部署。
IDE這塊後來有人安利Atom下的一個插件Etheratom，可以本地連節點的RPC編譯部署，同學也可以嘗試一下。
我們項目，後端直接用的NodeJS，IDE也是VSCode，ETH的web3庫，就直接用的web3.js。
前端也是web的，也是VSCode，沒啥好說的了。
04
—
Web3 & Solidity
web3基本上就是用RPC控制eth節點的API而已，大部分指令和geth控制台指令一致。
雖然ETH社區很活躍，但版本更新有點快，所以還是會遇到很多坑，我們主要用的是web3.js，中間就遇到個bug，github上看，應該是geth代碼改動造成的，但說 實話，web3.js處理也不嚴謹，差不多1個月沒人管，後來我們自己想辦法調用更底層的接口把這個bug迴避掉了。
鏈上的所有操作都是2步的，一步是發佈到鏈上，一步是最終確認，所以我們都沒有直接用web3.js的接口處理最終的回調，而是將上鍊後的地址記下來， 自己維護列表來查詢狀態的，這樣一方面不會阻塞玩家操作，另外也不會由於服務器別的異常重啟，對邏輯造成影響。
合約裡，一般都會有一些只讀接口，無GAS開銷，但這部分接口其實延遲也很嚴重，我們這部分數據也都是自己緩存的，能不調用鏈上的接口就沒調用鏈上的接口 。
智能合約原理上，是需要在任意ETH節點上運行都得到同樣的結果，所以完全不能主動從外部獲得數據（不安全），取到的時間戳等也都和當前區塊相關。
由於GAS規則的存在，智能合約裡也不建議做大的遍歷循環（甚至默認的map結構根本就不允許遍歷），除了自己的邏輯盡可能使用外部緩存（在外部把參數篩選出來，直接傳給 智能合約，就能省掉很多排序遍歷邏輯）外，因為現在區塊鏈原理上是不支持並行的，所以我們也大量的用到了索引，來簡化各種序列關係。
如果確實有一些很基本的功能，一定要在智能合約裡實現，基本語法又不支持的話，建議優先找現成的實現，譬如隨機數、可遍歷map、排序等。
智能合約實例化以後，就是一個地址，只要你有它的ABI，就能調用開放的接口。 因此，Solidity加了很多限制語法，來保障安全性（這點上我是支持ETH的，EOS那樣的完全用C++編譯WASM的方案，雖然更方便，但同時也失去了特殊語法層面的防禦措施） ，Solidity的很多版本更新都是類似這種，所以盡可能遵循最新的語法規範，盡可能在語法層面把安全性控制好。
智能合約一旦部署（實例化），代碼就是不可更改的，就好像是C++對像一樣，實例化以後，就是一個地址，萬一我們後期要調整邏輯怎麼辦呢？
目前來看，比較理想的方式是數據和實現分離（類COM機制），把權限控制好（各種限制語法支撐），這樣才能保障安全性的同時又留有一定的擴展性。
現在其實還有一批通用的ERC協議，開發者遵循這些協議規範，就會容易和第三方對接，而且多看看別人提交的議案，對自己的開發也會受益匪淺。
05
—
ETH應用最終模型
聊了那麼多，我們來把那個最簡模型稍加細化吧。
大體的結構沒變化，只是ETH相關的部分會變少很多，這也是我想傳達的，DAPP開發其實並沒有那麼特殊。
推薦
—
知識星球
待字閨中官方區塊鏈社區——最懂區塊鏈的人都在這裡。
往期推薦：