Разработчик криптографических протоколов и децентрализованных систем

Домашнее задание №1: ДЗ1 - классические white papers
Прочитать:
- whitepaper Bitcoin
- whitepaper Ethereum

Результат нужно оформить на портале сообщением-ответом на вопрос "что есть криптовалюта". Сообщение должно содержать не более 4-х слов (без учета предлогов), юмор в тему приветствуется :)

Домашнее задание №2: ДЗ2

• просмотреть код контрактов заданного преподавателем проекта, найти место, реализующее определенную логику и привести diff, изменяющий поведение смарт-контракта:
  • https://github.com/gnosis/MultiSigWallet/blob/master/contracts/MultiSigWallet.sol - сделать, чтобы с баланса multisig-контракта за одну транзакцию не могло бы уйти больше, чем 66 ETH
  • https://github.com/OpenZeppelin/openzeppelin-contracts/blob/f2112be4d8e2b8798f789b948f2a7625b2350fe7/contracts/token/ERC20/ERC20.sol - сделать, чтобы токен не мог быть transferred по субботам
  • https://github.com/mixbytes/solidity/blob/076551041c420b355ebab40c24442ccc7be7a14a/contracts/token/DividendToken.sol - сделать чтобы платеж в ETH принимался только специальной функцией, принимающей помимо ETH еще комментарий к платежу (bytes[32]). Простая отправка ETH в контракт запрещена
• diff разместить так, чтобы удобно было посмотреть все кейзы (на github или в хорошо отформатированном виде в сообщении)

Домашнее задание №3: ДЗ3 - пишем смарт-контракт и тесты к нему
Разработать контракт и тесты с использованием фреймворка truffle, как было показано на знаятии. Логику контракта выбрать из нижеприведенного списка. Задание делать в своем публичном репозитарии, в README - обязательно описание как скомпилировать код и запустить тесты. Тесты, покрывающие много логических ветвей (каждый "require", каждый "if") - плюс. Screencast работы с задеплоенным в testnet контрактом - плюс.

Дополнения "[на проект]" предлагают вариант дополнительных функций, которые позволят развивать это ДЗ далее, как курсовой проект

Варианты:

• коллективная покупка товара за ETH с произвольных адресов
  • [на проект] - с “заказом” в контракт отправляется ipfs_hash от файлом-строкой, где указан  адрес заказчика. Файл зашифровывается только для получателя платежа (его публичным ключом). После покупки поставщик сможет расшифровать адреса каждого покупателя своим приватным ключом. 
• голосование за заданную строку заранее фиксированным набором голосующих (< 10)
  • [на проект] с homomorphic сбором голосов как в waves, т.е. нельзя увидеть кто как голосовал, но в конце головования можно публично проверить сумму голосов
• governance токен: распределяет входящие ETH на несколько адресов в долях, пропорциональных балансам governance токена
  • [на проект] - сделать все административные функции (удобное добавление новых участников, перераспределение долей)
• своя идея контракта,  утвержденная преподавателем. Предлагаемая логика должна использовать взаиморасчеты в ETH или ERC20 токенах и не менее 3-х участвующих сторон

Домашнее задание №4: ДЗ4 - псевдослучайное распределение
 
Сделать программу - консольное приложение, используя языки: С/C++, Rust, Python, Go, Node.JS. Код должен быть оформлен в  отдельный репозитарий на GitHub c инструкцией в README.md как собрать и запустить код в консоли под Ubuntu 18.04

Программа принимает три параметра командной строки, типа:

./program --file <filename> --numbilets 20 --parameter 42

Параметры: имя файла с ФИО студентов, число билетов, параметр, меняющий распределение. Затем, программа равномерно и детерминировано выдает в консоль строку из файла + номер билета. Номера билетов детерминированно связаны с ФИО и параметром, меняющим распределение. 

Входные данные (параметры командной строки):
1) файл, где каждая строка - это ФИО студента, типа:

Иванов Иван Иванович
Ярцев Ярослав Ярославович
...
Петров Петр Петрович

2) число билетов N (билеты нумеруются с 1 до N (включая N))
3) численный параметр, детерминированно меняющий распределение (при его изменении распределение номеров билетов максимально изменяется). При использовании одного и того же параметра, одна и та же строка Фамилия-Имя из файла всегда генерирует один и тот же номер билета

Выходные данные: вывод в STDOUT строк вида:

Иванов Иван Иванович: 21
Ярцев Ярослав Ярославович: 12
...
Петров Петр Петрович: 11

 

Домашнее задание №5: ДЗ5

Сделать программу - консольное приложение, используя языки: С/C++, Rust, Python, Go, Node.JS. Код должен быть оформлен в  отдельный репозитарий на GitHub c инструкцией в README.md как собрать и запустить код в консоли под Ubuntu 18.04. К заданию должен быть приложен скриншот или текст вывода одного или нескольких прогонов программы(!).
Программа эмулирует работу автомобильного брелока, открывающего машину, с использованием ЭЦП в условиях, когда канал связи полностью доступен любому прослушивающему (в том числе и в течение большого времени и попыток), также атакующий может повторить прослушанные данные. 
То, что передается в реальном протоколе по сети в программе просто записывается в переменную и передается функции следующего шага в виде параметров, типа:

let handhsake_data = trinket_generate_hasndshake(...);
printf(“...trinket->car send data: ....”, handhsake_data);

let challenge_data = car_process_handshake(handshake_data);
printf(“... car->trinket send data: ...”, challenge_data);

let response_data = trinket_process_challenge(challenge_data);
printf(“...trinket->car send data: ....”, response_data);

Возможны различные варианты построения протокола, вот один из них:

1. Handshake. На этом этапе брелок отправляет машине код команды (любые данные, в истинности которых машина должна удостовериться) 
2. Challenge. Машина отправляет брелоку данные, с которыми брелок должен что-то сделать, что докажет машине, что это именно ее брелок
3. Response. Брелок делает то, что нужно, отправляя машние доказательство того, что это именно он отправил Handshake
4. Машина проверяет доказательство и исполняет команду

Программа последовательно демонстрирует этапы протокола, печатая в консоль кто кому и какие данные отправляет. Код желательно оформить так, чтобы можно было удобно идентифицировать каждый шаг протокола и связать его с выводом в консоль. В протоколе необходимо использовать один из алгоритмов генерации и проверки ЭЦП (любой алгоритм). Некоторые данные могут храниться одновременно и в брелоке и в машине (прописываться когда ключ “привязывается” к машине). 


Пример вывода программы:
 

0: (registration) 0xXXXXXXXXXXXX (pubkey1 written to trinked), 0xXXXXXXXXXXXXXX (pubkey2 written to car)
1: (handshake) trinket -> car, 0xXXXXXX (id command), 0xXXXXXXX (challenge for car)
2: (challenge) car -> trinket: 0xXXXXXX(challenge for trinket), 0xXXXXXXX (confirm challenge for car)
3: (response) trinket->car: 0xXXXXXXX (confirm challenge for trinket)
4: (action) car: check response - ok, OPEN DOOR

Логика, последовательность шагов, внутренние данные - все это вы проектируете сами, единственное требование - генерация и проверка ЭЦП. Рекомендуется сначала спроектировать протокол с пустыми mock-нутыми функциями generate_sig() и verify_sig() и лишь в конце использовать криптографичекую билиотеку.

P.S. плз, помните, что нам проверять задание, не надо строить проекты из десятков файлов с обработкой любых параметров. 

Домашнее задание №6: ДЗ7
 
Сделать программу - консольное приложение, используя языки: С/C++, Rust, Python, Go, Node.JS. Код должен быть оформлен в  отдельный репозитарий на GitHub c инструкцией в README.md как собрать и запустить код в консоли под Ubuntu 18.04. К коду должен быть приложен скриншот одного из запусков в консоли.

Программа, разделяет секретную строку в hex формате длиной 256 bit (например, приватный ключ ECDSA secp256k1) на N частей по схеме Шамира и восстанавливает его при предъявлении любых T частей.

Аргументы командной строки:
Единственный аргумент указывающий режим работы программы:

• ./your-program split - режим разделения
• ./your-program recover - режим восстановления

# разделение секрета:
./program split
# восстановление секрета
./program recover

Входные данные - mode split (stdin):
1 строчка - Приватный ключ (P_KEY)
2 строчка - Два числа N, T, где 2 < T <= N < 100

Выходные данные - mode split (stdout):
N строк, в каждой строке содержится кусочек разделенного секрета(в виде string)

stdin:
0xb04a9a2d251cd...6bd566468
3 2

stdout:
0x2b0a36a4058f8a..b0a36405f
0x6d0a362b58f8aa..40a4058f8
0x40a05f86a4058f..8a2b83a6d

Входные данные - mode recover (stdin):
T или более строк с кусочками секрета(в каждой строке кусок секрета в том же формате что и вывод программы в режиме split)

Выходные данные - mode recover (stdout):
Приватный ключ (P_KEY), в таком же виде что и перед разделением

stdin:
0x2b0a36a4058f8a..b0a36405f
0x6d0a362b58f8aa..40a4058f8
0x40a05f86a4058f..8a2b83a6d

stdout:
0xb04a9a2d251cd...6bd566468

 

Домашнее задание №7: ДЗ10 - проектирование курсовой работы
Подготовить стартовый репозитарий и README.md с верхнеуровневым описанием проекта, который собираетесь сделать в качестве курсового. 

Домашнее задание №8: ДЗ11 - полная инфраструктура DApp
Необходимо разработать в своем едином репозитарии GitHub простейший DApp который:

• принимает от пользователя бинарный файл (например, PNG)  и загружает его в IPFS (в свою ноду)
• хеш загруженного файла отправляет на хранение в простой смарт-контракт, хранящий mapping (address => ipfs_hash)
• по запросу, получает ipfs_hash из контракта (используя текущий адрес), достает его из IPFS, и демонстрирует в браузере

Проект дожен работать на локальных dev-версиях софта: Ethereum нода, IPFS нода, node.js запущенный локально.
В README должна быть рабочая инструкция как с нуля запустить проект на локальной машине (запуск локальной ноды, деплой контракта в нее, запуск локальной  IPFS ноды, запуск и конфигурирование DApp (указание в нем адреса контракта и location IPFS ноды) и описание последовательности действий чтобы воспроизвести цепочку “залить файл, записать в контракт, прочитать из контракта, скачать и показать файл”. Несмотря на простоту контракта, тесты должны быть представлены хотя бы минимально.