Ezerous
3 years ago
58 changed files with 420 additions and 428 deletions
@ -1,12 +1,12 @@ |
|||
{ |
|||
_id: '<the ID of the external identity>', |
|||
id: '<the ID of the external identity>', |
|||
// Auto-generated by OrbitDB
|
|||
_publicKey: '<signing key used to sign OrbitDB entries>', |
|||
publicKey: '<signing key used to sign OrbitDB entries>', |
|||
signatures: { |
|||
//Allows the owner of id to prove they own the private key associated with publicKey
|
|||
id: '<signature of _id signed using publicKey>', |
|||
id: '<signature of id signed using publicKey>', |
|||
//This links the two ids
|
|||
publicKey: '<signature of signatures.id + _publicKey using _id>' |
|||
publicKey: '<signature of signatures.id + publicKey using id>' |
|||
}, |
|||
type: 'orbitdb' |
|||
} |
|||
|
|||
|
Before Width: | Height: | Size: 161 KiB After Width: | Height: | Size: 171 KiB |
|
Before Width: | Height: | Size: 409 KiB After Width: | Height: | Size: 645 KiB |
|
Before Width: | Height: | Size: 639 KiB After Width: | Height: | Size: 737 KiB |
|
Before Width: | Height: | Size: 168 KiB After Width: | Height: | Size: 170 KiB |
|
Before Width: | Height: | Size: 72 KiB |
|
Before Width: | Height: | Size: 99 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
Before Width: | Height: | Size: 974 KiB After Width: | Height: | Size: 1.0 MiB |
@ -1,17 +1,16 @@ |
|||
\chapter*{Abstract} |
|||
\addcontentsline{toc}{chapter}{Abstract} |
|||
|
|||
In recent decades, the rapid growth of the internet has radically changed human |
|||
\textenglish{In recent decades, the rapid growth of the internet has radically changed human |
|||
societies, through a plethora of digital applications, the vast majority of which are offered by cloud computing service providers, following the client-server architecture. |
|||
|
|||
Although this implementation model has proven to be highly functional and has improved significantly over the years, its centralized logic is accompanied by a number of problems. First of all, the user is required to trust his personal data to an external entity. Maintaining full control over them, the latter gains the ability to process, share and censor them, either to serve its own interests or to comply with other authorities in power. In addition, there is no guarantee of data availability, as, at any time, the server can be disconnected indefinitely and for a variety of reasons, such as a cyber attack or a natural disaster. |
|||
Although this implementation model has proven to be highly functional and has improved significantly over the years, its centralized logic is accompanied by a number of problems. First of all, the user is required to trust his personal data to an external entity. Maintaining full control over them, the latter gains the ability to process, share and censor them, either to serve its own interests or to comply with other authorities in power. Furthermore, there is no guarantee of data availability, as, at any time, the server can be disconnected indefinitely and for a variety of reasons, such as a cyber attack or a natural disaster. |
|||
|
|||
These are some of the key factors that have led to the rapid development of a wide range of innovating open source software, that are based on technologiew such as blockchain and peer-to-peer networks. The above, although at a relatively early stage, are already powerful tools for creating distributed and decentralized applications. |
|||
These are some of the key factors that have led to the rapid development of a wide range of innovating open source software, that are based on technologies such as blockchain and peer-to-peer networks. The aforementioned, although at a relatively early stage, are already powerful tools for creating distributed and decentralized applications. |
|||
|
|||
The aim of this thesis is the implementation of an autonomous social platform, |
|||
which, by utilizing decentralization technologies, on the one hand will return the ownership of the staff |
|||
user data, on the other hand, will enable transparent democratic voting processes. These in a context resistant to both faults and attacks, as well as attempts at censorship and falsification. |
|||
The goal of this thesis is the implementation of an autonomous social platform, |
|||
which, by utilizing decentralization technologies, on the one hand will return the ownership of the data to the end user, on the other hand will provide transparent democratic voting processes. These in a context resistant to both faults and attacks, as well as attempts at censorship and falsification. |
|||
|
|||
The developed proof of concept application "Concordia" approaches the above goal by combining Ethereum and IPFS, in order to define a decentralized digital space, both at architectural and political level. |
|||
The developed proof of concept application "Concordia" approaches the above goal by combining Ethereum and IPFS, in order to define a digital space, that is decentralized both at architectural and political level. |
|||
\\[2\baselineskip] |
|||
\textbf {Keywords}: Decentralization, Ethereum, Blockchain, Smart Contract, Decentralized Application, IPFS, OrbitDB, React, Redux, Jenkins |
|||
\textbf {Keywords}: Decentralization, Ethereum, Blockchain, Smart Contract, Decentralized Application, IPFS, OrbitDB, React, Redux, Jenkins} |
|||
@ -0,0 +1,5 @@ |
|||
\section{Τυπογραφικές παραδοχές} \label{section:1-6-typography} |
|||
|
|||
Η συγγραφή του παρόντος εγγράφου έγινε στο ηλεκτρονικό, τυπογραφικό σύστημα \LaTeX. Στο εξής, το παρόν έγγραφο, η εργασία στην οποία αναφέρεται το έγγραφο αυτό, όπως και οποιοδήποτε μέρος της εργασίας αυτής, θα αναφέρονται στο κείμενο ως "διπλωματική" ή "πτυχιακή" ή "εργασία" ή "αναφορά". |
|||
|
|||
Ο πηγαίος κώδικας του παρόντος εγγράφου μπορεί να βρεθεί στο αντίστοιχο αποθετήριο κώδικα της διπλωματικής εργασίας\footnote{Δημόσιο αποθετήριο κώδικα αναφοράς της διπλωματικής \url{https://gitlab.com/ecentrics/thesis-report}.}. |
|||
@ -1,4 +1,4 @@ |
|||
\section{Οργάνωση κεφαλαίων}\label{section:1-6-document-structure} |
|||
\section{Οργάνωση κεφαλαίων}\label{section:1-7-document-structure} |
|||
|
|||
Η παρούσα διπλωματική εργασία οργανώνεται σε κεφάλαια, ενότητες και υποενότητες, όπως αυτά διατυπώνονται στα \hyperref[toc]{Περιεχόμενα}. Πιο συγκεκριμένα: |
|||
|
|||
@ -1,3 +1,15 @@ |
|||
\section{Μεθολογία σχεδίασης} \label{section:3-3.design-methodology} |
|||
\section{Μεθοδολογία σχεδίασης} \label{section:3-3-design-methodology} |
|||
|
|||
% TODO: add Agile stuff etc |
|||
Στον χώρο της τεχνολογίας λογισμικού υπάρχουν διάφορες μεθοδολογίες σχεδίασης οι οποίες έχουν μεταξύ τους κοινά στοιχεία. Αυτό καθιστά δύσκολο τον προσδιορισμό μίας μόνο μεθοδολογίας η οποία ακολουθείται πιστά σε κάθε έργο. Συνήθως, οι ομάδες που αναπτύσσουν το λογισμικό ακολουθούν μία μίξη από διάφορα εργαλεία, όπου αυτά κρίνονται βολικά για τους στόχους της ομάδας. % todo: need reference for this |
|||
|
|||
Κατά την σχεδίαση και την υλοποίηση του κώδικα ακολουθήθηκαν διάφορες τεχνικές και μοτίβα ανάπτυξης. Κατά βάση χρησιμοποιήθηκαν Agile μέθοδοι όπως το Kanban και Scrum και, αργότερα στην ανάπτυξη, το DevOps μοντέλο για διαρκή ενσωμάτωση (Continuous Integration) και διαρκή εγκατάσταση (Continuous Deployment). |
|||
|
|||
Για την παρούσα εργασία, πραγματοποιήθηκε ανάλυση και σχεδιασμός των επιμέρους μονάδων εργασίας (tasks) πριν την έναρξη της διαδικασίας ανάπτυξης του κώδικα. Τα tasks που προδιαγράφηκαν ήταν συνήθως epics\footnote{Τα epics είναι μεγάλες μονάδες εργασίας οι οποίες αφορούν κάποιο βασικό χαρακτηριστικό. Ο διαχωρισμός τους σε επιμέρους tasks αναβάλλεται με σκοπό την καλύτερη κατανόηση των αναγκών τους.} τα οποία αργότερα χωρίστηκαν σε επιμέρους, μικρότερα tasks. Ορίστηκαν επίσης ορόσημα (milestones) τα οποία βοήθησαν ιδιαίτερα στην ιεράρχηση και προτεραιοποίηση των tasks. |
|||
|
|||
Το Kanban είναι μία μέθοδος οργάνωσης έργων και οπτικοποίησης των μονάδων εργασίας (tasks) που απαιτούνται για την ολοκλήρωσή τους. Στο Kanban ορίζονται τα βασικά στάδια της ροής ενός task και χρησιμοποιούνται οπτικά μέσα ώστε να γίνει ιχνηλάτηση τόσο της συνολικής κατάστασης του έργου, όσο και συγκεκριμένων-μεμονωμένων tasks καθώς αυτά προοδεύουν. Για κάθε στάδιο ολοκλήρωσης ορίζεται μία ξεχωριστή ουρά εργασιών (στήλη), για παράδειγμα "σε αναμονή", "σε εξέλιξη", "ολοκληρωμένο". Χρησιμοποιούνται οπτικά σινιάλα (χρώματα, tags και άλλα) για τον διαχωρισμό και την γρήγορη κατανόηση των σημαντικότερων γνωρισμάτων των tasks, για παράδειγμα ξεχωριστό tag για κάθε υπηρεσία στην οποία αναφέρεται το task. Επίσης, ορίζονται όρια στον αριθμό των tasks που μπορούν να είναι ταυτόχρονα σε εξέλιξη. |
|||
|
|||
Μία άλλη Agile μέθοδος είναι το Scrum. Το Scrum χρησιμοποιεί και επεκτείνει το Kanban. Η βασικές διαφορές του με το Kanban είναι ότι στο Scrum υπάρχουν πιο αυστηρές διαδικασίες. Ορίζονται προγραμματιστικοί κύκλοι (sprints) οι οποίοι έχουν συγκεκριμένες ημερομηνίες έναρξης και λήξης και συγκεκριμένους στόχους οι οποίοι αντικατοπτρίζονται σε στόχους ολοκλήρωσης ορισμένων tasks. Οι ρόλοι είναι σαφέστεροι, με κάθε μέλος της ομάδας να αναλαμβάνει διαφορετικές ευθύνες στην οργάνωση και εκτέλεση. Για την διαδικασία ανάπτυξης, υπήρξε πολύ χρήσιμη η χρήση του Scrum σε περιόδους όπου ήταν αναγκαία η ταχύτατη ανάπτυξη καίριων μερών του συστήματος. Λόγω της αυστηρότητας που επιβάλλεται από αυτό, ειδικά σε ό,τι αφορά τις προθεσμίες ολοκλήρωσης των επιμέρους tasks αλλά και του συνολικού sprint. |
|||
|
|||
Καθώς η αναπτυξιακή διαδικασία ωριμάζει και η πλατφόρμα αποτελεί ένα βιώσιμο προϊόν, είναι χρήσιμη η ύπαρξη ενός συστήματος που να διευκολύνει την άμεση δημιουργία και δημοσίευση των νεότερων εκδόσεων. Μερικές εξαιρετικές μέθοδοι για την απρόσκοπτη και αυτοματοποιημένη επίτευξη του στόχου αυτού ορίζονται από το DevOps. Με τον όρο DevOps (development operations) αναφέρεται μία κουλτούρα σχεδίασης και ανάπτυξης λογισμικού που ορίζει τους ρόλους, τις διαδικασίες και τεχνολογίες της με σκοπό την συνεχή δημιουργία αξίας για τους χρήστες. Το DevOps έχει πολύ στενή σχέση με το Agile και αποτελεί την συνέχιση της νοοτροπίας αυτής στον χώρο. |
|||
|
|||
Μία από τις πιο χρήσιμες πτυχές του DevOps, η οποία χρησιμοποιήθηκε στην διπλωματική, είναι το CI/CD το οποίο περιγράφει τις διαδικασίες αυτοματοποίησης των εργασιών ενσωμάτωσης (integration), ελέγχου (testing), παράδοσης (delivery) και εγκατάστασης (deployment) του προϊόντος. Μέσω των διαδικασιών αυτών αφαιρείται η ανάγκη ανθρώπινης αλληλεπίδρασης για την ολοκλήρωση των σταδίων αυτών, ενώ επιτυγχάνεται η διαρκής και απρόσκοπτη διάθεση της τελευταίες έκδοσης της πλατφόρμας στους χρήστες. Ορίζονται επίσης διαδικασίες δημιουργίας περιβάλλοντος ελέγχου (staging deploys) το οποίο αποτελεί σημαντικό βοήθημα στον έγκαιρο εντοπισμό λαθών του κώδικα. |
|||
|
|||
@ -0,0 +1,9 @@ |
|||
\subsection{Αρθρώματα} \label{subsection:4-3-1-software-units} |
|||
|
|||
Σε αυτό το κεφάλαιο θα περιγραφούν με μεγαλύτερη λεπτομέρεια τα αρθρώματα που αναπτύχθηκαν. |
|||
|
|||
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.concordia-shared-unit} |
|||
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.concordia-contracts-unit} |
|||
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-identity-provider-unit} |
|||
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-drizzle-unit} |
|||
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-breeze-unit} |
|||
@ -0,0 +1,5 @@ |
|||
\subsubsection{Άρθρωμα concordia-contracts} \label{subsubsection:4-3-1-concordia-contracts-unit} |
|||
|
|||
Το άρθρωμα αυτό επιτελεί δύο ενέργειες. Αρχικά, είναι το άρθρωμα στο οποίο αναπτύσσονται τα contracts που χρησιμοποιούνται από την εφαρμογή. Το άρθρωμα αυτό αναλαμβάνει τη μεταγλώττιση των contracts από κώδικα γλώσσας Solidity, στην κατάλληλη τελική μορφή JSON. Παρέχονται επίσης σενάρια ενεργειών (scripts) ώστε τα contracts να μεταφορτωθούν σε blockchain καθώς και στην υπηρεσία \hyperref[subsection:4-3-5-concordia-contracts-provider-service]{Concordia Contracts Provider}. Αποτελεί επίσης βιβλιοθήκη η οποία μετά τη μεταγλώττιση και μεταφόρτωση των contracts σε blockchain παρέχει τα contract artifacts. Χρησιμοποιείται από τις υπηρεσίες \hyperref[subsection:4-3-2-concordia-application-service]{Concordia Application} και \hyperref[subsection:4-3-4-concordia-pinner-service]{Concordia Pinner}. |
|||
|
|||
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή τοπικής βιβλιοθήκης με τη χρήση της δυνατότητας yarn workspaces. |
|||
@ -0,0 +1,5 @@ |
|||
\subsubsection{Άρθρωμα concordia-shared} \label{subsubsection:4-3-1-concordia-shared-unit} |
|||
|
|||
Το άρθρωμα concordia-shared αποτελεί μία βιβλιοθήκη χρήσιμων εργαλείων και σταθερών. Εδώ περιέχεται όλο το λογισμικό το οποίο πρέπει ή είναι επιθυμητό να συμπεριφέρεται με τον ίδιο τρόπο συνολικά στο σύστημα, όπως για παράδειγμα μέθοδοι παραμετροποίησης των υπηρεσιών και μέθοδοι καταγραφής (logging). Το άρθρωμα αυτό χρησιμοποιείται από το άρθρωμα \hyperref[subsubsection:4-3-1-concordia-contracts-unit]{concordia-contracts} καθώς και από τις υπηρεσίες \hyperref[subsection:4-3-2-concordia-application-service]{Concordia Application}, \hyperref[subsection:4-3-4-concordia-pinner-service]{Concordia Pinner} και \hyperref[subsection:4-3-5-concordia-contracts-provider-service]{Concordia Contracts Provider}. |
|||
|
|||
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή τοπικής βιβλιοθήκης με τη χρήση της δυνατότητας διαχείρισης μοναδικού αποθετηρίου κώδικα (monorepo) yarn workspaces{\footnote{\url{https://yarnpkg.com/features/workspaces}}}. |
|||
@ -0,0 +1,7 @@ |
|||
\subsubsection{Άρθρωμα breeze} \label{subsubsection:4-3-1-eth-breeze-unit} |
|||
|
|||
Το άρθρωμα αυτό αναπτύχθηκε στα πλαίσια της διπλωματικής εργασίας και αποτελεί μία βιβλιοθήκη περίβλημα (wrapper) της βιβλιοθήκης OrbitDB, η οποία παρέχει ένα Redux store. |
|||
|
|||
Με τη συμπερίληψη του store του αρθρώματος στο κεντρικό Redux store της εφαρμογής, παρέχεται η δυνατότητα εκτέλεσης των λειτουργιών των OrbitDB βάσεων εντός του γενικότερου flow του frontend της εφαρμογής. Έτσι, οι προγραμματιστικές διεπαφές που προσφέρει η Orbit χρησιμοποιούνται πλέον μέσα από actions, reducers και middleware. |
|||
|
|||
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του μητρώου λογισμικού npm (\url{https://www.npmjs.com/package/@ecentrics/breeze}), ενώ το αποθετήριό του βρίσκεται στο GitLab (\url{https://gitlab.com/ecentrics/breeze}). |
|||
@ -0,0 +1,7 @@ |
|||
\subsubsection{Άρθρωμα drizzle} \label{subsubsection:4-3-1-eth-drizzle-unit} |
|||
|
|||
Το άρθρωμα drizzle που χρησιμοποιείται στην υπηρεσία \hyperref[subsection:4-3-2-concordia-application-service]{Concordia Application} είναι μία τροποποιημένη έκδοση της JavaScript βιβλιοθήκης Drizzle (και συγκεκριμένα του @drizzle/store\footnote{\url{https://github.com/trufflesuite/drizzle/tree/develop/packages/store}}), η οποία προσφέρεται από τη σουίτα εργαλείων Truffle. Η τροποποιημένη βιβλιοθήκη αναπτύχθηκε στα πλαίσια της διπλωματικής με στόχο τη διευκόλυνση της χρήσης του Drizle και την επιδιόρθωση προβληματικών σημείων της πρωτότυπης βιβλιοθήκης. |
|||
|
|||
Το άρθρωμα drizzle υλοποιεί τις προγραμματιστικές διεπαφές μέσω των οποίων πραγματοποιείται η επικοινωνία της εφαρμογής με το blockchain. Για την επίτευξη της επικοινωνίας αυτής, η βιβλιοθήκη χρησιμοποιεί τη συλλογή βιβλιοθηκών web3.js η οποία αποτελεί τον πιο διαδεδομένο τρόπο διεπαφής με το blockchain σε αποκεντρωτικές εφαρμογές. Τελικά, παρέχει ένα \hyperref[subsection:4-2-2-2-redux]{Redux} store, το οποίο συμπεριλαμβάνεται στο κεντρικό store της εφαρμογής. |
|||
|
|||
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του μητρώου λογισμικού npm (\url{https://www.npmjs.com/package/@ecentrics/drizzle}), ενώ το αποθετήριό του βρίσκεται στο GitLab (\url{https://gitlab.com/ecentrics/drizzle}). |
|||
@ -0,0 +1,16 @@ |
|||
\subsubsection{Άρθρωμα eth-identity-provider} \label{subsubsection:4-3-1-eth-identity-provider-unit} |
|||
|
|||
Η λειτουργία της βάσης OrbitDB επιτρέπει τη χρήση προσαρμοσμένων orbit-db-identity-provider, οι οποίοι θα δημιουργούν και θα επικυρώνουν |
|||
τα μοναδικά αναγνωριστικά των χρήστών (OrbitDB Identity) βάσει προσαρμοσμένων εξωτερικών αναγνωριστικών (external identifier), όπως παρουσιάζεται στο σχήμα \ref{figure:4-2-4-2-orbit-db-identity}. |
|||
|
|||
Στην περίπτωση της εφαρμογής Concordia είναι χρήσιμο να μπορούν να υπολογιστούν με ντετερμινιστικό τρόπο οι OrbitDB βάσεις δεδομένων του κάθε χρήστη, για λόγους απλότητας και εξοικονόμησης αποθηκευτικού χώρου επί του blockchain. Έτσι, αφού κάθε χρήστης ορίζεται μοναδικά μέσω της διεύθυνσης Ethereum με την οποία εγγράφεται και συνδέεται, αυτή θα πρέπει να αποτελεί και το εξωτερικό αναγνωριστικό στο πεδίο id της OrbitDB Identity. |
|||
|
|||
Για αυτόν το λόγο υλοποιήθηκε το άρθρωμα eth-identity-provider, το οποίο: |
|||
|
|||
\begin{itemize} |
|||
\item Παράγει ένα OrbitDB Identity για τον χρήστη, με id τον συνδυασμο του Ethereum address του και του address του κεντρικού contract της εφαρμογής\footnote{Το δεύτερο εισήχθη για την αποφυγή προβλημάτων σε πολλαπλές αναπτύξεις συμβολαίων.}. Αυτό επιτυγχάνεται με την υπογραφή μίας συναλλαγής με το Ethereum private key του χρήστη, μέσω του MetaMask. |
|||
\item Επικυρώνει τις OrbitDB Identity που απαιτούνται, εξασφαλίζοντας ότι υπογράφηκαν από τα Ethereum private key των κατόχων τους. |
|||
\item Διασφαλίζει ντετερμινιστικές, υπολογίσιμες διευθύνσεις OrbitDB βάσεων για τον κάθε χρήστη. |
|||
\end{itemize} |
|||
|
|||
Το eth-identity-provider γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του μητρώου λογισμικού npm (\url{https://www.npmjs.com/package/@ecentrics/eth-identity-provider}), ενώ το αποθετήριό του βρίσκεται στο GitLab (\url{https://gitlab.com/ecentrics/eth-identity-provider}). |
|||
@ -0,0 +1,45 @@ |
|||
\subsection{Concordia Application} \label{subsection:4-3-2-concordia-application-service} |
|||
|
|||
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
|||
|
|||
\logo{chapter-4/4.3.concordia-logo}{Concordia logo} |
|||
|
|||
Η εφαρμογή Concordia (Concordia Application) εκθέτει τις γραφικές διεπαφές μέσω των οποίων αλληλεπιδρούν οι χρήστες με το σύστημα. Αποτελεί τον δίαυλο επικοινωνίας του τελικού χρήστη με το blockchain και με τη βάση OrbitDB. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο σχήμα \ref{figure:4-3-concordia-application-architecture}. Μέσω της εφαρμογής Concordia οι χρήστες μπορούν: |
|||
|
|||
\begin{itemize} |
|||
\item Να περιηγούνται και να διαβάζουν το περιεχόμενο της πλατφόρμας |
|||
|
|||
\item Να δημιουργήσουν λογαριασμό χρήστη |
|||
|
|||
\item Να δημοσιεύουν και να τροποποιούν προσωπικές τους πληροφορίες, όπως η τοποθεσία και η εικόνα προφίλ |
|||
|
|||
\item Να δημιουργούν θέματα (topics) |
|||
|
|||
\item Να δημιουργούν και να τροποποιούν μηνύματα (posts) |
|||
|
|||
\item Να δημιουργούν ψηφοφορίες (polls), καθώς και να ψηφίζουν σε αυτές (εφόσον έχουν το δικαίωμα) |
|||
|
|||
\item Να υπερψηφίζουν (up-vote) ή να καταψηφίζουν (down-vote) μηνύματα άλλων χρηστών |
|||
\end{itemize} |
|||
|
|||
Η υπηρεσία αποτελείται από κώδικα γραμμένο σε JavaScript, ο οποίος γίνεται διαθέσιμος στους τελικούς χρήστες με τη μορφή εφαρμογής διαδικτύου (web application) μέσω ενός διακομιστή (server). Παρόλο που η υπηρεσία προσφέρει τη γραφική διεπαφή χρήστη μόνο στην αγγλική γλώσσα, έχει παραμετροποιηθεί ώστε να είναι δυνατή η εύκολη μεταγλώττιση της χωρίς την ανάγκη πραγματοποίησης μεγάλων αλλαγών στον κώδικα. |
|||
|
|||
Χρησιμοποιείται η βιβλιοθήκη \hyperref[subsection:4-2-2-1-react]{React} για την οργάνωση και ανάπτυξη των συνθετικών τμημάτων (components) του γραφικού περιβάλλοντος. Για το γραφικό περιβάλλον γίνεται χρήση του framework της Semantic UI\footnote{\url{https://semantic-ui.com/}}. Χρησιμοποιείται η βιβλιοθήκη \hyperref[subsection:4-2-2-2-redux]{Redux} για τη διαχείριση κατάστασης της εφαρμογής (state management), |
|||
καθώς και η βιβλιοθήκη \hyperref[subsection:4-2-2-3-redux-saga]{Redux-Saga} για τη διαχείριση ασύγχρονων παράπλευρων ενεργειών (side-effects) σε ένα σύστημα βασισμένο σε συμβάντα (event-based). Άλλες βιβλιοθήκες χρησιμοποιούνται για διάφορα μέρη της υπηρεσίας, ενώ χρησιμοποιούνται επίσης τα αρθρώματα που περιγράφηκαν προηγουμένως για την επίτευξη διαφορετικών στόχων. Ο πλήρης κατάλογος των βιβλιοθηκών και αρθρωμάτων μπορεί να βρεθεί στον κώδικα της υπηρεσίας στο παράρτημα. % todo: add reference to the appendix containing the code or a link to it in the repo |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png} |
|||
\caption{Αρχιτεκτονική υπηρεσίας Concordia Application} |
|||
\label{figure:4-3-concordia-application-architecture} |
|||
\end{figure} |
|||
|
|||
Για τη λειτουργία της υπηρεσία Concordia Application είναι απαραίτητα τα αντικείμενα (artifacts) που προκύπτουν από τη μεταγλώττιση των contracts και τη μεταφόρτωση/δημοσίευσή τους στο blockchain. Για την εισαγωγή των artifacts στην υπηρεσία έχουν αναπτυχθεί δύο μέθοδοι. |
|||
|
|||
Η πρώτη μέθοδος είναι η μεταγλώττιση και μεταφόρτωση των contracts πριν την παραγωγή του πακέτου λογισμικού της υπηρεσίας για τελική χρήση (production build). Με αυτόν τον τρόπο η υπηρεσία θα έχει πρόσβαση στα artifacts μέσω της βιβλιοθήκης που παράγεται από το άρθρωμα concordia-contracts. Αυτή η μέθοδος έχει το μειονέκτημα ότι το τελικό πακέτο λογισμικού (production build) "δένεται" με όποια συγκεκριμένη έκδοση των contracts είναι διαθέσιμη κατά τη δημιουργία του πακέτου. Αυτό σημαίνει ότι σε ενδεχόμενη ενημέρωση των contracts πρέπει αναγκαστικά να δημιουργηθεί και νέα έκδοση του πακέτου λογισμικού της υπηρεσίας Concordia Application. |
|||
|
|||
Για την αποφυγή του παραπάνω προβλήματος αναπτύχθηκε η δεύτερη μέθοδος προσκόμισης των contract artifacts, η οποία είναι η λήψη τους (download) από μία άλλη τοποθεσία στο διαδίκτυο. Σε αυτή τη μέθοδο, η εφαρμογή κατά την εκκίνησή της πραγματοποιεί ένα HTTP αίτημα (HTTP request) σε διεύθυνση η οποία δίνεται ως μεταβλητή περιβάλλοντος (environment variable). Η απάντηση του αιτήματος αναμένεται να περιέχει τα artifacts ώστε η εφαρμογή να τα χρησιμοποιήσει. |
|||
|
|||
\subsubsection{Διανομή} |
|||
|
|||
Η υπηρεσία Concordia Application πακετάρεται μαζί με τον διακομιστή nginx και γίνεται διαθέσιμη για χρήση ως εικόνα docker (docker image) μέσω του αποθετηρίου εικόνων dockerhub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της εκτέλεσης όπως η διεύθυνση του εξυπηρετητή (host location) της εφαρμογής και οι τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider. |
|||
@ -0,0 +1,16 @@ |
|||
\subsection{Concordia Contracts Migrator} \label{subsection:4-3-3-concordia-contracts-migrator} |
|||
|
|||
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
|||
|
|||
Η υπηρεσία αυτή αποτελείται από ένα εκτελέσιμο πρόγραμμα γραμμής εντολών βασισμένο στο άρθρωμα concordia-contracts που αναλύθηκε σε προηγούμενη υποενότητα (\ref{subsection:4-3-1-software-units}). Το πρόγραμμα, κατά την εκτέλεσή του, μεταγλωττίζει τα contracts και έπειτα τα μεταφορτώνει στο blockchain το οποίο είναι ορισμένο με χρήση μεταβλητών περιβάλλοντος. Τέλος, αν οι κατάλληλες μεταβλητές περιβάλλοντος είναι ορισμένες, το πρόγραμμα μεταφορτώνει τα τελικά artifacts σε αποθετήριο Concordia Contracts Provider. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-concordia-contracts-migrator-architecture}). |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png} |
|||
\caption{Αρχιτεκτονική υπηρεσίας Concordia Contracts Migrator} |
|||
\label{figure:4-3-concordia-contracts-migrator-architecture} |
|||
\end{figure} |
|||
|
|||
\subsubsection{Διανομή} |
|||
|
|||
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν τη διεύθυνση του blockchain και την τοποθεσία της υπηρεσίας Contracts Provider στην οποία το πρόγραμμα θα μεταφορτώσει τα contracts και τα artifacts. |
|||
@ -0,0 +1,21 @@ |
|||
\subsection{Concordia Pinner} \label{subsection:4-3-4-concordia-pinner-service} |
|||
|
|||
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
|||
|
|||
Η υπηρεσία καρφιτσώματος περιεχομένου (Concordia Pinner) αποτελεί μία εφαρμογή τερματικού (temrinal application/cmd application) η οποία στοχεύει στο καρφίτσωμα (pinning) του περιεχομένου που αποθηκεύεται στο IPFS μέσω της βάσης OrbitDB. Η υπηρεσία είναι γραμμένη στη γλώσσα προγραμματισμού JavaScript. Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-3-concordia-pinner-architecture}. |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png} |
|||
\caption{Αρχιτεκτονική υπηρεσίας Concordia Pinner} |
|||
\label{figure:4-3-concordia-pinner-architecture} |
|||
\end{figure} |
|||
|
|||
Η υπηρεσία αυτή υλοποιήθηκε για να εγγυηθεί η διαθεσιμότητα του περιεχομένου του συστήματος που αποθηκεύεται στο IPFS (τίτλοι θεμάτων, περιεχόμενο μηνυμάτων και άλλα). Λόγω του τρόπου λειτουργίας του IPFS, το περιεχόμενο που αναρτούν οι χρήστες πρέπει να καρφιτσώνεται από άλλους χρήστες ή αυτόνομες εφαρμογές, όπως η υπηρεσία Concordia Pinner, ώστε να είναι διαθέσιμο. Αν το περιεχόμενο δεν καρφιτσωθεί, τότε θα είναι διαθέσιμο στους υπόλοιπους χρήστες μόνο από |
|||
τον δημιουργό του, έτσι αν αυτός δεν είναι ενεργός στο δίκτυο, το περιεχόμενο θα είναι αδύνατο να βρεθεί. |
|||
|
|||
Η υπηρεσία συνδέεται στο blockchain από όπου παρακολουθεί την κατάσταση του συστήματος και "ακούει" για νέους χρήστες, θέματα, μηνύματα και ψηφοφορίες. Η υπηρεσία συνδέεται επίσης στο IPFS, έτσι όταν δημιουργηθεί νέο περιεχόμενο στο σύστημα το καρφιτσώνει αυτόματα. Με αυτό τον τρόπο, διατηρώντας την υπηρεσία πάντα διαθέσιμη, για παράδειγμα εκτελώντας τη σε περιβάλλον διακομιστή (server), διαβεβαιώνεται η διαθεσιμότητα του περιεχομένου. |
|||
|
|||
\subsubsection{Διανομή} |
|||
|
|||
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της υπηρεσίας όπως τη διεύθυνση του εξυπηρετητή (host location), τη διεύθυνση του blockchain, τις διαδρομές αποθήκευσης των δεδομένων στο σύστημα και τις τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider. |
|||
@ -0,0 +1,18 @@ |
|||
\subsection{Concordia Contracts Provider} \label{subsection:4-3-5-concordia-contracts-provider-service} |
|||
|
|||
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
|||
|
|||
Η υπηρεσία Contracts Provider αποτελεί μία βοηθητική υπηρεσία η οποία υλοποιεί ένα απλό αποθετήριο για τα contract artifacts. Είναι γραμμένη σε JavaScript και διαθέτει δύο HTTP \textenglish{endpoints}, ένα για τη μεταφόρτωση (upload) των artifacts προς την υπηρεσία και ένα για τη λήψη (download) από την υπηρεσία. Η υπηρεσία υποστηρίζει επίσης την επισύναψη ετικετών στα artifacts, όπως η έκδοση (version) ή το κλαδί ανάπτυξης (branch, για παράδειγμα \textenglish{master/develop}). Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-3-concordia-contracts-provider-architecture}. |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture} |
|||
\caption{Αρχιτεκτονική υπηρεσίας Concordia Contracts Provider} |
|||
\label{figure:4-3-concordia-contracts-provider-architecture} |
|||
\end{figure} |
|||
|
|||
Η υπηρεσία χρησιμοποιείται σε μία προσπάθεια αποσύνδεσης της βασικής εφαρμογής που υλοποιεί η υπηρεσία Concordia Application από μία συγκεκριμένη έκδοση των contracts. Οι λόγοι που αυτό είναι επιθυμητό αναπτύχθηκαν στην περιγραφή της υπηρεσίας Concordia \textenglish{Application} (υποενότητα \ref{subsection:4-3-2-concordia-application-service}). Ωστόσο, η υπηρεσία Contracts Provider αποτελεί σημείο κεντροποίησης του συστήματος, για το λόγο αυτό θεωρείται προσωρινή λύση η οποία θα μπορούσε να αντικατασταθεί από αποκεντρωτικές λύσεις όπως η μεταφόρτωση των artifacts στο IPFS και ο διαμοιρασμός τους από εκεί. |
|||
|
|||
\subsubsection{Διανομή} |
|||
|
|||
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν παραμέτρους της εκτέλεσης, όπως τη διαδρομή αποθήκευσης των μεταφορτωμένων contract artifacts. |
|||
@ -0,0 +1,9 @@ |
|||
\subsection{Ganache} \label{subsection:4-3-6-ganache-service} |
|||
|
|||
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
|||
|
|||
Η συγκεκριμένη υπηρεσία αξιοποιεί την CLI έκδοση του \hyperref[subsection:4-2-3-2-ganache]{Ganache}, δημιουργώντας ένα τοπικό ιδιωτικό Ethereum blockchain για τους σκοπούς ανάπτυξης της εφαρμογής Concordia. |
|||
|
|||
\subsubsection{Διανομή} |
|||
|
|||
Για τη χρήση της υπηρεσίας αυτής αναπτύχθηκε μία νέα εικόνα docker που βασίζεται στην επίσημη εικόνα που διατίθεται από τη σουίτα και προσθέτει μερικές χρήσιμες λειτουργικότητες όπως η δυνατότητα αποκάλυψης των κλειδιών που δημιουργούνται κατά την εκτέλεση. Η υπηρεσία γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Η εικόνα παρέχει τη δυνατότητα τροποποίησης των παραμέτρων εκτέλεσης με χρήση μεταβλητών περιβάλλοντος. Με αυτό τον τρόπο οι χρήστες μπορούν να αλλάξουν τον αριθμό των λογαριασμών που θα δημιουργηθούν, το ποσό του Ether που θα λάβει κάθε λογαριασμός καθώς και άλλες μεταβλητές. |
|||
@ -0,0 +1,9 @@ |
|||
\subsection{Rendezvous Server} \label{subsection:4-3-7-rendezvous-server-service} |
|||
|
|||
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
|||
|
|||
Η υπηρεσία Rendezvous Server παρέχει έναν signalling server, ο οποίος υιοθετεί το \hyperref[subsection:4-2-4-3-libp2p]{Libp2p} πρωτόκολλο μεταφοράς δεδομένων libp2p-webrtc-star. Μέσω αυτού παρέχεται στους ομότιμους χρήστες (peers) η δυνατότητα ανακάλυψης των διευθύνσεων των υπόλοιπων χρηστών στο δίκτυο του IPFS. |
|||
|
|||
\subsubsection{Διανομή} |
|||
|
|||
Η υπηρεσία αυτή είναι διαθέσιμη για χρήση από τους δημιουργούς της τόσο ως εφαρμογή μέσω του αποθετηρίου λογισμικού npm αλλά και ως docker image μέσω του αποθετηρίου εικόνων dockerhub. |
|||
@ -0,0 +1,26 @@ |
|||
\subsection{Διασύνδεση υπηρεσιών} \label{subsection:4-3-8-service-communication} |
|||
|
|||
Στο μοντέλο των μικροϋπηρεσιών, βασικό χαρακτηριστικό είναι η επικοινωνία των ξεχωριστών υπηρεσιών και η ανταλλαγή μηνυμάτων για την επίτευξη των λειτουργικοτήτων του συστήματος. Σε αυτήν την υποενότητα θα αναλυθεί ο τρόπος με τον οποίο οι μικροϋπηρεσίες επικοινωνούν μεταξύ τους, καθώς και η φύση και το περιεχόμενο των μηνυμάτων που ανταλλάσουν. |
|||
|
|||
Στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-communications-graph}) φαίνεται ο γράφος που οπτικοποιεί τα κανάλια επικοινωνίας μεταξύ των μικροϋπηρεσιών, καθώς και τα κανάλια επικοινωνίας των μικροϋπηρεσιών με το blockchain. |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.9\textwidth]{assets/figures/chapter-4/4.3.communications-diagram.png} |
|||
\caption{Γράφος οπτικοποίησης των καναλιών επικοινωνίας των μικροϋπηρεσιών} |
|||
\label{figure:4-3-communications-graph} |
|||
\end{figure} |
|||
|
|||
Εδώ αναλύεται η επικοινωνία κάθε μικροϋπηρεσίας: |
|||
|
|||
\begin{itemize} |
|||
\item \textbf{Contracts Migrator}: Η υπηρεσία εκτελεί αίτημα HTTP κατά την μεταφόρτωση των \textenglish{contracts} στο Ethereum blockchain. Eπίσης, εκτελεί αίτημα HTTP για την μεταφόρτωση των contract artifacts στην υπηρεσία Contracts Provider. |
|||
|
|||
\item \textbf{Concordia Application}: Η υπηρεσία εκτελεί αίτημα HTTP για την λήψη των contract \textenglish{artifacts} από την υπηρεσία Contracts Provider, εκτελεί αιτήματα HTTP για την διενέργεια συναλλαγών στο Ethereum blockchain και, τέλος, δημιουργεί κανάλι επικοινωνίας UDP με την υπηρεσία Rendezvous Server, για την ανακάλυψη ομότιμων χρηστών (peers) στο δίκτυο IPFS. |
|||
|
|||
\item \textbf{Pinner}: Η υπηρεσία εκτελεί αίτημα HTTP για την λήψη των contract artifacts από την υπηρεσία Contracts Provider, εκτελεί αιτήματα HTTP για την ανανέωση και παρατήρηση της κατάστασης του contract στο Ethereum blockchain και τέλος δημιουργεί κανάλι επικοινωνίας UDP με την υπηρεσία Rendezvous Server για την ανακάλυψη peers στο δίκτυο IPFS. |
|||
|
|||
\item \textbf{Rendezvous Server}: Η υπηρεσία διατηρεί ανοιχτά κανάλια επικοινωνίας UDP με τους ομότιμους χρήστες, μέσω των οποίων ενημερώνει την λίστα των διαθέσιμων, ενεργών χρηστών. |
|||
|
|||
\item \textbf{Contracts Provider}: Η υπηρεσία δεν υποκινεί καμία επικοινωνία, παρά μόνο απαντά σε αιτήματα επικοινωνίας από άλλες υπηρεσίες. |
|||
\end{itemize} |
|||
@ -0,0 +1,27 @@ |
|||
\subsection{Ροή πληροφορίας} \label{subsection:4-3-9-data-flow} |
|||
|
|||
Στην παρούσα υποενότητα θα αναλυθεί η ροή της πληροφορίας στο σύστημα. Λόγω των πολλαπλών υπηρεσιών, της κατάτμησης την πληροφορίας και των διαφορετικών σημείων αποθήκευσης της, η ροή της πληροφορίας στο σύστημα ακολουθεί ένα σχετικά περίπλοκο μονοπάτι (σε σχέση με κλασσικές, μονολιθικές, κεντροποιημένες εφαρμογές). |
|||
|
|||
Αρχικά θα γίνει αναφορά στη διαδικασία αποθήκευσης των νέων πληροφοριών. Η μοναδική πηγή παραγωγής δεδομένων στο σύστημα είναι οι χρήστες και κατ' επέκταση η υπηρεσία Concordia Application, εφόσον είναι η μοναδική υπηρεσία με την οποία αυτοί αλληλεπιδρούν. Τα δεδομένα που δημιουργούν οι χρήστες (πληροφορίες χρηστών, τίτλοι θεμάτων και περιεχόμενο μηνυμάτων) κατατέμνονται πριν αποθηκευτούν. Η πληροφορία που εισάγεται στο σύστημα διαχωρίζεται σε δύο μέρη. Στο blockchain αποθηκεύεται ένας δείκτης προς τα δεδομένα, ενώ τα πραγματικά δεδομένα αποθηκεύονται στη βάση OrbitDB. Ο δείκτης εκτός από την άμεση χρησιμότητα στην εύρεση των δεδομένων, παρέχει και την έμμεση λειτουργικότητα της δημιουργίας απαραίτητων μεταδομένων όπως ο αριθμός των θεμάτων στο σύστημα ή των μηνυμάτων σε ένα θέμα. |
|||
|
|||
Από την πλευρά της εύρεση των πληροφοριών στο σύστημα, η ροή είναι ως εξής. Αρχικά, είναι απαραίτητη η αναζήτηση στο blockchain για την εύρεση του δείκτη προς τα δεδομένα. Έπειτα, τα δεδομένα μπορούν να ανακτηθούν μέσω του IPFS από τον εκάστοτε χρήστη ή από κάποιον Pinner. |
|||
|
|||
Τέλος, παρακάτω δίνεται ένα παράδειγμα εισαγωγής πληροφορίας στο σύστημα και έπειτα ανάκτησης της ίδιας πληροφορίας. |
|||
|
|||
Έστω, χρήστης που δημιουργεί νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Μεταδεδομένα της δημιουργίας είναι η διεύθυνση του δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, θα επιστραφεί ο αύξων αριθμός του νέου θέματος. Έπειτα, στην προσωπική βάση OrbitDB του χρήστη και στον πίνακα των θεμάτων θα προστεθεί εγγραφή με αναγνωριστικό τον αύξων αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-3-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία. |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-create-topic-sequence-diagram} |
|||
\caption{Διάγραμμα ακολουθίας δημιουργίας θέματος} |
|||
\label{figure:4-3-data-flow-insert} |
|||
\end{figure} |
|||
|
|||
Έστω, χρήστης που επιθυμεί να διαβάσει το προηγούμενο θέμα. Αρχικά, πρέπει να διαβαστούν τα μεταδεδομένα του συγκεκριμένου θέματος από το blockchain. Έπειτα, διαβάζονται από το blockchain οι αύξοντες αριθμοί των μηνυμάτων που έχουν δημοσιευτεί στο θέμα αυτό. Σε μία τελευταία ανάκτηση από το blockchain διαβάζονται τα μεταδομένα του κάθε μηνύματος. Έπειτα, η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του θέματος και των μηνυμάτων, τα οποία ανακτώνται από τις προσωπικές βάσεις Orbit κάθε χρήστη. Στο σχήμα \ref{figure:4-3-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα. |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-fetch-topic-sequence-diagram} |
|||
\caption{Διάγραμμα ακολουθίας εύρεσης και ανάκτησης θέματος} |
|||
\label{figure:4-3-data-flow-read} |
|||
\end{figure} |
|||
@ -1 +1,20 @@ |
|||
\section{Προβλήματα ανάπτυξης} \label{section:4-5-problems-faced} |
|||
\section{Προβλήματα ανάπτυξης} \label{section:4-4-problems-faced} |
|||
|
|||
Σε αυτήν την ενότητα περιγράφονται οι μεγαλύτερες δυσκολίες που αντιμετωπίστηκαν κατά την ανάπτυξη της πλατφόρμας. Αυτές μπορεί να αναφέρονται σε τεχνικά θέματα, αλλά και στις κοινωνικές και πολιτισμικές συνθήκες που επικρατούν στον χώρο των DApps και των crypto γενικότερα. |
|||
|
|||
Μία από τις μεγαλύτερες τροχοπέδες που καθυστέρησε σοβαρά την ανάπτυξη ήταν η πρωιμότητα των βιβλιοθηκών και των εργαλείων ανάπτυξης. Οι βασικότερες βιβλιοθήκες που χρησιμοποιήθηκαν ήταν σε πρώτο ή δεύτερο πειραματικό στάδιο (alpha και beta phase αντίστοιχα). Συγκεκριμένα: |
|||
|
|||
\begin{itemize} |
|||
\item Όλα τα εργαλεία της σουίτας Truffle ήταν σε alpha phase κατά την ανάπτυξη (κάποια έχουν περάσει σε beta πλέον). |
|||
\item Το IPFS (συγκεκριμένα η βιβλιοθήκη js-ipfs) βρίσκεται ακόμα σε alpha έκδοση. |
|||
\item Η OrbitDB βρίσκεται ακόμα σε alpha phase. |
|||
\item Η γλώσσα των contracts, Solidity, ακόμα δεν έχει βγάλει version 1.0 καθώς αλλάζει διαρκώς με breaking changes\footnote{Από τη σελίδα του πηγαίου κώδικα \url{https://github.com/ethereum/solidity}}. |
|||
\end{itemize} |
|||
|
|||
Αυτή η έλλειψη ώριμων βιβλιοθηκών και εργαλείων προκάλεσε μείζονα προβλήματα. Συχνά έπρεπε να διορθωθούν προβλήματα των βιβλιοθηκών, ή να γίνει δουλειά που να τα παρακάμπτει. Άλλες φορές απαιτήθηκαν πολλές ώρες αποσφαλμάτωσης και δοκιμών ώστε να λειτουργήσουν τα χαρακτηριστικά που υπόσχονταν τα εργαλεία. |
|||
|
|||
Ένα άλλο πρόβλημα ήταν η έλλειψη εργαλείων για ορισμένες διαδικασίες. Δύο βασικά παραδείγματα αυτού αποτελούν πρώτον η έλλειψη υποστήριξης για integration/end-to-end testing των contracts κατά την ανάπτυξη (πλέον υπάρχουν κάποιες λύσεις) και δεύτερον η έλλειψη έτοιμων διαδικασιών, plugins και integrations του Jenkins με τα εργαλεία ανάπτυξης και ειδικά με τη σουίτα Truffle. |
|||
|
|||
Σε παρόμοια κατάσταση βρίσκεται και η γενική συναίνεση σχετικά με τα best practices. Σε διάφορα μέρη της ανάπτυξης παρατηρήθηκε ότι δεν υπήρχε κάποια διαμορφωμένη άποψη στην κοινότητα και κάθε ομάδα ανάπτυξης εφάρμοζε την δική της ιδέα. Αυτό καθιστά δύσκολη την ανάπτυξη από αρχάριους προγραμματιστές χωρίς καθοδήγηση. Ένα άλλο σχετικό πρόβλημα που παρατηρήθηκε είναι ότι στον χώρο υπάρχει ακόμα πολύς θόρυβος, δηλαδή σημαντικό μέρος των πηγών που βρίσκονται στο διαδίκτυο είναι αντικρουόμενες ή σε πολλές περιπτώσεις οι προτάσεις τους απορρίπτονται από την κοινότητα. |
|||
|
|||
Τελικώς, ένα μη τεχνικό ζήτημα που έπρεπε να αντιμετωπιστεί είναι η αβεβαιότητα της βιωσιμότητας, εξέλιξης και αποδοχής της τεχνολογίας blockchain και των εφαρμογών που βασίζονται σε αυτήν από το ευρύ κοινό. Αυτό συναίνεσε αρνητικά, καθώς δημιούργησε μία επιτακτικότητα προσοχής της εμπειρίας του χρήστη (UX), κάτι που φυσιολογικά δεν αποτελεί σημαντικό μέρος της ανάπτυξης ενός PoC. Η ανάγκη για προσοχή του UX πηγάζει από την ανάγκη για συγκράτηση των χρηστών (user retention) με στόχο την αντιστροφή της αβεβαιότητας και την παροχή μίας γνησίως ευχάριστης εμπειρίας. |
|||
|
|||
@ -1,45 +1,44 @@ |
|||
\section{Χαρακτηριστικά που υλοποιήθηκαν} \label{section:4-5-implemented-parts} |
|||
|
|||
Κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί όπως αναλύθηκε στο προηγούμενο κεφάλαιο και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των tasks. Λόγω των καθυστερήσεων αυτών έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των Sprint καθώς και διαπραγματεύσεις της σημαντικότητας των χαρακτηριστικών. Από τον επανασχεδιασμό και τις προσαρμογές αυτές προέκυψαν μερικές αλλαγές στο τελικό σετ των χαρακτηριστικών της πλατφόρμας σε σχέση με ό,τι είχε αρχικά προδιαγραφεί. Τα χαρακτηριστικά που υλοποιήθηκαν τελικά είναι: |
|||
Όπως αναλύθηκε στο προηγούμενο κεφάλαιο, κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των tasks. Λόγω των καθυστερήσεων αυτών έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των Sprint καθώς και διαπραγματεύσεις της σημαντικότητας των χαρακτηριστικών. Από τον επανασχεδιασμό και τις προσαρμογές αυτές προέκυψαν μερικές αλλαγές στο τελικό σετ των χαρακτηριστικών της πλατφόρμας σε σχέση με ό,τι είχε αρχικά προδιαγραφεί. |
|||
|
|||
Τα χαρακτηριστικά και οι αντίστοιχες Λειτουργικές Απαιτήσεις που τελικά υλοποιήθηκαν είναι: |
|||
|
|||
\begin{itemize} |
|||
\item η εγγραφή χρήστη και η δημιουργία των τοπικών βάσεων του όπως περιγράφεται στις \ref{srs:functional-srs-sign-up} \& \ref{srs:functional-srs-create-user-databases} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signup} |
|||
\item η αυτόματη είσοδος χρήστη όπως περιγράφεται στην \ref{srs:functional-srs-sign-in} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signin} |
|||
\item η δημιουργία θέματος και η δημιουργία ψηφοφοριών όπως περιγράφεται στις \ref{srs:functional-srs-create-topic} \& \ref{srs:functional-srs-create-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-topic} |
|||
\item η περιήγηση στα υπάρχοντας θέματα όπως περιγράφεται στην \ref{srs:functional-srs-browse-topics} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-fetch-topic} |
|||
\item η δημοσίευση μηνύματος όπως περιγράφεται στην \ref{srs:functional-srs-create-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-post} |
|||
\item η επεξεργασία μηνύματος όπως περιγράφεται στην \ref{srs:functional-srs-modify-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-modify-post} |
|||
\item η ψήφιση σε ψηφοφορία όπως περιγράφεται στην \ref{srs:functional-srs-vote-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-in-poll} |
|||
\item η ψήφιση σε μηνύματα όπως περιγράφεται στην \ref{srs:functional-srs-vote-posts} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-post} |
|||
\item η διαγραφή των τοπικών δεδομένων όπως περιγράφεται στην \ref{srs:functional-srs-delete-local-data} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-delete-local-data} |
|||
\item Η εγγραφή χρήστη και η δημιουργία των τοπικών βάσεων του, όπως περιγράφονται στις \ref{srs:functional-srs-sign-up} \& \ref{srs:functional-srs-create-user-databases} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signup}. |
|||
\item Η αυτόματη είσοδος χρήστη, όπως περιγράφεται στη \ref{srs:functional-srs-sign-in} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signin}. |
|||
\item Η δημιουργία θέματος και η δημιουργία ψηφοφοριών, όπως περιγράφονται στις \ref{srs:functional-srs-create-topic} \& \ref{srs:functional-srs-create-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-topic}. |
|||
\item Η περιήγηση στα υπάρχοντας θέματα, όπως περιγράφεται στη \ref{srs:functional-srs-browse-community-topics} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-fetch-topic}. |
|||
\item Η δημοσίευση μηνύματος, όπως περιγράφεται στη \ref{srs:functional-srs-create-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-post}. |
|||
\item Η επεξεργασία μηνύματος, όπως περιγράφεται στη \ref{srs:functional-srs-modify-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-modify-post}. |
|||
\item Η ψήφιση σε ψηφοφορία, όπως περιγράφεται στη \ref{srs:functional-srs-vote-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-in-poll}. |
|||
\item Η ψήφιση σε μηνύματα, όπως περιγράφεται στη \ref{srs:functional-srs-vote-posts} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-post}. |
|||
\item Η διαγραφή των τοπικών δεδομένων, όπως περιγράφεται στη \ref{srs:functional-srs-delete-local-data} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-delete-local-data}. |
|||
\end{itemize} |
|||
|
|||
Τα παραπάνω αντιστοιχούν σε 11 ολοκληρωμένες από τις 13 προδιαγεγραμμένες ΛΑ ή πλήρωση 84.6\%, ποσοστό που θεωρείται από τους συγγραφείς επαρκές για την εξαγωγή συμπερασμάτων για τον χώρο των DApps και υπερβάλλων για τα πλαίσια ενός PoC. Στο παράρτημα \ref{screenshots-appendix} παρατίθενται τα στιγμιότυπα οθόνης των υλοποιημένων χαρακτηριστικών. |
|||
Τα παραπάνω αντιστοιχούν σε 11 ολοκληρωμένες από τις 13 προδιαγεγραμμένες ΛΑ ή πλήρωση 84.6\%, ποσοστό που θεωρείται από τους συγγραφείς επαρκές για την εξαγωγή συμπερασμάτων για τον χώρο των DApps και υπερβάλλον για τα πλαίσια ενός PoC. Στο παράρτημα \ref{screenshots-appendix} παρατίθενται τα στιγμιότυπα οθόνης των υλοποιημένων χαρακτηριστικών. |
|||
|
|||
Τα χαρακτηριστικά τα οποία παραλήφθηκαν είναι τα παρακάτω: |
|||
Το χαρακτηριστικό το οποία παραλήφθηκε είναι η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contracts για τα tokens τους, όπως περιγράφονται στις \ref{srs:functional-srs-create-communities} \& \ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community}. |
|||
|
|||
\begin{itemize} |
|||
\item η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contracts για τα tokens τους όπως περιγράφεται στις \ref{srs:functional-srs-create-communities} \& \ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community} |
|||
\end{itemize} |
|||
Όσον αφορά στις Μη Λειτουργικές Απαιτήσεις, η \ref{srs:non-functional-srs-maximum-decentraliztion}, η οποία απαιτεί τη μεγιστοποίηση της αποκέντρωσης της πλατφόρμας, εκπληρώθηκε σε ικανοποιητικό βαθμό, παρότι φαινομενικά το σύστημα περιλαμβάνει σημεία κεντροποίησης για ορισμένες λειτουργίες του. Ενώ, δηλαδή, η διάθεση του frontend της εφαρμογής και των contract artifacts, καθώς και η διαδικασία ανακάλυψης των IPFS peers πραγματοποιούνται μέσω υπηρεσιών που εκτελούνται σε κεντρικούς εξυπηρετητές, στην πραγματικότητα είτε απλά παρέχουν σημαντικές διευκολύνσεις στο περιβάλλον ανάπτυξης, είτε αποτελούν προσωρινά εμπόδια που σχετίζονται με τους τρέχοντες περιορισμούς των υποκείμενων τεχνολογιών. Έτσι, από τη μία πλευρά ο κώδικας της εφαρμογής είναι εφικτό να διατίθεται στους χρήστες με αποκεντρωμένο τρόπο (π.χ. μέσω του ίδιου του IPFS), από την άλλη η παρούσα ανάγκη ύπαρξης των rendezvous server για το peer discovery μένει να επιλυθεί από την προγραμματιστική ομάδα του IPFS. |
|||
|
|||
Τέλος, η ΜΛΑ που αφορά την ελαχιστοποίηση των fees (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε όλη τη διαδικασία σχεδιασμού και υλοποίησης. Η ΜΛΑ σχετικά με την αναβαθμισιμότητα των contracts (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε λόγω του χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. |
|||
Επίσης, η ΜΛΑ που αφορά στην ελαχιστοποίηση των fees (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε ολόκληρες τις διαδικασίες του σχεδιασμού και της υλοποίησης. Αυτό επιτεύχθηκε τόσο με την αποθήκευση των απολύτως απαραίτητων δεδομένων επί του blockchain, όσο και με τη βελτιστοποίηση του κώδικα των smart contracts, ώστε να εκτελείται με τον μικρότερο δυνατό αριθμό υπολογιστικών κύκλων. |
|||
|
|||
Η \ref{srs:non-functional-srs-maximum-decentraliztion} απαιτεί την μεγιστοποίηση της αποκέντρωσης της πλατφόρμας. Παρότι υπάρχουν μέρη τα οποία φαινομενικά έχει παραβιαστεί, όπως η διάθεση της εφαρμογής και των contract artifacts μέσω κεντροποιημένων servers καθώς και η ύπαρξη του rendezvous server, στην πραγματικότητα έχει ακολουθηθεί σε ικανοποιητικό βαθμό. Σχετικά με την εφαρμογή και τα contracts, πάρθηκε η απόφαση να διατεθούν μέσω των αντίστοιχων servers επειδή αυτό προσφέρει μεγάλη ευελιξία και ευκολία στην ανάπτυξη. Θα μπορούσαν εύκολα να διατεθούν μέσω αποκεντρωμένων συστημάτων όπως torrents ή το IPFS και αυτό παραμένει ένα ανοιχτό θέμα. Επίσης ανοιχτό θέμα παραμένει η ανάγκη ύπαρξης του rendezvous server. Λόγω της φύσης του πρωτοκόλλου IPFS και της λειτουργίας που επιτελεί ο server αυτός, είναι αδύνατον να παραληφθεί, ωστόσο είναι ανοιχτό ερευνητικό πεδίο η περαιτέρω αποκέντρωση του πρωτοκόλλου. |
|||
% https://mnot.github.io/avoiding-internet-centralization/draft-nottingham-avoiding-internet-centralization.html#name-necessary-centralization |
|||
Τέλος, η ΜΛΑ που σχετίζεται με την αναβαθμισιμότητα των contracts (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε, λόγω του επιπρόσθετου χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. Ωστόσο, υπάρχουν ήδη πλήρως λειτουργικές μέθοδοι για την επίτευξη αυτού του στόχου, με διαθέσιμα plugin\footnote{\url{https://docs.openzeppelin.com/upgrades-plugins/1.x/}} που μπορούν να ενσωματωθούν απευθείας στις υπάρχοντες ροές εργασίας. |
|||
|
|||
\subsection{Διαφορές σχεδιασμού-υλοποίησης} \label{subsection:4-6-1-design-implementation-differences} |
|||
\subsection{Διαφορές σχεδιασμού-υλοποίησης} \label{subsection:4-5-1-design-implementation-differences} |
|||
|
|||
Σημαντικές διαφορές υπήρξαν επίσης στην διαδικασία υλοποίησης τόσο όσον αφορά τον αριθμό και τις λειτουργίες των διαφορετικών πακέτων λογισμικού όσο και τον χρονοπρογραμματισμό. Προστέθηκαν τρεις νέες υπηρεσίες, η υπηρεσία "Concordia Contracts Provider", ο προσαρμοσμένος IPFS pinner και η ιστοσελίδα "Concordia Guide". |
|||
Σημαντικές διαφορές υπήρξαν επίσης στην διαδικασία υλοποίησης τόσο όσον αφορά στον αριθμό και στις λειτουργίες των διαφορετικών πακέτων λογισμικού όσο και τον χρονοπρογραμματισμό. Προστέθηκαν τρεις νέες υπηρεσίες, η υπηρεσία "Concordia Contracts Provider", ο προσαρμοσμένος IPFS pinner "Concordia Pinner" και η ιστοσελίδα "Concordia Guide". |
|||
|
|||
Η ανάγκη για τα νέα πακέτα λογισμικού προέκυψε κατά την πορεία υλοποίησης της διπλωματικής και προστέθηκαν στον χρονοπρογραμματισμό που είχε γίνει στην αρχή της εργασίας. Στην προσαρμογή αυτή βοήθησαν ιδιαίτερα οι Agile τακτικές που ακολουθήθηκαν και η προσαρμοστικότητα που προσφέρει το Scrum σε μεταβαλλόμενες απαιτήσεις. |
|||
|
|||
Τέλος, κατά την υλοποίηση έγινε γρήγορα αντιληπτή η αξία που προσφέρουν ένα δοκιμαστικό περιβάλλον (staging environment) σε συνδυασμό με ένα CI/CD σύστημα. Για το λόγο αυτό πάρθηκε η απόφαση να μεταφερθεί το sprint που αφορούσε αυτά πολύ νωρίτερα στην διαδικασία υλοποίησης, ώστε να μεγιστοποιηθεί η χρήση του. |
|||
Τέλος, κατά την υλοποίηση έγινε γρήγορα αντιληπτή η αξία που προσφέρουν ένα δοκιμαστικό περιβάλλον (staging environment) σε συνδυασμό με ένα CI/CD σύστημα. Για το λόγο αυτό λήφθηκε η απόφαση να μεταφερθεί το sprint που αφορούσε αυτά πολύ νωρίτερα στην διαδικασία υλοποίησης, ώστε να μεγιστοποιηθεί η χρήση του. |
|||
|
|||
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.6.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα tasks τα οποία υπήρχαν στο χρονοπρογραμματισμό από τη αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία δεν υλοποιήθηκαν. |
|||
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.5.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα tasks τα οποία υπήρχαν στο χρονοπρογραμματισμό από τη αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία δεν υλοποιήθηκαν. |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=\textwidth]{assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png} |
|||
\caption{Διαχωρισμός σε sprints} |
|||
\label{figure:4.6.design-implementation-differences-sprints} |
|||
\label{figure:4.5.design-implementation-differences-sprints} |
|||
\end{figure} |
|||
|
|||
@ -1,4 +0,0 @@ |
|||
\begin{hyphenrules}{english} |
|||
% Custom hyphenations go here |
|||
% \hyphenation{ar-ti-fa-cts} |
|||
\end{hyphenrules} |
|||
Binary file not shown.
Loading…
Reference in new issue