Pull to refresh
27
0

Пользователь

Send message
По сути в статье написано то же самое, что и в Вашем комментарии. Никто не говорил, что блокчейн бесполезен, надо просто понимать что за собой влечет его использование. Мы автоматически не сделаем, например, фейсбук более безопасным, вставив туда непонятно зачем нужный блокчейн. В том числе крипто биржи были приведены в качестве примера централизованной системы несмотря на приставку «крипто-». Так что прооппонировать можно разве что по легкости установки, ведь не у каждого есть друг с эфиром, а покупка — это поначалу серьезная головная боль, плюс немаленькие комиссии — если хотите перевести фиат в крипту а потом обратно, то потеряете процентов наверное 20
Вот на этих сайтах собирают информацию и статистику по существующим приложениям: www.stateofthedapps.com, dappradar.com. В основном это либо азартные игры, либо клоны CryptoKitties, либо что-то для обмена токенами
Спасибо за отзыв и информацию к размышлению!
Единственное не очень понятно как работает защита от неконтролируемых действий бекенда. Ведь транзакции надо подписать приватным ключом => в какой-то момент времени бекенд знает наш ключ => ничто не мешает это значение сохранить и начать подписывать левые транзакции. В этой логике есть ошибка?
Если правильно понимаю — это просто защита от того, что кто-то завладеет базой с ключами. Тогда да, хранить их в открытом виде конечно опасно, и надо применять что-то из перечисленных вами способов. Просто речь шла о том, что мы не можем гарантировать защиту от злых бэкенд разработчиков, а если мы точно знаем, что они добрые — то их и не надо контролировать блокчейном.
Для открытия нужен не только адрес, но еще и abi (интерфейс). Как с этими данными открыть контракт описано как раз во второй части в пункте «Hello Command Line!»
Газ и комиссия нужны для оплаты не майнинга, а создания блока и одновременно для того, чтобы сделать спам транзакциями дорогим. В Proof-of-Stake и блоки создавать нужно, и проблема со спамом актуальна, так что газ должен сохраниться
alatushkin, спасибо за комментарий, очень правильное замечание.
Это так называемая полиморфная связь. Сейчас property можно привязать либо к place, либо к district. Представьте, что появляется третья (четвертая, пятая, ...) сущность к которой можно будет привязать property. При такой связи в структуру таблицы properties не придется вносить изменений.
У нас производных полей почти нет. Мы вынесли в отдельную таблицу периоды… Схема БД была изменена крайне незначительно.
В статье описано как. Мы обновляем нужные записи периодов только при изменениях и делаем это в фоне.
Может запрос и выглядит устрашающим, но только если его рассматривать целиком.
На деле он строится из кусков, это всего лишь несколько CTE следующие друг за другом. И в приложении каждое CTE строится отдельно, и более того, они переиспользуются в других подобных запросах.
И если рассматривать запрос отдельно, по шагам, как в статье, то ничего страшного в нем нет.
Вроде ничего решение, правда оно кажется очень трудоемким по реализации обновления данных, а также объем данных будет очень и очень большим. Кроме того, мы неоднократно встречались с ситуацией, когда какая-то нода отстает в кластере или же индекс совсем развалился. Обычно непросто понять, что произошло. Тут это еще как-то мониторить отдельно нужно. С другой стороны, по нашему опыту PostgreSQL великолепно держит нагрузку. Наше решение позволило «малой кровью» точечно переписать проблемную часть проекта.
А давайте вы напишете более-менее реалистичный сценарий? Здесь описан поиск и нет никаких UPDATE и уж тем более нет EXCLUSIVE блокировок. Данные только читаются. Адово тупить будет только разве что плохо написанный код.
Да, опечатка. Должно быть

WHERE '2018-01-02'::date - 7 <= arrival_date AND arrival_date <= '2018-01-02'::date + 7

Поправили, спасибо.
Да, поиск работает, и гораздо быстрее чем изначально.
geth --rinkeby — это и есть команда для запуска. И после этого не останавливая geth можно запускать Mist, он покажет прогресс, если синхронизация не закончилась
В этом логе можно увидеть, что подключение идет к главной сети, по строчке INFO [08-31|23:38:50] Allocated cache and file handles database=C:\\Users\\User\\AppData\\Roaming\\Ethereum\\geth\\chaindata cache=128 handles=102 — здесь Ethereum\geth — это папка с данными основной сети, для тестовых будет папка либо Ethereum\rinkeby\geth, либо Ethereum\testnet\geth
В первой части были описаны основные моменты. Но раз возник вопрос — добавили и в эту статью информацию о газе цитатой
Вроде нормальный код, bidder не получает эфир назад? На ropsten.etherscan.io для контракта есть вкладка Internal Transactions, в которой перечислены отправки из него. Почему-то ее нет для Rinkeby. Тут нужно как-нибудь по-другому проверять
Если нужно накапливать какую-то информацию, то да, можно определить массив и он будет храниться на блокчейне.
Сам контракт может хранить эфир, смотрите в сторону ключевого слова payable, его надо добавлять к методам, тогда во время вызова можно будет указать количество эфира, которое перейдет вместе с транзакцией.
Рандом в самом блокчейне невозможен, нужно использовать внешний генератор, смотрите Oraclize, он не только для рандома, а вообще для получения внешних данных.
1

Information

Rating
Does not participate
Location
Воронеж, Воронежская обл., Россия
Date of birth
Registered
Activity