Несколько технических вопросов к ДЭГ

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

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

Главный редактор эХО Москвы, Венедиктов, который упорно проталкивал ЭГ, и утверждает, что всё честно, и никто его ни в чём, обратном, не убедил.

Вопрос технический и интересный. И поэтому, я изучил Что же не так с ДЭГ в Москве? от Жижина. Зашёл на https://observer.mos.ru/all/ и скачал дампы базы данных, которые лежат там, PostgreSQL server и попробовал разобраться, что именно не так.

Техническая сторона, первое впечатление

Для изучения, я выбрал БД в которой информация о "Выборах депутатов Государственной Думы Федерального Собрания Российской Федерации восьмого созыва по одномандатному избирательному округу.", файл: observer-20210921_143000.sql

Всё очень плохо.

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

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

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

Как это происходит и почему?

Это происходит потому, что БД на https://observer.mos.ru/all/ создавалась не для работы, а именно для целей наблюдения. И была сделана абы как. Нельзя утверждать, что это было сделано специально, чтобы сделать невозможной проверку голосования. Потому, что если это просто "какая-то" база для наблюдателей, то с ней никто особо возиться не стал, и тем более проверять и тестировать, а потому и сделали криво и косо.

Техническая сторона. Знакомство с БД

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

  2. таблица "transactions" - главная таблица, где есть всё (что туда положили), а мы, из других материалов изучения этих данных уже знаем, что туда положили далеко не всё. Поле method_id, содержит код назначения этой транзакции, (описание взял у Жижина) важные для нас: 1 - регистрация избирателей, 4 - выдача бюллетеня, 5 - проверка доступа голосующего, 6 - приём бюллетеня (с зашифрованным голосом), 9 - расшифровка голоса

  3. таблица: "decrypted_ballots", содержит хэши транзакций с id 6 и id 9, и результат голосования в расшифрованном виде

Техническая сторона. Изучение данных

  • таблица "blocks", как оказалось, содержит множество пустых блоков. Создаётся впечатление, что система, зачем-то постоянно создаёт блоки, без особой зависимости от того, есть данные или нет. Как будто они создают некий time lapse, подтверждающий, что всё работает, просто операций нет. Теоретически, в этом нет ничего плохого, но и хорошего тоже нет. На графике, это выглядит это примерно так:

  • таблица "transactions" - главная таблица, где есть всё (что туда положили), а мы, из других материалов изучения этих данных уже знаем, что туда положили далеко не всё.

    • И тут возникает проблема, транзакции c method_id 1 и 4, содержат "voter_id" в виде "22443685531066461899103156899237857105006237160299631129744914447305194856993", а транзакции c method_id 5 и 6, содержат связанные поля voter_key и author в виде хеша "78cc1e391507d9ef8bcddfbf72d1cbde95c1f36f84940a5b8be4e8fa0542096a"Таким образом, связать избирателя с его бюллетенем невозможно. Есть вероятность, что voter_key это зашифрованный voter_id, но это не подтверждается, поскольку, если предполагать, что у нас в БД есть переголосования, то будут дубликаты voter_key в списке транзакций 5 и 6 типа.

    • Поиск двойных транзакций, дал результат для method_id = 4, но они не относятся к голосованию, а содержат записи об ошибках, которые произошли в одно и то же время. Всего, в базе есть 34294 избирателя у которого были записи об ошибках, и судя по времени этих ошибок (почти без интервала между ними), они носят чисто технический характер, запись в поле "status" для них выглядит так "{"type":"service_error","description":"Ballot cannot be issued","code":5,"runtime_id":0,"call_site":{"instance_id":1001,"call_type":"method","method_id":4}}". Бюллетень в результате выдаётся 1.

    • Итого, для method_id = 5 и 6, двойных записей нет, при проверке записей, где есть дубликаты voter_id, показали, что таких voter_id, в базе 34294, и всего записей, 78077. Итого, что получается?

      • method_id = 4 = 1987373 - 78077 + 34294 = 1943590 выдано бюллетеней, что соответствует данным на обсервере.

      • method_id = 5 = 2021969 записей о подтверждении

      • method_id = 6 = 2021969 записей о голосовании,

      Как такое может быть? Переголосования? но для него тоже выдаётся бюллетень (должен выдаваться, иначе как? О_о).
      Итого: 2021969 - 1943590 = 78379 лишних бюллетеней! это что вообще такое? Вбросы? но как проверить, связи с избирателями нет, просто бюллетени, которые лежат сверх тех, что были "напечатаны типографией". И этот вопрос ужа за гранью переголосований и т.п.

    • method_id 9 - расшифровка голоса, таких записей в таблице "transactions" - 1319943, что значительно меньше выданных бюллетеней, они содержат информацию о расшифровке голоса в бюллетене, и эти данные содержатся в следующей таблице: "decrypted_ballots". Почему их так мало, вопрос отдельный. Слышал такое объяснение, что данные о переголосованиях, лежат в отдельном секретном блокчейне, и вот с учётом сверки с ним, и были посчитаны голоса.

  • таблица: "decrypted_ballots", содержит 1318977 записей, что на 966 меньше чем в транзакциях о расшифровке!, Такого быть не должно в принципе! Записи попросту пропали, вдруг. Транзакции о расшифровке есть, а самой расшифровки нет. Конечно же, их можно расшифровать, но стоп. Зачем нам это делать? Есть программа, блокчейн, БД, которые должны работать. Но получается, что в их работе содержатся серьёзные проблемы, которые приводят к тому, что попросту пропадают данные.

    • Но как понимать 1318977 из 1943590 выданных бюллетеней?:

      • Можно было бы предположить, что вот эти вот 1318977 записей получились потому, что вот расшифровывали, и не успели. Такое может быть, ведь расшифровку ведь делали не одним запросом, а блоками. Но есть проблема, не расшифрованные записи в базе есть за весь период голосования. Возможно ли, что они брались не последовательно, по дате, а рандомно?

      • Есть предположение, что эта разница, с учётом того, что были переголосования, и по причине правок из таинственного скрытого блокчейна, вот эти голоса и должны быть посчитаны. Но вопрос, как тогда выглядит наша расшифровка? Ведь если есть переголосование, то отменяемые голоса, будут скорее всего в самом начале периода голосования, и их число будет снижаться к концу. Проверяем:

  • на графике видно, что динамика, действительно похожа на переголосования, но возникает вопрос, как переголосование могло быть в районе 23 часов 2021.09.19? 236 голоса, сделанные в период с 19 до 20 часов, не были посчитаны. А мы помним, что переголосовать можно только через 3 часа после голосования. В то время, как последний блок был создан в 2021-09-19 21:19:07.902+03. Если это переголосования, а система должна блокировать возможность на 3 часа, тогда, это могло быть сделано только специальным ботом, который не учёл эту особенность.

  • Возникла идея, сравнить голоса расшифрованные и нерасшифрованные, (которые вероятно отменили по вероятному переголосованию):

  • Получается лютый треш. Последние нерасшифрованные 236 голоса, просто не были учтены, в этот час и после него, просто не было новых. Поэтому, необходим точный и ясный ответ. Являются ли голоса в таблице "decrypted_ballots" полными и корректными?

    • И если да, тогда что это за такое странное расхождение в переголосованиях? то 0%, то 100%, что с этими голосами не так? Куда пропадают часть голосов и по какой причине?

    • Если нет, тогда и говорить не о чем, неверные данные = нет никаких данных, а значит не было и наблюдения за голосованием, а было просто шоу для маскировки.

Почему я не стал делать статистику?

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

Уже тех фатов того, что:

  • Бюллетеней учтено больше чем было выдано - провал.

  • Пропали часть расшифрованных бюллетеней - провал.

  • Невозможно понять, что именно происходит в базе данных - нет связи между избирателем и бюллетенем, а значит невозможно правильно посчитать - провал.

  • Понять почему расшифрованы только 65,23% - невозможно - провал.

  • Если эти данные, которые нам дали не корректны, то дайте корректные, они не могут их предоставить - провал.

Достаточно, чтобы признать систему нерабочей и отменить результаты ЭГ полностью.

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

Вопрос чем поможет статистика, если организаторы не признают прямых и очевидных ошибок?

Некоторые выводы

  1. Как вообще интерпретировать такие соотношения, неизвестно. Факт в том, что у наблюдателей, по сути нет корректного материала для наблюдения и проверок.

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

  3. Если от нас скрывают некоторые данные, то возникает вопрос - почему? Блокчейны с деньгами релат в свободном доступе, а от нас скрывают блокчейн с голосованием. Если у этого есть цель, то какая? Варианты, которые приходят в голову:

    1. Ничего не сработало и получилась куча ошибок, и данные которые нам всучили, некорректные. И скрывают сломанный, некачественный продукт.

    2. Скрывают реальные данные, поскольку они отличаются от тех итогов, которые нам предлагают как результаты голосования.

    3. Вероятно, что в реальном блокчейне, сделали вбросы, но настолько топорные, что они будут очевидны.

    4. Их секретный блокчейн содержит реальные данные избирателей, кто и как проголосовал. Увы, но система не может быть анонимной по определению. Регистрация на госсайтах не анонимная. СМС отправляются реальным людям. Поэтому, нам врут, что всё анонимно, а на самом деле нет.

    5. Любые комбинации на выбор.

  4. Если данные, которые нам предложили, нужно считать верными и полными, тогда единственны вывод, который можно сделать - система ЭГ не сработала, мы видим множество ошибок и нестыковок, которых быть попросту не может в корректно работающей системе, а если она работает не корректно, то доверять результатам её работы невозможно, а значит их следует отменить, а систему доработать.

Источник: https://habr.com/ru/post/582546/


Интересные статьи

Интересные статьи

У python одно из самых крупных комьюнити, это обусловлено тем, что этот язык любят многие за его простоту и универсальность. Очень много энтузиастов, которые создают всё ...
В этой статье я рассмотрю только один параметр, влияющий на освоение чего либо - внимание. Конечно, существуют и другие, но это вопрос других статей. Прошу в критике и ко...
Всем привет! Меня зовут Тилек, и я алкоголик пользуюсь Windows. Меня эта операционная система вполне устраивает. У меня видавший виды б/у-ный служебный ноутбук HP ProBook 4540s, котор...
Большинство списков вопросов интервью по Spring Boot заставляют вас запоминать случайные детали из документации Spring Boot. Но запоминание — плохая замена истинному пони...
Всем привет! Меня зовут Александр, я – инженер команды, отвечающей за развитие централизованных IT-сервисов, которыми пользуются продуктовые команды в X5 R...