fix: service pack 4

bibliography/references.bib

@@ -22,8 +22,7 @@
 	year         = 2001,
 	month        = 8,
 	journal      = {International Journal of Information Security},
-	doi          = {10.1007/s102070100002},
+	doi          = {10.1007/s102070100002}
-	url          = {https://doi.org/10.1007/s102070100002}
 }
 @online{2.3-merkle-proofs-explained,
 	title        = {Merkle proofs Explained.},

chapters/0.preamble/0.0.preamble.tex

@@ -1,3 +1,7 @@
+\pagestyle{plain}
+\newpage \ \newpage
+\pagestyle{fancy}
+
 \input{chapters/0.preamble/0.1.summary}
 
 \input{chapters/0.preamble/0.2.abstract}

chapters/1.introduction/1.3.problem-definition.tex

@@ -12,4 +12,4 @@
 	\item Έλλειψη εγγύησης της \textbf{ελευθερίας του λόγου}: Οι κεντρικές αρχές έχουν τη δυνατότητα να λογοκρίνουν τα δεδομένα, είτε βάσει των συμφερόντων τους, είτε βάσει υποχρεώσεών τους προς τρίτους.
 \end{itemize}
 
-Επιπλέον, όπως γίνεται φανερό, οι αδυναμίες του συστήματος ως προς τον πολιτικό άξονα το καθιστούν ακατάλληλο να παρέχει στους χρήστες αυθεντικές και επικυρώσιμες δημοκρατικές διαδικασίες. Τέτοιου είδους διαδικασίες μπορεί να είναι από απλές ψηφοφορίες, μέχρι σύνθετες διαδικασίες αυτοδιαχείρισης της πλατφόρμας.
+Επιπλέον, όπως γίνεται φανερό, οι αδυναμίες του συστήματος ως προς τον πολιτικό άξονα το καθιστούν ακατάλληλο να παρέχει στους χρήστες αυθεντικές και επικυρώσιμες δημοκρατικές διαδικασίες. Τέτοιου είδους διαδικασίες μπορεί να είναι από απλές ψηφοφορίες, μέχρι σύνθετες διαδικασίες αυτοδιαχείρισης μίας κοινότητας ή μίας οργάνωσης.

chapters/1.introduction/1.7.document-structure.tex

@@ -5,10 +5,10 @@
 Πιο συγκεκριμένα:
 
 \begin{itemize}
-	\item Το εισαγωγικό \hyperref[chapter:1-introduction]{\textbf{Κεφάλαιο 1}} έχει ως κεντρικά θέματα την ανάλυση του όρου "αποκέντρωση" (\ref{section:1-2-decentralization}), την περιγραφή του προβλήματος (\ref{section:1-3-problem-definition}) και την παρουσίαση του στόχου της εργασίας (\ref{section:1-4-thesis-goal}).
+	\item Το εισαγωγικό \hyperref[chapter:1-introduction]{\textbf{Κεφάλαιο 1}} έχει ως κεντρικά θέματα την ανάλυση του όρου "αποκέντρωση" (\ref{section:1-2-decentralization}), την περιγραφή του προβλήματος (\ref{section:1-3-problem-definition}), καθώς και την παρουσίαση του στόχου (\ref{section:1-4-thesis-goal}) και της μεθοδολογίας (\ref{section:1-5-methodology}) της εργασίας .
 	\item Το \hyperref[chapter:2-theoretical-background]{\textbf{Κεφάλαιο 2}} σχετίζεται με το θεωρητικό υπόβαθρο, το οποίο περιλαμβάνει όλες τις έννοιες που είναι απαραίτητες για την κατανόηση των διαδικασιών της σχεδίασης και της υλοποίησης της εφαρμογής. Απαρτίζεται από επτά ενότητες, στις οποίες αναλύονται σε επαρκή λεπτομέρεια οι συναρτήσεις κατακερματισμού (\ref{section:2-1-hash-functions}), η ασύμμετρη κρυπτογραφία (\ref{section:2-2-asymmetric-cryptography}), τα δένδρα Merkle (\ref{section:2-3-merkle-trees}), τα δίκτυα ομότιμων κόμβων (\ref{section:2-4-p2p-networks}), το blockchain (\ref{section:2-5-blockchain}), το Ethereum (\ref{section:2-6-ethereum}) και το IPFS (\ref{section:2-7-ipfs}).
 	\item Στο \hyperref[chapter:3-application-design]{\textbf{Κεφάλαιο 3}} περιγράφεται η διαδικασία της σχεδίασης της εφαρμογής. Συγκεκριμένα, ξεκινάει με τη σύλληψη της ιδέας (\ref{section:3-1-idea-conception}),την επιλογή της τεχνολογικής στοίβας (\ref{section:3-2-technology-stack}) και την παρουσίαση της μεθοδολογίας της σχεδίασης (\ref{section:3-3-design-methodology}). Συνεχίζει με τον ορισμό των κατηγοριών των χρηστών (\ref{section:3-4-user-categories}), των απαιτήσεων λογισμικού (\ref{section:3-5-software-requirements}) και των σεναριών χρήσης (\ref{section:3-6-use-cases}). Κλείνει με τις ενότητες της αρχιτεκτονική σχεδίασης (\ref{section:3-7-architecture-design}) και της
-	προδιαγραφής μεθόδου υλοποίησης και χρονοπρογραμματισμού (\ref{section:3-8-implementation-methodology-specification}).
+	προδιαγραφής της μεθόδου υλοποίησης και του χρονοπρογραμματισμού (\ref{section:3-8-implementation-methodology-specification}).
 	\item Στο \hyperref[chapter:4-application-implementation]{\textbf{Κεφάλαιο 4}} αναλύεται η διαδικασία υλοποίησης της πιλοτικής εφαρμογής Concordia. Αρχικά γίνεται μία περιγραφή της μεθοδολογίας που ακολουθήθηκε (\ref{subsection:4-1-implementation-methodology}), καθώς και των τεχνολογιών που χρησιμοποιήθηκαν (\ref{subsection:4-2-implementation-technology-stack}). Στην ενότητα \ref{section:4-3-implementation-architecture} παρουσιάζεται η αρχιτεκτονική του περιβάλλοντος ανάπτυξης και της εφαρμογής, μέσω της ανάλυσης των συνθετικών τους στοιχείων και του τρόπου που εκείνα διασυνδέονται. Έπειτα, επισημαίνονται τα προβλήματα που προέκυψαν κατά την ανάπτυξη (\ref{section:4-4-problems-faced}) και, τελικά, παρουσιάζονται τα υλοποιημένα χαρακτηριστικά της εφαρμογής, καθώς και οι διαφορές ανάμεσα στον σχεδιασμό και την υλοποίηση (\ref{section:4-5-implemented-parts}).
 	\item Στο \hyperref[chapter:5-conclusions-open-areas]{\textbf{Κεφάλαιο 5}} διατυπώνονται τα συμπεράσματα της εργασίας (\ref{section:5-1-conclusions}) και προτείνονται ορισμένες πιθανές μελλοντικές επεκτάσεις (\ref{section:5-2-open-areas}).
 	\item Το \hyperref[{appendix-a}]{\textbf{Παράρτημα Αʹ}} περιέχει στιγμιότυπα οθόνης της υλοποιημένης εφαρμογής.

chapters/2.theoretical-background/2.1.hash-functions.tex

@@ -12,7 +12,7 @@
 
 \begin{itemize}
 	\item Είναι ντετερμινιστική, δηλαδή η ίδια είσοδος παράγει πάντα την ίδια έξοδο.
-	\item Είναι μη αντιστρέψιμη, δηλαδή είναι πρακτικά ανέφικτο να υπολογιστεί η είσοδος δεδομένης μιας εξόδου.
+	\item Είναι μη αντιστρέψιμη, δηλαδή είναι πρακτικά ανέφικτο να υπολογιστεί η είσοδος δεδομένης μίας εξόδου.
 	\item Είναι αμφιμονοσήμαντη (1-1), δηλαδή σε δύο διαφορετικές εισόδους αντιστοιχούν πάντα δύο εντελώς διαφορετικές έξοδοι.
 	\item Είναι αποδοτική, δηλαδή ο υπολογισμός του hash οποιασδήποτε εισόδου είναι γρήγορος.
 \end{itemize}

chapters/2.theoretical-background/2.3.merkle-trees.tex

@@ -1,6 +1,6 @@
 \section{Δένδρα Merkle} \label{section:2-3-merkle-trees}
 
-Ένα δένδρο Merkle (Merkle tree ή hash tree) είναι μία δενδρική δομή δεδομένων, η οποία απαρτίζεται α) από φύλλα (leaf nodes) που περιέχουν hash από block δεδομένων και β) από άλλους κόμβους (non-leaf nodes) που περιέχουν τα hash της συνενώσεων των hash των θυγατρικών τους. Στην κορυφή του δένδρου βρίσκεται ο ριζικός κόμβος με το λεγόμενο root hash.
+Ένα δένδρο Merkle (Merkle tree ή hash tree) είναι μία δενδρική δομή δεδομένων, η οποία απαρτίζεται α) από φύλλα (leaf nodes) που περιέχουν hash από block δεδομένων και β) από άλλους κόμβους (non-leaf nodes) που περιέχουν τα hash των συνενώσεων των hash των θυγατρικών τους. Στην κορυφή του δένδρου βρίσκεται ο ριζικός κόμβος με το λεγόμενο root hash.
 
 Η πιο συνηθισμένη υλοποίηση είναι το δυαδικό (binary) δένδρο Merkle, το οποίο περιλαμβάνει δύο θυγατρικούς κόμβους (child nodes) κάτω από κάθε γονικό (non-leaf) κόμβο, και είναι αυτό που αναλύεται στη συνέχεια.
 
@@ -14,7 +14,7 @@
 
 Έτσι, μέσω των λεγόμενων Merkle proof, μπορούμε:
 \begin{itemize}
-	\item Να αποφανθούμε εάν κάποια δεδομένα ανήκουν στο δένδρο, υπολογίζοντας (για το εκάστοτε leaf node) hashes πλήθους ανάλογου του λογαρίθμου του συνολικού αριθμού των φύλλων.
+	\item Να αποφανθούμε εάν κάποια δεδομένα ανήκουν στο δένδρο, υπολογίζοντας (για το εκάστοτε leaf node) hash πλήθους ανάλογου του λογαρίθμου του συνολικού αριθμού των φύλλων.
 	\item Να αποδείξουμε συνοπτικά την εγκυρότητα ενός τμήματος κάποιου σετ δεδομένων, χωρίς να χρειαστεί να αποθηκεύσουμε ολόκληρο το σύνολο δεδομένων.
 	\item Να διασφαλίσουμε την εγκυρότητα ενός συγκεκριμένου συνόλου δεδομένων εντός ενός μεγαλύτερου σύνολου, χωρίς να χρειαστεί να αποκαλυφθεί το περιεχόμενο οποιουδήποτε εκ των δύο.\cite{2.3-merkle-proofs-explained} 
 \end{itemize}

chapters/2.theoretical-background/2.5.blockchain.tex

@@ -4,13 +4,17 @@
 
 Δομικό στοιχείο του blockchain είναι το μπλοκ (block), το οποίο περιέχει μία ομάδα έγκυρων συναλλαγών που έχουν κατακερματιστεί και κωδικοποιηθεί σε ένα δένδρο Merkle, το hash του προηγούμενου μπλοκ και μερικά ακόμα μεταδεδομένα (π.χ. nonce, timestamp). Έτσι, κάθε νέο μπλοκ "δείχνει" στο προηγούμενό του μέσω του hash, επιβεβαιώνοντας την ακεραιότητά του, με τα διαδεχόμενα μπλοκ να σχηματίζουν τελικά μία αλυσίδα, μέχρι το αρχικό μπλοκ, το οποίο είναι γνωστό ως το μπλοκ γένεσης (genesis block).
 
+\vspace{.5\baselineskip}
+
 \begin{figure}[H]
 	\centering
 	\includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.3.blockchain}
 	\caption{Blockchain ως αλυσίδα από block}
 \end{figure}
 
-Ως προς την κυριότητα επί αυτού, το blockchain συνήθως\footnote{Υπάρχουν και κάποιες υλοποιήσεις ιδιωτικών blockchain που, όμως, δε θα μας απασχολήσουν.} δεν ελέγχεται από κάποια κεντρική οντότητα, αλλά διατηρείται από ένα δημόσιο P2P δίκτυο. Οι κόμβοι (nodes) του δικτύου συμμορφώνονται συλλογικά με ένα πρωτόκολλο συναίνεσης (consensus) για την επικοινωνία και την επικύρωση νέων μπλοκ. Για παράδειγμα, στο Bitcoin, το consensus επιτυγχάνεται μέσω ενός Proof of Work (PoW) αλγορίθμου, όπου οι κόμβοι (miners) ανταγωνίζονται ο ένας τον άλλον για το ποιος θα λύσει πρώτος ένα σύνθετο αλγοριθμικό πρόβλημα που συσχετίζεται με το εκάστοτε block. Αυτός που θα τα καταφέρει επιβραβεύεται για την επεξεργαστική ισχύ που δαπάνησε με ένα ποσό από bitcoin. Εκείνα είναι εν μέρει νέα νομίσματα που κόβονται ή "εξορύσσονται" εκείνη τη στιγμή (όπως ορίζεται από το πρωτόκολλο), αλλά και όσα τέλη (fees) κατέβαλαν οι κόμβοι για να πραγματοποιήσουν τις συναλλαγές του μπλοκ. Αξίζει να σημειωθεί πως δεν είναι αναγκαίο να διαθέτει κανείς ολόκληρο το blockchain (το οποίο είναι ιδιαίτερα ογκώδες) - δηλαδή έναν πλήρη κόμβο - για να επικοινωνήσει με το δίκτυο, αλλά αρκεί να χρησιμοποιήσει έναν light node που απλά να αναμεταδίδει τις επιθυμητές συναλλαγές.
+\vspace{.5\baselineskip}
+
+Ως προς την κυριότητα επί αυτού, το blockchain συνήθως\footnote{Υπάρχουν και κάποιες υλοποιήσεις ιδιωτικών blockchain που, όμως, δε θα μας απασχολήσουν.} δεν ελέγχεται από κάποια κεντρική οντότητα, αλλά διατηρείται από ένα δημόσιο P2P δίκτυο. Οι κόμβοι του δικτύου συμμορφώνονται συλλογικά με ένα πρωτόκολλο συναίνεσης (consensus) για την επικοινωνία και την επικύρωση νέων μπλοκ. Για παράδειγμα, στο Bitcoin, το consensus επιτυγχάνεται μέσω ενός Proof of Work (PoW) αλγορίθμου, όπου οι κόμβοι (miners) ανταγωνίζονται ο ένας τον άλλον για το ποιος θα λύσει πρώτος ένα σύνθετο αλγοριθμικό πρόβλημα που συσχετίζεται με το εκάστοτε block. Αυτός που θα τα καταφέρει επιβραβεύεται για την επεξεργαστική ισχύ που δαπάνησε με ένα ποσό από bitcoin. Εκείνα είναι εν μέρει νέα νομίσματα που κόβονται ή "εξορύσσονται" εκείνη τη στιγμή (όπως ορίζεται από το πρωτόκολλο), αλλά και όσα τέλη (fees) κατέβαλαν οι κόμβοι για να πραγματοποιήσουν τις συναλλαγές του μπλοκ. Αξίζει να σημειωθεί πως δεν είναι αναγκαίο να διαθέτει κανείς ολόκληρο το blockchain (το οποίο είναι ιδιαίτερα ογκώδες) - δηλαδή έναν πλήρη κόμβο - για να επικοινωνήσει με το δίκτυο, αλλά αρκεί να χρησιμοποιήσει έναν light node που απλά να αναμεταδίδει τις επιθυμητές συναλλαγές.
 
 Η διευθυνσιοδότηση σε ένα blockchain επιτυγχάνεται αξιοποιώντας την κρυπτογραφία δημόσιου κλειδιού. Το πρωτόκολλο του εκάστοτε blockchain ορίζει έναν αλγόριθμο για την παραγωγή ζευγών κλειδιών (π.χ. ECDSA στο Bitcoin). Το δημόσιο από αυτά ορίζει τη διεύθυνση, ενώ το ιδιωτικό παραμένει μυστικό, υπό την κατοχή του χρήστη. Με αυτό τον τρόπο προκύπτει ένα πρακτικά ανεξάντλητο πλήθος πιθανών έγκυρων δημόσιων διευθύνσεων (π.χ. $2^{160}$ για το Bitcoin), στις οποίες οι χρήστες μπορούν να στέλνουν και να λαμβάνουν ποσά του εκάστοτε κρυπτονομίσματος. Για την αποστολή ενός ποσού, δηλώνουν το fee που επιθυμούν να καταβάλουν και υπογράφουν την επιθυμητή συναλλαγή με το ιδιωτικό τους κλειδί. Η συναλλαγή αναμεταδίδεται στο δίκτυο και παραμένει στο transaction pool μέχρις ότου να γίνει αποδεκτή και να συμπεριληφθεί στο επόμενο block.
 

chapters/2.theoretical-background/2.6.ethereum.tex

@@ -5,7 +5,7 @@
 Το Ethereum είναι ένα δημόσιο blockchain ανοιχτού κώδικα με εγγενές κρυπτονόμισμα το Ether (ETH). Παρέχει μία προγραμματιστική πλατφόρμα με ενσωματωμένη μία Turing-complete γλώσσα προγραμματισμού, που μπορεί να χρησιμοποιηθεί για τη δημιουργία αποκεντρωμένων εφαρμογών (Decentralized Applications ή DApps) μέσω της χρήσης "έξυπνων συμβολαίων" (smart contracts).\cite{2.6-ethereum-whitepaper}
 
 \subsection{Λογαριασμοί} \label{subsection:2-6-1-ethereum-accounts}
-Στο Ethereum blockchain οι λογαριασμοί αποτελούν οντότητες οι οποίες μπορούν να δέχονται, να κρατούν και να στέλνουν ETH και token, καθώς και να αλληλεπιδρούν με smart contracts.\cite{2.6-ethereum-documentation} Χωρίζονται σε δύο κατηγορίες: στους λογαριασμούς εξωτερικής κατοχής (\textenglish{externally owned accounts} ή EOAs) και στους λογαριασμούς συμβολαίων (contract accounts).
+Στο Ethereum blockchain οι λογαριασμοί αποτελούν οντότητες οι οποίες μπορούν να δέχονται, να κρατούν και να στέλνουν ETH και token, καθώς και να αλληλεπιδρούν με smart contracts. Χωρίζονται σε δύο κατηγορίες: στους λογαριασμούς εξωτερικής κατοχής (\textenglish{externally owned accounts} ή EOAs) και στους λογαριασμούς συμβολαίων (contract accounts).\cite{2.6-ethereum-documentation}
 
 Οι λογαριασμοί εξωτερικής κατοχής δημιουργούνται χωρίς κόστος και ελέγχονται μέσω ιδιωτικών κλειδιών. Μπορούν να πραγματοποιούν μόνο συναλλαγές μεταφοράς ETH ή κάποιου token.
 
@@ -24,35 +24,39 @@
 \end{itemize}
 
 Η δημιουργία των λογαριασμών επιτυγχάνεται μέσω της παραγωγής ενός ζεύγους κλειδιών, αξιοποιώντας τον 
-ECDSA (βλ. ενότητα \ref{section:2-2-asymmetric-cryptography}). Έτσι, το ιδιωτικό κλειδί χρησιμοποιείται για να υπογράφονται ψηφιακά οι συναλλαγές, ενώ το δημόσιο ορίζει τη δημόσια διεύθυνση του λογαριασμού (είναι της μορφής "0x + τα 20 τελευταία bytes του Keccak-256\footnote{Ο Keccak-256 αποτελεί τον κρυπτογραφικό αλγόριθμο κατακερματισμού που χρησιμοποειίται στο Ethereum. Πρόκειται για τον αλγόριθμο SHA3-256 πριν την τυποποίησή του από το NIST.} hash του δημόσιου κλειδιού").
+ECDSA (βλ. ενότητα \ref{section:2-2-asymmetric-cryptography}). Έτσι, το ιδιωτικό κλειδί χρησιμοποιείται για να υπογράφονται ψηφιακά οι συναλλαγές, ενώ το δημόσιο ορίζει τη δημόσια διεύθυνση του λογαριασμού (είναι της μορφής "0x + τα 20 τελευταία bytes του Keccak-256\footnote{Ο Keccak-256 αποτελεί τον κρυπτογραφικό αλγόριθμο κατακερματισμού που χρησιμοποιείται στο Ethereum. Πρόκειται για τον αλγόριθμο SHA3-256 πριν την τυποποίησή του από το NIST.} hash του δημόσιου κλειδιού").
 
-Κατά κύριο λόγο, οι χρήστες παράγουν και διαχειρίζονται τα ιδιωτικά κλειδιά των λογαριασμών εξωτερικής κατοχής μέσω ενός πορτοφολιού (wallet). Τα wallets αποτελούν εφαρμογές, οι οποίες δείχνουν το balance του λογαριασμού και παρέχουν τη δυνατότητα αποστολής/ λήψης ETH και token από/ σε αυτόν. Ορισμένα προτοφόλια προσφέρουν περαιτέρω λειτουργίες, σημαντικότερη εκ των οποίων είναι η διασύνδεση του λογαριασμού με αποκεντρωμένες εφαρμογές. Επί του παρόντος, το πιο διαδεδομένο πορτοφόλι τέτοιου τύπου είναι το MetaMask\footnote{\url{https://metamask.io/}}.
+Κατά κύριο λόγο, οι χρήστες παράγουν και διαχειρίζονται τα ιδιωτικά κλειδιά των λογαριασμών εξωτερικής κατοχής μέσω ενός πορτοφολιού (wallet). Τα wallet αποτελούν εφαρμογές, οι οποίες δείχνουν το balance του λογαριασμού και παρέχουν τη δυνατότητα αποστολής/ λήψης ETH και token από/ σε αυτόν. Ορισμένα προτοφόλια προσφέρουν περαιτέρω λειτουργίες, σημαντικότερη εκ των οποίων είναι η διασύνδεση του λογαριασμού με αποκεντρωμένες εφαρμογές. Επί του παρόντος, το πιο διαδεδομένο πορτοφόλι τέτοιου τύπου είναι το MetaMask\footnote{\url{https://metamask.io/}}.
 
 \subsection{Smart Contracts}
-Με λίγα λόγια, τα smart contracts αποτελούν αυτόνομα κομμάτια κώδικα, τα οποία είναι αποθηκευμένα στο blockchain και ενεργοποιούνται μέσω συναλλαγών. Κληρονομούν ιδιότητες του blockchain, όπως τη διαφάνεια (transparency), την επαληθευσιμότητα (verifiability) και την αμεταβλητότητα (immutability).
+Με λίγα λόγια, τα smart contract αποτελούν αυτόνομα κομμάτια κώδικα, τα οποία είναι αποθηκευμένα στο blockchain και ενεργοποιούνται μέσω συναλλαγών. Κληρονομούν ιδιότητες του blockchain, όπως τη διαφάνεια (transparency), την επαληθευσιμότητα (verifiability) και την αμεταβλητότητα (immutability).
 
 Ένα παράδειγμα της καθημερινότητας που μπορεί να παρομοιασθεί λειτουργικά με smart contract είναι ο αυτόματος πωλητής\cite{2.6-ethereum-smart-contracts}. Ένας αυτόματος πωλητής ορίζεται ως ένα αυτόνομο μηχάνημα που διανέμει αγαθά ή παρέχει υπηρεσίες, όταν εισαχθεί σε αυτόν κάποιο χρηματικό ποσό και επιλεχθεί ένα διαθέσιμο προϊόν. Οι αυτόματοι πωλητές είναι προγραμματισμένοι να εκτελούν συγκεκριμένους κανόνες, που θα μπορούσαν να οριστούν σε ένα συμβόλαιο. Με όμοιο τρόπο, σε ένα smart contract μπορούν να κωδικοποιηθούν αυθαίρετες συναρτήσεις μετάβασης, επιτρέποντας τη δημιουργία μίας πληθώρας αποκεντρωμένων εφαρμογών.
 
-Όπως προαναφέρθηκε στην υποενότητα \ref{subsection:2-6-1-ethereum-accounts}, τα smart contracts εντάσσονται σε contract accounts και απαιτούν την καταβολή τελών για τη δημιουργία τους, αφού χρειάζεται να εγγράψουν επί του blockchain τον κώδικα και τα αρχικά δεδομένα τους.
+Όπως προαναφέρθηκε στην υποενότητα \ref{subsection:2-6-1-ethereum-accounts}, τα smart contract εντάσσονται σε contract accounts και απαιτούν την καταβολή τελών για τη δημιουργία τους, αφού χρειάζεται να εγγράψουν επί του blockchain τον κώδικα και τα αρχικά δεδομένα τους.
 
 Επιπλέον, ο κώδικάς τους ενεργοποιείται μονάχα όταν δεχθούν μία έγκυρη συναλλαγή από κάποιον άλλον λογαριασμό (είτε εξωτερικής κατοχής, είτε συμβολαίου). Η συναλλαγή αυτή εμπεριέχει, πέρα από το απαιτούμενο fee, ένα συνοδευτικό μήνυμα με πληροφορίες σχετικές με τη συνάρτηση που πρέπει να εκτελεστεί. Η δε συνάρτηση μπορεί να πραγματοποιεί ποικίλες διαφορετικές ενέργειες, όπως την ανάγνωση και την εγγραφή στην εσωτερική αποθήκευση, την πραγματοποίηση νέων συναλλαγών, ή, ακόμα, τη δημιουργία νέων συμβολαίων.
 
-Η σύνταξη των smart contracts γίνεται κατά βάση σε γλώσσες υψηλού επιπέδου και, συγκεκριμένα, στις Solidity, Vyper και Fe\footnote{Βλ. αντίστοιχα \url{https://soliditylang.org/}, \url{https://github.com/vyperlang/vyper} και \url{https://fe-lang.org/}}. Πριν την εγγραφή τους στο blockchain, μεταγλωττίζονται σε bytecode εμηνεύσιμο από την EVM, η οποία είναι υπεύθυνη για την αποθήκευση και την εκτέλεσή του (βλ. υποενότητα \ref{subsection:2-6-5-evm}).
+Η σύνταξη των smart contract γίνεται κατά βάση σε γλώσσες υψηλού επιπέδου και, συγκεκριμένα, στις Solidity, Vyper και Fe\footnote{Βλ. αντίστοιχα \url{https://soliditylang.org/}, \url{https://github.com/vyperlang/vyper} και \url{https://fe-lang.org/}}. Πριν την εγγραφή τους στο blockchain, μεταγλωττίζονται σε bytecode εμηνεύσιμο από την EVM, η οποία είναι υπεύθυνη για την αποθήκευση και την εκτέλεσή του (βλ. υποενότητα \ref{subsection:2-6-5-evm}).
 
 \subsection{DApps}
-Οι DApps στο οικοσύστημα του Ethereum είναι εφαρμογές οι οποίες συνδυάζουν \textenglish{smart contracts} και  \textenglish{frontend UIs}. Είναι ντετερμινιστικές, Turing-complete και εκτελούνται απομονωμένα στην EVM.\cite{2.6-ethereum-documentation}
+Οι DApp στο οικοσύστημα του Ethereum είναι εφαρμογές οι οποίες συνδυάζουν \textenglish{smart contracts} και  \textenglish{frontend UIs}. Είναι ντετερμινιστικές, Turing-complete και εκτελούνται απομονωμένα στην EVM.\cite{2.6-ethereum-documentation}
 
-Πέρα από τα θετικά χαρακτηριστικά των DApps που αναλύθηκαν στην ενότητα \ref{section:1-2-decentralization} (ανοχή σε σφάλματα, αντοχή σε επιθέσεις, απουσία ανάγκης εκχώρησης εμπιστοσύνης, αντίσταση σε συμπαιγνίες), τα Ethereum DApps διαθέτουν επιπλέον όλα τα πλεονεκτήματα των blockchain και των smart contract, όπως μηδενικό downtime, πλήρη ακεραιότητα δεδομένων και επαληθεύσιμη συμπεριφορά.
+Πέρα από τα θετικά χαρακτηριστικά των DApp που αναλύθηκαν στην ενότητα \ref{section:1-2-decentralization} (ανοχή σε σφάλματα, αντοχή σε επιθέσεις, απουσία ανάγκης εκχώρησης εμπιστοσύνης, αντίσταση σε συμπαιγνίες), τα Ethereum DApp διαθέτουν επιπλέον όλα τα πλεονεκτήματα των blockchain και των smart contract, όπως μηδενικό downtime, πλήρη ακεραιότητα δεδομένων και επαληθεύσιμη συμπεριφορά.
 
 Ωστόσο, χαρακτηρίζονται και από μία σειρά αξιοσημείωτων μειονεκτημάτων, όπως τα παρακάτω:
 \begin{itemize}
 	\item Δυσκολία συντήρησης: Συντηρούνται δυσκολότερα από τις συγκεντρωτικές εφαρμογές, εξαιτίας της αμεταβλητότητας του κώδικα και των δεδομένων επί του blockchain. 
 	\item Επιβάρυνση απόδοσης: Υπάρχει τεράστια επιβάρυνση απόδοσης (performance overhead) και η κλιμάκωση (scaling) είναι πολύ δύσκολη, καθώς απαιτείται από όλους τους κόμβους να εκτελούν και να αποθηκεύουν όλες τις συναλλαγές.
 	\item Συμφόρηση δικτύου: Επί του παρόντος, το δίκτυο μπορεί να επεξεργαστεί μόνο περίπου 10-15 συναλλαγές ανά δευτερόλεπτο. Εάν οι συναλλαγές αποστέλλονται με ταχύτερο ρυθμό από αυτόν, θα αυξάνονται παράλληλα και οι μη επιβεβαιωμένες συναλλαγές που αναμένουν να εκτελεστούν.
-	\item Κακή εμπειρία χρήστη: Επί του παρόντος, είναι δύσκολο για τον μέσο τελικό χρήστη να αλληλεπιδράσει με το blockchain με ευκολία και ασφάλεια, καθώς απαιτούνται ενέργειες όπως η εγκατάσταση ειδικών εργαλείων για τη διασύνδεση με αυτό, η δημιουργία wallet, η διαφύλαξη του ιδιωτικού του κλειδιού και η προσθήκη ETH για την εξόφληση των τελών.
+	\item Κακή εμπειρία χρήστη: Επί του παρόντος, είναι δύσκολο για τον μέσο τελικό χρήστη να αλληλεπιδράσει με το blockchain με ευκολία και ασφάλεια, καθώς απαιτούνται ενέργειες όπως η εγκατάσταση ειδικών εργαλείων για τη διασύνδεση με αυτό, η δημιουργία wallet, η διαφύλαξη των ιδιωτικών του κλειδιών και η προσθήκη ETH για την εξόφληση των τελών.
 \end{itemize}
 
-Παρ' όλα τα μειονεκτήματα, τα οποία μετριάζονται με τον καιρό μέσω συνεχών αναβαθμίσεων της πλατφόρμας, υπάρχει ήδη ένα ευρύ φάσμα εφαρμογών που μπορούν να υλοποιηθούν στο Ethereum, αξιοποιώντας τα ισχυρά του πλεονεκτήματα. Οι εφαρμογές αυτές μπορούν να διακριθούν σε τρεις κατηγορίες:
+Παρ' όλα τα μειονεκτήματα, τα οποία μετριάζονται με τον καιρό μέσω συνεχών αναβαθμίσεων της πλατφόρμας, υπάρχει ήδη ένα ευρύ φάσμα εφαρμογών που μπορούν να υλοποιηθούν στο Ethereum, αξιοποιώντας τα ισχυρά του πλεονεκτήματα.
+
+\newpage
+Οι εφαρμογές αυτές μπορούν να διακριθούν σε τρεις κατηγορίες:
+
 \begin{enumerate}
 	\item Οικονομικές εφαρμογές, οι οποίες παρέχουν στους χρήστες ισχυρούς τρόπους διαχείρισης και σύναψης συμβάσεων χρησιμοποιώντας τα χρήματά τους. Αυτό περιλαμβάνει υπονομίσματα, χρηματοοικονομικά παράγωγα, συμβάσεις αντιστάθμισης κινδύνου, πορτοφόλια αποταμίευσης, διαθήκες και ακόμα και ορισμένες κατηγορίες συμβάσεων εργασίας πλήρους κλίμακας.
 	
@@ -85,9 +89,9 @@ ECDSA (βλ. ενότητα \ref{section:2-2-asymmetric-cryptography}). Έτσι
 	\item Χρησιμότητα (utility), για πρόσβαση ή πληρωμή μίας υπηρεσίας
 \end{itemize}
 
-Ένα σημαντικό κριτήριο κατηγοριοποίησης των token είναι η εναλλαξιμότητα (fungibility) τους. Ένα token είναι εναλλάξιμο όταν οποιαδήποτε μονάδα του μπορεί να αντικατασταθεί με μία άλλη χωρίς καμία διαφορά στην αξία ή τη λειτουργία του. Από την άλλη πλευρά, ένα non-fungible token (NFT) αντιπροσωπεύει ένα μοναδικό υλικό ή άυλο στοιχείο και, επομένως, είναι μη εναλλάξιμο.
+Ένα σημαντικό κριτήριο κατηγοριοποίησης των token είναι η εναλλαξιμότητά (fungibility) τους. Ένα token είναι εναλλάξιμο όταν οποιαδήποτε μονάδα του μπορεί να αντικατασταθεί με μία άλλη χωρίς καμία διαφορά στην αξία ή τη λειτουργία του. Από την άλλη πλευρά, ένα non-fungible token (NFT) αντιπροσωπεύει ένα μοναδικό υλικό ή άυλο στοιχείο και, επομένως, είναι μη εναλλάξιμο.
 
-Τέλος, τα token συχνά ακολουθούν κάποια καθορισμένα standards στην υλοποίησή τους. Τα δημοφιλέστερα από αυτά είναι τα ERC-20 και ERC-777 (για fungible token), το ERC-721 (για NFTs) και το ERC-1155 (για semi-fungible token ή SFTs).
+Τέλος, τα token συχνά ακολουθούν κάποια καθορισμένα πρότυπα στην υλοποίησή τους. Τα δημοφιλέστερα από αυτά είναι τα ERC-20 και ERC-777 (για fungible token), το ERC-721 (για NFTs) και το ERC-1155 (για semi-fungible token ή SFTs).
 
 \subsection{EVM} \label{subsection:2-6-5-evm}
 Τα smart contract (και, κατ' επέκταση, οι DApp) εκτελούνται από την εικονική μηχανή του Ethereum (Ethereum Virtual Machine ή EVM). Η EVM αποτελεί μία quasi\footnote{"Quasi" ("σχεδόν") επειδή όλες οι διαδικασίες εκτέλεσης περιορίζονται σε έναν πεπερασμένο αριθμό υπολογιστικών βημάτων από την ποσότητα gas που είναι διαθέσιμη για οποιαδήποτε εκτέλεση ενός smart contract.}–Turing-complete μηχανή καταστάσεων αρχιτεκτονικής βασισμένης σε στοίβα (stack-based architecture). Σε υψηλό επίπεδο, η EVM μπορεί να θεωρηθεί ως ένας παγκόσμιος αποκεντρωμένος υπολογιστής που περιέχει εκατομμύρια εκτελέσιμα αντικείμενα, το καθένα με τη δική του μόνιμη αποθήκη δεδομένων.
@@ -95,9 +99,9 @@ ECDSA (βλ. ενότητα \ref{section:2-2-asymmetric-cryptography}). Έτσι
 Η EVM αποθηκεύει όλες τις τιμές της μνήμης σε μια στοίβα και λειτουργεί με μέγεθος λέξης 256 bit, κυρίως για τη διευκόλυνση των εγγενών λειτουργιών κατακερματισμού και ελλειπτικής καμπύλης. Διαθέτει ένα σύνολο διευθυνσιοδοτήσιμων στοιχείων δεδομένων:
 
 \begin{itemize}
-	\item Έναν αμετάβλητο κώδικα προγράμματος σε εικονική μνήμη ROM, φορτωμένο με τον \textenglish{bytecode} του smart contract προς εκτέλεση.
+	\item Έναν αμετάβλητο κώδικα προγράμματος σε εικονική μνήμη ROM, φορτωμένο με τον \textenglish{bytecode} του smart contract προς εκτέλεση
-	\item Μία πτητική (volatile) μνήμη, με κάθε θέση ρητά αρχικοποιημένη στο μηδέν.
+	\item Μία πτητική (volatile) μνήμη, με κάθε θέση ρητά αρχικοποιημένη στο μηδέν
-	\item Ένας χώρος μόνιμης αποθήκευσης, που είναι μέρος του Ethereum state, επίσης αρχικά μηδενισμένος.
+	\item Έναν χώρο μόνιμης αποθήκευσης, που είναι μέρος του Ethereum state, επίσης αρχικά μηδενισμένο
 \end{itemize}
 
 Υπάρχει, επίσης, ένα σύνολο μεταβλητών περιβάλλοντος και δεδομένων, τα οποία είναι διαθέσιμα κατά την εκτέλεση.\cite{2.6-ethereum-mastering}

chapters/2.theoretical-background/2.7.ipfs.tex

@@ -2,25 +2,27 @@
 
 \logo{chapter-2/2.7.ipfs-logo}{IPFS logo}
 
-Το IPFS (InterPlanetary File System) είναι \textit{ένα P2P πρωτόκολλο υπερμέσων, σχεδιασμένο για να διατηρήσει και να αυξήσει τη γνώση της ανθρωπότητας κάνοντας το διαδίκτυο αναβαθμίσιμο, ανθεκτικό και πιο ανοιχτό}.\cite{2.7-ipfs}
+Το IPFS (InterPlanetary File System) είναι \textit{ένα P2P πρωτόκολλο υπερμέσων, σχεδιασμένο για να διατηρήσει και να αυξήσει τη γνώση της ανθρωπότητας κάνοντας το διαδίκτυο αναβαθμίσιμο, ανθεκτικό και πιο ανοιχτό}\cite{2.7-ipfs}.
 Πρακτικά πρόκειται για ένα κατανεμημένο σύστημα για αποθήκευση και πρόσβαση σε αρχεία, ιστότοπους, εφαρμογές και δεδομένα. Το περιεχόμενο είναι προσβάσιμο μέσω ενός δικτύου ομότιμων κόμβων που βρίσκονται οπουδήποτε στον κόσμο, οι οποίοι ενδέχεται να να αποθηκεύουν πληροφορία, να τη μεταφέρουν (relay nodes) ή και τα δύο.\cite{2.7-ipfs-docs}
 
 Ο τρόπος λειτουργίας του IPFS βασίζεται στα εξής:
 
 \begin{itemize}
 	\item \textbf{Μοναδική ταυτοποίηση μέσω διευθυνσιοδότησης περιεχομένου (content addressing)}. Το περιεχόμενο δεν προσδιορίζεται από την τοποθεσία του (π.χ. https://...), αλλά από το τι περιλαμβάνει. Κάθε κομμάτι περιεχομένου έχει ένα μοναδικό αναγνωριστικό (Content ID ή CID), το οποίο είναι το hash του σε μορφή multihash\footnote{\url{https://multiformats.io/multihash/}}.
-	\item \textbf{Σύνδεση περιεχομένου μέσω κατευθυνόμενων άκυκλων γράφων (Directed Acyclic Graphs ή DAGs)}. Το IPFS αξιοποιεί τα λεγόμενα Merkle DAGs, μίας δενδρικής δομής δεδομένων της οποίας κάθε κόμβος έχει ως μοναδικό αναγνωριστικό το hash του περιεχομένου του (το CID).
+	\item \textbf{Σύνδεση περιεχομένου μέσω κατευθυνόμενων άκυκλων γράφων (Directed Acyclic Graphs ή DAGs)}. Το IPFS αξιοποιεί τα λεγόμενα Merkle DAG, μίας δενδρικής δομής δεδομένων της οποίας κάθε κόμβος έχει ως μοναδικό αναγνωριστικό το hash του περιεχομένου του (το CID).
 
+	\vspace{-\baselineskip}
 	\begin{enumitemcenteredfigure}
 		\includegraphics[width=\textwidth]{assets/figures/chapter-2/2.7.merkle-dag.png}
 		\caption[Παράδειγμα Merkle DAG]{Παράδειγμα Merkle DAG\footnotemark}
 	\end{enumitemcenteredfigure}
+	\vspace{-\baselineskip}
 	\footnotetext{Βάσει ανάλογου σχήματος στο \url{https://proto.school/merkle-dags/}.}
-
+	
-	Όπως φαίνεται στο παραπάνω Merkle DAG, το δένδρο δημιουργείται από κάτω προς τα πάνω, υπολογίζοντας κάθε φορά τα κατάλληλα hashes/CIDs. Σε περίπτωση που το περιεχόμενο ενός κόμβου αλλάξει, τότε αλλάζει τόσο το CID του, όσο και τα CIDs όλων των προγόνων του.
+	Όπως φαίνεται στο παραπάνω Merkle DAG, το δένδρο δημιουργείται από κάτω προς τα πάνω, υπολογίζοντας κάθε φορά τα κατάλληλα hash/CID. Σε περίπτωση που το περιεχόμενο ενός κόμβου αλλάξει, τότε αλλάζει τόσο το CID του, όσο και τα CID όλων των προγόνων του.
-	\item \textbf{Ανακάλυψη περιεχομένου μέσω κατανεμημένων πινάκων κατακερματισμού (\textenglish{Distributed Hash Tables ή DHTs})}. Ο DHT είναι ένα κατανεμημένο σύστημα για την αντιστοίχιση κλειδιών σε τιμές. Στο IPFS αποτελεί το θεμελιώδες συστατικό του συστήματος δρομολόγησης περιεχομένου και λειτουργεί ως διασταύρωση μεταξύ καταλόγου και συστήματος πλοήγησης. Πρακτικά πρόκειται για ένα πίνακα που αποθηκεύει ποιος έχει ποια δεδομένα και, μέσω του οποίου, ο χρήστης βρίσκει τον peer που έχει αποθηκευμένο το επιθυμητό περιεχόμενο.
+	\item \textbf{Ανακάλυψη περιεχομένου μέσω κατανεμημένων πινάκων κατακερματισμού (\textenglish{Distributed Hash Tables ή DHTs})}. Ο DHT είναι ένα κατανεμημένο σύστημα για την αντιστοίχιση κλειδιών σε τιμές. Στο IPFS αποτελεί το θεμελιώδες συστατικό του συστήματος δρομολόγησης περιεχομένου και λειτουργεί ως διασταύρωση μεταξύ καταλόγου και συστήματος πλοήγησης. Πρακτικά πρόκειται για έναν πίνακα που αποθηκεύει ποιος έχει ποια δεδομένα και, μέσω του οποίου, ο χρήστης βρίσκει τους peer που έχουν αποθηκευμένο το επιθυμητό περιεχόμενο.
 \end{itemize}
 
-Κάτι που θα πρέπει να σημειωθεί είναι πως, σαν προεπιλογή, οι IPFS κόμβοι αντιμετωπίζουν τα αποθηκευμένα δεδομένα ως προσωρινή μνήμη (cache), πράγμα που σημαίνει ότι δεν υπάρχει καμία εγγύηση ότι εκείνα θα συνεχίσουν να παραμένουν αποθηκευμένα σε αυτούς. Για την αποφυγή της διαγραφής τους από τον garbage collector, τα δεδομένα θα πρέπει να σημανθούν ως σημαντικά, μέσω του "καρφιτσώματος" (pinning). Έτσι, για την ομαλή λειτουργία π.χ. μίας DApp που βασίζεται στο IPFS, θα πρέπει το περιεχόμενό της να είναι pinned από αρκετούς peers και/ή να γίνεται χρήση κάποιου pinning service, ώστε να εξασφαλίζεται διαθεσιμότητά του.
+Κάτι που θα πρέπει να σημειωθεί είναι πως, σαν προεπιλογή, οι IPFS κόμβοι αντιμετωπίζουν τα αποθηκευμένα δεδομένα ως προσωρινή μνήμη (cache), πράγμα που σημαίνει ότι δεν υπάρχει καμία εγγύηση ότι εκείνα θα συνεχίσουν να παραμένουν αποθηκευμένα σε αυτούς. Για την αποφυγή της διαγραφής τους από τον garbage collector, τα δεδομένα θα πρέπει να σημανθούν ως σημαντικά, μέσω του "καρφιτσώματός" (pinning) τους. Έτσι, για την ομαλή λειτουργία π.χ. μίας DApp που βασίζεται στο IPFS, θα πρέπει το περιεχόμενό της να είναι καρφιτσωμένο από αρκετούς peer και/ή να γίνεται χρήση κάποιου pinning service, ώστε να εξασφαλίζεται διαθεσιμότητά του.
 
-Βασικό πλεονέκτημα του IPFS είναι ότι ο αποκεντρωτικός του χαρακτήρας δίνει τη δυνατότητα να παρέχεται το περιεχόμενο από πολλούς κόμβους, οι οποίοι βρίσκονται σε διαφορετικές τοποθεσίες και δεν υπάγονται σε κάποια συγκεκριμένη κεντρική αρχή. Με αυτόν τον τρόπο, τα δεδομένα είναι πιο ανθεκτικά τόσο από άποψη διαθεσιμότητας (αν ένας κόμβος αποσυνδεθεί, θα υπάρχει κάποιος άλλος), όσο και από άποψη αντοχής στη λογοκρισία. Μπορεί, επίσης, να ανακτώνται γρηγορότερα, εφόσον τα διαθέτουν κάποιοι κοντινοί peers, πράγμα ιδιαίτερα πολύτιμο για κοινότητες που είναι καλά δικτυωμένες τοπικά αλλά δεν έχουν καλή σύνδεση με το ευρύτερο διαδίκτυο.
+Βασικό πλεονέκτημα του IPFS είναι ότι ο αποκεντρωτικός του χαρακτήρας δίνει τη δυνατότητα να παρέχεται το περιεχόμενο από πολλούς κόμβους, οι οποίοι βρίσκονται σε διαφορετικές τοποθεσίες και δεν υπάγονται σε κάποια συγκεκριμένη κεντρική αρχή. Με αυτόν τον τρόπο, τα δεδομένα είναι πιο ανθεκτικά, τόσο από άποψη διαθεσιμότητας (αν ένας κόμβος αποσυνδεθεί, θα υπάρχει κάποιος άλλος), όσο και από άποψη αντοχής στη λογοκρισία. Μπορεί, επίσης, να ανακτώνται γρηγορότερα, εφόσον τα διαθέτουν κάποιοι κοντινοί peer, πράγμα ιδιαίτερα πολύτιμο για κοινότητες που είναι καλά δικτυωμένες τοπικά αλλά δεν έχουν καλή σύνδεση με το ευρύτερο διαδίκτυο.

chapters/3.application-design/3.1.idea-conception.tex

@@ -2,7 +2,7 @@
 
 Η σύλληψη της ιδέας για τη δημιουργία της εφαρμογής της παρούσας διπλωματικής εργασίας είχε ως εφαλτήριο την αναγνώριση ενός διδιάστατου προβλήματος.
 
-Η πρώτη διάσταση εστιάζει στον χώρο των μέσων κοινωνικής δικτύωσης. Εκεί παρατηρείται αδιαμφισβήτητη επικράτηση πλατφορμών επικοινωνίας συγκεντρωτικής μορφής (π.χ. Facebook, Twitter, Instagram), ενώ προσπάθειες δημιουργίας αντίστοιχων αποκεντρωτικών εφαρμογών βρίσκονται σε πρώιμα στάδια, τόσο ανάπτυξης, όσο και υιοθέτησης από το ευρύ κοινό. Όπως αναλύθηκε και στην ενότητα \ref{section:1-3-problem-definition}, η τρέχουσα αυτή κατάσταση θέτει αξιοσημείωτα προβλήματα τεχνικής φύσεως (έλλειψη ασφάλειας και διαθεσιμότητας) και, κυρίως, πολιτικής (έλλειψη εμπιστοσύνης, εγγύησης της αυθεντικότητας των δεδομένων και της ελευθερίας του λόγου).
+Η πρώτη διάσταση εστιάζει στον χώρο των μέσων κοινωνικής δικτύωσης. Εκεί παρατηρείται αδιαμφισβήτητη επικράτηση πλατφορμών επικοινωνίας συγκεντρωτικής μορφής (π.χ. Facebook, Twitter, Instagram), ενώ προσπάθειες δημιουργίας αντίστοιχων αποκεντρωτικών εφαρμογών βρίσκονται σε πρώιμα στάδια, τόσο ανάπτυξης, όσο και υιοθέτησης από το ευρύ κοινό. Όπως αναλύθηκε και στην ενότητα \ref{section:1-3-problem-definition}, η τρέχουσα αυτή κατάσταση χαρακτηρίζεται από αξιοσημείωτα προβλήματα τεχνικής φύσεως (έλλειψη ασφάλειας και διαθεσιμότητας) και, κυρίως, πολιτικής (έλλειψη εμπιστοσύνης, εγγύησης της αυθεντικότητας των δεδομένων και της ελευθερίας του λόγου).
 
 Η δεύτερη διάσταση εστιάζει στον χώρο της ψηφιακής δημοκρατίας (digital democracy). Συγκεκριμένα, παρατηρείται έλλειψη  εργαλείων, ικανών να παρέχουν τη δυνατότητα διενέργειας αυθεντικών δημοκρατικών διαδικασιών. Ψηφοφορίες και αυτοδιαχείριση εντός συστημάτων κεντροποιημένης λογικής αδυνατούν, για αρχιτεκτονικούς λόγους, να εξασφαλίσουν τις απαραίτητες θεμελιώδεις ιδιότητες τέτοιων διαδικασιών, δηλαδή την ανωνυμία και την επαληθευσιμότητα.
 

chapters/3.application-design/3.2.technology-stack.tex

@@ -1,18 +1,20 @@
 \section{Τεχνολογική στοίβα} \label{section:3-2-technology-stack}
 
-Ξεκινώντας τη σχεδίαση της πλατφόρμας, πραγματοποιήθηκε έρευνα για την επιλογή της τεχνολογικής της στοίβας (technology stack). Αυτή αποφασίστηκε να ακολουθήσει μία προσαρμοσμένη για τα δεδομένα μορφή τριμερούς διάταξης\footnote{Η τριμερής διάταξη (three-tier architecture) διαχωρίζει μία εφαρμογή σε τρία ανεξάρτητα λειτουργικά επίπεδα και αποτελεί την κυρίαρχη επιλογή για διατάξεις παραδοσιακών εφαρμογών πελάτη-εξυπηρετητή.} και να χωριστεί σε τρία λογικά επίπεδα (tiers):
+Ξεκινώντας τη σχεδίαση της πλατφόρμας, πραγματοποιήθηκε έρευνα για την επιλογή της τεχνολογικής της στοίβας (technology stack). Αυτή αποφασίστηκε να ακολουθήσει μία προσαρμοσμένη για τα δεδομένα μορφή τριμερούς διάταξης\footnote{Η τριμερής διάταξη (three-tier architecture) διαχωρίζει μία εφαρμογή σε τρία ανεξάρτητα λειτουργικά επίπεδα και αποτελεί την κυρίαρχη επιλογή σε παραδοσιακές εφαρμογές αρχιτεκτονικής πελάτη-εξυπηρετητή.} και να χωριστεί σε τρία λογικά επίπεδα (tiers):
 
 \begin{enumerate}
     \item \textbf{Presentation tier}: Αποτελεί τη διεπαφή του χρήστη (user interface ή UI), μέσω της οποίας ο τελευταίος αλληλεπιδρά με την εφαρμογή. Για την εκπλήρωση των προδιαγραφών, το μοναδικό απαραίτητο χαρακτηριστικό αυτού του τμήματος είναι να μπορεί να εκτελείται αυτούσιο από τη συσκευή του τελικού χρήστη, δηλαδή να μην απαιτείται η ύπαρξη κάποιου εξυπηρετητή για τη λειτουργία του. Λαμβάνοντας, επιπροσθέτως, υπόψιν τις ανάγκες και τους περιορισμούς των λογισμικών των άλλων δύο επιπέδων, το παρόν κομμάτι αποφασίστηκε να σχεδιαστεί ως μία client-side web application σε HTML, CSS και JavaScript.
 
-    \item \textbf{Application tier}: Πρόκειται για το επίπεδο που πραγματοποιεί την επεξεργασία (\textenglish{processing}) της εφαρμογής. Εδώ επιλέχθηκαν το blockchain και τα smart contract, καθώς τα πλεονεκτήματά τους, όπως αυτά περιγράφηκαν στο κεφάλαιο \ref{chapter:2-theoretical-background}, αρμόζουν απόλυτα με τις ιδιαίτερες απαιτήσεις της εφαρμογής. Συγκεκριμένα, επιλέχθηκε η πλατφόρμα του Ethereum, καθώς αποτελεί τον πρωτοπόρο στο χώρο, διαθέτοντας την ισχυρότερη κοινότητα και τη δυνατότητα δημιουργίας πλήρως λειτουργικών αποκεντρωμένων εφαρμογών.
+    \item \textbf{Application tier}: Πρόκειται για το επίπεδο που πραγματοποιεί την επεξεργασία (\textenglish{processing}) της εφαρμογής. Εδώ επιλέχθηκαν το blockchain και τα smart contract, καθώς τα χαρακτηριστικά τους, όπως αυτά περιγράφηκαν στο κεφάλαιο \ref{chapter:2-theoretical-background}, αρμόζουν απόλυτα με τις ιδιαίτερες απαιτήσεις της εφαρμογής. Συγκεκριμένα, επιλέχθηκε η πλατφόρμα του Ethereum, καθώς αποτελεί τον πρωτοπόρο στο χώρο, διαθέτοντας την ισχυρότερη κοινότητα και τη δυνατότητα δημιουργίας πλήρως λειτουργικών αποκεντρωμένων εφαρμογών.
 
-    \item \textbf{Data tier}: Το τμήμα αυτό είναι υπεύθυνο για την αποθήκευση του κύριου όγκου των δεδομένων (storage). Για την επίτευξη πλήρους αρχιτεκτονικής αποκέντρωσης των δεδομένων επιλέχθηκε το IPFS (βλ. ενότητα \ref{section:2-7-ipfs}), το οποίο διανέμει το περιεχόμενο της εφαρμογής στους peers που συμμετέχουν σε αυτήν, χωρίς να απαιτεί κάποιο κεντρικό σημείο. Έτσι, κάθε χρήστης θα έχει πλήρη κυριότητα επί των δεδομένων του, ενώ, επιπλέον, θα συμμετέχει στην πλατφόρμα διαμοιράζοντας τα δεδομένα άλλων χρηστών.
+    \item \textbf{Data tier}: Το τμήμα αυτό είναι υπεύθυνο για την αποθήκευση του κύριου όγκου των δεδομένων (storage). Για την επίτευξη πλήρους αρχιτεκτονικής αποκέντρωσης των δεδομένων επιλέχθηκε το IPFS (βλ. ενότητα \ref{section:2-7-ipfs}), το οποίο διανέμει το περιεχόμενο της εφαρμογής στους peer που συμμετέχουν σε αυτήν, χωρίς να απαιτεί κάποιο κεντρικό σημείο. Έτσι, κάθε χρήστης θα έχει πλήρη κυριότητα επί των δεδομένων του, ενώ, επιπλέον, θα συμμετέχει στην πλατφόρμα διαμοιράζοντας τα δεδομένα άλλων χρηστών.
 \end{enumerate}
 
 \newpage
 Τελικά, με τη διασύνδεση των προαναφερθέντων τεχνολογιών, προκύπτει σχηματικά η ακόλουθη διάταξη:
 
+\vspace{.5\baselineskip}
+
 \begin{figure}[H]
     \centering
     \includegraphics[width=.55\textwidth]{assets/figures/chapter-3/3.2.technology.stack}

chapters/3.application-design/3.3.design-methodology.tex

@@ -1,15 +1,15 @@
 \section{Μεθοδολογία σχεδίασης} \label{section:3-3-design-methodology}
 
-Στον χώρο της τεχνολογίας λογισμικού υπάρχουν διάφορες μεθοδολογίες σχεδίασης, οι οποίες έχουν μεταξύ τους κοινά στοιχεία. Αυτό καθιστά δύσκολο τον προσδιορισμό μίας μόνο μεθοδολογίας η οποία να ακολουθείται πιστά σε κάθε έργο. Συνήθως, οι ομάδες που αναπτύσσουν το λογισμικό ακολουθούν μία μίξη από διάφορα εργαλεία, όπου αυτά κρίνονται ευνοϊκά για τους στόχους της ομάδας. % todo: need reference for this
+Στον χώρο της τεχνολογίας λογισμικού υπάρχουν διάφορες μεθοδολογίες σχεδίασης, οι οποίες έχουν μεταξύ τους κοινά στοιχεία. Αυτό καθιστά δύσκολο τον προσδιορισμό μίας μόνο μεθοδολογίας η οποία να ακολουθείται πιστά σε κάθε έργο. Συνήθως, οι ομάδες που αναπτύσσουν το λογισμικό ακολουθούν μία μίξη από διάφορα εργαλεία, όπου αυτά κρίνονται ευνοϊκά για τους στόχους τους. % todo: need reference for this
 
 Κατά τη σχεδίαση και την υλοποίηση του κώδικα ακολουθήθηκαν διάφορες τεχνικές και μοτίβα ανάπτυξης. Κατά βάση χρησιμοποιήθηκαν Agile μέθοδοι, όπως το Kanban και το Scrum και, αργότερα στην ανάπτυξη, το DevOps μοντέλο για διαρκή ενσωμάτωση (Continuous Integration) και διαρκή εγκατάσταση (Continuous Deployment).
 
-Για την παρούσα εργασία, πραγματοποιήθηκε ανάλυση και σχεδιασμός των επιμέρους μονάδων εργασίας (tasks) πριν την έναρξη της διαδικασίας ανάπτυξης του κώδικα. Τα task που προδιαγράφηκαν ήταν συνήθως epic\footnote{Τα epic είναι μεγάλες μονάδες εργασίας, οι οποίες αφορούν σε κάποιο βασικό χαρακτηριστικό. Ο διαχωρισμός τους σε επιμέρους task αναβάλλεται με σκοπό την καλύτερη κατανόηση των αναγκών τους.} τα οποία αργότερα χωρίστηκαν σε επιμέρους, μικρότερα task. Ορίστηκαν επίσης ορόσημα (milestones) τα οποία βοήθησαν ιδιαίτερα στην ιεράρχηση και προτεραιοποίηση των task.
+Για την παρούσα εργασία πραγματοποιήθηκε ανάλυση και σχεδιασμός των επιμέρους μονάδων εργασίας (tasks) πριν την έναρξη της διαδικασίας ανάπτυξης του κώδικα. Τα task που προδιαγράφηκαν ήταν συνήθως epic\footnote{Τα epic είναι μεγάλες μονάδες εργασίας, οι οποίες αφορούν σε κάποιο βασικό χαρακτηριστικό. Ο διαχωρισμός τους σε επιμέρους task αναβάλλεται με σκοπό την καλύτερη κατανόηση των αναγκών τους.} τα οποία αργότερα χωρίστηκαν σε επιμέρους, μικρότερα task. Ορίστηκαν επίσης ορόσημα (milestones) τα οποία βοήθησαν ιδιαίτερα στην ιεράρχηση και προτεραιοποίηση των 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 και αποτελεί τη συνέχιση αυτής της νοοτροπίας στον χώρο.
 
-Μία από τις πιο χρήσιμες πτυχές του DevOps, η οποία χρησιμοποιήθηκε στην διπλωματική, είναι το CI/CD, το οποίο περιγράφει τις διαδικασίες αυτοματοποίησης των εργασιών ενσωμάτωσης (integration), ελέγχου (testing), παράδοσης (delivery) και εγκατάστασης (deployment) του προϊόντος. Μέσω του CI/CD αφαιρείται η ανάγκη ανθρώπινης αλληλεπίδρασης για την ολοκλήρωση αυτών των σταδίων, ενώ επιτυγχάνεται η διαρκής και απρόσκοπτη διάθεση της τελευταίες έκδοσης της πλατφόρμας στους χρήστες. Ορίζονται επίσης διαδικασίες δημιουργίας περιβάλλοντος ελέγχου (staging deploys), κάτι που αποτελεί σημαντικό βοήθημα στον έγκαιρο εντοπισμό λαθών του κώδικα.
+Μία από τις πιο χρήσιμες πτυχές του DevOps, η οποία χρησιμοποιήθηκε στην διπλωματική, είναι το CI/CD, το οποίο περιγράφει τις διαδικασίες αυτοματοποίησης των εργασιών ενσωμάτωσης (integration), ελέγχου (testing), παράδοσης (delivery) και εγκατάστασης (deployment) του προϊόντος. Μέσω του CI/CD αφαιρείται η ανάγκη ανθρώπινης αλληλεπίδρασης για την ολοκλήρωση αυτών των σταδίων, ενώ επιτυγχάνεται η διαρκής και απρόσκοπτη διάθεση της τελευταίας έκδοσης της πλατφόρμας στους χρήστες. Ορίζονται επίσης διαδικασίες δημιουργίας περιβάλλοντος ελέγχου (staging deploys), κάτι που αποτελεί σημαντικό βοήθημα στον έγκαιρο εντοπισμό λαθών του κώδικα.

chapters/3.application-design/3.4.user-categories.tex

@@ -28,17 +28,17 @@
 
 \begin{threeparttable}[H]
     \begin{center}
-        \begin{tabularx}{\textwidth}{p{2.3cm} X X X X X X X X X}
+        \begin{tabularx}{\textwidth}{p{2.3cm} X X X X X X X X X X}
             \toprule
-            \multirow{7}{2.3cm}{\textbf{Κατηγορία χρήστη}} &\multicolumn{9}{c}{\textbf{Δικαιώματα}} \\ [0.5ex]
+            \multirow{7}{2.3cm}{\textbf{Κατηγορία χρήστη}} & \multicolumn{10}{c}{\textbf{Δικαιώματα}} \\ [0.5ex]
-            & \spheading{70}{6em}{Προβολή θεμάτων} & \spheading{70}{8em}{Προβολή μηνυμάτων} & \spheading{70}{8em}{Προβολή ψηφοφοριών} & \spheading{70}{8em}{Προβολή ψήφων μηνυμάτων} & \spheading{70}{8em}{Δημιουργία θεμάτων} & \spheading{70}{8em}{Δημιουργία μηνυμάτων} & \spheading{70}{8em}{Δημιουργία ψηφοφοριών} & \spheading{70}{8em}{Ψήφιση σε ψηφοφορίες} & \spheading{70}{8em}{Ψήφιση μηνυμάτων} \\ [0.5ex]
+            & \spheading{70}{6em}{Προβολή θεμάτων} & \spheading{70}{8em}{Προβολή μηνυμάτων} & \spheading{70}{8em}{Προβολή ψηφοφοριών} & \spheading{70}{8em}{Προβολή ψήφων μηνυμάτων} & \spheading{70}{8em}{Δημιουργία κοινοτήτων} & \spheading{70}{8em}{Δημιουργία θεμάτων} & \spheading{70}{8em}{Δημιουργία μηνυμάτων} & \spheading{70}{8em}{Δημιουργία ψηφοφοριών} & \spheading{70}{8em}{Ψήφιση σε ψηφοφορίες} & \spheading{70}{8em}{Ψήφιση μηνυμάτων} \\ [0.5ex]
             \midrule
-            Επισκέπτες & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} \\ [0.5ex]
+            Επισκέπτες & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} & \ \textcolor{red}{\faIcon{times}} \\ [0.5ex]
-            Εγγεγραμμένα μέλη & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \ \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \ \textcolor{OliveGreen}{\faIcon{check}} \\ [0.5ex]
+            Εγγεγραμμένα μέλη & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \ \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \ \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} \\ [0.5ex]
             \bottomrule
         \end{tabularx}
         \begin{tablenotes}
-            \item[*] \footnotesize{Μόνο στις κοινότητες στις οποίες κατέχει το αντίστοιχο token και σε αυτές οι οποίες δεν έχουν ορισμένο token.}
+            \item[*] \footnotesize{Μόνο στις κοινότητες στις οποίες κατέχει το αντίστοιχο token και σε όσες δεν έχουν ορισμένο token.}
         \end{tablenotes}
     \end{center}
     \caption{Δικαιώματα χρήσης ανά κατηγορία χρήστη}

chapters/3.application-design/3.5.software-requirements.tex

@@ -15,7 +15,7 @@
 	\sysReqItem
 		{\label{srs:functional-srs-sign-in}}
 		{Ο χρήστης πρέπει να μπορεί συνδέεται στην εφαρμογή, εφόσον είναι εγγεγραμμένος.}
-		{Το σύστημα πρέπει να διαπιστώνει αυτόματα εάν το τρέχον Ethereum address έχει λογαριασμό στην εφαρμογή και, εάν ναι, να συνδέει να τον χρήστη, ανακτώντας το Username του από το blockchain.}
+		{Το σύστημα πρέπει να διαπιστώνει αυτόματα εάν το τρέχον Ethereum address έχει λογαριασμό στην εφαρμογή και, εάν ναι, να συνδέει τον χρήστη, ανακτώντας το Username του από το blockchain.}
 		{5}{Αυτή η απαίτηση είναι ύψιστης προτεραιότητας για τους χρήστες, καθώς μέσω της σύνδεσης ενεργοποιούνται τα χαρακτηριστικά της δημιουργίας θεμάτων και δημοσίευσης μηνυμάτων.}
 		{5}{Η απαίτηση είναι ύψιστης σημασίας για το σύστημα, επειδή επηρεάζει τη λειτουργικότητά του.}
 
@@ -30,7 +30,7 @@
 		{\label{srs:functional-srs-create-topic}}
 		{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί θέματα (topics).}
 		{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί νέα θέματα. Αυτό το επιτυγχάνει πατώντας το κουμπί "New Topic", συμπληρώνοντας τα υποχρεωτικά πεδία της φόρμας ("Topic subject" και "First post content"), πατώντας το κουμπί "Create Topic" και επιβεβαιώνοντας τη συναλλαγή στο Ethereum.}
-		{5}{Αυτή η απαίτηση είναι υψηλής σημασίας καθώς επιτελεί έναν από τους βασικούς στόχους της πλατφόρμας.}
+		{5}{Αυτή η απαίτηση είναι υψηλής σημασίας, καθώς επιτελεί έναν από τους βασικούς στόχους της πλατφόρμας.}
 		{5}{Η απαίτηση είναι υψηλής σημασίας για τον ίδιο λόγο.}
 
 	\sysReqItem
@@ -75,6 +75,7 @@
 		{5}{Η απαίτηση είναι ύψιστης σημασίας για τους χρήστες, καθώς οι δημοκρατικές διαδικασίες αποτελούν μία από τις κύριες χρήσεις της πλατφόρμας.}
 		{5}{Η απαίτηση είναι ύψιστης σημασίας για το σύστημα, επειδή αποτελεί βασική προδιαγραφή του.}
 
+	\newpage
 	\sysReqItem
 		{\label{srs:functional-srs-delete-local-data}}
 		{Ο χρήστης πρέπει να μπορεί να διαγράφει τα τοπικά δεδομένα.}
@@ -99,20 +100,21 @@
 
 Η δεύτερη κατηγορία είναι αυτή των Μη Λειτουργικών Απαιτήσεων (ΜΛΑ). Περιλαμβάνει απαιτήσεις αρχιτεκτονικής σημασίας, οι οποίες καθορίζουν κριτήρια ή περιορισμούς του τρόπου λειτουργίας του συστήματος και σχετίζονται με χαρακτηριστικά όπως η αποδοτικότητα, η αξιοπιστία και η ευχρηστία του.
 
+\newpage
 \begin{enumerate}[label=\textbf{<ΜΛΑ-\arabic*>}, leftmargin=\parindent, align=left, labelwidth=\parindent, labelsep=0pt]
 	\sysReqItem
 		{\label{srs:non-functional-srs-maximum-decentraliztion}}
 		{Η πλατφόρμα πρέπει να είναι κατά το δυνατόν αρχιτεκτονικά αποκεντρωμένη.}
 		{Οι τεχνολογίες στις οποίες βασίζεται η πλατφόρμα πρέπει ιδανικά να μη δημιουργούν κεντρικά σημεία. Επιπλέον, η εφαρμογή και ο κώδικάς της πρέπει να διατίθενται δημόσια με αποκεντρωμένο τρόπο.}
 		{5}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί απαίτηση ύψιστης προτεραιότητας για τον χρήστη, καθώς διασφαλίζει την πολιτική αποκέντρωση και, έτσι, τους κύριους στόχους που έχουν οριστεί.}
-		{5}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί, απαίτηση ύψιστης σημασίας για το σύστημα, καθώς καθιστά το ίδιο ασφαλές σε επιθέσεις και τα δεδομένα μόνιμα διαθέσιμα στους χρήστες.}
+		{5}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί απαίτηση ύψιστης σημασίας για το σύστημα, καθώς καθιστά το ίδιο ασφαλές σε επιθέσεις και τα δεδομένα μόνιμα διαθέσιμα στους χρήστες.}
 
 	\sysReqItem
 		{\label{srs:non-functional-srs-minimize-fees}}
 		{Τα fee για τη χρήση του Ethereum blockchain πρέπει να ελαχιστοποιούνται.}
 		{Τα τέλη συναλλαγών που πρέπει να καταβάλλονται για τη χρήση του Ethereum blockchain εξαρτώνται άμεσα τόσο από τον όγκο των δεδομένων προς αποθήκευση, όσο και από τους κύκλους επεξεργασίας των smart contract της εφαρμογής. Ως προς τα δεδομένα, οι προγραμματιστές θα πρέπει να μεριμνούν ώστε ο κύριος όγκος τους να αποθηκεύεται επί του IPFS, ενώ επί του blockchain να αποθηκεύονται μόνο όσα πραγματικά χρειάζονται. Ως προς την απαιτούμενη επεξεργαστική ισχύ, πρέπει να βελτιστοποιείται ο κώδικας των smart contract, έτσι ώστε οι διάφορες λειτουργίες τους να εκτελούνται με τους λιγότερους δυνατούς επεξεργαστικούς κύκλους.}
-		{4}{Παρόλο που η απαίτηση δεν είναι απαραίτητη για τη χρήση της πλατφόρμας, είναι μεγάλης σημασίας για τους χρήστες, είναι ιδιαίτερα σημαντική για την ένταξη χρηστών με χαμηλότερες οικονομικές δυνατότητες.}
+		{4}{Παρόλο που η απαίτηση δεν είναι απαραίτητη για τη χρήση της πλατφόρμας, είναι ιδιαίτερα σημαντική για την ένταξη χρηστών με χαμηλότερες οικονομικές δυνατότητες.}
-		{5}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα, διότι αποτελεί σημαντικό παράγοντα που επιδρά στην προσέλκυση και τη διατήρηση ενεργών χρηστών.}
+		{2}{Η απαίτηση αυτή είναι χαμηλής σημασίας για το σύστημα, διότι μπορεί να είναι λειτουργικό χωρίς αυτή τη βελτιστοποίηση.}
 
 	\sysReqItem
 		{\label{srs:non-functional-srs-upgrade-contracts}}

chapters/3.application-design/3.6.use-cases.tex

@@ -1,8 +1,8 @@
 \section{Σενάρια χρήσης} \label{section:3-6-use-cases}
 
-Βασικό μέρος της σχεδίασης της πλατφόρμας ήταν η καταγραφή των απαιτήσεων, η οποία έγινε στην προηγούμενη ενότητα (\ref{section:3-5-software-requirements}), καθώς και η σχεδίαση και ανάπτυξη των σεναρίων χρήσης. Τα σενάρια χρήσης αντιστοιχίζουν πιθανές ενέργειες των χρηστών με αποκρίσεις του συστήματος. Μέσω αυτής της αντιστοίχισης, παρουσιάζεται η λειτουργικότητα του συστήματος και περιγράφονται τόσο οι λειτουργικές, όσο και οι μη λειτουργικές του απαιτήσεις.
+ Επόμενο στάδιο στη διαδικασία της σχεδίασης της πλατφόρμας, έπειτα από την καταγραφή των απαιτήσεων, είναι η ανάπτυξη των σεναρίων χρήσης. Τα σενάρια χρήσης αντιστοιχίζουν πιθανές ενέργειες των χρηστών με αποκρίσεις του συστήματος. Μέσω αυτής της αντιστοίχισης, παρουσιάζεται η λειτουργικότητα του συστήματος και περιγράφονται τόσο οι λειτουργικές, όσο και οι μη λειτουργικές του απαιτήσεις.
 
-Στις επόμενες υποενότητες παρατίθενται τα σενάρια χρήσης (<ΣΧ>) που δίνουν τις απαραίτητες πληροφορίες για την κατανόηση της λειτουργίας του συστήματος.
+Στις επόμενες υποενότητες παρατίθενται τα σενάρια χρήσης (<ΣΧ>) που περιλαμβάνουν τις απαραίτητες πληροφορίες για την κατανόηση της λειτουργίας του συστήματος.
 
 \input{chapters/3.application-design/3.6.use-cases/3.6.1.use-case-sign-up}
 \input{chapters/3.application-design/3.6.use-cases/3.6.2.use-case-sign-in}

chapters/3.application-design/3.6.use-cases/3.6.1.use-case-sign-up.tex

@@ -19,7 +19,7 @@
 
 \useCaseBaseFlowTable
 {
-    1 & Ο χρήστης πατάει το κουμπί "Εγγραφή".                                                    & Το σύστημα εμφανίζει την φόρμα "Εγγραφή Χρήστη". \\ [0.5ex]
+    1 & Ο χρήστης πατάει το κουμπί "Εγγραφή".                                                    & Το σύστημα εμφανίζει τη φόρμα "Εγγραφή Χρήστη". \\ [0.5ex]
     \midrule
     2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί "Υποβολή".                       & Το σύστημα εισάγει νέο χρήστη στο blockchain. \\ [0.5ex]
     \midrule

chapters/3.application-design/3.6.use-cases/3.6.10.use-case-create-community.tex

@@ -11,7 +11,7 @@
 {\ref{srs:functional-srs-create-communities}, \ref{srs:functional-srs-assign-community-contract}}
 {\ref{srs:non-functional-srs-minimize-fees}}
 {Ο χρήστης πατάει το κουμπί δημιουργίας νέας κοινότητας.}
-{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην αρχική σελίδα.}
+{Ο χρήστης πρέπει να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην αρχική σελίδα.}
 {Σενάριο χρήσης 10, δημιουργία νέας κοινότητας}
 {\label{table:3-6-use-case-create-community}}
 
@@ -37,7 +37,7 @@
 
 % ===== Alternate flow =====
 
-Το <ΣΧ-10> περιέχει επίσης δύο εναλλακτικές ροές που μπορεί να προκύψουν βάσει των επιλογών του χρήστη και οι οποίες περιγράφονται στους πίνακες \ref{table:3-6-use-case-create-community-alternate-flow-1} και \ref{table:3-6-use-case-create-community-alternate-flow-2}. Η εναλλακτική ροή 1 φαίνεται επίσης στο σχήμα \ref{figure:3-6-use-case-create-community-alternate-flow-1-sequence-diagram} όπου παρουσιάζεται το διάγραμμα ροής της.
+Το <ΣΧ-10> περιέχει επίσης δύο εναλλακτικές ροές που μπορεί να προκύψουν βάσει των επιλογών του χρήστη και οι οποίες περιγράφονται στους πίνακες \ref{table:3-6-use-case-create-community-alternate-flow-1} και \ref{table:3-6-use-case-create-community-alternate-flow-2}. Η εναλλακτική ροή 1 φαίνεται επίσης στο σχήμα \ref{figure:3-6-use-case-create-community-alternate-flow-1-sequence-diagram}, όπου παρουσιάζεται το διάγραμμα ροής της.
 
 \useCaseAlternateFlowTable
 {1}

chapters/3.application-design/3.6.use-cases/3.6.3.use-case-create-topic.tex

@@ -12,7 +12,7 @@
 {\ref{srs:functional-srs-create-topic}, \ref{srs:functional-srs-create-polls}}
 {\ref{srs:non-functional-srs-minimize-fees}}
 {Ο χρήστης πατάει το κουμπί δημιουργίας νέου θέματος.}
-{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην αρχική σελίδα.}
+{Ο χρήστης πρέπει να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην αρχική σελίδα.}
 {Σενάριο χρήσης 3, δημιουργία νέου θέματος}
 {\label{table:3-6-use-case-create-topic}}
 
@@ -40,7 +40,7 @@
 
 % ===== Alternate flow =====
 
-Το <ΣΧ-3> περιέχει επίσης δύο εναλλακτικές ροές που μπορεί να προκύψουν βάσει των επιλογών του χρήστη και οι οποίες περιγράφονται στους πίνακες \ref{table:3-6-use-case-create-topic-alternate-flow-1} και \ref{table:3-6-use-case-create-topic-alternate-flow-2}. Η εναλλακτική ροή 1 φαίνεται επίσης στο σχήμα \ref{figure:3-6-use-case-create-topic-alternate-flow-1-sequence-diagram} όπου παρουσιάζεται το διάγραμμα ροής της.
+Το <ΣΧ-3> περιέχει επίσης δύο εναλλακτικές ροές που μπορεί να προκύψουν βάσει των επιλογών του χρήστη και οι οποίες περιγράφονται στους πίνακες \ref{table:3-6-use-case-create-topic-alternate-flow-1} και \ref{table:3-6-use-case-create-topic-alternate-flow-2}. Η εναλλακτική ροή 1 φαίνεται επίσης στο σχήμα \ref{figure:3-6-use-case-create-topic-alternate-flow-1-sequence-diagram}, όπου παρουσιάζεται το διάγραμμα ροής της.
 
 \useCaseAlternateFlowTable
 {1}

chapters/3.application-design/3.6.use-cases/3.6.4.use-case-fetch-topic.tex

@@ -37,7 +37,7 @@
 
 % ===== Alternate flow =====
 \newpage
-Το <ΣΧ-4> περιέχει επίσης μία εναλλακτική ροή που μπορεί να προκύψει βάσει των επιλογών του χρήστη και η οποία περιγράφεται στον πίνακα \ref{table:3-6-use-case-fetch-topic-alternate-flow-1}. Η εναλλακτική ροή 1 φαίνεται επίσης στο σχήμα \ref{figure:3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram} όπου παρουσιάζεται το διάγραμμα ροής της.
+Το <ΣΧ-4> περιέχει επίσης μία εναλλακτική ροή που μπορεί να προκύψει βάσει των επιλογών του χρήστη και η οποία περιγράφεται στον πίνακα \ref{table:3-6-use-case-fetch-topic-alternate-flow-1}. Η εναλλακτική ροή 1 φαίνεται επίσης στο σχήμα \ref{figure:3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram}, όπου παρουσιάζεται το διάγραμμα ροής της.
 
 \useCaseAlternateFlowTable
 {1}

chapters/3.application-design/3.6.use-cases/3.6.5.use-case-create-post.tex

@@ -12,7 +12,7 @@
 {\ref{srs:functional-srs-create-post}}
 {\ref{srs:non-functional-srs-minimize-fees}}
 {Ο χρήστης πατάει το κουμπί δημιουργίας νέου μηνύματος.}
-{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στη σελίδα ενός θέματος.}
+{Ο χρήστης πρέπει να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στη σελίδα ενός θέματος.}
 {Σενάριο χρήσης 5, δημιουργία νέου μηνύματος}
 {\label{table:3-6-use-case-create-post}}
 

chapters/3.application-design/3.6.use-cases/3.6.6.use-case-modify-post.tex

@@ -11,7 +11,7 @@
 {\ref{srs:functional-srs-modify-post}}
 {-}
 {Ο χρήστης πατάει το κουμπί τροποποίησης του μηνύματος.}
-{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στη σελίδα του θέματος που περιέχει το μήνυμά του.}
+{Ο χρήστης πρέπει να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στη σελίδα του θέματος που περιέχει το μήνυμά του.}
 {Σενάριο χρήσης 6, τροποποίηση μηνύματος}
 {\label{table:3-6-use-case-modify-post}}
 

chapters/3.application-design/3.6.use-cases/3.6.7.use-case-vote-in-poll.tex

@@ -11,7 +11,7 @@
 {\ref{srs:functional-srs-vote-polls}}
 {\ref{srs:non-functional-srs-minimize-fees}}
 {Ο χρήστης πατάει το κουμπί ψηφοφορίας.}
-{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στη σελίδα ενός θέματος το οποίο περιλαμβάνει ψηφοφορία.}
+{Ο χρήστης πρέπει να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στη σελίδα ενός θέματος το οποίο περιλαμβάνει ψηφοφορία.}
 {Σενάριο χρήσης 7, ψήφιση σε ψηφοφορία}
 {\label{table:3-6-use-case-vote-in-poll}}
 

chapters/3.application-design/3.6.use-cases/3.6.8.use-case-vote-post.tex

@@ -10,8 +10,8 @@
 {Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να υπερψηφίσει ή καταψηφίσει ένα μήνυμα.}
 {\ref{srs:functional-srs-vote-posts}}
 {\ref{srs:non-functional-srs-minimize-fees}}
-{Ο επισκέπτης πατάει το κουμπί υπερψήφισης ή καταψήφισης.}
+{Ο χρήστης πατάει το κουμπί υπερψήφισης ή καταψήφισης.}
-{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στη σελίδα ενός θέματος το οποίο περιλαμβάνει τουλάχιστον ένα μήνυμα το οποίο δεν έχει δημιουργήσει ο ίδιος.}
+{Ο χρήστης πρέπει να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στη σελίδα ενός θέματος το οποίο περιλαμβάνει τουλάχιστον ένα μήνυμα το οποίο δεν έχει δημιουργήσει ο ίδιος.}
 {Σενάριο χρήσης 8, ψήφιση μηνύματος}
 {\label{table:3-6-use-case-vote-post}}
 

chapters/3.application-design/3.6.use-cases/3.6.9.delete-local-data.tex

@@ -10,8 +10,8 @@
 {Στόχος του σεναρίου χρήσης είναι ο επισκέπτης να μπορεί να διαγράψει τα τοπικά δεδομένα που αποθηκεύονται στο σύστημά του από την εφαρμογή.}
 {\ref{srs:functional-srs-delete-local-data}}
 {-}
-{Ο επισκέπτης πατάει το κουμπί διαγραφής των τοπικών δεδομένων.}
+{Ο επισκέπτης ή χρήστης πατάει το κουμπί διαγραφής των τοπικών δεδομένων.}
-{Ο επισκέπτης πρέπει να έχει ανοίξει τη σελίδα της εφαρμογής.}
+{Ο επισκέπτης ή χρήστης πρέπει να έχει ανοίξει τη σελίδα της εφαρμογής.}
 {Σενάριο χρήσης 9, διαγραφή τοπικών δεδομένων}
 {\label{table:3-6-use-case-delete-local-data}}
 

chapters/3.application-design/3.7.architecture-design.tex

@@ -1,7 +1,7 @@
 \newpage
 \section{Αρχιτεκτονική σχεδίαση} \label{section:3-7-architecture-design}
 
-Σε αυτήν την ενότητα περιγράφεται η αρχιτεκτονική του συστήματος, όπως προέκυψε από την επιλεγμένη τεχνολογική στοίβα και τις προαναφερθείσες απαιτήσεις του. Θα πρέπει να σημειωθεί ότι η παρουσιαζόμενη αρχιτεκτονική είναι πρώιμη και δεν αποτελεί την τελική υλοποίηση της πλατφόρμας, η οποία περιγράφεται στο κεφάλαιο \ref{chapter:4-application-implementation}. 
+Σε αυτήν την ενότητα περιγράφεται η αρχιτεκτονική του συστήματος, όπως προέκυψε από την επιλεγμένη τεχνολογική στοίβα και τις προαναφερθείσες απαιτήσεις του. Θα πρέπει να επισημανθεί ότι η παρουσιαζόμενη αρχιτεκτονική είναι πρώιμη και δεν αποτελεί την τελική υλοποίηση της πλατφόρμας, η οποία περιγράφεται στο κεφάλαιο \ref{chapter:4-application-implementation}. 
 
 Συνοπτικά, η αρχιτεκτονική του συστήματος αποτυπώνεται στο παρακάτω διάγραμμα:
 \vspace{\baselineskip}

chapters/3.application-design/3.8.implementation-methodology-specification.tex

@@ -8,11 +8,11 @@
 
 Κατά τον χρονοπρογραμματισμό υιοθετήθηκαν οι τακτικές που ορίζει το Scrum. Το συνολικό προγραμματιστικό έργο χωρίστηκε σε επιμέρους διακριτούς στόχους και κάθε στόχος αντιστοιχήθηκε σε ένα Sprint. Η εργασία κάθε Sprint διαχωρίστηκε περαιτέρω σε επιμέρους epic. Ωστόσο, σε αυτό το στάδιο χρονοπρογραμματισμού δεν έγινε αναλυτικότερη περιγραφή των task των epic, διαδικασία που πραγματοποιήθηκε κατά το αρχικό στάδιο της υλοποίησης των τελευταίων.
 
-Ως σημαντικότερος στόχος της ανάπτυξης ορίζεται η δημιουργία ενός ελάχιστου βιώσιμου προϊόντος (Minumum Viable Product - MVP). Σε αυτό τον στόχο περιλαμβάνονται οι πιο στοιχειώδεις λειτουργίες μίας πλατφόρμας επικοινωνίας οι οποίες την κάνουν χρήσιμη, δηλαδή η δυνατότητα εγγραφής, δημιουργίας θεμάτων και μηνυμάτων και ανάγνωσης του υπάρχοντος περιεχομένου. Επειδή ο στόχος αυτός περιέχει από μόνος του σημαντική πολυπλοκότητα και δυσκολία κρίθηκε αναγκαίος ο περαιτέρω διαχωρισμός του σε τρία Sprint.
+Ως σημαντικότερος στόχος της ανάπτυξης ορίζεται η δημιουργία ενός ελάχιστου βιώσιμου προϊόντος (Minumum Viable Product - MVP). Σε αυτόν τον στόχο περιλαμβάνονται οι πιο στοιχειώδεις λειτουργίες μίας πλατφόρμας επικοινωνίας οι οποίες την κάνουν χρήσιμη, δηλαδή η δυνατότητα εγγραφής, δημιουργίας θεμάτων και μηνυμάτων και ανάγνωσης του υπάρχοντος περιεχομένου. Επειδή ο στόχος αυτός περιέχει από μόνος του σημαντική πολυπλοκότητα και δυσκολία κρίθηκε αναγκαίος ο περαιτέρω διαχωρισμός του σε τρία Sprint.
 
-Στο πρώτο Sprint ορίστηκε ο στόχος της δημιουργίας μίας βάσης κώδικα (codebase), της εξοικείωσης με τα προγραμματιστικά εργαλεία του οικοσυστήματος των DApp και της επιτυχούς δημιουργίας του πρώτου contract. Ως στόχος του δεύτερου Sprint ορίστηκε η δημιουργία των τεχνικών χαρακτηριστικών που αφορούν στους χρήστες της εφαρμογής και που οι ίδιοι έχουν συνηθίσει να αναμένουν από μία τέτοια πλατφόρμα. Στο τρίτο Sprint συμπεριλήφθηκαν τα τεχνικά χαρακτηριστικά που απομένουν ώστε να δημιουργηθεί το MVP.
+Στο πρώτο Sprint ορίστηκε ο στόχος της δημιουργίας μίας βάσης κώδικα (codebase), της εξοικείωσης με τα προγραμματιστικά εργαλεία του οικοσυστήματος των DApp και της επιτυχούς δημιουργίας του πρώτου έξυπνου συμβολαίου. Ως στόχος του δεύτερου Sprint ορίστηκε η δημιουργία των τεχνικών χαρακτηριστικών που αφορούν στους χρήστες της εφαρμογής και που οι ίδιοι έχουν συνηθίσει να αναμένουν από μία τέτοια πλατφόρμα. Στο τρίτο Sprint συμπεριλήφθηκαν τα τεχνικά χαρακτηριστικά που απομένουν ώστε να δημιουργηθεί το MVP.
 
-Τα επόμενα τρία Sprint χτίζουν διαδοχικά πάνω στην υπάρχουσα δουλειά και υποδομή. Στο τέταρτο μέρος εργασίας ως στόχος ορίστηκε η προσθήκη των δυνατοτήτων της ψηφοφορίας επί των μηνυμάτων, καθώς και της δημιουργίας ψηφοφοριών (polls) στα θέματα. Το επόμενο Sprint περιλαμβάνει εργασίες δημιουργίας υποδομής και την πρώτη ημι-δημόσια εγκατάσταση της εφαρμογής σε περιβάλλον δοκιμής. Το τελευταίο Sprint αποτελεί το τελικό προϊόν και περιέχει task σχετικά με την δημιουργία κοινοτήτων και τη beta εγκατάσταση της εφαρμογής.
+Τα επόμενα τρία Sprint χτίζουν διαδοχικά πάνω στην υπάρχουσα δουλειά και υποδομή. Στο τέταρτο μέρος εργασίας ορίστηκε ως στόχος η προσθήκη των δυνατοτήτων της ψηφοφορίας επί των μηνυμάτων, καθώς και της δημιουργίας ψηφοφοριών (polls) στα θέματα. Το επόμενο Sprint περιλαμβάνει εργασίες δημιουργίας υποδομής και την πρώτη ημι-δημόσια εγκατάσταση της εφαρμογής σε περιβάλλον δοκιμής. Το τελευταίο Sprint αποτελεί το τελικό προϊόν και περιέχει task σχετικά με τη δημιουργία κοινοτήτων και τη beta εγκατάσταση της εφαρμογής.
 
 \newpage
 Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα:

chapters/4.application-implementation/4.1.implementation-methodology.tex

@@ -1,14 +1,14 @@
 \section{Μεθοδολογία υλοποίησης} \label{subsection:4-1-implementation-methodology}
 
-Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της εργασίας που απαιτείται σε διαχειρίσιμα μέρη, χρησιμοποιήθηκαν διάφορα εργαλεία και μέθοδοι ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git, η μέθοδος οργάνωσης Scrum και οι διαδικασίες ανάπτυξης DevOps. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύγχρονη ανάπτυξη λογισμικού.
+Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της απαιτούμενης εργασίας σε διαχειρίσιμα μέρη, χρησιμοποιήθηκαν διάφορα εργαλεία και μέθοδοι ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git, η μέθοδος οργάνωσης Scrum και οι διαδικασίες ανάπτυξης DevOps. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύγχρονη ανάπτυξη λογισμικού.
 
-Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διαρκούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφείς και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερωμένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγή τελμάτων κατά τη συγγραφή του κώδικα.
+Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διαρκούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι σαφώς ορισμένοι και χωρισμένοι σε διαχειρίσιμα μέρη, τα οποία δεν καταβάλλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερωμένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγή τελμάτων κατά τη συγγραφή του κώδικα.
 
-Το Git\footnote{\url{https://git-scm.com/}} είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του 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).
+Για τους σκοπούς της παρούσας διπλωματικής χρησιμοποιήθηκε το μοντέλο GitHub flow\cite{4.1-github-flow}. Το μοντέλο αυτό ορίζει ότι κάθε προγραμματιστής ανοίγει ένα νέο branch για την ανάπτυξη ενός χαρακτηριστικού της εφαρμογής ή για τη διόρθωση ενός μέρους του κώδικα. Έπειτα, όταν η εργασία έχει ολοκληρωθεί, δημιουργείται ένα αίτημα ένωσης (pull request) με το βασικό κλαδί ανάπτυξης (develop) της εφαρμογής. Η εργασία υπόκειται σε αξιολόγηση από την υπόλοιπη ομάδα (review) και, όταν κριθεί ότι ικανοποιεί τις ανάγκες του έργου, το κλαδί ενώνεται με το develop. Όταν το develop φτάσει σε ικανό σημείο σταθερότητας και αλλαγών, γίνεται merge με το κλαδί παραγωγής (master). Από το κλαδί develop δημιουργούνται οι δοκιμαστικές εκδόσεις αιχμής της εφαρμογής, οι οποίες χρησιμοποιούνται κατά τον έλεγχο (staging versions), ενώ από το master δημιουργούνται οι τελικές της εκδόσεις, οι οποίες διανέμονται για χρήση στην παραγωγή (production versions).
 
-Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από task τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (Sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των task πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί.
+Το Scrum είναι μία μέθοδος οργάνωσης, στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από task, τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (Sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των task πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint, τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί.
 
 Λόγω του πολύ μικρού μεγέθους της ομάδας, το Scrum ακολουθήθηκε ελαστικά. Συγκεκριμένα, δεν ορίστηκε ένας συγκεκριμένος επιμελητής του board αλλά κάθε μέλος της ομάδας φρόντιζε για τον ορισμό και την περιγραφή ενός μέρους των task. Τα Sprint δεν ήταν συνεχόμενα και δεν είχαν πάντα τον ίδιο χρόνο εκτέλεσης, αλλά προσαρμόζονταν ανάλογα με τις εκάστοτε ανάγκες και τον χρόνο των μελών. Για την οπτικοποίηση των task χρησιμοποιήθηκε κατά βάση η μέθοδος Kanban (που χρησιμοποιείται από το ίδιο το Scrum). Τα task χωρίστηκαν κατά κύριο λόγο στις παρακάτω λίστες:
 
@@ -17,13 +17,15 @@
     \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
+    \item "Ολοκλήρωσης" (done), που περιλαμβάνει task τα οποία έχουν τελειώσει, δηλαδή των οποίων η ανάπτυξη έχει ολοκληρωθεί και το pull request έχει ενωθεί στο develop
 \end{itemize}
 
-Επίσης, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί από task που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή (π.χ. μέχρι τέσσερα task στην λίστα εκτέλεσης). Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των task από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task.
+Επίσης, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί από task που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή (π.χ. μέχρι τέσσερα task στη λίστα εκτέλεσης). Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των task από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση ανάπτυξης για την ανάληψη κάποιου νέου task.
 
 Για την υλοποίηση του Scrum χρησιμοποιήθηκε η διαδικτυακή υπηρεσία Trello\footnote{\url{https://trello.com/}}, στιγμιότυπο της οποίας φαίνεται στο παρακάτω σχήμα:
 
+\vspace{.25\baselineskip}
+
 \begin{figure}[H]
     \centering
     \includegraphics[width=\textwidth]{assets/figures/chapter-4/4.1.implementation-methodology-kanban.png}
@@ -31,7 +33,7 @@
     \label{figure:4.1.implementation-methodology-kanban}
 \end{figure}
 
-Κατά τη διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά στο deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην ταχεία, απρόσκοπτη και αυτοματοποιημένη ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι:
+Κατά τη διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά στο deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην ταχεία, απρόσκοπτη και αυτοματοποιημένη ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και την εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι:
 
 \begin{itemize}
     \item Συνεχής έλεγχος (continuous testing)
@@ -42,7 +44,7 @@
 
 Για την υλοποίηση αυτών των τακτικών επιλέχθηκε μετά από εκτενή έρευνα η πλατφόρμα \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}:
+Η ροή εργασιών αποτελείται από στάδια και βήματα τα οποία φαίνονται στο σχήμα \ref{figure:4.1.implementation-methodology-jenkins-pipeline}:
 
 \begin{enumerate}
     \item Αρχικά εκτελείται το βήμα "Version", το οποίο συλλέγει στοιχεία σχετικά με την εκτέλεση του pipeline, όπως το κλαδί του κώδικα που πυροδότησε τη ροή και τα πακέτα λογισμικού που περιλαμβάνονται στο git repository και περιέχουν αλλαγές.
@@ -61,4 +63,4 @@
 
 \vspace{\baselineskip}
 
-Με τη χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με τη χρήση του συγκεκριμένου pipeline γίνεται σίγουρο ό,τι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης ο κώδικας ελέγχεται και τα αποτελέσματα των test είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker image, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλουν τα μέλη της ομάδας σε αυτό.
+Με τη χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με τη χρήση της συγκεκριμένης ροής εργασιών εξασφαλίζεται ότι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης, ο κώδικας ελέγχεται και τα αποτελέσματα των test είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker image, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλλουν τα μέλη της ομάδας σε αυτό.

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies.tex

@@ -1,6 +1,6 @@
 \subsection{Τεχνολογίες σχετικές με το development}
 
-Σε αυτήν την υποενότητα περιγράφονται ορισμένα θεμελιώδη εργαλεία και frameworks που συνετέλεσαν στην ανάπτυξη της εφαρμογής.
+Σε αυτήν την υποενότητα περιγράφονται ορισμένα θεμελιώδη εργαλεία και framework που συνετέλεσαν στην ανάπτυξη της εφαρμογής.
 
 %TODO: Add janus (?)
 

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.2.docker.tex

@@ -4,11 +4,11 @@
 
 Το Docker\footnote{\url{https://www.docker.com/}} αποτελεί μία πλατφόρμα η οποία παρέχει λογισμικό εικονοποίησης (virtualization) στο επίπεδο του λειτουργικού συστήματος, καθώς και ολοκληρωμένα συστήματα διαμοιρασμού και εκτέλεσης των παραγόμενων εικόνων.
 
-Δίνει τη δυνατότητα σύνθεσης εικονικών περιβαλλόντων λειτουργικού συστήματος, τα οποία ονομάζονται εικόνες (images). Μέσα στις εικόνες είναι δυνατή η εκτέλεση προγραμμάτων σε ασφαλή, απομονωμένα και προβλέψιμα περιβάλλοντα, τα οποία εγγυούνται τις ίδιες συνθήκες εκτέλεσης παντού. Έτσι, οι προγραμματιστές δε χρειάζεται να ανησυχούν για το περιβάλλον εκτέλεσης του κώδικα και την ρύθμιση των παραμέτρων σε κάθε ξεχωριστή εγκατάσταση.
+Προσφέρει τη δυνατότητα σύνθεσης εικονικών περιβαλλόντων λειτουργικού συστήματος, τα οποία ονομάζονται εικόνες (images). Μέσα στις εικόνες είναι δυνατή η εκτέλεση προγραμμάτων σε ασφαλή, απομονωμένα και προβλέψιμα περιβάλλοντα, τα οποία εγγυώνται τις ίδιες συνθήκες εκτέλεσης παντού. Έτσι, οι προγραμματιστές δε χρειάζεται να ανησυχούν για το περιβάλλον εκτέλεσης του κώδικα και τη ρύθμιση των παραμέτρων σε κάθε ξεχωριστή εγκατάσταση.
 
 Ταυτόχρονα, η πλατφόρμα του Docker παρέχει συστήματα και τυποποιημένες μεθόδους για το πακετάρισμα των εικόνων, τη μεταφόρτωση και την εκτέλεσή τους σε απομακρυσμένα συστήματα. Με αυτόν τον τρόπο αποτελεί πολύτιμο εργαλείο, το οποίο έχει γίνει το στάνταρ στη βιομηχανία λογισμικού για τον διαμοιρασμό και την εγκατάσταση ολοκληρωμένων εφαρμογών σε περιβάλλοντα δοκιμής (staging environments) και παραγωγής (production environments).
 
-Τέλος, η λειτουργία τοπικής εκτέλεσης των εικόνων στο σύστημα ανάπτυξης του κώδικα προσφέρει τη δυνατότητα τοπικού ελέγχου (testing) και αποσφαλμάτωσης (debug), σε ένα περιβάλλον ίδιο με αυτό της εκτέλεσης. Αυτό είναι εξαιρετικά σημαντικό, επειδή αποκλείει τυχούσες μεταβολές στην πορεία εκτέλεσης του προγράμματος που μπορεί να προέκυπταν από την εκτέλεση σε ένα διαφορετικό περιβάλλον.
+Τέλος, η λειτουργία τοπικής εκτέλεσης των εικόνων στο σύστημα ανάπτυξης του κώδικα προσφέρει τη δυνατότητα τοπικού ελέγχου (testing) και αποσφαλμάτωσης (debug), σε ένα περιβάλλον ίδιο με αυτό της εκτέλεσης. Αυτό είναι εξαιρετικά σημαντικό, επειδή αποκλείει τυχούσες μεταβολές στην πορεία εκτέλεσης του προγράμματος, που μπορεί να προέκυπταν από την εκτέλεση σε ένα διαφορετικό περιβάλλον.
 
 % TODO: example citations
 % Merkel, Dirk. “Docker: Lightweight Linux Containers for Consistent Development and Deployment.” Linux Journal, vol. 2014, no. 239, 2014, p. 2.

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins.tex

@@ -2,9 +2,9 @@
 
 \logo{chapter-4/4.2.jenkins-logo}{Jenkins logo}
 
-Το Jenkins\footnote{\url{https://www.jenkins.io/}} είναι ένας πλήρως παραμετροποιήσιμος και επεκτάσιμος διακομιστής αυτοματοποίησης (\textenglish{automation server}). Ο διακομιστής μπορεί να αυτοματοποιήσει τις διαδικασίες ελέγχου, ολοκλήρωσης, παράδοσης και εγκατάστασης του κώδικα, υλοποιώντας έτσι βασικές διαδικασίες που ορίζει το DevOps, συνεχή έλεγχο (\textenglish{continuous testing}), συνεχή ολοκλήρωση (\textenglish{continuous integration}), συνεχή παράδοση (\textenglish{continuous delivery}) και συνεχή εγκατάσταση (\textenglish{continuous deployment}). Επίσης, το Jenkins μπορεί να παραμετροποιηθεί μέσω των ρυθμίσεων που προσφέρει και των επεκτάσεων (plugins) που υπάρχουν, ώστε να παρέχει τις δυνατότητες αυτές για οποιαδήποτε πλατφόρμα, γλώσσα και περιβάλλον ανάπτυξης.
+Το Jenkins\footnote{\url{https://www.jenkins.io/}} είναι ένας πλήρως παραμετροποιήσιμος και επεκτάσιμος διακομιστής αυτοματοποίησης (\textenglish{automation server}). Ο διακομιστής μπορεί να αυτοματοποιήσει τις διαδικασίες ελέγχου, ολοκλήρωσης, παράδοσης και εγκατάστασης του κώδικα, υλοποιώντας έτσι βασικές διαδικασίες που ορίζει το DevOps, όπως συνεχή έλεγχο (\textenglish{continuous testing}), συνεχή ολοκλήρωση (\textenglish{continuous integration}), συνεχή παράδοση (\textenglish{continuous delivery}) και συνεχή εγκατάσταση (\textenglish{continuous deployment}). Επίσης, το Jenkins μπορεί να παραμετροποιηθεί τόσο μέσω των ενσωματωμένων ρυθμίσεων, όσο και μέσω των διαθέσιμων επεκτάσεων (plugins), παρέχοντας αυτές τις δυνατότητες για οποιαδήποτε πλατφόρμα, γλώσσα και περιβάλλον ανάπτυξης.
 
-Στο Jenkins είναι δυνατός ο ορισμός με χρήση κώδικα (σε Groovy και στο DSL που παρέχεται από το Jenkins) πολλαπλών γραμμών εργασιών (pipeline). Οι γραμμές εργασιών συντίθενται από πολλαπλά βήματα, τα οποία επιτελούν ξεχωριστούς στόχους προς το τελικό αποτέλεσμα της γραμμής. Τα βήματα μπορούν να εκτελούνται σειριακά ή παράλληλα. Ενώ δίνεται η δυνατότητα εκτέλεσης σε πολλαπλά, διανεμημένα συστήματα, καθώς και άλλες προχωρημένες λειτουργικότητες.
+Στο Jenkins είναι δυνατός ο ορισμός πολλαπλών γραμμών εργασιών (pipeline) με χρήση κώδικα (σε Groovy και στο DSL που παρέχεται από το Jenkins). Οι γραμμές εργασιών συντίθενται από πολλαπλά βήματα, τα οποία επιτελούν ξεχωριστούς στόχους προς το τελικό αποτέλεσμα της γραμμής. Τα βήματα μπορούν να εκτελούνται σειριακά ή παράλληλα, ενώ παρέχεται η δυνατότητα εκτέλεσης σε πολλαπλά, διανεμημένα συστήματα, καθώς και άλλες προχωρημένες λειτουργικότητες.
 
 Το Jenkins συνδυάζεται αποτελεσματικά με την πλατφόρμα του Docker που περιγράφηκε προηγουμένως. Μέσω του συνδυασμού δίνεται η ευκαιρία της αυτοματοποίησης του μεγαλύτερου μέρους του DevOps σε ένα απολύτως προβλέψιμο περιβάλλον, το οποίο παραμένει σταθερό από την ανάπτυξη του κώδικα μέχρι την τελική εγκατάσταση. Με αυτήν τη μέθοδο βελτιώνεται σημαντικά η αποτελεσματικότητα των ομάδων ανάπτυξης κώδικα.
 

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.1.react.tex

@@ -2,8 +2,8 @@
 
 \logo{chapter-4/4.2.react-logo}{React logo}
 
-Η React\footnote{\url{https://reactjs.org/}} αποτελεί βιβλιοθήκη JavaScript, η οποία χρησιμοποιείται για την κατασκευή διεπαφών χρήστη. Είναι δηλωτική (declarative) και βασίζεται σε components, τα οποία διαχειρίζονται την κατάστασή τους (state) και συντίθενται για να δημιουργήσουν πολύπλοκα διαδραστικά UIs. Τα components συνήθως υλοποιούνται σε JSX (JavaScript Syntax Extension), η οποία επεκτείνει τη JavaScript, επιτρέποντας την εισαγωγή αυτούσιων HTML εκφράσεων εντός του κώδικά της.
+Η React\footnote{\url{https://reactjs.org/}} αποτελεί βιβλιοθήκη JavaScript, η οποία χρησιμοποιείται για την κατασκευή διεπαφών χρήστη. Είναι δηλωτική (declarative) και βασίζεται σε components, τα οποία διαχειρίζονται την κατάστασή (state) τους και συντίθενται για να δημιουργήσουν πολύπλοκα διαδραστικά UI. Τα components συνήθως υλοποιούνται σε JSX (JavaScript Syntax Extension), η οποία επεκτείνει τη JavaScript, επιτρέποντας την εισαγωγή αυτούσιων HTML εκφράσεων εντός του κώδικά της.
 
-Ένα σημαντικό εργαλείο για την ταχεία ανάπτυξη web εφαρμογών σε React είναι το Create React App\footnote{\url{https://create-react-app.dev/}}. Με τη χρήση μίας και μόνο εντολής (\texttt{npx create-react-app my-app}), εγκαθίσταται αυτόματα ένας development server σε περιβάλλον Node.js (ως μία μοναδική βιβλιοθήκη). Αυτός εμπεριέχει μία πληθώρα από build tools (π.χ. Webpack, Babel, ESLint), τα οποία προσφέρουν ισχυρές δυνατότητες, όπως άμεσα reloads και παραγωγή βελτιστοποιημένων bundles. Έτσι, η διαδικασία της υλοποίησης αποκτά ποικίλες διευκολύνσεις, χωρίς να απαιτεί την εκμάθηση, την χειροκίνητη εγκατάσταση και την προηγμένη διαμόρφωση των τεχνολογιών στο εσωτερικό. 
+Ένα σημαντικό εργαλείο για την ταχεία ανάπτυξη web εφαρμογών σε React είναι το Create React App\footnote{\url{https://create-react-app.dev/}}. Με τη χρήση μίας και μόνο εντολής (\texttt{npx create-react-app my-app}), εγκαθίσταται αυτόματα ένας development server σε περιβάλλον Node.js (ως μία μοναδική βιβλιοθήκη). Αυτός εμπεριέχει μία πληθώρα από build tools (π.χ. Webpack, Babel, ESLint), τα οποία προσφέρουν ισχυρές δυνατότητες, όπως άμεσα reloads και παραγωγή βελτιστοποιημένων bundles. Έτσι, η διαδικασία της υλοποίησης αποκτά ποικίλες διευκολύνσεις, χωρίς να απαιτεί την εκμάθηση, τη χειροκίνητη εγκατάσταση και την προηγμένη διαμόρφωση των τεχνολογιών στο εσωτερικό. 
 
 Η React έχει το αποθετήριό της στο GitHub\footnote{\url{https://github.com/facebook/react/}} και διατίθεται μέσω του μητρώου npm\footnote{\url{https://www.npmjs.com/package/react}}.

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.2.redux.tex

@@ -7,12 +7,12 @@
 Τα δομικά στοιχεία του Redux είναι τα εξής:
 \begin{itemize}
 	\item \textbf{Actions}: Αντικείμενα τα οποία περιέχουν νέα πληροφορία για την τροποποίηση του state της εφαρμογής.
-	\item \textbf{Reducers}: Συναρτήσεις οι οποίες λαμβάνοντας ένα action και διαβάζοντας το τρέχον state, εφαρμόζουν κάποια λογική για την παραγωγή ενός νέου state.
+	\item \textbf{Reducers}: Συναρτήσεις, οι οποίες λαμβάνοντας ένα action και διαβάζοντας το τρέχον state, εφαρμόζουν κάποια λογική για την παραγωγή ενός νέου state.
 	\item \textbf{Store}: Το αντικείμενο στο οποίο βρίσκεται αποθηκευμένο το state της εφαρμογής. Η βασική ιδιότητα του state είναι ότι παραμένει αμετάβλητο και, για την ανανέωσή του, παράγεται πάντα ένα νέο state object μέσω των reducer.
-	\item \textbf{Middleware}: Προαιρετικά κομμάτια κώδικα που λαμβάνουν actions πριν εκείνα φτάσουν στους reducers και εκτελούν κάποιο side effect. Συνήθως χρησιμοποιούνται για ενέργειες όπως logging και error reporting ή για να ενώσουν το Redux με εξωτερικά APIs. 
+	\item \textbf{Middleware}: Προαιρετικά κομμάτια κώδικα που λαμβάνουν action πριν εκείνα φτάσουν στους reducer και εκτελούν κάποιο side effect. Συνήθως χρησιμοποιούνται για ενέργειες όπως logging και error reporting ή για να ενώσουν το Redux με εξωτερικά API. 
 \end{itemize}
 
-Αν και το ίδιο το Redux είναι μικροσκοπικό σε μέγεθος, ο τρόπος υλοποίησής του έχει επιτρέψει τη δημιουργία ενός τεράστιου οικοσυστήματος εργαλείων και επεκτάσεων, τα οποία συνδέονται μαζί του ή βασίζονται σε αυτό. Για παράδειγμα, μία από τις κύριες χρήσεις του είναι η κατασκευή διεπαφών χρήστη σε συνδύασμό με άλλες βιβλιοθήκες, όπως με την React. Σε αυτήν την περίπτωση, συνδέεται μαζί της με το npm πακέτο \texttt{react-redux} και η λειτουργία του υπό ανάπτυξη UI προκύπτει ως εξής:
+Αν και το ίδιο το Redux είναι μικροσκοπικό σε μέγεθος, ο τρόπος υλοποίησής του έχει επιτρέψει τη δημιουργία ενός τεράστιου οικοσυστήματος εργαλείων και επεκτάσεων, τα οποία συνδέονται μαζί του ή βασίζονται σε αυτό. Για παράδειγμα, μία από τις κύριες χρήσεις του είναι η κατασκευή διεπαφών χρήστη σε συνδύασμό με άλλες βιβλιοθήκες, όπως με τη React. Σε αυτήν την περίπτωση, συνδέεται μαζί της με το npm πακέτο \texttt{react-redux} και η λειτουργία του υπό ανάπτυξη UI προκύπτει ως εξής:
 
 \begin{figure}[H]
 	\centering

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.3.redux-saga.tex

@@ -2,6 +2,6 @@
 
 \logo{chapter-4/4.2.redux-saga-logo}{Redux-Saga logo}
 
-Το Redux-Saga\footnote{\url{https://redux.js.org/}} αποτελεί μία βιβλιοθήκη JavaScript του οικοσυστήματος του Redux. Πρόκειται για ένα Redux middleware, το οποίο χρησιμοποιεί ESG generator functions\footnote{\url{https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*}} για την εκτέλεση και διαχείριση ποικίλων ασύγχρονων side effect. Αυτές οι συναρτήσεις (sagas) παρέχουν μία πληθώρα επιλογών για την παράλληλη εκτέλεση κώδικα που μπορεί να σχετίζεται με εξωτερικά APIs, όπως με ένα blockchain ή μία βάση δεδομένων. Με αυτόν τον τρόπο, τα τελευταία μπορούν να συμπεριληφθούν στο κεντρικό Redux store και τη διαχείριση του συνολικού state της εφαρμογής.
+Το Redux-Saga\footnote{\url{https://redux.js.org/}} αποτελεί μία βιβλιοθήκη JavaScript του οικοσυστήματος του Redux. Πρόκειται για ένα Redux middleware, το οποίο χρησιμοποιεί ESG generator functions\footnote{\url{https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*}} για την εκτέλεση και διαχείριση ποικίλων ασύγχρονων side effect. Αυτές οι συναρτήσεις (sagas) παρέχουν μία πληθώρα επιλογών για την παράλληλη εκτέλεση κώδικα που μπορεί να σχετίζεται με εξωτερικά API, όπως με ένα blockchain ή μία βάση δεδομένων. Με αυτόν τον τρόπο, τα τελευταία μπορούν να συμπεριληφθούν στο κεντρικό Redux store και τη διαχείριση του συνολικού state της εφαρμογής.
 
 Το Redux-Saga έχει το αποθετήριό του στο GitHub\footnote{\url{https://github.com/redux-saga/redux-saga}} και διατίθεται μέσω του μητρώου npm\footnote{\url{https://www.npmjs.com/package/redux-saga}}.

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.1.truffle.tex

@@ -2,10 +2,10 @@
 
 \logo{chapter-4/4.2.truffle-logo}{Truffle logo}
 
-Το Truffle\footnote{\url{https://trufflesuite.com/truffle/}} είναι ένα από τα δημοφιλέστερα Ethereum development frameworks και αποτελεί τμήμα της σουίτας Truffle.
+Το Truffle\footnote{\url{https://trufflesuite.com/truffle/}} είναι ένα από τα δημοφιλέστερα Ethereum development framework και αποτελεί τμήμα της σουίτας Truffle.
 
-Μέσω του Truffle πραγματοποιείται η διαχείριση των έξυπνων συμβολαίων. Αυτή περιλαμβάνει τη δοκιμή, τη σύνδεση και τη μεταγλώττισή τους, καθώς και την ανάπτυξη τους στο blockchain.
+Μέσω του Truffle πραγματοποιείται η διαχείριση των έξυπνων συμβολαίων. Αυτή περιλαμβάνει τόσο τη δοκιμή, τη σύνδεση και τη μεταγλώττισή τους, όσο και την εγκατάστασή τους στο blockchain.
 
-Επίσης, το Truffle περιέχει πρόσθετα σχετικά εργαλεία, όπως διαδραστική κονσόλα για άμεση αλληλεπίδραση με τα contract και εκτελεστής εξωτερικών σεναρίων (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}}.

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.2.ganache.tex

@@ -6,8 +6,8 @@
 
 To Ganache παρέχει ισχυρά εργαλεία για την ανάπτυξη έξυπνων συμβολαίων, όπως:
 \begin{itemize}
-	\item Block explorer, μέσω του οποίου μπορούν να εξεταστούν λεπτομερώς όλα τα blocks και οι συναλλαγές που έλαβαν χώρα.
+	\item Block explorer, μέσω του οποίου μπορούν να εξεταστούν λεπτομερώς όλα τα block και οι συναλλαγές που έλαβαν χώρα.
-	\item Εξρεύνηση των εσωτερικών των contract και των πυροδοτημένων event τους.
+	\item Εξερεύνηση των εσωτερικών των contract και των πυροδοτημένων event τους.
 	\item Ενδελεχές αρχείο καταγραφής της εξόδου του blockchain, το οποίο περιλαμβάνει σημαντικές πληροφορίες για τον εντοπισμό σφαλμάτων.
 	\item Δυνατότητα διαμόρφωσης του χρόνου εξόρυξης των block, έτσι ώστε να αρμόζει με τις εκάστοτε ανάγκες (αυτόματη εξόρυξη ή εξόρυξη σε προσαρμοσμένο χρονικό διάστημα).
 \end{itemize}

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.2.orbit-db.tex

@@ -2,7 +2,7 @@
 
 \logo{chapter-4/4.2.orbitdb-logo}{OrbitDB logo}
 
-Η OrbitDB είναι μία P2P βάση δεδομένων ανοιχτού κώδικα. Χρησιμοποιεί το IPFS για την αποθήκευση των δεδομένων και το IPFS Pubsub για τον αυτόματο συγχρονισμό των βάσεων δεδομένων μεταξύ των peers. Είναι τελικά συνεπής (eventually consistent) και χρησιμοποιεί CRDTs (Conflict-Free Replicated Data Types) για συγχωνεύσεις βάσεων δεδομένων χωρίς συγκρούσεις, πράγμα που την καθιστά εξαιρετική επιλογή για DApps και offline-first web applications.\cite{4.2-orbitdb}
+Η OrbitDB είναι μία P2P βάση δεδομένων ανοιχτού κώδικα. Χρησιμοποιεί το IPFS για την αποθήκευση των δεδομένων και το IPFS Pubsub για τον αυτόματο συγχρονισμό των βάσεων δεδομένων μεταξύ των peer. Είναι τελικά συνεπής (eventually consistent) και χρησιμοποιεί CRDTs (Conflict-Free Replicated Data Types) για συγχωνεύσεις βάσεων δεδομένων χωρίς συγκρούσεις, πράγμα που την καθιστά εξαιρετική επιλογή για DApps και offline-first web applications.\cite{4.2-orbitdb}
 
 Κάποια βασικά χαρακτηριστικά της είναι τα εξής:
 \begin{itemize}
@@ -16,7 +16,7 @@
 		\item counter: μία βάση δεδομένων για καταμέτρηση συμβάντων.
 	\end{itemize}
 	
-	Όλα τα stores υλοποιούνται πάνω στο \texttt{ipfs-log}, μία αμετάβλητη, operation-based CRDT για κατανεμημένα συστήματα, ενώ υπάρχει και η δυνατότητα δημιουργίας προσαρμοσμένων stores ανάλογα με την περίπτωση.
+	Όλα τα store υλοποιούνται πάνω στο \texttt{ipfs-log}, μία αμετάβλητη, operation-based CRDT για κατανεμημένα συστήματα, ενώ υπάρχει και η δυνατότητα δημιουργίας προσαρμοσμένων store ανάλογα με την περίπτωση.
 	
 	\item \textbf{Address}: Κάθε βάση δεδομένων λαμβάνει κατά τη δημιουργία της μία διεύθυνση της μορφής \texttt{/orbitdb/CID/DATABASE\_NAME}, όπου \texttt{CID} είναι το IPFS multihash του μανιφέστου της και \texttt{DATABASE\_NAME} το όνομα της βάσης.\cite{4.2-orbitdb-guide}Το μανιφέστο είναι ένα IPFS object που περιέχει πληροφορίες της βάσης όπως το όνομα, τον τύπο και έναν δείκτη στον ελεγκτή πρόσβασης (access controller).
 	
@@ -29,7 +29,7 @@
 		\label{figure:4-2-4-2-orbit-db-identity}
 	\end{enumitemcenteredfigure}
 
-	\item \textbf{Access Control}: Κατά τη δημιουργία μίας βάσης μπορούν να οριστούν όσοι θα έχουν δικαίωμα εγγραφής σε αυτή, μέσω ενός ελεγκτή πρόσβασης (access controller). Ο ελεγκτής θα περιλαμβάνει τα public keys τους, τα οποία μπορούν να ανακτηθούν από το identity του καθενός. Από προεπιλογή και αν δεν ορίζεται διαφορετικά, δίνεται πρόσβαση εγγραφής μόνο στον δημιουργό της βάσης.
+	\item \textbf{Access Control}: Κατά τη δημιουργία μίας βάσης μπορούν να οριστούν όσοι θα έχουν δικαίωμα εγγραφής σε αυτή, μέσω ενός ελεγκτή πρόσβασης (access controller). Ο ελεγκτής θα περιλαμβάνει τα public key τους, τα οποία μπορούν να ανακτηθούν από το identity του καθενός. Από προεπιλογή και αν δεν ορίζεται διαφορετικά, δίνεται πρόσβαση εγγραφής μόνο στον δημιουργό της βάσης.
 \end{itemize}
 
 Η OrbitDB έχει το αποθετήριό της στο GitHub\footnote{\url{https://github.com/orbitdb/orbit-db}} και διατίθεται μέσω του μητρώου npm\footnote{\url{https://www.npmjs.com/package/orbit-db}}.

chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.3.libp2p.tex

@@ -4,6 +4,6 @@
 
 Η libp2p είναι ένα αρθρωτό σύστημα πρωτοκόλλων, προδιαγραφών και βιβλιοθηκών που επιτρέπουν την ανάπτυξη p2p εφαρμογών. Αποτελεί το υποκείμενο επίπεδο δικτύου του IPFS.\cite{2.7-ipfs-docs}
 
-Ένα από τα υλοποιημένα πρωτόκολλα μεταφοράς δεδομένων της libp2p είναι το libp2p-webrtc-star\footnote{\url{https://github.com/libp2p/js-libp2p-webrtc-star}}. Αποτελεί πρωτόκολλο μεταφοράς δεδομένων το οποίο υποστηρίζεται τόσο από Node.js servers, όσο και από browsers. Περιλαμβάνει, επίσης, έναν signalling server, που επιτρέπει τη γρήγορη ανακάλυψη και διασύνδεση των peers.
+Ένα από τα υλοποιημένα πρωτόκολλα μεταφοράς δεδομένων της libp2p είναι το libp2p-webrtc-star\footnote{\url{https://github.com/libp2p/js-libp2p-webrtc-star}}. Αποτελεί πρωτόκολλο μεταφοράς δεδομένων, το οποίο υποστηρίζεται τόσο από Node.js servers, όσο και από browsers. Περιλαμβάνει, επίσης, έναν signalling server, που επιτρέπει τη γρήγορη ανακάλυψη και διασύνδεση των peer.
 
 Το libp2p-webrtc-star έχει το αποθετήριό του στο GitHub\footnote{\url{https://github.com/libp2p/js-libp2p-webrtc-star}} και διατίθεται μέσω του μητρώου npm\footnote{\url{https://www.npmjs.com/package/libp2p-webrtc-star}}.

chapters/appendix/appendix-b.tex

@@ -7,7 +7,7 @@
 \captionsetup{labelformat=AppendixBTables}
 \setcounter{table}{0}
 
-Στο παρόν παράρτημα παρατίθενται πίνακες με στατιστικά στοιχεία του κώδικα της εφαρμογής Concordia, καθώς και των υλοποιημένων βιβλιοθηκών. Συγκεκριμένα, πραγματοποιήθηκε καταμέτρηση των αρχείων και των γραμμών κώδικα μέσω του προγραμμάτος cloc\footnote{\url{https://github.com/AlDanial/cloc}} (27-1-2022), διαδικασία στην οποία αγνοήθηκαν αυτόματα configuration και auto-generated αρχεία (π.χ. yarn.lock, .gitignore).
+Στο παρόν παράρτημα παρατίθενται πίνακες με στατιστικά στοιχεία του κώδικα της εφαρμογής Concordia, καθώς και των υλοποιημένων βιβλιοθηκών. Συγκεκριμένα, πραγματοποιήθηκε καταμέτρηση των αρχείων και των γραμμών κώδικα (27-1-2022) μέσω του προγραμμάτος cloc\footnote{\url{https://github.com/AlDanial/cloc}}, διαδικασία στην οποία αγνοήθηκαν αυτόματα configuration και auto-generated αρχεία (π.χ. yarn.lock, .gitignore).
 
 \begin{center}
 	\codestatstable{Concordia}{https://gitlab.com/ecentrics/concordia}

misc/packages.tex

@@ -18,6 +18,7 @@
 \usepackage{custom-packages/greek-enumerate}	% Greek enumeration for ordered item lists
 \usepackage{float}								% For \begin{figure}[H]
 \usepackage[font={footnotesize, it}]{caption}	% For captions under figures
+\usepackage[onehalfspacing]{setspace}
 \usepackage[bottom]{footmisc}
 \DeclareCaptionLabelFormat{AppendixAFigures}{Στιγμιότυπο Corcordia Α.#2}
 \DeclareCaptionLabelFormat{AppendixBTables}{Πίνακας B.#2}
@@ -33,7 +34,7 @@
 \tcbuselibrary{minted}							% Make tcolorbox work with minted
 \usepackage{graphicx}
 \usepackage{appendix}							% Appendix helpers
-\usepackage[onehalfspacing]{setspace}
+
 \usepackage[bookmarksnumbered]{hyperref}							% Extensive support for hypertext
 
 % --- titlesec ---