Technical features of the ICO. Start

Hi, Habr! Today my story will be about the technical experience of conducting an ICO on the Ethereum platform before and during the ICO. I have participated so far in a small number of projects, but have already managed to collect some technical background. I bet the technical roadmap to hold an ICO for the Habr audience will be interesting. I ask under kat all interested.

Crowdsale economic model preparation

It all starts with a customer who wants to spend crowdsale. Although the task “release us N tokens and let your contract sell them at the rate of X to air” seems quite clear and simple, often specific parameters are given in the mode “we are not sure now, but we will tell you before the ICO”. Very often the customer knows only what he is willing to give for his tokens, but he doesn’t think at all how he will distribute them, and he believes that the number of tokens, dates, the size of discounts for sale are such free parameters, you can freely turn them some admin and secure the contract the night before the ICO. In fact, this is not the case, and in real life it is necessary to take into account the risk of even a trivial typo. Remember that you are dealing with a smart contract that cannot be corrected, once you have been arrested. And you have a great opportunity (confusing, for example, dates) to roll out a contract, which at some point fills up all the funds of users - and you will never get them.

For example, you write something like this in each function:

require(currentTime > icoStartTime); 

Thereby prohibiting any operations with the contract outside the time limits specified in the deployment. In this case, a misprint for a delay can be quite expensive, especially if she stops the contract not at the very beginning, but somewhere in the middle. Of course, you can secure a new contract if you have provided for a controller contract, but you have to correct your own shoals made by carelessness in front of investors. And those who are watching your work, in which you tritely mixed up the dates, will draw their own conclusions.

Many models have subtle points regarding bonuses and referral programs. Referral programs are especially good when, upon presentation of a certain secret from one user, another user receives a bonus to his tokens. Such things work well in conventional systems in which the order of transactions is determined on a single server and there is a database of all users. When implemented in a smart contract, such a program:

• may contain logical holes that are often invisible when first viewed, for example, it allows you to create a chain of investors who in turn earn bonuses themselves for themselves, cyclically “selling” themselves;
• it requires programming additional calculations, not very complex, but still more voluminous than simply assigning N tokens to the address. And these are additional gas costs, and the more cunning the customer’s algorithm, the more expensive the transaction sent to your contract will be.

Any additional calculations are a potentially vulnerable spot, arithmetic overflows in smart contracts are a reality.

Therefore, the study of the economic model is the most important initial step. It ends with the fact that the paper is fixed specific task for the development. And try to get all the constants at once - and use them immediately during development. 90% of the code that you have to write are contract tests, and their number strongly depends on the number of periods, discounts, etc. If the customer comes to you the evening before the GitHub contract is published, he says that he decided to spend the ICO for a year and every day, reduce the discount by 0.1% instead of the previous version with three periods - you have to rewrite all the tests.

As for me, it is best to ask the customer to start submitting the task in the form of a user-story about the investor and the beneficiary. The hypothetical investor on the first of September transfers the sum of N air to the contract address and receives M tokens. On September 2, the beneficiary sends instructions from his personal address to change the course of the tokens and issue X tokens in one ETH. On September 3, the second investor sends N air and receives another amount of tokens. The third investor sends N air, but the tokens have run out, so he gets as much as he has left, and the delivery on the air returns to him. In some similar form, squeeze out a customer story like this to accurately understand what you mean the same thing.

Pre-lay time for the first stage. You can sit with the client for five or six hours, repeat such gatherings a few more times and never come to a consensus. If you want to do everything correctly and efficiently - it may be worthwhile after the first fruitless meeting to politely ask the client to first take a good, several days to consider and write out all aspects with his team - and only then spend money and time on development.

Well, let's finish the first section, experienced developers, he is familiar with as "without good nz result xs."

If you do not even in general imagine the launch of a smart contract to work

Scroll through this small section if you have already deployed at least one contract: this is another attempt to briefly explain the essence of launching the contract into work.

Depla is as follows. You send a very large transaction from your Ethereum client, which contains the smart contract code. You say to the Ethereum network: “Put my smart contract at a certain address. With this address, users will access the contract. ” It’s as if you are posting your version of the site on the Internet, and it starts working at no address. It is impossible to overwrite another contract in the place of a secured one, no code is corrected, it is possible only to place a new version of the contract at a different address. The contract as an ordinary member of the network has its own balance of the ether and is able to receive and send air, a kind of “automated wallet”. If you just send money to him (of course, if such a scenario is provided for in the contract), then his balance will increase. If you send 10 ETH and in the corresponding method in the contract you do not break, you will receive +10 ETH on the balance of the contract. In the case of a crowdsale contract within a smart contract, the function that accepts ETH multiplies the amount received by the current token rate and assigns the corresponding number of tokens to the sending address. In fact, he simply writes information into the blockchain that this address needs to charge so many tokens.

For example, the number of tokens, which is issued to the ICO, is just the program data. More specifically, token balances are values ​​in an associative array, where the keys are Ethereum addresses. Transfer of tokens from one participant to another can be viewed as a call to the transfer method of a smart contract placed at a given address, which will take some of the tokens from one address and add to another. These changes in the program's memory will be recorded in the next block by the miner, who will execute the contract and the transaction that came into it from the user.

One of the features of programming in this area is data publicity. Do not forget that any data that you transfer to any function of a smart contract is open. For example, you cannot simply play “rock, paper, scissors” by stupidly sending your choice to a contract. If you do this, then you can spy on the previous transaction and send yours, taking into account what you see. Therefore, the programming algorithms of any sweepstakes, auctions, etc. are always multi-pass. First, all parties should submit the hashes of their decisions - and only after that they should publish the decisions themselves, which we no longer refuse.

Another problem is the order of transactions. The fact is that the miner is able to see what kind of transaction came, and quickly generate his own with a higher commission, thus placing it in the block above the original one. So these points should be paid attention to when designing your decentralized service and the crowdsale procedure.

Technical aspects of the development of smart contracts in Ethereum

The contract code laid out in the Ethereum blockchain is available to everyone, but with reservations. In fact, after the “create_contract” transaction is minimized, only the contract byte-code will be available in the blockchain, and for it to be beautifully presented, for example, like here , you need to pass the verification of the contract. And this is, in general, a rather dreary procedure. Just bullet dozens of contracts a day without special tools you will not succeed. Well, investors are unlikely to want to throw money into an unverified contract, whose code cannot be read, so the need for verification is obvious.

Publishing the source of the smart contract means that anyone can see the entire contract interface and make sure that it is not deceived, the tokens are not taken away, the beneficiaries are not overcharged, etc. Let's not forget what the decentralized execution systems of smart contracts are created for. - this is just a public placement of software code in such a way that its execution is undeniable. Therefore, if you have a “interesting” function in the contract, with the help of which you can add an arbitrary number of tokens or transfer any number of tokens from one address to another, then for all investors this will cause inconvenient questions for you. Not a single operation with tokens can be hidden, because each transaction and each action performed by it in the contract are recorded in the blockchain of the broadcast.

I would bring a few such features; they raise legitimate questions for those who read the contract code of investors, which can greatly undermine the credibility of your project.

Feature 1 - additional tokens after ICO. If you in White Paper did not substantiate the token issue after ICO, then the function that creates N tokens for any address that works after the ICO period is the ability of the beneficiaries to make 100500 tokens at any time and dump them on the stock exchange away. Trust in your crowdsale will not add it.

Feature 2 - withdrawal without multi-signature. Should the project put all the air and other currencies on wallets, the output from which is possible from a single computer? And the point here is not even in the decency of the beneficiary or in the safety of Ethereum. Even the pope, collecting funds for a new church, can take advantage of a vulnerable laptop. And I remind you that in the case of ICO, a successful attack on a computer with secret keys to the address to which funds are collected sometimes brings millions to the attacker. So welcome to the 21st century: With the development of a crypt, the PC becomes a very attractive target for hackers. And the fact that the beneficiaries did not think about it and did not provide their addresses with a multi-signature can also cause mixed feelings among investors.

By the way, for you to be in the know: BTC output from Bitcoin multisig addresses and ETH output from a multisig contract on the Ether are things that are technically very different. In Bitcoin, in order to deduce BTC from a multisig address, it is necessary to form a transaction with several signatures in advance, having walked with a flash drive on all the signing computers. And in Ethereum, you must first put a multisig contract on the network and, after the ETH appears on it, send several transactions to it with the required number of computers. That is, on the Ether, signatures are sent by separate transactions, and the ETH is sent to the address specified in advance at the moment when exactly the required number of valid signatures arrive, for example, two of the three.

Be sure to pre-arrange (several days) take care of multisig addresses. Creating them from various clients like Ethereum Wallet for Ethereum and Electrum for Bitcoin is a simple task, but you need to take care not about the address itself - it’s really easy to create a multisig, but to at least one of the multisig computers (and this can be a zoo from a new MacBook owner'a, an ancient mastodon laptop weighing 7.5 kilos and an accidentally accumulated new laptop five years ago in the IT department) was a complete and current Ethereum node that would have time to catch up and process new blocks when launched quickly, in a matter of minutes, otherwise you are in none of This multisig client will not see the actual numbers.

Feature 3 - the absence of a contract code on GitHub laid out within a reasonable time before ICO. If by activity on GitHub it can be seen that you committed a heavily modified contract on the last night before the ICO, then there are good reasons to believe that it was being prepared “on the knee”. And this means that, most likely, you didn’t conduct an audit or you have requested something after the audit, potentially adding new holes. In an ideal world, you publish the contract code a month before the ICO - then you can have time to audit the code, declare bug bounty (as it was specially created for ICO, because the owner has a secret weapon - tokens that he can very generously distribute) .

The verified code published on the blockchain should appear a few days before the ICO. In general, if you send a bunch of ether to some address, it would be nice to still look at this address in etherscan and make sure that this is the very crowdsale contract. I would advise everyone, whether you are a developer or not, to look at the contract code, even if it is not very clear. In a good contract there are normal comments that are understandable, and the language itself is quite clear to almost any developer.

Feature 4 - any interesting additional functionality such as additional token issuance, their forced transmission at the owner’s command, etc. For example, the possibility of early withdrawal of funds if the function broadcasting to the beneficiaries does not contain any conditions about the withdrawal time and the contract owners can call her at any time to pick up the air. Usually, during the crowdsale period, both the output of the air and any operations with tokens are blocked.

In general, the principle of the formation of such a feature you understand. This is what they mean when they talk about the new digital economy. It’s not developers who need it, but rather financiers who understand what functionality can fool investors and which one is useful. In general, the developers - program honestly, and those who understand Fintekhovtsy - let us sit down at Solidity slowly.

Since we are discussing development problems, I’ll add that after launching several contracts we have a new paranoia about timestamps, which are set in contracts manually. The fact is that the probability of making a mistake in ts is rather high, no matter how much you talk about accuracy in the task of constants. It also happens that the dates of the project will be sent to you by the owner of the project, and you will simply stick them into the contract, because it is late at night and it's not reluctant to double-check. We even blinded the JS helper, which searches for timestamps in the copied code and displays them as a sorted list of dates, so it's more convenient to check. The cost of a mistake here is indecently high. If somewhere in the third discount period crowdsale contract suddenly gets stuck or closes the crowdsale - it will be very unpleasant.

A little more about the technical features of the development. For the correct broadcast purse to work with a full blockchain, you need a normal computer with an SSD. Now I’ll explain - you need the whole blockchain not because you think that in the past someone changed something and stole all your airwaves, but so that when you conduct a crowdsale you have a node that is completely synchronized with the network, which quickly and urgently receives new blocks. After all, you want to see the current status of your fees on the project and react if something goes wrong. And without the SSD, the computer can “catch up” with the blockchain for a very, very long time: we are talking about days. From a technical point of view, this is because, in order to validate smart contracts, client software must often refer to arbitrary blocks of the chain. And such a pseudo-home reading is the worst pattern for traditional HDDs, since you need to rearrange the read head all the time. But for SSD this reading is a fad. Moreover, plus plays into the hands of the fact that the blocks in the blockchain do not change - and this means a small number of overwrites, which, in theory, they like SSD. So the difference between HDD and SSD here is very serious. It seems to me that the disk cache is also not easy with the Ethereum client work pattern, since the read block is rarely needed again and the cache is not very effective here. This already applies to both types of disks.

Plus, when we said that the contract code could not be changed, we, of course, were not entirely sincere. In fact, this possibility is laid. To do this, make the main contract controller, a kind of proxy that stores the addresses of contracts that may have to be replaced. It has methods (available, of course, only to the owners) that allow changing the internal address of the contract, and, as users continue to send transactions to the controller, they are sent to the new contract instead of the old one. In general, any more or less complex system of smart contracts is not complete without controller contracts. We will tell more about this in other articles. From the investor’s point of view, the history of proxy contracts, on the one hand, seems to be good, because if they find a mistake, developers can fix it by replacing the contract, and on the other, suspicious: the same developers can “fix” the contract at any time without the possibility early withdrawal of funds to the “more friendly version”. Well, to heaps, as usual, any complication of the general scheme, especially in the area where one contract causes another (and here lies the mass of interesting vulnerabilities), leads to more places with potential vulnerabilities.

If you are a customer, wait for the developers to develop a smart contract and quietly get angry with them, as they give you three files for a total of 100 significant lines of length and say “we are everything” - then you are properly angry. In fact, the code is really a little bit, but you generally don’t have to look into it, but into tests. It is their quantity and quality that speaks for the crowdsale script. In the development of smart contracts tests - this is not an optional, but a mandatory part of the development. With such an error cost, test-driven development is generally the only way to write something normal. It is tests that will help you catch the most stupid and offensive bugs associated with the boundaries of periods, change of discounts, especially when the owner decides to suddenly change a few constants.

Web development

There are two types of crowdsale - in pure air and "all others are crutches." If customers had limited to collecting in one broadcast, the developers would be happy, and security problems would be 80-90% less (IMHO). Indeed, in the case of tokens (where the client only needs to see the balance and transfer the tokens to and fro), the network client (wallet) itself is a fully functional personal account with a much greater degree of protection than what you program yourself. Transaction history + backup you get right out of the box. A separate very important plus is that in this case the source of the crowdsale page might look like this:

 <html><h1>0x2bd1f12269c1ff80042c8d354bba4c1ca52e2061</h1></html> 

, , , ; , ETH. , . , , , -, . html — , DDoS' , — - ( + ) ( ). , — . , , - — .

owner (, , , , Ethereum) — , . BTC.

, BTC. BTC- ETH-, . Ethereum ETH-, , - , . , , Ethereum, MyEtherWallet -. , , JavaScript , , . , , , , . , , ?

, , , . BTC-, . , ETH- , ( , ). BTC- , BTC . , , , : , — .

, - . BTC: , , , .

offline - BTC (LTC, DASH . .) , . — , Ethereum ( ), token-contract , mint(address addr, uint amount) , ETH- addr amount -. cron- , -, , ; VISA MasterCard, .

crowdsale

, - web-, , «» crowdsale. ICO . — , , . — . , ICO, : . , ICO, : , copy-past, DDoS- crowdsale.

crowdsale Ethereum, : — SQL-, user-supplied — XSS. — Ethereum Wallet.

DDoS crowdsale — . , «shut up and take my money», - , , , , 133 ETH (~40$):

https://etherscan.io/address/0x5d3f32f4b2e99fb79d2f6a1cbf3aa7390f8fc751

crowdsale — . , - Cloudflare, . . , DDoS . , Cloudflare: , , , .

fallback- — / . , , , DDoS, , . , , ( 04:30 ), . , SMM — . , ( -), crowdsale-, -, - , - , , .

— , , ICO « -»: - Parity ( Security Alert 2017-11-08 ). -, , «» ( selfdestruct() ) , -. , , 150M . , ICO, , . Parity — , , , , , .

crowdsale- owner', . web- , , ICO. , . , , , , .

crowdsale

ICO , , . ICO , . ICO , , . , , - . cron-, , crowdsale:

 wget -O- https://myico.com | fgrep '<h1>0xTRUE_CROWDSALE_ADDRESS</h1>' 

, ICO — . , ( , etherscan) — . — , ( ICO) — , , .

findings

, ICO - . , , , . , .

, , .