Aplicațiile Blockchain au devenit extrem de populare în ultimii ani, însă dezvoltarea unui blockchain rămâne un mister pentru mulți programatori. În încercarea de a ne satisface curiozitățile, am ales să demistificăm procesul de creare al unui blockchain, găsind oportunitatea perfectă de a construi și prezenta o aplicație de acest tip în doar 24 de ore: evenimentul Ship IT - un hackathon organizat de Accesa la sediul din Cluj-Napoca, în luna iunie, la care au participat peste 60 de colegi și invitați externi. În rândurile de mai jos vom putea explora învățăturile extrase din această călătorie.
Având în vedere timpul scurt alocat dezvoltării aplicației, a fost important pentru noi să fim bine pregătiți în ziua evenimentului. Acest lucru a însemnat să avem o înțelegere în profunzime a ceea ce presupune construirea tehnologiei blockchain, să deținem tehnologiile potrivite selectate și să clarificăm arhitectura soluției.
În faza de pregătire, concentrarea noastră a fost să definim și să înțelegem sistemele și componentele care ar putea să facă parte din aplicația blockchain, fapt care a condus la mai multe cercetări asupra proiectelor disponibile pentru construirea aplicațiilor de acest tip. În timpul cercetărilor, am găsit două proiecte principale open-source: Hyperledger și Tendermint.
Hyperledger Iroha este o platformă pentru dezvoltarea aplicațiilor blockchain, care oferă permisiuni autorizate și se concentrează asupra furnizării de instrumente pentru dezvoltarea rapidă a aplicațiilor. Proiectul vine cu multe comenzi predefinite, care permit programatorilor să-și modeleze activele digitale și să construiască un sistem autorizat în jurul lor, cu un risc minim de defecte - este ca și cum ai compune o aplicație folosind logica preconstruită.
Tendermint este un program care gestionează mecanismul de consens și oferă un API pentru interacțiunea cu motorul de consens. Folosind API, programatorii pot construi propriul set de reguli deterministe și pot modela active digitale. Acest API oferă libertatea de a defini anumite componente ale sistemului: permisiuni, roluri, acțiuni, active digitale dar și reprezentarea acestora.
Pentru echipa noastră formată din șapte membri, a fost de la sine înțeles că a construi un sistem de la zero în 24 ore va fi extrem de dificil, iar concentrarea excesivă și lipsa prioritizării într-o astfel de provocare ar cauza nefinalizarea soluției în timp util. Pe de altă parte, folosirea unei aplicații cum ar fi Hyperledger ar însemna ca echipa să fi construit puține sau doar o singură componentă, ceea ce ar sugera absența conștientizării multiplelor funcționalități implementate în interiorul platformei. S-ar putea să nu avem nici măcar control asupra numărului de resurse folosite pentru acțiuni precum semnarea mesajelor sau resurse pentru diferite nivele persistente. Prin urmare, echipa a decis să folosească Tendermint, datorită calității sale de a furniza un echilibru bun între funcționalitatea preconstruită și componentele care pot fi construite independent.
În timpul pregătirii, am petrecut cea mai mare parte a timpului înțelegând Tendermint, deoarece acesta manipula părți complexe ale software-ului. Principalul domeniu de interes a fost interfața pentru comunicarea cu Tendermint, funcționarea internă a proceselor Tendermint, cerințele de implementare și scalarea rețelei, toleranța la erori și mecanismele de recuperare.
Împreună cu Tendermint, au fost folosite următoarele tehnologii și instrumente:
Tendermint;
Java 17 pentru construirea validatorilor;
Xodus pentru stocarea activelor digitale;
Protocol Buffers (Protobuf) și open-source framework gRPC pentru comunicarea între Tendermint și validatori;
Docker pentru deploy-ul nodurilor care rulează Tendermint și validatori într-o singură rețea în mai multe containere;
Java și Spring Boot pentru construirea aplicației client ce vizează partea de back-end;
Angular pentru secțiunea de front-end a aplicației client.
Protocoalele de comunicare folosite între diferite sisteme sunt:
RPC (Remote Procedure Call);
Unul din cele mai importante aspecte în dezvoltarea software este acela de a avea o arhitectură cât mai bine și clar definită, fiind extrem de util să știm înainte de dezvoltare cum împărțim problema în părți mai mici. Prin urmare, am urmărit să stabilim ce componente vor fi folosite pentru a rezolva care probleme, ce componente se vor reuni într-un singur sistem, câte sisteme logice vom avea și cum se va realiza comunicarea între aceste sisteme.
Fig.1: Componentele aplicației
După multe discuții, echipa a identificat componentele cheie care ar trebui construite pentru a obține o aplicație de blockchain funcțională:
UI / UX pentru vizualizarea activelor digitale și a informației (Fig.1) ;
Aplicația client back-end pentru comunicarea cu rețeaua pentru crearea activelor digitale, executarea tranzacțiilor și interogarea informațiilor (Fig. 1) ;
Rețeaua peer-to-peer blockchain ( Fig.1). Această rețea rulează mai multe noduri și un client se poate conecta la oricare nod.
Mecanismul de consens (Fig. 2). Este parte din Tendermint și folosește algoritmul de toleranță al greșelii Bizantin pentru a ajunge la un consens;
Stocarea pentru blockchain (Fig. 2). Pentru stocarea informației de blockchain este folosit LevelDB de către Tendermint.
Validarea tranzacțiilor. API RPC care face serializare personalizată folosind parametri (Fig. 2). Aplicație Java care gestionează starea activelor digitale și validează tranzacțiile care pot să își schimbe starea;
Stocarea activelor digitale de către validatori (Fig. 2);
Figura 2: Componentele unui nod din Blockchain
Ziua de Hackathon a început, iar echipa s-a adunat pentru a discuta deciziile finale pentru implementare. Având în vedere experiența membrilor din echipă, colegii s-au oferit voluntari pentru a implementa părți distincte ale sistemului, fiind cel mai dinamic proiect la care am participat până acum.
Pentru a obține cele mai bune rezultate pe baza abilităților membrilor echipei, aceasta a fost împărțită în cinci grupuri:
Experții în Java și-au luat responsabilitatea de a implementa partea de back-end pentru aplicația client și validatorii. Acest grup a creat un validator care poate verifica tranzacții înainte de crearea unui portofel și transferul monedelor dintr-un portofel în altul. Validatorii vor rula într-un fir separat și vor vorbi cu Tendermint prin gRPC (proiect open-source pentru RPC). De altfel, va fi creat și un client final, care poate trimite cererea atât pentru creare, cât și pentru transferul de monede.
Membrii cu experiență în modelele de depozit și tehnologia de persistență și-au asumat responsabilitatea pentru persistența activelor digitale (portofele) și dezvoltarea mecanismelor de interogare. Persistența urma să fie obținută prin utilizarea proiectului JetBrains Xodus. Interogarea va permite clienților finali să enumere portofelele disponibile, să creeze portofele și să verifice soldurile.
Membrii cu experiență în DevOps și configurarea rețelei au fost responsabili pentru implementarea rețelei Tendermint, care trebuie să fie lansată cu minim patru noduri și patru validatoare. Fiecare nod ar trebui să fie asociat cu un validator, validatorul asociat ar trebui să poată comunica prin portul TCP, dar niciun validator nu ar trebui să fie expus public. Fiecare nod va fi expus public pentru a comunica cu un client final.
Alți ingineri s-au ocupat de protocoale de autentificare și permisiuni pentru tranzacțiile utilizatorilor. Autentificarea trebuie făcută folosind semnături de chei private și publice. Clientul final trebuie să semneze toate tranzacțiile pentru a-și valida identitatea. Pentru permisiuni, chei private speciale vor fi date clienților finali selectați. Un client final cu o cheie privată specială pentru permisiuni și cheia lor privată personală va putea semna solicitări speciale.
Pentru o organizare bună și colaborare între membrii echipei, aveam întâlniri scurte la fiecare două ore.
Până aici, totul mergea conform planului, iar direcția echipei era bine stabilită. Un început promițător a oferit echipei un impuls moral și am simțit că obiectivele noastre vor fi ușor de atins. În primele opt ore, echipele 1, 2 și 3 și-au terminat taskurile. Echipa 4 a finalizat implementarea privind protocolul de autentificare. Din acest punct, implementarea celor mai importante componente a fost rezolvată. Echipa trebuie acum să se concentreze asupra integrării tuturor componentelor și să se asigure că funcționează ca un întreg.
Și ca în orice proiect software, odată cu momentul integrării tuturor componentelor ies la iveală problemele. Acesta a fost și cazul soluției noastre, deși totul funcționa conform așteptărilor, tranzacția de la un portofel la altul producea erori la rulare.
După multe ore în care au fost investigate logurile, echipa a reușit să identifice sursa problemei. Eroarea venea din utilizarea unei funcții pseudo-aleatorii în validatorii responsabili de generarea de id-uri unice. Acest lucru a implicat că un singur id de portofel este diferit în fiecare nod al rețelei. Odată identificată cauza, repararea a presupus implementarea unei funcții de hashing personalizate. În acest moment, am conștientizat următorul aspect: comportamentul determinist al validatorilor este deosebit de important în blockchainul nostru. Fiecare nod care are un validator instalat trebuie să producă aceleași ieșiri pentru aceleași intrări, altfel mecanismul de consens va eșua.
Având partea de integrare finalizată, în ultimele opt ore rămase, Grupa 5 trebuia să facă partea de UI iar Grupa 4 partea de adăugarea permisiunilor pentru utilizatori. O soluție tehnică care funcționează prin linia de comandă oferă într-adevăr o dovadă a conceptului, dar o demonstrație a UI-ului este extrem de puternică. După o discuție lungă, echipa a decis să prioritizeze partea de UI și să lase doar doi membri să se concentreze pe sarcinile grupului 4, cu condiția că, dacă funcționalitatea nu este implementată în următoarele două ore, echipa o va șterge din listă. A fost o decizie dificilă de luat, deoarece membrii au fost incredibil de implicați în a face această funcționalitate implementabilă.
Din păcate, două ore mai târziu, partea de permisiuni încă nu a fost finalizată și, din acest motiv, s-a luat decizia de a fi abandonată, astfel încât echipa să se poată concentra pe crearea unei prezentări pentru juriu. Deoarece 75% din juriu erau persoane non-tehnice, a fost important să pregătim o prezentare bună și o interfață de utilizare și mai bună. Pentru a ne asigura că întreaga echipă poate construi o prezentare inteligibilă și care să stârnească interesul, membrii au folosit Microsoft 365 PowerPoint pentru a lucra simultan la prezentare.
În sfârșit, totul este la locul său și, deși am sacrificat o funcționalitate, sacrificiul a meritat, deoarece echipa are o prezentare finalizată și un demo funcțional. Gândindu-ne la acea zi, demonstrația noastră în fața juriului a fost partea cheie a câștigării competiției de către echipa noastră la categoria Technical Achievement.
Nefiind complet mulțumiți cu soluția implementată la eveniment, echipa a luat decizia de a continua explorarea. Următoarele pe listă sunt rețelele Peer-to-Peer - acestea sunt o componentă cheie în construirea unei soluții blockchain descentralizate. Astfel de rețele pot fi create folosind diferiți algoritmi - unii din cei mai utilizați algoritmi sunt tabelele cu hash distribuit Kademlia și protocoalele "gossip" . Alegerea unui algoritm în locul altuia pentru soluția blockchain poate afecta scalabilitatea acestuia, resursele utilizate și stabilitatea rețelei.
După ce am trecut prin toată această experiență, am putea spune că am făcut multe progrese în înțelegerea unor concepte necesare construirii de aplicații blockchain. Totuși, acesta este doar începutul acestei explorări. Un lucru este clar pentru noi - construirea unei soluții profesionale va necesita să înțelegem funcționarea mai multor componente diferite, inclusiv componentele pe care le-am construit de la zero în timpul hackathonului, rețeaua Peer-to-Peer, mecanisme de consens etc. Fără această înțelegere, alegerea oricărei soluții, proiectele ca Hyperledger, Tendermint sau aplicațiile personalizate ne pot duce în multe capcane, mai ales atunci când construiești soluții pentru afaceri reglementate, cum ar fi sectorul bancar, unde securitatea, disponibilitatea ridicată și performanța sunt importante.
de Dan Sabadis , Peter Suciu
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
