RO134065A0

RO134065A0 - Platformă şi metodă de conectare a unui motor de blockchain

Info

Publication number: RO134065A0
Application number: ROA201900496A
Authority: RO
Inventors: Alin-Daniel Iftemi
Original assignee: Ingenium Blockchain Technologies S.R.L.
Priority date: 2019-08-14
Filing date: 2019-08-14
Publication date: 2020-04-30
Also published as: US20210103603A1; US11544291B2

Abstract

Invenţia se referă la o platformă şi la o metodă de conectare a unui motor de blockchain cu o bază de date tradiţională. Platforma conform invenţiei este implementată sub forma unei reţele de noduri care este împărţită în cel puţin două subreţele: o subreţea de securitate şi o subreţea de date, toate nodurile din subreţeaua de securitate conţinând informaţii referitoare la cheile de securitate ale utilizatorilor, licenţele de funcţionare, politicile de acces, precum şi alte informaţii care ţin de mecanismul de licenţiere, autentificare şi autorizare a utilizatorilor care accesează platforma, iar nodurile din cel puţin o subreţea de date cuprind o componentă software care foloseşte o reţea de calculatoare, o interfaţă de comunicare API ce permite interacţiunea cu reţeaua de calculatoare şi preluarea informaţiilor care trebuie salvate într-un sistem de stocare, o interfaţă GraphQL de interogare a datelor, un motor de procesare a datelor, un motor blockchain, o interfaţă de conectare între motorul de procesare a datelor şi motorul blockchain, şi o bază de date.

Description

Invenția se referă la platformă și la o metodă de conectare destinată să conecteze un motor de blockchain cu cel puțin o bază de date tradițională.

Un blockchain este o listă de înregistrări (sau date) în continuă creștere, numite blocuri, care sunt legate și securizate cu ajutorul criptografiei. Ca structură de date, un blockchain este o listă simplu înlănțuită, în care legăturile între elemente se fac prin hash (funcție hash). Astfel, fiecare bloc conține de obicei o legătură către un bloc anterior (un hash al blocului anterior), un timestamp și datele tranzacției. Prin design, blockchain-urile sunt rezistente la modificarea datelor. Blockchain-ul este „un registru transparent și distribuit care poate înregistra tranzacții între două părți în mod eficient, verificabil și permanent”. Pentru a fi folosit ca registru distribuit, un blockchain este de obicei administrat de o rețea colectivă de tip peer-to-peer, ce aderă la un protocol pentru validarea noilor blocuri. Odată înregistrate, datele din orice bloc de date nu mai pot fi modificate retroactiv fără alterarea blocurilor care urmează, ceea ce necesită acordul majoritar al participanților din rețea.

Blockchain-urile sunt securizate prin design și sunt un exemplu de sistem de calcul distribuit cu toleranță ridicată de tip bizantin (toleranță la atacatori sau la calculatoare necooperante). Problema consensului descentralizat a fost prin urmare rezolvată cu ajutorul tehnologiei blockchain. Acest lucru face ca tehnologia blockchain să fie adecvată pentru înregistrarea de evenimente, dosare medicale precum și înregistrarea altor activități de management cum ar fi gestionarea identității, procesarea tranzacțiilor, documentarea provenienței, urmărirea traseului comercial al produselor alimentare sau sisteme de votare.

Primul blockchain public a fost conceptualizat în anul 2008 de o persoană anonimă care s-a identificat cu numele de Satoshi Nakamoto. în 2009 a fost pus în aplicare în criptomoneda Bitcoin, unde servește ca registru public și descentralizat pentru toate tranzacțiile. Inventarea tehnologiei blockchain a făcut ca Bitcoin să devină prima monedă digitală care a rezolvat problema dublei cheltuieli fără să se folosească de o autoritate centrală de încredere sau de servere centrale. Designul monedei Bitcoin a fost sursă de inspirație pentru multe alte aplicații.

Tehnologia blockchain s-a evidențiat printr-o serie de beneficii tehnice și conceptuale care se dovedesc a avea un impact foarte mare in ceea ce privește guvernarea interacțiunii

/3λ a 2019 00496 14/08/2019 părților cu produsele software precum si securitate datelor pe care aceștia le operează. Printre acestea enumerăm:

Imutabiiitatea datelor: datorita structurii de blocuri de date dependente logic prin semnături de tip hash, rezistenta la modificarea datelor este una din principalele caracteristici pe care tehnologia blockchain le aduce la nivel de securitate și protecție a datelor stocate

- Descentralizarea: eliminarea unei guvernări centrale a datelor și a utilizatorilor care accesează o aplicație bazata pe tehnologia blockchain. Datele sunt stocate intr-un sistem accesibil tuturor părților iar utilizatorii îl pot accesa direct în nodul personal, în baza regulilor și politicilor de securitate fata de care s-au supus. Aceasta proprietate creste nivelul de încredere al utilizatorilor în modul în care sistemul gestionează datele și protejează confidențialitatea utilizatorilor.

- Distributivitatea: scalabilitatea sistemului este garantata de prezenta mai multor noduri , unde fiecare dintre noduri conține o copie integrala a datelor (blockchain-ul) precum și a programului informatic care facilitează accesul la aceste date. Sistemele distribuite nu sunt o inovație a tehnologiei blockchain, ele au existat de foarte mult timp, însă tehnologia se diferențiază prin însumarea mai multor tehnologii existente care împreuna crează o tehnologie inovativa, nu neapărat prin beneficiile aduse de fiecare componenta în parte.

Securitatea: protecția datelor (criptare/decriptare), dar și algoritmii criptografici de semnare a tranzacțiilor care sunt înglobate într-un bloc, conferă un nivel înalt de securitate a datelor care nu numai ca garantează protecția acestora prin criptare dar garantează și autentificarea, autenticitatea, integritatea și non-repudierea acestora.

Aplicația Bitcoin a stârnit interes comunităților de tehnologii prin robustețea, rezistenta la atacuri informatice și securitatea prin care aceasta reușește sa funcționeze fără a fi guvernata de o entitate. Tehnologia blockchain care sta la baza aplicației Bitcoin a devenit extrem de apetisanta, și s-a dovedit ca beneficiile pe care aceasta le oferă pot fi utilizate și la nivel de aplicații software industriale.

a 2019 00496

14/08/2019

Prezenta invenție își propune să furnizeze o platformă și o metodă de conectare care să permită implementarea tehnologiei blockchain în soluțiile software pe care le dezvoltă sau pe care le-au dezvoltat deja.

Un alt obiectiv al invenției este acela de a facilita adopția blockchain la nivel industrial, combinând tehnologia blockchain cu mecanismele de stocare de date (motoare baze de date) tradiționale.

In conformitate cu prezenta invenție, platforma de conectare este destinată să conecteze un motor de blockchain cu o bază de date tradițională, platforma fiind implementată sub forma unei rețele de noduri, rețeaua de noduri menționată fiind împărțită în cel puțin două subrețele: o subrețea de securitate și o subrețea de date, toate nodurile din sub-rețeaua de securitate conținând informații referitoare la cheile de securitate ale utilizatorilor, licențele de funcționare, politice de acces, precum și alte informații care țin de mecanismul de licențiere, autentificare și autorizare al utilizatorilor care accesează platforma, și în care nodurile din cel puțin o subrețea de date cuprind o componentă software care folosește o rețea de calculatoare, o interfață de comunicare API ce permite interacțiunea cu rețeaua de calculatoare și preluarea informațiilor care trebuie salvate în sistemul de stocare, o interfață GraphQL de interogare a datelor, un motor procesare date, un motor blockchain, o interfața de conectare între motorul de procesare date și motorul blockchain, și o bază de date.

Alte caracteristici preferate ale platformei conform prezentei invenții sunt prezentate în revendicările dependente 2-11.

Obiectivele invenției sunt atinse de asemenea cu ajutorul unei metode metode de conectare a unui motor de blockchain cu cel puțin un motor de management a bazelor de date, metoda cuprinzând etapele de asigurare a unei platforme de conectare, conform revendicării 1, platforma menționată fiind implementată sub forma unei rețele de noduri împărțită în cel puțin două subrețele: o subrețea de securitate și o subrețea de date, toate nodurile din sub rețeaua de securitate conținând informații referitoare la cheile de securitate ale utilizatorilor, licențele de funcționare, politice de acces, precum și alte informații care țin de mecanismul de licențiere, autentificare și autorizare al utilizatorilor care accesează platforma, și în care nodurile din acea cel puțin o subrețea de date cuprind o componentă software care folosește o rețea de calculatoare, o interfață de comunicare API ce permite interacțiunea cu rețeaua de calculatoare și preluarea informațiilor care trebuiesc salvate în sistemul de stocare, o interfață GraphQL de interogare a datelor, un motor procesare date, un motor blockchain, o interfața de conectare între motorul de procesare date și motorul blockchain, și o bază de date.

a 2019 00496

14/08/2019 I h

Alte caracteristici preferate ale platformei conform prezentei invenții sunt prezentate în revendicările dependente 13-24.

Alte obiective, caracteristici și avantaje ale prezentei invenții vor reieși mai clar din următoarea descriere detaliată a unor exemple preferate de realizare a invenției, dată în legătură cu Figurile anexate, care prezintă schematic și nu limitativ conceptele prezentei invenții, și în care:

Figura 1: este o diagramă schematică implementare a nodurilor platformei conform prezentei invenții;

- Figura 2 este o diagramă schematică a structurii unui nod al platformei conform prezentei invenții;

- Figura 3 este o diagramă exemplificativă pentru mecanismul de stocare a datelor;

- Figura 4 este o schemă ilustrativă a unei rețelei deschise;

- Figura 5 este o schemă ilustrativă a unei rețele restricționate (1)

- Figura 6 este o schemă ilustrativă de rețea restricționată (2)

Figura 7 este o diagramă exemplificativă de rețea cu un nod FULL NODE și 2 noduri PARȚIAL NODE

Cu referire la Figurile anexate, platforma conform prezentei invenții este o platformă de de conectare, o platforma de intermediere, care conectează un motor de blockchain (Ex: Ethereum, Hyperledger) cu o baza de date tradiționala (Ex: MongoDb, Oracle, MsSql). Aceasta conexiune (hibrid) este îmbunătățită cu un set de proprietăți, beneficii și funcționalități care au ca scop înlesnirea adopției de către programatori dar și ușurarea muncii acestora în ceea ce privește dezvoltarea de aplicații descentralizate și cu grad înalt de securitate a datelor.

Platforma conform prezentei invenții este ușor accesibilă prin intermediul API (Application Programming Interface / Drivers), asa cum majoritatea programatorilor sunt obișnuiți să interacționeze cu mecanismele de stocare de date existente.

La nivel arhitectural platforma conform prezentei invenții (pe parcursul prezentei documentații, platforma conform prezentei invenții poate fi denumită și HyperFiuse, fiind înțeles faptul că această denumire nu limitează în nici un fel caracteristicile și domeniul de aplicare al invenției) se prezintă sub forma unei rețele de calculatoare (care se mai numesc și noduri). Aceasta rețea de calculatoare este grupată în subretele, fiind necesare cel puțin două subrețele în crearea unei infrastructuri: sub-rețeaua de securitate și sub-rețeaua de date. La 4 a 2019 00496 14/08/2019 rândul ei, sub-rețeaua de date poate fi împărțită în mai multe sub-rețele, în funcție de zone geografice sau alte grupări logice convenabile administratorului de sistem.

Fiecare sub-rețea conține unul sau mai multe noduri, tipul de sub-rețea fiind dat de tipul de date stocat pe nodurile care o compun. In sub-rețeaua de securitate, toate nodurile conțin informații referitoare la cheile de securitate ale utilizatorilor, licențele de funcționare, politice de acces precum și alte informații care țin de mecanismul de licențiere, autentificare și autorizare al utilizatorilor care accesează sistemul.

Mecanismul de autentificare și autorizare folosit în motoarele de blockchain publice (vezi Bitcoin/Ethereum) se bazează pe cupluri de chei publice/private, dar cheia privata este în posesia utilizatorului. Este bine cunoscut faptul ca pierderea unei chei private, duce la imposibilitatea decriptării informației care a fost criptata cu cheia publica asociata acesteia. Dacă în aplicațiile de tip blockchain public, regulile sunt foarte clare de la bun început, și fiecare utilizator își asuma păstrarea cheii private, în mediul de business lucrurile stau cu totul altfel. Datorită riscului ridicat pe care îl prezintă pierderea unei chei de decriptare în mediul de business, a fost creata sub-rețeaua de securitate care va stoca aceste informații pentru utilizatori. Menționez ca sistemul poate funcționa și prin descentralizarea completa a utilizatorilor si cheilor asociate acestora, în unul din următoarele cazuri:

- Beneficiarul își asumă ca utilizatorii să țină cheile în custodie proprie

Se conectează un furnizor extern care va face mentenanța cheilor utilizatorilor

Se folosesc chei hardware pentru utilizatorii care accesează aplicația

Descentralizarea completă și mutarea cheilor utilizatorilor în custodia acestora nu elimină necesitatea sub-rețelei de securitate. Aceasta conține de exemplu și politici de acces la sub-rețeaua de date, care vor fi întotdeauna salvate în sub-rețeaua de securitate. Sub-rețeaua de securitate va fi administrată de beneficiarul principal al infrastructurii dar există și posibilitatea ca aceasta să fie administrată de mai multe părți, acest lucru fiind la îndemâna beneficiarului.

Sub-rețeaua de date, conține efectiv nodurile cu date care fac scopul existentei produsului software. Crearea mai multor sub-rețele de date se face deoarece acestea pot fi configurate separat de către administratorul sistemului în așa fel încât anumite sub-rețele de date să nu poată primi conexiuni decât de la anumite adrese IP. De asemenea, anumite subrețele pot fi configurate sa nu permită sincronizarea anumitor date in noduri din alte sub-rețele de date. De exemplu: se poate configura o anumită entitate (tabela), să nu se sincronizeze decât cu noduri din interiorul sub-rețelei în care se află.

a 2019 00496

14/08/2019

Cu referire la Figura 1 anexată, sunt ilustrate următoarele caracteristici:

Element Grafic	Descriere
Dreptunghi roșu	Sub-rețea securitate
Dreptunghi verde	Sub-rețea de date
Săgeata roșie	Canal de comunicare al utilizatorilor în vederea autorizării și autentificării
Săgeata albastra	Canal de comunicare și sincronizare a datelor intre sub-rețele
Săgeata neagra	Canal de comunicare și sincronizare a datelor intre noduri
Săgeata verde	API - interfața comunicare programatori
	Nod în sub-rețea
gi	Sisteme externe care se pot conecta cu HyperFiuse.
	Interfața administrare HyperFiuse prin intermediul căreia administratorul configurează sistemul

Cu referire la Figura 2 anexată, sunt ilustrate următoarele componente:

Componență nod	Descriere și scop
Aplicație software	Componenta software care folosește platforma HyperFiuse
Interfață API	Interfața de comunicare, care permite programatorului sa interacționeze cu platforma HyperFiuse. Interfața API prezintă conectori de comunicare care folosesc protocoalele HTTP(REST) și TCP.
Interfață GraphQL	Interfața de interogare a datelor. Interfața API permite interacțiunea cu datele în sistem CRUD (create, read, update, delete). Pentru mecanisme de interogare mai complexa a datelor se folosește interfața GraphQL Aceasta componenta este de asemenea dedicata programatorilor ca și o unealta de accesare a datelor.
Motor procesare date	Motorul HyperFiuse. Toată funcționalitate care face parte din produsul HyperFiuse este concentrata în aceasta componenta. Fiecare funcționalitate va fi explicata detaliat

a 2019 00496

14/08/2019

	în capitolele următoare.
Interfață adaptor blockchain	Interfața de conectare intre motor HyperFiuse și motor blockchain. Aceasta componenta permite inter-schimbarea motorului de blockchain cu orice motor blockchain preferat de beneficiar si permite HyperFiuse sa fie o platforma agnostica în acest punct de vedere
Platforma/Motor blockchain	Motor de blockchain precum Hyperledger Fabric, Tendermint, Ethereum s.a.m.d
Interfață adaptor baza de date	Interfața de conectare intre motor HyperFiuse și motor de baze de date. Aceasta componenta permite inter-schimbarea motorului de baza de date cu orice motor blockchain preferat de beneficiar și permite HyperFiuse sa fie o platforma agnostica în acest punct de vedere
Baza de date	Motor de baza de date precum Oracle, MongoDb, MsSQL s.a.m.d.

3.3.1 Mecanism stocare date

Platforma conform prezentei invenții (HyperFiuse) poate fi denumită și un produs software conector a unui motor de blockchain (HyperLedger, Tendermint, Ethereum etc) cu un motor de management a bazelor de date (MongoDb, MsSql, Oracle etc), permițând programatorilor sa comunice cu un singur sistem, care la rândul lui se va ocupa de stocarea datelor în ambele componente conectate (blockchain și baza de date), precum și cu sincronizarea datelor stocate pe toate nodurile de date care compun rețeaua.

Mecanismul de bază constă în preluarea informațiilor care trebuiesc salvate în sistemul de stocare, calcularea unei amprente a informației preluate folosind algoritmi de hashing, salvarea datelor preluate în motorul de baze de date, și a amprentei, împreuna cu referința locației datelor (tabela/colecția din baza de date și identificatorul unic al datelor în tabela/colecție) în motorul de blockchain.

Primul pas al procedeului de stocare de date este preluarea datelor. Acest proces se face cu ajutorului interfeței API, prin intermediul căreia aplicația software trimite informațiile care se doresc a fi stocate în sistem blockchain database. După cum se vede și în figura Mecanism stocare date de mai jos, aplicația software trimite un pachet de date de forma { nume student: Alin, prenume student: IFTEMI }. Formatul de date trimis diferă în funcție de entitatea/tabela în care se dorește a fi stocata informația, structura acesteia fiind a 2019 00496

14/08/2019 definita în prealabil prin intermediul metodelor API expuse în componenta Interfața API, sau prin intermediul aplicației de administrare a sistemului HyperFiuse.

Pasul al doilea consta în preluarea datelor, de către motorul HyperFiuse, pentru validare și salvare în baza de date respectiv salvarea în blockchain (mecanismul de blocuri imutabile). Configurarea standard, de început, prevede ca fiecare structura de date care este trimisa pentru salvare sa fie stocata în baza de date, iar pe blockchain sa se salveze o referința la locația datelor în baza de date(Tabela/colecție și identificator unic înregistrare) precum și o amprenta digitala a acestor informații.

Pentru exemplul prezentat în figura Mecanism stocare date, informația preluata de motorul de procesare de date HyperFiuse, și anume { “nume student”:”Alin”, “prenume student:”IFTEMI” }, este împărțita în doua seturi de date, cate una pentru fiecare componenta de stocare, baza de date respectiv blockchain (blocurile de date imutabile din motorul de blockchain).

In acest fel, forma informației stocate in baza de date se prezintă in structura { “id”:”XXX”, “nume student”: Alin”, “prenume student”:”IFTEMI” }. Câmpul “id” din structura prezentata se refera la identificatorul unic care s-a obținut in urma salvării. In exemplul prezentat, valoare “XXX” poate reprezenta orice identificator unic asociat informației salvate de către motorul de baze de date. Fiecare data trimisa către stocare este direcționată către tabela/colecția asociata acesteia in sistemul de gestionare a bazelor de date (motorul de baze de date).

După salvarea informației in baza de date, se calculează amprenta digitală a înregistrării salvate folosind o metoda/funcție de hash-ing (MD5, SHA256, SHA512). Sistemul poate folosi orice metodă de hash-ing agreată de administrator, selecția acesteia făcându-se în baza unui parametru configurabil al HyperFiuse. Amprenta digitală, împreună cu numele tabelei din sistemul de gestiune a bazelor de date în care s-au salvat datele, și cu identificatorul unic al înregistrării, se grupează într-un set nou de date de forma { “id”: ”YYY”, “Tabela / colecție Studenți ”, “identificator unic XXX”, “amprenta pachet date motor baza de date”:”ZZZ” } și se trimit către salvarea in blockchain (motorul de blockchain); Câmpul “id” reprezintă identificatorul unic al tranzacției asociată de către motorul de blockchain, unde cu valoarea “YYY” poate reprezenta orice valoare dată de către un astfel de sistem. în acest mod, se creează o legătură între informațiile salvate în baza de date și informațiile salvate în blockchain, punctul de legătură fiind numele tabelei în care s-au salvat datele și identificatorul unic al înregistrării din tabel.

a 2019 00496

14/08/2019

Structura tabelei, entității sau colecției în care se salvează informația este definită în prealabil de administratorul sistemului folosind Interfața API sau aplicația web de configurare a HyperFiuse. Structura de date folosita ca exemplu in acest document are ca scop prezentarea conceptului de stocare a datelor și a conexiunii intre sistemele de blockchain cu sistemele de baze de date. în sistemul de producție, aceste structuri pot fi diferite prin număr de câmpuri sau denumire câmpuri, variantele prezentate mai sus folosind doar pentru scop explicat și educațional. Câmpuri din motorul de blockchain precum: nodul unde a fost salvată înregistrarea, data/ora la care o înregistrare s-a făcut și alte câmpuri, au fost omise întocmai a evidenția mai simplu și mai clar mecanismul de funcționare a sistemului.

Procedeul descris este similar și pentru ștergerea datelor. Operațiunile de scriere la nivel de baza de date pot fi de trei feluri: inserare, modificare și ștergere. Fiecare operațiune este stocata in blockchain ca și tranzacție independenta alături de informațiile de referința precum tabela, identificatorul înregistrării și amprenta digitala. Practic, fiecare operațiune de modificare a datelor este salvata ca o tranzacție pe blockchain și toate operațiunile sunt păstrate integral pe toată durata de viata a aplicației. La nivel de baza de date, operațiunile pot modifica datele conform tipului de tranzacție solicitata de aplicația software (programator) : creare, modificare sau ștergere. Tabela/colecția din baza de date asociata structurii de date asupra căreia se fac modificări, păstrează in permanenta ultima versiune a datelor dar pentru fiecare tabela/colecție există tabela/colecție corespondentă care păstrează toate versiunile anterioare ale înregistrării tranzacționate.

Acest mecanism este creat pentru a păstra un istoric imutabil al operațiunilor (blockchain) dar și versiunea integrala a datelor precum și istoricul acestora. Există posibilitatea de a configura HyperFiuse să nu păstreze istoricul datelor modificate, sau ca acest istoric sa poate fi șters pentru anumite înregistrări. Aceasta funcționalitate este utilă pentru îndeplinirea cerințelor legale GDPR, iar parametrizarea acestor operațiuni poate fi făcuta numai pentru tabelele/colecțiile selectate de administratorul sistemului și la inițiativa acestuia.

3.3.2 Mecanism distribuție date

HyperFiuse se prezintă sub forma unei rețele de noduri, iar distribuția/sincronizarea datelor este funcționalitate principala pentru ca sistemul sa poate oferi scalabilitate, descentralizare și rezistenta la modificarea datelor. Rețeaua de date HyperFiuse poate fi compusa din mai multe sub-rețele (vezi capitolul 3.2). iar fiecare sub-rețea de date conține mai multe noduri. Fiecare nod, conține o copie integrala a datelor din blockchain (blocuri imutabile de referințe tranzacții) precum și o copie a bazei de date (vei capitolul 3.3). La salvarea unui a 2019 00496

14/08/2019 set de date, tipul de operațiune, referința și amprenta digitala sunt salvate in blockchain iar datele sunt direcționate către baza de date unde se stochează in tabelele/colecțiile corespunzătoare (vezi capitolul 3.3.1).

Odată trimise datele către motorul de blockchain, acesta începe sa facă sincronizarea cu celelalte instanțe instalate pe nodurile de date, folosind algoritmii de consens care au fost configurați la instalare. Procesul de sincronizare al motorului de blockchain se ocupa și de crearea de blocuri de tranzacții (înregistrări), aceasta funcționalitate fiind in totalitate specifica motorului de blockchain, iar eficienta sincronizării precum și viteza de sincronizare fiind strict dependenta de configurările și de motorul de blockchain ales de beneficiar. HyperFiuse integrează motoare de blockchain in funcție de preferința beneficiarului și nu intervine in mecanismele de sincronizare ale acestora.

Datele din blockchain se distribuie pe absolut toate nodurile din toate sub-rețelele de date, sub autoritatea motorului de blockchain, dar datele din baza de date sunt sincronizate de sistemul HyperFiuse. Fiecare nod din sub-rețeaua de date este actualizat in blockchain cu blocurile cele mai recent validate de motorul de blockchain, iar odată sincronizat un nou bloc, sistemul HyperFiuse procesează fiecare tranzacție din bloc și pentru fiecare dintre acestea inițiază o cerere de obținere a datelor modificate către nodul emitent in care a fost creata tranzacția. Odată primite datele, acestea sunt modificate și in baza de date a nodului recipient conform tipului de tranzacție specificat in blockchain. Modificarea acestora se refera la oricare dintre operațiunile de alterare a datelor: creare, modificare și ștergere precum și la crearea istoricului înregistrării tranzacționate.

Timpul, respectiv viteza de sincronizare a datelor din blockchain este direct dependenta de motorul de blockchain folosit (HyperLedger, Tendermint, Ethereum etc), fiind la latitudinea beneficiarului alegerea unui motor de blockchain convenabil in funcție de tipul de activitate al produsului software deservit de HyperFiuse. în general, motoarele de blockchain pentru aplicații industriale sunt optimizate pentru performanta, dar cu toate acestea se pot diferenția prin viteza sau algoritmul de sincronizare, configurările și modalitatea de stocare a datelor din chain-ul imutabil sau prin funcționalitate comerciala. Hyperfiuse este independent de motorul de blockchain, mai multe distribuții fiind disponibile pentru ca beneficiarul sa își aleagă distribuția cea mai convenabila, atât d.p.d.v. motor de blockchain cat și motor de baze de date. Mai multe detalii despre independenta fata de motorul de blockchain in capitolul 3.3.4.

a 2019 00496

14/08/2019 J2 f

3.3.3 Mecanism citire date

Accesul la date oferit de HyperFiuse se face prin doua moduri: acces direct la baza de date și acces prin Interfața API.

Accesul direct la baza de date se refera la publicarea detaliilor de conectare directa la motorul de baze de date. Acest tip de conectare este folosit in situația in care aplicația software folosește interogații complexe bazate pe T-SQL sau se doresc citiri rapide din baza de date, citiri cu timp de răspuns asumat de motorul de baza de date. Aplicația software se conectează direct la baza de date pentru a efectua citiri și in cazul unei migrări rapide, de la o infrastructura bazata pe sisteme de gestiune a bazelor de date clasice la o infrastructura bazata pe HyperFiuse blockchain database, când mai pot exista situații când nu s-a finalizat modificarea codului sursa pentru a efectua citirea prin HyperFiuse, acel lucru urmând a se realiza mai târziu.

Există și dezavantaje pentru acest tip de citire, și anume că nu se pot obține automat datele care au fost criptate în sistem, decriptarea va trebui sa fie făcuta manual de către programator (vezi capitolul 3.3.8). De asemenea, datele nu vor fi filtrate după drepturile de acces ale utilizatorilor asupra acestora (vezi capitolul 3.3.11). La operațiunile de citire prin Interfața API, decriptarea datelor se face automat și în funcție de drepturile utilizatorului asupra datelor.

Metoda recomandata este accesarea înregistrărilor prin Interfața API. HyperFiuse va retuma informațiile solicitate de programator din Aplicația Software, iar acestea ii vor fi livrate ținând cont de toate configurările și filtrele de funcționalitate HyperFiuse. Concret, citirea prin Interfața Api va retuma datele în format citibil (decriptate), va filtra datele în funcție de drepturile pe care utilizatorul care efectuează citirea le are asupra acestora, va efectua verificări de integritate asupra datelor și va permite citirea cu opțiunea de reconstruire a datelor în cazul în care au fost identificate modificări/ștergeri neautorizate asupra acestora. De asemenea, prin Interfața API, se pot efectua foarte ușor și eficient operații de citire a versiunilor anterioare a unei înregistrări. Toate aceste beneficii sunt descrise în capitolele următoare și nu sunt disponibile la citirea informațiilor direct din sistemul de gestiune a bazei de date.

Viteza de citire a datelor prin Interfața Api, este este aceiași cu viteza de citire direct din baza de date, la care se adaugă (unde este cazul) timpul de decriptare, timpul de verificare a integrității datelor, timpul de reconstrucție a unei înregistrări și de filtrare a datelor asupra cărora utilizatorul care face citirea are acces. Toate aceste operațiuni adiționale aduc o a 2019 00496

14/08/2019 )1^ întârziere minora unei operațiuni de citire, întârziere care ar fi apărut oricum în momentul în care programatorul ar fi decis sa implementeze singur aceste funcționalități la nivel de aplicație software. De asemenea, toate aceste beneficii oferite de HyperFiuse care se adaugă la timpul de citire sunt opționale și la latitudinea administratorului de sistem și a programatorului.

3.3.4 Independenta față de motorul de blockchain

HyperFiuse folosește componenta de blockchain, motorul de blockchain, pentru a sincroniza blocurile de date cu tranzacții, referințe la datele operate și amprenta digitala a acestora, precum și pentru a păstra un istoric imutabil al tuturor operațiunilor asupra datelor, întregul set de blocuri de date al motorului de blockchain este folosit de HyperFiuse pentru reconstrucția și sincronizarea datelor din motorul de baze de date.

Tehnologia blockchain este la început de drum, nu este încă diferențiat un motor de blockchain in detrimentul altuia și se experimentează foarte mult pe partea de algoritmi de consens și viteza de sincronizare. Exista deja multi producători de software care au evoluat considerabil in ceea ce privește cercetarea și dezvoltarea in domeniul motoarelor de blockchain, și care au scos pe piața produse fiabile, dar tehnologia este încă la început de drum.

Datorită și faptului că există mai mulți producători de motoare de blockchain, iar nevoile clienților/beneficiarilor se pot raporta și la acest lucru, HyperFiuse se prezintă ca o platforma independenta de aceasta componenta. Asta înseamnă ca HyperFiuse poate funcționa și cu HyperLedger Fabric (motor de blockchain), și cu Tendermint și cu oricare motor de blockchain își dorește beneficiarul aplicației. HyperFiuse va fi distribuit beneficiarului cu o combinație de motor blockchain și motor baza de date la solicitarea acestuia sau ii va fi distribuit în forma descărcabilă de pe site-ul companiei, fiind la latitudinea dezvoltatorului sa creeze o diversitate cat mai mare de distribuții pentru a acoperi nevoile tuturor beneficiarilor.

3.3.5 Independenta fata de motorul de baze de date

Fiecare nod HyperFiuse conține și un sistem de gestiune a bazelor de date, motorul de baze de date. Aceasta componenta este folosita pentru a stoca în întregime înregistrările și datele salvate in sistem precum și pentru a păstra versiunile anterioare ale acestora.

Este bine cunoscută dependenta anumitor beneficiari de anumiți producători/fumizori de sisteme de gestiune a bazelor de date, și cum HyperFiuse a fost creat sa ofere și posibilitatea migrării aplicațiilor software existente in tehnologia blockchain, a devenit 12 a 2019 00496 14/08/2019 imperios necesar ca aceasta componenta, motorul de baze de date, sa poată fi schimbata in funcție de preferința beneficiarului.

Datorită și faptului că există mai mulți producători de motoare de baze de date, iar nevoile clienților/beneficiarilor se pot raporta și la acest lucru, HyperFiuse se prezintă ca o platforma independenta de aceasta componenta. Asta înseamnă ca HyperFiuse poate funcționa și cu Oracle (motor de baze de date), și cu MongoDb și cu oricare motor de baze de date își dorește beneficiarul aplicației. HyperFiuse va fi distribuit beneficiarului cu o combinație de motor blockchain și motor baza de date la solicitarea acestuia sau ii va fi distribuit în forma descărcabilă de pe site-ul companiei, fiind la latitudinea dezvoltatorului sa creeze o diversitate cat mai mare de distribuții pentru a acoperi nevoile tuturor beneficiarilor.

3.3.6 Polițe de sincronizare a datelor

Conform descrierii din capitolul 3.2, sub-rețelele de date pot fi configurate pentru a limita sincronizarea datelor din anumite tabele/colecții la nodurile din cadrul sub-rețelei. Polițele de sincronizare a datelor se aplica la nivel de sub-rețea, unde pentru fiecare sub-rețea de date se poate specifica ce tabela/colecție de date sa nu se sincronizeze cu noduri din afara sub-rețelei.

Polițele de sincronizare a datelor permit și restricționarea cererilor de furnizare date adresate nodurilor din sub-rețea prin intermediul Interfeței API. Aceasta restricționare se face la nivel de adresa IP, și odată definita o astfel de polița de restricționare, nu se mai poate comunica cu Interfața API decât de către Aplicațiile Software care sunt într-o marja de IP conforma cu configurarea sub-rețelei de date.

O sub-rețea de date care nu are definita nici o polița de sincronizare a datelor se numește OPEN NETWORK, iar o sub-rețea de date care are definita cel puțin o regula într-o polița de sincronizare a datelor se numește RESTRICTED NETWORK.

Un exemplu de scenariu in care o poliță restrictiva la sincronizarea datelor ar avea sens, este pentru cazul în care China nu permite transferul documentelor personale stocate în format electronic sa părăsească granițele fizice ale tarii. Dacă un beneficiar din China ar desfășura activități în China și in Korea, iar in Korea nu ar exista astfel de restricții, atunci rețeaua de date HyperFiuse ar putea fi împărțită cu doua sub-rețele de date, una in China și una in Korea. Pentru sub-rețeaua din China vom crea o polița de sincronizare a datelor care va include tabela “Documente” ca tabela/colecție care nu are voie sa sincronizeze date în alte sub-rețele și vom adăuga in polița de sincronizare și o regula de blocare a cererilor de acces de la orice IP care nu este din China, (este important de știut ca descărcarea în format electronic a a 2019 00496

14/08/2019 unui document accesat dintr-un browser din Europa, este considerat de asemenea o breșă care rezulta într-o ilegalitate; de aceea este necesara și limitarea accesului la Interfața API pe nodurile din sub-rețeaua China). Restricțiile in ceea ce privește sincronizarea datelor se pot aplica atât către datele care pleacă dintr-o anumita sub-rețea cat și la datele vin din alte subrețele, de asemenea aceste restricții se aplica la nivel de tabela/colecție din sub-rețea de date.

In figurile 4-6 anexate sunt definite următoarele scenarii:

- Fig. 4 Rețea deschisă (Open Network) - exemplu de rețea in care nu s-a definit nici un fel de restricții la nivel de tabela/colecție “Documente”. Este un scenariu clasic, in care nu se definesc restricții dar se definesc sub-rețele pentru a păstra opțiunea deschisa in viitor. Deși nu exista nici o diferența intre a avea o rețea neîmpărțită in sub-rețele și a împărți rețeaua in doua sub-rețele de tip OPENNETWORK (fără restricții) , este indicata împărțirea in sub-rețele din punct de vedere logic, pentru a eventuale configurări sau limitări care pot apărea in producție care necesita implementări rapide.

- Fig. 5 Rețea restricționată 1 (Restricted Network 1) - exemplu de rețea in care s-a definit pe tabela Documente din sub-rețeaua China o regula de restricție pentru ca datele introduse prin nodurile din sub-rețeaua China sa nu se sincronizeze decât in subrețeaua China și sa nu permită sincronizarea cu noduri din sub-rețele externe. Regula permite însă ca tabela sa primească înregistrări din alte sub-rețele de date

Fig. 6. Rețea restricționată 2 (Restricted Network 2) - exemplu de rețea în care s-a definit pe tabela Documente din sub-rețeaua China o regula de restricție pentru ca datele introduse prin nodurile din sub-rețeaua China sa nu se sincronizeze decât in subrețeaua China și sa nu permită sincronizarea cu noduri din sub-rețele externe. Regula NU permite nici ca tabela sa primească înregistrări din alte sub-rețele de date. Același efect s-ar fi obținut dacă ambele sub-rețele ar fi restricționat tabela “Documente” numai la trimiterea de date. In ambele variante nu se regăsesc diferențe la nivelul in care sunt distribuite datele dar modalitate de sincronizare ar fi fost diferită dacă am mai introduce o alta sub-rețea..

3.3.7 Polițe de stocare a datelor

HyperFiuse este o rețea distribuita de noduri, unde fiecare nod retine o copie integrala, o replica, a bazei de date. Multiplicarea nedeterminata a nodurilor, respectiv a întregului set de date din baza de date, poate crea probleme de logica și de infrastructura. Nu întotdeauna are sens ca un nod, în mentenanța unei părți, sa conțină toate datele din sistem la fel cum nu are sens sa se întrețină prea multe noduri cu toate datele, din perspective tehnica a consumului de a 2019 00496

14/08/2019 resurse hardware. Pentru a rezolva aceasta problema, HyperFiuse permite configurarea unui nod în asa fel încât acesta sa nu sincronizeze toate datele, și sa stocheze numai datele care au fost salvate folosind Interfața API instalata pe nodul în cauză.

în acest mod, un nod în rețeaua HyperFiuse poate fi un nod care stochează toate datele din sistem, iar un astfel de nod se numește FULL NODE. Aceste noduri de obicei se găzduiesc în sediul central sau într-un centru de date care aparține beneficiarului, și pot servi ca sursa pentru recuperare de date sau ca un instrument de back-up în timp real. Scopul fiind de a proteja nodurile de business de la parteneri sau filiale, de a întreține volume mari de date cu hardware scump. Funcționalitatea este opțională, fiind posibil fără probleme, în funcție de scop, ca toate nodurile dintr-o rețea sau sub-rețea sa funcționeze ca un FULL NODE.

Un nod poate funcționa fără a sincroniza toate datele care se salvează pe toată rețeaua, păstrând doar datele care au fost introduse folosind Interfața API a nodului respectiv. Aceste noduri nu vor păstra în baza de date decât datele care au fost introduse prin Interfața API a nodului în cauza. Acest procedeu nu restricționează accesul la alte date introduse prin alte noduri, acestea fiind replicate în momentul în care sunt solicitate de utilizator. Odată copiate, în urma unei solicitări, datele aduse vor rămâne pe nodul parțial pentru totdeauna. Scopul acestei funcționalități este de a oferi posibilitatea unui software sa comunice cu un nod de date întreținut într-un mediu de afaceri, precum o filiala sau un birou mic, fără a fi nevoie de o infrastructura hardware complexa instalata la fata locului, dar și pentru a evita sincronizarea anumitor date care aparțin altor părți pe baza de date locala. HyperFiuse poate deservi ca soluție de stocare de date, aplicații software care sunt operate de mai multi terți care sunt foarte interesați ca datele pe care aceștia le introduc în sistem sa nu fie expuse celorlalte părți care operează sistemul. Chiar dacă aceste date pot fi criptate, se induce o siguranța sporita în momentul în care, deși criptate, datele nu sunt deloc accesibile altor părți. Aceste noduri poartă denumirea de PARȚIAL NODE.

Un nod PRIVATE, este un alt tip de nod, care nu numai că nu copiază local datele care au fost introduse prin interfața API a altor noduri, dar nici nu permite ca datele introduse prin Interfața API proprie să fie sincronizate pe alte noduri. în figura 7 se poate observa o reprezentare a unei rețele cu un nod FLTLL NODE și 2 noduri PARȚIAL NODE

3.3.8 Criptarea datelor

Criptarea datelor este folosita în HyperFiuse pentru a îmbunătăți protecția și securitatea datelor stocate în componenta de baza de date, și a oferi posibilitatea beneficiarului sa ascundă anumite informații senzitive în cazul unor extrageri de date neautorizate dar și pentru a oferi 15

a 2019 00496

14/08/2019 utilizatorilor sistemului posibilitatea de a deveni proprietari ai datelor nu numai la nivel conceptual ci și la nivel fizic, aceste date aflate în proprietatea utilizatorului fiind criptate cu cheia privata a acestuia.

Mecanismele de criptare sunt bazate pe algoritmi de criptare asimetrici, care folosesc un cuplu de chei format din cheie publica pentru criptare și cheie privata pentru decriptare. Mecanismul de funcționare al acestui mod de criptare nu este explicat in acest document, dar pentru mai multe informații se poate accesa acest link https://en.wikipedia.org/wiki/Publickeycrypto graphy

HyperFiuse folosește doua entități care pot cripta/decripta informații în sistem, mai exact administratorul/beneficiarul sistemului și utilizatorul/utilizatorii care adaugă informații în sistem. Mecanismul de criptare este cu precădere destinat pentru a proteja informațiile adăugate de utilizatori dar administratorul are funcția de criptare/decriptare pentru a putea interveni în recuperarea unor date care au fost criptate de un utilizator, iar acesta din urma și-a pierdut cheia privata de decriptare sau efectiv nu este disponibil pentru a decripta la o cerere de acces a informațiilor inițiata de către un alt utilizator. Mecanismul de acces Ia informații, bazat pe cererile utilizatorilor este descris în detaliu în capitolul 3.3.11

Cuplul de chei format din cheie publica și cheie privata, care aparține administratorului se numește cuplu de chei MAȘTER. Cheia privata MAȘTER este împărțita în mai multe bucăți, astfel încât aceasta sa nu poată fi reconstruita decât dacă sunt prezenți mai multi administratori în procesul de decriptare urgenta. Scopul acestei funcționalități este sa se prezinte încredere în beneficiarul sistemului, care deși poate decripta informații în regim de urgenta, acest procedeu sa nu se poată face decât într-un mediu controlat, cu mai multi administratori de fata și cu toți pașii efectuați din aceasta operațiune logați într-un sistem imutabil de loguri. Cheia privata este împărțita in N bucăți (configurabil) fiind nevoie de K bucăți pentru a reconstrui cheia (unde K <= N). Algoritmul folosit pentru a împărți cheia privata se numește “Shamir's Secret Sharing” și explicarea lui nu face scopul acestui document dar mai multe detalii despre acest algoritm se pot vizualiza la acest link https.7/en.wikipedia.org/wiki/Shamir%27s_Secret Sharing Fiecare bucata din cheia privata MAȘTER care este în guvernarea unui administrator este criptata la rândul ei cu cuplul de chei asimetrice care ii aparține acestuia, pentru a preveni un administrator sa vadă în sistem bucata din cheia privata MAȘTER care ii aparține altui administrator. Configurabil, se poate opta ca cheia asimetrica a unui administrator sa fie o cheie hardware, un dispozitiv extern, sau ca aceasta sa fie stocata în sub-rețeaua de securitate și sa se genereze în baza numelui de utilizator și a parolei administratorului.

IU a 2019 00496 14/08/2019

Utilizatorilor HyperFiuse li se crează un cuplu de chei asimetrice, iar aceștia vor folosi cheia publica pentru criptare și cheia privata pentru decriptare. Cheia publica este disponibila și vizibila tuturor utilizatorilor din sistem, dar cheia privata este secreta și aparține fiecărui utilizator în parte. Cheia privata a unui utilizator este protejata de HyperFiuse prin 3 mecanisme diferite și anume: dispozitiv hardware extern care stochează cheia privata și este în posesia utilizatorului, păstrarea cheii private de către utilizator în format sir de caractere digital sau varianta mai puțin securizata, în care cheile sunt stocate în sub-rețeaua de securitate și gestionate de sistem. A treia varianta în care cheile private sunt gestionate de sistem, sunt destinate produselor software care nu au utilizatori pregătiți sa își protejeze o cheie privată și pun accent pe alte funcționalități oferite de HyperFiuse sau acorda un gram de încredere superior beneficiarilor platformei, din perspectiva faptului ca aceștia pot oferi protecția necesara a acestor chei în relația cu alte părți.

Criptarea informațiilor care se salvează în baza de date se face la solicitarea utilizatorilor de sistem. Aceștia pot configura sistemul ca anumite înregistrări sa fie stocate în baza de date criptat. Exista și posibilitatea ca anumite câmpuri dintr-o înregistrare (eg. doar câmpul nume și prenume dintr-o tabelă cu câmpurile nume, prenume și data nașterii) sa fie criptate, restul dintre acestea sa fie stocate în clar, în forma în care au fost introduse de utilizator. Alegerea câmpurilor dintr-o entitate (tabela) care sa fie stocate criptat sta la latitudinea beneficiarului, și este opțiunea acestuia sa gestioneze volumul de informații care se criptează în raport cu performanta care se așteaptă de la sistem, având în vedere faptul ca este binecunoscuta situația în care procesul de criptare și decriptare poate reduce performanta de acces la informație.

Informația care se criptează înainte de stocare, este criptata cu doua chei publice, cheia utilizatorului care introduce datele și cheia MAȘTER care este folosita la decriptare în caz de urgenta. Sistemul poate fi configurat sa nu se folosească o cheie MAȘTER, și recuperarea datelor sa nu se facă decât pe baza cheii private a utilizatorului, dar acest lucru se va face în cunoștința de cauza cu mențiunea ca dacă un utilizator își pierde cheia privata, este posibil ca datele criptate sa nu mai poată fi recuperate niciodată.

Programatorul care interacționează cu HyperFiuse prin Interfața API nu se va îngrijora niciodată de procesul de criptare/decriptare, cheile asociate procesului fiind generate din timp, iar el va trimite întotdeauna informațiile în formatul original necriptat și le va extrage din sistem în același format. Procesul de criptare, stocare criptata și decriptare este efectuat de HyperFiuse in mecanismele interioare, programatorii fiind scutiți de efortul de a procesa aceste operațiuni.

a 2019 00496

14/08/2019

3.3.9 Decriptarea datelor

Decriptarea datelor in HyperFiuse are loc în urma unei solicitări de vizualizare a datelor din partea unui utilizator, în contextul în care datele au fost stocate criptat în baza de date. Aceasta decriptare se face cu cheia privata a utilizatorului care a introdus datele și care este proprietarul acelor date. Decriptarea mai poate fi făcuta și de administratorul sistemului cu cheia MAȘTER în cazurile speciale când utilizatorul a pierdut cheia privata sau când utilizatorul nu poate răspunde la o cerere urgenta de acordare a permisiunii asupra datelor (Ex: datele criptate sunt date medicale de importanta vitala și utilizatorul este chiar posesorul cheii private în postura de a nu putea oferi acces la acestea)

Decriptarea datelor mai este invocată și în cazul în care se solicita acces în baza unei cereri formulate de un alt utilizator. Proprietatea datelor nu restricționează total accesul la acestea, datele deținute pot fi chiar adăugate in sistem ca date publice sau ca date private. Cele publice sunt accesate de toți utilizatorii iar cele private nu pot fi accesate de nici un alt utilizator decât de utilizatorul care le-a adăugat. Dar datele pot fi introduse și cu caracteristica PERMIS SIONED care permite celorlalți utilizatori sa vadă ca datele exista în sistem dar aceștia trebuie sa solicite acces. In acest caz, dacă utilizatorul proprietar de date dorește sa ofere acces, atunci se mai efectuează o decriptare a datelor cu cheia proprietarului de date iar datele sunt făcute disponibile pentru utilizatorul căruia i s-a acordat privilegii de citire.

Mecanismul de criptare și decriptare a informațiilor introduse de un utilizator sunt opționale, și activarea acestora este făcută de administratorul de sistem, de designerul de infrastructura de date în funcție de logica produsului software și așteptările funcționale ale produsului software care folosește platforma HyperFiuse.

3.3.10 Semnarea datelor

O semnătură digitală este o schemă matematică folosită pentru a demonstra autenticitatea mesajelor sau documentelor digitale. O semnătură digitală validă oferă destinatarului o bază solidă pentru a crede că mesajul a fost creat de către un expeditor cunoscut (autentificare), să fie sigur că expeditorul nu poate nega că a trimis mesajul (nonrepudiere), și că mesajul nu a fost modificat pe parcurs (integritate).

Semnăturile digitale sunt un element standard al celor mai multe suite de protocoale criptografice, și sunt frecvent utilizate pentru distribuirea de software, tranzacții financiare, software de gestiunea contractelor, precum și în alte cazuri în care este important să se a 2019 00496

14/08/2019 detecteze falsificarea sau manipularea datelor. Mai multe informații despre semnătura digitala se găsesc la acest link:

https://ro.wikipedia.org/wiki/Semn%C4%83tur%C4%83 digital%C4%83

HyperFiuse utilizează semnătura digitala pentru a semna tranzacțiile care sunt stocate pe lanțul imutabil în blockchain. Fiecare tranzacție este de fapt o operațiune de scriere/modificare a unei înregistrări în baza de date, dar detaliile operațiunii care sunt salvate în blockchain (vezi detalii în capitolul 3.3.1) sunt semnate digital. In blockchain se salvează tranzacțiile care sunt grupate în blocuri de tranzacții. Fiecare tranzacție din bloc este semnata digital cu cheile utilizatorului care a adăugat datele în sistem, iar fiecare bloc este semnat digital cu cheile nodului care a confirmat blocul de tranzacții.

3.3.11 Proprietatea datelor și accesul la date

Fiecare utilizator HyperFiuse este proprietarul informațiilor pe care acesta le introduce în sistem. Acest lucru se confirma prin semnături digitale (vezi capitolul 3.3.10) și prin criptarea informațiilor introduse. Exista într-adevăr și posibilitatea de a nu cripta informația, mai ales ca exista un timp prețios pierdut la decriptare, dar este la latitudinea administratorului de sistem sa decidă ce informație este sensibila și necesita criptare pentru a proteja accesul la aceasta și ce informație poate fi stocata necriptat fiind suficienta doar semnătura digitala pentru a demonstra proprietatea informației.

Criptarea informației stocate în baza de date, este mecanismul esențial în protejarea informațiilor unui utilizator. Mecanismul de criptare/decriptare explicat în capitolul 3.3.8 și 3.3.9, se aplica având ca scop protecția datelor în baza de date, date care pot fi replicate pe noduri aflata în gestiune unor terți, dar și pentru a proteja accesul la date fata de alți utilizatori, înregistrările stocate în sistem cu eticheta PERMISSIONED (vezi capitolul 3.3.9) sunt disponibile către alți utilizatori, care pot vedea ca informația exista, dar pentru a putea-o accesa este nevoie de un mecanism de cerere de permisiune de acces, permisiune acordata în final de utilizatorul care este proprietar al informației. înregistrările stocate cu eticheta PRIVATE (vezi capitolul 3.3.9) nu vor putea fi niciodată accesate prin intermediul mecanismul de cerere de acces, dar un administrator va putea sa le vizualizeze direct în baza de date, iar acele informații ar trebui sa fie stocate criptat dacă acestea sunt informații sensibile.

Proprietatea datelor unui utilizator impune acestuia sa participe în procesul de cerere de acces la date (pentru înregistrările etichetate cu PERMISSIONED) și este utilă ca datele sa fie stocate criptat în cazul în care informațiile se doresc a fi distribuite către terți în baza unei

a 2019 00496

14/08/2019 //^ cereri de acces. Asta nu înseamnă ca datele pot fi distribuite și necriptat, acestea nu vor fi disponibile prin Interfața API, dar vor putea fi vizibile unui administrator de date direct in baza de date. Mecanismele de configurare a câmpurilor, dintr-o colecție sau entitate, care stochează informația criptat sunt gestionate de administratorul de sistem. Arhitectul sistemului de date va decide dacă o înregistrare este stocata criptat integral în baza de date sau doar anumite câmpuri din acea înregistrare vor stoca informația criptat. Eticheta de PERMISSIONED este transmisa de către programatorul care trimite informațiile în sistem, și fiecare înregistrare trimisa către salvare poate avea eticheta PERMISSIONED, PRIVATE sau PUBLIC. Sistemul software care comunica cu HyperFiuse, în baza regulilor decise de programator, poate trimite informațiile cu una din cele 3 etichete indiferent de cum este configurata tabela și/sau cate câmpuri sunt criptate sau nu.

în contextul în care o înregistrare este criptata în totalitate, se poate acorda acces numai la anumite câmpuri din aceasta. Utilizatorul care solicita acces la o înregistrare PERMISSIONED, cunoaște structura tabelei în care informația este criptata, și poate solicita accesa la întreaga înregistrare sau numai la câteva câmpuri din aceasta. De asemenea, proprietarul de date, poate acorda acces la toate câmpurile la care i s-a cerut acces sau poate decide căror câmpuri din cele solicitate, sa le acorde permisiune de citire. De asemenea, permisiunea de acces, se acorda pe o perioada de timp limitata, perioada de timp decisa de proprietarul datelor, iar la expirarea acestei perioade de timp informația nu mai poate fi accesata, și este nevoie de o noua cerere de acces pentru a obține din nou privilegiile de citire.

în tot acest proces de cerere și acordare de acces la date etichetate cu PERMISSIONED, nu se face transfer de cheie privata de decriptare, informația fiind decriptata cu cheia proprietarului de date și apoi aceasta este transmisa către utilizatorul care a solicitat acces, în forma clara necriptata prin Interfața API. Proprietarul datelor poate refuza o cerere de acces la date.

3.3.12 Vizibilitatea datelor în blockchain

Orice utilizator are acces la datele din HyperFiuse prin Interfața API. Interfața API permite unui utilizator sa interacționeze cu sistemul pentru a adaugă, modifica și șterge informații ca în orice sistem de gestiune a bazelor de date tradițional. Operațiunea de citire se face de asemenea prin intermediul Interfeței API, iar citirea informațiilor dintr-o tabela retumează calup de date la care utilizatorul care efectuează operația de citire are acces.

Operațiunea de listare a informațiilor dintr-o tabela, se poate efectua cu parametru de filtrare a informațiilor la care un utilizator are acces:

a 2019 00496

14/08/2019

Μ

Listare informații cu parametru ALL ACCESSIBLE: se retumează toate informațiile introduse cu eticheta PLTBLIC, toate informațiile introduse cu parametru PERMISSIONED care aparțin utilizatorului care face citirea sau altor utilizatori care au acordat acces la date utilizatorului care face citirea și toate informațiile introduse cu eticheta PRIVATE de către utilizatorul care face citire.

Listare informații cu parametru ALL: se retumează toate informațiile la care un utilizator are acces (aceleași descrise mai sus la listarea cu parametru ALL ACCESSIBLE) la care se adaugă și toate informațiile introduse cu parametru PERMISSIONED de alți utilizatori și la care nu a fost acordata permisiunea de citire. Aceste informații vor fi retumate doar cu identificatorul unic al înregistrării și identificatorul utilizatorului care este proprietarul datelor, fără a dezvălui conținutul înregistrării, iar identificatorul unic va fi folosit de utilizatorul care a efectuat citirea pentru o solicitare de acces la date.

- Listare informații cu parametru ALL FORBIDDEN: se retumează toate informațiile introduse cu parametru PERMISSIONED de alți utilizatori și la care nu a fost acordata permisiunea de citire. Aceste informații vor fi retumate doar cu identificatorul unic al înregistrării și identificatorul utilizatorului care este proprietarul datelor, fără a dezvălui conținutul înregistrării, iar identificatorul unic va fi folosit de utilizatorul care a efectuat citirea pentru o solicitare de acces Ia date.

Indiferent ca informațiile sunt sau nu sunt criptate în baza de date, operațiunea de citire va retuma lista înregistrărilor solicitate în forma clara, necriptata, procesul de decriptare fiind efectuat automat (în baza permisiunilor) de sistemul HyperFiuse, înainte ca acestea sa fie livrate către utilizatorul care efectuează operațiunea de citire.

3.3.13 Citirea cu confirmarea a integrității datelor

Operațiunea citirii individuale a unei înregistrări, în baza identificatorului unic al acesteia, se poate efectua și cu cerere de verificare a integrității datelor, pentru a se identifica dacă informațiile retumate de operațiunea de citire nu au suferit modificări neautorizate la nivel de baza de date. Operațiunea de verificare a integrității este opțională, iar în cazul în care se optează pentru aceasta, rezultatul retumat în urma solicitării înregistrării către Interfața API, va conține un câmp care are valoarea logica ADEVARAT sau FALS (true / false) care va indica exact dacă informația a fost alterata sau nu. Este la latitudinea programatorului sau a sistemului software care solicita informația, sa decidă ce acțiuni se pot deduce după citire, în cazul în care o informație a fost identificata ca modificata neautorizat. Utilizatorul care a 21 a 2019 00496

14/08/2019 //Λ efectuat operația de citire poate contacta administratorul de date și solicita investigații mai ample sau poate solicita sistemului sa reconstruiască informația și sa o readucă la forma originala (vezi capitolul 3.3.14)

Verificarea informațiilor se face prin calcularea unui hash al datelor citite din baza de date, și compararea acestuia cu hash-ul corespondent înregistrării din blockchain. In blockchain, hash-ul original fiind calculat și stocat la momentul introducerii datelor în sistem. Dacă cele doua hash-uri sunt diferite înseamnă ca informația a fost modificata în baza de date. Se pleacă de la premiza ca informația din blockchain nu poate fi modificata, iar falsificarea acesteia presupune reconstrucția întregului lanț imutabil de date pe toate nodurile.

Indiferent ca informațiile sunt sau nu sunt criptate în baza de date, operațiunea de citire va retuma înregistrarea solicitate în forma clara, necriptata, procesul de decriptare fiind efectuat automat (în baza permisiunilor) de sistemul HyperFiuse, înainte ca aceasta sa fie livrata către utilizatorul care efectuează operațiunea de citire.

3.3.14 Reconstrucția datelor alterate

Operațiunea citirii individuale a unei înregistrări, în baza identificatorului unic al acesteia, se poate efectua și cu cerere de reconstrucție a înregistrării. Este la latitudinea programatorului dacă decide sa reconstruiască o informație în cazul în care aceasta a fost identificata ca alterata fata de forma originala. Programatorul sau sistemul software care operează citirea, poate solicita reconstrucția înregistrării independent de eventuale modificări ale acesteia. Opțiunea de reconstrucție a datelor poate fi invocata la orice citire a informatei.

Mecanismul de reconstrucție, odată invocat, va cauta o varianta nealterata a înregistrării pe nodul de date unde informația a fost adăugata sau pe un nod de tip FULL NODE din rețea. Mecanismul de reconstrucție este creat pentru a oferi variante rapide pentru recuperarea datelor și pentru a oferi garanție superioara a imutabilității datelor și rezistentei sporite ale datelor la modificări neautorizate.

3.3.15 Mecanismul de versionare a datelor

Toate datele stocate în HyperFiuse, sunt păstrate împreuna cu tot istoricul modificărilor acestora. Orice tabela/colecție creata în HyperFiuse are un corespondent în baza de date 22 a 2019 00496

14/08/2019 ]! £ indiferent ce motor de baze de date este folosit. Pe lângă aceasta tabela, se crează o tabela istoric care va stoca toate versiunile anterioare ale unei înregistrări. Mai exact, în tabela din baza de date vom avea întotdeauna ultima versiune a unei înregistrări iar în tabela asociata de istoric vom avea toate versiunile anterioare ale înregistrării.

Versiunile istorice ale unei înregistrări, sunt și ele imutabile, adică pot fi verificate cu hash-ul original stocat în blockchain, iar mecanismul de verificare a integrității (vezi capitolul 3.3,13) și mecanismul de reconstrucție de date (vezi capitolul 3.3.14) se aplica și în cazul datelor istorice.

Operațiunea citirii individuale a unei înregistrări, în baza identificatorului unic al acesteia, se poate efectua și cu cerere de vizualizare a unei versiuni istorice a unei înregistrări. Orice citire, retumează odată cu datele solicitate și versiunea maxima a înregistrării (număr întreg de la 1 la n unde n este ultima versiune). In baza acestui număr de versiune maxima, programatorul poate solicita orice versiune din intervalul l-n a înregistrării respective în asa fel încât HyperFiuse va ști ce fel de informație se solicita și va retuma datele din tabela principala sau din tabela istoric.

3.3.16 Mecanismul de recuperare a datelor (back-up in timp real)

HyperFiuse înlocuiește mecanismul de back-up clasic prin copiere integrala a bazei de date (tip snapshot), și elimina problemele de pierdere a datelor care se scriu în baza de date de la momentul creării ultimei copii pana la distrugerea bazei de date. Pe lângă aceste riscuri, back-up-ul prin copiere integrala de tip snapshot solicita și foarte mult spațiu pe disk, la modul în care cu cat mai dese sunt copiile cu atât mai mult spațiu se consuma.

HyperFiuse stochează datele integral pe fiecare nod de tip FULL NODE(vezi capitolul 3.3.7), iar de fiecare data când un nod de date de tip FULL NODE este adăugat într-o subrețea, acesta începe să se sincronizeze și sa aducă toate datele din baza de date și din blockchain. Procesul durează o perioada de timp direct proporțională cu volumul de date stocat. Nodul creat expune prin Interfața API toate funcționalitățile prin care produsul software poate interacționa cu HyperFiuse pentru a fi complet operațional. Un nod pierdut sau deteriorat la care se conectează un produs software poate fi ușor reconstruit iar intre timp produsul software se poate conecta la oricare alt nod de tip FULL NODE din rețea.

Acest mecanism nu solicită nici un fel copiere integrala de tip snapshot, din contra, este nevoie de 2-3 noduri de tip FULL NODE care să asigure siguranța maximă de care e nevoie pentru a garanta ca un sistem poate fi operațional și disponibil 100%, în comparație cu un back-up clasic care face cel puțin 2-3 copii integrale în fiecare zi.

a 2019 00496

14/08/2019

3.3.17 Mecanismul de alerte și notificări

Operațiunile înregistrate în HyperFiuse, pot fi monitorizare de administratorul de sistem, iar la fiecare interacțiune de scriere, citire, ștergere sau actualizare a unei înregistrări, se pot defini alerte și notificări. Mecanismul de alerte și notificări se definește prin “momentul producerii unui eveniment - (CÂND)” și “activitatea care trebuie sa se desfășoare la producerea unui eveniment - (CE)”.

Evenimentele care pot fi monitorizate în HyperFiuse sunt detaliate în tabelul următor (CÂND):

Operațiune Scriere	Eveniment	Descriere
INSERT	BEFORE	înainte de inserarea unei înregistrări se poate genera o alerta
INSERT	AFTER	După inserarea unui eveniment in sistem se va genera o alerta.
UPDATE	BEFORE	înainte de actualizarea unei înregistrări se poate genera o alerta
UPDATE	AFTER	După actualizarea unui eveniment in sistem se va genera o alerta.
DELETE	BEFORE	înainte de ștergerea unei înregistrări se poate genera o alerta
DELETE	AFTER	După ștergerea unui eveniment in sistem se va genera o alerta.
UPDATE-ID	BEFORE	înainte de actualizarea unei anumite înregistrări se poate genera o alerta, alerta care nu se va genera decât dacă înregistrarea cu identificatorul unic specificat de administrator va fi actualizata
UPDATE-ID	AFTER	După actualizarea unui anumit eveniment in sistem se va genera o alerta, alerta care nu se va genera decât dacă înregistrarea cu identificatorul unic specificat de administrator va fi actualizata
DELETE-ID	BEFORE	înainte de ștergerea unei anumite înregistrări se poate genera o alerta, alerta care nu se va genera decât dacă înregistrarea cu identificatorul unic specificat de administrator va fi ștearsă

a 2019 00496

14/08/2019

DELETE-ID

AFTER

După ștergerea unui eveniment in sistem se va genera o alerta, alerta care nu se va genera decât dacă înregistrarea cu identificatorul unic specificat de administrator va fi ștearsă

Fiecare alerta generata de sistem in urma evenimentelor definite în tabelul de mai sus, poate fi operata în mai multe feluri după cum urmează (CE):

Tip prelucrare	Parametru	Descriere
Procedura Stocata	înregistrare operata	La fiecare eveniment se executa un smart contract (vezi capitolul 3.3.19) de tip procedura stocata. Se va trimite ca parametru înregistrarea alterata și procedura stocata va acționa conform instrucțiunilor din smart contract asa cum au fost create de programator.
Mesaj Web	înregistrare operata	La fiecare eveniment se va executa un request(cerere) web de tip POST, care are ca parametru înregistrarea alterata și detalii despre tipul evenimentului care a înregistrat alerta. Va fi la latitudinea programului care va intercepta request-ul sa determine ce va face mai departe cu informațiile primite.
Notificare Sistem	înregistrare operata	La fiecare eveniment se va adăuga o înregistrare in tabela de notificări de sistem, înregistrare care va conține detalii despre tipul evenimentului care a generat alerta, înregistrarea alterata și utilizatorul care a inițiat operațiunea de scriere. Administratorul de sistem va observa aceste alerte in aplicația de administrare a sistemului.
E-mail	înregistrare operata	La fiecare eveniment se va trimite un email cu detalii despre tipul evenimentului care a generat alerta, înregistrarea alterata și utilizatorul care a inițiat operațiunea de scriere. E-mail-ul se va trimite numai dacă sistemul este configurat cu detaliile SMTP necesare trimiterii de email-uri din sistem.

3.3.18 Licențierea nodurilor

HyperFiuse este un sistem creat pentru a deservi companiile care dezvolta soluții software pe tehnologia blockchain, companii care își vor construi soluțiile pe o rețea privata. Mai exact, nodurile care fac partea din rețeaua HyperFiuse vor aparține unui client, beneficiar, care deși va administra întreg sistemul, poate apărea posibilitatea ca anumite noduri sa ruleze 25

a 2019 00496

14/08/2019 la terți. Din acest motiv, dar și pentru a evita introducerea unui nod în rețea de către persoane neautorizate, este nevoie de un mecanism de licențiere al nodurilor, un mecanism care sa permită crearea de noi noduri, dar în același timp acest proces sa fie supravegheat, aprobat și controlat de beneficiarul final al sistemului.

Licențierea nodurilor protejează beneficiarul de adăugarea unor noduri neaprobate în sistem, care pot fi folosite la extragerea de informații de către terți neautorizați. Dacă în soluțiile blockchain tip public, nu este necesara aceasta protecție, in HyperFiuse se dorește ca nici un nod care este parte din rețea sa nu fie pornit fără aprobarea finala a beneficiarului de sistem.

Există două proceduri care trebuiesc urmate pentru a pomi o rețea HyperFiuse: procedura de a pomi nodul inițial sau primul nod și procedura de adăugare a altor noduri într-o rețea deja creata. Procedura de pornire sau de creare a nodului inițial are următorii pași:

1. Se pornește nodul inițial și se da ca parametru de pornire numele/identificatorul unic al nodului.

2. Se apelează prin Interfața API funcția /license/generateLicenseKeys cu parametri validity si startDate, pentru a crea o licența care se prezintă sub forma unui cuplu de chei publice/private. Parametrul validity se refera la perioada de valabilitate a licenței iar parametru startDate se refera la data în care licența intra în vigoare. API-ul generează și stochează licența în sistem și întoarce înregistrarea salvata cu identificatorul unic asociat acesteia.

3. Se apelează prin Interfața API funcția /license/createNode cu parametri nodeld, licenselds\ nodeType, pentru a crea o configurare care asociază nodul inițial cu licența creata la pasul anterior. Parametrul nodeld se încarcă cu numele nodului/identificatorul unic al acestuia, parametrul licenseld se încarcă cu identificatorul unic al licenței care s-a generat la pasul 2 iar parametru nodeType specifica tipul nodului care este creat (nod de date sau nod de autorizare - pentru mai multe detalii vezi capitolul 3.2). API-ul asociază licența creata cu nodul pornit și întoarce înregistrarea stocata pentru confirmare.

4. Se descarcă licența generată la pasul 2 prin Interfața API funcția /license/download/{nodeNatne} Parametru nodeName conține numele nodului creat/identificatorul unic al acestuia.

5. Se copiază fișierul de licența descărcat pe nodul inițial in folderul specific stocării de fișiere de licența a 2019 00496

14/08/2019

6. Se apelează prin Interfața API funcția /license/applyConfîguration care generează token-ul nodului care este folosit mai departe de nodul inițial în comunicarea cu celelalte noduri din rețea (sub forma de cheie API).

Procedura de adăugare a unui nod nou în rețea este următoarea:

1. Se apelează prin Interfața API funcția /Ucense/generateLicenseKeys cu parametri validity si startDate, pentru a crea o licența care se prezintă sub forma unui cuplu de chei publice/private. Parametrul validity se refera la perioada de valabilitate a licenței iar parametru startDate se refera la data în care licența intra în vigoare. API-ul generează și stochează licența în sistem și întoarce înregistrarea salvata cu identificatorul unic asociat acesteia.

2. Se apelează prin Interfața API funcția /license/createNode cu parametri nodeld, licenseld si nodeType, pentru a crea o configurare care asociază nodul nou cu licența creata la pasul anterior. Parametrul nodeld se încarcă cu numele nodului/identificatorul unic al acestuia, parametrul licenseld se încarcă cu identificatorul unic al licenței care s-a generat la pasul 1 iar parametru nodeType specifica tipul nodului care este creat (nod de date sau nod de autorizare - pentru mai multe detalii vezi capitolul 3.2). API-ul asociază licența creata cu nodul nou și întoarce înregistrarea stocata pentru confirmare.

3. Se descarcă licența generata la pasul 1 prin Interfața API funcția /license/download/{nodeName} Parametru nodeName conține numele nodului nou creat/identificatorul unic al acestuia.

4. Se copiază fișierul de licența descărcat pe nodul nou creat în folderul specific stocării de fișiere de licența

5. Se pornește nodul nou creat cu parametrul de pornire numele nodului/identificatorul unic al acestuia ales de operator la pasul 2. La pornirea nodului, se generează automat un token specific noului nod creat, care va folosi în comunicarea cu alte noduri din rețeaua HyperFiuse (cheie secreta API)

Mecanismele definite au ca scop clarificarea faptului ca exista un mecanism de licențiere în baza căruia un nod poate fi asociat cu o rețea HyperFiuse, clarificarea procedurii prin care acest mecanism de licențiere este activat împreună cu pornirea și adăugarea unui nod nou, precum și clarificarea faptului ca comunicarea intre nodurile rețelei se face prin protocolul TCP și numai în baza unei chei secrete API care este asociata cu licența de funcționare a fiecărui nod în parte.

a 2019 00496

14/08/2019

3.3.19 Contracte Inteligente (Smart Contracts)

Contractele inteligente sau smart contracts, sunt secvențe de cod (programe software) pe care un programator le poate alipi sau adăuga sistemului HyperFiuse. Aceste programe au ca scop extinderea funcționalităților existente ale platformei, permițând programatorului sau beneficiarului sa adauge funcții noi pe lângă caracteristicile standard care sunt disponibile la instalare. De asemenea, contractele inteligente se mai evidențiază și prin faptul ca sunt stocate în blockchain, iar codul sursa care le definește devine imutabil, oferind beneficiarului sau terților care interacționează cu sistemul HyperFiuse, garanția ca anumite funcționalități nu pot fi modificate nici măcar de beneficiarul platformei.

Dezvoltarea de contracte inteligente este la îndemâna oricărui programator, care are la dispoziție o instanța de HyperFiuse, codul sursa al contractului inteligent fiind în proprietatea programatorului, acesta fiind liber de a comercializa sau pune la dispoziție gratuit funcționalitatea creata. Cu toate acestea, mecanismul și mediul de execuție al contractelor inteligente, adică platforma HyperFiuse este și va rămâne proprietatea intelectuala a Ingenium Blockchain Technologies, creatorul HyperFiuse. De asemenea, pentru a crea un contract inteligent, programatorul trebuie sa urmeze procedurile de dezvoltare puse la dispoziție de Ingenium Blockchain Technologies, precum și librăriile ajutătoare și/sau platformele care facilitează aceste dezvoltări.

HyperFiuse este un mediu de execuție al contractelor inteligente, iar prin intermediul unui contract inteligent, programatorul poate interacționa cu mai multe componente/funcționalități deja existente precum Criptarea/Decriptarea, verificarea integrității unei înregistrări șamd. La momentul dezvoltării unui contract inteligent, programatorul are nevoie de interfețele de comunicare cu funcționalitățile existente, chiar dacă nu se afla într-un mediu de execuție HyperFiuse. Practic, prin intermediul librăriilor puse la dispoziție de Ingenium Blockchain Technologies, un programator poate folosi un mediu de dezvoltare Java pentru crea contracte inteligente, fără a avea neapărat la dispoziție un sistem HyperFiuse funcțional. într-adevăr, pentru testarea contractului dezvoltat, va fi nevoie de un mediu de test sau o instanța HyperFiuse pentru rularea funcționalității create. Aceste librarii cu interfețe de interacționare HyperFiuse sunt disponibile la descărcare pentru orice programator care dorește sa dezvolte contracte inteligente.

Contractele inteligente sunt dezvoltate pe calculatorul personal de către programatori, iar odată terminate acestea pot fi încărcate și activate în sistemul HyperFiuse. Codul sursă al unui contract inteligent va fi în format arhiva Java (*.jar), și poate conține sursele programului, a 2019 00496

14/08/2019 atașarea acestora la arhiva fiind strict la latitudinea programatorului. încărcarea contractului inteligent în HyperFiuse se face prin intermediul interfeței de administrare de către administratorul sistemului sau de către programator, în funcție de drepturile de acces ale acestuia. Odată încărcat un contract inteligent, HyperFiuse va stoca conținutul arhivei precum și componentele acesteia și va genera semnătura calculata printr-o funcție hash a oricărui fișier care compune arhiva încărcata. Toate semnăturile asociate fișierelor care compun arhiva contractului inteligent, împreuna cu operația de încărcare în sine, sunt stocate pe blockchain (lanțul imutabil) pentru a putea verifica la orice moment din timp integritatea funcționalităților pe care contractul inteligent le expune, și pentru a garanta utilizatorilor sistemului ca codul de executat nu a fost alterat.

Mecanismul de distribuție date (vezi capitolul 3.3.2) va ajuta ca contractul inteligent încărcat în sistem sa fie distribuit și încărcat pe toate nodurile de date din rețea, în asa fel încât funcționalitatea pe care contractul inteligent o expune sa fie disponibila în tot sistemul. Acest procedeu ajuta foarte mult și la mecanismele de propagare de cod și funcționalități noi într-un sistem aflat în producție.

Un contract inteligent se supune și mecanismului de versionare al HyperFiuse, mecanism care permite unui programator sa aducă îmbunătățiri unui contract inteligent, încărcând versiuni noi ale contractului și permițând rularea și execuția unui contract inteligent cu parametru de versiune. Programatorul sau administratorul sistemului poate opta și pentru anularea unei versiuni de contract inteligent, pentru situațiile în care versiunile noi sunt critice sau nu se mai dorește expunerea unor anumite funcționalități.

Un contract inteligent se încarcă în sistemul HyperFiuse și la publicare primește un id unic ca răspuns la unei operațiuni de încărcare efectuate corect. încărcarea unui contract inteligent poate eșua în contextul unor erori de cod sursa sau în contextul în care se rulează anumite teste de securitate fără rezultat pozitiv. Lista contractelor publicate de un utilizator, în general un administrator are drept de încărcare a unui smart contract, este disponibila în aplicația de administrare a sistemului. Fiecare contract inteligent disponibil în lista contractelor încărcate poate fi operat de administrator în felul următor:

activare/dezactivare - contractul inteligent odată încărcat nu este activ, disponibil funcțional pana când nu este activat de administrator. Dezactivarea unui contract inteligent duce contractul în starea în care nu mai poate fi accesat de utilizatori, contractul devenind nefuncțional ștergere - contractul inteligent este anulat, și nu mai poate fi apelat de nici un utilizator. Operațiunea este ireversibila a 2019 00496

14/08/2019

- actualizare - se încarcă o noua versiune a contractului inteligent verificare istoric - se verifica istoricul apelurilor utilizatorilor la contractul inteligent. Istoricul se prezintă sub forma unui log imutabil care detaliază apelurile utilizatorilor și cuprinde informații precum metoda din contract apelata, parametri de apelare, utilizatorul care a apelat contractul, data și ora evenimentului, eventuale erori precum și log-urile specificate de programator în interiorul contractului.

- activare/dezactivare sistem de logare contract inteligent

- definire contract inteligent ca activitate recurenta cu parametri globali (data, ora, etc) se aplica numai pentru contracte inteligente de tip procedura stocata

- specificare utilizator în numele căruia se executa contractul inteligent - se aplica numai pentru contracte inteligente de tip procedura stocata

Contractele inteligente sunt de mai multe tipuri și se diferențiază prin natura în care se executa. Avem contracte inteligente de tip API și contracte inteligente de tip procedura stocata.

Contractele inteligente de tip API, sunt contractele a căror funcționalitate este accesata direct de programator prin Interfața API. Un contract inteligent este apelat prin Interfața API, prin intermediul unui API general, care ia ca parametri in URL identificatorul unic al contractului, versiunea contractului și metoda din contract care se apelează. Cererea web API este de tip POST și în conținutul cererii se transmit parametri metodei apelate în format JSON. Răspunsul cererii web de apelare a unei metode unui contract inteligent poate fi de orice natura specifica unei cereri de tip POST: JSON, text, HTML, descărcare de fișier șamd.

Contractele inteligente de tip procedura stocata, sunt contractele care nu pot fi apelate direct de programator prin intermediul Interfeței API, dar pot fi apelate de mecanismul de alertare sau de alte contracte inteligente. Scopul acestora este sa faciliteze funcționalitate în interiorul HyperFiuse, care poate fi reutilizata și de alte contracte sau poate fi apelata de procese interne HyperFiuse (asa cum este mecanismul de alerte care în urma unui eveniment poate apela un contract inteligent). Apelarea unei metode dintr-un contract inteligent de tip procedura stocata, întoarce rezultatul la momentul execuției, iar log-urile asociate pot fi vizualizate de administrator în interfața de administrare. Contractele inteligente de tip procedura stocata pot fi definite de către administrator și ca activități recurente, procese care se execută regulat și efectuează anumite operațiuni la intervale regulate de timp.

Un contract inteligent, odată încărcat în sistemul HyperFiuse, poate fi instruit de programatorul care l-a creat sa efectueze cel puțin următoarele operațiuni:

a 2019 00496

14/08/2019 poate opera asupra oricărei entități/tabele de date. Operarea unei entități se refera la modificarea structurii acesteia sau la manipularea datelor (citire, adăugare, actualizare și ștergere)

- poate efectua operațiuni de verificare a integrității datelor

- poate efectua operațiuni de recuperare a datelor poate efectua operațiuni de criptare/decriptare de date

- poate efectua operațiuni de semnare digitala a datelor

- poate accesa diferite versiuni ale datelor

- poate solicita acces la date și poate oferi acces la date

- poate apela contracte inteligente de tip procedura stocata

- poate accesa servicii expuse de HyperFiuse: trimitere email, generare de alerte notificări, scriere de loguri etc

- poate accesa librăriile de funcționalități puse la dispoziție de HyperFiuse: librarii pentru validarea parametrilor de intrare, librarii pentru calcule matematice, librarii pentru formatare text

- poate accesa servicii web externe

- poate accesa orice funcționalitate pusa la dispoziție de limbajul de programare Java, în nivelului de securitate aplicat de administratorul platformei

Toate metodele dintr-un contract inteligent se vor executa în numele unui utilizator de sistem, și toate restricțiile de securitate respectiv drepturile de acces pe care acesta le are, se vor aplica pe parcursul execuției metodei din contract. Utilizatorul care apelează contractul inteligent este utilizatorul ale cărui drepturi de acces vor fi aplicate. Pentru anumite proceduri stocate recurente, poate fi configurata execuția în numele unui utilizator anume sau utilizator de sistem (administrator)

3.3.20 GraphQL

GraphQL este un limbaj open-source de interogare a datelor obținute prin interfețe de tip API și un mediu de manipulare a acestora. Limbajul a fost dezvoltat în 2012 de Facebook pentru uz intern, și a fost făcut public în 2015. GraphQL se prezintă tot ca o interfață API care permite operațiuni de manipulare, mult mai complexe a datelor, cu API-uri care sunt limitate prin operațiunile pe care le pun la dispoziția programatorilor.

HyperFiuse expune prin Interfața API, operațiunile primare de interacțiune cu datele salvate în sistem: creare date, actualizare date, ștergere date și citire de date. Cu ajutorul a 2019 00496

14/08/2019

GraphQL, Interfața API HyperFiuse oferă posibilitatea programatorului sa creeze interogări complexe cu aceste date într-un mod mai ușor și mai eficient.

GraphQL nu este proprietatea HyperFiuse, este doar o componenta open-source pe care acesta o folosește, singurul lucru care trebuie reținut din acest context este ca HyperFiuse, cu ajutorul GraphQL, oferă posibilitatea programatorului de a rula și interogări complexe prin Interfața REST API.

Invenția a fost în principal descrisă mai sus cu referire la câteva exemple de realizare. Cu toate acestea, așa cum este ușor de apreciat de o persoană de specialitate în domeniu, alte exemple de realizare față de cele dezvăluite mai sus sunt la fel de posibile în interiorul scopului invenției, așa cum este definit prin revendicările anexate.

Claims

REVENDICĂRI

1. Platformă de conectare destinată să conecteze un motor de blockchain cu o bază de date tradițională, platforma fiind implementată sub forma unei rețele de noduri, rețeaua de noduri menționată fiind împărțită în cel puțin două subrețele: o subrețea de securitate și o subrețea de date, toate nodurile din sub-rețeaua de securitate conținând informații referitoare la cheile de securitate ale utilizatorilor, licențele de funcționare, politice de acces, precum și alte informații care țin de mecanismul de licențiere, autentificare și autorizare al utilizatorilor care accesează platforma, și în care nodurile din cel puțin o subrețea de date cuprind o componentă software care folosește o rețea de calculatoare, o interfață de comunicare API ce permite interacțiunea cu rețeaua de calculatoare și preluarea informațiilor care trebuie salvate în sistemul de stocare, o interfață GraphQL de interogare a datelor, un motor procesare date, un motor blockchain, o interfața de conectare între motorul de procesare date și motorul blockchain, și o bază de date.
2. Platformă conform revendicării 1, cuprinzând mijloace de validare a datelor și salvarea acestora în baza de date menționată, precum și salvarea în blockchain a unei referințe despre locația datelor în baza de date și a unei amprente digitale a acestor informații.
3. Platformă conform revendicării 1, cuprinzând mijloace de calcul a amprentei digitale a înregistrării salvate folosind o funcție hash (Ex: MD5, SHA256, SHA512, dar pot fi folosite și alte funcții de calcul a amprentei digitale).
4. Platformă conform revendicării 1, cuprinzând mijloace de scriere la nivel de bază de date, în care mijloacele de scriere pot fi de trei feluri: inserare, modificare și ștergere, fiecare operațiune fiind stocată în blockchain ca tranzacție independentă alături de informațiile de referință, precum o tabelă, un identificator al înregistrării și amprentă digitală menționată.
5. Platformă conform revendicării 1, în care motorul de blockchain are autoritatea de distribuție a datelor din blockchain pe toate nodurile din toate sub rețelele de date, iar datele din baza de date sunt sincronizate cu ajutorul platformei de conectare, fiecare nod din sub rețeaua de date este actualizat în blockchain cu blocurile cele mai recent validate de motorul de blockchain, iar odată sincronizat un nou bloc, platforma de conectare procesează fiecare tranzacție din bloc și pentru fiecare dintre acestea inițiază o cerere de obținere a datelor modificate către nodul emitent în care a fost creată tranzacția, iar odată primite datele, acestea a 2019 00496

14/08/2019 sunt modificate și în baza de date a nodului recipient conform tipului de tranzacție specificat în blockchain.
6. Platformă conform revendicării 1, în care platforma de conectare permite accesul direct la baza de date, respectiv publicarea detaliilor de conectare directă la motorul de baze de date.
7. Platformă conform revendicării 1, în care platforma de conectare permite accesul la baza de date prin interfața API, interfață care va retuma datele în format decriptat, va filtra datele în funcție de drepturile pe care utilizatorul care efectuează citirea le are asupra acestora, va efectua verificări de integritate asupra datelor și va permite citirea cu opțiunea de reconstruire a datelor în cazul în care au fost identificate modificări/ștergeri neautorizate asupra acestora.
8. Platformă conform revendicării 1, în care sub rețelele de date pot fi configurate pentru a limita sincronizarea datelor din anumite tabele/colecții la nodurile din cadrul subretelei, polițele de sincronizare a datelor aplicându-se la nivel de subrețea, unde pentru fiecare subrețea de date se poate specifica ce tabelă/colecție de date să nu se sincronizeze cu noduri din afara sub rețelei.
9. Platformă conform revendicării 1, în care platforma permite configurarea unui nod în așa fel încât acesta să nu sincronizeze toate datele, și să stocheze numai datele care au fost salvate folosind Interfața API instalată pe nodul menționat.
10. Platformă conform revendicării 1, în care platforma permite criptarea informațiilor printrun cuplu de chei format dintr-o cheie publică și o cheie privată, cheia privată a unui utilizator fiind protejată prin 3 mecanisme diferite și anume: dispozitiv hardware extern care stochează cheia privată și este în posesia utilizatorului, păstrarea cheii private de către utilizator în format șir de caractere digital sau în care cheile sunt stocate în sub rețeaua de securitate și gestionate de platformă, și a treia varianta în care cheile private sunt gestionate de platformă, sunt destinate produselor software care nu au utilizatori pregătiți să își protejeze o cheie privată și pun accent pe alte funcționalități oferite de platformă.
11. Platformă conform revendicării 1, în care platforma cuprinde mijloace de licențiere a nodurilor care permite crearea de noi noduri, sub supravegherea, aprobarea și controlul utilizatorului de platformă.

a 2019 00496

14/08/2019
12. Metodă de conectare a unui motor de blockchain cu cel puțin un motor de management a bazelor de date, metoda cuprinzând etapele de asigurare a unei platforme de conectare, conform revendicării 1, platforma menționată fiind implementată sub forma unei rețele de noduri împărțită în cel puțin două subrețele: o subrețea de securitate și o subrețea de date, toate nodurile din sub rețeaua de securitate conținând informații referitoare la cheile de securitate ale utilizatorilor, licențele de funcționare, politice de acces, precum și alte informații care țin de mecanismul de licențiere, autentificare și autorizare al utilizatorilor care accesează platforma, și în care nodurile din acea cel puțin o subrețea de date cuprind o componentă software care folosește o rețea de calculatoare, o interfață de comunicare API ce permite interacțiunea cu rețeaua de calculatoare și preluarea informațiilor care trebuiesc salvate în sistemul de stocare, o interfață GraphQL de interogare a datelor, un motor procesare date, un motor blockchain, o interfața de conectare între motorul de procesare date și motorul blockchain, și o bază de date.
13. Metodă conform revendicării 12, cuprinzând etapele de validare a datelor și salvare a acestora în baza de date menționată, precum și salvarea în blockchain a unei referințe despre locația datelor în baza de date și a unei amprente digitale a acestor informații.
14. Metodă conform revendicării 12, cuprinzând o etapă de calcul a amprentei digitale a înregistrării salvate folosind o funcție hash (Ex: MD5, SHA256, SHA512, dar pot fi folosite și alte funcții de calcul a amprentei digitale).
15. Metodă conform revendicării 12, cuprinzând etapa de scriere la nivel de bază de date, în care etapa de scriere pot fi de trei feluri: inserare, modificare și ștergere, fiecare operațiune fiind stocată în blockchain ca și tranzacție independentă alături de informațiile de referință, precum o tabelă, un identificator al înregistrării și amprentă digitală menționată.
16. Metodă conform revendicării 12, în care autoritatea de distribuție a datelor din blockchain pe toate nodurile din toate sub-rețelele de date aparține motorului de blockchain, iar datele din baza de date sunt sincronizate cu ajutorul platformei de conectare, fiecare nod din sub-rețeaua de date este actualizat în blockchain cu blocurile cele mai recent validate de motorul de blockchain, iar odată sincronizat un nou bloc, platforma de conectare procesează fiecare tranzacție din bloc și pentru fiecare dintre acestea inițiază o cerere de obținere a datelor

a 2019 00496

14/08/2019 modificate către nodul emitent în care a fost creată tranzacția, iar odată primite datele, acestea sunt modificate și în baza de date a nodului recipient conform tipului de tranzacție specificat în blockchain.
17. Metodă conform revendicării 12, cuprinzând etapa de permitere a accesului direct la baza de date, respectiv publicarea detaliilor de conectare directă la motorul de baze de date.
18. Metodă conform revendicării 12, cuprinzând etapa de permitere a accesului la baza de date prin interfața API, interfață care va retuma datele în format decriptat, va filtra datele în funcție de drepturile pe care utilizatorul care efectuează citirea le are asupra acestora, va efectua verificări de integritate asupra datelor și va permite citirea cu opțiunea de reconstruire a datelor în cazul în care au fost identificate modificări/ștergeri neautorizate asupra acestora.
19. Metodă conform revendicării 12, cuprinzând etapa de configurare a sub-rețelelor de date pentru a limita sincronizarea datelor din anumite tabele/colecții la nodurile din cadrul subrețelei, polițele de sincronizare a datelor aplicându-se la nivel de subrețea, unde pentru fiecare subrețea de date se poate specifica ce tabelă/colecție de date să nu se sincronizeze cu noduri din afara sub-rețelei.
20. Metodă conform revendicării 12, cuprinzând etapa de configurare a unui nod în așa fel încât acesta să nu sincronizeze toate datele, și să stocheze numai datele care au fost salvate folosind Interfața API instalată pe nodul menționat.
21. Metodă conform revendicării 12, cuprinzând etapa de criptare a informațiilor printr-un cuplu de chei format dintr-o cheie publică și o cheie privată, cheia privată a unui utilizator fiind protejată prin 3 mecanisme diferite și anume: dispozitiv hardware extern care stochează cheia privată și este în posesia utilizatorului, păstrarea cheii private de către utilizator în format șir de caractere digital sau în care cheile sunt stocate în sub-rețeaua de securitate și gestionate de platformă, și a treia varianta în care cheile private sunt gestionate de platformă, sunt destinate produselor software care nu au utilizatori pregătiți să își protejeze o cheie privată și pun accent pe alte funcționalități oferite de platformă.
22. Metodă conform revendicării 12, cuprinzând etapa de licențiere a nodurilor care permite crearea de noi noduri, sub supravegherea, aprobarea și controlul utilizatorului de platformă.

a 2019 00496

14/08/2019
23. Metodă conform revendicării 22, în care etapa de pornire sau de creare a unui nod inițial cuprinde următorii pași:

- pornirea nodul inițial și stabilirea ca parametru de pornire numele/identificatorul unic al nodului;

- apelarea prin Interfața API a funcției /Ucense/generateLicenseKeys cu parametri validity si startDate, pentru a crea o licență care se prezintă sub forma unui cuplu de chei publice/private

- apelarea prin interfața API a funcției /license/createNode cu parametri nodeld, licenseld si nodeType, pentru a crea o configurație care asociază nodul inițial cu licența creată la pasul anterior;

descărcarea licenței generată la pasul 2, prin interfața API, funcției /license/download/{nodeName}

- copierea fișierul de licență descărcat pe nodul inițial în folderul specific stocării de fișiere de licență;

- apelarea prin Interfața API a funcției /license/applyConfiguration care generează token-ul nodului care este folosit mai departe de nodul inițial în comunicarea cu celelalte noduri din rețea.
24. Metodă conform revendicării 22, în care etapa de adăugare a unui nod nou în rețea cuprinde următorii pași:

- apelarea prin interfața API a funcției /license/generateLicenseKeys cu parametri validity și startDate, pentru a crea o licență care se prezintă sub forma unui cuplu de chei publice/private;

- apelarea prin interfața API a funcției /license/createNode cu parametri nodeld, licenseld si nodeType, pentru a crea o configurație care asociază nodul nou cu licența creată la pasul anterior;

descărcarea licenței, generată la pasul 1 prin Interfața API, a funcției /license/download/{nodeName};

- copierea fișierului de licență descărcat pe nodul nou creat în folderul specific stocării de fișiere de licență;

- pornirea nodului nou creat cu parametrul de pornire numele nodului/identificatorul unic al acestuia ales de operator la pasul 2.
25. Produs program de calculator pentru conectarea unui motor de blockchain cu cel puțin un motor de management a bazelor de date, programul de calculator cuprinzând un cod de a 2019 00496

14/08/2019 { Qț program de calculator care, atunci când este rulat pe un echipament de utilizator, determină echipamentul de utilizator să realizeze metoda din oricare dintre revendicările 12 la 24.