Комментарии 37
Мне кажется, в случае биткоина нужно не запрашивать у пользователя адрес, с которого он будет посылать, а генерировать новый адрес для принятия платежа. Так как у пользователя может быть множество адресов на одном аккаунте и он сам может не знать, с какого адреса кошелек проведет транзакцию
Да, можно и так, это тоже вариант — я вот поленился расписать абзац про адреса. Есть даже еще более правильный с точки зрения безопасности вариант. Дело в том, что и Ethereum и Bitcoin используют один и тот же ассиметричный алгоритм — и если у инвестора есть BTC адрес, то секретный ключ от него «подходит» к «парному» ему ETH адресу. Проблема только в том, что адреса ETH и BTC — это не чистые публичные ключи, а хеши от них, причем хеш функции разные — SHA-256 и Keccak-256 вроде. Поэтому, если юзер даст нам свой публичный ключ от BTC, мы можем без проблем создать ему адрес ETH, который управляется тем же секретным ключом, что и BTC. Но этот способ почему-то не используют, видимо инвесторам это сложно проделывать, проще выдать готовые адреса.
Наверное, сложно объяснить инвестору, что от него требуется. :)
Да, надо писать инструкцию по каждому кошельку, как достать свой public key, куда его вкопипастить и почему это безопасно. А учитывая, что пар ключей у юзера много, ошибок не избежать. Так что этот вариант походу не катит, хотя с точки зрения дизайна он хороший — нет необходимости хранить лишние данные. Человек сделал транзакцию на BTC адрес (значит у него точно есть ключик к адресу, с котрого он шлет BTC), и мы ему гарантированно безопасно начисляем токены на derived ETH адрес, никакой другой инфы не нужно
Тревожит этот момент
Т.е. если в коде баг, то можно потерять собранные эфиры. Проблема в том, что код это всегда баги.
Перезаписать другой контракт на место задеплоенного нельзя, никакой код не исправляется, возможно лишь помещение новой версии контракта по другому адресу.
Т.е. если в коде баг, то можно потерять собранные эфиры. Проблема в том, что код это всегда баги.
именно так, существует состояние когда ничего сделать нельзя. Но в принципе для крипты эта проблема повсеместная, потеряв секретный ключ от адреса точно так же необратимо можно лишиться любого криптоактива
От потери ключа легко подстраховаться. От багов в коде подстраховаться невозможно. Отрицать возможность багов даже в коротком коде на несколько страниц — это отрыв от реальности, любой разработчик подтвердит. А тем более если код этот написан в спешке.
А про Proxy контракты Вы ничего не слышали?)
Я вроде про них написал: «С точки зрения инвестора история с прокси-контрактами, с одной стороны, вроде хорошая, ведь если найдут ошибку, то разработчики смогут её исправить, заменив контракт, а с другой — подозрительная: те же разработчики могут в любой момент «исправить» контракт без возможности досрочного вывода средств на «более дружественную версию»». Я их правда назвал контроллерами, и в принципе «контроллер» мне больше нравится, ибо подразумевает возможность управления
Помните, что вы имеете дело со смарт-контрактом, который невозможно поправить, единожды задеплоив. И у вас есть отличная возможность (перепутав, к примеру, даты) выкатить контракт, который в какой-то момент залочит все средства пользователей — и вы никогда их не достанете.
Ага, а геттеры и сеттеры с модификатором onlyOwner это вид черной магии.
они позволяют заменить код контракта, не изменив его адрес?
Они позволяют установить нужные значения в свойства контракта не изменив его адрес. Если тебе говорят, что не знают, по какой цене будут продавать токены, то делаешь свойство tokenPrice и метод setTokenPrice с модификатором onlyOwner. И не надо ничего передеплоивать при изменении мнения заказчика относительно цены.
Довольно забавно еще читать про «точку зрения инвесторов». Это я о верифицированных контрактах, контрактах-контроллерах и тому подобном. Якобы, инвесторам это важно. Может быть, у вас какая-то другая практика, но по моему опыту, крупные инвесторы, которые дают 80% средств ICO вообще не понимают, что такое смарт-контракт и уж тем более не разбираются ни в каком коде. Многим даже приходится объяснять, как купить крипту. Код смотрят программисты. Ни больше ни меньше и рассчитывать что кому-то кроме них он будет интересен — такое себе. Это конечно не отменяет необходимость верификации, но причины совершенно другие, нежели траст со стороны инвесторов
Я конечно имею в виду умных инвесторов, которые изучают проект, прежде чем в него инвестировать, а не тех, кто сейчас «даёт 80% средств ICO». То, что сейчас не смотрят код контрактов, скоро изменится. Люди вообще довольно быстро начинают догонять, когда их кидают на деньги.
У инвесторов свои каналы получения информации. Если они не могут прочитать solidity-код (даже если кто-то может — тратить свое время на это будет крайне неэффективно), это не значит, что они не узнают, что ICO «X» looks scammy.
Looks scammy вытекает вовсе не из кода, вот о чем я говорю. Вообще, сейчас вполне нормальная практика иметь ЛК инвестора, в котором ты даже не можешь посмотреть адрес СК. 90% ICO которые я вижу сейчас поступают так. Для интересующихся всегда есть github. А скамануть можно и с безупречным смарт-контрактом и целым отрядом Escrow-агентов. Скам\не скам это не об этом
Вообще, сейчас вполне нормальная практика иметь ЛК инвестора, в котором ты даже не можешь посмотреть адрес СК. 90% ICO которые я вижу сейчас поступают так.
90% по сборам или штучно? Понимаете, к чему я веду?
А скамануть можно и с безупречным смарт-контрактом и целым отрядом Escrow-агентов.
Это аргумент из серии «кому надо — все равно сломают». Конечно. Но при прочих равных лучше иметь прозрачные, криптографически гарантированные условия.
«Нормальная практика» она потому, что компаниям похрен на качество, и они ждут только бабло, а разработчики и рады покорее отстреляться и пойти к следующему клиенту. Это нифига не нормальная практика, и она обречена, как только на рынок зайдёт достаточное количество скиллованных компаний и разрабов.
Пруф, или не было)
Более того, я не уверен, что большинство ICOшек аутсоряст создание СК и личных кабинетов. По моей личной практике и опыту общения с другими компаниями, большинство все таки стараются делать это in-house. А в таком ключе Ваши слова выше вообще слабо соотносятся с реальностью.
что компаниям похрен на качество, и они ждут только бабло, а разработчики и рады покорее отстреляться и пойти к следующему клиенту.
Более того, я не уверен, что большинство ICOшек аутсоряст создание СК и личных кабинетов. По моей личной практике и опыту общения с другими компаниями, большинство все таки стараются делать это in-house. А в таком ключе Ваши слова выше вообще слабо соотносятся с реальностью.
Хм, по нашему опыту, больше чем половина заказчиков точно хотели бы отдать весь процесс ICO на аутсорс. Разработка самого проекта — это да, предпочитают своих растить, а вот ICO — это отдельная песня, ее обычно хотят отдельной историей провести.
Про «пруф или не было» — если вы про «нормальную практику», то когда меня знакомый инвестор просит посмотреть что-как с проектом, то, если я не могу увидеть верифицированный код контракта, то просто говорю, что там по раздолбайски отнеслись к деплою — и я бы этим чувакам серьезные инвестиции бы не доверил. Он уже делает свои выводы.
Про «пруф или не было» — если вы про «нормальную практику», то когда меня знакомый инвестор просит посмотреть что-как с проектом, то, если я не могу увидеть верифицированный код контракта, то просто говорю, что там по раздолбайски отнеслись к деплою — и я бы этим чувакам серьезные инвестиции бы не доверил. Он уже делает свои выводы.
Спасибо за отличную статью.
А как происходит выпуск токенов, которыми контракт торгует?
А как происходит выпуск токенов, которыми контракт торгует?
выпуск токена это просто запись, внесённая в storage контракта, фактически делается
tokenBalances['0xADDRESS_FROM_WHICH_ETH_CAME'] += nTokens;
а трансфер с одного адреса на другой:
tokenBalances['0xSOURCE_ADDR'] -= nTokens;
tokenBalances['0xDEST_ADDR'] += nTokens;
############
и эти изменения в storage контракта сохраняются в блокчейне (майнер исполняет контракт, и если всё ок — фиксирует изменения в storagе в свежесмайненном блоке)
tokenBalances['0xADDRESS_FROM_WHICH_ETH_CAME'] += nTokens;
а трансфер с одного адреса на другой:
tokenBalances['0xSOURCE_ADDR'] -= nTokens;
tokenBalances['0xDEST_ADDR'] += nTokens;
############
и эти изменения в storage контракта сохраняются в блокчейне (майнер исполняет контракт, и если всё ок — фиксирует изменения в storagе в свежесмайненном блоке)
То есть на основе данного storage у нас получается новая криптовалюта?
Насколько в этом случае реально договориться с какой-нибудь биржей, чтобы организовать торги этими токенами?
Это я к вопросу о безопасности продаж. Переложить частично на биржу.
Насколько в этом случае реально договориться с какой-нибудь биржей, чтобы организовать торги этими токенами?
Это я к вопросу о безопасности продаж. Переложить частично на биржу.
Скажем так: не просто, но более, чем реально. Большинство токенов так и делают — договариваются с биржами о торгах после ICO.
Есть «интерфейс» для токенов(ERC20), который приводит их к общему виду. Соответсвенно биржам намного меньше работы по внедрению новых токенов
Существует стандарт ERC20 — он фактически говорит «у вашего контракта токена должны быть методы balanceOf(...), totalSupply(), transfer(...) и т.п read-more. После этого бирже (которая фактически проводит транзакции за вас) достаточно знать лишь адрес контракта токена (например SONM токен — адрес 0x983f6d60db79ea8ca4eb9968c6aff8cfa04b3c63б) и теперь биржа может просто посылать транзакции с вызовами, например „transfer“ чтобы торговать определенным токеном. Т.е. надо просто заставить биржу добавить себе в список еще одни ETH адрес и название токена, под которым он будет листиться на бирже, а операции с любым токеном ERC20 стандартны
Было бы интересно почитать каким образом происходит сборка проектов, сдача релизов, тестирование(кем и как), согласование ТЗ на практике. Имеется ли опыт сдачи проектов с частично закрытым кодом но в котором разумеется детально описаны условия тестирования и приемки? Примеры подобных проектов?
Я не очень вопрос понял — если вы про ICO — то это в общем-то «одноразовый» проект. Смарт контракт не должен работать после ICO, сайт crowdsale тоже. Код контракта открыт полностью, «собирать» его не нужно. Сайт — это как принято у вас в компании. Или вы про сами блокчейн-проекты и методы работы команд с ними?
ICO — то это в общем-то «одноразовый» проект. Смарт контракт не должен работать после ICO
Немного не понятно, как не должен? А если нужно вывести эти токены на биржу, она ведь должна будет «дёргать» методы balanceOf(), totalSupply(), transfer(),… из смарт-контракта или откуда?
И если ответите на еще пару вопросов, было бы отлично.
К примеру у меня есть яблочная косточка и я предполагаю, что через 10 лет у меня будет урожай в 100 яблок. Я провожу успешно ICO по сбору средств на поддержание роста дерева. 100 пользователей имеют по 1 YABLOKO токену.
1. В кошельке Эфира, они видят свои YABLOKO = 1?
2. Могут ли они эти токены обменять на другие токены в сети Эфира, без использования бирж?
3. Могут ли они обменять токен на Эфир обратно (без бирж), если да, то по какому курсу и кто этот курс задаёт?
4. Если обменять нельзя, то получается пользователям только и остаётся — ждать урожай?
5. Когда прошло 10 лет, я раздаю яблоки и получаю на свой кошелёк 100 своих токенов, всё, их жизненный цикл окончен, так как они не имеют ценность?
Давайте я отвечу.
Контракт, проводящий раздачу токенов (ICO) и сам токен — который пользователи видят в кошельке и т.п., не обязательно один и тот же контракт. А так да, контракт токена — он будет постоянно использоваться, при каждой операции.
1) — Да
2) Прямой сделкой перевода — да. Сейчас в разной стадии готовности несколько проектов, позволяющие проводить сделки без бирж — Melonport, Bankor и т.п.
3) Да могут, не обменять только, а продать. На децентрализованой бирже или напрямую другому участнику по согласованному курсу с ним (ОТС-сделка, говоря языком финансов)
4) Они могут (и делают) дожидаются момента выхода (листинга) на бирже
5) Зависит от ваше модели проекта. Если у вас есть еще яблоки, то все остальные желающие будут караулить ваши токены на рынке, чтобы купить.
Контракт, проводящий раздачу токенов (ICO) и сам токен — который пользователи видят в кошельке и т.п., не обязательно один и тот же контракт. А так да, контракт токена — он будет постоянно использоваться, при каждой операции.
1) — Да
2) Прямой сделкой перевода — да. Сейчас в разной стадии готовности несколько проектов, позволяющие проводить сделки без бирж — Melonport, Bankor и т.п.
3) Да могут, не обменять только, а продать. На децентрализованой бирже или напрямую другому участнику по согласованному курсу с ним (ОТС-сделка, говоря языком финансов)
4) Они могут (и делают) дожидаются момента выхода (листинга) на бирже
5) Зависит от ваше модели проекта. Если у вас есть еще яблоки, то все остальные желающие будут караулить ваши токены на рынке, чтобы купить.
0) Спасибо, совершенно точный ответ. Контракт токена обычно делают отдельным от контракта ICO — после ICO ICO-шный контракт уже не нужен, и не принимает эфир и не минтит(выдает в котракте токена) токены инвесторам.
1) да, фактически вы указав адрес контракта любого ERC20 токена заставите кошелёк дернуть метод balanceOf соответствующего Token-контракта, и он скажет сколько на вашем адресе токенов. Транзакция для этого не нужна, т.к. опреация read-only, по факту кошелёк сам просмотрит свой блокчейн, сам исполнит метод «balanceOf» и покажет баланс
2) технически да, так как обмен можно сделать через смарт-контракт с escrow или еще лучше, используя какой нибудь atomic swap. Правда в реале это будет стоить много газа для всех участников, поэтому через биржу проще, и вроде, обычно так и делают. В общем решения есть, но их надо раскапывать, собственно мы их как раз копаем
3) да, правда если другому участнику, возможно кидалово — я именно такое наблюдал. Договорились хранить токены на адресе, ключ от которого продавец передас покупателю. Ну и получив эфир продавец по бычстрому слил свои токены на другой свой адрес. Здесь бы тоже atomic swap пригодился
4) точняк
5) точняк
1) да, фактически вы указав адрес контракта любого ERC20 токена заставите кошелёк дернуть метод balanceOf соответствующего Token-контракта, и он скажет сколько на вашем адресе токенов. Транзакция для этого не нужна, т.к. опреация read-only, по факту кошелёк сам просмотрит свой блокчейн, сам исполнит метод «balanceOf» и покажет баланс
2) технически да, так как обмен можно сделать через смарт-контракт с escrow или еще лучше, используя какой нибудь atomic swap. Правда в реале это будет стоить много газа для всех участников, поэтому через биржу проще, и вроде, обычно так и делают. В общем решения есть, но их надо раскапывать, собственно мы их как раз копаем
3) да, правда если другому участнику, возможно кидалово — я именно такое наблюдал. Договорились хранить токены на адресе, ключ от которого продавец передас покупателю. Ну и получив эфир продавец по бычстрому слил свои токены на другой свой адрес. Здесь бы тоже atomic swap пригодился
4) точняк
5) точняк
Можете посмотреть в сторону truffle framework, там есть инструменты для тестирования и деплоя. «Сборка», как правило ограничивается заменой импортов содержимым тех самых файлов, например, можно использовать npm-пакет `sol-merger`. Но такая «сборка» нужна только в целях верификации контрактов, потому что верификация etherscan не умеет работать с импортами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Технические особенности проведения ICO. Начало