Ένα δένδρο Merkle (Merkle tree ή hash tree) είναι μία δενδρική δομή δεδομένων, η οποία απαρτίζεται από φύλλα (leaf nodes) που περιέχουν hashes από blocks δεδομένων και από άλλους κόμβους (non-leaf nodes) που περιέχουν hashes των hashes των θυγατρικών τους. Στην κορυφή του δένδρου βρίσκεται ο ριζικός κόμβος με το λεγόμενο root hash.\cite{2.3-merkle-tree}
Ένα δένδρο Merkle (Merkle tree ή hash tree) είναι μία δενδρική δομή δεδομένων, η οποία απαρτίζεται α) από φύλλα (leaf nodes) που περιέχουν hash από block δεδομένων και β) από άλλους κόμβους (non-leaf nodes) που περιέχουν τα hash της συνενώσεων των hash των θυγατρικών τους. Στην κορυφή του δένδρου βρίσκεται ο ριζικός κόμβος με το λεγόμενο root hash.
Η πιο συνηθισμένη υλοποίηση είναι το δυαδικό (binary) δένδρο Merkle, το οποίο περιλαμβάνει δύο θυγατρικούς κόμβους (child nodes) κάτω από κάθε γονικό (non-leaf) κόμβο, και είναι αυτό που αναλύεται στη συνέχεια.
@ -10,7 +10,7 @@
\caption{Παράδειγμα δυαδικού δένδρου Merkle}
\end{figure}
Τα Merkle trees επιτρέπουν την αποδοτική και ασφαλή επαλήθευση των περιεχομένων που ανήκουν σε σετ δεδομένων μεγάλου μεγέθους. Η βασική ιδιότητα είναι ότι για κάθε σετ δεδομένων υπάρχει ακριβώς ένα πιθανό δένδρο, το οποίο δε γίνεται να τροποποιηθεί χωρίς να αλλάξει ταυτόχρονα και το root hash.
Τα Merkle tree επιτρέπουν την αποδοτική και ασφαλή επαλήθευση των περιεχομένων που ανήκουν σε σετ δεδομένων μεγάλου μεγέθους. Η βασική ιδιότητα είναι ότι για κάθε σετ δεδομένων υπάρχει ακριβώς ένα πιθανό δένδρο, το οποίο δε γίνεται να τροποποιηθεί χωρίς να αλλάξει ταυτόχρονα και το root hash.
\caption{Αρχιτεκτονικές δικτύων client-server και P2P}
\end{figure}
Τα P2P networks μπορούν να χωριστούν σε δύο κατηγορίες:
Τα P2P network μπορούν να χωριστούν σε δύο κατηγορίες:
\begin{itemize}
\item Στα "Καθαρά" (Pure) P2P networks, στα οποία ισχύει ότι η αφαίρεση ενός τυχαίου κόμβου από το δίκτυο δεν προκαλεί κάποιο πρόβλημα σε αυτό.
\item Στα "Υβριδικά" (Hybrid) P2P networks, στα οποία συμμετέχουν επιπλέον και κεντρικές οντότητες, παρέχοντας απαραίτητα τμήματα των προσφερόμενων υπηρεσιών.
\item Στα "Καθαρά" (Pure) P2P network, στα οποία ισχύει ότι η αφαίρεση ενός τυχαίου κόμβου από το δίκτυο δεν προκαλεί κάποιο πρόβλημα σε αυτό.
\item Στα "Υβριδικά" (Hybrid) P2P network, στα οποία συμμετέχουν επιπλέον και κεντρικές οντότητες, παρέχοντας απαραίτητα τμήματα των προσφερόμενων υπηρεσιών.
\end{itemize}
Από εδώ και στο εξής, εάν δεν αναφέρεται ρητά η κατηγορία κάποιου P2P network, θα εννοείται ότι ανήκει στην πρώτη.
Το blockchain αποτελεί μία διανεμημένη δημόσια σειρά δεδομένων, που διατηρεί έναν αμετάβλητο ως προς το ιστορικό του κατάλογο (immutable ledger) ψηφιακών συναλλαγών (digital transactions) ενός αγαθού (asset), π.χ. ενός νομίσματος (currency ή token). Περιγράφηκε για πρώτη φορά το 2008 από ένα άτομο (ή μία ομάδα ανθρώπων) με το ψευδώνυμο Satoshi Nakamoto, αποτελώντας τη βάση του κρυπτονομίσματος (cryptocurrency) Bitcoin.\cite{2.5-bitcoin}
Δομικό στοιχείο του blockchain είναι το μπλοκ (block), το οποίο περιέχει μία ομάδα έγκυρων συναλλαγών που έχουν κατακερματιστεί και κωδικοποιηθεί σε ένα δένδρο Merkle, το hash του προηγούμενου μπλοκ και μερικά ακόμα μεταδεδομένα (π.χ. nonce, timestamp). Έτσι, κάθε νέο μπλοκ "δείχνει" στο προηγούμενό του μέσω του hash, επιβεβαιώνοντας την ακεραιότητά του, με τα διαδεχόμενα μπλοκ να σχηματίζουν τελικά μία αλυσίδα, μέχρι το αρχικό μπλοκ, το οποίο είναι γνωστό ως το μπλοκ γένεσης (genesis block).\cite{2.5-blockchain}
Δομικό στοιχείο του blockchain είναι το μπλοκ (block), το οποίο περιέχει μία ομάδα έγκυρων συναλλαγών που έχουν κατακερματιστεί και κωδικοποιηθεί σε ένα δένδρο Merkle, το hash του προηγούμενου μπλοκ και μερικά ακόμα μεταδεδομένα (π.χ. nonce, timestamp). Έτσι, κάθε νέο μπλοκ "δείχνει" στο προηγούμενό του μέσω του hash, επιβεβαιώνοντας την ακεραιότητά του, με τα διαδεχόμενα μπλοκ να σχηματίζουν τελικά μία αλυσίδα, μέχρι το αρχικό μπλοκ, το οποίο είναι γνωστό ως το μπλοκ γένεσης (genesis block).
Σε αυτό το κεφάλαιο περιγράφεται η διαδικασία σχεδίασης της εφαρμογής Concordia, από τη σύλληψη της ιδέας και την επιλογή της τεχνολογικής στοίβας, μέχρι τον ορισμό της αρχιτεκτονικής της και τον διαχωρισμό του προγραμματιστικού έργου σε sprints.
Σε αυτό το κεφάλαιο περιγράφεται η διαδικασία σχεδίασης της εφαρμογής Concordia, από τη σύλληψη της ιδέας και την επιλογή της τεχνολογικής στοίβας, μέχρι τον ορισμό της αρχιτεκτονικής της και τον διαχωρισμό του προγραμματιστικού έργου σε Sprint.
Στον χώρο της τεχνολογίας λογισμικού υπάρχουν διάφορες μεθοδολογίες σχεδίασης οι οποίες έχουν μεταξύ τους κοινά στοιχεία. Αυτό καθιστά δύσκολο τον προσδιορισμό μίας μόνο μεθοδολογίας η οποία να ακολουθείται πιστά σε κάθε έργο. Συνήθως, οι ομάδες που αναπτύσσουν το λογισμικό ακολουθούν μία μίξη από διάφορα εργαλεία, όπου αυτά κρίνονται βολικά για τους στόχους της ομάδας. % todo: need reference for this
Στον χώρο της τεχνολογίας λογισμικού υπάρχουν διάφορες μεθοδολογίες σχεδίασης, οι οποίες έχουν μεταξύ τους κοινά στοιχεία. Αυτό καθιστά δύσκολο τον προσδιορισμό μίας μόνο μεθοδολογίας η οποία να ακολουθείται πιστά σε κάθε έργο. Συνήθως, οι ομάδες που αναπτύσσουν το λογισμικό ακολουθούν μία μίξη από διάφορα εργαλεία, όπου αυτά κρίνονται ευνοϊκά για τους στόχους της ομάδας. % todo: need reference for this
Κατά την σχεδίαση και την υλοποίηση του κώδικα ακολουθήθηκαν διάφορες τεχνικές και μοτίβα ανάπτυξης. Κατά βάση χρησιμοποιήθηκαν Agile μέθοδοι όπως το Kanban και το Scrum και αργότερα στην ανάπτυξη το DevOps μοντέλο για διαρκή ενσωμάτωση (Continuous Integration) και διαρκή εγκατάσταση (Continuous Deployment).
Κατά τη σχεδίαση και την υλοποίηση του κώδικα ακολουθήθηκαν διάφορες τεχνικές και μοτίβα ανάπτυξης. Κατά βάση χρησιμοποιήθηκαν Agile μέθοδοι, όπως το Kanban και το Scrum και, αργότερα στην ανάπτυξη, το DevOps μοντέλο για διαρκή ενσωμάτωση (Continuous Integration) και διαρκή εγκατάσταση (Continuous Deployment).
Για την παρούσα εργασία, πραγματοποιήθηκε ανάλυση και σχεδιασμός των επιμέρους μονάδων εργασίας (tasks) πριν την έναρξη της διαδικασίας ανάπτυξης του κώδικα. Τα task που προδιαγράφηκαν ήταν συνήθως epics\footnote{Τα epics είναι μεγάλες μονάδες εργασίας, οι οποίες αφορούν σε κάποιο βασικό χαρακτηριστικό. Ο διαχωρισμός τους σε επιμέρους task αναβάλλεται με σκοπό την καλύτερη κατανόηση των αναγκών τους.} τα οποία αργότερα χωρίστηκαν σε επιμέρους, μικρότερα task. Ορίστηκαν επίσης ορόσημα (milestones) τα οποία βοήθησαν ιδιαίτερα στην ιεράρχηση και προτεραιοποίηση των task.
Για την παρούσα εργασία, πραγματοποιήθηκε ανάλυση και σχεδιασμός των επιμέρους μονάδων εργασίας (tasks) πριν την έναρξη της διαδικασίας ανάπτυξης του κώδικα. Τα task που προδιαγράφηκαν ήταν συνήθως epic\footnote{Τα epic είναι μεγάλες μονάδες εργασίας, οι οποίες αφορούν σε κάποιο βασικό χαρακτηριστικό. Ο διαχωρισμός τους σε επιμέρους task αναβάλλεται με σκοπό την καλύτερη κατανόηση των αναγκών τους.} τα οποία αργότερα χωρίστηκαν σε επιμέρους, μικρότερα task. Ορίστηκαν επίσης ορόσημα (milestones) τα οποία βοήθησαν ιδιαίτερα στην ιεράρχηση και προτεραιοποίηση των task.
Το Kanban είναι μία μέθοδος οργάνωσης έργων και οπτικοποίησης των μονάδων εργασίας που απαιτούνται για την ολοκλήρωσή τους. Στο Kanban ορίζονται τα βασικά στάδια της ροής ενός task και χρησιμοποιούνται οπτικά μέσα, ώστε να γίνει ιχνηλάτηση τόσο της συνολικής κατάστασης του έργου, όσο και συγκεκριμένων-μεμονωμένων task καθώς αυτά προοδεύουν. Για κάθε στάδιο ολοκλήρωσης ορίζεται μία ξεχωριστή ουρά εργασιών (στήλη), για παράδειγμα "σε αναμονή", "σε εξέλιξη", "ολοκληρωμένο". Χρησιμοποιούνται οπτικά σινιάλα (χρώματα, tags και άλλα) για τον διαχωρισμό και την γρήγορη κατανόηση των σημαντικότερων γνωρισμάτων των task, για παράδειγμα ξεχωριστό tag για κάθε υπηρεσία στην οποία αναφέρεται το task. Επίσης, ορίζονται όρια στον αριθμό των task που μπορούν να είναι ταυτόχρονα σε εξέλιξη.
Το Kanban είναι μία μέθοδος οργάνωσης έργων και οπτικοποίησης των μονάδων εργασίας που απαιτούνται για την ολοκλήρωσή τους. Στο Kanban ορίζονται τα βασικά στάδια της ροής ενός task και χρησιμοποιούνται οπτικά μέσα, ώστε να γίνει ιχνηλάτηση τόσο της συνολικής κατάστασης του έργου, όσο και συγκεκριμένων-μεμονωμένων task καθώς αυτά προοδεύουν. Για κάθε στάδιο ολοκλήρωσης ορίζεται μία ξεχωριστή ουρά εργασιών (στήλη), για παράδειγμα "σε αναμονή", "σε εξέλιξη", "ολοκληρωμένο". Χρησιμοποιούνται οπτικά σινιάλα (χρώματα, tags και άλλα) για τον διαχωρισμό και τη γρήγορη κατανόηση των σημαντικότερων γνωρισμάτων των task, για παράδειγμα ξεχωριστό tag για κάθε υπηρεσία στην οποία αναφέρεται το task. Επίσης, ορίζονται όρια στον αριθμό των task που μπορούν να είναι ταυτόχρονα σε εξέλιξη.
Μία άλλη Agile μέθοδος είναι το Scrum. Το Scrum χρησιμοποιεί και επεκτείνει το Kanban. Η βασικές διαφορές του με το Kanban είναι ότι στο Scrum υπάρχουν πιο αυστηρές διαδικασίες. Ορίζονται προγραμματιστικοί κύκλοι (sprints), οι οποίοι έχουν συγκεκριμένες ημερομηνίες έναρξης και λήξης και συγκεκριμένους στόχους, οι οποίοι αντικατοπτρίζονται σε στόχους ολοκλήρωσης ορισμένων task. Οι ρόλοι είναι σαφέστεροι, με κάθε μέλος της ομάδας να αναλαμβάνει διαφορετικές ευθύνες στην οργάνωση και εκτέλεση. Για τη διαδικασία ανάπτυξης, υπήρξε πολύ χρήσιμη η χρήση του Scrum σε περιόδους που ήταν αναγκαία η ταχύτατη ανάπτυξη καίριων μερών του συστήματος. Αυτό λόγω της αυστηρότητας που επιβάλλει, ειδικά σε ό,τι αφορά στις προθεσμίες ολοκλήρωσης τόσο των επιμέρους task, όσο και του συνολικού sprint.
Μία άλλη Agile μέθοδος είναι το Scrum. Το Scrum χρησιμοποιεί και επεκτείνει το Kanban. Η βασικές διαφορές του με το Kanban είναι ότι στο Scrum υπάρχουν πιο αυστηρές διαδικασίες. Ορίζονται προγραμματιστικοί κύκλοι (Sprints), οι οποίοι έχουν συγκεκριμένες ημερομηνίες έναρξης και λήξης και συγκεκριμένους στόχους, οι οποίοι αντικατοπτρίζονται σε στόχους ολοκλήρωσης ορισμένων task. Οι ρόλοι είναι σαφέστεροι, με κάθε μέλος της ομάδας να αναλαμβάνει διαφορετικές ευθύνες στην οργάνωση και εκτέλεση. Για τη διαδικασία ανάπτυξης, αποδείχθηκε πολύ χρήσιμη η χρήση του Scrum σε περιόδους που ήταν αναγκαία η ταχύτατη ανάπτυξη καίριων μερών του συστήματος. Αυτό λόγω της αυστηρότητας που επιβάλλει, ειδικά σε ό,τι αφορά στις προθεσμίες ολοκλήρωσης τόσο των επιμέρους task, όσο και του συνολικού Sprint.
Καθώς η αναπτυξιακή διαδικασία ωριμάζει και η πλατφόρμα μετατρέπεται σε βιώσιμο προϊόν, είναι χρήσιμη η ύπαρξη ενός συστήματος που να διευκολύνει τη δημιουργία και τη δημοσίευση καινούργιων εκδόσεων. Μερικές εξαιρετικές μέθοδοι για την απρόσκοπτη και αυτοματοποιημένη επίτευξη αυτού του στόχου ορίζονται από το DevOps. Με τον όρο DevOps (development operations) αναφέρεται μία κουλτούρα σχεδίασης και ανάπτυξης λογισμικού που ορίζει τους ρόλους, τις διαδικασίες και τις τεχνολογίες της, με σκοπό τη συνεχή δημιουργία αξίας για τους χρήστες. Το DevOps έχει πολύ στενή σχέση με το Agile και αποτελεί τη συνέχιση αυτής της νοοτροπίας στον χώρο.
\item Ο κώδικας του frontend εκτελείται αποκλειστικά στο σύστημα του χρήστη, χωρίς να απαιτείται κάποιος εξυπηρετητής. Δηλαδή, ο χρήστης αρκεί απλά να έχει τον κώδικα αποθηκευμένο στον υπολογιστή του.
\item Ο χρήστης αλληλεπιδρά άμεσα με το UI και το MetaMask. Το MetaMask αποτελεί browser add-on, το οποίο διαχειρίζεται τα ιδιωτικά κλειδιά Ethereum του χρήστη και πραγματοποιεί τις συναλλαγές του τελευταίου με τα smart contract. Στην προκειμένη περίπτωση, περιέχει τα κλειδιά που σχετίζονται αφενός με τη διεύθυνση με την οποία ο χρήστης εγγράφεται στην πλατφόρμα, αφετέρου με τις διευθύνσεις που περιέχουν τα token των κοινοτήτων στις οποίες ανήκει και έχει δικαιώματα ψήφου.
\item Στο frontend εκτελείται στο παρασκήνιο ένας κόμβος για το IPFS. Αυτός συνδέεται με άλλους κατάλληλους κόμβους, διαμοιράζοντας τον κύριο όγκο των δεδομένων της εφαρμογής (π.χ. του περιεχομένου των μηνυμάτων).
\item Τέλος, στο Ethereum blockchain υπάρχουν τόσο τα contracts της εφαρμογής, όσο και τα εξωτερικά contracts που παρέχουν τα token των κοινοτήτων. Τα μεν λειτουργούν ως το σημείο αναφοράς της εφαρμογής, επί του οποίου εκτελούνται οι ενέργειες και αποθηκεύονται οι μεταβλητές που είναι απολύτως απαραίτητες για τη λειτουργία της πλατφόρμας (π.χ. εγγεγραμμένοι χρήστες, δημιουργημένες κοινότητες). Τα δε δημιουργούνται από εξωτερικές οντότητες, οι οποίες ορίζουν κατά τη βούλησή τους τον ακριβή τρόπο δημιουργίας και διαμοιρασμού των token τους στους χρήστες.
\item Τέλος, στο Ethereum blockchain υπάρχουν τόσο τα contract της εφαρμογής, όσο και τα εξωτερικά contracts που παρέχουν τα token των κοινοτήτων. Τα μεν λειτουργούν ως το σημείο αναφοράς της εφαρμογής, επί του οποίου εκτελούνται οι ενέργειες και αποθηκεύονται οι μεταβλητές που είναι απολύτως απαραίτητες για τη λειτουργία της πλατφόρμας (π.χ. εγγεγραμμένοι χρήστες, δημιουργημένες κοινότητες). Τα δε δημιουργούνται από εξωτερικές οντότητες, οι οποίες ορίζουν κατά τη βούλησή τους τον ακριβή τρόπο δημιουργίας και διαμοιρασμού των token τους στους χρήστες.
Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διαρκούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφείς και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερωμένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγή τελμάτων κατά τη συγγραφή του κώδικα.
Το Git είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση (merge) κλαδιών (branches).
Το Git\footnote{\url{https://git-scm.com/}} είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση (merge) κλαδιών (branches).
Για τους σκοπούς της παρούσας διπλωματικής χρησιμοποιήθηκε το μοντέλο GitHub flow.\cite{4.1-github-flow} Το μοντέλο αυτό ορίζει ότι κάθε προγραμματιστής ανοίγει ένα νέο branch για τη ανάπτυξη ενός χαρακτηριστικού της εφαρμογής ή τη διόρθωση ενός μέρους του κώδικα. Έπειτα, όταν η δουλειά έχει ολοκληρωθεί, δημιουργείται ένα αίτημα ένωσης (pull request) με το βασικό κλαδί ανάπτυξης (develop) της εφαρμογής. Η δουλειά υπόκειται σε αξιολόγηση από την υπόλοιπη ομάδα (review) και όταν κριθεί ότι ικανοποιεί τις ανάγκες του έργου, το branch γίνεται merge με το develop. Όταν το develop φτάσει σε ικανό σημείο σταθερότητας και αλλαγών, γίνεται merge με το branch παραγωγής (master). Από το master δημιουργούνται οι τελικές εκδόσεις της εφαρμογής οι οποίες διανέμονται για χρήση στην παραγωγή (production versions), ενώ από το develop δημιουργούνται οι δοκιμαστικές εκδόσεις αιχμής της εφαρμογής οι οποίες χρησιμοποιούνται κατά τον έλεγχο (staging versions).
Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από tasks τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των tasks πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί.
Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από task τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (Sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των task πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί.
Λόγω του πολύ μικρού μεγέθους της ομάδας, το Scrum ακολουθήθηκε ελαστικά. Συγκεκριμένα, δεν ορίστηκε ένας συγκεκριμένος επιμελητής του board αλλά κάθε μέλος της ομάδας φρόντιζε για τον ορισμό και την περιγραφή ενός μέρους των tasks. Τα sprints δεν ήταν συνεχόμενα και δεν είχαν πάντα τον ίδιο χρόνο εκτέλεσης αλλά προσαρμόζονταν ανάλογα με τις εκάστοτε ανάγκες και τον χρόνο των μελών. Κατά βάση, χρησιμοποιήθηκε η μέθοδος Kanban (που χρησιμοποιείται από το ίδιο το Scrum), για την οπτικοποίηση των tasks. Τα tasks χωρίστηκαν κατά κύριο λόγο στις παρακάτω λίστες:
Λόγω του πολύ μικρού μεγέθους της ομάδας, το Scrum ακολουθήθηκε ελαστικά. Συγκεκριμένα, δεν ορίστηκε ένας συγκεκριμένος επιμελητής του board αλλά κάθε μέλος της ομάδας φρόντιζε για τον ορισμό και την περιγραφή ενός μέρους των task. Τα Sprint δεν ήταν συνεχόμενα και δεν είχαν πάντα τον ίδιο χρόνο εκτέλεσης, αλλά προσαρμόζονταν ανάλογα με τις εκάστοτε ανάγκες και τον χρόνο των μελών. Για την οπτικοποίηση των task χρησιμοποιήθηκε κατά βάση η μέθοδος Kanban (που χρησιμοποιείται από το ίδιο το Scrum). Τα task χωρίστηκαν κατά κύριο λόγο στις παρακάτω λίστες:
\begin{itemize}
\item "Αναμονής" (backlog), η οποία περιέχει tasks τα οποία δεν έχουν ακόμα εισαχθεί σε κάποιο sprint
\item "Ενεργού sprint" (sprint/todo), που περιλαμβάνει tasks τα οποία συμμετέχουν στο ενεργό (τρέχον) sprint
\item "Εκτέλεσης" (in progress/doing), η οποία περιλαμβάνει tasks για τα οποία έχει ξεκινήσει η ανάπτυξη από κάποιο μέλος της ομάδας
\item "Ελέγχου και αξιολόγησης" (testing/code review), η οποία περιέχει tasks των οποίων η ανάπτυξη έχει ολοκληρωθεί και βρίσκονται στο στάδιο ελέγχου (testing) ή αναμονής σε pull request
\item "Ολοκλήρωσης" (done), που περιλαμβάνει tasks τα οποία έχουν τελειώσει, δηλαδή των οποίων η ανάπτυξη έχει ολοκληρωθεί και το pull request έχει γίνει merge
\item "Αναμονής" (backlog), η οποία περιέχει task τα οποία δεν έχουν ακόμα εισαχθεί σε κάποιο sprint
\item "Ενεργού Sprint" (sprint/todo), που περιλαμβάνει task τα οποία συμμετέχουν στο ενεργό (τρέχον) Sprint
\item "Εκτέλεσης" (in progress/doing), η οποία περιλαμβάνει task για τα οποία έχει ξεκινήσει η ανάπτυξη από κάποιο μέλος της ομάδας
\item "Ελέγχου και αξιολόγησης" (testing/code review), η οποία περιέχει task των οποίων η ανάπτυξη έχει ολοκληρωθεί και βρίσκονται στο στάδιο ελέγχου (testing) ή αναμονής σε pull request
\item "Ολοκλήρωσης" (done), που περιλαμβάνει task τα οποία έχουν τελειώσει, δηλαδή των οποίων η ανάπτυξη έχει ολοκληρωθεί και το pull request έχει γίνει merge
\end{itemize}
Επίσης, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί από tasks που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή (π.χ. μέχρι τέσσερα tasks στην λίστα εκτέλεσης). Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των tasks από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task.
Επίσης, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί από task που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή (π.χ. μέχρι τέσσερα task στην λίστα εκτέλεσης). Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των task από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task.
Για την υλοποίηση του Scrum χρησιμοποιήθηκε η διαδικτυακή υπηρεσία Trello\footnote{\url{https://trello.com/}}, στιγμιότυπο της οποίας φαίνεται στο παρακάτω σχήμα:
Κατά την διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά το deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην απρόσκοπτη, αυτοματοποιημένη και γρήγορα ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι:
Κατά τη διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά στο deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην ταχεία, απρόσκοπτη και αυτοματοποιημένη ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι:
\begin{itemize}
\item Συνεχής έλεγχος (continuous testing)
@ -40,23 +40,25 @@
\item Συνεχής εγκατάσταση (continuous deployment)
\end{itemize}
Για την υλοποίηση των τακτικών αυτών επιλέχθηκε μετά από εκτενή έρευνα η πλατφόρμα \hyperref[subsection:4-2-1-3-jenkins]{Jenkins}. Το Jenkins συνδυάστηκε με την πλατφόρμα εικονοποίησης \hyperref[subsection:4-2-1-2-docker]{Docker} ώστε να ακολουθηθούν οι τελευταίες ενδεδειγμένες πρακτικές της βιομηχανίας. Έγινε συγγραφή του αρχείου Jenkinsfile το οποίο περιγράφει με κώδικα την ροή εργασιών (pipeline) που πρέπει να ακολουθηθεί μετά από κάθε αλλαγή στον κώδικα. Η εκτέλεση του pipeline πραγματοποιείται αυτόματα από το Jenkins.
Για την υλοποίηση αυτών των τακτικών επιλέχθηκε μετά από εκτενή έρευνα η πλατφόρμα \hyperref[subsection:4-2-1-3-jenkins]{Jenkins}. Το Jenkins συνδυάστηκε με την πλατφόρμα εικονοποίησης \hyperref[subsection:4-2-1-2-docker]{Docker}, ώστε να ακολουθηθούν οι τελευταίες ενδεδειγμένες πρακτικές της βιομηχανίας. Έτσι, έγινε συγγραφή του αρχείου Jenkinsfile, το οποίο περιγράφει με κώδικα τη ροή εργασιών (pipeline) που πρέπει να ακολουθηθεί μετά από κάθε αλλαγή στον κώδικα. Η εκτέλεση του pipeline πραγματοποιείται αυτόματα από το Jenkins.
Το pipeline αποτελείται από στάδια και βήματα τα οποία φαίνονται στο σχήμα \ref{figure:4.1.implementation-methodology-jenkins-pipeline}:
\begin{enumerate}
\item Αρχικά εκτελείται το βήμα "Version", το οποίο συλλέγει στοιχεία σχετικά με την εκτέλεση του pipeline όπως το κλαδί του κώδικα που πυροδότησε τη ροή και ποια από τα πακέτα λογισμικού που περιλαμβάνονται στο git repository περιέχουν αλλαγές.
\item Έπειτα εκτελείται το στάδιο "TEST" το οποίο περιέχει δύο βήματα που εκτελούνται παράλληλα και πραγματοποιούν έλεγχο του κώδικα των πακέτων.
\item Αν το κλαδί πυροδότησης είναι ένα feature branch η ροή σταματά εδώ, ενώ αν πρόκειται για ένα από τα βασικά κλαδιά (master ή develop) τότε η ροή συνεχίζει με το στάδιο "BUILD" στο οποίο εκτελούνται παράλληλα τα βήματα που χτίζουν τα docker images των πακέτων εκείνων τα οποία περιέχουν αλλαγές.
\item Στο στάδιο "PUBLISH", αν το κλαδί πυροδότησης είναι το κύριο κλαδί παραγωγής (master), τότε εκτελούνται παράλληλα βήματα τα οποία δημοσιεύουν τα docker images που δημιουργήθηκαν στο αποθετήριο Dockerhub.
\item Τέλος, εκτελείται το στάδιο "DEPLOY", κατά το οποίο πραγματοποιείται η εγκατάσταση των υπηρεσιών στο ανάλογο περιβάλλον, staging για το κλαδί develop και production για το κλαδί master.
\item Αρχικά εκτελείται το βήμα "Version", το οποίο συλλέγει στοιχεία σχετικά με την εκτέλεση του pipeline, όπως το κλαδί του κώδικα που πυροδότησε τη ροή και τα πακέτα λογισμικού που περιλαμβάνονται στο git repository και περιέχουν αλλαγές.
\item Έπειτα εκτελείται το στάδιο "TEST", το οποίο περιέχει δύο βήματα που εκτελούνται παράλληλα και πραγματοποιούν έλεγχο του κώδικα των πακέτων.
\item Αν το κλαδί πυροδότησης είναι ένα feature branch η ροή σταματά εδώ, ενώ αν πρόκειται για ένα από τα βασικά κλαδιά (master ή develop), τότε η ροή συνεχίζει με το στάδιο "BUILD", στο οποίο εκτελούνται παράλληλα τα βήματα που χτίζουν τα docker image όσων πακέτων περιέχουν αλλαγές.
\item Στο στάδιο "PUBLISH", αν το κλαδί πυροδότησης είναι το κύριο κλαδί παραγωγής (master), τότε εκτελούνται παράλληλα βήματα τα οποία δημοσιεύουν τα docker image που δημιουργήθηκαν στο αποθετήριο Docker Hub.
\item Τέλος, εκτελείται το στάδιο "DEPLOY", κατά το οποίο πραγματοποιείται η εγκατάσταση των υπηρεσιών στο ανάλογο περιβάλλον (staging για το κλαδί develop και production για το κλαδί master).
Με τη χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με τη χρήση του συγκεκριμένου pipeline γίνεται σίγουρο ό,τι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης ο κώδικας ελέγχεται και τα αποτελέσματα των tests είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker images, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλουν τα μέλη της ομάδας σε αυτό.
\vspace{\baselineskip}
Με τη χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με τη χρήση του συγκεκριμένου pipeline γίνεται σίγουρο ό,τι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης ο κώδικας ελέγχεται και τα αποτελέσματα των test είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker image, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλουν τα μέλη της ομάδας σε αυτό.
Το Node.js\footnote{\url{https://nodejs.org/}} είναι ένα περιβάλλον χρόνου εκτέλεσης JavaScript πολλαπλών πλατφορμών, το οποίο εκτελείται στη μηχανή V8\footnote{\url{https://v8.dev/}} και παρέχει τη δυνατότητα εκτέλεσης κώδικα JavaScript εκτός περιηγητών ιστού. Επιτρέπει στους προγραμματιστές να χρησιμοποιούν JavaScript για τη σύνταξη εργαλείων γραμμής εντολών και τη δημιουργία κλιμακωτών διαδικτυακών εφαρμογών (κυρίως για εξυπηρετητές). Έχει αρχιτεκτονική βασισμένη σε συμβάντα (event-driven architecture), με δυνατότητα ασύγχρονης εισόδου/εξόδου (asynchronous I/O).\cite{4.2-node.js}
Το Node.js\footnote{\url{https://nodejs.org/}} είναι ένα περιβάλλον χρόνου εκτέλεσης JavaScript πολλαπλών πλατφορμών, το οποίο εκτελείται στη μηχανή V8\footnote{\url{https://v8.dev/}} και παρέχει τη δυνατότητα εκτέλεσης κώδικα JavaScript εκτός περιηγητών ιστού. Επιτρέπει στους προγραμματιστές να χρησιμοποιούν JavaScript για τη σύνταξη εργαλείων γραμμής εντολών και τη δημιουργία κλιμακωτών διαδικτυακών εφαρμογών (κυρίως για εξυπηρετητές). Έχει αρχιτεκτονική βασισμένη σε συμβάντα (event-driven architecture), με δυνατότητα ασύγχρονης εισόδου/εξόδου (asynchronous I/O).
Ένα από τα σημαντικότερα χαρακτηριστικά του Node.js είναι ο ενσωματωμένος διαχειριστής πακέτων του, ο οποίος ονομάζεται npm. Με τον npm γίνεται εφικτή η εγκατάσταση πακέτων (βιβλιοθηκών) από το μητρώο npm (npm registry\footnote{\url{https://www.npmjs.com/}}), καθώς και η οργάνωση και η διαχείρισή τους στα πλαίσια της ανάπτυξης μίας εφαρμογής που εξαρτάται από αυτά.
Μέσω του Truffle πραγματοποιείται η διαχείριση των έξυπνων συμβολαίων. Αυτή περιλαμβάνει τη δοκιμή, τη σύνδεση και τη μεταγλώττισή τους, καθώς και την ανάπτυξη τους στο blockchain.
Επίσης, το Truffle περιέχει πρόσθετα σχετικά εργαλεία, όπως διαδραστική κονσόλα για άμεση αλληλεπίδραση με τα contracts και εκτελεστής εξωτερικών σεναρίων (external script runner).
Επίσης, το Truffle περιέχει πρόσθετα σχετικά εργαλεία, όπως διαδραστική κονσόλα για άμεση αλληλεπίδραση με τα contract και εκτελεστής εξωτερικών σεναρίων (external script runner).
Έχει το αποθετήριό του στο GitHub\footnote{\url{https://github.com/trufflesuite/truffle}} και διατίθεται μέσω του μητρώου npm\footnote{\url{https://www.npmjs.com/package/truffle}}.
Το άρθρωμα αυτό επιτελεί δύο ενέργειες. Αρχικά, είναι το άρθρωμα στο οποίο αναπτύσσονται τα 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}.
Το παρόν άρθρωμα είναι αυτό στο οποίο αναπτύσσονται τα contract που χρησιμοποιούνται από την εφαρμογή και το οποίο αναλαμβάνει τη μεταγλώττισή τους από κώδικα γλώσσας Solidity στην κατάλληλη τελική μορφή JSON. Παρέχει επίσης σενάρια ενεργειών (scripts), μέσω των οποίων τα contract μεταφορτώνονται στο blockchain, καθώς και στην υπηρεσία \hyperref[subsection:4-3-5-concordia-contracts-provider-service]{Concordia Contracts Provider}. Επιπλέον, το concordia-contracts αποτελεί βιβλιοθήκη, η οποία μετά τη μεταγλώττιση και τη μεταφόρτωση των contract στο blockchain παρέχει τα contract artifact, τα οποία χρησιμοποιούνται από τις υπηρεσίες \hyperref[subsection:4-3-2-concordia-application-service]{Concordia Application} και \hyperref[subsection:4-3-4-concordia-pinner-service]{Concordia Pinner}.
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή τοπικής βιβλιοθήκης με τη χρήση της δυνατότητας yarn workspaces.
Το άρθρωμα 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}.
Το άρθρωμα 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}}}.
Η υπηρεσία αποτελείται από κώδικα γραμμένο σε 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
Χρησιμοποιείται η βιβλιοθήκη \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
Για τη λειτουργία της υπηρεσία Concordia Application είναι απαραίτητα τα αντικείμενα (artifacts) που προκύπτουν από τη μεταγλώττιση των contracts και τη μεταφόρτωση/δημοσίευσή τους στο blockchain. Για την εισαγωγή των artifacts στην υπηρεσία έχουν αναπτυχθεί δύο μέθοδοι.
Για τη λειτουργία της υπηρεσία Concordia Application είναι απαραίτητα τα αντικείμενα (artifacts) που προκύπτουν από τη μεταγλώττιση των contract και τη μεταφόρτωση/δημοσίευσή τους στο blockchain. Για την εισαγωγή των artifact στην υπηρεσία έχουν αναπτυχθεί δύο μέθοδοι.
Η πρώτη μέθοδος είναι η μεταγλώττιση και μεταφόρτωση των contracts πριν την παραγωγή του πακέτου λογισμικού της υπηρεσίας για τελική χρήση (production build). Με αυτόν τον τρόπο η υπηρεσία θα έχει πρόσβαση στα artifacts μέσω της βιβλιοθήκης που παράγεται από το άρθρωμα concordia-contracts. Αυτή η μέθοδος έχει το μειονέκτημα ότι το τελικό πακέτο λογισμικού (production build) "δένεται" με όποια συγκεκριμένη έκδοση των contracts είναι διαθέσιμη κατά τη δημιουργία του πακέτου. Αυτό σημαίνει ότι σε ενδεχόμενη ενημέρωση των contracts πρέπει αναγκαστικά να δημιουργηθεί και νέα έκδοση του πακέτου λογισμικού της υπηρεσίας Concordia Application.
Η πρώτη μέθοδος είναι η μεταγλώττιση και μεταφόρτωση των contract πριν την παραγωγή του πακέτου λογισμικού της υπηρεσίας για τελική χρήση (production build). Με αυτόν τον τρόπο η υπηρεσία θα έχει πρόσβαση στα artifact μέσω της βιβλιοθήκης που παράγεται από το άρθρωμα concordia-contracts. Αυτή η μέθοδος έχει το μειονέκτημα ότι το τελικό πακέτο λογισμικού (production build) "δένεται" με όποια συγκεκριμένη έκδοση των contract είναι διαθέσιμη κατά τη δημιουργία του πακέτου. Αυτό σημαίνει ότι σε ενδεχόμενη ενημέρωση των contract πρέπει αναγκαστικά να δημιουργηθεί και νέα έκδοση του πακέτου λογισμικού της υπηρεσίας Concordia Application.
Για την αποφυγή του παραπάνω προβλήματος αναπτύχθηκε η δεύτερη μέθοδος προσκόμισης των contract artifacts, η οποία είναι η λήψη τους (download) από μία άλλη τοποθεσία στο διαδίκτυο. Σε αυτή τη μέθοδο, η εφαρμογή κατά την εκκίνησή της πραγματοποιεί ένα HTTP αίτημα (HTTP request) σε διεύθυνση η οποία δίνεται ως μεταβλητή περιβάλλοντος (environment variable). Η απάντηση του αιτήματος αναμένεται να περιέχει τα artifacts ώστε η εφαρμογή να τα χρησιμοποιήσει.
Για την αποφυγή του παραπάνω προβλήματος αναπτύχθηκε η δεύτερη μέθοδος προσκόμισης των contract artifact, η οποία είναι η λήψη τους (download) από μία άλλη τοποθεσία στο διαδίκτυο. Σε αυτή τη μέθοδο, η εφαρμογή κατά την εκκίνησή της πραγματοποιεί ένα HTTP αίτημα (HTTP request) σε διεύθυνση η οποία δίνεται ως μεταβλητή περιβάλλοντος (environment variable). Η απάντηση του αιτήματος αναμένεται να περιέχει τα artifact ώστε η εφαρμογή να τα χρησιμοποιήσει.
\subsubsection{Διανομή}
Η υπηρεσία Concordia Application πακετάρεται μαζί με τον διακομιστή nginx και γίνεται διαθέσιμη για χρήση ως εικόνα docker (docker image) μέσω του αποθετηρίου εικόνων dockerhub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της εκτέλεσης όπως η διεύθυνση του εξυπηρετητή (host location) της εφαρμογής και οι τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider.
Η υπηρεσία Concordia Application πακετάρεται μαζί με τον διακομιστή nginx και γίνεται διαθέσιμη για χρήση ως εικόνα Docker (Docker image) μέσω του αποθετηρίου εικόνων Docker Hub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της εκτέλεσης όπως η διεύθυνση του εξυπηρετητή (host location) της εφαρμογής και οι τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider.
Η υπηρεσία αυτή αποτελείται από ένα εκτελέσιμο πρόγραμμα γραμμής εντολών βασισμένο στο άρθρωμα concordia-contracts που αναλύθηκε σε προηγούμενη υποενότητα (\ref{subsection:4-3-1-software-units}). Το πρόγραμμα, κατά την εκτέλεσή του, μεταγλωττίζει τα contracts και έπειτα τα μεταφορτώνει στο blockchain το οποίο είναι ορισμένο με χρήση μεταβλητών περιβάλλοντος. Τέλος, αν οι κατάλληλες μεταβλητές περιβάλλοντος είναι ορισμένες, το πρόγραμμα μεταφορτώνει τα τελικά artifacts σε αποθετήριο Concordia Contracts Provider.
Η υπηρεσία αυτή αποτελείται από ένα εκτελέσιμο πρόγραμμα γραμμής εντολών βασισμένο στο άρθρωμα concordia-contracts που αναλύθηκε σε προηγούμενη υποενότητα (\ref{subsection:4-3-1-software-units}). Το πρόγραμμα, κατά την εκτέλεσή του, μεταγλωττίζει τα contract και έπειτα τα μεταφορτώνει στο blockchain το οποίο είναι ορισμένο με χρήση μεταβλητών περιβάλλοντος. Τέλος, αν οι κατάλληλες μεταβλητές περιβάλλοντος είναι ορισμένες, το πρόγραμμα μεταφορτώνει τα τελικά artifacts σε αποθετήριο Concordia Contracts Provider. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο σχήμα \ref{figure:4-3-concordia-contracts-migrator-architecture}.
Η αρχιτεκτονική της υπηρεσίας φαίνεται στο παρακάτω σχήμα:
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν τη διεύθυνση του blockchain και την τοποθεσία της υπηρεσίας Contracts Provider στην οποία το πρόγραμμα θα μεταφορτώσει τα contracts και τα artifacts.
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως Docker image μέσω του αποθετηρίου εικόνων Docker Hub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν τη διεύθυνση του blockchain και την τοποθεσία της υπηρεσίας Contracts Provider στην οποία το πρόγραμμα θα μεταφορτώσει τα contract και τα artifact.
Η υπηρεσία καρφιτσώματος περιεχομένου (Concordia Pinner) αποτελεί μία εφαρμογή τερματικού (temrinal application/cmd application) η οποία στοχεύει στο καρφίτσωμα (pinning) του περιεχομένου που αποθηκεύεται στο IPFS μέσω της βάσης OrbitDB. Η υπηρεσία είναι γραμμένη στη γλώσσα προγραμματισμού JavaScript.
Η υπηρεσία καρφιτσώματος περιεχομένου (Concordia Pinner) αποτελεί μία εφαρμογή τερματικού (temrinal application/cmd application) η οποία στοχεύει στο καρφίτσωμα (pinning) του περιεχομένου που αποθηκεύεται στο IPFS μέσω της βάσης OrbitDB. Η υπηρεσία είναι γραμμένη στη γλώσσα προγραμματισμού JavaScript, ενώ η αρχιτεκτονική της φαίνεται στο σχήμα \ref{figure:4-3-concordia-pinner-architecture}.
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της υπηρεσίας όπως τη διεύθυνση του εξυπηρετητή (host location), τη διεύθυνση του blockchain, τις διαδρομές αποθήκευσης των δεδομένων στο σύστημα και τις τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider.
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως Docker image μέσω του αποθετηρίου εικόνων Docker Hub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της υπηρεσίας όπως τη διεύθυνση του εξυπηρετητή (host location), τη διεύθυνση του blockchain, τις διαδρομές αποθήκευσης των δεδομένων στο σύστημα και τις τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider.
Η υπηρεσία Contracts Provider αποτελεί μία βοηθητική υπηρεσία η οποία υλοποιεί ένα απλό αποθετήριο για τα contract artifacts. Είναι γραμμένη σε JavaScript και διαθέτει δύο HTTP \textenglish{endpoints}, ένα για τη μεταφόρτωση (upload) των artifacts προς την υπηρεσία και ένα για τη λήψη (download) από την υπηρεσία. Η υπηρεσία υποστηρίζει επίσης την επισύναψη ετικετών στα artifacts, όπως η έκδοση (version) ή το κλαδί ανάπτυξης (branch, για παράδειγμα \textenglish{master/develop}).
Η υπηρεσία 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}.
Η υπηρεσία χρησιμοποιείται σε μία προσπάθεια αποσύνδεσης της βασικής εφαρμογής που υλοποιεί η υπηρεσία Concordia Application από μία συγκεκριμένη έκδοση των contracts. Οι λόγοι που αυτό είναι επιθυμητό αναπτύχθηκαν στην περιγραφή της υπηρεσίας Concordia \textenglish{Application} (υποενότητα \ref{subsection:4-3-2-concordia-application-service}). Ωστόσο, η υπηρεσία Contracts Provider αποτελεί σημείο κεντροποίησης του συστήματος, για το λόγο αυτό θεωρείται προσωρινή λύση η οποία θα μπορούσε να αντικατασταθεί από αποκεντρωτικές λύσεις όπως η μεταφόρτωση των artifacts στο IPFS και ο διαμοιρασμός τους από εκεί.
Η υπηρεσία χρησιμοποιείται σε μία προσπάθεια αποσύνδεσης της βασικής εφαρμογής που υλοποιεί η υπηρεσία Concordia Application από μία συγκεκριμένη έκδοση των contract. Οι λόγοι που αυτό είναι επιθυμητό αναπτύχθηκαν στην περιγραφή της υπηρεσίας Concordia \textenglish{Application} (υποενότητα \ref{subsection:4-3-2-concordia-application-service}). Ωστόσο, η υπηρεσία Contracts Provider αποτελεί σημείο κεντροποίησης του συστήματος, για το λόγο αυτό θεωρείται προσωρινή λύση, η οποία θα μπορούσε να αντικατασταθεί από αποκεντρωτικές λύσεις όπως η μεταφόρτωση των artifacts στο IPFS και ο διαμοιρασμός τους από εκεί.
\subsubsection{Διανομή}
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν παραμέτρους της εκτέλεσης, όπως τη διαδρομή αποθήκευσης των μεταφορτωμένων contract artifacts.
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως Docker image μέσω του αποθετηρίου εικόνων Docker Hub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν παραμέτρους της εκτέλεσης, όπως τη διαδρομή αποθήκευσης των μεταφορτωμένων contract artifacts.
Για τη χρήση της υπηρεσίας αυτής αναπτύχθηκε μία νέα εικόνα docker που βασίζεται στην επίσημη εικόνα που διατίθεται από τη σουίτα και προσθέτει μερικές χρήσιμες λειτουργικότητες όπως η δυνατότητα αποκάλυψης των κλειδιών που δημιουργούνται κατά την εκτέλεση. Η υπηρεσία γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Η εικόνα παρέχει τη δυνατότητα τροποποίησης των παραμέτρων εκτέλεσης με χρήση μεταβλητών περιβάλλοντος. Με αυτό τον τρόπο οι χρήστες μπορούν να αλλάξουν τον αριθμό των λογαριασμών που θα δημιουργηθούν, το ποσό του Ether που θα λάβει κάθε λογαριασμός καθώς και άλλες μεταβλητές.
Για τη χρήση της υπηρεσίας αυτής αναπτύχθηκε μία νέα εικόνα Docker που βασίζεται στην επίσημη εικόνα που διατίθεται από τη σουίτα και προσθέτει μερικές χρήσιμες λειτουργίες, όπως η δυνατότητα αποκάλυψης των κλειδιών που δημιουργούνται κατά την εκτέλεση. Η υπηρεσία γίνεται διαθέσιμη για χρήση ως Docker image μέσω του αποθετηρίου εικόνων Docker Hub. Η εικόνα παρέχει τη δυνατότητα τροποποίησης των παραμέτρων εκτέλεσης με χρήση μεταβλητών περιβάλλοντος. Με αυτόν τον τρόπο οι προγραμματιστές μπορούν να αλλάξουν τον αριθμό των λογαριασμών που θα δημιουργηθούν, το ποσό του ETH που θα λάβει κάθε λογαριασμός, καθώς και άλλες μεταβλητές.
Η υπηρεσία αυτή είναι διαθέσιμη για χρήση από τους δημιουργούς της τόσο ως εφαρμογή μέσω του αποθετηρίου λογισμικού npm αλλά και ως docker image μέσω του αποθετηρίου εικόνων dockerhub.
Η υπηρεσία αυτή είναι διαθέσιμη για χρήση από τους δημιουργούς της τόσο ως εφαρμογή μέσω του αποθετηρίου λογισμικού npm αλλά και ως Docker image μέσω του αποθετηρίου εικόνων Docker Hub.
Στην παρούσα υποενότητα θα αναλυθεί η ροή της πληροφορίας στο σύστημα. Λόγω των πολλαπλών υπηρεσιών, της κατάτμησης την πληροφορίας και των διαφορετικών σημείων αποθήκευσης της, η ροή της πληροφορίας στο σύστημα ακολουθεί ένα σχετικά περίπλοκο μονοπάτι (σε σχέση με κλασσικές, μονολιθικές, κεντροποιημένες εφαρμογές).
Στην παρούσα υποενότητα αναλύεται η ροή της πληροφορίας στο σύστημα. Λόγω των πολλαπλών υπηρεσιών, της κατάτμησης την πληροφορίας και των διαφορετικών σημείων αποθήκευσης της, η ροή της πληροφορίας στο σύστημα ακολουθεί ένα σχετικά περίπλοκο μονοπάτι (σε σχέση με κλασσικές, μονολιθικές, κεντροποιημένες εφαρμογές).
Αρχικά θα γίνει αναφορά στη διαδικασία αποθήκευσης των νέων πληροφοριών. Η μοναδική πηγή παραγωγής δεδομένων στο σύστημα είναι οι χρήστες και κατ' επέκταση η υπηρεσία Concordia Application, εφόσον είναι η μοναδική υπηρεσία με την οποία αυτοί αλληλεπιδρούν. Τα δεδομένα που δημιουργούν οι χρήστες (πληροφορίες χρηστών, τίτλοι θεμάτων και περιεχόμενο μηνυμάτων) κατατέμνονται πριν αποθηκευτούν. Η πληροφορία που εισάγεται στο σύστημα διαχωρίζεται σε δύο μέρη. Στο blockchain αποθηκεύεται ένας δείκτης προς τα δεδομένα, ενώ τα πραγματικά δεδομένα αποθηκεύονται στη βάση OrbitDB. Ο δείκτης εκτός από την άμεση χρησιμότητα στην εύρεση των δεδομένων, παρέχει και την έμμεση λειτουργικότητα της δημιουργίας απαραίτητων μεταδομένων όπως ο αριθμός των θεμάτων στο σύστημα ή των μηνυμάτων σε ένα θέμα.
Αρχικά θα γίνει αναφορά στη διαδικασία αποθήκευσης των νέων πληροφοριών. Η μοναδική πηγή παραγωγής δεδομένων στο σύστημα είναι οι χρήστες και κατ' επέκταση η υπηρεσία Concordia Application, εφόσον είναι η μοναδική υπηρεσία με την οποία αυτοί αλληλεπιδρούν. Τα δεδομένα που δημιουργούν οι χρήστες (πληροφορίες χρηστών, τίτλοι θεμάτων και περιεχόμενο μηνυμάτων) κατατέμνονται πριν αποθηκευτούν. Η πληροφορία που εισάγεται στο σύστημα διαχωρίζεται σε δύο μέρη. Στο blockchain αποθηκεύεται ένας δείκτης προς τα δεδομένα, ενώ τα πραγματικά δεδομένα αποθηκεύονται στη βάση OrbitDB. Ο δείκτης, εκτός από την άμεση χρησιμότητα στην εύρεση των δεδομένων, παρέχει και την έμμεση λειτουργικότητα της δημιουργίας απαραίτητων μεταδομένων όπως ο αριθμός των θεμάτων στο σύστημα ή των μηνυμάτων σε ένα θέμα.
Από την πλευρά της εύρεση των πληροφοριών στο σύστημα, η ροή είναι ως εξής. Αρχικά, είναι απαραίτητη η αναζήτηση στο blockchain για την εύρεση του δείκτη προς τα δεδομένα. Έπειτα, τα δεδομένα μπορούν να ανακτηθούν μέσω του IPFS από τον εκάστοτε χρήστη ή από κάποιον Pinner.
Από την πλευρά της εύρεσης των πληροφοριών στο σύστημα, η ροή έχει ως εξής. Αρχικά, είναι απαραίτητη η αναζήτηση στο blockchain για την εύρεση του δείκτη προς τα δεδομένα. Έπειτα, τα δεδομένα μπορούν να ανακτηθούν μέσω του IPFS είτε από τους χρήστες που τα διαθέτουν, είτε από κάποιον pinner.
Τέλος, παρακάτω δίνεται ένα παράδειγμα εισαγωγής πληροφορίας στο σύστημα και έπειτα ανάκτησης της ίδιας πληροφορίας.
Στη συνέχεια δίνεται ένα παράδειγμα εισαγωγής πληροφορίας στο σύστημα και ανάκτησης της ίδιας πληροφορίας από αυτό.
Έστω, χρήστης που δημιουργεί νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Μεταδεδομένα της δημιουργίας είναι η διεύθυνση του δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, θα επιστραφεί ο αύξων αριθμός του νέου θέματος. Έπειτα, στην προσωπική βάση OrbitDB του χρήστη και στον πίνακα των θεμάτων θα προστεθεί εγγραφή με αναγνωριστικό τον αύξων αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-3-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία.
Έστω, λοιπόν, ένας χρήστης που δημιουργεί ένα νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Τα μεταδεδομένα της δημιουργίας είναι η διεύθυνση του δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, επιστρέφεται ο αύξοντας αριθμός του νέου θέματος. Έπειτα, στην προσωπική OrbitDB βάση του χρήστη και στον πίνακα των θεμάτων προστίθεται μία εγγραφή με αναγνωριστικό τον αύξοντα αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-3-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία.
\vspace{\baselineskip}
%TODO: Doesn't this figure also need a "New post ID" for topic's first post?
Έστω, χρήστης που επιθυμεί να διαβάσει το προηγούμενο θέμα. Αρχικά, πρέπει να διαβαστούν τα μεταδεδομένα του συγκεκριμένου θέματος από το blockchain. Έπειτα, διαβάζονται από το blockchain οι αύξοντες αριθμοί των μηνυμάτων που έχουν δημοσιευτεί στο θέμα αυτό. Σε μία τελευταία ανάκτηση από το blockchain διαβάζονται τα μεταδομένα του κάθε μηνύματος. Έπειτα, η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του θέματος και των μηνυμάτων, τα οποία ανακτώνται από τις προσωπικές βάσεις Orbit κάθε χρήστη. Στο σχήμα \ref{figure:4-3-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα.
Έστω τώρα ένας χρήστης που επιθυμεί να διαβάσει το προηγούμενο θέμα. Αρχικά, πρέπει να διαβαστούν τα μεταδεδομένα του συγκεκριμένου θέματος από το blockchain. Έπειτα, διαβάζονται από το blockchain οι αύξοντες αριθμοί των μηνυμάτων που έχουν δημοσιευτεί στο θέμα αυτό. Σε μία τελευταία ανάκτηση από το blockchain διαβάζονται τα μεταδομένα του κάθε μηνύματος. Έπειτα, η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του θέματος και των μηνυμάτων, τα οποία ανακτώνται από τις προσωπικές OrbitDB βάσεις του κάθε χρήστη. Στο σχήμα \ref{figure:4-3-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα.
\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}}.
\item Η γλώσσα των contract, 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.
Ένα άλλο πρόβλημα ήταν η έλλειψη εργαλείων για ορισμένες διαδικασίες. Δύο βασικά παραδείγματα αυτού αποτελούν πρώτον η έλλειψη υποστήριξης για integration/end-to-end testing των contract κατά την ανάπτυξη (πλέον υπάρχουν κάποιες λύσεις) και δεύτερον η έλλειψη έτοιμων διαδικασιών, plugin και integration του Jenkins με τα εργαλεία ανάπτυξης και ειδικά με τη σουίτα Truffle.
Σε παρόμοια κατάσταση βρίσκεται και η γενική συναίνεση σχετικά με τα best practices. Σε διάφορα μέρη της ανάπτυξης παρατηρήθηκε ότι δεν υπήρχε κάποια διαμορφωμένη άποψη στην κοινότητα και κάθε ομάδα ανάπτυξης εφάρμοζε την δική της ιδέα. Αυτό καθιστά δύσκολη την ανάπτυξη από αρχάριους προγραμματιστές χωρίς καθοδήγηση. Ένα άλλο σχετικό πρόβλημα που παρατηρήθηκε είναι ότι στον χώρο υπάρχει ακόμα πολύς θόρυβος, δηλαδή σημαντικό μέρος των πηγών που βρίσκονται στο διαδίκτυο είναι αντικρουόμενες ή σε πολλές περιπτώσεις οι προτάσεις τους απορρίπτονται από την κοινότητα.
Σε παρόμοια κατάσταση βρίσκεται και η γενική συναίνεση σχετικά με τα best practices. Σε διάφορα μέρη της ανάπτυξης παρατηρήθηκε ότι δεν υπήρχε κάποια διαμορφωμένη άποψη στην κοινότητα και κάθε ομάδα ανάπτυξης εφάρμοζε την δική της ιδέα. Αυτό καθιστά δύσκολη την ανάπτυξη από αρχάριους προγραμματιστές χωρίς καθοδήγηση. Ένα άλλο σχετικό πρόβλημα που παρατηρήθηκε είναι ότι στον χώρο υπάρχει ακόμα πολύς θόρυβος, δηλαδή σημαντικό μέρος των πηγών που βρίσκονται στο διαδίκτυο είναι αντικρουόμενες ή, σε πολλές περιπτώσεις, οι προτάσεις τους απορρίπτονται από την κοινότητα.
Τελικώς, ένα μη τεχνικό ζήτημα που έπρεπε να αντιμετωπιστεί είναι η αβεβαιότητα της βιωσιμότητας, εξέλιξης και αποδοχής της τεχνολογίας blockchain και των εφαρμογών που βασίζονται σε αυτήν από το ευρύ κοινό. Αυτό συναίνεσε αρνητικά, καθώς δημιούργησε μία επιτακτικότητα προσοχής της εμπειρίας του χρήστη (UX), κάτι που φυσιολογικά δεν αποτελεί σημαντικό μέρος της ανάπτυξης ενός PoC. Η ανάγκη για προσοχή του UX πηγάζει από την ανάγκη για συγκράτηση των χρηστών (user retention) με στόχο την αντιστροφή της αβεβαιότητας και την παροχή μίας γνησίως ευχάριστης εμπειρίας.
Τέλος, ένα μη τεχνικό ζήτημα που έπρεπε να αντιμετωπιστεί είναι η αβεβαιότητα της βιωσιμότητας, της εξέλιξης και της αποδοχής της τεχνολογίας blockchain και των εφαρμογών που βασίζονται σε αυτήν από το ευρύ κοινό. Αυτό συναίνεσε αρνητικά, καθώς δημιούργησε μία επιτακτικότητα προσοχής της εμπειρίας του χρήστη (UX), κάτι που φυσιολογικά δεν αποτελεί σημαντικό μέρος της ανάπτυξης ενός PoC. Η ανάγκη για προσοχή του UX πηγάζει από την ανάγκη για συγκράτηση των χρηστών (user retention), με στόχο την αντιστροφή της αβεβαιότητας και την παροχή μίας γνησίως ευχάριστης εμπειρίας.
Όπως αναλύθηκε στο προηγούμενο κεφάλαιο, κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των tasks. Λόγω των καθυστερήσεων αυτών έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των Sprint καθώς και διαπραγματεύσεις της σημαντικότητας των χαρακτηριστικών. Από τον επανασχεδιασμό και τις προσαρμογές αυτές προέκυψαν μερικές αλλαγές στο τελικό σετ των χαρακτηριστικών της πλατφόρμας σε σχέση με ό,τι είχε αρχικά προδιαγραφεί.
Όπως αναλύθηκε στην προηγούμενη ενότητα, κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των task. Εξαιτίας αυτών των καθυστερήσεων έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των 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-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-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}.
@ -16,29 +16,31 @@
\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. Στο \hyperref[{appendix-a}]{παράρτημα Αʹ} παρατίθενται τα στιγμιότυπα οθόνης των υλοποιημένων χαρακτηριστικών.
Τα παραπάνω αντιστοιχούν σε 11 ολοκληρωμένες από τις 13 προδιαγεγραμμένες ΛΑ ή πλήρωση 84.6\%, ποσοστό που θεωρείται από τους συγγραφείς επαρκές για την εξαγωγή συμπερασμάτων για τον χώρο των DApp και υπερβάλλον για τα πλαίσια ενός PoC. Στο \hyperref[{appendix-a}]{παράρτημα Αʹ} περιλαμβάνονται στιγμιότυπα οθόνης τα οποία αντιστοιχίζονται με τις ΛΑ των υλοποιήμενων χαρακτηριστικών.
Το χαρακτηριστικό το οποία παραλήφθηκε είναι η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contracts για τα tokens τους, όπως περιγράφονται στις \ref{srs:functional-srs-create-communities}\&\ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community}.
Το χαρακτηριστικά τά οποία παραλήφθηκαν είναι η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contract για τα token τους, όπως περιγράφονται στις \ref{srs:functional-srs-create-communities}\&\ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community}.
Όσον αφορά στις Μη Λειτουργικές Απαιτήσεις, η \ref{srs:non-functional-srs-maximum-decentraliztion}, η οποία απαιτεί τη μεγιστοποίηση της αποκέντρωσης της πλατφόρμας, εκπληρώθηκε σε ικανοποιητικό βαθμό, παρότι φαινομενικά το σύστημα περιλαμβάνει σημεία κεντροποίησης για ορισμένες λειτουργίες του. Ενώ, δηλαδή, η διάθεση του frontend της εφαρμογής και των contract artifacts, καθώς και η διαδικασία ανακάλυψης των IPFS peers πραγματοποιούνται μέσω υπηρεσιών που εκτελούνται σε κεντρικούς εξυπηρετητές, στην πραγματικότητα είτε απλά παρέχουν σημαντικές διευκολύνσεις στο περιβάλλον ανάπτυξης, είτε αποτελούν προσωρινά εμπόδια που σχετίζονται με τους τρέχοντες περιορισμούς των υποκείμενων τεχνολογιών. Έτσι, από τη μία πλευρά ο κώδικας της εφαρμογής είναι εφικτό να διατίθεται στους χρήστες με αποκεντρωμένο τρόπο (π.χ. μέσω του ίδιου του IPFS), από την άλλη η παρούσα ανάγκη ύπαρξης των rendezvous server για το peer discovery μένει να επιλυθεί από την προγραμματιστική ομάδα του IPFS.
Όσον αφορά στις Μη Λειτουργικές Απαιτήσεις, η \ref{srs:non-functional-srs-maximum-decentraliztion}, η οποία απαιτεί τη μεγιστοποίηση της αποκέντρωσης της πλατφόρμας, εκπληρώθηκε σε ικανοποιητικό βαθμό, παρότι φαινομενικά το σύστημα περιλαμβάνει σημεία κεντροποίησης για ορισμένες λειτουργίες του. Ενώ, δηλαδή, η διάθεση του frontend της εφαρμογής και των contract artifact, καθώς και η διαδικασία ανακάλυψης των IPFS peer πραγματοποιούνται μέσω υπηρεσιών που εκτελούνται σε κεντρικούς εξυπηρετητές, στην πραγματικότητα είτε απλά παρέχουν σημαντικές διευκολύνσεις στο περιβάλλον ανάπτυξης, είτε αποτελούν προσωρινά εμπόδια που σχετίζονται με τους τρέχοντες περιορισμούς των υποκείμενων τεχνολογιών. Έτσι, από τη μία πλευρά ο κώδικας της εφαρμογής είναι εφικτό να διατίθεται στους χρήστες με αποκεντρωμένο τρόπο (π.χ. μέσω του ίδιου του IPFS), από την άλλη η παρούσα ανάγκη ύπαρξης των rendezvous server για το peer discovery μένει να επιλυθεί από την προγραμματιστική ομάδα του IPFS.
Επίσης, η ΜΛΑ που αφορά στην ελαχιστοποίηση των fees (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε ολόκληρες τις διαδικασίες του σχεδιασμού και της υλοποίησης. Αυτό επιτεύχθηκε τόσο με την αποθήκευση των απολύτως απαραίτητων δεδομένων επί του blockchain, όσο και με τη βελτιστοποίηση του κώδικα των smart contracts, ώστε να εκτελείται με τον μικρότερο δυνατό αριθμό υπολογιστικών κύκλων.
Επίσης, η ΜΛΑ που αφορά στην ελαχιστοποίηση των fee (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε ολόκληρες τις διαδικασίες του σχεδιασμού και της υλοποίησης. Αυτό επιτεύχθηκε τόσο με την αποθήκευση των απολύτως απαραίτητων δεδομένων επί του blockchain, όσο και με τη βελτιστοποίηση του κώδικα των smart contract, ώστε να εκτελείται με τον μικρότερο δυνατό αριθμό υπολογιστικών κύκλων.
Τέλος, η ΜΛΑ που σχετίζεται με την αναβαθμισιμότητα των contracts (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε, λόγω του επιπρόσθετου χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. Ωστόσο, υπάρχουν ήδη πλήρως λειτουργικές μέθοδοι για την επίτευξη αυτού του στόχου, με διαθέσιμα plugin\footnote{\url{https://docs.openzeppelin.com/upgrades-plugins/1.x/}} που μπορούν να ενσωματωθούν απευθείας στις υπάρχοντες ροές εργασίας.
Τέλος, η ΜΛΑ που σχετίζεται με την αναβαθμισιμότητα των contract (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε, λόγω του επιπρόσθετου χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. Ωστόσο, υπάρχουν ήδη πλήρως λειτουργικές μέθοδοι για την επίτευξη αυτού του στόχου, με διαθέσιμα plugin\footnote{\url{https://docs.openzeppelin.com/upgrades-plugins/1.x/}} που μπορούν να ενσωματωθούν απευθείας στις υπάρχοντες ροές εργασίας.
Σημαντικές διαφορές υπήρξαν επίσης στην διαδικασία υλοποίησης τόσο όσον αφορά στον αριθμό και στις λειτουργίες των διαφορετικών πακέτων λογισμικού όσο και τον χρονοπρογραμματισμό. Προστέθηκαν τρεις νέες υπηρεσίες, η υπηρεσία "Concordia Contracts Provider", ο προσαρμοσμένος IPFS pinner "Concordia 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.5.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα tasks τα οποία υπήρχαν στο χρονοπρογραμματισμό από τη αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία δεν υλοποιήθηκαν.
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.5.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα task τα οποία υπήρχαν στον χρονοπρογραμματισμό από την αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία τελικά δεν υλοποιήθηκαν.
Ωστόσο, θα πρέπει να επισημανθεί ότι η εφαρμογή χαρακτηρίζεται από ορισμένα μειονεκτήματα, τα οποία σχετίζονται, κυρίως, με την πρώιμη κατάσταση ανάπτυξης των επιλεγμένων τεχνολογιών:
\begin{itemize}
\item Στο Application tier, μέσω της χρήσης του Ethereum, εισάγονται όλα εκείνα τα ζητήματα που συνοδεύουν επί του παρόντος το blockchain και τα smart contracts. Τα βασικότερα από αυτά είναι τα τέλη των συναλλαγών, η ανάγκη χρήσης επιπρόσθετων λογισμικών (π.χ. MetaMask) και η κλιμακοθετησιμότητά (scalability) των DApp. Σε γενικές γραμμές, το κλίμα στην παγκόσμια προγραμματιστική κοινότητα παραμένει αρκέτα πολωμένο ως προς το αν τελικά πλατφόρμες όπως το Ethereum θα μπορέσουν να ξεπεράσουν τα διάφορα προβλήματα και να ανταπεξέλθουν στις προσδοκίες.
\item Στο Application tier, μέσω της χρήσης του Ethereum, εισάγονται όλα εκείνα τα ζητήματα που συνοδεύουν επί του παρόντος το blockchain και τα smart contract. Τα βασικότερα από αυτά είναι τα τέλη των συναλλαγών, η ανάγκη χρήσης επιπρόσθετων λογισμικών (π.χ. MetaMask) και η κλιμακοθετησιμότητά (scalability) των DApp. Σε γενικές γραμμές, το κλίμα στην παγκόσμια προγραμματιστική κοινότητα παραμένει αρκέτα πολωμένο ως προς το αν τελικά πλατφόρμες όπως το Ethereum θα μπορέσουν να ξεπεράσουν τα διάφορα προβλήματα και να ανταπεξέλθουν στις προσδοκίες.
\item Στο Data tier, το IPFS και η OrbitDB αποτελούν επίσης ιδιαίτερα καινοτόμα λογισμικά και δε θεωρούνται ακόμα production-ready. Αυτό έχει ως αποτέλεσμα να εισάγουν με τη σειρά τους διάφορα προβλήματα, τα οποία σχετίζονται κυρίως με την εύρεση των peers (το οποίο βασίζεται προσωρινά σε signalling servers\footnote{Βλ. και \url{https://github.com/libp2p/js-libp2p/issues/385}.}) και το replication των δεδομένων.
\item Στο Data tier, το IPFS και η OrbitDB αποτελούν επίσης ιδιαίτερα καινοτόμα λογισμικά και δε θεωρούνται ακόμα production-ready. Αυτό έχει ως αποτέλεσμα να εισάγουν με τη σειρά τους διάφορα προβλήματα, τα οποία σχετίζονται κυρίως με την εύρεση των peers (το οποίο βασίζεται προσωρινά σε signalling servers\footnote{Βλ. και \url{https://github.com/libp2p/js-libp2p/issues/385}.}, καθιστώντας το P2P δίκτυο υβριδικό) και το replication των δεδομένων.
\end{itemize}
Τέλος, τονίζεται πως, παρ' όλες τις τρέχουσες δυσκολίες, οι προγραμματιστικές κοινότητες των παραπάνω τεχνολογιών εργάζονται αδιάκοπα για τη βελτίωση τους, ενώ παρόμοια εναλλακτικά project μπορούν ανά πάσα στιγμή να αντικαταστήσουν αυτά που επιλέχθηκαν στην τρέχουσα υλοποίηση της τεχνολογικής στοίβας.
Ezerous
3 years ago