@ -0,0 +1,2 @@ |
|||
# Auto detect text files and perform LF normalization |
|||
* text=auto eol=lf |
@ -0,0 +1,6 @@ |
|||
# Αυτόνομο κοινωνικό δίκτυο βασισμένο σε τεχνολογίες αποκέντρωσης |
|||
|
|||
*WIP* |
|||
|
|||
## How to run |
|||
`xelatex.exe -synctex=1 -interaction=nonstopmode -shell-escape "thesis".tex` |
@ -0,0 +1,12 @@ |
|||
{ |
|||
id: '<the ID of the external identity>', |
|||
// Auto-generated by OrbitDB
|
|||
publicKey: '<signing key used to sign OrbitDB entries>', |
|||
signatures: { |
|||
//Allows the owner of id to prove they own the private key associated with publicKey
|
|||
id: '<signature of id signed using publicKey>', |
|||
//This links the two ids
|
|||
publicKey: '<signature of signatures.id + publicKey using id>' |
|||
}, |
|||
type: 'orbitdb' |
|||
} |
After Width: | Height: | Size: 138 KiB |
After Width: | Height: | Size: 411 KiB |
After Width: | Height: | Size: 250 KiB |
After Width: | Height: | Size: 139 KiB |
After Width: | Height: | Size: 356 KiB |
After Width: | Height: | Size: 36 KiB |
After Width: | Height: | Size: 193 KiB |
After Width: | Height: | Size: 61 KiB |
After Width: | Height: | Size: 44 KiB |
After Width: | Height: | Size: 22 KiB |
After Width: | Height: | Size: 120 KiB |
After Width: | Height: | Size: 171 KiB |
After Width: | Height: | Size: 645 KiB |
After Width: | Height: | Size: 737 KiB |
After Width: | Height: | Size: 702 KiB |
After Width: | Height: | Size: 170 KiB |
After Width: | Height: | Size: 37 KiB |
After Width: | Height: | Size: 97 KiB |
After Width: | Height: | Size: 62 KiB |
After Width: | Height: | Size: 122 KiB |
After Width: | Height: | Size: 689 KiB |
After Width: | Height: | Size: 49 KiB |
After Width: | Height: | Size: 20 KiB |
After Width: | Height: | Size: 112 KiB |
After Width: | Height: | Size: 57 KiB |
After Width: | Height: | Size: 2.4 MiB |
After Width: | Height: | Size: 46 KiB |
After Width: | Height: | Size: 25 KiB |
After Width: | Height: | Size: 112 KiB |
After Width: | Height: | Size: 103 KiB |
After Width: | Height: | Size: 47 KiB |
After Width: | Height: | Size: 62 KiB |
After Width: | Height: | Size: 31 KiB |
After Width: | Height: | Size: 186 KiB |
After Width: | Height: | Size: 15 KiB |
After Width: | Height: | Size: 26 KiB |
After Width: | Height: | Size: 1.0 MiB |
After Width: | Height: | Size: 165 KiB |
@ -1,25 +1,129 @@ |
|||
% examples... for more check out this: |
|||
% https://www.overleaf.com/learn/latex/bibliography_management_with_bibtex |
|||
|
|||
% proposed label naming convention: "chapter.subchapter-descriptive_name" |
|||
% for example: "2.2.2-why-gpg-is-awesome" |
|||
|
|||
@article{einstein, |
|||
author = "Albert Einstein", |
|||
title = "{Zur Elektrodynamik bewegter K{\"o}rper}. ({German}) |
|||
[{On} the electrodynamics of moving bodies]", |
|||
journal = "Annalen der Physik", |
|||
volume = "322", |
|||
number = "10", |
|||
pages = "891--921", |
|||
year = "1905", |
|||
DOI = "http://dx.doi.org/10.1002/andp.19053221004" |
|||
} |
|||
|
|||
@book{latexcompanion, |
|||
author = "Michel Goossens and Frank Mittelbach and Alexander Samarin", |
|||
title = "The \LaTeX\ Companion", |
|||
year = "1993", |
|||
publisher = "Addison-Wesley", |
|||
address = "Reading, Massachusetts" |
|||
% See also: https://www.overleaf.com/learn/latex/bibliography_management_with_bibtex |
|||
@misc{1.2-ethereum-learn, |
|||
title = {Μάθετε για το Ethereum}, |
|||
url = {https://ethereum.org/el/learn/}, |
|||
urldate = {2021-03-16} |
|||
} |
|||
@online{1.2-the-meaning-of-decentralization, |
|||
title = {The Meaning of Decentralization}, |
|||
author = {Vitalik Buterin}, |
|||
url = {https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274}, |
|||
date = {2017-02-06} |
|||
} |
|||
@book{1.2-virtual-migration, |
|||
title = {Virtual Migration}, |
|||
author = {Aneesh, A.}, |
|||
date = 2006, |
|||
optpublisher = {Duke University Press} |
|||
} |
|||
@article{2.2-ecdsa, |
|||
title = {The Elliptic Curve Digital Signature Algorithm (ECDSA)}, |
|||
author = {Johnson, Don and Menezes, Alfred and Vanstone, Scott}, |
|||
year = 2001, |
|||
month = 8, |
|||
journal = {International Journal of Information Security}, |
|||
doi = {10.1007/s102070100002}, |
|||
url = {https://doi.org/10.1007/s102070100002} |
|||
} |
|||
@online{2.3-merkle-tree, |
|||
title = {Merkle tree}, |
|||
author = {Wikipedia}, |
|||
url = {https://en.wikipedia.org/wiki/Merkle_tree} |
|||
} |
|||
@online{2.3-merkle-proofs-explained, |
|||
title = {Merkle proofs Explained.}, |
|||
author = {Belavadi Prahalad}, |
|||
url = {https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5}, |
|||
date = {2018-01-07} |
|||
} |
|||
@inproceedings{2.4-p2p-networking, |
|||
title = {A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications}, |
|||
author = {Schollmeier, R.}, |
|||
year = 2001, |
|||
booktitle = {Proceedings First International Conference on Peer-to-Peer Computing}, |
|||
pages = {101--102}, |
|||
doi = {10.1109/P2P.2001.990434} |
|||
} |
|||
@article{2.5-bitcoin, |
|||
title = {Bitcoin: A Peer-to-Peer Electronic Cash System}, |
|||
author = {Nakamoto, Satoshi}, |
|||
journal = {Cryptography Mailing list at https://metzdowd.com}, |
|||
date = {2008-10-31} |
|||
} |
|||
@misc{2.5-blockchain, |
|||
title = {Blockchain}, |
|||
author = {Wikipedia}, |
|||
url = {https://en.wikipedia.org/wiki/Blockchain} |
|||
} |
|||
@online{2.6-ethereum-whitepaper, |
|||
title = {Ethereum Whitepaper}, |
|||
author = {Vitalik Buterin}, |
|||
url = {https://ethereum.org/en/whitepaper}, |
|||
urldate = {2021-06-28}, |
|||
date = 2013 |
|||
} |
|||
@online{2.6-ethereum-documentation, |
|||
title = {Ethereum documentation}, |
|||
author = {Ethereum community}, |
|||
url = {https://ethereum.org/en/developers/docs/}, |
|||
urldate = {2021-09-05} |
|||
} |
|||
@article{2.6-ethereum-smart-contracts, |
|||
title = {Formalizing and Securing Relationships on Public Networks}, |
|||
author = {Szabo, Nick}, |
|||
year = 1997, |
|||
month = 9, |
|||
journal = {First Monday}, |
|||
volume = 2, |
|||
number = 9, |
|||
doi = {10.5210/fm.v2i9.548}, |
|||
url = {https://journals.uic.edu/ojs/index.php/fm/article/view/548} |
|||
} |
|||
@book{2.6-ethereum-mastering, |
|||
title = {Mastering Ethereum: Building Smart Contracts and DApps}, |
|||
author = {Andreas M Antonopoulos, Gavin Wood}, |
|||
publisher = {O'Reilly Media}, |
|||
isbn = 1491971940, |
|||
date = 2018, |
|||
opturl = {https://cypherpunks-core.github.io/ethereumbook/} |
|||
} |
|||
@misc{2.7-ipfs, |
|||
title = {IPFS}, |
|||
url = {https://ipfs.io/} |
|||
} |
|||
@misc{2.7-ipfs-docs, |
|||
title = {IPFS documentation}, |
|||
url = {https://docs.ipfs.io/} |
|||
} |
|||
@online{4.1-github-flow, |
|||
title = {Understanding the GitHub flow}, |
|||
author = {GitHub Guides}, |
|||
url = {https://guides.github.com/introduction/flow/} |
|||
} |
|||
@misc{4.2-node.js, |
|||
title = {Node.js}, |
|||
author = {Wikipedia}, |
|||
url = {https://en.wikipedia.org/wiki/Node.js} |
|||
} |
|||
@misc{4.2-orbitdb, |
|||
title = {OrbitDB}, |
|||
url = {https://orbitdb.org} |
|||
} |
|||
@misc{4.2-orbitdb-guide, |
|||
title = {Getting Started with OrbitDB}, |
|||
url = {https://github.com/orbitdb/orbit-db/blob/main/GUIDE.md} |
|||
} |
|||
@misc{5.2-privacy-on-ethereum, |
|||
title = {Privacy on Ethereum}, |
|||
url = {https://docs.ethhub.io/ethereum-roadmap/privacy/}, |
|||
urldate = {2021-12-12} |
|||
} |
|||
@article{5.2-taxonomy-of-reputation-systems, |
|||
title = {Reputation systems: A survey and taxonomy}, |
|||
author = {Hendrikx, Ferry and Bubendorfer, Kris and Chard, Ryan}, |
|||
year = 2014, |
|||
month = {08}, |
|||
journal = {Journal of Parallel and Distributed Computing}, |
|||
volume = 75, |
|||
doi = {10.1016/j.jpdc.2014.08.004} |
|||
} |
|||
|
@ -1 +1,17 @@ |
|||
Decentralized και τα σχετικά. |
|||
\chapter*{Περίληψη} |
|||
\addcontentsline{toc}{chapter}{Περίληψη} |
|||
|
|||
Τις τελευταίες δεκαετίες, η ραγδαία ανάπτυξη του διαδικτύου μετέβαλε ριζικά τις ανθρώπινες |
|||
κοινωνίες, μέσω μίας πληθώρας ψηφιακών εφαρμογών, οι οποίες, στη συντριπτική τους πλειοψηφία, προσφέρονται από παρόχους υπηρεσιών υπολογιστικού νέφους, ακολουθώντας την αρχιτεκτονική πελάτη-εξυπηρετητή. |
|||
|
|||
Μολονότι αυτό το μοντέλο υλοποίησης έχει αποδειχθεί ιδιαίτερα λειτουργικό και έχει βελτιωθεί αξιοσημείωτα ανά τα χρόνια, η συγκεντρωτική του λογική συνοδεύεται από μία σειρά προβλημάτων. Πρώτον, οι χρήστες καλούνται να εμπιστευθούν τα προσωπικά τους δεδομένα σε μία εξωτερική οντότητα. Εκείνη, διατηρώντας τον πλήρη έλεγχο επί αυτών, αποκτάει τη δυνατότητα να τα επεξεργάζεται, να τα διαμοιράζεται και να τα λογοκρίνει, είτε για να εξυπηρετήσει τα συμφέροντά της, είτε για να συμμορφωθεί με άλλες αρχές που της ασκούν εξουσία. Επιπλέον, απουσιάζει η εγγύηση της διαθεσιμότητας των δεδομένων, καθώς, ανά πάσα στιγμή, ο εξυπηρετητής μπορεί να αποσυνδεθεί για αόριστο χρονικό διάστημα και λόγω ποικίλων αιτιών, όπως κάποιας κυβερνοεπίθεσης ή κάποιας φυσικής καταστροφής. |
|||
|
|||
Αυτοί είναι μερικοί βασικοί λόγοι που συνετέλεσαν στην ταχεία ανάπτυξη ενός συνόλου καινοτόμων λογισμικών ανοιχτού κώδικα, τα οποία βασίζονται σε τεχνολογίες όπως το blockchain και τα δίκτυα ομότιμων κόμβων. Τα παραπάνω, αν και βρίσκονται σε σχετικά πρώιμο στάδιο, αποτελούν ήδη ισχυρά εργαλεία δημιουργίας κατανεμημένων και αποκεντρωμένων εφαρμογών. |
|||
|
|||
Στόχος της παρούσας διπλωματικής εργασίας είναι η υλοποίηση μίας αυτόνομης κοινωνικής πλατφόρμας, |
|||
η οποία, αξιοποιώντας τεχνολογίες αποκέντρωσης, αφενός θα επιστρέφει την κυριότητα των προσωπικών |
|||
δεδομένων στον χρήστη, αφετέρου θα παρέχει τη δυνατότητα διενέργειας διαφανών δημοκρατικών ψηφοφοριών. Αυτά μέσα σε ένα πλαίσιο ανθεκτικό, τόσο σε σφάλματα και επιθέσεις, όσο και σε απόπειρες λογοκρισίας και παραποίησης. |
|||
|
|||
Η αναπτυχθείσα πιλοτική εφαρμογή "Concordia" προσεγγίζει τον παραπάνω στόχο συνδυάζοντας τις τεχνολογίες Ethereum και IPFS, ώστε να ορίσει έναν αποκεντρωμένο ψηφιακό χώρο, τόσο σε αρχιτεκτονικό όσο και πολιτικό επίπεδο. |
|||
\\[2\baselineskip] |
|||
\textbf{Λέξεις-Κλειδιά}: Αποκεντροποίηση, Ethereum, Blockchain, Έξυπνο Συμβόλαιο, Αποκεντρωμένη Εφαρμογή, IPFS, OrbitDB, React, Redux, Jenkins |
@ -1 +1,15 @@ |
|||
Don't forget the keywords. |
|||
\chapter*{Abstract} |
|||
\addcontentsline{toc}{chapter}{Abstract} |
|||
|
|||
\textenglish{In recent decades, the rapid growth of the internet has radically changed society, 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. Firstly, users are required to trust their 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 technologies, 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 +1,11 @@ |
|||
Ευχαριστούμε η Αθήνα. Ευχαριστούμε η Ελλάδα. |
|||
\chapter*{Ευχαριστίες} |
|||
\addcontentsline{toc}{chapter}{Ευχαριστίες} |
|||
|
|||
Σε αυτό το σημείο θα θέλαμε να ευχαριστήσουμε εγκάρδια όλους εκείνους που συνέβαλλαν στην εκπόνηση της παρούσας εργασίας: |
|||
|
|||
\begin{itemize} |
|||
\item Τον επιβλέποντα καθηγητή μας, κ. Δημάκη Χρήστο, για την ευκαιρία που μας έδωσε να ασχοληθούμε με το συγκεκριμένο θέμα και την εμπιστοσύνη που μας έδειξε από την αρχή μέχρι το τέλος. |
|||
\item Τη Νικολαΐδου Μελίνα, για τη σχεδίαση του λογότυπου της εφαρμογής και τη δημιουργία σημαντικού τμήματος των σχημάτων του παρόντος εγγράφου. |
|||
\item Τις οικογένειες και τους φίλους μας, για την αμέριστη υλική και ηθική υποστήριξη που μας προσέφεραν καθ' όλη τη διάρκεια των σπουδών μας. |
|||
\item Ο ένας τον άλλον, για την άρτια επικοινωνία και συνεργασία, καθώς και για την υπομονή και την επιμονή, χαρακτηριστικά καθοριστικής σημασίας για την επιτυχή πορεία της διπλωματικής. |
|||
\end{itemize} |
|||
|
@ -1 +1,5 @@ |
|||
\tableofcontents |
|||
% TOC bookmark solution found here: |
|||
% https://tex.stackexchange.com/questions/97024/how-to-add-the-pdf-bookmark-of-toc-without-its-name-contents-in-toc |
|||
\clearpage |
|||
\pdfbookmark{\contentsname}{toc} |
|||
\tableofcontents \label{toc} |
|||
|
@ -1,8 +1,9 @@ |
|||
\chapter{Εισαγωγή} |
|||
\chapter{Εισαγωγή}\label{chapter:1-introduction} |
|||
|
|||
\input{chapters/1.introduction/1.1.general} |
|||
\input{chapters/1.introduction/1.2.problem-definition} |
|||
\input{chapters/1.introduction/1.3.suggested-solution} |
|||
\input{chapters/1.introduction/1.4.goals} |
|||
\input{chapters/1.introduction/1.2.decentralization} |
|||
\input{chapters/1.introduction/1.3.problem-definition} |
|||
\input{chapters/1.introduction/1.4.thesis-goal} |
|||
\input{chapters/1.introduction/1.5.methodology} |
|||
\input{chapters/1.introduction/1.6.document-structure} |
|||
\input{chapters/1.introduction/1.6.typography} |
|||
\input{chapters/1.introduction/1.7.document-structure} |
@ -1,3 +1,12 @@ |
|||
\section{Γενικά} |
|||
\section{Γενικά}\label{section:1-1-general} |
|||
|
|||
Η αλματώδης ανάπτυξη του διαδικτύου διαμόρφωσε ένα ολοκαίνουργιο τοπίο σε κάθε τομέα της ανθρώπινης δραστηριότητας, παρέχοντας ένα αναρίθμητο πλήθος εφαρμογών και υπηρεσιών. Τα μέσα κοινωνικής δικτύωσης, |
|||
το ηλεκτρονικό ταχυδρομείο, η ψηφιακή ειδησεογραφία, ο διαμοιρασμός αρχείων και |
|||
οι υπηρεσίες πολυμέσων ροής, αποτελούν ορισμένα από τα σημαντικότερα - και πλέον αναπόσπαστα - κομμάτια, |
|||
που συνθέτουν την ψηφιακή πτυχή της σύγχρονης καθημερινότητας. |
|||
|
|||
Κατά κύριο λόγο, το μοντέλο που ακολουθούν οι παραπάνω τεχνολογίες είναι αυτό της αρχιτεκτονικής πελάτη-εξυπηρετητή (client–server architecture) και προσφέρονται από παρόχους υπηρεσιών υπολογιστικού νέφους (cloud computing service providers). Αυτό σημαίνει ότι οι απαραίτητες λειτουργίες τους, δηλαδή η επεξεργασία (processing), η αποθήκευση των δεδομένων (storage) και το πρωτόκολλο επικοινωνίας (communication protocol) υλοποιούνται επί ενός συγκεντρωτικού (centralized) πλαισίου, κάτι που τους προσδίδει ορισμένα αξιοσημείωτα πλεονεκτήματα (π.χ. ευκολία ανάπτυξης, συντήρησης και αποσφαλμάτωσης). |
|||
|
|||
Στις μέρες μας, ωστόσο, παρατηρείται παράλληλα μία τάση δημιουργίας εφαρμογών που ακολουθούν αποκεντρωτικά μοντέλα λειτουργίας, στα οποία το processing και το storage κατανέμονται σε ένα σύνολο κόμβων που επικοινωνούν ομότιμα. Εντός, λοιπόν, αυτής της τάσης, αναπτύσσονται με ταχείς ρυθμούς διάφορα λογισμικά, τα οποία συνθέτουν ένα νέο, αποκεντρωτικό οικοσύστημα. Αυτό περιλαμβάνει (μεταξύ άλλων) τόσο καινοτόμα πρωτόκολλα αποθήκευσης δεδομένων (π.χ. IPFS), όσο και πλατφόρμες ανάπτυξης και εκτέλεσης αποκεντρωμένων εφαρμογών (π.χ. Ethereum blockchain). |
|||
|
|||
\newpage |
@ -0,0 +1,22 @@ |
|||
\section{Περί αποκέντρωσης}\label{section:1-2-decentralization} |
|||
|
|||
Αν και ο όρος "αποκέντρωση" χρησιμοποιείται ευρέως στην επιστήμη των υπολογιστών και στα κρυπτοοικονομικά\footnote{Τα "κρυπτοοικονομικά" είναι η πρακτική επιστήμη της δημιουργίας κατανεμημένων συστημάτων, οι ιδιότητες των οποίων εξασφαλίζονται με οικονομικά κίνητρα, ενώ οι οικονομικοί τους μηχανισμοί είναι κρυπτογραφικά εγγυημένοι.\cite{1.2-ethereum-learn}} (cryptoeconomics), συνήθως ορίζεται αρκετά ασαφώς\cite{1.2-the-meaning-of-decentralization}. Στην πραγματικότητα η αποκέντρωση (ή, αντίστοιχα, ο συγκεντρωτισμός) μπορεί να τοποθετηθεί πάνω σε τρεις ξεχωριστούς άξονες, οι οποίοι είναι σε γενικές γραμμές ανεξάρτητοι ο ένας από τον άλλον. Αυτοί έχουν ως εξής: |
|||
|
|||
\begin{enumerate} |
|||
\item \textbf{Αρχιτεκτονική} αποκέντρωση: Από πόσους φυσικούς υπολογιστές αποτελείται ένα σύστημα; Πόσοι από αυτούς μπορούν, ανά πάσα στιγμή, να χαλάσουν και εκείνο να αντέξει; |
|||
\item \textbf{Πολιτική} αποκέντρωση: Πόσα άτομα ή οργανισμοί ελέγχουν τους υπολογιστές από τους οποίους αποτελείται το σύστημα; |
|||
\item \textbf{Λογική} αποκέντρωση: Η διεπαφή και οι δομές δεδομένων του συστήματος μοιάζουν περισσότερο με ένα μονολιθικό αντικείμενο ή ένα άμορφο σμήνος; Αν, δηλαδή, το σύστημα (συμπεριλαμβανομένων των παρόχων και των χρηστών) "κοπεί στη μέση", θα συνεχίσουν τα δύο μισά να λειτουργούν πλήρως ως ανεξάρτητες μονάδες; |
|||
\end{enumerate} |
|||
|
|||
Για παράδειγμα, το BitTorrent είναι αποκεντρωτικό ως προς όλους τους άξονες, ενώ ένα CDN (Content Delivery Network), είναι μόνο αρχιτεκτονικά και λογικά, αφού ελέγχεται από κάποια εταιρεία. Φυσικά, η έννοια μπορεί να γενικευθεί και να μιλάμε για αποκέντρωση μίας επιχείρησης (συνήθως πλήρως συγκεντρωτική) ή μίας γλώσσας (συνήθως πλήρως αποκεντρωτική). |
|||
|
|||
Η επιλογή της δομής ενός συστήματος ως προς την αποκέντρωσή του βασίζεται στις εκάστοτε ανάγκες και στους στόχους του. Μερικά ισχυρά πλεονεκτήματα που διατυπώνονται συχνά για τα αποκεντρωτικά συστήματα είναι τα εξής: |
|||
|
|||
\begin{itemize} |
|||
\item \textbf{Ανοχή σε σφάλματα}: Τα αρχιτεκτονικά αποκεντρωμένα συστήματα είναι λιγότερο πιθανό να αποτύχουν τυχαία, επειδή βασίζονται σε πολλά ξεχωριστά στοιχεία που είναι απίθανο να παρουσιάσουν σφάλματα ταυτόχρονα. |
|||
\item \textbf{Αντοχή σε επιθέσεις}: Το κόστος μίας επίθεσης, που έχει ως στόχο την καταστροφή ή τον χειρισμό ενός αποκεντρωτικού συστήματος, είναι πολύ ακριβό. Αυτό συμβαίνει επειδή δεν υπάρχει κάποιο ευαίσθητο κεντρικό σημείο στο οποίο να μπορεί να πραγματοποιηθεί μία επίθεση, η οποία να έχει κόστος πολύ χαμηλότερο από το οικονομικό μέγεθος του περιβάλλοντος συστήματος. |
|||
\item \textbf{Απουσία ανάγκης εκχώρησης εμπιστοσύνης}: Σε ένα ιδανικό πολιτικά αποκεντρωμένο σύστημα οι χρήστες δε χρειάζεται να εμπιστεύονται κάποια κεντρική αρχή για την επεξεργασία και την αποθήκευση των δεδομένων. |
|||
\item \textbf{Αντίσταση σε συμπαιγνίες}: είναι πολύ πιο δύσκολο για τους συμμετέχοντες σε αποκεντρωμένα συστήματα να συνεργαστούν για να ενεργήσουν με τρόπο που τους ωφελεί σε βάρος άλλων συμμετεχόντων. |
|||
\end{itemize} |
|||
|
|||
Ιδιαίτερα τα τελευταία χρόνια, παρατηρείται μία έντονη ανάγκη υλοποίησης αποκεντρωμένων εφαρμογών (decentralized applications), οι οποίες, πέρα από τα αρχιτεκτονικά πλεονεκτήματα που τις χαρακτηρίζουν (π.χ. σταθερότητα, ασφάλεια, επεκτασιμότητα), αποσκοπούν στην επίτευξη πολιτικής αποκέντρωσης. Αυτό πηγάζει τόσο από την ανάγκη προάσπισης των αρχών που καταστρατηγούνται όταν τα δεδομένα υπάγονται στον έλεγχο κάποιας κεντρικής διαχείρισης (π.χ. της ελευθερίας του λόγου, της ανωνυμίας και της ιδιωτικότητας του χρήστη), όσο και από την ανάγκη δημιουργίας διαδικασιών που απαιτούν εγκυρότητα και αυθεντικότητα, όπως όσων σχετίζονται με την αυτοδιαχείριση και την άμεση δημοκρατία. Ως απόγειο των παραπάνω, μπορούν να θεωρηθούν οι λεγόμενες \textit{αποκεντρωτικές αυτόνομες οργανώσεις} (decentralized autonomous organizations ή DAOs), οι οποίες αποτελούν μία μορφή αλγοκρατικής\footnote{Ο όρος "αλγοκρατία" (algocracy) αναφέρεται σε εναλλακτικές μορφές διακυβέρνησης που βασίζονται στη χρήση αλγορίθμων.\cite{1.2-virtual-migration}} οργάνωσης βασισμένης σε τεχνολογίες αποκέντρωσης και, κυρίως, στο blockchain. |
@ -1,19 +0,0 @@ |
|||
\section{Ορισμός του προβλήματος} |
|||
|
|||
Στις μέρες μας τα περισσότερα δεδομένα των χρηστών βρίσκονται υπό τον έλεγχο συγκεντρωτικών συστημάτων. Σε τέτοια συστήματα οι χρήστες δεν είναι κύριοι των δεδομένων τους, δεν έχουν εγγύηση για την αυθεντικότητα αυτών που βλέπουν και υπόκεινται σε λογοκρισία, ενώ τα συστήματα αυτά δεν είναι ασφαλή και μπορεί να σταματήσουν να λειτουργούν προσωρινά ή μόνιμα για τεχνικούς/οικονομικούς/νομικούς λόγους. |
|||
|
|||
Οι περισσότερες διαδεδομένες, συγκεντρωτικές μορφές πλατφόρμας επικοινωνίας (mailing list, forum, κοινωνικά δίκτυα και άλλες) χρειάζονται, τυπικά, τουλάχιστον τις εξής τεχνολογίες: |
|||
|
|||
\begin{itemize} |
|||
\item μία πηγή επεξεργαστικής ισχύος (processing) |
|||
\item μία βάση δεδομένων |
|||
\item ένα πρωτόκολλο επικοινωνίας |
|||
\end{itemize} |
|||
|
|||
Η επεξεργαστική ισχύς είναι αναγκαία για την περάτωση των λειτουργιών οι οποίες υλοποιούν τις υπηρεσίες της πλατφόρμας. Τις περισσότερες φορές η πηγή αυτή είναι ένας server ή μία cloud υπηρεσία. |
|||
|
|||
Η βάση δεδομένων είναι απαραίτητη για την αποθήκευση της πληροφορίας. Σε μικρότερες εφαρμογές η βάση βρίσκεται στο ίδιο σύστημα που γίνεται και το processing, ενώ σε μεγαλύτερες ενδέχεται να υπάρχει για λόγους ασφάλειας ένα ξεχωριστό σύστημα αφιερωμένο στη βάση δεδομένων. |
|||
|
|||
Το πρωτόκολλο επικοινωνίας αναλαμβάνει τη μετάδοση και ανάκτηση της πληροφορίας. Το πρωτόκολλό που χρησιμοποιείται σήμερα στη συντριπτική πλοιοψηφία των εφαρμογών είναι το HTTP. |
|||
|
|||
Κάθε ένα από τα παραπάνω μέρη, εισάγει την ανάγκη ύπαρξης κεντρικών αρχών που τα διαχειρίζονται και τα συντηρούν. Η αρχή αυτή είναι συνήθως ο πάροχος της υπηρεσίας που διαχειρίζεται το processing και τη βάση δεδομένων, έχοντας έτσι πρόσβαση σε όλα τα δεδομένα που υπάρχουν στο σύστημα. |
@ -0,0 +1,15 @@ |
|||
\section{Ορισμός του προβλήματος}\label{section:1-3-problem-definition} |
|||
|
|||
Οι περισσότερες διαδεδομένες πλατφόρμες επικοινωνίας (κοινωνικά δίκτυα, mailing lists, forums κ.ά.) είναι ως επί το πλείστον συγκεντρωτικής μορφής, πράγμα το οποίο καθιστά αναγκαία την ύπαρξη κεντρικών αρχών που να τις διαχειρίζονται και να τις συντηρούν. |
|||
|
|||
Παρά τα θετικά της χαρακτηριστικά, η κεντροποιημένη λογική ενός τέτοιου συστήματος αφενός συνοδεύεται από ποικίλα μειονεκτήματα τεχνικής φύσεως (αρχιτεκτονικός συγκεντρωτισμός), αφετέρου εγείρει σοβαρούς προβληματισμούς σχετικά με τη διαχείριση των προσωπικών δεδομένων των χρηστών από τις κεντρικές αρχές (πολιτικός συγκεντρωτισμός). Τα βασικότερα από τα παραπάνω θα μπορούσαν να συνοψιστούν ως εξής: |
|||
|
|||
\begin{itemize} |
|||
\item Έλλειψη \textbf{ασφάλειας}: Τα προσωπικά δεδομένα των χρηστών μπορεί να υποκλαπούν εξαιτίας κάποιας κυβερνοεπίθεσης. |
|||
\item Έλλειψη \textbf{διαθεσιμότητας}: Το σύστημα μπορεί να σταματήσει να λειτουργεί προσωρινά ή μόνιμα για τεχνικούς, οικονομικούς ή νομικούς λόγους. |
|||
\item Έλλειψη \textbf{εμπιστοσύνης}: Οι κεντρικές αρχές έχουν τη δυνατότητα να παρακολουθούν τους χρήστες, να διαβάζουν, ή ακόμα και να διαρρέουν τα προσωπικά τους δεδομένα εν αγνοία των τελευταίων. Οι δε χρήστες δε διαθέτουν κανέναν τρόπο με τον οποίον να μπορούν να τις εμπιστευθούν με βεβαιότητα. |
|||
\item Έλλειψη εγγύησης της \textbf{αυθεντικότητας} των δεδομένων: Οι κεντρικές αρχές έχουν τη δυνατότητα να τροποποιούν τα δεδομένα κατά βούληση κάτι που έχει ως αποτέλεσμα να μην υπάρχει εγγύηση ως προς την αυθεντικότητα όσων βλέπουν οι χρήστες. |
|||
\item Έλλειψη εγγύησης της \textbf{ελευθερίας του λόγου}: Οι κεντρικές αρχές έχουν τη δυνατότητα να λογοκρίνουν τα δεδομένα, είτε βάσει των συμφερόντων τους, είτε βάσει υποχρεώσεών τους προς τρίτους. |
|||
\end{itemize} |
|||
|
|||
Επιπλέον, όπως γίνεται φανερό, οι αδυναμίες του συστήματος ως προς τον πολιτικό άξονα το καθιστούν ακατάλληλο να παρέχει στους χρήστες αυθεντικές και επικυρώσιμες δημοκρατικές διαδικασίες. Τέτοιου είδους διαδικασίες θα μπορούσε να ήταν από απλές ψηφοφορίες, μέχρι σύνθετες διαδικασίες αυτοδιαχείρισης της πλατφόρμας. |
@ -1,20 +0,0 @@ |
|||
\section{Προτεινόμενη λύση} |
|||
|
|||
Το Concordia είναι η εφαρμογή η οποία αναπτύσσουμε εμείς και στοχεύει να διορθώσει αυτά τα προβλήματα, επαναφέροντας στους χρήστες την κυριότητα των δεδομένων τους, εξασφαλίζοντας την πλήρη ελευθερία του λόγου και την αυθεντικότητα, ανοίγοντας τον δρόμο για αξιόπιστες ψηφοφορίες |
|||
Όλα αυτά μέσα από δημόσιες, αποκεντρωτικές διαδικασίες. |
|||
|
|||
\subsection{Απαιτήσεις} |
|||
|
|||
\subsection{Αποκέντρωση} |
|||
|
|||
% Παλιό από Drive |
|||
Αποκέντρωση του συστήματος σημαίνει πρακτικά ότι το processing και η αποθήκευση των δεδομένων δε θα γίνονται από κάποια κεντρική αρχή αλλά θα είναι κατανεμημένα στο σύνολο των χρηστών (nodes). Με αυτόν τον τρόπο δεν υπάρχει ανάγκη για μία κεντρική αρχή και τα δεδομένα δεν είναι ελέγξιμα από κανέναν ατομικά, παρά μόνο από τη συναίνεση (consensus) του δικτύου. |
|||
|
|||
Τα συγκεντρωτικά συστήματα έχουν μερικά θετικά χαρακτηριστικά που λείπουν από τα αποκεντρωτικά συστήματα, όπως ευκολία ανάπτυξης, συντήρησης και αποσφαλμάτωσης των εφαρμογών. Πάσχουν ωστόσο σε ό,τι αφορά την σταθερότητα, την ασφάλεια, την επεκτασιμότητα και την εξέλιξη, τομείς όπου τα αποκεντρωτικά συστήματα είναι ιδιαίτερα αποτελεσματικά. |
|||
|
|||
Η ανάγκη για αποκέντρωση των εφαρμογών, ειδικά στην επικοινωνία, είναι μεγάλη και πηγάζει από την ανάγκη για ελευθερία του λόγου, ανωνυμία και ιδιωτικότητα. Χρησιμοποιώντας τεχνικές για κατανομή του processing, μία διανεμημένη βάση δεδομένων και αλγόριθμους κρυπτογραφίας δημόσιου κλειδιού μπορούμε να προστατεύσουμε την ανωνυμία του χρήστη αλλά και να εγγυηθούμε την ταυτοποίησή του. |
|||
|
|||
\subsection{Αμεσοδημοκρατικές διαδικασίες και αυτοδιαχείριση} |
|||
|
|||
% Παλιό από Drive |
|||
Για την πλήρη επίτευξη του στόχου απαιτείται επίσης ένα σύστημα διαχείρισης της πλατφόρμας αυτής καθ’ αυτής αλλά και των περιεχομένων της. Το σύστημα που επιλέγουμε για αυτούς τους σκοπούς είναι αυτό της άμεσης δημοκρατίας και αυτοδιαχείρισης. Αυτό σημαίνει ότι οι αποφάσεις θα παίρνονται μέσα από ψηφοφορίες στις οποίες θα μπορούν να συμμετέχουν όσα μέλη έχουν δικαίωμα ψήφου. Έτσι, λόγω της αποκέντρωσης και άρα της έλλειψης διοικούσας αρχής, η πλατφόρμα μπορεί να χρησιμοποιηθεί σαν μία εγγυημένα αμερόληπτη αρχή για ψηφοφορίες πάνω σε θέματα που αφορούν τη φοιτητική ζωή και όχι μόνο. |
@ -1,4 +0,0 @@ |
|||
\section{Στόχος} |
|||
|
|||
% Παλιό από Drive |
|||
Στόχος του project είναι η δημιουργία μιας κοινωνικής πλατφόρμας, η οποία, βασιζόμενη σε τεχνολογίες αποκέντρωσης, αφενός θα παρέχει ελευθερία λόγου, εργαλεία αυτοδιαχείρισης και αμεσοδημοκρατικές διαδικασίες, αφετέρου θα διασφαλίζει την κυριότητα των δεδομένων του χρήστη από τον ίδιο και την ανεξαρτητοποίηση του συστήματος από κεντρικές οντότητες. Παράλληλα, θα παρέχει στους επαληθευμένους χρήστες του ΑΠΘ μια πλατφόρμα για ανώνυμες και αυθεντικές ψηφοφορίες, εν δυνάμει ικανών να αποτελέσουν ένα έγκυρο, έμπιστο και άμεσα δημοκρατικό βήμα λήψης αποφάσεων. |
@ -0,0 +1,5 @@ |
|||
\section{Στόχος της διπλωματικής}\label{section:1-4-thesis-goal} |
|||
|
|||
Στόχος της παρούσας διπλωματικής εργασίας είναι η δημιουργία μίας αυτόνομης κοινωνικής πλατφόρμας, η οποία, βασιζόμενη σε τεχνολογίες αποκέντρωσης, θα λειτουργεί ανεξάρτητα από κεντρικές αρχές, παρέχοντας στους χρήστες της πλήρη ελευθερία του λόγου και κυριότητα επί των δεδομένων τους. Παράλληλα, θα παρέχει μία πλατφόρμα για ανώνυμες και αυθεντικές ψηφοφορίες, εν δυνάμει ικανών να αποτελέσουν ένα έγκυρο, έμπιστο και άμεσα δημοκρατικό βήμα λήψης αποφάσεων. |
|||
|
|||
Η proof of concept (PoC) εφαρμογή που αναπτύχθηκε για την επίτευξη του παραπάνω στόχου ονομάζεται Concordia\footnote{Η Concordia είναι η θεά της αρχαίας Ρωμαϊκής θρησκείας που προσωποποιεί την ομόνοια. Στην ελληνική μυθολογία ταυτίζεται με τη θεότητα Ομόνοια ή τη θεά Αρμονία.} και λειτουργεί μέσω ενός συνδυασμού αποκεντρωτικών τεχνολογιών. Πιο συγκεκριμένα, στον επεξεργαστικό πυρήνα της και σαν σημείο αναφοράς αξιοποιεί τo Ethereum blockchain, ενώ για την αποθήκευση του μεγαλύτερου όγκου των δεδομένων χρησιμοποιεί το IPFS μέσω της OrbitDB. Η δε διεπαφή του χρήστη υλοποιείται με σύγχρονες μεθόδους web development σε JavaScript (React, Redux κ.ά.). |
@ -1,9 +1,11 @@ |
|||
\section{Μεθοδολογία ανάπτυξης} |
|||
\section{Μεθοδολογία της διπλωματικής}\label{section:1-5-methodology} |
|||
|
|||
Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της απαραίτητης δουλειάς σε διαχειρίσιμα μέρη σχεδιάστηκε η χρήση διάφορων εργαλείων και μεθόδων ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git και η μέθοδος οργάνωσης Scrum. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύχρονη ανάπτυξη λογισμικού. |
|||
Έναυσμα της παρούσας εργασίας αποτέλεσε η παρατηρήση της αρχιτεκτονικής δομής των σύγχρονων διαδικτυακών εφαρμογών και η ανάγκη διερεύνησης των επιπτώσεών της στον τελικό χρήστη. |
|||
|
|||
Το Git είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση κλαδιών (branches). Για τους σκοπούς της παρούσας διπλωματικής σχεδιάστηκε η χρήση του μοντέλου που έχει αναπτυχθεί από την εταιρία Github, Flow. Το μοντέλο αυτό ορίζει ότι κάθε προγραμματιστής θα ανοίγει ένα νέο branch για τη ανάπτυξη ενός νέου χαρακτηριστικού της εφαρρμογής ή την διόρθωση ενός μέρους του κώδικα. Έπειτα, όταν η δουλειά έχει ολοκληρωθεί το branch ενώνεται (merge) με το βασικό branch της εφαρμογής. |
|||
Αρχικά, ορίστηκε με σαφήνεια το πρόβλημα (\hyperref[section:1-3-problem-definition]{ενότητα 1.3}) και ο στόχος της διπλωματικής (\hyperref[section:1-4-thesis-goal]{ενότητα 1.4}), λαμβάνοντας την απόφαση να περιοριστεί στον τομέα των μέσων κοινωνικής δικτύωσης και της ψηφιακής δημοκρατίας. |
|||
|
|||
Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο/η επιμελητής/επιμελήτρια του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από μέρη εργασίας τα οποία θα αποτελέσουν το επόμενο Sprint. Κάθε μέρος εργασίας ανατίθεται σε κάποιο μέλος για υλοποίηση και ορίζεται για το Sprint μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των μερών εργασίας πριν τη λήξη της. Στο τέλος προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί. |
|||
Στη συνέχεια, πραγματοποιήθηκε έρευνα του χώρου των αποκεντρωμένων τεχνολογιών και ξεκίνησε η διαδικασία της σχεδίασης της εφαρμογής, μέσω της επιλογής του μοντέλου της τεχνολογικής στοίβας και του κατάλληλου λογισμικού σε κάθε επίπεδό της. |
|||
|
|||
Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διακρούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφής και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερομένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγεί τελμάτων κατά τη συγγραφή του κώδικα. |
|||
Ακολούθησε η διαδικασία υλοποίησης της πιλοτικής πλατφόρμας Concordia, με στόχο να καταστεί ο αρχικός σχεδιασμός πραγματοποιήσιμος. |
|||
|
|||
Τέλος, εξήχθησαν συμπεράσματα και διατυπώθηκαν πιθανές μελλοντικές επεκτάσεις για την εφαρμογή. |
|||
|
@ -1 +0,0 @@ |
|||
\section{Οργάνωση κεφαλαίων} |
@ -0,0 +1,9 @@ |
|||
\section{Τυπογραφικές παραδοχές} \label{section:1-6-typography} |
|||
|
|||
Το παρόν έγγραφο αποτυπώνεται με τη γραμματοσειρά Linux Libertine O\footnote{\url{https://libertine-fonts.org/}}, ενώ για τα κομμάτια κώδικα χρησιμοποιείται η Hack\footnote{\url{https://sourcefoundry.org/hack/}}. Το μέγεθος του κυρίως κειμένου είναι 12pt και το διάστιχό του είναι επαυξημένο του προκαθορισμένου κατά το ήμισυ για άνεση κατά την ανάγνωση. |
|||
|
|||
Καταβάλλεται η μέγιστη δυνατή προσπάθεια για τη χρήση ελληνικών όρων, όπου αυτό είναι εφικτό, με τους αντίστοιχους αγγλικούς να τους συνοδεύουν σε ακόλουθες παρενθέσεις. Τα εισαγωγικά που χρησιμοποιούνται είναι τα διπλά γωνιώδη (« »), τόσο για ελληνικούς, όσο και για ξενόγλωσσους χαρακτηρισμούς. |
|||
|
|||
Επίσης, αριθμούνται επί της συνολικής έκτασης της εργασίας οι λεζάντες των σχημάτων και των πινάκων, οι υποσημειώσεις και οι βιβλιογραφικές αναφορές, με τις τελευταίες να παρατίθενται στο τέλος του εγγράφου. |
|||
|
|||
Τέλος, επισημαίνεται ότι η συγγραφή της αναφοράς πραγματοποιήθηκε στο ηλεκτρονικό τυπογραφικό σύστημα \LaTeX. Ο πηγαίος της κώδικας μπορεί να βρεθεί στο αντίστοιχο αποθετήριο κώδικα της διπλωματικής εργασίας\footnote{\url{https://gitlab.com/ecentrics/thesis-report}.}. |
@ -0,0 +1,14 @@ |
|||
\section{Οργάνωση κεφαλαίων}\label{section:1-7-document-structure} |
|||
|
|||
Η παρούσα διπλωματική εργασία οργανώνεται σε κεφάλαια, ενότητες και υποενότητες, όπως αυτά διατυπώνονται στα \hyperref[toc]{Περιεχόμενα}. Πιο συγκεκριμένα: |
|||
|
|||
\begin{itemize} |
|||
\item Στο εισαγωγικό \hyperref[chapter:1-introduction]{\textbf{Κεφάλαιο 1}} γίνεται μία σύντομη ανάλυση του όρου "αποκέντρωση", μία περιγραφή του προβλήματος και μία παρουσίαση του στόχου της εργασίας. |
|||
\item Το \hyperref[chapter:2-theoretical-background]{\textbf{Κεφάλαιο 2}} σχετίζεται με το θεωρητικό υπόβαθρο, το οποίο περιλαμβάνει όλες τις έννοιες που είναι απαραίτητες για την κατανόηση των διαδικασιών της σχεδίασης και της υλοποίησης της εφαρμογής. |
|||
\item Στο \hyperref[chapter:3-application-design]{\textbf{Κεφάλαιο 3}} αναλύεται η διαδικασία της σχεδίασης της εφαρμογής. |
|||
\item Στο \hyperref[chapter:4-application-implementation]{\textbf{Κεφάλαιο 4}} περιγράφεται η διαδικασία υλοποίησης της πιλοτικής εφαρμογής Concordia. |
|||
\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{Παράρτημα Αʹ}} περιέχει στιγμιότυπα οθόνης της υλοποιημένης εφαρμογής. |
|||
\item Το \hyperref[{appendix-b}]{\textbf{Παράρτημα Βʹ}} περιλαμβάνει πίνακες με στατιστικά του αναπτυχθέντα κώδικα. |
|||
\item Τέλος, παρατίθενται οι \textbf{βιβλιογραφικές αναφορές} που χρησιμοποιήθηκαν στο κείμενο. |
|||
\end{itemize} |
@ -1,8 +1,9 @@ |
|||
\chapter{Θεωρητικό υπόβαθρο} |
|||
\chapter{Θεωρητικό υπόβαθρο}\label{chapter:2-theoretical-background} |
|||
|
|||
\input{chapters/2.theoretical-background/2.1.hash-functions} |
|||
\input{chapters/2.theoretical-background/2.2.assymetric-cryptography} |
|||
\input{chapters/2.theoretical-background/2.3.blockchain} |
|||
\input{chapters/2.theoretical-background/2.4.smart-contracts} |
|||
\input{chapters/2.theoretical-background/2.5.distributed-databases} |
|||
\input{chapters/2.theoretical-background/2.6.decentralized-apps} |
|||
\input{chapters/2.theoretical-background/2.2.asymmetric-cryptography} |
|||
\input{chapters/2.theoretical-background/2.3.merkle-trees} |
|||
\input{chapters/2.theoretical-background/2.4.p2p-networks} |
|||
\input{chapters/2.theoretical-background/2.5.blockchain} |
|||
\input{chapters/2.theoretical-background/2.6.ethereum} |
|||
\input{chapters/2.theoretical-background/2.7.ipfs} |
@ -1,18 +1,26 @@ |
|||
\section{Συναρτήσεις κατακερματισμού} |
|||
\section{Συναρτήσεις κατακερματισμού} \label{section:2-1-hash-functions} |
|||
|
|||
% Παλιό από Drive |
|||
Οι κρυπτογραφικές συναρτήσεις κατακερματισμού (cryptographic hash functions) είναι ειδική κατηγορία συναρτήσεων κατακερματισμού σχεδιασμένες για χρήση στην κρυπτογραφία. Οι συναρτήσεις κατακερματισμού είναι μαθηματικές συναρτήσεις που δέχονται ως είσοδο δεδομένα τυχαίου μεγέθους και επιστρέφουν συμβολοσειρές σταθερού μήκους αναπαράστασης. |
|||
Οι κρυπτογραφικές συναρτήσεις κατακερματισμού (cryptographic hash functions) είναι ειδική κατηγορία συναρτήσεων κατακερματισμού σχεδιασμένες για χρήση στην κρυπτογραφία. Αποτελούν μαθηματικές συναρτήσεις που δέχονται ως είσοδο δεδομένα τυχαίου μεγέθους και επιστρέφουν συμβολοσειρές σταθερού μήκους. |
|||
|
|||
% TODO: insert diagram |
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.9\textwidth]{assets/figures/chapter-2/2.1.hash-functions-1.png} |
|||
\caption{Λειτουργία συνάρτησης κατακερματισμού} |
|||
\end{figure} |
|||
|
|||
Οι τιμές που επιστρέφει η συνάρτηση κατακερματισμού ονομάζονται τιμές κατακερματισμού (hash values ή πιο απλά hashes). Μια ιδανική κρυπτογραφική συνάρτηση κατακερματισμού έχει τις εξής βασικές ιδιότητες: |
|||
Οι τιμές που επιστρέφει η συνάρτηση κατακερματισμού ονομάζονται τιμές κατακερματισμού (hash values, digests ή απλά hashes). Μία ιδανική κρυπτογραφική συνάρτηση κατακερματισμού έχει τις εξής βασικές ιδιότητες: |
|||
|
|||
\begin{itemize} |
|||
\item Είναι ντετερμινιστική, έτσι η ίδια είσοδος παράγει πάντα την ίδια έξοδο. |
|||
\item Ο υπολογισμός των hashes για οποιοδήποτε μήνυμα είναι γρήγορος. |
|||
\item Δεν είναι εφικτό να βρεις την είσοδο από το hash, παρά μόνο δοκιμάζοντας όλα τα πιθανά μηνύματα. |
|||
\item Μία μικρή αλλαγή στο μήνυμα επιφέρει τόσο μεγάλες αλλαγές στο νέο παραγόμενο hash ώστε να φαίνεται ασυσχέτιστο με το παλιό. |
|||
\item Δεν είναι εφικτό να βρεθούν δύο διαφορετικές είσοδοι που δίνουν το ίδιο hash. |
|||
\item Είναι ντετερμινιστική, δηλαδή η ίδια είσοδος παράγει πάντα την ίδια έξοδο. |
|||
\item Είναι μη αντιστρέψιμη, δηλαδή είναι πρακτικά ανέφικτο να υπολογιστεί η είσοδος δεδομένης μιας εξόδου. |
|||
\item Είναι αμφιμονοσήμαντη (1-1), δηλαδή σε δύο διαφορετικές εισόδους αντιστοιχούν πάντα δύο εντελώς διαφορετικές έξοδοι. |
|||
\item Είναι αποδοτική, δηλαδή ο υπολογισμός του hash οποιασδήποτε εισόδου είναι γρήγορος. |
|||
\end{itemize} |
|||
|
|||
% TODO: insert diagram |
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.9\textwidth]{assets/figures/chapter-2/2.1.hash-functions-2.png} |
|||
\caption{Παράδειγμα λειτουργίας συνάρτησης κατακερματισμού} |
|||
\end{figure} |
|||
|
|||
Μία από τις δημοφιλέστερες οικογένειες κρυπτογραφικών αλγορίθμων κατακερματισμού είναι αυτή των Secure Hash Algorithms (SHA), η οποία περιλαμβάνει τους SHA-0, SHA-1, SHA-2 και SHA-3. |
@ -1,28 +0,0 @@ |
|||
\section{Κρυπτογραφία ασύμμετρου κλειδιού} |
|||
|
|||
\subsection{Ασύμμετρη κρυπτογραφία} |
|||
|
|||
% TODO |
|||
|
|||
\subsection{OpenPGP} |
|||
|
|||
% Παλιό από Drive |
|||
Το Pretty Good Privacy (PGP) αποτελεί λογισμικό κρυπτογράφησης υψηλής ασφαλείας βασισμένο στην τεχνολογία που καλείται κρυπτογράφηση "δημοσίων κλειδιών" (public key). Επιτρέπει την ανταλλαγή αρχείων και μηνυμάτων διασφαλίζοντας το απόρρητο και την ταυτότητα σε συνδυασμό με την ευκολία λειτουργίας. |
|||
|
|||
\begin{itemize} |
|||
\item Διασφάλιση του απορρήτου σημαίνει ότι μόνο αυτός για τον οποίο προορίζεται ένα μήνυμα είναι ικανός να το αποκρυπτογραφήσει και να το διαβάσει. |
|||
\item Πιστοποίηση της ταυτότητας σημαίνει ότι μηνύματα που φαίνεται πως έχουν προέλθει από κάποιο άτομο μπορούν να έχουν προέλθει μόνο από αυτό το άτομο. |
|||
\item Ευκολία σημαίνει ότι η διασφάλιση του απόρρητου και η πιστοποίησης της ταυτότητας παρέχονται χωρίς την πολυπλοκότητα της διαχείρισης κλειδιών η οποία σχετίζεται με τη συμβατική κρυπτογραφία. |
|||
\end{itemize} |
|||
|
|||
Στα κρυπτοσυστήματα δημοσίων κλειδιών ο καθένας έχει δυο συμπληρωματικά κλειδιά. Ένα που δίδεται δημόσια (public key) και ένα μυστικό (private key). Βασικά χαρακτηριστικά των δύο κλειδιών είναι ότι: 1) οτιδήποτε κρυπτογραφηθεί με το ένα αποκρυπτογραφείται μόνο από το άλλο και 2) το ένα δεν προκύπτει από το άλλο. |
|||
|
|||
% TODO: insert diagram |
|||
|
|||
Έτσι, ο καθένας μπορεί να χρησιμοποιήσει το δημόσιο κλειδί του παραλήπτη ενός μηνύματος για να κρυπτογραφήσει ένα μήνυμα προς αυτό το άτομο ενώ ο παραλήπτης μπορεί να χρησιμοποιήσει με τη σειρά του το αντίστοιχο μυστικό κλειδί για να αποκρυπτογραφήσει το μήνυμα. Κανένας άλλος εκτός από τον παραλήπτη δεν μπορεί να το αποκρυπτογραφήσει (ούτε καν το άτομο που το κρυπτογράφησε), διότι κανένας άλλος δεν έχει πρόσβαση στο μυστικό κλειδί. |
|||
|
|||
Επίσης παρέχεται υπηρεσία πιστοποίησης του μηνύματος. Το μυστικό κλειδί του αποστολέα μπορεί να χρησιμοποιηθεί για την κρυπτογράφηση του μηνύματος άρα και για την υπογραφή του. Έτσι δημιουργείται μια ψηφιακή υπογραφή του μηνύματος την οποία ο παραλήπτης ή οποιοσδήποτε άλλος μπορεί να ελέγξει χρησιμοποιώντας το δημόσιο κλειδί του αποστολέα για να την αποκρυπτογραφήσει. Αυτό αποδεικνύει ότι ο αποστολέας ήταν ο πραγματικός δημιουργός του μηνύματος και ότι το μήνυμα δεν αλλοιώθηκε από κάποιον άλλον διότι μόνο ο αποστολέας έχει στην κατοχή του το μυστικό κλειδί που έφτιαξε την υπογραφή. |
|||
|
|||
% TODO: insert diagram |
|||
|
|||
Γίνεται προφανές ότι χρησιμοποιώντας κάποιο hash αντί πραγματικών ονομάτων μπορούμε εγγυηθούμε την ανωνυμία του χρήστη αφού μόνο ένα φαινομενικά τυχαίο string είναι δημόσια διαθέσιμο. Αν ταυτόχρονα συνδέσουμε το hash με ένα PGP public key εγγυόμαστε την ταυτοποίηση του χρήστη καθώς μόνο ο κάτοχος του private κλειδιού μπορεί να υπογράψει ορθά ένα μήνυμα. |
@ -0,0 +1,37 @@ |
|||
\section{Ασύμμετρη κρυπτογραφία} \label{section:2-2-asymmetric-cryptography} |
|||
|
|||
Η ασύμμετρη κρυπτογραφία (asymmetric cryptography) ή κρυπτογραφία δημόσιου κλειδιού (public-key cryptography) αποτελεί κρυπτογραφικό σύστημα που βασίζεται στη χρήση ενός ζεύγους κλειδιών (key pair), του \textit{δημόσιου} (public key) και του \textit{ιδιωτικού} (private key). Αυτά τα κλειδιά είναι μαθηματικά συνδεδεμένα ως εξής: |
|||
|
|||
\begin{itemize} |
|||
\item Το ιδιωτικό κλειδί δε μπορεί να προκύψει γνωρίζοντας το δημόσιό του |
|||
\item Ό,τι κρυπτογραφηθεί από το ένα μπορεί να αποκρυπτογραφηθεί μόνο από το άλλο |
|||
\end{itemize} |
|||
|
|||
Η δημιουργία ενός ζεύγους κλειδιών επιτυγχάνεται μέσω μιας \textit{γεννήτριας κλειδιών} (\textenglish{key generation function}), η οποία χρησιμοποιεί ειδικούς αλγορίθμους (π.χ. RSA), δεχόμενη ως είσοδο έναν τυχαίο αριθμό. Από τα παραχθέντα κλειδιά, το δημόσιο γνωστοποιείται σε τρίτους, ενώ το ιδιωτικό παραμένει μυστικό. |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.2.asymmetric-key-generation.png} |
|||
\caption{Παραγωγή ασύμμετρου ζεύγους κλειδιών} |
|||
\end{figure} |
|||
|
|||
Ο χρήστης μπορεί να χρησιμοποιήσει τα κλειδιά για δύο βασικούς σκοπούς: |
|||
|
|||
\begin{enumerate} |
|||
\item Για να αποκρυπτογραφήσει μηνύματα άλλων χρηστών, οι οποίοι τα κρυπτογράφησαν χρησιμοποιώντας το δημόσιο κλειδί του. Με αυτόν τον τρόπο εξασφαλίζεται η \textit{εμπιστευτικότητα} (confidentiality). |
|||
\item Για να υπογράψει ψηφιακά ένα μήνυμα, κρυπτογραφώντας το hash των δεδομένων του με το ιδιωτικό του κλειδί. Έτσι, ο παραλήπτης του μηνύματος μπορεί μέσω της ληφθείσας \textit{ψηφιακής υπογραφής} (digital signature): |
|||
\begin{enumerate} |
|||
\item Να επαληθεύσει την ταυτότητα του αποστολέα, αποκρυπτογραφώντας επιτυχώς την ψηφιακή υπογραφή με το δημόσιο κλειδί του τελευταίου. Εξασφαλίζεται έτσι η \textit{πιστοποίηση} (authenticity) της προέλευσης των δεδομένων. |
|||
\item Να επιβεβαιώσει ότι το μήνυμα έφτασε αναλλοίωτο, εφόσον το hash των δεδομένων συμπίπτει με το hash εντός της ψηφιακής υπογραφής. Με αυτόν τον τρόπο εξασφαλίζεται η \textit{ακεραιότητα} (integrity) των δεδομένων. |
|||
\end{enumerate} |
|||
\end{enumerate} |
|||
|
|||
Με τον συνδυασμό των παραπάνω, λέμε ότι δύο χρήστες μπορούν να επικοινωνούν μεταξύ τους με \textit{κρυπτογράφηση απ' άκρη σ' άκρη} (end to end encryption). |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.2.asymmetric-end-to-end-communication.png} |
|||
\caption{Κρυπτογράφηση απ' άκρη σ' άκρη} |
|||
\end{figure} |
|||
|
|||
Μία προσέγγιση στην κρυπτογραφία δημόσιου κλειδιού είναι η κρυπτογραφία ελλειπτικής καμπύλης (Elliptic-Curve Cryptography ή ECC). Η ECC βασίζεται στην αλγεβρική δομή των ελλειπτικών καμπυλών σε πεπερασμένα πεδία και υπερέχει της non-EC κρυπτογραφίας, καθώς επιτρέπει τη δημιουργία μικρότερων κλειδιών με ισοδύναμη ασφάλεια. Ένα από τα πρωτόκολλά της είναι ο Elliptic Curve Digital Signature Algorithm (ECDSA), ο οποίος χρησιμοποιείται για την ψηφιακή υπογραφή δεδομένων και αποτελεί το EC-ανάλογο του DSA (Digital Signature Algorithm).\cite{2.2-ecdsa} |
@ -1,14 +0,0 @@ |
|||
\section{Blockchain} |
|||
|
|||
% Παλιό από Drive |
|||
Πρακτικά το blockchain είναι μία διανεμημένη δημόσια βάση δεδομένων που διατηρεί έναν αμετάβλητο κατάλογο (immutable ledger) ψηφιακών συναλλαγών (digital transactions) ενός νομίσματος (token). Ο κατάλογος αυτός παίρνει τη μορφή μιας αλυσίδας (chain) από blocks συναλλαγών που διαδέχονται το ένα το άλλο. |
|||
|
|||
Ως προς την κυριότητα επί αυτής, η βάση δεν ελέγχεται από κάποια κεντρική οντότητα, αλλά αναπαράγεται σε όλους τους (πλήρεις) κόμβους (full nodes) που απαρτίζουν συλλογικά το δίκτυο. Με το δικό του κόμβο μπορεί να συμμετάσχει οποιοσδήποτε το επιθυμεί, ωστόσο δεν είναι αναγκαίο για τον χρήστη που θέλει απλά να συναλλαγεί στο δίκτυο να διαθέτει τον κόμβο του (διαθέτει απλά έναν light node). |
|||
|
|||
Η λειτουργία των κόμβων (ενν. full) είναι η επικύρωση των συναλλαγών που επιθυμούν να πραγματοποιήσουν οι χρήστες. Για την επικύρωση, ανταγωνίζονται ο ένας τον άλλον για το ποιος θα λύσει πρώτος ένα σύνθετο αλγοριθμικό πρόβλημα που συσχετίζεται με το εκάστοτε block. Το κίνητρο για τη δαπάνη της επεξεργαστικής ισχύος που απαιτείται για αυτό είναι η ανταμοιβή του κόμβου που θα καταλήξει πρώτος στη λύση του προβλήματος με ένα ποσό από tokens. Ανάλογα με τον αλγόριθμο που έχει προσυμφωνηθεί να χρησιμοποιείται στο εκάστοτε blockchain (Proof of Work, Proof of Stake κτλ.), οι κόμβοι του χαρακτηρίζονται ως miners/stakers/κ.ά. . |
|||
|
|||
Έτσι, με το που προκύψει λύση, δημιουργείται ένα νέο block στο οποίο καταγράφονται -μεταξύ άλλων- οι συναλλαγές που πραγματοποιούν οι χρήστες, μια παραπομπή στο προηγούμενο block και η λύση του αλγορίθμου. O κόμβος που επέλυσε πρώτος το πρόβλημα επιβραβεύεται με ένα ποσό νομισμάτων, που απαρτίζεται τόσο από μια προσυμφωνηθείσα ποσότητα νομισμάτων που δημιορυργείται σε κάθε block, όσο και με τα τέλη συναλλαγής (transaction fees) που κατέβαλαν στο δίκτυο οι χρήστες που πραγματοποίησαν τις συναλλαγές. |
|||
|
|||
% TODO: insert diagram |
|||
|
|||
Η διευθυνσιοδότηση σε ένα blockchain επιτυγχάνεται αξιοποιώντας το PGP. Δηλαδή αποστολείς και παραλήπτες είναι πάντα κάτοχοι των ιδιωτικών κλειδιών κάποιων δημοσίων διευθύνσεων. Ο οποιοσδήποτε μπορεί να παράγει ανά πάσα στιγμή στον υπολογιστή του ένα valid PGP ζεύγος και να λαμβάνει tokens στην παραχθείσα δημόσια διεύθυνση (το πλήθος των έγκυρων δημοσίων διευθύνσεων είναι πρακτικά ανεξάντλητο π.χ. $2^{160}$ για το Bitcoin). |
@ -0,0 +1,20 @@ |
|||
\section{Δένδρα Merkle} \label{section:2-3-merkle-trees} |
|||
|
|||
Ένα δένδρο Merkle (Merkle tree ή hash tree) είναι μία δενδρική δομή δεδομένων, η οποία απαρτίζεται από φύλλα (leaf nodes) που περιέχουν hashes από blocks δεδομένων και από άλλους κόμβους (non-leaf nodes) που περιέχουν τα hashes των θυγατρικών τους. Στην κορυφή του δένδρου βρίσκεται ο ριζικός κόμβος με το λεγόμενο root hash.\cite{2.3-merkle-tree} |
|||
|
|||
Η πιο συνηθισμένη υλοποίηση είναι το δυαδικό (binary) δένδρο Merkle, το οποίο περιλαμβάνει δύο θυγατρικούς κόμβους (child nodes) κάτω από κάθε γονικό (non-leaf) κόμβο, και είναι αυτό που αναλύεται στη συνέχεια. |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.85\textwidth]{assets/figures/chapter-2/2.3.merkle-tree.png} |
|||
\caption{Παράδειγμα δυαδικού δένδρου Merkle} |
|||
\end{figure} |
|||
|
|||
Τα Merkle trees επιτρέπουν την αποδοτική και ασφαλή επαλήθευση των περιεχομένων που ανήκουν σε σετ δεδομένων μεγάλου μεγέθους. Η βασική ιδιότητα είναι ότι για κάθε σετ δεδομένων υπάρχει ακριβώς ένα πιθανό δένδρο, το οποίο δε γίνεται να τροποποιηθεί χωρίς να αλλάξει ταυτόχρονα και το root hash. |
|||
|
|||
Έτσι, μέσω των λεγόμενων Merkle proofs, μπορούμε: |
|||
\begin{itemize} |
|||
\item Να αποφανθούμε εάν κάποια δεδομένα ανήκουν στο δένδρο, υπολογίζοντας (για το εκάστοτε leaf node) hashes πλήθους ανάλογου του λογαρίθμου του συνολοικού αριθμού των φύλλων. |
|||
\item Να αποδείξουμε συνοπτικά την εγκυρότητα ενός τμήματος κάποιου σετ δεδομένων, χωρίς να χρειαστεί να αποθηκεύσουμε ολόκληρο το σύνολο δεδομένων. |
|||
\item Να διασφαλίσουμε την εγκυρότητα ενός συγκεκριμένου συνόλου δεδομένων εντός ενός μεγαλύτερου σύνολου, χωρίς να χρειαστεί να αποκαλυφθεί το περιεχόμενο οποιουδήποτε εκ των δύο.\cite{2.3-merkle-proofs-explained} |
|||
\end{itemize} |
@ -0,0 +1,18 @@ |
|||
\section{Δίκτυα Ομότιμων Κόμβων} \label{section:2-4-p2p-networks} |
|||
|
|||
Τα δίκτυα ομότιμων κόμβων ή Peer-to-Peer (P2P) networks αποτελούν μία κατανεμημένη αρχιτεκτονική δικτύων, οι συμμετέχοντες (κόμβοι) της οποίας μοιράζονται ένα τμήμα των πόρων τους, με στόχο την παροχή κάποιας υπηρεσίας (π.χ. τον διαμοιρασμό περιεχομένου). Εν αντιθέσει με συγκεντρωτικά δίκτυα τύπου client-server, οι κόμβοι (nodes) έχουν απευθείας πρόσβαση στους πόρους, χωρίς τη διαμεσολάβηση ενδιάμεσων οντοτήτων. Οι συμμετέχοντες ενός τέτοιου δικτύου είναι, δηλαδή, ταυτόχρονα, τόσο πάροχοι, όσο και αιτούντες των πόρων και της παρεχόμενης υπηρεσίας.\cite{2.4-p2p-networking} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.4.p2p-networks} |
|||
\caption{Αρχιτεκτονικές δικτύων client-server και P2P} |
|||
\end{figure} |
|||
|
|||
Τα P2P networks μπορούν να χωριστούν σε δύο κατηγορίες: |
|||
|
|||
\begin{itemize} |
|||
\item Στα "Καθαρά" (Pure) P2P networks, στα οποία ισχύει ότι η αφαίρεση ενός τυχαίου κόμβου από το δίκτυο δεν προκαλεί κάποιο πρόβλημα σε αυτό. |
|||
\item Στα "Υβριδικά" (Hybrid) P2P networks, στα οποία συμμετέχουν επιπλέον και κεντρικές οντότητες, παρέχοντας απαραίτητα τμήματα των προσφερόμενων υπηρεσιών. |
|||
\end{itemize} |
|||
|
|||
Από εδώ και στο εξής, εάν δεν αναφέρεται ρητά η κατηγορία κάποιου P2P network, θα εννοείται ότι ανήκει στην πρώτη. |
@ -1,7 +0,0 @@ |
|||
\section{Έξυπνα συμβόλαια} |
|||
|
|||
Smart Contracts |
|||
- τι είναι; |
|||
- γιατί τα χρειαζόμαστε; ποιο πρόβλημα λύνουν; |
|||
- αναφορά στα έξοδα |
|||
- πόσα, ποια blockchains υλοποιούν smart contracts; |
@ -0,0 +1,25 @@ |
|||
\section{Blockchain} \label{section:2-5-blockchain} |
|||
|
|||
Το 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} |
|||
|
|||
\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 επιτυγχάνεται αξιοποιώντας την κρυπτογραφία δημόσιου κλειδιού. Το πρωτόκολλο του εκάστοτε blockchain ορίζει έναν αλγόριθμο για την παραγωγή ζευγών κλειδιών (π.χ. ECDSA στο Bitcoin). Το δημόσιο από αυτά ορίζει τη διεύθυνση, ενώ το ιδιωτικό παραμένει μυστικό, υπό την κατοχή του χρήστη. Με αυτό τον τρόπο προκύπτει ένα πρακτικά ανεξάντλητο πλήθος πιθανών έγκυρων δημόσιων διευθύνσεων (π.χ. $2^{160}$ για το Bitcoin), στις οποίες οι χρήστες μπορούν να στέλνουν και να λαμβάνουν ποσά του εκάστοτε κρυπτονομίσματος. Για την αποστολή ενός ποσού, δηλώνουν το fee που επιθυμούν να καταβάλουν και υπογράφουν την επιθυμητή συναλλαγή με το ιδιωτικό τους κλειδί. Η συναλλαγή αναμεταδίδεται στο δίκτυο και παραμένει στο transaction pool μέχρις ότου να γίνει αποδεκτή και να συμπεριληφθεί στο επόμενο block. |
|||
|
|||
Από τεχνική σκοπιά, το blockchain μπορεί να θεωρηθεί ως μία μηχανή καταστάσεων βασισμένη σε συναλλαγές (transaction-based state machine). Δηλαδή, ξεκινάει από μία αρχική κατάσταση (genesis state), η οποία τροποποιείται σταδιακά με κάθε block, και περιλαμβάνει ανά πάσα στιγμή τις διευθύνσεις με τα ποσά των νομισμάτων που τις αντιστοιχούν. |
|||
|
|||
\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 είναι αρχιτεκτονικά και πολιτικά αποκεντρωτικό, καθώς δε διαθέτει δομικά κάποιο κεντρικό σημείο αποτυχίας, ούτε ελέγχεται από κάποιον. Ωστόσο, είναι λογικά συγκεντρωτικό, αφού υπάρχει μία κοινά αποδεκτή κατάσταση και το σύστημα συμπεριφέρεται μακροσκοπικά ως ένας ενιαίος υπολογιστής. |
@ -1,8 +0,0 @@ |
|||
\section{Αποκεντρωτική αποθήκευση δεδομένων (βάση δεδομένων)} |
|||
|
|||
Distributed databases |
|||
- τι είναι; |
|||
- ποιες είναι οι διαφορές από το blockchain; |
|||
- γιατί τις χρειαζόμαστε; ποιο πρόβλημα λύνουν; |
|||
- πόσες, ποιες υπάρχουν; παραδείγματα/διαφορές |
|||
- τεχνική ανάλυση (προτερήματα, drawbacks) |
@ -1 +0,0 @@ |
|||
\section{Αποκετροποιημένες εφαρμογές} |
@ -0,0 +1,103 @@ |
|||
\section{Ethereum} \label{section:2-6-ethereum} |
|||
|
|||
\logo{chapter-2/2.6.ethereum-logo}{Ethereum logo} |
|||
|
|||
Το 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 και tokens, καθώς και να αλληλεπιδρούν με smart contracts.\cite{2.6-ethereum-documentation} Χωρίζονται σε δύο κατηγορίες: στους λογαριασμούς εξωτερικής κατοχής (\textenglish{externally owned accounts} ή EOAs) και στους λογαριασμούς συμβολαίων (contract accounts). |
|||
|
|||
Οι λογαριασμοί εξωτερικής κατοχής δημιουργούνται χωρίς κόστος και ελέγχονται μέσω ιδιωτικών κλειδιών. Μπορούν να πραγματοποιούν μόνο συναλλαγές μεταφοράς ETH ή κάποιου token. |
|||
|
|||
Από την άλλη, οι λογαριασμοί συμβολαίων απαιτούν κάποιο κόστος δημιουργίας, καθώς χρησιμοποιούν αποθηκευτικό χώρο επί του blockchain, ενώ ελέγχονται αποκλειστικά από τον κώδικά τους. Οι συναλλαγές που πραγματοποιούν προς άλλους λογαριασμούς είναι μόνο σαν αντίδραση σε μία εισερχόμενη συναλλαγή, όπως ορίζει ο κώδικας του smart contract τους. |
|||
|
|||
Πιο αναλυτικά, τα πεδία που διαθέτουν οι λογαριασμοί στο Ethereum είναι τα εξής: |
|||
|
|||
\begin{itemize} |
|||
\item Το \textbf{nonce}: ένας μετρητής που υποδεικνύει τον αριθμό των απεσταλμένων συναλλαγών του λογαριασμού. Αυτό διασφαλίζει ότι οι συναλλαγές διεκπεραιώνονται μόνο μία φορά. Σε έναν λογαριασμό συμβολαίου, αυτός ο αριθμός αντιπροσωπεύει τον αριθμό των συμβολαίων που δημιουργήθηκαν από εκείνον. |
|||
|
|||
\item Το \textbf{balance}: το ποσό σε ETH που διαθέτει ο λογαριασμός, μετρημένο σε wei (1 ETH = $10^{18}$ wei). |
|||
|
|||
\item Το \textbf{codeHash}: ένα hash που αναφέρεται στον κώδικα του λογαριασμού (contract code). Είναι χαρακτηριστικό των λογαριασμών συμβολαίων (στους λογαριασμούς εξωτερικής κατοχής είναι hash μίας κενής συμβολοσειράς) και, σε αντίθεση με τα άλλα πεδία, αφότου οριστεί παραμένει αμετάβλητο. |
|||
|
|||
\item Το \textbf{storageRoot}: το root hash του δένδρου Merkle των αποθηκευμένων δεδομένων του smart contract, εφόσον πρόκειται για έναν λογαριασμό συμβολαίου (δε χρησιμοποιείται σε λογαριασμούς εξωτερικής κατοχής). |
|||
\end{itemize} |
|||
|
|||
Η δημιουργία των λογαριασμών επιτυγχάνεται μέσω της παραγωγής ενός ζεύγους κλειδιών, αξιοποιώντας τον |
|||
ECDSA (βλ. ενότητα \ref{section:2-2-asymmetric-cryptography}). Έτσι, το ιδιωτικό κλειδί χρησιμοποιείται για να υπογράφονται ψηφιακά οι συναλλαγές, ενώ το δημόσιο ορίζει τη δημόσια διεύθυνση του λογαριασμού (είναι της μορφής "0x + τα 20 τελευταία bytes του Keccak-256\footnote{Ο Keccak-256 αποτελεί τον κρυπτογραφικό αλγόριθμο κατακερματισμού που χρησιμοποειίται στο Ethereum. Πρόκειται για τον αλγόριθμο SHA3-256 πριν την τυποποίησή του από το NIST.} hash του δημόσιου κλειδιού"). |
|||
|
|||
Κατά κύριο λόγο, οι χρήστες παράγουν και διαχειρίζονται τα ιδιωτικά κλειδιά των λογαριασμών εξωτερικής κατοχής μέσω ενός πορτοφολιού (wallet). Τα wallets αποτελούν εφαρμογές, οι οποίες δείχνουν το balance του λογαριασμού και παρέχουν τη δυνατότητα αποστολής/ λήψης ETH και tokens από/ σε αυτόν. Ορισμένα προτοφόλια προσφέρουν περαιτέρω λειτουργίες, σημαντικότερη εκ των οποίων είναι η διασύνδεση του λογαριασμού με αποκεντρωμένες εφαρμογές. Επί του παρόντος, το πιο διαδεδομένο πορτοφόλι τέτοιου τύπου είναι το MetaMask\footnote{\url{https://metamask.io/}}. |
|||
|
|||
\subsection{Smart Contracts} |
|||
Με λίγα λόγια, τα smart contracts αποτελούν αυτόνομα κομμάτια κώδικα, τα οποία είναι αποθηκευμένα στο 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 τον κώδικα και τα αρχικά δεδομένα τους. |
|||
|
|||
Επιπλέον, ο κώδικάς τους ενεργοποιείται μονάχα όταν δεχθούν μία έγκυρη συναλλαγή από κάποιον άλλον λογαριασμό (είτε εξωτερικής κατοχής, είτε συμβολαίου). Η συναλλαγή αυτή εμπεριέχει, πέρα από το απαιτούμενο fee, ένα συνοδευτικό μήνυμα με πληροφορίες σχετικές με τη συνάρτηση που πρέπει να εκτελεστεί. Η δε συνάρτηση μπορεί να πραγματοποιεί ποικίλες διαφορετικές ενέργειες, όπως την ανάγνωση και την εγγραφή στην εσωτερική αποθήκευση, την πραγματοποίηση νέων συναλλαγών, ή, ακόμα, τη δημιουργία νέων συμβολαίων. |
|||
|
|||
Η σύνταξη των smart contracts γίνεται κατά βάση σε γλώσσες υψηλού επιπέδου και, συγκεκριμένα, στις Solidity, Vyper και Fe\footnote{\url{https://soliditylang.org/}, \url{https://github.com/vyperlang/vyper} και \url{https://fe-lang.org/}}. Πριν την εγγραφή τους στο blockchain, μεταγλωττίζονται σε εμηνεύσιμο από την EVM bytecode, η οποία είναι υπεύθυνη για την αποθήκευση και την εκτέλεσή του (βλ. υποενότητα \ref{subsection:2-6-5-evm}). |
|||
|
|||
\subsection{DApps} |
|||
Οι DApps στο οικοσύστημα του 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, πλήρη ακεραιότητα δεδομένων και επαληθεύσιμη συμπεριφορά. |
|||
|
|||
Ωστόσο, χαρακτηρίζονται και από μία σειρά αξιοσημείωτων μειονεκτημάτων, όπως τα παρακάτω: |
|||
\begin{itemize} |
|||
\item Δυσκολία συντήρησης: Συντηρούνται δυσκολότερα από τις συγκεντρωτικές εφαρμογές, εξαιτίας της αμεταβλητότητας του κώδικα και των δεδομένων επί του blockchain. |
|||
\item Επιβάρυνση απόδοσης: Υπάρχει τεράστια επιβάρυνση απόδοσης (performance overhead) και η κλιμάκωση (scaling) είναι πολύ δύσκολη, καθώς απαιτείται όλοι οι κόμβοι να εκτελούν και να αποθηκεύουν όλες τις συναλλαγές. |
|||
\item Συμφόρηση δικτύου: Επί του παρόντος, το δίκτυο μπορεί να επεξεργαστεί μόνο περίπου 10-15 συναλλαγές ανά δευτερόλεπτο. Εάν οι συναλλαγές αποστέλλονται με ταχύτερο ρυθμό από αυτόν, θα αυξάνονται παράλληλα και οι μη επιβεβαιωμένες συναλλαγές που αναμένουν να εκτελεστούν. |
|||
\item Κακή εμπειρία χρήστη: Επί του παρόντος, είναι δύσκολο για τον μέσο τελικό χρήστη να αλληλεπιδράσει με το blockchain με ευκολία και ασφάλεια, καθώς απαιτούνται ενέργειες όπως η εγκατάσταση ειδικών εργαλείων για τη διασύνδεση με αυτό, η δημιουργία wallet, η διαφύλαξη του ιδιωτικού του κλειδιού και η προσθήκη ETH για την εξόφληση των τελών. |
|||
\end{itemize} |
|||
|
|||
Παρ' όλα τα μειονεκτήματα, τα οποία μετριάζονται με τον καιρό μέσω συνεχών αναβαθμίσεων της πλατφόρμας, υπάρχει ήδη ένα ευρύ φάσμα εφαρμογών που μπορούν να υλοποιηθούν στο Ethereum, αξιοποιώντας τα ισχυρά του πλεονεκτήματα. Οι εφαρμογές αυτές μπορούν να διακριθούν σε τρεις κατηγορίες: |
|||
\begin{enumerate} |
|||
\item Οικονομικές εφαρμογές, οι οποίες παρέχουν στους χρήστες ισχυρούς τρόπους διαχείρισης και σύναψης συμβάσεων χρησιμοποιώντας τα χρήματά τους. Αυτό περιλαμβάνει υπονομίσματα, χρηματοοικονομικά παράγωγα, συμβάσεις αντιστάθμισης κινδύνου, πορτοφόλια αποταμίευσης, διαθήκες και ακόμα και ορισμένες κατηγορίες συμβάσεων εργασίας πλήρους κλίμακας. |
|||
|
|||
\item Ημι-οικονομικές εφαρμογές, όπου εμπλέκονται χρήματα, αλλά η λειτουργία τους εμπεριέχει παράλληλα και μία αξιοσημείωτη μη νομισματική πλευρά. Ένα τέτοιο παράδειγμα είναι οι αυτόματες πληρωμές για λύσεις σε υπολογιστικά προβλήματα (βλ. Gitcoin). |
|||
|
|||
\item Μη οικονομικές εφαρμογές, όπως η αποκεντρωμένη αποθήκευση δεδομένων, συστήματα ταυτότητας (identity) και φήμης (reputation), διαδικτυακές ψηφοφορίες και αποκεντρωμένη διακυβέρνηση. Οι τελευταίες εισάγουν και την έννοια των Αποκεντρωμένων Αυτόνομων Οργανώσεων (Decentralized Autonomous Organizations ή DAOs), οντοτήτων που ενεργούν αυτόνομα, χωρίς την ανάγκη διαμεσολάβησης κάποιας συγκεντρωτικής (\textenglish{centralized}) αρχής.\cite{2.6-ethereum-whitepaper} |
|||
\end{enumerate} |
|||
|
|||
\subsection{Tokens} |
|||
|
|||
Η λέξη "token" προέρχεται από τη λέξη "tācen" των Παλαιών Αγγλικών και σημαίνει σημάδι ή |
|||
σύμβολο. Στην καθημερινότητα, ο όρος χρησιμοποιείται, κατά κύριο λόγο, για την περιγραφή αντικειμένων ειδικού σκοπού, τα οποία μοιάζουν με κέρματα και έχουν ασήμαντη εγγενή αξία (π.χ. μάρκες παιχνιδιών). Συνήθως, η χρήση των tokens περιορίζεται σε συγκεκριμένες επιχειρήσεις, οργανισμούς ή τοποθεσίες, πράγμα το οποίο σημαίνει ότι δεν ανταλλάσσονται εύκολα και τυπικά έχουν μόνο μία λειτουργία.\cite{2.6-ethereum-mastering} |
|||
|
|||
Ωστόσο, στο Ethereum blockchain η έννοια των tokens επεκτείνεται και επαναπροσδιορίζεται. Πλέον δεν υπάρχουν περιορισμοί χρήσης και ιδιοκτησίας, ενώ η αξία τους ποικίλει, ανάλογα με το τι αντιπροσωπεύουν (π.χ. νομίσματα, περιουσιακά στοιχεία, ή δικαιώματα πρόσβασης). Μπορούν, δε, να ανταλλαχθούν σε παγκόσμιο επίπεδο, για άλλα tokens ή για άλλα νομίσματα. |
|||
|
|||
Τα tokens που ορίζονται σε Ethereum smart contracts μπορούν να έχουν μία ή περισσότερες από τις παρακάτω χρήσεις: |
|||
|
|||
\begin{itemize} |
|||
\item Νόμισμα (currency) |
|||
\item Πόρος (resource), π.χ. για το διαμοιρασμό CPU ή storage εντός ενός δικτύου |
|||
\item Περιουσιακό στοιχείο (asset), εγγενούς ή εξωγενούς, υλικού |
|||
ή άυλου (π.χ. χρυσός, πετρέλαιο, ενέργεια, ακίνητο) |
|||
\item Πρόσβαση (access), ψηφιακή ή |
|||
φυσική (π.χ. forum, δωμάτιο ξενοδοχείου) |
|||
\item Μετοχικό κεφάλαιο (equity) ενός ψηφιακού οργανισμού (π.χ. μίας DAO) ή μίας νομικής οντότητας (π.χ. μίας εταιρείας) |
|||
\item Ψηφοφορία (voting), παρέχοντας δικαιώματα ψήφου σε ένα ψηφιακό ή νομικό σύστημα |
|||
\item Συλλεκτικό (collectible), ψηφιακό ή φυσικό |
|||
\item Ταυτότητα (identity), ψηφιακής ή νομικής φύσεως |
|||
\item Πιστοποίηση (attestation), π.χ. πτυχίο, πιστοποιητικό γέννησης |
|||
\item Χρησιμότητα (utility), για πρόσβαση ή πληρωμή μίας υπηρεσίας |
|||
\end{itemize} |
|||
|
|||
Ένα σημαντικό κριτήριο κατηγοριοποίησης των tokens είναι η εναλλαξιμότητα (fungibility) τους. Ένα token είναι εναλλάξιμο όταν οποιαδήποτε μονάδα του μπορεί να αντικατασταθεί με μία άλλη χωρίς καμία διαφορά στην αξία ή τη λειτουργία του. Από την άλλη πλευρά, ένα non-fungible token (NFT) αντιπροσωπεύει ένα μοναδικό υλικό ή άυλο στοιχείο και, επομένως, είναι μη εναλλάξιμο. |
|||
|
|||
Τέλος, τα tokens συχνά ακολουθούν κάποια καθορισμένα standards στην υλοποίησή τους. Τα δημοφιλέστερα από αυτά είναι τα ERC-20 και ERC-777 (για fungible tokens), το ERC-721 (για NFTs) και το ERC-1155 (για semi-fungible tokens ή SFTs). |
|||
|
|||
\subsection{EVM} \label{subsection:2-6-5-evm} |
|||
Τα smart contracts (και, κατ' επέκταση, οι DApps) εκτελούνται από την εικονική μηχανή του Ethereum (Ethereum Virtual Machine ή EVM). Η EVM αποτελεί μία quasi\footnote{"Quasi" ("σχεδόν") επειδή όλες οι διαδικασίες εκτέλεσης περιορίζονται σε έναν πεπερασμένο αριθμό υπολογιστικών βημάτων από την ποσότητα gas που είναι διαθέσιμη για οποιαδήποτε εκτέλεση ενός smart contract.}–Turing-complete μηχανή καταστάσεων αρχιτεκτονικής βασισμένης σε στοίβα (stack-based architecture). Σε υψηλό επίπεδο, η EVM μπορεί να θεωρηθεί ως ένας παγκόσμιος αποκεντρωμένος υπολογιστής που περιέχει εκατομμύρια εκτελέσιμα αντικείμενα, το καθένα με τη δική του μόνιμη αποθήκη δεδομένων. |
|||
|
|||
Η EVM αποθηκεύει όλες τις τιμές της μνήμης σε μια στοίβα και λειτουργεί με μέγεθος λέξης 256 bit, κυρίως για τη διευκόλυνση των εγγενών λειτουργιών κατακερματισμού και ελλειπτικής καμπύλης. Διαθέτει ένα σύνολο διευθυνσιοδοτήσιμων στοιχείων δεδομένων: |
|||
|
|||
\begin{itemize} |
|||
\item Έναν αμετάβλητο κώδικα προγράμματος σε εικονική μνήμη ROM, φορτωμένο με τον \textenglish{bytecode} του smart contract προς εκτέλεση. |
|||
\item Μία πτητική (volatile) μνήμη, με κάθε θέση ρητά αρχικοποιημένη στο μηδέν. |
|||
\item Ένας χώρος μόνιμης αποθήκευσης, που είναι μέρος του Ethereum state, επίσης αρχικά μηδενισμένος. |
|||
\end{itemize} |
|||
|
|||
Υπάρχει, επίσης, ένα σύνολο μεταβλητών περιβάλλοντος και δεδομένων, τα οποία είναι διαθέσιμα κατά την εκτέλεση.\cite{2.6-ethereum-mastering} |
@ -0,0 +1,26 @@ |
|||
\section{IPFS} \label{section:2-7-ipfs} |
|||
|
|||
\logo{chapter-2/2.7.ipfs-logo}{IPFS logo} |
|||
|
|||
Το 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 (\url{https://multiformats.io/multihash/}). |
|||
\item \textbf{Σύνδεση περιεχομένου μέσω κατευθυνόμενων άκυκλων γράφων (Directed Acyclic Graphs ή DAGs)}. Το IPFS αξιοποιεί DAGs (και συγκεκριμένα Merkle DAGs), μίας δομής δεδομένων της οποίας κάθε κόμβος έχει ως μοναδικό αναγνωριστικό το hash του περιεχομένου του (το CID). |
|||
|
|||
\begin{enumitemcenteredfigure} |
|||
\includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.7.merkle-dag.png} |
|||
\caption[Παράδειγμα Merkle DAG]{Παράδειγμα Merkle DAG\footnotemark} |
|||
\end{enumitemcenteredfigure} |
|||
\footnotetext{\url{https://proto.school/merkle-dags/}} |
|||
|
|||
Στο παραπάνω Merkle DAG τα baf...i αποτελούν τα CID των αρχείων και των φακέλων. Το δένδρο δημιουργείται από κάτω προς τα πάνω, υπολογίζοντας κάθε φορά τα κατάλληλα hashes/CIDs. Σε περίπτωση που το περιεχόμενο ενός κόμβου αλλάξει, τότε αλλάζει τόσο το CID του, όσο και τα CIDs όλων των προγόνων του. |
|||
\item \textbf{Ανακάλυψη περιεχομένου μέσω κατανεμημένων πινάκων κατακερματισμού (\textenglish{Distributed Hash Tables ή DHTs})}. Ο DHT είναι ένα κατανεμημένο σύστημα για την αντιστοίχιση κλειδιών σε τιμές. Στο IPFS αποτελεί το θεμελιώδες συστατικό του συστήματος δρομολόγησης περιεχομένου και λειτουργεί ως διασταύρωση μεταξύ καταλόγου και συστήματος πλοήγησης. Πρακτικά πρόκειται για ένα πίνακα που αποθηκεύει ποιος έχει ποια δεδομένα και, μέσω του οποίου, ο χρήστης βρίσκει τον peer που έχει αποθηκευμένο το επιθυμητό περιεχόμενο. |
|||
\end{itemize} |
|||
|
|||
Κάτι που θα πρέπει να σημειωθεί είναι πως, σαν προεπιλογή, οι IPFS κόμβοι αντιμετωπίζουν τα αποθηκευμένα δεδομένα ως προσωρινή μνήμη (cache), πράγμα που σημαίνει ότι δεν υπάρχει καμία εγγύηση ότι εκείνα θα συνεχίσουν να παραμένουν αποθηκευμένα σε αυτούς. Για την αποφυγή της διαγραφής τους από τον garbage collector, τα δεδομένα θα πρέπει να σημανθούν ως σημαντικά, μέσω του "καρφιτσώματος" (pinning). Έτσι, για την ομαλή λειτουργία π.χ. μίας DApp που βασίζεται στο IPFS, θα πρέπει το περιεχόμενό της να είναι pinned από αρκετούς peers και/ή να γίνεται χρήση κάποιου pinning service, ώστε να εξασφαλίζεται διαθεσιμότητά του. |
|||
|
|||
Βασικό πλεονέκτημα του IPFS είναι ότι ο αποκεντρωτικός του χαρακτήρας δίνει τη δυνατότητα να παρέχεται το περιεχόμενο από πολλούς κόμβους, οι οποίοι βρίσκονται σε διαφορετικές τοποθεσίες και δεν υπάγονται σε κάποια συγκεκριμένη κεντρική αρχή. Με αυτόν τον τρόπο, τα δεδομένα είναι πιο ανθεκτικά τόσο από άποψη διαθεσιμότητας (αν ένας κόμβος αποσυνδεθεί, θα υπάρχει κάποιος άλλος), όσο και από άποψη αντοχής στη λογοκρισία. Μπορεί, επίσης, να ανακτώνται γρηγορότερα, εφόσον τα διαθέτουν κάποιοι κοντινοί peers, πράγμα ιδιαίτερα πολύτιμο για κοινότητες που είναι καλά δικτυωμένες τοπικά αλλά δεν έχουν καλή σύνδεση με το ευρύτερο διαδίκτυο. |
@ -1,8 +1,12 @@ |
|||
\chapter{Σχεδίαση εφαρμογής} |
|||
\chapter{Σχεδίαση εφαρμογής}\label{chapter:3-application-design} |
|||
|
|||
\input{chapters/3.application-design/3.1.application-parts} |
|||
\input{chapters/3.application-design/3.2.user-categories} |
|||
\input{chapters/3.application-design/3.3.use-cases} |
|||
\input{chapters/3.application-design/3.4.technology-stack} |
|||
\input{chapters/3.application-design/3.5.implementation-methodology-specification} |
|||
\input{chapters/3.application-design/3.6.architecture.design} |
|||
Σε αυτό το κεφάλαιο περιγράφεται η διαδικασία σχεδίασης της εφαρμογής Concordia, από τη σύλληψη της ιδέας και την επιλογή της τεχνολογικής στοίβας, μέχρι τον ορισμό της αρχιτεκτονικής της και τον διαχωρισμό του προγραμματιστικού έργου σε sprints. |
|||
|
|||
\input{chapters/3.application-design/3.1.idea-conception} |
|||
\input{chapters/3.application-design/3.2.technology-stack} |
|||
\input{chapters/3.application-design/3.3.design-methodology} |
|||
\input{chapters/3.application-design/3.4.user-categories} |
|||
\input{chapters/3.application-design/3.5.software-requirements} |
|||
\input{chapters/3.application-design/3.6.use-cases} |
|||
\input{chapters/3.application-design/3.7.architecture-design} |
|||
\input{chapters/3.application-design/3.8.implementation-methodology-specification} |
|||
|
@ -1,19 +0,0 @@ |
|||
\section{Λογικά μέρη} |
|||
|
|||
% Παλιό από Drive |
|||
Η πλατφόρμα μπορεί να διαχωριστεί σε δύο λογικά μέρη: |
|||
|
|||
1) Το πρώτο μέρος αποτελεί μία αυτοτελή και πλήρως αποκεντρωτική πλατφόρμα που στόχος της είναι να παρέχει τη δυνατότητα ελευθερίας λόγου απρόσβλητου σε λογοκρισία και διαγραφή από κεντρικές οντότητες εξουσίας. Στην ουσία εδώ θα μπορεί - σε μια απλοποιημένη εκδοχή - οποιοσδήποτε να δημιουργήσει topics ή να απαντήσει σε άλλα. Επεξεργαστικός πυρήνας θα είναι ένα smart contract το οποίο θα δέχεται από τους χρήστες transactions και θα τα εγγράφει στο Storage Layer: |
|||
|
|||
% TODO: insert diagram |
|||
|
|||
Το μειονέκτημα αυτού του κομματιού είναι πως για να λειτουργήσει απαιτεί για κάθε transaction οι χρήστες να καταβάλουν κάποιο τέλος για τα fees. Αν και υπάρχουν σχέδια από την ομάδα ανάπτυξης του Ethereum για τη μείωσή τους στο μέλλον (έως και 10-2), τα fees στη χρήση της EVM θα είναι αναπόφευκτα. Ωστόσο θα πρέπει να σημειωθεί ότι αφενός παρέχουν μια μορφή προστασίας απέναντι σε κακόβουλους χρήστες που θα πλημμύριζαν την εφαρμογή με ανεπιθύμητο ποσοτικά/ποιοτικά περιεχόμενο (θα τους ήταν οικονομικά ασύμφορη μια τέτοια επίθεση), αφετέρου υπάρχουν κάποια workarounds για να μειωθεί δραστικά η εμπλοκή του χρήστη με την καταβολή τελών, κάτι που περιγράφεται παρακάτω στις κατηγορίες χρηστών. Τα παραπάνω πρακτικά σημαίνουν ότι το Smart Contract θα πρέπει ανά διαστήματα να φορτίζεται (από οποιονδήποτε) με Ethereum ή οι χρήστες (βλ. κατηγορίες χρηστών) να καταβάλουν τα δικά τους έξοδα. |
|||
|
|||
2) Το δεύτερο μέρος αποτελεί μια μερικώς αποκεντρωτική και μη αυτοτελή πλατφόρμα που έρχεται να λειτουργήσει επιπρόσθετα στην πρώτη. Το κομμάτι αυτό απευθύνεται αποκλειστικά σε επικυρωμένα μέλη του ΑΠΘ και συνιστά ένα αμεσοδημοκρατικό σύστημα ψηφοφορίας που θα εγγυάται σε υψηλό βαθμό την εγκυρότητα και την ανωνυμία των διαδικασιών του. Με λίγα λόγια, θα δημιουργούνται θέματα προς ψηφοφορία (στο πρώτο κομμάτι), πάνω στα οποία θα ψηφίζουν όσοι έχουν το δικαίωμα (αυτοί θα ορίζονται με την κατοχή ενός ανάλογου token στο Ethereum). |
|||
|
|||
% TODO: insert diagram |
|||
|
|||
O χρήστης μέσω ενός Frontend (μιας κλασικής ιστοσελίδας ουσιαστικά) θα μπορεί να πιστοποιήσει μέσω login στο it.auth.gr* την ακαδημαϊκή του ταυτότητα. Στη συνέχεια το TDS (Token Distribution Service, ελέγχοντας το admin account των tokens θα παρέχει στο χρήστη δύο tokens. Ένα το οποίο θα του δίνει voting rights (verified user) και ένα που θα κάνει τη πλατφόρμα να του επιστρέφει τα τέλη τα οποία πληρώνουν σε κάθε post τους (trusted user). |
|||
|
|||
|
|||
*Ιδανικά, με τη συνεργασία του ΑΠΘ, το UAS θα αποτελεί υπηρεσία συνεργαζόμενη με την Υποδομή πιστοποίησης και εξουσιοδότησης (βλ. https://it.auth.gr/el/infrastructure/aai). Αυτό σημαίνει ότι οι χρήστες δε θα χρειάζεται να εμπιστευτούν τον UAS με τα it credential τους. |
@ -0,0 +1,9 @@ |
|||
\section{Σύλληψη της ιδέας} \label{section:3-1-idea-conception} |
|||
|
|||
Η σύλληψη της ιδέας για τη δημιουργία της εφαρμογής της παρούσας διπλωματικής εργασίας έχει ως εφαλτήριο την αναγνώριση ενός διδιάστατου προβλήματος. |
|||
|
|||
Η πρώτη διάσταση εστιάζει στον χώρο των μέσων κοινωνικής δικτύωσης. Εκεί παρατηρείται αδιαμφισβήτητη επικράτηση πλατφορμών επικοινωνίας συγκεντρωτικής μορφής (π.χ. Facebook, Twitter, Instagram), ενώ προσπάθειες δημιουργίας αντίστοιχων αποκεντρωτικών εφαρμογών βρίσκονται σε πρώιμα στάδια, τόσο ανάπτυξης, όσο και υιοθέτησης από το ευρύ κοινό. Όπως αναλύθηκε και στην ενότητα \ref{section:1-3-problem-definition}, η τρέχουσα αυτή κατάσταση θέτει αξιοσημείωτα προβλήματα τεχνικής φύσεως (έλλειψη ασφάλειας και διαθεσιμότητας) και, κυρίως, πολιτικής (έλλειψη εμπιστοσύνης, εγγύησης της αυθεντικότητας των δεδομένων και της ελευθερίας του λόγου). |
|||
|
|||
Η δεύτερη διάσταση εστιάζει στον χώρο της ψηφιακής δημοκρατίας (digital democracy). Συγκεκριμένα, παρατηρείται έλλειψη εργαλείων, ικανών να παρέχουν τη δυνατότητα διενέργειας αυθεντικών δημοκρατικών διαδικασιών. Ψηφοφορίες και αυτοδιαχείριση εντός συστημάτων κεντροποιημένης λογικής αδυνατούν, για αρχιτεκτονικούς λόγους, να εξασφαλίσουν τις απαραίτητες θεμελιώδεις ιδιότητες τέτοιων διαδικασιών, δηλαδή της ανωνυμίας και της επαληθευσιμότητας. |
|||
|
|||
Αυτές οι παρατηρήσεις αποτέλεσαν την έμπνευση για τη δημιουργία μίας εφαρμογής, η οποία, μέσω ενός προτεινόμενου συνδυασμού αποκεντρωτικών τεχνολογιών, να ορίσει έναν ψηφιακό χώρο που θα έρθει αντιμέτωπος με το παραπάνω πρόβλημα. Έτσι, κεντρικός στόχος της πιλοτικής εφαρμογής Concordia, είναι να αποτελέσει μία αυτόνομη κοινωνική πλατφόρμα, που θα κατοχυρώνει στους χρήστες της ελευθερία του λόγου και πλήρη κυριότητα επί των δεδομένων τους. Επιπλέον, θα παρέχει τη δυνατότητα διενέργειας αυθεντικών, ανώνυμων ψηφοφοριών, κάτι που θα την καθιστά ένα αξιόπιστο δημοκρατικό βήμα για τη λήψη αποφάσεων εντός των αυτοδιαχειριζόμενων κοινοτήτων της. |
@ -0,0 +1,19 @@ |
|||
\section{Τεχνολογική στοίβα} \label{section:3-2-technology-stack} |
|||
|
|||
Ξεκινώντας τη σχεδίαση της πλατφόρμας, πραγματοποιήθηκε έρευνα για την επιλογή της τεχνολογικής της στοίβας (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 contracts, καθώς τα πλεονεκτήματά τους, όπως αυτά περιγράφηκαν στο κεφάλαιο \ref{chapter:2-theoretical-background}, αρμόζουν απόλυτα με τις ιδιαίτερες απαιτήσεις της εφαρμογής. Συγκεκριμένα, επιλέχθηκε η πλατφόρμα του Ethereum, καθώς αποτελεί τον πρωτοπόρο στο χώρο, διαθέτοντας την ισχυρότερη κοινότητα και την δυνατότητα δημιουργίας πλήρως λειτουργικών εφαρμογών. |
|||
|
|||
\item \textbf{Data tier}: Το τμήμα αυτό είναι υπεύθυνο για την αποθήκευση του κύριου όγκου των δεδομένων (storage). Για την επίτευξη πλήρους αρχιτεκτονικής αποκέντρωσης των δεδομένων επιλέχθηκε το IPFS (βλ. ενότητα \ref{section:2-7-ipfs}), το οποίο διανέμει το περιεχόμενο της εφαρμογής στους peers που συμμετέχουν σε αυτήν, χωρίς να απαιτεί κάποιο κεντρικό σημείο. Έτσι, κάθε χρήστης θα έχει πλήρη κυριότητα επί των δεδομένων του, ενώ, επιπλέον, θα συμμετέχει στην πλατφόρμα διαμοιράζοντας τα δεδομένα άλλων χρηστών. |
|||
\end{enumerate} |
|||
|
|||
Τελικά, με τη διασύνδεση των προαναφερθέντων τεχνολογιών, προκύπτει σχηματικά η ακόλουθη διάταξη: |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\includegraphics[width=.55\textwidth]{assets/figures/chapter-3/3.2.technology.stack} |
|||
\caption{Επιλεγμένη τεχνολογική στοίβα} |
|||
\end{figure} |
@ -1,34 +0,0 @@ |
|||
\section{Κατηγορίες χρηστών} |
|||
|
|||
% Παλιό από Drive |
|||
\subsection{Πρώτο μέρος} |
|||
|
|||
Όπως προειπώθηκε, το πρώτο μέρος της πλατφόρμας θα είναι ανοιχτό σε όλους. Ωστόσο, οι χρήστες του μπορούν να διακριθούν στις εξής δύο κατηγορίες: |
|||
|
|||
\begin{itemize} |
|||
\item Έμπιστα μέλη του δικτύου (trusted users) |
|||
\item Μη έμπιστα μέλη (untrusted users) |
|||
\end{itemize} |
|||
|
|||
Βασική διαφορά των δύο κατηγοριών είναι πως ενώ οι trusted users θα αποζημιώνονται αυτόματα από το (ενν. φορτισμένο) smart contract και άρα θα είναι απαλλαγμένοι από τέλη, οι δεύτεροι θα πρέπει να καταβάλουν μόνοι τους τα τέλη τους (fees) για κάθε ενέργεια (π.χ. posting). |
|||
|
|||
Η εμπιστοσύνη ενός χρήστη (trust) μπορεί να οριστεί ως ένας ακέραιος αριθμός με κάποιο κατώφλι, πάνω από το οποίο ο χρήστης θα θεωρείται trusted. Το trust θα μπορεί να αυξομειώνεται ανά πάσα στιγμή, με τους χρήστες να δίνουν και να παίρνουν βαθμούς trust σε/από άλλους. |
|||
|
|||
Αξίζει να σημειωθεί επίσης ότι επειδή όλες οι συναλλαγές καταγράφονται, είναι δυνατό να υπολογιστεί το συνολικό ποσό του Ethereum που έχει ξοδέψει ένας common user μέχρι να γίνει trusted και έτσι μπορεί σταδιακά να του επιστραφεί μέσω του contract. Αυτό δίνει κίνητρο στους χρήστες να διατηρούν σωστή συμπεριφορά και να συμβάλλουν θετικά στην πλατφόρμα. |
|||
|
|||
\subsection{Δεύτερο μέρος} |
|||
|
|||
Για το δεύτερο μέρος της πλατφόρμας, οι χρήστες του μπορούν να διακριθούν στις εξής κατηγορίες: |
|||
|
|||
\begin{itemize} |
|||
\item Πιστοποιημένα μέλη του Α.Π.Θ. (verified users) |
|||
\item Μη πιστοποιημένα μέλη του Α.Π.Θ. (untrusted users) |
|||
\end{itemize} |
|||
|
|||
Σχετικά με το δικαίωμα ψήφου για αυθεντικές δημοκρατικές αποφάσεις σχετικές με το ΑΠΘ, αυτό θα το έχουν μόνο οι verified χρήστες του δικτύου. Οι verified χρήστες θα μπορούν επιπλέον να αλληλεπιδρούν με την πλατφόρμα εξαρχής χωρίς την καταβολή τελών (θα ξεκινάνε ως trusted), πράγμα που βέβαια δε σημαίνει ότι χάνοντας trust δε θα μπορούν να χάσουν αυτό το προνόμιο. |
|||
|
|||
\subsection{Σύνοψη χρηστών} |
|||
|
|||
Συμπερασματικά προκύπτουν τέσσερις διακριτές κατηγορίες χρηστών με ξεχωριστά δικαιώματα που φαίνονται στο παρακάτω διάγραμμα: |
|||
|
|||
% TODO: insert diagram |
@ -0,0 +1,15 @@ |
|||
\section{Μεθοδολογία σχεδίασης} \label{section:3-3-design-methodology} |
|||
|
|||
Στον χώρο της τεχνολογίας λογισμικού υπάρχουν διάφορες μεθοδολογίες σχεδίασης οι οποίες έχουν μεταξύ τους κοινά στοιχεία. Αυτό καθιστά δύσκολο τον προσδιορισμό μίας μόνο μεθοδολογίας η οποία ακολουθείται πιστά σε κάθε έργο. Συνήθως, οι ομάδες που αναπτύσσουν το λογισμικό ακολουθούν μία μίξη από διάφορα εργαλεία, όπου αυτά κρίνονται βολικά για τους στόχους της ομάδας. % 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) το οποίο αποτελεί σημαντικό βοήθημα στον έγκαιρο εντοπισμό λαθών του κώδικα. |
@ -1 +0,0 @@ |
|||
\section{Σενάρια χρήσης} |
@ -1,54 +0,0 @@ |
|||
\section{Τεχνολογίες} |
|||
|
|||
\subsection{Ethereum} |
|||
|
|||
Ξεκινώντας την σχεδίαση της πλατφόρμας πραγματοποιήσαμε έρευνα ώστε να ανακαλύψουμε τις πιθανές επιλογές για το κομμάτι της διανεμημένης επεξεργασίας (distributed computing). Αναλογιστήκαμε τα προτερήματα και μειονεκτήματα διάφορων επιλογών, συμπεριλαμβανομένων των ... |
|||
|
|||
Επιλέξαμε να προχωρήσουμε με το Ethereum και όχι κάποια άλλη πλατφόρμα επειδή ... |
|||
|
|||
Το Ethereum είναι ... |
|||
Παρέχει Smart Contracts ακολουθώντας το μοντέλο ... |
|||
Proof of work είναι ... |
|||
Ο τρόπος που υπολογίζεται και πληρώνεται η καταναλώμενη επεξεργαστική ισχύς είναι ... |
|||
Αυτά εισάγουν τους εξής περιορισμούς που πρέπει να ληφθούν υπόψιν κατά την υλοποίηση ... |
|||
|
|||
% Παλιό από Drive |
|||
Προχωρώντας την τεχνολογία του blockchain ένα βήμα παραπέρα, ξεκίνησαν να δημιουργούνται προγραμματιστικές πλατφόρμες για την ανάπτυξη αποκεντρωτικών εφαρμογών (Decentralized Applications ή DApps). Η πρώτη και, μέχρι τώρα, πιο δημοφιλής, ισχυρή και λειτουργική πλατφόρμα είναι το Ethereum. |
|||
|
|||
Στο Ethereum υπάρχουν δύο είδη λογαριασμών: οι Externally Owned Accounts και οι Contracts Accounts. Η διαφορά τους είναι ότι ενώ οι πρώτοι ελέγχονται από τους χρήστες, οι δεύτεροι διαθέτουν ένα αμετάβλητο (immutable) κομμάτι κώδικα το οποίο αποτελεί ένα Smart Contract. Όταν μια συναλλαγή σταλεί σε ένα Smart Contract, ο συσχετιζόμενος κώδικας εκτελείται από την “Ethereum Virtual Machine (EVM)” σε κάθε κόμβο (και εν τέλει όλοι έρχονται σε consensus). Φυσικά, για την εκτέλεση των operations στην EVM (όπως και για τα απλά transactions) χρειάζεται να δοθούν κάποια fees στους miners ως ανταμοιβή για την εργασία τους. |
|||
|
|||
|
|||
\subsection{IPFS, OrbitDB} |
|||
|
|||
Όπως η επιλογή του Blockchain, που περιγράφηκε στο προηγούμενο κεφάλαιο (insert reference), ομοίως και η επιλογή του λογισμικού που θα χρησιμοποιηθεί για την κατανεμημένη αποθήκευση δεδομένων ξεκίνησε με μία έρευνα των επιλογών που υπάρχουν. Αναλογιστήκαμε τα προτερήματα και μειονεκτήματα διάφορων επιλογών, συμπεριλαμβανομένων των ... |
|||
|
|||
Επιλέξαμε να προχωρήσουμε με το IPFS και την OrbitDB έναντι άλλων λύσεων επειδή ... |
|||
|
|||
Το IPFS είναι ... |
|||
Παρέχει ... με τον εξής τρόπο ... |
|||
Δωρεάν ... |
|||
Αυτά τα χαρακτηριστικά εισάγουν τους εξής περιορισμούς που πρέπει να ληφθούν υπόψιν κατά την υλοποίηση ... |
|||
|
|||
Η OrbitDB είναι ... και χρησιμοποιεί το IPFS για να καταφέρει τα εξής χαρακτηριστικά ... |
|||
Περιορισμοί πάλι κλπ ... |
|||
|
|||
% Παλιό από Drive |
|||
Ένα από τα προβλήματα που προκύπτουν με την αποκέντρωση εφαρμογών είναι αυτό της εύρεσης των resources που χρειαζόμαστε. Το πρόβλημα έγκειται στο γεγονός ότι δεν υπάρχει ένας server και άρα μία μοναδική διεύθυνση IP από την οποία μπορούμε να πάρουμε το αντικείμενο που ψάχνουμε, διότι όλα είναι διανεμημένα στο δίκτυο. Επιπλέον η αποθήκευση μεγάλου όγκου πληροφοριών στο Ethereum on-chain έχει απαγορευτικά μεγάλο κόστος οπότε απορρίπτεται. |
|||
|
|||
Το πρόβλημα ανάγεται σε αυτό της επικοινωνίας μεταξύ των κόμβων. Αν καθοριστεί ένα πρότυπο επικοινωνίας μεταξύ των κόμβων τότε τα αντικείμενα μπορούν να βρεθούν ζητώντας τα από τους γειτονικούς κόμβους, οι οποίοι με τη σειρά τους θα τα ζητήσουν από τους δικούς τους γείτονες και ου το κάθε εξής, μέχρι το αντικείμενο να βρεθεί και να σταλεί στον κόμβο που αρχικά το ζήτησε. |
|||
|
|||
Το IPFS είναι ένα νέο πρωτόκολλο μεταφοράς υπερκειμένου που βρίσκεται ακόμα υπό ανάπτυξη. Όπως το γνωστό πρωτόκολλο HTTP, για συγκεντρωτικά συστήματα, έτσι και το IPFS, για αποκεντρωτικά συστήματα, καθορίζει το πρότυπο το οποίο θα χρησιμοποιούν τα τερματικά του δικτύου για να επικοινωνούν μεταξύ τους. Χρησιμοποιεί κρυπτογραφικές τεχνικές, όπως αυτές που είδαμε παραπάνω, καθώς και διάφορες άλλες τεχνολογίες για να: |
|||
|
|||
\begin{itemize} |
|||
\item συντονίσει τη παράδοση περιεχομένου |
|||
\item υλοποιήσει στρώμα σύνδεσης μέσω οποιουδήποτε πρωτοκόλλου δικτύου |
|||
\item ορίσει ένα σύστημα ονομάτων τομέων (DNS) |
|||
\item υλοποιήσει στρώμα δρομολόγησης |
|||
\item διαμοιράσει αρχεία με peer-to-peer (P2P) τεχνικές |
|||
\end{itemize} |
|||
|
|||
Έτσι το IPFS ορίζει ένα νέο δίκτυο υπολογιστών που συμπληρώνει τα ήδη υπάρχοντα (www, Tor, .bit) διατηρώντας πλήρως αποκεντρωμένη αρχιτεκτονική και κανένα κεντρικό σημείο αποτυχίας. |
|||
|
|||
Συνοπτικά, δηλαδή, στο IPFS αποθηκεύονται διευθυνσιοδοτημένα βάσει περιεχομένου (content-addressable) αρχεία, τα οποία ανακτώνται βάσει του hash των περιεχομένων τους (αντί για την τοποθεσία τους), ενώ ανακαλύπτονται και διαμοιράζονται μέσω του παρεχόμενου P2P network layer. Αξίζει, ωστόσο, να σημειωθεί πως το layer αυτό δεν εγγυάται από μόνο του το hosting των αρχείων και το διαθέσιμο bandwidth για την ανάκτηση τους, πράγμα που σημαίνει ότι θα πρέπει να γίνει παροχή υποδομής από τους χρήστες ικανής να υποστηρίξει έναν ελάχιστο αριθμό κόμβων αποθήκευσης. |
|||
|
|||
Πρόκειται για συμπληρωματικές τεχνολογίες στις παραπάνω που στόχο έχουν την οργάνωση των αποθηκευμένων πληροφοριών σε μορφή βάσεων δεδομένων. |
@ -0,0 +1,44 @@ |
|||
\section{Κατηγορίες χρηστών} \label{section:3-4-user-categories} |
|||
|
|||
Οι χρήστες (actors) της πλατφόρμας χωρίζονται σε πρωτεύοντες ή ενεργούς και δευτερεύοντες ή παθητικούς. Πρωτεύοντες χρήστες είναι εκείνοι που εκκινούν διεργασίες στο σύστημα. Δευτερεύοντες είναι οι χρήστες με τους οποίους αλληλεπιδρά το σύστημα, αλλά οι ίδιοι δεν εκκινούν διεργασίες σε αυτό. Συνολικά οι χρήστες που συμμετέχουν στο σύστημα είναι οι: |
|||
|
|||
\begin{itemize} |
|||
\item Επισκέπτες |
|||
\item Εγγεγραμμένα μέλη |
|||
\item Συμβόλαια κοινοτήτων |
|||
\end{itemize} |
|||
|
|||
\subsection{Ενεργοί χρήστες} |
|||
|
|||
Οι ενεργοί χρήστες στο σύστημα είναι οι επισκέπτες και τα εγγεγραμμένα μέλη. |
|||
|
|||
Όλοι οι χρήστες στο σύστημα είναι αρχικά επισκέπτες. Οι επισκέπτες έχουν τη δυνατότητα να βλέπουν το περιεχόμενο της κοινότητας, αλλά δε μπορούν να συμμετέχουν δημιουργώντας νέο περιεχόμενο (δημοσιεύοντας νέα θέματα ή μηνύματα). Επίσης, δε μπορούν να συμμετέχουν στις ψηφοφορίες της κοινότητας ή να ψηφίσουν τα μηνύματα. |
|||
|
|||
Όταν ένας επισκέπτης εγγράφεται στο σύστημα, αποκτά έναν μοναδικό, αύξοντα αριθμό χρήστη και αποτελεί πλέον εγγεγραμμένο μέλος της κοινότητας. Τα εγγεγραμμένα μέλη έχουν τα δικαιώματα των επισκεπτών και μπορούν επιπλέον να προσθέσουν περιεχόμενο στην πλατφόρμα μέσω της δημιουργίας νέων θεμάτων, της δημοσίευσης μηνυμάτων και της ψήφισης στις ψηφοφορίες στις οποίες έχουν δικαίωμα. |
|||
|
|||
\subsection{Παθητικοί χρήστες} |
|||
|
|||
Παθητικοί χρήστες τους συστήματος είναι τα συμβόλαια των κοινοτήτων. Τα συμβόλαια αυτά δεν εκκινούν διεργασίες στο σύστημα και δεν αλληλεπιδρούν με αυτό άμεσα. Αποτελούν αυτόνομες εξωτερικές οντότητες, οι οποίες ορίζουν τους χρήστες κοινοτήτων μέσω της διάθεσης αναγνωριστικών token στα μέλη τους. Συγκεκριμένα, μέσω του διαμοιρασμού των token, καθορίζουν ποιοι χρήστες της πλατφόρμας έχουν δικαίωμα ψήφου στις ψηφοφορίες που αφορούν την κοινότητα. |
|||
|
|||
\subsection{Σύνοψη χρηστών} |
|||
|
|||
Συμπερασματικά προκύπτουν δύο διακριτές κατηγορίες ενεργών χρηστών με ξεχωριστά δικαιώματα όπως φαίνεται στο παρακάτω σχήμα: |
|||
|
|||
\begin{threeparttable}[H] |
|||
\begin{center} |
|||
\begin{tabularx}{\textwidth}{p{2.3cm} X X X X X X X X X} |
|||
\toprule |
|||
\multirow{7}{2.3cm}{\textbf{Κατηγορία χρήστη}} &\multicolumn{9}{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] |
|||
\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{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}} & \ \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \ \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \ \textcolor{OliveGreen}{\faIcon{check}} \\ [0.5ex] |
|||
\bottomrule |
|||
\end{tabularx} |
|||
\begin{tablenotes} |
|||
\item[*] \footnotesize{Μόνο στις κοινότητες στις οποίες κατέχει το αντίστοιχο token και σε αυτές οι οποίες δεν έχουν ορισμένο token.} |
|||
\end{tablenotes} |
|||
\end{center} |
|||
\caption{Δικαιώματα χρήσης ανά κατηγορία χρήστη} |
|||
\label{table:3-4-user-category-permissions} |
|||
\end{threeparttable} |
@ -1,38 +0,0 @@ |
|||
\section{Προδιαγραφή μεθόδου υλοποίησης και χρονοπρογραμματισμός} |
|||
|
|||
\subsection{Προδιαγραφή κύκλων} |
|||
|
|||
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται ως εξής: |
|||
|
|||
% TODO: insert diagram |
|||
|
|||
\subsection{Πρώτη φάση} |
|||
|
|||
% Παλιό από Drive |
|||
Στήνεται ένα Ethereum Private Network ως βάση πάνω στην οποία θα δουλέψουμε. Πάνω σε αυτό γράφουμε τα contracts που θα είναι υπεύθυνα για διεκπεραίωση ή μη των posts. |
|||
Στη συνέχεια αναπτύσσεται ο απαραίτητος κώδικας που υλοποιεί το posting χρησιμοποιώντας τις βιβλιοθήκες που δίνονται από το IPFS για την επικοινωνία μεταξύ των κόμβων του δικτύου και αυτές που δίνονται από τη BigChainDB για την αποθήκευση των πληροφοριών με διανεμημένο τρόπο. |
|||
Γίνονται δοκιμές για την εξακρίβωση της σωστής λειτουργίας του αποτελέσματος και διορθώνονται τυχόν λάθη στο κώδικα. |
|||
|
|||
\subsection{Δεύτερη φάση} |
|||
|
|||
% Παλιό από Drive |
|||
Υλοποιείται το δικαίωμα ψήφου και posting χωρίς fees. Αυτό γίνεται μέσω δύο contracts που θα δημιουργούν δύο διαφορετικά tokens (voting token, feeless token) και θα τα αποδίδουν στον εκάστοτε χρήστη που πρέπει να πάρει το δικαίωμα. |
|||
Αναπτύσσεται κώδικας που να υλοποιεί τη διαδικασία ψηφοφορίας. |
|||
Γίνονται δοκιμές για την εξακρίβωση της σωστής λειτουργίας του αποτελέσματος και διορθώνονται τυχόν λάθη στο κώδικα. Σε αυτή τη φάση η απόδοση των tokens θα γίνει χειροκίνητα για το σκοπό της δοκιμής. |
|||
|
|||
\subsection{Τρίτη φάση} |
|||
|
|||
% Παλιό από Drive |
|||
Υλοποιείται ένα σύστημα απόδοσης εμπιστοσύνης (ΣΑΠ). |
|||
Αναπτύσσονται τα contracts που είναι απαραίτητα για τη λειτουργία του ΣΑΠ καθώς και για την αυτόματη απόδοση feeless token στους trusted χρήστες. |
|||
Γίνονται δοκιμές για την εξακρίβωση της σωστής λειτουργίας του αποτελέσματος και διορθώνονται τυχόν λάθη στο κώδικα. |
|||
Εφόσον η εφαρμογή περάσει το στάδιο των δοκιμών είναι έτοιμη για alpha deployment, είναι δηλαδή έτοιμη για χρήση από το κοινό, υπολείπονται όμως χαρακτηριστικά που είναι ιδιαίτερα θεμιτά αλλά όχι απαραίτητα για τη λειτουργία. |
|||
|
|||
\subsection{Τέταρτη φάση} |
|||
|
|||
% Παλιό από Drive |
|||
Αναπτύσσεται ο κώδικας του (μοναδικού) συγκεντρωτικού τμήματος του συστήματος το οποίο ανήκει στο δεύτερο κομμάτι - του UAS: Έτσι αυτοματοποιείται η διαδικασία απόδοσης των token, που στην προηγούμενη φάση έγινε χειροκίνητα. |
|||
Γίνονται δοκιμές για την εξακρίβωση της σωστής λειτουργίας του αποτελέσματος και διορθώνονται τυχόν λάθη στο κώδικα. |
|||
Εφόσον η εφαρμογή περάσει το στάδιο των δοκιμών είναι έτοιμη για ένα beta deployment, ώστε να γίνει πιο ευρύς έλεγχος από μία ομάδα δοκιμών και να παρθεί feedback για την εμπειρία χρήστη. |
|||
|
|||
Για το τελικό deployment θα μπορούσε να τεθεί ως στόχος η κατά το δυνατόν μείωση των τελών για τη λειτουργία της πλατφόρμας, ανεπτυγμένα χαρακτηριστικά επικοινωνίας όπως δόμηση των συζητήσεων σε κατηγορίες, προφίλ χρηστών και άλλα χαρακτηριστικά ευκολίας χρήσης. |
@ -0,0 +1,123 @@ |
|||
\section{Απαιτήσεις λογισμικού} \label{section:3-5-software-requirements} |
|||
|
|||
Στην παρούσα ενότητα περιγράφονται οι βασικές απαιτήσεις λογισμικού ( \textenglish{software requirements}) της εφαρμογής. |
|||
|
|||
Η πρώτη κατηγορία είναι αυτή των Λειτουργικών Απαιτήσεων (ΛΑ), η οποία αναφέρεται στη συμπεριφορά του συστήματος, δηλαδή στον τρόπο που θα αντιδρά και στις εξόδους που θα παράγει ανάλογα με τις εισόδους. |
|||
|
|||
\begin{enumerate}[label=\textbf{<ΛΑ-\arabic*>}, leftmargin=\parindent, align=left, labelwidth=\parindent, labelsep=0pt] |
|||
\sysReqItem |
|||
{\label{srs:functional-srs-sign-up}} |
|||
{Ο χρήστης πρέπει να μπορεί να εγγραφεί στην εφαρμογή με τον Ethereum λογαριασμό του.} |
|||
{Ο χρήστης πρέπει να μπορεί να εγγραφεί στην εφαρμογή, πατώντας το κουμπί "Sign Up" και συμπληρώνοντας τα απαραίτητα πεδία σύμφωνα με τις οδηγίες. Το πεδίο "Username" είναι υποχρεωτικό να συμπληρωθεί με το επιθυμητό username, το οποίο ορίζεται με μοναδικό τρόπο. Σε περίπτωση που ο χρήστης εισάγει μη διαθέσιμο Username, το σύστημα θα πρέπει να μην επιτρέπει στον χρήστη να συνεχίσει και να προβάλει αντίστοιχο μήνυμα λάθους. Επιπλέον, υπάρχουν τα προαιρετικά πεδία "Profile picture URL" και "Location", στα οποία ο χρήστης μπορεί να εισάγει μία εικόνα προφίλ και την τοποθεσία του αντίστοιχα.} |
|||
{5}{Η απαίτηση είναι ύψιστης προτεραιότητας για τους επισκέπτες, καθώς μόνο μέσω της εγγραφής μπορούν να χρησιμοποιήσουν τα υπόλοιπα χαρακτηριστικά της εφαρμογής (όπως φαίνεται στον πίνακα \ref{table:3-4-user-category-permissions}).} |
|||
{5}{Η απαίτηση είναι ύψιστης σημασίας για το σύστημα, επειδή επηρεάζει τη λειτουργικότητά του.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-sign-in}} |
|||
{Ο χρήστης πρέπει να μπορεί συνδέεται στην εφαρμογή, εφόσον είναι εγγεγραμμένος.} |
|||
{Το σύστημα πρέπει να διαπιστώνει αυτόματα εάν το τρέχον Ethereum address έχει λογαριασμό στην εφαρμογή και εάν ναι, να συνδέει να τον χρήστη, ανακτώντας το Username του από το blockchain και προβάλλοντας το στο μενού.} |
|||
{5}{Αυτή η απαίτηση είναι ύψιστης προτεραιότητας για τους χρήστες, καθώς μέσω της σύνδεσης ενεργοποιούνται τα χαρακτηριστικά της δημιουργίας θεμάτων και δημοσίευσης μηνυμάτων.} |
|||
{5}{Η απαίτηση είναι ύψιστης σημασίας για το σύστημα, επειδή επηρεάζει τη λειτουργικότητά του.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-create-user-databases}} |
|||
{Το σύστημα πρέπει να δημιουργεί τις απαραίτητες βάσεις δεδομένων και να τις συγχρονίζει με το δίκτυο.} |
|||
{Το σύστημα πρέπει να δημιουργεί τις απαραίτητες OrbitDB βάσεις δεδομένων, εάν αυτές δεν υπάρχουν ήδη τοπικά. Όταν ο χρήστης ξεκλειδώνει τον Ethereum λογαριασμό του, το σύστημα θα πρέπει να τον προτρέπει να υπογράψει με το ιδιωτικό του κλειδί τη συναλλαγή δημιουργίας της OrbitDB Identity του. Αυτή θα εξασφαλίζει τη γνησιότητα των βάσεών του και των δεδομένων που εκείνες θα περιέχουν. Επιπλέον, τοπικές βάσεις δεδομένων θα πρέπει να συγχρονίζονται με τις βάσεις άλλων IPFS κόμβων και να διατηρούνται ενημερωμένες.} |
|||
{5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για τους χρήστες, καθώς η πλειοψηφία των δεδομένων της εφαρμογής διατηρούνται σε αυτές τις βάσεις.} |
|||
{5}{Η παρούσα απαίτηση είναι ύψιστης σημασίας για το σύστημα, καθώς οι περισσότερες θεμελιώδεις λειτουργίες της εφαρμογής προϋποθέτουν την αποθήκευση δεδομένων σε OrbitDB βάσεις.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-create-topic}} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί θέματα (topics).} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί νέα θέματα. Αυτό το επιτυγχάνει πατώντας το κουμπί "New Topic", συμπληρώνοντας τα υποχρεωτικά πεδία της φόρμας ("Topic subject" και "First post content"), πατώντας το κουμπί "Create Topic" και επιβεβαιώνοντας τη συναλλαγή στο Ethereum.} |
|||
{5}{Αυτή η απαίτηση είναι υψηλής σημασίας καθώς επιτελεί έναν από τους βασικούς στόχους της πλατφόρμας.} |
|||
{5}{Η απαίτηση είναι υψηλής σημασίας για τον ίδιο λόγο.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-browse-community-topics}} |
|||
{Ο χρήστης πρέπει να μπορεί να περιηγείται στα θέματα μίας κοινότητας.} |
|||
{Το σύστημα πρέπει να μπορεί να προβάλλει τα δημιουργημένα θέματα μίας κοινότητας στην αρχική οθόνη της. Ο χρήστης πρέπει να μπορεί να περιηγείται σε αυτά πατώντας πάνω τους και, έπειτα, χρησιμοποιώντας τα βέλη πλοήγησης, να περιηγηθεί στο ιστορικό των μηνυμάτων του θέματος.} |
|||
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας, αφού επιτρέπει στους επισκέπτες να έχουν πρόσβαση στο δημοσιευμένο υλικό της πλατφόρμας.} |
|||
{5}{Πρόκετια για απαίτηση υψηλής σημασίας, επειδή αποτελεί βασικό χαρακτηριστικό για τη χρηστικότητα της πλατφόρμας.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-create-post}} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί μηνύματα (posts).} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί μηνύματα στο θέμα που επιθυμεί. Αυτό επιτυγχάνεται συμπληρώνοντας το πεδίο νέου μηνύματος στην οθόνη του θέματος, πατώντας το κουμπί "Post" και επιβεβαιώνοντας τη συναλλαγή στο Ethereum.} |
|||
{5}{Αυτή η απαίτηση είναι ύψιστης σημασίας για τους χρήστες, επειδή αποτελεί ένα από τα βασικότερα χαρακτηριστικά της πλατφόρμας.} |
|||
{5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για το σύστημα, καθώς αποτελεί θεμελιώδες κομμάτι για την επίτευξη του βασικότερου στόχου της, δηλαδή της δημιουργίας διαλόγου.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-modify-post}} |
|||
{Ο χρήστης πρέπει να μπορεί να τροποποιεί τα μηνύματά του.} |
|||
{Ο χρήστης πρέπει να μπορεί να τροποποιεί τα μηνύματά του. Αυτό το επιτυγχάνει επιλέγοντας το κουμπί επεξεργασίας στο εκάστοτε μήνυμα, πραγματοποιώντας τις επιθυμητές τροποποιήσεις και πατώντας το κουμπί επιβεβαίωσης. Στη συνέχεια, το σύστημα τροποποιεί το περιεχόμενο του μηνύματος στη βάση δεδομένων του χρήστη. Σε περίπτωση που ο χρήστης αλλάξει γνώμη κατά τη διάρκεια της διαδικασίας της επεξεργασίας, μπορεί να πατήσει το κουμπί ακύρωσης και να αναιρέσει τις αλλαγές που πραγματοποίησε.} |
|||
{4}{Η απαίτηση αυτή αποτελεί σημαντικό χαρακτηριστικό, καθώς παρέχει στους χρήστες άμεσο έλεγχο επί των δεδομένων τους.} |
|||
{3}{Αυτή η απαίτηση είναι μέτριας σημαντικότητας για το σύστημα, επειδή αυτό θα μπορούσε να είναι λειτουργικό χωρίς το χαρακτηριστικό της επεξεργασίας μηνυμάτων.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-vote-posts}} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να ψηφίζει σε μηνύματα άλλων χρηστών.} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να υπερψηφίζει ή να καταψηφίζει μηνύματα άλλων χρηστών. Αυτό το επιτυγχάνει πατώντας τα παρακείμενα κουμπιά "+" ή "-" αντίστοιχα και επιβεβαιώνοντας τη συναλλαγή στο Ethereum (οι ψήφοι αποθηκεύονται εκεί). Η διαδικασία ισχύει και για την τροποποίηση ή την αφαίρεση μίας ψήφου από τον χρήστη.} |
|||
{3}{Η παρούσα απαίτηση είναι μέτριας σημασίας για τους χρήστες, καθώς αποτελεί ένα χρήσιμο αλλά όχι απαραίτητο χαρακτηριστικό.} |
|||
{2}{Η απαίτηση είναι χαμηλής σημασίας για τη λειτουργικότητα του συστήματος. Ωστόσο, τα δημιουργημένα δεδομένα μπορεί να είναι χρήσιμα σε μελλοντική επέκταση της εφαρμογής (π.χ. για τον υπολογισμό της εμπιστοσύνης των χρηστών).} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-create-polls}} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί ψηφοφορίες (polls).} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί ψηφοφορίες στις κοινότητες που του το επιτρέπουν. Αυτό το επιτυγχάνει πατώντας "Add Poll" στην οθόνη δημιουργία θέματος και συμπληρώνοντας τα απαραίτητα πεδία.} |
|||
{5}{Η απαίτηση είναι ύψιστης σημασίας για τους χρήστες, καθώς οι δημοκρατικές διαδικασίες αποτελούν μία από τις κύριες χρήσεις της πλατφόρμας.} |
|||
{5}{Η απαίτηση είναι ύψιστης σημασίας για το σύστημα, επειδή αποτελεί βασική προδιαγραφή του.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-vote-polls}} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να ψηφίζει σε ψηφοφορίες.} |
|||
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να ψηφίζει σε ψηφοφορίες, σύμφωνα με τους εκάστοτε κανόνες της. Σε κοινότητες που το απαιτούν, ο χρήστης θα πρέπει να διαθέτει το αντίστοιχο voting token για να έχει το δικαίωμα ψήφου.} |
|||
{5}{Η απαίτηση είναι ύψιστης σημασίας για τους χρήστες, καθώς οι δημοκρατικές διαδικασίες αποτελούν μία από τις κύριες χρήσεις της πλατφόρμας.} |
|||
{5}{Η απαίτηση είναι ύψιστης σημασίας για το σύστημα, επειδή αποτελεί βασική προδιαγραφή του.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-delete-local-data}} |
|||
{Ο χρήστης πρέπει να μπορεί να διαγράφει τα τοπικά δεδομένα.} |
|||
{Ο χρήστης πρέπει να μπορεί να διαγράφει τα τοπικά δεδομένα. Αυτό το επιτυγχάνει πατώντας στο κουμπί "Clear databases" του μενού και επιβεβαιώνοντας τη διαγραφή μέσω ενός pop-up διαλόγου.} |
|||
{2}{Η απαίτηση αυτή είναι χαμηλής σημασία για τους χρήστες, διότι αποτελεί απλά μία διευκόλυνση για τη διαγραφή των δεδομένων που έχουν αποθηκεύσει τοπικά.} |
|||
{2}{Η απαίτηση αυτή είναι χαμηλής σημασίας για το σύστημα.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-create-communities}} |
|||
{Ο χρήστης πρέπει να μπορεί να δημιουργεί κοινότητες.} |
|||
{Ο χρήστης πρέπει να μπορεί να δημιουργεί κοινότητες, πατώντας το κουμπί "Create community" και συμπληρώνοντας τα απαραίτητα πεδία.} |
|||
{4}{Η απαίτηση είναι μεγάλης σημασίας για τους χρήστες, καθώς παρέχει την ευελιξία της δημιουργίας κοινοτήτων.} |
|||
{4}{Πρόκειται για απαίτηση μεγάλης σημασίας για την πλατφόρμα, επειδή έτσι γενικεύει τη χρήση της σε περισσότερες κοινότητες, προσελκύοντας μεγαλύτερο αριθμό χρηστών.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:functional-srs-assign-community-contract}} |
|||
{Κατά τη δημιουργία κοινότητας, ο χρήστης πρέπει να έχει τη δυνατότητα να ορίσει ένα contract που θα παρέχει προσαρμοσμένα tokens για αυτήν.} |
|||
{Κατά τη δημιουργία κοινότητας, ο χρήστης πρέπει να έχει τη δυνατότητα να ορίσει ένα contract που θα παρέχει προσαρμοσμένα tokens για αυτήν. Τα tokens αυτά θα διαμοιράζονται με τον τρόπο που επιθυμεί η κοινότητα και θα είναι εκείνα τα οποία θα καθορίζουν τους έγκυρους ψηφοφόρους της.} |
|||
{4}{Αυτή η απαίτηση είναι μεγάλης σημασίας, καθώς παρέχει στις κοινότητες τη δυνατότητα διενέργειας επιβεβαιώσιμων ανώνυμων ψηφοφοριών.} |
|||
{4}{Η απαίτηση είναι μεγάλης σημασίας για το σύστημα, διότι παρέχει στις κοινότητες την απαιτούμενη αυτονομία στον ορισμό των δημοκρατικών διαδικασιών τους.} |
|||
\end{enumerate} |
|||
|
|||
Η δεύτερη κατηγορία είναι αυτή των Μη Λειτουργικών Απαιτήσεων (ΜΛΑ). Περιλαμβάνει απαιτήσεις αρχιτεκτονικής σημασίας, οι οποίες καθορίζουν κριτήρια ή περιορισμούς του τρόπου λειτουργίας του συστήματος και σχετίζονται με χαρακτηριστικά όπως η αποδοτικότητα, η αξιοπιστία και η ευχρηστία του. |
|||
|
|||
\begin{enumerate}[label=\textbf{<ΜΛΑ-\arabic*>}, leftmargin=\parindent, align=left, labelwidth=\parindent, labelsep=0pt] |
|||
\sysReqItem |
|||
{\label{srs:non-functional-srs-maximum-decentraliztion}} |
|||
{Η πλατφόρμα πρέπει να είναι κατά το δυνατόν αρχιτεκτονικά αποκεντρωμένη.} |
|||
{Οι τεχνολογίες στις οποίες βασίζεται η πλατφόρμα πρέπει ιδανικά να μη δημιουργούν κεντρικά σημεία. Επιπλέον, ο κώδικας και η δημόσια διάθεση του πρέπει να γίνονται με αποκεντρωμένο τρόπο.} |
|||
{5}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί απαίτηση ύψιστης προτεραιότητας για τον χρήστη, καθώς διασφαλίζει την πολιτική αποκέντρωση και, έτσι, τους κύριους στόχους που έχουν οριστεί.} |
|||
{5}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί, απαίτηση ύψιστης σημασίας για το σύστημα, καθώς καθιστά το ίδιο ασφαλές σε επιθέσεις και τα δεδομένα μόνιμα διαθέσιμα στους χρήστες.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:non-functional-srs-minimize-fees}} |
|||
{Τα fees για τη χρήση του Ethereum blockchain πρέπει να ελαχιστοποιούνται.} |
|||
{Τα τέλη συναλλαγών που πρέπει να καταβάλλονται για τη χρήση του Ethereum blockchain εξαρτώνται άμεσα τόσο από τον όγκο των δεδομένων προς αποθήκευση, όσο και από τους κύκλους επεξεργασίας των smart contracts της εφαρμογής. Ως προς τα δεδομένα, οι προγραμματιστές θα πρέπει να μεριμνούν ώστε ο κύριος όγκος τους να αποθηκεύεται επί του IPFS, ενώ επί του blockchain να αποθηκεύονται μόνο όσα πραγματικά χρειάζονται. Ως προς την απαιτούμενη επεξεργαστική ισχύ, πρέπει να βελτιστοποιείται ο κώδικας των smart contracts, έτσι ώστε οι διάφορες λειτουργίες τους να εκτελούνται με τους λιγότερους δυνατούς επεξεργαστικούς κύκλους.} |
|||
{4}{Η απαίτηση αυτή είναι μεγάλης σημασίας για τους χρήστες καθώς ναι μεν δεν είναι απαραίτητη για τη χρήση της αλλά είναι ιδιαίτερα σημαντική για την ένταξη χρηστών με χαμηλότερες οικονομικές δυνατότητες.} |
|||
{5}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα διότι αποτελεί σημαντικό παράγοντα που επιδρά στην προσέλκυση και τη διατήρηση ενεργών χρηστών.} |
|||
|
|||
\sysReqItem |
|||
{\label{srs:non-functional-srs-upgrade-contracts}} |
|||
{Τα contracts της εφαρμογής πρέπει να είναι αναβαθμίσιμα.} |
|||
{Τα contracts της εφαρμογής πρέπει μπορούν να αναβαθμιστούν, έτσι ώστε να μπορούν να προστίθενται λειτουργίες και να διορθώνονται σφάλματα. Η αναβαθμισιμότητά τους θα πρέπει να επιτυγχάνεται με μεθόδους που να μην υπονομεύουν τη λειτουργικότητα των προηγούμενων εκδόσεων.} |
|||
{2}{Η απαίτηση αυτή είναι χαμηλής σημασίας για τους χρήστες, καθώς αφορά την ανάπτυξη και όχι τη χρήση της.} |
|||
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας για το σύστημα, επειδή προσφέρει τη δυνατότητα αποσφαλμάτωσης του, καθώς και την υλοποίηση νέων χαρακτηριστικών.} |
|||
\end{enumerate} |
@ -1 +0,0 @@ |
|||
\section{Αρχιτεκτονική} |
@ -0,0 +1,16 @@ |
|||
\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} |
|||
\input{chapters/3.application-design/3.6.use-cases/3.6.3.use-case-create-topic} |
|||
\input{chapters/3.application-design/3.6.use-cases/3.6.4.use-case-fetch-topic} |
|||
\input{chapters/3.application-design/3.6.use-cases/3.6.5.use-case-create-post} |
|||
\input{chapters/3.application-design/3.6.use-cases/3.6.6.use-case-modify-post} |
|||
\input{chapters/3.application-design/3.6.use-cases/3.6.7.use-case-vote-in-poll} |
|||
\input{chapters/3.application-design/3.6.use-cases/3.6.8.use-case-vote-post} |
|||
\input{chapters/3.application-design/3.6.use-cases/3.6.9.delete-local-data} |
|||
\input{chapters/3.application-design/3.6.use-cases/3.6.10.use-case-create-community} |
@ -0,0 +1,78 @@ |
|||
% ===== ===== |
|||
% Use case 1 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 1: Εγγραφή χρήστη} \label{subsection:3-6-use-case-signup} |
|||
|
|||
Το σενάριο χρήσης 1, <ΣΧ-1>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την εγγραφή ενός χρήστη στο σύστημα. Στους πίνακες \ref{table:3-6-use-case-sign-up} και \ref{table:3-6-use-case-sign-up-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-1> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-sign-up-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Εγγράφομαι στο σύστημα} |
|||
{Στόχος του σεναρίου χρήσης είναι ο επισκέπτης να μπορεί να εγγραφεί στο σύστημα ως χρήστης.} |
|||
{\ref{srs:functional-srs-sign-up}, \ref{srs:functional-srs-create-user-databases}} |
|||
{\ref{srs:non-functional-srs-minimize-fees}} |
|||
{Ο επισκέπτης πατάει το κουμπί εγγραφή.} |
|||
{Ο επισκέπτης πρέπει να έχει ανοίξει την σελίδα της εφαρμογής.} |
|||
{Σενάριο χρήσης 1, εγγραφή χρήστη στο σύστημα.} |
|||
{\label{table:3-6-use-case-sign-up}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί εγγραφή. & Το σύστημα εμφανίζει την φόρμα "Εγγραφή Χρήστη". \\ [0.5ex] |
|||
\midrule |
|||
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί "Υποβολή". & Το σύστημα εισάγει νέο χρήστη στο blockchain. \\ [0.5ex] |
|||
\midrule |
|||
3 & - & Το σύστημα δημιουργεί τις προσωπικές βάσεις βάσεις δεδομένων OrbitDb του χρήστη. \\ [0.5ex] |
|||
\midrule |
|||
4 & - & Το σύστημα εμφανίζει την φόρμα "Πληροφορίες Χρήστη". \\ [0.5ex] |
|||
\midrule |
|||
5 & Ο χρήστης συμπληρώνει τις προσωπικές του πληροφορίες και πατάει το κουμπί "Υποβολή". & Το σύστημα εισάγει τις πληροφορίες χρήστη στην προσωπική του βάση OrbitDb. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα μεταβαίνει στην αρχική σελίδα της εφαρμογής.} |
|||
{Σενάριο χρήσης 1 - Βασική ροή} |
|||
{\label{table:3-6-use-case-sign-up-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-sign-up-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 1 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-sign-up-base-flow-sequence-diagram} |
|||
\end{figure} |
|||
|
|||
% ===== Alternate flows ===== |
|||
|
|||
Το <ΣΧ-1> περιέχει επίσης τρεις εναλλακτικές ροές που μπορεί να προκύψουν βάσει των επιλογών του χρήστη και οι οποίες περιγράφονται στους πίνακες \ref{table:3-6-use-case-sign-up-alternate-flow-1}, \ref{table:3-6-use-case-sign-up-alternate-flow-2} και \ref{table:3-6-use-case-sign-up-alternate-flow-3}. |
|||
|
|||
\useCaseAlternateFlowTable |
|||
{1} |
|||
{Τα στοιχεία χρήστη είναι λανθασμένα.} |
|||
{Εφόσον ο χρήστης στη γραμμή 2 δεν συμπληρώσει το πεδίο ονόματος χρήστη ή συμπληρώσει ένα όνομα χρήστη το οποίο είναι ήδη σε χρήση στο σύστημα, το σύστημα πρέπει να επιστρέψει σχετικό μήνυμα σφάλματος.} |
|||
{ |
|||
1 & - & Το σύστημα εμφανίζει μήνυμα σφάλματος. |
|||
} |
|||
{Το σύστημα επιστρέφει στη γραμμή 1 της βασικής ροής.} |
|||
{Σενάριο χρήσης 1 - Εναλλακτική ροή 1} |
|||
{\label{table:3-6-use-case-sign-up-alternate-flow-1}} |
|||
|
|||
\useCaseAlternateFlowTable |
|||
{2} |
|||
{Ο χρήστης πατάει το κουμπί "Άκυρο".} |
|||
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει "Άκυρο" το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής.} |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί "Άκυρο" & Το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής. |
|||
} |
|||
{Το σενάριο χρήσης τερματίζεται.} |
|||
{Σενάριο χρήσης 1 - Εναλλακτική ροή 2} |
|||
{\label{table:3-6-use-case-sign-up-alternate-flow-2}} |
|||
|
|||
\useCaseAlternateFlowTable |
|||
{3} |
|||
{Ο χρήστης πατάει το κουμπί "Παράληψη".} |
|||
{Εφόσον ο χρήστης στη γραμμή 5 της Βασικής Ροής επιλέξει "Παράληψη" το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής.} |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί "Παράληψη" & Το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής. |
|||
} |
|||
{Το σενάριο χρήσης τερματίζεται.} |
|||
{Σενάριο χρήσης 1 - Εναλλακτική ροή 3} |
|||
{\label{table:3-6-use-case-sign-up-alternate-flow-3}} |
@ -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,35 @@ |
|||
% ===== ===== |
|||
% Use case 1 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 2: Σύνδεση χρήστη} \label{subsection:3-6-use-case-signin} |
|||
|
|||
Το σενάριο χρήσης 2, <ΣΧ-2>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την σύνδεση ενός χρήστη στο σύστημα. Στους πίνακες \ref{table:3-6-use-case-sign-in} και \ref{table:3-6-use-case-sign-in-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-2> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-sign-in-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Συνδέομαι στο σύστημα} |
|||
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να συνδέεται αυτόματα στο σύστημα.} |
|||
{\ref{srs:functional-srs-sign-in}} |
|||
{-} |
|||
{-} |
|||
{Ο χρήστης πρέπει να έχει ανοίξει την σελίδα της εφαρμογής.} |
|||
{Σενάριο χρήσης 2, σύνδεση χρήστη στο σύστημα.} |
|||
{\label{table:3-6-use-case-sign-in}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & - & Το σύστημα ανακτά τις πληροφορίες του χρήστη από το blockchain. \\ [0.5ex] |
|||
\midrule |
|||
2 & - & Το σύστημα δημιουργεί τις προσωπικές βάσεις βάσεις δεδομένων OrbitDb του χρήστη. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα παραμένει στην αρχική σελίδα της εφαρμογής.} |
|||
{Σενάριο χρήσης 2 - Βασική ροή} |
|||
{\label{table:3-6-use-case-sign-in-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-sign-in-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 2 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-sign-in-base-flow-sequence-diagram} |
|||
\end{figure} |
@ -0,0 +1,74 @@ |
|||
% ===== ===== |
|||
% Use case 3 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 3: Δημιουργία νέου θέματος} \label{subsection:3-6-use-case-create-topic} |
|||
|
|||
Το σενάριο χρήσης 3, <ΣΧ-3>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την δημιουργία ενός θέματος. Στους πίνακες \ref{table:3-6-use-case-create-topic} και \ref{table:3-6-use-case-create-topic-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-3> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-create-topic-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Δημιουργώ νέο θέμα} |
|||
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να δημιουργήσει νέο θέμα.} |
|||
{\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}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί δημιουργίας νέου θέματος. & Το σύστημα εμφανίζει την φόρμα "Δημιουργία Θέματος". \\ [0.5ex] |
|||
\midrule |
|||
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί "Υποβολή". & Το σύστημα εισάγει νέο θέμα στο blockchain. \\ [0.5ex] |
|||
\midrule |
|||
3 & - & Το σύστημα εισάγει τις πληροφορίες του θέματος στην προσωπική βάση OrbitDb του χρήστη. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα μεταβαίνει στην σελίδα του νέου θέματος.} |
|||
{Σενάριο χρήσης 3 - Βασική ροή} |
|||
{\label{table:3-6-use-case-create-topic-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-create-topic-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 3 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-create-topic-base-flow-sequence-diagram} |
|||
\end{figure} |
|||
|
|||
% ===== 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} όπου παρουσιάζεται το διάγραμμα ροής της. |
|||
|
|||
\useCaseAlternateFlowTable |
|||
{1} |
|||
{Ο χρήστης δημιουργεί ψηφοφορία.} |
|||
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει "Προσθήκη Ψηφοφορίας" το σύστημα ανανεώνει την σελίδα προσθέτοντας τα επιπλέον πεδία της φόρμας "Δημιουργία Ψηφοφορίας".} |
|||
{ |
|||
1 & Ο χρήστης, αφού συμπληρώσει τη φόρμα "Δημιουργία Θέματος", πατάει το κουμπί "Προσθήκη ψηφοφορίας" & Το σύστημα ανανεώνει τη σελίδα με τα πεδία της φόρμας "Δημιουργία Ψηφοφορίας". \\ [0.5ex] |
|||
\midrule |
|||
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί "Υποβολή". & Το σύστημα εισάγει το νέο θέμα καθώς και τη νέα ψηφοφορία στο blockchain. \\ [0.5ex] |
|||
\midrule |
|||
3 & - & Το σύστημα εισάγει τις πληροφορίες του θέματος και της ψηφοφορίας στις προσωπικές βάσεις OrbitDb του χρήστη. |
|||
} |
|||
{Το σύστημα μεταβαίνει στην σελίδα του νέου θέματος.} |
|||
{Σενάριο χρήσης 3 - Εναλλακτική ροή 1} |
|||
{\label{table:3-6-use-case-create-topic-alternate-flow-1}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-create-topic-alternate-flow-1-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 3 - Διάγραμμα εναλλακτικής ροής 1} |
|||
\label{figure:3-6-use-case-create-topic-alternate-flow-1-sequence-diagram} |
|||
\end{figure} |
|||
|
|||
\useCaseAlternateFlowTable |
|||
{2} |
|||
{Ο χρήστης πατάει το κουμπί "Άκυρο".} |
|||
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής ή στη γραμμή 2 της Εναλλακτικής Ροής 1 επιλέξει "Άκυρο" το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής.} |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί "Άκυρο" & Το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής. |
|||
} |
|||
{Το σενάριο χρήσης τερματίζεται.} |
|||
{Σενάριο χρήσης 3 - Εναλλακτική ροή 2} |
|||
{\label{table:3-6-use-case-create-topic-alternate-flow-2}} |
@ -0,0 +1,60 @@ |
|||
% ===== ===== |
|||
% Use case 4 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 4: Ανάκτηση θέματος} \label{subsection:3-6-use-case-fetch-topic} |
|||
|
|||
Το σενάριο χρήσης 4, <ΣΧ-4>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την ανάκτηση ενός θέματος. Στους πίνακες \ref{table:3-6-use-case-fetch-topic} και \ref{table:3-6-use-case-fetch-topic-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-4> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-fetch-topic-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Ανακτώ ένα θέμα} |
|||
{Στόχος του σεναρίου χρήσης είναι ο επισκέπτης ή ο χρήστης να μπορεί να ανακτήσει ένα θέμα.} |
|||
{\ref{srs:functional-srs-browse-community-topics}} |
|||
{-} |
|||
{Ο επισκέπτης ή χρήστης πατάει σε ένα από τα θέματα.} |
|||
{Ο επισκέπτης ή χρήστης πρέπει να έχει ανοίξει την σελίδα της εφαρμογής.} |
|||
{Σενάριο χρήσης 4, ανάκτηση θέματος.} |
|||
{\label{table:3-6-use-case-fetch-topic}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & Ο χρήστης πατάει σε ένα από τα θέματα της λίστας. & Το σύστημα ανακτά τις πληροφορίες του θέματος από το blockchain. \\ [0.5ex] |
|||
\midrule |
|||
2 & - & Το σύστημα ανακτά τα μηνύματα του θέματος αντιγράφοντας τις προσωπικές βάσεις OrbitDb των συγγραφέων. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα μεταβαίνει στην σελίδα του θέματος.} |
|||
{Σενάριο χρήσης 4 - Βασική ροή} |
|||
{\label{table:3-6-use-case-fetch-topic-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-fetch-topic-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 4 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-fetch-topic-base-flow-sequence-diagram} |
|||
\end{figure} |
|||
|
|||
% ===== Alternate flow ===== |
|||
|
|||
Το <ΣΧ-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} |
|||
{Το θέμα περιέχει ψηφοφορία.} |
|||
{Εφόσον το θέμα που ανακτήθηκε στη γραμμή 1 της Βασικής Ροής περιέχει ψηφοφορία ανακτώνται οι πληροφορίες της.} |
|||
{ |
|||
1 & - & Το σύστημα ανακτά τα μηνύματα του θέματος αντιγράφοντας τις προσωπικές βάσεις OrbitDb των συγγραφέων. \\ [0.5ex] |
|||
2 & - & Το σύστημα ανακτά την ψηφοφορία από το blockchain. \\ [0.5ex] |
|||
3 & - & Το σύστημα ανακτά τις πληροφορίες της ψηφοφορίας αντιγράφοντας την προσωπική βάση OrbitDb του συγγραφέα. \\ [0.5ex] |
|||
4 & - & Το σύστημα επιβεβαιώνει τις πληροφορίες της ψηφοφορίας με βάση το hash που έχει ανακτηθεί από το blockchain. \\ [0.5ex] |
|||
} |
|||
{Το σενάριο χρήσης τερματίζεται.} |
|||
{Σενάριο χρήσης 4 - Εναλλακτική ροή 1} |
|||
{\label{table:3-6-use-case-fetch-topic-alternate-flow-1}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 4 - Διάγραμμα εναλλακτικής ροής 1} |
|||
\label{figure:3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram} |
|||
\end{figure} |
@ -0,0 +1,52 @@ |
|||
% ===== ===== |
|||
% Use case 5 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 5: Δημιουργία νέου μηνύματος} \label{subsection:3-6-use-case-create-post} |
|||
|
|||
Το σενάριο χρήσης 5, <ΣΧ-5>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την δημιουργία ενός μηνύματος. Στους πίνακες \ref{table:3-6-use-case-create-post} και \ref{table:3-6-use-case-create-post-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-5> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-create-post-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Δημιουργώ νέο μήνυμα} |
|||
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να δημιουργήσει νέο μήνυμα.} |
|||
{\ref{srs:functional-srs-create-post}} |
|||
{\ref{srs:non-functional-srs-minimize-fees}} |
|||
{Ο χρήστης πατάει το κουμπί δημιουργίας νέου μηνύματος.} |
|||
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην σελίδα ενός θέματος.} |
|||
{Σενάριο χρήσης 5, δημιουργία νέου μηνύματος.} |
|||
{\label{table:3-6-use-case-create-post}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί δημιουργίας νέου μηνύματος. & Το σύστημα εμφανίζει την φόρμα "Δημιουργία Μηνύματος". \\ [0.5ex] |
|||
\midrule |
|||
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί "Υποβολή". & Το σύστημα εισάγει νέο μήνυμα στο blockchain. \\ [0.5ex] |
|||
\midrule |
|||
3 & - & Το σύστημα εισάγει τις πληροφορίες του μηνύματος στην προσωπική βάση OrbitDb του χρήστη. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα παραμένει στη σελίδα του θέματος εμφανίζοντας το νέο μήνυμα.} |
|||
{Σενάριο χρήσης 5 - Βασική ροή} |
|||
{\label{table:3-6-use-case-create-post-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-create-post-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 5 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-create-post-base-flow-sequence-diagram} |
|||
\end{figure} |
|||
|
|||
% ===== Alternate flow ===== |
|||
|
|||
Το <ΣΧ-5> περιέχει επίσης μία εναλλακτική ροή που μπορεί να προκύψει βάσει των επιλογών του χρήστη και η οποία περιγράφεται στον πίνακα \ref{table:3-6-use-case-create-post-alternate-flow-1}. |
|||
|
|||
\useCaseAlternateFlowTable |
|||
{1} |
|||
{Ο χρήστης πατάει το κουμπί "Άκυρο".} |
|||
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει "Άκυρο" το σύστημα επιστρέφει στη σελίδα του θέματος.} |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί "Άκυρο" & Το σύστημα επιστρέφει στη σελίδα του θέματος. |
|||
} |
|||
{Το σενάριο χρήσης τερματίζεται.} |
|||
{Σενάριο χρήσης 5 - Εναλλακτική ροή 1} |
|||
{\label{table:3-6-use-case-create-post-alternate-flow-1}} |
@ -0,0 +1,50 @@ |
|||
% ===== ===== |
|||
% Use case 6 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 6: Τροποποίηση μηνύματος} \label{subsection:3-6-use-case-modify-post} |
|||
|
|||
Το σενάριο χρήσης 6, <ΣΧ-6>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για τη τροποποίηση ενός μηνύματος. Στους πίνακες \ref{table:3-6-use-case-modify-post} και \ref{table:3-6-use-case-modify-post-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-6> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-modify-post-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Τροποποιώ ένα μήνυμα} |
|||
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να τροποποιήσει τα μηνύματά του.} |
|||
{\ref{srs:functional-srs-modify-post}} |
|||
{-} |
|||
{Ο χρήστης πατάει το κουμπί τροποποίησης του μηνύματος.} |
|||
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην σελίδα του θέματος που περιέχει το μήνυμά του.} |
|||
{Σενάριο χρήσης 6, τροποποίηση μηνύματος.} |
|||
{\label{table:3-6-use-case-modify-post}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί τροποποίησης του μηνύματος. & Το σύστημα εμφανίζει την φόρμα "Τροποποίηση Μηνύματος". \\ [0.5ex] |
|||
\midrule |
|||
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί "Υποβολή". & Το σύστημα τροποποιεί τις πληροφορίες του μηνύματος στην προσωπική βάση OrbitDb του χρήστη. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα παραμένει στη σελίδα του θέματος εμφανίζοντας το τροποποιημένο μήνυμα.} |
|||
{Σενάριο χρήσης 6 - Βασική ροή} |
|||
{\label{table:3-6-use-case-modify-post-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-modify-post-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 6 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-modify-post-base-flow-sequence-diagram} |
|||
\end{figure} |
|||
|
|||
% ===== Alternate flow ===== |
|||
|
|||
Το <ΣΧ-6> περιέχει επίσης μία εναλλακτική ροή που μπορεί να προκύψει βάσει των επιλογών του χρήστη και η οποία περιγράφεται στον πίνακα \ref{table:3-6-use-case-modify-post-alternate-flow-1}. |
|||
|
|||
\useCaseAlternateFlowTable |
|||
{1} |
|||
{Ο χρήστης πατάει το κουμπί "Άκυρο".} |
|||
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει "Άκυρο" το σύστημα επιστρέφει στη σελίδα του θέματος.} |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί "Άκυρο" & Το σύστημα επιστρέφει στη σελίδα του θέματος. |
|||
} |
|||
{Το σενάριο χρήσης τερματίζεται.} |
|||
{Σενάριο χρήσης 6 - Εναλλακτική ροή 1} |
|||
{\label{table:3-6-use-case-modify-post-alternate-flow-1}} |
@ -0,0 +1,33 @@ |
|||
% ===== ===== |
|||
% Use case 7 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 7: Ψήφιση σε ψηφοφορία} \label{subsection:3-6-use-case-vote-in-poll} |
|||
|
|||
Το σενάριο χρήσης 7, <ΣΧ-7>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την ψήφιση σε μία ψηφοφορία. Στους πίνακες \ref{table:3-6-use-case-vote-in-poll} και \ref{table:3-6-use-case-vote-in-poll-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-7> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-vote-in-poll-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Ψηφίζω σε ψηφοφορία} |
|||
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να ψηφίσει σε μία ψηφοφορία.} |
|||
{\ref{srs:functional-srs-vote-polls}} |
|||
{\ref{srs:non-functional-srs-minimize-fees}} |
|||
{Ο χρήστης πατάει το κουμπί ψηφοφορίας.} |
|||
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην σελίδα ενός θέματος το οποίο περιλαμβάνει ψηφοφορία.} |
|||
{Σενάριο χρήσης 7, ψήφιση σε ψηφοφορία.} |
|||
{\label{table:3-6-use-case-vote-in-poll}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & Ο χρήστης πατάει το κουμπί της επιλογής που επιθυμεί να ψηφίσει και πατάει το κουμπί "Υποβολή". & Το σύστημα εισάγει νέα ψήφο στο blockchain. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα ανανεώνει τις πληροφορίες της ψηφοφορίας.} |
|||
{Σενάριο χρήσης 7 - Βασική ροή} |
|||
{\label{table:3-6-use-case-vote-in-poll-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-vote-in-poll-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 7 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-vote-in-poll-base-flow-sequence-diagram} |
|||
\end{figure} |
@ -0,0 +1,33 @@ |
|||
% ===== ===== |
|||
% Use case 8 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 8: Ψήφιση μηνύματος} \label{subsection:3-6-use-case-vote-post} |
|||
|
|||
Το σενάριο χρήσης 8, <ΣΧ-8>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την ψήφιση σε ένα μήνυμα. Στους πίνακες \ref{table:3-6-use-case-vote-post} και \ref{table:3-6-use-case-vote-post-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-8> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-vote-post-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Ψηφίζω σε μήνυμα} |
|||
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να υπερψηφίσει ή καταψηφίσει ένα μήνυμα.} |
|||
{\ref{srs:functional-srs-vote-posts}} |
|||
{\ref{srs:non-functional-srs-minimize-fees}} |
|||
{Ο επισκέπτης πατάει το κουμπί υπερψήφισης ή καταψήφισης.} |
|||
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην σελίδα ενός θέματος το οποίο περιλαμβάνει τουλάχιστον ένα μήνυμα το οποίο δεν έχει δημιουργήσει ο ίδιος.} |
|||
{Σενάριο χρήσης 8, ψήφιση μηνύματος.} |
|||
{\label{table:3-6-use-case-vote-post}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & Ο χρήστης πατάει στο κουμπί υπερψήφισης μηνύματος. & Το σύστημα εισάγει νέα ψήφο μηνύματος στο blockchain. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα ανανεώνει τις ψήφους του μηνύματος.} |
|||
{Σενάριο χρήσης 8 - Βασική ροή} |
|||
{\label{table:3-6-use-case-vote-post-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-vote-post-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 8 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-vote-post-base-flow-sequence-diagram} |
|||
\end{figure} |
@ -0,0 +1,35 @@ |
|||
% ===== ===== |
|||
% Use case 9 |
|||
% ===== ===== |
|||
\subsection{Σενάριο χρήσης 9: Διαγραφή τοπικών δεδομένων} \label{subsection:3-6-use-case-delete-local-data} |
|||
|
|||
Το σενάριο χρήσης 9, <ΣΧ-9>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για τη διαγραφή των τοπικών δεδομένων. Στους πίνακες \ref{table:3-6-use-case-delete-local-data} και \ref{table:3-6-use-case-delete-local-data-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-9> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-delete-local-data-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
|||
|
|||
\useCaseTable |
|||
{Διαγράφω τα τοπικά δεδομένα} |
|||
{Στόχος του σεναρίου χρήσης είναι ο επισκέπτης να μπορεί να διαγράψει τα τοπικά δεδομένα που αποθηκεύονται στο σύστημά του από την εφαρμογή.} |
|||
{\ref{srs:functional-srs-delete-local-data}} |
|||
{-} |
|||
{Ο επισκέπτης πατάει το κουμπί διαγραφής των τοπικών δεδομένων.} |
|||
{Ο επισκέπτης πρέπει να έχει ανοίξει την σελίδα της εφαρμογής.} |
|||
{Σενάριο χρήσης 9, διαγραφή τοπικών δεδομένων.} |
|||
{\label{table:3-6-use-case-delete-local-data}} |
|||
|
|||
% ===== Base flow ===== |
|||
|
|||
\useCaseBaseFlowTable |
|||
{ |
|||
1 & Ο επισκέπτης πατάει το κουμπί διαγραφής των τοπικών δεδομένων. & Το σύστημα εμφανίζει την φόρμα "Επιβεβαίωση Διαγραφής Τοπικών Δεδομένων". \\ [0.5ex] |
|||
\midrule |
|||
2 & Ο επισκέπτης συμπληρώνει το πεδίο και πατάει το κουμπί "Υποβολή". & Το σύστημα διαγράφει όλες τις τοπικές βάσεις OrbitDb που χρησιμοποιούνται από την εφαρμογή. \\ [0.5ex] |
|||
} |
|||
{Το σύστημα παραμένει πραγματοποιεί ανανέωση της σελίδας.} |
|||
{Σενάριο χρήσης 9 - Βασική ροή} |
|||
{\label{table:3-6-use-case-delete-local-data-base-flow}} |
|||
|
|||
\begin{figure}[H] |
|||
\centering |
|||
\input{tikz/chapter-3/3-6-use-case-delete-local-data-sequence-diagram} |
|||
\caption{Σενάριο χρήσης 9 - Διάγραμμα βασικής ροής} |
|||
\label{figure:3-6-use-case-delete-local-data-base-flow-sequence-diagram} |
|||
\end{figure} |