@ -1,12 +1,12 @@ |
|||||
{ |
{ |
||||
_id: '<the ID of the external identity>', |
id: '<the ID of the external identity>', |
||||
// Auto-generated by OrbitDB
|
// Auto-generated by OrbitDB
|
||||
_publicKey: '<signing key used to sign OrbitDB entries>', |
publicKey: '<signing key used to sign OrbitDB entries>', |
||||
signatures: { |
signatures: { |
||||
//Allows the owner of id to prove they own the private key associated with publicKey
|
//Allows the owner of id to prove they own the private key associated with publicKey
|
||||
id: '<signature of _id signed using publicKey>', |
id: '<signature of id signed using publicKey>', |
||||
//This links the two ids
|
//This links the two ids
|
||||
publicKey: '<signature of signatures.id + _publicKey using _id>' |
publicKey: '<signature of signatures.id + publicKey using id>' |
||||
}, |
}, |
||||
type: 'orbitdb' |
type: 'orbitdb' |
||||
} |
} |
||||
|
After Width: | Height: | Size: 356 KiB |
After Width: | Height: | Size: 36 KiB |
Before Width: | Height: | Size: 161 KiB After Width: | Height: | Size: 171 KiB |
Before Width: | Height: | Size: 409 KiB After Width: | Height: | Size: 645 KiB |
Before Width: | Height: | Size: 639 KiB After Width: | Height: | Size: 737 KiB |
Before Width: | Height: | Size: 168 KiB After Width: | Height: | Size: 170 KiB |
Before Width: | Height: | Size: 72 KiB |
Before Width: | Height: | Size: 99 KiB |
After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 974 KiB After Width: | Height: | Size: 1.0 MiB |
@ -1,14 +1,17 @@ |
|||||
\chapter*{Περίληψη} |
\chapter*{Περίληψη} |
||||
\addcontentsline{toc}{chapter}{Περίληψη} |
\addcontentsline{toc}{chapter}{Περίληψη} |
||||
|
|
||||
Τις τελευταίες δεκαετίες, η ραγδαία ανάπτυξη του διαδικτύου μετέβαλε ριζικά τις ανθρώπινες |
Τις τελευταίες δεκαετίες, η ραγδαία ανάπτυξη του διαδικτύου μετέβαλε ριζικά τις ανθρώπινες |
||||
κοινωνίες, μέσω μίας πληθώρας ψηφιακών εφαρμογών, οι οποίες, στη συντριπτική τους πλειοψηφία, προσφέρονται από παρόχους υπηρεσιών υπολογιστικού νέφους, ακολουθώντας την αρχιτεκτονική πελάτη-εξυπηρετητή. |
κοινωνίες, μέσω μίας πληθώρας ψηφιακών εφαρμογών, οι οποίες, στη συντριπτική τους πλειοψηφία, προσφέρονται από παρόχους υπηρεσιών υπολογιστικού νέφους, ακολουθώντας την αρχιτεκτονική πελάτη-εξυπηρετητή. |
||||
|
|
||||
Μολονότι αυτό το μοντέλο υλοποίησης έχει αποδειχθεί ιδιαίτερα λειτουργικό και έχει βελτιωθεί αξιοσημείωτα ανά τα χρόνια, η συγκεντρωτική του λογική συνοδεύεται από μία σειρά προβλημάτων. Πρώτα απ' όλα, ο χρήστης καλείται να εμπιστευθεί τα προσωπικά του δεδομένα σε μία εξωτερική οντότητα. Εκείνη, διατηρώντας τον πλήρη έλεγχο επί αυτών, διαθέτει τη δυνατότητα να τα επεξεργάζεται, να τα διαμοιράζεται και να τα λογοκρίνει, είτε για να εξυπηρετήσει τα συμφέροντά της, είτε για να συμμορφωθεί με άλλες αρχές που της ασκούν εξουσία. Επιπλέον, απουσιάζει η εγγύηση της διαθεσιμότητας των δεδομένων, καθώς, ανά πάσα στιγμή, ο εξυπηρετητής μπορεί να αποσυνδεθεί για αόριστο χρονικό διάστημα και λόγω ποικίλων αιτιών, όπως κάποιας κυβερνοεπίθεσης ή κάποιας φυσικής καταστροφής. |
Μολονότι αυτό το μοντέλο υλοποίησης έχει αποδειχθεί ιδιαίτερα λειτουργικό και έχει βελτιωθεί αξιοσημείωτα ανά τα χρόνια, η συγκεντρωτική του λογική συνοδεύεται από μία σειρά προβλημάτων. Πρώτα απ' όλα, ο χρήστης καλείται να εμπιστευθεί τα προσωπικά του δεδομένα σε μία εξωτερική οντότητα. Εκείνη, διατηρώντας τον πλήρη έλεγχο επί αυτών, αποκτάει τη δυνατότητα να τα επεξεργάζεται, να τα διαμοιράζεται και να τα λογοκρίνει, είτε για να εξυπηρετήσει τα συμφέροντά της, είτε για να συμμορφωθεί με άλλες αρχές που της ασκούν εξουσία. Επιπλέον, απουσιάζει η εγγύηση της διαθεσιμότητας των δεδομένων, καθώς, ανά πάσα στιγμή, ο εξυπηρετητής μπορεί να αποσυνδεθεί για αόριστο χρονικό διάστημα και λόγω ποικίλων αιτιών, όπως κάποιας κυβερνοεπίθεσης ή κάποιας φυσικής καταστροφής. |
||||
|
|
||||
Αυτοί είναι μερικοί βασικοί λόγοι που συνετέλεσαν στην ταχεία ανάπτυξη ενός συνόλου λογισμικών ανοιχτού κώδικα, όπως του Ethereum blockchain και του IPFS, τα οποία, αν και βρίσκονται σε σχετικά πρώιμο στάδιο, αποτελούν ήδη ικανά εργαλεία δημιουργίας κατανεμημένων και αποκεντρωμένων εφαρμογών. |
Αυτοί είναι μερικοί βασικοί λόγοι που συνετέλεσαν στην ταχεία ανάπτυξη ενός συνόλου καινοτόμων λογισμικών ανοιχτού κώδικα, τα οποία βασίζονται σε τεχνολογίες όπως το blockchain και τα δίκτυα ομότιμων κόμβων. Τα παραπάνω, αν και βρίσκονται σε σχετικά πρώιμο στάδιο, αποτελούν ήδη ισχυρά εργαλεία δημιουργίας κατανεμημένων και αποκεντρωμένων εφαρμογών. |
||||
|
|
||||
Στόχος της παρούσας διπλωματικής εργασίας είναι η υλοποίηση μίας αυτόνομης κοινωνικής πλατφόρμας, |
Στόχος της παρούσας διπλωματικής εργασίας είναι η υλοποίηση μίας αυτόνομης κοινωνικής πλατφόρμας, |
||||
η οποία, αξιοποιώντας τεχνολογίες αποκέντρωσης, αφενός θα επιστρέφει την κυριότητα των προσωπικών |
η οποία, αξιοποιώντας τεχνολογίες αποκέντρωσης, αφενός θα επιστρέφει την κυριότητα των προσωπικών |
||||
δεδομένων στον χρήστη, αφετέρου θα παρέχει τη δυνατότητα διενέργειας διαφανών δημοκρατικών ψηφοφοριών. Αυτά μέσα σε ένα πλαίσιο ανθεκτικό, τόσο σε σφάλματα και επιθέσεις, όσο και σε απόπειρες λογοκρισίας και παραποίησης. |
δεδομένων στον χρήστη, αφετέρου θα παρέχει τη δυνατότητα διενέργειας διαφανών δημοκρατικών ψηφοφοριών. Αυτά μέσα σε ένα πλαίσιο ανθεκτικό, τόσο σε σφάλματα και επιθέσεις, όσο και σε απόπειρες λογοκρισίας και παραποίησης. |
||||
|
|
||||
|
Η αναπτυχθείσα πιλοτική εφαρμογή "Concordia" προσεγγίζει τον παραπάνω στόχο συνδυάζοντας τα Ethereum και IPFS, ώστε να ορίσει έναν αποκεντρωμένο ψηφιακό χώρο, τόσο σε αρχιτεκτονικό όσο και πολιτικό επίπεδο. |
||||
\\[2\baselineskip] |
\\[2\baselineskip] |
||||
\textbf{Λέξεις-Κλειδιά}: Αποκεντροποίηση, Ethereum, Blockchain, Έξυπνο Συμβόλαιο, Αποκεντρωμένη Εφαρμογή, IPFS, OrbitDB, React, Redux, Jenkins |
\textbf{Λέξεις-Κλειδιά}: Αποκεντροποίηση, Ethereum, Blockchain, Έξυπνο Συμβόλαιο, Αποκεντρωμένη Εφαρμογή, IPFS, OrbitDB, React, Redux, Jenkins |
@ -1,3 +1,16 @@ |
|||||
\chapter*{Abstract} |
\chapter*{Abstract} |
||||
\addcontentsline{toc}{chapter}{Abstract} |
\addcontentsline{toc}{chapter}{Abstract} |
||||
Don't forget the keywords. |
|
||||
|
\textenglish{In recent decades, the rapid growth of the internet has radically changed human |
||||
|
societies, through a plethora of digital applications, the vast majority of which are offered by cloud computing service providers, following the client-server architecture. |
||||
|
|
||||
|
Although this implementation model has proven to be highly functional and has improved significantly over the years, its centralized logic is accompanied by a number of problems. First of all, the user is required to trust his personal data to an external entity. Maintaining full control over them, the latter gains the ability to process, share and censor them, either to serve its own interests or to comply with other authorities in power. Furthermore, there is no guarantee of data availability, as, at any time, the server can be disconnected indefinitely and for a variety of reasons, such as a cyber attack or a natural disaster. |
||||
|
|
||||
|
These are some of the key factors that have led to the rapid development of a wide range of innovating open source software, that are based on technologies such as blockchain and peer-to-peer networks. The aforementioned, although at a relatively early stage, are already powerful tools for creating distributed and decentralized applications. |
||||
|
|
||||
|
The goal of this thesis is the implementation of an autonomous social platform, |
||||
|
which, by utilizing decentralization technologies, on the one hand will return the ownership of the data to the end user, on the other hand will provide transparent democratic voting processes. These in a context resistant to both faults and attacks, as well as attempts at censorship and falsification. |
||||
|
|
||||
|
The developed proof of concept application "Concordia" approaches the above goal by combining Ethereum and IPFS, in order to define a digital space, that is decentralized both at architectural and political level. |
||||
|
\\[2\baselineskip] |
||||
|
\textbf {Keywords}: Decentralization, Ethereum, Blockchain, Smart Contract, Decentralized Application, IPFS, OrbitDB, React, Redux, Jenkins} |
@ -1,3 +1,11 @@ |
|||||
\chapter*{Ευχαριστίες} |
\chapter*{Ευχαριστίες} |
||||
\addcontentsline{toc}{chapter}{Ευχαριστίες} |
\addcontentsline{toc}{chapter}{Ευχαριστίες} |
||||
Ευχαριστούμε η Αθήνα. Ευχαριστούμε η Ελλάδα. |
|
||||
|
Σε αυτό το σημείο θα θέλαμε να ευχαριστήσουμε εγκάρδια όλους εκείνους που συνέβαλλαν στην εκπόνηση της παρούσας εργασίας: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item Τον επιβλέποντα καθηγητή μας, κ. Δημάκη Χρήστο, για την ευκαιρία που μας έδωσε να ασχοληθούμε με το συγκεκριμένο θέμα και την εμπιστοσύνη που μας έδειξε από την αρχή μέχρι το τέλος. |
||||
|
\item Τη Νικολαΐδου Μελίνα, για τη σχεδίαση του λογότυπου της εφαρμογής και τη δημιουργία σημαντικού τμήματος των σχημάτων του παρόντος εγγράφου. |
||||
|
\item Τις οικογένειες και τους φίλους μας, για την αμέριστη υλική και ηθική υποστήριξη που μας προσέφεραν καθ' όλη τη διάρκεια των σπουδών μας. |
||||
|
\item Ο ένας τον άλλον, για την άρτια επικοινωνία και συνεργασία, καθώς και για την υπομονή και την επιμονή, χαρακτηριστικά καθοριστικής σημασίας για την επιτυχή πορεία της διπλωματικής. |
||||
|
\end{itemize} |
||||
|
@ -0,0 +1,5 @@ |
|||||
|
\section{Τυπογραφικές παραδοχές} \label{section:1-6-typography} |
||||
|
|
||||
|
Η συγγραφή του παρόντος εγγράφου έγινε στο ηλεκτρονικό, τυπογραφικό σύστημα \LaTeX. Στο εξής, το παρόν έγγραφο, η εργασία στην οποία αναφέρεται το έγγραφο αυτό, όπως και οποιοδήποτε μέρος της εργασίας αυτής, θα αναφέρονται στο κείμενο ως "διπλωματική" ή "πτυχιακή" ή "εργασία" ή "αναφορά". |
||||
|
|
||||
|
Ο πηγαίος κώδικας του παρόντος εγγράφου μπορεί να βρεθεί στο αντίστοιχο αποθετήριο κώδικα της διπλωματικής εργασίας\footnote{Δημόσιο αποθετήριο κώδικα αναφοράς της διπλωματικής \url{https://gitlab.com/ecentrics/thesis-report}.}. |
@ -1,4 +1,4 @@ |
|||||
\section{Οργάνωση κεφαλαίων}\label{section:1-6-document-structure} |
\section{Οργάνωση κεφαλαίων}\label{section:1-7-document-structure} |
||||
|
|
||||
Η παρούσα διπλωματική εργασία οργανώνεται σε κεφάλαια, ενότητες και υποενότητες, όπως αυτά διατυπώνονται στα \hyperref[toc]{Περιεχόμενα}. Πιο συγκεκριμένα: |
Η παρούσα διπλωματική εργασία οργανώνεται σε κεφάλαια, ενότητες και υποενότητες, όπως αυτά διατυπώνονται στα \hyperref[toc]{Περιεχόμενα}. Πιο συγκεκριμένα: |
||||
|
|
@ -1,17 +1,25 @@ |
|||||
\section{Blockchain} \label{section:2-5-blockchain} |
\section{Blockchain} \label{section:2-5-blockchain} |
||||
|
|
||||
Το blockchain αποτελεί μία διανεμημένη δημόσια σειρά δεδομένων, που διατηρεί έναν αμετάβλητο ως προς το ιστορικό του κατάλογο (immutable ledger) ψηφιακών συναλλαγών (digital transactions) ενός αγαθού (asset), π.χ. ενός νομίσματος (token). Περιγράφηκε για πρώτη φορά το 2008 από ένα άτομο (ή μία ομάδα ανθρώπων) γνωστό ως Satoshi Nakamoto, αποτελώντας τη βάση του κρυπτονομίσματος (cryptocurrency) Bitcoin.\cite{2.5-bitcoin} |
Το blockchain αποτελεί μία διανεμημένη δημόσια σειρά δεδομένων, που διατηρεί έναν αμετάβλητο ως προς το ιστορικό του κατάλογο (immutable ledger) ψηφιακών συναλλαγών (digital transactions) ενός αγαθού (asset), π.χ. ενός νομίσματος (currency ή token). Περιγράφηκε για πρώτη φορά το 2008 από ένα άτομο (ή μία ομάδα ανθρώπων) γνωστό ως Satoshi Nakamoto, αποτελώντας τη βάση του κρυπτονομίσματος (cryptocurrency) Bitcoin.\cite{2.5-bitcoin} |
||||
|
|
||||
Δομικό στοιχείο του blockchain είναι το μπλοκ (block), το οποίο περιέχει μία ομάδα έγκυρων συναλλαγών που έχουν κατακερματιστεί και κωδικοποιηθεί σε ένα δένδρο Merkle, το hash του προηγούμενου μπλοκ και μερικά ακόμα μεταδεδομένα (π.χ. nonce, timestamp). Έτσι, κάθε νέο μπλοκ "δείχνει" στο προηγούμενό του μέσω του hash, επιβεβαιώνοντας την ακεραιότητά του, με τα διαδεχόμενα μπλοκ να σχηματίζουν τελικά μία αλυσίδα, μέχρι το αρχικό μπλοκ, το οποίο είναι γνωστό ως το μπλοκ γένεσης (genesis block).\cite{2.5-blockchain} |
Δομικό στοιχείο του blockchain είναι το μπλοκ (block), το οποίο περιέχει μία ομάδα έγκυρων συναλλαγών που έχουν κατακερματιστεί και κωδικοποιηθεί σε ένα δένδρο Merkle, το hash του προηγούμενου μπλοκ και μερικά ακόμα μεταδεδομένα (π.χ. nonce, timestamp). Έτσι, κάθε νέο μπλοκ "δείχνει" στο προηγούμενό του μέσω του hash, επιβεβαιώνοντας την ακεραιότητά του, με τα διαδεχόμενα μπλοκ να σχηματίζουν τελικά μία αλυσίδα, μέχρι το αρχικό μπλοκ, το οποίο είναι γνωστό ως το μπλοκ γένεσης (genesis block).\cite{2.5-blockchain} |
||||
|
|
||||
%TODO: add image like https://cdn.hackernoon.com/hn-images/1*qYKsqQ6aV-DgFD0REfcnig.png or https://ethereum.org/static/6f7d50fd4fab9f8abb94b5e610ade7e4/bf8c1/ethereum-blocks.png --- add that this is simplified |
\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 που απλά αναμεταδίδει την συναλλαγή που επιθυμεί να πραγματοποιήσει ο χρήστης. |
Ως προς την κυριότητα επί αυτού, το blockchain συνήθως\footnote{Υπάρχουν και κάποιες υλοποιήσεις ιδιωτικών blockchain που, όμως, δε θα μας απασχολήσουν.} δεν ελέγχεται από κάποια κεντρική οντότητα, αλλά διατηρείται από ένα δημόσιο P2P δίκτυο. Οι κόμβοι (nodes) του δικτύου συμμορφώνονται συλλογικά με ένα πρωτόκολλο συναίνεσης (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. |
Η διευθυνσιοδότηση σε ένα blockchain επιτυγχάνεται αξιοποιώντας την κρυπτογραφία δημόσιου κλειδιού. Το πρωτόκολλο του εκάστοτε blockchain ορίζει έναν αλγόριθμο για την παραγωγή ζευγών κλειδιών (π.χ. ECDSA στο Bitcoin). Το δημόσιο από αυτά ορίζει τη διεύθυνση, ενώ το ιδιωτικό παραμένει μυστικό, υπό την κατοχή του χρήστη. Με αυτό τον τρόπο προκύπτει ένα πρακτικά ανεξάντλητο πλήθος πιθανών έγκυρων δημόσιων διευθύνσεων (π.χ. $2^{160}$ για το Bitcoin), στις οποίες οι χρήστες μπορούν να στέλνουν και να λαμβάνουν ποσά του εκάστοτε κρυπτονομίσματος. Για την αποστολή ενός ποσού, δηλώνουν το fee που επιθυμούν να καταβάλουν και υπογράφουν την επιθυμητή συναλλαγή με το ιδιωτικό τους κλειδί. Η συναλλαγή αναμεταδίδεται στο δίκτυο και παραμένει στο transaction pool μέχρις ότου να γίνει αποδεκτή και να συμπεριληφθεί στο επόμενο block. |
||||
|
|
||||
Από τεχνική σκοπιά, το blockchain μπορεί να θεωρηθεί ως μία μηχανή καταστάσεων βασισμένη σε συναλλαγές (transaction-based state machine). Δηλαδή, ξεκινάει από μία αρχική κατάσταση (genesis state), η οποία τροποποιείται σταδιακά με κάθε block, και περιλαμβάνει ανά πάσα στιγμή τις διευθύνσεις με τα ποσά των νομισμάτων που τις αντιστοιχούν. |
Από τεχνική σκοπιά, το blockchain μπορεί να θεωρηθεί ως μία μηχανή καταστάσεων βασισμένη σε συναλλαγές (transaction-based state machine). Δηλαδή, ξεκινάει από μία αρχική κατάσταση (genesis state), η οποία τροποποιείται σταδιακά με κάθε block, και περιλαμβάνει ανά πάσα στιγμή τις διευθύνσεις με τα ποσά των νομισμάτων που τις αντιστοιχούν. |
||||
|
|
||||
%TODO: add image like ethereum-evm-illustrated page 9 or https://ethereum.org/static/0aeff9bcdfb1f5fd002610b4a5cff197/460fa/ethereum-state-transition.png |
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.3.blockchain.world.state} |
||||
|
\caption{Blockchain ως μηχανή καταστάσεων} |
||||
|
\end{figure} |
||||
|
|
||||
Σύμφωνα με την ανάλυση της ενότητας \ref{section:1-2-decentralization}, το blockchain είναι αρχιτεκτονικά και πολιτικά αποκεντρωτικό, καθώς δεν διαθέτει δοκιμκά κάποιο κεντρικό σημείο αποτυχίας, ούτε ελέγχεται από κάποιον. Ωστόσο, είναι λογικά συγκεντρωτικό, αφού υπάρχει μία κοινά αποδεκτή κατάσταση και το σύστημα συμπεριφέρεται μακροσκοπικά ως ένας ενιαίος υπολογιστής. |
Σύμφωνα με την ανάλυση της ενότητας \ref{section:1-2-decentralization}, το blockchain είναι αρχιτεκτονικά και πολιτικά αποκεντρωτικό, καθώς δε διαθέτει δομικά κάποιο κεντρικό σημείο αποτυχίας, ούτε ελέγχεται από κάποιον. Ωστόσο, είναι λογικά συγκεντρωτικό, αφού υπάρχει μία κοινά αποδεκτή κατάσταση και το σύστημα συμπεριφέρεται μακροσκοπικά ως ένας ενιαίος υπολογιστής. |
||||
|
@ -1,3 +1,15 @@ |
|||||
\section{Μεθολογία σχεδίασης} \label{section:3-3.design-methodology} |
\section{Μεθοδολογία σχεδίασης} \label{section:3-3-design-methodology} |
||||
|
|
||||
% TODO: add Agile stuff etc |
Στον χώρο της τεχνολογίας λογισμικού υπάρχουν διάφορες μεθοδολογίες σχεδίασης οι οποίες έχουν μεταξύ τους κοινά στοιχεία. Αυτό καθιστά δύσκολο τον προσδιορισμό μίας μόνο μεθοδολογίας η οποία ακολουθείται πιστά σε κάθε έργο. Συνήθως, οι ομάδες που αναπτύσσουν το λογισμικό ακολουθούν μία μίξη από διάφορα εργαλεία, όπου αυτά κρίνονται βολικά για τους στόχους της ομάδας. % todo: need reference for this |
||||
|
|
||||
|
Κατά την σχεδίαση και την υλοποίηση του κώδικα ακολουθήθηκαν διάφορες τεχνικές και μοτίβα ανάπτυξης. Κατά βάση χρησιμοποιήθηκαν Agile μέθοδοι όπως το Kanban και Scrum και, αργότερα στην ανάπτυξη, το DevOps μοντέλο για διαρκή ενσωμάτωση (Continuous Integration) και διαρκή εγκατάσταση (Continuous Deployment). |
||||
|
|
||||
|
Για την παρούσα εργασία, πραγματοποιήθηκε ανάλυση και σχεδιασμός των επιμέρους μονάδων εργασίας (tasks) πριν την έναρξη της διαδικασίας ανάπτυξης του κώδικα. Τα tasks που προδιαγράφηκαν ήταν συνήθως epics\footnote{Τα epics είναι μεγάλες μονάδες εργασίας οι οποίες αφορούν κάποιο βασικό χαρακτηριστικό. Ο διαχωρισμός τους σε επιμέρους tasks αναβάλλεται με σκοπό την καλύτερη κατανόηση των αναγκών τους.} τα οποία αργότερα χωρίστηκαν σε επιμέρους, μικρότερα tasks. Ορίστηκαν επίσης ορόσημα (milestones) τα οποία βοήθησαν ιδιαίτερα στην ιεράρχηση και προτεραιοποίηση των tasks. |
||||
|
|
||||
|
Το Kanban είναι μία μέθοδος οργάνωσης έργων και οπτικοποίησης των μονάδων εργασίας (tasks) που απαιτούνται για την ολοκλήρωσή τους. Στο Kanban ορίζονται τα βασικά στάδια της ροής ενός task και χρησιμοποιούνται οπτικά μέσα ώστε να γίνει ιχνηλάτηση τόσο της συνολικής κατάστασης του έργου, όσο και συγκεκριμένων-μεμονωμένων tasks καθώς αυτά προοδεύουν. Για κάθε στάδιο ολοκλήρωσης ορίζεται μία ξεχωριστή ουρά εργασιών (στήλη), για παράδειγμα "σε αναμονή", "σε εξέλιξη", "ολοκληρωμένο". Χρησιμοποιούνται οπτικά σινιάλα (χρώματα, tags και άλλα) για τον διαχωρισμό και την γρήγορη κατανόηση των σημαντικότερων γνωρισμάτων των tasks, για παράδειγμα ξεχωριστό tag για κάθε υπηρεσία στην οποία αναφέρεται το task. Επίσης, ορίζονται όρια στον αριθμό των tasks που μπορούν να είναι ταυτόχρονα σε εξέλιξη. |
||||
|
|
||||
|
Μία άλλη Agile μέθοδος είναι το Scrum. Το Scrum χρησιμοποιεί και επεκτείνει το Kanban. Η βασικές διαφορές του με το Kanban είναι ότι στο Scrum υπάρχουν πιο αυστηρές διαδικασίες. Ορίζονται προγραμματιστικοί κύκλοι (sprints) οι οποίοι έχουν συγκεκριμένες ημερομηνίες έναρξης και λήξης και συγκεκριμένους στόχους οι οποίοι αντικατοπτρίζονται σε στόχους ολοκλήρωσης ορισμένων tasks. Οι ρόλοι είναι σαφέστεροι, με κάθε μέλος της ομάδας να αναλαμβάνει διαφορετικές ευθύνες στην οργάνωση και εκτέλεση. Για την διαδικασία ανάπτυξης, υπήρξε πολύ χρήσιμη η χρήση του Scrum σε περιόδους όπου ήταν αναγκαία η ταχύτατη ανάπτυξη καίριων μερών του συστήματος. Λόγω της αυστηρότητας που επιβάλλεται από αυτό, ειδικά σε ό,τι αφορά τις προθεσμίες ολοκλήρωσης των επιμέρους tasks αλλά και του συνολικού sprint. |
||||
|
|
||||
|
Καθώς η αναπτυξιακή διαδικασία ωριμάζει και η πλατφόρμα αποτελεί ένα βιώσιμο προϊόν, είναι χρήσιμη η ύπαρξη ενός συστήματος που να διευκολύνει την άμεση δημιουργία και δημοσίευση των νεότερων εκδόσεων. Μερικές εξαιρετικές μέθοδοι για την απρόσκοπτη και αυτοματοποιημένη επίτευξη του στόχου αυτού ορίζονται από το DevOps. Με τον όρο DevOps (development operations) αναφέρεται μία κουλτούρα σχεδίασης και ανάπτυξης λογισμικού που ορίζει τους ρόλους, τις διαδικασίες και τεχνολογίες της με σκοπό την συνεχή δημιουργία αξίας για τους χρήστες. Το DevOps έχει πολύ στενή σχέση με το Agile και αποτελεί την συνέχιση της νοοτροπίας αυτής στον χώρο. |
||||
|
|
||||
|
Μία από τις πιο χρήσιμες πτυχές του DevOps, η οποία χρησιμοποιήθηκε στην διπλωματική, είναι το CI/CD το οποίο περιγράφει τις διαδικασίες αυτοματοποίησης των εργασιών ενσωμάτωσης (integration), ελέγχου (testing), παράδοσης (delivery) και εγκατάστασης (deployment) του προϊόντος. Μέσω των διαδικασιών αυτών αφαιρείται η ανάγκη ανθρώπινης αλληλεπίδρασης για την ολοκλήρωση των σταδίων αυτών, ενώ επιτυγχάνεται η διαρκής και απρόσκοπτη διάθεση της τελευταίες έκδοσης της πλατφόρμας στους χρήστες. Ορίζονται επίσης διαδικασίες δημιουργίας περιβάλλοντος ελέγχου (staging deploys) το οποίο αποτελεί σημαντικό βοήθημα στον έγκαιρο εντοπισμό λαθών του κώδικα. |
||||
|
@ -0,0 +1,70 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 10 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 10: Δημιουργία κοινότητας} \label{subsection:3-10-use-case-create-community} |
||||
|
|
||||
|
Το σενάριο χρήσης 10, <ΣΧ-10>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την δημιουργία μίας κοινότητας. Στους πίνακες \ref{table:3-6-use-case-create-community} και \ref{table:3-6-use-case-create-community-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-10> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-create-community-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Δημιουργώ νέα κοινότητα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να δημιουργήσει νέα κοινότητα.} |
||||
|
{\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}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί δημιουργίας νέας κοινότητας. & Το σύστημα εμφανίζει την φόρμα ``Δημιουργία Κοινότητας''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί ``Υποβολή''. & Το σύστημα δημιουργεί νέα κοινότητα στο blockchain. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα μεταβαίνει στην σελίδα της νέας κοινότητας.} |
||||
|
{Σενάριο χρήσης 10 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-create-community-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-create-community-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 10 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-create-community-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
|
|
||||
|
% ===== 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} όπου παρουσιάζεται το διάγραμμα ροής της. |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{1} |
||||
|
{Ο χρήστης ορίζει εξωτερικό contract για την κοινότητα.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει ``Προσθήκη Συμβολαίου'' το σύστημα ανανεώνει την σελίδα προσθέτοντας τα επιπλέον πεδία της φόρμας ``Σύνδεση Συμβολαίου''.} |
||||
|
{ |
||||
|
1 & Ο χρήστης, αφού συμπληρώσει τη φόρμα ``Δημιουργία Κοινότητας'', πατάει το κουμπί ``Προσθήκη ψηφοφορίας'' & Το σύστημα ανανεώνει τη σελίδα με τα πεδία της φόρμας ``Σύνδεση Συμβολαίου''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί ``Υποβολή''. & Το σύστημα δημιουργεί την νέα κοινότητα στο blockchain και την συνδέει με το εξωτερικό contract. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα μεταβαίνει στην σελίδα της νέας κοινότητας.} |
||||
|
{Σενάριο χρήσης 10 - Εναλλακτική ροή 1} |
||||
|
{\label{table:3-6-use-case-create-community-alternate-flow-1}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-create-community-alternate-flow-1-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 3 - Διάγραμμα εναλλακτικής ροής 1} |
||||
|
\label{figure:3-6-use-case-create-community-alternate-flow-1-sequence-diagram} |
||||
|
\end{figure} |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{2} |
||||
|
{Ο χρήστης πατάει το κουμπί ``Άκυρο''.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής ή στη γραμμή 2 της Εναλλακτικής Ροής 1 επιλέξει ``Άκυρο'' το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής.} |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί ``Άκυρο'' & Το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής. |
||||
|
} |
||||
|
{Το σενάριο χρήσης τερματίζεται.} |
||||
|
{Σενάριο χρήσης 10 - Εναλλακτική ροή 2} |
||||
|
{\label{table:3-6-use-case-create-community-alternate-flow-2}} |
@ -0,0 +1,9 @@ |
|||||
|
\subsection{Αρθρώματα} \label{subsection:4-3-1-software-units} |
||||
|
|
||||
|
Σε αυτό το κεφάλαιο θα περιγραφούν με μεγαλύτερη λεπτομέρεια τα αρθρώματα που αναπτύχθηκαν. |
||||
|
|
||||
|
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.concordia-shared-unit} |
||||
|
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.concordia-contracts-unit} |
||||
|
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-identity-provider-unit} |
||||
|
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-drizzle-unit} |
||||
|
\input{chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-breeze-unit} |
@ -0,0 +1,5 @@ |
|||||
|
\subsubsection{Άρθρωμα concordia-contracts} \label{subsubsection:4-3-1-concordia-contracts-unit} |
||||
|
|
||||
|
Το άρθρωμα αυτό επιτελεί δύο ενέργειες. Αρχικά, είναι το άρθρωμα στο οποίο αναπτύσσονται τα contracts που χρησιμοποιούνται από την εφαρμογή. Το άρθρωμα αυτό αναλαμβάνει τη μεταγλώττιση των contracts από κώδικα γλώσσας Solidity, στην κατάλληλη τελική μορφή JSON. Παρέχονται επίσης σενάρια ενεργειών (scripts) ώστε τα contracts να μεταφορτωθούν σε blockchain καθώς και στην υπηρεσία \hyperref[subsection:4-3-5-concordia-contracts-provider-service]{Concordia Contracts Provider}. Αποτελεί επίσης βιβλιοθήκη η οποία μετά τη μεταγλώττιση και μεταφόρτωση των contracts σε blockchain παρέχει τα contract artifacts. Χρησιμοποιείται από τις υπηρεσίες \hyperref[subsection:4-3-2-concordia-application-service]{Concordia Application} και \hyperref[subsection:4-3-4-concordia-pinner-service]{Concordia Pinner}. |
||||
|
|
||||
|
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή τοπικής βιβλιοθήκης με τη χρήση της δυνατότητας yarn workspaces. |
@ -0,0 +1,5 @@ |
|||||
|
\subsubsection{Άρθρωμα concordia-shared} \label{subsubsection:4-3-1-concordia-shared-unit} |
||||
|
|
||||
|
Το άρθρωμα concordia-shared αποτελεί μία βιβλιοθήκη χρήσιμων εργαλείων και σταθερών. Εδώ περιέχεται όλο το λογισμικό το οποίο πρέπει ή είναι επιθυμητό να συμπεριφέρεται με τον ίδιο τρόπο συνολικά στο σύστημα, όπως για παράδειγμα μέθοδοι παραμετροποίησης των υπηρεσιών και μέθοδοι καταγραφής (logging). Το άρθρωμα αυτό χρησιμοποιείται από το άρθρωμα \hyperref[subsubsection:4-3-1-concordia-contracts-unit]{concordia-contracts} καθώς και από τις υπηρεσίες \hyperref[subsection:4-3-2-concordia-application-service]{Concordia Application}, \hyperref[subsection:4-3-4-concordia-pinner-service]{Concordia Pinner} και \hyperref[subsection:4-3-5-concordia-contracts-provider-service]{Concordia Contracts Provider}. |
||||
|
|
||||
|
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή τοπικής βιβλιοθήκης με τη χρήση της δυνατότητας διαχείρισης μοναδικού αποθετηρίου κώδικα (monorepo) yarn workspaces{\footnote{\url{https://yarnpkg.com/features/workspaces}}}. |
@ -0,0 +1,7 @@ |
|||||
|
\subsubsection{Άρθρωμα breeze} \label{subsubsection:4-3-1-eth-breeze-unit} |
||||
|
|
||||
|
Το άρθρωμα αυτό αναπτύχθηκε στα πλαίσια της διπλωματικής εργασίας και αποτελεί μία βιβλιοθήκη περίβλημα (wrapper) της βιβλιοθήκης \hyperref[subsection:4-2-4-2-orbit-db]{OrbitDB}, η οποία παρέχει ένα \hyperref[subsection:4-2-2-2-redux]{Redux} store. |
||||
|
|
||||
|
Με τη συμπερίληψη του αρθρώματος στο κεντρικό Redux store της εφαρμογής, παρέχεται η δυνατότητα εκτέλεσης των λειτουργιών των OrbitDB βάσεων εντός του γενικότερου flow του frontend της εφαρμογής. Έτσι, οι προγραμματιστικές διεπαφές που προσφέρει η Orbit χρησιμοποιούνται πλέον μέσα από actions, reducers και middleware. |
||||
|
|
||||
|
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του μητρώου λογισμικού npm (\url{https://www.npmjs.com/package/@ecentrics/breeze}), ενώ το αποθετήριό του βρίσκεται στο GitLab (\url{https://gitlab.com/ecentrics/breeze}). |
@ -0,0 +1,7 @@ |
|||||
|
\subsubsection{Άρθρωμα drizzle} \label{subsubsection:4-3-1-eth-drizzle-unit} |
||||
|
|
||||
|
Το άρθρωμα drizzle που χρησιμοποιείται στην υπηρεσία \hyperref[subsection:4-3-2-concordia-application-service]{Concordia Application} είναι μία τροποποιημένη έκδοση της JavaScript βιβλιοθήκης Drizzle (και συγκεκριμένα του @drizzle/store\footnote{\url{https://github.com/trufflesuite/drizzle/tree/develop/packages/store}}), η οποία προσφέρεται από τη σουίτα εργαλείων Truffle. Η τροποποιημένη βιβλιοθήκη αναπτύχθηκε στα πλαίσια της διπλωματικής με στόχο τη διευκόλυνση της χρήσης του Drizle και την επιδιόρθωση προβληματικών σημείων της πρωτότυπης βιβλιοθήκης. |
||||
|
|
||||
|
Το άρθρωμα drizzle υλοποιεί τις προγραμματιστικές διεπαφές μέσω των οποίων πραγματοποιείται η επικοινωνία της εφαρμογής με το blockchain. Για την επίτευξη της επικοινωνίας αυτής, η βιβλιοθήκη χρησιμοποιεί τη συλλογή βιβλιοθηκών web3.js η οποία αποτελεί τον πιο διαδεδομένο τρόπο διεπαφής με το blockchain σε αποκεντρωτικές εφαρμογές. Τελικά, παρέχει ένα Redux store, το οποίο συμπεριλαμβάνεται στο κεντρικό store της εφαρμογής. |
||||
|
|
||||
|
Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του μητρώου λογισμικού npm (\url{https://www.npmjs.com/package/@ecentrics/drizzle}), ενώ το αποθετήριό του βρίσκεται στο GitLab (\url{https://gitlab.com/ecentrics/drizzle}). |
@ -0,0 +1,16 @@ |
|||||
|
\subsubsection{Άρθρωμα eth-identity-provider} \label{subsubsection:4-3-1-eth-identity-provider-unit} |
||||
|
|
||||
|
Η λειτουργία της βάσης OrbitDB επιτρέπει τη χρήση προσαρμοσμένων orbit-db-identity-provider, οι οποίοι θα δημιουργούν και θα επικυρώνουν |
||||
|
τα μοναδικά αναγνωριστικά των χρήστών (OrbitDB Identity) βάσει προσαρμοσμένων εξωτερικών αναγνωριστικών (external identifier), όπως παρουσιάζεται στο σχήμα \ref{figure:4-2-4-2-orbit-db-identity}. |
||||
|
|
||||
|
Στην περίπτωση της εφαρμογής Concordia είναι χρήσιμο να μπορούν να υπολογιστούν με ντετερμινιστικό τρόπο οι OrbitDB βάσεις δεδομένων του κάθε χρήστη, για λόγους απλότητας και εξοικονόμησης αποθηκευτικού χώρου επί του blockchain. Έτσι, αφού κάθε χρήστης ορίζεται μοναδικά μέσω της διεύθυνσης Ethereum με την οποία εγγράφεται και συνδέεται, αυτή θα πρέπει να αποτελεί και το εξωτερικό αναγνωριστικό στο πεδίο id της OrbitDB Identity. |
||||
|
|
||||
|
Για αυτόν το λόγο υλοποιήθηκε το άρθρωμα eth-identity-provider, το οποίο: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item Παράγει ένα OrbitDB Identity για τον χρήστη, με id τον συνδυασμο του Ethereum address του και του address του κεντρικού contract της εφαρμογής\footnote{Το δεύτερο εισήχθη για την αποφυγή προβλημάτων σε πολλαπλές αναπτύξεις συμβολαίων.}. Αυτό επιτυγχάνεται με την υπογραφή μίας συναλλαγής με το Ethereum private key του χρήστη, μέσω του MetaMask. |
||||
|
\item Επικυρώνει τις OrbitDB Identity που απαιτούνται, εξασφαλίζοντας ότι υπογράφηκαν από τα Ethereum private key των κατόχων τους. |
||||
|
\item Διασφαλίζει ντετερμινιστικές, υπολογίσιμες διευθύνσεις OrbitDB βάσεων για τον κάθε χρήστη. |
||||
|
\end{itemize} |
||||
|
|
||||
|
Το eth-identity-provider γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του μητρώου λογισμικού npm (\url{https://www.npmjs.com/package/@ecentrics/eth-identity-provider}), ενώ το αποθετήριό του βρίσκεται στο GitLab (\url{https://gitlab.com/ecentrics/eth-identity-provider}). |
@ -0,0 +1,45 @@ |
|||||
|
\subsection{Concordia Application} \label{subsection:4-3-2-concordia-application-service} |
||||
|
|
||||
|
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
||||
|
|
||||
|
\logo{chapter-4/4.3.concordia-logo}{Concordia logo} |
||||
|
|
||||
|
Η εφαρμογή Concordia (Concordia Application) εκθέτει τις γραφικές διεπαφές μέσω των οποίων αλληλεπιδρούν οι χρήστες με το σύστημα. Αποτελεί τον δίαυλο επικοινωνίας του τελικού χρήστη με το blockchain και με τη βάση OrbitDB. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο σχήμα \ref{figure:4-3-concordia-application-architecture}. Μέσω της εφαρμογής Concordia οι χρήστες μπορούν: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item Να περιηγούνται και να διαβάζουν το περιεχόμενο της πλατφόρμας |
||||
|
|
||||
|
\item Να δημιουργήσουν λογαριασμό χρήστη |
||||
|
|
||||
|
\item Να δημοσιεύουν και να τροποποιούν προσωπικές τους πληροφορίες, όπως η τοποθεσία και η εικόνα προφίλ |
||||
|
|
||||
|
\item Να δημιουργούν θέματα (topics) |
||||
|
|
||||
|
\item Να δημιουργούν και να τροποποιούν μηνύματα (posts) |
||||
|
|
||||
|
\item Να δημιουργούν ψηφοφορίες (polls), καθώς και να ψηφίζουν σε αυτές (εφόσον έχουν το δικαίωμα) |
||||
|
|
||||
|
\item Να υπερψηφίζουν (up-vote) ή να καταψηφίζουν (down-vote) μηνύματα άλλων χρηστών |
||||
|
\end{itemize} |
||||
|
|
||||
|
Η υπηρεσία αποτελείται από κώδικα γραμμένο σε JavaScript, ο οποίος γίνεται διαθέσιμος στους τελικούς χρήστες με τη μορφή εφαρμογής διαδικτύου (web application) μέσω ενός διακομιστή (server). Παρόλο που η υπηρεσία προσφέρει τη γραφική διεπαφή χρήστη μόνο στην αγγλική γλώσσα, έχει παραμετροποιηθεί ώστε να είναι δυνατή η εύκολη μεταγλώττιση της χωρίς την ανάγκη πραγματοποίησης μεγάλων αλλαγών στον κώδικα. |
||||
|
|
||||
|
Χρησιμοποιείται η βιβλιοθήκη \hyperref[subsection:4-2-2-1-react]{React} για την οργάνωση και ανάπτυξη των συνθετικών τμημάτων (components) του γραφικού περιβάλλοντος. Για το γραφικό περιβάλλον γίνεται χρήση του framework της Semantic UI\footnote{\url{https://semantic-ui.com/}}. Χρησιμοποιείται η βιβλιοθήκη \hyperref[subsection:4-2-2-2-redux]{Redux} για τη διαχείριση κατάστασης της εφαρμογής (state management), |
||||
|
καθώς και η βιβλιοθήκη \hyperref[subsection:4-2-2-3-redux-saga]{Redux-Saga} για τη διαχείριση ασύγχρονων παράπλευρων ενεργειών (side-effects) σε ένα σύστημα βασισμένο σε συμβάντα (event-based). Άλλες βιβλιοθήκες χρησιμοποιούνται για διάφορα μέρη της υπηρεσίας, ενώ χρησιμοποιούνται επίσης τα αρθρώματα που περιγράφηκαν προηγουμένως για την επίτευξη διαφορετικών στόχων. Ο πλήρης κατάλογος των βιβλιοθηκών και αρθρωμάτων μπορεί να βρεθεί στον κώδικα της υπηρεσίας στο παράρτημα. % todo: add reference to the appendix containing the code or a link to it in the repo |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png} |
||||
|
\caption{Αρχιτεκτονική υπηρεσίας Concordia Application} |
||||
|
\label{figure:4-3-concordia-application-architecture} |
||||
|
\end{figure} |
||||
|
|
||||
|
Για τη λειτουργία της υπηρεσία Concordia Application είναι απαραίτητα τα αντικείμενα (artifacts) που προκύπτουν από τη μεταγλώττιση των contracts και τη μεταφόρτωση/δημοσίευσή τους στο blockchain. Για την εισαγωγή των artifacts στην υπηρεσία έχουν αναπτυχθεί δύο μέθοδοι. |
||||
|
|
||||
|
Η πρώτη μέθοδος είναι η μεταγλώττιση και μεταφόρτωση των contracts πριν την παραγωγή του πακέτου λογισμικού της υπηρεσίας για τελική χρήση (production build). Με αυτόν τον τρόπο η υπηρεσία θα έχει πρόσβαση στα artifacts μέσω της βιβλιοθήκης που παράγεται από το άρθρωμα concordia-contracts. Αυτή η μέθοδος έχει το μειονέκτημα ότι το τελικό πακέτο λογισμικού (production build) "δένεται" με όποια συγκεκριμένη έκδοση των contracts είναι διαθέσιμη κατά τη δημιουργία του πακέτου. Αυτό σημαίνει ότι σε ενδεχόμενη ενημέρωση των contracts πρέπει αναγκαστικά να δημιουργηθεί και νέα έκδοση του πακέτου λογισμικού της υπηρεσίας Concordia Application. |
||||
|
|
||||
|
Για την αποφυγή του παραπάνω προβλήματος αναπτύχθηκε η δεύτερη μέθοδος προσκόμισης των contract artifacts, η οποία είναι η λήψη τους (download) από μία άλλη τοποθεσία στο διαδίκτυο. Σε αυτή τη μέθοδο, η εφαρμογή κατά την εκκίνησή της πραγματοποιεί ένα HTTP αίτημα (HTTP request) σε διεύθυνση η οποία δίνεται ως μεταβλητή περιβάλλοντος (environment variable). Η απάντηση του αιτήματος αναμένεται να περιέχει τα artifacts ώστε η εφαρμογή να τα χρησιμοποιήσει. |
||||
|
|
||||
|
\subsubsection{Διανομή} |
||||
|
|
||||
|
Η υπηρεσία Concordia Application πακετάρεται μαζί με τον διακομιστή nginx και γίνεται διαθέσιμη για χρήση ως εικόνα docker (docker image) μέσω του αποθετηρίου εικόνων dockerhub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της εκτέλεσης όπως η διεύθυνση του εξυπηρετητή (host location) της εφαρμογής και οι τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider. |
@ -0,0 +1,16 @@ |
|||||
|
\subsection{Concordia Contracts Migrator} \label{subsection:4-3-3-concordia-contracts-migrator} |
||||
|
|
||||
|
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
||||
|
|
||||
|
Η υπηρεσία αυτή αποτελείται από ένα εκτελέσιμο πρόγραμμα γραμμής εντολών βασισμένο στο άρθρωμα concordia-contracts που αναλύθηκε σε προηγούμενη υποενότητα (\ref{subsection:4-3-1-software-units}). Το πρόγραμμα, κατά την εκτέλεσή του, μεταγλωττίζει τα contracts και έπειτα τα μεταφορτώνει στο blockchain το οποίο είναι ορισμένο με χρήση μεταβλητών περιβάλλοντος. Τέλος, αν οι κατάλληλες μεταβλητές περιβάλλοντος είναι ορισμένες, το πρόγραμμα μεταφορτώνει τα τελικά artifacts σε αποθετήριο Concordia Contracts Provider. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-concordia-contracts-migrator-architecture}). |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png} |
||||
|
\caption{Αρχιτεκτονική υπηρεσίας Concordia Contracts Migrator} |
||||
|
\label{figure:4-3-concordia-contracts-migrator-architecture} |
||||
|
\end{figure} |
||||
|
|
||||
|
\subsubsection{Διανομή} |
||||
|
|
||||
|
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν τη διεύθυνση του blockchain και την τοποθεσία της υπηρεσίας Contracts Provider στην οποία το πρόγραμμα θα μεταφορτώσει τα contracts και τα artifacts. |
@ -0,0 +1,21 @@ |
|||||
|
\subsection{Concordia Pinner} \label{subsection:4-3-4-concordia-pinner-service} |
||||
|
|
||||
|
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
||||
|
|
||||
|
Η υπηρεσία καρφιτσώματος περιεχομένου (Concordia Pinner) αποτελεί μία εφαρμογή τερματικού (temrinal application/cmd application) η οποία στοχεύει στο καρφίτσωμα (pinning) του περιεχομένου που αποθηκεύεται στο IPFS μέσω της βάσης OrbitDB. Η υπηρεσία είναι γραμμένη στη γλώσσα προγραμματισμού JavaScript. Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-3-concordia-pinner-architecture}. |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png} |
||||
|
\caption{Αρχιτεκτονική υπηρεσίας Concordia Pinner} |
||||
|
\label{figure:4-3-concordia-pinner-architecture} |
||||
|
\end{figure} |
||||
|
|
||||
|
Η υπηρεσία αυτή υλοποιήθηκε για να εγγυηθεί η διαθεσιμότητα του περιεχομένου του συστήματος που αποθηκεύεται στο IPFS (τίτλοι θεμάτων, περιεχόμενο μηνυμάτων και άλλα). Λόγω του τρόπου λειτουργίας του IPFS, το περιεχόμενο που αναρτούν οι χρήστες πρέπει να καρφιτσώνεται από άλλους χρήστες ή αυτόνομες εφαρμογές, όπως η υπηρεσία Concordia Pinner, ώστε να είναι διαθέσιμο. Αν το περιεχόμενο δεν καρφιτσωθεί, τότε θα είναι διαθέσιμο στους υπόλοιπους χρήστες μόνο από |
||||
|
τον δημιουργό του, έτσι αν αυτός δεν είναι ενεργός στο δίκτυο, το περιεχόμενο θα είναι αδύνατο να βρεθεί. |
||||
|
|
||||
|
Η υπηρεσία συνδέεται στο blockchain από όπου παρακολουθεί την κατάσταση του συστήματος και "ακούει" για νέους χρήστες, θέματα, μηνύματα και ψηφοφορίες. Η υπηρεσία συνδέεται επίσης στο IPFS, έτσι όταν δημιουργηθεί νέο περιεχόμενο στο σύστημα το καρφιτσώνει αυτόματα. Με αυτό τον τρόπο, διατηρώντας την υπηρεσία πάντα διαθέσιμη, για παράδειγμα εκτελώντας τη σε περιβάλλον διακομιστή (server), διαβεβαιώνεται η διαθεσιμότητα του περιεχομένου. |
||||
|
|
||||
|
\subsubsection{Διανομή} |
||||
|
|
||||
|
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της υπηρεσίας όπως τη διεύθυνση του εξυπηρετητή (host location), τη διεύθυνση του blockchain, τις διαδρομές αποθήκευσης των δεδομένων στο σύστημα και τις τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider. |
@ -0,0 +1,18 @@ |
|||||
|
\subsection{Concordia Contracts Provider} \label{subsection:4-3-5-concordia-contracts-provider-service} |
||||
|
|
||||
|
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
||||
|
|
||||
|
Η υπηρεσία Contracts Provider αποτελεί μία βοηθητική υπηρεσία η οποία υλοποιεί ένα απλό αποθετήριο για τα contract artifacts. Είναι γραμμένη σε JavaScript και διαθέτει δύο HTTP \textenglish{endpoints}, ένα για τη μεταφόρτωση (upload) των artifacts προς την υπηρεσία και ένα για τη λήψη (download) από την υπηρεσία. Η υπηρεσία υποστηρίζει επίσης την επισύναψη ετικετών στα artifacts, όπως η έκδοση (version) ή το κλαδί ανάπτυξης (branch, για παράδειγμα \textenglish{master/develop}). Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-3-concordia-contracts-provider-architecture}. |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture} |
||||
|
\caption{Αρχιτεκτονική υπηρεσίας Concordia Contracts Provider} |
||||
|
\label{figure:4-3-concordia-contracts-provider-architecture} |
||||
|
\end{figure} |
||||
|
|
||||
|
Η υπηρεσία χρησιμοποιείται σε μία προσπάθεια αποσύνδεσης της βασικής εφαρμογής που υλοποιεί η υπηρεσία Concordia Application από μία συγκεκριμένη έκδοση των contracts. Οι λόγοι που αυτό είναι επιθυμητό αναπτύχθηκαν στην περιγραφή της υπηρεσίας Concordia \textenglish{Application} (υποενότητα \ref{subsection:4-3-2-concordia-application-service}). Ωστόσο, η υπηρεσία Contracts Provider αποτελεί σημείο κεντροποίησης του συστήματος, για το λόγο αυτό θεωρείται προσωρινή λύση η οποία θα μπορούσε να αντικατασταθεί από αποκεντρωτικές λύσεις όπως η μεταφόρτωση των artifacts στο IPFS και ο διαμοιρασμός τους από εκεί. |
||||
|
|
||||
|
\subsubsection{Διανομή} |
||||
|
|
||||
|
Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν παραμέτρους της εκτέλεσης, όπως τη διαδρομή αποθήκευσης των μεταφορτωμένων contract artifacts. |
@ -0,0 +1,9 @@ |
|||||
|
\subsection{Ganache} \label{subsection:4-3-6-ganache-service} |
||||
|
|
||||
|
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
||||
|
|
||||
|
Η συγκεκριμένη υπηρεσία αξιοποιεί την CLI έκδοση του \hyperref[subsection:4-2-3-2-ganache]{Ganache}, δημιουργώντας ένα τοπικό ιδιωτικό Ethereum blockchain για τους σκοπούς ανάπτυξης της εφαρμογής Concordia. |
||||
|
|
||||
|
\subsubsection{Διανομή} |
||||
|
|
||||
|
Για τη χρήση της υπηρεσίας αυτής αναπτύχθηκε μία νέα εικόνα docker που βασίζεται στην επίσημη εικόνα που διατίθεται από τη σουίτα και προσθέτει μερικές χρήσιμες λειτουργικότητες όπως η δυνατότητα αποκάλυψης των κλειδιών που δημιουργούνται κατά την εκτέλεση. Η υπηρεσία γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Η εικόνα παρέχει τη δυνατότητα τροποποίησης των παραμέτρων εκτέλεσης με χρήση μεταβλητών περιβάλλοντος. Με αυτό τον τρόπο οι χρήστες μπορούν να αλλάξουν τον αριθμό των λογαριασμών που θα δημιουργηθούν, το ποσό του Ether που θα λάβει κάθε λογαριασμός καθώς και άλλες μεταβλητές. |
@ -0,0 +1,9 @@ |
|||||
|
\subsection{Rendezvous Server} \label{subsection:4-3-7-rendezvous-server-service} |
||||
|
|
||||
|
\subsubsection{Περιγραφή - Στόχοι υπηρεσίας} |
||||
|
|
||||
|
Η υπηρεσία Rendezvous Server παρέχει έναν signalling server, ο οποίος υιοθετεί το \hyperref[subsection:4-2-4-3-libp2p]{Libp2p} πρωτόκολλο μεταφοράς δεδομένων libp2p-webrtc-star. Μέσω αυτού παρέχεται στους ομότιμους χρήστες (peers) η δυνατότητα ανακάλυψης των διευθύνσεων των υπόλοιπων χρηστών στο δίκτυο του IPFS. |
||||
|
|
||||
|
\subsubsection{Διανομή} |
||||
|
|
||||
|
Η υπηρεσία αυτή είναι διαθέσιμη για χρήση από τους δημιουργούς της τόσο ως εφαρμογή μέσω του αποθετηρίου λογισμικού npm αλλά και ως docker image μέσω του αποθετηρίου εικόνων dockerhub. |
@ -0,0 +1,26 @@ |
|||||
|
\subsection{Διασύνδεση υπηρεσιών} \label{subsection:4-3-8-service-communication} |
||||
|
|
||||
|
Στο μοντέλο των μικροϋπηρεσιών, βασικό χαρακτηριστικό είναι η επικοινωνία των ξεχωριστών υπηρεσιών και η ανταλλαγή μηνυμάτων για την επίτευξη των λειτουργικοτήτων του συστήματος. Σε αυτήν την υποενότητα θα αναλυθεί ο τρόπος με τον οποίο οι μικροϋπηρεσίες επικοινωνούν μεταξύ τους, καθώς και η φύση και το περιεχόμενο των μηνυμάτων που ανταλλάσουν. |
||||
|
|
||||
|
Στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-communications-graph}) φαίνεται ο γράφος που οπτικοποιεί τα κανάλια επικοινωνίας μεταξύ των μικροϋπηρεσιών, καθώς και τα κανάλια επικοινωνίας των μικροϋπηρεσιών με το blockchain. |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.9\textwidth]{assets/figures/chapter-4/4.3.communications-diagram.png} |
||||
|
\caption{Γράφος οπτικοποίησης των καναλιών επικοινωνίας των μικροϋπηρεσιών} |
||||
|
\label{figure:4-3-communications-graph} |
||||
|
\end{figure} |
||||
|
|
||||
|
Εδώ αναλύεται η επικοινωνία κάθε μικροϋπηρεσίας: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item \textbf{Contracts Migrator}: Η υπηρεσία εκτελεί αίτημα HTTP κατά την μεταφόρτωση των \textenglish{contracts} στο Ethereum blockchain. Eπίσης, εκτελεί αίτημα HTTP για την μεταφόρτωση των contract artifacts στην υπηρεσία Contracts Provider. |
||||
|
|
||||
|
\item \textbf{Concordia Application}: Η υπηρεσία εκτελεί αίτημα HTTP για την λήψη των contract \textenglish{artifacts} από την υπηρεσία Contracts Provider, εκτελεί αιτήματα HTTP για την διενέργεια συναλλαγών στο Ethereum blockchain και, τέλος, δημιουργεί κανάλι επικοινωνίας UDP με την υπηρεσία Rendezvous Server, για την ανακάλυψη ομότιμων χρηστών (peers) στο δίκτυο IPFS. |
||||
|
|
||||
|
\item \textbf{Pinner}: Η υπηρεσία εκτελεί αίτημα HTTP για την λήψη των contract artifacts από την υπηρεσία Contracts Provider, εκτελεί αιτήματα HTTP για την ανανέωση και παρατήρηση της κατάστασης του contract στο Ethereum blockchain και τέλος δημιουργεί κανάλι επικοινωνίας UDP με την υπηρεσία Rendezvous Server για την ανακάλυψη peers στο δίκτυο IPFS. |
||||
|
|
||||
|
\item \textbf{Rendezvous Server}: Η υπηρεσία διατηρεί ανοιχτά κανάλια επικοινωνίας UDP με τους ομότιμους χρήστες, μέσω των οποίων ενημερώνει την λίστα των διαθέσιμων, ενεργών χρηστών. |
||||
|
|
||||
|
\item \textbf{Contracts Provider}: Η υπηρεσία δεν υποκινεί καμία επικοινωνία, παρά μόνο απαντά σε αιτήματα επικοινωνίας από άλλες υπηρεσίες. |
||||
|
\end{itemize} |
@ -0,0 +1,27 @@ |
|||||
|
\subsection{Ροή πληροφορίας} \label{subsection:4-3-9-data-flow} |
||||
|
|
||||
|
Στην παρούσα υποενότητα θα αναλυθεί η ροή της πληροφορίας στο σύστημα. Λόγω των πολλαπλών υπηρεσιών, της κατάτμησης την πληροφορίας και των διαφορετικών σημείων αποθήκευσης της, η ροή της πληροφορίας στο σύστημα ακολουθεί ένα σχετικά περίπλοκο μονοπάτι (σε σχέση με κλασσικές, μονολιθικές, κεντροποιημένες εφαρμογές). |
||||
|
|
||||
|
Αρχικά θα γίνει αναφορά στη διαδικασία αποθήκευσης των νέων πληροφοριών. Η μοναδική πηγή παραγωγής δεδομένων στο σύστημα είναι οι χρήστες και κατ' επέκταση η υπηρεσία Concordia Application, εφόσον είναι η μοναδική υπηρεσία με την οποία αυτοί αλληλεπιδρούν. Τα δεδομένα που δημιουργούν οι χρήστες (πληροφορίες χρηστών, τίτλοι θεμάτων και περιεχόμενο μηνυμάτων) κατατέμνονται πριν αποθηκευτούν. Η πληροφορία που εισάγεται στο σύστημα διαχωρίζεται σε δύο μέρη. Στο blockchain αποθηκεύεται ένας δείκτης προς τα δεδομένα, ενώ τα πραγματικά δεδομένα αποθηκεύονται στη βάση OrbitDB. Ο δείκτης εκτός από την άμεση χρησιμότητα στην εύρεση των δεδομένων, παρέχει και την έμμεση λειτουργικότητα της δημιουργίας απαραίτητων μεταδομένων όπως ο αριθμός των θεμάτων στο σύστημα ή των μηνυμάτων σε ένα θέμα. |
||||
|
|
||||
|
Από την πλευρά της εύρεση των πληροφοριών στο σύστημα, η ροή είναι ως εξής. Αρχικά, είναι απαραίτητη η αναζήτηση στο blockchain για την εύρεση του δείκτη προς τα δεδομένα. Έπειτα, τα δεδομένα μπορούν να ανακτηθούν μέσω του IPFS από τον εκάστοτε χρήστη ή από κάποιον Pinner. |
||||
|
|
||||
|
Τέλος, παρακάτω δίνεται ένα παράδειγμα εισαγωγής πληροφορίας στο σύστημα και έπειτα ανάκτησης της ίδιας πληροφορίας. |
||||
|
|
||||
|
Έστω, χρήστης που δημιουργεί νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Μεταδεδομένα της δημιουργίας είναι η διεύθυνση του δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, θα επιστραφεί ο αύξων αριθμός του νέου θέματος. Έπειτα, στην προσωπική βάση OrbitDB του χρήστη και στον πίνακα των θεμάτων θα προστεθεί εγγραφή με αναγνωριστικό τον αύξων αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-3-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία. |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-create-topic-sequence-diagram} |
||||
|
\caption{Διάγραμμα ακολουθίας δημιουργίας θέματος} |
||||
|
\label{figure:4-3-data-flow-insert} |
||||
|
\end{figure} |
||||
|
|
||||
|
Έστω, χρήστης που επιθυμεί να διαβάσει το προηγούμενο θέμα. Αρχικά, πρέπει να διαβαστούν τα μεταδεδομένα του συγκεκριμένου θέματος από το blockchain. Έπειτα, διαβάζονται από το blockchain οι αύξοντες αριθμοί των μηνυμάτων που έχουν δημοσιευτεί στο θέμα αυτό. Σε μία τελευταία ανάκτηση από το blockchain διαβάζονται τα μεταδομένα του κάθε μηνύματος. Έπειτα, η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του θέματος και των μηνυμάτων, τα οποία ανακτώνται από τις προσωπικές βάσεις Orbit κάθε χρήστη. Στο σχήμα \ref{figure:4-3-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα. |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-fetch-topic-sequence-diagram} |
||||
|
\caption{Διάγραμμα ακολουθίας εύρεσης και ανάκτησης θέματος} |
||||
|
\label{figure:4-3-data-flow-read} |
||||
|
\end{figure} |
@ -1 +1,20 @@ |
|||||
\section{Προβλήματα ανάπτυξης} \label{section:4-5-problems-faced} |
\section{Προβλήματα ανάπτυξης} \label{section:4-4-problems-faced} |
||||
|
|
||||
|
Σε αυτήν την ενότητα περιγράφονται οι μεγαλύτερες δυσκολίες που αντιμετωπίστηκαν κατά την ανάπτυξη της πλατφόρμας. Αυτές μπορεί να αναφέρονται σε τεχνικά θέματα, αλλά και στις κοινωνικές και πολιτισμικές συνθήκες που επικρατούν στον χώρο των DApps και των crypto γενικότερα. |
||||
|
|
||||
|
Μία από τις μεγαλύτερες τροχοπέδες που καθυστέρησε σοβαρά την ανάπτυξη ήταν η πρωιμότητα των βιβλιοθηκών και των εργαλείων ανάπτυξης. Οι βασικότερες βιβλιοθήκες που χρησιμοποιήθηκαν ήταν σε πρώτο ή δεύτερο πειραματικό στάδιο (alpha και beta phase αντίστοιχα). Συγκεκριμένα: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item Όλα τα εργαλεία της σουίτας Truffle ήταν σε alpha phase κατά την ανάπτυξη (κάποια έχουν περάσει σε beta πλέον). |
||||
|
\item Το IPFS (συγκεκριμένα η βιβλιοθήκη js-ipfs) βρίσκεται ακόμα σε alpha έκδοση. |
||||
|
\item Η OrbitDB βρίσκεται ακόμα σε alpha phase. |
||||
|
\item Η γλώσσα των contracts, Solidity, ακόμα δεν έχει βγάλει version 1.0 καθώς αλλάζει διαρκώς με breaking changes\footnote{Από τη σελίδα του πηγαίου κώδικα \url{https://github.com/ethereum/solidity}}. |
||||
|
\end{itemize} |
||||
|
|
||||
|
Αυτή η έλλειψη ώριμων βιβλιοθηκών και εργαλείων προκάλεσε μείζονα προβλήματα. Συχνά έπρεπε να διορθωθούν προβλήματα των βιβλιοθηκών, ή να γίνει δουλειά που να τα παρακάμπτει. Άλλες φορές απαιτήθηκαν πολλές ώρες αποσφαλμάτωσης και δοκιμών ώστε να λειτουργήσουν τα χαρακτηριστικά που υπόσχονταν τα εργαλεία. |
||||
|
|
||||
|
Ένα άλλο πρόβλημα ήταν η έλλειψη εργαλείων για ορισμένες διαδικασίες. Δύο βασικά παραδείγματα αυτού αποτελούν πρώτον η έλλειψη υποστήριξης για integration/end-to-end testing των contracts κατά την ανάπτυξη (πλέον υπάρχουν κάποιες λύσεις) και δεύτερον η έλλειψη έτοιμων διαδικασιών, plugins και integrations του Jenkins με τα εργαλεία ανάπτυξης και ειδικά με τη σουίτα Truffle. |
||||
|
|
||||
|
Σε παρόμοια κατάσταση βρίσκεται και η γενική συναίνεση σχετικά με τα best practices. Σε διάφορα μέρη της ανάπτυξης παρατηρήθηκε ότι δεν υπήρχε κάποια διαμορφωμένη άποψη στην κοινότητα και κάθε ομάδα ανάπτυξης εφάρμοζε την δική της ιδέα. Αυτό καθιστά δύσκολη την ανάπτυξη από αρχάριους προγραμματιστές χωρίς καθοδήγηση. Ένα άλλο σχετικό πρόβλημα που παρατηρήθηκε είναι ότι στον χώρο υπάρχει ακόμα πολύς θόρυβος, δηλαδή σημαντικό μέρος των πηγών που βρίσκονται στο διαδίκτυο είναι αντικρουόμενες ή σε πολλές περιπτώσεις οι προτάσεις τους απορρίπτονται από την κοινότητα. |
||||
|
|
||||
|
Τελικώς, ένα μη τεχνικό ζήτημα που έπρεπε να αντιμετωπιστεί είναι η αβεβαιότητα της βιωσιμότητας, εξέλιξης και αποδοχής της τεχνολογίας blockchain και των εφαρμογών που βασίζονται σε αυτήν από το ευρύ κοινό. Αυτό συναίνεσε αρνητικά, καθώς δημιούργησε μία επιτακτικότητα προσοχής της εμπειρίας του χρήστη (UX), κάτι που φυσιολογικά δεν αποτελεί σημαντικό μέρος της ανάπτυξης ενός PoC. Η ανάγκη για προσοχή του UX πηγάζει από την ανάγκη για συγκράτηση των χρηστών (user retention) με στόχο την αντιστροφή της αβεβαιότητας και την παροχή μίας γνησίως ευχάριστης εμπειρίας. |
||||
|
@ -1,3 +1,4 @@ |
|||||
\chapter{Στιγμιότυπα οθόνης πλατφόρμας} \label{screenshots-appendix} |
\chapter*{Παράρτημα Αʹ\\[20pt]Στιγμιότυπα οθόνης πλατφόρμας}\label{screenshots-appendix} |
||||
|
\addcontentsline{toc}{section}{Αʹ Στιγμιότυπα οθόνης πλατφόρμας} |
||||
|
|
||||
TODO: add screenshots of application |
% TODO: add screenshots of application |
@ -1,4 +0,0 @@ |
|||||
\begin{hyphenrules}{english} |
|
||||
% Custom hyphenations go here |
|
||||
% \hyphenation{ar-ti-fa-cts} |
|
||||
\end{hyphenrules} |
|
@ -0,0 +1,21 @@ |
|||||
|
\begin{sequencediagram} |
||||
|
\newthread{actor}{Actor}{} |
||||
|
\newinst[4]{concordia}{:Concordia}{} |
||||
|
\newinst[4]{eth}{:Ethereum}{} |
||||
|
\newinst{orbit}{:OrbitDb}{} |
||||
|
|
||||
|
\begin{call}{actor}{Create community}{concordia}{Community creation form} |
||||
|
\end{call} |
||||
|
|
||||
|
\begin{call}{actor}{Add external contract}{concordia}{External contract form} |
||||
|
\end{call} |
||||
|
|
||||
|
\begin{call}{actor}{Submit}{concordia}{Created community page} |
||||
|
|
||||
|
\begin{call}{concordia}{Create community}{eth}{New community ID} |
||||
|
\end{call} |
||||
|
|
||||
|
\begin{call}{concordia}{Connect external contract}{eth}{} |
||||
|
\end{call} |
||||
|
\end{call} |
||||
|
\end{sequencediagram} |
@ -0,0 +1,16 @@ |
|||||
|
\begin{sequencediagram} |
||||
|
\newthread{actor}{Actor}{} |
||||
|
\newinst[3]{concordia}{:Concordia}{} |
||||
|
\newinst[2]{eth}{:Ethereum}{} |
||||
|
\newinst[1]{orbit}{:OrbitDb}{} |
||||
|
|
||||
|
\begin{call}{actor}{Create community}{concordia}{Community creation form} |
||||
|
\end{call} |
||||
|
|
||||
|
\begin{call}{actor}{Submit}{concordia}{Created community page} |
||||
|
|
||||
|
\begin{call}{concordia}{Create community}{eth}{New community ID} |
||||
|
\end{call} |
||||
|
|
||||
|
\end{call} |
||||
|
\end{sequencediagram} |