Не вижу, где может возникнуть, описанная вами ситуация. Перевод эфира на рассмотренный контракт приведет к вызову payback функции, которая отгрузит токены. В ответ на отгрузку токенов у sender-а ничего не вызовется, т.к. это по сути внутреннее дело нашего контракта.
Если эфир был переведен на адрес смартконтракта с холодного кошелька, токены будут начислены на адрес этого холодного кошелька. Никаких дополнительных функций для этого не нужно.
Сразу видно, что ICO Вы не проводили:) Поговорите с юристами, они объяснят, что означает указание данных Васи Пупкина для Васи Пупкина при проведении ICO, кто несет ответственность и перед кем. Это далеко за границами этого поста, я принципиально не хочу выходить за технические рамки, хотя мы и обладаем глубокими юридическими компетенциями в данном вопросе.
Еще хорошей практикой является реализовывать сложную бизнес-логику в виде набора связанных между собой контрактов, причем отдельные части этой логики можно заменять, опять же голосованием держателей токенов. В блокчейне принято «играть» в демократию:)
Контракт обновить нельзя, но можно загрузить новый и перевести туда всех держателей токенов. Для миграции можно предусмотреть дополнительную функциональность контракта, чтобы не делать это руками. Ну и в стиле децентрализации/блокчейн делать эту миграцию голосованием держателей токенов. Опять же хочу в качестве примера такой реализации привести свой «контракт PROVER»:https://etherscan.io/address/0x5B5d8A8A732A3c73fF0fB6980880Ef399ecaf72E#code. Там можно подсмотреть реализацию миграции НА этот контракт и С этого контракта. Все демократично и безопасно:)
Ощущается явная проблема с чувством юмора:) Прошу прощения, что оскорбил Ваши светлые чувства:)
На самом деле, рассмотренный смартконтракт в чистом виде скам, т.к. объективно никак не защищает интересов инвесторов (покупателей токенов). Такие контракты не должны быть в боевых проектах. Он всего лишь демонстрирует принципы организации краудсейла с технической точки зрения.
Касательно анонимности и ICO. Не открою америку, если скажу, что и в классическом венчуре и в ICO деньги дают прежде всего команде. Успешные анонимные ICO — большая редкость. Поэтому если вы не делаете скам (в проекте, в смартконтракте), то напишите, кто Вы есть такой, чтобы инвесторы видели, что Вы готовы ответить за базар:) Но это лишь мое мнение, возможно, я идеализирую. Но в нашим проектах PROVER и OpenLongevity мы руководствуемся именно такими принципами.
Можно предложить и более параноидальную схему по принципу multisig, когда контракт «знает» нескольких владельцев, а для смены одного из владельцев требуется confirm всех остальных. Реализовать это несложно, но это выходит за рамки «простого смартконтракта для ICO» :)
Друзья, все это не предмет данного поста. На низком уровне есть вполне себе читаемый байткод, при желании можно писать сразу в нем:) А можно создавать любые высокоуровневые абстракции. Сейчас есть два языка «высокого уровня» для написания смартконтрактов для Ethereum Virtual Machine, это Solidity (на основе Javascript) и Serpent (на основе Python). Второй скорее мертв, чем жив, т.к. уже больше года не было обновлений, а в Solidity фиксят регулярно ошибки компилятора. В настоящее время мы своей командой ведем работу над созданием визуального языка программирования смартконтрактов на основе Scratch. Пока еще окончательно не определились, будем ли сразу генерировать байткод или же в качестве промежуточного слоя будем использовать Solidity, чтобы оставить возможность верификации полученного кода. Вобщем, платформа Ethereum достаточно универсальна, чтобы решать на ней широкий класс задач. Вопрос в том, что у разработчиков не дошли руки сделать удобной прикладную разработку.
Этот пост как раз для тех, кто не хочет заморачиваться:)
При написании нормального смартконтракта нужно думать о куче дополнительных вещей, о которых не всегда думают при обычном программировании: стоимость выполнения тех или иных операций (выраженная в деньгах), максимальные ограничения на стоимость в рамках одной транзакции (чтобы контракт не заблокировался), ну и куча ошибок компиллятора, которые надо знать и на уровне кода от них защищаться. Об этом, возможно, еще напишу другие посты.
owner — это и есть адрес.
Ну и контракты по ссылке не стоит считать эталоном — например, они подвержены той же short address attack.
Вот мой контракт проекта PROVER действительно прекрасен, но он реализует вполне конкретную бизнес-логику, требуемую именно для моего проекта.
Достаточно системно рассматриваются примеры на официальном сайте ethereum.org.
Если программируете свободно на других языках, то можно попробовать такой формат — learnxinyminutes.com/docs/solidity.
Ну а перед сном надо читать вот это — solidity.readthedocs.io/en/develop/contracts.html
На самом деле, рассмотренный смартконтракт в чистом виде скам, т.к. объективно никак не защищает интересов инвесторов (покупателей токенов). Такие контракты не должны быть в боевых проектах. Он всего лишь демонстрирует принципы организации краудсейла с технической точки зрения.
Касательно анонимности и ICO. Не открою америку, если скажу, что и в классическом венчуре и в ICO деньги дают прежде всего команде. Успешные анонимные ICO — большая редкость. Поэтому если вы не делаете скам (в проекте, в смартконтракте), то напишите, кто Вы есть такой, чтобы инвесторы видели, что Вы готовы ответить за базар:) Но это лишь мое мнение, возможно, я идеализирую. Но в нашим проектах PROVER и OpenLongevity мы руководствуемся именно такими принципами.
При написании нормального смартконтракта нужно думать о куче дополнительных вещей, о которых не всегда думают при обычном программировании: стоимость выполнения тех или иных операций (выраженная в деньгах), максимальные ограничения на стоимость в рамках одной транзакции (чтобы контракт не заблокировался), ну и куча ошибок компиллятора, которые надо знать и на уровне кода от них защищаться. Об этом, возможно, еще напишу другие посты.
Спасибо!