udpate
This commit is contained in:
Alex Ant
Vendored
BIN
Binary file not shown.
Vendored
BIN
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 267 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 374 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 323 KiB |
+4
-2
@@ -1,13 +1,15 @@
|
||||
# Контакты
|
||||
<iframe style="border: 0px !important;" src="https://workflow.coopenomics.world/form/d657db5e-2e27-4f6b-b8f2-8623a2a3281d" width="100%" height="1000"></iframe>
|
||||
|
||||
| Потребительский кооператив | ВОСХОД |
|
||||
|
||||
<!-- | Потребительский кооператив | ВОСХОД |
|
||||
|----------|------------------------------|
|
||||
| ИНН | 9728130611 |
|
||||
| КПП | 772801001 |
|
||||
| ОГРН | 1247700283346 |
|
||||
| Председатель | Муравьёв Алексей Николаевич |
|
||||
| Е-почта | [chairman.voskhod@gmail.com](mailto:chairman.voskhod@gmail.com) |
|
||||
| Telegram | [@mr_alex_ant](telegram:/mr_alex_ant) |
|
||||
| Telegram | [@mr_alex_ant](telegram:/mr_alex_ant) | -->
|
||||
|
||||
|
||||
<!-- [Подпишись на мой телеграм-канал :fontawesome-solid-paper-plane:](https://t.me/dao_ants){ .md-button } -->
|
||||
@@ -1,12 +1,15 @@
|
||||
Основные компоненты ядра включают:
|
||||
Платформа кооперативной экономики основана на открытом исходном коде блокчейна EOSIO и Antelope.
|
||||
|
||||
- nodeos: Основной сервис ядра, который управляет хранением данных в блокчейне, поддерживает одноранговые сетевые соединения и планирует выполнение смарт-контрактов. Этот компонент поддерживает модульность через плагины, которые могут быть настроены для различных задач.
|
||||
## nodeos
|
||||
Ведущая программа, которая управляет хранением данных в блокчейне, поддерживает сетевые соединения, передаёт и принимает транзакции, воспроизводит состояние базы данных, исполняет действия, и так далее - т.е. выполняет всю базовую инфраструктурную работу платформы.
|
||||
|
||||
- cleos: Инструмент командной строки для взаимодействия с REST API, предоставляемыми nodeos. Cleos позволяет развертывать, тестировать и управлять смарт-контрактами, а также взаимодействовать с системой на уровне командной строки.
|
||||
## cleos
|
||||
Инструмент командной строки для взаимодействия с REST API, предоставляемыми nodeos. Cleos позволяет развертывать, тестировать и управлять смарт-контрактами, а также взаимодействовать с системой на уровне командной строки.
|
||||
|
||||
- keosd: Демон-менеджер ключей, обеспечивающий безопасное хранение приватных ключей и выполнение цифровых подписей. Keosd хранит ключи в зашифрованных кошельках, обеспечивая безопасность транзакций.
|
||||
## keosd
|
||||
Терминальый кошелёк и менеджер ключей, обеспечивающий безопасное хранение приватных ключей и выполнение цифровых подписей на сервере. Keosd хранит ключи в зашифрованных кошельках, обеспечивая безопасность транзакций.
|
||||
|
||||
- CDT (Contract Development Tools): Инструментарий для разработки смарт-контрактов на языке C/C++, который позволяет создавать, оптимизировать и отлаживать смарт-контракты, компилируемые в WebAssembly (Wasm).
|
||||
## CDT (Contract Development Tools)
|
||||
Инструментарий для разработки смарт-контрактов на языке C/C++, который позволяет создавать, оптимизировать и отлаживать смарт-контракты, компилируемые в WebAssembly (Wasm).
|
||||
|
||||
Эти компоненты обеспечивают стабильную работу операционной системы, поддерживая все аспекты взаимодействия кооперативов и их пайщиков в цифровой среде. Они обеспечивают надежность, безопасность и производительность платформы, делая ее устойчивой к внешним и внутренним воздействиям.
|
||||
|
||||
|
||||
@@ -1,29 +1,90 @@
|
||||
|
||||
### Смарт-контракты
|
||||
Смарт-контракты являются основой функционирования платформы кооперативной экономики, обеспечивая выполнение ключевых системных процессов, связанных с управлением кооперативами, их финансовыми потоками и юридически значимыми действиями. Эти контракты работают на уровне операционной системы и обслуживают базовые потребности всей сети кооперативов. Они определяют основные правила взаимодействия, проверяют права доступа и обеспечивают выполнение всех системных операций в рамках платформы.
|
||||
## Смарт-контракты
|
||||
|
||||
Перечень системных смарт-контрактов:
|
||||
Каждое действие, которое вызывается на платформе, всегда принадлежит к одному из смарт-контрактов, который отвечает за его исполнение.
|
||||
|
||||
- eosio.bios: Базовый контракт, отвечающий за инициализацию и управление параметрами блокчейн-сети. Он используется при развертывании и настройке новых блокчейн-узлов, а также обеспечивает выполнение базовых функций управления сетью.
|
||||
|
||||
- eosio.system: Контракт управления жизненным циклом аккаунтов и другими критически важными функциями блокчейн-сети, такими как управление ресурсами (оперативной памятью, CPU и сетевой пропускной способностью), обработка транзакций, управление ставками и выборами делегатов.
|
||||
!!!note "Смарт-контракт - это программа, которая прозрачно исполняется на платформе"
|
||||
|
||||
- eosio.token: Контракт, обеспечивающий создание, выпуск и управление токенами внутри платформы. Этот контракт отвечает за все операции с токенами, включая их передачу между участниками, создание новых токенов и уничтожение неиспользуемых.
|
||||
Программный код смарт-контрактов для платформы пишется на языке программирования C/C++ и исполняется в WebAssembly (WASM) в специально-подготовленной для этого распределенной среде. Платформа является хранилищем для смарт-контрактов, которые представляют из себя программный код, который реагирует на внешние действия по API, которое сами и реализуют.
|
||||
|
||||
- eosio.msig: Контракт многосигнатурных транзакций, который позволяет участникам сети создавать транзакции, требующие подписи нескольких участников перед их выполнением. Этот механизм повышает безопасность при принятии важных решений, требующих одобрения нескольких сторон.
|
||||
Каждый смарт-контракт содержит в себе строгое описание структур принимаемых и хранимых данных, а также наименования действий и требуемых авторизаций для их выполнения. Каждое действие может содержать в себе операции по изменению внутренней базы данных смарт-контракта, которая описывается в самом смарт-контракте.
|
||||
|
||||
- eosio.wrap: Контракт, предоставляющий механизм завернутых транзакций, которые могут быть инициированы и подтверждены авторизованными учетными записями. Этот контракт используется для выполнения административных функций с повышенными правами доступа, например, при замене утерянных ключей аккаунта.
|
||||
|
||||
Кроме стандартных контрактов, платформа кооперативной экономики включает следующие уникальные системные контракты:
|
||||
Платформа оперирует двумя типами смарт-контрактов: системные и кооперативные. Если системные смарт-контракты - это конкретные действия, реализующие бизнес-логику в программном коде, то кооперативые смарт-контракты соединяют простые действия в сценарии кооперации.
|
||||
|
||||
- draft: Контракт управления шаблонами документов. Этот контракт позволяет создавать, редактировать и хранить шаблоны юридически значимых документов, которые затем могут быть использованы кооперативами для автоматического создания документов на основе заданных шаблонов.
|
||||
|
||||
- registrator: Контракт реестра пайщиков, который обеспечивает регистрацию новых аккаунтов и управление процессом вступления пайщиков в кооперативы. Этот контракт контролирует правильность и легитимность процесса вступления, а также поддерживает актуальность данных в реестре.
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
КооперативныйСмартКонтракт : Кооперативные Смарт-Контракты
|
||||
state КооперативныйСмартКонтракт {
|
||||
direction LR
|
||||
КооперативныйПроцесс : Кооперативные Процессы
|
||||
ЦелевыеПрограммы : Целевые Программы
|
||||
}
|
||||
|
||||
КооперативныйСмартКонтракт --> СистемныеСмартКонтракты
|
||||
|
||||
- soviet: Контракт совета кооперативов, который получает повестку заседаний, обеспечивает голосование членов совета и фиксирует принятые решения по документам, созданным на основе шаблонов из контракта draft. Этот контракт автоматизирует процесс принятия решений внутри кооперативов.
|
||||
СистемныеСмартКонтракты: Системные Смарт-Контракты
|
||||
state СистемныеСмартКонтракты {
|
||||
registrator
|
||||
soviet
|
||||
fund
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
- fund: Контракт управления фондами кооператива, который отвечает за учет и распределение средств, находящихся в фондах кооператива. Этот контракт также может обеспечивать управление целевыми фондами, использующимися для финансирования различных программ и инициатив внутри кооператива.
|
||||
### Системные смарт-контракты
|
||||
Как было ранее сказано, системные смарт-контракты - это программный код, написанный на языке C/C++ и исполняющийся в распределенной цифровой среде. Каждый системный смарт-контракт реализует програмный интерфейс (API) и выполняет действия с собственной базой данных.
|
||||
|
||||
- gateway: Контракт шлюза финансовых потоков, который управляет процессами взносов и возврата взносов. Этот контракт обеспечивает правильность и своевременность обработки финансовых операций, гарантируя выполнение всех обязательств между кооперативом и его пайщиками.
|
||||
На платформе существует и поддерживаются следующие системные смарт-контракты:
|
||||
|
||||
- eosio.bios: Базовый контракт, отвечающий за инициализацию и управление параметрами блокчейн-сети при ёё запуске.
|
||||
|
||||
- eosio.system: Контракт управления жизненным циклом аккаунтов и другими общими функциями блокчейн-сети, такими как: аренда вычислительных ресурсов, правила эмиссии системного токена AXON, учёт участия делегатов в производстве блоков, и т.д.
|
||||
|
||||
- eosio.token: Контракт, обеспечивающий управление системным токеном AXON. Этот контракт отвечает за операцию эмиссии токена и его учёта.
|
||||
|
||||
- eosio.msig: Контракт многосигнатурных транзакций, который позволяет участникам сети создавать транзакции, требующие подписи нескольких участников перед их выполнением.
|
||||
|
||||
- eosio.sudo: Контракт, предоставляющий резервный механизм восстановления, и используется для выполнения административных функций с повышенными правами доступа, например, при замене утерянных ключей аккаунта.
|
||||
|
||||
- draft: Контракт управления шаблонами документов платформы. Этот контракт позволяет создавать, редактировать и хранить шаблоны юридически значимых документов, которые используются кооперативами для генерации документов.
|
||||
|
||||
- registrator: Контракт реестра пайщиков, который обеспечивает регистрацию новых аккаунтов и ведение обще-кооперативного реестра пайщиков.
|
||||
|
||||
- soviet: Контракт совета кооперативов, который отвечает за работу совета: получает повестку заседаний из других контрактов, обеспечивает голосование членов совета и фиксирует принятые решения в протоколах, созданных на основе шаблонов из контракта draft. Здесь же хранятся таблицы цифровых кошельков пайщиков, их целевых программ, а также, информация о кооперативных участнках и их Уполномоченных.
|
||||
|
||||
- fund: Контракт управления фондами кооператива, который отвечает за учет и распределение средств, находящихся в фондах. Этот контракт обеспечивает учёт движения средств по всем фондам кооператива.
|
||||
|
||||
- gateway: Контракт шлюза финансовых потоков, который управляет процессами взносов и возврата взносов. Этот контракт обеспечивает обработку финансовых операций при взносе и возврате взноса из кооператива.
|
||||
|
||||
Все эти системные смарт-контракты совместно обеспечивают работу атомарных действий платформы кооперативной экономики. Простые действия системных смарт-контрактов объединяются в кооперативные сценарии использования.
|
||||
|
||||
|
||||
### Кооперативные смарт-контракты
|
||||
|
||||
!!!note "Кооперативные смарт-контракты - это стандартизированная последовательность действий в кооперации"
|
||||
|
||||
Кооперативные смарт-контракты представляют из себя последовательности действий, которые необходимо вызвать в системных смарт-контрактах в правильном порядке и при правильных условиях, для того, чтобы исполнить сценарий кооперации.
|
||||
|
||||
На текущий момент реализуются следующие базовые кооперативные сценарии:
|
||||
|
||||
- Регистрация пайщика
|
||||
|
||||
- Паевый взнос
|
||||
|
||||
- Возврат паевого взноса
|
||||
|
||||
- Возврат паевого взноса с новацией
|
||||
|
||||
- Использование членских взносов из фондов
|
||||
|
||||
Которые объединяются в целевые кооперативые смарт-контракты:
|
||||
|
||||
- целевая потребительская программа "СОСЕДИ" - реализация сценария "кооперативный маркетплейс", где пайщики совершают взносы и получают возвраты взносов имуществом и деньгами.
|
||||
|
||||
Количество целевых кооперативных смарт-контрактов не ограничено. Смарт-контракты являются основой функционирования платформы кооперативной экономики, обеспечивая выполнение ключевых системных процессов, связанных с управлением кооперативами, их финансовыми потоками и юридически значимыми действиями.
|
||||
|
||||
Смарт-контракты работают на уровне технологии блокчейн и обслуживают базовые потребности сети кооперативов. Они определяют основные правила взаимодействия, проверяют права доступа и обеспечивают выполнение всех системных операций в рамках платформы.
|
||||
|
||||
Эти системные смарт-контракты совместно обеспечивают надежную и безопасную работу платформы кооперативной экономики, автоматизируя ключевые процессы управления кооперативами и поддерживая их повседневную деятельность.
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Индексы
|
||||
В качестве контейнеров для таблиц в смарт-контрактах используется объект multi_index из языка программирования C/C++.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Состояние
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Процесс включения происходит не моментально, и на финализацию транзакции требуется примерно 120 секунд. За это время все ноды делегатов должны автоматически прийти к консенсусу по их содержанию - все включаемые действия должны устраивать по-крайней мере 2/3% делегатов.
|
||||
|
||||
Подробнее
|
||||
|
||||
Те действия, которые применяются - могут влиять на состояние базы данных, или не влиять - это зависит от кода действия смарт-контракта.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Таблицы
|
||||
Смарт-контракты содержат действия. Каждое действие связано с программным кодом, который выполняется на каждой ноде при включении транзакции в цепочку.
|
||||
|
||||
|
||||
Если в действии находятся команды на изменение таблиц - то они будут применины на каждой ноде.
|
||||
|
||||
Эти команды стандартны, и как и для любой базы данных включают 4 базовых операции: создать, редактировать, читать и удалить. При этом, в случае удаления или редактирования - удаляется и редактируется только текущее состояние в базе данных, которое доступно по API, но вся история остаётся последовательной и неизменной.
|
||||
|
||||
Таким образом, при синхронизации нод, формируются таблицы распределенной базы данных на каждой ноде. И каждая нода в любой момент времени (по № блока), может извлечь информацию о том, какое состояние базы данных было в тот момент. И эта история непрерывна с самого начала - с момента запуска блокчейна.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[[транзакция -> действие 1, действие 2, действие 3 -> не изменяет состояние базы данных, добавляет запись в таблицу user, удаляет запись из таблицы order]]
|
||||
|
||||
|
||||
История транзакций образует публичную и доступную всем последовательность вызова смарт-контрактов, от момента запуска платформы. Где каждый вызов действия в смарт-контракте может исполнять команды на добавление, удаление, или редактирование записей в базе данных смарт-контракта.
|
||||
То, что делает смарт-контракт, полностью зависит от программного кода его реализации.
|
||||
+11
-31
@@ -1,30 +1,4 @@
|
||||
# Режимы работы
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph Producers["Производители (Делегаты)"]
|
||||
ProducerNode1["Производитель 1"]
|
||||
ProducerNode2["Производитель 2"]
|
||||
ProducerNode3["Производитель 3"]
|
||||
end
|
||||
|
||||
subgraph SeedNodes["SEED Ноды"]
|
||||
SeedNode1["SEED Нода 1"]
|
||||
SeedNode2["SEED Нода 2"]
|
||||
end
|
||||
|
||||
subgraph APINodes["API Ноды"]
|
||||
APINode1["API Нода 1"]
|
||||
APINode2["API Нода 2"]
|
||||
end
|
||||
|
||||
Producers --- SeedNodes
|
||||
SeedNodes --- APINodes
|
||||
|
||||
ExternalWorld["Кооперативные приложения"]
|
||||
ExternalWorld --- APINodes
|
||||
```
|
||||
|
||||
## Делегатская нода
|
||||
## Запустить ноду делегата
|
||||
|
||||
Делегат - это узел сети, который принимает участие в производстве новых блоков для цепочки. Локальная сеть кооперативной экономики, которая была запущена в процессе "быстрого старта", состоит из 1 делегата, который настроен также в качестве API и SEED-ноды.
|
||||
|
||||
@@ -52,7 +26,12 @@ pnpm run cli start
|
||||
|
||||
Такой режим запуска необходим при конфигурации сетей кооперативной экономики, где ноды производителей отделены от нод API, SEED и HISTORY, и занимаются исключительно производством блоков, не расходуя свои вычислительные ресурсы на прочие операции, поскольку от своевременности производства блоков зависит устойчивость сети.
|
||||
|
||||
## API-нода
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Запустить API-ноду
|
||||
Запуск ноды в режиме производства блоков не допускает чтения информации из блокчейна или отправку транзакций в него, а только производит цепочку и распространяет её по прямым соединениям с другими нодами. Для того, чтобы мы могли извлекать информацию из таблиц и отправлять транзакции, нам необходимо подключить соответствующие плагины к блокчейну. Вы можете добавить их к действующей ноде производителя:
|
||||
|
||||
``` { .bash .copy .annotate}
|
||||
@@ -103,7 +82,8 @@ curl -X GET http://127.0.0.1:8888/v1/chain/get_info
|
||||
|
||||
Что означает - нода запущена и функционирует нормально. Теперь мы можем подключить командный кошелёк для совершения операций с нодой - извлечения таблиц или отправки транзакций. И по этому же порту, который был открыт нами у API-ноды, мы можем подключать веб-приложения. Обо всём об этом будет рассказано далее.
|
||||
|
||||
## SEED-нода
|
||||
|
||||
## Запустить SEED-ноду
|
||||
|
||||
Ранее мы сконфигурировали API-ноду, которая стала доступна по HTTP, и которая работает на одной машине с Делегатской нодой. В реальной же конфигурации, нам необходимо поддерживать синхронизацию сети нескольких нод между собой. Для этого, нам необходимо соединить их, открыв порт для входящих подключений:
|
||||
|
||||
@@ -129,8 +109,8 @@ SEED-ноды используются для того, чтобы поддер
|
||||
|
||||
Архитектурно, SEED-ноды находятся выделенным слоем между замкнутым кругом делегатов и внешним миром, предоставляя возможность участникам синхронизировать свои ноды без прямого доступа к IP-адресу или имени действующего делегата.
|
||||
|
||||
## HISTORY-нода
|
||||
HISTORY-ноды используются для извлечения истории действий в блокчейне, включая все те действия смарт-контрактов, которые вызывались в рамках других действий автоматически в процессе их исполнения. Кроме того, HISTORY-нода предоставляет информацию о истории изменения всех таблиц системы, что в целом позволяет составить полную историческую карту всех событий и их эффектов в системе.
|
||||
|
||||
## Запуск HISTORY-ноды
|
||||
|
||||
Для конфигурации HISTORY-ноды необходимо задействовать следующие опции в конфиге:
|
||||
|
||||
@@ -0,0 +1,195 @@
|
||||
Все транзакции, которые отправляются в блокчейн - принимаются нодами. Полная копия всей цепочки содержится на каждой ноде и передаётся другим нодам по внутренним протоколам связи с регулярностью дважды в секунду (2 блока в секунду).
|
||||
|
||||
!!!note "Нода - экземпляр серверного программного обеспечения блокчейна"
|
||||
На нодах исполняется программное обеспечение блокчейна. Ноду блокчейна может запустить и синхронизировать из открытых источников любой желающий на своём сервере.
|
||||
|
||||
История транзакций образует публичную последовательность вызова действий всех смарт-контрактов от момента запуска платформы. И эта содержится одновременно на всех нодах сети и она абсолютно идентичная.
|
||||
|
||||
Однако, то, как ноды работают с этой историей, зависит от их назначения. Всего в сети можно выделить 4 основных функциональных назначения нод: HISTORY-ноды, DELEGATE-ноды, SEED-ноды и API-ноды.
|
||||
|
||||
Все эти ноды по своей сути являются PEER-нодами, т.е. нодами, которые равны друг другу.
|
||||
|
||||
!!!note "PEER-нода - это любая нода блокчейна"
|
||||
|
||||
Все PEER-ноды функционально одинаковы. Они позволяют принимать и передавать новые блоки истории от подключенных пиров, и делают автоматически. Все представленные ниже ноды - это PEER-ноды в своей основе. Мы же будем рассматривать только практически-полезные ноды на прикладном уровне.
|
||||
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Layer0["Ноды истории"]
|
||||
History1["HISTORY-1"]
|
||||
History2["HISTORY-2"]
|
||||
History3["HISTORY-..."]
|
||||
end
|
||||
|
||||
subgraph Layer1["Делегатские ноды"]
|
||||
Delegate1["DELEGATE-1"]
|
||||
Delegate2["DELEGATE-..."]
|
||||
Delegate3["DELEGATE-21"]
|
||||
end
|
||||
|
||||
subgraph Layer2["SEED-ноды"]
|
||||
Seed1["SEED-1"]
|
||||
Seed2["SEED-2"]
|
||||
Seed3["SEED-..."]
|
||||
end
|
||||
|
||||
subgraph Layer3["API-ноды"]
|
||||
API1["API-1"]
|
||||
API2["API-2"]
|
||||
API2["API-..."]
|
||||
end
|
||||
|
||||
ExternalApps["Приложения провайдеров"]
|
||||
|
||||
Layer0 --> Layer1
|
||||
Layer0 --> Layer2
|
||||
Layer1 --> Layer3
|
||||
Layer2 --> Layer3
|
||||
Layer3 --> ExternalApps
|
||||
|
||||
```
|
||||
|
||||
|
||||
## HISTORY-нода
|
||||
Несмотря на то, что все PEER-ноды обычно содержат полную цепочку истории событий, это не предоставляет им прямой возможности обращения к ней. История содержится на всех PEER-нодах, воспроизводится при запуске, и синхронизируется, но в этом процессе используются только данные из текущего блока. После проверки блока - данные уходят в историю, сохраняются на жестком диске в цепочке истории, и активно в PEER-ноде не используются.
|
||||
|
||||
Чтобы их использовать активно, каждый желающий может запустить HISTORY-ноду, включив дополнительный плагин, который сделает все исторические данные доступными по протоколу Websocket. В сети существуют программные решения (в том числе в наших репозиториях), которые используют HISTORY-ноды для извлечения данных из цепочки истории ноды - в обычную базу данных MONGO или POSTGRES.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Layer0["HISTORY-нода"]
|
||||
A1["Хранение полной истории блоков"]
|
||||
A2["Предоставление API"]
|
||||
A3["Поддержка Websocket соединений"]
|
||||
end
|
||||
|
||||
subgraph Layer1["Методы API"]
|
||||
B["Извлечение блоков"]
|
||||
C["Действия и каскадные вызовы"]
|
||||
D["Срез состояния таблиц"]
|
||||
end
|
||||
|
||||
subgraph Layer2["Приложения"]
|
||||
E["Обозреватели"]
|
||||
F["Инструменты анализа"]
|
||||
G["Фабрики документов"]
|
||||
end
|
||||
|
||||
Layer0 --> Layer1
|
||||
Layer1 --> Layer2
|
||||
|
||||
```
|
||||
|
||||
|
||||
Именно HISTORY-ноды используются фабриками документов при кооперативах для восстановления истории подписанных документов. Это позволяет хранить большие массивы неизменяемых данных, но не использовать для этого дорогие ресурсы оперативной памяти. HISTORY-нода конфигурируется при запуске с помощью дополнительных настроек плагина истории. Без этого плагина, история транзакций по-прежнему будет содержаться в каждой ноде, но без возможности быстрого извлечения для прикладного применения.
|
||||
|
||||
HISTORY-нода позволяет извлекать не только данные о действиях, которые вызывались пользователями, но и о каскадных действиях, которые вызывались автоматически смарт-контрактами в других смарт-контрактах согласно заложенной в них бизнес-логике кооперации.
|
||||
|
||||
Например, все действия с цифровыми кошельками пользователей - автомарны, и вызываются только каскадными действиями других смарт-контрактов. Таким образом, HISTORY-нода позволит при необходимости извлечь все действия, которые влияли на кошелёк пользователя. Также, HISTORY-нода позволяет не только извлекать действия, но и все изменения в таблицах контрактов.
|
||||
|
||||
Используя HISTORY-ноду можно получить "срез" состояния блокчейна в любой момент времени. Выяснить, какие действие исполнялись тогда, и какое состояние таблиц блокчейна было. Всё это позволяет делать HISTORY-нода, и по сути, они являются основанием для подробных обозревателей истории транзакций блокчейна.
|
||||
|
||||
## DELEGATE-нода
|
||||
Все принятые нодами транзакции образуют неизменяемую цепочку истории событий и приходят процесс утверждения каждым делегатом. Для того, чтобы новая транзакция была принята, необходимо, чтобы по-крайней мере 2/3 нод делегатов были согласны с тем, что транзакция удовлетворяет всем математическим правилам валидации, включая проверки на аудентификацию, целостность и доступность. Процесс достижения консенсуса подробнее описан в другом разделе.
|
||||
|
||||
!!!note "Делегаты - это участники, которые предоставляют вычислительные ресурсы своих серверов для работы платформы."
|
||||
|
||||
Делегаты выполняют ключевую роль по обработке транзакций и включению их в цепочку блоков, которая фактически производится на их серверах. Т.е. именно делегатские ноды являются производителями блокчейна, и именно они ставят свои подписи на каждом новом блоке истории событий, утверждая ее и делая тем самым неизменной.
|
||||
|
||||
На платформе действует система выборов делегатов, где 21 основная команда и 150 резервных команд получают право предоставлять свои ресурсы и получать за это вознаграждение. Подробнее о системе ресурсов и токеномике вознаграждений в соответствующих разделах.
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
subgraph Layer0["DELEGATE-нода"]
|
||||
A1["Производство блоков"]
|
||||
A2["Достижение консенсуса"]
|
||||
A3["Предоставление вычислительных ресурсов"]
|
||||
A4["Получение вознаграждений"]
|
||||
end
|
||||
|
||||
```
|
||||
|
||||
Запуск делегатской ноды осуществляется путём добавления плагина и ключа производителя в конфигурацию ноды при её синхронизации. Однако, для того, чтобы участвовать в производстве блокчейна, делегату необходимо стать пайщиком кооператива-оператора и присоединиться к соответствующей целевой потребительской программе. Кроме того, делегату необходимо собрать достаточное количество голосов, чтобы войти в топ-21 самых надежных и доверенных делегатов платформы. Подробнее о процессе выборов в соответствующем разделе.
|
||||
|
||||
Здесь же следует сказать, что ключевым для делегата является его скорость и надежность в производстве транзакций. Это значит, что никаких других операций на той же ноде совершать нежелательно. Поэтому ноды делегатов рекомендуется отделять от всех других нод в производственных средах. Более того, существует программная возможность соединения нод делегатов исключительно с доверенными SEED-нодами, что позволяет делегатам построить внутреннюю, изолированную топологию для надежной обработки транзакций.
|
||||
|
||||
|
||||
## API-нода
|
||||
|
||||
!!!note "API-нода - программный интерфейс для связи с приложениями провайдеров"
|
||||
|
||||
Все ноды обладают API - например, у HISTORY - это API для извлечения истории, а у делегата - это API делегата. Однако, для регулярной работы с платформой необходим доступ к методам, которые позволяют отправлять транзакции, получать информацию из таблиц распределенной базы данных, и другую, прочую информацию о состоянии блокчейна.
|
||||
|
||||
Для этого нужны API-ноды. Они конфигурируются таким образом, что предоставляют публичные конечные точки доступа для взаимодействия с внешним программным обеспечением. Они предоставляют RPC-интерфейсы, позволяющие отправлять POST и GET запросы для отправки транзакций и извлечения данных.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Layer0["API-нода"]
|
||||
A1["Публичная точка доступа"]
|
||||
A2["Первичная валидация транзакций"]
|
||||
A3["Вещание транзакций в сеть"]
|
||||
A4["Извлечение данных из базы"]
|
||||
end
|
||||
|
||||
subgraph Layer1["Функции взаимодействия"]
|
||||
B1["Отправка транзакций"]
|
||||
B2["Получение данных из таблиц"]
|
||||
B3["Получение информации о состоянии блокчейна"]
|
||||
end
|
||||
|
||||
subgraph Layer2["Внешние приложения"]
|
||||
C1["Приложения провайдеров"]
|
||||
end
|
||||
|
||||
Layer0 --> Layer1
|
||||
Layer1 --> Layer2
|
||||
|
||||
```
|
||||
|
||||
API-ноды при получении новой транзакции немедленно производят валидацию её и действий внутри неё. И только в случае если транзакция признана этой нодой достоверной - она отправляется всем другим нодам сети (вещается). Ноды делегатов получают эти транзакции и точно также проверяют их. И только в том случае, если 2/3 из основных делегатов согласятся с тем, что новая транзакция не содержит ошибок - тогда и только тогда она будет включена в цепочку. А до этого времени она считается всеми нодами - обратимой.
|
||||
|
||||
Но API-нода не беспокоится об этом. Её задачи - первичная валидация, вещание транзакции в сеть, а также, извлечение информации из собственной базы данных по запросам. База данных API-ноды формируется в процессе синхронизации и обновляется дважды в секунду автоматизированным и заверенным решением делегатов.
|
||||
|
||||
|
||||
## SEED-нода
|
||||
Для того, чтобы все ноды сети могли получить информацию о её состоянии - необходимы специальные ноды, которые будут предоставлять эту информацию большими пачками блоков транзакций. Такие ноды называются SEED, или, семя.
|
||||
|
||||
!!!note "SEED-нода - это публичная точка для синхронизации блокчейна"
|
||||
|
||||
Любой ноде для того, чтобы подключиться к блокчейн-сети, необходимо указать SEED-ноду, с которой будет произведена полная синхронизация цепочки блоков истории транзакций. SEED-ноды предоставляют такую возможность. Их главная задача - подключать другие ноды, делиться актуальной информацией о состоянии блоков, а также, наличии других нод в сети.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Z1["Новая нода"]
|
||||
|
||||
subgraph Layer0["SEED-нода"]
|
||||
A2["Синхронизация новых нод"]
|
||||
A3["Передача списка активных PEER-нод"]
|
||||
end
|
||||
|
||||
subgraph Layer2["PEER-ноды"]
|
||||
C1["SEED-ноды"]
|
||||
C2["DELEGATE-ноды"]
|
||||
C3["HISTORY-ноды"]
|
||||
C4["API-ноды"]
|
||||
end
|
||||
|
||||
Z1 --> Layer0
|
||||
Layer0 --> Layer2
|
||||
|
||||
```
|
||||
|
||||
Подключившись к любой активной SEED-ноде, нода немедленно начинает синхронизацию, а также, получает с неё список всех активных PEER-нод, с которыми начнётся взаимодействие после завершения синхронизации. Таким образом, SEED-нода -- это точка входа в блокчейн-сеть. Все доступные SEED-нодами публикуются делегатами на своих ресурсах, распределенно.
|
||||
|
||||
|
||||
## Синхронизация
|
||||
Все принятые блокчейном транзакции образуют цепочку истории действий. Полная копия этой цепочки содержится на каждой PEER-ноде и передаётся другим нодам по внутренним сетевым каналам связи платформы при синхронизации.
|
||||
|
||||
Синхронизация - процесс скачивания и криптографической проверки истории транзакций блокчейна.
|
||||
|
||||
При подключении новой PEER-ноды к платформе, она скачивает всю историю, криптографически проверяет взаимосвязь между блоками, и полностью воссоздаёт состояние своей базы данных таким, какое оно у всех других нод в сети.
|
||||
|
||||
Синхронизация выполняется между всеми PEER-нодами дважды в секунду. Именно такая скорость производства новых блоков истории транзакций на платформе. Блоки могут быть и пустыми, но процесс производства и синхронизации не останавливается ни на секунду.
|
||||
|
||||
Синхронизация истории между нодами сопровождается синхронизацией текущего состояния распределенной базы данных, которая хранится одновременно на всех серверах нод в их оперативной памяти.
|
||||
@@ -0,0 +1,277 @@
|
||||
База данных COOPENOMICS — это встроенная распределённая система хранения данных платформы, организованная в таблицы для управления состояниями смарт-контрактов. Изменение данных осуществляется через специальные методы, называемые действиями, которые задаются в коде смарт-контрактов.
|
||||
|
||||
В процессе синхронизации каждая нода воспроизводит все действия из всех транзакций и последовательно восстанавливает актуальное состояние базы данных. База данных платформы хранится в оперативной памяти каждой PEER-ноды и используется ими для проверки новых транзакций, а также, для чтения состояния внешними приложениями.
|
||||
|
||||
Информацию из базы данных можно извлекать посредством API, пользуясь GET запросами с параметрами для поиска информации на контрактах. А поскольку эта база данных формируется и поддерживается всеми PEER-нодами одновременно, то она - распределённая, и одинаковая для всех.
|
||||
|
||||
|
||||
!!!note "Сравним с обычной базой данных"
|
||||
POSTGRES - это реляционная база данных, которая позволяет выполнять операции создания, удаления, редактирования и чтения любой записи в любой таблице. База данных, при этом, никаким образом не ограничивает разработчиков в том, как с ней работать, и не требует соблюдения каких-либо бизнес-правил при изменении данных в ней. Реализация бизнес-правил выносится разработчиками за пределы самой базы данных в отдельные приложения, которые решают: когда и кому можно прочитать, добавить, изменить или обновить данные. POSTGRES к этим правилам никакого отношения не имеет и никаких ограничений не накладывает. Бизнес-правила и информация в базе данных никак не связаны.
|
||||
|
||||
COOPENOMICS - это распределенная база данных, которая хранит информацию и бизнес-правила по её изменению в смарт-контрактах. Информация описываются структурами данных, а правила - программным кодом. Правила, которые описаны в программном коде смарт-контрактов позволяют изменить состояние распределенной базы данных только в том случае, если все программные условия смарт-контракта выполнены. И если обычная база никаким образом не регламентирует разработчикам когда они могут добавить информацию, а когда удалить, то смарт-контракты в распределенной базе данных - это делают. Мы не можем создать запись, если в смарт-контракте указано, что для этого пользователь должен быть пайщиком, или удалить её, если пайщик - активен. Таким образом, в COOPENOMICS база данных и правила по изменению информации в ней неразрывно связаны.
|
||||
|
||||
Действия и таблицы в COOPENOMICS неразрывно связаны, образуя единое целое: каждое изменение в таблице возможно только через выполнение действия, определённого в коде смарт-контракта. Нельзя напрямую изменить данные таблицы, поскольку все модификации выполняются через строго заданные правила, описанные в действиях. Это гарантирует, что любые изменения данных проходят проверку логики контракта и согласуются с правилами платформы.
|
||||
|
||||
|
||||
## Типы данных
|
||||
Все структуры данных в COOPENOMICS описываются с помощью следующих типов:
|
||||
|
||||
| Тип данных | Описание |
|
||||
|--------------------|------------------------------------------------------------------------------------------|
|
||||
| `uint64_t` | 64-битное беззнаковое целое число. Используется для хранения идентификаторов и других числовых значений. |
|
||||
| `uint32_t` | 32-битное беззнаковое целое число. Применяется для меньших чисел, например, счетчиков или меток времени. |
|
||||
| `uint16_t` | 16-битное беззнаковое целое число. Используется для хранения небольших числовых данных. |
|
||||
| `uint8_t` | 8-битное беззнаковое целое число. Часто используется для хранения флагов или маленьких чисел. |
|
||||
| `int64_t` | 64-битное знаковое целое число. Применяется для значений, которые могут быть отрицательными. |
|
||||
| `int32_t` | 32-битное знаковое целое число. Используется для хранения небольших отрицательных или положительных чисел. |
|
||||
| `int16_t` | 16-битное знаковое целое число. Для небольших числовых данных. |
|
||||
| `int8_t` | 8-битное знаковое целое число. Часто используется для флагов или небольших чисел. |
|
||||
| `float64_t` | 64-битное число с плавающей точкой. Используется для хранения вещественных чисел с высокой точностью. |
|
||||
| `float32_t` | 32-битное число с плавающей точкой. Используется для вещественных чисел меньшей точности. |
|
||||
| `bool` | Логический тип. Хранит значение `true` или `false`. |
|
||||
| `name` | Специальный тип, представляющий имя аккаунта или идентификатор. Ограничен 12 символами `a-z` и цифрами `1-5`. |
|
||||
| `asset` | Тип для хранения токенов с их количеством и символом валюты. |
|
||||
| `checksum256` | 256-битный хеш. Применяется для хранения контрольных сумм или идентификаторов. |
|
||||
| `time_point` | Тип для хранения меток времени с микросекундной точностью. |
|
||||
| `time_point_sec` | Тип для хранения меток времени с секундной точностью. |
|
||||
| `block_timestamp_type` | Тип для хранения временных меток блоков в сети. |
|
||||
| `std::string` | Тип строки для хранения текстовых данных. |
|
||||
| `std::vector<T>` | Массив данных заданного типа `T`. Используется для хранения списков или массивов данных. |
|
||||
| `std::optional<T>` | Тип, указывающий на возможность наличия или отсутствия значения типа `T`. |
|
||||
|
||||
|
||||
|
||||
|
||||
## Структуры данных
|
||||
Типы данных составляют структуры:
|
||||
|
||||
```
|
||||
struct User {
|
||||
uint64_t id; // Уникальный идентификатор пользователя
|
||||
std::string name; // Имя пользователя
|
||||
uint32_t age; // Возраст пользователя
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
Структуры могут содержать структуры:
|
||||
|
||||
```
|
||||
struct Address {
|
||||
std::string city; // Город
|
||||
std::string street; // Улица
|
||||
uint32_t house_number;// Номер дома
|
||||
};
|
||||
|
||||
struct UserWithAddress {
|
||||
uint64_t id; // Уникальный идентификатор
|
||||
std::string name; // Имя
|
||||
Address address; // Адрес пользователя
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
И массивы структур:
|
||||
|
||||
```
|
||||
struct Post {
|
||||
uint64_t id; // Уникальный идентификатор поста
|
||||
std::string title; // Заголовок поста
|
||||
std::string content; // Содержимое поста
|
||||
};
|
||||
|
||||
struct UserWithPosts {
|
||||
uint64_t id; // Уникальный идентификатор пользователя
|
||||
std::string name; // Имя пользователя
|
||||
std::vector<Post> posts; // Список постов пользователя
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
Также, поля в структурах могут быть не обязательными:
|
||||
|
||||
```
|
||||
struct Profile {
|
||||
uint64_t id; // Уникальный идентификатор
|
||||
std::string username; // Имя пользователя
|
||||
std::optional<std::string> bio; // Биография (может отсутствовать)
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Таблицы
|
||||
Таблицы определяются указанием в структуре макроса, ключа и типа индекса.
|
||||
|
||||
``` { .bash .copy .annotate}
|
||||
struct [[eosio::table]] Product { # (1)
|
||||
uint64_t id; # (2)
|
||||
std::string name; # (3)
|
||||
uint64_t category_id; # (4)
|
||||
double price; # (5)
|
||||
|
||||
uint64_t primary_key() const { return id; } # (6)
|
||||
};
|
||||
|
||||
typedef eosio::multi_index<"products"_n, Product> product_table; # (7)
|
||||
|
||||
```
|
||||
|
||||
1. Здесь [[eosio::table]] - это макрос, указывающий что структура - это таблица, и она должна быть отображена в API смарт-контракта для доступа извне. Этот макрос используется компилятором при генерации бинарного интерфейса смарт-контракта, который затем будет установлен на платформе.
|
||||
|
||||
2. Уникальный идентификатор продукта
|
||||
|
||||
3. Название продукта
|
||||
|
||||
4. ID категории
|
||||
|
||||
5. Цена
|
||||
|
||||
6. Это основной индекс, который будет использоваться для проверки уникальности и поиска. Его тип - uint64_t, как и тип поля id, которое указано в качестве основного индекса.
|
||||
|
||||
7. typedef eosio::multi_index<"products"_n, Product> product_table; - это определение типа индекса в таблице, которое заявляет что таблица будет храниться в области памяти под именем "products"_n, там будет храниться объект типа Product, и имя этому индексу - product_table.
|
||||
|
||||
|
||||
!!!note "Макрос кодировки имени аккаунта"
|
||||
_n - это макрос, который говорит о том, что указанную строку необходимо перевести в кодировку имен аккаунтов; на платформе имена аккаунтов кодируются в числовые аналоги, т.е. если мы видим имя аккаунта в виде строки, то блокчейн "видит" большое число, которым закодирована строка. А т.к. в именах аккаунтов допустимы только буквы a-z и цифры 1-5, а также, длинна должна быть не более 12 символов, то ими мы и ограничены в создании пространства имен таблиц, по которым они будут доступны по API. Макрос _n - это быстрый перевод указанной строки в имя аккаунта, у которого есть функциональный аналог: name("products").
|
||||
|
||||
|
||||
Чтобы обратиться к описанной таблице в смарт-контракте необходимо:
|
||||
|
||||
``` { .bash .copy .annotate}
|
||||
product_table table1("contractname"_n, "contractname".value); # (1)
|
||||
auto product = table1.find(1); # (2)
|
||||
print(product -> name); # (3)
|
||||
```
|
||||
|
||||
1. Строим индекс, к которому мы будем обращаться. Где первый контракт в скобках указывает на то имя контракта, который является хранилищем данных. Каждый контракт может запрашивать информацию из любых других контрактов, если он осведомлён о её структуре. Второй же контракт указывает на область памяти, в которой хранится информация. В данном случае мы ищем информацию в области памяти самого контракта, однако, могли бы заменить её, например, на область памяти username.value, то говорило бы о том, что записи необходимо искать в области памяти пользователя.
|
||||
|
||||
2. Ищем продукт под индексом 1.
|
||||
|
||||
3. Распечатываем имя продукта в консоль.
|
||||
|
||||
## Создание записи
|
||||
|
||||
Описанный выше пример показывает, как на платформе реализуется поиск информации. Но как добавлять, редактировать и удалять информацию? Для этого применяются методы emplace, modify и erase на индексах.
|
||||
|
||||
|
||||
``` { .bash .copy .annotate}
|
||||
product_table table1("contractname"_n, "contractname".value); # (1)
|
||||
|
||||
table1.emplace("contractname"_n, [&](auto &row){ # (2)
|
||||
row.id = 1; # (3)
|
||||
row.name = "Ball"; # (4)
|
||||
row.category_id = 1; # (5)
|
||||
row.price = 100; # (6)
|
||||
})
|
||||
|
||||
```
|
||||
|
||||
1. Вновь строим индекс в котором мы будем создавать запись в контракте "contractname" в глобальной области памяти самого контракта "contractname".
|
||||
|
||||
2. Вызываем метод emplace, где первый параметр - это имя плательщика за системный ресурс оперативную памяти (RAM), который будет расчитан исходя из того, какое количество информации будет фактически сохранено. Вторым параметром мы передаем лямбда-функцию с названием строки, которую будем менять. Обычно эта лямбда-функция всегда одинакова для всех вызовов и её просто нужно запомнить.
|
||||
|
||||
3. Устанавливаем идентификатор строки
|
||||
|
||||
4. Задаём значение поля name
|
||||
|
||||
5. Задаём значение категории
|
||||
|
||||
6. Задаём значение идентификатора категории
|
||||
|
||||
|
||||
## Редактирование записи
|
||||
Для редактирования записи, нам нужно её найти и применить метод modify:
|
||||
|
||||
``` { .bash .copy .annotate}
|
||||
product_table table1("contractname"_n, "contractname".value); # (1)
|
||||
auto product = table1.find(1); # (2)
|
||||
|
||||
table1.modify(product, "contractname"_n, [&](auto &row){ # (3)
|
||||
row.price = 200; # (4)
|
||||
});
|
||||
```
|
||||
|
||||
1. Формируем индекс
|
||||
2. Ищем запись по primary_key
|
||||
3. Вызываем метод modify, где первый аргумент - это указатель на ранее найденный продукт, второй - это имя аккаунта плательщика за RAM, и третий аргумент, как и ранее - это лямбда функция, которую мы применяем для того, чтобы получить доступ к строке row.
|
||||
4. Устанавливаем новую цену продукта
|
||||
|
||||
|
||||
## Удаление записи
|
||||
Для удаления записи, аналогично, нам нужно её найти и применить метод erase:
|
||||
|
||||
``` { .bash .copy .annotate}
|
||||
product_table table1("contractname"_n, "contractname".value); # (1)
|
||||
auto product = table1.find(1); # (2)
|
||||
|
||||
table1.erase(product); # (3)
|
||||
|
||||
```
|
||||
|
||||
1. Формируем индекс
|
||||
2. Ищем запись по primary_key
|
||||
3. Вызываем метод erase и передаем указатель на ранее найденный продукт
|
||||
|
||||
Удаление записи производится из состояния распределенной базы данных, которое хранится в оперативной памяти всех PEER-нод одновременно. Поэтому, удаленные данные могут быть найдены только в HISTORY-нодах, которые содержат подробную информацию о всех действиях и всех изменениях в таблицах, которые они повлекли.
|
||||
|
||||
|
||||
## Действия
|
||||
Программный код по изменению информации в таблицах распределенной базы данных всегда находится в действиях смарт-контрактах. Невозможно изменить информацию в таблицах минуя действия смарт-контракта. Действия же могут содержать дополнительные правила и проверки, которые отражают в себе реальные бизнес-правила, по которым функционирует система. Таким образом, бизнес-правила неразрывно связаны с информацией в базе данных.
|
||||
|
||||
Например, прежде чем добавить запись в таблицу заявок на поставку продукта, мы проверим - а является ли пользователь - пайщиком кооператива? Но до этого - нам необходимо объявить само действие и проверить права доступа.
|
||||
|
||||
``` { .bash .copy .annotate}
|
||||
[[eosio::action]] createorder(eosio::name username, uint64_t product_id) { # (1)
|
||||
require_auth(username); # (2)
|
||||
|
||||
product_table table1("contractname"_n, "contractname".value); # (3)
|
||||
auto product = table1.find(1); # (4)
|
||||
eosio::check(product != table1.end(), "Продукт не найден"); # (5)
|
||||
|
||||
orders_table orders("contractname"_n, "contractname".value) # (6)
|
||||
|
||||
orders.emplace("contractname"_n, [&](auto &row){ # (7)
|
||||
row.order_id = available_primary_key(); # (8)
|
||||
row.username = username; # (9)
|
||||
row.product_id = product_id; # (10)
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
1. Объявляем действие смарт-контракта как функцию с указанием макроса [[eosio::action]] и аргументами, которое действие будет принимать.
|
||||
|
||||
2. Указываем требуемую аудентификацию, которой контракт будет требовать при вызове действия. В данном случае контракт сможет исполнить действие только в том случае, если он будет вызвано пользователем с именем аккаунта username.
|
||||
|
||||
3. Формируем индекс продуктов
|
||||
|
||||
4. Ищем продукт
|
||||
|
||||
5. Проверяем существует ли продукт. В случае, если указатель product соответствует концу таблицу table1.end(), выполнение действия немедленно завершится с ошибкой, что продукт не найден.
|
||||
|
||||
6. Формируем индекс заявок
|
||||
|
||||
7. Как и ранее, применяем функцию emplace на индексе и извлекаем строку для добавления
|
||||
|
||||
8. Получаем доступный primary_key, который будет расчитан автоматически
|
||||
|
||||
9. Присваиваем имя пользователя
|
||||
|
||||
10. Присваиваем заказу идентификатор продукта
|
||||
|
||||
|
||||
## Вывод
|
||||
Распределенная база включает в себя бизнес-правила, которые нельзя обойти: невозможно добавить запись в базу данных, не пройдя хотя бы одну из проверок в действии смарт-контракта. И таких проверок может быть много, и все они могут быть достаточно сложными.
|
||||
|
||||
Если в действиях смарт-контракта заложен программный код, который добавляет, редактирует или удаляет запись в базе данных, то это будет произведено на всех нодах автоматически после включения транзакции в цепочку блоков истории. Обмен информацией между нодами происходит дважды в секунду.
|
||||
|
||||
Смарт-контракты позволяют описывать структуры таблиц и типы данных в них, а затем, создавать, редактировать, искать и удалять информацию в базе данных посредством вызова действий. Логика работы с данными в таблицах смарт-контрактов лежит также в смарт-контрактах. А вся история вызовов - сохраняется в неразрывную цепочку истории.
|
||||
|
||||
Не каждое действие смарт-контракта может влиять на состояние таблиц распределенной базы данных - некоторые действия могут не вносить никаких изменений в таблицы, и при этом, исполняться. Это допустимо.
|
||||
|
||||
Все действия из транзакций применяются к состоянию базы данных последовательно. Если одно из действий в транзакции не может пройти проверку на математических условиях программного кода смарт-контракта, то такое действие отклоняется нодой автоматически вместе со всей транзакцией и всеми действиями в ней.
|
||||
|
||||
Программный код смарт-контрактов вызывается в момент применения действия из транзакции. Это происходит каждый раз, когда любая PEER-нода получает входящую транзакцию от пользователя или от других нод в процессе синхронизации.
|
||||
|
||||
Каждое принятое действие изменяет историю блокчейна, и может влиять на состояние распределенной базы данных, создавая, редактируя или удаляя записи в таблицах смарт-контрактов. Невозможно изменить таблицы смарт-контрактов в обход программного кода их действий - они неразрывно связаны в единое целое, и этим база данных COOPENOMICS отличается от любой другой базы данных.
|
||||
@@ -1 +0,0 @@
|
||||
# Синхронизация
|
||||
@@ -0,0 +1,505 @@
|
||||
Традиционные формы капитала, характерные для индустриальной эпохи, такие как материальные активы и финансовые инструменты, постепенно утрачивают свою ценность. В условиях нового технологического уклада ключевым видом капитала становится __интеллектуальный продукт__, создать который возможно только на основании объединения идей, ресурсов и действий людей во времени.
|
||||
|
||||
__Кооперативная экономика__, как доктрина развития в постиндустриальную эпоху, предоставляет инструменты для создания, капитализации и защиты результатов интеллектуальной деятельности, где идеи людей правят над процессами.
|
||||
|
||||
## Линия Жизни
|
||||
|
||||
__Большинство__ саморазвивающихся __систем__ (биологических, экономических, технических, организационных и др.) __следуют__ динамике __логистической кривой__ (S-образной), также называемой Линией Жизни, проходя фазы зарождения, роста, затухания и возможного перехода на новый уровень.
|
||||
|
||||
__Линия Жизни__ описывает универсальную закономерность, характерную для самых разных процессов: от эволюции организмов и технологий до общественных институтов и экономических циклов. Независимо от сферы, она включает три ключевые стадии:
|
||||
|
||||
1. __Зарождение__ – появление идеи, технологии или структуры, ее адаптация к среде.
|
||||
|
||||
2. __Расширение__ (внедрение, рост, экспансия) – стремительное распространение, вовлечение новых участников, накопление ресурсов и влияния.
|
||||
|
||||
3. __Насыщение__ (затухание, стабилизация, трансформация) – система достигает предела, либо выходит на новый уровень, либо теряет актуальность.
|
||||
|
||||
Для наглядности это можно представить на __двумерном__ графике, где по оси __X__ расположено время, а по оси __Y__ – суммарный эффект существования системы. В зависимости от контекста это могут быть __стоимость, общественная польза, степень вовлеченности, технологический прогресс, социальная справедливость, качество жизни, устойчивость экосистемы, культурное влияние и др__. Несмотря на различие терминологии, физическая суть всех этих процессов едина: ускорение, насыщение, переход или угасание.
|
||||
|
||||
<figure markdown="span">
|
||||
|
||||
<figcaption>Линия Жизни</figcaption>
|
||||
</figure>
|
||||
|
||||
На __начальном этапе__ система постепенно привлекает внимание за счёт __новизны или уникальности своих полезных характеристик__. На __этапе насыщения__ она достигает пика своей общественной значимости, когда интерес и использование выходят на максимум. __Этап стабилизации__ сопровождается снижением темпов роста, переходом в устойчивое состояние или началом угасания, что может привести к __рождению новой Линии Жизни__.
|
||||
|
||||
Прекращение существования системы, то есть __завершение её Линии Жизни__, может быть вызвано как внутренними, так и внешними факторами. Среди них: появление более эффективных альтернатив, моральное устаревание, снижение актуальности из-за изменений в потребностях общества или технологическом ландшафте.
|
||||
|
||||
<figure markdown="span">
|
||||
|
||||
<figcaption>Исторические Линии Жизни</figcaption>
|
||||
</figure>
|
||||
|
||||
|
||||
Выявление Линий Жизни, управление их переходами и предельно эффективное распределение ограниченных ресурсов является ключевым фактором роста общественной пользы без избыточных потрясений и с минимальными затратами. История даёт примеры: развитие каналов, железных дорог, телеграфа, трубопроводов и автомобильных дорог, и т.д. - каждая из этих технологий прошла свою Линию Жизни, достигла насыщения, уже уступила своё место новым решениям или уступит в будущем.
|
||||
|
||||
|
||||
## Стоимость и Ценности
|
||||
|
||||
__Создание результатов интеллектуальной деятельности (РИД) требует__ одновременного и сбалансированного использования ключевых элементов: __идей, ресурсов, времени и действий__. Каждый из этих элементов равнозначен и важен для роста результатов линии жизни.
|
||||
|
||||
<figure markdown="span">
|
||||
|
||||
<figcaption>Состав линии жизни</figcaption>
|
||||
</figure>
|
||||
|
||||
|
||||
__Стоимость__ — это количественное выражение вклада в результат интеллектуальной деятельности, определяемое совокупностью ресурсов, идей и усилий, затраченных на его создание. Она отображается на графике по оси Y и служит стартовой объективной метрикой роста результатов линии жизни. Стоимость позволяет измерить экономический эффект и продолжает расти, пока система получает ресурсное и общественное подкрепление.
|
||||
|
||||
Ценности, напротив, представляют субъективное восприятие линии жизни. Они отражают личные ожидания участников процесса и включают такие аспекты, как удовлетворение, вдохновение, чувство прогресса, пользу, доверие и гармонию. Эти параметры многомерны и не сводятся к одной оси. На графике они представлены осью __Zn__, которая объединяет субъективные метрики в единую многомерную категорию, отражающую суммарное отношение людей к линии жизни.
|
||||
|
||||
Линия жизни системы растёт в сторону ценностей, которые вдохновляют участников на продолжение действий. Пока люди видят личную или общественную значимость в линии жизни, она продолжает развиваться. Когда ценность становится недостижимой или теряет актуальность, линия жизни затухает, уступая место новой версии, где обновлённые идеи и ценности запускают новый цикл развития.
|
||||
|
||||
Ценности являются фундаментальной основой линии жизни, определяя её долгосрочную значимость. Они вдохновляют на действия, задают вектор развития и поддерживают вовлечённость участников. Стоимость, в свою очередь, объективно фиксирует рост результатов, служа базовой метрикой линии жизни. Совокупность объективных и субъективных метрик позволяет системе адаптироваться, выходить на новые уровни развития и создавать пространство для новых линий жизни.
|
||||
|
||||
## Волновой план
|
||||
|
||||
Все линии жизни объекта интеллектуальной собственности, формируемые результатами интеллектуальной деятельности людей в прошлом, настоящем и будущем, объединяются в единую систему — волновой план.
|
||||
|
||||
<figure markdown="span">
|
||||
|
||||
<figcaption>Волны линии жизни</figcaption>
|
||||
</figure>
|
||||
|
||||
__Волновой план__ — это живая, гибкая и вероятностная карта роста результатов интеллектуальной деятельности. Она отражает взаимосвязи и эволюцию линий жизни через производственные циклы, объединяя предложения и усилия Сообщества. В отличие от статичных дорожных карт, волновой план динамически обновляется, реагируя на изменения в системе ценностей, технологических возможностях и степени вовлечённости участников.
|
||||
|
||||
Каждая линия жизни развивается в рамках волнового плана, соединяясь с другими линиями через периоды корректировок, технологических изменений и адаптаций в производственных циклах. Эти соединения позволяют системе оставаться гибкой, не разрушая уже накопленные результаты. Например, волновой план можно представить через простейшую метафору календарных недель: начало и конец недели характеризуются спадом продуктивности, а её середина — ростом. Аналогично в проектах возникают фазы активного роста, периоды рефлексии и переходы к новым этапам.
|
||||
|
||||
Информация о линиях жизни и ключевых событиях хранится в виде графов, где каждая вершина фиксирует события: внесение предложений, ресурсов или действий. Эти графы создают структурированное представление, позволяя сохранять взаимосвязи между событиями и линиями жизни.
|
||||
|
||||
Для анализа и интерпретации данных графы проецируются на графики и используются для формирования рекомендаций, которые предоставляют ИИ-агенты. Такие рекомендации позволят участникам системы увидеть текущую динамику, предсказывать будущие траектории развития и принимать оптимальные решения на основе комплексного анализа данных.
|
||||
|
||||
Искусственный интеллект должен изучать накопленные графовые данные, выявляет закономерности в линиях жизни и прогнозирует их дальнейшее развитие. Используя историю каждого проекта, ИИ обучится создавать гибкие сценарии, которые адаптируются к изменениям внешних и внутренних условий.
|
||||
|
||||
Волновой план станет инструментом согласованного управления результатами интеллектуальной деятельности. Он обеспечивает рациональное распределение ресурсов, прогнозирование будущих направлений развития и поддержку ценностей участников. Построенный на графовой структуре и обогащённый рекомендациями ИИ-агентов, волновой план направляет систему к достижению новых результатов, сохраняя её адаптивность и устойчивость.
|
||||
|
||||
## Идеи и Предложения
|
||||
|
||||
__Идея__ — это мысленный образ возможного решения, модели, метода или действия, которое, по мнению автора, может принести дополнительную ценность объекту интеллектуальной собственности (ОИС). В контексте Кооперативной Экономики идеи формируют основу для дальнейшего развития проектов и производства результатов интеллектуальной деятельности (РИД).
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
idea["Идея"] -->project_proposal["Проектное предложение"]
|
||||
idea -->rational_proposal["Рациональное предложение"]
|
||||
idea -->value_proposal["Ценностное предложение"]
|
||||
|
||||
```
|
||||
Чтобы идея обрела практическую ценность, она должна быть оформлена в виде __проектного предложения__. Только через оформление в проектное предложение идея становится частью волнового плана и получает возможность для реализации. В Сообществе существует три типа предложений каждое из которых выполняет свою роль в иерархии процесса генерации РИД, а именно:
|
||||
|
||||
### Проектные предложения
|
||||
|
||||
Проектные предложения описывают Идеи, которые могут перерасти в полноценные проекты и получить командный круг для реализации. Они фиксируют предполагаемый эффект и стратегическую ценность.
|
||||
|
||||
__Шаблон:__
|
||||
> Если мы [действие/изменение], то [результат/эффект], потому что [обоснование - проблема, возможность, решение].
|
||||
|
||||
|
||||
__Примеры:__
|
||||
|
||||
> - Если мы создадим цифровой алгоритм межотраслевого баланса в Кооперативной Экономике, то сможем планировать производство и услуги в кооперативном формате, таким образом решим проблему дисбаланса производства и услуг.
|
||||
> - Если мы разработаем алгоритм прогнозирования потребностей участников Кооперативной Экономики, то сможем предотвращать дефицит товаров и услуг, потому что это позволит заранее распределять ресурсы.
|
||||
> - Если мы создадим платформу для коллективного проектирования экосистемных решений, то сможем объединять участников в проектные группы по их навыкам и ценностям, потому что это ускорит генерацию идей и повысит продуктивность.
|
||||
|
||||
Проектные предложения оцениваются Сообществом и Советом с участием ИИ-агентов. Если проектное предложение получает одобрение, для его проработки выделяются ресурсы и создаётся соответствующий проект с командным кругом.
|
||||
|
||||
### Рациональные предложения
|
||||
|
||||
Рациональные предложения — это конкретные планы действий в командном круге, которые необходимо выполнить ответственному в заданный период. Они начинаются с инфинитива и соответствуют принципам SMART (Конкретность, Измеримость, Достижимость, Актуальность, Ограниченность во времени).
|
||||
|
||||
|
||||
__Шаблон:__
|
||||
> [Действие с окончанием ^ть] за [срок] [ресурс] [цель].
|
||||
|
||||
__Примеры:__
|
||||
> - Установить датчики света в офисе за 15 тыс. рублей.
|
||||
> - Настроить резервное копирование данных за 7 дней.
|
||||
|
||||
|
||||
Рациональные предложения используются для формирования производственного/ хозяйственного плана реализации проектного предложения. Они определяют, какие задачи будут выполнены в ближайшие спринты (двухнедельные циклы) и какие ресурсы потребуются для их реализации.
|
||||
|
||||
|
||||
### Ценностные предложения
|
||||
|
||||
Ценностные предложения отражают личные приоритеты участников командного круга по реализации проектного предложения, их ожидания от процесса такой реализации и общие ориентиры. Они не требуют немедленного исполнения, но помогают уточнить или определить стратегическое направление в реализации проектного предложения.
|
||||
|
||||
|
||||
__Шаблон:__
|
||||
> Мне важно [желаемое состояние].
|
||||
|
||||
__Примеры:__
|
||||
> - Мне важно через 1 год обеспечить автоматизированное управление ресурсами, чтобы сократить время и ресурсы для администрирования.
|
||||
> - Мне важно, чтобы Вася писал код без багов или чтобы кто-то тестировал код за Васю.
|
||||
> - Мне важно хорошо отдохнуть в выходные.
|
||||
|
||||
Ценностные предложения фиксируются в волновом плане и служат ориентирами для оперативного планирования в командном круге по реализации проектного предложения. Они позволяют выявлять мотивацию участников Круга, а также учитывать как ближайшие, так и долгосрочные цели Сообщества в целом.
|
||||
|
||||
|
||||
|
||||
__Как предложения становятся частью волнового плана__
|
||||
|
||||
1. В Сообщество поступают идеи. Сообщество их регистрирует.
|
||||
|
||||
2. Совет и ИИ-агенты анализируют поступающие идеи. Одобренные идеи становятся проектными предложениями - на их реализацию формируется Командный Круг.
|
||||
|
||||
3. В Командном Круге могут возникать ценностные предложения. Они помогают учитывать приоритеты и ожидания участников Командного Круга от реализации проектного предложения.
|
||||
|
||||
4. Рациональные предложения участников Командного Круга формируют производственный план. В начале каждого спринта - короткого оперативного плана действий (раз в 2 недели) определяется перечень задач и ответственные.
|
||||
|
||||
|
||||
Таким образом, система предложений обеспечивает баланс между стратегическим видением, индивидуальными приоритетами и оперативным выполнением задач.
|
||||
|
||||
|
||||
## Сообщество
|
||||
|
||||
Представим, что у нас есть Сообщество (кооператив как формат его воплощения), представители которого рождают идеи. Но не просто отвлеченные идеи, а проектные, ценностные и рациональные предложения, которые, с учетом доступных ресурсов, и по мнению участников сообщества и их ИИ-агентов, смогут обеспечить для Сообщества благо.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
community["Сообщество"] -->|Генерирует| proposals["Предложения"]
|
||||
community -->|Избирает| council["Совет"]
|
||||
community -->|Наполняет| circles["Круги"]
|
||||
community -->|Привлекает| resources["Ресурсы"]
|
||||
```
|
||||
|
||||
Деятельность по производству объекта интеллектуальной собственности основывается на Предложениях Сообщества, которые регистрируются в Кооперативе как паевые взносы авторским правом по номинальной стоимости, определенным Советом.
|
||||
|
||||
|
||||
Процесс генерации объекта интеллектуальной собственности опирается на взаимодействие между людьми и их ИИ-агентами, которые помогают анализировать возможные траектории развития, учитывать ограничения и прогнозировать наиболее эффективные пути реализации результатов интеллектуальной деятельности. В этом смысле Сообщество выступает как коллективный разум, где индивидуальные ценности пересекаются, усиливают друг друга и формируют новые линии жизни.
|
||||
|
||||
|
||||
Каждое принятое предложение становится частью волнового плана, связываясь с существующими результатами и формируя основу для новых производственных циклов. Таким образом, Сообщество не только создает интеллектуальный продукт, но и активно управляет его жизненным циклом, прогнозируя и регулируя точки роста и коррекций его линий жизни.
|
||||
|
||||
## Совет
|
||||
|
||||
__Совет__ — это стратегический управляющий орган Сообщества, который отвечает за долгосрочное планирование, координацию производственных процессов и согласование ценностных ориентиров.
|
||||
|
||||
Совет избирается общим собранием Сообщества на ограниченный срок и действует в рамках принципов кооперативного управления, сочетая коллективное принятие решений с алгоритмической поддержкой ИИ-агентов.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
council["Совет"] -->|Утверждает| wave_plan["Планы"]
|
||||
council -->|Определяет| strategy["Стратегию"]
|
||||
council -->|Координирует| projects["Проекты"]
|
||||
council -->|Распределяет| resources["Ресурсы"]
|
||||
council -->|Формирует| circles["Круги"]
|
||||
```
|
||||
|
||||
Основная роль Совета заключается в утверждении волновых планов проектов, выстраивании долгосрочных направлений развития и обеспечении эффективного распределения ресурсов. Совет принимает входящие рациональные предложения, интегрирует их в стратегические производственные циклы и формирует прогнозные производственные дорожные карты на 2 недели, 3 месяца, 1 год, 5 лет, 10 лет и более, начиная с дальних горизонтов и непрерывно адаптируя их с учетом новых данных, изменяющихся приоритетов и доступных ресурсов.
|
||||
|
||||
Совет также отвечает за инициирование и координацию проектов. На основании собственного видения, рекомендаций ИИ-агентов и накопленных ресурсов он открывает производство новых проектов, формирует командные круги и заключает договоры и смарт-контракты об Участии в Хозяйственной Деятельности. Это позволяет Сообществу эффективно структурировать интеллектуальную активность, обеспечивая согласованность линий жизни и максимальную капитализацию результатов интеллектуальной деятельности.
|
||||
|
||||
|
||||
Таким образом, Совет является фундаментальным механизмом саморегуляции Сообщества, соединяя ценности участников, волновое планирование и производственные циклы в единую, эволюционирующую систему управления интеллектуальным капиталом.
|
||||
|
||||
## Авторы и Создатели
|
||||
|
||||
Авторы и создатели являются ключевыми участниками процесса генерации РИД в рамках Кооперативной Экономики. Они представляют две взаимодополняющие роли:
|
||||
|
||||
__1. Авторы__ — это инициаторы идей, которые формулируют проектные, ценностные и рациональные предложения. Их вклад заключается в создании концептуальных решений, направленных на развитие объекта интеллектуальной собственности (ОИС). Они регистрируют авторские права на свои предложения и вносят их в Сообщество в качестве паевого взноса. Авторские права фиксируются юридически и технологически (например, через NFT), обеспечивая защиту идей и их возможную капитализацию.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
authors["Авторы"] -->|Формулируют| ideas["Проектные предложения"]
|
||||
authors -->|Регистрируют| ip_rights["Авторские права"]
|
||||
authors -->|Вносят| shares["Паевые взносы"]
|
||||
|
||||
```
|
||||
|
||||
|
||||
__2. Создатели__ — это участники, которые совершают конкретные действия во времени для воплощения предложений в реальность и используют ресурсы, предоставленные Сообществом. Создатели формируют между собой командные круги, берут на себя ответственность за выполнение задач и фиксируют прогресс в рамках волнового плана.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
creators["Создатели"] -->|Реализуют| proposals["Предложения"]
|
||||
creators -->|Используют| resources["Ресурсы"]
|
||||
creators -->|Фиксируют| progress["Прогресс"]
|
||||
|
||||
```
|
||||
|
||||
Хотя автор и создатель могут быть разными людьми, в ряде случаев один участник может совмещать обе роли — предложить идею и принять активное участие в её реализации.
|
||||
|
||||
## Виды взносов
|
||||
```mermaid
|
||||
graph TD;
|
||||
contributions["Вклады/Взносы"] -->ideas["Идеи"]
|
||||
contributions --> actions["Действия"]
|
||||
contributions --> resources["Ресурсы"]
|
||||
|
||||
ideas -->|Формулируются| authors["Авторами"]
|
||||
actions -->|Выполняются| creators["Создателями"]
|
||||
resources -->|Предоставляются| community["Сообществом"]
|
||||
```
|
||||
|
||||
Производство РИД опирается на три равнозначных вида взносов: __идеи, действия и ресурсы__. Каждый из них представляет собой форму участия в создании интеллектуального продукта и вносит свой вклад в его генерацию.
|
||||
|
||||
__Идеи__ являются исходной точкой любого РИД. Авторы формируют проектные, ценностные и рациональные предложения, которые затем проходят процесс оценки и интеграции в волновой план. Идея сама по себе имеет номинальную стоимость при регистрации авторских прав, но фактическая её ценность определяется тем, насколько Сообщество готово осуществлять действия и вкладывать в неё своё время и ресурсы.
|
||||
|
||||
__Действия__ подтверждают ценность идей. Создатели тратят своё время на их реализацию, беря на себя ответственность за воплощение предложений в конкретный продукт. Время создателей — это основной измеримый актив, на который опирается модель по определению сгенерированной стоимости РИД.
|
||||
|
||||
__Ресурсы__ поддерживают процесс создания. Это могут быть финансовые средства, инфраструктура, оборудование, технологии или иные материальные активы, без которых невозможно воплощение идей в реальность. Вложенные ресурсы учитываются при расчёте совокупной стоимости сгенерированного РИД.
|
||||
|
||||
Каждый вклад не существует в изоляции. Только их синхронное сочетание позволяет обеспечить создание интеллектуального продукта, закрепить авторские права и перераспределить участие в сгенерированной стоимости РИД среди всех участников процесса.
|
||||
|
||||
## Круги
|
||||
|
||||
__Круги__ — это гибкие, самоорганизующиеся команды, объединяющие создателей, авторов и приглашённых наблюдателей для реализации проектных предложений. Они формируются в ответ на принятие Сообществом проектных инициатив и действуют в рамках производственных циклов, согласованных с волновым планом.
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
circles["Круги"] -->|Объединяют| creators["Создателей"]
|
||||
circles -->|Объединяют| authors["Авторов"]
|
||||
circles -->|Включают| observers["Наблюдателей"]
|
||||
circles -->|Реализуют| proposals["Предложения"]
|
||||
circles -->|Используют| resources["Ресурсы"]
|
||||
circles -->|Фиксируют| metrics["Метрики"]
|
||||
circles -->|Расформировываются| dissolve["После завершения проекта"]
|
||||
|
||||
```
|
||||
|
||||
Создатели в круге берут на себя реализацию предложений, используя предоставленный Сообществом ресурс и вкладывая своё время и действия, а авторы сопровождают процесс, обеспечивая смысловую и концептуальную целостность идеи. Наблюдатели могут быть включены в круг в качестве экспертов, аналитиков или заинтересованных сторон, обеспечивающих стратегическую поддержку и контроль за ходом работ.
|
||||
|
||||
|
||||
Каждый круг обладает собственной системой метрик, определяющей распределение премии среди его участников. Эти метрики могут учитывать сложность выполненной работы, её соответствие первоначальной концепции, степень вовлечённости или другие параметры, согласованные внутри круга. Это позволяет каждому участнику круга видеть прозрачную систему оценки своего вклада и справедливого распределения вознаграждения.
|
||||
|
||||
|
||||
Круги не фиксированы во времени — они существуют, пока ведётся работа над соответствующими предложениями. Как только проектная инициатива завершается или переходит в новую фазу, круг может быть расформирован, изменён или переформатирован для новых задач. Такое динамическое управление командами позволяет максимально эффективно использовать потенциал Сообщества, распределяя усилия в соответствии с заданными приоритетами развития.
|
||||
|
||||
## Проекты
|
||||
|
||||
__Проекты__ — это структурно-функциональные единицы, в рамках которых осуществляется генерация РИД. Они представляют собой контейнеры для развития идей, объединяющие командные круги, техническую и организационную инфраструктуру, а также ресурсы, выделенные Сообществом для их реализации.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
projects["Проекты"] -->|Формируются из| proposals["Предложения"]
|
||||
projects -->|Объединяют| circles["Командные круги"]
|
||||
projects -->|Используют| resources["Ресурсы"]
|
||||
projects -->|Проходят этапы| lifecycle["Жизненный цикл"]
|
||||
|
||||
lifecycle -->|Формирование| formation["Формирование"]
|
||||
lifecycle -->|Развитие| growth["Развитие"]
|
||||
lifecycle -->|Насыщение| saturation["Насыщение"]
|
||||
lifecycle -->|Завершение| completion["Завершение"]
|
||||
|
||||
projects -->|Управляются| council["Советом"]
|
||||
projects -->|Согласуются с| wave_plan["Волновым планом"]
|
||||
|
||||
```
|
||||
|
||||
Каждый проект проходит через естественные этапы жизненного цикла: формирование, развитие, насыщение и завершение, что соответствует принципам волнового планирования. В начале проект может существовать как концепция в виде проектного предложения. После его утверждения Сообществом и выделения необходимых ресурсов создаётся соответствующий круг, который берёт на себя его реализацию.
|
||||
|
||||
Проекты управляются на основе производственного плана, формируемого из рациональных предложений. Этот план задаёт направления развития, этапы реализации и ключевые контрольные точки, согласованные с волновым планом.
|
||||
|
||||
Сообщество, через Совет и ИИ-агентов, координирует открытие и поддержку проектов, направляя ресурсы на наиболее перспективные инициативы. Это позволяет обеспечить стратегическое развитие интеллектуальной деятельности, избегая хаотичного распределения усилий.
|
||||
|
||||
Совет, на основании собственного видения, рекомендаций ИИ-агентов, и накопленных ресурсов своевременно открывает производство проектов и формирует командные круги личными приглашениями членов Сообщества, заключая с ними договор и смарт-контракт об Участии в Хозяйственной Деятельности.
|
||||
|
||||
Договор представляет собой юридическое описание условий участия в создании результатов интеллектуальной деятельности, а смарт-контракт - реализует их в программном коде блокчейна Кооперативной Экономики, фиксируя авторские права на предложения и перераспределяя рост капитализации среди всех членов Сообщества.
|
||||
|
||||
Таким образом, проекты выступают в качестве основного механизма кооперативного производства, связывая ценностное целеполагание, командную работу и капитализацию интеллектуальной собственности в единую систему роста.
|
||||
|
||||
## Процесс планирования
|
||||
|
||||
Процесс планирования является основой организации деятельности Сообщества, соединяя стратегическое управление, производственные циклы и механизм капитализации интеллектуальной собственности. Он включает в себя последовательные этапы принятия предложений, выявления проектов, формирования командных кругов и детального проектирования производственного процесса.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
planning["Процесс планирования"] -->|Принимает| proposals["Предложения"]
|
||||
proposals -->|Фиксируются в| tracker["Трекере"]
|
||||
tracker -->|Проходят оценку| evaluation["Оценка и анализ"]
|
||||
|
||||
evaluation -->|Выявляет| projects["Проекты"]
|
||||
projects -->|Группируются по направлениям| categorization["Структурирование проектов"]
|
||||
|
||||
projects -->|Формируют| circles["Командные круги"]
|
||||
circles -->|Получают доступ к| resources["Ресурсам"]
|
||||
circles -->|Определяют| work_processes["Рабочие процессы"]
|
||||
|
||||
planning -->|Формирует| production_plan["Производственный план"]
|
||||
production_plan -->|Содержит временные горизонты| time_frames["Пятилетний, годовой, квартальный, двухнедельный"]
|
||||
|
||||
planning -->|Проводит| review["Сверка с волновым планом"]
|
||||
review -->|Фиксирует| results["Результаты"]
|
||||
review -->|Корректирует| strategy["Стратегическое и тактическое планирование"]
|
||||
|
||||
```
|
||||
|
||||
__1. Принятие предложений__
|
||||
|
||||
На первом этапе Сообщество принимает предложения всех типов: проектные, ценностные и рациональные. Эти предложения поступают от участников и фиксируются в трекере, где проходят предварительную оценку и анализ. На этом этапе Сообщество определяет потенциал каждого предложения, его соответствие стратегическим приоритетам и доступным ресурсам.
|
||||
|
||||
|
||||
__2. Выявление проектов__
|
||||
|
||||
После фиксации предложений начинается процесс выявления проектов. Предложения, обладающие высоким потенциалом и поддержкой участников, формируют основу для создания новых проектов. Они группируются по направлениям, что позволяет структурировать работу и подготовить их к следующему этапу.
|
||||
|
||||
__3. Формирование командного круга__
|
||||
|
||||
Для каждого проекта формируется командный круг, состоящий из создателей, авторов и приглашённых участников. Круг получает доступ к необходимым ресурсам, определяет рабочие процессы и договаривается о системе распределения премии среди участников.
|
||||
|
||||
|
||||
|
||||
__4. Производственное планирование__
|
||||
|
||||
Командный круг разрабатывает производственный план, который включает предложения общего планирования на различные временные горизонты:
|
||||
|
||||
- Пятилетний цикл — стратегическое видение направления развития проекта.
|
||||
- Годовой цикл — определение ключевых этапов работы на год.
|
||||
- Квартальный цикл (3 месяца) — уточнение приоритетных задач на ближайшее время.
|
||||
- Двухнедельный цикл (спринт) — конкретные шаги и задачи, которые предстоит выполнить в ближайшие 14 дней.
|
||||
|
||||
Этот процесс формирует основу волнового планирования, обеспечивая динамическую адаптацию проектов к изменяющимся условиям и стратегическим приоритетам.
|
||||
|
||||
|
||||
|
||||
__5. Сверка и регистрация результатов__
|
||||
|
||||
Каждые 2 недели проводится сверка производственного плана с волновым планом. В ходе сверки фиксируются фактические результаты, достигнутые командными кругами, а также пересматриваются приоритеты и корректируются планы на следующие циклы.
|
||||
|
||||
На этом этапе:
|
||||
- Производится регистрация сгенерированных результатов интеллектуальной деятельности в Кооперативе.
|
||||
- Фиксируется фактическое затраченное время участников.
|
||||
- Распределяются вклады от стоимости сгенерированного РИД среди создателей и авторов.
|
||||
- Определяются корректировки в стратегическом и тактическом планировании.
|
||||
|
||||
|
||||
Этот механизм позволяет Сообществу управлять процессом создания интеллектуальной собственности в режиме реального времени, обеспечивая прозрачность, справедливое распределение участия в стоимости сгенерированного РИД и согласованность долгосрочных и краткосрочных целей.
|
||||
|
||||
|
||||
Таким образом, планирование представляет собой непрерывный процесс, в котором ценности, идеи, ресурсы и действия формируют единую живую систему кооперативного управления.
|
||||
|
||||
## Генерация РИД
|
||||
|
||||
Сгенерированная стоимость РИД определяется суммарной стоимостью идей, действий и ресурсов, вложенных в процесс его создания. Её расчет основан на принципе __золотого сечения__, который определяет баланс между вложенным трудом создателей и ценностью авторских идей.
|
||||
|
||||
Единственный способ подтвердить ценность идеи — это вложить в неё действия. Если Сообщество принимает предложение и начинает его реализацию, каждый вложенный час работы увеличивает совокупную сгенерированную стоимость РИД втрое.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
rid_generation["Генерация РИД"] -->|Опирается на| contributions["Вклады: Идеи, Действия, Ресурсы"]
|
||||
|
||||
contributions -->|Формируют| value["Сгенерированную стоимость"]
|
||||
value -->|Рассчитывается по| golden_ratio["Принципу золотого сечения (1.618)"]
|
||||
|
||||
value -->|Распределяется на| creators_reward["Вознаграждение создателей"]
|
||||
value -->|Распределяется на| authors_premium["Премия авторов"]
|
||||
value -->|Формирует| coop_capital["Складочный капитал сообщества"]
|
||||
|
||||
creators_reward -->|Распределяется среди| team["Командного круга"]
|
||||
authors_premium -->|Закрепляет| idea_value["Ценность предложений"]
|
||||
|
||||
coop_capital -->|Входит в| coop_fund["Фонд сообщества"]
|
||||
|
||||
```
|
||||
|
||||
Допустим, создатель инвестирует 1 час времени, номинальная стоимость которого составляет 3000 рублей. В этот момент возникает сгенерированная стоимость 9000 рублей, распределяемая следующим образом:
|
||||
|
||||
- 3000 рублей — оплата труда создателя.
|
||||
- 1146 рублей (3000 × 0,382) — “премия” создателей, которая распределяется среди членов командного круга.
|
||||
- 4854 рублей (3000 × 1,618) — “премия” авторов, закрепляющая ценность предложения.
|
||||
|
||||
“Премия” выражается в дополнительном взносе участника в виде Имущества - РИД.
|
||||
|
||||
Такое распределение формирует устойчивую модель генерации РИД, в которой создатели получают вознаграждение за вложенное время, а авторы — “премию” за де-факто определенную ценность своих идей. При этом дополнительная “премия” создателей перераспределяется внутри командного круга, согласно установленным метрикам, определяемым самим кругом.
|
||||
|
||||
Чем больше времени и ресурсов вкладывается в реализацию идеи, тем выше её сгенерированная стоимость. Этот процесс не статичен — он напрямую зависит от вовлечённости участников и динамики волнового планирования. Каждое принятое предложение проходит через этапы проверки, реализации и роста стоимости, формируя живую систему, в которой ценность интеллектуальной деятельности объективно закрепляется в системе вкладов, действий и результатов.
|
||||
|
||||
## Капитализация РИД
|
||||
В основе Кооперативной Экономики лежит принцип совместного роста интеллектуального капитала - его капитализацию. В отличие от традиционных моделей, где ценность создаётся и фиксируется локально, здесь каждый новый вклад не только оценивается сам по себе, но и увеличивает стоимость всех предыдущих вложений.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
rid_capitalization["Капитализация РИД"] -->|Опирается на| golden_ratio["Принцип золотого сечения (1.618)"]
|
||||
|
||||
rid_capitalization -->|Увеличивает| total_value["Совокупную стоимость интеллектуального капитала"]
|
||||
total_value -->|Распределяется между| authors["Авторами"]
|
||||
total_value -->|Распределяется между| creators["Создателями"]
|
||||
total_value -->|Пополняет| coop_fund["Фонд сообщества"]
|
||||
|
||||
coop_fund -->|Распределяет| rewards["Вознаграждения участников"]
|
||||
rewards -->|Растут при| growth["Росте документооборота"]
|
||||
```
|
||||
|
||||
Этот механизм основан на принципе золотого сечения (1,618), который выполняет две ключевые функции:
|
||||
|
||||
1. Определяет баланс капитализации между авторами и создателями. Вложенное время подтверждает ценность идеи, а коэффициент золотого сечения задаёт соотношение между вкладом авторов и трудом создателей.
|
||||
|
||||
2. Обеспечивает экспоненциальный рост интеллектуального капитала в Сообществе. Каждый новый вклад приумножает стоимость всей экосистемы, усиливая значимость как текущих, так и прошлых достижений.
|
||||
|
||||
Если предложение принимается к реализации, его ценность увеличивается втрое. Допустим, создатель инвестирует 1 час работы стоимостью 3000 рублей. Это создаёт 9000 рублей интеллектуального капитала, распределяемых следующим образом:
|
||||
|
||||
- 3000 рублей — вознаграждение создателя за вложенное время.
|
||||
- 1146 рублей (3000 × 0,382) — “премия” создателей, распределяемая внутри командного круга.
|
||||
- 4854 рублей (3000 × 1,618) — “премия” авторов, закрепляющая ценность идеи.
|
||||
|
||||
Но на этом процесс не останавливается. 9000 рублей капитализации вносятся в Кооператив как паевые взносы от участников круга, которые затем, также дополнительными имущественными паевыми взносами каждого члена Сообщества, увеличивает общий Складочный капитал Сообщества принципу золотого сечения:
|
||||
|
||||
- 9000 × 1,618 = 14 562 рублей дополнительно распределяются среди всех участников Сообщества, которые вносили взносы ранее — будь то идеи, ресурсы или действия.
|
||||
|
||||
Таким образом, каждый новый вклад не просто добавляет ценность в систему — он увеличивает капитализацию всех предыдущих интеллектуальных вложений.
|
||||
|
||||
В результате:
|
||||
- Авторы получают “премию” за свои идеи, подтверждённые действиями.
|
||||
- Создатели получают оплату за работу и дополнительную “премию” в рамках командного круга.
|
||||
- Сообщество в целом и его участники видят, как их накопленные взносы постоянно растут за счёт механизма взаимного усиления.
|
||||
|
||||
Этот принцип обеспечивает непрерывное развитие интеллектуального капитала и создаёт эффект волнового роста, при котором не только у каждого нового предложения фиксируется стоимость, но и капитализирует все предыдущих результатов, связывая их в единую систему долгосрочного роста.
|
||||
|
||||
|
||||
## Выгода
|
||||
|
||||
Генерация и Капитализация РИД создает фундамент для роста Сообщества, но сама по себе не является конечной выгодой. Для обретения практической ценности, она должна превратиться в экономический поток, который обеспечивается функционированием платформы Кооперативной Экономики. Этот поток формируется через документооборот, осуществляемый в рамках кооперативных контрактов, которые оплачиваются в AXON — утилитарном токене платформы.
|
||||
|
||||
Экономическая модель построена на механизме сеньоража, который активируется только при увеличении оборота токенов AXON в рамках одного цикла. Это означает, что выгода каждого участника зависит от роста документооборота, а не от статического владения токенами или интеллектуальными правами. При этом ключевым элементом является автоматическая эмиссия, которая запускается, когда платформа демонстрирует прирост объема произведенных документов.
|
||||
|
||||
```mermaid
|
||||
graph TD;
|
||||
benefit["Выгода"] -->|Создаётся через| doc_flow["Рост документооборота"]
|
||||
doc_flow -->|Измеряется в| axon["Токен AXON"]
|
||||
|
||||
doc_flow -->|При увеличении| emission["Автоматическая эмиссия AXON"]
|
||||
emission -->|Пополняет| return_fund["Фонд возвратов в RUB"]
|
||||
return_fund -->|Распределяет| contributors["Вознаграждения участникам"]
|
||||
|
||||
contributors -->|Получают выгоду от| past_contributions["Ранее сделанных вкладов"]
|
||||
contributors -->|Мотивированы к| ecosystem_growth["Развитию экосистемы"]
|
||||
|
||||
```
|
||||
|
||||
Чтобы понять, как работает эта система, рассмотрим простой пример.
|
||||
|
||||
Предположим, что в первую неделю на платформе было произведено 1000 документов, а на вторую — 1200 документов. Это означает, что за цикл платформа показала прирост документооборота на 200 документов. Если каждый документ оплачивается в 1 AXON, то финансовый прирост оборота за этот цикл составляет 200 AXON.
|
||||
|
||||
Система реагирует на этот прирост, умножая его на коэффициент 1.618. Это значит, что запускается эмиссия 200 × 1.618 = 323 AXON, которые поступают в фонд возвратов Сообщества. Эти токены распределяются среди участников, ранее внесших вклад в проекты, которые обеспечили рост документооборота.
|
||||
|
||||
Таким образом, каждое увеличение оборота приводит к автоматическому созданию новых ресурсов, которые затем перераспределяются в Сообществе. Это создает прямую связь между интеллектуальной деятельностью, ростом документооборота и выплатами участникам.
|
||||
|
||||
|
||||
|
||||
Важно понимать, что система работает только на приросте. Если объем документооборота не увеличивается, то эмиссия не производится, а выплаты сеньоража прекращаются. Это исключает возможность инфляционного разбавления стоимости токенов и стимулирует Сообщество постоянно развивать проекты, которые обеспечивают рост документооборота.
|
||||
|
||||
Выгода в этой модели формируется на нескольких уровнях.
|
||||
|
||||
__Во-первых__, создатели и авторы получают сгенерированную стоимость РИД как совершенные ими взносы. Каждый проект, запускаемый в Сообществе, не просто фиксирует интеллектуальную ценность, но и создает условия для дальнейшего роста. Чем больше документов порождает конкретный проект, тем больше эмиссия, и, следовательно, тем выше стоимость паевых взносов, сделанных ранее.
|
||||
|
||||
|
||||
__Во-вторых__, все члены Сообщества, которые вносили вклад ранее, получают капитализацию своих взносов пропорционально доле в сеньораже. Например, если кто-то инвестировал ресурсы или внес интеллектуальный вклад в прошлом, их стоимость увеличивается за счет того, что каждый новый цикл документооборота приводит к автоматическому перераспределению части вновь созданных ресурсов.
|
||||
|
||||
__В-третьих__, это создает естественный механизм самофинансирования. В отличие от традиционных моделей, где финансовые поступления зависят от внешних инвестиций или одноразовых продаж, здесь весь процесс поддерживается за счет постоянного развития интеллектуальной деятельности и документооборота.
|
||||
|
||||
Благодаря этой модели Сообщество избегает дестабилизирующих факторов, таких как инфляция, стагнация или зависимость от ограниченного числа крупных инвесторов. Здесь каждый участник заинтересован в развитии платформы, потому что его выгода не ограничивается разовыми выплатами, а встроена в общий механизм роста экосистемы.
|
||||
|
||||
|
||||
Таким образом, платформа Кооперативной Экономики представляет собой сбалансированную систему, в которой каждый вклад обеспечивает долгосрочную ценность. Чем активнее Сообщество, тем больше ресурсов возвращается участникам, формируя устойчивый экономический цикл и создавая прочный фундамент для дальнейшего роста и развития.
|
||||
|
||||
|
||||
## Заключение
|
||||
|
||||
__Кооперативная Экономика__ — это система, в которой интеллектуальный труд капитализируется по объективным правилам, а ценность создаётся через непрерывный рост интеллектуального капитала. Вложенное время, идеи и действия фиксируются, усиливают стоимость всех предыдущих вкладов и формируют основу для дальнейшего развития.
|
||||
|
||||
Документооборот, возникающий в процессе работы проектов, подтверждает ценность созданных результатов и запускает экономический механизм возврата вложений. Рост документооборота увеличивает оборот токенов AXON, что обеспечивает выплаты по вложенным идеям, действиям и ресурсам.
|
||||
|
||||
При увеличении документооборота автоматически запускается эмиссия новых токенов, которые поступают в фонд возвратов Сообщества. Эти токены распределяются между участниками, внесшими вклад в предыдущих циклах, усиливая их участие в общем успехе. Этот механизм создаёт замкнутую, самоподдерживающуюся систему, в которой развитие зависит от активности участников и стратегических решений Сообщества.
|
||||
|
||||
Модель объединяет интеллектуальный капитал с ценностями людей. Каждый участник вносит свой вклад, двигаясь в сторону своих ценностных ориентиров, закреплённых в волновом плане. Это стимулирует создание новых идей и обеспечивает их осмысленное развитие в рамках общих целей Сообщества.
|
||||
|
||||
Кооперативная Экономика формирует устойчивую систему роста, в которой интеллектуальный труд капитализируется, проекты формируют экономический поток, а Сообщество развивается на основе долгосрочной ценности. Активное участие и совместная деятельность увеличивают капитализацию идей, расширяют ресурсы участников и создают прочный фундамент для будущего роста.
|
||||
@@ -0,0 +1,53 @@
|
||||
В индустриальную эпоху капиталом считались материальные активы — земля, фабрики, оборудование. Затем, в финансовую эру, на первый план вышли денежные инструменты — акции, облигации, кредиты. Сегодня, в цифровую эпоху, главную ценность формируют идеи. Интеллектуальный капитал становится основой экономики, но его потенциал ограничен существующими методами оценки и распределения.
|
||||
|
||||
Кооперативная Экономика предлагает новый способ генерации и капитализации результатов интеллектуальной деятельности (РИД). Здесь идея — это капитал, а её ценность определяется затраченным временем и ресурсами на её реализацию. Вместо банального перераспределения существующих активов возникает механизм роста, при котором каждый новый интеллектуальный вклад увеличивает стоимость всех предыдущих.
|
||||
|
||||
---
|
||||
|
||||
## Генерация и капитализация РИД
|
||||
|
||||
Капитализация РИД включает два ключевых этапа:
|
||||
|
||||
- **Генерация РИД** — разработка идей и предложений, для чего концентрируются усилия, затрачивается время и ресурсы.
|
||||
- **Капитализация РИД** — признание стоимости интеллектуального вклада и его закрепление в Кооперативе.
|
||||
|
||||
Идеи оформляются в виде предложений и встраиваются в волновой план — систему мониторинга и прогнозов роста, управляемую ИИ-агентами. ИИ-агенты анализируют, структурируют и рекомендуют предложения, помогая Сообществу адаптироваться к изменениям.
|
||||
|
||||
Когда идея принимается к реализации, её ценность подтверждается затраченным временем и действиями участников. Сгенерированная стоимость РИД формируется с учетом принципа золотого сечения (1,618), который устанавливает пропорции между трудом создателей и ценностью авторских идей.
|
||||
|
||||
Допустим, создатель инвестирует **1 час** в реализацию идеи, а номинальная стоимость часа — **3000 рублей**. В этот момент возникает сгенерированная стоимость РИД **9000 рублей**, распределяемая так:
|
||||
|
||||
- **3000 рублей** — оплата труда создателя;
|
||||
- **1146 рублей** (3000 × 0,382) — премия создателей, распределяемая внутри командного круга;
|
||||
- **4854 рубля** (3000 × 1,618) — премия авторов, закрепляющая ценность идеи.
|
||||
|
||||
Затем суммарная стоимость РИД **9000 рублей** вносится в Кооператив как паевой взнос и увеличивает общую стоимость всех предыдущих вкладов. Далее, по принципу золотого сечения, ещё **9000 × 1,618 = 14 562 рублей** дополнительно распределяются среди участников, ранее внесших вклад, создавая, таким образом, капитализацию РИД.
|
||||
|
||||
---
|
||||
|
||||
## Экономический поток и возврат вложений
|
||||
|
||||
Кооперативная Экономика не просто фиксирует ценность идей, но и порождает реальный экономический поток, обеспечивающий возврат вложений. Он формируется через электронный документооборот платформы для кооперативов, который оплачивается ими в утилити-токене AXON.
|
||||
|
||||
Когда документооборот платформы растёт, запускается автоматическая эмиссия новых токенов, которые поступают в фонд возвратов Сообщества. Эмиссия рассчитывается по приросту документооборота за цикл:
|
||||
|
||||
- **Первая неделя**: произведено **1000 документов**.
|
||||
- **Вторая неделя**: **1200 документов**.
|
||||
- **Прирост**: **200 документов × 1 AXON = 200 AXON**.
|
||||
- **Эмиссия**: **200 × 1,618 = 323 AXON**, поступающих в фонд возвратов.
|
||||
|
||||
Эти токены распределяются среди участников, внесших вклад для дальнейших возвратов им, создавая устойчивый механизм саморазвития системы. Если же документооборот не растёт, эмиссия не производится, что исключает инфляцию и мотивирует Сообщество наращивать РИДы.
|
||||
|
||||
---
|
||||
|
||||
## Защита результатов интеллектуальной деятельности
|
||||
|
||||
Каждый сгенерированный результат интеллектуальной деятельности требует не только капитализации, но и юридической защиты. Кооперативная Экономика закрепляет авторские права участников в системе интеллектуальной собственности. Это создаёт устойчивую модель, в которой:
|
||||
|
||||
- **Авторы** получают защиту своих идей и возможность их капитализации.
|
||||
- **Создатели** фиксируют затраченное время и получают вознаграждение.
|
||||
- **Сообщество** наращивает совокупную стоимость своих активов и формирует долговременную ценность.
|
||||
|
||||
---
|
||||
|
||||
Кооперативная Экономика — это новая экономическая модель, в которой ценность создаётся через интеллектуальный труд, а стоимость знаний растёт с каждым новым интеллектуальным вкладом. Идеи превращаются в реальные активы, поддерживаются Сообществом, юридически защищаются Кооперативом и монетизируются через экономический оборот платформы.
|
||||
@@ -0,0 +1,411 @@
|
||||
Каждый пайщик при вступлении в любой кооператив платформы получают цифровое удостоверение - карту пайщика.
|
||||
|
||||
Карта пайщика (CARD.COOP) - это цифровое удостоверение пайщика
|
||||
|
||||
Каждая карта пайщика содержит зашифрованную информацию: ФИО, дату рождения, адрес электронной почты, по желанию пайщика - паспортные данные. Кроме информации о пайщике, каждая карта содержит приватный ключ, которым пайщик подписывает документы на платформе, а также информацию о том, какой кооператив выпустил карту, и о тех кооперативах, кто подтвердил корректность персональных данных на этой карте.
|
||||
|
||||
Карты пайщика выпускаются кооперативами с использованием сервиса CARD.COOP. Для выпуска карт кооперативы используют программное обеспечение провайдеров, которые обеспечивают реализацию стандартизированных сценариев, описанных в этом разделе посредством официальных SDK или публичных точек доступа API.
|
||||
|
||||
|
||||
## Краткое описание
|
||||
Система представляет собой стандарт для безопасной регистрации, аутентификации и обмена конфиденциальными данными между пользователями и кооперативами. Она использует протокол с нулевым разглашением (zero-knowledge), что означает, что сервер никогда не знает реального пароля пользователя, его ключей подписи или приватных данных. Вся чувствительная информация шифруется на стороне клиента, и сервер хранит только зашифрованные данные.
|
||||
|
||||
|
||||
## Основные компоненты системы
|
||||
Пользователь при регистрации или входе в любой кооператив платформы взаимодействует только с клиентским сервисом id.card.coop, который обеспечивает безопасное предоставление зашифрованных данных кооперативу и обеспечивает цифровую подпись документов без передачи приватного ключа за пределы клиентского приложения.
|
||||
|
||||
__Пользователь__: Человек, который хочет зарегистрироваться и использовать систему для хранения и обмена конфиденциальными данными с кооперативами.
|
||||
|
||||
__Клиентское приложение__: Веб-сайт стандарта CARD.COOP, который пользователь использует в браузере для взаимодействия с системой.
|
||||
|
||||
__Сервер__: Бэкенд стандарта CARD.COOP, который обрабатывает запросы от клиентского приложения, хранит зашифрованные данные и управляет аутентификацией и авторизацией.
|
||||
|
||||
__Кооператив__: Организация или сервис, которому пользователь может предоставить доступ к своим конфиденциальным данным. Обычно это кооператив, который использует программное обеспечение своего провайдера.
|
||||
|
||||
## Как работает система
|
||||
Работу системы CARD.COOP можно разделить для пользователя на 5 этапов: регистрация, сохранение данных, предоставление доступа, подпись документов и отзыв доступа.
|
||||
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Пользователь
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
participant Кооператив
|
||||
|
||||
Кооператив->>Пользователь: Запрос доступа
|
||||
|
||||
Пользователь->>Клиент: Регистрация / Вход
|
||||
Клиент->>Сервер: Аутентификация
|
||||
Сервер-->>Клиент: Токены доступа
|
||||
|
||||
Пользователь->>Клиент: Ввод приватных данных
|
||||
Клиент->>Клиент: Генерация ключа подписи
|
||||
Клиент->>Клиент: Шифрование данных
|
||||
|
||||
Клиент->>Сервер: Сохранение зашифрованных данных
|
||||
|
||||
Пользователь->>Клиент: Предоставление доступа
|
||||
|
||||
Клиент->>Сервер: Запрос личных данных и информации о кооперативе
|
||||
Сервер-->>Клиент: Зашифрованные данные
|
||||
|
||||
Клиент->>Клиент: Дешифрование данных
|
||||
|
||||
Клиент->>Клиент: Перешифрование личных данных только для кооператива
|
||||
|
||||
Клиент->>Сервер: Сохранение данных для кооператива
|
||||
|
||||
Сервер-->>Клиент: Тикет доступа
|
||||
Клиент->>Кооператив: Передача тикета
|
||||
|
||||
Кооператив->>Сервер: Обмен тикета на токен
|
||||
Сервер-->>Кооператив: Токен доступа кооператива
|
||||
Кооператив->>Сервер: Запрос данных
|
||||
Сервер-->>Кооператив: Зашифрованные данные
|
||||
Кооператив->>Кооператив: Расшифровка данных
|
||||
|
||||
Кооператив ->>Пользователь: Документ на подпись
|
||||
|
||||
Пользователь ->>Клиент: Ввод PIN-кода
|
||||
Клиент->>Клиент: Дешифрование ключа подписи
|
||||
Клиент->>Клиент: Цифровая подпись документа
|
||||
Клиент->>Кооператив: Подписанный документ
|
||||
|
||||
Пользователь->>Клиент: Отзыв доступа
|
||||
Клиент->>Сервер: Удаление зашифрованных данных для кооператива
|
||||
|
||||
```
|
||||
|
||||
### Вход / регистрация
|
||||
При регистрации пользователь вводит email, пароль. Из пароля генерируется мастер-ключ для шифрования данных, и хэш-ключ, который используется на сервере в качестве пароля.
|
||||
|
||||
После ввода почты, пароля, сервер предоставляет клиенту токены доступа, которые клиент пользователя теперь будет прикладывать к каждому запросу, подтверждая собственную авторизацию.
|
||||
|
||||
Пользователь попадает на этап регистрации при вступлении в любой кооператив. После вступления в любой кооператив, вступление в любой другой кооператив происходит по принципам "быстрого входа" - без повторного личных ввода данных.
|
||||
|
||||
Ввод email: Пользователь начинает процесс регистрации, вводя свой адрес электронной почты в клиентском приложении.
|
||||
|
||||
Получение серверной соли и UUID: Клиентское приложение отправляет email на сервер, и сервер отвечает, предоставляя уникальный идентификатор (UUID) и серверную соль (server_salt).
|
||||
|
||||
Серверная соль - это случайная строка, которая используется для защиты от атак с использованием заготовленных таблиц.
|
||||
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Пользователь
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
|
||||
Пользователь->>Клиент: Вводит email (user@example.com)
|
||||
Клиент->>Сервер: POST /auth/initiate-registration<br/>{"email": "user@example.com"}
|
||||
Сервер-->>Клиент: {"uuid": "...", "serverSalt": "..."}
|
||||
|
||||
Пользователь->>Клиент: Вводит пароль
|
||||
Клиент->>Клиент: Генерирует хэш-ключ
|
||||
Клиент->>Сервер: POST /auth/complete-registration<br/>{"email": "user@example.com", "hashKey": "...", "uuid": "..."}
|
||||
Сервер-->>Клиент: {"accessToken": "...", "refreshToken": "..."}
|
||||
```
|
||||
|
||||
Генерация хэш-ключа: Клиентское приложение использует введенный пользователем пароль и полученную серверную соль для создания хэш-ключа (hashKey). Это делается с помощью криптографической функции хэширования, которая повторяется 1000 итераций.
|
||||
|
||||
```
|
||||
hashKey = hash(пароль + server_salt + 1000)
|
||||
```
|
||||
|
||||
Отправка hashKey на сервер: Клиентское приложение отправляет на сервер email, hashKey и UUID.
|
||||
|
||||
Сохранение пользователя: Сервер сохраняет информацию о пользователе, включая email, hashKey и серверную соль. Поскольку сервер знает только хэшированную версию пароля, он не может узнать сам пароль.
|
||||
|
||||
Выдача токенов: Сервер генерирует пару токенов — accessToken и refreshToken — и отправляет их клиентскому приложению.
|
||||
|
||||
Сохранение токенов: Клиентское приложение сохраняет полученные токены для последующего использования.
|
||||
|
||||
|
||||
|
||||
|
||||
### Сохранение данных
|
||||
|
||||
пользователь вводит персональные данные. Данные зашифровываются и сохраняются на сервере с использованием мастер-ключа и пинкода пользователя. Сервер никогда не получает пароль или мастер-ключ пользователя, и не может расшифровать данные без пользователя. Все криптографические операции по работе с данными пользователь выполняет у себя на клиенте.
|
||||
|
||||
и устанавливает пин-кодПин-код же используется для дополнительного шифрования ключа подписи карты в локальном хранилище клиента пользователя, откуда ключ извлекаются для подписи любого документа в дальнейшем.
|
||||
|
||||
|
||||
2. Выпуск карты пользователя
|
||||
Ввод приватных данных: Пользователь вводит свои личные данные, которые он хочет сохранить (например, паспортные данные, личные заметки и т.д.).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2. Выпуск карты пользователя
|
||||
Ввод приватных данных: Пользователь вводит свои личные данные, которые он хочет сохранить (например, паспортные данные, личные заметки и т.д.).
|
||||
|
||||
Генерация AES-ключа: Клиентское приложение создает симметричный ключ шифрования (AESKey) на основе пароля пользователя и его email (используется в качестве соли). Это делается с помощью функции деривации ключа с большим количеством итераций (например, 100000), чтобы усложнить перебор ключей.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Пользователь
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
|
||||
Пользователь->>Клиент: Вводит приватные данные
|
||||
Клиент->>Клиент: Генерирует AESKey = deriveKey(пароль, email, 100000)
|
||||
Клиент->>Клиент: Генерирует username и WIFKey
|
||||
Клиент->>Клиент: Шифрует данные и WIFKey с помощью AESKey
|
||||
Клиент->>Сервер: POST /card/issue<br/>{"username": "...", "encryptedData": "...", "coopName": "...", "signature": "..."}<br/>Authorization: Bearer accessToken
|
||||
Сервер-->>Клиент: {"id": "...", "username": "...", "coopName": "..."}
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
AESKey = deriveKey(пароль, email, 100000)
|
||||
```
|
||||
|
||||
Шифрование данных: Приватные данные и, возможно, приватный ключ пользователя (например, WIFKey) шифруются с использованием AESKey. Это гарантирует, что данные могут быть расшифрованы только с правильным паролем.
|
||||
|
||||
Отправка зашифрованных данных на сервер: Клиентское приложение отправляет на сервер username, зашифрованные данные (encryptedData), название кооператива (coopName) и цифровую подпись (signature).
|
||||
|
||||
Сохранение карты: Сервер сохраняет информацию о карте пользователя, включая username, encryptedData, coopName, signature и идентификатор пользователя.
|
||||
|
||||
3. Аутентификация пользователя (Вход)
|
||||
Ввод email и пароля: Пользователь вводит свой email и пароль для входа в систему.
|
||||
|
||||
Получение серверной соли и UUID: Клиентское приложение отправляет email на сервер, и сервер отвечает, предоставляя server_salt и UUID.
|
||||
|
||||
Генерация hashKey: Клиентское приложение снова генерирует hashKey с использованием введенного пароля и полученной серверной соли.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Пользователь
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
|
||||
Пользователь->>Клиент: Вводит email (user@example.com)
|
||||
Клиент->>Сервер: POST /auth/initiate-login<br/>{"email": "user@example.com"}
|
||||
Сервер-->>Клиент: {"uuid": "...", "serverSalt": "..."}
|
||||
|
||||
Пользователь->>Клиент: Вводит пароль
|
||||
Клиент->>Клиент: Генерирует hashKey = hash(пароль + serverSalt + 1000)
|
||||
Клиент->>Сервер: POST /auth/complete-login<br/>{"email": "user@example.com", "hashKey": "...", "uuid": "..."}
|
||||
Сервер-->>Клиент: {"accessToken": "...", "refreshToken": "..."}
|
||||
Клиент->>Пользователь: Сохраняет accessToken и refreshToken
|
||||
```
|
||||
|
||||
```
|
||||
hashKey = hash(пароль + server_salt + 1000)
|
||||
```
|
||||
|
||||
Отправка hashKey на сервер: Клиентское приложение отправляет на сервер email, hashKey и UUID.
|
||||
|
||||
Проверка на сервере: Сервер сравнивает полученный hashKey с тем, который хранится в базе данных для этого email.
|
||||
|
||||
Выдача токенов: Если hashKey совпадает, сервер генерирует новый accessToken и refreshToken и отправляет их клиентскому приложению.
|
||||
|
||||
4. Предоставление доступа кооперативу
|
||||
Переход по ссылке кооператива: Кооператив направляет пользователя на сайт системы с параметрами coopName и callbackUrl.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Пользователь
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
participant Кооператив
|
||||
|
||||
Кооператив->>Пользователь: Перенаправляет на id.card.coop с coopName и callbackUrl
|
||||
Пользователь->>Клиент: Переходит на id.card.coop
|
||||
Клиент->>Сервер: POST /access/prepare-share-data<br/>{"coopName": "exampleCoop"}<br/>Authorization: Bearer accessToken
|
||||
Сервер->>Сервер: Получает coopPublicKey
|
||||
Сервер-->>Клиент: {"coopName": "exampleCoop", "coopPublicKey": "COOP_PUBLIC_KEY"}
|
||||
```
|
||||
|
||||
Получение информации о кооперативе: Клиентское приложение отправляет запрос на сервер, чтобы получить информацию о кооперативе, включая его публичный ключ (coopPublicKey).
|
||||
|
||||
Получение и расшифровка данных: Клиентское приложение запрашивает зашифрованные данные пользователя с сервера и расшифровывает их с использованием AESKey.
|
||||
|
||||
Перешифровка данных для кооператива: Расшифрованные данные затем шифруются на клиенте с использованием публичного ключа кооператива (coopPublicKey). Это гарантирует, что только кооператив сможет расшифровать эти данные своим приватным ключом.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Пользователь
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
|
||||
Клиент->>Сервер: GET /card/get<br/>Authorization: Bearer accessToken
|
||||
Сервер-->>Клиент: {"encryptedData": "encrypted-private-data-xyz"}
|
||||
|
||||
Клиент->>Клиент: Расшифровывает encryptedData с помощью AESKey
|
||||
Клиент->>Клиент: Перешифровывает данные с использованием coopPublicKey (COOP_PUBLIC_KEY)
|
||||
Клиент->>Сервер: POST /access/share-data<br/>{"coopName": "exampleCoop", "encryptedData": "encrypted-data-for-coop-999"}<br/>Authorization: Bearer accessToken
|
||||
Сервер-->>Клиент: {"ticket": "access-ticket-abcdef"}
|
||||
Клиент->>Пользователь: Перенаправляет обратно на сайт кооператива с ticket
|
||||
|
||||
```
|
||||
|
||||
Отправка перешифрованных данных на сервер: Клиентское приложение отправляет зашифрованные для кооператива данные на сервер вместе с coopName.
|
||||
|
||||
Получение тикета: Сервер сохраняет зашифрованные данные и возвращает уникальный тикет (accessId), который будет использоваться кооперативом для доступа к данным.
|
||||
|
||||
Перенаправление на кооператив: Клиентское приложение перенаправляет пользователя обратно на сайт кооператива, передавая ему полученный тикет.
|
||||
|
||||
5. Получение данных кооперативом
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Кооператив
|
||||
participant Сервер
|
||||
|
||||
Кооператив->>Сервер: POST /access/exchange-ticket<br/>{"ticket": "access-ticket-abcdef"}
|
||||
Сервер->>Сервер: Проверяет валидность ticket
|
||||
Сервер-->>Кооператив: {"accessToken": "coop-access-token-112233"}
|
||||
```
|
||||
|
||||
Обмен тикета на токен: Кооператив отправляет тикет на сервер и обменивает его на специальный accessToken, который предоставляет ограниченный доступ к данным пользователя.
|
||||
|
||||
Запрос зашифрованных данных: Кооператив использует полученный accessToken для запроса зашифрованных данных пользователя с сервера.
|
||||
|
||||
Расшифровка данных: Кооператив получает зашифрованные данные и расшифровывает их с помощью своего приватного ключа. Теперь он имеет доступ к информации, которую пользователь решил ему предоставить.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Кооператив
|
||||
participant Сервер
|
||||
|
||||
Кооператив->>Сервер: GET /access/get-encrypted-data/user123/exampleCoop<br/>Authorization: Bearer coop-access-token-112233
|
||||
Сервер->>Сервер: Проверяет coopAccessToken и права доступа
|
||||
Сервер-->>Кооператив: {"encryptedData": "encrypted-data-for-coop-999"}
|
||||
Кооператив->>Кооператив: Расшифровывает encryptedData с помощью coopPrivateKey
|
||||
```
|
||||
|
||||
6. Управление доступом
|
||||
Отзыв доступа: Пользователь может в любой момент отозвать доступ кооператива к своим данным. Для этого он отправляет соответствующий запрос на сервер, и сервер удаляет зашифрованные данные для этого кооператива.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Пользователь
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
|
||||
Пользователь->>Клиент: Решает отозвать доступ у exampleCoop
|
||||
Клиент->>Сервер: DELETE /access/revoke/exampleCoop<br/>Authorization: Bearer accessToken
|
||||
Сервер->>Сервер: Удаляет AccessRequest для пользователя и exampleCoop
|
||||
Сервер-->>Клиент: {"message": "Доступ успешно отозван"}
|
||||
```
|
||||
|
||||
Просмотр списка доступов: Пользователь может запросить список кооперативов, которым он предоставил доступ, и управлять ими.
|
||||
|
||||
7. Обновление токенов и выход из системы
|
||||
Обновление accessToken: Когда срок действия accessToken истекает, клиентское приложение может использовать refreshToken для получения нового accessToken, отправив соответствующий запрос на сервер.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
|
||||
Клиент->>Сервер: POST /auth/refresh-token<br/>Authorization: Bearer refreshToken
|
||||
Сервер->>Сервер: Проверяет refreshToken
|
||||
Сервер-->>Клиент: {"accessToken": "new-access-token", "refreshToken": "new-refresh-token"}
|
||||
Клиент->>Клиент: Сохраняет новые accessToken и refreshToken
|
||||
```
|
||||
|
||||
Выход из системы: Пользователь может выйти из системы, и сервер аннулирует его refreshToken, что предотвращает дальнейшее использование токенов для доступа к системе.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
|
||||
Клиент->>Сервер: POST /auth/logout<br/>Authorization: Bearer refreshToken
|
||||
Сервер->>Сервер: Отзывает refreshToken
|
||||
Сервер-->>Клиент: {"message": "Вы успешно вышли из системы"}
|
||||
Клиент->>Клиент: Очищает сохраненные токены
|
||||
```
|
||||
|
||||
## Примечания
|
||||
### Участники:
|
||||
|
||||
Пользователь: Конечный пользователь, взаимодействующий с системой.
|
||||
Клиент: Клиентское приложение (например, веб-браузер или мобильное приложение).
|
||||
Сервер: Бэкенд-сервер, обрабатывающий API-запросы.
|
||||
Кооператив: Кооператив, запрашивающий доступ к данным пользователя.
|
||||
|
||||
Заголовки авторизации:
|
||||
accessToken пользователя используется для аутентификации запросов от клиента к серверу.
|
||||
coopAccessToken кооператива используется кооперативом для доступа к данным пользователя после обмена тикета.
|
||||
Шифрование данных:
|
||||
|
||||
AESKey: Получен путем деривации пароля пользователя и email, используется для шифрования/дешифрования приватных данных на стороне клиента.
|
||||
|
||||
coopPublicKey: Публичный ключ кооператива, используется клиентом для перешифровки данных для кооператива.
|
||||
|
||||
coopPrivateKey: Приватный ключ кооператива, используется для расшифровки полученных от сервера данных.
|
||||
|
||||
|
||||
Токены и тикеты:
|
||||
accessToken: Краткосрочный JWT для аутентификации запросов.
|
||||
refreshToken: Долгосрочный токен для получения новых accessToken.
|
||||
ticket: Уникальный идентификатор, используемый кооперативом для обмена на accessToken.
|
||||
Процессы:
|
||||
|
||||
|
||||
## Алгоритм и методы
|
||||
|
||||
|
||||
|
||||
|
||||
## Преимущества системы
|
||||
Регистрация и вход реализуют протокол нулевого разглашения (zero-knowledge), при котором сервер никогда не видит реальный пароль пользователя. Предоставление доступа требует согласия пользователя и включает перешифровку данных специально для кооператива. Отзыв доступа удаляет возможность кооператива получать данные пользователя. Обновление токенов и выход обеспечивают непрерывность сессии и безопасность.
|
||||
|
||||
Безопасность: Поскольку сервер никогда не видит пароли или приватные данные пользователя в открытом виде, риск компрометации информации значительно снижается.
|
||||
|
||||
Контроль пользователя: Пользователь полностью контролирует, кому и какие данные он предоставляет. Он может в любой момент отозвать доступ или предоставить его повторно.
|
||||
|
||||
Гибкость: Система поддерживает множественные кооперативы, и пользователь может взаимодействовать с разными организациями, предоставляя им доступ к своим данным по мере необходимости.
|
||||
|
||||
Приватность: Использование асимметричного шифрования гарантирует, что только кооператив, которому предназначены данные, сможет их расшифровать.
|
||||
|
||||
Пример сценария использования
|
||||
Регистрация: Ирина регистрируется в системе, используя свой email и пароль. Ее пароль никогда не отправляется на сервер в открытом виде.
|
||||
|
||||
Сохранение данных: Она вводит свои персональные данные и сохраняет их в зашифрованном виде на сервере.
|
||||
|
||||
Предоставление доступа: Кооператив "Здоровье" запрашивает у Ирины доступ к ее медицинским данным. Ирина соглашается и предоставляет доступ, перешифровывая свои данные на публичный ключ кооператива.
|
||||
|
||||
Получение данных кооперативом: Кооператив "Здоровье" получает зашифрованные данные и расшифровывает их своим приватным ключом.
|
||||
|
||||
Отзыв доступа: Позже Ирина решает отозвать доступ кооператива к ее данным и делает это через клиентское приложение.
|
||||
|
||||
## Заключение
|
||||
Система обеспечивает безопасное хранение и обмен конфиденциальными данными, предоставляя пользователю полный контроль над своими данными и тем, кто к ним имеет доступ. Использование протокола с нулевым разглашением и асимметричного шифрования делает систему надежной и устойчивой к компрометации данных.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
CARD.COOP - это стандарт, и его код опубликован. Клиентов и серверов CARD.COOP может быть много - как личных, пользовательских, так и кооперативных. Исполнение стандарта CARD.COOP возможно в физических (пластиковых) картах и мобильных приложениях.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Пользователь
|
||||
participant Клиент
|
||||
participant Сервер
|
||||
participant Кооператив
|
||||
|
||||
Кооператив->>Пользователь: Запрос доступа
|
||||
|
||||
Пользователь->>Клиент: Регистрация / Вход
|
||||
Клиент->>Сервер: Аутентификация
|
||||
Сервер-->>Клиент: Токены доступа
|
||||
```
|
||||
@@ -1,18 +1,8 @@
|
||||
[пайщик -> кооператив -> провайдер -> платформа]
|
||||
|
||||
Пайщик, обращаясь к одному из подключенных кооперативов на платформе, обращается в программное обеспечение провайдера, который предоставляет его кооперативу сервис. Кооператив же обладает соглашением с провайдером о правилах и условиях предоставления сервиса.
|
||||
|
||||
!!!note "Провайдеры - это организации, которые предоставляют кооперативам программное обеспечение платформы кооперативной экономики как готовый сервис "с кнопками". "
|
||||
|
||||
|
||||
Провайдеры обеспечивают для кооперативов и их пайщиков контроль прав доступа к реестрам и фабрике документов. Фабрика документов производит цифровые документы в соответствии с методологией кооперации в моменты нажатия пайщиком соответствующих кнопок в приложении провайдера на основании информации из реестров.
|
||||
|
||||
!!!note "Фабрика документов - стандатизированное программное обеспечение провайдеров для производства цифровых документов"
|
||||
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
Пайщик[Пайщик] --> ПрограммноеОбеспечение[(Программное обеспечение Провайдера)]
|
||||
Пайщик[Пайщик] --> Кооператив[Кооператив]
|
||||
Кооператив --> ПрограммноеОбеспечение[(Программное обеспечение Провайдера)]
|
||||
|
||||
subgraph ПрограммноеОбеспечение[Программное обеспечение Провайдера]
|
||||
Контроллер[Контроллер доступа]
|
||||
@@ -33,8 +23,18 @@ flowchart TB
|
||||
КооперативныйКонтракт --> СистемныеКонтракты
|
||||
СистемныеКонтракты --> РаспределеннаяБаза
|
||||
end
|
||||
|
||||
```
|
||||
|
||||
Пайщик, обращаясь к одному из подключенных кооперативов на платформе, обращается в программное обеспечение провайдера, который предоставляет его кооперативу сервис. Кооператив же обладает соглашением с провайдером о правилах и условиях предоставления сервиса.
|
||||
|
||||
!!!note "Провайдеры - это организации, которые предоставляют кооперативам программное обеспечение платформы кооперативной экономики как готовый сервис "с кнопками". "
|
||||
|
||||
|
||||
Провайдеры обеспечивают для кооперативов и их пайщиков контроль прав доступа к реестрам и фабрике документов. Фабрика документов производит цифровые документы в соответствии с методологией кооперации в моменты нажатия пайщиком соответствующих кнопок в приложении провайдера на основании информации из реестров.
|
||||
|
||||
!!!note "Фабрика документов - стандатизированное программное обеспечение провайдеров для производства цифровых документов"
|
||||
|
||||
Фактическое подключение кооперативов осуществляется оператором. Оператор платформы кооперативной экономики осуществляет исполнение кооперативного смарт-контракта о подключении нового кооператива, результатом которого является регистрация аккаунтов в блокчейне и конфигурация системных смарт-контрактов, необходимая для нормальной работы подключенного кооператива.
|
||||
|
||||
```mermaid
|
||||
|
||||
+4
-4
@@ -8,10 +8,10 @@ BASE_PATH=$BASE_PATH
|
||||
mkdocs build
|
||||
|
||||
# # Переключаемся в директорию contracts, генерируем документацию и копируем
|
||||
cd "$BASE_PATH/contracts" || exit
|
||||
doxygen
|
||||
mkdir -p "$BASE_PATH/docsdocsdocs/coopenomics/site/contracts"
|
||||
rsync -r docs/html/* "$BASE_PATH/docsdocsdocs/coopenomics/site/contracts"
|
||||
#cd "$BASE_PATH/contracts" || exit
|
||||
#doxygen
|
||||
#mkdir -p "$BASE_PATH/docsdocsdocs/coopenomics/site/contracts"
|
||||
#rsync -r docs/html/* "$BASE_PATH/docsdocsdocs/coopenomics/site/contracts"
|
||||
|
||||
# # Переключаемся в директорию cooptypes, генерируем документацию и копируем
|
||||
# cd "$BASE_PATH/monocoop/components/cooptypes" || exit
|
||||
|
||||
+17
-14
@@ -37,7 +37,7 @@ theme:
|
||||
- navigation.sections
|
||||
- navigation.instant
|
||||
- navigation.instant.prefetch
|
||||
# - navigation.expand
|
||||
- navigation.expand
|
||||
# - toc.follow
|
||||
# - toc.integrate
|
||||
- search.share
|
||||
@@ -110,28 +110,31 @@ markdown_extensions:
|
||||
alternate_style: true
|
||||
nav:
|
||||
- Доктрина: index.md
|
||||
- Капитализация идей:
|
||||
- Кратко об Идеократии: documentation/capitalization/short-ideocraty.md
|
||||
- Идеократия Кооперативной Экономики: documentation/capitalization/ideocraty.md
|
||||
- Платформа:
|
||||
- Введение: documentation/intro.md
|
||||
- Обзор: documentation/overview.md
|
||||
# - Аудентификация и карта пайщика:
|
||||
# - Введение: documentation/cardcoop/intro.md
|
||||
# - Стандарты:
|
||||
- Карта пайщика: documentation/cardcoop.md
|
||||
- Блокчейн:
|
||||
- Введение: documentation/blockchain/intro.md
|
||||
- Аккаунты, ключи и подписи: documentation/blockchain/accounts.md
|
||||
- Действия и транзакции: documentation/blockchain/transactions.md
|
||||
- Таблицы и индексы: documentation/blockchain/state.md
|
||||
|
||||
- Смарт-контракты: documentation/blockchain/contracts.md
|
||||
- Ноды и синхронизация истории: documentation/blockchain/nodes.md
|
||||
- База данных: documentation/blockchain/state.md
|
||||
- Компоненты: documentation/blockchain/components.md
|
||||
# - Делегаты: documentation/blockchain/witnesses.md
|
||||
# - Состав: documentation/blockchain/sostav.md
|
||||
- Быстрый старт: documentation/blockchain/install.md
|
||||
- Протоколы: documentation/blockchain/protocols.md
|
||||
# - Полный старт: documentation/blockchain/install.md
|
||||
# - Командный кошелёк: https://google.com
|
||||
- Типы нод: documentation/blockchain/modes.md
|
||||
- Делегаты и консенсус: documentation/blockchain/witnesses.md
|
||||
- Параметры конфигурации: documentation/blockchain/configuration.md
|
||||
# - Смарт-контракты: documentation/blockchain/contracts.md
|
||||
- Инструкции:
|
||||
- Быстрый старт: documentation/blockchain/install.md
|
||||
# - Полный старт: documentation/blockchain/install.md
|
||||
# - Командный кошелёк: https://google.com
|
||||
|
||||
|
||||
|
||||
# - Синхронизация: documentation/blockchain/sync.md
|
||||
# - API: https://developers.eos.io/welcome/latest/reference/index
|
||||
|
||||
@@ -144,7 +147,7 @@ nav:
|
||||
|
||||
- Подключение: providers.md
|
||||
- Словарь: vocabulary.md
|
||||
- Вопрос-ответ: faq.md
|
||||
# - Вопрос-ответ: faq.md
|
||||
- Контакты: contacts.md
|
||||
|
||||
# - Программные Модули: modules.md
|
||||
|
||||
Reference in New Issue
Block a user