Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
В случае Биткоина проверку осуществляют не только майнеры (хотя и они тоже), а полные ноды биткоин-сети. Собственно для этого они и нужны — проверять новые блоки от майнеров и распространять их дальше если они соответствуют правилам протокола. Если часть майнеров начнет создавать «неправильные» блоки, то сеть полных узлов эти блоки отвергнет, а учтёт только «правильные» блоки от честных майнеров. Поэтому текущая централизация майнинга не является столь критичной угрозой для сети (хотя это, конечно, не очень хорошо).
Я с вами согласен, и в статье, в самом начале, об этом говорится.
Подчеркну, предлагаемый метод ориентирован не столько на публичные блокчейны криптовалют, сколько на частные блокчейны, которые уже сейчас начинают внедряться в компаниях и госструктурах.
Подчеркну, предлагаемый метод ориентирован не столько на публичные блокчейны криптовалют, сколько на частные блокчейны, которые уже сейчас начинают внедряться в компаниях и госструктурах.
Дополню свой предыдущий комментарий. Уточнил на blockchain.info, текущий размер блокчейна биткоина превышает 133 Гб, не считая индексов. У меня нет статистических данных, но с высокой степенью вероятности предположу, держателями большинства полных узлов являются владельцы майнерских ферм, входящих в тот или иной пул. Мне как-то сложно представить множество обычных пользователей, которые ради поддержки своего кошелька будут поднимать полный узел.
Я вот держу полную ноду, хотя ни к майнингу отношения не имею, ни к огромному количеству биткоинов. Просто в целом как-то не особо мешает.
Поэтому я корректно и написал, что чаще всего полные узлы поднимают майнеры. Но не утверждал, что каждый владелец полного узла является майнером.
Большинство пользователей предпочитают легкие или онлайн кошельки, так как процесс первичной синхронизации полного узла слишком долог. Думаю, это отпугивает многих.
Впрочем, это не имеет принципиального значения к теме, поднятой в данной статье.
Большинство пользователей предпочитают легкие или онлайн кошельки, так как процесс первичной синхронизации полного узла слишком долог. Думаю, это отпугивает многих.
Впрочем, это не имеет принципиального значения к теме, поднятой в данной статье.
У многих больше доверия к кошельку биткоинКоре чем к другим, а коре есть только «толстый». Если бы был готовый дамп раздаваемый коре (допустим обновляемый раз в неделю чтобы автоматизировать распределенную проверку целостности), то я бы только им и пользовался, а так, поскольку в крипе сижу мало то да, сижу на тонких в основном.
Ну а в целом я вот не очень понимаю зачем таскать с собой весь блокчейн.
ИМХО если держать UTXO и последние тысячу блоков то надежность работы будет ничуть не хуже, зато ресурсов нужно будет много меньше.
Ну а в целом я вот не очень понимаю зачем таскать с собой весь блокчейн.
ИМХО если держать UTXO и последние тысячу блоков то надежность работы будет ничуть не хуже, зато ресурсов нужно будет много меньше.
Статистику по узлам можно посмотреть здесь bitnodes.21.co и здесь coin.dance/nodes. Видно, что большинство узлов расположено в Европе и США. Стоимость содержания полного узла не так велика с точки зрения объема — можно хранить только хеши блоков (режим prune), тогда объем данных будет 550 ГБ. Скорее проблемой для обычных пользователей может быть исходящий трафик.
В принципе, в сообществе Биткоин пользователей регулярно звучат опасения, что текущее количество полных узлов (порядка 9k) недостаточное. Но, например, история активации Segwit -UASF которая была в августе, показывает, что если появляется угроза раскола сети то многие пользователи «подтягиваются» и запускают полные ноды. И инициатива пользователей с UASF является хорошим примером того, какую большую роль играет сеть полных нод Биткоина.
В принципе, в сообществе Биткоин пользователей регулярно звучат опасения, что текущее количество полных узлов (порядка 9k) недостаточное. Но, например, история активации Segwit -UASF которая была в августе, показывает, что если появляется угроза раскола сети то многие пользователи «подтягиваются» и запускают полные ноды. И инициатива пользователей с UASF является хорошим примером того, какую большую роль играет сеть полных нод Биткоина.
Спасибо за ссылки. По последним данным насчитывается более 17 млн кошельков в сети биткоина. Даже если учесть, что пользователь может иметь неограниченное число кошельков, то 9 тыс. полных узлов теряются на фоне остальных пользователей.
Интересно, есть ли статистика по числу майнеров? Тогда можно было бы посмотреть корреляцию с числом полных узлов.
Интересно, есть ли статистика по числу майнеров? Тогда можно было бы посмотреть корреляцию с числом полных узлов.
алгоритм консенсуса нужен не только для подтверждения транзакций, но и для первичной эмиссии монет, что гораздо важнее.
именно PoW и рост курса рывками привлекает и привлекает все новых пользователей в bitcoin.
ничего лучше PoW (и может быть PoC) всякие pos, dpos и т.п. — не катят, потому как концентрируют монеты и влияние у ограниченного изначально круга лиц.
именно PoW и рост курса рывками привлекает и привлекает все новых пользователей в bitcoin.
ничего лучше PoW (и может быть PoC) всякие pos, dpos и т.п. — не катят, потому как концентрируют монеты и влияние у ограниченного изначально круга лиц.
Эмиссия монет в биткоине это тоже транзакция, которая, по сути дела, также требует подтверждения.
Повторюсь, предлагаемый метод ориентирован на частные блокчейны, в которых нет особого смысла развивать внутренний консенсус.
Повторюсь, предлагаемый метод ориентирован на частные блокчейны, в которых нет особого смысла развивать внутренний консенсус.
coinbase это транзакция, но весь смысл ее в том, кому и когда именно она передает монеты, именно хорошее распределение сделало криптовалюты такими интересными. Именно поэтому форки типа bitcoin share (и наверняка будущий bitcoin gpu) популярны и имеют такую высокую цену — потому что качественно распределены по сообществу.
Частным блокчейнам за глаза хватит dpos (bitshares/steemit/golos) или проще — ledger consensus process (ripple)
Частным блокчейнам за глаза хватит dpos (bitshares/steemit/golos) или проще — ledger consensus process (ripple)
Частным блокчейнам за глаза хватит dpos (bitshares/steemit/golos) или проще — ledger consensus process (ripple)
Частные блокчейны вовсе могут обойтись без внутреннего консенсуса. Между кем в частном блокчейне нужно искать консенсус?
Обеспечение доверительных механизмов конечно же.
Частный это не значит что все участники белые и пушистые, особенно когда дело касается финансовой заинтересованностью.
dpos например, дает возможность выбрать (буквально голосованием деньгой или влиянием) некоторое количество тех кто будет заверять транзакции (вырожденный случай — все участники), которые должны это делать своевременно и по очереди. А еще часть держит полные ноды и большую часть голосов — контролирует первых.
Это классика — одному доверять контроль над финансами — дать в руки ему возможность для манипуляций, и это ему будет бесплатно. Завяжи такой контроль на двоих — и атака станет дороже, если таких людей будет больше, сделай их работу прозрачной — и атака станет невообразимо дорогой — проверенная временем схема.
Частный это не значит что все участники белые и пушистые, особенно когда дело касается финансовой заинтересованностью.
dpos например, дает возможность выбрать (буквально голосованием деньгой или влиянием) некоторое количество тех кто будет заверять транзакции (вырожденный случай — все участники), которые должны это делать своевременно и по очереди. А еще часть держит полные ноды и большую часть голосов — контролирует первых.
Это классика — одному доверять контроль над финансами — дать в руки ему возможность для манипуляций, и это ему будет бесплатно. Завяжи такой контроль на двоих — и атака станет дороже, если таких людей будет больше, сделай их работу прозрачной — и атака станет невообразимо дорогой — проверенная временем схема.
В частном блокчейне все узлы, в той или иной степени, административно связаны друг с другом в рамках иерархических связей внутри организации, например, банка. Захочет хозяин банка подменить отчетность, записанную в блокчейне его банка (частный блокчейн), и очень легко это сделает. Неважно каким методом достигался консенсус. Скажет админу Васе, что это надо. Вася и сделает все в лучшем виде.
Поэтому внутренний консенсус не имеет доверия. Поэтому при внедрении частных блокчейнов идет делегирование доверия. В решении, например, Exonum хэши блоков частного блокчейна отправляются в биткоин. В Эфириуме тоже есть способы построения дочерних блокчейнов, которые доверие делегируют в смарт-контракты. Это все работает и никто не пытается поставить под сомнение работу частных блокчейнов без внутреннего консенсуса.
В моем решении использован другой метод делегирования доверия. Разница в том, что при Exonum и Эфириуме частный блокчейн будет вынужден платить деньги за поддержание к нему доверия. В решении DLT Trust оплата не предусмотрена.
Поэтому внутренний консенсус не имеет доверия. Поэтому при внедрении частных блокчейнов идет делегирование доверия. В решении, например, Exonum хэши блоков частного блокчейна отправляются в биткоин. В Эфириуме тоже есть способы построения дочерних блокчейнов, которые доверие делегируют в смарт-контракты. Это все работает и никто не пытается поставить под сомнение работу частных блокчейнов без внутреннего консенсуса.
В моем решении использован другой метод делегирования доверия. Разница в том, что при Exonum и Эфириуме частный блокчейн будет вынужден платить деньги за поддержание к нему доверия. В решении DLT Trust оплата не предусмотрена.
В частном блокчейне все узлы, в той или иной степени, административно связаны друг с другом в рамках иерархических связей внутри организации, например, банка. Захочет хозяин банка подменить отчетность, записанную в блокчейне его банка (частный блокчейн), и очень легко это сделает.
Откуда вы это берете, где этот кладезь дезинформации? Блокчейн, принадлежащий одному хозяину это бессмысленная, дорогая и неудобная база данных, так никто не делает. Или делают для распила бабла или для того, чтобы впарить инновации кому-нибудь.
Посмотрите хотя бы на Hyperledger Fabric. Частный блокчейн, узлы могут контролироваться разными организациями, для изменения алгоритма работы сети эти узлы должны проголосовать. Такой блокчейн можно использовать в банках (множественное число), например, для работы с KYC (know your customer) данными. И никакой провинциальный банк из Дагестана не сможет изменить кредитный рейтинг без согласия других участников системы. В этом и есть сила блокчейна, в том, что данные децентрализованы и им можно доверять.
А по вашему получается, что частный блокчейн живет в одной организации и контролируется ею же. Поставьте тогда любую БД, настройте репликацию и права доступа и не парьтесь. Это будет многократно дешевле и проще.
Посмотрите хотя бы на Hyperledger Fabric. Частный блокчейн, узлы могут контролироваться разными организациями, для изменения алгоритма работы сети эти узлы должны проголосовать.
Почему вы так решили? Hyperledger Fabric это не частный блокчейн, а лишь платформа для разработки разных блокчейнов.
Ваш пример блокчейна, который контролируют разные организации не стоит называть частным блокчейном. Это публичный блокчейн, объединяющий группу компаний по профессиональному признаку.
В последний год много публикаций о месте и роли настоящих частных блокчейнов, работающих в рамках одной компании. Вокруг них начался настоящий холивар. Если Вы считаете, что на рынке нет места частным блокчейнам, то это Ваше мнение. Я не собираюсь спорить, жизнь покажет.
Так же жизнь покажет насколько станет востребованным предлагаемый метод, описанный в статье. Сейчас идет активная по созданию демо-прототипа. Думаю, в начале ноября он уже будет готов.
Вы считаете, что на рынке нет места частным блокчейнам, то это Ваше мнение. Я не собираюсь спорить, жизнь покажет.
Этот спор очень просто решить, предложите сценарии использования такого блокчейна и покажите почему он лучше базы данных в таком сценарии.
Реальный пример частного блокчейна в масштабах государственного ведомства. На базе Exonum был создан частный блокчейн регпалаты в Грузии.
А чем он лучше чем БД для данного применения?
Лично я вижу преимущество в росте доверия со стороны граждан, чья собственность внесена в электронный реестр. В обычной БД очень просто подменить запись. Гиви думает магазин принадлежит ему, а вдруг оказалось, что владелец сейчас Гела.
Доверие к самому блокчейну в данном примере обеспечивается за счет делегирования доверия, в виде хэшей блоков, в биткоин.
Так как не разбирался в деталях этой реализации, то подробностей в каком виде идет запись хэшей в биткоин сообщить не могу.
Доверие к самому блокчейну в данном примере обеспечивается за счет делегирования доверия, в виде хэшей блоков, в биткоин.
Так как не разбирался в деталях этой реализации, то подробностей в каком виде идет запись хэшей в биткоин сообщить не могу.
Какое тут доверие? Частному блокчейну доверять нельзя, им владеет единственный и злонамеренный владелец. На шаге 1 Гера регистрирует юр. лицо, появляется запись в биткоин. На шаге 2 Гела переписывает юр. лицо на себя и появляется ещё одна запись в биткоин. Все честно, вот запись в частном блокчейне, вот хеш в биткоине.
В реальной жизни Гела пойдет в суд с поддельных договором купли продажи. Или Геру посадят и не выпустят пока он не подпишет документы.
И так, между делом, если частному блокчейну нельзя доверять и все работает на делегировании (посылке хешей), то зачем вообще блокчейн? Я могу хеши из базы посылать с тем же успехом.
Итого — ваш пример шикарно работает на основе БД, а еще ни БД ни даже полноценный блокчейн озвученную проблему не решают. Решают ее независимые суды и органы право порядка.
Я все еще жду примера чем частный блокчейн, контролируемый одной организацией, лучше обычной БД.
В реальной жизни Гела пойдет в суд с поддельных договором купли продажи. Или Геру посадят и не выпустят пока он не подпишет документы.
И так, между делом, если частному блокчейну нельзя доверять и все работает на делегировании (посылке хешей), то зачем вообще блокчейн? Я могу хеши из базы посылать с тем же успехом.
Итого — ваш пример шикарно работает на основе БД, а еще ни БД ни даже полноценный блокчейн озвученную проблему не решают. Решают ее независимые суды и органы право порядка.
Я все еще жду примера чем частный блокчейн, контролируемый одной организацией, лучше обычной БД.
Это не мой пример, взятый из головы. Это реально работающий проект.
Извините, но начинать холивар на тему что лучше для организации обычная БД или БД в связке с блокчейном я не собираюсь.
Извините, но начинать холивар на тему что лучше для организации обычная БД или БД в связке с блокчейном я не собираюсь.
Я не вижу почвы для холиваров. Есть конкретный вопрос, лежащий в технической области.
Сценарий вы предложили (регпалата Грузии), но очевидно, что частный блокчейн в этом сценарии не дает никаких преимуществ перед БД. Более того, DLT Trust в этом сценарии тоже не дает населению доп. защиты.
Этот спор очень просто решить, предложите сценарии использования такого блокчейна и покажите почему он лучше базы данных в таком сценарии.
Сценарий вы предложили (регпалата Грузии), но очевидно, что частный блокчейн в этом сценарии не дает никаких преимуществ перед БД. Более того, DLT Trust в этом сценарии тоже не дает населению доп. защиты.
Я вам привел реально работающий пример. Хорош он или плох не хочу обсуждать. Пример есть и, думаю, он не единственный. Вы не согласны с перспективами использования технологии блокчейна в частных сетях, это ваше право. Я же считаю, что во многих корпоративных решениях блокчейны будут применяться. Время покажет кто из нас был прав.
Вопрос «есть ли будущее у частного блокчейна» выходит за рамки данной статьи. Для меня это как аксиома, есть будущее. Поэтому тратится время и деньги на создание упомянутого метода.
Если победит подход, отражающий вашу точку зрения, то ничего страшного не произойдет. Я только зафиксирую убытки :)
Думаю, наш дальнейший спор не имеет перспектив, согласен, что вы победитель.:)
Вопрос «есть ли будущее у частного блокчейна» выходит за рамки данной статьи. Для меня это как аксиома, есть будущее. Поэтому тратится время и деньги на создание упомянутого метода.
Если победит подход, отражающий вашу точку зрения, то ничего страшного не произойдет. Я только зафиксирую убытки :)
Думаю, наш дальнейший спор не имеет перспектив, согласен, что вы победитель.:)
Раз уж некропостнул, то попробую влезть в ваш спор, поскольку это частый холивар.
Смотрите.
Допустим у нас есть некая организация с сотней филиалов в разных городах, а то и странах.
Как в любой крупной структуре ее управление не монолитно.
Имеют место конфликты интересов. Как явные (соучредители вступили в конфликт, начальник филиала не может уволить своего зама потому что КЗоТ и совету директоров в целом пофиг что зам спит с женой начальника и т.п.) так и скрытые (например кто-то из айтишников «двойной агент», или пойдем еще глубже — «сантехник»/курьер втыкнул что-то в сеть или в комп имеющий выход на ядро сети, ну или банально очередную 0день-уязвимость в каком-то софте провтыкали).
Вопрос — как в случае обычной базы заинтересованному лицу (имеющему на это право) быть уверенным что данные в базе не компрометированы? Нет, от слива информации с помощью блокчейна защититься сложно, но от изменения — элементарно.
Любой миноритарий может видеть что мажоритарии не мухлюют с документацией, ген.директор может с помощью одного доверенного специалиста (или сам) проверить целостность базы и т.п.
Я не говорю что это единственное или даже лучшее решение для подобных кейсов. В частности есть решения где нет ни блоков ни цепочек, но есть хеши у каждой транзакции и построенная на их базе репликация. Но у этих решений есть свои минусы и плюсы и в сравнении с ними избитый блокчейн смотрится вполне достойно. А вот «голая» база уже не очень.
Ну и напоследок простой кейс из давно забытой бытности АСУшника в госконторе: в среднем раз в месяц на меня расписывали запросы СБУ/прокуратуры/главка о том когда на самом деле был создан тот или иной документ (пачка документов), нет ли признаков вмешательства и т.п. (Ага, распределенная СУБД на 60 удаленных баз часть из которых синхронизировались вообще по флоппинету, ну точнее мне курьер DHL раз в три дня флешку привозил, все пишут в общее пространство и база не журналируемая).
Задачка была нетривиальная, хоть и регулярная.
В зависимости от политической коньюктуры ответы колебались от «ответить невозможно» до «судя по таким-то признакам скорее всего было так и так». От объективных фактов ответ не зависил от слова совсем. Всегда была большая неопределенность (нет у меня были периодические бинарные бекапы баз, но к делу их не пришьешь) которую я интерпретировал исходя из пожеланий руководства или моего собственного видения. Вот так чтобы прямо соврать я никогда не врал. Всегда отвечал правду, но какую из правд написать — тут уж простите.
Смотрите.
Допустим у нас есть некая организация с сотней филиалов в разных городах, а то и странах.
Как в любой крупной структуре ее управление не монолитно.
Имеют место конфликты интересов. Как явные (соучредители вступили в конфликт, начальник филиала не может уволить своего зама потому что КЗоТ и совету директоров в целом пофиг что зам спит с женой начальника и т.п.) так и скрытые (например кто-то из айтишников «двойной агент», или пойдем еще глубже — «сантехник»/курьер втыкнул что-то в сеть или в комп имеющий выход на ядро сети, ну или банально очередную 0день-уязвимость в каком-то софте провтыкали).
Вопрос — как в случае обычной базы заинтересованному лицу (имеющему на это право) быть уверенным что данные в базе не компрометированы? Нет, от слива информации с помощью блокчейна защититься сложно, но от изменения — элементарно.
Любой миноритарий может видеть что мажоритарии не мухлюют с документацией, ген.директор может с помощью одного доверенного специалиста (или сам) проверить целостность базы и т.п.
Я не говорю что это единственное или даже лучшее решение для подобных кейсов. В частности есть решения где нет ни блоков ни цепочек, но есть хеши у каждой транзакции и построенная на их базе репликация. Но у этих решений есть свои минусы и плюсы и в сравнении с ними избитый блокчейн смотрится вполне достойно. А вот «голая» база уже не очень.
Ну и напоследок простой кейс из давно забытой бытности АСУшника в госконторе: в среднем раз в месяц на меня расписывали запросы СБУ/прокуратуры/главка о том когда на самом деле был создан тот или иной документ (пачка документов), нет ли признаков вмешательства и т.п. (Ага, распределенная СУБД на 60 удаленных баз часть из которых синхронизировались вообще по флоппинету, ну точнее мне курьер DHL раз в три дня флешку привозил, все пишут в общее пространство и база не журналируемая).
Задачка была нетривиальная, хоть и регулярная.
В зависимости от политической коньюктуры ответы колебались от «ответить невозможно» до «судя по таким-то признакам скорее всего было так и так». От объективных фактов ответ не зависил от слова совсем. Всегда была большая неопределенность (нет у меня были периодические бинарные бекапы баз, но к делу их не пришьешь) которую я интерпретировал исходя из пожеланий руководства или моего собственного видения. Вот так чтобы прямо соврать я никогда не врал. Всегда отвечал правду, но какую из правд написать — тут уж простите.
Нет, от слива информации с помощью блокчейна защититься сложно, но от изменения — элементарно.
Именно так, согласно пословице: от домашнего вора нет запора. Ну хоть полдела защищается — от внесения изменений :)
Ну частично можно и с чтением поработать с помощью приватного блокчейна, но тут сильно от задачи зависит.
Недавно пилили решение в котором документ (атомарная единица данных) целиком не хранился ни на одном узле, а хранился по кусочкам на нескольких узлах с несколькими копиями (нужно N*M узлов, где N колво частичек документа, влияет на сложность сговора, M — степень дублирования информации в сети, влияет на надежность).
Ну а в общей базе (на блокчейне, но не суть в данном случае) хранилась метаинформация вроде прав на чтение, прав на запись, хешей тегов по которым могут искать инфу и т.п. Ну и собственно для чего это делалось — отдельный блокчейн (можно тот-же) в котором хранился лог запросов.
Клиент (сотрудник организации) делал запрос информации, «бросал» его ближайшему узлу, тот тиражировал «кому надо», и узлы у которых есть нужная инфа по кусочку ее возвращали, при этом (ради чего все затевалось) запрос клиента сохранялся в блокчейн запросов. Чтобы прочитать информацию из базы и не сохранить сам факт чтения этой информации нужно получить контроль минимум над N узлами (список которых в идеале должен меняться от запроса к запросу).
Ну а дальше уже можно вводить лимиты, интеллектуальные мониторинги и т.п.
Например можно сделать фильтр Блума чтобы считать не количество запросов менеджера к клиентской базе а количество РАЗНЫХ запросов к базе выявляя неавторизованную активность по сливу базы оставляя единичный доступ к любой информации.
Понятно что схема не спасет от «супер-рута» у которого рут ко всем серверам, но в большой структуре при достаточной степени суверенитета подразделений эту операцию можно сделать очень сложной.
Недавно пилили решение в котором документ (атомарная единица данных) целиком не хранился ни на одном узле, а хранился по кусочкам на нескольких узлах с несколькими копиями (нужно N*M узлов, где N колво частичек документа, влияет на сложность сговора, M — степень дублирования информации в сети, влияет на надежность).
Ну а в общей базе (на блокчейне, но не суть в данном случае) хранилась метаинформация вроде прав на чтение, прав на запись, хешей тегов по которым могут искать инфу и т.п. Ну и собственно для чего это делалось — отдельный блокчейн (можно тот-же) в котором хранился лог запросов.
Клиент (сотрудник организации) делал запрос информации, «бросал» его ближайшему узлу, тот тиражировал «кому надо», и узлы у которых есть нужная инфа по кусочку ее возвращали, при этом (ради чего все затевалось) запрос клиента сохранялся в блокчейн запросов. Чтобы прочитать информацию из базы и не сохранить сам факт чтения этой информации нужно получить контроль минимум над N узлами (список которых в идеале должен меняться от запроса к запросу).
Ну а дальше уже можно вводить лимиты, интеллектуальные мониторинги и т.п.
Например можно сделать фильтр Блума чтобы считать не количество запросов менеджера к клиентской базе а количество РАЗНЫХ запросов к базе выявляя неавторизованную активность по сливу базы оставляя единичный доступ к любой информации.
Понятно что схема не спасет от «супер-рута» у которого рут ко всем серверам, но в большой структуре при достаточной степени суверенитета подразделений эту операцию можно сделать очень сложной.
Кажется этот сценарий покрывается следующими мерами (кажется вы так и сделали)
— лог изменений в базу (таблица audit log например)
— сертификатами и цифровой подписью к каждой записи
И кажется, это сильно удобнее в эксплуатации, чем использование цепочки блоков и последующее решение как все это индексировать, реплицировать и т.п. Может тут есть какие-то подводные грабли, но мне они не очевидны.
— лог изменений в базу (таблица audit log например)
— сертификатами и цифровой подписью к каждой записи
И кажется, это сильно удобнее в эксплуатации, чем использование цепочки блоков и последующее решение как все это индексировать, реплицировать и т.п. Может тут есть какие-то подводные грабли, но мне они не очевидны.
Ваша таблица изменений в базу может быть изменена любым пользователем имеющим к ней доступ (не обязательно root, но пусть будет root).
Просто открываем таблицу, удаляем одни записи, вставляем на их место другие, чтобы общая картинка «плясала». Всё. Никто. Ничего. Не узнает. И не докажет.
Все что можно сделать — иметь в сети одну доверенную машину, которую контролируешь только ты, и она будет хранить у себя копию данного лога. Правда это не спасет от махинаций с нарушением целостности, но по крайней мере при глубоком расследовании подлог можно будет… нет, не доказать — обнаружить. Доказать — как повезет. Ведь кто знает — может у всех все правильно, а у вас подделка?)
Частным случаем подобных «безопасных логов на надежном носителе» являются… бумажные носители.
Когда есть документы, или распечатки отчетов и т.п. в которых есть данные противоречащие базе.
Но все это… неимоверно сложно.
Вместе с тем решения на базе деревьев Меркле (не обязательно блокчейн, есть другие цепочки и деревья, без блоков) позволяют просто максимально распространять один единственный хеш, и быть уверенным что все что ДО этого хеша — неизменно.
Да, в приватных решениях блоки не обязательны, но они дают дополнительную атомарность, упрощая репликацию, восстановление и т.п. повсеместный блокчейн это дань моде, но лично я помню как мне приходилось использовать флоппинет в котором синхронизация удаленного филиала велась ежедневным обменом флешками, которые возили курьеры DHL. Если бы та база была на блокчейне, то проблем бы не было, а вот что-то более реалтаймовое, где нет деления на блоки — могло бы вызвать проблему, если бы заранее не предусмотрели такой большой пинг (в 48 часов).
Просто открываем таблицу, удаляем одни записи, вставляем на их место другие, чтобы общая картинка «плясала». Всё. Никто. Ничего. Не узнает. И не докажет.
Все что можно сделать — иметь в сети одну доверенную машину, которую контролируешь только ты, и она будет хранить у себя копию данного лога. Правда это не спасет от махинаций с нарушением целостности, но по крайней мере при глубоком расследовании подлог можно будет… нет, не доказать — обнаружить. Доказать — как повезет. Ведь кто знает — может у всех все правильно, а у вас подделка?)
Частным случаем подобных «безопасных логов на надежном носителе» являются… бумажные носители.
Когда есть документы, или распечатки отчетов и т.п. в которых есть данные противоречащие базе.
Но все это… неимоверно сложно.
Вместе с тем решения на базе деревьев Меркле (не обязательно блокчейн, есть другие цепочки и деревья, без блоков) позволяют просто максимально распространять один единственный хеш, и быть уверенным что все что ДО этого хеша — неизменно.
Да, в приватных решениях блоки не обязательны, но они дают дополнительную атомарность, упрощая репликацию, восстановление и т.п. повсеместный блокчейн это дань моде, но лично я помню как мне приходилось использовать флоппинет в котором синхронизация удаленного филиала велась ежедневным обменом флешками, которые возили курьеры DHL. Если бы та база была на блокчейне, то проблем бы не было, а вот что-то более реалтаймовое, где нет деления на блоки — могло бы вызвать проблему, если бы заранее не предусмотрели такой большой пинг (в 48 часов).
Почему для аудита и защиты от подделки не использовать старую добрую цифровую подпись? Кажется ее довольно тяжело подделать даже самому главному админу.
0. Для начала выдаем пользователям пару публичный и приватный ключ.
1. Берем запись в базе, которую хотим защитить от подлога.
2. Вычисляем ее хеш или просто склеиваем все поля. Для пущей надежности запишем туда же хеш предыдущей версии или же возьмем и сериализуем дерево Меркле. Тут уж в зависимости от требований.
3. Подписываем то, что получилось с помощью приватного ключа пользователя и записываем результат куда-нибудь рядом.
4. Если надо проверить подлинность записи, то достаточно взять публичный ключ пользователя и проверить подпись.
Если кто-то захочет поменять данные, то ему придется «засветиться» и оставить везде свою подпись и переписать кучу хешей. Абсолютно то же самое случится если кто-то перепишет блокчейн, что вполне возможно если он не основан на proof of work. И кажется все это более оправдано в текущей ситуации, потому что в обмен на 3-4 недели работы по реализации цифровой подписи, получаем все богатство инструментария для работы с БД. Инструменты для блокчейна до этого уровня дойдут лет через 5.
Для надежной репликации уже есть миллион решений и блокчейн новых не предлагает. Например CouchDB, она будет отлично реплицироваться и будет также append only (собственно это следствие отсутствия проблем с реализацией).
0. Для начала выдаем пользователям пару публичный и приватный ключ.
1. Берем запись в базе, которую хотим защитить от подлога.
2. Вычисляем ее хеш или просто склеиваем все поля. Для пущей надежности запишем туда же хеш предыдущей версии или же возьмем и сериализуем дерево Меркле. Тут уж в зависимости от требований.
3. Подписываем то, что получилось с помощью приватного ключа пользователя и записываем результат куда-нибудь рядом.
4. Если надо проверить подлинность записи, то достаточно взять публичный ключ пользователя и проверить подпись.
Если кто-то захочет поменять данные, то ему придется «засветиться» и оставить везде свою подпись и переписать кучу хешей. Абсолютно то же самое случится если кто-то перепишет блокчейн, что вполне возможно если он не основан на proof of work. И кажется все это более оправдано в текущей ситуации, потому что в обмен на 3-4 недели работы по реализации цифровой подписи, получаем все богатство инструментария для работы с БД. Инструменты для блокчейна до этого уровня дойдут лет через 5.
Для надежной репликации уже есть миллион решений и блокчейн новых не предлагает. Например CouchDB, она будет отлично реплицироваться и будет также append only (собственно это следствие отсутствия проблем с реализацией).
Для пущей надежности запишем туда же хеш предыдущей версии или же возьмем и сериализуем дерево Меркле.
Поздравляю. Вы изобрели блокчейн.
Ну не совсем, у вас тут нет именно «блоков», точнее один блок это один документ, но как я уже говорил выше — разбиение на блоки не обязательно, хотя и дает много полезностей именно на уровне более серьезной реализации.
Блокчейн совсем не обязательно что-то большое и сложное. Вот например тоже блокчейн.
Поздравляю. Вы изобрели блокчейн.
Да ладно вам, ничего я не изобретал, вы же не думаете, что я тут полемику развел и не представляю как оно внутри работает :) Я просто показал, что можно в рамках существующих БД добиться обнаружения злонамеренных искажений данных. А еще в нагрузку получить кучу специалистов, знакомых с технологией, кучу готовых инструментов и интеграцию со всеми средами разработки и языками. И кажется все это сильно перевешивает сомнительные перспективы интегрировать сторонний сервис, которому все равно нельзя доверять.
Ну протягивая подобные вещи в нативный SQL вы получите кучу неприятных моментов с репликацией.
В результате вы деградируете до чего-то близкого к noSQL. И это уже будет довольно похоже на решения на базе блокчейна.
А так… кто сказал что блокчейн должен храниться в отдельных файлах а не в субд? Кто сказал что блок не может состоять из одной записи?
В целом я так понимаю у нас спор скатывается в терминологический.
Приватными блокчейнами называют децентрализованные одноранговые (?) структуры хранения данных, использующие дерево хешей (или цепочку) для обеспечения целостности и используемые в рамках одной структуры или тем или иным образом идентифицированного и ограниченного круга лиц.
В результате вы деградируете до чего-то близкого к noSQL. И это уже будет довольно похоже на решения на базе блокчейна.
А так… кто сказал что блокчейн должен храниться в отдельных файлах а не в субд? Кто сказал что блок не может состоять из одной записи?
В целом я так понимаю у нас спор скатывается в терминологический.
Приватными блокчейнами называют децентрализованные одноранговые (?) структуры хранения данных, использующие дерево хешей (или цепочку) для обеспечения целостности и используемые в рамках одной структуры или тем или иным образом идентифицированного и ограниченного круга лиц.
Для начала выдаем пользователям пару публичный и приватный ключ.
Для защиты от подделки это совсем не нужно.
Вообще-то, чем больше итераций в алгоритме, тем хуже он работает и менее дружелюбен пользователям.
В этой статье дается ссылка на описание метода под условным названием «круговая порука». Чем больше пользователей, тем сложнее подделать запись какого-нибудь отдельного пользователя.
По указанному методу реализован алгоритм проекта, обсуждаемого в этой статье.
Единственный минус принципа «одна транзакция (или документ) — один блок» это быстрый рост объема блокчейна. Но данная проблема нивелируется при переходе к персональным блокчейнам, которые хранятся децентрализовано. При этом их неизменность обеспечивается методом ARB (круговая порука). Кстати, на этот метод подана патентная заявка US.
Консенсус нужен для защиты блокчейна от попыток внести неверные (фальсифицированные) данные со стороны его нод-участников. Данной опасности подвержен только публичный блокчейн со свободным доступом. Приватному блокчейну консенсус не нужен. «By design». Это для начала…
Предлагаемая схема решения на основе «all-round bail», к сожалению, имеет не просто «ряд ограничений», но «ряд фундаметальных ограничений», которые не позволяют получить релевантный результат на основе данной технологии. Это в завершение…
Предлагаемая схема решения на основе «all-round bail», к сожалению, имеет не просто «ряд ограничений», но «ряд фундаметальных ограничений», которые не позволяют получить релевантный результат на основе данной технологии. Это в завершение…
По вопросу необязательности консенсуса в частных блокчейнах прямо указано в статье. Перечитайте третий абзац второй части.
По второму вопросу для примера хотелось бы услышать хотя бы парочку «фундаментальных ограничений» из упомянутого ряда.
Смысл предлагаемого метода как раз заключается, чтобы не допустить «переписывание» частного блокчейна при отсутствии консенсуса. Скажем, клиентам банка, в котором будет внедрен частный блокчейн, требуются гораздо весомее аргументы, чем честные голубые глаза управляющего. Вспомните истории о забалансовых счетах со суммами с многими нулями.
По второму вопросу для примера хотелось бы услышать хотя бы парочку «фундаментальных ограничений» из упомянутого ряда.
Смысл предлагаемого метода как раз заключается, чтобы не допустить «переписывание» частного блокчейна при отсутствии консенсуса. Скажем, клиентам банка, в котором будет внедрен частный блокчейн, требуются гораздо весомее аргументы, чем честные голубые глаза управляющего. Вспомните истории о забалансовых счетах со суммами с многими нулями.
Вся «мякотка» второго абзаца второй части заключается во втором предложении этого абзаца. Это предложение, в свою очередь, делает полностью бессмысленным все последующие рассуждения о «кисельных берегах» приватного блокчейна. Клиентам банка блокчейн не нужен от слова совсем. Им нужны банковские услуги. А вот банкирам блокчейн нужен для минимизации издержек и накладных расходов. Буквально для того чтобы уволить всех операционисток и дармоедов из службы безопасности. Но если уволить дармоедов некому будет следить за «приватностью» приватного блокчейна и сисадмин Вася может запросто нарисовать туда пару «забалансовых» транзакций на сумму с многими нулями в свой кошелёк. Поэтому дармоедов увольнять всё же нельзя… А если им всё равно нужно платить, за то что они охраняют «приватность» блокчейна от Васи, то зачем вообще нужен такой приватный блокчейн? Смысл блокчейна заключается как раз в его публичности и в том что его защиту осуществляет сила толпы. А для этого толпу необходимо заинтересовать и дать ей стимул проявить свою силу.
Фундаментальность ограничений, упомянутых вами же, вы с лёгкостью сможете рассмотреть сами, если уберёте из понятия блокчейна принцип приватности. Совсем. Поскольку приватный блокчейн сам по-себе лишён смысла.
Фундаментальность ограничений, упомянутых вами же, вы с лёгкостью сможете рассмотреть сами, если уберёте из понятия блокчейна принцип приватности. Совсем. Поскольку приватный блокчейн сам по-себе лишён смысла.
Лично я не упоминал «фундаментальных» ограничений, это высказали Вы. Я лишь попросил привести пару примеров.
Для того, чтобы не кормить банковский планктон и уберечься от Васи был и разработан предложенный метод. Проверка неизменности блокчейна, например, банка переносится в публичное пространство. Уже есть внедренные решения, когда частные или приватные блокчейны привязываются к публичным, к тому же биткоину или эфириуму. Почитайте, скажем, про Exonum. Предлагаемый метод решает эту задачу иначе.
Частный блокчейн нужен не столько самому банку, сколько клиентам банка, дабы быть уверенными в невозможности возникновения забалансных счетов. Если продолжить примеры из банковской сферы, то следует вспомнить историю появления АСВ. Появление этого агенства реально успокоило клиентов банка, что даже в случае его банкротства они смогут вернуть свои вклады.
Банку будет выгодно внедрять блокчейн и делать его надежным в глазах клиентов.
Для того, чтобы не кормить банковский планктон и уберечься от Васи был и разработан предложенный метод. Проверка неизменности блокчейна, например, банка переносится в публичное пространство. Уже есть внедренные решения, когда частные или приватные блокчейны привязываются к публичным, к тому же биткоину или эфириуму. Почитайте, скажем, про Exonum. Предлагаемый метод решает эту задачу иначе.
Частный блокчейн нужен не столько самому банку, сколько клиентам банка, дабы быть уверенными в невозможности возникновения забалансных счетов. Если продолжить примеры из банковской сферы, то следует вспомнить историю появления АСВ. Появление этого агенства реально успокоило клиентов банка, что даже в случае его банкротства они смогут вернуть свои вклады.
Банку будет выгодно внедрять блокчейн и делать его надежным в глазах клиентов.
А кто помешает хорьку в DLT Trust подправить что-то в данных?
Другими словами, откуда возьмется доверие к DLT Trust?
Другими словами, откуда возьмется доверие к DLT Trust?
Данные не хранятся в DLT Trust, это лишь агрегатор, посредник. Его цель получить хэши от независимых блокчейнов и раздать им обратно результирующий хэш на определенный момент времени. Копии результирующих хэшей затем сохраняются в разных блокчейнах в виде, например, транзакций. В базе посредника сохраняется лишь информация о размещении результирующих хэшей в блокчейнах. Для удобства обслуживания запросов на проверку неизменности того или иного блока в любом блокчейне.
Конечно, в базе посредника может храниться и сам результирующий хэш, особой нагрузки это не создаст. Но главная особенность это тот же эффект, как в публичных блокчейнах. Любой узел может перепроверить корректность любого блока. Здесь же любой блокчейн может перепроверить результирующие хэши как в самом DLT Trust, так и в партнерских блокчейнах.
Как указывалось в статье, в принципе блокчейны могут обмениваться хэшами друг с другом напрямую, без посредника. Посредник в лице DLT Trust только упрощает взаимодействие, если число участников велико.
Конечно, в базе посредника может храниться и сам результирующий хэш, особой нагрузки это не создаст. Но главная особенность это тот же эффект, как в публичных блокчейнах. Любой узел может перепроверить корректность любого блока. Здесь же любой блокчейн может перепроверить результирующие хэши как в самом DLT Trust, так и в партнерских блокчейнах.
Как указывалось в статье, в принципе блокчейны могут обмениваться хэшами друг с другом напрямую, без посредника. Посредник в лице DLT Trust только упрощает взаимодействие, если число участников велико.
Спасибо.
Попробую развить свою мысль.
Есть три блокчейна, ими рулят Алиса, Боб и Ева, куда ж без неё.
Ева путем махинаций изменила несколько блоков в своем блокчейне, сейчас не важно как. Спеша закрепить успех, она выгружает хэши во внешний блокчейн. Владелец (оператор) DLT в доле и вносит в поток данных соответствующие изменения. Самому ему ничего, естественно, хранить не нужно.
Вопрос мой был — как Алиса и Боб могут доверять этому парню из DLT? Снова нужен механизм обеспечения доверия…
Это все немного поверхностно и сильно утрировано, но идея, думаю, понятна.
Попробую развить свою мысль.
Есть три блокчейна, ими рулят Алиса, Боб и Ева, куда ж без неё.
Ева путем махинаций изменила несколько блоков в своем блокчейне, сейчас не важно как. Спеша закрепить успех, она выгружает хэши во внешний блокчейн. Владелец (оператор) DLT в доле и вносит в поток данных соответствующие изменения. Самому ему ничего, естественно, хранить не нужно.
Вопрос мой был — как Алиса и Боб могут доверять этому парню из DLT? Снова нужен механизм обеспечения доверия…
Это все немного поверхностно и сильно утрировано, но идея, думаю, понятна.
Предложенный Вами сценарий невозможен, так как процесс привязан к вектору времени.
Для упрощения рассмотрения предположим, что Алиса, Боб и Ева формируют блоки своих цепочек с одинаковым периодом, в одни и те же моменты времени.
В момент времени Т-2 (Т это текущий момент времени) нашими героями были получены хэши блоков А-2, Б-2 и Е-2, которые они отправили парню в DLT Trust. Парень из принятых хэшей методом вычисления корня дерева Меркла получил результирующий хэш R-2. Этот хэш он сразу же разослал нашим героям, которые включили его в очередные свои блоки А-1, Б-1 и Е-1, сформированные в момент времени Т-1.
В момент времени Т Ева решила изменить свой блок Е-2. В своей цепочке она это может сделать очень просто. Но при всем желании помочь Еве, парень из DLT Trust уже ничего не сможет поменять в результирующем хэше R-2, который был уже разослан всем остальным участникам в момент времени Т-2 и был включен в следующие блоки всех блокчейнов в момент Т-1. Даже если Ева спохватилась бы в момент Т-1 или сразу после отсылки своего хэша Е-2, то все равно уже ничего изменить было бы нельзя, так как ни у нее, ни у парня из DLT Trust нет машины времени. Как только хэш Е-2 оказался включен в результирующий хэш R-2 уже ничего нельзя подменить.
Для упрощения рассмотрения предположим, что Алиса, Боб и Ева формируют блоки своих цепочек с одинаковым периодом, в одни и те же моменты времени.
В момент времени Т-2 (Т это текущий момент времени) нашими героями были получены хэши блоков А-2, Б-2 и Е-2, которые они отправили парню в DLT Trust. Парень из принятых хэшей методом вычисления корня дерева Меркла получил результирующий хэш R-2. Этот хэш он сразу же разослал нашим героям, которые включили его в очередные свои блоки А-1, Б-1 и Е-1, сформированные в момент времени Т-1.
В момент времени Т Ева решила изменить свой блок Е-2. В своей цепочке она это может сделать очень просто. Но при всем желании помочь Еве, парень из DLT Trust уже ничего не сможет поменять в результирующем хэше R-2, который был уже разослан всем остальным участникам в момент времени Т-2 и был включен в следующие блоки всех блокчейнов в момент Т-1. Даже если Ева спохватилась бы в момент Т-1 или сразу после отсылки своего хэша Е-2, то все равно уже ничего изменить было бы нельзя, так как ни у нее, ни у парня из DLT Trust нет машины времени. Как только хэш Е-2 оказался включен в результирующий хэш R-2 уже ничего нельзя подменить.
Про вектор времени очень интересное замечание. А кто обеспечит эталон этого времени? Это ещё одно (очередное) фундаментальное ограничение. Чем мерить будем? Скажу сразу, что всякие NTP заранее и изначально посылаются «на йуг»… Как и всевозможные DLT Trust. Каково решение данной проблемы?
А что делать с форками цепочки блоков? Совершенно нормально когда в сети есть несколько версий цепочки, различающиеся последними n блоками. В какой-то момент консенсус выберет одну из них, а остальные исчезнут.
То есть в момент времени T, может выясниться, что в T-2 существовало две версии блокчейна Евы (и это нормально) и «выиграла» не та, что была послана в DLT Trust.
1. Как DLT Trust обновит другие блокчейны?
2. Как DLT Trust отличит ситуация форка сети от злонамеренный действия Евы?
То есть в момент времени T, может выясниться, что в T-2 существовало две версии блокчейна Евы (и это нормально) и «выиграла» не та, что была послана в DLT Trust.
1. Как DLT Trust обновит другие блокчейны?
2. Как DLT Trust отличит ситуация форка сети от злонамеренный действия Евы?
Метод был разработан для повышения доверия к частным блокчейнам. В общем случае, в таких блокчейнах нет состязательности при формировании цепочки. Она там не нужна, мне сложно представить ситуацию, когда, например. в корпоративной информационной системе потребуется применение, скажем, PoW для достижения внутреннего консенсуса.
Тем не менее даже в случае использования внутреннего консенсуса блокчейн может участвовать во взаимном обмене хэшами через DLT Trust. Важно помнить, сам DLT Trust выступает как посредник, что вы прислали, то он и растиражировал. Поэтому выбор какой хэш отправить зависит только от самого блокчейна.
Так как режим работы асинхронный, то ничто не мешает отправлять в систему хэш блока, который не входит в последние n блоков, чья судьба пока не ясна. В таком случае возникнет определенная задержка, но принципиально ничего не изменится.
Тем не менее даже в случае использования внутреннего консенсуса блокчейн может участвовать во взаимном обмене хэшами через DLT Trust. Важно помнить, сам DLT Trust выступает как посредник, что вы прислали, то он и растиражировал. Поэтому выбор какой хэш отправить зависит только от самого блокчейна.
Так как режим работы асинхронный, то ничто не мешает отправлять в систему хэш блока, который не входит в последние n блоков, чья судьба пока не ясна. В таком случае возникнет определенная задержка, но принципиально ничего не изменится.
Если мы говорим о частном блокчейне (permissioned blockhain), то в нем должны участвовать только компоненты, которым можно доверять. Если в схему добавить DLT Trust, то нужно доверять DLT Trust, потому что от него приходят хеши, которые надо записать в свой блокчейн.
Это вы утверждаете, но почему я должен этому доверять?
Важно помнить, сам DLT Trust выступает как посредник, что вы прислали, то он и растиражировал.
Это вы утверждаете, но почему я должен этому доверять?
DLT Trust не является часть частного блокчейна. Информация, полученная от DLT Trust заносится в блокчейн средствами этого блокчейна.
Насчет доверия я пишу ниже
Насчет доверия я пишу ниже
Вот владею я блокчейном, и DLT Trust присылает мне хеш и предлагает этот хеш записать. Видимо мне этот хеш нужен для принятия каких-то очень важных решений, иначе я бы с DLT Trust не связывался. Но вот проблема — у меня нет никаких гарантий, что присланный хеш не является попыткой ввести меня в заблуждение. Если я стану сам проверять хеши, то мне не нужен DLT Trust, если не стану, то у меня нет никаких гарантий, кроме утверждения DLT Trust о том, что все ок.
А что если злобный хакер взломал DLT Trust и может по своему усмотрению посылать кому-надо какие угодно хеши?
Блокчейн совершает революцию в финансах как раз потому, что убирает «доверенных» участников и связанные с ними процессы с рынка. Вместе с этим исчезнут мириады посредников и регуляторов, которые затрудняют сделки и увеличивают стоимость. Примеры:
— Центробанки;
— Депозитарии, хранящие информацию о ценных бумагах;
— Биржи, гарантирующие исполнение обязательств;
— SWIFT, VISA и прочие
— Escrow сервисы
— и т.д.
Я не берусь ничего утверждать, но с моей колокольни кажется, что введение механизма вроде DLT Trust это шаг назад. Неизбежно затем индустрии понадобится специальный регулятор, который будет следить за тем, чтобы организации подобные DLT Trust не обманывали своих клиентов и вели себя «правильно» и мы вернемся к тому, с чего начинали.
Если я технически могу это сделать, то смысл мне работать с DLT Trust?
Я думаю, что предлагаемый механизм может быть полезен в виде open source библиотеки, которую организации могут использовать по своему усмотрению. DLT Trust как организация вызывает сомнения.
Повторю, DLT Trust никоим образом не проверяет корректность вычисления хэшей очередных блоков ни в одном из блокчейнов, которые обслуживает. Его первая функциональная задача: обеспечить взаимный обмен хешей. Ответственность за корректность присылаемых хэшей лежит блокчейне.
А что если злобный хакер взломал DLT Trust и может по своему усмотрению посылать кому-надо какие угодно хеши?
Доверие к кому-нибудь или к чему-нибудь в подавляющем большинстве случаев обычно формируется в два этапа. Априори некто считает DLT Trust достойным доверия. Свое мнение он может формировать за счет косвенных факторов, например, отзывы знакомых.
Блокчейн совершает революцию в финансах как раз потому, что убирает «доверенных» участников и связанные с ними процессы с рынка. Вместе с этим исчезнут мириады посредников и регуляторов, которые затрудняют сделки и увеличивают стоимость. Примеры:
— Центробанки;
— Депозитарии, хранящие информацию о ценных бумагах;
— Биржи, гарантирующие исполнение обязательств;
— SWIFT, VISA и прочие
— Escrow сервисы
— и т.д.
Я не берусь ничего утверждать, но с моей колокольни кажется, что введение механизма вроде DLT Trust это шаг назад. Неизбежно затем индустрии понадобится специальный регулятор, который будет следить за тем, чтобы организации подобные DLT Trust не обманывали своих клиентов и вели себя «правильно» и мы вернемся к тому, с чего начинали.
Любой легитимный пользователь, в том числе владелец частного блокчейна, имеет возможность перепроверить всю информацию, касающуюся его блокчейна.
Если я технически могу это сделать, то смысл мне работать с DLT Trust?
Я думаю, что предлагаемый механизм может быть полезен в виде open source библиотеки, которую организации могут использовать по своему усмотрению. DLT Trust как организация вызывает сомнения.
Ваш комментарий показал, что Вы не полностью поняли и смысл метода, и его механизм. Вполне вероятно, что я просто плохо объяснил это в статье.
Ваши вопросы можно разбить на 2 группы.
1. Нужен ли вообще обмен хэшами?
2. Почему обмен хэшами должен идти через DLT Trust?
Попробую ответить, хотя это я пытался сделать в самой статье.
1. Обмен хэшами дело добровольное. Речь идет о частных, приватных блокчейнах, а не о публичных, вроде биткоина или эфириума. В частном блокчейне, как правило, нет процесса консенсуса. Если даже он есть, то его достижение не обусловлено мощью доказательства как в публичных блокчейнах. Поэтому данные изолированного частного блокчейна могут быть модифицированы в любой момент времени и при этом обеспечена целостность цепочки. Такая ситуация не добавляет доверия к информации, записанной в блокчейн. Как известно, одной из важнейших характеристик блокчейна является гарантия неизменности ранее записанной информации. Ради этого все и затевалось.
У частного блокчейна есть лишь один способ показать свою надежность в глазах пользователей. Например, вкладчикам банка, если блокчейн принадлежит банку. Этот способ связан с передачей хэшей блоков в доверенную среду в глазах клиента. Сейчас уже существуют подобные решения, например, упоминавшееся в статье решение Exonum компании Bitfury. Его предназначение вроде бы ни у кого не вызывает сомнений.
Предлагаемый метод «круговой поруки» решает ту же задачу, но немного по другому. В нем нет привязки к публичному блокчейну. Доверие достигается за счет массового тиражирования результирующего хэша среди независимых частных блокчейнов. Клиент банка всегда может перепроверить честность блокчейна банка, запросив данные из нескольких независимых от этого банка блокчейнов. Владелец же блокчейна банка может перепроверить честность DLT Trust, перепроверив свои хэши в независимых блокчейнах.
2. Как я уже указывал, независимые блокчейны вполне могут обмениваться хэшами текущих блоков непосредственно друг с другом, без всяких посредников в лице DLT Trust. Алгоритм практически останется тем же. Усложнится только реализация такого обмена и реализация контроля.
Еще раз подчеркну, что речь идет о сервисе для частных блокчейнов.
Ваши вопросы можно разбить на 2 группы.
1. Нужен ли вообще обмен хэшами?
2. Почему обмен хэшами должен идти через DLT Trust?
Попробую ответить, хотя это я пытался сделать в самой статье.
1. Обмен хэшами дело добровольное. Речь идет о частных, приватных блокчейнах, а не о публичных, вроде биткоина или эфириума. В частном блокчейне, как правило, нет процесса консенсуса. Если даже он есть, то его достижение не обусловлено мощью доказательства как в публичных блокчейнах. Поэтому данные изолированного частного блокчейна могут быть модифицированы в любой момент времени и при этом обеспечена целостность цепочки. Такая ситуация не добавляет доверия к информации, записанной в блокчейн. Как известно, одной из важнейших характеристик блокчейна является гарантия неизменности ранее записанной информации. Ради этого все и затевалось.
У частного блокчейна есть лишь один способ показать свою надежность в глазах пользователей. Например, вкладчикам банка, если блокчейн принадлежит банку. Этот способ связан с передачей хэшей блоков в доверенную среду в глазах клиента. Сейчас уже существуют подобные решения, например, упоминавшееся в статье решение Exonum компании Bitfury. Его предназначение вроде бы ни у кого не вызывает сомнений.
Предлагаемый метод «круговой поруки» решает ту же задачу, но немного по другому. В нем нет привязки к публичному блокчейну. Доверие достигается за счет массового тиражирования результирующего хэша среди независимых частных блокчейнов. Клиент банка всегда может перепроверить честность блокчейна банка, запросив данные из нескольких независимых от этого банка блокчейнов. Владелец же блокчейна банка может перепроверить честность DLT Trust, перепроверив свои хэши в независимых блокчейнах.
2. Как я уже указывал, независимые блокчейны вполне могут обмениваться хэшами текущих блоков непосредственно друг с другом, без всяких посредников в лице DLT Trust. Алгоритм практически останется тем же. Усложнится только реализация такого обмена и реализация контроля.
Еще раз подчеркну, что речь идет о сервисе для частных блокчейнов.
Скорее не «не добавлять последние спорные блоки» а добавить хеши от ОБЕИХ цепочек. Простите, статью читал по диагонали, но основная идея у вас довольно банальная, так что если ошибся поправьте:
Кросс-хеши между разными цепочками фундаментально решают только одну задачу — дать уверенность что определенная информация уже существовала на тот или иной момент. Ни больше, но и не меньше. Смысл данного действия примерно такой же как в электронном документообороте добавление подписанного специальным сервисом таймштамп.
Наличие таких меток (кросс-хешей в блокчейне или таймштампов в документе) гарантируют что данные сущности (блоки, документы, транзакции). Ну будет у вас кросхеш цепочки которой больше нет (не выдержала консенуса), ну значит был форк который не поддержали, ну и ладно. Если протокол позволяет состязательность, значит ситуация нормальная.
При этом если оставлять только те блоки которые имеют окончательный консенсус (интересно как это решать если есть состязательность, ну да ладно), то мы теряем часть информации. Точнее получаем лишнюю задержку и большую неопределенность.
Кросс-хеши между разными цепочками фундаментально решают только одну задачу — дать уверенность что определенная информация уже существовала на тот или иной момент. Ни больше, но и не меньше. Смысл данного действия примерно такой же как в электронном документообороте добавление подписанного специальным сервисом таймштамп.
Наличие таких меток (кросс-хешей в блокчейне или таймштампов в документе) гарантируют что данные сущности (блоки, документы, транзакции). Ну будет у вас кросхеш цепочки которой больше нет (не выдержала консенуса), ну значит был форк который не поддержали, ну и ладно. Если протокол позволяет состязательность, значит ситуация нормальная.
При этом если оставлять только те блоки которые имеют окончательный консенсус (интересно как это решать если есть состязательность, ну да ладно), то мы теряем часть информации. Точнее получаем лишнюю задержку и большую неопределенность.
Фишка в том, что при создании блоков в разных блокчейнах, участвующих в этой системе, уже не требуется состязательный консенсус и, следовательно, не будет форков.
Для форков может быть много причин. Например нарушение связности приведет к дробелнию сети. Потом после восстановления они как-то договорятся, но что делать в промежутке? И нет, «раз они оба могут достучаться до кросс-блокчейнов значит связь есть» — не аргумент. Связь бывает и односторонней, и с очень большим пингом (мой курьер DHL) и много чего еще.
Ну или организационный форк… не уверен что кто-то такое предусматривает, но вспоминается случай из середины девяностых: в одной полугосударственной структуре одномоментно образовалось два совета директоров, два комплекта печатей и т.п. и оба считали себя единственными легитимными. У обоих кланов были свои юридические основания для этого и «свои» силовые структуры которые обеспечивали безопасность их «резиденции». Очень хорошо помню как мама (работала там в бухгалтерии) рассказывала в красках выражение лица тетки из отдела кадров (который был у них общим, его не поделили) когда ей на стол легли два комплекта приказов от разных кланов об увольнении соперников. Комментарий был примерно такой «ну и что мне с этим всем делать? А ведь так хочется выполнить их оба»… Собственно через год когда они всласть насепаратистились было принято решение на уровне кабмина и появилась третья власть которая так и сделала — уволила и тех и других.
После чего шел некий процесс слияния «блокчейнов» их приказов и распоряжений. Что-то отменяли, что-то утверждали, в общем и в целом каким-то образом «склеили».
Вполне себе ожидаемым будет поведение при котором узлы «лояльные» одной власти поддерживают их цепочку и игнорируют цепочку оппонентов. Ну а узлы которые «не определились» (например ретрансляторы, сетевые элементы) тупо рассылают всех кто имеет доступ к внутренней сети).
Ну или организационный форк… не уверен что кто-то такое предусматривает, но вспоминается случай из середины девяностых: в одной полугосударственной структуре одномоментно образовалось два совета директоров, два комплекта печатей и т.п. и оба считали себя единственными легитимными. У обоих кланов были свои юридические основания для этого и «свои» силовые структуры которые обеспечивали безопасность их «резиденции». Очень хорошо помню как мама (работала там в бухгалтерии) рассказывала в красках выражение лица тетки из отдела кадров (который был у них общим, его не поделили) когда ей на стол легли два комплекта приказов от разных кланов об увольнении соперников. Комментарий был примерно такой «ну и что мне с этим всем делать? А ведь так хочется выполнить их оба»… Собственно через год когда они всласть насепаратистились было принято решение на уровне кабмина и появилась третья власть которая так и сделала — уволила и тех и других.
После чего шел некий процесс слияния «блокчейнов» их приказов и распоряжений. Что-то отменяли, что-то утверждали, в общем и в целом каким-то образом «склеили».
Вполне себе ожидаемым будет поведение при котором узлы «лояльные» одной власти поддерживают их цепочку и игнорируют цепочку оппонентов. Ну а узлы которые «не определились» (например ретрансляторы, сетевые элементы) тупо рассылают всех кто имеет доступ к внутренней сети).
Да фиг с ней с Евой… Гораздо хуже, когда у Мэллори напару с её подругой Труди есть целый набор из N версий блокчейнов… И они манипулирует ими исходя из своих корыстных интресов.
И какую роль в этой схеме играет DLT Trust? Если его функции сводятся к роли Трента, то вся обсуждаемай схема является запутанным и усложнённым вариантом классического PKI. Чем функции DLT Trust отличаются от функций традиционного CA?
И какую роль в этой схеме играет DLT Trust? Если его функции сводятся к роли Трента, то вся обсуждаемай схема является запутанным и усложнённым вариантом классического PKI. Чем функции DLT Trust отличаются от функций традиционного CA?
Вероятно вы для вопроса нажали не на той ветке. Чуть выше вашего комментария дан ответ на этот вопрос. Повторю: Важно помнить, сам DLT Trust выступает как посредник, что вы прислали, то он и растиражировал. Поэтому выбор какой хэш отправить зависит только от самого блокчейна.
Я нажал на той ветке… Т.е. DLT Trust не выполняет никаких проверок и не несёт трастового функционала? По какой причине, в таком случае, приватные блокчейны могут доверять информации, которую он транслирует?
DLT Trust предназначен для выполнения той функциональности, которая заявлена. Не надо ее расширять своими предположениями.
Повторю, DLT Trust никоим образом не проверяет корректность вычисления хэшей очередных блоков ни в одном из блокчейнов, которые обслуживает. Его первая функциональная задача: обеспечить взаимный обмен хешей. Ответственность за корректность присылаемых хэшей лежит блокчейне.
Доверие к кому-нибудь или к чему-нибудь в подавляющем большинстве случаев обычно формируется в два этапа. Априори некто считает DLT Trust достойным доверия. Свое мнение он может формировать за счет косвенных факторов, например, отзывы знакомых.
На втором этапе, апостериори, некто может убедиться на собственном опыте, что DLT Trust достоин доверия. Отсюда вытекает вторая функциональная задача DLT Trust: предоставление механизма контроля. Любой легитимный пользователь, в том числе владелец частного блокчейна, имеет возможность перепроверить всю информацию, касающуюся его блокчейна. Другими словами, он всегда имеет возможность убедиться, что значение хэшей его блоков, переданные в DLT Trust, не были изменены перед рассылкой в другие блокчейны.
Повторю, DLT Trust никоим образом не проверяет корректность вычисления хэшей очередных блоков ни в одном из блокчейнов, которые обслуживает. Его первая функциональная задача: обеспечить взаимный обмен хешей. Ответственность за корректность присылаемых хэшей лежит блокчейне.
Доверие к кому-нибудь или к чему-нибудь в подавляющем большинстве случаев обычно формируется в два этапа. Априори некто считает DLT Trust достойным доверия. Свое мнение он может формировать за счет косвенных факторов, например, отзывы знакомых.
На втором этапе, апостериори, некто может убедиться на собственном опыте, что DLT Trust достоин доверия. Отсюда вытекает вторая функциональная задача DLT Trust: предоставление механизма контроля. Любой легитимный пользователь, в том числе владелец частного блокчейна, имеет возможность перепроверить всю информацию, касающуюся его блокчейна. Другими словами, он всегда имеет возможность убедиться, что значение хэшей его блоков, переданные в DLT Trust, не были изменены перед рассылкой в другие блокчейны.
Описанный метод на «круговой поруке» хорошо коррелирует с тем что описывал в Доказательство на лицо (PoF)
Условная схожесть в том, что также предлагается подход «услуга за услугу», которая оставляет реестры организаций там где они и должны быть, т.е. у них. И в то же время не позволяет вносить правки в реестр.
Условная схожесть в том, что также предлагается подход «услуга за услугу», которая оставляет реестры организаций там где они и должны быть, т.е. у них. И в то же время не позволяет вносить правки в реестр.
Спасибо за ссылку. Прочитал, интересное решение. Есть некоторые сомнения в его реализуемости в планетарном масштабе, но концептуально очень интересно.
Возможно я с ходу не уловил тонкостей Вашего решения, но в моем представлении блокчейн, как технология, совершенно не требует криптовалют. Впрочем, не буду продолжать развивать мысль о криптовалютах, чтобы не порождать в комментариях ненужный холивар.
Единственное с чем я не согласен в вашей идеи, это с попыткой создания «плоского» общества, по принципу P2P или теории шести (сейчас, с ростом численности человечества, уже говорят о семи) рукопожатий. Вся история человечества показывает стремление к иерархии. Вы верно подметили, что схожие процессы выстраивания иерархии идут в нынешних публичных блокчейнах.
Но внутри какой-нибудь группы социума, например, рабочем коллективе или в тех же соцсетях, Ваше решение отлично впишется, так как реально позволяет «оцифровать» такое понятие как авторитет.
Возможно я с ходу не уловил тонкостей Вашего решения, но в моем представлении блокчейн, как технология, совершенно не требует криптовалют. Впрочем, не буду продолжать развивать мысль о криптовалютах, чтобы не порождать в комментариях ненужный холивар.
Единственное с чем я не согласен в вашей идеи, это с попыткой создания «плоского» общества, по принципу P2P или теории шести (сейчас, с ростом численности человечества, уже говорят о семи) рукопожатий. Вся история человечества показывает стремление к иерархии. Вы верно подметили, что схожие процессы выстраивания иерархии идут в нынешних публичных блокчейнах.
Но внутри какой-нибудь группы социума, например, рабочем коллективе или в тех же соцсетях, Ваше решение отлично впишется, так как реально позволяет «оцифровать» такое понятие как авторитет.
Логика такая
1. Криптовалюты нужны чтобы были майнеры
2. Майнеры нужны чтобы реализовать PoW
3 PoW нужен для достижения консенсуса и масштабирования сети на тысячи узлов
Альтернатива это BFT алгоритмы, но у них есть проблемы с масштабируемостью, там иногда возникает n^2 запросов для подтверждения операции (n — число узлов).
1. Криптовалюты нужны чтобы были майнеры
2. Майнеры нужны чтобы реализовать PoW
3 PoW нужен для достижения консенсуса и масштабирования сети на тысячи узлов
Альтернатива это BFT алгоритмы, но у них есть проблемы с масштабируемостью, там иногда возникает n^2 запросов для подтверждения операции (n — число узлов).
Ваша логика работает верно для случая публичного блокчейна. В общем случае для частного блокчейна, например, банка совершенно не нужен процесс получения консенсуса. Между кем внутри частного блокчейна будет находиться согласие о выборе продолжения цепочки?
Ваша логика работает верно для случая публичного блокчейна.
Все верно, криптовалюты нужны только для PoW, если его нет, то и валюта не нужна.
В общем случае для частного блокчейна, например, банка совершенно не нужен процесс получения консенсуса.
Еще как нужно, иначе один узел считает что Вася деньги потратил, а другой нет.
Между кем внутри частного блокчейна будет находиться согласие о выборе продолжения цепочки?
Между узлами блокчейна, конечно. Механизмы достижения согласованного состояния могут быть разными. Мoжет быть PoW (и тогда нужна криптовалюта) может быть BFT (и тогда вопрос масштабирования на много узлов).
Еще как нужно, иначе один узел считает что Вася деньги потратил, а другой нет.
Весь вопрос в применении технологии блокчейна в информационной системе банка. Если ее построение предполагается по принципу, например, биткоина, то да, консенсус нужен. Впрочем, так как все узлы банка находятся административно в одних руках, то качество консенсуса может оказаться как в старом анекдоте позапрошлого века:
Купец нанимает бухгалтера.
Задает вопрос первому претенденту: Сколько будет 2х2? Претендент честно отвечает: 4. Купец его выгоняет. Следующий отвечает 3, тоже выгоняют и т.д.
Собеседование прошел кандидат, давший ответ: А сколько вам надо?
Поэтому, что есть консенсус в частном блокчейне, что его нет, доверия к такому консенсусу априори не может быть. Доверие возникнет, если копии значений хэшей блоков частного консенсуса будут иметь копии в независимых местах.
Впрочем, так как все узлы банка находятся административно в одних руках, то качество консенсуса может оказаться как в старом анекдоте позапрошлого века:
В этом случае вам хватит БД и она будет работать на порядок лучше чем блокчейн. Блокчейн имеет смысл как хранилище, которому несколько разных институтов (компаний, людей) могут доверять. А если как вы говорите, то блокчейн это просто тормозная, неудобная и дорогая в эксплуатации база данных.
Блокчейн имеет смысл как хранилище, которому несколько разных институтов (компаний, людей) могут доверять.
Именно так, я об этом и говорю, но применительно к частным блокчейнам. Если вы не отрицаете право на существование таких блокчейнов (а они уже существуют), то должны для себя определиться по какому критерию будете доверять им.
А если как вы говорите, то блокчейн это просто тормозная, неудобная и дорогая в эксплуатации база данных.
Я уже об этом упоминал в каком-то комментарии, что DLT Trust никак не влияет на внутреннюю работу частного блокчейна. Он лишь предоставляет каждому блокчейну одинаковый пакет данных. Не думаю, что одна дополнительная (и очень короткая, в текущей реализации 46 байт) запись в каждый блок сделает частный блокчейн тормозным, неудобным и дорогим.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Метод гарантирования доверия в блокчейнах