Сейчас проблемы как таковой вообще нет. Счетчик все показывает на экран и отправляет в компанию, компания потом чаржит. Если видите что что цифры на счетчике не совпадают с тем, что прислала компания — бьете тревогу.
Да, все так. Здесь недоверие с другой стороны: компания Вам не доверяет, что Вы передаете показания верно.
А теперь вопрос, надеюсь не глупый: много ли есть проблем, или задач, которые ну никак не могут доверится центральному серверу или одному владельцу?
Вопрос доверия — выходит за рамки технической дискуссии, думаю на Хабре дальнейшей дискуссии не место. Я просто оставлю это и это здесь.
Еще один вопрос: неужели невозможно добиться доверия и прозрачности используя стандартные инструменты и централизованные решения?
Можно хранить данные централизованно и публиковать их, подписывая своим закрытым ключом. Наверное, понадобится какая-то упорядоченность данных, как минимум хронологическая. И утилиты работы с этим массивом данных. Какой готовый софт решит задачу? Например, из семейства Hyperledger или упомянутый локальный EOS.
По ходу статьи мы не говорим, что использование глобального децентрализованного блокчейна — обязательный элемент нашего решения.
Прежде всего рекомендую бесплатную лекцию-воркшоп моего коллеги, где как раз будет затронута тема токена (2 модели токенов: mintable и полный premint) aronicle.timepad.ru/event/665542, по-моему будет трансляция.
По вопросам:
1) Можно добавить себе после ICO (т.н. mintable), а можно до ICO сразу отложить 100, а остальные 900 продать (т.н. полный premint). (900 и 100 чтобы получалось 90% и 10%).
Выдергивать из уже проданных, конечно, не хорошо. Хотя технически возможно в ряде случаев, т.к. балансы токена ведутся в контракте токена, вот тут например: github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/ERC20/BasicToken.sol#L15.
2) и 3) Тут как и с покупкой доли в ООО или АО: если 1000 Ваших токенов покупают по 1 ETH, при этом зная, что продаются 90% токенов проекта, значит уже в момент покупки инвесторы оценивают проект в 1000/0.9 = 1111 ETH. До покупки стоимость проекта была сугубо умозрительной, после покупки проект имеет в активах 1000 ETH, плюс у Вас токены оцененные в 111 ETH.
Дополнительное замечание: удвоения стоимости здесь не происходит: т.к. нельзя одновременно продать 90% токенов и продать 1000 ETH (если сначала продать токены, то теряется право распоряжаться эфиром проекта; если сначала продать эфир проекта — то его стоимость наверняка упадет и токены обесценятся).
4) В простом случае — да, эфир собирается сразу Вам в кошелек. Собранный эфир — строго говоря не Ваш, а проекта, напр. пообедать за его счет будет некрасиво и даже (в глазах ряда стран) незаконно. А вот 100 токенов — Ваши личные — можно аккуратно их продать и купить ягуар, но не забывать делать проект.
5) Вцелом да, только число токенов, повторюсь, записано в контракте токена. Адрес этого контракта владелец токенов должен руками добавить в watch token в кошелек.
Насколько понимаю, Вами предлагается найти всех майнеров, перебрав участников сети. Подозреваю, участников сети десятки тысяч и более — трудно будет искать майнеров. Или можно определить их ip, не перебирая всех участников?
майнеру отправлять блоки с write-only ноды
Уточню: майнер может «читать» сеть с одного ip, а посылать новый блок с другого, на котором он вообще не слушает никакие порты.
А поподробнее? Не забываем, что я могу увидеть конечный эффект любой незамайненой транзакции, применив ее к текущему состоянию БЧ, как бы глубоко обфусцирована она ни была.
Если их более 25, то придется принудительно рвать соединения до известных IP, например, с помощью iptables, и так собрать их все.
А сколько их? Например, у меня постоянно запущена нода rinkeby. Есть подозрение, что порядок величины — десятки тысяч и более. Трудоемкая задача получается.
Как вариант защиты — майнеру отправлять блоки с write-only ноды. Тогда ддосать придется ip целиком.
«Почти» потому что его нельзя самому себе нарисовать. В тестнете rinkeby его довольно легко получить: faucet.rinkeby.io. Балансы разных сетей никак не связаны, по сути это независимые криптовалюты.
Возможности контрактов по взаимодействию с внешним миром весьма ограничены, т.к. их работа должна быть проверяема любым узлом сети, и значит всегда возвращать один и тот же результат. Кроме того, опять же поскольку эту работу вынужден будет выполнить любой т.н. полный узел, она дорого стоит (записать 32 байта не так давно стоило порядка $0.2).
Конкретно в случае обращения за прогнозом погоды — это можно, например сходить в какое-либо json-api с помощью сервиса www.oraclize.it — сервис доставит данные в Ваш контракт и ему с какой-то степенью можно доверять. Но лишь с какой-то степенью. Ждем появления т.н. децентрализованных оракулов.
1. По сравнению со сборами даже небольших проектов затраты на деплой и комиссии пренебрежимо малы (к тому же, после последнего хардфорка они стали сильно ниже, см. ethgasstation.info). Гораздо большую угрозу лишние связи представляют для безопасности и надежности, т.к. нужно внимательно проконтролировать доступ и не поиметь проблем из-за reentrancy. Пока что несколько, т.е. единицы контрактов в системе кажется разумным решением. Уверен, с развитием технологий мы увидим и десятки и сотни.
2. В SafeMath методы помечены как internal, т.е. компилятору нет необходимости делать их публичными, и Вам нет нужды ее деплоить. После компиляции и оптимизации их код окажется в теле контракта, и по расходу газа это будет эквивалентно тому, что они прописаны прямо в вызывающем коде.
3. Хороший и важный вопрос. Когда-то столкнулся точно с таким же. К сожалению, готового удобного инструмента получить good ol' stacktrace нет. Приходится прибегать к таким примитивным способам как вывод информации с помощью событий (truffle показывает залогированные события упавшего теста) и локализация багов комментированием кусков кода дихотомией. Надеюсь, я отстал от жизни и в комментариях подскажут решение получше.
4. Автотесты — конечно только на testrpc. В testnet стоит провести тест всего за пределами кода контрактов — т.е. миграций, связи контрактов, верификации, кошельков, и провести пару пробных транзакций.
5. Затраты газа на деплой можно оценить либо по логу testrpc либо опять же на testnet. Затем берем запас на неудачные попытки: умножаем газ на 2.5 — 4. Оцениваем цену газа на момент деплоя — сейчас она в основном мала, 1 Gwei, но в общем случае она колеблется в разы в течение дня в зависимости от загруженности сети. Умножив газ на его цену получим затраты на деплой. Если эфира не хватило в ходе деплоя, текущая миграция завершится с ошибкой, и в следующий раз truffle начнет миграцию с нее.
6. В самом простом варианте можно просто скачать Ethereum Wallet, он скачает geth автоматически и тот начнет синхронизацию. У Вас будет и удобный интерфейс работы с контрактами, и возможность запустить geth с поднятым rpc для truffle:
Первоначальная синхронизация с нуля не проверяет каждую транзакцию и идет относительно быстро (на macbook pro можно уложиться в 8 часов! ура!). Синхронизация не-с-нуля идет заметно медленнее. В определенный момент будет быстрее удалить блокчейн (осторожно — не удалите keystore!) и запустить с нуля. Если есть доверенная контролируемая Вами нода — можно просто скопировать блокчейн с нее. В любом случае мы рекомендуем брать хорошее железо — 256G+ SSD, 8G+ памяти, процессор порядка core i5 или лучше. С магнитными дисками не стоит даже связываться. Совершенно верно, синхронизацию стоит начать за неделю и постоянно донакатывать блоки — уже не раз теряли и свое время и время заказчика на этом, теперь научены опытом.
7. Могу озвучить в личке. Здесь отмечу, что разработчики смарт-контрактов и тем более блокчейнов сейчас могут рассчитывать на очень выгодные условия, в 2-3 раза более выгодные.
Статья эта несмотря на длину, конечно, довольно обзорная. Я уже отмечал, что и по разработке и по безопасности нужны не то что отдельные статьи — отдельные курсы. Отвечая на вопрос про несколько crowdsale'ов — мы используем один токен, владение которым передается от crowdsale к crowdsale с помощью этого mixin'а, защищенного мультиподписью, умеем откатывать токен вместе с возвратом средств. Вот пример из того, что сейчас в работе. Конечно, есть альтернативные варианты.
Т.е. по сути введены поколения структур. Да, хорошая идея. Вложенные маппинги работают за счет того, что локация в storage определяется условно говоря как хэш(локация мапинга, uid, ключ) — новый uid — все обнулено.
Вообще, сейчас вполне нормальная практика иметь ЛК инвестора, в котором ты даже не можешь посмотреть адрес СК. 90% ICO которые я вижу сейчас поступают так.
90% по сборам или штучно? Понимаете, к чему я веду?
А скамануть можно и с безупречным смарт-контрактом и целым отрядом Escrow-агентов.
Это аргумент из серии «кому надо — все равно сломают». Конечно. Но при прочих равных лучше иметь прозрачные, криптографически гарантированные условия.
У инвесторов свои каналы получения информации. Если они не могут прочитать solidity-код (даже если кто-то может — тратить свое время на это будет крайне неэффективно), это не значит, что они не узнают, что ICO «X» looks scammy.
Чисто и лаконично написано.
Но в функции transferOwnership есть цикл, число итераций которого может оказаться порядка тысячи и более: for (i = 0; i < allPendingOperations.length; i++) {
что приведет к достижению лимита газа блока и невозможности поменять владельцев контракта. Мультиподпись ethereum wallet также этим страдает (функция clearPending). В своей мультиподписи на базе МП ethereum wallet мы ввели принудительный сброс pending-операций в потенциально опасной ситуации, но я считаю это временным решением — планируем переработать алгоритм сброса в итерационный, который адаптивно учитывает msg.gas.
Да, это пожалуй самый большой слон в посудной лавке, о котором евангелисты умалчивают в пламенных речах.
Проблема масштабируемости состоит из как минимум двух подпроблем: нарастить число транзакций в секунду (TPS) и спасти жесткие диски от сотен гигабайт занятых под блокчейн.
TPS проще всего наращивается в различных delegated- алгоритмах консенсуса, напр. в EOS, напр. в Ethereum Casper (не совсем delegated, но важно то, что число нод, формирующих блоки, мало и дисциплина формирования довольно упорядочена).
Серьезно ужать блокчейн — сложнее. Есть различные легковесные решения, но, кажется, там возникает либо проблема эффективности, либо проблема доверия. Есть идеи шардинга, но, напр., в Ethereum оно только на этапе экспериментов github.com/ethereum/wiki/wiki/Sharding-FAQ.
Если присоединяешься к пулу, и юнит-экономика сходится (т.е. достаточна ли энергоэффективность, вне зависимости от hash rate), то почему бы и нет. Правда не уверен, что в случае CPU она сойдется. Может на bitcoin gold.
Поднимали на одном с помощью github.com/smartzplatform/eos-hackathon/blob/master/backend/dev/start_local_chain.sh
Не будет, работает на mac и linux.
Думаю скоро выпустим workshop на www.youtube.com/channel/UCn4kywh7NwNNHce2a2murSg.
Будет взыматься. В локальном режиме (nodeos -e) у аккаунтов бесконечные ресурсы.
Не знаю, как такое может быть. Если запись бесплатна, можно заддосать всю сеть записью.
Да, все так. Здесь недоверие с другой стороны: компания Вам не доверяет, что Вы передаете показания верно.
Вопрос доверия — выходит за рамки технической дискуссии, думаю на Хабре дальнейшей дискуссии не место. Я просто оставлю это и это здесь.
Можно хранить данные централизованно и публиковать их, подписывая своим закрытым ключом. Наверное, понадобится какая-то упорядоченность данных, как минимум хронологическая. И утилиты работы с этим массивом данных. Какой готовый софт решит задачу? Например, из семейства Hyperledger или упомянутый локальный EOS.
По ходу статьи мы не говорим, что использование глобального децентрализованного блокчейна — обязательный элемент нашего решения.
Спасибо, хорошие вопросы и кейс важный.
Прежде всего рекомендую бесплатную лекцию-воркшоп моего коллеги, где как раз будет затронута тема токена (2 модели токенов: mintable и полный premint) aronicle.timepad.ru/event/665542, по-моему будет трансляция.
По вопросам:
1) Можно добавить себе после ICO (т.н. mintable), а можно до ICO сразу отложить 100, а остальные 900 продать (т.н. полный premint). (900 и 100 чтобы получалось 90% и 10%).
Выдергивать из уже проданных, конечно, не хорошо. Хотя технически возможно в ряде случаев, т.к. балансы токена ведутся в контракте токена, вот тут например: github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/ERC20/BasicToken.sol#L15.
2) и 3) Тут как и с покупкой доли в ООО или АО: если 1000 Ваших токенов покупают по 1 ETH, при этом зная, что продаются 90% токенов проекта, значит уже в момент покупки инвесторы оценивают проект в 1000/0.9 = 1111 ETH. До покупки стоимость проекта была сугубо умозрительной, после покупки проект имеет в активах 1000 ETH, плюс у Вас токены оцененные в 111 ETH.
Дополнительное замечание: удвоения стоимости здесь не происходит: т.к. нельзя одновременно продать 90% токенов и продать 1000 ETH (если сначала продать токены, то теряется право распоряжаться эфиром проекта; если сначала продать эфир проекта — то его стоимость наверняка упадет и токены обесценятся).
4) В простом случае — да, эфир собирается сразу Вам в кошелек. Собранный эфир — строго говоря не Ваш, а проекта, напр. пообедать за его счет будет некрасиво и даже (в глазах ряда стран) незаконно. А вот 100 токенов — Ваши личные — можно аккуратно их продать и купить ягуар, но не забывать делать проект.
5) Вцелом да, только число токенов, повторюсь, записано в контракте токена. Адрес этого контракта владелец токенов должен руками добавить в watch token в кошелек.
Насколько понимаю, Вами предлагается найти всех майнеров, перебрав участников сети. Подозреваю, участников сети десятки тысяч и более — трудно будет искать майнеров. Или можно определить их ip, не перебирая всех участников?
Уточню: майнер может «читать» сеть с одного ip, а посылать новый блок с другого, на котором он вообще не слушает никакие порты.
А сколько их? Например, у меня постоянно запущена нода rinkeby. Есть подозрение, что порядок величины — десятки тысяч и более. Трудоемкая задача получается.
Как вариант защиты — майнеру отправлять блоки с write-only ноды. Тогда ддосать придется ip целиком.
Конкретно в случае обращения за прогнозом погоды — это можно, например сходить в какое-либо json-api с помощью сервиса www.oraclize.it — сервис доставит данные в Ваш контракт и ему с какой-то степенью можно доверять. Но лишь с какой-то степенью. Ждем появления т.н. децентрализованных оракулов.
1. По сравнению со сборами даже небольших проектов затраты на деплой и комиссии пренебрежимо малы (к тому же, после последнего хардфорка они стали сильно ниже, см. ethgasstation.info). Гораздо большую угрозу лишние связи представляют для безопасности и надежности, т.к. нужно внимательно проконтролировать доступ и не поиметь проблем из-за reentrancy. Пока что несколько, т.е. единицы контрактов в системе кажется разумным решением. Уверен, с развитием технологий мы увидим и десятки и сотни.
2. В SafeMath методы помечены как internal, т.е. компилятору нет необходимости делать их публичными, и Вам нет нужды ее деплоить. После компиляции и оптимизации их код окажется в теле контракта, и по расходу газа это будет эквивалентно тому, что они прописаны прямо в вызывающем коде.
3. Хороший и важный вопрос. Когда-то столкнулся точно с таким же. К сожалению, готового удобного инструмента получить good ol' stacktrace нет. Приходится прибегать к таким примитивным способам как вывод информации с помощью событий (truffle показывает залогированные события упавшего теста) и локализация багов комментированием кусков кода дихотомией. Надеюсь, я отстал от жизни и в комментариях подскажут решение получше.
4. Автотесты — конечно только на testrpc. В testnet стоит провести тест всего за пределами кода контрактов — т.е. миграций, связи контрактов, верификации, кошельков, и провести пару пробных транзакций.
5. Затраты газа на деплой можно оценить либо по логу testrpc либо опять же на testnet. Затем берем запас на неудачные попытки: умножаем газ на 2.5 — 4. Оцениваем цену газа на момент деплоя — сейчас она в основном мала, 1 Gwei, но в общем случае она колеблется в разы в течение дня в зависимости от загруженности сети. Умножив газ на его цену получим затраты на деплой. Если эфира не хватило в ходе деплоя, текущая миграция завершится с ошибкой, и в следующий раз truffle начнет миграцию с нее.
6. В самом простом варианте можно просто скачать Ethereum Wallet, он скачает geth автоматически и тот начнет синхронизацию. У Вас будет и удобный интерфейс работы с контрактами, и возможность запустить geth с поднятым rpc для truffle:
и добавляем в networks в truffle.js:
Первоначальная синхронизация с нуля не проверяет каждую транзакцию и идет относительно быстро (на macbook pro можно уложиться в 8 часов! ура!). Синхронизация не-с-нуля идет заметно медленнее. В определенный момент будет быстрее удалить блокчейн (осторожно — не удалите keystore!) и запустить с нуля. Если есть доверенная контролируемая Вами нода — можно просто скопировать блокчейн с нее. В любом случае мы рекомендуем брать хорошее железо — 256G+ SSD, 8G+ памяти, процессор порядка core i5 или лучше. С магнитными дисками не стоит даже связываться. Совершенно верно, синхронизацию стоит начать за неделю и постоянно донакатывать блоки — уже не раз теряли и свое время и время заказчика на этом, теперь научены опытом.
7. Могу озвучить в личке. Здесь отмечу, что разработчики смарт-контрактов и тем более блокчейнов сейчас могут рассчитывать на очень выгодные условия, в 2-3 раза более выгодные.
Статья эта несмотря на длину, конечно, довольно обзорная. Я уже отмечал, что и по разработке и по безопасности нужны не то что отдельные статьи — отдельные курсы. Отвечая на вопрос про несколько crowdsale'ов — мы используем один токен, владение которым передается от crowdsale к crowdsale с помощью этого mixin'а, защищенного мультиподписью, умеем откатывать токен вместе с возвратом средств. Вот пример из того, что сейчас в работе. Конечно, есть альтернативные варианты.
А с какой целью очищать? Уменьшить размер блокчейна не получится, разве что размер текущего состояния.
90% по сборам или штучно? Понимаете, к чему я веду?
Это аргумент из серии «кому надо — все равно сломают». Конечно. Но при прочих равных лучше иметь прозрачные, криптографически гарантированные условия.
Но в функции
transferOwnershipесть цикл, число итераций которого может оказаться порядка тысячи и более:for (i = 0; i < allPendingOperations.length; i++) {что приведет к достижению лимита газа блока и невозможности поменять владельцев контракта.
Мультиподпись ethereum wallet также этим страдает (функция
clearPending).В своей мультиподписи на базе МП ethereum wallet мы ввели принудительный сброс pending-операций в потенциально опасной ситуации, но я считаю это временным решением — планируем переработать алгоритм сброса в итерационный, который адаптивно учитывает
msg.gas.Проблема масштабируемости состоит из как минимум двух подпроблем: нарастить число транзакций в секунду (TPS) и спасти жесткие диски от сотен гигабайт занятых под блокчейн.
TPS проще всего наращивается в различных delegated- алгоритмах консенсуса, напр. в EOS, напр. в Ethereum Casper (не совсем delegated, но важно то, что число нод, формирующих блоки, мало и дисциплина формирования довольно упорядочена).
Серьезно ужать блокчейн — сложнее. Есть различные легковесные решения, но, кажется, там возникает либо проблема эффективности, либо проблема доверия. Есть идеи шардинга, но, напр., в Ethereum оно только на этапе экспериментов github.com/ethereum/wiki/wiki/Sharding-FAQ.