Стало лучше. Для жизни точно, при том существенно. Убрали огромное кол-во синих заборов, сделали пару дорог, общественные пространства, добавилась станция метро.
Очередной коммент, использующий слово «статья», не объясняющий и не определяющий понятие «статья», как будто это так просто и все должны знать что это такое.
Мы работали в этом направлении, правда на с AI. Слишком много концептуальных вопросов, ответить на которые «здесь и сейчас» невозможно. Не то состояние принятия технологии и рынка в целом, чтобы можно было серьезно думать об этом. Но это лишь мои выводы, ваши могут быть совершенно другие — пробуйте!)
Что получается в случае с блокчейн-логикой на бэкенде? Ключами распоряжаются централизованно и нет никакой защиты от несогласованных с пользователем транзакций
Это неправда. Есть вариант, когда мы выдаем пользователю приватный ключ и платежный пароль при помощи которого шифруем PK на бекенде. Таким образом у держателя бекенда есть доступ только к зашифрованному PK, который без платежного пароля бесполезен. Пользователь же может в любой момент импортировать свой PK в любой удобный кошелек, а при использовании нашего бекенда подтверждать транзакции своим платежным паролем.
Есть и вариант когда мы не храним у себя даже зашифрованный pk. Отдаем пользователю mnemonic + pk, у себя сохраняем соль. При совершении транзакции просим у юзера mnemonic, при помощи соли получаем pk на беке, как мы делаем в нашем icodashboard.space
Но в целом — в 99.9% случаев блокчейн конечно же не нужен. Но с точки зрения разработчика — ознакомиться и быть в курсе несомненно стоит. Я думаю, что в ближайшие пару лет чуда не произойдет и мы не найдем применения помимо трансфера активов, но в перспективе 5-10 лет — почему бы и нет?)
Учитывая все эти числа, мы можем вспомнить, что создание контракта — это единовременный процесс, поэтому могу заключить, что оптимизация развёртывания смарт-контрактов не является сейчас важным вопросом для Ethereum. Уверен, что ещё вернусь к этому вопросу в будущем, а сейчас есть ещё много интересных проблем оптимизации, связанных с байт-кодом самих контрактов.
Мне в практике достаточно часто попадаются огромные, монолитные контракты, деплой которых не помещается в блок. Это я просто к возможным темам)
Можете посмотреть в сторону truffle framework, там есть инструменты для тестирования и деплоя. «Сборка», как правило ограничивается заменой импортов содержимым тех самых файлов, например, можно использовать npm-пакет `sol-merger`. Но такая «сборка» нужна только в целях верификации контрактов, потому что верификация etherscan не умеет работать с импортами.
что компаниям похрен на качество, и они ждут только бабло, а разработчики и рады покорее отстреляться и пойти к следующему клиенту.
Более того, я не уверен, что большинство ICOшек аутсоряст создание СК и личных кабинетов. По моей личной практике и опыту общения с другими компаниями, большинство все таки стараются делать это in-house. А в таком ключе Ваши слова выше вообще слабо соотносятся с реальностью.
Looks scammy вытекает вовсе не из кода, вот о чем я говорю. Вообще, сейчас вполне нормальная практика иметь ЛК инвестора, в котором ты даже не можешь посмотреть адрес СК. 90% ICO которые я вижу сейчас поступают так. Для интересующихся всегда есть github. А скамануть можно и с безупречным смарт-контрактом и целым отрядом Escrow-агентов. Скам\не скам это не об этом
Они позволяют установить нужные значения в свойства контракта не изменив его адрес. Если тебе говорят, что не знают, по какой цене будут продавать токены, то делаешь свойство tokenPrice и метод setTokenPrice с модификатором onlyOwner. И не надо ничего передеплоивать при изменении мнения заказчика относительно цены.
Довольно забавно еще читать про «точку зрения инвесторов». Это я о верифицированных контрактах, контрактах-контроллерах и тому подобном. Якобы, инвесторам это важно. Может быть, у вас какая-то другая практика, но по моему опыту, крупные инвесторы, которые дают 80% средств ICO вообще не понимают, что такое смарт-контракт и уж тем более не разбираются ни в каком коде. Многим даже приходится объяснять, как купить крипту. Код смотрят программисты. Ни больше ни меньше и рассчитывать что кому-то кроме них он будет интересен — такое себе. Это конечно не отменяет необходимость верификации, но причины совершенно другие, нежели траст со стороны инвесторов
Помните, что вы имеете дело со смарт-контрактом, который невозможно поправить, единожды задеплоив. И у вас есть отличная возможность (перепутав, к примеру, даты) выкатить контракт, который в какой-то момент залочит все средства пользователей — и вы никогда их не достанете.
Ага, а геттеры и сеттеры с модификатором onlyOwner это вид черной магии.
Плюсану, ровно та же история. У меня хорошо наполненный GitHub профайл, а с моей нынешней работы меня не утащишь ни за что, очень от нее кайфую. А она от меня)
А личная жизнь вообще на то и ЛИЧНАЯ, чтобы никого, кроме меня она не беспокоила.
По-разному. Когда по утрам, когда по вечерам, когда на работе, у меня в целом нету четкого разделения на рабочее и нерабочее время(что скорее плохо, чем хорошо)
ru.wikipedia.org/wiki/%D0%A1%D1%85%D0%B5%D0%BC%D0%B0_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D1%81%D0%B5%D0%BA%D1%80%D0%B5%D1%82%D0%B0_%D0%A8%D0%B0%D0%BC%D0%B8%D1%80%D0%B0
Это неправда. Есть вариант, когда мы выдаем пользователю приватный ключ и платежный пароль при помощи которого шифруем PK на бекенде. Таким образом у держателя бекенда есть доступ только к зашифрованному PK, который без платежного пароля бесполезен. Пользователь же может в любой момент импортировать свой PK в любой удобный кошелек, а при использовании нашего бекенда подтверждать транзакции своим платежным паролем.
Есть и вариант когда мы не храним у себя даже зашифрованный pk. Отдаем пользователю mnemonic + pk, у себя сохраняем соль. При совершении транзакции просим у юзера mnemonic, при помощи соли получаем pk на беке, как мы делаем в нашем icodashboard.space
Но в целом — в 99.9% случаев блокчейн конечно же не нужен. Но с точки зрения разработчика — ознакомиться и быть в курсе несомненно стоит. Я думаю, что в ближайшие пару лет чуда не произойдет и мы не найдем применения помимо трансфера активов, но в перспективе 5-10 лет — почему бы и нет?)
Мне в практике достаточно часто попадаются огромные, монолитные контракты, деплой которых не помещается в блок. Это я просто к возможным темам)
Более того, я не уверен, что большинство ICOшек аутсоряст создание СК и личных кабинетов. По моей личной практике и опыту общения с другими компаниями, большинство все таки стараются делать это in-house. А в таком ключе Ваши слова выше вообще слабо соотносятся с реальностью.
Ага, а геттеры и сеттеры с модификатором onlyOwner это вид черной магии.
А личная жизнь вообще на то и ЛИЧНАЯ, чтобы никого, кроме меня она не беспокоила.