Solidity 官方文檔中文版 2_Ethereum 智能合約介紹

時間 2019-12-14

標籤 solidity 官方文檔中文版 ethereum 智能合約介紹简体版

原文原文鏈接

一個簡單的智能合約

先從一個很是基礎的例子開始，不用擔憂你如今還一點都不瞭解，咱們將逐步瞭解到更多的細節。html

Storage

contract SimpleStorage {
    uint storedData;

    function set(uint x) {
        storedData = x;
    }

    function get() constant returns (uint retVal) {
        return storedData;
    }
}

在Solidity中，一個合約由一組代碼（合約的函數）和數據（合約的狀態）組成。合約位於以太坊區塊鏈上的一個特殊地址。*uint storedData*; 這行代碼聲明瞭一個狀態變量，變量名爲storedData，類型爲 uint （256bits無符號整數）。你能夠認爲它就像數據庫裏面的一個存儲單元，跟管理數據庫同樣，能夠經過調用函數查詢和修改它。在以太坊中，一般只有合約的擁有者才能這樣作。在這個例子中，函數 set 和 get 分別用於修改和查詢變量的值。git

跟不少其餘語言同樣，訪問狀態變量時，不須要在前面增長 this. 這樣的前綴。程序員

這個合約還沒法作不少事情（受限於以太坊的基礎設施），僅僅是容許任何人儲存一個數字。並且世界上任何一我的均可以來存取這個數字，缺乏一個（可靠的）方式來保護你發佈的數字。任何人均可以調用set方法設置一個不一樣的數字覆蓋你發佈的數字。可是你的數字將會留存在區塊鏈的歷史上。稍後咱們會學習如何增長一個存取限制，使得只有你才能修改這個數字。github

代幣的例子

接下來的合約將實現一個形式最簡單的加密貨幣。空中取幣再也不是一個魔術，固然只有建立合約的人才能作這件事情（想用其餘貨幣發行模式也很簡單，只是實現細節上的差別）。並且任何人均可以發送貨幣給其餘人，不須要註冊用戶名和密碼，只要有一對以太坊的公私鑰便可。數據庫

Note瀏覽器

對於在線solidity環境來講，這不是一個好的例子。若是你使用在線solidity環境來嘗試這個例子。調用函數時，將沒法改變from的地址。因此你只能扮演鑄幣者的角色，能夠鑄造貨幣併發送給其餘人，而沒法扮演其餘人的角色。這點在線solidity環境未來會作改進。安全

contract Coin {
//關鍵字「public」使變量能從合約外部訪問。
    address public minter;
    mapping (address => uint) public balances;

//事件讓輕客戶端能高效的對變化作出反應。
    event Sent(address from, address to, uint amount);

//這個構造函數的代碼僅僅只在合約建立的時候被運行。
    function Coin() {
        minter = msg.sender;
    }
    function mint(address receiver, uint amount) {
        if (msg.sender != minter) return;
        balances[receiver] += amount;
    }
    function send(address receiver, uint amount) {
        if (balances[msg.sender] < amount) return;
        balances[msg.sender] -= amount;
        balances[receiver] += amount;
        Sent(msg.sender, receiver, amount);
    }
}

這個合約引入了一些新的概念，讓咱們一個一個來看一下。網絡

address public minter; 這行代碼聲明瞭一個可公開訪問的狀態變量，類型爲address。address類型的值大小爲160 bits，不支持任何算術操做。適用於存儲合約的地址或其餘人的公私鑰。public關鍵字會自動爲其修飾的狀態變量生成訪問函數。沒有public關鍵字的變量將沒法被其餘合約訪問。另外只有本合約內的代碼才能寫入。自動生成的函數以下：數據結構

function minter() returns (address) { return minter; }

固然咱們本身增長一個這樣的訪問函數是行不通的。編譯器會報錯，指出這個函數與一個狀態變量重名。併發

下一行代碼 mapping (address => uint) public balances; 建立了一個public的狀態變量，可是其類型更加的複雜。該類型將一些address映射到無符號整數。mapping能夠被認爲是一個哈希表，每個可能的key對應的value被虛擬的初始化爲全0.這個類比不是很嚴謹，對於一個mapping，沒法獲取一個包含其全部key或者value的鏈表。因此咱們得本身記着添加了哪些東西到mapping中。更好的方式是維護一個這樣的鏈表，或者使用其餘更高級的數據類型。或者只在不受這個缺陷影響的場景中使用mapping，就像這個例子。在這個例子中由public關鍵字生成的訪問函數將會更加複雜，其代碼大體以下：

function balances(address _account) returns (uint balance) {
    return balances[_account];
}

咱們能夠很方便的經過這個函數查詢某個特定帳號的餘額。

event Sent(address from, address to, uint value); 這行代碼聲明瞭一個「事件」。由send函數的最後一行代碼觸發。客戶端（服務端應用也適用）能夠以很低的開銷來監聽這些由區塊鏈觸發的事件。事件觸發時，監聽者會同時接收到from，to，value這些參數值，能夠方便的用於跟蹤交易。爲了監聽這個事件，你可使用以下代碼：

Coin.Sent().watch({}, '', function(error, result) {
    if (!error) {
        console.log("Coin transfer: " + result.args.amount +
            " coins were sent from " + result.args.from +
            " to " + result.args.to + ".");
        console.log("Balances now:\n" +
            "Sender: " + Coin.balances.call(result.args.from) +
            "Receiver: " + Coin.balances.call(result.args.to));
    }
}

注意在客戶端中是如何調用自動生成的 balances 函數的。

這裏有個比較特殊的函數 Coin。它是一個構造函數，會在合約建立的時候運行，以後就沒法被調用。它會永久得存儲合約建立者的地址。msg（以及tx和block）是一個神奇的全局變量，它包含了一些能夠被合約代碼訪問的屬於區塊鏈的屬性。msg.sender 老是存放着當前函數的外部調用者的地址。

最後，真正被用戶或者其餘合約調用，用來完成本合約功能的函數是mint和send。若是合約建立者以外的其餘人調用mint，什麼都不會發生。而send能夠被任何人（擁有必定數量的代幣）調用，發送一些幣給其餘人。注意，當你經過該合約發送一些代幣到某個地址，在區塊鏈瀏覽器中查詢該地址將什麼也看不到。由於發送代幣致使的餘額變化只存儲在該代幣合約的數據存儲中。經過事件咱們能夠很容易建立一個能夠追蹤你的新幣交易和餘額的「區塊鏈瀏覽器」。

區塊鏈基礎

對於程序員來講，區塊鏈這個概念其實不難理解。由於最難懂的一些東西（挖礦，哈希，橢圓曲線加密，點對點網絡等等）只是爲了提供一系列的特性和保障。你只須要接受這些既有的特性，不須要關心其底層的技術。就像你若是僅僅是爲了使用亞馬遜的AWS，並不須要瞭解其內部工做原理。

交易/事務

區塊鏈是一個全局共享的，事務性的數據庫。這意味着參與這個網絡的每個人均可以讀取其中的記錄。若是你想修改這個數據庫中的東西，就必須建立一個事務，並獲得其餘全部人的確認。事務這個詞意味着你要作的修改（假如你想同時修改兩個值）只能被完徹底全的實施或者一點都沒有進行。

此外，當你的事務被應用到這個數據庫的時候，其餘事務不能修改該數據庫。

舉個例子，想象一張表，裏面列出了某個電子貨幣全部帳號的餘額。當從一個帳戶到另一個帳戶的轉帳請求發生時，這個數據庫的事務特性確保從一個帳戶中減掉的金額會被加到另外一個帳戶上。若是由於某種緣由，往目標帳戶上增長金額沒法進行，那麼源帳戶的金額也不會發生任何變化。

此外，一個事務會被髮送者（建立者）進行密碼學簽名。這項措施很是直觀的爲數據庫的特定修改增長了訪問保護。在電子貨幣的例子中，一個簡單的檢查就能夠確保只有持有帳戶密鑰的人，才能從該帳戶向外轉帳。

區塊

區塊鏈要解決的一個主要難題，在比特幣中被稱爲「雙花攻擊」。當網絡上出現了兩筆交易，都要花光一個帳戶中的錢時，會發生什麼？一個衝突？

簡單的回答是你不須要關心這個問題。這些交易會被排序並打包成「區塊」，而後被全部參與的節點執行和分發。若是兩筆交易相互衝突，排序靠後的交易會被拒絕並剔除出區塊。

這些區塊按時間排成一個線性序列。這也正是「區塊鏈」這個詞的由來。區塊以一個至關規律的時間間隔加入到鏈上。對於以太坊，這個間隔大體是17秒。

做爲「順序選擇機制」（一般稱爲「挖礦」）的一部分，一段區塊鏈可能會時不時被回滾。但這種狀況只會發生在整條鏈的末端。回滾涉及的區塊越多，其發生的機率越小。因此你的交易可能會被回滾，甚至會被從區塊鏈中刪除。可是你等待的越久，這種狀況發生的機率就越小。

以太坊虛擬機

總覽

以太坊虛擬機（EVM）是以太坊中智能合約的運行環境。它不只被沙箱封裝起來，事實上它被徹底隔離，也就是說運行在EVM內部的代碼不能接觸到網絡、文件系統或者其它進程。甚至智能合約與其它智能合約只有有限的接觸。

帳戶

以太坊中有兩類帳戶，它們共用同一個地址空間。外部帳戶，該類帳戶被公鑰-私鑰對控制（人類）。合約帳戶，該類帳戶被存儲在帳戶中的代碼控制。

外部帳戶的地址是由公鑰決定的，合約帳戶的地址是在建立該合約時肯定的（這個地址由合約建立者的地址和該地址發出過的交易數量計算獲得，地址發出過的交易數量也被稱做"nonce"）

合約帳戶存儲了代碼，外部帳戶則沒有，除了這點之外，這兩類帳戶對於EVM來講是同樣的。

每一個帳戶有一個key-value形式的持久化存儲。其中key和value的長度都是256比特，名字叫作storage.

另外，每一個帳戶都有一個以太幣餘額（單位是「Wei"），該帳戶餘額能夠經過向它發送帶有以太幣的交易來改變。

交易

一筆交易是一條消息，從一個帳戶發送到另外一個帳戶（多是相同的帳戶或者零帳戶，見下文）。交易能夠包含二進制數據（payload）和以太幣。

若是目標帳戶包含代碼，該代碼會執行，payload就是輸入數據。

若是目標帳戶是零帳戶（帳戶地址是0），交易將建立一個新合約。正如上文所講，這個合約地址不是零地址，而是由合約建立者的地址和該地址發出過的交易數量（被稱爲nonce）計算獲得。建立合約交易的payload被看成EVM字節碼執行。執行的輸出作爲合約代碼被永久存儲。這意味着，爲了建立一個合約，你不須要向合約發送真正的合約代碼，而是發送可以返回真正代碼的代碼。

Gas

以太坊上的每筆交易都會被收取必定數量的gas，gas的目的是限制執行交易所需的工做量，同時爲執行支付費用。當EVM執行交易時，gas將按照特定規則被逐漸消耗。

gas price（以太幣計）是由交易建立者設置的，發送帳戶須要預付的交易費用 = gas price * gas amount。若是執行結束還有gas剩餘，這些gas將被返還給發送帳戶。

不管執行到什麼位置，一旦gas被耗盡（好比降爲負值），將會觸發一個out-of-gas異常。當前調用幀所作的全部狀態修改都將被回滾。

存儲，主存和棧

每一個帳戶有一塊持久化內存區域被稱爲存儲。其形式爲key-value，key和value的長度均爲256比特。在合約裏，不能遍歷帳戶的存儲。相對於另外兩種，存儲的讀操做相對來講開銷較大，修改存儲更甚。一個合約只能對它本身的存儲進行讀寫。

第二個內存區被稱爲主存。合約執行每次消息調用時，都有一塊新的，被清除過的主存。主存能夠以字節粒度尋址，可是讀寫粒度爲32字節（256比特）。操做主存的開銷隨着其增加而變大（平方級別）。

EVM不是基於寄存器，而是基於棧的虛擬機。所以全部的計算都在一個被稱爲棧的區域執行。棧最大有1024個元素，每一個元素256比特。對棧的訪問只限於其頂端，方式爲：容許拷貝最頂端的16個元素中的一個到棧頂，或者是交換棧頂元素和下面16個元素中的一個。全部其餘操做都只能取最頂的兩個（或一個，或更多，取決於具體的操做）元素，並把結果壓在棧頂。固然能夠把棧上的元素放到存儲或者主存中。可是沒法只訪問棧上指定深度的那個元素，在那以前必需要把指定深度之上的全部元素都從棧中移除才行。

指令集

EVM的指令集被刻意保持在最小規模，以儘量避免可能致使共識問題的錯誤實現。全部的指令都是針對256比特這個基本的數據類型的操做。具有經常使用的算術，位，邏輯和比較操做。也能夠作到條件和無條件跳轉。此外，合約能夠訪問當前區塊的相關屬性，好比它的編號和時間戳。

消息調用

合約能夠經過消息調用的方式來調用其它合約或者發送以太幣到非合約帳戶。消息調用和交易很是相似，它們都有一個源，一個目標，數據負載，以太幣，gas和返回數據。事實上每一個交易均可以被認爲是一個頂層消息調用，這個消息調用會依次產生更多的消息調用。

一個合約能夠決定剩餘gas的分配。好比內部消息調用時使用多少gas，或者指望保留多少gas。若是在內部消息調用時發生了out-of-gas異常（或者其餘異常），合約將會獲得通知，一個錯誤碼被壓在棧上。這種狀況只是內部消息調用的gas耗盡。在solidity中，這種狀況下發起調用的合約默認會觸發一我的工異常。這個異常會打印出調用棧。就像以前說過的，被調用的合約（發起調用的合約也同樣）會擁有嶄新的主存並可以訪問調用的負載。調用負載被存儲在一個單獨的被稱爲calldata的區域。調用執行結束後，返回數據將被存放在調用方預先分配好的一塊內存中。

調用層數被限制爲1024，所以對於更加複雜的操做，咱們應該使用循環而不是遞歸。

代碼調用和庫

存在一種特殊類型的消息調用，被稱爲callcode。它跟消息調用幾乎徹底同樣，只是加載自目標地址的代碼將在發起調用的合約上下文中運行。

這意味着一個合約能夠在運行時從另一個地址動態加載代碼。存儲，當前地址和餘額都指向發起調用的合約，只有代碼是從被調用地址獲取的。

這使得Solidity能夠實現」庫「。可複用的庫代碼能夠應用在一個合約的存儲上，能夠用來實現複雜的數據結構。

日誌

在區塊層面，能夠用一種特殊的可索引的數據結構來存儲數據。這個特性被稱爲日誌，Solidity用它來實現事件。合約建立以後就沒法訪問日誌數據，可是這些數據能夠從區塊鏈外高效的訪問。由於部分日誌數據被存儲在布隆過濾器（Bloom filter) 中，咱們能夠高效而且安全的搜索日誌，因此那些沒有下載整個區塊鏈的網絡節點（輕客戶端）也能夠找到這些日誌。