Привет, Хабр! Меня зовут Иван, я разрабатываю сервис онлайн-голосований WE.Vote на основе блокчейн-платформы Waves Enterprise. Сама идея голосований в онлайне уже давным-давно реализована разными компаниями, но в любых кейсах повышенной ответственности все равно прибегают к старой доброй бумаге. Давайте посмотрим, как электронное голосование сможет посостязаться с ней в максимально строгих условиях.

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

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

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

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

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

Стоит ли, положившись на идеальность нашего мира, отвечать на оба вопроса да? Или мы можем создать техническое решение, отвечающее всем требованиям?Давайте посмотрим.

Чего мы хотим добиться

На самом абстрактном уровне всё, что делают информационные системы, это создают/изменяют данные, передают данные, хранят данные, а также дают доступ к этим данным.В применении к онлайн-голосованиям это выглядит следующим образом:

1. Организатор голосования создает повестку и хочет управлять правилами доступа к этой повестке: сделать ли ее публичной или раскрыть только участникам голосования.

2. Организатор голосования создает список его участников и хочет быть уверенным, что в его голосовании примут участие именно они. Сами участники также заинтересованы в этом, так как подразумевается, что они принимают решение по важному для них вопросу и мнение/намерения/выгода третьих лиц не должны на это решение повлиять.

3. Организатор задает правила проведения голосования. Эти правила без раскрытия сути голосования должны быть доступны широкой публике, чтобы организатор, участники голосования и третьи лица (например, регулятор) могли убедиться, что способ принятия решения был выбран корректно и все прошло по заранее известному плану.

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

5. Участник голосования заполняет бюллетень и хочет убедиться, что его голос будет учтен, его голос не будет изменен и никто не сможет определить, как именно он проголосовал (частный случай открытых голосований оставим в стороне).

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

При чем тут блокчейн

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

Распределенное хранение

С ходу напрашивается решение использовать блокчейн для хранения данных голосования.Так при правильном развертывании сети блокчейн-узловмы сможем не беспокоиться о том, что оператор сервиса единолично подменит записанные данные. Проблема надежного хранения исторической информации решена.

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

Естественно, встает вопрос хранения конфиденциальных данных. Блокчейнсам по себене позволяет таких фокусов, поэтому нам надо разобраться,какие данные в системе являются открытыми, а какие приватными. Атакженайти методы защиты конфиденциальных данных. Например, при создании голосования мы имеем следующий набор данных:

• повестка и материалы голосования;

• контактные данные пользователей идентификатор пользователей в реальном мире (e-mail или номер телефона);

• персональные данные пользователей в целом, в системе не требуются, но делают работу удобнее как для организатора голосования, так и для самих участников;

• пара публичного и приватного ключей участника голосования работают как внутрисистемный идентификатор пользователя и дают возможность участвовать вголосовании.

С повесткой и материалами голосования мы можем работать как любой другой облачный сервис: организатор голосования загружает их на сервер (бэкенд), и их доступность определяется ролевой моделью: участникам голосования мы их показываем, от остальных прячем. Для уверенности в том, что на бэкенде ничего с повесткой не произойдет, сохраним в блокчейне хеш от материалов, хранящихся на сервере. Организатор видит, что в голосовании зафиксировано именно то содержание голосования, которое он планировал, участники голосования при получении повестки также могут убедиться, что повестка эта у всех едина.

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

Пара ключей создается пользователем локально, на его персональном устройстве. Приватный ключ этого устройства не покидает, а публичный сохраняется набэкендекак параметр учетной записи. Организатор голосования работает со списком участников в виде Ф.И.О. и e-mail. При сохранении данных голосования в блокчейне туда же уходит список публичных ключей. Голос подписан ключом пользователя, и если публичный ключ отправителя есть в списке участников, мы принимаем бюллетень. Такая схема позволяет,с одной стороны,не светить персональными данными пользователей, а с другой сделать более прозрачной работу системы.

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

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

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

Подводя промежуточный итог, можно сказать,что:

• Мы решили проблему прозрачности и immutable-хранения исторических данных, используя блокчейн.

• Управление видимостью конфиденциальных данных мы организовали классическим централизованным образом, но внесли дополнительный механизм контроля информации на бэкенде через хеши-якоря, хранящиеся в блокчейне.

• Работу с информацией об участниках голосования мы разделили. Персональные данные хранятся классическим образом, а взаимодействие происходит с уникальным блокчейн-идентификатором, от имени которого пользователь отправляет свой голос.

Но, несмотря на то что мы обещали обойтись без магии, она все-таки произошла. Для шифрования бюллетеней нам понадобился открытый ключ голосования, но никто не сказал, откуда он взялся! Очевидно, что это предельно важная часть всего процесса голосования и к нему нельзя отнестись легкомысленно. Еще более интересным кусочком пазла является приватный ключ, соответствующий открытому ключу голосования, так как именно с его помощью мы сможем получить итоги голосования.Настал момент шагнуть в область криптографии (которая для 99.9% людей не сильно отличается от магии).

Криптография

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

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

Несколько болеенадежным вариантом будет техника разделения приватного ключа после генерации хорошо известная схема разделения секрета Шамира. Ключевая пара создается, публичный ключ сохраняется в блокчейне как открытый ключ голосования, а приватный ключ разделяется на несколько частей, которые независимо хранятся доверенными участниками. Чтобы подвести итоги голосования, приватный ключ необходимо собрать и после этого расшифровать бюллетени. Если кто-то из доверенных участников заболел, схема Шамира предполагает возможность сбора приватного ключа меньшим количеством участников. То есть если ключ был разбит на N частей, собрать обратно его можно, используя K частей, где K < N.

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

Конечно, существуют механизмы разрыва первой связки персональных данных и открытого ключа через технику слепой подписи, но это очень своеобразный механизм, который необходимо правильно внедрить. При этом всё равно может сохраниться возможность вычислить по IP голосующего. Он приходит на авторизованный метод получать слепую подпись, а потом стучится на неавторизованный метод отправить голос. Формально во втором случае мы не знаем, кто именно к нам пришел, и опираемся только на проверку слепой подписи. Но у нас есть возможность сопоставить параметры устройства/браузера/соединения и понять, что это тот самый Иванов, который 5 минут назад получал у нас слепую подпись. Или представим похожую атаку на сопоставление по времени получения подписи и отправки голоса. Когда голосующие идут толпой по 500 человек в секунду, такая атака теряет свою эффективность, но при меньшей нагрузке вполне себе работает.

Попробуем сделать лучше?

Распределенная генерация ключа

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

Для формирования общегооткрытогоключа голосования (MainPubliсKey) используется алгоритм DKG (distributed key generation) из статьи TorbenPrydsPedersenA threshold cryptosystem without a trusted party,перенесенный на эллиптические кривые (в оригинальной статье используется мультипликативная группа конечного поля (поля Галуа)GF(p)). При этом есть ограничение:при любой жалобе (не сходится контрольная сумма) одного из участников на другого необходимо перезапустить процесс генерации с самого начала.

В нашей текущей реализации DKG используются стандартные эллиптические кривые seсp256k1 (Bitcoin, Ethereum) и функция хеширования SHA-256. Можно легко добавить, например, Ed25519 или даже российские кривые ТК-26 и хеш Стрибог, если потребуется. Также можно не завязываться на 256-битных кривых, а использовать 512-битные.

Участниками DKG у нас будут несколько экземпляров криптографических сервисов, выполняющих всю криптографическую магию. Чтобы не возникало вопросов о возможности непрозрачного общения между сервисами, единственным их интерфейсом будет взаимодействие с блокчейн-нодой. Один декрипт одна нода. Принципиально такое соотношение 1 к 1 не требуется, декриптов может быть больше или меньше чем нод, но выглядит логичным иметь одинаковый уровень децентрализации как на слое хранения/транспорта данных (см. раздел выше), так и на слое криптографии.

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

Протокол DKG Pedersen 91 на эллиптических кривых

Параметры протокола:

1. Эллиптическая кривая E и генератор (Base) подгруппы этой кривой большого простого порядка q.

2. Другой генератор (BaseCommit) той же подгруппы, для которого число x из соотношения BaseCommit = x * Base неизвестно никому.

3. (k, n), гдеnобщее число развернутых криптографических сервисов (DecryptService), сгенерировавших пары ключей, аkминимальное число сервисов, которое необходимо для восстановления общего секрета. k <= (n+1)/2, то есть еслиk - 1участниковнечестные или у них украли ключи, то это никак не повлияет на безопасность общего секрета (MainPubliсKey).

Шаг 0. Индексы DecryptService

Каждому изnDecryptServiceприсваивается уникальный порядковый номер от 1 доn. Это нужно, потому что от порядкового номераDecryptServiceзависит коэффициент Лагранжа, который потребуется для реализации схемы K из N.

Шаг 1. Создание открытого ключа голосования

Каждый изnDecryptServiceгенерирует пару публичного (Pub_n)и приватного (priv_n) ключей для эллиптической кривой: j-йсервер генерирует пару ключей:priv_j,Pub_j,гдеPub_j = priv_j * Base(точка Base генератор простой подгруппы). И делает Pedersen commitment для публичного ключа:

1. Генерируется случайное число, скалярr_j.

2. Вычисляется точка, коммитС_j = r * BaseCommit + Pub_j.

3. С_jпубликуется в блокчейн.

После того как каждый изnDecryptServiceопубликовал свой коммит ПедерсенаС_j, каждый DecryptService публикует свой скалярr_j. На основе опубликованных в блокчейне скаляров любой сторонний наблюдатель может восстановить публичные ключи каждого DecryptService Pub_j =С_j -r * BaseCommit а затем вычислить общий публичный ключ Pub (MainPublicKey) как сумму отдельныхPub_j.

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

Шаг 2. Генерация полиномов и раздача теней

Каждыйj-йDecryptService случайным образом:

• Генерирует полином степениk - 1:f_j(x) = f_j_0 + f_j_1*x + ... + f_j_k-1* x^(k-1), где коэффициентf_j0 = priv_j, а остальные случайные элементы поляGF(q), гдеq порядок подгруппы точек.

• Считает значения полинома для каждогоi-гоизnзначений:f_j(i) = f_j_0+ f_j_1*i + ... + f_j_k-1* i^(k-1). Значениеf_j(i)называется тенью (shadow).

• Шифруетf_j(i)при помощиPub_iдля всех других серверов и публикует результаты шифрования. Таким образом,значениеf_j(i)может узнать только владелецpriv_i, т.е. DecryptService номерi.

Шаг 3. Проверка коэффициентов полиномов

Чтобы убедиться, что каждый из DecryptService следует протоколу DKG, они проверяют значения теней, полученных друг от друга. Каждый DecryptServiceпубликует каждый коэффициент своего полинома, умноженного на генератор Base: j-й сервер:f_j,0* Base, f_j,1* Base, ... , f_j,k-1* Base, где f_j,k-1 это коэффициент при степениk - 1.

После этого каждыйi-йDecryptServiceпроверяет все расшифрованные тениf_j(i)(гдеjиз множества от 1 доn, исключаяi), которые для него зашифровали другиеn - 1участников DKG. i-йDecryptServiceдля тени от сервераj:

1. Вычисляетf_j(i) * Base

2. Берет экспоненты его коэффициентов:f_j,0* Base, f_j.1* Base, ... , f_j,k-1* Base

3. Домножает каждый на соответствующую степеньi:f_j,0* Base, i * ( f_j,1* Base), ... , i^(k-1) * ( f_j,k-1* Base)

4. Складывает их.

Если результат сложения равенf_j(i) * Base(тень отjдляi, умноженная на генератор), то результат принимается. В противном случае публикуется жалоба на серверj: значение тениf_j(i), и протокол запускается с самого начала шага 0.

Если ни у кого нет жалоб, то каждый сервер вычисляет свой секретный ключs_iкак сумму значенийf_j(i)от всехjсерверов, включая себя.

Если взять любые изkучастников, то сложив ихs_i * Lagrange(k, i), где Lagrange(k, i) коэффициент Лагранжа, который зависит от номеров из выбранной группы (k) и номераi, мы получим приватный ключ, соответствующий общему ключу Pub (MainPublicKey), то есть по сути сумму всехpriv_i.

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

Мы решили проблему угона приватного ключа до начала голосования. Он не был создан централизовано, и чтобы получить доступ к данным голосования, злоумышленнику необходимо взломать K серверов, а не один. Но остается вопрос: как мы будем проводить расшифровывание. Будем ли мы собирать приватный ключ в этот момент и дадим ли шанс злоумышленнику? Пожалуй, не дадим.

Шаг 4. Распределенное дешифрование

Допустим, мы зашифровываем сообщение M на открытом ключе голосования (MainPublicKey):

1. Генерируем число r и считаем R = r * Base.

2. ВычисляемС = M + r *MainPublicKey.

3. Получившийся шифротекст пара точек (R, C) мы публикуем в блокчейне.

4. Владелец приватного ключаprivвычисляет значение:priv * R.

5. И расшифровываетM:M = С -priv * R.

Таким образом, для расшифровывания (R, C) нужно вычислитьpriv * R.

Если наш приватный ключ распределен (допустим, что (k, n) = (3,6)), каждый криптографический сервис независимо считает значениеs_i * R, используя свою часть приватного ключа, и публикует результат в блокчейне. Назовем это значение частичной расшифровкой. Дальше остается домножить любые 3 из 6 результатовs_i * Rна соответствующий коэффициент Лагранжа, сложить три точки и получить priv * R. А используя это значение, мы расшифровываем сообщение М.

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

Гомоморфное шифрование

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

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

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

Использовать такую возможность в голосовании мы можем, представив бюллетень в виде матрицы, где каждая строка это отдельный вопрос, по которому принимается решение, а ячейки в пределах строки это варианты ответов на этот вопрос. Заполняя бюллетень, участник голосования выбирает вариант, и мы обозначаем его единицей. Остальные ячейки заполняются нулями. Затем мы шифруем каждую ячейку бюллетеня. Именно в таком зашифрованном виде бюллетень попадает в блокчейн. Что именно зашифровано в каждой ячейке мы не знаем.

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

В итоге мы получаем не только совместную и прозрачную работу нескольких независимых сервисов при вычислении итогов голосования, где ни один из них не может эти результаты подтасовать. Мы также добились очень высокого уровня конфиденциальности голосования. Мы анонимизировали выбор участников голосования через сложение столбиком у нас есть сумма, но нам неизвестны слагаемые!

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

Зашифрованное сообщение 1: ( R1, С1 ) =( r1 * Base,M1 + r1 *MainPublicKey)

Зашифрованное сообщение 2: ( R2, С2 ) =( r2 * Base,M2 + r2 *MainPublicKey)

Их сумма: ( R1 + R2, C1 + C2 ) = ( ( r1+r2 ) * Base, M1 + M2 + ( r1 + r2 ) *MainPublicKey)

Сумму расшифровываем так же, как отдельные сообщения (помним чтоMainPublicKey= priv * Base):

( M1 + M2 ) = ( C1 + C2 ) priv * ( R1 + R2 ) = M1 + M2 + ( r1 + r2 ) *MainPublicKey priv * ( r1 + r2 ) * Base = M1 + M2

Кто-то скажет магия, кто-то возразит математика.

В результате мы, кажется, сделали все возможное, чтобы защитить участника голосования. Его голос нельзя подделать, его нельзя прочитать, его практически нельзя заблокировать или потерять. Участника голосования нельзя лишить премии за выбор неправильного кандидата.

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

Доказательства с нулевым разглашением (ZKP Zero Knowledge Proofs)

Однако не только организатор или внешний злоумышленник могут иметь мотивацию повлиять на исход выборов. Нарушитель может затесаться и в ряды участников голосования. Поскольку мы используем очень простую механику сложения столбиком и не заглядываем в индивидуальные бюллетени, у участника голосования есть возможность покопаться в клиентском приложении и сформировать бюллетень, где он вместо "1" проставит за своего кандидата значение 100500. Или 100500 за того, кого недолюбливает. Система посчитает итоги, и кандидат нарушителя победит с внушительным преимуществом.

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

Одна из самых наглядных демонстраций работы ZKP (интерактивной разновидности) это Пещера Али-Бабы или Лабиринт:

Участник A обладает ключом, открывающим дверь в лабиринте, и хочет доказать это участнику B, но не хочет показывать ключ. Чтобы В мог убедиться в верности утверждения А, они организуют серию испытаний:

1. А заходит в лабиринт пока В отвернулся. В не знает, в какую сторону пошел А.

2. В дает А указание выйти с какой-либо стороны, например, слева.

3. Если А действительно обладает ключом, он может появиться с любой стороны и выполняет указание В.

Шанс того, что А просто повезло, и он, не имея ключа, изначально пошел налево, составляет 50/50. Поэтому они повторяют испытание еще и еще раз, пока вероятность везения не станет пренебрежимо малой, и В не признает, что А действительно обладает ключом. При этом В не увидит самого ключа, не получит никакой информации, которой обладает А (направление, которое А выбирает в каждом испытании), но в результате серии испытаний он получит достоверное (вероятностное, но с любой необходимой В точностью) доказательство.

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

ZKP на бюллетене

По каждому вопросу мы, помимо заполненных и зашифрованных ячеек с вариантами выбора, к каждой ячейке приложим NIZK, доказывающее, что в этой ячейке зашифровано одно из значений 0 или 1 но не раскрывающее, какое именно. И дополнительно приложим доказательство, что зашифрованная сумма значений всех ячеек по вопросу равна 1. Это означает, что участник голосования может поставить 1 в любую из ячеек и выбрать только один вариант.

При желании (а оно у нас есть) мы можем на базе этой схемы ZKP реализовать более сложные схемы голосований. Например, взвешенное голосование, где каждый участник отдает не один голос, а количество голосов, пропорциональное своей доле акций компании. Для этого мы должны вместо 1 создать ZKP для значения веса голоса участника. Или вариант голосования с множественным выбором, где каждый голосующий может выбрать не один вариант из N, а несколько. Для этого мы по каждой ячейке добавляем ZKP для ряда значений [0, 1, 2, 3]. Суммарный ZKP может быть на значение [3] тогда голосующий должен распределить все свои голоса. Или на ряд значений[1, 2, 3] то есть он может выбрать от 1 до 3 вариантов, но не может не ответить на вопрос.

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

Структура зашифрованного бюллетеня выглядит следующим образом:

(R_1, C_1), Proof_1,

.........................

(R_M, C_M), Proof_M,

Sum_Proof

Система принимает только те бюллетени, все ZKP которых прошли проверку валидности. То есть наш нарушитель из числа участников голосования может испортить свой бюллетень (так же как в случае с бумажным бланком), но не может воспользоваться тем, что мы не подсматриваем в содержимое его голоса мы имеем возможность убедиться в правильном заполнении бюллетеня без его расшифровки.

ZKP на частичных расшифровках

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

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

Второе условие: если расшифровывание нескладывается,и мы подозреваем, что некоторые криптографические сервисы решили саботировать голосование, неплохо бы иметь возможность проверить, какой именно из сервисов сбоит. Для этого при публикации частичных расшифровок каждый криптосервис создает и прикладывает ZK-доказательство расшифровки, используя алгоритмZKP Chaum-Pedersen, который доказывает знание числа x для двух соотношений A = x * B и C = x * D (где A B, C, D точки на одной кривой).

Теперь у любого квалифицированного стороннего наблюдателя есть возможность:

• самостоятельно провести гомоморфное сложение валидных бюллетеней и получить итоговый бюллетень;

• проверить доказательства расшифровки этого суммарного бюллетеня от каждого криптографического сервиса;

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

Для удобства последний шаг мы проведем сами и зафиксируем итоги голосования в блокчейне как массива массивов вида [ [ 2,5,6 ], [ 3,5,5 ], [ 7,6 ], [ 10,3 ] ].

Смарт-контракты

Фух, кажется, мы описали протокол голосования, который, используя распределенные технологии и криптографию, позволяет дать честным участникам и организаторам голосований все необходимые гарантии и защищает процесс коллективного принятия решений от внутреннего и внешнего нарушителя. Очевидно, при условии правильной децентрализации распределении узлов системы между независимыми участниками; без этого мы получаем замороченные Google Forms :)

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

Именно такую роль выполняют смарт-контракты в блокчейне. Это умный ящик для голосования, который фиксируетправила голосования,хранит список участников и статусную модель голосования: какой публичный ключ принадлежит участнику, какой криптографическому сервису. Также смарт-контракт регистрирует публичные данные протокола DKG, проверяет и сохраняет отправленные голоса и результаты голосования.

А что дальше?

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

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

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

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

Когда сегодня прочитал новость про то, что глава Twitter Джек Дорси выставил на торги свой первый твит и его цена уже какая-то неприлично высокая, сразу вспомнилась одна давняя история о том, как запускали "продажу твитов". Правда задача была несколько иная не продавать какие-то исторически важные твиты, а реализовать смарт-контракт для сообщества одной блокчейн платформы, который бы позволял всем желающим писать в твиттер сообщества... за токены этой самой платформы.

Смарт-контракт

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

В нашем же случае смарт-контракт определен следующим образом: любая транзакция в сети блокчейн, удовлетворяющая определённым требованиям, должна привести к публикации твита в определенном аккаунте. Такое "соглашение" нужно было для того, чтобы любой участник сообщества без какой-либо цензуры мог высказаться в твиттере сообщества, а другие участники могли прочитать это. Условия смарт-контракта следующие:

• Транзакция с содержаниям текста должна была быть отправлена на советующий адрес в сети блокчейн

• Стоимость одной транзакции должна быть выше 1 WCT (специализированный токен сообщества)

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

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

Имплементация смарт-контракта

Прелесть заключается в том, чтобы реализовать смарт-контракт с такой логикой, фактически вообще не нужно обладать супер специфическими знаниями, поднимать какую-то сложную инфраструктуру и вот почему:

• Тебе не нужно поднимать и держать свой узел сети блокчейн достаточно регулярно "просматривать" последние транзакции в сети и если там что-то пришло на определенный адрес - запускать логику смарт-контракта. Для этого у всех приличных блокчейнов давно реализованы публичные rest-api

• Для реализации смарт-контракта нужна более или менее надежная инфраструктура, которая позволит регулярно по REST API "заглядывать" в блокчейн и если там что-то есть, постить это через REST API twitter-a в соответствующий адрес. В общем-то и все, т.е. никаких солидетей или прочих дикостей блокчейна знать не надо, вполне подойдут языки, на которых пишут hello world-ы школьники.

• Да, нужно понимать как устроены транзакции в блокчейне, нужно понимать, что такое подтверждения, форки сети и т.п. Но по большому счету разобраться не проблема.

Да, наверное единственной особенностью является то, что было решено использовать Lambda функцию AWS(как следствие небольшие заморочки с тем как и где хранить последнюю "высоту" блока с транзакциями между запусками функции), но это только для того, чтобы не платить за полноценную инфраструктуру(да и зачем), чтобы выполнять одну рутинную операцию. При этом, вся эта инфраструктура ничего не стоит - это входит в "бесплатный порог использования ресурсов".

И этот смарт-контракт работает в таком виде вот уже более 2х-лет, с января 2019 года и за это время, на моей памяти, был всего один инцидент, когда текст с отправленной транзакций не было опубликован и связано это было с тем, что сам твиттер не пропустил через свой API откровенно "рекламный твит". В остальном вся история публична и максимально прозрачна:

• Аккаунт в твиттере: https://twitter.com/wctgram/

• История твиттов в блокчейне: 3P4gHFYo6UrW31XAhsPv1W9PHJKyE4BE8kb

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

P.S.: А цена NFT токена "мема" в заголовке статьи выше $20к по текущему курсу.

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

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

По тем или иным причинам могут произойти какие - либо изменения в данных и без злого умысла сбой в электропитании, выход из строя оборудования и прочее.

Как это работает?

Итак, есть данные и их нужно защитить от нежелательных изменений. Информация может быть любая транзакции денежных средств, перемещение посылок, билеты на самолёт и т.д.

Информацию (данные) мы будем делить на части (блоки) и будем выстраивать цепочку этих блоков.

В нашем примере будут хранится данные о денежных транзакциях.

Создадим первый блок.

Так как блок первый в нём будут хранится только данные и номер блока.

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

Для наглядности можно сформировать массив данных, состоящий из хэша и номера кошелька.

Хэш функцию будем использовать не SHA 256, а по проще MD5, просто получаемый хэш с помощью этой функции лучше читаем человеком (он короче), чем SHA 256.

Хэш первого кошелька будет c4ca4238a0b923820dcc509a6f75849b (это цифра 1).

Объём выпуска нашей криптовалюты 1 млн.

В блок поместим номер блока (цифру 1) и будем нумеровать блоки последовательно (1, 2, 3, ).

Это всё, что будет храниться в нашем первом блоке и хэш первого блока будет таким: 45d04629fc2f54182ba55aad029152ae.

Второй блок будет содержать данные о транзакциях, хэш блока 1 и соответственно свой номер блока 2.

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

Данные в блоке

Третий и последующие блоки будет построены по аналогии со вторым.

Таким образом мы получим следующую цепочку блоков.

Изменение в любом из блоков повлечёт изменения его собственного хэша и хэша всех последующих блоков.

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

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

Смарт - контракт

Что такое смарт-контракт и как он работает?

Как и в обычном контракте для совершения сделки (приобретения или отчуждения чего-либо) необходимо выполнить определённые условия и произвести определённые действия.

Предположим, стороне 1 (первый контрагент) необходимо продать криптовалюту и купить рубли, и есть другая сторона (контрагент 2), кто хочет продать рубли и купить криптовалюту.

Чтобы состоялась сделка (контракт был исполнен) необходимо выполнение определённых условий, то есть необходим алгоритм, который проверяет эти условия для того, чтобы прошла транзакция в следствии которой контрагент 1 получит определённую сумму рублей по определённому курсу, а другой контрагент (2) криптовалюту в соответствующем объёме и по соответствующему курсу (установленному курсы, например криптовалютной биржей).

Прежде чем совершить сделку одного лица с другим (контрагентов 1 и 2) необходимо проверить есть ли у контрагента 1 необходимое количество криптовалюты для совершения сделки, уплаты комиссии, налогов, и есть ли у контрагента 2 необходимая сумма рублей для совершения сделки, уплаты комиссии, налогов и пр.

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

На счета могут быть наложены ограничения, например по размеру суммы и это нужно тоже проверить.

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

Выполнение условий контролируют по обычному контракту сами стороны (участники сделки) или третьи стороны, например сотрудниками банка, юристами и т.д., что бывает стоит не дёшево и затрачивается на эти процедуры много времени.

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

PHP код для совершения операции продажи криптовалюты (ETH) и покупки рублей на бирже exmo.me.

<?php//exmo.me$key = 'K-9';$secret = 'S-6';$mt = explode(' ', microtime());$NONCE = $mt[1] . substr($mt[0], 2, 6);$url = "https://api.exmo.com/v1.1/order_create";$req = array("nonce"=>$NONCE,"pair"=>"ETC_RUB","quantity"=>0.01, //объём"price"=>449.0754, //цена"type"=>"buy",);$post_data = http_build_query($req, '', '&');$sign = hash_hmac('sha512', $post_data, $secret);$headers = array('Sign: ' . $sign,'Key: ' . $key,);$ch = curl_init();curl_setopt($ch, CURLOPT_URL, $url);curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);curl_setopt($ch, CURLOPT_POST, 1);curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);$output = curl_exec($ch);$output = json_decode($output, true);echo '<pre>';var_dump($output);echo '</pre>';?>

Привет хабр! Недавно заметил, что на рускоязычную аудиторию очень мало туториялов чтобы войти в мир блокчейна и разрабатывать там. Решил поделиться статьей про смарт-контракты на Ethereum. Эта статья очень помогла мне когда-то, вникнуть в мир блокчейна и разрабатывать там смарт контракты. Оригинал статьи по этой ссылке.

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

Если компания сама обманывает некоторые транзакции и получает деньги, как вы узнаете, что вас обманули?

Именно здесь децентрализованная установка является оптимальным решением.
Если нет третьей стороны, продавцы могут зарабатывать больше безопасным способом.

Список функций

1. Создание аукциона

2. Размещение ставки

3. Завершение аукциона

Инструменты

1. Смарт-контрактSolidity,Remix,Metamask

2. FrontendWeb3.js,Vue.js,Вью-кли,Boostrap-вю

Предпосылки

1. Начало работы с MetaMask

2. Компиляция и развертывание с использованием Remix IDE

3. Введение в смарт-контракты и надежность

Github

Если вы хотите увидеть только код, вы можете найти его здесь:
https://github.com/openberry-ac/Auction

Зачем создавать приложение для аукционов?

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

Смарт-контракты помогут вам обменивать деньги, собственность, акции или что-либо ценное прозрачным и бесконфликтным способом, избегая при этом услуг посредников, таких как система аукционов.

Создание проекта

Рабочий процесс

1. Создание смарт-контракта

2. Создание веб-приложения и настройка Web3.js

3. Определение методов: кодирование во внешнем интерфейсе

Создание смарт-контракта

Поскольку наш контракт будет основан на Ethereum, мы будем использоватьSolidity, язык программирования, используемый для создания смарт-контрактов.

ВRemixсоздайте новый файл с именемAuctionBox.solи добавьте следующий код:

// AuctionBox.sol// We will be using Solidity version 0.5.3pragma solidity 0.5.3;// Importing OpenZeppelin's SafeMath Implementationimport "https://github.com/OpenZeppelin/openzeppelin-solidity/contracts/math/SafeMath.sol";contract AuctionBox{        Auction[] public auctions;        function createAuction (        string memory _title,        uint _startPrice,        string memory _description        ) public{        // set the new instance        Auction newAuction = new Auction(msg.sender, _title, _startPrice, _description);        // push the auction address to auctions array        auctions.push(newAuction);    }        function returnAllAuctions() public view returns(Auction[] memory){        return auctions;    }}contract Auction {        using SafeMath for uint256;        address payable private owner;     string title;    uint startPrice;    string description;    enum State{Default, Running, Finalized}    State public auctionState;    uint public highestPrice;    address payable public highestBidder;    mapping(address => uint) public bids;        /** @dev constructor to creat an auction      * @param _owner who call createAuction() in AuctionBox contract      * @param _title the title of the auction      * @param _startPrice the start price of the auction      * @param _description the description of the auction      */          constructor(        address payable _owner,        string memory _title,        uint _startPrice,        string memory _description                ) public {        // initialize auction        owner = _owner;        title = _title;        startPrice = _startPrice;        description = _description;        auctionState = State.Running;    }        modifier notOwner(){        require(msg.sender != owner);        _;    }        /** @dev Function to place a bid      * @return true      */        function placeBid() public payable notOwner returns(bool) {        require(auctionState == State.Running);        require(msg.value > 0);        // update the current bid        // uint currentBid = bids[msg.sender] + msg.value;        uint currentBid = bids[msg.sender].add(msg.value);        require(currentBid > highestPrice);        // set the currentBid links with msg.sender        bids[msg.sender] = currentBid;        // update the highest price        highestPrice = currentBid;        highestBidder = msg.sender;                return true;    }        function finalizeAuction() public{        //the owner and bidders can finalize the auction.        require(msg.sender == owner || bids[msg.sender] > 0);                address payable recipiant;        uint value;                // owner can get highestPrice        if(msg.sender == owner){            recipiant = owner;            value = highestPrice;        }        // highestBidder can get no money        else if (msg.sender == highestBidder){            recipiant = highestBidder;            value = 0;        }        // Other bidders can get back the money         else {            recipiant = msg.sender;            value = bids[msg.sender];        }        // initialize the value        bids[msg.sender] = 0;        recipiant.transfer(value);        auctionState = State.Finalized;    }        /** @dev Function to return the contents od the auction      * @return the title of the auction      * @return the start price of the auction      * @return the description of the auction      * @return the state of the auction       */            function returnContents() public view returns(                string memory,        uint,        string memory,        State        ) {        return (            title,            startPrice,            description,            auctionState        );    }}

В реальных условиях многие предметы могут быть проданы с аукциона.Чтобы упростить доступ ко всем предметам, выставленным на аукцион, мы создали пакет или коробку под названием AuctionBox, в которой указаны все адреса аукционов!

Чтобы эта система работала, нам нужно подготовить два типа контрактов, которые называются контрактом аукциона и контрактом AuctionBox.

После написания в Remix разверните его втестовой сети Ropsten.

Чтобы убедиться, что наш контракт был развернут, вы должны увидеть это в Remix:Здесь нам нужно выбратьконтрактAuctionBox.

Создадим аукцион!

После развертывания попробуем провести аукцион методомcreateAuction.

В случае успеха вы можете нажатьreturnAllAuctionsи увидеть адрес контракта!

Создание веб-приложения

Теперь наш смарт-контракт работает, но просто смотреть на числа неинтересно, поэтому мы создадим простое веб-приложение.

Настройка

Чтобы ускорить процесс, предоставляется шаблонный проект, который можно найти здесь.Теперь давайте выполним следующие команды в вашем терминале (или в командной строке/Powershell для Windows):

# git clone the project templategit clone -b boilerplate --single-branch https://github.com/openberry-ac/Auction.git# go inside the foldercd Auction# install packages needed in the web applicationnpm install# install web3, this is for connecting the contract npm install -s web3@1.0.0-beta.37# To run the appnpm run dev

Затем он должен автоматически отображаться наhttp://localhost:8080/

Настройка web3.js

Откройте файл с именемweb3.jsвпапкеконтрактов, затем вставьте его как следующий код:

// web3.jsimport Web3 from 'web3';if (window.ethereum) {  window.web3 = new Web3(ethereum);  try {    // Request account access if needed    ethereum.enable();  } catch (error) {    // User denied account access...  }} else if (window.web3) { // Legacy dapp browsers...  window.web3 = new Web3(web3.currentProvider);} else { // Non-dapp browsers...  console.log('Non-Ethereum browser detected. You should consider trying MetaMask!');}console.log(web3);export default web3;

По сути, это получаетweb3экземпляр, который инициализирует расширение Metamask, поэтому мы можем использовать его и в нашем приложении.Нам нужно вызвать это позже при получении экземпляра нашего смарт-контракта.

Вы можете встретить всплывающее окно MetaMask в вашем браузере, которое запрашивает разрешение на доступ.Вам нужно просто нажать кнопку Подключиться прямо здесь:

Подключение к нашему экземпляру смарт-контракта

Теперь нам нужен ABI нашего смарт-контракта и адрес контракта, чтобы подключить его к нашему веб-приложению.Чтобы получить ABI, вернитесь вRemix, перейдите навкладкуCompileи нажмитеABIрядом с кнопкой Details, как показано на рисунке:

Чтобы получить адрес контракта, перейдите навкладку Выполнить и нажмите кнопку Копировать, как показано на рисунке:

Вы также можете получитьаукционконтактABIпутем изменения выбранного контракта на аукцион и нажав ABI.

После того, открыть файлы сименемAuctionBoxInstance.jsиAuctionInstance.jsвпапкe contracts, азатем вставьте его вкачестве переменногоABIsзначения и договора адреса, как это:

//AuctionBoxInstance.jsimport web3 from './web3';const address = ''// THE CONTRACT ADDRESSconst abi = []// THE ABIconst instance = new web3.eth.Contract(abi, address);export default instance;

// AuctionInstance.jsimport web3 from './web3';const abi = []// THE ABI// Here is just only abi because we haven't created auction yet.export default (address) => {  const instance = new web3.eth.Contract(abi, address);  return instance;};

Определение методов

Вы могли заметить, что пользовательский интерфейс есть, но кнопки не работают.Это потому, что мы еще не определили наши функции, чем мы сейчас займемся.ОткройтеApp.vueв папке srcи приступим к заполнению пробелов!

beforeMount

Здесь мы получим количество аукционов, которые вы создали ранее.

// App.vuebeforeMount() {  // get auctionBox method: returnAllAuctions()  auctionBox.methods    .returnAllAuctions()    .call()    .then((auctions) => {      console.log(auctions);      // set the amount of auctions      this.amount = auctions.length;    });},

Создать функцию аукциона

Здесь мы создаем аукцион, используя данные пользователя, которые будут показаны внизу страницы.

// App.vuecreateAuction() {  // get accounts  web3.eth.getAccounts().then((accounts) => {    // convert 'ether' to 'wei'    const startPrice = web3.utils.toWei(this.startPrice, 'ether');    // createAuction in AuctionBox contract    this.isLoad = true;    return auctionBox.methods.createAuction(this.title, startPrice, this.description)      .send({ from: accounts[0] });  }).then(() => {    // initialize forms    this.isLoad = false;    this.title = '';    this.startPrice = '';    this.description = '';    // get the previous auction    return auctionBox.methods.returnAllAuctions().call();  }).then((auctions) => {    const index = auctions.length - 1;    console.log(auctions[index]);    // get the contract address of the previous auction    this.auctionAddress = auctions[index];    // set the address as the parameter    const auctionInstance = auction(auctions[index]);    return auctionInstance.methods.returnContents().call();  })    .then((lists) => {      console.log(lists);      const auctionlists = lists;      // convert 'wei' to 'ether'      auctionlists[1] = web3.utils.fromWei(auctionlists[1], 'ether');      this.auctionCard = auctionlists;      // show up the auction at the bottom of the page      this.isShow = true;      this.amount += 1;    })    .catch((err) => {      console.log(err);    });},

Функция размещения ставки

Здесь мы обрабатываем событие, когда пользователь делает ставку.

// App.vuehandleSubmit() {  // convert 'ether' to 'wei'  const bidPriceWei = web3.utils.toWei(this.bidPrice, 'ether');  // get the wallet adddress  const fromAddress = web3.eth.accounts.givenProvider.selectedAddress;  // set the address as the parameter  const selectedAuction = auction(this.auctionAddress);  this.isBid = true;  // placeBid in Auction contract  selectedAuction.methods    .placeBid()    .send({      from: fromAddress,      value: bidPriceWei,    })    .then(() => {      this.isBid = false;      // increase the number of bidders      this.bidders += 1;      this.bidPrice = '';    });},

Завершить аукцион

Здесь мы обрабатываем событие, при котором пользователь завершает аукцион.

// App.vuehandleFinalize() {  // get accounts  web3.eth.getAccounts().then((accounts) => {    // set the address as the parameter    const selectedAuction = auction(this.auctionAddress);    this.isFin = true;    // finalizeAuction in Auction contract    selectedAuction.methods      .finalizeAuction()      .send({ from: accounts[0] })      .then(() => {        this.isFin = false;        this.finalizeStatus = 'finalized';      });  });},

Мы уже создали аукцион в Remix, адрес его контракта вы можете увидеть в консоли.

В моем случае я создал 9 аукционов, поэтому могу видеть это в консоли:

Завершено !!

Обновите браузер, чтобы увидеть изменения.На этот раз все веб-приложение готово, и все работает!После этого вы сможете использовать его так:

ПРИМЕЧАНИЕ: Тот, кто сделал действие, не может делать ставки на собственном аукционе.Итак, вам нужно переключиться на другую учетную запись (отличную от стартовой), чтобы сделать ставку.

ПРИМЕЧАНИЕ. Чтобы отобразить карточку аукциона, создайте еще один аукцион в своем браузере.

Резюме

Вы узнали, как создать смарт-контракт и как с ним взаимодействовать с помощью web3.js.Вы также узнали, как настроить свой собственный проект с помощью Vue.js, и создали простое приложение.

Ну и что дальше?

Возможно, вы захотите добавить логику для крайнего срока, потому что это важно в реальном приложении для аукционов.На данный момент мы пропустили его, чтобы избежать сложности и сократить время, но если вы хотите попробовать его собрать,это вам очень поможет:)

Если вам нужен полный код этого руководства, вы можете проверить его здесь:
https://github.com/openberry-ac/Auction

Привет хабр! Недавно заметил, что на рускоязычную аудиторию очень мало туториялов чтобы войти в мир блокчейна и разрабатывать там. Решил поделиться статьей про смарт-контракты на Ethereum. Эта статья очень помогла мне когда-то, вникнуть в мир блокчейна и разрабатывать там смарт контракты. Оригинал статьи по этой ссылке.

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

Если компания сама обманывает некоторые транзакции и получает деньги, как вы узнаете, что вас обманули?

Именно здесь децентрализованная установка является оптимальным решением.
Если нет третьей стороны, продавцы могут зарабатывать больше безопасным способом.

Список функций

1. Создание аукциона

2. Размещение ставки

3. Завершение аукциона

Инструменты

1. Смарт-контрактSolidity,Remix,Metamask

2. FrontendWeb3.js,Vue.js,Вью-кли,Boostrap-вю

Предпосылки

1. Начало работы с MetaMask

2. Компиляция и развертывание с использованием Remix IDE

3. Введение в смарт-контракты и надежность

Github

Если вы хотите увидеть только код, вы можете найти его здесь:
https://github.com/openberry-ac/Auction

Зачем создавать приложение для аукционов?

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

Смарт-контракты помогут вам обменивать деньги, собственность, акции или что-либо ценное прозрачным и бесконфликтным способом, избегая при этом услуг посредников, таких как система аукционов.

Создание проекта

Рабочий процесс

1. Создание смарт-контракта

2. Создание веб-приложения и настройка Web3.js

3. Определение методов: кодирование во внешнем интерфейсе

Создание смарт-контракта

Поскольку наш контракт будет основан на Ethereum, мы будем использоватьSolidity, язык программирования, используемый для создания смарт-контрактов.

ВRemixсоздайте новый файл с именемAuctionBox.solи добавьте следующий код:

// AuctionBox.sol// We will be using Solidity version 0.5.3pragma solidity 0.5.3;// Importing OpenZeppelin's SafeMath Implementationimport "https://github.com/OpenZeppelin/openzeppelin-solidity/contracts/math/SafeMath.sol";contract AuctionBox{        Auction[] public auctions;        function createAuction (        string memory _title,        uint _startPrice,        string memory _description        ) public{        // set the new instance        Auction newAuction = new Auction(msg.sender, _title, _startPrice, _description);        // push the auction address to auctions array        auctions.push(newAuction);    }        function returnAllAuctions() public view returns(Auction[] memory){        return auctions;    }}contract Auction {        using SafeMath for uint256;        address payable private owner;     string title;    uint startPrice;    string description;    enum State{Default, Running, Finalized}    State public auctionState;    uint public highestPrice;    address payable public highestBidder;    mapping(address => uint) public bids;        /** @dev constructor to creat an auction      * @param _owner who call createAuction() in AuctionBox contract      * @param _title the title of the auction      * @param _startPrice the start price of the auction      * @param _description the description of the auction      */          constructor(        address payable _owner,        string memory _title,        uint _startPrice,        string memory _description                ) public {        // initialize auction        owner = _owner;        title = _title;        startPrice = _startPrice;        description = _description;        auctionState = State.Running;    }        modifier notOwner(){        require(msg.sender != owner);        _;    }        /** @dev Function to place a bid      * @return true      */        function placeBid() public payable notOwner returns(bool) {        require(auctionState == State.Running);        require(msg.value > 0);        // update the current bid        // uint currentBid = bids[msg.sender] + msg.value;        uint currentBid = bids[msg.sender].add(msg.value);        require(currentBid > highestPrice);        // set the currentBid links with msg.sender        bids[msg.sender] = currentBid;        // update the highest price        highestPrice = currentBid;        highestBidder = msg.sender;                return true;    }        function finalizeAuction() public{        //the owner and bidders can finalize the auction.        require(msg.sender == owner || bids[msg.sender] > 0);                address payable recipiant;        uint value;                // owner can get highestPrice        if(msg.sender == owner){            recipiant = owner;            value = highestPrice;        }        // highestBidder can get no money        else if (msg.sender == highestBidder){            recipiant = highestBidder;            value = 0;        }        // Other bidders can get back the money         else {            recipiant = msg.sender;            value = bids[msg.sender];        }        // initialize the value        bids[msg.sender] = 0;        recipiant.transfer(value);        auctionState = State.Finalized;    }        /** @dev Function to return the contents od the auction      * @return the title of the auction      * @return the start price of the auction      * @return the description of the auction      * @return the state of the auction       */            function returnContents() public view returns(                string memory,        uint,        string memory,        State        ) {        return (            title,            startPrice,            description,            auctionState        );    }}

В реальных условиях многие предметы могут быть проданы с аукциона.Чтобы упростить доступ ко всем предметам, выставленным на аукцион, мы создали пакет или коробку под названием AuctionBox, в которой указаны все адреса аукционов!

Чтобы эта система работала, нам нужно подготовить два типа контрактов, которые называются контрактом аукциона и контрактом AuctionBox.

После написания в Remix разверните его втестовой сети Ropsten.

Чтобы убедиться, что наш контракт был развернут, вы должны увидеть это в Remix:Здесь нам нужно выбратьконтрактAuctionBox.

Создадим аукцион!

После развертывания попробуем провести аукцион методомcreateAuction.

В случае успеха вы можете нажатьreturnAllAuctionsи увидеть адрес контракта!

Создание веб-приложения

Теперь наш смарт-контракт работает, но просто смотреть на числа неинтересно, поэтому мы создадим простое веб-приложение.

Настройка

Чтобы ускорить процесс, предоставляется шаблонный проект, который можно найти здесь.Теперь давайте выполним следующие команды в вашем терминале (или в командной строке/Powershell для Windows):

# git clone the project templategit clone -b boilerplate --single-branch https://github.com/openberry-ac/Auction.git# go inside the foldercd Auction# install packages needed in the web applicationnpm install# install web3, this is for connecting the contract npm install -s web3@1.0.0-beta.37# To run the appnpm run dev

Затем он должен автоматически отображаться наhttp://localhost:8080/

Настройка web3.js

Откройте файл с именемweb3.jsвпапкеконтрактов, затем вставьте его как следующий код:

// web3.jsimport Web3 from 'web3';if (window.ethereum) {  window.web3 = new Web3(ethereum);  try {    // Request account access if needed    ethereum.enable();  } catch (error) {    // User denied account access...  }} else if (window.web3) { // Legacy dapp browsers...  window.web3 = new Web3(web3.currentProvider);} else { // Non-dapp browsers...  console.log('Non-Ethereum browser detected. You should consider trying MetaMask!');}console.log(web3);export default web3;

По сути, это получаетweb3экземпляр, который инициализирует расширение Metamask, поэтому мы можем использовать его и в нашем приложении.Нам нужно вызвать это позже при получении экземпляра нашего смарт-контракта.

Вы можете встретить всплывающее окно MetaMask в вашем браузере, которое запрашивает разрешение на доступ.Вам нужно просто нажать кнопку Подключиться прямо здесь:

Подключение к нашему экземпляру смарт-контракта

Теперь нам нужен ABI нашего смарт-контракта и адрес контракта, чтобы подключить его к нашему веб-приложению.Чтобы получить ABI, вернитесь вRemix, перейдите навкладкуCompileи нажмитеABIрядом с кнопкой Details, как показано на рисунке:

Чтобы получить адрес контракта, перейдите навкладку Выполнить и нажмите кнопку Копировать, как показано на рисунке:

Вы также можете получитьаукционконтактABIпутем изменения выбранного контракта на аукцион и нажав ABI.

После того, открыть файлы сименемAuctionBoxInstance.jsиAuctionInstance.jsвпапкe contracts, азатем вставьте его вкачестве переменногоABIsзначения и договора адреса, как это:

//AuctionBoxInstance.jsimport web3 from './web3';const address = ''// THE CONTRACT ADDRESSconst abi = []// THE ABIconst instance = new web3.eth.Contract(abi, address);export default instance;

// AuctionInstance.jsimport web3 from './web3';const abi = []// THE ABI// Here is just only abi because we haven't created auction yet.export default (address) => {  const instance = new web3.eth.Contract(abi, address);  return instance;};

Определение методов

Вы могли заметить, что пользовательский интерфейс есть, но кнопки не работают.Это потому, что мы еще не определили наши функции, чем мы сейчас займемся.ОткройтеApp.vueв папке srcи приступим к заполнению пробелов!

beforeMount

Здесь мы получим количество аукционов, которые вы создали ранее.

// App.vuebeforeMount() {  // get auctionBox method: returnAllAuctions()  auctionBox.methods    .returnAllAuctions()    .call()    .then((auctions) => {      console.log(auctions);      // set the amount of auctions      this.amount = auctions.length;    });},

Создать функцию аукциона

Здесь мы создаем аукцион, используя данные пользователя, которые будут показаны внизу страницы.

// App.vuecreateAuction() {  // get accounts  web3.eth.getAccounts().then((accounts) => {    // convert 'ether' to 'wei'    const startPrice = web3.utils.toWei(this.startPrice, 'ether');    // createAuction in AuctionBox contract    this.isLoad = true;    return auctionBox.methods.createAuction(this.title, startPrice, this.description)      .send({ from: accounts[0] });  }).then(() => {    // initialize forms    this.isLoad = false;    this.title = '';    this.startPrice = '';    this.description = '';    // get the previous auction    return auctionBox.methods.returnAllAuctions().call();  }).then((auctions) => {    const index = auctions.length - 1;    console.log(auctions[index]);    // get the contract address of the previous auction    this.auctionAddress = auctions[index];    // set the address as the parameter    const auctionInstance = auction(auctions[index]);    return auctionInstance.methods.returnContents().call();  })    .then((lists) => {      console.log(lists);      const auctionlists = lists;      // convert 'wei' to 'ether'      auctionlists[1] = web3.utils.fromWei(auctionlists[1], 'ether');      this.auctionCard = auctionlists;      // show up the auction at the bottom of the page      this.isShow = true;      this.amount += 1;    })    .catch((err) => {      console.log(err);    });},

Функция размещения ставки

Здесь мы обрабатываем событие, когда пользователь делает ставку.

// App.vuehandleSubmit() {  // convert 'ether' to 'wei'  const bidPriceWei = web3.utils.toWei(this.bidPrice, 'ether');  // get the wallet adddress  const fromAddress = web3.eth.accounts.givenProvider.selectedAddress;  // set the address as the parameter  const selectedAuction = auction(this.auctionAddress);  this.isBid = true;  // placeBid in Auction contract  selectedAuction.methods    .placeBid()    .send({      from: fromAddress,      value: bidPriceWei,    })    .then(() => {      this.isBid = false;      // increase the number of bidders      this.bidders += 1;      this.bidPrice = '';    });},

Завершить аукцион

Здесь мы обрабатываем событие, при котором пользователь завершает аукцион.

// App.vuehandleFinalize() {  // get accounts  web3.eth.getAccounts().then((accounts) => {    // set the address as the parameter    const selectedAuction = auction(this.auctionAddress);    this.isFin = true;    // finalizeAuction in Auction contract    selectedAuction.methods      .finalizeAuction()      .send({ from: accounts[0] })      .then(() => {        this.isFin = false;        this.finalizeStatus = 'finalized';      });  });},

Мы уже создали аукцион в Remix, адрес его контракта вы можете увидеть в консоли.

В моем случае я создал 9 аукционов, поэтому могу видеть это в консоли:

Завершено !!

Обновите браузер, чтобы увидеть изменения.На этот раз все веб-приложение готово, и все работает!После этого вы сможете использовать его так:

ПРИМЕЧАНИЕ: Тот, кто сделал действие, не может делать ставки на собственном аукционе.Итак, вам нужно переключиться на другую учетную запись (отличную от стартовой), чтобы сделать ставку.

ПРИМЕЧАНИЕ. Чтобы отобразить карточку аукциона, создайте еще один аукцион в своем браузере.

Резюме

Вы узнали, как создать смарт-контракт и как с ним взаимодействовать с помощью web3.js.Вы также узнали, как настроить свой собственный проект с помощью Vue.js, и создали простое приложение.

Ну и что дальше?

Возможно, вы захотите добавить логику для крайнего срока, потому что это важно в реальном приложении для аукционов.На данный момент мы пропустили его, чтобы избежать сложности и сократить время, но если вы хотите попробовать его собрать,это вам очень поможет:)

Если вам нужен полный код этого руководства, вы можете проверить его здесь:
https://github.com/openberry-ac/Auction

Одна из интересных тем, о которой мне хотелось бы сегодня рассказать - это программирование смарт-контрактов. За язык на котором мы будем программировать свой смарт возьмем Solidity, а в качестве платформы будем использовать FreeTON

В технологию blockchain сегодня не будем погружаться, ибо про него уже много статей. Поэтому рассмотрим простой смарт-контракт в следующем порядке:

1. Как он устроен;

2. С чего начать;

3. "Hello World";

4. Особенности TON смарт-контрактов;

5. Ссылки на дополнительную информацию.

Как устроен смарт-контракт

По сути смарт-контракт это обычный файл, как небольшая компьютерная программа он состоит из исполняемого кода, данных программы и мета-данных. Чтобы его запустить вовсе необязательно нужен blockchain. Для простого "Hello World" или калькулятора достаточно только компилятора и программы, запускающей функции смарт-контракта (назовем ее run executor).
У скомпилированного смарт-контракта нет единой точки входа (функции main), вызывать можно любые public функции на свой вкус, для этого в комплекте с ним при компиляции генерируется ABI (благодаря которому внешняя вызывающая программа отыскивает нужную функцию, то есть точку входа, внутри откомпилированного бинарного образа смарт-контракта).
Поэтому мы можем представить себе его как микро-сервис, либо еще проще как веб-сервис в виде, скажем PHP-скрипта.
Как можно догадаться такой скрипт сам по себе не генерирует пользовательское UI или HTML-разметку, а следовательно, ему требуется Frontend.
Поэтому у подобных blockchain-проектов есть JavaScript-фреймворки, обеспечивающие такое взаимодействие (и конечно они все используют ABI смарт-контракта с которым хотят иметь дело).
Про взаимодействие и deploy в blockchain стоит написать отдельную статью.

Теперь взглянем на смарт-контракт с точки зрения программиста. Программисты думают о них как о классах ООП. Поэтому следует рассмотреть отличия классов и смарт-контрактов.

Хранение в памяти глобальных переменных (свойств) смарт-контрактов своеобразно тем, что они хранятся в blockchain как в базе данных, доступ к их значениям обеспечивается через вызов функций. Когда речь идет про обычный класс, то такие данные необходимо записывать на носитель постоянной памяти самостоятельно.

Помимо хранения данных переменных у языков смарт-контрактов не имеется (по крайней мере на данном этапе их развития) стандартной библиотеки функций и классов, пока что мы лишь имеем дело со встроенным в виртуальную машину API.

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

Быстрый старт

Для работы нам понадобиться VSCode и плагин TONDev, установив его выполним следующее:

В области проводника VSCode кликнем правой кнопкой мыши, и в контекстном меню снизу выберем Create Solidity Contract:

Появится сгенерированный плагином файл Contract.sol:

Теперь мы его можем скомпилировать, кликнув по нему и в контекстном меню выбрав Compile Solidity Contract:

Таким образом мы можем сразу же получить готовый, но не особо полезный смарт-контракт. В рабочую директорию проекта добавится скомпилированный .tvc и .abi.json.
Подсветка ошибок связана с особенностями, о которых поговорим далее, а пока давайте напишем свой собственный HelloWorld.sol.

Hello World!

В самом простом виде наш "Hello World" будет выглядеть так:

pragma ton-solidity >= 0.35.0;pragma AbiHeader expire;contract HelloWorld {    function HelloWorld() public pure returns (string) {        tvm.accept();        return 'Hello World!';    }}

Или можно написать внутри нашей функции вот так tvm.log("Hello World!"); это инструкция для виртуальной машины TON, поэтому давайте поговорим про TON Solidity Compiller API.

Особенности TON смарт-контрактов

Выполнение функции смарт-контракта происходит так, что выполнение каждой команды байт-кода, расходует определенное количество "газа": такая система нужна для предотвращения массовых вызовов функций смарт-контрактов из других аккаунтов, направленных специально на перегрузку и отказ в обслуживании системы (в обиходе DDoS). Таким образом функций смарт-контрактов выполняются за счет вызывающего аккаунта, для этого ему необходимо передать определенное количество средств для оплаты вызова функции (зависит от тела функции), в противном случае (когда недостаточно средств) вместо выполнения функции вызывающий аккаунт получит отчет об ошибке.

Как видно из примера нашего "Hello World", первой инструкцией мы выставляем tvm.accept(); это и есть обращение к API виртуальной машины TON. Таким образом мы сообщаем смарт контракту, что необходимо выполнить данную функцию даже в том случае если аккаунт не профинансировал требуемый вызов функции, а функция будет вызвана за счет средств на балансе аккаунта смарт-контракта (как и пользовательские аккаунты, у смарт-контрактов имеется похожий счет).

Так как "газ" для смарт-контрактов служит средством защиты от спам-атак, он требует финансовых затрат, выраженных в криптовалюте blockchain-сети. Cледовательно, вызов tvm.accept(); расходующий средства со счета смарт-контракта не очень-то и выгоден с точки зрения предоставления услуг (в большинстве случаев). Чтобы сбалансировать расходы и определить есть ли необходимость выполнять смарт контракт за счет баланса аккаунта самого смарт-контракта или же возложить расходы на вызывающий аккаунт, можно воспользоваться инструкцией require().

Инструкция require() (требование) позволяет задать условия, только при выполнении которого начнется выполнение функции смарт-контракта. Например, мы можем перед вызовом tvm.accept(); добавить требование require(msg.pubkey()==tvm.pubkey()); которое не допустит вызов функции смарт-контракта, если публичный ключ отправителя смарт-контракта не соответствует ключу аккаунта самого смарт-контракта.

Пока я думаю для первой стати хватит. Давайте сделаем так. Если читателям данная тема будет интересна я буду писать тут статьи про смарт-контракты и взаимодействие с ними из JavaScript, а так же отвечать на вопросы. Буду рад любым замечаниям, поправкам и напутствиям. А пока расскажу, где можно найти информацию по данной теме самостоятельно.

Ссылки

Для получения основополагающей информации о проекте TON можно зайти на официальный сайт проекта Павла и Николая Дуровых. К сожалению из-за сложностей с регуляторами в США проект, как часть Telegram, закрыт. Проект который продолжил путь стал независимым сообществом. А тут находится документация для разработчиков. Ну и github.

О том, как минимизировать юридические риски при разработке смарт-контрактов, расскажу в этом материале.

Смарт-контракты это программы, которые автоматически инициируют процесс сделки при наступлении определенных условий. С юридической точки зрения они отличаются от стандартных договоров тем, что по условиям сделки возникающие из нее обязательства могут исполняться автоматически без отдельного волеизъявления сторон.

Как работают смарт-контракты

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

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

Плюсы смарт-контрактов

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

Данные, записанные в компьютерном коде конкретного смарт-контракта, не могут быть изменены в одностороннем порядке. Если одна сторона сделки не выполняет свои обязательства, другая будет защищена условиями интеллектуального договора. Смарт-контракты практически полностью исключают необходимость вмешательства третьих лиц. Гарантия на транзакцию сама программа, которая, в отличие от посредников, не даст основания сомневаться в ее честности.

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

Минусы смарт-контрактов

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

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

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

Сложнее, если процесс полностью автоматизирован и проходит только в виртуальном мире, а все действия контролирует алгоритм. Порой даже сами разработчики смарт-контрактов не могут повлиять на них. Такая история в 2017 году случилась с блокчейн-кошельком Parity. Из-за неосторожно введенной разработчиками команды на удаление файлов на кошельках пользователей (в основном, стартапов) оказалось заморожено более 150 млн долларов. Создателям Parity не удалось разблокировать счета клиентов даже спустя полгода напряженной работы! К слову, это далеко не первый случай, когда уязвимости в работе Parity приводили к утечкам, взломам и денежным потерям.

Как минимизировать риски

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

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

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

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

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