An error in a smart contract can cost the founder of the project who decided to hold the ICO, the trust of investors and all the money collected, and the developer - the reputation. Correctly organized ICO - like a fighting machine, the design of which does not tolerate flaws, and the smart contract itself should work like a good Swiss watch. In recent years, the developers have accumulated experience, and, quite bitter. Therefore, starting to create a smart contract - it is worth paying attention to already existing postulates.
Many specialists write very sensibly about blocking technologies and, in particular, about the specifics of smart contracts and ICO in general. But the submission of material is often quite difficult to understand. Therefore, I took the liberty of adapting the material found on Habré, so to speak, to a wider audience.
Pros even without me will understand, and the rest, I think it will be useful to get a basic understanding of smart contracts and the organization of ICO from a technical point of view.
Technical task
It all starts with a simple, at first glance, a task from the founders of the project who want to conduct a crowd scale and gather from investors as much development money as possible and to themselves for a cup of coffee.
As a rule, the task is reduced to the release of an equal number of tokens and their sale to investors at the current exchange rate to the air. And, often, specific parameters are not immediately given. The customer believes that he can think about and issue them right on the night before the ICO.
For some reason quite self-conscious in the blockbuster technologies people think that the parameters of the smart contract change "on the fly" at any moment. Therefore, it is important to convey to them the understanding that this is not entirely true. It is important to work out the economic model at once so that later nothing can be changed at the last moment.
It is necessary to get and fix all the constants on paper so that they can be used immediately for development. The more complex the terms of the contract - the more tests will be required taking into account specific parameters. At the slightest change, everything will have to be tested again. And only then spread open code on GitHub.
As an option - you can write together with the customer such a history of the interaction of a smart contract with an investor.
It can look like this:
1. The investor translates to the address of the smart contract a certain number of aether and receives tokens in return.
2. The next day the beneficiary (the customer) sends an instruction from the personal address, according to which the price of the token will change.
3. In the future, the next investor sends the air and receives a different number of tokens than the first investor.
4. Another investor also sends the broadcast, but the tokens have ended or are less than what is supposed to be given out to the amount sent. Then the air is returned in full or the change is given.
Only in this way can you be sure that the developer understands the customer correctly.
If there is a feeling that the founders of the project themselves do not know exactly how interaction should be organized - it is worthwhile to invite them to think carefully, and only then to continue the joint discussion. Otherwise, you can spend a lot of time for a gift, and do not come to the end result.
In principle - most developers and so understand that without a good TK the required result will not work. Each time, he will develop his own algorithms of interaction with customers. Therefore, it is worth going to the main part.
Errors that should not be allowed
Do not forget that a smart contract is a public code, and everyone should be able to look into it, and with a smart kind of poke a finger into a piece of code that is not clear to him. Therefore, if there are, so to speak, doubtful moments in the contract (which should not be), the developers and founders of the project should be ready to answer "inconvenient" questions. And if the contract will allow you to additionally release a certain number of tokens (which, for example, contradicts promises) or, even more, transfer tokens to another address before the end of the ICO - investors will certainly have suspicions (among literate ones).
What can we talk about?
Issue additional number of tokens after a token. Nobody will like it if the beneficiaries have, hypothetically, the opportunity to generate "+100500 million tokens", sell them, and go on vacation to the Bahamas. If the smart contract still allows the possibility of additional release of tokens - this should be in advance justified in White Paper.
The possibility of transferring funds by only one beneficiary. In other words, the lack of a multi-signature function. And exactly - can you trust your hard-earned $ 5000, so hard earned on Bitcoin's growth rate, only one beneficiary's computer? Yes, let him be at least a Pope and collect for a new church, but the greedy hackers will not stop the holy crucifixion. Therefore, it is so important to transfer funds was possible only through several signatures. Otherwise, the received millions can easily be presented to some Vasya from 5B.
By the way, there is a significant difference between the multi-signature for the Bitcoin address and the multi-tag contract in Ether. If you need to generate a transaction from Bitcoin's multi-sig-address in order to create a transaction offline - by creating a file, having strolled with a flash drive on the computer, then you need to send several transactions from different machines to withdraw funds from the multisign contract to Etherium. Frequently given conditions allow you to make a transfer when you receive a contract with 2 out of 3 signatures in the form of transactions.
And one more important point - to create a multisign contract is not a problem, but in order for all the clients used for this to display actual figures, it is necessary that one of them be a complete node.
The release of tokens or their forced transfer to the team. The absence of conditions in the code on the time of withdrawal of funds can be safely considered a bad form. At a minimum, for the token-day period, all transfers must be impossible.
The absence of a contract for GitHub. Public access to the code is already a necessity a priori. And, it is laid out it should be, at least, a few days before the sale of tokens. Nothing to add to it a couple of hours before the start of the ICO should not be. And then it will look like this: "Wait, wait - I've here forgotten... Everything - now throw me with your millions." The matter is that it is desirable, that before the start the contract was evaluated by specialists. And the changes after the audit will not add credibility. Ideally - the publication of the contract for the month. And no changes. Hasty edits issue amateurs. Therefore, before the publication - a lot of tests and audit of professionals.
Hence it is clear that whether you are a developer, financier or professional investor in the ICO - you should definitely understand the code of the smart contract, and therefore know the language of Solidity. Even if you are not a developer, you need to know the basics, in any case. To develop the ideal smart contract, you need a competent financier and a gifted developer - and it's better if it's the same person.
And finally - be attentive to the timestamp (timestamps that program a contract for certain actions at a certain time). No one really wants a smart contract to be stuck at a certain stage or to close a token? The price of the error is very high.
Deploy
Let's say all the details are taken into account - and it's time to deploy a smart contract on the network. In other words, "embed" it.
To do this, you must send a large transaction from the Ethereum client that contains the smart contract code. This is equivalent to directing the network to place a contract at a specific address. Through the address, users can refer to the contract.
In fact - the contract is a kind of automated wallet, which has its balance, and which can receive and send the air. In general, the same equal participant in the network.
Everything works simply - if you send the sum to the address of the contract on air, it will make a calculation and send back a certain number of tokens. After that, the miners will include this information in the next block and thus execute the contract and the transaction from the user.
Remember that you can not change the contract after the game - you can only create a new code and place it at a different address.
Okay - we should admit honestly that everything is not so scary. In fact, there is an opportunity to make edits. For this, a contractor-controller is provided, which stores the addresses of the remaining simple contracts.
In this case, users send funds to the contractor-controller, and already he redirects to any other contract. Therefore, the old one can be replaced with a new one. Thus, developers can correct the error by simply creating a new code and changing the address in the main contract. And, as a rule, complex systems of smart contracts without supervisors are not made.
But, at the same time, nothing prevents the developers at any time simply to replace the contract for a more profitable for themselves. In general, the reverse side of the coin, which can alert investors. No one will like it. And in general - complex systems, where one contract causes another, are more vulnerable.
Therefore, it is better to take into account all the nuances immediately, to make one contract, and then nothing in it to change. More confidence will be.
Remember that a banal typo in the dates may turn out that at a certain stage the contract will simply block the funds, and no one therefrom will no longer reach them.
The controller will create a new contract - but how will all this look in the eyes of investors who will draw conclusions about the developer's competence?
Also, keep in mind that the more complex a contract is, for example, if it allows one user to present a "secret" given to him by another user and get a bonus to tokens - the more risks there are. This is often used when referral programs and bonus discounts are used in the token.
In this case, an incorrectly drawn up contract can contain logical holes and allow the creation of a chain of investors who in turn earn bonuses on their own, cyclically "selling" themselves.
In addition, such algorithms require additional calculations and, accordingly, more significant gas consumption. And the more difficult - the more expensive transaction.
In other words, the additional complexity is more vulnerabilities and a headache.
Investor's personal area
Yes - personal cabinet ... Many people have the question - how much is it needed? If the case for the blockbuster Efirium was limited only to translations on air - then, probably, this would be a complete excess. Let's just say, "commercial ponty."
Without investments in other crypto-currencies and, especially, Fiat - the purse of the ether would come up as the best personal cabinet of the investor. There to him and protection, and confidentiality, and convenience. Transaction history, backup, and all the other buns right out of the box. You just need to specify the address of the smart contract on the website and wait for receipts. Beauty. Even with a smart contract, you do not need to fool around - take the finished option, run it by yourself and the deal is ready. So think about all the benefits of fees on the net.
But not everything is so simple in the world of finance and block-technologies. Some met only Bitkoyn, got their address from the fifth attempt and shook hands transferred there from the Savings Bank $ 300 blood. And some people have just decided to get acquainted with the world of crypto-currency and want to transfer to the account of beneficiaries from a bank card or an electronic system, like PayPal. How to be?
That's where you need a personal cabinet. With an interface, payment options, instructions and a beautiful balance display. And maybe even KYC as it should be in civil countries to screw? Well then, full of openwork. But for all this will have to work. And this, let's say, goes beyond the simple development of a smart contract.
You need to understand the web technologies and, especially, protect the site from phishing attacks. It is better to use only static HTML - the minimum of security holes and DDoS to lay it is also not easy. Therefore, the client is more likely to be phishing to a fake site somewhere at the level of substituting certificates or just dropping the link in the chat.
Okay, let's leave for the phishing at last and understand what is required for our dear investor to make a translation, for example, in bitkoinah.
To begin with, you need to show him where to transfer the bitcoins. That's why we need an office where the user will indicate his etherium address. Yes - without it, in any case, we will not do. Because tokens on the air can only be charged to the etherium address. In the office, you can provide an instruction or an opportunity to generate a purse directly, so to speak, without departing from the ticket office.
To do this, you can create the key pairs yourself and give it to the investor, so that he can open them, for example, MyEtherWallet. But it still requires specific actions from him, and you need to prove to him that you yourself do not see these keys. It's easier to give him instructions - how to make a purse. After that, he will indicate the addresses - from where they come (BTC) and where to put (ETH). Everything should be stated correctly - it is in his own interest. Otherwise, well, that's his problem ...
Now you need a script that will monitor Bitcoin's blocking system, or any other, on a schedule, in search of a transaction from a familiar address to the one you specified. The translation came - the script communicates with the Ethereum node, from where a transaction is sent to the smart contract calling the mint (address addr, uint amount) method. In other words, the contract is instructed to send a specific number of tokens to a particular address. The method is suitable even for such payment systems as VISA or MasterCard - if, of course, there is access to the log of their payments.
And if with the smart contract itself, the script and the interface of the personal cabinet, as a rule, there are no problems, then everything is difficult with protection from hard-core Khatskers.
Understand - a successful ICO will attract not only the attention of intelligence agencies but also various kinds of intruders who are very eager to grab a savory piece of this delicious pie. Or even take possession of it completely. They know for sure that the game is worth the candle (balance of fees in sight). And they are fully armed. And you?
They just need to access the admin panel of the site and replace only one line by sending investments to their address. And it does not matter that then, in order to withdraw funds, they will have to hire an army of goblins for naked - they will find ways, it would be something to cash in. And the site with collections of a million dollars, they will press all that they can - from Trojans that can replace the address directly in the buffer when copying to large-scale DDoS attacks. This can be a real war, which you will not even notice if the security is on top. Or you find out that you lost when it's too late.
Therefore, if you want to take fewer risks - collect only on air. The best investor's office is Ethereum Wallet. Severely and trivially - do not twist the holes in the decorations of the site. Serious people - not to face.
And remember, even with better protection, do not relax. You should have a ready-made script for the main types of problems. For example - it's DDoS, the invasion of phishers in the chat rooms or even breaking the contract. All should be ready - from developers to SMM-specialists.
But that your team is not on duty in shifts at the monitors (which, of course, is desirable), especially since some ICO's are from several months to a year - automate the process. Well, let at least a simple script will go to the site and check its operability, as well as the presence of the correct address for transactions of investors. Monitor the blockade - after all, the outgoing transaction from the address for charges before the due time indicates a successful attack. In other words, is something wrong? Then a battle alarm - and forward saving the investors' funds and own reputation.
Conclusion
Therefore, it is so important not only to audit the smart contract but also the entire crowdsale-combine. It really should be a fighting machine and nothing else. Over time, this, of course, will become an established scheme and, in all likelihood, this concern will be taken care of by the designers of the ICO. Perhaps even insurance will be offered. But while many prefer to do it on their own - and all responsibility lies solely with them. This responsibility is not only for the fate of its ICO but also for the reputation of blocking technologies in general. Remember this.
