​Санкции уже никогда не будут прежними

Система mBridge является крупнейшим на сегодняшний день пилотным проектом трансграничного CBDC (Central bank digital currency, Цифровая валюта центрального банка).

Это совместная разработка Китая, ОАЕ и Таиланда.

Гонконгский мост mBridge является центральным элементом планов Китая по дедолларизации.

Проект mBridge экспериментирует с трансграничными платежами с использованием общей платформы, основанной на технологии распределенного реестра (DLT), на которой несколько центральных банков могут выпускать и обменивать свои цифровые валюты (мульти-CBDC).

В сентябре более 20 крупнейших коммерческих банков участвовали в расчете реальной стоимости от имени корпоративных клиентов. Расчеты касались международной торговли и межбанковских переводов. Участвовавшие страны - Китай, Гонконг, ОАЭ и Таиланд, на долю которых приходится 19% мировой торговли товарами.

Наибольшее влияние mBridge окажет на санкции, поскольку он создает децентрализованную блокчейн-систему (DLT), где невозможно отследить попадают ли сделки под нарушение санкций.

До трансграничных переводов CBDC осталось не 20 лет, а 1-2 года.

ЦБ разразился аналитичкой про DeFi
https://www.cbr.ru/Content/Document/File/141992/report_07112022.pdf

Тут один финансовый канал @dpolarfox вспомнил интересные цитаты Брежнева. Леонид Ильич, в общем-то, поднимал не новую тему и к проблемам децентрализации она имеет самое прямое отношение. Насколько мы можем хоть что-то изменить, изменив технологию?
В этой же связи можно вспомнить Iron law of oligarchy Роберта Михельса: как бы демократически не начиналось то или иное движение, всё заканчивается диктатом олигархии. Если посмотреть на мир крипты, то мы увидим прямо сегодня в новостях историю Binance и FTX, олигархический междусобойчик, подковёрная борьба и кидалово, банкротство. Что-то совсем это далеко от идей peer-to-peer cash.
С другой стороны, мы же не живём под властью римских императоров. Всё проходит свой круг бытия. Демократия, олигархия, тирания, крах. Затем по новой.

Разговоры в курилке

Ссаными тряпками https://www.bloomberg.com/news/articles/2022-11-23/new-york-governor-hochul-signs-moratorium-to-curb-crypto-mining

Оцените количество исправлений в спецификации CommonMark на 7м году её разработки https://spec.commonmark.org/0.30/changes.html В частности, они вымарывают понятие whitespace, потому что спейс спейсу рознь, как оказалось. Мой личный опыт работы с Markdown такой же: лучше не менять парсер, а то нужно будет перепроверять весь массив текста на косяки. И даже официальный парсер с сommonmark.org меня радовал багами. Большой плюс, конечно, в том, что Markdown легко писать. А потом... наступит потом.

Между тем, Markdown в целом уже вполне себе совершеннолетний формат, ему 18 лет. Тем не менее, разработка спецификации с какой-то более-менее полной совместимостью между реализациями уже 7 лет буксует. И это при крайней, исключительной минималистичности формата.
Сложность имеет комбинаторный характер. Это можно обратить в благо, когда система из ортогональных и крайне простых компонентов демонстриует сложное поведение в положительном смысле (гибкость, большие возможности).
Это может работать и во вред, когда крайне минималистичная система настолько непредсказуемо и комбинаторно сложно взаимодействует внутри себя, что остаётся только объявить баги фичами и гордиться ими.

А лучший парсер для Markdown кто-то однажды сделает на основе нейросетей. Это, он скажет, вложенный список, ну потому что "я так ощущаю". А вон то вот - нет, не список, это просто италик после hard wrap так разбросало.

Однажды я изобрёл очень красивый способ хранения Мёркловых деревьев и очень гордился этим. Как оказалось, в тот же год его изобрели два исследователя. А в 2019 его же изобрёл Russ Cox, известный гений из команды разработчиков go, тоже очень гордился.
Поэтому, вот три ссылки про двоичное Мёрклово дерево для append-only логов и потоков и про его хранение в append-only файле/массиве
https://www.rfc-editor.org/rfc/rfc7574.html
https://research.swtch.com/tlog < наиболее доступно написано
https://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf
То есть, правильно пишем раскладку дерева в файл и всё просто: реализация Мёрклова дерева для лога - это просто ещё один лог (с хэшами). Крайне мало кода, никакой БД, просто написать правильные формулы.
По степени переизобретания и гордежа, эта структура данных уступает weave, но тоже неплохо.

Письма с фронта

# Code is hypertext, IDE is a browser

Спасибо Сергею Булгакову, выкладываю своё выступление на внутренней конфе JetBrains весной 2018. Качество звука ещё хуже, чем качество доклада, а вот картинки порассматривать можно.

На тот момент в JetBrains есть что-то около трёх проектов сетевого IDE:
уже почти продуктовый Datalore Костика и Ко, X-серверо-подобная сетевизация IDEA от Жемерова, и проект Зайцева. Ну и ваш покорный слуга со своими идеями тоже затесался тогда в эти ряды.

В чём смысл сетевого IDE? Ну, очень просто. Во-первых, проекты стали сильно большими и всё править, индексировать, билдить и отлаживать на лаптопе разработчика становится уже сложновато. Кроме того, разрастаются команды разработчиков и весь процесс становится всё более коллаборативным. Соответственно, возникает вопрос, как делать сетевую IDE - нужна целостная концепция.

Моя точка зрения была примерно такая: требуется сетевая система контроля версий, работающая в реальном времени. Она должна крутиться в ядре IDE и принимать/отправлять/синхронизировать данные между разными частями системы. Как код, так и различные аннотации, так и задачи, и прочее разное.

Единственная заминка, что сейчас подходящей системы нет (а в 2018 тем более), хотя её основные принципы в CRDT сообществе обсуждаются уже лет 10. Такая система контроля версий должна позволять, в том числе, бранчи - оверлеи. В том плане, что в отдельные бранчи кладётся не только код но и, например, аннотации к коду. Где-то на сервере крутится демон, разбирает и аннотирует код, мы подключаем бранч - видим аннотации, отключаем - не видим. Код и данные для этого имеют адресацию, устойчивую к изменениям, так что можно строить граф данных, а не только версионировать текст. Ну и внутри всё на CRDT структурах данных, чтобы работал конкурентный доступ. Идиллия, только реализовать сложновато. Очень непохоже на то, как раньше писали - и накопленные за десятилетия трюки и тулзы поэтому не работают.

Получается скорее даже не собственно система контоля версий, а система синхронизации данных самого общего назначения. В которой мёржится всё со всем. "Смёржить, но не смешивать. Бонд, Джеймс Бонд." Это всё довольно нетривиальная задача, хотя, повторяю, эта тема лет 10 обсуждается в сообществе, а основные примитивы придуманы в конце 70-х. Но, я тут уже приводил статистику, сколько строк кода есть в git — как в среднего размера базе данных. При очень базовом наборе функций и идеально простой модели. Для CRDT пока сколько кода не написано увы. Но пишется потихоньку.

Сетевое IDE JetBrains, которое сейчас в бете, преследует гораздо более скромные цели - коллаборативная работа, если потребуется, нескольких участников на хорошем интернете. Синхронизация данных там от Зайцева, и сделана в идеологии Datomic/Datascript, триплетами. В notion и его клонах, кстати, так же сделано. Кое-кем из здесь присутствующих. Есть кстати ликбез по подходу от ещё одного кложуриста - Брагилевского. Вот собственно всех российских кложуристов я и упомянул в этом посте, да и те уже уехали все.

В общем, четыре года прошло, прогресс есть, счастья пока нет.

А вот и видео.

Идея ноутбука-ширмы из 4х плоскостей меня вот так вот сильно заинтриговала. Это скорее получается "рабочая станция" с разными форматами использования.
P.S. Не, скреплять это всё намертво смысла нет. Гораздо веселей - возможность использовать планшет, как дополнительный экран через USB-C и какие-то крепления дополнительные, чтобы это всё сцеплять в произвольных комбинациях.

Цифровой рубль всё-таки на блокчейне сделали, по данным Коммерсанта. Лично мне такой выбор непонятен. Что блокчейн per se не масштабируется толком (даже без PoW) известно с момента изобретения.
P.S. В официальной презе деталей мало

У кого мало развита паранойя - советую на ночь читать статьи Мордехая Гури про эксфильстрацию данных из air-gapped компьютеров. То есть, беспроводной карты нет, провода нет, передаём данные всякими интересными способами:. Например, создавая нагрузку на RAM, наводим электромагнитные колебания на частоте WiFi и так отправляем данные на близлежащее оборудование с WiFi модулем (смартфон, раутер).
Примерно так же можно и через GSM. Основная сложность таких методов - низкая пропускная способность и малая эффективная дистанция, но если у вас в кармане всегда смартфон, то проблем никаких нет, получается.
Это всё и объясняет паранойю криптанов, которые покупают за наличку свежий ноут, арендуют машину и делают свои крипто-дела в пустыне, на скорости не менее 100кмч.

P.S. по ссылке есть видео демонстраций

Вот немного на тему, про которую я частенько высказывался - миграция git на SHA-256 отменилась сама собой. Эффект понятный: поскольку SHA-1 хэши используются в качестве идентификаторов, на них завязано довольно много кода. Сам по себе git довольно большая система, но некий доброволец brian m. carlson по видимому проделал эту неблагодарную работу - везде сделал код переключаемым на SHA-256.
Но неразрешимая проблема в том, что множество других систем (напр GitHub) интегрируются с git и количество кода в них - необозримо. Кто это всё вызовется мигрировать? Лес рук 😂
Поэтому, git остаётся со штопаной версией SHA-1 на обозримую перспективу (навсегда).
Какой из этого вывод интересный? Становится очевидно, что git это не приложение, а сеть. Не codebase, а protocol. И управляется законами сетей. Нельзя тут просто переписать и выпустить версию 2.0. Посмотрите на IPv6, его уже 30 лет выпускают, а прогресс крайне скромный.
Как можно решить проблему с продырявливанием крипто - я рассказывал в докладе про RON. Крипто должно быть отдельным слоем, заменяемым. Это немножко портит концептуальную чистоту в том плане, что хэш это true name of the data. Но как имя хэш имеет слишком много недостатков.

Такие вот интересные мысли приходили в голову 10 лет назад.