Погружение в разработку на Ethereum. Часть 0: блокчейн не нужен

Наверняка многие из вас задумывались, зачем вообще понадобился блокчейн и Ethereum в частности. Кто-то возможно пошел дальше и нашел множество красивых характеристик: децентрализация, прозрачность, доверие без посредников, взломостойкость. Это же просто отлично, правда? Да, но…


Блокчейн в текущем виде идеально подходит только для узкого круга задач, если не считать “добавить нанотехнологий для вау-эффекта” задачей (а под эту задачу можно подогнать что угодно). Конечно, с чего-то надо начинать, разные эксперименты прощупывают почву, показывают где можно ожидать спрос, где возникает неожиданный тупик, где недостатки оказываются не такими критичными, как предсказывалось. Но знать о границах необходимо, чтобы осознанно решать, можно ли в данном конкретном случае попытаться перешагнуть через них.

Кстати, Ethereum это не единственный и не самый лучший во всех отношениях вариант. Возможно, блокчейн как раз и подходит под вашу задачу, но какой-нибудь другой. Но далее говорим «блокчейн», имеем в виду «Ethereum»

Попробуем описать те особенности блокчейна и смарт контрактов, которые делают решение на первый взгляд перспективных задач неэффективными или вообще невозможными. Хотелось бы еще сказать, что пункты обобщенные, поэтому теоретически могут быть и вполне нормальные решения для конкретных use-кейсов. Поэтому относитесь к этому списку как к слабым местам Ethereum, нуждающимся в проработке перед началом проекта.

И еще, просьба простить если многое из этого покажется вам очевидным. Как показала практика, часто именно об этих вещах приходится разговаривать с клиентом в первую очередь.

1. Высокий порог вхождения

Если ваша аудитория — это обычные пользователи, а не блокчейн-энтузиасты, то очень небольшая часть будет заморачиваться, чтобы начать пользоваться вашим приложением. Представьте: надо не только установить Metamask или Mist с нодой, но еще и купить эфира, а это тоже нетривиальный процесс поначалу. То есть если ваша цель — максимальный охват аудитории, то Ethereum пока не подходит. Например делать магазин исключительно на смарт-контрактах скорее всего плохая идея.

Что делать?

• Предлагать преимущества, перекрывающие неудобства
• Целиться на аудиторию “в теме”
• Можно было бы скрыть блокчейн-логику от пользователя, положив ее на бэкенд, если бы не следующий пункт

2. Децентрализованная централизация

Все-таки плюс блокчейна в том, что участники могут максимально не доверять друг другу, но такое возможно только если пользователь сам хозяин своего приватного ключа. Тогда только он может подписывать транзакции и выполнять разные действия со своего адреса. Что получается в случае с блокчейн-логикой на бэкенде? Ключами распоряжаются централизованно и нет никакой защиты от несогласованных с пользователем транзакций — значит остается просто довериться порядочности и безопасности сервера. Так например большинство криптобирж хоть и оперирует криптовалютой, но никаких связанных с этим преимуществ не использует.

Что делать?

• Понять, нужны ли прозрачность и иммутабельность или возможность манипулирования криптой. Если нет — дешевле и удобнее использовать обычную базу данных
• Продумывать и прорабатывать механику работы так, чтобы сохранить технологические гарантии

3. Все данные публичны

Независимо от того, как написан смарт контракт, при желании можно получить значение любого поля данных в нем. И историю транзакций. Поэтому если вы записываете что-либо идентифицирующее пользователя, например почту или имя, то все, что делает этот пользователь становится достоянием общественности. Вполне возможно поверх придется навернуть какое-то шифрование. При этом ключи для этого придется хранить на принимающей стороне, то есть пользователь опять должен доверить свои данные третьей стороне. Поэтому для более-менее секретных данных обычное приватное хранилище может оказаться более оправданным. Если собрались заключать соглашения на блокчейне — возможно больше потеряете, чем приобретете.

Что делать?

Понять, требуются ли приватные данные для логики смарт контракта. Если да — рассмотреть вариант оперирования хешами вместо самих данных

4. Блокчейн — не суперкомпьютер

У кого-то может возникнуть впечатление, что майнеры пускают огромные мощности на выполнение полезных вычислений, но это конечно далеко не так. Хотелось бы на всякий случай прояснить: производительность Ethereum больше похожа на производительность встроенной системы — ограниченные ресурсы, ограниченная память, ограниченный размер “прошивки” (байт кода смарт контракта). Поэтому некритические вычисления надо по-максимуму выносить офф-чейн. По этой причине в смарт контрактах врядли получится сколько-нибудь сложно анализировать данные или скажем производить шифрование

Что делать?

• Не использовать блокчейн в качестве калькулятора
• Если нужны вычисления, контролирующиеся на блокчейне, можно рассмотреть фичу computation в oraclize

5. Блокчейн — не универсальное хранилище

Часто можно услышать запрос сохранять что-то на блокчейн: информацию или документы. Тут проблемы очевидны: во-первых сохранять данные дорого, во-вторых блокчейн никак не приспособлен например для поиска — либо у вас есть mapping (ключ — значение) который кстати тоже добавляет стоимости к каждой записи, либо придется искать перебором. Плюс нет управления разрешениями. Поэтому не стоит просто менять бд на блокчейн, важно понять зачем это в принципе понадобилось. Отдельно по файлам стоит помнить и о публичности данных: если вы скажем храните ссылку на IPFS, то все ее видят и могут скачать то, что по ней лежит. Так что если вы хотите хранить на блокчейне фотографии — стоит подумать зачем.

Что делать?

• Как правило все, что нужно — это просто сохранять хеш для верификации того, что лежит на офф-чейне
• Сохранять только данные, требующиеся для логики работы смарт контракта

6. Привязка блокчейна к реальному миру

Блокчейн сам в себе без проблем передает монеты/токены, но как передавать то, что за них покупается? Даже если это файл, как обеспечить подтверждение его передачи без третьей стороны? Короткий ответ: не очень просто, потому что мы предполагаем, что обе стороны хотят обмануть друг друга и от них потребуется куча проверок, шифрования-дешифрования, а если возник спор, то без офф-чейн вычислений или арбитра не обойтись. Как понимаете для физического товара или услуги все усложняется тем, что кто-то должен заносить информацию о том, что, грубо говоря, товар получен. Этот кто-то не может быть заинтересованным лицом, значит это третья сторона, которой мы опять же должны доверять. Тогда наше блокчейн решение имеет слабое место в виде вот этого арбитра, а раз мы ему доверяем, почему бы не доверить и все остальное, скажем хостить обычную базу и проводить платежи. Прежде чем делать что-то надо четко ответить на этот вопрос. То есть например смысл токена, который вы предлагаете обменять на скидку в оффлайн магазине, лично нам представляется сомнительным

Что делать?

Четко ответить себе, чем не подходит централизованная логика. Если ответа нет — отказаться от блокчейна

7. Нет страховки от ошибок пользователя

Если в банке вы по ошибке отправили деньги не туда или у вас взломали аккаунт, то есть вариант написать в поддержку, есть время отменить или откатить транзакцию. В смарт-контрактах вы не сможете вручную сделать то, что не предусмотрено кодом. Опять сталкиваемся с необходимостью введения арбитра, которому выдаются привилегии, сравнимые с централизацией всего решения.

Что делать?

При необходимости введение искусственной задержки перевода средств в смарт контракте

8. Долгое время выполнения транзакции

Если у вас динамичная система с постоянно перезаписывающимися состояниями и основанной на них логикой, то вас скорее всего не устроит время ожидания, т.к. по крайней мере в Ethereum нормальным временем подтверждения транзакции можно считать пол минуты, а если не разоряться на газ, то как правило больше. Даже если счет идет не на секунды, стоит учитывать возможность задержки транзакции на неопределенное время и закладывать достаточные интервалы. Так что пока такие игры как покер либо невозможны в чистом виде на смарт контрактах Ethereum, либо нетривиальны и требуют упор на оффчейн логику

Что делать?

• Если вы планируете очень частое обращение к блокчейну, стоит смотреть не в сторону Ethereum, а может вообще и не в сторону блокчейна
• По возможности собирать несколько транзакций в одну, выполняя часть логики оффчейн
• В крайнем случае можно увеличивать цену за газ по мере необходимости
• Если транзакция долго не проходит, можно указать увеличенную цену и послать ее еще раз (транзакция должна остаться неизменной, включая nonce). Более дорогая заменит более дешевую

9. Обход цензуры пока не идеальный

Если вы с помощью блокчейна хотите противостоять правительству или что-то в таком духе, знайте, что веб-сервис это все еще централизованная штука, хоть даже он основан на блокчейне. То есть доменное имя или ip можно все так же легко заблокировать и пользователи должны будут узнать адрес зеркала. Преимущества — не надо делать бэкапы базы и зная адрес в сети Ethereum, можно всегда получить доступ менее user-friendly средствами (Mist, MyEtherWallet, etherscan и т.д.) Но нельзя сказать что проблема цензуры решена полностью.

Что делать?

Устойчивость к блокировкам это бонус, но не стоит на нем основывать решение использовать блокчейн или нет

Если не Ethereum, то кто?

Много кто. Другие блокчейн и не-блокчейн решения могут пожертвовать либо децентрализованностью, либо открытостью, либо доступностью для неограниченного количества участников, в обмен получив увеличенную скорость транзакций, отсутствие проблем с приватностью и т.д. Это EOS, решения на Hyberledger, Exonum, Hashgraph, Corda и многое другое. Но есть такой немаловажный фактор, как имя на слуху. Это и большая база пользователей, и большая база приложений, информации и средств для разработки, оттестированность. А это можно записать в плюсы к Ethereum. И посмотрим, что принесут Casper и Sharding.

Так ли все плохо?

Самый главный вопрос, проходящий через все эти пункты — осознанность выбора именно блокчейна. Важно, чтобы технология решала проблему, добавление блокчейна в уже решенную задачу скорее всего не сделает решение более эффективным.
Например если вы неизвестно кто и хотите запустить казино, то у вас проблема заработать репутацию, показать честность и привлечь какую-то базу пользователей. Предлагая решение на Ethereum вы можете хотя бы теоретически гарантировать пользователям прозрачную работу (хоть и мало кто будет на самом деле аудировать ваш смарт контракт перед игрой). И привлекаете людей с лишней криптовалютой на счету и недостаточным количеством возможностей ее применения. Можно сказать, что цель достигается.
А если вы хотите добавить блокчейн в мессенджер, то скорее всего не только не решите проблемы (а какие они могут быть? — в голову приходят цензура и приватность), но и добавите новых.
Найти больше правильных применений — возможно дело будущего, когда вырастет база пользователей и покупать криптовалюту будет легче чем сейчас. Но в целом можно смотреть в сторону таких применений:

1. Бюрократизированные и долгие процессы: переводы заграницу, оформление документов
2. Процессы основанные на доверии к платформе: фонды, казино
3. Данные, использующиеся в разных областях или несвязанных компаниях: туроператоры, кредитная история, черные списки
4. Контроль не вызывающих доверия процессов: голосования, fundraising

Принадлежность задачи к одному из пунктов не значит, что блокчейн идеально впишется. Всегда смотрите что предлагают другие, более оптимизированные технологии. То есть ход мысли должен быть «как бы решить эту проблему», а не «куда бы прикрутить блокчейн».

Погружение в разработку на Ethereum:
Часть 1: введение
Часть 2: Web3.js и газ
Часть 3: приложение для пользователя
Часть 4: деплой и дебаг в truffle, ganache, infura
Часть 5: Oraclize

Автор: rubyruby

Источник