Блокчейн и безопасность данных в 1С

13.05.22

Администрирование - Информационная безопасность

Безопасность данных – обширная тема со множеством задач. О том, как избежать подмены данных и с помощью технологии блокчейн контролировать изменения в системе, на митапе «Безопасность в 1С» рассказал Михаил Калимулин.

Я Михаил Калимулин, разработчик 1С, преподаватель. С конца 2017-го года я публиковал несколько статей на Инфостарте по поводу блокчейна и применимости его в 1С. Ну а теперь хочу предложить вашему вниманию данный доклад.

 

 

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

  • Мы можем хотеть сделать явное тайным – ограничить доступ к информации. Для этого используются пароли, права доступа, ограничения доступа и т.д. Блокчейн сюда не входит.

  • Есть другой подход к безопасности – «тайное» сделать «явным». Этот вариант менее очевидный, но не менее значимый. И мы сейчас поговорим именно об этом.

 

 

Есть классический пример – есть некий приходный документ, в котором у нас изначально было поступление 10 штук чего-либо по цене 1 рубль.

Этот документ изменяется вот так: пришла одна штука по цене 10 рублей. Сумма документа не поменялась.

 

 

Как нетрудно догадаться, гипотетический злоумышленник теперь может 9 штук спокойно отнести себе домой.

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

Надо понимать, что практически 100% баз 1С никак не защищены от подобного рода атаки. Тем не менее, решение этой проблемы существует.

 

 

Но, чтобы решить эту проблему, нам придется пройти непростым путем – между Сциллой и Харибдой.

  • Сциллой здесь будет то, что я называю «очарование технологиями», это полагаться исключительно на технику, игнорируя «человеческий фактор», думать, что мы сейчас в нашей базе прикрутим какие-то алгоритмы, и все будет хорошо. Такое достаточно сильно распространено, вспомните, насколько популярен совершенно бесполезный контроль отрицательных остатков. Нет, мы не сможем добиться никаких результатов, полагаясь только на алгоритмы. Чтобы понять, где была правда – 1*10 или 10*1 – нам нужен будет человек, нужны будут его глаза, руки, иногда голова. Надо взять первичный документ и на него посмотреть. По-другому не получится никак.

  • А Харибдой здесь будет – полагаться только на контроль человека, игнорируя технические вызовы и возможности.

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

Это техническое решение называется хэш-функции.

 

Хэш-функции, SHA-256

 

 

Хэш-функции – вещь простая. Мы берем что-то большое и сжимаем его. Мы можем взять гигабайт данных, а на выходе получить 32 байта. Например, одна из самых распространенных на данный момент хэш-функций SHA-256 – она нам как раз 32 байта выдаст.

Надо понимать, что сами по себе хэш-функции – вещь достаточно изощренная. Вы просто подумайте – вам нужно из гигабайта получить 32 байта. Можно, конечно, просто взять и в случайном порядке повыдергивать лишние, а вставить случайные 32 байта. Но это будет плохая хэш-функция. Хорошая хэш-функция работает так, что, если у вас есть один гигабайт данных и другой гигабайт данных, которые отличается друг от друга всего на один бит, хэш-функция вернет совершенно другое значение. Она не просто так выдергивает случайные 32 байта.

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

Вероятность того, что мы получим у хэш-функции похожий набор, равняется 1 к 2 в степени 255 – ровно столько возможных значений в 32 байтах. Это 5*1076. А количество атомов во всей наблюдаемой вселенной по разным оценкам 4*1079, 4*1080 или 4*1081.

Это сравнимые числа. Представьте себе количество атомов – не в комнате, не в солнечной системе и даже не в галактике, а почти во всей вселенной, которую мы видим.

 

 

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

Обратите внимание на алгоритм получения хэш-функции. Я специально здесь привел экранчик – не для того, чтобы разбираться, что там написано, а чтобы оценить, как это выглядит. Самый популярный алгоритм SHA-256, который используется в широко известном биткоине – вот он весь. Он на один экран помещается, он предельно прост. Здесь один цикл и внутри него два цикла, где производятся элементарные действия.

 

 

В 1С это выглядит еще проще. Тут буквально три строки.

Итак, мы можем воспользоваться хэш-функцией, чтобы сжать наши данные в 32 байтах. А 32 байта – это не очень большой объем, его можно визуально контролировать. Можно тренировать память и запоминать. Можно на бумажку выписать и сравнить. Занимает меньше минуты, я сам это делал.

Так мы можем контролировать огромный набор данных.

 

Алгоритм работы журнала по принципу "цепочки блоков"

 

 

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

Вернемся к нашему примеру с приходными документами. Представим себе, мы решили организовать такой контроль:

  • Когда мы начинаем работать, у нас пока нет ни одного приходного документа.

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

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

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

Что здесь хорошо? Мы можем теперь взять наш журнал, нам его глазами не нужно просматривать весь. Нам глазами достаточно посмотреть только один последний ключ – те самые 32 байта. Я открываю журнал, вижу последний ключ и сравниваю его с чем-нибудь (с бумажкой, например). Если ключи совпадают, мой журнал в целостности, мне не нужно проверять каждый из этих блоков глазами, если это можно проделать программно.

 

 

Алгоритм работы журнала достаточно простой.

  • Мы делаем проверку целостности журнала – у нас программа бежит по этим блокам, получает хэш-суммы от данных документа. Проходит по ссылкам, разворачивает, сериализует документ, получает данные документа в виде строки, добавляет предыдущий ключ, вычисляет хэш-функцию, сравнивает ее значение с записанным конечным ключом. Если значения совпадают – все хорошо. Пробегаемся по всем документам и получаем список того, что у нас есть в журнале. Нам остается простейшим запросом получить, чего в журнале нет – какие новые документы добавились. И дальше новые документы добавляем в конец журнала.

  • Следующий шаг – мы добавляем записи о новых (измененных, удаленных) блоках. Если я бежал по этим блокам и где-то увидел, что документ изменен, я с этим блоком ничего не делаю, с ним все нормально, я просто в конец журнала добавлю еще раз ссылку на этот же документ, но уже пересчитанные ключи, пересчитанные хэш-суммы. А в той записи укажу, что она была изменена, и укажу ссылку на ее потомка. Допустим, у меня была запись №1, потом через 10 записей ее поменяли. В 10-й записи лежит актуальная копия. В случае, есть документ меняли несколько раз, вот так по цепочке можно пройти. Смысл в том, что любое изменение всегда попадает в конец. Удаленные документы – это частный случай изменения. Там есть некоторые хитрости, но я не буду на этом останавливаться.

  • И визуализирую все, что у меня было – вот мои документы новые, вот мои документы измененные. Вот теперь садитесь, включайте свои глаза, свои руки, свои головы, берите первичные документы и проверяйте.

Если запустить такую систему, нашему гипотетическому злоумышленнику становится некуда влезть. Подменить 10 на 1 не получится никаким способом.

 

Возможные уязвимости решения

 

 

Можно придумать только две уязвимости.

  • Первая уязвимость чисто техническая, связанная с алгоритмами хэш-функций. Здесь речь о том, что алгоритм получения хэша очень простой, у него 64 шага. Если количество шагов уменьшить до 10, это тоже будет хэш-функция, она тоже будет приемлемо работать, но такую функцию уже сломали. Она действительно уже не работает, потому что есть способ поискать коллизии – автоматически запустить алгоритм, который будет находить такие наборы данных и выдавать тот же самый результат хэш-функции. SHA-256 взломали до 30-го шага, но в целом он до сих пор является надежным. С другой стороны, существование коллизий – это вопрос для математиков. Допустим, мы можем найти одну-две-три коллизии. Вопрос в том, то нам не первую попавшуюся надо. Если вспомнить, что мы делаем с документом – мы его сериализуем. Мы документ превращаем в строку по каким-то правилам (XML, JSON). Мы нашли коллизию, но эта коллизия в формат JSON или XML не попадает. А перебирать коллизии до тех пор, пока мы не наткнемся на что-то приемлемое – это может быть столь же неприемлемо, как просто перебирать. С этой стороны эта уязвимость весьма гипотетическая.

  • А второй момент – подмена алгоритма. Многие уверены, что надежная программа – это только та, которую ты сам написал. Во все остальное, что ты запускаешь, всегда можно что-то куда-то вставить. Тут мы возвращаемся к тому моменту, когда я вам говорю о простоте. Сам алгоритм хэш-функции прост, его можно воспроизвести самому. Можно пользоваться конструктором ХэшированиеДанных() – это три строчки в 1С, как я показывал. Там невозможно что-то вставить.

 

 

Вот так выглядит описанный мной на предыдущем шаге алгоритм в реальности.

В процедуре контроля всего лишь 150 строк кода – это не ERP, где куда-то что-то можно вставить и не найдешь никогда, это можно контролировать глазами.

Если вы, перед тем как запускать контроль журнала, хотите убедиться, что запускаете код, где никаких вставок быть не может – это можно проделать глазами.

Соответственно, аргумент о подмене алгоритма тоже легко парируется, а вы получаете технические методы контроля, основанные на хэш-функциях.

 

Вывод

 

 

К чему я хочу призвать коллег?

Давайте посмотрим на безопасность с другой стороны. Мы можем стараться сделать так, чтобы у людей не было возможности поменять 10 на 1, а можно подойти с другой стороны – можно сделать так, чтобы все изменения в базе было легко контролировать. Этот механизм математически работает абсолютно безупречно, и вы с его помощью можете создать систему контроля, которую никак не обойти и никак не испортить.

 

Вопросы

 

Есть ли готовая реализация вашего решения?

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

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

Как это выглядит для пользователей, для аудиторов? Например, если в документе изменился какой-то реквизит, сможет ли аудитор увидеть, какой именно реквизит изменился? Или он в целом увидит, что документ изменился?

Тут нужно понимать, что вопросы безопасности должны решаться комплексно. Эта технология не отменяет бэкапы, да, мы делаем регулярные бэкапы базы. Эта система дает сигнал, что этот документ изменился, и дальше можно придумать такую систему, которая почти в автоматическом режиме поднимет бэкап, сравнит текущую базу с бэкапом, покажет, что эти реквизиты поменялись. Это тоже можно все в автоматическом режиме сделать. Можно просто не заморачиваться этим и построить систему контроля, которая основана на том, что изменился документ – значит, нужно поднимать первичку. Не обязательно говорить тому же аудитору, что конкретно поменялось. У тебя прошел сигнал, что с этим документом что-то не так, его надо снова проверять. Хотя я согласен, что, если там будет 1000 строк, ему не очень удобно снова все проходить. В этом случае, действительно, вы поднимаете из бэкапа конкретный документ. Тут ведь главное понимать, что вы ищете не иголку в стоге сена, а вы идете по ссылке на конкретный документ и сравниваете его реквизиты.

Есть же механизм версий – и в платформе, и в БСП. Насколько возможности блокчейна оправданны? Можно ли заменить один механизм на другой? Есть ли смысл?

По идее, эти механизмы должны друг друга дополнять. Механизм контроля версий – это всего лишь таблица с определенными данными, их можно запросто поменять. Если использовать только журнал регистрации, то любой школьник погуглит и найдет, как в нем запись удалить или поменять. Нужно понимать, что есть защита, которая подразумевает, что злоумышленник чем-то не будет владеть, чем владеет администратор системы. И есть абсолютная защита, в которой неважно, какой уровень доступа у злоумышленника. Он все равно ничего не сможет сделать. Что бы он ни сделал, это будет видно. Я призываю к тому, чтобы посмотреть на безопасность с разных сторон. Если у вас будет безопасность и там, и там, тогда это будет настоящая безопасность.

А почему версию можно поменять, а блокчейн нельзя пересчитать с какого-то момента?

Нельзя пересчитать, потому что у вас где-то на бумажке записан последний ключ. Пересчитать можно, действительно, у нас есть алгоритм, который пробегает по журналу и контролирует соответствие данных документов их хэш-суммам. Да, можно весь журнал заменить каким-то способом. Но у вас в кармане лежит бумажка. Вы замените весь журнал, у вас последний ключ в этом журнале будет другой. Здесь суть в том, что мы не полагаемся полностью на алгоритмы, у нас есть глаза и алгоритмы. И то, и другое в синтезе.

Как на каждый документ-объект базы сделать «бумажку» с последним блоком?

Не каждый документ, вам нужно записать только последний блок. У вас есть журнал – он постоянно растет, а вы раз в день проверяете, у вас всегда есть только один последний ключ, вам не нужно хранить значения блока на каждый документ. В этом и смысл блокчейна как цепочки. У вас это все зацепилось одно за другое. И в конце концов вы получили самый последний ключ – надо понимать, что он в себе содержит все предыдущее, потому что у вас ключ за ключ цеплялся и последний ключ связан со всеми остальными.

А что делать, когда идет работа задним числом?

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

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

Там есть больше вопросов к специфике отражения изменений в 1С – например, мы же документ можем не трогать, мы же только движения можем поменять. Есть множество специфических тем, но я боюсь, мы просто не сможем их все обсудить сейчас. Я бы просто хотел обратить внимание коллег на то, что существует такой способ.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Безопасность в 1С".

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

AUTO VPN (portable)

Информационная безопасность Платные (руб)

Автоматизация подключения пользователей к удаленному рабочему месту или сети посредством создания автоматического VPN (L2TP или L2TP/IPSEC и т.д.) подключения без ввода настроек пользователем (с возможностью скрытия этих настроек от пользователя). Программа автоматически выполняет подключение к VPN серверу и после успешного коннекта , если необходимо, подключение к серверу удаленных рабочих столов (RDP).

1200 руб.

24.03.2020    14399    22    32    

33

Настройка аутентификации в 1С с использованием стандарта RFC 7519 (JWT)

Информационная безопасность Платформа 1С v8.3 Бесплатно (free)

Рассмотрим в статье более подробную и последовательную настройку аутентификации в 1С с использованием распространенной технологии JWT, которая пришла в программу в платформе версии 8.3.21.1302.

27.02.2024    2608    PROSTO-1C    9    

29

Device flow аутентификация, или туда и обратно

Информационная безопасность Платформа 1С v8.3 Абонемент ($m)

Интеграционные решения стали неотъемлемой частью нашей жизни. Правилом хорошего тона в современных приложениях является не давать интегратору доступ к чувствительным данным. Device flow позволяет аутентифицировать пользователя, не показывая приложению чувствительные данные (например: логин и пароль)<br> Рассмотрим Device flow аутентификацию, в приложении, на примере OpenID провайдера Yandex.

1 стартмани

27.10.2023    1618    platonov.e    1    

23

Анализатор безопасности базы сервера 1С

Информационная безопасность Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

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

5 стартмани

24.04.2023    5438    14    soulner    7    

29

Двухфакторная аутентификация в 1С через Telegram и Email

Информационная безопасность Платформа 1С v8.3 1С:ERP Управление предприятием 2 Абонемент ($m)

1С, начиная с версии платформы 8.3.21, добавили в систему возможность двойной аутентификации. Как это работает: в пользователе информационной базы появилось свойство «Аутентификация токеном доступа» (АутентификацияТокеномДоступа во встроенном языке), если установить этот признак и осуществить ряд манипуляций на встроенном языке, то появляется возможность при аутентификации отправлять HTTP запросы, которые и реализуют этот самый второй фактор. Данное расширение позволяет организовать двухфакторную аутентификацию с помощью электронной почты или мессенджера Telegram.

2 стартмани

08.12.2022    5968    32    Silenser    12    

23

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

Информационная безопасность Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

От клиента клиенту, от одной системы к другой, мы вновь и вновь встречаем одни и те же проблемы и дыры в безопасности. На конференции Infostart Event 2021 Post-Apocalypse Виталий Онянов рассказал о базовых принципах безопасности информационных систем и представил чек-лист, с помощью которого вы сможете проверить свою систему на уязвимость.

26.10.2022    9245    Tavalik    46    

113
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 3033 13.05.22 14:27 Сейчас в теме
Вспомнилась шутка:
- Подскажите какой-нить сильный архиватор?!
- md5.
2. mkalimulin 1148 13.05.22 15:25 Сейчас в теме
3. booksfill 16.05.22 18:18 Сейчас в теме
Идея понятна.
Но как ее использовать на практике, имеется в виду не реализация, а реальная работа - не очень.

Потому как узнать, что это документ был изменен, потом поднимать бэкап и глазками отслеживать 100500 мест - не вариант.
Даже если таких мест всего два, т.к. "творческая правка" не обязана бросаться в глаза - достаточно "ошибиться" в цене, в третьем знаке, и продать чего-то на несколько сотен миллионов. И еще преднамеренно внести ошибку в другом месте этого же документа - абсолютно безобидную ну, чтобы дольше искали, а мы пока все спрячем.

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

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

Иначе возможна работа по схеме - N сегодня украл, пометил в табличе блокчейна, что это вовсе не он, а Y. Завтра (а найдите того, кто будет глазками считывать последний блок чаще чем раз в день) вскрылось, что украдено. При этом неясно ни кто украл, ни как догнать N.
Первое можно как-то отследить по логам, камерам и т.п., а вот как быть с догнать ...

И еще, недаром Митник говорил все больше про социальную инженерию.

Самый простой способ - украсть, а бумажку подменить на новую или под благовидным предлогом испортить.

Кстати, в критичных данных заинтересован обычно big boss, а бумажку он заставит читать в 99% случаев подчиненного, которого подкупить/запугать при игре на хорошие деньги - проще простого.

Поэтому скоро вместо бумажки получится несколько отдельных зашифрованных хранилищ "бумажки" + сама бумажка и никто всем этим зоопарком пользоваться не будет.
8. reset2 17 20.05.22 15:28 Сейчас в теме
Если механизм рассматривается как защита от продвинутого мошенника с полными правами - то очень несовершенно.
Зачем мошеннику в принципе оставлять в системе изменения.

1. Оформили/согласовали выдачу 1 шт.
2. Мошенник меняет в документе на 10 шт.
3. Мошенник идет на склад получает 10 шт.
4. Возвращает в документах 1 шт. Подчищает ЖР, версии и прочее

На бумажке хэш совпадает.
Кладовщики платят недостачу по итогам инвентаризации.
Мошенник - тихо злорадствует.
11. mkalimulin 1148 21.05.22 12:37 Сейчас в теме
(8) В конце дня контролер просматривает все документы в базе и привязывает их к реальности. Например видит выдачу 1шт. Звонит кладовщику и спрашивает: ты сколько выдал? 10? ага... Или не звонит, а берет бумажную бумажку, которую написал кладовщик. И там, как вы понимаете написано 10, а вовсе не 1.
Тут надо понимать какую конкретно задачу решает блокчейн. Блокчейн не может заменить человека в момент привязки к реальности. Зато он может гарантировать, что привязанное один раз, потом отвязать уже будет невозможно никаким способом и ни под какими правами.
12. reset2 17 21.05.22 16:21 Сейчас в теме
(11) можно долго накидывать на эту тему :)
- контролер тоже в доле
- контролер в определенный момент не заметит 11101111 и 11110111
- и т.д.

А вот если "привязка к реальности" сработать между п.1 и п.2 тогда да... но как это реализовать с приемлемым уровнем производительности и безопасности...
13. mkalimulin 1148 21.05.22 18:59 Сейчас в теме
(12) А и не надо ничего накидывать. В самом простом случае у вас есть кладовщик с материальной ответственностью. И он кровно заинтересован в том, чтобы 10 штук., выданные в реальности, по базе проходили, как 10 штук., а не как 1. И если этот кладовщик будет вооружен блокчейном, то никакой злоумышленник его уже не обойдет. Потому что кладовщик сразу заметит подмену 10 на 1
4. Indgo 338 17.05.22 11:38 Сейчас в теме
Blockchain на dbf файлах. Как я сразу не догадался. Гениально.
Отправлю к комунити bitcoin-core. Пусть переделают блокчейн на DBF файлы.

Скажу больше у вас есть последователи. Один разработчик сделал блокчейн Chia на SQL Lite. Вылетает правда постоянно и синхронится в 100 раз медленнее и Скаманулся недавно. Но это не помеха. Ваш блокчейн будет лучше ;-)
5. mkalimulin 1148 17.05.22 12:58 Сейчас в теме
(4) Могу и на TXT сделать )))
6. Indgo 338 17.05.22 14:08 Сейчас в теме
7. mkalimulin 1148 17.05.22 20:20 Сейчас в теме
(6) Если палец показывает на Луну, надо смотреть на Луну, а не на палец
9. SerVer1C 748 20.05.22 20:41 Сейчас в теме
Сила блокчейна в практической невозможности его пересчета, потому что в расчетах задействовано много вычислительных ресурсов. Если защищать подобным образом 1 базу, то за недолгое время можно пересчитать весь блокчейн (не говоря уже про пересчет на видеокарте) и продолжить уже генерить свою цепочку после изменения объектов базы.
10. mkalimulin 1148 21.05.22 12:03 Сейчас в теме
(9) Пересчитать можно, но это это нельзя будет сделать незаметно. Сила блокчейна в том, что тайное становится явным. А то, о чем вы говорите, относится к проблеме достижения консенсуса. В криптовалютах это действительно проблема. А в приватной базе консенсус присутствует имманентно
14. Indgo 338 23.05.22 10:35 Сейчас в теме
(10)
) А в приватной базе консенсус присутствует имманентно

Приватный блокчен? Это как хромой ходок или альфа самец без инструмента. Не бывате не какого приватного блокчейна, как и свободного раба(приватного человека).
Блокчейн пересчитать - да пожалуйста. Только вот миллионы децентрализованных нод и майнеров Bitcoin не примут ваши лживые транзакции.
Основные принципы блокчейна:
1. Децентрализация.
2. Децентрализация.
3. Децентрализация.
4. HODL.
5. Bitcoin.

Все остальное чепуха.
16. mkalimulin 1148 23.05.22 12:44 Сейчас в теме
(14)
Блокчейн - это цепочка блоков. Не более того (но и не менее). Цепочку блоков можно применять где угодно. Как в публичных, так и в приватных базах
17. Indgo 338 23.05.22 17:14 Сейчас в теме
(16)
Блокчейн - это цепочка блоков. Не более того (но и не менее)
Ваша логика мне ясна, что то типа того: Автомобиль - это навозная телега в которой есть руль, не более того. А двигатели шестеренки...привода... Приватная телега в сарае - запрягай лошадей и езжай за сеном... это тоже автомобиль.
Прикрепленные файлы:
15. Indgo 338 23.05.22 10:40 Сейчас в теме
(9)
(9)
можно пересчитать весь блокчейн (не говоря уже про пересчет на видеокарте) и продолжить уже генерить свою цепочку после изменения объектов базы.

Видеокарты плохо считают цепочки. Их ядра маленькие и слабые. Для расчета цепочек используется CPU.
GPU - для параллельных, не зависящих друг от друга вычислений.
18. Indgo 338 23.05.22 17:31 Сейчас в теме
Но, чтобы решить эту проблему, нам придется пройти непростым путем – между Сциллой и Харибдой.
Прикрепленные файлы:
19. mkalimulin 1148 23.05.22 20:37 Сейчас в теме
(17) Нет. Моя логика заключается в том, что автомобиль - это автомобиль, а колесо - это колесо. Криптовалюта - автомобиль. Блокчейн - колесо.
Оставьте свое сообщение