Как мы делали первую сделку-аккредитив на блокчейн в Альфа-Банке

Несколько месяцев назад Альфа-Банк и S7 совершили сделку-аккредитив, используя блокчейн. Если вы ещё не видели, то прошу сюда.

  

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

Так выглядит наш интерфейс:



Технически мы сделали:

  • Фронт-приложение для клиентов
  • Фронт-приложение для сотрудника банка
  • API для взаимодействия с внутрибанковскими сервисами, сохранения документов в БД и взаимодействия с Ethereum
  • Контракты для создания аккредитивов и осуществления операций над ними
  • Инфраструктурные приседания по минимуму

Всё это на js: react, redux, node. Контракты на solidity. Приложения в Docker-контейнерах, а клиент для сети Ethereum — Parity взяли отсюда. Кстати, подняли мы его на отдельной машине, так как он достаточно активно потребляет ресурсы, но как оказалось впоследствии — с этим мы добавили себе ещё кучу проблем. В целом создание приложений и возня с инфраструктурой заняли гораздо больше времени, чем работа над контрактами. Но про фронты и инфраструктуру статей достаточно, поэтому поговорим о контрактах.

Несмотря на хайп, самым частым вопросом остаётся: а зачем вам блокчейн и смарт-контракты? Многие видят потенциал в технологии, и ещё больше людей настроены скептически, нам же просто интересно. Но есть проблема — найти бизнес-кейс для того, чтобы применить блокчейн и не притягивать за уши. Поэтому мы пошли простым путём и вдохновились идеей Barclays, которые первыми в мире сделали Аккредитивы на блокчейне вместе с компанией Wave. К тому же продукт, который мы сделали нужен был и без блокчейна, а тут ещё получилось и заняться некоторым исследованием.

Как же можно применять эту технологию? Хорошо, когда вы можете использовать одну из доступных криптовалют, чтобы производить денежный оборот, но, как известно, у нас законодательно запрещена работа с криптовалютами, даже если это не будет фактически валютой, а, например, colored coins, поэтому никакого эквивалента реальным деньгам мы не переносили внутрь сети. Следующая идея — использовать блокчейн как “неизменную” базу данных (про неизменность и просто вспомнить), состояние которой валидируют и сохраняют участники сети, тогда можно создать зависимость ваших бизнес-операций от некоторого состояния внутри блокчейна и использовать его как ещё один регулятор, как бы иронично это ни звучало. Плюсом добавления в вашу систему такого “переключателя” является открытость и доступность его состояния, любой, кто может скачать и запустить клиент сети, с которой работает ваше приложение, может узнать, в каком состоянии находятся сейчас “переключатели” при условии того, что этот человек знает, как их найти с помощью необходимых идентификаторов. Соответственно, чем больше логики перейдет на блокчейн, тем более открытым будет процесс для клиентов, и тем ближе будет ваше приложение к концепции DAPP. Теперь очередь подходит к тому, чтобы выбрать, какую же сеть использовать, а их достаточно много, можно почитать анализ полугодовой давности о некоторых популярных из них. Говоря о популярных — многие слышали про биткойн, но не все знают о том, что в нём есть скриптовый язык, и некоторые концепции вполне реализуются с помощью него. Тем не менее, появляются новые криптовалюты, сосредоточенные на том чтобы решить проблемы биткоина, и одна из таких — Ethereum. Решение использовать Ethereum было принято не из-за наличия смарт-контрактов, а из-за совокупности улучшений, описанных в White-Paper.

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

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

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

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

Что же такое смарт-контракты Ethereum? Это просто программы, исполняемые EVM (Ethereum Virtual Machine). Контракты могут писаться на нескольких языках, например, на solidity. Все поддерживаемые языки тьюринг-полные, но это не значит, что вы можете всё сделать на EVM. Исполнение вашего кода должно контролироваться, т.к. его будут исполнять другие участники сети, поэтому за исполнение вы будете платить деньги — wei (деноминация ether). Чтобы код, написанный в вашем контракте, начал исполняться, вам нужно создать транзакцию. Эти транзакции передаются майнерам — тем участникам сети, которые занимаются её поддержкой. Они добавляют новые блоки с валидными транзакциями в блокчейн (объяснение намеренно упрощено, подробнее можно почитать тут и тут). Если в качестве адресата транзакции указан смарт-контракт, то майнер исполняет код функции, которая вызывается в транзакции, это стоит вычислительных ресурсов майнера, их использование вы должны оплатить.

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

Кажется, чтобы вообще что-то cделать, нужно платить, но если у вас нету друга, который вам подарил эфир на новый год, то можно настроить клиент на приватный чейн, там можно вводить читкоды на миллионы эфиров и тестировать свои творения. Вообще так лучше всегда делать.

У Parity есть возможность запуска с приватным чейном. Хотя есть способ проще — воспользоваться симулятором. Также есть фрэймворки, упрощающие написание смарт-контрактов и приложений, взаимодействующих с ними, например, truffle или embark. Особых предпочтений у меня нет, но на этом проекте я больше работал с embark. Хотя truffle позволяет компилировать контракты — создавать js-обвязку над вызывом функций контрактов, ориентирован на TDD и по дефолту создает проект метакоин (как сделать свою валюту внутри Ethereum), поэтому, чтобы начать разбираться, я бы порекомендовал его.

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

Зависимость от блокчейна мы добавили после второго и четвертого пункта в бизнес-процессе. После подтверждения аккредитива сотрудником банка в первом контракте создаётся объект аккредитива.

struct LetterOfCredit {
    bool init;
    bytes32 hash;
  }

Эти структуры надо где-то хранить, желательно в чем-то типа key-value store, в solidity есть:

mapping (bytes32 => LetterOfCredit) lcs;

Теперь по 32-байтному ключу мы можем получить доступ к объекту аккредитива или создать его. В нашем случае ключом будет md5 от трёх полей — ИНН покупателя + ИНН продавца + Название и номер договора (да, это одно поле). Насколько вы помните, md5 — 128 битная хэш функция, значит, digest — 16 байт, если представить в виде символов — используем шестнадцатеричное исчисление, соответственно, один символ кодирует 2^4 — полбайта (называется ниббл), 16 байт превращаются в 32 ниббла, в 32 символа, при передаче этих символов в виде строчки из стороннего клиента логично предположить, что кодироваться они будут одним байтом, значит, 32 байта (пуф 16 байт стали 32). Т.к. мы сохраняем работу с нашими контрактами из клиентов с web-view, то приходится мириться с тем, что они там будут вводить именно строчку, поэтому md5. С точки зрения защиты данных md5 разумеется не стоит использовать, повысить устойчивость к атакам можно добавив дополнительный слой хэширования перед md5 и использовать например SHA-3.

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



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

Дальше нам нужно реализовать закрытие аккредитива и можно всё сделать внутри этого же контракта, но т.к. в дальнейшем есть планы по развитию и на следующих этапах будет целесообразно использовать некоторое множество контрактов — мы решили делать закрытие в другом контракте, поэтому нам нужно как-то передать объект, для этого есть opcode call, например:

nextContract.call(bytes4(sha3("create(bytes32,bytes32)")), id, lcs[id].hash);

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

modifier restricted() {
    if (msg.sender == owner) _;
  }

или отдельный контракт, от которого можно наследоваться:

contract Owned {
    function Owned() { owner = msg.sender; }
    address owner;

    modifier restricted {
        if (msg.sender != owner)
            throw;
        _;
    }
}

где address owner будет инициализирован при создании контракта вашим адресом.

Теперь второй контракт можно создавать из первого контракта (используя просто new NextContract()), пометив нужные функции второго контракта модификатором restricted, потому что в таком случае msg.sender будет первый контракт, а не ваш аккаунт, который оплачивает транзакцию, его адрес будет в tx.origin (пример контрактов). Так происходит потому, что вызов одного контракта другим происходит с помощью сообщений, при этом всё выполнение оплачивается из изначального газа в транзакции.

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

Когда аккредитив попадает во второй контракт, в его структуру добавляется поле статус, и по умолчанию он будет открытый.

После того как продавец предоставит соответствующие документы, которые проверит сотрудник банка, во втором контракте будет вызвана функция закрытия аккредитива, доступ к которой ограничен другим модификатором, в данном случае это не первый контракт, а только аккаунт (адрес), у которого есть права для закрытия аккредитива. Если на вход функции закрытия переданы существующий во втором контракте id и полученный с помощью mapping аккредитив содержит поле hash, идентичное переданному на вход в функцию, то произойдет закрытие аккредитива, т.е. значение поля “статус” в структуре аккредитива поменяется.

Посмотрим на это через Parity, подсоединенному ко второму контракту:



Здесь помимо функций видны результаты их работы — под полем retVal

Все эти операции осуществляются тремя транзакциями:

  • txCreate — создание аккредитива
  • txForSend — посылка его во второй контракт для закрытия
  • txClose — закрытие аккредитива

Как это выглядит для пользователя:


(транзакции со скриншота на приватном чейне)

Посмотреть паблик транзакции можно, на специальном поисковике (etherscan). Наши контракты на etherscan: первый и второй.

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

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

Если у вас микросервисная архитектура и приложение, требующее соединения с клиентом сети, находится не на том же сервере, на котором клиент, то на запросы вашего приложения будут возвращаться ошибки. Потому что по умолчанию Parity (клиент) слушает только localhost. Мы решили эту проблему, поставив перед ним Nginx, чтобы правильно спроксировать запросы и дополнительно обойти CORS:

location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Origin http://127.0.0.1:8080;
  }

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

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

Итак, easy level использования блокчейн — вы хотите делать записи об операциях в вашем бизнес-процессе во внешнем ресурсе, чтобы потом можно было показать транзакции об этих операциях и обратиться к смарт-контрактам, которые вернут формальное подтверждение произведённым операциям (мы на easy).

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

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

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

В заключение:

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

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

Сейчас есть много гипотез и идей, как можно использовать блокчейн. Что из этого удастся реализовать в соответствии с законодательством РФ? На этот вопрос можно будет ответить только после принятия большего количества законов, регулирующих использование блокчейна.

Что ещё почитать:

Writing more robust smart contracts
Understanding oracles

Ещё про Ethereum:

Yellow paper
Ethereum trie
Альфа-Банк 93,13
Компания
Поделиться публикацией
Комментарии 38
  • +2
    Вы молодцы. Вызывает уважение, что вы вообще этим занимаетесь.
    • +1
      Про затраты времени на разработку инфраструктуры вокруг блокчейна — прям в точку. Особенно вокруг Ethereum-a, где по сути единственное нормальное подобие sdk — web3. В том же hyperledger (fabric) всё устроено попроще.
      • 0
        Спасибо за статью, круто. Мы например пытаемся реализовать локальный «блокчейн» не затрагивая глобально, повторить, но только на 10 машинах. Не подскажите что можно почитать (помимо https://blockchain.info)? Т.е. по большому счету эта та же P2P сеть только с небольшими надстройками по вычислению хеш функций как я понимаю.
        • 0
          Если я правильно понял, то что вы хотите — приватный чейн (консорциум)? Думаю, что в данном случае вам можно посмотреть на другие способы достижения консенсуса, например Proof-of-Authority
          • 0
            Спасибо, обязательно глянем. Да. Знакомы и смотрели proof of work and proof of stake. Но наша проблема, скажем, джуновская. Хотим реализовать в.нет. Но тут вылезло недостаток знаний по сети, с чем сейчас активно и боремся. Изначально пробовали через PNRP протокол просто построить P2P. Но не вышло, куча вещей нужно сделать что бы выйти глобально, попытки не оставили пробуем.Второй вариант, возможно экзотичный, через WCF, каждая машина и хост и сервис. Задумка следующая: запускаем первую программу, в настройках вводим ее некоторые параметры, она становится хостом. При запуске аналогичной программы на другой машине она должна по настройкам подключится к первой (тут в голову приходит перекинуть файл тхт, но так не пойдет). Т.е. она как- то должна определить что есть такая-то машина с сервисом. Главное что бы не было сервера. Как такое реализовать? Или без сервера посредника никак? Т.е. первая машина становится node (хост и клиент), и к ее сети должна подключится вторая, потом третья и так далее. При каждом подключении машины копируют настройки/данные одна другой (передают и получают через сервис), что бы могли работать независимо. Далее уже будем реализовывать консенсус. Или мы не в том направлении смотрим? Заранее спасибо,
            • 0
              Если вы хотите передавать настройки и автоматизировать подключение в сеть, только чтобы потом сделать приватный чейн, то может проще посмотреть вот этот туториал.
        • 0
          Так же советую почитать Monax, если собираетесь писать свои смарт-контракты. Там есть много полезной информации по ним (аля паттерны, бестпрактис и прочее)
      • 0
        Подскажите, к каким данным (проверяемым только программно и на основе которых можно строить соответствующую логику) имеет доступ ethereum virtual machine.
        • 0
          У EVM есть доступ к данным в блокчейне, который вы прописали при запуске (паблик или что-то другое).
          Если вы хотите получать доступ к внешним данным, то это нужно делать наоборот — сделайте приложение (оракул) которое получает данные из внешнего мира и делает транзакции к вашим смарт контрактам.
          • 0
            Приложение оракул связывает реальный мир с блокчейном, т.е. добавляет в него данные, на основе которых контракты будут действовать, идеологически какие еще функции они исполняют?

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

            Если нет, то в чем достоинства использования EVM перед централизованным подходом? или как пример, переноса всей логики, которая могла бы быть запрограммирована в приложение-оракул, и только данные хранить в блокчейне (например bitcoin)?
            • 0
              У них много функций например N-of-M multi-signature transactions, про оракулы есть хорошая статья.
              Да можно сделать oracle network. Чтобы противостоять злонамереным владельцам вам потребуется добавить алгоритм консенсуса в вашу сеть, берите этот.
              То сколько вычислительных операций вы будете выполнять внутри ethereum и вне его — это ваш выбор, учитывая что внутри они скорее всего будут дороже, возможно вы сделаете выбор хранить в блокчейне только данные. В качестве оправдания вычислительных операций — код контракта не меняется, и вы можете сделать его открытым и обще доступным, тогда ваши эвристические формулы вычисления, например комиссии, будут общедоступны и неизменны — это может повысить доверие к вашему продукту.
              • 0
                немного не понял про oracle network, если закрыть глаза на стоимость исполнения кода внутри EVM, почему нельзя использовать уже существующий блокчейн, а городить свой?

                Если хранить данные только в блокчейне, то зачем нам вообще нужен ethereum? если есть bitcoin?

                Я просто пытаюсь понять, что именно такого интересного в ethereum что ломанулись писать под него инструментарий, почему не развивать уже существующие блокчейны?

                p.s. если сравнивать орг.проблемы, то у ethereum идеологически все еще хуже (форк спасения DAO) чем у bitcoin, с его размером блока.
                • 0
                  Что-то первый вопрос я не понял.
                  Мы не только данные храним в блокчейне, какая-то часть логики там находится.

                  Вообще мне нравятся идеи ethash, ghost и gas, вот уже хотя бы три причины почему ethereum.

                  Да, про орг. проблемы согласен, про это есть в статье.
                  • 0
                    oracle — это third party и centralysed, т.е. все то, ради чего мы уходим в блокчейн, вся беда в том что блокчейн не видит внешнего мира и не существует адекватной технологии эту информацию туда гарантированно положить, вот и получается что нужно внешнее централизованное решение, которое превращает всю систему в зависимую от единого центра… спасибо блокчейну, информацию можно хранить с гарантией что 'она не потеряется' и ее 'не подменят после записи', но просто хранение данных может делать абсолютно любой блокчейн, соответственно выбирай кого-нибудь понадежней, побыстрее и подешевле.

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

                    т.е. ваш ответ, выбор ethereum потому что 'красивенько и перламутровые пуговицы', да?
                    • 0
                      Мне не очень понятно, почему нужно зависеть от единого центра.

                      Предлагаю вам почитать white paper и yellow paper, там хватает примеров и достаточно подробно изложены преимущества тех идей, которые я перечислил, думаю что цитирование и пересказ — дело бессмысленное.
        • 0
          Если я правильно понимаю, то
          1) при получении банком подтверждающих документов по аккредитиву должен быть совершен перевод. И (если он в другой банк) «откатить» его нельзя.
          2) при получении банком подтверждающих документов по аккредитиву должен быть закрыть контракт в etherium. И его тоже «откатить» его нельзя.
          3) это должно происходить в одной распределённой транзакции.

          Как у вас целостность поддерживается?
          • 0
            Я уже писал в статье, что все операции проводились в пределах одного банка. У нас аккредитив — это объект с определённым статусом внутри контракта, поэтому откатить можно.
            Тригерром для изменения статуса является проверка данных сотрудником банка и успешное выполнение операций внутри банка, поэтому просто последовательное выполнение операций, в случае ошибки — продолжаем с того места на котором остановились.

          • 0
            Очень толковая статья, спасибо.
            Но вот по этой части много вопросов:
            Что же такое смарт-контракты Ethereum? Это просто программы, исполняемые EVM (Ethereum Virtual Machine). Контракты могут писаться на нескольких языках, например, на solidity. Все поддерживаемые языки тьюринг-полные, но это не значит, что вы можете всё сделать на EVM. Исполнение вашего кода должно контролироваться, т.к. его будут исполнять другие участники сети, поэтому за исполнение вы будете платить деньги — wei (деноминация ether). Чтобы код, написанный в вашем контракте, начал исполняться, вам нужно создать транзакцию. Эти транзакции передаются майнерам — тем участникам сети, которые занимаются её поддержкой. Они добавляют новые блоки с валидными транзакциями в блокчейн (объяснение намеренно упрощено, подробнее можно почитать тут и тут). Если в качестве адресата транзакции указан смарт-контракт, то майнер исполняет код функции, которая вызывается в транзакции, это стоит вычислительных ресурсов майнера, их использование вы должны оплатить.

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


            — создание самого смарт-контракта — оплачивается газом, формируется блок. Откуда брать этот газ? На основании чего определяется его дефолтное значение? Про приватный чейн все понятно, но неинтересно.
            — исполнение контракта — оплачивается wei — это тоже блок (транзакция)? Эту криптовалюту тоже надо покупать?
            — как определяется цена «обслуживания» умного контракта, от чего зависит ее размер?
            • 0
              Допустим вы вызываете функцию контракта
              inContract.sendLetterOfCreditToNextContractAsync(id, { value: 0, gas: 100 })
              

              «gas 100» — означает что ваша транзакция будет стоить 100 * gasprice
              gasprice — задаёте либо вы сами, указав прямо в web3 (т.е. добавив вконце gasPrice: 999) либо используется дефолтное значение для клиента сети, которым вы пользуетесь. Обычно клиенты вычисляют дефолтное значение газа, используя для этого информацию о последних транзакциях. подробнее
              ether — 1e18 wei про деноминации
              Цена выполнения функций контракта зависит от количества вычислительных операций и количества данных которые вы хотите сохранить в блокчейн.
              • 0
                Спасибо, стало понятнее, но все же вопрос остался: кто при совершении аккредитива платил майнерам Etherium: банк, клиент или вы как сервис провайдер?
                • 0
                  Это деликатная тема, третий вариант с сервис провайдером, мне нравится больше.
                  Во всяком случае клиенты не платили майнерам.
            • –1

              ?!?!??!?!?!!!?


              Чтоа? Что вы, собственно, сделали? Прежде чем писать маркетинговый буллшит и показывать веб-интерфейсы, расскажите, в чём суть произошедшего?


              В общем, пролистал пару первых абзацев вашей статьи и отвечаю.


              Прежде чем начать свой коммент, хочу сказать пару слов о терминологии. Ethereum — это децентрализованная сеть. Это вполне конкретная децентрализованная сеть (конкретный instance) с некой вполне конкретной цепочкой блоков. Когда мы говорим "Ethereum", мы имеем в виду именно её, эту сеть. Если речь идёт об альтернативной сети, построенной с помощью того же кода и той же технологии, это оговаривается отдельно. Ether — это децентрализованная валюта, лежащая в основе сети Ethereum. По словам разработчиков, "Ether — это топливо для контрактов Ethereum". Опять-таки, Ether — это конкретная валюта с конретным курсом по отношению к доллару. Сейчас Ether равен 19.7 долларов. Если речь идёт об альтернативной валюте на основе той же технологии, то это нужно оговаривать отдельно.


              Итак, вы воспользовались одной из существующих криптовалют, одной из запущенных децентрализованных сетей? Одним конкретным запущенным instance'м децентрализованной сети, такой как например, главный instance (main net) сети ethereum, той главной сети, к которой по дефолту подключается скачанный с оф. сайта клиент ethereum? Или вы просто воспользовались технологией блокчейн, т. е. создали свой блокчейн на основе существующего кода? Скажем, взяли код ethereum на его основе запустили свой instance ethereum-сети, получили свою основанную на ethereum сеть?


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


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


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


              Далее, как вы легально оформили сами эти контракты на Ethereum? Где вы взяли документы, подтверждающие, что эти контакты на Ethereum заключены? Которые, в случае чего, будете показывать налоговой и пр.? Вы продублировали каждый контракт Ethereum реальным контрактом?


              Как вы подстраховались от резкого изменения курса? Вот купили вы кучу этеров, заключили контакты, всё у вас ок. Теперь пришла пора продать этеры. А цена резко изменилась. И вы в убытке. Вы подстраховались от такого? Как?


              Ответьте, пожалуйста, на все эти вопросы.


              Итак, мне совершенно не нравится ваша статья. С чего нужно начать статью? Можно начать с короткого абзаца для привлечения внимания, который в двух словах рассказывает, что и как. Он может быть непонятным, главное, чтобы он привлёк внимание. И его можно опустить. А вот дальше нужно по порядку рассказать всё как есть. Рассказать, действительно ли вы воспользовались главным instance'ом Ethereum, где вы взяли этеры, кому они перешли в распоряжение после покупки, как вы юридически всё это оформляете и так далее и тому подобное. А потом уже рассказывать про этот ваш веб интерфейс. И про особенности настройки Ethereum. И конкретный код на solidity. Иначе ничего не понятно вообще.


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

              • 0
                В общем, пролистал пару первых абзацев вашей статьи и отвечаю.

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

                Друг подарил, хотя уже есть даже физические обменники.
              • –1

                А, ну да, ещё вопросы. Как наличие контактов Ethereum гарантирует реальное совершение услуги? Что такое вообще этот ваш аккредетатив? Блин, если бы вы захотели, вы бы могли в одном абзаце всё уместить! В чём суть аккредетатива, т. е. что именно за договор нужно было переместить на блокчейн, и как конкретно вы его на блокчейне разместили.


                Далее, действительно ли вам понадобилось количество этеров, равное по своей ценности сумме сделки? Или нет, вы просто воспользовались неким символическим маленьким количеством этеров, к сумме сделке не имеющем отношения? Если маленьким, то какой тогда вообще смысл в этом Ethereum контракте? Что он вообще будет гарантировать? Это поиграться что ли? У вас Ethereum тогда просто для учёта сделок, но для их гарантии что ли?


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


                И блин, всё это нужно было запихнуть в начало статьи. Сразу всё написать: мы воспользовались реальным instance'ом Ethreum (или не воспользовались), закупили Ether'ов на всю сумму, на все миллионы рублей (или не закупили), юридически оформили так-то (или не оформили) и т. д.

                • 0
                  сразу после вводного абзаца —
                  Хорошо, когда вы можете использовать одну из доступных криптовалют, чтобы производить денежный оборот, но, как известно, у нас законодательно запрещена работа с криптовалютами, даже если это не будет фактически валютой, а, например, colored coins, поэтому никакого эквивалента реальным деньгам мы не переносили внутрь сети.

                  Если вы знакомы с ethereum проектами, то наверное уже должны были догадаться, что мы сделали. Кстати есть мнение, что другие ребята которые делали аккредитивы на блокчейне делали также, во всяком случае те с кем я говорил.
                • +1

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

                  • 0
                    Рад что вы всё сами поняли, кажется это было описано тут
                    поэтому никакого эквивалента реальным деньгам мы не переносили внутрь сети.

                    Как вы понимаете, сейчас в смарт-контрактах реализовано просто сохранение хэшей от некоторых полей аккредитива, его статус и проверка информации при закрытии. Да, у нас было больше идей того, что можно перенести на сторону блокчейна, и, возможно, в дальнейшем их получится реализовать. В данном проекте мы большую часть времени потратили на создание приложений: фронт-энд и апи. Хотя есть мнение, что так происходит во многих проектах, связанных с блокчейном.
                  • 0
                    > И всё таки зачем вам может понадобиться блокчейн? В идеале если вам нужно создать систему обмена информацией между участниками, независимую от уровня доверия между ними, то это то что вам нужно.

                    А зачем это нужно вам? Вы же банк, по идее как раз торгуете своим авторитетом в сделках. Любые децентрализованные сделки конкурируют с вашим основным бизнесом. Какая польза от блокчейна может быть для банка?
                    • 0
                      Согласен пытаться увеличивать доверие к банку странное занятие, но в сделках же участвует не только банк. Поэтому ключевым преимуществом является возможность авторизации внутри сети всех участников сделки и то что все операции подписаны. Разумеется цифровая подпись в ethereum не по ГОСТу, поэтому требуется заключение дополнительных юридических соглашений и использование ГОСТовой цифровой подписи на копии документов. Но возможно в будущем будет реализация блокчейна по ГОСТу, тогда про многие из текущих усложнений можно будет забыть.
                      • 0
                        Я имел в виду, что банк может использовать свой авторитет для обеспечения сделки. Ну как сейчас сделано: покупатели не боятся платить через банк, потому что если продавец их обманет, они смогут оспорить сделку и получить возврат от банка. И за эту услугу банк берёт свою долю.

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

                          Я имел ввиду отличную от ethereum реализацию концепции блокчейна/платформы для смартконтрактов, использующую гостовые алгоритмы, в целях обеспечения необходимой юридической доказательной базы.
                          • 0
                            Смарт контракты — хорошо, когда софт заменяет человеческий фактор.

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

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

                            В результате появится авторитетный орган «совет банков», который устанавливает правила технологической игры, и которому все должны доверять. И снова мы приходим к исходным условиям задачи — есть единственный актор. А если мы не можем его установить, то и договориться не сможем.
                            • 0
                              Ну да если и делать что-то такое, то нужно использовать не PoW, благо альтернативных алгоритмов достижения консенсуса, не нуждающихся в вычислительных мощностях, достаточно.
                              Не очень понятно почему должен создаваться совет банков, вырожденный в одного актора, вы почему-то хотите всё централизовать :)
                    • 0
                      Если бы делали сейчас, то на основе Ethereum или Hyperledger?
                      • 0
                        В этом проекте мы хотели использовать публичный чейн, поэтому Ethereum.
                        Но если говорить про проекты только на приватном чейне, то, наверное, Fabric. Хотя в последних версиях Parity приватный чейн Ethereum получил хороший апгрейд.
                      • 0
                        Могли бы и нормально в статье код контрактов привести а не давать ссылку на байт-код в блокчейне. Для разработчиков — пользы от статьи почти никакой

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое