Частные блокчейны против хэшграфа, Ripple, BigChainDb
Я исследовал различные блокчейны для некоторых случаев использования. В конце концов, я пришел к выводу, что установка приватной блокчейна эквивалентна распределенной базе данных с такими понятиями блокчейна, как неизменяемость и цифровые подписи. Например: Bigchaindb. (Ну, если нам нужна функция умного контракта, распределенная база данных может не работать)
Теоретически алгоритм согласования хеш-графа не выглядит достаточно безопасным для публичной цепочки. Похоже, близкая альтернативная версия Ripple.
В итоге,
- Hashgraph, Ripple костюмы для частной сети.
- Частная цепочка эквивалентна настройке распределенной базы данных
Здесь я делюсь своими взглядами, чтобы узнать, чем приватная сеть лучше распределенной базы данных?
3 ответа
Большинство существующих в настоящее время распределенных баз данных являются отказоустойчивыми (поэтому они продолжают работать, если несколько узлов выходят из строя из множества), но не являются отказоустойчивыми в Византии (BFT), т.е. они не могут обрабатывать произвольные отказы. Большинство блокчейнов являются BFT, поэтому даже если вы не доверяете некоторым узлам, вы можете доверять всей системе.
Большинство распределенных баз данных позволяют изменять или удалять данные. (Здесь есть несколько интересных исключений, но я отвлекся.) Большинство блокчейнов этого не делают.
Большинство распределенных баз данных имеют центрального администратора, который может делать практически все, включая изменение данных, удаление данных, удаление целых таблиц / коллекций или удаление всей базы данных. Большинство блокчейнов не имеют единой точки контроля, подобной этой.
До недавнего времени BigchainDB не был BFT, и администратор базы данных (например, администратор базы данных MongoDB) мог вызвать хаос. Следующая версия будет сильно отличаться: это будет BFT, и у нее не будет единой точки контроля (т.е. больше не будет глобального администратора или чего-то подобного).
В большинстве реализаций БД вы: а) знаете узлы и б) доверяете узлам.
В разрешенном DLT вы: а) знаете узлы, но б) не доверяете узлам.
В недопустимом DLT вы: а) не знаете узлов и б) не доверяете узлам.
Это спектр того, что вы пытаетесь достичь с помощью DLT. Например, в CULedger хеш-граф используется потому, что узлы знают друг друга и соглашаются участвовать, но они не обязательно доверяют друг другу в том смысле, что их интересы могут быть не полностью согласованы.
Чтобы быть ясным, хэшграф является консенсусным слоем прямо сейчас. Существует множество функций, которые все еще необходимо отсортировать, прежде чем они будут готовы к не разрешенной реализации: выдача / распределение ставок, mgt узла (включая повторное соединение узла), mgt пользователя / аккаунта и т. Д. В качестве консенсусного уровня хеш-график "безопасный" как приложение, которое вы создаете поверх него. Я помещаю "безопасный" в кавычки только потому, что понимаю, что это означает разные вещи для разных людей. Слой консенсуса сам по себе криптографически обоснован... это просто вопрос того, как вы сообщаете и используете транзакции (которые являются просто байтовыми массивами).
Чтобы продвинуться дальше... не могли бы вы реализовать кластер Cassandra с распределенными узлами и разрешениями, позволяющими узлам играть друг с другом, не доверяя друг другу? Может быть. Я признаю, что не знаю, есть ли поддержка ненадежных распределенных узлов, но я знаю, что большинство DLT были созданы с этой целью.
Отличный вопрос, кстати.
Определяющими признаками консенсуса в отношении хэш-графа являются виртуальное голосование, упорядочение транзакций и быстрота перехода от протокола к сплетне. Это помогает хэш-графу достичь состояния возможного асинхронного BFT в хронотопической архитектуре. Если мы добавим к этим свойствам дополнительную криптографическую строгость и целостность, это будет быстрый, безопасный и самоорганизованный открытый распределенный регистр графов с уникальными свойствами.