Ezerous
3 years ago
10 changed files with 104 additions and 167 deletions
|
After Width: | Height: | Size: 161 KiB |
|
After Width: | Height: | Size: 409 KiB |
|
Before Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 47 KiB |
|
Before Width: | Height: | Size: 13 KiB |
@ -1,25 +1,20 @@ |
|||||
\section{Τεχνολογική στοίβα} \label{section:3-2-technology-stack} |
\section{Τεχνολογική στοίβα} \label{section:3-2-technology-stack} |
||||
|
|
||||
% TODO: Add React/ Redux |
Ξεκινώντας τη σχεδίαση της πλατφόρμας, πραγματοποιήθηκε έρευνα για την επιλογή της τεχνολογικής της στοίβας (technology stack). Αυτή αποφασίστηκε να ακολουθήσει μία προσαρμοσμένη για τα δεδομένα μορφή τριμερούς διάταξης\footnote{Η τριμερής διάταξη (three-tier architecture) διαχωρίζει μία εφαρμογή σε τρία ανεξάρτητα λειτουργικά επίπεδα και αποτελεί την κυρίαρχη επιλογή για διατάξεις παραδοσιακών εφαρμογών πελάτη-εξυπηρετητή.} και να χωριστεί σε τρία λογικά επίπεδα (tiers): |
||||
|
|
||||
\subsection{Ethereum} |
\begin{enumerate} |
||||
|
\item \textbf{Presentation tier}: Αποτελεί τη διεπαφή του χρήστη (user interface ή UI), μέσω της οποίας ο τελευταίος αλληλεπιδρά με την εφαρμογή. Για την εκπλήρωση των προδιαγραφών, το μοναδικό απαραίτητο χαρακτηριστικό αυτού του τμήματος είναι να μπορεί να εκτελείται αυτούσιο από τη συσκευή του τελικού χρήστη, δηλαδή να μην απαιτείται η ύπαρξη κάποιου εξυπηρετητή για τη λειτουργία του. Λαμβάνοντας, επιπροσθέτως, υπόψιν τις ανάγκες και τους περιορισμούς των λογισμικών των άλλων δύο επιπέδων, το παρόν κομμάτι αποφασίστηκε να σχεδιαστεί ως μία client-side web application σε HTML/CSS/JS. |
||||
|
|
||||
Ξεκινώντας την σχεδίαση της πλατφόρμας πραγματοποιήσαμε έρευνα ώστε να ανακαλύψουμε τις πιθανές επιλογές για το κομμάτι της διανεμημένης επεξεργασίας (\textenglish{distributed computing}). Αναλογιστήκαμε τα προτερήματα και μειονεκτήματα διάφορων επιλογών, συμπεριλαμβανομένων των ... |
\item \textbf{Application tier}: Πρόκειται για το επίπεδο που πραγματοποιεί την επεξεργασία (\textenglish{processing}) της εφαρμογης. Εδώ επιλέχθηκαν το blockchain και τα smart contracts, καθώς τα πλεονεκτήματά τους, όπως αυτά περιγράφηκαν στο κεφάλαιο \ref{chapter:2-theoretical-background}, αρμόζουν απόλυτα με τις ιδιαίτερες απαιτήσεις της εφαρμογής. Συγκεκριμένα, επιλέχθηκε η πλατφόρμα του Ethereum, καθώς αποτελεί τον πρωτοπόρο στο χώρο, διαθέτοντας την ισχυρότερη κοινότητα και την δυνατότητα δημιουργίας πλήρως λειτουργικών εφαρμογών. |
||||
|
|
||||
Επιλέξαμε να προχωρήσουμε με το Ethereum και όχι κάποια άλλη πλατφόρμα επειδή ... |
\item \textbf{Data tier}: Το τμήμα αυτό είναι υπεύθυνο για την αποθήκευση του κύριου όγκου των δεδομένων (storage). Για την επίτευξη πλήρους αρχιτεκτονικής αποκέντρωσης των δεδομένων επιλέχθηκε το IPFS (βλ. ενότητα \ref{section:2-7-ipfs}), το οποίο διανέμει το περιεχόμενο της εφαρμογής στους peers που συμμετέχουν σε αυτήν, χωρίς να απαιτεί κάποιο κεντρικό σημείο. Έτσι, κάθε χρήστης θα έχει πλήρη κυριότητα επί των δεδομένων του, ενώ, επιπλέον, θα συμμετέχει στην πλατφόρμα διαμοιράζοντας τα δεδομένα άλλων χρηστών. |
||||
|
\end{enumerate} |
||||
|
|
||||
|
Τελικά, με τη διασύνδεση των προαναφερθέντων τεχνολογιών, προκύπτει σχηματικά η ακόλουθη διάταξη: |
||||
|
|
||||
\subsection{IPFS, OrbitDB} |
% TODO: Create proper diagram |
||||
|
|
||||
Όπως η επιλογή του Blockchain, που περιγράφηκε στο προηγούμενο κεφάλαιο (\textenglish{insert reference}), ομοίως και η επιλογή του λογισμικού που θα χρησιμοποιηθεί για την κατανεμημένη αποθήκευση δεδομένων ξεκίνησε με μία έρευνα των επιλογών που υπάρχουν. Αναλογιστήκαμε τα προτερήματα και μειονεκτήματα διάφορων επιλογών, συμπεριλαμβανομένων των ... |
|
||||
|
|
||||
Επιλέξαμε να προχωρήσουμε με το IPFS και την OrbitDB έναντι άλλων λύσεων επειδή ... |
|
||||
|
|
||||
Η OrbitDB είναι ... και χρησιμοποιεί το IPFS για να καταφέρει τα εξής χαρακτηριστικά ... |
|
||||
Περιορισμοί πάλι κλπ .... |
|
||||
|
|
||||
\begin{figure}[H] |
\begin{figure}[H] |
||||
\centering |
\centering |
||||
\includegraphics[width=.75\textwidth]{assets/figures/chapter-3/simple_dapp_stack} |
\includegraphics[width=.75\textwidth]{assets/figures/chapter-3/3.2.technology.stack} |
||||
\caption{Τεχνολογική στοίβα} |
\caption{Τεχνολογική στοίβα} |
||||
\end{figure} |
\end{figure} |
||||
|
|||||
@ -1,62 +1,21 @@ |
|||||
\section{Αρχιτεκτονική σχεδίαση} \label{section:3-7-architecture-design} |
\section{Αρχιτεκτονική σχεδίαση} \label{section:3-7-architecture-design} |
||||
|
|
||||
Στο κεφάλαιο αυτό θα περιγραφεί η αρχιτεκτονική του συστήματος, όπως αυτό σχεδιάστηκε αρχικά. Η αρχιτεκτονική αυτή είναι πρώιμη και δεν αποτελεί την τελική υλοποίηση της πλατφόρμας στο σύνολό της. Μέρη της πρώιμης αρχιτεκτονικής είναι διαφορετικά από αυτά της τελικής η οποία περιγράφεται σε επόμενο κεφάλαιο. |
Στο κεφάλαιο αυτό περιγράφεται η αρχιτεκτονική του συστήματος, όπως προέκυψε από την επιλεγμένη τεχνολογική στοίβα και τις προαναφερθείσες απαιτήσεις του. Θα πρέπει να σημειωθεί ότι η παρουσιαζόμενη αρχιτεκτονική είναι πρώιμη και δεν αποτελεί την τελική υλοποίηση της πλατφόρμας, η οποία περιγράφεται στο κεφάλαιο \ref{chapter:4-application-implementation}. |
||||
|
|
||||
% TODO: remove future tense used in this chapter |
Συνοπτικά, η αρχιτεκτονική του συστήματος αποτυπώνεται στο παρακάτω διάγραμμα: |
||||
% TODO: add a brand new diagram! |
|
||||
|
|
||||
% Temporary Paste: Λογικά μέρη |
|
||||
|
|
||||
Η πλατφόρμα χωρίζεται σε δύο λογικά μέρη τα οποία θα αναλυθούν σε λεπτομέρεια στα επόμενα κεφάλαια: |
|
||||
|
|
||||
\begin{enumerate} |
|
||||
\item μία αυτοτελή και πλήρως αποκεντρωτική πλατφόρμα επικοινωνίας γενικής χρήσης |
|
||||
\item μία μερικώς αποκεντρωτική και μη αυτοτελή επέκταση του πρώτου μέρους στοχευμένη για χρήση από μέλη του ΑΠΘ |
|
||||
\end{enumerate} |
|
||||
|
|
||||
\subsection{Πρώτο μέρος} \label{subsection:3-1-first-part} |
|
||||
|
|
||||
Το πρώτο μέρος αποτελεί μία αυτοτελή και πλήρως αποκεντρωτική πλατφόρμα. Στόχος της πλατφόρμας είναι να παρέχει τη |
|
||||
δυνατότητα ελευθερίας λόγου, απρόσβλητου σε λογοκρισία από κεντρικές οντότητες εξουσίας. Στην πλατφόρμα αυτή θα μπορεί |
|
||||
οποιοσδήποτε να δημιουργήσει θέματα (topics) ή να απαντήσει σε άλλα. Η επεξεργασία των πληροφοριών που παράγονται και η |
|
||||
οποία είναι αναγκαία για τη λειτουργία της πλατφόρμας θα παρέχεται από το Ethereum μέσω των smart contracts τα οποία θα |
|
||||
υλοποιηθούν στο πλαίσιο αυτής της διπλωματικής. Τα contracts αποτελούν ανοιχτό λογισμικό από τη φύση τους, κάτι το οποίο |
|
||||
ενισχύει την διαφάνεια των διαδικασιών κάνοντας το επιχείρημα της ισότητας του λόγου πιο δυνατό. Τα contracts αυτά θα |
|
||||
δέχονται transactions από τους χρήστες και θα εγγράφουν τα αποτελέσματα στο Storage Layer του blockchain: |
|
||||
|
|
||||
% TODO: remove AUTH stuff, make it more abstract |
|
||||
|
|
||||
Το πρόβλημα αυτής της προσέγγισης είναι πως, για τη λειτουργία της, απαιτείται για κάθε συναλλαγή (transaction) οι |
|
||||
χρήστες να καταβάλουν ένα τέλος. Το τέλος αυτό αφορά τα fees που είναι αναγκαία για την περάτωση των συναλλαγών. Παρόλο |
|
||||
που υπάρχουν σχέδια από την ομάδα ανάπτυξης του Ethereum για τη μείωσή αυτών των fees στο μέλλον, θα είναι πάντα |
|
||||
αναπόφευκτα για τη χρήση του EVM. Ωστόσο, πρέπει να σημειωθούν δύο πράγματα. Αφενός τα τέλη παρέχουν μια μορφή |
|
||||
προστασίας απέναντι σε κακόβουλους χρήστες που θα πλημμύριζαν την εφαρμογή με ανεπιθύμητο ποσοτικά ή ποιοτικά |
|
||||
περιεχόμενο καθώς θα τους ήταν οικονομικά ασύμφορη μια τέτοια επίθεση. Αφετέρου υπάρχουν κάποιες εναλλακτικές ώστε να |
|
||||
μειωθεί δραστικά η εμπλοκή του χρήστη με την καταβολή τελών, κάτι που περιγράφεται παρακάτω στις κατηγορίες χρηστών. |
|
||||
|
|
||||
Τα παραπάνω πρακτικά σημαίνουν ότι το Smart Contract θα πρέπει ανά διαστήματα να φορτίζεται με Ether ή οι χρήστες να |
|
||||
καταβάλουν τα δικά τους έξοδα. |
|
||||
|
|
||||
\subsection{Δεύτερο μέρος} \label{subsection:3-2-first-part} |
|
||||
|
|
||||
Το δεύτερο μέρος αποτελεί μια μερικώς αποκεντρωτική και μη αυτοτελή πλατφόρμα που λειτουργεί προσθετικά στην πρώτη. Το |
|
||||
κομμάτι αυτό απευθύνεται αποκλειστικά σε επικυρωμένα μέλη του ΑΠΘ και συνιστά ένα αμεσοδημοκρατικό σύστημα ψηφοφορίας |
|
||||
που θα εγγυάται σε υψηλό βαθμό την εγκυρότητα και την ανωνυμία των διαδικασιών του. Στο πρώτο μέρος, το οποίο αναλύθηκε |
|
||||
προηγουμένως, θα παρέχεται η δυνατότητα δημιουργίας θεμάτων προς ψηφοφορία. Πάνω στα θέματα αυτά θα ψηφίζουν όσοι έχουν |
|
||||
δικαίωμα, ενώ το δικαίωμα στην ψήφο θα ορίζεται με την κατοχή ενός ανάλογου token στο Ethereum. |
|
||||
|
|
||||
|
% TODO: Add proper figure |
||||
\begin{figure}[H] |
\begin{figure}[H] |
||||
\centering |
\centering |
||||
\includegraphics[width=\textwidth]{assets/figures/chapter-3/uas} |
\includegraphics[width=.75\textwidth]{assets/figures/chapter-3/3.7.architecture-design} |
||||
\caption{Ethereum logo} |
\caption{Αρχιτεκτονική του συστήματος (στάδιο σχεδίασης)} |
||||
\end{figure} |
\end{figure} |
||||
|
|
||||
O χρήστης, μέσω ενός frontend με τη μορφή ιστοσελίδας, θα μπορεί να πιστοποιήσει μέσω login στο \texttt{it.auth.gr} την |
Αξίζει να σημειωθούν τα εξής: |
||||
ακαδημαϊκή του ταυτότητα. Στη συνέχεια η Υπηρεσία Διανομής Token (Token Distribution Service - TDS), όντως ο ιδιοκτήτης |
|
||||
(owner) του contract που δινέμει τα tokens θα παρέχει στο χρήστη δύο tokens. Το πρώτο token θα δίνει στον χρήστης το |
|
||||
δικαίωμα ψήφου (verified user token) και το δεύτερο θα σηματοδοτεί στη πλατφόρμα ότι πρέπει του επιστρέφει τα τέλη |
|
||||
(fees) τα οποία πληρώνει (trusted user token). |
|
||||
|
|
||||
*Ιδανικά, με τη συνεργασία του ΑΠΘ, το UAS θα αποτελεί υπηρεσία συνεργαζόμενη με την Υποδομή πιστοποίησης και |
\begin{itemize} |
||||
εξουσιοδότησης (βλ. https://it.auth.gr/el/infrastructure/aai). Αυτό σημαίνει ότι οι χρήστες δε θα χρειάζεται να |
\item Ο κώδικας του frontend εκτελείται αποκλειστικά στο σύστημα του χρήστη, χωρίς να απαιτείται κάποιος εξυπηρετητής. Δηλαδή, ο χρήστης αρκεί απλά να έχει τον κώδικα αποθηκευμένο στον υπολογιστή του. |
||||
εμπιστευτούν τον UAS με τα it credential τους. |
\item Ο χρήστης αλληλεπιδρά άμεσα με το UI και το MetaMask. Το MetaMask αποτελεί browser add-on, το οποίο διαχειρίζεται τα ιδιωτικά κλειδιά Ethereum του χρήστη και πραγματοποιεί τις συναλλαγές του τελευταίου με τα smart contracts. Στην προκειμένη περίπτωση, περιέχει τα κλειδιά που σχετίζονται αφενός με τη διεύθυνση με την οποία ο χρήστης εγγράφεται στην πλατφόρμα, αφετέρου με τις διευθύνσεις που περιέχουν τα NFTs των κοινοτήτων στις οποίες ανήκει και έχει δικαιώματα ψήφου. |
||||
|
\item Στο frontend εκτελείται στο παρασκήνιο ένας κόμβος για το IPFS. Αυτός συνδέεται με άλλους κατάλληλους κόμβους, διαμοιράζοντας τον κύριο όγκο των δεδομένων της εφαρμογής (π.χ. του περιεχομένου των μηνυμάτων). |
||||
|
\item Τέλος, στο Ethereum blockchain υπάρχουν τόσο τα contracts της εφαρμογής, όσο και τα εξωτερικά contracts που παρέχουν τα tokens των κοινοτήτων. Τα μεν λειτουργούν ως το σημείο αναφοράς της εφαρμογής, επί του οποίου εκτελούνται οι ενέργειες και αποθηκεύονται οι μεταβλητές που είναι απολύτως απαραίτητες για τη λειτουργία της πλατφόρμας (π.χ. εγγεγραμμένοι χρήστες, δημιουργημένες κοινότητες). Τα δε, δημιουργούνται από εξωτερικές οντότητες, οι οποίες ορίζουν κατά τη βούλησή τους τον ακριβή τρόπο δημιουργίας και διαμοιρασμού των tokens τους στους χρήστες. |
||||
|
\end{itemize} |
||||
Binary file not shown.
Loading…
Reference in new issue