Предложенный Вами сценарий невозможен, так как процесс привязан к вектору времени.
Для упрощения рассмотрения предположим, что Алиса, Боб и Ева формируют блоки своих цепочек с одинаковым периодом, в одни и те же моменты времени.
В момент времени Т-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 уже ничего нельзя подменить.
Данные не хранятся в DLT Trust, это лишь агрегатор, посредник. Его цель получить хэши от независимых блокчейнов и раздать им обратно результирующий хэш на определенный момент времени. Копии результирующих хэшей затем сохраняются в разных блокчейнах в виде, например, транзакций. В базе посредника сохраняется лишь информация о размещении результирующих хэшей в блокчейнах. Для удобства обслуживания запросов на проверку неизменности того или иного блока в любом блокчейне.
Конечно, в базе посредника может храниться и сам результирующий хэш, особой нагрузки это не создаст. Но главная особенность это тот же эффект, как в публичных блокчейнах. Любой узел может перепроверить корректность любого блока. Здесь же любой блокчейн может перепроверить результирующие хэши как в самом DLT Trust, так и в партнерских блокчейнах.
Как указывалось в статье, в принципе блокчейны могут обмениваться хэшами друг с другом напрямую, без посредника. Посредник в лице DLT Trust только упрощает взаимодействие, если число участников велико.
Лично я не упоминал «фундаментальных» ограничений, это высказали Вы. Я лишь попросил привести пару примеров.
Для того, чтобы не кормить банковский планктон и уберечься от Васи был и разработан предложенный метод. Проверка неизменности блокчейна, например, банка переносится в публичное пространство. Уже есть внедренные решения, когда частные или приватные блокчейны привязываются к публичным, к тому же биткоину или эфириуму. Почитайте, скажем, про Exonum. Предлагаемый метод решает эту задачу иначе.
Частный блокчейн нужен не столько самому банку, сколько клиентам банка, дабы быть уверенными в невозможности возникновения забалансных счетов. Если продолжить примеры из банковской сферы, то следует вспомнить историю появления АСВ. Появление этого агенства реально успокоило клиентов банка, что даже в случае его банкротства они смогут вернуть свои вклады.
Банку будет выгодно внедрять блокчейн и делать его надежным в глазах клиентов.
По вопросу необязательности консенсуса в частных блокчейнах прямо указано в статье. Перечитайте третий абзац второй части.
По второму вопросу для примера хотелось бы услышать хотя бы парочку «фундаментальных ограничений» из упомянутого ряда.
Смысл предлагаемого метода как раз заключается, чтобы не допустить «переписывание» частного блокчейна при отсутствии консенсуса. Скажем, клиентам банка, в котором будет внедрен частный блокчейн, требуются гораздо весомее аргументы, чем честные голубые глаза управляющего. Вспомните истории о забалансовых счетах со суммами с многими нулями.
Эмиссия монет в биткоине это тоже транзакция, которая, по сути дела, также требует подтверждения.
Повторюсь, предлагаемый метод ориентирован на частные блокчейны, в которых нет особого смысла развивать внутренний консенсус.
Поэтому я корректно и написал, что чаще всего полные узлы поднимают майнеры. Но не утверждал, что каждый владелец полного узла является майнером.
Большинство пользователей предпочитают легкие или онлайн кошельки, так как процесс первичной синхронизации полного узла слишком долог. Думаю, это отпугивает многих.
Впрочем, это не имеет принципиального значения к теме, поднятой в данной статье.
Спасибо за ссылки. По последним данным насчитывается более 17 млн кошельков в сети биткоина. Даже если учесть, что пользователь может иметь неограниченное число кошельков, то 9 тыс. полных узлов теряются на фоне остальных пользователей.
Интересно, есть ли статистика по числу майнеров? Тогда можно было бы посмотреть корреляцию с числом полных узлов.
Дополню свой предыдущий комментарий. Уточнил на blockchain.info, текущий размер блокчейна биткоина превышает 133 Гб, не считая индексов. У меня нет статистических данных, но с высокой степенью вероятности предположу, держателями большинства полных узлов являются владельцы майнерских ферм, входящих в тот или иной пул. Мне как-то сложно представить множество обычных пользователей, которые ради поддержки своего кошелька будут поднимать полный узел.
Я с вами согласен, и в статье, в самом начале, об этом говорится.
Подчеркну, предлагаемый метод ориентирован не столько на публичные блокчейны криптовалют, сколько на частные блокчейны, которые уже сейчас начинают внедряться в компаниях и госструктурах.
Вы упомянули, что блокчейн это частный случай давно известных распределенных реестров. Согласен, но вот вопрос: как давно известных? У меня сложилось впечатление, что этот термин попал в обиход уже после публикации концепции биткоинов в 2008 году.
Попытка поиска в Гугле ранних упоминаний о Distributed Ledger не увенчалась успехом. основная масса ранних источников датируется 2012-2013 годами. Активно этот термин начинается употребляться в 2015-2016 годах. Но не настаиваю, возможно, плохо искал.
Насчет вагона с сахаром я погорячился. Это несколько неудачный пример. Но вот пример, который уже давно функционирует и имеет много признаков «настоящего» смарт-контракта. Я имею ввиду покупку товара на Алиэкспрессе. Выбрав товар, мы его оплачиваем, деньги поступают на аккаунт продавца, но пока ему недоступны. Средства разблокируются либо спустя определенное число дней после отправки товара, либо после подтверждения покупателем получение товара и удовлетворенностью его качеством. Иногда посылки не доходят и часто качество страдает, но покупатель имеет возможность выставить претензию, которую рассматривает уже администрация Алиэкспресса.
Другими словами, в этой схеме велико значение человеческого фактора. Махинации возможны со стороны всех участников процесса, хотя, на первый взгляд, процесс достаточно формализован.
Поясните, как можно уменьшить значение человеческого фактора в смарт-контрактах, например, на базе Эфириума?
Скажите, есть ли ограничения в использовании смарт-контрактов? Для всех ли видов сделок они подходят?
Например, можно ли с помощью смарт-контракта купить вагон сахара? Как быть, если формально сахар доставлен покупателю, но качество не соответствует условиям контракта?
Или смарт-контракты подходят только для сделок, поддающихся четкой формализации?
Для упрощения рассмотрения предположим, что Алиса, Боб и Ева формируют блоки своих цепочек с одинаковым периодом, в одни и те же моменты времени.
В момент времени Т-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 уже ничего нельзя подменить.
Конечно, в базе посредника может храниться и сам результирующий хэш, особой нагрузки это не создаст. Но главная особенность это тот же эффект, как в публичных блокчейнах. Любой узел может перепроверить корректность любого блока. Здесь же любой блокчейн может перепроверить результирующие хэши как в самом DLT Trust, так и в партнерских блокчейнах.
Как указывалось в статье, в принципе блокчейны могут обмениваться хэшами друг с другом напрямую, без посредника. Посредник в лице DLT Trust только упрощает взаимодействие, если число участников велико.
Для того, чтобы не кормить банковский планктон и уберечься от Васи был и разработан предложенный метод. Проверка неизменности блокчейна, например, банка переносится в публичное пространство. Уже есть внедренные решения, когда частные или приватные блокчейны привязываются к публичным, к тому же биткоину или эфириуму. Почитайте, скажем, про Exonum. Предлагаемый метод решает эту задачу иначе.
Частный блокчейн нужен не столько самому банку, сколько клиентам банка, дабы быть уверенными в невозможности возникновения забалансных счетов. Если продолжить примеры из банковской сферы, то следует вспомнить историю появления АСВ. Появление этого агенства реально успокоило клиентов банка, что даже в случае его банкротства они смогут вернуть свои вклады.
Банку будет выгодно внедрять блокчейн и делать его надежным в глазах клиентов.
По второму вопросу для примера хотелось бы услышать хотя бы парочку «фундаментальных ограничений» из упомянутого ряда.
Смысл предлагаемого метода как раз заключается, чтобы не допустить «переписывание» частного блокчейна при отсутствии консенсуса. Скажем, клиентам банка, в котором будет внедрен частный блокчейн, требуются гораздо весомее аргументы, чем честные голубые глаза управляющего. Вспомните истории о забалансовых счетах со суммами с многими нулями.
Повторюсь, предлагаемый метод ориентирован на частные блокчейны, в которых нет особого смысла развивать внутренний консенсус.
Большинство пользователей предпочитают легкие или онлайн кошельки, так как процесс первичной синхронизации полного узла слишком долог. Думаю, это отпугивает многих.
Впрочем, это не имеет принципиального значения к теме, поднятой в данной статье.
Интересно, есть ли статистика по числу майнеров? Тогда можно было бы посмотреть корреляцию с числом полных узлов.
Подчеркну, предлагаемый метод ориентирован не столько на публичные блокчейны криптовалют, сколько на частные блокчейны, которые уже сейчас начинают внедряться в компаниях и госструктурах.
Попытка поиска в Гугле ранних упоминаний о Distributed Ledger не увенчалась успехом. основная масса ранних источников датируется 2012-2013 годами. Активно этот термин начинается употребляться в 2015-2016 годах. Но не настаиваю, возможно, плохо искал.
Другими словами, в этой схеме велико значение человеческого фактора. Махинации возможны со стороны всех участников процесса, хотя, на первый взгляд, процесс достаточно формализован.
Поясните, как можно уменьшить значение человеческого фактора в смарт-контрактах, например, на базе Эфириума?
Например, можно ли с помощью смарт-контракта купить вагон сахара? Как быть, если формально сахар доставлен покупателю, но качество не соответствует условиям контракта?
Или смарт-контракты подходят только для сделок, поддающихся четкой формализации?