部署你的第一個智能合約


#1

教程原始來源


譯者: Kimi Sian-Yu Chen
譯者註:請於試驗環境中學習本教程, 建議ETC錢包餘額小於1ETC.
若有疑問處, 可以先參考原文

介紹

已經有很多智能合約的範本你可以在ETC上使用, 但對於一些簡單的智能合約來說, 你甚至不需要自己撰寫程式碼.

你有多重簽名錢包, IoT proof of concepts, ERC 223 tokens (and https://tokenmint.io/), OpenZeppelin’s suite of useful contracts, 還有更多你想部署的智能合約範本其實目前都可以取得.

對於本範例來說, 我們打算部署一個多重簽名錢包, 而且我們會認真的全面性看待替代方式與可能的問題, 都盡量能被討論.
其實並不是那麼的困難, 只是有些事情, 例如合約部署, 在以太坊的生態環境中仍須持續被完善.

而且在本範例中, 我們也不打算修改任何程式碼.
你只需要做一件事, 透過本範例學習部署智能合約, 讓部署變得簡單, is hard-code your constructor arguments rather than declare them during deployment.

你的合約建構子簽名就像下面這樣

function MyContract() (empty)

而不是這個

function MyContract(address myAddress, uint256 someNumber) (non-empty)

你也可以參考我的Commit歷史(作為範例),
(https://github.com/pyskell/multisig/commit/3cf29ab5381d6ce1c59506c766e11a6ee6e1aa41)
將一個非空的建構子轉換成一個空的建構子.
這相當簡單, 僅僅刪除參數與寫死變數.

你也許會得到一些益處(透過unrolling一個迴圈), 並節省計算cycles/gas.

為什麼需要一個空的建構子

以當前背景來說, 當前開發的複雜可歸屬於下列原因

Parity:

  • 其合約部署, 不支持任何硬件簽名
  • 支持建構子參數

MEW:

  • 其合約部署, 支持任何硬件簽名
  • 不支持建構子參數

Classic Ether Wallet (縮寫:CEW ):

  • 其合約部署, 支持任何硬件簽名
  • 支持建構子參數 (except arrays)

所以基本上使用CEW與合約(具有空的建構子)是最好的選項,
以上給我們最彈性的部署與金鑰存儲選項.
另一個好處是透過空的建構子可以讓其他人重製同樣的bytecode (and assure themselves that the code deployed matches the code as written).

先從範例程式碼開始

我們先使用多重簽名作為範例, 它具有實用性與比部署simple token contract困難
讓它實際成為一個部署智能合約的好例子.

我們使用的範例程式碼放置於 https://github.com/pyskell/multisig
這是基於OpenZeppelin的多重簽名錢包.

Disclaimer: The example code provided here is for EXAMPLE only. If you deployed the code as it currently exists then you would create a multi-sig with several ETC community members as the approved signers. For obvious reasons you don’t want strangers in control of the funds in your multi-sig wallet. If you want to use this code for a real multi-sig then you should be able to find the few areas you need to modify, if you cannot then you should not be using a multi-sig.

免責聲明: 本範例程式碼僅限用於"範例", 這個程式碼會產生一個多重簽名(多個ETC社區成員)
明顯的, 你一定不想在你的多重簽名錢包內讓陌生人來控制你的資金.
如果你想用本範例來做一個多重簽名, 你應該必須找到需要修改的地方.
如果你不會修改, 則不應使用本範例作為多重簽名使用.

安裝 Truffle

Truffle是一個簡單且超棒的合約測試與編譯工具.
你可以在這裡參考Truffle的安裝方式(http://truffleframework.com/docs/getting_started/installation)
請在安裝完後, 回到本教學.

創造你自己的移轉

如果你夠熟悉其他程式語言的移轉, 這裡有點相同.
基本上你只要告訴Truffle

  1. 所有檔案的位置,
  2. 要編譯什麼
  3. 要做什麼
    如果你使用Truffle來部署, 則我們不需再做其他事情.

我們跳過了一些步驟, migrations如名義上也用來測試與部署本地/遠端測試網路.
你也許想要多個migrations在同一個專案內,針對不同的目的.
但在本示範中, 我們只需要一個migrations/1_initial_migration.js

看起來應該會像這樣子, 並且告訴truffle哪一個檔案你想要編譯.

var DayLimit = artifacts.require("./DayLimit.sol");
var MultisigWallet = artifacts.require("./MultisigWallet.sol");
var Multisig = artifacts.require("./Multisig.sol");
var Shareable = artifacts.require("./Shareable.sol");
var Migrations = artifacts.require("./Migrations.sol");

你所有的合約都應放置於 contracts/資料夾

為了實際編譯全部檔案, 你只需要在終端機內鍵入truffle compile , 在你的專案子目錄中.

Truffle會尋遍你的 contracts/ 資料夾的所有檔案並產生相對應的.json檔案.
所有產生的檔案都會放置於build/contracts/ 資料夾內, 你會在此資料夾內找到你想部署合約的bytecode內容.

Just FYI: Migrations (migrations/) are executed in file order from the file with the smallest number in front of it to the largest.

部署你的合約

Ok, 你可以編譯好程式碼且已經準備好開始部署.
對於很多開發工具來說, 這是做簡單的一個步驟, C#幫你做好安裝檔, JAVA幫你打包成單一 .jar檔, 而且大部分的應用軟體可以執行./application.
在ETC上面(同ETH), 這有點麻煩, 你需要把剛產生的bytecode內容丟到 https://ethereumproject.github.io/etherwallet/ 來部署.

之前提到我們之所以使用CEW有兩個原因

  1. 我們可以使用硬件錢包簽署, 這幾戶是一個必須,尤其是任何合約都需要權限可以被你的key pair修改, 在這麼案子裡是多重簽名
  2. 我們因為從合約中移除建構子, 而CEW支援此功能.

為了部署這個合約, 請至 https://ethereumproject.github.io/etherwallet/ 並點選 “Deploy Contract”

現在打開 build/contracts/MultisigWallet.json 檔案, 並尋找 bytecode 欄位.
你可以打開這個文健使用你喜愛的編輯器.
把文件內bytecode 欄位的內容拷貝到CEW的 “Byte Code” 欄位內.

你使用這個檔案的目的在於這是你的主合約, 這包括了其他的相依合約在內.
對於不同的合約部署, 會有不同的需求, 可能是單一個不同合約,或是多個不同合約部署到他們各自的地址.
如果你正在部署一個複雜的合約程序,建議參考合約的說明文件.

當你把bytecode貼進去時, 請在CEW內按下Estimate gasLimit, 他會給你一個預測的價格來部署合約.
以本範例的情況使用了180萬的Gas上限.
這個上限應該ok, 如果發送合約失敗的情況下, 你可以將Gas上限稍微提升.

image

確保你的Gas價格(在CEW的右上方)合理的低 (對於大型的合約來說), 才不會讓你付了太多.
除此, 你也可以總是支付比較高的Gas價格.

當你要發送合約時, 請確保你選擇了正確的網路 ( 請選擇ETC網路) 笑

你可以根據熟悉的方式來簽署與傳送這個交易.
即使你進行一個多重簽名的動作, 你也可能想要使用一個硬錢包.

成功部署!

如果你已經照上面的指示與過程進行了, 你的合約已經被部署到了一個新的地址. 有趣的是, 這個地址是根據你的公開錢包地址+隨機數. 去預測一個部署位置基本上是可行的. 你甚至可以寄送資金至一個未使用的合約位置, 然後再部署一個合約來取取回他們.

但我離題了, 希望你可以學到更多, 但我寫得並不是很好. 若你有任何問題, 請直接回覆本文.


#2

Introduce

There are many smart contract templates that you can use on ETC, but for some simple smart contracts, you don’t even need to write your own code.

You have multiple signature wallets, IoT proof of concepts, ERC 223 tokens (and https://tokenmint.io/), OpenZeppelin’s suite of useful contracts, and many more smart contract templates that you would like to deploy are currently available.

For this example, we intend to deploy a multi-signature wallet, and we will seriously consider the alternatives and possible problems in a comprehensive way. We will try to be discussed as much as possible.
In fact, it is not that difficult. It is only that some things, such as contract deployment, must continue to be perfected in the ecological environment of Ethereum.

And in this example, we do not intend to modify any code.
You only need to do one thing. Learn the deployment of smart contracts through this paradigm and make the deployment easy. It is hard-code your constructor arguments rather than declare them during deployment.

Your contract builds a sub-signature like the following

Function MyContract() (empty)

Not this

Function MyContract(address myAddress, uint256 someNumber) (non-empty)

You can also refer to my Commit history (as an example),
(https://github.com/pyskell/multisig/commit/3cf29ab5381d6ce1c59506c766e11a6ee6e1aa41)
Convert a non-empty constructor into an empty constructor.
This is quite simple, just delete the parameters and write-dead variables.

You may get some benefit (by unrolling a loop) and save calculations/gas.
Why do you need an empty constructor

In the current context, the complexity of the current development can be attributed to the following reasons:

Parity:

Its contract deployment does not support any hardware signature
Support for constructing child parameters

MEW:

Its contract deployment supports any hardware signature
Does not support construction of sub-parameters

Classic Ether Wallet (abbreviation: CEW):

Its contract deployment supports any hardware signature
Support for except arrays

So basically using CEW and contracts (with empty constructors) is the best option,
Above gives us the most flexible deployment and key storage options.
Another advantage is that through empty builders it is possible for others to reproduce heavy bytecode (and assure themselves that the code disclosed matches the code as written).
Start with the sample code

We first use multi-signature as an example. It has practicality and is harder to deploy than simple token contract.
Let it actually be a good example of deploying smart contracts.

The sample code we use is located at https://github.com/pyskell/multisig
This is a multi-signature wallet based on OpenZeppelin.

Disclaimer: The example code provided here is for EXAMPLE only. If you deployed the code as it currently exists then you would create a multi-sig with several ETC community members as the approved signers. For obvious reasons you don’t want strangers in control Of the funds in your multi-sig wallet. If you want to use this code for a real multi-sig then you should be able to find the few areas you need to modify, if you cannot then you should not be using a multi- Sig.

Disclaimer: This sample code is for “examples” only, this code will generate a multi-signature (multiple ETC community members)
Obviously, you don’t want strangers to control your money in your multi-signature wallet.
If you want to use this example to do a multi-signature, you should have to find where you need to modify it.
If you do not modify it, you should not use this sample as a multi-signature.
Install Truffle

Truffle is a simple and awesome contract testing and compilation tool.
You can refer to Truffle installation here (http://truffleframework.com/docs/getting_started/installation)
Please return to this tutorial after installation.
Create your own transfer

If you are familiar with the transfer of other programming languages, this is a little bit the same.
Basically you just tell Truffle

The location of all files,
What to compile
What to do
If you use Truffle to deploy, then we don't need to do anything else.

We skipped some steps, and migrations are nominally used to test and deploy local/far-end test networks.
You may want multiple migrations in the same project for different purposes.
But in this demonstration, we only need one migrations/1_initial_migration.js

It should look like this, and tell the truffle which file you want to compile.

Var DayLimit = artifacts.require("./DayLimit.sol");
Var MultisigWallet = artifacts.require("./MultisigWallet.sol");
Var Multisig = artifacts.require("./Multisig.sol");
Var Shareable = artifacts.require("./Shareable.sol");
Var Migrations = artifacts.require("./Migrations.sol");

All your contracts should be placed in contracts/folders

In order to actually compile all the files, you only need to type truffle compile in the terminal in your project subdirectory.

Truffle searches through all the files in your contracts/folders and generates the corresponding .json file.
All generated files will be placed in the build/contracts/ folder. You will find the bytecode contents of the contract you want to deploy in this folder.

Just FYI: Migrations (migrations/) are executed in file order from the file with the smallest number in front of it to the largest.
Deploy your contract

Ok, you can compile the code and you are ready to start the deployment.
For many development tools, this is a simple step. C# helps you to do the installation. JAVA helps you pack it into a single .jar file, and most applications can execute ./application.
Above ETC (with ETH), this is a bit tricky, you need to throw the bytecode content just created to https://ethereumproject.github.io/etherwallet/ to deploy.

We mentioned earlier that we use CEW for two reasons

We can use the hardware wallet to sign, which is a must, especially if any contract needs permission to be modified by your key pair. In this case it is a multi-signature.
We remove the constructor from the contract, and CEW supports this function.

To deploy this contract, please go to https://ethereumproject.github.io/etherwallet/ and click “Deploy Contract”

Now open the build/contracts/MultisigWallet.json file and look for the bytecode field.
You can open this Wenjian using your favorite editor.
Copy the contents of the bytecode field in the file into the “Byte Code” field of the CEW.

Bytecode_example
Bytecode_example.png1756x569 82.9 KB

The purpose of using this file is that this is your main contract. This includes other dependent contracts.
For different contract deployments, there will be different requirements. It may be a single different contract or multiple different contracts deployed to their respective addresses.
If you are deploying a complex contract procedure, it is recommended to refer to the contract’s documentation.

When you paste bytecode in, please click on Estimate GasLimit in CEW. He will give you a predicted price to deploy the contract.
The 1.8 million Gas ceiling was used in this sample scenario.
This limit should be ok. If the contract is sent out in a failure, you can increase the Gas limit slightly.

Image

Make sure that your Gas price (in the top right of the CEW) is reasonably low (for large contracts) that won’t make you pay too much.
In addition, you can always pay higher Gas prices.

When you want to send a contract, make sure that you select the correct network (Please select ETC network)

You can sign and send this transaction in a familiar way.
Even if you do a multi-signature action, you may want to use a hard wallet.
Successful deployment!

If you have followed the above instructions and process, your contract has been deployed to a new address. Interestingly, this address is based on your public wallet address + random number. To predict a deployment position is basically feasible You can even send funds to an unused contract location, and then deploy a contract to get them back.

But I digressed, I hope you can learn more, but I did not write well. If you have any questions, please reply directly to this article.