Pull to refresh

Comments 61

Да, а ещё, если у вас будет не одноразовый сессионный ключ, а привязанный к вашей душе приватник, будет чудесный побочный эффект: вас с вашим персональным ключом теперь можно будет деанонимизировать везде, в каких магазинах что покупаете, в какое кино ходите, какое порно смотрите, какие новости читаете. Так что извольте, лучше не надо таких новшеств.
Это зависит от реализации работы с ключами. Есть варианты сделать как «KYC» так и полную анонимность для одной и той же пары ключей, да и вовсе обойтись одной парой ключей только на стороне сервера.
В том-то и дело, что если мы делаем анонимность, то пропадает изначальный смысл, ради чего мы городили весь этот огород. Если Боб не может деанонимизировать ключи Алисы и Евы, то для него нет разницы между ними, и Ева может спокойно проводить MiM атаку, по крайней мере, если сессионные ключи по-прежнему будут генерироваться с помощью Диффи-Хеллмана.
Мы делаем публичный кейчэин на основе блокчеина. А уж как его применять — зависит от сервиса. Можно как обычный ssl, можно как ДХ с KYC, можно ДХ с предварительным обменом ключей. Главное что мы имеем возможность обменяться через блокчеин с кем угодно верифицированным пабликом, или производным пабликом от публичного как в биткоине. Это дает гибкую, но связную систему с широкими возможностями.

Есть и такой вариант, что для особых случаев возможно установить сессию через транзакцию блокчеина — там куча возможностей открывается для анонимности, ограниченной анонимности и ее отсутствия.
Ну то есть, ваша позиция такая:
1. У нас есть проблема, для решения которой вы предложили использовать блокчейн
2. Решение на блокчейне либо имеет неприемлемый побочный эффект, либо не решает проблему.
3. А ну и фиг с ним, зато у нас получилась гибкая система с широкими возможностями, а где надо посекьюрнее, так там ещё пару уровней сверху наворотим.
Ок, спасибо, понятно :)
2. Решение на блокчейне либо имеет неприемлемый побочный эффект, либо не решает проблему.


Решает проблему рисков централизованного хранения всех сертификатов. Рисков там не мало мягко говоря. Остальное там как минимум не хуже чем сейчас.

«пару уровней сверху наворотим. „

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

Учитывая все накладные расходы на внедрение, для того, чтобы это имело шансы на жизнь, оно должно быть не «не хуже», а многократно лучше в ряде ключевых моментов.
А в чём отличие от разворачивания самому себе центра сертификации?

Браузер не поверит рутовому сертификату, потому, что я то ли боб, то ли ева?

Ну так в блокчейне тоже не ясно, кто ножу поднял.

Поясните, пожалуйста.
А в чём отличие от разворачивания самому себе центра сертификации?


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

Браузер не поверит рутовому сертификату, потому, что я то ли боб, то ли ева?


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

Ну так в блокчейне тоже не ясно, кто ножу поднял.

Да это и не важно. В блокчеине ясно точно, что данные внесены в него строго с соблюдением консенсуса. Перепроверка осуществляется по хэшу. Чем больше нод предоставит аналогичный хэш, те «валиднее» данные.

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

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

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

Да гораздо больше мягко говоря. Опроси клиент хэш дерева с количества нод больше 1-3-10-50, то вероятность атаки снижается значительно.
Скачал и опрашиваешь преиодически n количество случайных нод на предмет целостности по базы по хэшу.

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

Все таки поправка. К каналу связи между машиной и нодой. Когда рут под контролем, считается что ничего не спасет. Но даже тут, замечу, с помощью криптотехнологии и бч есть очень стабильное решение на оснвове дополнительного железа (цена вопроса 50$). Напишу про этот кейс в отдельной статье.

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

И поэтому смысла менять шило на мыло нет никакого.

Ну всевозможные аргументы я изложил, дальше каждый сам решает)
К каналу связи между машиной и нодой.

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

А как он это узнает? Мы говорим ведь о защите произвольного https-сеанса, а не о логине зарегистрированного пользователя. Т.е. в общем случае нет разницы, Боб с Алисой знакомы, или общаются в первый раз в жизни.
Потому что в блокчейне лежит ключ, на котором написано «Алиса» и каждый может его найти и убедиться в том, что его не подменили. Впрочем, я не совсем понимаю, что означает «анонимность» в приложении к HTTPS, когда мы точно знаем имя сервера и хотим убедиться, что это именно он.
Потому что в блокчейне лежит ключ, на котором написано «Алиса» и каждый может его найти и убедиться в том, что его не подменили

Ну тогда мы можем и организовать службу трекинга, которая будет следить, на какие сайты заходит пользователь с ключом «Алиса». А если не будет никакой верификации, и каждый человек сможет произвольно создавать ключи в блокчейне с любой информацией, то тогда чем это отличается с точки зрения безопасности от системы с генерацией одноразовых сессионных ключей на лету?
На мой взгляд, в статье предлагается решение проблемы децентрализованной верификации сайтов, а не пользователей. Верификация пользователей, конечно, тоже возможна, но без деанонимизации её смысл мне непонятен. Тут уже ключ становится важнее приписанной к нему информации, т.к. Алис может быть много, и именно ключ позволяет найти среди них нужную.
Я наоборот, из статьи понял, что речь идет именно о пользовательских ключах. Сайты-то и сейчас вполне себе надёжно верифицированы, чтобы подменить сайт, нужно либо предварительно подсадить пользователю сторонний корневой сертификат, которым будет подписан фальшивый сертификат сайта, либо рассчитывать, что пользователь будет игнорировать предупреждения. Примерно такие же способы фальсификации могут использоваться и в случае блокчейна.
Есть ещё вероятность того, что центр сертификации по «просьбе» спецслужб выпустит поддельный сертификат или его кто-нибудь хакнет.
Ну, может. А может быть, кто-то вставит закладку в сервис, который валидацию сертификатов из публичного блокчейна осуществляет. От этого ведь никто не застрахован.
Можно иметь несколько ключей, тогда не получится связать того, кто смотрит порно, с тем, кто читает новости. По крайней мере, это будет не проще, чем сейчас.
Первое что пришло мне в голову после прочтения данной статьи:
  1. Сколько нужно будет ждать, пока пройдёт «регистрация» сессионного ключа и вызываемая сторона начнёт мне доверять (блок с моим ключём попадёт в блокчейн и синхронизируется между нодами)? Сможет ли он хоть как-то конкурировать с HTTPS по скорости работы и удобству?
  2. Как будет осуществляться безопасное взаимодействие до blockchain-нод? Как будет осуществляться первичный поиск хостов и т.д.?
  3. Если блокчейн будет использоваться в том числе и для хранения отпечатков сессионных ключей, то не окажется ли что при активном использовании, сопоставимым с текущими объёмами https трафика, размер блокчейна начнёт превышать возможности его хранения на каждой из машин, участников блокчейна?
  4. Кто будет оплачивать содержание всей этой инфрастуктуры, разработки ПО, рекламу
    и т.д.? По крайней мере до момента достижения критической массы пользователей, когда на данный протокол обратят внимание крупные компании.
1. Уже есть проекты которые за 3-10 секунд делают запись в блокчейне доступной любому желающему. Как правило, больше 10 подтверждений блока с транзакцией говорит о том, запись внесена корректно и все нормально. Если блок генерится раз в три секунды (есть работающие в продакшне решения), то уже через полминуты можно запросить с 20 различных нод-подписчиков данные по транзе и убедиться все ли в порядке.

2. Видимо это придется раскрыть в отдельной статье. Оказалось неочевидно из текущей. Вкратце. Есть два способа.

Первый — как и сейчас в https — прошитый в браузер адресс публичного «удостоверяющего центра» (по сути одна из нод, которую например крупный поисковик решил сделать публичной для удобства). Этот способ сопоставим по безопасности с текущей реализацией https.

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

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

4. Мне сложно сказать так сразу. Есть некоторые, не до конца оформленные мысли по этому поводу, но вряд ли они в один комент уместятся.
Спасибо за ответ.

за 3-10 секунд делают запись в блокчейне доступной любому желающему

Возможно для тех, кому приватность действительно важна, вроде тех, кто сейчас использует TOR, это подойдёт, но для массового пользователя выглядит жутко неудобно (особенно в реалиях нестабильного/мобильного интернета).

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

Первый — как и сейчас в https — прошитый в браузер адресс публичного «удостоверяющего центра» (по сути одна из нод, которую например крупный поисковик решил сделать публичной для удобства). Этот способ сопоставим по безопасности с текущей реализацией https.

Получается что в этом случае мы получаем примерно те же векторы атак, что и с https, только с повышенной централизацией, т.к. почти наверняка получим примерно ту же ситуацию, что и с DNS сервисами, где 2-3 крупных игрока обслуживают большую часть пользовательского трафика — на мой взгляд это может быть даже хуже того, что мы сейчас имеем с публичными CA.
Возможно я что-то не понимаю, так что буду рад почитать подробнее, когда будет отдельная статья.

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

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


Буду еще на эту тему писать. Там вопросы скорости как раз таки не особо остро стоят. Система вполне масштабируема. Юзеру нужно всего лишь по определенному ключу получить паблик, чтоб удостовериться что он «нормальный». Далее две стороны генерируют сессию по дифи-хелману. Это не медленнее чем установление сессии в вотсапе. Чувствую, сумбурно получается объяснение. Разложу по полочкам в следующих статьях.
В общем виде архитектура очень простая (сразу замечу, это не скрытая реклама и т.п, а просто концепт. Аналогов такой системы мне не известно).
Эй, а как же namecoin?

POW консенсус имеет некоторое очарование, но себя изжил. <...> Консенсус может быть и без электричества (не буквально конечно): POS, DPOS, и пр.
Консенсус, действительно, может быть без электричества. Однако ни POS, ни DPOS — не обеспечивают защиту от Sybil Attack, что бы там их изобретатели и популяризаторы не заявляли. Полноценный алгоритм консенсуса должен (просто обязан) в процессе своей работы необратимо расходовать некий ресурс. POW этому требованию удовлетворяет.
namecoin

Я подозревал, что не первый это придумал) Посмотрю, что у них там реализовано.

«Полноценный алгоритм консенсуса должен (просто обязан) в процессе своей работы необратимо расходовать некий ресурс.»


В идеале да. Мне так видится концепт цифрового золота и будет содержать в себе POW компонент для обеспечения свойства некоего «благородства» (по аналогии с химией) вложенных ресурсов.

Как ресурс можно рассматривать репутацию ноды или выраженное ей доверие. Понимаю, это спорно.

Однако в реальных системах придется идти на некий компромисс между математичской красотой POW и практической осуществимости иных вариантов.
Проблема систем с репутацией в том, что репутация — величина не скалярная. Репутация — это свойство отношения двух субъектов. В системе из N субъектов можно говорить об N2 различных репутаций (и это если не брать в расчет, что каждый i-й субъект может поддерживать Mi независимых identities).
UFO just landed and posted this here
как вариант существующие центры сертификации поднимают ноды и объединяются в блокчейн
браузер как и прежде знает сертификаты центров, но проверяет их у других центров тоже(корневые) и если один центр начинает шалить, то консенсус его банит и делит обслуживание его сертификатов между собой

Для решения части проблем с сертификатами придумали и уже внедрили публичные централизованные логи сертификатов — https://www.ietf.org/rfc/rfc6962.txt
https://en.wikipedia.org/wiki/Certificate_Transparency
https://www.certificate-transparency.org/
nmk2002 29 октября 2015 в 18:51 Обзор Certificate Transparency https://habr.com/ru/post/269729/


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

Списки существующих логов — http://www.certificate-transparency.org/known-logs
https://www.gstatic.com/ct/log_list/log_list.json
провайдеры логов — Google Cloudflare DigiCert Symantec Certly.io Izenpe WoSign Venafi CNNIC StartCom Sectigo


Неизменность уже сделана по аналогии с блокчейном


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

Зато они не зависят ни от каких майнеров-добровольцев, не заставляют их хранить десятки ТБ данных (у гугла уже под 4 млрд записей в логе) в множестве копий и не платят за майнинг. Провайдеры логов подписывают заявки на добавление в лог:


При добавлении сертификата в лог, в ответ возвращается подписанный штамп времени сертификата. Он является как бы обещанием лога включить сертификат в лог в течение фиксированного времени. При установлении TLS соединения веб-сервер должен вместе с сертификатом предоставить клиенту штамп времени от одного или нескольких логов. Браузер клиента, в свою очередь, не должен принимать сертификат, если действующий штамп времени отсутствует.

Мониторингом лога занимаются наблюдатели (Certificate monitor). Это такие сервера, которые отслеживают каждую новую запись в логе и сверяют новый хэш корня дерева Меркла со своими расчетами.…
Еще одна роль в Certificate Transparency – аудитор (Certificate auditor). Он берет частичную информацию о логе и проверяет, что эта информация соответствует другой имеющейся частичной информации, то есть убеждается в правильном поведении лога и его криптографической последовательности. Вторая задача аудитора — убедиться, что конкретный сертификат появился в логе.

В итоге, когда браузеры не будут принимать сертификаты, информация о которых отсутствует в логах, выпустить незаметно сертификат для чужого домена будет затруднительно.… С начала 2015 года браузер Chrome требует поддержку CT для EV-сертификатов.

firefox: https://wiki.mozilla.org/PKI:CT "With help from the Google CT team, we are currently planning to add code to Firefox and/or NSS that will check for CT information in a TLS handshake. We will create preferences that allow the user to apply these checks to TLS handshakes (either all or a subset), but these preferences will be off by default."


https://security.stackexchange.com/questions/178418/what-is-the-status-of-certificate-transparency


Starting in April 2018, Google Chrome plans to start enforcing the use of Certificate Transparency in all newly issued certificates by refusing to treat them as valid unless they're included in at least two distinct, qualified Certificate Transparency logs.
UFO just landed and posted this here
Здесь же вызнаетекто, вроде, ради подтверждения неизменности некоторой публичной информации, для чего он и был задуман, не?
Большинство пользователей не будет разворачивать свою ноду для подтверждения, а будут использовать какую-нибудь публичную, которой доверяют. А так как они доверяют ноде, то блокчейн там или не блокчейн уже не важно — чистый маркетинг.
Большинство — да (и для него такая возможность учтена), но это не значит, что всех асболютно надо под большинство усреднять.
Или значит? Мне видится настораживающим такой подход.
В моём понимании блокчейн используется для того, чтобы преодолеть кризис доверия. Т.е. при частном недоверии участников, само большинство считается вполне честным, не сговорившимся. Результат работы блокчейна и есть тот, с которым согласно большинство. Фактически ответственность с какого-то конкретного участника «размазывается» по всем, по меньшей мере по большинству.
Я вижу аналогию с «усреднением под большинство» в самом блокчейне.
«усреднением под большинство»

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

Грубо говоря: «мы тут все друг другу доверяем, но ты, если не доверяешь — ставь ноду и давай в консенсус.» И это улучшит в итоге общий уровень доверия
Блокчейн даёт возможность создать свою ноду тем, кто этого хочет, а для остальных — выбрать ту, которой они доверяют больше. Тот факт, что владельцы разных узлов, имеющие различные интересы, соглашаются с достоверностью блокчейна, значительно повышает доверие к нему.
Блокчеин решает только одну единственную проблему double-spend и всё.
Остальной хайп и попытки развести на деньги. При этом стараются не озвучивать стоимость владения сетью. Почему все поголовно должны метнутся бесплатно хранить гигабайты мусора на своих серверах?
Блокчейн сам по себе это только подтверждение целостности информации. Сама информация может быть абсолютно любой, в том совершенно не связанной с деньгами. Нет необходимости всем хранить всю цепочку — достаточно наличия некоторого количества независимых узлов.
Контрольная сумма и цифровая подпись ничуть не хуже подтверждают целостность информации и вам для этого вообще не нужна сеть.
Нужна — ибо подтверждает что контрольная сумма была расчитана в соответствии с прозрачным механизмом консенсуса а не как-то иначе.
Не понял утверждения. Контрольная сумма отвечает только за целостность, а за консенсус подписи участников.
Упс, извиняюсь. Я слегка не туда зарулил. Перефразирую. Контрольная сумма позволяет проверить целостность данных, но они должны быть в наличии у вас. А если нет? Если есть только кусок и надо быстро? Тогда поможет что-то типа дерева меркла или цепочки хэшей. Тут сеть имеет значение как и количество независимых нод.
Нафига козе баян. Есть torrent-ы и копии у всех заинтересованных участников плюс можно отдавать ссылки любым заинтересованным сторонам.
Если вам надо подписать несколько терабайт видео, то вычисляете хэш этого безобразия и подписываете его и по email или на флешке или вообще в qr код вставляете и на A4 печатаете и в сейф.
Ну я в статье размышляю над рил-тайм шифрованием в интернете и с т.з. безопасности в том числе. В таком ключе и комментирую.
UFO just landed and posted this here
куда можно только дописывать в конец.

Возможно но не обязательно. Уже есть реализации консенсусной бд без применения бч.

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

Неизменность и доверие строится на механизме консенсуса. К большинству это имеет опосредованное отношение, хотя зависит от механизма консенсуса. Это же основы бч)

А для валидации данных достаточно иметь копию дерева меркла бч на каждом устройстве. Весь бч копировать вовсе необязательно.
Наш тренер просто зверюга (с)
Ну армия вайтишников пополняется молодыми дарованиями, которые пробуют использовать разные технологии. Со временем заматереют и будут глобально понимать архитектуру и понимать что часть технологий не применима ни целиком ни в частности. Часть технологий являются плодом больного воображения жадного маркетолога. Пусть пробуют. Возможно появится решение для «множества пользователей» где применении подобных технологий будет уместно.
UFO just landed and posted this here
Насколько мне известно, другие сферы, где блокчейн применим иначе, чем костыль, прикрученый к бамперу, отсутствуют.

С этого момента cтатья пошла по звезде :))) Получилась очередная идея как использовать блокчейн как распределенную БД. Спасибо, но не нужно этого делать.

Блокчеин — это распределенная бд в принципе. Я даже и не знаю, чем это еще может быть :)
А вот вопросам безопасности распределенность как раз не помешала бы.

Вот тут пытался описать в чем настоящие преимущества блокчейна и какое использование считать правильным: https://habr.com/ru/post/342802/

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

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

В случае же публичного кейчена владелец ноды сам является источником риска и конфликт интересов в иной плоскости.

А так да, мне нравится ваша точка зрения на бч. Но как дополняющая имеющиеся, но не исключающая.

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

На мой взгляд конкурентное преимущество бч только одно — обеспечение среды в которой решен вопрос доверия к данным из базы. В остальном он дороже, медленнее, сложнее, и во всех смыслах хуже чем обычная бд.
Sign up to leave a comment.

Articles