Частные блокчейны против Hashgraph, Ripple, BigChainDb

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

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

В итоге,

  1. Hashgraph, Ripple подходят для частной сети.
  2. Частная цепочка эквивалентна настройке распределенной базы данных

Здесь я делюсь своим мнением, чтобы узнать, чем частная цепочка лучше распределенной базы данных?


blockchain ethereum bigchaindb ripple hashgraph
person Minisha    schedule 29.01.2018    source источник

Ответы (3)


arrow_upward
5
arrow_downward

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

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

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

До недавнего времени BigchainDB не был BFT, и администратор базы данных (например, администратор базы данных MongoDB) мог вызвать хаос. Следующая версия будет сильно отличаться: это будет BFT, и у нее не будет единой точки управления (т.е. не будет больше глобального администратора или чего-то подобного).

person Troy McConaghy    schedule 29.01.2018
comment
1) Мы могли бы сделать базу данных неизменной, отозвав разрешение на запись и установив для пароля администратора значение какой-то тарабарщины. 2) Если есть частная цепочка с 3 узлами в ней, если два узла решили изменить данные, то данные уже будут свернуты. Однако я понимаю вашу точку зрения. Спасибо. - person Minisha; 30.01.2018
comment
1) Есть разные степени неизменности (невозможность что-либо изменить). Хотя отмена разрешений на запись и блокировка администратора может показаться достаточным, это не защитит жесткие диски от прямой перезаписи (возможно, с шумом). База данных должна обнаруживать такие вещи и восстанавливаться после них, если это возможно. Вообще говоря, чем больше копий, тем лучше, потому что потом их все труднее уничтожить. Инженерия неизменяемости - действительно увлекательная тема. - person Troy McConaghy; 31.01.2018
comment
2) Как упоминалось в предыдущем комментарии, чем больше копий, тем более неизменными становятся данные. Византийские отказоустойчивые системы могут обрабатывать от 1/3 до 1/2 узлов, выходящих из строя (в зависимости от используемого алгоритма консенсуса). Некоторые просто остановятся, если обнаружат, что этот порог превышен, чтобы предотвратить распространение любого ущерба на хорошие узлы. - person Troy McConaghy; 31.01.2018

arrow_upward
1
arrow_downward

В большинстве реализаций БД вы: а) знаете узлы и б) доверяете узлам.

В разрешенном DLT вы: а) знаете узлы, но б) не доверяете узлам.

В неразрешенном DLT вы: а) не знаете узлы и б) не доверяете узлам.

Это спектр того, что вы пытаетесь достичь с помощью DLT. Например, в CULedger используется хешграф, потому что узлы знают друг друга и соглашаются взаимодействовать, но они не обязательно доверяют друг другу в том смысле, что их интересы могут не совпадать.

Чтобы быть ясным, сейчас hashgraph - это слой консенсуса. Есть множество функций, которые все еще необходимо отсортировать, прежде чем он будет готов для несанкционированной реализации: выдача / распределение долей, управление узлом (включая повторное подключение узла), управление пользователем / учетной записью и т. Д. "безопасный" как приложение, которое вы создаете на его основе. Я заключил слово «безопасный» в кавычки только потому, что понимаю, что это означает разные вещи для разных людей. Сам уровень консенсуса криптографически надежен ... это просто вопрос того, как вы сообщаете и потребляете транзакции (которые представляют собой просто массивы байтов).

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

Кстати, отличный вопрос.

person Ken Anderson    schedule 01.02.2018
comment
В разрешенной / неразрешенной сети мы должны доверять 1/3 узлов. - person Minisha; 14.02.2018

arrow_upward
-1
arrow_downward

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

person Gokul Alex    schedule 19.02.2018