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)
Function MyContract(address myAddress, uint256 someNumber) (non-empty)
You can also refer to my Commit history (as an example),
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:
Its contract deployment does not support any hardware signature
Support for constructing child parameters
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.
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.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.
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.
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.