Как использовать блокчейн в реальном мире

Рассказали на DevFest Siberia 2017 как использовать блокчейн в реальном мире.

Вот пожалуйста: видео ниже, транскрибация еще ниже.

До исследований и разработок я работал в «Яндексе» в службе безопасности, занимался разработкой софта. В службе безопасности «Яндекса» я занимался всякими разными проектами, которые связаны с безопасностью. Всякие проекты Х, так называемые. Много интересной работы.

Где-то 3 года назад я вообще ничего не знал, даже, как-то особо и не сталкивался с блокчейном, но мир три года назад поменялся. Мы с партнерами были одними из первых, кто на банковской конференции в Казани, на FINOPOLIS, Центробанку и банкирам предложили использовать блокчейн. Это предложение вызвало некий скепсис, тогда еще следственный комитет и прочие быстро создали законы о том, что надо наказывать всех, кто криптой занимается, и поэтому отношение к нам было очень неоднозначное.

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

Я сегодня больше расскажу технологическую часть, сильно не будем уходить в какие-то супер-детали, потому что я детали обычно рассказываю на golang-митапах, потому что большинство софта у нас пишется на Go. Кто пишет на Go? Есть? Вот, 3 человека. Это нормально. Обычно меньше. Это не маргинальный язык.

Зачем блокчейн бизнесу

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

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

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

Когда приходишь в бизнес, в банк, например, у него стоят совсем другие задачи. Задачи стоят вот какие: в банке, например, или в платежной системе, просто в бизнесе. Я сам предприниматель, не стартапер, и это то же самое, с чем я сталкиваюсь в каких-то своих продуктах, не только в сфере услуг R&D. Например, у нас есть процессинг. И есть система, которая отслеживает мошеннические действия. И так получается, что они как-то должны быть связаны, но их разрабатывают разные команды, может быть, это даже разные продуктовые команды в разных странах. И им требуется обмениваться данными и, одновременно с обменом данными, встает вопрос, чтобы между тем, как они обмениваются, ничего не потерялось.

Про информационную безопасность, гибкость бизнеса и скорость

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

Когда мы меняем, например, какую-то корпоративную базу, как правило — это Oracle, на что-то такое, связанное с распределенными реестрами, мы в несколько точек это фиксируем, у нас добавляется так называемое eventual consistency. Кто знает, что это такое? А как это по-русски перевести? Кто-то называет это «согласованность в конечном итоге». Перевел деньги, перевел от А к Б деньги, в итоге у тебя у А через некоторое время, когда две системы синхронизируются, окажется, что у А эти деньги списались, сразу можем это показать, а у Б они дойдут пока по проводам байты, биты доедут в другой дата-центр какой-нибудь. Это не сразу происходит. Не суть, это технологическая штука. Абсолютно не полезно в рамках нашего сегодняшнего диалога. Но это важно. То есть, когда это разрабатываешь. Соответственно, куча повторений. Эта система, ее нельзя сделать строго консистентной, чтобы еще была некая распределенность, ибо CAP теорема. Можно же так сказать? Можно.

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

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

Соответственно, скорость фиксации... какая там последняя скорость фиксации? Может кто знает, у кого свежак данные? У биткоина какая скорость фиксации транзакций? 15 в секунду? В минуту? Не очень много можно прогнать. Когда, например, два банка будут миллиарды гонять, они вряд ли это доверят такой системе. Потому что 15 минут. За 15 минут может много что произойти. Тем более у нас. Соответственно, встает вопрос: что делать? Открытые решения, вроде подходят, но не совсем. Что-то свое писать — возвращаемся обычно к обычной архитектуре. Что там у нас: база данных, таблица с аккаунтами и SQL-запрос — перевести с одного на другой.

Зачем блокчейн, если уже есть классические базы данных

Это уже существующие решения, они у всех банков, как правило, есть. И они вешаются от того что есть один какой-то Oracle, который реально тяжело и дорого. Что все на блокчейн то накинулись? Курс валюты подскочил и обслуживать вендерные решения стало реально дорого. Был миллион долларов в год, стало два. Весомо. Встает вопрос: что нам делать, где хранить? Поэтому нам нужно какое-то хранилище. В MySQL хранили, где-то там еще. Но единая база- это медленное восстановление. Есть большая проблема, когда у нас все в одной точке, даже если это реплицированная база данных, все равно происходит прикол с чет что реплика упала, мастер упал, тебе все равно нужно его восстанавливать, например, 200ГБ данных перекачать, даже если это на гигабите происходит.

Про скорость восстановления после аварии

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

Как повысить себе зарплату

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

Про архитектуру процессинга и большие данные

Значит, наш паттерн таков: вместо демократии, как в биткоине, мы работаем в доверенном окружении.
Мы заведомо друг другу доверяем. Нужно выбросить большое количество фишек, связанных с тем, что мы не знаем друг друга и не доверяем друг другу. Транзакции в нашем случае проходят через сервисы, которые называются гейтами. У каждого гейта есть свой блок, можно его назвать чейном, как раз все эти транзакции следуют друг за другом. И для каждого счета — своя цепочка. То есть у нас нет единой цепочки. Гейты договариваются друг с другом.

Самоорганизация: Как узлы процессинга делят ответственность

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

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

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

Про дорогую и дешевую надежную инфраструктуру

В инфраструктуру тоже надо вкладываться. И порой бывает реально проще несколько оптических кабелей кинуть, чем писать систему, которая переживает, там, катастрофоустойчивую систему, это реально дорого. И программисты скорее всего запутаются через некоторое время и не поймут, она реально катастрофоустойчивая, или нет, или они заблуждались. Это по опыту наблюдения за разными командами. Все, соответственно, чейн на каждом гейте ограничен, то есть мы не храним копию чейна как у биткоина, как у смежных систем. Нам не надо скачивать всю эту историю, мы ее подкачиваем из базы, из хранилища по мере того, как мы с ней работаем. То есть, вплоть до того, как вы делаете перевод, вам говорят: «Нет, погоди, у меня нет данных». И он так в фоне подкачал, повторил, и такой: «О, все нормально, зафиксировал». Поэтому я и говорил на первом слайде про eventual consistency, что много повторов, много retries, это особенности таких систем. Не надо думать, что это плохо. Это нормально.

Зачем писать свою специализированную базу данных

О надежном хранилище. Я, когда писал заголовок этого слайда «надежное хранилище», громко звучит «надежное хранилище», то есть это, по сути, что такое? Это то, где хранится вся оставшаяся цепочка такой платформы. Такой подход можно использовать где угодно. И на каком угодно языке реализовать, и на каком угодно стеке технологий. Это важно. Почему мы ни мемкеш, ни редис не используем, потому что у нас ограниченная схема данных, у нас только транзакция и настройка счета. То есть две сущности есть. Нам не нужно какую-то невероятную гибкость иметь. Мы можем специализированный движок написать. И важно не терять транзакции в нашем случае. То есть у нас получается гибридный подход: с одной стороны, это распределенный реестр, с другой стороны — это надежное хранилище с транзакциями. Потеряли, развалили блокчейн и все. Не все, но для конкретного счета это может быть грустно.

Как оно вообще работает? Эти гейты, они в итоге отпроцессили у себя транзакцию, посчитали что баланс сходится, и роутят полученные данные, дублируют их, у себя пишут и пишут в базу. А записать в базу — это что? У нас есть некоторый контроллер, это просто сервис, на него попадает: от А перевели к Б и у Б появились деньги. Транзакция для А исходящая и транзакция для Б входящая. Дальше мы все это упаковываем в транзакционную модель на шардах. Соответственно, у базы на низком уровне данные пошардированы, поделены, но поделены уже по какой-то своей логике, которая не касается гейтов. ТО есть это просто хранилище, оно отдельно где-то находится. Гейты видят только один адрес по сути за балансом.

Дальше, шарды. У каждого шарда есть свои реплики. Например, в нескольких дата-центрах. Соответственно, нам вообще фиолетово. У нас отключится дата-центр — ничего у нас не произойдет. Подключится он обратно. Реплики восстановят из своих двух копий. Как правило, у нас все данные на каждом шарде в трех копиях хранятся. Вот так вот обеспечивается достаточно надежное сохранение транзакций. Я очень критически отношусь к слову «надежно», потому что очень много баз данных, в том числе коммерческих, из нового этого ньюейдж, когда они все пишут: «мы классные, мы замечательные, мы переживаем отключение дата-центров, можете все что угодно делать и мы восстановимся из любого состояния». Мне то на слово не поверят банкиры если я им это скажу. Поэтому есть такой, на слайде этого нет, но я вам расскажу.

Почему процессинг реально надежный, а остальные нет

Есть такой тест для баз данных, называется Jepsen. Кто-нибудь слышал про этот тест, Jepsen? О. А чего-нибудь писали под Jepsen? Вот. Jepsen — это некий фреймворк для тестирования баз данных, написанный неким увлеченным парнем, Кайл. Кайл же его зовут, да? Как-то так. У него никнейм aphyr. И что делает эта штука? Она запускает любую базу данных на пяти виртуальных машинах. Начинает слать случайные запросы на каждую машину. И в процессе отправки запросов, например, зафиксировать какие-то данные, прочитать, то есть какой-то сценарий, она начинает производить дестрой с этими машинами. Гонять время системное туда-обратно. Замораживать процесс, размораживать его. Убивать эту машинку, поднимать ее. То есть полный дестрой, как в реальном мире.

Мне часто говорят: «Вот в NetFlix есть такая программа ChaosMonkey, обезьянка хаоса, они тоже что-то подобное тестируют». И Кайл с помощью Jepsen практически разломал большинство баз данных. То есть, вы можете погуглить, от него блог есть на эту тему, у него большое количество багрепортов есть, на разные базы данных. Кто монгу использует? Ну вот. Монгу, какие-то версии ломали, она теряла данные в такой ситуации, то есть, если в финансах попасть нехило. Что еще ломали?

В кассандре были какие-то приколы. То есть он много чего ломал. Мы, когда свое хранилище писали, мы сразу себе задрали планку очень высоко: наша задача была проходить тест «джепсен». И недавно он начал проходиться. То есть наша база полностью проходит на всех трех уровнях, на уровне шарда с репликами, мы смотрим, дестрой с репликами производим, потом level-up делаем, потом фиксируем на шардах, то есть дестрой производим не на реплики, а на уровне шарда, и на самом верхнем уровне, дестрой уже на уровне всего кластера производим. Чтобы можно было понять, где происходит что-то не так. Это реально биг челлендж. Огромный респект моему коллеге Никифору, который и реализовал эти тесты на джепсене. То есть он этим занимался. Это жесть. Такого у нас не делают. Пока. И еще одна важная фишка, если вы когда-нибудь начнете писать свою базу данных, это очевидно, что параллельный доступ — это очень большая проблема.

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

А если это неправильно понять, например, опираться на часы неправильные, то можно попасть. И джепсену спасибо. Он тоже это выпаливает. Это все проблемы, с которыми сталкиваются любые реально распределенные системы. У нас шарды маленькие, опять же, возвращаясь к моменту, что, чтобы данные не перекачивать долго. То есть в некоторых на сетапах размер шарда у нас может быть где-то полгигабайта. Это оптимально высчитанное время, чтобы, если произошел какой-то факап, поднялся сервис, он успел по сети перекачать, и мы не вышли за предел 8 секунд допустимого простоя. Вот откуда это идет. Опять же, размер данных, он очень влияет. То есть это число не с потолка берется, 3, 10, 100. Можно обратить на это внимание.

Про сайдчейн, мастерчейн и легальный путь блокчейна от ЦБ

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

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

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

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

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

Вопросы: про сбитое время на разных узлах

Слышно? О, хорошо.
— Спасибо за доклад, мне понравилось.
— Здорово.
— Как вы решили проблему с тем что приходят транзакции со сбитым временем, как вы это решали?
— Есть такой пейпер у гугла про TrueTime. Читали его? Нет? Расскажешь про время? Давай.
— Никифор: Если две транзакции приходят в один аккаунт, об этом речь, да? Есть несколько подходов. Во-первых, можно логическими часами обмениваться, если они получаются неупорядоченными, то мы синхронизируем часы и пробуем заново. То есть, какое-то событие произошло здесь, счетчик, часы увеличили, послали на эту, здесь началось событие заново, то есть заново пробуем, это событие произошло здесь счетчик увеличили, на третью все это пришло, счетчики сравнились, они разные, сравнимые, события упорядочились. Другой подход — стараемся часы синхронизировать как можно точнее между собой. Там у Гугла есть атомные часы, чтобы все совсем точно. И гарантированно часы у нас расходятся на какую-то милливеличину. Наша система гарантирует это, и мы знаем это, можем на это положиться. Когда с двух точек пришли разные запросы с разными временами в какую-то третью точку. В третьей точке мы смотрим на временные метки и этот интервал времени ждем просто. То есть, если этот интервал времени мы подождали, ничего к нам больше не пришло, то ничего больше не могло начаться более, чем этот интервал назад. Соответственно, никакое новое событие к нам не придет из прошлого, или будущего. Понятно?
— В принципе, да.
— То есть сравниваем не таймстемпы, а сравниваем интервалы, то есть я почему про пейпер сказал, там основная идея, если его не читать, эту огромную портянку, что мы сравниваем интервалы. А интервалы у нас, допустимый интервал расхождения ошибки, он задан, например, точностью атомных часов, мы примерно знаем плюс минус 20 миллисекунд.
— То есть событие произошло не раньше, чем столько-то и не позже, чем столько-то. И это также. И если мы можем их сравнить так, что верхние и нижние границы не пересекаются, то события можно упорядочить. В основном идет борьба за то, чтобы уменьшить, чтобы меньше было расхождений.

Вопросы: когда закончится бесконечная база и почему мы хорошо работаем на дешевом железе

— О блокчейне, я, конечно, не так много знаю, но такой вот вопрос: если в базу бесконечно писать, то что? Объем же бесконечно будет увеличиваться, получается. Как будем через 20 лет, там миллиарды транзакций в год, будет увеличиваться память, придется где-то все это хранить.
— Ну да. Поэтому в этой системе активно используется шардирование, шардирование на небольшие кусочки. Если какой-то шард пухнет, он просто делится на 2 других. Как клетка делится. С одной две появилось. Так же с шардами. Вот и все. Просто больше шардов будет, не один дата-центр, а 10. Ничего страшного.
— Это будет дороже?
— Нет, все эти данные, они лежат в компактном виде и их можно хранить на дешевом железе на «так себе» винтах. То есть можно прям дешевые железки скупать толпами и ставить под это хранилище. Одна из главных коммерческих фишек такого подхода, такой базы. Потому что дорогое железо — это дорогое железо. Вот и все. Потому что нам, по сути, без разницы, умрет машинка, новую поставим. Новая засетапится, подольет за какое-то время на себя эти же данные. Процессим дальше. А все остальные узлы, гейты, контроллеры базы, шарды и прочее — они все могут умирать. По сути. Вот и все.
— Спасибо.

Вопросы: про релиз процессинга обществу

— Что еще? Любые вопросы.
— Спасибо за доклад, было очень интересно. Я правильно понял, что вы делаете хранилище с транзакциями для своего большого заказчика и при этом это хранилище нигде не доступно на платной или бесплатной основе. Вы даже название его не сказали.
— Да. Все так.
— А будет когда-нибудь? На коммерческой основе. Звучит просто очень хорошо.
— Пейпер будет.
— Хорошо. А дальше сами уже будем допиливать что-то подобное.
— Ну да. Мы постараемся в пейпере спалить побольше.

Вопросы: причем тут антифрод и блокчейн

— Здравствуйте, спасибо за доклад. У меня есть 2 вопроса. Поскольку вы в своем хранилище храните хеши своих данных, да? На сколько объем данных отличается от использования каких-то стандартных хранилищ, типа реляционных баз данных, по транзакциям. Второй вопрос: вы упомянули, что эту технологию можно использовать в антифроде, но я не совсем понял. Антифрод, насколько я знаю, подразумевает выявление аномалий в транзакциях, вы эту тему как-то не раскрыли. Поясните пожалуйста, спасибо.
— Начнем с антифрода. Антифрод-система в общем смысле — это такой ответственный кусочек, в котором действительно анализируются какие-то аномалии данных. Чтобы нам их правильно анализировать, нам нужно первое: убедиться, что у нас вход чистый, что админ или программист процессинга не поставил «ифы» на нужные места и своим друзьям не сливает бабки. Например, или еще на каком-то пути происходит модификация. Очень много можно придумать, как вмешаться посередине. Тут получается, антифрод-система с чистым входом поработала, но еще нужно обеспечить выполнение ее вердиктов, то есть мы должны где-то хранить этот лог того, что она делает. Чтобы не было такого, что антифрод заблокировал счет, потом там произошли какие-то шуры-муры, потом в базе потерли эти вердикты, вроде ничего не блокировалось и вроде все хорошо. В большой компании, где больше 20 продуктов и много продуктовых команд, сидеть сверху и наблюдать за всем сложно, а иначе будут деньги куда-то утекать. Поэтому хранение в неизменяемом хранилище бонусом. Это просто бонус. Не все данные там хранятся, не все существующие команды хотят использовать эту платформу. Логично. Они такие: «Мы складываем в Oracle, зачем нам ваш процессинг». Но это свойство, оно очень ценно для них. Там еще был вопрос, я, мне, когда по 2 вопроса задают, у меня переполнение возникает. О чем там было?
— Насчет сравнения вашего хранилища с более традиционными хранилищами типа Oracle. То есть если производить транзакции через базу данных Oracle и через вашу базу данных. На сколько будет различаться объем данных.
— Опять же, прежде чем садиться писать базу, были проведены тесты под этот тип данных. Там самая главная проблема даже не в размере данных, а в том, что есть один мастер и на него очень большая нагрузка идет, потому что он один держит баланс. А разделить этот мастер на 200 или 300 мини-мастеров нельзя. Уже не получается. Так не работает. Есть гибридные подходы вроде Google Vitess, на базе MySQL с шардированием, интересный подход, тоже его изучали. Кто-то кассандру под это дело вкручивает. Очень экзотическое решение, по моему мнению. Мы ее тоже тестировали. В итоге, архитектура с легким сервисом, написанным на быстром, с помощью быстрых алгоритмов на компилируемом языке с бинарным протоколом, он обеспечивает все, что нам хотелось от этого хранилища. По поводу того, много ли данных это занимает, мы данные храним на самом нижнем уровне, в протобафе оптимизированном. То есть в протобафе тоже есть несколько вариаций. Мы храним в версии, под размер оптимизированной. Сколько там времени? Еще вопросы? Я ответил?

Вопросы: о размахе разработки

— Спасибо за доклад. У меня вопрос: много у вас людей разработкой занимается?
— Нет.
— Примерно? Окей.
— Не здание точно. Небольшая команда. Еще?

Вопросы: о работе узлов процессинга, кто за что отвечает

— Спасибо за доклад. Я так понимаю на один счет — один гейт в единицу времени?
— По-разному.
— То есть, на один счет можно сделать несколько гейтов?
— Да, абсолютно. И они независимы друг от друга. Они даже друг про друга не знают.
— Например, узнать баланс клиента, это кто отвечает, гейт или сторонняя сущность?
— Идем на гейт, спрашиваем баланс. Если у него есть чейн его, по сути ему нужна последняя транзакция по этому счету, потому что в каждой транзакции пишется баланс. Мы произвели действие — баланс такой-то. Если у него есть эта транзакция — он ее отдаст. Если нет, он скажет: «Сорян, у меня ее нет», сходит в базу, повторим запрос, вернем баланс.
— А если несколько гейтов, как они между собой синхронизируются? Через мастер или между собой?
— Нет, они в один момент процессят конкретный рейндж счетов, все. То есть они не пересекаются.
— Спасибо.

2018  
Популярное