web3.0系統開發技術詳細介紹與分析

Web 3.0的紐帶作用：

　　

　　與DAPP瀏覽器相輔相成的是其底層網路架構Web 3.0，這是和資訊網際網路時代傳統瀏覽器基於的Web 2.0完全不同的體系架構。區塊鏈技術，尤其是ETH的出現使Web 3.0成為基於區塊鏈進行價值傳遞的基礎網路。

　　

　　從技術架構來看，Web 3.0的體系架構更為複雜，它在傳統資訊網際網路的基礎上，增加了價值（Token）的傳遞。

　　

　　合約是程式碼（它的功能）和資料（它的狀態）的集合，存在於ETH區塊鏈的特定地址。合約賬戶能夠在彼此之間傳遞資訊，進行圖靈完備的運算。合約依靠被稱作ETH虛擬機器(EVM)位元組程式碼（ETH特有的二進位制格式）上的區塊鏈執行。

　　

　　合約很典型地用諸如Solidity等語言寫成，然後編譯成位元組程式碼上傳到區塊鏈上。

　　

　　ETH語言

　　

　　合約依靠被稱作ETH虛擬機器(EVM)位元組程式碼（ETH特有的二進位制格式）上的區塊鏈執行。如有系統開發需求對接V:MrsFu123然而，合約很典型地用諸如Solidity等語言寫成，然後用ETH虛擬機器編譯器編譯成位元組程式碼上傳到區塊鏈。

　　

　　編譯合約

　　

　　solidity合約的編譯可以透過很多機制完成。

　　

　　透過命令列使用solc編譯器。

　　

　　在geth或eth提供的javascript控制檯使用web3.eth.compile.solidity(這仍然需要安裝solc編譯器)。

　　

　　線上Solidity實時編譯器。

　　

　　建立solidity合約的Meteor dapp Cosmo。

　　

　　Mix IDE。

　　

　　ETH錢包。

　　

　　注意：關於solc和編譯Solidity合約程式碼的更多資訊可在此檢視。

　　

　　在geth設定solidity編譯器

　　

　　如果你啟動了geth節點，就可以檢視哪個編譯器可用。

　　

　　這一指令會返回到顯示當前哪個編譯器可用的字串。

　　

　　注意：solc編譯器和cpp-ethereum一起安裝。或者，你可以自己建立。

　　

　　如果你的solc可執行檔案不在標準位置，可以用—solc標誌為solc可執行檔案指定一個定製路線

　　

　　或者你可以透過控制檯在執行期間設定這個選項：

　　

　　編譯一個簡單合約

　　

　　讓我們編譯一個簡單的合約源：

　　

　　這個合約提供了一個單一方法multiply，它和一個正整數a呼叫並返回到a*7。

　　

　　注意：編譯器透過RPC因此也能透過web3.js，對瀏覽器內任何透過RPC/IPC連線到geth的Ðapp可用。

　　

　　下面的例子會向你展示如何透過JSON-RPC接合geth來使用編譯器。

　　

　　Code編譯的ETH虛擬機器位元組程式碼

　　

　　Info從編譯器輸出的額外後設資料

　　

　　Source原始碼

　　

　　Language合約語言(Solidity，Serpent，LLL

　　

　　LanguageVersion合約語言版本

　　

　　compilerVersion用於編譯這個合約的solidity編譯器版本。

　　

　　abiDefinition應用的二進位制介面定義

　　

　　userDoc使用者的NatSpec Doc。

　　

　　developerDoc開發者的NatSpec Doc。

　　

　　編譯器輸出的直接結構化(到code和info)反映了兩種非常不同的部署路徑。編譯的ETH虛擬機器程式碼和一個合約建立交易被髮送到區塊，剩下的(info)在理想狀態下會存活在去中心化雲上，公開驗證的後設資料則執行區塊鏈上的程式碼。

　　

　　如果你的源包含多個合約，輸出會包括每個合約一個入口，對應的合約資訊物件可以用作為屬性名稱的合約名字檢索到。你可以透過檢測當前的GlobalRegistrar程式碼來試一下：

　　

　　建立和部署合約

　　

　　注意：用線上Solidity實時編譯器或Mix IDE程式會更容易完成。

　　

　　所有的二進位制資料都以十六進位制的格式序列化。十六進位制字串總會有一個十六進位制字首0x。

　　

　　注意：注意arg1,arg2,…是合約建構函式引數，以備它要接受引數。如果合約不需要建構函式引數，就可以忽略這些引數。

　　

　　值得指出的是，這一步驟需要你支付執行。一旦交易成功進入到區塊，你的賬戶餘額(你作為傳送方放在from領域)會根據ETH虛擬機器的gas規則被扣減。一段時間以後，你的交易會在一個區塊中出現，確認它帶來的狀態是共識。你的合約現在存在於區塊鏈上。以不同步的方式做同樣的事看起來是這樣：

　　

　　與合約互動

　　

　　與合約互動典型的做法是用諸如eth.contract()功能的抽象層，它會返回到javascript物件，和所有可用的合約功能一起，作為可呼叫的javascript功能。描述合約可用功能的標準方式是ABI定義。這個物件是一個字串，它描述了呼叫簽名和每個可用合約功能的返回值。

　　

　　現在ABI中具體說明的所有功能呼叫都在合約例項中可用。你可以用兩種方法中的一種來呼叫這些合約例項上的方法。

　　

　　當用sendTransaction被呼叫的時候，功能呼叫透過傳送交易來執行。需要花費以太幣來傳送，呼叫會一直記錄在區塊鏈上。用這種方式進行的呼叫返回值是交易散表。

　　

　　當用call被呼叫的時候，功能在ETH虛擬機器被本地執行，功能返回值和功能一起返回。用這種方式進行的呼叫不會記錄在區塊鏈上，因此也不會改變合約內部狀態。這種呼叫方式被稱為恆定功能呼叫。以這種方式進行的呼叫不花費以太幣。

　　

　　隨著公鏈等基礎設施的完善，未來將會出現更多基於不同應用場景的DAPP，包括：儲存、社交、即時通訊等領域均已出現相應的代表案例。手機錢包作為區塊鏈世界的“支付寶”，可以連線DAPP提供的服務端，以及終端使用者，因此內嵌DAPP瀏覽器成為很自然的選擇。

　　

　　當然，如果未來出現殺手級的DAPP，演變成新的流量入口，那麼該應用也可能內建錢包和DAPP瀏覽器的功能，從而和錢包應用爭奪入口級的機會。因此，DAPP瀏覽器在未來更可能內嵌在高頻剛需的流量入口中。