Apostolos Fanakis
4 years ago
commit
2fc9714798
49 changed files with 818 additions and 0 deletions
@ -0,0 +1,279 @@ |
|||
## Core latex/pdflatex auxiliary files: |
|||
*.aux |
|||
*.lof |
|||
*.log |
|||
*.lot |
|||
*.fls |
|||
*.out |
|||
*.toc |
|||
*.fmt |
|||
*.fot |
|||
*.cb |
|||
*.cb2 |
|||
.*.lb |
|||
|
|||
## Intermediate documents: |
|||
*.dvi |
|||
*.xdv |
|||
*-converted-to.* |
|||
# these rules might exclude image files for figures etc. |
|||
# *.ps |
|||
# *.eps |
|||
# *.pdf |
|||
|
|||
## Generated if empty string is given at "Please type another file name for output:" |
|||
.pdf |
|||
|
|||
## Bibliography auxiliary files (bibtex/biblatex/biber): |
|||
*.bbl |
|||
*.bcf |
|||
*.blg |
|||
*-blx.aux |
|||
*-blx.bib |
|||
*.run.xml |
|||
|
|||
## Build tool auxiliary files: |
|||
*.fdb_latexmk |
|||
*.synctex |
|||
*.synctex(busy) |
|||
*.synctex.gz |
|||
*.synctex.gz(busy) |
|||
*.pdfsync |
|||
|
|||
## Build tool directories for auxiliary files |
|||
# latexrun |
|||
latex.out/ |
|||
|
|||
## Auxiliary and intermediate files from other packages: |
|||
# algorithms |
|||
*.alg |
|||
*.loa |
|||
|
|||
# achemso |
|||
acs-*.bib |
|||
|
|||
# amsthm |
|||
*.thm |
|||
|
|||
# beamer |
|||
*.nav |
|||
*.pre |
|||
*.snm |
|||
*.vrb |
|||
|
|||
# changes |
|||
*.soc |
|||
|
|||
# comment |
|||
*.cut |
|||
|
|||
# cprotect |
|||
*.cpt |
|||
|
|||
# elsarticle (documentclass of Elsevier journals) |
|||
*.spl |
|||
|
|||
# endnotes |
|||
*.ent |
|||
|
|||
# fixme |
|||
*.lox |
|||
|
|||
# feynmf/feynmp |
|||
*.mf |
|||
*.mp |
|||
*.t[1-9] |
|||
*.t[1-9][0-9] |
|||
*.tfm |
|||
|
|||
#(r)(e)ledmac/(r)(e)ledpar |
|||
*.end |
|||
*.?end |
|||
*.[1-9] |
|||
*.[1-9][0-9] |
|||
*.[1-9][0-9][0-9] |
|||
*.[1-9]R |
|||
*.[1-9][0-9]R |
|||
*.[1-9][0-9][0-9]R |
|||
*.eledsec[1-9] |
|||
*.eledsec[1-9]R |
|||
*.eledsec[1-9][0-9] |
|||
*.eledsec[1-9][0-9]R |
|||
*.eledsec[1-9][0-9][0-9] |
|||
*.eledsec[1-9][0-9][0-9]R |
|||
|
|||
# glossaries |
|||
*.acn |
|||
*.acr |
|||
*.glg |
|||
*.glo |
|||
*.gls |
|||
*.glsdefs |
|||
*.lzo |
|||
*.lzs |
|||
|
|||
# uncomment this for glossaries-extra (will ignore makeindex's style files!) |
|||
# *.ist |
|||
|
|||
# gnuplottex |
|||
*-gnuplottex-* |
|||
|
|||
# gregoriotex |
|||
*.gaux |
|||
*.gtex |
|||
|
|||
# htlatex |
|||
*.4ct |
|||
*.4tc |
|||
*.idv |
|||
*.lg |
|||
*.trc |
|||
*.xref |
|||
|
|||
# hyperref |
|||
*.brf |
|||
|
|||
# knitr |
|||
*-concordance.tex |
|||
# TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files |
|||
# *.tikz |
|||
*-tikzDictionary |
|||
|
|||
# listings |
|||
*.lol |
|||
|
|||
# luatexja-ruby |
|||
*.ltjruby |
|||
|
|||
# makeidx |
|||
*.idx |
|||
*.ilg |
|||
*.ind |
|||
|
|||
# minitoc |
|||
*.maf |
|||
*.mlf |
|||
*.mlt |
|||
*.mtc[0-9]* |
|||
*.slf[0-9]* |
|||
*.slt[0-9]* |
|||
*.stc[0-9]* |
|||
|
|||
# minted |
|||
_minted* |
|||
*.pyg |
|||
|
|||
# morewrites |
|||
*.mw |
|||
|
|||
# nomencl |
|||
*.nlg |
|||
*.nlo |
|||
*.nls |
|||
|
|||
# pax |
|||
*.pax |
|||
|
|||
# pdfpcnotes |
|||
*.pdfpc |
|||
|
|||
# sagetex |
|||
*.sagetex.sage |
|||
*.sagetex.py |
|||
*.sagetex.scmd |
|||
|
|||
# scrwfile |
|||
*.wrt |
|||
|
|||
# sympy |
|||
*.sout |
|||
*.sympy |
|||
sympy-plots-for-*.tex/ |
|||
|
|||
# pdfcomment |
|||
*.upa |
|||
*.upb |
|||
|
|||
# pythontex |
|||
*.pytxcode |
|||
pythontex-files-*/ |
|||
|
|||
# tcolorbox |
|||
*.listing |
|||
|
|||
# thmtools |
|||
*.loe |
|||
|
|||
# TikZ & PGF |
|||
*.dpth |
|||
*.md5 |
|||
*.auxlock |
|||
|
|||
# todonotes |
|||
*.tdo |
|||
|
|||
# vhistory |
|||
*.hst |
|||
*.ver |
|||
|
|||
# easy-todo |
|||
*.lod |
|||
|
|||
# xcolor |
|||
*.xcp |
|||
|
|||
# xmpincl |
|||
*.xmpi |
|||
|
|||
# xindy |
|||
*.xdy |
|||
|
|||
# xypic precompiled matrices and outlines |
|||
*.xyc |
|||
*.xyd |
|||
|
|||
# endfloat |
|||
*.ttt |
|||
*.fff |
|||
|
|||
# Latexian |
|||
TSWLatexianTemp* |
|||
|
|||
## Editors: |
|||
# WinEdt |
|||
*.bak |
|||
*.sav |
|||
|
|||
# Texpad |
|||
.texpadtmp |
|||
|
|||
# LyX |
|||
*.lyx~ |
|||
|
|||
# Kile |
|||
*.backup |
|||
|
|||
# gummi |
|||
.*.swp |
|||
|
|||
# KBibTeX |
|||
*~[0-9]* |
|||
|
|||
# TeXnicCenter |
|||
*.tps |
|||
|
|||
# auto folder when using emacs and auctex |
|||
./auto/* |
|||
*.el |
|||
|
|||
# expex forward references with \gathertags |
|||
*-tags.tex |
|||
|
|||
# standalone packages |
|||
*.sta |
|||
|
|||
# Makeindex log files |
|||
*.lpz |
|||
|
|||
# xwatermark package |
|||
*.xwm |
After Width: | Height: | Size: 189 KiB |
@ -0,0 +1 @@ |
|||
\addbibresource{bibliography/references.bib} |
@ -0,0 +1,25 @@ |
|||
% 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" |
|||
} |
@ -0,0 +1,14 @@ |
|||
\input{chapters/0.preamble/0.1.summary} |
|||
|
|||
\input{chapters/0.preamble/0.2.abstract} |
|||
\newpage |
|||
|
|||
% Acknowledgements |
|||
\input{chapters/0.preamble/0.3.acknowledgements} |
|||
\newpage |
|||
|
|||
\input{chapters/0.preamble/0.4.toc} |
|||
\newpage |
|||
|
|||
\input{chapters/0.preamble/0.5.lists} |
|||
\newpage |
@ -0,0 +1 @@ |
|||
Decentralized και τα σχετικά. |
@ -0,0 +1 @@ |
|||
Don't forget the keywords. |
@ -0,0 +1 @@ |
|||
Ευχαριστούμε η Αθήνα. Ευχαριστούμε η Ελλάδα. |
@ -0,0 +1 @@ |
|||
\tableofcontents |
@ -0,0 +1,8 @@ |
|||
\chapter{Εισαγωγή} |
|||
|
|||
\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.5.methodology} |
|||
\input{chapters/1.introduction/1.6.document-structure} |
@ -0,0 +1,3 @@ |
|||
\section{Γενικά} |
|||
|
|||
|
@ -0,0 +1,19 @@ |
|||
\section{Ορισμός του προβλήματος} |
|||
|
|||
Στις μέρες μας τα περισσότερα δεδομένα των χρηστών βρίσκονται υπό τον έλεγχο συγκεντρωτικών συστημάτων. Σε τέτοια συστήματα οι χρήστες δεν είναι κύριοι των δεδομένων τους, δεν έχουν εγγύηση για την αυθεντικότητα αυτών που βλέπουν και υπόκεινται σε λογοκρισία, ενώ τα συστήματα αυτά δεν είναι ασφαλή και μπορεί να σταματήσουν να λειτουργούν προσωρινά ή μόνιμα για τεχνικούς/οικονομικούς/νομικούς λόγους. |
|||
|
|||
Οι περισσότερες διαδεδομένες, συγκεντρωτικές μορφές πλατφόρμας επικοινωνίας (mailing list, forum, κοινωνικά δίκτυα και άλλες) χρειάζονται, τυπικά, τουλάχιστον τις εξής τεχνολογίες: |
|||
|
|||
\begin{itemize} |
|||
\item μία πηγή επεξεργαστικής ισχύος (processing) |
|||
\item μία βάση δεδομένων |
|||
\item ένα πρωτόκολλο επικοινωνίας |
|||
\end{itemize} |
|||
|
|||
Η επεξεργαστική ισχύς είναι αναγκαία για την περάτωση των λειτουργιών οι οποίες υλοποιούν τις υπηρεσίες της πλατφόρμας. Τις περισσότερες φορές η πηγή αυτή είναι ένας server ή μία cloud υπηρεσία. |
|||
|
|||
Η βάση δεδομένων είναι απαραίτητη για την αποθήκευση της πληροφορίας. Σε μικρότερες εφαρμογές η βάση βρίσκεται στο ίδιο σύστημα που γίνεται και το processing, ενώ σε μεγαλύτερες ενδέχεται να υπάρχει για λόγους ασφάλειας ένα ξεχωριστό σύστημα αφιερωμένο στη βάση δεδομένων. |
|||
|
|||
Το πρωτόκολλο επικοινωνίας αναλαμβάνει τη μετάδοση και ανάκτηση της πληροφορίας. Το πρωτόκολλό που χρησιμοποιείται σήμερα στη συντριπτική πλοιοψηφία των εφαρμογών είναι το HTTP. |
|||
|
|||
Κάθε ένα από τα παραπάνω μέρη, εισάγει την ανάγκη ύπαρξης κεντρικών αρχών που τα διαχειρίζονται και τα συντηρούν. Η αρχή αυτή είναι συνήθως ο πάροχος της υπηρεσίας που διαχειρίζεται το processing και τη βάση δεδομένων, έχοντας έτσι πρόσβαση σε όλα τα δεδομένα που υπάρχουν στο σύστημα. |
@ -0,0 +1,20 @@ |
|||
\section{Προτεινόμενη λύση} |
|||
|
|||
Το Concordia είναι η εφαρμογή η οποία αναπτύσσουμε εμείς και στοχεύει να διορθώσει αυτά τα προβλήματα, επαναφέροντας στους χρήστες την κυριότητα των δεδομένων τους, εξασφαλίζοντας την πλήρη ελευθερία του λόγου και την αυθεντικότητα, ανοίγοντας τον δρόμο για αξιόπιστες ψηφοφορίες |
|||
Όλα αυτά μέσα από δημόσιες, αποκεντρωτικές διαδικασίες. |
|||
|
|||
\subsection{Απαιτήσεις} |
|||
|
|||
\subsection{Αποκέντρωση} |
|||
|
|||
% Παλιό από Drive |
|||
Αποκέντρωση του συστήματος σημαίνει πρακτικά ότι το processing και η αποθήκευση των δεδομένων δε θα γίνονται από κάποια κεντρική αρχή αλλά θα είναι κατανεμημένα στο σύνολο των χρηστών (nodes). Με αυτόν τον τρόπο δεν υπάρχει ανάγκη για μία κεντρική αρχή και τα δεδομένα δεν είναι ελέγξιμα από κανέναν ατομικά, παρά μόνο από τη συναίνεση (consensus) του δικτύου. |
|||
|
|||
Τα συγκεντρωτικά συστήματα έχουν μερικά θετικά χαρακτηριστικά που λείπουν από τα αποκεντρωτικά συστήματα, όπως ευκολία ανάπτυξης, συντήρησης και αποσφαλμάτωσης των εφαρμογών. Πάσχουν ωστόσο σε ό,τι αφορά την σταθερότητα, την ασφάλεια, την επεκτασιμότητα και την εξέλιξη, τομείς όπου τα αποκεντρωτικά συστήματα είναι ιδιαίτερα αποτελεσματικά. |
|||
|
|||
Η ανάγκη για αποκέντρωση των εφαρμογών, ειδικά στην επικοινωνία, είναι μεγάλη και πηγάζει από την ανάγκη για ελευθερία του λόγου, ανωνυμία και ιδιωτικότητα. Χρησιμοποιώντας τεχνικές για κατανομή του processing, μία διανεμημένη βάση δεδομένων και αλγόριθμους κρυπτογραφίας δημόσιου κλειδιού μπορούμε να προστατεύσουμε την ανωνυμία του χρήστη αλλά και να εγγυηθούμε την ταυτοποίησή του. |
|||
|
|||
\subsection{Αμεσοδημοκρατικές διαδικασίες και αυτοδιαχείριση} |
|||
|
|||
% Παλιό από Drive |
|||
Για την πλήρη επίτευξη του στόχου απαιτείται επίσης ένα σύστημα διαχείρισης της πλατφόρμας αυτής καθ’ αυτής αλλά και των περιεχομένων της. Το σύστημα που επιλέγουμε για αυτούς τους σκοπούς είναι αυτό της άμεσης δημοκρατίας και αυτοδιαχείρισης. Αυτό σημαίνει ότι οι αποφάσεις θα παίρνονται μέσα από ψηφοφορίες στις οποίες θα μπορούν να συμμετέχουν όσα μέλη έχουν δικαίωμα ψήφου. Έτσι, λόγω της αποκέντρωσης και άρα της έλλειψης διοικούσας αρχής, η πλατφόρμα μπορεί να χρησιμοποιηθεί σαν μία εγγυημένα αμερόληπτη αρχή για ψηφοφορίες πάνω σε θέματα που αφορούν τη φοιτητική ζωή και όχι μόνο. |
@ -0,0 +1,4 @@ |
|||
\section{Στόχος} |
|||
|
|||
% Παλιό από Drive |
|||
Στόχος του project είναι η δημιουργία μιας κοινωνικής πλατφόρμας, η οποία, βασιζόμενη σε τεχνολογίες αποκέντρωσης, αφενός θα παρέχει ελευθερία λόγου, εργαλεία αυτοδιαχείρισης και αμεσοδημοκρατικές διαδικασίες, αφετέρου θα διασφαλίζει την κυριότητα των δεδομένων του χρήστη από τον ίδιο και την ανεξαρτητοποίηση του συστήματος από κεντρικές οντότητες. Παράλληλα, θα παρέχει στους επαληθευμένους χρήστες του ΑΠΘ μια πλατφόρμα για ανώνυμες και αυθεντικές ψηφοφορίες, εν δυνάμει ικανών να αποτελέσουν ένα έγκυρο, έμπιστο και άμεσα δημοκρατικό βήμα λήψης αποφάσεων. |
@ -0,0 +1,9 @@ |
|||
\section{Μεθοδολογία ανάπτυξης} |
|||
|
|||
Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της απαραίτητης δουλειάς σε διαχειρίσιμα μέρη σχεδιάστηκε η χρήση διάφορων εργαλείων και μεθόδων ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git και η μέθοδος οργάνωσης Scrum. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύχρονη ανάπτυξη λογισμικού. |
|||
|
|||
Το Git είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση κλαδιών (branches). Για τους σκοπούς της παρούσας διπλωματικής σχεδιάστηκε η χρήση του μοντέλου που έχει αναπτυχθεί από την εταιρία Github, Flow. Το μοντέλο αυτό ορίζει ότι κάθε προγραμματιστής θα ανοίγει ένα νέο branch για τη ανάπτυξη ενός νέου χαρακτηριστικού της εφαρρμογής ή την διόρθωση ενός μέρους του κώδικα. Έπειτα, όταν η δουλειά έχει ολοκληρωθεί το branch ενώνεται (merge) με το βασικό branch της εφαρμογής. |
|||
|
|||
Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο/η επιμελητής/επιμελήτρια του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από μέρη εργασίας τα οποία θα αποτελέσουν το επόμενο Sprint. Κάθε μέρος εργασίας ανατίθεται σε κάποιο μέλος για υλοποίηση και ορίζεται για το Sprint μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των μερών εργασίας πριν τη λήξη της. Στο τέλος προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί. |
|||
|
|||
Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διακρούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφής και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερομένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγεί τελμάτων κατά τη συγγραφή του κώδικα. |
@ -0,0 +1 @@ |
|||
\section{Οργάνωση κεφαλαίων} |
@ -0,0 +1,8 @@ |
|||
\chapter{Θεωρητικό υπόβαθρο} |
|||
|
|||
\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} |
@ -0,0 +1,18 @@ |
|||
\section{Συναρτήσεις κατακερματισμού} |
|||
|
|||
% Παλιό από Drive |
|||
Οι κρυπτογραφικές συναρτήσεις κατακερματισμού (cryptographic hash functions) είναι ειδική κατηγορία συναρτήσεων κατακερματισμού σχεδιασμένες για χρήση στην κρυπτογραφία. Οι συναρτήσεις κατακερματισμού είναι μαθηματικές συναρτήσεις που δέχονται ως είσοδο δεδομένα τυχαίου μεγέθους και επιστρέφουν συμβολοσειρές σταθερού μήκους αναπαράστασης. |
|||
|
|||
% TODO: insert diagram |
|||
|
|||
Οι τιμές που επιστρέφει η συνάρτηση κατακερματισμού ονομάζονται τιμές κατακερματισμού (hash values ή πιο απλά hashes). Μια ιδανική κρυπτογραφική συνάρτηση κατακερματισμού έχει τις εξής βασικές ιδιότητες: |
|||
|
|||
\begin{itemize} |
|||
\item Είναι ντετερμινιστική, έτσι η ίδια είσοδος παράγει πάντα την ίδια έξοδο. |
|||
\item Ο υπολογισμός των hashes για οποιοδήποτε μήνυμα είναι γρήγορος. |
|||
\item Δεν είναι εφικτό να βρεις την είσοδο από το hash, παρά μόνο δοκιμάζοντας όλα τα πιθανά μηνύματα. |
|||
\item Μία μικρή αλλαγή στο μήνυμα επιφέρει τόσο μεγάλες αλλαγές στο νέο παραγόμενο hash ώστε να φαίνεται ασυσχέτιστο με το παλιό. |
|||
\item Δεν είναι εφικτό να βρεθούν δύο διαφορετικές είσοδοι που δίνουν το ίδιο hash. |
|||
\end{itemize} |
|||
|
|||
% TODO: insert diagram |
@ -0,0 +1,28 @@ |
|||
\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,14 @@ |
|||
\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,7 @@ |
|||
\section{Έξυπνα συμβόλαια} |
|||
|
|||
Smart Contracts |
|||
- τι είναι; |
|||
- γιατί τα χρειαζόμαστε; ποιο πρόβλημα λύνουν; |
|||
- αναφορά στα έξοδα |
|||
- πόσα, ποια blockchains υλοποιούν smart contracts; |
@ -0,0 +1,8 @@ |
|||
\section{Αποκεντρωτική αποθήκευση δεδομένων (βάση δεδομένων)} |
|||
|
|||
Distributed databases |
|||
- τι είναι; |
|||
- ποιες είναι οι διαφορές από το blockchain; |
|||
- γιατί τις χρειαζόμαστε; ποιο πρόβλημα λύνουν; |
|||
- πόσες, ποιες υπάρχουν; παραδείγματα/διαφορές |
|||
- τεχνική ανάλυση (προτερήματα, drawbacks) |
@ -0,0 +1 @@ |
|||
\section{Αποκετροποιημένες εφαρμογές} |
@ -0,0 +1,8 @@ |
|||
\chapter{Σχεδίαση εφαρμογής} |
|||
|
|||
\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} |
@ -0,0 +1,19 @@ |
|||
\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,34 @@ |
|||
\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 @@ |
|||
\section{Σενάρια χρήσης} |
@ -0,0 +1,54 @@ |
|||
\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,38 @@ |
|||
\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 @@ |
|||
\section{Αρχιτεκτονική} |
@ -0,0 +1,6 @@ |
|||
\chapter{Υλοποίηση εφαρμογής} |
|||
|
|||
\input{chapters/4.application-implementation/4.1.implemented-parts} |
|||
\input{chapters/4.application-implementation/4.2.implementation-methodology} |
|||
\input{chapters/4.application-implementation/4.3.implementation-technology-stack} |
|||
\input{chapters/4.application-implementation/4.4.implementation-architecture} |
@ -0,0 +1 @@ |
|||
\section{Χαρακτηριστικά που υλοποιήθηκαν} |
@ -0,0 +1 @@ |
|||
\section{Μεθοδολογία υλοποίησης} |
@ -0,0 +1 @@ |
|||
\section{Τεχνολογίες υλοποίησης} |
@ -0,0 +1 @@ |
|||
\section{Αρχιτεκτονική υλοποίησης} |
@ -0,0 +1,6 @@ |
|||
\chapter{Συμπεράσματα} |
|||
|
|||
\input{chapters/5.conclusions/5.1.problems-faced} |
|||
\input{chapters/5.conclusions/5.2.design-implementation-differences} |
|||
\input{chapters/5.conclusions/5.3.open-areas} |
|||
\input{chapters/5.conclusions/5.4.conclusion} |
@ -0,0 +1 @@ |
|||
\section{Προβλήματα ανάπτυξης} |
@ -0,0 +1 @@ |
|||
\section{Διαφορές σχεδιασμού-υλοποίησης} |
@ -0,0 +1 @@ |
|||
\section{Ανοιχτά θέματα} |
@ -0,0 +1 @@ |
|||
\section{Επίλογος} |
@ -0,0 +1,54 @@ |
|||
% Heavily based on this template: |
|||
% https://www.overleaf.com/latex/templates/university-of-lincoln-computer-science-thesis-template-unofficial/vdbphtsnwdqv |
|||
|
|||
% Define variables |
|||
\makeatletter |
|||
|
|||
\newcommand{\universityLogo}[1]{\def\@logo{#1}} |
|||
\newcommand{\programme}[1]{\def\@programmename{#1}} |
|||
\newcommand{\school}[1]{\def\@schoolname{#1}} |
|||
\newcommand{\university}[1]{\def\@universityname{#1}} |
|||
\newcommand{\supervisor}[1]{\def\@supervisor{#1}} |
|||
|
|||
\makeatother |
|||
|
|||
% Change the author concat text |
|||
\renewcommand*{\Authand}{ και } |
|||
|
|||
% Make custom title |
|||
\makeatletter |
|||
\renewcommand\maketitle{ |
|||
{\raggedright |
|||
\begin{center} |
|||
|
|||
% Make the logo |
|||
\makeatletter |
|||
\centering\includegraphics[height=5cm]{\@logo} |
|||
|
|||
% Make the title |
|||
\vspace{3.44cm} |
|||
{\huge \@title} |
|||
|
|||
% The authors, school and university name |
|||
\vspace{3.72cm} |
|||
{\Large \@author} |
|||
\vspace{3.94cm} |
|||
|
|||
\begin{tabular}{rl} |
|||
\textit{Επιβλέπων} & \@supervisor |
|||
\end{tabular} |
|||
|
|||
% Print out the supervisor |
|||
\vspace{1cm} |
|||
{\@programmename \\ |
|||
\vspace{0.25cm} \@schoolname \\ |
|||
\vspace{0.25cm} \@universityname} |
|||
|
|||
% Then the date |
|||
\vspace{1.5cm} |
|||
{\footnotesize \@date} |
|||
|
|||
\end{center}} |
|||
\newpage |
|||
} |
|||
\makeatother |
@ -0,0 +1,25 @@ |
|||
Some text and the a cite\cite{einstein}. |
|||
|
|||
And another cite\cite{latexcompanion}. |
|||
|
|||
This is a list: |
|||
\begin{itemize} |
|||
\item item 1 |
|||
\item item 2 |
|||
\item item 3 |
|||
\end{itemize} |
|||
|
|||
This is some vertical space |
|||
\vspace{2cm} |
|||
|
|||
This is a numbered list: |
|||
\begin{enumerate} |
|||
\item asdf |
|||
\item fdas |
|||
\end{enumerate} |
|||
|
|||
\footnote{Here is a footnote} |
|||
|
|||
\texttt{This is monospace} |
|||
\newline |
|||
\newpage |
@ -0,0 +1,10 @@ |
|||
\ProvidesPackage{languages-fonts} |
|||
|
|||
\usepackage{polyglossia} |
|||
|
|||
\newfontfamily\greekfont[Script=Greek]{Linux Libertine O} |
|||
\newfontfamily\greekfontsf[Script=Greek]{Linux Libertine O} |
|||
\newfontfamily\greekfonttt[Script=Greek]{Linux Libertine Mono O} |
|||
|
|||
\setdefaultlanguage{greek} |
|||
\setotherlanguage{english} |
@ -0,0 +1,19 @@ |
|||
% Packages used |
|||
|
|||
% Used for flexibility, so other types of documents can have their own preambles (e.g. presentations) |
|||
\usepackage[subpreambles=true]{standalone} |
|||
|
|||
% Used for all the files inside thesis directory |
|||
\usepackage{subfiles} |
|||
|
|||
% General styling settings |
|||
\usepackage{thesis-general} |
|||
|
|||
% Paper size and margins |
|||
\usepackage{geometry} |
|||
|
|||
\usepackage{biblatex} |
|||
\usepackage{csquotes} |
|||
|
|||
% Custom commands |
|||
\input{custom-commands/custom-title} |
@ -0,0 +1,17 @@ |
|||
\universityLogo{assets/figures/auth-logo.png} |
|||
|
|||
\title{Αυτόνομο αμεσοδημοκρατικό κοινωνικό δίκτυο βασισμένο σε τεχνολογίες αποκέντρωσης} |
|||
|
|||
\author[1]{Νικολαΐδης Παναγιώτης} |
|||
\author[2]{Φανάκης Απόστολος} |
|||
|
|||
\affil[1]{nkpanagi@auth.gr, 7491} |
|||
\affil[2]{apostolof@auth.gr, 8261} |
|||
|
|||
\programme{Τμήμα Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών} |
|||
\school{Πολυτεχνική Σχολή} |
|||
\university{Αριστοτέλειο Πανεπιστήμιο Θεσσαλονίκης} |
|||
|
|||
\supervisor{Χρήστος Ε. Δημάκης} |
|||
|
|||
\date{Θεσσαλονίκη \the\year} |
@ -0,0 +1,8 @@ |
|||
\ProvidesPackage{thesis-general} |
|||
|
|||
% --- Languages & Fonts --- |
|||
\usepackage{languages-fonts} |
|||
|
|||
% --- Styling --- |
|||
\usepackage{hyperref} % Extensive support for hypertext |
|||
\usepackage{authblk} % Support for footnote style author/affiliation |
Binary file not shown.
@ -0,0 +1,39 @@ |
|||
\documentclass{report} |
|||
|
|||
% Custom packages |
|||
\input{packages} |
|||
|
|||
% Sets up the bib files |
|||
\input{bibliography/bib-setup} |
|||
|
|||
% Paper size and margins |
|||
\geometry{a4paper, top=2.5cm, bottom=2.5cm, left=2.2cm,right=2.2cm} |
|||
|
|||
\input{thesis-details} |
|||
|
|||
\begin{document} |
|||
|
|||
% Makes the cover page |
|||
\maketitle |
|||
|
|||
% TODO: delete this |
|||
\input{examples-page} |
|||
|
|||
\input{chapters/0.preamble/0.0.preamble} |
|||
|
|||
% start of thesis body |
|||
% --------------------------- |
|||
|
|||
\input{chapters/1.introduction/1.0.introduction} |
|||
\input{chapters/2.theoretical-background/2.0.theoretical-background} |
|||
\input{chapters/3.application-design/3.0.application-design} |
|||
\input{chapters/4.application-implementation/4.0.application-implementation} |
|||
\input{chapters/5.conclusions/5.0.conclusions} |
|||
|
|||
% end of thesis body |
|||
% -------------------------- |
|||
|
|||
% Prints out the references |
|||
\printbibliography |
|||
|
|||
\end{document} |
Loading…
Reference in new issue