воскресенье, 21 мая 2017 г.

Блокчейн

                   
  • https://yadi.sk/i/z2NdeQo23KdVti
  • Обзор децентрализованных крипто-платформ. Часть1: Waves https://habrahabr.ru/company/web_payment_ru/blog/310082/ 
  • Обзор децентрализованных технологий. Часть 1 https://habrahabr.ru/post/237765/ 
  •  Часть 1. Где хранить данные децентрализованным приложениям на блокчейне? 
  • https://habrahabr.ru/post/327836/ 
  • Часть 2. Где хранить данные децентрализованным приложениям на блокчейне? 
  •  https://habrahabr.ru/post/327947/
  •  Часть 3. Где хранить данные децентрализованным приложениям на блокчейне?
  • https://habrahabr.ru/post/328004/ 
  • https://habrahabr.ru/company/neobit/blog/324456/
  • Криптовалюта Ethereum: пишем эксплойт под уязвимый умный контракт и получаем токены'
  • https://habrahabr.ru/post/328246/
  • Смарт контракты Ethereum: структурируем токены как акции
  • https://habrahabr.ru/company/acronis/blog/331326/
  • Как с помощью блокчейна защитить свои данные
  • https://habrahabr.ru/company/acronis/blog/327908/
  • Acronis Backup 12.5 (теперь и) Advanced: долгожданный выпуск
  • https://habrahabr.ru/company/web_payment_ru/blog/313294/
  • Обзор децентрализованных крипто-платформ. Часть 2: Lisk
  • Блокчейн (blockchain — цепочка блоков) — это неизменяемая структура данных, состоящая из списка блоков, где каждый следующий блок содержит хэш предыдущего блока. В результате такого хэширования цепочка блоков становится неизменяемой: нельзя изменить или удалить блок из середины цепи, не перестроив все блоки выше, потому что малейшее изменение потребует перестройки (пересчета хэшей) всех блоков выше изменения.
  • Если сделать ещё подсчет хэша каждого блока вычислительно или экономически сложной операцией, то изменение данных в середине цепи становится вообще практически невозможным. Сочетание сложности подсчета хэша нового блока, а также легкости проверки правильности хэша как раз и обеспечивает блокчейну серьёзную устойчивость к неправомерным изменениям. На этом и держится безопасность биткоина и других блокчейнов.
  • Благодаря этому своему свойству блокчейн проекты могут быть публично децентрализованы. То есть, кто угодно может поставить рабочий узел блокчейна и генерировать новые блоки. В большинстве реализаций блокчейна за генерацию блока дают награду — этот процесс называется майнинг. А поскольку майнить сложно, а результаты твои легко могут быть проверены, то выгодно действовать только честно. Иначе потратишь ресурсы на майнинг, а другие майнеры твой блок не примут — вся работа насмарку. Таким образом, при полной децентрализации и независимости отдельных узлов сеть блокчейнов работает как единое целое.
  • Но ладно, допустим, одного нечестного майнера легко вычислить и проигнорировать. Но что, если их много, и они сговорились? Представьте, что все люди вокруг вас считают красный свет зеленым. :) И смотрят на вас, как на ненормального, если вы считаете иначе. Социальные эксперименты показывают, что большинство людей в такой ситуации начинают сомневаться и присоединяются к мнению большинства. А ведь в блокчейне как раз и работает правило большинства!
  • Подобная проблема выяснения истины в условиях, когда твои собеседники могут бессовестно врать, была названа Лесли Лампортом «Проблемой византийских генералов», а https://www.microsoft.com/en-us/research/publication/reaching-agreement-presence-faults/ двумя годами ранее в 1980 году им же совместно с другими авторами. Было показано, что при n шпионах, которые могут врать и искажать информацию, консенсус между участниками может быть достигнут при общем количестве участников 3n+1. А если гарантировать, что шпионы не могут искажать переданную через них сообщения, то достаточно и 2n+1. В блокчейне за счет электронной подписи зловредные узлы не могут искажать информацию, поэтому если в блокчейне менее половины зловредных узлов, то сеть устойчива.
  • Устойчивость сети к зловредным узлам называется устойчивостью к византийской проблеме (Byzantine Fault Tolerance, BFT). BFT очень важна для публичных сетевых систем, в которые могут свободно добавляться произвольные узлы. Именно такими системами является большинство проектов на блокчейне.
  • Применение блокчейна не ограничивается созданием криптовалют. Внутрь блока можно записывать что угодно. В https://bitcoin.org/ru/ туда записывается список новых транзакций, и применяется это для обмена криптовалютой между её владельцами. В https://namecoin.org/ в блоках хранятся произвольные пары ключ-значение, что можно применить для создания децентрализованных DNS. В других реализациях блокчейна используются ещё какие-нибудь фишки. А вот https://ethereum.org/ пошел значительно дальше. Он позволяет хранить в блокчейне не только транзакции, но и полноценные Тьюринг-полные программы, называемые смарт-контрактами, которые позволяют очень тонко настроить блокчейн на прикладную задачу. Например, NameCoin реализуется на Ethereum 5 строками кода.
  • Ethereum задумывался как универсальная платформа для создания децентрализованных проектов на основе блокчейна. Зачем реализовывать весь блокчейн заново, разворачивать собственную инфраструктуру, если можно парой-тройкой смарт контрактов реализовать то, что тебе нужно, на Ethereum, как, например, аналог NameCoin? Поэтому последнее время Ethereum переживает бурный рост.  На Ethereum работают уже http://dapps.ethercasts.com/, например, соц сеть и биржа фрилансеров
  • Блокчейн со смарт-контрактами предоставляет приложениям всю инфраструктуру. Приложения имеют выполняемый на блокчейне код в смарт контрактах. Приложения могут хранить в блокчейне любую информацию, передавая её в свои смарт контракты как данные. Приложения могут читать эту информацию из блокчейна, потому что состояние блокчейна Ethereum — это, по сути, база данных ключ-значение.
  • Казалось бы, что ещё нужно? Приложения получаются действительно децентрализованными, неподверженными цензуре и запрещению. В общем, блокчейн — это сплошные достоинства! Но если бы всё было так хорошо… При создании действительно мощных приложений сразу обнаруживаются и недостатки.
  • Неизменяемость. Неизменяемость — это, конечно, хорошо. Именно неизменяемость даёт блокчейну публичность и BFT. Однако есть и обратная сторона медали. Все данные, которые приложения пишут в блокчейн, остаются там навсегда. Поиграли в слова — блокчейн это запомнил. Разместили информацию в социальной сети — она навсегда сохранена в блокчейне, даже если вы потом удалили свой профиль. Взрывной рост числа приложений на блокчейне приводит к сильному раздуванию цепи блоков в размере. Уже сейчас размер полного блокчейна Ethereum перевалил за 130Гб, хотя он работает меньше 2 лет. У биткоина меньше при его солидном возрасте более 7 лет.
  • Конечно, в некоторые реализации Ethereum включают технологию https://blog.ethereum.org/2015/06/26/state-tree-pruning/, которая позволяет хранить только последнее состояние блокчейна, с ограниченной историей примерно на сутки, что на текущий момент позволяет сократить хранимую информацию в 20 раз. Например, https://github.com/ethereum/go-ethereum full node требует для хранения блокчейна 130 Гб, а Parity с поддержкой данной технологии — всего 6 Гб. Однако, учитывая, что рост числа приложений только начинается, а каждому узлу Ethereum приходится хранить все данные всех приложений, это выглядит хоть и необходимой, но всего лишь отсрочкой проблемы. С ростом размера блокчейна он перестанет помещаться на массово выпускаемые жесткие диски, его обслуживание станет по карману лишь большим организациям, что ведет к опасной централизации — сосредоточению контроля над более чем 50% сети у одной организации. Это может нарушить BFT.
  • Медленность транзакций. За свою устройчивость блокчейны расплачиваются скоростью транзакций. У биткоина 7 транзакций в секунду, у Ethereum — 15. И это на всю сеть, потому что каждый узел полностью реплицирует другие узлы. Добавление нового узла повышает устойчивость системы, но никоим образом не увеличивает скорость её работы или максимальный объём хранения данных. То есть, изменение данных (а каждое изменение данных в блокчейне — это транзакция) является бутылочным горлышком. Популярные приложения сразу же натолкнутся на это ограничение.
  • Примитивное хранение данных. При том, что состояние блокчейна уже является базой данных «ключ-значение», она довольно примитивна. Поиск возможен только по первичному ключу, объем хранимых данных очень ограничен. Для серьёзных приложений этого явно недостаточно.
  • Таким образом, при разработке приложений на блокчейнах, например, для Ethereum, проблема хранения данных стоит очень остро. Сейчас нет удовлетворительных способов её решения.
  • Но ведь существующие приложения, например, AKASHA как-то выкручиваются… В следующей части мы рассмотрим существующие подходы к решению этой проблемы.
  • Итак, если у нас есть децентрализованное приложение, какие требования к хранилищу данных
  • Распределенность — поскольку вся инфраструктура блокчейна и приложений на нем распределенная, хранилище данных также должно быть распределенное и децентрализованное.
  • Публичность. Новые узлы могут добавляться к сети и брать на себя часть нагрузки в любой момент.
  • Устойчивость к проблеме византийских генералов и другим типам атак в публичной сети— в публичной распределенной сети без этого никак.
  • Учитывая, что все данные, помещенные в БД, подписываются их владельцем, узлы не могут по своему усмотрению подменить данные, как и не могут испортить данные при репликации на других узлах. Попытки подмены сразу же обнаруживаются, используя механизм электронной подписи. За попытку подмены узел-нарушитель может быть лишен регистрационного депозита и исключен из сети. Для размещения депозита, настройки прав доступа, механизмов взаиморасчетов между узлами используется внешний (для БД) блокчейн, который должен поддерживать тьюринг-полные смарт контракты.
  • Поддержка шардинга — (возможность репликации только части данных на каждой ноде, чтобы увеличить максимальный суммарный объем данных) Каждая узел БД отвечает за определенный интервал первичных ключей данных, которые он хранит. Уровень репликации (число узлов, хранящих копии данных с одним и тем же первичным ключом) задаётся отдельно и может расти с ростом сети.
  • если мы ожидаем, что приложение будет популярно и будет хранить огромные объемы данных, то хорошо бы воспользоваться мощностью сети, чтобы увеличить максимальные объемы хранения. Полная репликация данных на каждом узле, разумеется, уменьшает шансы потери данных в случае проблем с отдельными узлами. Однако в случае большой мощности сети, например, сотни или тысячи серверов, дублировать все данные на всех серверах чрезвычайно избыточно, и можно уменьшить уровень репликации в пользу увеличения максимального суммарного объема данных. То есть, если у нас N серверов, то каждая запись должна реплицироваться только на m из них, m < N. Это позволит линейно увеличивать суммарный объем хранимых данных добавлением серверов.
  • Скорость — для популярных приложений могут потребоваться сотни тысяч, если не миллионы транзакций по сохранению или чтению данных в секунду. Принципы хранения данных позволяют предположить, что скорость записи и чтения данных в такой БД не будет сильно отличаться от текущих реализаций подобных баз данных, например, Apache Cassandra.
  • Структурированность — хранилище должно быть способно сохранять внутреннюю структуру данных, чтобы давать возможность приложениям связывать отдельные записи между собой. Это может быть JSON документ со структурой, удобной для конкретного приложения.
  • Удаление данных — хранилище должно поддерживать удаление более ненужных для приложения данных, чтобы освободить место Удаление данных поддерживается. Гарантировать мгновенное удаление нельзя, но в конце концов при добропорядочном поведении узлов данные будут удалены. Злонамеренный узел может сознательно сохранять все данные, которые удаляются. Однако он не сможет это сделать для всех данных, потому что ему направляются запросы только в определенном интервале первичных ключей.
  • Вторичные ключи, полнотекстовый поиск,
  • Язык запросов с возможностью осуществлять поиск не только по первичному ключу С помощью ElasticSearch, аналогично методам интеграции с Cassandra в проекте Elassandraвозможно расширение языка запросов вторичными ключами и полнотекстовым поиском. Приложения должны иметь возможность осуществлять быстрый поиск по хранимым данным, учитывая их внутреннюю структуру. 
  • Давайте посмотрим, насколько существующие технологии удовлетворяют этим требованиям.
  • IPFS
  • Ihttps://ipfs.io/ (InterPlanetary File System) — технология распределенной файловой системы, основанная на https://en.wikipedia.org/wiki/Distributed_hash_table(Distributed Hash Table) и протоколе https://en.wikipedia.org/wiki/BitTorrent. Она позволяет объединить файловые системы на различных устройствах в одну, используя контентную адресацию.
  • Достоинства:
  • Каждое устройство хранит только те файлы, которые ему нужны, плюс метаинформацию по расположению файлов на других устройствах. Поэтому не требуется доп. мотивация за хранение файлов.
  • Нет необходимости доверять пирам, потому что адресация файлов осуществляется по содержимому.
  • Устойчивость к флуду (загрузке ненужных файлов в сеть), потому что файлы размещаются только на собственное устройство.
  • Высокая пропускная способность (благодаря BitTorrent)
  • Недостатки:
  • Хранение только файлов (неструктурированной информации).
  • После размещения файла нельзя выходить из сети, пока он по ней не разойдется.
  • Хранение данных другими устройствами не гарантировано, для гарантированного предоставления своего файла другим нужно быть онлайн
  • Файлы статичны (неизменяемы)
  • Удаление файла в принципе не предусмотрено.
  • Именно с использованием IPFS строится социальная сеть https://akasha.world/ (Ethereum + IPFS) и торговая площадка https://openbazaar.org/. Они в полной мере наследуют указанные выше недостатки IPFS, основной из которых — нельзя разместить информацию в сети и выйти оффлайн, пока она не распространилась по пирам.
  • Распределенные файловые хранилища
  • Такие хранилища позволяют объединять отдельные устройства в общее облачное хранилище. В результате пользователи могут хранить там свои файлы так же, как они это могли бы делать в классическом централизованном хранилище, например, https://www.dropbox.com/, но дешевле. Владельцы устройств (“фермеры”), предоставляя место для хранения чужих файлов, получают за это деньги от пользователей соответственно своему вкладу. Чтобы измерить вклад, обеспечить надежность хранения и пресечь злоупотребления, используются различные проверки, например, proof of storage (доказательство принятия файла), proof of retrievability (доказательство, что файл в наличии и может быть извлечен), основанные на криптографии. За успешное прохождение проверки пользователь платит, а фермер получает некоторую сумму в криптовалюте.
  • Строятся такие проекты, в основном, с использованием технологии DHT и контентной адресации (когда хэш от файла является его идентификатором). Некоторые дополнительно используют смарт контракты.
  • Таких проектов на рынке на текущий момент довольно много, например, http://sia.tech/, https://storj.io/, https://github.com/ethersphere/swarm https://github.com/ethersphere/swarm, https://maidsafe.net/. Они все построены по схожим принципам. Причем Ethereum Swarm задумывался в том числе и для обеспечения удобного хранилища файлов для dApps.
  • Достоинства:
  • Файлы хранятся в облаке и доступны независимо от доступности их владельца.
  • Высокая пропускная способность.
  • За счет финансовой мотивации обеспечивается надежность хранения и извлечения файлов.
  • Удаление ненужных файлов возможно
  • Недостатки:
  • Хранение только файлов (а не структурированной информации)
  • Файлы статичны
  • Хранение небесплатно
  • Для хранения файлов распределенные файловые хранилища выглядят привлекательно. Однако для хранения структурированной динамической информации, например, пользовательских данных социальной сети, хранение данных в статических файлах представляет собой серьезную проблему. Дело в том, что файловые хранилища ничего не знают о содержимом файла, а приложению может требоваться искать информацию не только по идентификатору (или имени) файла, но и по его содержимому. Например, найти всех пользователей с ключевым словом blockchain. Или находящихся в определенном городе. Или даже осуществлять полноценный поиск по публикациям. Поэтому продолжаем искать реализацию получше.
  • Распределенные базы данных
  • К сожалению, в силу теоремы CAP нельзя получить полностью распределенную базу данных, которая одновременно обеспечивает согласованность, доступность и устойчивость к разделению (последнее означает, что бд продолжает функционировать даже если часть узлов выключилась из сети, или сообщения от них не доходят).
  • Для наших нужд требуется именно распределенная база данных, разумеется, устойчивая к разделению и доступная — нам необходимо быстро получать ответ из неё, хотя, возможно, и не самый свежий. Это ограничивает наш выбор рядом NoSQL баз данных, потому что ACID SQL СУБД в первую очередь обеспечивают согласованность.
  • Реализаций распределенных NoSQL баз данных великое множество. Например, MongoDB, Cassandra, RethinkDB. Все они способны работать с большим количеством реплик, объединяющихся в кластер. Клиент работает с одной из реплик, а данные автоматически синхронизируются с остальными. Для балансировки нагрузки может использоваться шардинг, когда часть данных хранится только на части реплик. Добавление в кластер новой реплики практически линейно масштабирует кластер, причем некоторые реализации (например, Cassandra) позволяют реплике автоматически принять на себя часть работы кластера.
  • NoSQL базы данных обеспечивают “целостность в конечном итоге” (eventual consistency), то есть, данные становятся согласованы через некоторое время, когда отдельные реплики синхронизируются. В этом они похожи на блокчейн — подтверждение транзакции тем вероятнее, чем больше времени прошло.
  • NoSQL базы данных могут хранить как просто ключ-значение, так и поддерживать внутреннюю структуру значения, а также дополнительные индексы. Наиболее продвинутые имеют также базовую поддержку транзакций и SQL-подобный язык запросов (например, Cassandra).
  • По всему вышесказанному этот класс баз данных может показаться идеальным для использования в блокчейне. Но есть проблема. Представьте, что в слаженный кластер таких баз данных кто-то добавил злонамеренную реплику, которая начинает сообщать другим репликам в кластере, что все данные необходимо удалить! Все остальные реплики послушно все данные удалят, и база данных будет безнадежно испорчена. То есть, такая слаженная работа реплик возможна сейчас только в доверенной среде (кластер таких баз данных неустойчив к проблеме византийских генералов). Если в кластер поместить злонамеренно работающую реплику, она может вызвать уничтожение данных всего кластера.
  • Достоинства:
  • Высокая скорость
  • Линейное масштабирование скорости и размера хранилища
  • Устойчивость к недоступности отдельных реплик
  • Зрелые реализации
  • Недостатки:
  • Необходимость доверять пирам — неустойчивость к https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B4%D0%B0%D1%87%D0%B0_%D0%B2%D0%B8%D0%B7%D0%B0%D0%BD%D1%82%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D1%85_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D0%BB%D0%BE%D0%B2.
  • BigChainDB
  • Существует реализация блокчейна под названием https://www.bigchaindb.com/ или, как она ещё называется, IPDB (InterPlanetary DataBase), которая часто упоминается как решение всех проблем с хранилищем данных. Авторы заявляют очень высокую скорость транзакций (1 млн/сек), огромную емкость хранилища (за счет распределенного хранения с частичной репликацией). BigChainDB получает эти преимущества за счет упрощенного консенсуса при формировании блоков, а также за счет хранения всех блоков и транзакций в существующей реализации noSql базы данных — https://www.rethinkdb.com/ или http://cassandra.apache.org/.
  • К сожалению, подобная архитектура имеет существенный недостаток — каждый узел имеет полные права на запись в общее хранилище данных, а значит, система в целом неустойчива к проблеме византийских генералов. Авторы этого проекта https://docs.bigchaindb.com/en/latest/bft.html об https://github.com/bigchaindb/bigchaindb/issues/293, обещая подумать об этом позже. Однако исправление фундаментальных проблем в базовой архитектуре после выпуска продукта весьма трудоёмко и чаще всего невозможно, потому что может привести к существенно другому продукту с другой архитектурой. Такое легкое отношение к фундаментальной проблеме вызывает https://reddit.com/r/Bitcoin/comments/4j7wjf/bigchaindb_a_prime_example_of_blockchain_bullshit/ проекта со стороны сообщества, потому что демонстрируемые высокие скоростные и объёмные характеристики BigChainDB в условиях отсутствия BFT (Byzantine Fault Tolerance) не так уж и отличаются от характеристик, демонстрируемых изначально noSql базами данных https://www.rethinkdb.com/ и http://cassandra.apache.org/, которые используются ею для хранения данных. Но раз уж всё равно требуется полное доверие между узлами, то почему не пользоваться указанными базами данных напрямую?
  • Таким образом, реальное использование BigChainDB ограничивается приватными сетями. Чтобы не вводить людей в заблуждение, BigChainDB стоило бы назвать BigPrivateBlockChain, тогда никаких вопросов не возникало бы. Для публичных сетей она совершенно не подходит.
  • Достоинства:
  • Скорость и хранилище, сопоставимое с распределенными noSql базами данных
  • Недостатки:
  • По сути, это и есть обычная noSql база данных, дополненная недостатками блокчейна
  • Неизменяемость (данные нельзя удалить легально, но можно злонамеренно)
  • Неустойчивость к проблеме византийских генералов, следовательно, невозможность использования в публичной сети
  • Таким образом, BigChainDB совершенно не подходит для хранения данных децентрализованных приложений в публичных сетях.

 

Итак, https://habrahabr.ru/post/327947/ хранилищ по тем или иным параметрам не удовлетворяют требованиям к базе данных, которая подойдет широкому классу децентрализованных приложений на блокчейне.         При том, что в угоду скорости допустима нежесткая связь с блокчейном (то есть, не все транзакции будут проходить через блокчейн), она должна быть устойчива к злонамеренному поведению других узлов БД, обеспечивать достаточный уровень репликации, иметь механизмы мотивации участников на поддержку сети. То есть, такая база будет нуждаться в поддержке блокчейна со смарт контрактами. При создании такой базы данных предлагается отталкиваться от существующих noSql реализаций, например, Apache Cassandra, но при этом наделить нашу БД следующими свойствами:
  • База публичная, идентификация пользователя (клиента) базы осуществляется по его публичному ключу (тот же самый ключ, что в блокчейне) — это ID пользователя.
  • Каждый пользователь может слать транзакции в базу, каждая транзакция должна быть подписана этим пользователем.
  • Созданная пользователем новая запись запоминает, что он её владелец.
  • Изменять запись после создания может только её владелец (или пользователь, для которого установлено доверие через механизм разрешений, реализованный как смарт контракт на блокчейне).
  • Все могут читать все записи.
  • Чтобы между разными пользователями не возникало конфликтов ключей их записей, всем ключам записей пользователя делается префикс: ID пользователя.
  • Более сложные разрешения можно устанавливать с помощью смарт контракта в блокчейне (например, доверие между конкретными пользователями, права на создание/удаление таблиц) и т.д.
  • Все разрешения обязательно проверяются и при транзакциях, и при репликациях.
Обязательная криптографическая подпись каждой записи гарантирует, что её изменение или удаление злонамеренной стороной без знания личного ключа владельца записи невозможно. То есть, таким образом построенное хранение данных устойчиво к https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B4%D0%B0%D1%87%D0%B0_%D0%B2%D0%B8%D0%B7%D0%B0%D0%BD%D1%82%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D1%85_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D0%BB%D0%BE%D0%B2 даже без механизма консенсуса.  Это даёт надежду, что скорость работы такой схемы будет не сильно отличаться от скорости существующих реализаций noSql баз данных. Однако злоумышленник может произвести https://en.wikipedia.org/wiki/Sybil_attack генерируя пары ключей и создавая мусорные записи в БД. Эта проблема решается введением мотивации.

Мотивация

Публичная сеть предполагает, что участники могут свободно присоединяться к ней, предоставляя оборудование, усиливающее вычислительную мощь, объемы хранения информации и распределенность сети. Для стимуляции такого поведения владельцы оборудования должны получать вознаграждение, мотивирующее их на честную работу. Это означает, что операции с БД будут платными для конечного пользователя. Это может дико звучать для человека, не знакомого с блокчейном, но вполне обосновано. Дело в том, что блокчейн проекты чаще всего не имеют собственника. Ими владеет сообщество. В результате само же сообщество должно оплачивать издержки на функционирование проекта. Деньги совсем небольшие, но ненулевые. Существующие децентрализованные хранилища файлов, которые мы рассмотрели в предыдущей части статьи, также взимают с пользователя плату за хранение файлов. И нам без этого никуда, на базовом уровне функционирование оборудование должно оплачиваться его пользователями. В принципе, эти затраты могут потом компенсироваться из других источников, но эта темы выходит за рамки данной статьи. Аналогично https://github.com/ethersphere/swarm предполагаются следующие награды:
  • Награда за извлечение данных
  • Награда за хранение данных
Награды выделяются из средств пользователя, осуществляющего запросы к БД. Так как платежи через блокчейн проходят весьма долго, для быстрых платежей можно использовать два метода — https://en.bitcoin.it/wiki/Off-Chain_Transactions и “чековые книжки”. В случае off-chain транзакций пользователю будет необходимо создавать off-chain канал с каждым узлом БД (или использовать промежуточные каналы между узлами). Учитывая, что каждый такой канал требует резервирования средств на нём, это может быть довольно накладно. Поэтому мы примем в качестве основного подход “чековой книжки”. Поясним, что это такое.  Перед обращением к базе данных пользователь должен зарезервировать часть средств на специальном смарт контракте “чековая книжка”. Далее адрес этого контракта используется узлом БД для получения вознаграждения — контракт “чековая книжка” хранит деньги своего владельца и позволяет третьим сторонам обналичивать подписанные владельцем чеки, просто посылая транзакцию с чеком в качестве данных на метод cash контракта.
  • Контракт отслеживает итоговую сумму, выписанную каждому получателю во время соединения
  • Владелец при посылке чека должен обязательно запоминать общую посланную сумму
Чек обналичивается, если
  • адрес контракта соответствует адресу на чеке
  • чек подписан владельцем (ID пользователя — публичный ключ)
  • полная сумма на чеке больше, чем в предыдущем погашенном чеке для данного получателя
Тогда при необходимости вознаградить узел БД, пользователь просто шлет ей чек. Узел-получатель может сохранять только последний полученный чек от каждого пользователя и периодически обналичивать его, посылая на контракт “чековая книжка”, что позволяет при некотором доверии экономить на транзакциях блокчейна.

Награда за извлечение данных

Данные на узлах БД имеют определенный уровень репликации, то есть, данные с определенным ключом хранятся только на части узлов, например, на N. Тем не менее, за данными пользователь может обратиться к любому узлу. Узел, к которой обратился пользователь, выступает далее в качестве “координатора”. По значению ключа данных вычисляются N узлов, ответственные за хранение этих ключей, и запросы направляются к ним. Возвращенные узлами данные проверяются координатором на соответствие электронным подписям, сравниваются по метке времени, и самая свежая запись возвращается пользователю. Оплате подлежит работа координатора и реплик, хранящих данные. Пропорции оплаты подлежат более подробному расчету, но для стимуляции правильного поведения необходимо выполнять следующие принципы:
  • Чем быстрее узел вернул данные, тем большую часть оплаты он заслуживает
  • Если узел вернул старые данные, оплата уменьшается
  • Узел, не вернувший данные, не получает ничего
  • Координатор получает фиксированную небольшую часть
Вместе с данными координатор выставляет счет, где указано, какому узлу сколько полагается. Пользователь выписывает чеки каждому. Координатор отправляет чеки узлам. А также обновленные данные, если узел не вернул ничего или вернул старые данные. Чтобы защититься от злонамеренных координаторов и пользователей, которые не будут платить, каждый узел ведет список пользователей, от которых он ожидает оплаты, и координаторов, посылающих запросы от этих пользователей. Если уровень задолженности превышает некоторое пороговое значение, узел может перестать принимать запросы от указанных пользователей и координаторов. При получении чеков списки корректируются.

Награда за хранение

Награда за извлечение косвенным образом стимулирует и хранение, но работает только в отношении популярных и часто запрашиваемых данных. Для стимуляции долговременного хранения данных, особенно если они запрашиваются редко, требуется награда за хранение. В статье об http://swarm-gateways.net/bzz:/theswarm.eth/ethersphere/orange-papers/1/sw%5E3.pdf описана система наград за хранение. Узлы заключают с владельцем информации контракт на хранение данных в течение какого-то времени. Оплата хранения может происходить в момент сохранения (обновления) данных или через некоторое время при условии, что данные действительно хранятся. В случае обнаружения потери данных в течение действия контракта, узел может быть оштрафован, для чего каждому узлу требуется первоначальная регистрация с гарантийным депозитом. При сохранении данных узел возвращает квитанцию, которая служит доказательством, что узел принял файл на хранение. Эта квитанция впоследствии позволяет проверить, хранятся ли всё ещё соответствующие им данные, и если нет — инициировать транзакцию на судебный смарт контракт, который позволит наказать провинившийся узел. В нашем случае данные не статичны, запись с одним и тем же ключом может перезаписываться несколько раз. В этом случае предъявленной квитанции может соответствовать не только оригинальная запись, но и более новая запись с тем же ключом. При инициированной пользователем операции удаления данных, вместо физического удаления данные заменяются специальной “нулевой” записью. Запись может быть физически удалена после истечения контракта хранения на неё.

Полнотекстовый поиск, вторичные индексы

В noSql базах данных быстрый поиск с задействованием небольшого количества узлов возможен только по первичному ключу. Наша БД в этом отношении немногим отличается от них. Между тем, поиск записей по ключевым словам, а также группировка записей по каким-то критериям трудно достижима без вторичных индексов и полнотекстового поиска. Для полнотекстового поиска, а также использования вторичных индексов предлагается использовать решение, аналогичное http://www.elassandra.io/. Это решение представляет собой локальные полнотекстовые индексы https://www.elastic.co/products/elasticsearch на каждом узле распределенной noSql базы http://cassandra.apache.org/. Полнотекстовые запросы рассылаются координатором всем узлам, затем смешиваются и возвращаются клиенту. Поскольку дополнительные индексы создаются локально и независимо на каждом узле, дополнительное предотвращение проблемы византийских генералов не требуется.

Итоги

Такая БД может использоваться децентрализованными приложениями на любых блокчейнах, поддерживающих Тьюринг-полные смарт контракты (впрочем, для других блокчейнов децентрализованные приложения и не создаются). Например, она может быть использована для нужд распределенных приложений поверх блокчейнов Ethereum, RChain и других. Концепция такой БД была разработана в рамках open-source проекта https://ubermensch.store/. Реализации ещё нет (но она явно востребована), а концепция сегодня выносится на суд общественности. Надеемся, что впервые представленная концепция публичной децентрализованной noSql БД заинтересует вас достаточно, чтобы обсудить её 


https://thegraph.com/ makes it easy to query blockchain data using https://graphql.org/. Decentralized nodes aggregate blockchain data, supported by https://ipfs.io/.
You can send compute jobs to https://iex.ec/, and even handle intense graphic rendering with the https://www.rendertoken.com/. With all these protocol tokens flying around, we might need to do some https://arxiv.org/abs/1801.09515 to exchange tokens across multiple blockchains.
You can use https://w3c.github.io/vc-use-cases/, batched and anchored to your blockchain of choice (suggestion: Bitcoin) to record any kind of data, including ownership and transfer of assets like real estate, car titles, and NFTs. You can store those claims, supporting files, and various database records (see https://github.com/orbitdb/orbit-db) on https://ipfs.io/ or https://storj.io/.



на Комментариев нет:
Подписаться на: Сообщения (Atom)

mlops

  . Почти вся информация по вопросу собрана в гитхабе  awesome-mlops , который курирует Лариса Висенгериева, главный эксперт сайта ml-ops.or...

  • Интересное
           https://poedinki.ru/  https://mikhailivanov.ru/   https://ru.wikipedia.org/wiki/Vaporwave  https://en.wikipedia.or...
  • Современные тренды web-разработки на 2021
    Гайды Настраиваем удобный npm проект для себя и команды или немного о современных фронтенд инструментах https://habr.com/post/417429/ ...
  • Electron and Visual Studio Code и Atom
    VIM Emacs Sublime Notepad++ Electron – технология, разработанная GitHub. Она позволяет строить кроссплатформенные десктопные прилож...