Юрий Корженевский — о том, как построить безопасные системы для банков на блокчейне

Понятные сервисы и паранойя о безопасности

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

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

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

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

Распределенная система работает на то, чтобы данные сошлись. Когда мы меняем корпоративную базу, как правило, — Oracle, на систему с распределенными реестрами, мы меняем подход к архитектуре. У нас добавляется eventual consistency (согласованность в конечном итоге — «Хайтек»). Важно правильно соединить классический и новый подход к фиксации данных. Чтобы не получилось так: перевел деньги от А к Б, а после синхронизации систем окажется, что у А эти деньги списались, а к Б они еще идут.

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

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

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

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

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

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

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

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

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

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

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

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

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

Redis — сетевое журналируемое хранилище данных типа «ключ — значение» с открытым исходным кодом.

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

Jepsen — фреймворк для тестирования баз данных, написанный Кайлом Кингсбери с никнеймом Aphyr. Jepsen запускает любую базу данных на пяти виртуальных машинах и начинает слать случайные запросы на каждую машину. В процессе отправки запросов на фиксацию и чтение данных, запускается сценарий — и Jepsen начинает случайно уничтожать эти машины. Гонять системное время. Замораживать процесс и размораживать его. Убивать эту машину, поднимать ее. «Полный дестрой», как в реальном мире. Кайл с помощью Jepsen разломал большинство баз данных и собрал большое количество багрепортов по ним.

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

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

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

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

Мастерчейн — система для проведения анкоринга: когда данные выгружаются из системы и фиксируются в неподконтрольном месте. Сегодня Центробанк с участниками рынка развивает легальную блокчейн-платформу общего назначения. Данные при нем уходят не в биткоин, а в Мастерчейн ЦБ. Именно Мастерчейн, скорее всего, будет иметь правовой статус платформы в России.

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

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

Подпишитесь на наши новости
Лого www.SiteHere.ru
1970-01-01 03:00 http://news.xtipe.com/ru/news/25211

Смотрите так же

Russian Robot Olympiad: как дети строят роботов и решают реальные инженерные проблемы 1970-01-01 03:00

Что общего между конструктором LEGO, школьниками и научной фантастикой? Как оказалось, — образовательная робототехника. В России уже 15 лет подряд проводится робототехническая олимпиада. Школьники решают глобальные задачи, связанные с проблемами голода, выходят за рамки образовательных программ и сталкиваются с реальными инженерными трудностями. «Хайтек» поговорил с Алексеем Хабибуллиным, руководителем отдела проектных олимпиад в Университете Иннополис, о том, как проводится Всероссийская робототехническая олимпиада, нужен ли образовательный стандарт по робототехнике и почему школьников важно мотивировать на инженерные специальности в младших классах.

Бездомный программист раздавал резюме на улице. Ему предложили работу в Google, Netflix и еще в 200 компаниях 1970-01-01 03:00

Разработчик Дэвид Касарез после провала собственного стартапа сначала жил в фургоне, а затем в парке. После трех лет поисков мужчина решил раздавать резюме на улице — и уже через несколько дней получил более 200 откликов от технологических компаний, среди которых были Google, Netflix, LinkedIn, Pandora и другие. Об этом пишет New York Post.

Анализ нового вида сингулярности показал, что наша Вселенная может разорваться в любую секунду 1970-01-01 03:00

Физики из БФУ имени И. Канта построили математическую модель темной энергии, в которой будущее Вселенной оказалось намного менее предсказуемым, чем ученые считали ранее. Об этом пишет РИА «Новости».

Россия к 2027 году создаст ракетный экраноплан 1970-01-01 03:00

В России создадут опытный образец ракетного экраноплана «Орлан», который, в частности, будет использоваться для спасению экипажа потерпевших крушение кораблей. Соответствующие положения содержатся в государственной программе вооружений на 2018–2027 годы, пишет ТАСС.

Появилась нейронная сеть, которая имитирует устройство мозга 1970-01-01 03:00

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