Нужны абсолютно прозрачные выборы? — Их есть у меня

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
На дворе XXI век, а мы продолжаем голосовать «камешками». Давайте это менять. Тем более, что «цифровых» инструментов для этого становится всё больше и больше.

Системы электронного голосования разрабатываются во всём мире. Упор делается как на железо (например в Индии (1) и у DARPA (2)), так и на софт (ElectionGuard (3) и электронные выборы в Мосгордуму (4)). Здесь мы поговорим о части, которая относится к софту.

В обеих системах (ElectionGuard и системы для Мосгордумы) упор делается на защиту передаваемой информации от браузера голосующего до хранилища системы, а также на охрану анонимности голосования. Безусловным плюсом системы ElectionGuard является возможность пересчитать результаты голосования любым желающим. Достоинство системы для Мосгордумы — хранение данных в блокчейне, что гарантирует неизменность уже внесённых данных. Но в описании обеих систем нет информации о способах защиты от внутреннего «вброса» голосов. При хранении анонимных данных сделать «вбросы» изнутри системы теоретически достаточно просто.

Представляем вашему вниманию абсолютно прозрачную систему голосования с возможностью пересчёта голосов любым желающим и полным отсутствием возможности «вброса» голосов изнутри — ЗаКого.рф (5)!

Первое достигается хранением данных в блокчейне. Второе — неанонимностью голосования. Ииии погодите кидаться всякой дрянью… Сейчас вы всё поймёте.

Мы используем два блокчейна:

  • «закрытый», для хранения информации о том, кто и как проголосовал;
  • «открытый», для хранения анонимной информации о голосовании и хэша соответствующего «закрытого» блока.

Доступа к «закрытому» блокчейну нет ни у кого, кроме хозяина системы. Данные «открытого» блокчейна могут быть скачаны для проверки любым желающим. Скрипт проверки прилагается. Учитывая, что хэш «закрытого» блока хранится в «открытом» блоке и также участвует в расчёте хэша «открытого» блока, изменение «закрытого» блокчейна невозможно.

Теперь поговорим о неанонимности. Хранение информации о голосующем позволяет специальным органам проверить отсутствие «вбросов». Берём определённый процент от всех блоков, для каждого блока смотрим информацию о голосующем, связываемся с ним и узнаём, правда ли, что он голосовал. При полной анонимности в хранилище можно загрузить практически любое количество нужных голосов. При этом способ организации хранилища значения не имеет.

Что важнее: анонимность голосования или прозрачность выборов? Человечеству ещё предстоит ответить на этот вопрос. Для меня ответ очевиден: государство стоооолько уже знает обо мне, что ещё немного знаний мне не повредит (качество охраны этой информации оставим за рамками статьи).

В следующих версиях мы планируем:

  • заменить авторизацию через соцсети, на авторизацию через Госуслуги;
  • воспользоваться опытом проектов ElectionGuard (3) и Мосгордумы (4) по защите данных на этапе от браузера пользователя до хранилища системы.

P. S. Кстати, первое абсолютно прозрачное голосование уже идёт (на примере выборов глав регионов). Присоединяйтесь на ЗаКого.рф (5)!

Ссылки:

  1. Электронная машина для голосования в Индии;
  2. Электронная машина для голосования по заказу DARPA;
  3. ElectionGuard от Galois и Microsoft;
  4. Электронные выборы в Московскую городскую Думу;
  5. Наша система ЗаКого.рф.
Источник: https://habr.com/ru/post/466561/


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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «The real reason why JavaScript has arrow functions» автора Martin Novák. * фраза-мем из игры Skyrim Читать д...
Добрый день всем! А дело было так: звонит поздно вечером девушка из Мегафона и лепечет что-то про скидочные купоны-талоны, которые появятся в моём личном кабинете. Мол, это просто парт...
Всем привет. Когда я искал информацию о журналировании (аудите событий) в Bitrix, на Хабре не было ни чего, в остальном рунете кое что было, но кто же там найдёт? Для пополнения базы знаний...
Если в вашей компании хотя бы два сотрудника, отвечающих за работу со сделками в Битрикс24, рано или поздно возникает вопрос распределения лидов между ними.
Если Вы используете в своих проектах инфоблоки 2.0 и таблицы InnoDB, то есть шанс в один прекрасный момент столкнуться с ошибкой MySQL «SQL Error (1118): Row size too large. The maximum row si...