Снимки глобального состояния

Непростая тема. И вроде не такая уж большая . Нужно только понять, что такое согласованное состояние и изучить два алгоритма - Чанди-Лэмпорта (требует FIFO каналов) и Лая-Янга (нет требования FIFO). А что-то трудно идёт.

По книге Фоккинга разбираться сложно. Гораздо лучше написано у Кшемкальяни и Сингала. Вот ссылка на их лекцию (на самом деле, это просто кусок их книги, перенесённый на слайды).

У Фоккинга нашёл только хороший перевод понятия FIFO-канала : каналы с обработкой сообщений в порядке очереди.

Дополнение. Почитав Кшемкальяни (упомянутую лекцию и их же статью An introduction to snapshot algorithms in distributed computing), понял, что весьма упрощённо представлял себе область. На самом деле, там три группы алгоритмов:

1. для FIFO-каналов. Здесь алгоритм Чанди-Лэмпорта и его модификации ( Spezialetti and Kearns, Venkatesan, Helary). 
2. для не-FIFO.  Алгоритм Лая-Янга, Маттерна
3. для систем с каузальной доставкой. Алгоритмы Acharya-Badrinath, Alagar-Venkatesan.

Алгоритм банкира

Здесь я пишу о своём нынешнем понимании алгоритма банкира, которое пока является неполным.

Этот алгоритм - стратегия, которая позволяет ресурсы потребителям, избегая тупиковых ситуаций (deadlock avoidance). Такой алгоритм пригодится, например, операционной системе, которая распределяет процессам память, даёт доступ к принтеру и т.д.

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

Нам дано: количество ресурсов и количество потребителей (процессов). Важное ограничение алгоритма: необходимо знать максимальную потребность в каждом ресурсе каждого потребителя. 

В двух словах алгоритм выглядит следующим образом. У нас есть Available - вектор наличных ресурсов (один на всю систему) и Need - вектор потребностей каждого процесса. Просматриваем потребности процессов, начиная с первого. Если у i-го процесса Need <= Available, то система выдаст ему все нужные ресурсы. Процесс отработает, вернёт ресурсы и будет исключен из списка работающих процессов. Далее опять происходит просмотр обновлённого списка работающих процессов, определяется следующий процесс, который получит ресурсы.  

Ссылки:
Dijkstra’s Banker’s algorithm detailed explanation [ссылка] - лучшая
Wiki: Banker’s algorithm [ссылка]
What is Banker's Algorithm? [ссылка]

Репликация и модели согласованности

Нашёл несколько замечательных материалов по теме.

Consistency Models and Protocols in Distributed System [ссылка] в блоге некоего Qing-а
А еще хорошие  статей Майкла Уиттекера (молод, но уже много написал): сборник Consistency in Distributed Systems [ссылка] и его блог [ссылка]

Всё, что нужно знать о распределенной обработке данных

Наткнулся на статью со смелым названием Distributed Data Processing 101 – The Only Guide You’ll Ever Need (ссылка). И знаете, автор не подкачал. Кратко пробежался по основным уровням обработки (сбор, хранение, обработка, безопасность, визуализация). И чуть-чуть об основных архитектурах - Каппа и Лямбда. Вполне себе неплохая отправная точка для новичка в теме.

И вообще, на 8bitmen.com много интересных статей об ИТ-архитектуре банков и др продвинутых в этом плане организаций

Смарт-контракты с нуля

Как научиться писать смарт-контракты на Solidity, не имея вообще никакого представления о предмете?

Начать можно с онлайн-компилятора, который называется Remix (remix.ethereum.org). Уроков по написанию контрактов на Solidity в этом компиляторе полно в интернете. Проблема только в том, что многие из них написаны для старой версии Remix (а иногда для старой версии Solidity). Руководство, использующее новую версию, можно найти здесь.

Документация по языку Solidity - по адресу solidity.readthedocs.io, введение с примерами самых простых контрактов - здесь.

Прямо как я

Учиться чему-то и вести онлайн-дневник о процессе обучения - хорошая идея, так делаю не только я. Вот пост некой Фло из Нью-Йорка Live notetaking as I learn about distributed computing
(ссылка). Человек разработал для себя некий план (плюс список литературы), который должен помочь в изучении распределённых вычислений. Есть, что позаимствовать.

Несколько хороших статей об блокчейне

Сравнение Ethereum и Bitcoin на blockgeeks.com - статья Bitcoin VS Ethereum: [The Ultimate Step-by-Step Comparison Guide] (ссылка). Много интересных деталей:

1. Основные даты в истории развития этих двух криптовалют
2. Краткое описание proof-of-stake (протокол Casper). Майнеры делают некоторую ставку (из своих средств) при попытке сформировать новый блок. Если именно этот блок будет включён в блокчейн - майнер получит награду, пропорционально своей ставке. Если же будет замечена какая-то мошенническая активность с его стороны- его монеты будут списаны
3. Пользователь в своей транзакции может сам указывать размер награды майнеру. Чем больше награда - тем быстрее транзакция попадёт в блок
4. В Эфире различные операции стоят по-разному в единицах газа - приведена таблица "цен"
5. Эфир, как и биткоин, начался со статьи. Статьи Виталика, разумеется 😊
6. Аргументы за и против увеличения размера блока. Этот спор расколол Биткоин (произошёл хардфорк) на Bitcoin (который не стал увеличивать размер блока, вместо этого включил технологию) SegWit и Bitcoin Cash (без SegWit, размер блока стал 8 MБ).
7. В Эфире нет максимального размера блока, есть предел газа. Можно добавлять транзакции в блок, пока суммарное количество нужного для этих транзакций газа не превысит порогового значения.