Ризомное программирование. Попытка постичь программирование смарт- контрактов в блокчейн- архитектуре.

Когда начинаешь изучать, как программировать смарт-контракты, понимаешь, что “все так и не так”. :-)

Действительно, буквы те же, слова те же,  классы, функции… Serpent - это Python, Solidity - JS.  Но почти сразу выясняется, что привычную структуру модулей организовать не получится, по папочкам все не разложишь. И вообще, в один смарт-контракт тысячами строки писать не стоит, так как блокчейн и плата за газ. То есть да, то что мы привыкли расходовать без счета (хвала Гордону Муру) - циклы процессора (да и память тоже) в эфире жестко лимитировано оплатой за выполнение инструкций.

Но это не самое… необычное… Введенное еще Винером правило разделения кода и данных в блокчейн-программировании тоже размывается… Блокчейн, с одной стороны, - это база данных, но каждая транзакция несет в себе встроенную процедуру - смарт-контракт, пусть даже самый простой - передача фиксированной суммы между кошельками… А выглядит это как данные...  То есть, с другой стороны, - это аналог системы контроля версий?!

То есть, мое любимое структурное программирование, когда-то описанное Э.Дейкстрой здесь точно применить нельзя. Думаю, в том числе, и из-за этого питоноподобный Serpent  не пошел в широкие массы, и сейчас его заменяют на Solidity, который ближе к JS и C.

Следовательно, нужна другая метафора архитектуры, и, глядя на то, как можно обращаться с вызовами смарт-контрактов, мне пришло в голову это spaghetti-style.

Однако с юности я помню, что так программировать нельзя. И я стал думать дальше.

Что похоже на спагетти, но не спагетти? Где есть внутренняя структура?

Вот корневая система какого-то растения:

Вот система грибницы - мицелия.

А вот - структура социальной сети.

Думается мне ( и не только мне), что все эти структуры объединяются метафорой ризомы. Философия ризомы (фр. rhizome «корневище») — одно из ключевых понятий философии постструктурализма и постмодернизма, введенное Ж. Делёзом и Ф. Гваттари в одноименной книге 1976 года и призванное служить основанием и формой реализации «номадологического проекта» этих авторов см. Вики.

 Но как программировать в ризоме, не сваливаясь в спагетти-стайл?

То есть, можно представить, что смарт-контракты - это грибы, плодовые тела  грибницы или корневой системы - ризомы, а корни - это связи, вызовы между ними.

Что дальше?

Цитата из Вики:
Делёз и Гваттари называют следующие основные свойства ризомы: (1) связь, (2) гетерогенность, (3) множественности, (4) незначащий разрыв, (5) картирование, (6) декалькомания (в смысле фрактальности повторения).

То есть, по дедукции, ризомное программирование должно учитывать особенности ризомы.

1 and 2: Principles of connection and heterogeneity: "...any point of a rhizome can be connected to any other, and must be," по переводу Brian Massumi

Связь - вообще крупные программные продукты и так отличаются “ризомностью”, большим количеством межмодульных связей, ради чего и было придумано объектное программирование и принцип “связного, низкосцепленного кода”. Есть подозрение, что  такой  код в смарт-контрактах построить не удастся.  Ближе всего к ризомности архитектура мультиагентных сетей, каждый смарт-контракт выступает как программный агент.

 

Гетерогенность  - нужно учитывать то, что различные смарт-контракты в блокчейн-ризоме могут быть разработаны самыми разными программистами, командами, с разными стандартам кодирования. Возможные выходы - или максимально высокая стандартизация интерфейсов между смартконтрактами, либо повышение их интеллектуальности через семантизацию и/или, опять же  привлечение дополнительных агентских систем искусственного интеллекта.

Multiplicity -  Множественности

“ only when the multiple is effectively treated as a substantive, "multiplicity" that it ceases to have any relation to the One”

Философия ризомы вводит понятие множественности - как противоположности структуре, дереву, структуре.

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

В блокчейне будет появляться все больше смарт-контрактов со схожей функциональностью. Чтобы остановить лавинообразный рост сущностей, скорее  потребуется создание “блокчейн-библиотек” - стандартизированных смартконтрактов с типовой функциональностью.

Незначащий разрыв

“a rhizome may be broken, but it will start up again on one of its old lines, or on new lines”

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

 Principle of cartography and decalcomania: a rhizome is not amenable to any structural or generative model; it is a "map and not a tracing"

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

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

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

Возможно, такие функции не удастся реализовать полностью в смарт-контрактах и потребуется еще один уровень аналитики, в виде модуля ERP системы. см. сайт DARFChain