[Сенатор] Ardor блокчейн интеграционна архитектура според публичните документи

3.3. Цифров идентификатор и слой на блокчейн
    Платформата SENATOR ще предоставя набор от услуги, които могат да се използват от различни хора (както физически, така и юридически) и IoT субекти, с които те ще взаимодействат. Взаимодействията между платформата и тези лица и образувания се опосредстват от цифрови идентичности. Цифровите идентичности на Senator се управляват в специфичен модул от архитектурата на Senator, наречен Senator ID. В това отношение доверието между множество страни и външни партньори е от съществено значение. Поради тази причина решихме да включим блокчейн технологията (първоначално експериментална) като основополагаща основа, за да осигурим необходимото доверие за работа със системата.
    Предишни резултати, D1.2 и D1.3, допълнително уточняват пригодността на използването на цифрови идентичности и блокчейн технология и специфични функции в Senator.

3.3.1. Блокчейн: функционално описание
    Блокчейнът е запис или книга на цифрови събития, която е „децентрализирана“ между множество страни. Като алтернатива може да се опише като система от бази данни, която поддържа и записва данни по такъв начин, че множество заинтересовани страни да могат уверено и сигурно да споделят достъп до едни и същи данни и информация. Всяка актуализация на данни, представляващи цифров актив, трябва да бъде съгласувана с мнозинството от участниците в системата. Тези данни, веднъж проверени, никога не могат да бъдат изтрити, така че съдържат ясен и проверим запис на всяка транзакция, гарантирайки оперативна увереност.
    Прилагането на тази технология ще види постепенно приемане в различни случаи на употреба. Следователно най-добрата архитектура в този случай се счита за комбинация от хибридно решение, при което промените се съхраняват в централизирана база данни, а доказателството за промяна се съхранява в блокчейна. Това е идеално решение за осигуряване на най-високо ниво на надеждност на вашата система.
    Избрахме да използваме базирани на Ardor блокчейни, защото те могат да бъдат изградени в рамките на публична мрежа, намалявайки разходите за инфраструктура и поддръжка. Изборът на Ardor се основава на анализа на изискванията и заключенията от Работен пакет 1.
    Има два случая на използване, които проектът планира да приложи: проследяване на транзакции и проследяване на IoT. Ще дадем приоритет на първия случай на употреба и ще внедрим други случаи на употреба въз основа на производителността. Характеристиките и техническите описания за всеки случай на употреба са описани подробно по-долу.

3.3.1.1. проследимост на транзакциите
    Първият случай на употреба иска да покрие важна характеристика на Senator. Ефективната доставка на стоки в градска зона (известна като последната миля) може да изисква управление на пратки между множество транспортни компании. Затова е необходимо да се внедри услуга, която да проследява движението на стоки и колети между фирмите.
    За тази цел предлагаме да използваме базирано на Ardor блокчейн решение. Този подход се състои в използването на Ardor за проследяване на важни и по-важни транзакции в корабните компании, участващи в процеса. Предложеното решение събира транзакции, представляващи движението на пакети между Компания А и Компания Б. Ние не проследяваме движението на пакети в рамките на една и съща компания, тъй като това е отговорност на всяка компания и се управлява частно.
    Прилагането на този случай на използване е от решаващо значение за намаляване на времето за разрешаване, когато две или повече страни, отговорни за доставката, имат спор относно извършената работа. Това ще осигури прост и мощен механизъм за валидиране на транзакции и предоставяне на информация на потребителите и потребителите за това кои компании са участвали в процеса на доставка.

3.3.1.2. IoT проследимост
    Този случай на използване се стреми да записва данни, генерирани от IoT устройства (превозни средства, машини и т.н.), за да се постигне по-проследимо управление на стоките въз основа на информацията, генерирана на всички етапи на IoT устройствата и услугите за доставка, от производството до доставката и обслужването на клиента. Интегрирането с блокчейн ви позволява да поддържате доверие в различните направени измервания, така че по-късно да можете да вземате решения въз основа на записаните данни.
Има две нива на интеграция:
- Данните се събират и използват по-късно за проследяване на стоки и пакети , например колко време отнема доставката на пакет от произхода до клиента, проследяване на маршрута, като се вземат предвид физическите условия като температура, влажност, вибрации и времето, през което е създаден за запис на поредица от събития). В този сценарий всички данни се регистрират и използват за изследване на данни за подобряване на услугата.
- Записаните данни обхващат информация, свързана с различни стойности, представляващи физическите условия, договорени от участващите страни. Например, има температурни пропуски по време на процеса на доставка.

​3.3.2. Блокчейн интеграция
    Във фазата на доказване на концепцията се използва един възел Senator Ardor (SAN). Когато решението влезе в производство, ще се обмисли разполагането на още два възела. Тази технология се развива с много бързи темпове. За да смекчи рисковете, свързани с тези среди, Ardor може да разработи мостове за свързване с други блокчейн услуги. Същият базиран на Ardor блокчейн ще се използва и за двата случая на използване на Senator. Обхватът на проекта включва следните елементи:

- SAN, осигуряващ достъп до публичната блокчейн Ardor

- Централизирана база данни, свързана към SAN.

- Разработване на разширени API операции за вмъкване, запитване и проверка на данни, съхранени в системата

Настройте своя SAN, за да осигурите максимална производителност, минимални транзакционни разходи и достъпност. По-долу е показана диаграма на високо ниво на решението.





И двата случая на използване се основават на набор от архитектурни компоненти, които поддържат проследяването на важни и по-важни транзакции в рамките на агентите, участващи в процеса:

- Действията зависят от API слой, който се извиква от множество агенти, участващи в процеса.

- API операциите, които задействат блокчейн транзакции, са обединени със схема за пакетиране без такси.

- API са REST услуги.

- Има метод (POST) за изпращане на данни към възела Ardor.

- Има метод (GET) за получаване на данни от Ardor node. Ardour не е система за отчитане и не е проектирана да изпълнява анализи или сложни заявки. Обхватът на заявката на решението е да предостави опции за обработка на задачи като:

- Той разбира транзакция със същия полезен товар, както е записан в Ardour, като валидна транзакция, като проверява дали транзакцията, изпратена преди това от SENATOR ID, е валидна.

- Вземете информация за транзакции, записани в Ardour.

- Извличане на транзакции от потребители в даден диапазон от данни.

- възел Ardor. Частен възел в хибридна мрежова настройка, който обработва всички данни за всяка транзакция, изпратена до услугата.

- H2 база данни. База данни, прикрепена към възел на Ardor, която съхранява копия на транзакции в подкрепа на операциите на Ardor.

Решението има и интеграционен компонент с публичната мрежа Ardor. Това решение може да бъде конфигурирано да предава представяне на блок от транзакции към обществената мрежа Ardor. Например, както е показано на фигура 8, 100 транзакции, записани в частните възли на Ardour, хоствани в инфраструктурата на Senator, се изпращат към публичната мрежа. Считайте това за хибридно поведение.



    Платформата Ardor групира транзакции на дъщерни вериги в дъщерни верижни блокове, които се прехвърлят към родителската верига. Този процес се нарича групиране и е отличителен белег на многоверижните възможности на Ardor. Понастоящем блоковете на основната верига на Ardor съдържат до 10 блока дъщерна верига, а всеки блок дъщерна верига съдържа до 100 транзакции. Най-голямото предимство на тази архитектура е мащабируемостта и гъвкавостта. Процесът на групиране на транзакции се нарича групиране и е показан на фигура 8.
    SENATOR ще използва дъщерната верига на IGNIS във фазата на доказване на концепцията. Тази верига събира цялата функционалност и може да бъде мигрирана към собствена дъщерна верига в бъдеще. Senator Bundler ще се състои от компонент на възел, който групира всички транзакции в мрежата и плаща такса за транзакции в блокчейна на партньора. Това означава, че акаунтите на партньорите на SENATOR могат да бъдат маркирани във веригата като атрибути на акаунта, което позволява транзакции без комисионни за партньори.

    ​Различни компоненти на SENATOR комуникират с Ardor чрез API. Възлите на SENATOR Ardor могат да взаимодействат с помощта на HTTP заявки към порта (по подразбиране 27876). Повечето HTTP заявки могат да използват метода GET или POST, но някои извиквания на API приемат само метода POST от съображения за сигурност. Архитектурата на високо ниво е показана на фигура 9.




SAN осигурява цялата функционалност и свързаност към обществената блокчейн мрежа на Ardor. Първата стъпка изисква само един възел в инфраструктурата на SENATOR. В бъдещите производствени сценарии могат да се разглеждат два възела.

Обменените съобщения са във формат JSON и имат следната структура:

- Дескриптор на съобщението

- Тема: По избор, използва се за бъдеща публикация/абонамент.

- Идентификационен номер на корелация (ID на корелация): По избор, използва се за бъдещи заявки за синхронизация.

- Идентификационен номер на група: По избор, използва се за бъдещи заявки за групова обработка.

- Приложение: По избор, използва се за разширено маршрутизиране в бъдеще.

- Идентификатор на съобщението: Идентификаторът на заявката.

- Полезен товар

- CDATA елемент: Всяка заявка се моделира, за да съответства на очакваното съобщение.

- заглавка на разширение (по избор)

​Отговорът се дефинира като съобщение, съдържащо следните елементи:

- Код на причината за Ardor: 0 означава, че съобщението е обработено успешно, 1 означава, че съобщението чака интегриране в блокчейн слоя Ardor, 2 е кодът за грешка.

- ИД на съобщението: Това е уникалният идентификатор на съобщението. Когато се задейства блокчейн транзакция, той е същият като пълния идентификатор на хеш транзакция.

​3.3.3. ID на сенатора: Описание на функцията
    Различните случаи на употреба, идентифицирани в T1.1 „Дефиниране на случаи на употреба и анализ на изискванията“, ни позволяват да посочим изискванията, на които трябва да отговарят цифровите самоличности на Senator. Предложението за основна схема за цифрова идентичност е дефинирано, за да позволи регистрацията на лица и организации, които:

- индивидуален:

- естествен човек

- корпорация

- Субект (IoT)

- превозно средство

- Други бъдещи обекти (шкафчета, интелигентен паркинг, градски центрове и т.н.)​



    Подходът за цифрова идентичност, показан по-горе, осигурява необходимата гъвкавост, за да отговори на идентифицираните случаи на употреба, което му позволява да се развива по прост, мащабируем и сигурен начин, докато добавяме други случаи на употреба в бъдеще.

3.3.4. Интегриране на ID на сенатора
    Платформата SENATOR разчита на модула SENATOR ID за регистрация и достъп от физически лица, юридически лица и IoT субекти, както е дефинирано в T1.1 „Анализ на дефиниции на случаи на използване и анализ на изискванията". Платформата SENATOR може да бъде достъпна по два различни начина:

- Предно уеб/мобилно приложение

-API

От по-техническа гледна точка се предлага архитектура за цифрова идентичност, състояща се от следните компоненти:​


    ​Когато използват предните уеб или мобилни приложения, лица и организации могат да получат достъп до платформата SENATOR, като се регистрират или влязат в екрана, активиран за тази цел. Освен това Senator предлага възможност за достъп до платформата чрез API до платформи на трети страни. Този достъп не се препоръчва за компании и организации с определен размер, но е специално препоръчителен.
    И в двата случая модулът SENATOR ID извиква CORREOSID чрез API след това. CORREOS ID е решение за цифрова идентичност, задвижвано от CORREOS, което понастоящем представлява подхода на регистъра за корпоративни клиенти и се е доказало с времето като стабилно и сигурно решение.

Comments

Popular posts from this blog

Reviewing the strategy -"Rejected"

Monthly report for March 2024

ArdorBG Forging Pool