Блокчейн в базе 1С
Разработка - Математика и алгоритмы
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
В этой статье описывается преимущественно техническая сторона дела. Здесь в тексте много исходного кода на языке 1С. Если вам нужно популярное описание, без программного кода, тогда вам сюда:
//infostart.ru/public/1114877/
Шаг 1. Создадим документ Блокчейн
Цепочку блоков надо где-то хранить. Для простоты я выбрал объект метаданных "Документ". Вобще говоря, хранить цепочку можно и вне базы, хоть в текстовом файле. Также можно использовать справочник или регистр сведений. Я выбрал документ отчасти произвольно, отчасти потому, что в нем есть дата, а она может в дальнейшем пригодиться. Что бы это ни было, нам нужны четыре (всего лишь, впрочем, можно и три) реквизита.
КонтролируемыйДокумент, как можно догадаться - ссылка на документ любого вида. КлючНачальный, ХешДокумента и КлючКонечный - строки неограниченной длины (можно задать длину 64).
Шаг 2. Сделаем обработку генерации цепочки блоков.
Найдем последний элемент цепочки. Я сделал это так:
Функция ПолучитьПоследнийБлок()
запрос=новый запрос;
запрос.Текст=
"ВЫБРАТЬ ПЕРВЫЕ 1
| Блокчейн.Ссылка КАК Ссылка
|ИЗ
| Документ.Блокчейн КАК Блокчейн
|
|УПОРЯДОЧИТЬ ПО
| Блокчейн.Номер УБЫВ";
выб=запрос.Выполнить().Выбрать();
если выб.Следующий() тогда
возврат выб.ссылка;
иначе
возврат неопределено;
конецесли;
КонецФункции
Запомним конечный ключ последнего блока, он станет начальным ключом первого созданного нами блока.
ПоследнийБлок=ПолучитьПоследнийБлок();
если ПоследнийБлок=неопределено тогда
КлючНачальный="";
иначе
КлючНачальный=ПоследнийБлок.КлючКонечный;
конецесли;
Получим все проведенные документы, которые еще не попали в цепочку блоков. Здесь я использую следующую заготовку запроса:
запрос=новый запрос;
текстзапроса=
"ВЫБРАТЬ
| Док.Ссылка КАК Ссылка
|ИЗ
| Документ.<вид> КАК Док
| ЛЕВОЕ СОЕДИНЕНИЕ Документ.Блокчейн КАК Блокчейн
| ПО Док.Ссылка = Блокчейн.КонтролируемыйДокумент
|ГДЕ
| Док.Проведен
| И Блокчейн.Ссылка ЕСТЬ NULL";
Строка <вид> в тексте запроса в дальнейшем заменяется на конкретный вид документа.
Обработаем документы. Я разместил в обработке дерево значений для настройки списка документов, которые мы будем включать в блокчейн, а также списка их реквизитов.
А вот собственно сама генерация цепочки блоков:
видыдокументов=настройка.ПолучитьЭлементы();
для каждого вид из видыдокументов цикл
если вид.пометка тогда
запрос.Текст=стрзаменить(текстзапроса,"<вид>",вид.имя);
выб=запрос.Выполнить().Выбрать();
пока выб.Следующий() цикл
новблок=документы.Блокчейн.СоздатьДокумент();
новблок.Дата=текущаядата();
новблок.КонтролируемыйДокумент=выб.ссылка;
новблок.ХешДокумента=ПолучитьХешДокумента(выб.ссылка);
новблок.КлючНачальный=КлючНачальный;
новблок.КлючКонечный=ПолучитьКонечныйКлюч(КлючНачальный,новблок.ХешДокумента);
новблок.Записать();
КлючНачальный=новблок.КлючКонечный;
конеццикла;
конецесли;
конеццикла;
Функция ПолучитьХэшДокумента() - банальна, но я ее приведу.
Функция ПолучитьДокументСтрокой(ссылка)
рез="";
видд=ссылка.метаданные().имя;
нвид=неопределено;
ветка=настройка.ПолучитьЭлементы();
для каждого вид из ветка цикл
если вид.имя=видд тогда
нвид=вид;
прервать;
конецесли;
конеццикла;
если не нвид=неопределено тогда
реквизиты=нвид.ПолучитьЭлементы();
для каждого рек из реквизиты цикл
если рек.пометка тогда
поз=стрнайти(рек.имя,".");
если поз=0 тогда
рез=рез+строка(ссылка[рек.имя]);
иначе
имятч=лев(рек.имя,поз-1);
имярек=сред(рек.имя,поз+1);
для каждого стр из ссылка[имятч] цикл
рез=рез+строка(стр[имярек]);
конеццикла;
конецесли;
конецесли;
конеццикла;
конецесли;
возврат рез;
КонецФункции
Функция ПолучитьХешДокумента(ссылка)
хд=новый ХешированиеДанных(ХешФункция.SHA256);
хд.Добавить(ПолучитьДокументСтрокой(ссылка));
рез=строка(хд.ХешСумма);
рез=стрзаменить(рез," ","");
возврат рез;
КонецФункции
Строковое представление документа следовало бы сделать более изощренным и включить в него ИД ссылок. Если будете делать рабочую версию, доделайте функцию ПолучитьДокументСтрокой().
Чуть более интересна функция ПолучитьКонечныйКлюч(). Собственно здесь и кроется сама суть технологии.
Функция HEX(знач знч)
рез= "";
Пока знч > 0 Цикл
рез = Сред("0123456789ABCDEF", знч%16+1,1) + рез;
знч = Цел(знч/16) ;
КонецЦикла;
Возврат рез;
КонецФункции
Функция ПолучитьКонечныйКлюч(КлючНачальный,хеш)
нули="00000000000000000000000000000000000000000000";
нули=лев(нули,сложность);
рез="";
сч=0;
пока истина цикл
хд=новый ХешированиеДанных(ХешФункция.SHA256);
рез=HEX(сч);
хд.Добавить(КлючНачальный+хеш+рез);
стр=стрзаменить(хд.ХешСумма," ","");
если сложность=0 тогда
прервать;
иначеесли лев(стр,сложность)=нули тогда
прервать;
конецесли;
сч=сч+1;
конеццикла;
возврат рез;
КонецФункции
Я подбираю значение конечного ключа до тех пор, пока ключ начальный, хэш документа и ключ конечный в сумме не дадут некий "красивый" хеш. Красивым считается хеш, который содержит в начале некоторое количество нулей. Количество нулей определяет сложность нахождения красивого хеша.
Полностью процедура генерации цепочки блоков выглядит так:
Процедура ЗапускНаСервере()
ПоследнийБлок=ПолучитьПоследнийБлок();
если ПоследнийБлок=неопределено тогда
КлючНачальный="";
иначе
КлючНачальный=ПоследнийБлок.КлючКонечный;
конецесли;
запрос=новый запрос;
текстзапроса=
"ВЫБРАТЬ
| Док.Ссылка КАК Ссылка
|ИЗ
| Документ.<вид> КАК Док
| ЛЕВОЕ СОЕДИНЕНИЕ Документ.Блокчейн КАК Блокчейн
| ПО Док.Ссылка = Блокчейн.КонтролируемыйДокумент
|ГДЕ
| Док.Проведен
| И Блокчейн.Ссылка ЕСТЬ NULL";
видыдокументов=настройка.ПолучитьЭлементы();
для каждого вид из видыдокументов цикл
если вид.пометка тогда
запрос.Текст=стрзаменить(текстзапроса,"<вид>",вид.имя);
выб=запрос.Выполнить().Выбрать();
пока выб.Следующий() цикл
новблок=документы.Блокчейн.СоздатьДокумент();
новблок.Дата=текущаядата();
новблок.КонтролируемыйДокумент=выб.ссылка;
новблок.ХешДокумента=ПолучитьХешДокумента(выб.ссылка);
новблок.КлючНачальный=КлючНачальный;
новблок.КлючКонечный=ПолучитьКонечныйКлюч(КлючНачальный,новблок.ХешДокумента);
новблок.Записать();
КлючНачальный=новблок.КлючКонечный;
конеццикла;
конецесли;
конеццикла;
КонецПроцедуры
Обработка генерации цепочки блоков готова. Можно позапускать ее в ручном режиме в учебных целях. В рабочем режиме потребуется заставить ее работать постоянно тем или иным способом.
Шаг 3. Сделаем обработку контроля.
С обработкой контроля все еще проще. Я скопировал предыдущую обработку, чтобы иметь тот же интерфейс настройки
и заменил процедуру генерации на процедуру контроля.
Процедура ЗапускНаСервере()
контрольпройден=истина;
ключ="";
выб=документы.Блокчейн.Выбрать();
пока выб.Следующий() цикл
если выб.КлючНачальный<>ключ тогда
сообщить("Блок "+выб.Номер+" нарушена последовательность блоков");
контрольпройден=ложь;
иначеесли лев(строка(выб.КонтролируемыйДокумент),1)="<" тогда
сообщить("Блок "+выб.Номер+" документ удален");
контрольпройден=ложь;
иначеесли не выб.КонтролируемыйДокумент.Проведен тогда
сообщить("Блок "+выб.Номер+" документ распроведен");
контрольпройден=ложь;
иначеесли выб.ХешДокумента<>ПолучитьХешДокумента(выб.КонтролируемыйДокумент) тогда
сообщить("Блок "+выб.Номер+" документ изменен");
контрольпройден=ложь;
иначеесли не ЭтоКрасивыйХеш(выб.КлючНачальный,выб.ХешДокумента,выб.КлючКонечный) тогда
сообщить("Блок "+выб.Номер+" неправильный хеш");
контрольпройден=ложь;
конецесли;
ключ=выб.КлючКонечный;
конеццикла;
если контрольпройден тогда
сообщить("Контроль пройден");
конецесли;
КонецПроцедуры
Функция ЭтоКрасивыйХеш() - упрощенная вариация того, что мы видели в функции ПолучитьКонечныйКлюч() на предыдущем шаге.
Функция ЭтоКрасивыйХеш(КлючНачальный,хеш,КлючКонечный)
нули="00000000000000000000000000000000000000000000";
нули=лев(нули,сложность);
хд=новый ХешированиеДанных(ХешФункция.SHA256);
хд.Добавить(КлючНачальный+хеш+КлючКонечный);
стр=стрзаменить(хд.ХешСумма," ","");
если сложность=0 тогда
возврат истина;
иначе
возврат лев(стр,сложность)=нули;
конецесли;
КонецФункции
Что в итоге.
Вы можете самостоятельно сделать обработки генерации и контроля, следуя моим инструкциям, или скачать готовые. Позапускать их и убедиться, что любая операция с документом, который попал в цепочку приводит к необходимости пересчитывать все, начиная с этого документа. При правильно подобранной сложности, это становится практически не осуществимо. Теоретически, конечно, можно попросить знакомого китайского майнера задействовать его ферму для решения данной задачи. Но он ведь попросит компенсировать неполученные им биткоины (и еще столько же, в лучшем случае, а сколько это сейчас в долларах/рублях считайте сами). С другой стороны затраты на безопасность базы, как вы можете убедиться, не такие уж большие. Несложная программная часть. Немного дополнительного места на диске. И вычислительные ресурсы для генерации цепочки блоков. Последние могут быть больше или меньше в зависимости от желаемого уровня защиты.
Стоит заметить, что возможна также атака путем подмены контролирующей обработки. Но она настолько проста, что ее может визуально контролировать кто угодно. Как вариант можно регулярно скачивать контролирующую обработку (например, с инфостарта ))) ) .
Обработки тестировались на версии 8.3.10.2639.
Update 09.01.2018
Публикация вызвала оживленное и, что еще более важно, плодотворное обсуждение. И я хочу поблагодарить всех, кто принял в нем участие. Ниже я подведу итоги состоявщегося обсуждения и представлю продукт, в котором учтены существенные замечания.
1. Что это такое?
Блокчейн обычно связывают с криптовалютами. Данная технология не имеет отношения к майнингу криптовалют. Идея состоит в том, чтобы использовать особым образом связанную цепочку блоков (блокчейн) для контроля неизменности документов в информационной базе 1С.
2. Чем это лучше, того что есть сейчас?
В докомпьютерной бухгалтерии существовала (впрочем, она и сейчас существует, только не применяется на практике, по крайней мере в 1С) следующая концепция безопасности. Невозможно предотвратить неправомерные действия, но можно сделать так, что любое такое действие будет быстро выявлено. Современные информационные базы защищены системой прав доступа, паролями и т.д. Но. Когда злоумышленник преодолевает эту защиту, его дествия практически невозможно выявить. Например. Некто меняет в свою пользу в приходном документе количество и цену местами. Условно говоря, вместо 10 пачеки сахара по 1 рублю, ставит 1 по 10. После чего он может спокойно забрать 9 пачек себе. Скорее всего, об этом никто и никогда не узнает. Данная система позволяет создать абсолютную защиту, в том смысле, что любое изменение(удаление) контролируемого документа будет моментально обнаружено. Способов обмануть систему, в том числе путем подмены цепочки, нет. Подробнее см. п.4.
3. Это - дополнительная нагрузка на информационную базу? Документы будут медленнее проводиться?
Система защиты работает автономно, в процесс проведения документов никак не вмешивается. При построении цепочки происходит однократное чтение нового документа. При контроле чтение каждого документа из цепочки.
4. Зачем нужен "майнинг"?
Майнинг конечно же в кавычках. Дело в том, что в настоящем майнинге основным моментом является поиск т.н. красивого хеша. Такого, который содержит в начале определенное количество нулей. В приведенном выше решении я тоже использовал этот прием. Ищется красивый хеш с количеством нулей, соответствующем заданной пользователем сложности. Моя идея заключалась в том, что злоумышленник всегда будет вынужден догонять. Тогда можно будет подобрать такую сложность, что затраты на подмену цепочки сделают атаку бессмысленной. Тут я несколько увлекся и упустил из виду, что злоумышленник может принять решение о подмене документа и сразу же начать строить альтернативную цепочку. Таким образом, атакующий и система находятся в равном положении. CSiER обратил внимание на это и предложил отказаться от "майнинга" и дать пользователю возможность визуального контроля цепочки на предмет подмены. Пользователь записывает куда-нибудь ключ последнего на сегодня(или вчера) блока, а на следующий день сверяет свою запись с состоянием цепочки. В таком виде система действительно дает абсолютную защиту и в коммерческом решении я использую этот метод. Но я все равно оставил "майнинг". Дело в том, что если отказаться от него совсем (задать сложность 0), тогда ключ для контроля будет слишком длинным (64 символа). А если задать сложность 2 или 3, тогда ключ будет длиной 2-4 символа, что гораздо удобнее.
Коммерческое решение представляет собой две исходные обработки соединенные в одну и доработанные с учетом п.4. Интерфейс найстройки принципиально не изменился. Добавилась страница состояния, откуда можно переписывать ключи для контроля цепочки.
При выявлении того или иного нарушения, система выдает соответствующее сообщение.
Принципиальным отличием является то, что для хранения цепочки используется не документ информационной базы, а внешний файл XBase. Это дает возможность организовать негласную проверку базы, такую которая будет незаметна в том числе и для ИТ. Более подробное описание можно найти в руководстве пользователя.
На мой взгляд, надежный контроль неизменности документов - очень важная технология. Можно создать множество решений на ее основе. Если кто-то возьмется за это, то он может использовать код из данной публикации без каких-либо условий.
Update 22.01.2018
Платная версия, которую я представил в прошлый раз, подразумевала не совсем 1С-овский стиль работы. Документ попавший в цепочку блоков уже нельзя было менять совсем. При обнаружении изменения, нужно было вернуть документ в первоначальный вид. Я оставил эту платную версию под новым именем "Докчейн строгий". И в дополнении к ней предлагаю основную версию под названием "Докчейн. Защищенный журнал". В этой версии документы могут изменяться и удаляться. Все такие действия заносятся в ту же цепочку блоков и получается журнал, защищенный от изменений. Чтобы не загромождать данную публикацию, я создал новую:
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Математика и алгоритмы Разработчик 1С 8.3 Абонемент ($m)
Данная внешняя обработка для платформы 1С:Предприятие реализует усовершенствованный алгоритм Левенштейна для вычисления схожести строк с учетом различных лингвистических особенностей русского языка. В отличие от классической реализации, этот алгоритм учитывает фонетические, визуальные и контекстные особенности набора текста.
1 стартмани
07.11.2025 7015 18 InFlach 17
Математика и алгоритмы Запросы Разработчик 1С:Предприятие 8 Бесплатно (free)
Рассмотрим быстрый алгоритм поиска дублей с использованием hash функции по набору полей шапки и табличных частей.
08.07.2024 9180 ivanov660 9
Математика и алгоритмы Разработчик 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)
На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.
1 стартмани
30.01.2024 16980 stopa85 12
Математика и алгоритмы Бесплатно (free)
Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.
19.10.2023 25249 user1959478 57
Математика и алгоритмы Разное 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)
Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.
2 стартмани
29.09.2023 15740 maksa2005 8
Математика и алгоритмы Инструментарий разработчика Разработчик 1С:Предприятие 8 Россия Абонемент ($m)
Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.
1 стартмани
09.06.2023 25558 13 SpaceOfMyHead 20
Математика и алгоритмы Разработчик 1С:Предприятие 8 Бесплатно (free)
Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.
03.04.2023 17745 RustIG 10
Механизмы платформы 1С Математика и алгоритмы Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
В статье анализируются средства платформы для решения системы линейных уравнений в 1С. Приводятся доводы в пользу некорректной работы встроенных алгоритмов, а значит потенциально некорректного расчета себестоимости в типовых конфигурациях.
23.11.2022 16627 gzharkoj 17
У вас этот "блокчейн" для какой то практической цели используется?
если выб.Следующий() тогда
Результат запроса на пустоту правильно определять
Результат = Запрос.Выполнить();
Если НЕ Результат.Пустой() Тогда
КонецЕсли;Что бы не создавать объект Выборка из пустого результата запроса.
Если в коде используете Выборка.Следующий() с последующей обработкой результатов выборки (как у автора), то перед этим Результат.Пустая() не обязательно делать. Вместо этого Выборка.Следующий() вернет Ложь, что и будет означать пустой результат.
Там написано что проверять результат на пустоту надо с помощью "Пустой()". Что бы не создавать объект выборка из пустого запроса только для того что бы убедится что он пустой.
А если вы уверены что в результате вашего запроса всегда будет результат то тогда проверка "Пустой()" лишняя.
З.Ы. Хотя да... можно трактовать по разному. Если потом есть обработка то можно делать выборку. Но если результат может быть пустым то наверное всё же лучше через оператор Пустой.
З.Ы.Ы. Это я где то в каком то курсе по программированию видел(на спеца вроде). Там объяснялось что результат запроса надо проверять на пустоту, а не делать выборку из пустого результат, если результат может быть пустым. Если результат есть всегда то проверку на пустоту делать не нужно.
Хотя и в типовых очень часто проверку на пустоту делают Выборка.Следующий(). Или Выборка.Количество().
"практически" или "не изменяемыми" ?
Дело в том что я и так могу в своей базе сделать что то "практически не изменяемым" программными средствами. То есть, обойтись без "блокчейна".
Вопрос в том какие задачи можно решать эффективно с помощью блокчейна и это будет лучше чем другими средствами. А так получается "блокчейн" ради "блокчейна".
На одном из инфостарт эвентов вроде кто то делал доклад про блокчейн в 1С и видимо как то они его используют. Но давно было... наверное уже не найду.
Вы сделаете. И стоимость успешной атаки на вашу защиту - 1 час работы начинающего.
Стоимость атаки на мою защиту зависит от выбранной сложности и может быть сколь угодно большой.
В этом и проблема блокчейна. Палить килловаты энергии ради красивого хэша. Наверное должны быть другие менее ресурсозатратные инструменты.
Безопасность не может быть бесплатной. Мое решение хорошо тем, что уровень затрат на безопасность можно гибко подстраивать под конкретную ситуацию. Он может быть как скромным (но вполне достаточным, для того, чтобы у вас со склада не воровали, например, сахар), так и внушительным, таким, где стоимость атаки начинается от миллионов долларов.
А если вы хотите действительно серьезной защиты - купите ASIC. Он будет половину времени работать на вашу безопасность, а половину времени майнить. В этом случае, как ни странно, затраты вообще выходят в ноль.
+ дополнительным плюсом можно сделать "онлайн" подпись, с абсолютной невозможностью изменений задним числом, не дожидаясь попадания данных в "блокчеин"
Так что безопасность "дутая".
Т.е. поменять я могу - подменить данные - сложнее, но видимо тоже можно, ну в вашей процедуре даже проверка хэшастрокой в документе соответствия хэшу реальному - не выполняется, т.е. я могу их нагенерить без расчета с учетом сложности.. тип вставить ложные хэши.
Итак, блокчейн - это инструмент для неподменности данных в первую очередь. Но! Для этого требуется децентрализация.
Кто-то хитрый взял и поменял местами количество и цену в старом документе. Контроль это обнаружил и выдал ссылку на документ. Бухгалтерия достала первичку и восстановила документ. Из "бумажного" бэкапа, так сказать.
Т.е. КлючКонечный <> Хеш(КлючНачальный + ХешДокумента + Соль) для каждого документа.
При этом ХешДокумента - строка из значений всех реквизитов документа.
И проверять нужно будет с самого начала.
И как быстро оно будет работать, при активном документообороте, скажем, через месяц? 6 месяцев? 2 года?
В итоге появится "Дата запрета редактирования данных".
А когда она появится - мы не узнаем об изменении в документах старого периода.
А кто поменял? Нужно хранить пользователя, который записал. И дату, когда поменял.
В случае прямой записи в базу (что это за база, в которую любой Вася может писать напрямую? Куда админы смотрят?) всё равно мы только сможем факт изменения (а если будем использовать Дату запрета редактирования, то и это можем не узнать), ничего более.
В итоге, получим упрощенное версионирование.
А идея, в принципе, интересная.
Если же внесли изменения в базу и одновременно заменили ХешДокумента, тогда КлючНачальный+ХешДокумента+КлючКонечный не дадут "красивый" хеш. Посмотрите код, он совсем короткий.
Почему не ввел? Очень даже ввел, распечатал, отдал другу на склад, кладовщик сверился с данными в системе и разрешил отгрузку лишнего мешка сахара, после чего вор-манагер поменял количество на меньшее, перепечатал документы для доставки, и лишь затем ваша обработка добавила измененный документ в блокчейн. Красота!
Технологию блокчейна теоретически можно применить в нашей работе, но не в указанном вами случае! Зачем вообще нужно проверять всю историю документов в базе, если махинации на практике проводят в текущем оперативном диапазон (до недели), в рамках которого восстановить цепочку будет несложно?
В таком случае у меня, как у вашего потенциального взломщика (того самого, который умеет обходить дату запрета редактирования, RLS и все варианты версионирования), есть простой и надежный метод взлома вашей системы. Выборочно беру несколько звеньев и в СУБД напрямую изменяю связанные исходящий и входящий хеши - вам звоночек, что документы кто-то изменил - ищите его бумажную копию в архиве, сверяйте и понимайте что творится какая-то непонятная херня. Вы в панике пытаетесь восстановить какой-то из старых бэкапов для сравнения, но (у меня же по условиям ситуации есть доступ к СУБД), как только я решил ломать систему, я позаботился о том, что бы бэкапы стали "невосстанавливаемыми". И теперь у вас выбор: или плюнуть на весь этот блокчейн и забыть как страшный сон, или заплатить китайским майнерам за восстановление цепи и заметания следов моих преступлений.
Да и запись в блокчейн документа в течении 4-10 минут - это полный бред. Защита имеет смысл в компаниях с большим оборотом, когда каждую минуту вводят несколько документов - ваш централизованный блокчейн на базе Proof-of-Work просто уничтожит бизнес.
Поломать ключи и вывести из строя саму систему, не трогая при этом документы - интересная мысль. Но к чему такие сложности? Можно ведь просто выбросить сервер в окно. Успешная атака - это когда вы что-то сделали и никто ничего не узнал.
Какая разница - сколько времени пишется документ в блокчейн? Основной системе от этого ни холодно ни жарко.
Каждый день наблюдаю за этой процедурой. В какой-то момент отвлекаю внимание и быстро устанавливаю в браузере расширение Tampermonkey или подобное; скрываю видимость иконки на панели; забрасываю на выполнение мой скриптик. Мой скрипт обнаружив, что просматривается сайт Инфостарт заменяет ссылку на обработку другой ссылкой, которая ведет на мой сервер, где лежит моя обработка, которая всегда будет возвращать успешность проверки.
И это я еще не хакер! Был бы хакером, то установил бы на компьютере резидентную программу, которая анализировала запросы к файловой системы. Если обращается процесс со словом designer, то отдавал бы оригинальную обработку - проверяйте сколько хотите, но если обращается на чтение процесс платформы в режиме предприятия, подсовывал бы свою модифицированную обработку.
информация одновременно открыта для чтения - все могут видеть все НО + информация защищена от изменений из вне. изменять могут только те для кого эта информация предназначена
1. Провести расследование и восстановить документ в первоначальном виде.
2. Плюнуть на все и отказаться от дальнейшего использования системы безопасности.
3. Попросить знакомого китайского майнера задействовать его ферму для восстановления правильной цепочки.
Исходя из этого, я и утверждаю, что мой контроль дает гарантию неизменности.
Так объясните?
предлагают ту же задачу решать другими способами. Вопрос в чём преимущество именно этой технологии для решения конкретной задачи? А не любой другой технологии.
Вопрос в том когда блокчейн для решения задачи это хорошо. Что бы не было "блокчейна" ради "блокчейна".
Одно из преимущество в (56) описано
Но так как тут сеть из 1 узла, то смысла в ней конечно нет.
А для контроля неизменности достаточно версионирования, что в 1с уже есть, и даже в платформе.
Ведь если есть полный доступ к базе, то можно удалить все ключи позднее документа и все пересчитать заново
Я ведь не биткоины майнить предлагаю, а сделать такую систему, чтобы сахар со склада не воровали.
Так блокчейн пока за руку не ловит. То что в программе не изменили, не означает что со склада не унесли.
Значит область сужается до того что система только отслеживает изменения в базе.
Проблема, когда унесли, изменили в базе и никто не узнал.
А с моей системой за эти несчастные 9 пачек придется потратить ресурсы, которых хватит на один биткоин. 9 пачек ведь не стоят один биткоин?
Раскроется факт что что-то изменили, но в каком объекте будет неизвестно.
"А с моей системой за эти несчастные 9 пачек придется потратить ресурсы"
Не придётся.
Но в общем и целом, если сократить круг держателей базы транзакций до участников некоторой хозяйственной деятельности, то интерес к этой технологии может быть оправдан и необходимости в дополнительной математике уже не будет, т.к. любой узел просто не даст поступить изменению, а записи в узле с изменениями при первом входящем пакете с контрольной суммой будут скомпрометированы и признаны недействительными и система перейдет в режим синхронизации разрушенных ("подмененных") блоков.
Насчет сложности в обработке генерации - примерно то же самое. Вообще атака путем подмены кода - легка, изящна, и... легко отражаема.
или удалили все документы Блоков - и все понятно что кто-то залез а где и что изменяли - непонятно
Что касается удаления блоков. Так ведь и базу можно легко удалить. И что вы тогда делать будете?
Я хочу иметь безопасную базу - я закачиваю безопасную обработку.
Все просто.
Кстати, практика работы "задним числом" потому и получила такое широкое распространение, что запрет не имел смысла. Не было надежной гарантии от изменения старых документов.
Если уж фантазировать, что нашелся человек, который может писать напрямую в базу, то почему бы ему не сделать копию базы, забрать её к себе и там, в спокойной обстановке запустить пересчет хешей за день-два. И потом залить их в реальную базу. Даже пересчет двух хешей, изменённого документа, и следующего за ним, покажет, что изменили второй документ, а не первый. И что делать?
Я не говорю, что мою систему нельзя атаковать. Я говорю, что вы, как пользователь, можете сами установить цену атаки и сделать ее бессмысленной.
Это дает огромные возможности для создание ERP-системы нового поколения.
Можно создать систему с прозрачным и надежным к взлому аудиторским следом, до бесконечности. Именно то, что повышает капитализацию предприятия для инвестора. То, чего не хватало 1С. Это возможность выхода на мировой рынок.
С точки зрения маркетинга это тоже супер!
Надо создать подсистему для типовой, возможно с облачным сервисом, который будет обладать огромными вычислительными мощностями и сдаваться для вычисления красивого хеша. Опять же майнеров перепродавать.
Из обсуждения вы можете увидеть, что я сам сначала нелестно отозвался об идее прикрутить блокчейн к обычной базе. Потом подумал: а вдруг в этом что-то есть. Понял, что есть. Идея показалась настолько простой и красивой, что ближайшие выходные были принесены в жертву тому, чтобы донести ее до уважаемого сообщества. Надеюсь, что эта публикация даст старт множеству интересных разработок. Ваша идея насчет облака очень интересна. Тут действительно открываются необыкновенные возможности. Можно наполовину майнить, наполовину обсчитывать безопасность. Можно задействовать майнеров и частично снять с них упреки в том, что они понапрасну тратят электроэнергию. Вот же сахар со склада не воруют. Есть польза? Есть.
Т.е. это не в чистом виде криптовалюта, а просто контроль последовательности транзакций. Но мне кажется и так все доверяют транзакциям стартмани.
А вообще использование блокчейна - идея интересная
Про защиту данных в базе от кого угодно и даже программиста с админскими правами...а ведь атака может быть проведена не на систему блокчейна, а на функционал показывающий отличия
Например, если делать регламентое задание, которое показывает измененные документы - его взломали и оно ничего не показывает, типо все хорошо
Это может только если какая то внешняя обработка, которая лежит где то в секретном месте, и только какие то доверенные люди знают где она, и запускают ее вручную...
Наверное проще хэши документов хранить в какой то удаленной базе, и документы будут быстро проводиться и контроль будет
и т.п.
Если говорить о кодинге в конфигураторе - то соблюдение элементарных правил это хороший тон.. Если про статью - то имхо, обязанность. Кто-то смотрит, учится на таких примерах, копирует их. А учится на подобном не стоит.
Плюсанул только за интерес к контексту и поднятое обсуждение.
Тем не менее статья подняла обсуждение и думаю данный алгоритм(не блокчейн) - может применяться в некоторых случаях, а каких надо думать =)
Хранить цепочки будут майнеры, которые могут получать доход с каждого проведения. А за хранение проведения будет платить компания, которой нужен блокчейн аудиторский след.
крипто деньги не могут быть средством накопления, но вот средством обмена запросто : товар - крипта - товар.
ресурсы даже внутри организации ограничены - поэтому можно предположить футуристическую картинку, когда руководство каждому отделу в начале месяца выделяет некоторое количество крипты для оплаты работы сотрудников IT :) .
нужно -потратили, не нужно - хорошо работаете и конвертируете эту крипту в премию :-)
Еще плюс к этому в сейчас блокчейндж работает по одному документу поиск последнего блока идет без привязки к типу документа , может стоит разделить цепочки для каждого из типов?
Прикручиваем РИБ. Включаем в блоки все документы. И вот, на уровне всей системы уже реальный механизм контроля неизменности документов (это к вопросу о применяемости). Обработку контроля вешаем на регламентное задание с отправкой письма, как только кто-то поменял в документе 100 рублей на 1 рубль и цепочка разрушилась... Вуаля))
если Вы попробуете скачать локальный кошел любой криптовалюты - то именно это и происходит. По сути, Вы себе на свой домашний ПК затаскиваете весь блокчейн от самой первой транзакции до самой последней. И периодичски еще синхроните, если хотите с кошельком работать
но я в блокчейнах не моображаю, так что, может быть несу фигню полную..
> Документ проводится, затем попадает в цепочку.
- чем это обеспечивается? если подменили "процедуру" "Документ проводится, затем попадает в цепочку"..? надо обеспечивать неизменность "процедуры"...?
Подмена кода ничего не даст атакующему. Код восстановят и его атака всплывет.
Просьба описать подробнее - где и как планируете применять данное решение.
Данный вопрос возник потому, что:
его скомпрометируют и он начнет выдавать "левые" хэши или перестанет работать - а тут отчетность, простои и т.д.) и хочется использовать блокчейн - имхо проще убрать майнинговую составляющую в функции ПолучитьКонечныйКлюч и хранить последний хэш каждого дня на этом компе (похожий пример с отличным описанием и кодом на Gitbuh можно глянуть ).
Вариант, когда у злоумышленника нет доступа к серверу/железу и т.д. думаю рассматривать смысла нет, так как здесь есть более простые реализации защиты (даты запрета, версионирование, сохранять ВерсияДанных при записи и т.д.).
Думаю, что идею защиты нужно строить на том, что злоумышленник всегда впереди, но ему просто невыгодно заниматься взломом (например, потребуется полный перебор, который с учётом закона Мура закончится к моменту, когда защищаемая информация безнадежно устареет).
Какова структура вашего блока? Т.е. у вас вы определяете "блок" как документ? Почему вы храните только один Хэш? Ведь по идее,в блоке, надо хранить как хэш текущего рассматриваемого блока, так и хэш предыдущего. При чем создавать блок (у вас документ) только в случае если есть предыдущий хэш.
Ваш подход, конечно же не кошерный (если я все правильно понял из публикации - я человек и тоже могу ошибаться), сейчас поясню:
Для работы блокчейн-пдохода - необходим принцип Доказательства работы.
Что это значит?
Доказательство выполнения работы (Proof-of-work, POW) — принцип защиты распределенных систем, основанный на необходимости выполнения запрашивающей стороной некоторой достаточно сложной длительной работы (POW-задачи), результат которой легко и быстро проверяется обслуживающей стороной (односторонняя функция).
Т.е главная особенность блокчейна заключается в асимметрии затрат времени - затраты значительны для инициатора запроса (взломщика) и весьма малы для проверяющего (нашей системы).
У вас (на сколько я вижу) данный принцип не соблюден - от этого толку от него не много, разве что действительно, тратить вычислительные ресурсы вами же.
Полезно почитать историю, если кому интересно тут:
Откуда все началось.. |
|---|
| Впервые идея Proof-of-work, прозвучала в статье «Pricing via Processing or Combatting Junk Mail» в 1993 году.
Авторы предложили следующую идею: для доступа к общему ресурсу, пользователь должен вычислить некоторую функцию, весьма сложную и ресурсоемкую, но при этом решаемую за приемлемое время. Вычисление функции на стороне клиента должно быть гораздо сложнее, чем проверка результата на стороне сервера. Одним из обязательных условий является то, что функция не должна быть амортизируемой, то есть при решении нескольких функций времени требовалось бы пропорционально их количеству. По предположению, подобные дополнительные расчёты не создают препятствий для отправки нескольких обычных писем с компьютера рядового пользователя, но необходимость постоянных вычислений делает отправку спама очень ресурсоемкой для злоумышленников. По независимым оценкам подобные системы приводят фактически к существенному ограничению количества писем, которые возможно отправить за день с одного компьютера. |
Данные о блоках (документах) и блоки необходимо хранить также децентрализовано (например на клиентах), также необходим механизм принятия блока и сообщения о новых блоках.
Когда кто-то создает новый блок (документ) - он оповещает об этом всех клиентов сети. Когда новый "клиент системы" (пользователь, который может генерировать блоки/документы) - он должен получать информацию о последнем блоке..
И еще немного надо сделать.. уже нет времени писать)) В следующий раз дополню)
Главная идея - нет никакой распределенной сети. Все работает в одной базе. Ассиметрия есть. Сравните процедуру генерации и процедуру контроля.
а в bitcoin как работает доказательство работы - Вычислением хеша ?
Суть реализации - создание реестра связанных документов, по алгоритму взятия хэша предыдущих данных (документа) для создания хэша текущего обрабатываемого документа.
Без децентарлизованной сети.. можно начать генерить "свою ветку" правильных документов и сказать что эта ветка - правильная и ничего что там везде суммы уменьшены в два раза))
теряем процедуру расчета хеша документа и контроль накрывается медным тазиком.
надо обеспечивать а) 100% надежность хранения процедуры расчета хеша и 2) обеспечивать при этом ее неизменность
- кто гарантирует что вот эта процедура расчета хеша - легитимная?
(извините, если бред)
на моей памяти гибла часть информации, забитая мной на портал. причем безвозвозвратно.
Опять же - ИС представляет свои услуги как площадки по размещению контента на условиях АСИС - то бишь не несет никакой ответсвенности если чтото гдето потеряется ;-) так что все на свой страх и риск.
Единственный вариант имхо более менее даст если эти процедуры станут дефакто стандартом использования в 1С
речь всего лишь об устойчивости системы.
если опираться на какой-то визуальный контроль - внимание вопрос - как часто его надо проводить? как обеспечить чтобы о нем не забыли?
мой мелкий опыт показывает что в тех процессах где важна стабильность работы с воспроизводимым результатом - любую визуальщину и участие человека как звена в цепочке процесса следует исключить.
грубо говоря - я должен иметь возможность КУДАТО обратиться и с высокой степенью гарантии получить верный код с которым я смогу верифицировать текущий код в случае такой необходимости.
то есть дб некий "удостоверяющий центр"
имхо как неспеца
Функция ПолучитьХешДокумента(ссылка)
хд=новый ХешированиеДанных(ХешФункция.SHA256);
хд.Добавить(ПолучитьДокументСтрокой(ссылка));
рез=строка(хд.ХешСумма);
рез=стрзаменить(рез," ","");
возврат рез;
КонецФункции Вы думаете никто не заметит?
Функция ПолучитьХешДокумента(ссылка)
хд=новый ХешированиеДанных(ХешФункция.SHA256);
хд.Добавить(ПолучитьДокументСтрокой(ссылка));
рез=строка(хд.ХешСумма);
рез=стрзаменить(рез," ","");
если рез="BEA23CC1CAA3165970E3DDE2E87D76454429494B913D71662827751 ПоказатьКонецФункции
А самое главное зачем мне или инфостарту это делать?
Тут мы приходим к ситуации схожей с линукс. Крайне сложно под нее сделать защиту, т.к. любая функция, даже системная, может быть относительно легко подменена.
точно также можно сказать
Всегда можно взять первичку и сверить с тем что в базе.
Зачем блокчейн?
разницы концептуально никакой, разница только в масштабах и длительности проверк и
.
вопрос тривиальный
"Кто будет проверять проверяющих".
решения - нет
.
;-)
Но смысл не в ИС, а в хранении процедуры проверки вне организации, возможно в виде облачного сервиса.
Опять же - если инфа осталась в бэкапах, но по какой
внедряли в этот момент новый движок или что-то иное - вот меня как пользователя когда я ищу материал - ну совсем не волнует. и вдобавок косяки исправлялись не самостоятельно службой поддержки сайта, а тогда когда я обращался что отсутствует публикация которая должна быть. Это имеет прямое отношение к надежности хранения данных - в частности верифицируемой процедуре контроля цепочки - на которую ссылается автор что при необходимости ее можно взять с портала. И откуда ее взять - если по поиску ее не найти? вручную лопатить стопицот публикаций? Траблы на сайте случаются. но ОЧЕНЬ РЕДКО. это имеет место быть и это надо признать. И вести работу чтобы это случалось еще реже. Существенного ущерба от таких очень редких траблов вроде не нанесено никому ;-) а вопрос я только поднял в контектсе обсуждения публикации, а не в плане какихто голословных обвинений (обращение в саппорт по утерянной обработке , по нераюотающему поиску
а поиск - да, починили
будем надеяться что ок.
и внезапно опять ничего не потеряется не сломается :-)
Например, в windows всегда был поиск по файлам плохой, но это не значит, что файлы пропадают.
а техподдержка - да, понемногу становится лучше.
но очень уж медленно :-)
А если привлечь компанию 1С, то на базе ее 1С:Сеть можно было бы еще смарт-контракты реализовать, которые бы программировали на языке 1С :)
Да и не очень понятно, зачем обычным пользователям предоставлять прямой доступ к БД?
Кроме того, у системы есть еще куча критичных багов :)
1) Имхо, система плохо себя поведет при добавлении реквизита.
2) Может косячить при расширении типов в реквизите (когда Неопределено появится), при изменении представлений справочников.
---
Что будет при довольно типовой операции - добавили новый реквизит в документ и через универсальный подбор заполнили для всех старых доков - десятки часов и дым из под процессора? :)
Это мне чем-то напомнило узкое место 1с7.7 - помните, там была ТА? и если начать распроводить документы с начала времен, то это было адски долго, пропорционально числу доков от начала времен до ТА. Тут мне кажется будет такое же поведение.
Первое правило безопасности - следует исходить из того, что у атакующего есть все пароли и все компетенции. Правка кода - плохая атака. Она раскрывается легко и со 100% вероятностью.
согласен, проглядел про выбранные реквизиты.
Заменим этот пункт на мое опасение, что вы добавили единую точку блокировки для всех (проверяемых) документов - пока один док проводится, остальные ждут :) Это убивает всю эффективность управляемых (построчных) блокировок и возвращает нас минимум к конфигурацию с неуправляемым режимом (табличными блокировками). А в самом плохом случае - когда мы хотим контролировать все доки в базе, мы даже получаем 1с7.7 с ее журналом документов как самым узким местом системы (ведь любой проводимый док захватывает табличной блокировкой его и все остальные ждут).
А когда документ читается то, чтобы хеш сделать (естественно, все для цели "против воровства")?
Моделируем ситуацию:
Пользователь создал документ, провел, через минуту зашел в него и подправил (и так 5 раз, допустим). Когда и как должна запуститься генерация хеша?
типа стоял вахтер и проверял пропуска, но если пропуска не было - пускал и так :-)
Как только вы воссстановили документ(справочник), процедура контроля перестает выдавать ошибку. Цепочку исправлять не надо.
Накидал по-быстрому обработку.. получилось вполне удобоваримо. Остатки записываем в строку xml а потом уже из нее получаем хеш
При этом даже если прямым доступом в БД запишем проводки, то легко вычисляется в какой момент времени изменились остатки по счетам банальной проверкой хеша в обратной последовательности документов
Как пример : программно скорректировали проводки документа - ваша проверка этого не покажет. По сути для документа ничего не поменялось (ни один реквизит не изменился).
Остаток на 01.12 какого-то товара 1шт на 10руб
Есть документ 10.12 на списание 1шт на 10 руб с рассчитанным хешем.
Если какая-то редиска добавила в 02.12 ещё 1 товар на 200руб, то при сверка хеша остатков будет видно проблему, а вот хеш движений и хеш реквизитов ничего нам не даст
С другой стороны - возможность строить цепочку на остатках, пожалуй можно будет давать пользователю системы как опцию.
Внешняя компонента? Гениально, спасибо пойду разрабатывать на 1С свой майнер, криптовалюту, нейросеть, блокчейн. Вот жеж дураки вокруг, можно же 1С использовать, а они мучаются с питоном, жавой, C++
Ибо по логике 1с документы это всего лишь данные для движений, а сам учет хранится в регистрах, соответственно, изменив движения, не меняя документы - будет совершено достаточно сложно диагностируемое злодеяние(особенно если проводки формируются не просто переносом реквизитов документа, а значения расчитываются в момент проведения).
Код
Набор = РегистрыНакопления.ИмяРегистра.СоздатьНаборЗаписей();
Набор.Отбор.Регистратор.Установить(ссылкаНаДокумент);
Код злодеяния
Набор.Записать();
Время взлома 5 минут, цена - 100 рублей.
А с учетом того, что в принципе движения могут быть и вперед относительно текущей точки времени, и это не противоречит в общем то ничему, а так же в наборе каждый элемент движения может быть на разную дату - можно натворить сущий бардак, который не сложно устранить, но сложно диагностировать.
(249) Не всегда
Вот еще пример зловредительства:
Набор = РегистрыНакопления.ИмяРегистра.СоздатьНаборЗаписей();
СсылкаНаПустойДокумент = Документы.ИмяДокумента.ПолучитьСсылку(Новый УникальныйИдентификатор);
Набор.Отбор.Регистратор.Установить(СсылкаНаПустойДокумент);
Код злодеяния
Набор.Записать();
И все вокруг бегают не понимая, почему движения есть, а документ пропал и как такое возможно.
Конечно, эти ситуации обойти можно, но это еще как минимум 2 проверки, и это уже будет не так быстро и изящно
За примеры атак - спасибо.
Для того что бы обеспечить системе неуязвимость, необходимо постоянно повышать сложность и производительность системы. В биткоине, например, каждый год в 3-5 раз повышается сложность. Вы готовы покупать каждый год новые сервера?
Тоже самое можно организовать на АССИМЕТРИЧНЫХ алгоритмах, т.е. злоумышленику нужна на порядки большая производительность, что бы переписать историю.
В этой конкретной реализации сложнее получить доступ к БД, чем переписать историю цепочки.
Да, и ассиметричный алгоритм в этой разработке как раз и используется. Смотрите внимательнее.
В текущем варианте я использую POW только лишь для того, чтобы получить короткий ключ вместо длинного.
Изначально я полагал, что атакующему придется догонять систему и тогда, можно будет задать такую сложность, что атака станет бессмысленной. Защищающий может подключить ту же видеокарту, для быстрого вычисления хешей. Тогда атакующий должен будет задействовать ASIC. Но если у него есть ASIC, зачем ему атаковать вашу систему? За это же время он заработает гораздо больше, используя свое оборудование по назначению.
В процессе обсуждения в этом топике выяснилось, что атакующий и система находятся в равном положении. Атакующий не обязан догонять. Он может начать строить альтернативную цепочку сразу же, как решит изменить какой-либо документ.
В этот момент я был склонен убрать POW из моего решения, а вместо него использовать систему визуального контроля конечных хешей. Однако, при сложности 2-3, мой POW дает ключи длиной 2-4 символа (например 22A) и работает быстро. А без POW ключ будет длиной 64 символа (например 00024887939293171D6402945C7102B84C12E513D372E5D01FA7676F46FE
Теперь самое главное, что следует понимать. Данная технология как раз и призвана защищать систему от случая "проникновения взломщика", как вы это назвали. В том то и дело, что взломщик не сможет ничего натворить, как бы странным вам это не казалось. Посмотрите еще раз внимательнее на предлагаемое решение. Если вам это не очевидно, предложите вариант действий "взломщика" и я вам объясню - почему это не сработает.
Речь не о взломе а о том, что приватный блокчейн не может быть доверенным. В указанных статьях есть подробный разбор, как владелец приватного блокчейна может влиять на его содержание, незаметно для других пользователей. Более того, есть и ещё одно важное свойство - если приватный блокчейн так сколочен, что в нём действительно нельзя ничего изменить даже владельцу, то сам блокчейн на таких настройках не нужен, его надёжность достигается другими средствами, а не блокчейном.
А в данном материале ничего об этом не сказано, что вводит потенциальных покупателей (пусть их и практически нет) в заблуждение.
Это вы не вводите людей в заблуждение. В указанных статьях описано на примерах, как ваш "блокчейн", как и любой приватный, может быть использован владельцем для подтасовки Вы в своём "материале" не описываете схему, которая бы предотвращала такую подтасовку.
Если вы не согласны с этим утверждением, то прямо здесь, в следующем посте изложите свою идею. Ждем.
Опять брешет и не краснеет) Тебе десять раз приводились примеры, как можно приватный блокчейн вертеть владельцу, но ты же не для этого пришёл, чтобы учиться чему-то, а для того, чтобы свой михчейн впаривать! Никакого вознаграждения я с тебя не получил, потому что ты изворачивался как мог.
В общем, любой твой потенциальный покупатель, которых, почему-то нет (странно, да?) может почитать статьи и убедиться самостоятельно в том. что блокчейн в этой реализации либо не нужен, либо не соответствуют заявленной надёжности. А с тобой я опять время терять не собираюсь.
Вы не могли бы заходить в ветку с чем-то конкретным, а не с бурей эмоций?
Но тогда имеет смысл еще создать хеш-ключь сразу всего периода чтобы его и контролировать первично, а уже потом разбираться какой же документ был исправлен.
Вообще-то если бы эта схема была встроена в 1С на уровне платформы для контроля закрытого периода, или контроля цепочек, то было бы очень неплохо. Многим бы пригодилось.
Цепочка = БлокиЦепочкиДокументов.НашаЦепочкаДокументов;
результат = Цепочка.ПроверитьЦелостностьПериодов;
Если НЕ результат тогда
ОбъектыСНарушениями = Цепочка.НайтиНесоответствия;
Конецесли;
Опишите, пожалуйста, свои действия в следующем сценарии:
Ваш выбор:
1) Продать свое поделие покупателю еще раз
2) Бесплатно внести измения и провести аудит документов, поставив юридически значимую подпись.
3) Начать менять задним числом условия (ну, как вы обычно делаете)
4) Ваш вариант.
Если изменения затрагивают схему сериализации документа, то вы действуете точно так же, как и в ситуации, когда вы сами по каким-либо причинам решили поменять схему. Перестраиваете журнал.
Это что бы вы к формулировке не придирались, а на вопрос о своих действиях ответили.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 717210
Создание 18.12.17 11:04
Обновление 18.06.20 12:02
Просмотры 48340
Загрузки 124
Рейтинг
134
Комментарии 291
Код открыт Да
Рубрики Математика и алгоритмы
Кому Разработчик
Тип файла Внешняя обработка (ert,epf)
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
