❶ 用Go來做以太坊開發④智能合約
在這個章節中我們會介紹如何用Go來編譯，部署，寫入和讀取智能合約。
與智能合約交互，我們要先生成相應智能合約的應用二進制介面ABI(application binary interface)，並把ABI編譯成我們可以在Go應用中調用的格式。
第一步是安裝 Solidity編譯器 ( solc ).
Solc 在Ubuntu上有snapcraft包。
Solc在macOS上有Homebrew的包。
其他的平台或者從源碼編譯的教程請查閱官方solidity文檔 install guide .
我們還得安裝一個叫 abigen 的工具，來從solidity智能合約生成ABI。
假設您已經在計算機上設置了Go，只需運行以下命令即可安裝 abigen 工具。
我們將創建一個簡單的智能合約來測試。 學習更復雜的智能合約，或者智能合約的開發的內容則超出了本書的范圍。 我強烈建議您查看 truffle framework 來學習開發和測試智能合約。
這里只是一個簡單的合約，就是一個鍵/值存儲，只有一個外部方法來設置任何人的鍵/值對。 我們還在設置值後添加了要發出的事件。
雖然這個智能合約很簡單，但它將適用於這個例子。
現在我們可以從一個solidity文件生成ABI。
它會將其寫入名為「Store_sol_Store.abi」的文件中
現在讓我們用 abigen 將ABI轉換為我們可以導入的Go文件。 這個新文件將包含我們可以用來與Go應用程序中的智能合約進行交互的所有可用方法。
為了從Go部署智能合約，我們還需要將solidity智能合約編譯為EVM位元組碼。 EVM位元組碼將在事務的數據欄位中發送。 在Go文件上生成部署方法需要bin文件。
現在我們編譯Go合約文件，其中包括deploy方法，因為我們包含了bin文件。
在接下來的課程中，我們將學習如何部署智能合約，然後與之交互。
Commands
Store.sol
solc version used for these examples
如果你還沒看之前的章節，請先學習 編譯智能合約的章節 因為這節內容，需要先了解如何將智能合約編譯為Go文件。
假設你已經導入從 abigen 生成的新創建的Go包文件，並設置ethclient，載入您的私鑰，下一步是創建一個有配置密匙的交易發送器(tansactor)。 首先從go-ethereum導入 accounts/abi/bind 包，然後調用傳入私鑰的 NewKeyedTransactor 。 然後設置通常的屬性，如nonce，燃氣價格，燃氣上線限制和ETH值。
如果你還記得上個章節的內容, 我們創建了一個非常簡單的「Store」合約，用於設置和存儲鍵/值對。 生成的Go合約文件提供了部署方法。 部署方法名稱始終以單詞 Deploy 開頭，後跟合約名稱，在本例中為 Store 。
deploy函數接受有密匙的事務處理器，ethclient，以及智能合約構造函數可能接受的任何輸入參數。我們測試的智能合約接受一個版本號的字元串參數。 此函數將返回新部署的合約地址，事務對象，我們可以交互的合約實例，還有錯誤（如果有）。
就這么簡單：）你可以用事務哈希來在Etherscan上查詢合約的部署狀態: https://rinkeby.etherscan.io/tx/
Commands
Store.sol
contract_deploy.go
solc version used for these examples
這寫章節需要了解如何將智能合約的ABI編譯成Go的合約文件。如果你還沒看， 前先讀 上一個章節 。
一旦使用 abigen 工具將智能合約的ABI編譯為Go包，下一步就是調用「New」方法，其格式為「New<contractname style="box-sizing: border-box; font-size: 16px; -ms-text-size-adjust: auto; -webkit-tap-highlight-color: transparent;">」，所以在我們的例子中如果你 回想一下它將是 NewStore 。 此初始化方法接收智能合約的地址，並返回可以開始與之交互的合約實例。</contractname>
Commands
Store.sol
contract_load.go
solc version used for these examples
這寫章節需要了解如何將智能合約的ABI編譯成Go的合約文件。如果你還沒看， 前先讀 上一個章節 。
在上個章節我們學習了如何在Go應用程序中初始化合約實例。 現在我們將使用新合約實例提供的方法來閱讀智能合約。 如果你還記得我們在部署過程中設置的合約中有一個名為 version 的全局變數。 因為它是公開的，這意味著它們將成為我們自動創建的getter函數。 常量和view函數也接受 bind.CallOpts 作為第一個參數。了解可用的具體選項要看相應類的 文檔 一般情況下我們可以用 nil 。
Commands
Store.sol
contract_read.go
solc version used for these examples
這寫章節需要了解如何將智能合約的ABI編譯成Go的合約文件。如果你還沒看， 前先讀 上一個章節 。
寫入智能合約需要我們用私鑰來對交易事務進行簽名。
我們還需要先查到nonce和燃氣價格。
接下來，我們創建一個新的keyed transactor，它接收私鑰。
然後我們需要設置keyed transactor的標准交易選項。
現在我們載入一個智能合約的實例。如果你還記得 上個章節 我們創建一個名為 Store 的合約，並使用 abigen 工具生成一個Go文件。 要初始化它，我們只需調用合約包的 New 方法，並提供智能合約地址和ethclient，它返回我們可以使用的合約實例。
我們創建的智能合約有一個名為 SetItem 的外部方法，它接受solidity「bytes32」格式的兩個參數（key，value）。 這意味著Go合約包要求我們傳遞一個長度為32個位元組的位元組數組。 調用 SetItem 方法需要我們傳遞我們之前創建的 auth 對象（keyed transactor）。 在幕後，此方法將使用它的參數對此函數調用進行編碼，將其設置為事務的 data 屬性，並使用私鑰對其進行簽名。 結果將是一個已簽名的事務對象。
現在我就可以看到交易已經成功被發送到了以太坊網路了: https://rinkeby.etherscan.io/tx/
要驗證鍵/值是否已設置，我們可以讀取智能合約中的值。
搞定！
Commands
Store.sol
contract_write.go
solc version used for these examples
有時您需要讀取已部署的智能合約的位元組碼。 由於所有智能合約位元組碼都存在於區塊鏈中，因此我們可以輕松獲取它。
首先設置客戶端和要讀取的位元組碼的智能合約地址。
現在你需要調用客戶端的 codeAt 方法。 codeAt 方法接受智能合約地址和可選的塊編號，並以位元組格式返回位元組碼。
你也可以在etherscan上查詢16進制格式的位元組碼 https://rinkeby.etherscan.io/address/#code
contract_bytecode.go
首先創建一個ERC20智能合約interface。 這只是與您可以調用的函數的函數定義的契約。
然後將interface智能合約編譯為JSON ABI，並使用 abigen 從ABI創建Go包。
假設我們已經像往常一樣設置了以太坊客戶端，我們現在可以將新的 token 包導入我們的應用程序並實例化它。這個例子里我們用 Golem 代幣的地址.
我們現在可以調用任何ERC20的方法。 例如，我們可以查詢用戶的代幣余額。
我們還可以讀ERC20智能合約的公共變數。
我們可以做一些簡單的數學運算將余額轉換為可讀的十進制格式。
同樣的信息也可以在etherscan上查詢: https://etherscan.io/token/?a=
Commands
erc20.sol
contract_read_erc20.go
solc version used for these examples
❷ 【以太坊易錯概念】nonce, 公私鑰和地址，BASE64/BASE58,
以太坊里的nonce有兩種意思，一個是proof of work nonce，一個是account nonce。
在智能合約里，nonce的值代表的是該合約創建的合約數量。只有當一個合約創建另一個合約的時候才會增加nonce的值。但是當一個合約調用另一個合約中的method時 nonce的值是不變的。
在以太坊中nonce的值可以這樣來獲取（其實也就是屬於一個賬戶的交易數量）：
但是這個方法只能獲取交易once的值。目前是沒有內置方法來訪問contract中的nonce值的
通過橢圓曲線演算法生成鑰匙對（公鑰和私鑰），以太坊採用的是secp256k1曲線,
公鑰採用uncompressed模式，生成的私鑰為長度32位元組的16進制字串，公鑰為長度64的公鑰字串。公鑰04開頭。
把公鑰去掉04，剩下的進行keccak-256的哈希，得到長度64位元組的16進制字串，丟掉前面24個，拿後40個，再加上"0x"，即為以太坊地址。
整個過程可以歸納為：
2）有些網關或系統只能使用ASCII字元。Base64就是用來將非ASCII字元的數據轉換成ASCII字元的一種方法，而且base64特別適合在http，mime協議下快速傳輸數據。Base64使用【字母azAZ數字09和+/】這64個字元編碼。原理是將3個位元組轉換成4個位元組(3 X 8) = 24 = (4 X 6)
當剩下的字元數量不足3個位元組時，則應使用0進行填充，相應的，輸出字元則使用'='佔位，因此編碼後輸出的文本末尾可能會出現1至2個'='。
1）Base58是用於Bitcoin中使用的一種獨特的編碼方式，主要用於產生Bitcoin的錢包地址。相比Base64，Base58不使用數字"0"，字母大寫"O"，字母大寫"I"，和字母小寫"l"，以及"+"和"/"符號。
Base58Check是一種常用在比特幣中的Base58編碼格式，增加了錯誤校驗碼來檢查數據在轉錄中出現的錯誤。 校驗碼長4個位元組，添加到需要編碼的數據之後。校驗碼是從需要編碼的數據的哈希值中得到的，所以可以用來檢測並避免轉錄和輸入中產生的錯誤。使用 Base58check編碼格式時，編碼軟體會計算原始數據的校驗碼並和結果數據中自帶的校驗碼進行對比。二者不匹配則表明有錯誤產生，那麼這個 Base58Check格式的數據就是無效的。例如，一個錯誤比特幣地址就不會被錢包認為是有效的地址，否則這種錯誤會造成資金的丟失。
為了使用Base58Check編碼格式對數據（數字）進行編碼，首先我們要對數據添加一個稱作「版本位元組」的前綴，這個前綴用來明確需要編碼的數 據的類型。例如，比特幣地址的前綴是0（十六進制是0x00），而對私鑰編碼時前綴是128（十六進制是0x80）。 表4-1會列出一些常見版本的前綴。
接下來，我們計算「雙哈希」校驗碼，意味著要對之前的結果（前綴和數據）運行兩次SHA256哈希演算法：
checksum = SHA256(SHA256(prefix+data))
在產生的長32個位元組的哈希值（兩次哈希運算）中，我們只取前4個位元組。這4個位元組就作為校驗碼。校驗碼會添加到數據之後。
結果由三部分組成：前綴、數據和校驗碼。這個結果採用之前描述的Base58字母表編碼。下圖描述了Base58Check編碼的過程。
相同:
1） 哈希演算法、Merkle樹、公鑰密碼演算法
https://blog.csdn.net/s_lisheng/article/details/77937202?from=singlemessage
2）全新的 SHA-3 加密標准 —— Keccak
https://blog.csdn.net/renq_654321/article/details/79797428
3）在線加密演算法
http://tools.jb51.net/password/hash_md5_sha
4）比特幣地址生成演算法詳解
https://www.cnblogs.com/zhaoweiwei/p/address.html
5）Base58Check編碼實現示例
https://blog.csdn.net/QQ604666459/article/details/82419527
6） 比特幣交易中的簽名與驗證
https://www.jianshu.com/p/a21b7d72532f
❸ 比特幣區塊里的各個欄位含義(先寫了個nonce)
nonce是個啥意思？根據bitcoin wiki
nonce是一個4-byte大小的區域，nonce的值設定使得該塊的hash是以一串0開頭的。
對於塊數據的一點點改變（比如nonce）都會引起block hash的巨大變化。由於逆向預測hash值相對應的一組bit值（hash原文）是不可行的，在嘗試足夠多的nonce值且計算每個nonce值相對應的block hash之後可以找到一個滿足有指定數量 0 bits (0比特位) 的hash值。而 0 bits的數量值是由difficult設定的。最終產生的hash須得是一個小於當前difficulty值。
因為這個迭代的計算耗費時間和資源，塊的出現也就是得到了正確的nonce值，這構成了 proof of work
關於以太坊里的nonce 網上很多解釋，很多一上來就是 交易計數器 ， 然而卻把跟POW有關的丟了嗎？事實上以太坊里的nonce有兩種意思，一個是proof of work nonce，一個是account nonce。
那智能合約呢？合約也算是Account的一種，那也有nonce嗎？
是的，而且合約裡面的nonce也差不多，也是一個counter。在智能合約里，nonce的值代表的是該合約創建的合約數量。只有當一個合約創建另一個合約的時候才會增加nonce的值。但是當一個合約調用另一個合約中的method時 nonce的值是不變的。
在以太坊中nonce的值可以這樣來獲取（其實也就是屬於一個賬戶的交易數量）：
但是這個方法只能獲取交易once的值。目前是沒有內置方法來訪問contract中的nonce值的，除了自己定義一個counter來計數...
那好，再來看一下Ethereum Block中的nonce：
以太坊和比特幣區塊鏈一樣，也需要proof of work（計劃轉移到股份證明也早已在做了）。在比特幣區塊鏈中，pow應該是要算出一個符合難度要求的值，通常是以一串0開頭的。這個難度一直在變化。可以查看 比特幣區塊鏈的POW難度變化 。
❹ ERC-721 文檔翻譯(上)
在之前的2篇文章中，已經講了一些關於ERC-721的基本概念，適用范圍，以及ERC-721與ERC-20的區別。本文是針對ERC-721 NFTS （Non-Fungible Tokens）標準的翻譯，將會更加詳細與准確，由於文章篇幅較長，所以分為上、下2部分來講解。由於本人水平有限，如有錯誤，歡迎大家指正。
原文鏈接 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
ERC-721是對於不可互換Token的一個標准介面，也稱為契約
以下標准將允許在智能合約中去實現 NFTs 的標准API。這些標准提供了一些基本的函數去追蹤和交易NFTs。
我們考慮了以下2種使用案例，NFTs由個人擁有和交易以及向第三方經紀人/錢包/運營商托運。NFTs可以代表數字或者物理資產的所有權。我們考慮了各種各樣的資產，並且我們知道你會想像的更多：
一般來說，所有的房子都是獨特的，沒有2隻貓是一樣的。NFTs是可區分的，並且你必須單獨追蹤每一個的所有權。
標准介面允許錢包/經紀人/拍賣應用程序在以太坊的任何NFT上運行。我們提供了簡單的ERC-721 智能合約以及追蹤任意數量NFT的合約。其它的應用程序會在後面討論。
ERC-721標準是受ERC-20 token 標准和EIP-20被創造2年來的經驗的啟發。EIP-20不足以追蹤NFTs，因為每個資產都是不同的(不可置換的)，然而每一個Token都是相同的(可置換的)。
這個標准和EIP-20的區別如下。
在本文檔中的關鍵字，"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"將會按照RFC 2119中的描述進行解釋。
每個符合ERC-721標準的合約都必須實現ERC721 和 ERC165介面(受以下注意事項的限制)
介面說明：
balanceOf(): 返回由_owner 持有的NFTs的數量。
ownerOf(): 返回tokenId代幣持有者的地址。
approve(): 授予地址_to具有_tokenId的控制權，方法成功後需觸發Approval 事件。
setApprovalForAll(): 授予地址_operator具有所有NFTs的控制權，成功後需觸發ApprovalForAll事件。
getApproved()、isApprovedForAll(): 用來查詢授權。
safeTransferFrom(): 轉移NFT所有權，一次成功的轉移操作必須發起 Transer 事件。函數的實現需要做一下幾種檢查：
調用者msg.sender應該是當前tokenId的所有者或被授權的地址
_from 必須是 _tokenId的所有者
_tokenId 應該是當前合約正在監測的NFTs 中的任何一個
_to 地址不應該為 0
如果_to 是一個合約應該調用其onERC721Received方法, 並且檢查其返回值，如果返回值不為bytes4(keccak256("onERC721Received(address,uint256,bytes)"))拋出異常。
一個可接收NFT的合約必須實現ERC721TokenReceiver介面：
transferFrom(): 用來轉移NFTs, 方法成功後需觸發Transfer事件。調用者自己確認_to地址能正常接收NFT，否則將丟失此NFT。此函數實現時需要檢查上面條件的前4條。
對於ERC-721智能合約， 元數據擴展(metadata extension) 是可選項(參見下面的注意事項)。這可以讓你的智能合約被訊問其名稱以及有關您NFTs資產的詳細信息
介面說明：
name(): 返回合約名字，盡管是可選，但強烈建議實現，即便是返回空字元串。
symbol(): 返回合約代幣符號，盡管是可選，但強烈建議實現，即便是返回空字元串。
tokenURI(): 返回_tokenId所對應的外部資源文件的URI（通常是IPFS或HTTP(S)路徑）。
外部資源文件需要包含名字、描述、圖片，其格式的要求如下：
對於ERC-721智能合約，枚舉擴展(enumeration extension)是可選的。這允許您的合約發布完整的NFTs列表並且使其可以被發現。主要目的是提高合約中NTF的可訪問性。
介面說明：
totalSupply(): 返回NFT總量
tokenByIndex(): 通過索引返回對應的tokenId。
tokenOfOwnerByIndex(): 所有者可以一次擁有多個的NFT, 此函數返回_owner擁有的NFT列表中對應索引的tokenId。
❺ 【ETH錢包開發04】web3j轉賬ERC-20 Token
在上一篇文章中講解了ETH轉賬，這一篇講一下ERC-20 Token轉賬。
【ETH錢包開發03】web3j轉賬ETH
1、直接用web3j的API
2、java／Android調用合約的 transfer 方法
不管用哪種方式來轉賬，你都需要先寫一個solidity智能合約文件來創建ERC-20 Token，然後部署合約，最後才是通過客戶端來調用。
注意：erc-20 token轉賬和eth轉賬的區別如下：
1、erc-20 token創建交易對象用的是這個方法 createTransaction
2、erc-20 token需要構建 Function ，它其實對應的就是erc-20 token合約中的那些方法。它的第一個參數就是ERC20中那幾個方法的名稱，第二個參數的話就是對應合約方法中的參數，第三個參數是和第二個參數對應的，按照我那樣就行了。轉賬的話就是 transfer ，我們從合約的 transfer 可以看到第一個參數是收款地址，第二個參數是金額，所以 Function 這里對應起來就好。
這種方法不需要使用web3j封裝的方法，而是直接調用solidity合約的方法。
步驟
1、web3j載入一個已經部署的合約
2、驗證合約是否載入成功 isValid
3、如何載入合約成功，則調用合約的 transfer 方法
注意：
1、這里的 TokenERC20 是根據solidity智能合約生成的對應的Java類，用於java／Android和智能合約交互的，如果你對這里不太清楚，不妨看看我之前的一篇文章。
以太坊Web3j命令行生成Java版本的智能合約
2、如果載入合約失敗，可能的一個原因是合約對應的Java類中的 BINARY 的值不對，這個值是你部署合約成功之後的bytecode，你最好檢查對比一下。
我發送一筆交易，可以通過這個地址查詢
https://rinkeby.etherscan.io/tx/
❻ 以太坊合約中一個合約是否可以調用另外一個合約
可以的，參考合約之間的交互。數字貨幣交易平台幣匯。比如我正試圖從另一個工廠合約中簽智能合約，然後重新部署新智能合約的地址。然而，它返回的地址是交易哈希值而不是合約地址。我相信這是因為當地址被返回時合約尚未開采。當我使用Web3部署智能合約時，它似乎一直等到智能合約被部署完成後才輸出合約地址。
❼ 以太坊的智能合約
智能合約是運行在計算機裡面的，用於保證讓參與方執行承諾的代碼，般情況下，普通合約上記錄了甲方與乙方各方面的關系條款，並通常是通過法律強制執行或保護的，而「智能合約」則是用密碼或密鑰來執行關系。以更加直接的角度來理解的話，即「智能合約」的程序內容將同-開始大家一起設定好的那樣百分百執行，並且零差錯。
舉個例子，以太坊用戶可以使用智能合約在特定日期向朋友發送10個以太幣。在這種情況下，用戶可以操作創建一個合約，然後將程序推人該合約中進行特殊計算，以便它能夠執行所需的命令。而以太坊就是專門把精力集中在這件事上的這么一個平台。
比特幣是第一個支持「智能契約」的資源幣種，因為網路的價值在於把價值或數據從一個點或人轉移到另一個點或人身上。節點網路只在滿足某些條件時才會進行驗證，但是，比特幣僅限於貨幣用例。相反，以大坊取代了比特幣那種帶有不小限制性的編程語言，取而代之的是一種允許開發人員編寫自己程序的語言。以太坊允許開發人員編寫他們自己的「智能契約」，即「自主代理」或「自治代理」，正如ETH白皮書所稱的那樣。該編程語言是「圖靈完備」語言，這意味著它支持一組更廣泛的計算指令。智能合約能做些什麼呢？
1.「多簽名」賬戶功能，只有在一定比例的人同意時才能使用資金。這個功能經常用在與眾籌或募捐類似的活動中。
2.管理用戶之間所簽訂的協議。例如，一方從另一方購買保險服務3.為其他合同提供實用程序。
4.存儲有關應用程序的信息，如「域注冊信息」或「會員信息記錄」。概念有時候比較晦澀，我們舉一個募捐的智能合約的例子來幫助理解：假設我們想向全網用戶發起募捐，那就可以先定義一個智能賬戶，它有三個狀態：當前募捐總量，捐款目標和被捐贈人的地址，然後給它定義兩個函數：接收募捐函數和捐款函數。
接收募捐函數每次收到發過來的轉賬請求，先核對下發送者是否有足夠多的錢(EVM會提供發送請求者的地址，程序可以通過地址獲取到該人當前的區塊鏈財務狀況)，然後每次募捐麗數調用時，都會比較下當前募捐總量跟捐款目標的比較，如果超過目標，就把當前收到的捐款全部發送到指定的被捐款人地址，否則的話，就只更新當前募捐總量狀態值。
捐款函數將所有捐款發送到保存的被捐贈人地址，並且將當前捐款總量清零。每一個想要募捐的人，用自己的ETH地址向該智能賬戶發起一筆轉賬，並且指明了要調用接受其募捐函數。於是我們就有一個募捐智能合約了，人們可以往裡面捐款，達到限額後錢會自動發送到指定賬戶，全世界的礦工都在為這個合約進行計算和擔保，不再需要人去盯著看有沒有被挪用，這就是智能合約的魅力所在。
❽ 以太坊的ABI編碼
ABI全稱Application Binary Interface, 是調用智能合約函數以及合約之間函數調用的消息編碼格式定義,也可以理解為智能合約函數調用的介面說明. 類似Webservice里的SOAP協議一樣；也就是定義操作函數簽名，參數編碼，返回結果編碼等。
使用ABI協議時必須要求在編譯時知道類型,即強類型相關.
當一個智能合約編譯出來後, 他的abi介面定義就確定了. 比如下面的智能合約:
生成的位元組碼:
生成的abi定義:
可以看出, 生成abi包含了2個定義: 函數 lotus , 事件 Log_lotus , 各個欄位含義見上. 根據該abi定義,就可以生成調用該智能合約函數的abi格式的數據了.
格式簡單的可以表示為: 函數選擇器+參數編碼
一個函數調用的前四個位元組數據指定了要調用的函數簽名。計算方式是使用函數簽名的 keccak256 的哈希，取4個位元組。
函數名如果有多個參數使用,隔開，要去掉表達式中的所有空格。在geth客戶端,通過命令可以得到hash:
由於前面的函數簽名使用了四個位元組，參數的數據將從第五個位元組開始。
根據參數類型,編碼規則有所區別:
除了bytes,和string, 其他類型的數據不足32位元組長度的需要加0補足32位元組. 動態長度的編碼在例子中介紹.
函數: function baz(uint32 x, bool y) :
調用: baz(69, true)
生成的數據如下:
返回結果是一個bool值，在這里，返回的是false:
函數: f(uint,uint32[],bytes10,bytes)
調用: (0x123, [0x456, 0x789], "1234567890", "Hello, world!")
函數選擇器: bytes4(sha3("f(uint256,uint32[],bytes10,bytes)"))
對於 固定大小的類型 值 uint256 和 bytes10 ，直接編碼值。
對於 動態內容類型 值 uint32[] 和 bytes ，我們先 編碼偏移值 ，偏移值是整個值編碼的開始到真正存這個數據的偏移值（這里不計算頭四個用於表示函數簽名的位元組）。
所以參數編碼數據依次為：
尾部部分的第一個動態參數， [0x456, 0x789] 編碼拆解如下：
最後我們來看看第二個動態參數的的編碼， Hello, world! 。
所以最終結果是:
❾ java中怎麼樣調用eth的智能合約
一般來說，部署智能合約的步驟為：
1啟動一個以太坊節點 (例如geth或者testrpc)。
2使用solc編譯智能合約。 => 獲得二進制代碼。
3將編譯好的合約部署到網路。（這一步會消耗以太幣，還需要使用你的節點的默認地址或者指定地址來給合約簽名。） => 獲得合約的區塊鏈地址和ABI（合約介面的JSON表示，包括變數，事件和可以調用的方法）。(譯註：作者在這里把ABI與合約介面弄混了。ABI是合約介面的二進製表示。)
4用web3.js提供的JavaScript API來調用合約。（根據調用的類型有可能會消耗以太幣。）
❿ 以太坊智能合約開發：讓合約接受轉賬
在以太坊智能合約開發中，通常會有向合約地址進行轉賬的需求，那麼有幾種向合約地址進行轉賬的方式呢？
有三種方式：
部署合約時轉賬
調用合約提供的方法
直接向合約地址進行轉賬
但有一個問題，以太坊的智能合約默認是拒絕來自任何地址的轉賬，那麼如何讓合約能夠支持接收轉賬呢？
1、部署轉賬
在進行合約開發時，如果想要在部署時，直接向該合約進行轉賬，只需要給構造函數中添加payable修飾符。
示例：
2、執行合約轉賬
執行合約轉賬，則需要給你需要支持轉賬功能的方法添加payable修飾符
示例：
3、直接轉賬
支持直接轉賬，需要藉助後備函數(fallback function)，只需要為後備函數添加 payable 修飾符
示例：