diff --git a/.gitignore b/.gitignore index 328a40c..ea45bb2 100644 --- a/.gitignore +++ b/.gitignore @@ -277,3 +277,9 @@ TSWLatexianTemp* # xwatermark package *.xwm + +output +Makefile +.idea +*.sublime-project +*.sublime-workspace diff --git a/README.md b/README.md new file mode 100644 index 0000000..00d050d --- /dev/null +++ b/README.md @@ -0,0 +1,6 @@ +# Αυτόνομο κοινωνικό δίκτυο βασισμένο σε τεχνολογίες αποκέντρωσης + +*WIP* + +## How to run +`xelatex.exe -synctex=1 -interaction=nonstopmode -shell-escape "thesis".tex` diff --git a/assets/code/orbit-db-identity.js b/assets/code/orbit-db-identity.js new file mode 100644 index 0000000..8306a06 --- /dev/null +++ b/assets/code/orbit-db-identity.js @@ -0,0 +1,12 @@ +{ + _id: '', + // Auto-generated by OrbitDB + _publicKey: '', + signatures: { + //Allows the owner of id to prove they own the private key associated with publicKey + id: '', + //This links the two ids + publicKey: '' + }, + type: 'orbitdb' +} diff --git a/assets/figures/chapter-2/2.1.hash-functions-1.png b/assets/figures/chapter-2/2.1.hash-functions-1.png new file mode 100644 index 0000000..d651fc4 Binary files /dev/null and b/assets/figures/chapter-2/2.1.hash-functions-1.png differ diff --git a/assets/figures/chapter-2/2.1.hash-functions-2.png b/assets/figures/chapter-2/2.1.hash-functions-2.png new file mode 100644 index 0000000..84d3cc2 Binary files /dev/null and b/assets/figures/chapter-2/2.1.hash-functions-2.png differ diff --git a/assets/figures/asymmetric-end-to-end-communication.png b/assets/figures/chapter-2/2.2.asymmetric-end-to-end-communication.png similarity index 100% rename from assets/figures/asymmetric-end-to-end-communication.png rename to assets/figures/chapter-2/2.2.asymmetric-end-to-end-communication.png diff --git a/assets/figures/asymmetric-key-generation.png b/assets/figures/chapter-2/2.2.asymmetric-key-generation.png similarity index 100% rename from assets/figures/asymmetric-key-generation.png rename to assets/figures/chapter-2/2.2.asymmetric-key-generation.png diff --git a/assets/figures/chapter-2/2.3.merkle-tree.png b/assets/figures/chapter-2/2.3.merkle-tree.png new file mode 100644 index 0000000..f516fa2 Binary files /dev/null and b/assets/figures/chapter-2/2.3.merkle-tree.png differ diff --git a/assets/figures/ethereum-logo.png b/assets/figures/chapter-2/2.6.ethereum-logo.png similarity index 100% rename from assets/figures/ethereum-logo.png rename to assets/figures/chapter-2/2.6.ethereum-logo.png diff --git a/assets/figures/ipfs-logo.png b/assets/figures/chapter-2/2.7.ipfs-logo.png similarity index 100% rename from assets/figures/ipfs-logo.png rename to assets/figures/chapter-2/2.7.ipfs-logo.png diff --git a/assets/figures/merkle-dag.png b/assets/figures/chapter-2/2.7.merkle-dag.png similarity index 100% rename from assets/figures/merkle-dag.png rename to assets/figures/chapter-2/2.7.merkle-dag.png diff --git a/assets/figures/chapter-3/3.2.technology.stack.png b/assets/figures/chapter-3/3.2.technology.stack.png new file mode 100644 index 0000000..cca9ec6 Binary files /dev/null and b/assets/figures/chapter-3/3.2.technology.stack.png differ diff --git a/assets/figures/chapter-3/3.7.architecture-design.png b/assets/figures/chapter-3/3.7.architecture-design.png new file mode 100644 index 0000000..6a89a86 Binary files /dev/null and b/assets/figures/chapter-3/3.7.architecture-design.png differ diff --git a/assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png b/assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png new file mode 100644 index 0000000..45c172d Binary files /dev/null and b/assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png differ diff --git a/assets/figures/chapter-4/4.1.implementation-methodology-jenkins-pipeline.png b/assets/figures/chapter-4/4.1.implementation-methodology-jenkins-pipeline.png new file mode 100644 index 0000000..8447c19 Binary files /dev/null and b/assets/figures/chapter-4/4.1.implementation-methodology-jenkins-pipeline.png differ diff --git a/assets/figures/chapter-4/4.1.implementation-methodology-kanban.png b/assets/figures/chapter-4/4.1.implementation-methodology-kanban.png new file mode 100644 index 0000000..710e37c Binary files /dev/null and b/assets/figures/chapter-4/4.1.implementation-methodology-kanban.png differ diff --git a/assets/figures/chapter-4/4.2.docker-logo.png b/assets/figures/chapter-4/4.2.docker-logo.png new file mode 100644 index 0000000..60b9017 Binary files /dev/null and b/assets/figures/chapter-4/4.2.docker-logo.png differ diff --git a/assets/figures/chapter-4/4.2.ganache-gui.png b/assets/figures/chapter-4/4.2.ganache-gui.png new file mode 100644 index 0000000..4588c54 Binary files /dev/null and b/assets/figures/chapter-4/4.2.ganache-gui.png differ diff --git a/assets/figures/chapter-4/4.2.ganache-logo.png b/assets/figures/chapter-4/4.2.ganache-logo.png new file mode 100644 index 0000000..5b2b09f Binary files /dev/null and b/assets/figures/chapter-4/4.2.ganache-logo.png differ diff --git a/assets/figures/chapter-4/4.2.jenkins-logo.png b/assets/figures/chapter-4/4.2.jenkins-logo.png new file mode 100644 index 0000000..5cd5250 Binary files /dev/null and b/assets/figures/chapter-4/4.2.jenkins-logo.png differ diff --git a/assets/figures/chapter-4/4.2.js-ipfs-logo.png b/assets/figures/chapter-4/4.2.js-ipfs-logo.png new file mode 100644 index 0000000..529d7c6 Binary files /dev/null and b/assets/figures/chapter-4/4.2.js-ipfs-logo.png differ diff --git a/assets/figures/chapter-4/4.2.libp2p-logo.png b/assets/figures/chapter-4/4.2.libp2p-logo.png new file mode 100644 index 0000000..7fd4b72 Binary files /dev/null and b/assets/figures/chapter-4/4.2.libp2p-logo.png differ diff --git a/assets/figures/chapter-4/4.2.node.js-logo.png b/assets/figures/chapter-4/4.2.node.js-logo.png new file mode 100644 index 0000000..bab737c Binary files /dev/null and b/assets/figures/chapter-4/4.2.node.js-logo.png differ diff --git a/assets/figures/orbitdb-logo.png b/assets/figures/chapter-4/4.2.orbitdb-logo.png similarity index 100% rename from assets/figures/orbitdb-logo.png rename to assets/figures/chapter-4/4.2.orbitdb-logo.png diff --git a/assets/figures/chapter-4/4.2.react-logo.png b/assets/figures/chapter-4/4.2.react-logo.png new file mode 100644 index 0000000..713bd65 Binary files /dev/null and b/assets/figures/chapter-4/4.2.react-logo.png differ diff --git a/assets/figures/chapter-4/4.2.react-redux.png b/assets/figures/chapter-4/4.2.react-redux.png new file mode 100644 index 0000000..96f6725 Binary files /dev/null and b/assets/figures/chapter-4/4.2.react-redux.png differ diff --git a/assets/figures/chapter-4/4.2.redux-logo.png b/assets/figures/chapter-4/4.2.redux-logo.png new file mode 100644 index 0000000..148b674 Binary files /dev/null and b/assets/figures/chapter-4/4.2.redux-logo.png differ diff --git a/assets/figures/chapter-4/4.2.redux-saga-logo.png b/assets/figures/chapter-4/4.2.redux-saga-logo.png new file mode 100644 index 0000000..38a4c43 Binary files /dev/null and b/assets/figures/chapter-4/4.2.redux-saga-logo.png differ diff --git a/assets/figures/chapter-4/4.2.truffle-logo.png b/assets/figures/chapter-4/4.2.truffle-logo.png new file mode 100644 index 0000000..d1d62ef Binary files /dev/null and b/assets/figures/chapter-4/4.2.truffle-logo.png differ diff --git a/assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png b/assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png new file mode 100644 index 0000000..8ade85e Binary files /dev/null and b/assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png differ diff --git a/assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png b/assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png new file mode 100644 index 0000000..fbd2cab Binary files /dev/null and b/assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png differ diff --git a/assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png b/assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png new file mode 100644 index 0000000..d5e273e Binary files /dev/null and b/assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png differ diff --git a/assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture.png b/assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture.png new file mode 100644 index 0000000..71c491d Binary files /dev/null and b/assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture.png differ diff --git a/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png b/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png new file mode 100644 index 0000000..04d4255 Binary files /dev/null and b/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png differ diff --git a/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png b/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png new file mode 100644 index 0000000..2d3c295 Binary files /dev/null and b/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png differ diff --git a/assets/figures/chapter-4/4.3.architecture-architecture-overview.png b/assets/figures/chapter-4/4.3.architecture-architecture-overview.png new file mode 100644 index 0000000..8c193f5 Binary files /dev/null and b/assets/figures/chapter-4/4.3.architecture-architecture-overview.png differ diff --git a/assets/figures/chapter-4/4.3.communications-diagram.png b/assets/figures/chapter-4/4.3.communications-diagram.png new file mode 100644 index 0000000..85c72b9 Binary files /dev/null and b/assets/figures/chapter-4/4.3.communications-diagram.png differ diff --git a/assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png b/assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png new file mode 100644 index 0000000..2e7fb89 Binary files /dev/null and b/assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png differ diff --git a/assets/figures/chapter-5/5.1.xkcd_2030_voting_software.png b/assets/figures/chapter-5/5.1.xkcd_2030_voting_software.png new file mode 100644 index 0000000..8ee2898 Binary files /dev/null and b/assets/figures/chapter-5/5.1.xkcd_2030_voting_software.png differ diff --git a/assets/figures/orbitdb-identity.png b/assets/figures/orbitdb-identity.png deleted file mode 100644 index ef6eeb0..0000000 Binary files a/assets/figures/orbitdb-identity.png and /dev/null differ diff --git a/bibliography/references.bib b/bibliography/references.bib index 04c64cd..13f7847 100644 --- a/bibliography/references.bib +++ b/bibliography/references.bib @@ -1,92 +1,134 @@ % 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, - author = {Wikipedia}, - title = {Merkle tree}, - url = {https://en.wikipedia.org/wiki/Merkle_tree} + title = {Merkle tree}, + author = {Wikipedia}, + url = {https://en.wikipedia.org/wiki/Merkle_tree} } - @online{2.3-merkle-proofs-explained, - author = {Belavadi Prahalad}, - title = {Merkle proofs Explained.}, - date = {2018-01-07}, - url = {https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5} + 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, - author={Schollmeier, R.}, - booktitle={Proceedings First International Conference on Peer-to-Peer Computing}, - title={A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications}, - year={2001}, - pages={101-102}, - doi={10.1109/P2P.2001.990434} -} - + 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, - author = {Nakamoto, Satoshi}, - year = {2009}, - month = {03}, - title = {Bitcoin: A Peer-to-Peer Electronic Cash System}, - journal = {Cryptography Mailing list at https://metzdowd.com} + 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, - author = {Wikipedia}, - title = {Blockchain}, - url = {https://en.wikipedia.org/wiki/Blockchain} + title = {Blockchain}, + author = {Wikipedia}, + url = {https://en.wikipedia.org/wiki/Blockchain} } - @online{2.6-ethereum-whitepaper, - author = {Vitalik Buterin}, - title = {Ethereum Whitepaper}, - date = {2013}, - urldate = {2021-06-28}, - url = {https://ethereum.org/en/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, - author = {Savelyev, Alexander}, - year = {2017}, - month = {04}, - pages = {1-19}, - title = {Contract law 2.0: ‘Smart’ contracts as the beginning of the end of classic contract law}, - volume = {26}, - journal = {Information \& Communications Technology Law}, - doi = {10.1080/13600834.2017.1301036} -} - + 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, - author = {Andreas M Antonopoulos, Gavin Wood}, - title = {Mastering Ethereum: Building Smart Contracts and DApps}, - date = {2018}, - publisher = {O'Reilly Media}, - isbn = {1491971940 }, - OPTurl = {https://cypherpunks-core.github.io/ethereumbook/}, -} - + 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/} + title = {IPFS}, + url = {https://ipfs.io/} } - @misc{2.7-ipfs-docs, - title = {IPFS documentation}, - url = {https://docs.ipfs.io/} + title = {IPFS documentation}, + url = {https://docs.ipfs.io/} } - @misc{2.7-merkle-dags-proto-school, - author = {ProtoSchool}, - title = {Merkle DAGs: Structuring Data for the Distributed Web}, - url = {https://proto.school/merkle-dags/} + title = {Merkle DAGs: Structuring Data for the Distributed Web}, + author = {ProtoSchool}, + url = {https://proto.school/merkle-dags/} +} +@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{2.8-orbitdb, - title = {OrbitDB}, - url = {https://orbitdb.org} +@misc{5.2-privacy-on-ethereum, + title = {Privacy on Ethereum}, + url = {https://docs.ethhub.io/ethereum-roadmap/privacy/}, + urldate = {2021-12-12} } - -@misc{2.8-orbitdb-guide, - title = {Getting Started with OrbitDB}, - url = {https://github.com/orbitdb/orbit-db/blob/main/GUIDE.md} +@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} } - diff --git a/chapters/0.preamble/0.1.summary.tex b/chapters/0.preamble/0.1.summary.tex index 571993c..b56286c 100644 --- a/chapters/0.preamble/0.1.summary.tex +++ b/chapters/0.preamble/0.1.summary.tex @@ -3,7 +3,7 @@ Τις τελευταίες δεκαετίες, η ραγδαία ανάπτυξη του διαδικτύου μετέβαλε ριζικά τις ανθρώπινες κοινωνίες, μέσω μίας πληθώρας ψηφιακών εφαρμογών, οι οποίες, στη συντριπτική τους πλειοψηφία, προσφέρονται από παρόχους υπηρεσιών υπολογιστικού νέφους, ακολουθώντας την αρχιτεκτονική πελάτη-εξυπηρετητή. -Μολονότι αυτό το μοντέλο υλοποίησης έχει αποδειχθεί ιδιαίτερα λειτουργικό και έχει βελτιωθεί αξιοσημείωτα ανά τα χρόνια, η συγκεντρωτική του λογική συνοδεύεται από μία σειρά προβλημάτων. Πρώτα απ' όλα, ο χρήστης καλείται να εμπιστευθεί τα προσωπικά του δεδομένα σε μία τρίτη οντότητα. Εκείνη, διατηρώντας τον πλήρη έλεγχο επί αυτών, διαθέτει τη δυνατότητα να τα επεξεργάζεται, να τα διαμοιράζεται και να τα λογοκρίνει, είτε για να εξυπηρετήσει τα συμφέροντά της, είτε για να συμμορφωθεί με άλλες αρχές που της ασκούν εξουσία. Επιπλέον, απουσιάζει η εγγύηση της διαθεσιμότητας των δεδομένων, καθώς, ανά πάσα στιγμή, ο εξυπηρετητής μπορεί να αποσυνδεθεί για αόριστο χρονικό διάστημα και λόγω ποικίλων αιτιών, όπως κάποιας κυβερνοεπίθεσης ή κάποιας φυσικής καταστροφής. +Μολονότι αυτό το μοντέλο υλοποίησης έχει αποδειχθεί ιδιαίτερα λειτουργικό και έχει βελτιωθεί αξιοσημείωτα ανά τα χρόνια, η συγκεντρωτική του λογική συνοδεύεται από μία σειρά προβλημάτων. Πρώτα απ' όλα, ο χρήστης καλείται να εμπιστευθεί τα προσωπικά του δεδομένα σε μία εξωτερική οντότητα. Εκείνη, διατηρώντας τον πλήρη έλεγχο επί αυτών, διαθέτει τη δυνατότητα να τα επεξεργάζεται, να τα διαμοιράζεται και να τα λογοκρίνει, είτε για να εξυπηρετήσει τα συμφέροντά της, είτε για να συμμορφωθεί με άλλες αρχές που της ασκούν εξουσία. Επιπλέον, απουσιάζει η εγγύηση της διαθεσιμότητας των δεδομένων, καθώς, ανά πάσα στιγμή, ο εξυπηρετητής μπορεί να αποσυνδεθεί για αόριστο χρονικό διάστημα και λόγω ποικίλων αιτιών, όπως κάποιας κυβερνοεπίθεσης ή κάποιας φυσικής καταστροφής. Αυτοί είναι μερικοί βασικοί λόγοι που συνετέλεσαν στην ταχεία ανάπτυξη ενός συνόλου λογισμικών ανοιχτού κώδικα, όπως του Ethereum blockchain και του IPFS, τα οποία, αν και βρίσκονται σε σχετικά πρώιμο στάδιο, αποτελούν ήδη ικανά εργαλεία δημιουργίας κατανεμημένων και αποκεντρωμένων εφαρμογών. @@ -11,4 +11,4 @@ η οποία, αξιοποιώντας τεχνολογίες αποκέντρωσης, αφενός θα επιστρέφει την κυριότητα των προσωπικών δεδομένων στον χρήστη, αφετέρου θα παρέχει τη δυνατότητα διενέργειας διαφανών δημοκρατικών ψηφοφοριών. Αυτά μέσα σε ένα πλαίσιο ανθεκτικό, τόσο σε σφάλματα και επιθέσεις, όσο και σε απόπειρες λογοκρισίας και παραποίησης. \\[2\baselineskip] -\textbf{Λέξεις-Κλειδιά}: Αποκεντροποίηση, Ethereum, Blockchain, Έξυπνο Συμβόλαιο, Αποκεντρωμένη Εφαρμογή, IPFS, OrbitDB \ No newline at end of file +\textbf{Λέξεις-Κλειδιά}: Αποκεντροποίηση, Ethereum, Blockchain, Έξυπνο Συμβόλαιο, Αποκεντρωμένη Εφαρμογή, IPFS, OrbitDB, React, Redux, Jenkins \ No newline at end of file diff --git a/chapters/0.preamble/0.4.toc.tex b/chapters/0.preamble/0.4.toc.tex index 67f93b1..d937ccf 100644 --- a/chapters/0.preamble/0.4.toc.tex +++ b/chapters/0.preamble/0.4.toc.tex @@ -1 +1,5 @@ -\tableofcontents \ No newline at end of file +% 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} diff --git a/chapters/1.introduction/1.0.introduction.tex b/chapters/1.introduction/1.0.introduction.tex index e330bbd..523db09 100644 --- a/chapters/1.introduction/1.0.introduction.tex +++ b/chapters/1.introduction/1.0.introduction.tex @@ -1,8 +1,8 @@ -\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.document-structure} \ No newline at end of file diff --git a/chapters/1.introduction/1.1.general.tex b/chapters/1.introduction/1.1.general.tex index 3a5fb1d..8aa113c 100644 --- a/chapters/1.introduction/1.1.general.tex +++ b/chapters/1.introduction/1.1.general.tex @@ -1,3 +1,12 @@ \section{Γενικά} +Η αλματώδης ανάπτυξη του διαδικτύου διαμόρφωσε ένα ολοκαίνουργιο τοπίο σε κάθε τομέα της ανθρώπινης δραστηριότητας, παρέχοντας ένα αναρίθμητο πλήθος εφαρμογών και υπηρεσιών. Τα μέσα κοινωνικής δικτύωσης, +το ηλεκτρονικό ταχυδρομείο, η ψηφιακή ειδησεογραφία, ο διαμοιρασμός αρχείων και +οι υπηρεσίες πολυμέσων ροής, αποτελούν ορισμένα από τα σημαντικότερα - και πλέον αναπόσπαστα - κομμάτια, +που συνθέτουν την ψηφιακή πτυχή της σύγχρονης καθημερινότητας. +Κατά κύριο λόγο, το μοντέλο που ακολουθούν οι παραπάνω τεχνολογίες είναι αυτό της αρχιτεκτονικής πελάτη-εξυπηρετητή (client–server architecture) και προσφέρονται από παρόχους υπηρεσιών υπολογιστικού νέφους (cloud computing service providers). Αυτό σημαίνει ότι οι απαραίτητες λειτουργίες τους, δηλαδή η επεξεργασία (processing), η αποθήκευση των δεδομένων (storage) και το πρωτόκολλο επικοινωνίας (communication protocol) υλοποιούνται επί ενός συγκεντρωτικού (centralized) πλαισίου, κάτι που τους προσδίδει ορισμένα αξιοσημείωτα πλεονεκτήματα (π.χ. ευκολία ανάπτυξης, συντήρησης και αποσφαλμάτωσης). + +Στις μέρες μας, ωστόσο, παρατηρείται παράλληλα μία τάση δημιουργίας εφαρμογών που ακολουθούν αποκεντρωτικά μοντέλα λειτουργίας, στα οποία το processing και το storage κατανέμονται σε ένα σύνολο κόμβων που επικοινωνούν ομότιμα. Εντός, λοιπόν, αυτής της τάσης, αναπτύσσονται με ταχείς ρυθμούς διάφορα λογισμικά, τα οποία συνθέτουν ένα νέο, αποκεντρωτικό οικοσύστημα. Αυτό περιλαμβάνει (μεταξύ άλλων) τόσο καινοτόμα πρωτόκολλα αποθήκευσης δεδομένων (π.χ. IPFS), όσο και πλατφόρμες ανάπτυξης και εκτέλεσης αποκεντρωμένων εφαρμογών (π.χ. Ethereum blockchain). + +\newpage \ No newline at end of file diff --git a/chapters/1.introduction/1.2.decentralization.tex b/chapters/1.introduction/1.2.decentralization.tex new file mode 100644 index 0000000..9301276 --- /dev/null +++ b/chapters/1.introduction/1.2.decentralization.tex @@ -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. diff --git a/chapters/1.introduction/1.2.problem-definition.tex b/chapters/1.introduction/1.2.problem-definition.tex deleted file mode 100644 index fc3e4e0..0000000 --- a/chapters/1.introduction/1.2.problem-definition.tex +++ /dev/null @@ -1,19 +0,0 @@ -\section{Ορισμός του προβλήματος} - -Στις μέρες μας τα περισσότερα δεδομένα των χρηστών βρίσκονται υπό τον έλεγχο συγκεντρωτικών συστημάτων. Σε τέτοια συστήματα οι χρήστες δεν είναι κύριοι των δεδομένων τους, δεν έχουν εγγύηση για την αυθεντικότητα αυτών που βλέπουν και υπόκεινται σε λογοκρισία, ενώ τα συστήματα αυτά δεν είναι ασφαλή και μπορεί να σταματήσουν να λειτουργούν προσωρινά ή μόνιμα για τεχνικούς/οικονομικούς/νομικούς λόγους. - -Οι περισσότερες διαδεδομένες, συγκεντρωτικές μορφές πλατφόρμας επικοινωνίας (mailing list, forum, κοινωνικά δίκτυα και άλλες) χρειάζονται, τυπικά, τουλάχιστον τις εξής τεχνολογίες: - -\begin{itemize} - \item μία πηγή επεξεργαστικής ισχύος (processing) - \item μία βάση δεδομένων - \item ένα πρωτόκολλο επικοινωνίας -\end{itemize} - -Η επεξεργαστική ισχύς είναι αναγκαία για την περάτωση των λειτουργιών οι οποίες υλοποιούν τις υπηρεσίες της πλατφόρμας. Τις περισσότερες φορές η πηγή αυτή είναι ένας server ή μία cloud υπηρεσία. - -Η βάση δεδομένων είναι απαραίτητη για την αποθήκευση της πληροφορίας. Σε μικρότερες εφαρμογές η βάση βρίσκεται στο ίδιο σύστημα που γίνεται και το processing, ενώ σε μεγαλύτερες ενδέχεται να υπάρχει για λόγους ασφάλειας ένα ξεχωριστό σύστημα αφιερωμένο στη βάση δεδομένων. - -Το πρωτόκολλο επικοινωνίας αναλαμβάνει τη μετάδοση και ανάκτηση της πληροφορίας. Το πρωτόκολλό που χρησιμοποιείται σήμερα στη συντριπτική πλοιοψηφία των εφαρμογών είναι το HTTP. - -Κάθε ένα από τα παραπάνω μέρη, εισάγει την ανάγκη ύπαρξης κεντρικών αρχών που τα διαχειρίζονται και τα συντηρούν. Η αρχή αυτή είναι συνήθως ο πάροχος της υπηρεσίας που διαχειρίζεται το processing και τη βάση δεδομένων, έχοντας έτσι πρόσβαση σε όλα τα δεδομένα που υπάρχουν στο σύστημα. diff --git a/chapters/1.introduction/1.3.problem-definition.tex b/chapters/1.introduction/1.3.problem-definition.tex new file mode 100644 index 0000000..e7b4af7 --- /dev/null +++ b/chapters/1.introduction/1.3.problem-definition.tex @@ -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} + +Επιπλέον, όπως γίνεται φανερό, οι αδυναμίες του συστήματος ως προς τον πολιτικό άξονα το καθιστούν ακατάλληλο να παρέχει στους χρήστες αυθεντικές και επικυρώσιμες δημοκρατικές διαδικασίες. Τέτοιου είδους διαδικασίες θα μπορούσε να ήταν από απλές ψηφοφορίες, μέχρι σύνθετες διαδικασίες αυτοδιαχείρισης της πλατφόρμας. \ No newline at end of file diff --git a/chapters/1.introduction/1.3.suggested-solution.tex b/chapters/1.introduction/1.3.suggested-solution.tex deleted file mode 100644 index 89deb45..0000000 --- a/chapters/1.introduction/1.3.suggested-solution.tex +++ /dev/null @@ -1,20 +0,0 @@ -\section{Προτεινόμενη λύση} - -Το Concordia είναι η εφαρμογή η οποία αναπτύσσουμε εμείς και στοχεύει να διορθώσει αυτά τα προβλήματα, επαναφέροντας στους χρήστες την κυριότητα των δεδομένων τους, εξασφαλίζοντας την πλήρη ελευθερία του λόγου και την αυθεντικότητα, ανοίγοντας τον δρόμο για αξιόπιστες ψηφοφορίες -Όλα αυτά μέσα από δημόσιες, αποκεντρωτικές διαδικασίες. - -\subsection{Απαιτήσεις} - -\subsection{Αποκέντρωση} - -% Παλιό από Drive -Αποκέντρωση του συστήματος σημαίνει πρακτικά ότι το processing και η αποθήκευση των δεδομένων δε θα γίνονται από κάποια κεντρική αρχή αλλά θα είναι κατανεμημένα στο σύνολο των χρηστών (nodes). Με αυτόν τον τρόπο δεν υπάρχει ανάγκη για μία κεντρική αρχή και τα δεδομένα δεν είναι ελέγξιμα από κανέναν ατομικά, παρά μόνο από τη συναίνεση (consensus) του δικτύου. - -Τα συγκεντρωτικά συστήματα έχουν μερικά θετικά χαρακτηριστικά που λείπουν από τα αποκεντρωτικά συστήματα, όπως ευκολία ανάπτυξης, συντήρησης και αποσφαλμάτωσης των εφαρμογών. Πάσχουν ωστόσο σε ό,τι αφορά την σταθερότητα, την ασφάλεια, την επεκτασιμότητα και την εξέλιξη, τομείς όπου τα αποκεντρωτικά συστήματα είναι ιδιαίτερα αποτελεσματικά. - -Η ανάγκη για αποκέντρωση των εφαρμογών, ειδικά στην επικοινωνία, είναι μεγάλη και πηγάζει από την ανάγκη για ελευθερία του λόγου, ανωνυμία και ιδιωτικότητα. Χρησιμοποιώντας τεχνικές για κατανομή του processing, μία διανεμημένη βάση δεδομένων και αλγόριθμους κρυπτογραφίας δημόσιου κλειδιού μπορούμε να προστατεύσουμε την ανωνυμία του χρήστη αλλά και να εγγυηθούμε την ταυτοποίησή του. - -\subsection{Αμεσοδημοκρατικές διαδικασίες και αυτοδιαχείριση} - -% Παλιό από Drive -Για την πλήρη επίτευξη του στόχου απαιτείται επίσης ένα σύστημα διαχείρισης της πλατφόρμας αυτής καθ’ αυτής αλλά και των περιεχομένων της. Το σύστημα που επιλέγουμε για αυτούς τους σκοπούς είναι αυτό της άμεσης δημοκρατίας και αυτοδιαχείρισης. Αυτό σημαίνει ότι οι αποφάσεις θα παίρνονται μέσα από ψηφοφορίες στις οποίες θα μπορούν να συμμετέχουν όσα μέλη έχουν δικαίωμα ψήφου. Έτσι, λόγω της αποκέντρωσης και άρα της έλλειψης διοικούσας αρχής, η πλατφόρμα μπορεί να χρησιμοποιηθεί σαν μία εγγυημένα αμερόληπτη αρχή για ψηφοφορίες πάνω σε θέματα που αφορούν τη φοιτητική ζωή και όχι μόνο. diff --git a/chapters/1.introduction/1.4.goals.tex b/chapters/1.introduction/1.4.goals.tex deleted file mode 100644 index 408e31d..0000000 --- a/chapters/1.introduction/1.4.goals.tex +++ /dev/null @@ -1,4 +0,0 @@ -\section{Στόχος} - -% Παλιό από Drive -Στόχος του project είναι η δημιουργία μιας κοινωνικής πλατφόρμας, η οποία, βασιζόμενη σε τεχνολογίες αποκέντρωσης, αφενός θα παρέχει ελευθερία λόγου, εργαλεία αυτοδιαχείρισης και αμεσοδημοκρατικές διαδικασίες, αφετέρου θα διασφαλίζει την κυριότητα των δεδομένων του χρήστη από τον ίδιο και την ανεξαρτητοποίηση του συστήματος από κεντρικές οντότητες. Παράλληλα, θα παρέχει στους επαληθευμένους χρήστες του ΑΠΘ μια πλατφόρμα για ανώνυμες και αυθεντικές ψηφοφορίες, εν δυνάμει ικανών να αποτελέσουν ένα έγκυρο, έμπιστο και άμεσα δημοκρατικό βήμα λήψης αποφάσεων. diff --git a/chapters/1.introduction/1.4.thesis-goal.tex b/chapters/1.introduction/1.4.thesis-goal.tex new file mode 100644 index 0000000..900559a --- /dev/null +++ b/chapters/1.introduction/1.4.thesis-goal.tex @@ -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 κ.ά.). diff --git a/chapters/1.introduction/1.5.methodology.tex b/chapters/1.introduction/1.5.methodology.tex index 751f63b..ab68d81 100644 --- a/chapters/1.introduction/1.5.methodology.tex +++ b/chapters/1.introduction/1.5.methodology.tex @@ -1,9 +1,9 @@ -\section{Μεθοδολογία ανάπτυξης} +\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. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί. +Στα πρώτα στάδια της έρευνας εξοικειωθήκαμε με τον χώρο .... -Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διακρούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφής και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερομένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγεί τελμάτων κατά τη συγγραφή του κώδικα. +Έπειτα, έγιναν μερικές πρώτες προσπάθειες για τη δημιουργία ενός proof of concept application... diff --git a/chapters/1.introduction/1.6.document-structure.tex b/chapters/1.introduction/1.6.document-structure.tex index ed17892..fe2ed22 100644 --- a/chapters/1.introduction/1.6.document-structure.tex +++ b/chapters/1.introduction/1.6.document-structure.tex @@ -1 +1,11 @@ \section{Οργάνωση κεφαλαίων} + +Η παρούσα διπλωματική εργασία οργανώνεται σε κεφάλαια, ενότητες και υποενότητες, όπως αυτά παρατίθενται στα \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}} + \item Στο \hyperref[chapter:5-conclusions-open-areas]{\textbf{Κεφάλαιο 5}} +\end{itemize} \ No newline at end of file diff --git a/chapters/2.theoretical-background/2.0.theoretical-background.tex b/chapters/2.theoretical-background/2.0.theoretical-background.tex index 0b2e43f..a621d5b 100644 --- a/chapters/2.theoretical-background/2.0.theoretical-background.tex +++ b/chapters/2.theoretical-background/2.0.theoretical-background.tex @@ -1,4 +1,4 @@ -\chapter{Θεωρητικό υπόβαθρο} +\chapter{Θεωρητικό υπόβαθρο}\label{chapter:2-theoretical-background} \input{chapters/2.theoretical-background/2.1.hash-functions} \input{chapters/2.theoretical-background/2.2.asymmetric-cryptography} @@ -6,5 +6,4 @@ \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} -\input{chapters/2.theoretical-background/2.8.orbit-db} \ No newline at end of file +\input{chapters/2.theoretical-background/2.7.ipfs} \ No newline at end of file diff --git a/chapters/2.theoretical-background/2.1.hash-functions.tex b/chapters/2.theoretical-background/2.1.hash-functions.tex index f5a3158..8b6580a 100644 --- a/chapters/2.theoretical-background/2.1.hash-functions.tex +++ b/chapters/2.theoretical-background/2.1.hash-functions.tex @@ -1,8 +1,12 @@ -\section{Συναρτήσεις κατακερματισμού} +\section{Συναρτήσεις κατακερματισμού} \label{section:2-1-hash-functions} -Οι \textbf{κρυπτογραφικές συναρτήσεις κατακερματισμού} (cryptographic hash functions) είναι ειδική κατηγορία συναρτήσεων κατακερματισμού σχεδιασμένες για χρήση στην κρυπτογραφία. Αποτελούν μαθηματικές συναρτήσεις που δέχονται ως είσοδο δεδομένα τυχαίου μεγέθους και επιστρέφουν συμβολοσειρές σταθερού μήκους. +Οι κρυπτογραφικές συναρτήσεις κατακερματισμού (cryptographic hash functions) είναι ειδική κατηγορία συναρτήσεων κατακερματισμού σχεδιασμένες για χρήση στην κρυπτογραφία. Αποτελούν μαθηματικές συναρτήσεις που δέχονται ως είσοδο δεδομένα τυχαίου μεγέθους και επιστρέφουν συμβολοσειρές σταθερού μήκους. -% TODO: insert diagram +\begin{figure}[H] + \centering + \includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.1.hash-functions-1.png} + \caption{Λειτουργία συνάρτησης κατακερματισμού} +\end{figure} Οι τιμές που επιστρέφει η συνάρτηση κατακερματισμού ονομάζονται τιμές κατακερματισμού (hash values, digests ή απλά hashes). Μία ιδανική κρυπτογραφική συνάρτηση κατακερματισμού έχει τις εξής βασικές ιδιότητες: @@ -13,4 +17,10 @@ \item Είναι αποδοτική, δηλαδή ο υπολογισμός του hash οποιασδήποτε εισόδου είναι γρήγορος. \end{itemize} -% TODO: insert diagram +\begin{figure}[H] + \centering + \includegraphics[width=.95\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. \ No newline at end of file diff --git a/chapters/2.theoretical-background/2.2.asymmetric-cryptography.tex b/chapters/2.theoretical-background/2.2.asymmetric-cryptography.tex index 8dbd234..4500acb 100644 --- a/chapters/2.theoretical-background/2.2.asymmetric-cryptography.tex +++ b/chapters/2.theoretical-background/2.2.asymmetric-cryptography.tex @@ -1,17 +1,17 @@ -\section{Ασύμμετρη κρυπτογραφία} +\section{Ασύμμετρη κρυπτογραφία} \label{section:2-2-asymmetric-cryptography} -Η \textbf{ασύμμετρη κρυπτογραφία} (asymmetric cryptography) ή κρυπτογραφία δημόσιου κλειδιού (public-key cryptography) αποτελεί κρυπτογραφικό σύστημα που βασίζεται στη χρήση ενός ζεύγους κλειδιών (key pair), του \textit{δημόσιου} (public key) και του \textit{ιδιωτικού} (private key). Αυτά τα κλειδιά είναι μαθηματικά συνδεδεμένα ως εξής: +Η ασύμμετρη κρυπτογραφία (asymmetric cryptography) ή κρυπτογραφία δημόσιου κλειδιού (public-key cryptography) αποτελεί κρυπτογραφικό σύστημα που βασίζεται στη χρήση ενός ζεύγους κλειδιών (key pair), του \textit{δημόσιου} (public key) και του \textit{ιδιωτικού} (private key). Αυτά τα κλειδιά είναι μαθηματικά συνδεδεμένα ως εξής: \begin{itemize} \item Το ιδιωτικό κλειδί δε μπορεί να προκύψει γνωρίζοντας το δημόσιό του \item Ό,τι κρυπτογραφηθεί από το ένα μπορεί να αποκρυπτογραφηθεί μόνο από το άλλο \end{itemize} -Η δημιουργία ενός ζεύγους κλειδιών επιτυγχάνεται μέσω μιας \textit{γεννήτριας κλειδιών} (key generation function), η οποία χρησιμοποιεί ειδικούς αλγορίθμους (π.χ. RSA), δεχόμενη ως είσοδο έναν τυχαίο αριθμό. Από τα παραχθέντα κλειδιά, το δημόσιο γνωστοποιείται σε τρίτους, ενώ το ιδιωτικό παραμένει μυστικό. +Η δημιουργία ενός ζεύγους κλειδιών επιτυγχάνεται μέσω μιας \textit{γεννήτριας κλειδιών} (\textenglish{key generation function}), η οποία χρησιμοποιεί ειδικούς αλγορίθμους (π.χ. RSA), δεχόμενη ως είσοδο έναν τυχαίο αριθμό. Από τα παραχθέντα κλειδιά, το δημόσιο γνωστοποιείται σε τρίτους, ενώ το ιδιωτικό παραμένει μυστικό. \begin{figure}[H] \centering - \includegraphics[width=15cm]{assets/figures/asymmetric-key-generation.png} + \includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.2.asymmetric-key-generation.png} \caption{Παραγωγή ασύμμετρου ζεύγους κλειδιών} \end{figure} @@ -30,7 +30,8 @@ \begin{figure}[H] \centering - \includegraphics[width=15cm]{assets/figures/asymmetric-end-to-end-communication.png} + \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} \ No newline at end of file diff --git a/chapters/2.theoretical-background/2.3.merkle-trees.tex b/chapters/2.theoretical-background/2.3.merkle-trees.tex index e7a8475..d6091b4 100644 --- a/chapters/2.theoretical-background/2.3.merkle-trees.tex +++ b/chapters/2.theoretical-background/2.3.merkle-trees.tex @@ -1,10 +1,14 @@ -\section{Δένδρα Merkle} +\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}. +Ένα δένδρο 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 κόμβο, και είναι αυτό που αναλύεται στη συνέχεια. -%TODO create and add image of a binary hash tree like: https://en.wikipedia.org/wiki/File:Hash_Tree.svg +\begin{figure}[H] + \centering + \includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.3.merkle-tree.png} + \caption{Παράδειγμα δυαδικού δένδρου Merkle} +\end{figure} Τα Merkle trees επιτρέπουν την αποδοτική και ασφαλή επαλήθευση των περιεχομένων που ανήκουν σε σετ δεδομένων μεγάλου μεγέθους. Η βασική ιδιότητα είναι ότι για κάθε σετ δεδομένων υπάρχει ακριβώς ένα πιθανό δένδρο, το οποίο δε γίνεται να τροποποιηθεί χωρίς να αλλάξει ταυτόχρονα και το root hash. @@ -12,5 +16,5 @@ \begin{itemize} \item Να αποφανθούμε εάν κάποια δεδομένα ανήκουν στο δένδρο (με τον αριθμό των hashes που θα πρέπει να υπολογιστούν να είναι ανάλογος του λογαρίθμου του αριθμού των leaf nodes). \item Να αποδείξουμε συνοπτικά την εγκυρότητα ενός τμήματος κάποιου σετ δεδομένων, χωρίς να χρειαστεί να αποθηκεύσουμε ολόκληρο το σύνολο δεδομένων. - \item Να διασφαλίσουμε την εγκυρότητα ενός συγκεκριμένου συνόλου δεδομένων εντός ενός μεγαλύτερου σύνολου, χωρίς να χρειαστεί να αποκαλυφθεί το περιεχόμενο οποιουδήποτε εκ των δύο\cite{2.3-merkle-proofs-explained}. + \item Να διασφαλίσουμε την εγκυρότητα ενός συγκεκριμένου συνόλου δεδομένων εντός ενός μεγαλύτερου σύνολου, χωρίς να χρειαστεί να αποκαλυφθεί το περιεχόμενο οποιουδήποτε εκ των δύο.\cite{2.3-merkle-proofs-explained} \end{itemize} diff --git a/chapters/2.theoretical-background/2.4.p2p-networks.tex b/chapters/2.theoretical-background/2.4.p2p-networks.tex index cb96cc0..aa6610e 100644 --- a/chapters/2.theoretical-background/2.4.p2p-networks.tex +++ b/chapters/2.theoretical-background/2.4.p2p-networks.tex @@ -1,4 +1,4 @@ -\section{Δίκτυα Ομότιμων Κόμβων} +\section{Δίκτυα Ομότιμων Κόμβων} \label{section:2-4-p2p-networks} Τα δίκτυα ομότιμων κόμβων ή Peer-to-Peer (P2P) networks αποτελούν μία κατανεμημένη αρχιτεκτονική δικτύων, οι συμμετέχοντες (κόμβοι) της οποίας μοιράζονται ένα τμήμα των πόρων τους, με στόχο την παροχή κάποιας υπηρεσίας (π.χ. τον διαμοιρασμό περιεχομένου). Εν αντιθέσει με συγκεντρωτικά δίκτυα τύπου client/server, οι κόμβοι (nodes) έχουν απευθείας πρόσβαση στους πόρους, χωρίς τη διαμεσολάβηση ενδιάμεσων οντοτήτων. Οι συμμετέχοντες ενός τέτοιου δικτύου είναι, δηλαδή, ταυτόχρονα, τόσο πάροχοι, όσο και αιτούντες των πόρων και της παρεχόμενης υπηρεσίας.\cite{2.4-p2p-networking} @@ -9,5 +9,4 @@ \item Στα "Υβριδικά" (Hybrid) P2P networks, στα οποία συμμετέχουν επιπλέον και κεντρικές οντότητες, παρέχοντας απαραίτητα τμήματα των προσφερόμενων υπηρεσιών. \end{itemize} -Από εδώ και στο εξής, εάν δεν αναφέρεται ρητά η κατηγορία κάποιου P2P network, θα εννοείται ότι ανήκει στην πρώτη. - +Από εδώ και στο εξής, εάν δεν αναφέρεται ρητά η κατηγορία κάποιου P2P network, θα εννοείται ότι ανήκει στην πρώτη. \ No newline at end of file diff --git a/chapters/2.theoretical-background/2.5.blockchain.tex b/chapters/2.theoretical-background/2.5.blockchain.tex index 3ffe821..2c3ac00 100644 --- a/chapters/2.theoretical-background/2.5.blockchain.tex +++ b/chapters/2.theoretical-background/2.5.blockchain.tex @@ -1,4 +1,4 @@ -\section{Blockchain} +\section{Blockchain} \label{section:2-5-blockchain} Το blockchain αποτελεί μία διανεμημένη δημόσια σειρά δεδομένων, που διατηρεί έναν αμετάβλητο ως προς το ιστορικό του κατάλογο (immutable ledger) ψηφιακών συναλλαγών (digital transactions) ενός αγαθού (asset), π.χ. ενός νομίσματος (token). Περιγράφηκε για πρώτη φορά το 2008 από ένα άτομο (ή μία ομάδα ανθρώπων) γνωστό ως Satoshi Nakamoto, αποτελώντας τη βάση του κρυπτονομίσματος (cryptocurrency) Bitcoin.\cite{2.5-bitcoin} @@ -6,10 +6,12 @@ %TODO: add image like https://cdn.hackernoon.com/hn-images/1*qYKsqQ6aV-DgFD0REfcnig.png or https://ethereum.org/static/6f7d50fd4fab9f8abb94b5e610ade7e4/bf8c1/ethereum-blocks.png --- add that this is simplified -Ως προς την κυριότητα επί αυτού, το blockchain συνήθως\footnote{Υπάρχουν και κάποιες υλοποιήσεις ιδιωτικών blockchain που, όμως, δε θα μας απασχολήσουν.} δεν ελέγχεται από κάποια κεντρική οντότητα, αλλά διατηρείται από ένα δημόσιο P2P δίκτυο. Οι κόμβοι (nodes) του δικτύου συμμορφώνονται συλλογικά με ένα πρωτόκολλο συναίνεσης (consensus) για την επικοινωνία και την επικύρωση νέων μπλοκ. Για παράδειγμα, στο Bitcoin, το consensus επιτυγχάνεται μέσω ενός Proof of Work (PoW) αλγορίθμου, όπου οι κόμβοι (miners) ανταγωνίζονται ο ένας τον άλλον για το ποιος θα λύσει πρώτος ένα σύνθετο αλγοριθμικό πρόβλημα που συσχετίζεται με το εκάστοτε block. Αυτός που θα τα καταφέρει επιβραβεύεται για την επεξεργαστική ισχύ που δαπάνησε με ένα ποσό από bitcoin. Εκείνα είναι εν μέρει νέα νομίσματα που κόβονται ή "εξορύσσονται" εκείνη τη στιγμή (όπως ορίζεται από το πρωτόκολλο), αλλά και όσα τέλη (fees) κατέβαλαν οι κόμβοι για να πραγματοποιήσουν τις συναλλαγές του μπλοκ. Αξίζει να σημειωθεί πως δεν είναι αναγκαίο να διαθέτει κανείς ολόκληρο το blockchain (το οποίο είναι ογκώδες) - δηλαδή έναν πλήρη κόμβο - για να επικοινωνήσει με το δίκτυο, αλλά αρκεί ένας light node που απλά αναμεταδίδει την συναλλαγή που επιθυμεί να πραγματοποιήσει ο χρήστης. +Ως προς την κυριότητα επί αυτού, το blockchain συνήθως\footnote{Υπάρχουν και κάποιες υλοποιήσεις ιδιωτικών blockchain που, όμως, δε θα μας απασχολήσουν.} δεν ελέγχεται από κάποια κεντρική οντότητα, αλλά διατηρείται από ένα δημόσιο P2P δίκτυο. Οι κόμβοι (nodes) του δικτύου συμμορφώνονται συλλογικά με ένα πρωτόκολλο συναίνεσης (consensus) για την επικοινωνία και την επικύρωση νέων μπλοκ. Για παράδειγμα, στο Bitcoin, το consensus επιτυγχάνεται μέσω ενός Proof of Work (PoW) αλγορίθμου, όπου οι κόμβοι (miners) ανταγωνίζονται ο ένας τον άλλον για το ποιος θα λύσει πρώτος ένα σύνθετο αλγοριθμικό πρόβλημα που συσχετίζεται με το εκάστοτε block. Αυτός που θα τα καταφέρει επιβραβεύεται για την επεξεργαστική ισχύ που δαπάνησε με ένα ποσό από bitcoin. Εκείνα είναι εν μέρει νέα νομίσματα που κόβονται ή "εξορύσσονται" εκείνη τη στιγμή (όπως ορίζεται από το πρωτόκολλο), αλλά και όσα τέλη (fees) κατέβαλαν οι κόμβοι για να πραγματοποιήσουν τις συναλλαγές του μπλοκ. Αξίζει να σημειωθεί πως δεν είναι αναγκαίο να διαθέτει κανείς ολόκληρο το blockchain (το οποίο είναι ογκώδες) - δηλαδή έναν πλήρη κόμβο - για να επικοινωνήσει με το δίκτυο, αλλά αρκεί ένας light node που απλά αναμεταδίδει την συναλλαγή που επιθυμεί να πραγματοποιήσει ο χρήστης. Η διευθυνσιοδότηση σε ένα blockchain επιτυγχάνεται αξιοποιώντας την κρυπτογραφία δημόσιου κλειδιού. Το πρωτόκολλο του εκάστοτε blockchain ορίζει έναν αλγόριθμο για την παραγωγή ζευγών κλειδιών (π.χ. ECDSA στο Bitcoin). Το δημόσιο από αυτά ορίζει τη διεύθυνση, ενώ το ιδιωτικό παραμένει μυστικό, υπό την κατοχή του χρήστη. Με αυτό τον τρόπο προκύπτει ένα πρακτικά ανεξάντλητο πλήθος πιθανών έγκυρων δημόσιων διευθύνσεων (π.χ. $2^{160}$ για το Bitcoin), στις οποίες οι χρήστες μπορούν να στέλνουν και να λαμβάνουν ποσά του εκάστοτε κρυπτονομίσματος. Για την αποστολή ενός ποσού, δηλώνουν το fee που επιθυμούν να καταβάλουν και υπογράφουν την επιθυμητή συναλλαγή με το ιδιωτικό τους κλειδί. Η συναλλαγή αναμεταδίδεται στο δίκτυο και παραμένει στο transaction pool μέχρις ότου να γίνει αποδεκτή και να συμπεριληφθεί στο επόμενο block. Από τεχνική σκοπιά, το blockchain μπορεί να θεωρηθεί ως μία μηχανή καταστάσεων βασισμένη σε συναλλαγές (transaction-based state machine). Δηλαδή, ξεκινάει από μία αρχική κατάσταση (genesis state), η οποία τροποποιείται σταδιακά με κάθε block, και περιλαμβάνει ανά πάσα στιγμή τις διευθύνσεις με τα ποσά των νομισμάτων που τις αντιστοιχούν. -%TODO: add image like ethereum-evm-illustrated page 9 or https://ethereum.org/static/0aeff9bcdfb1f5fd002610b4a5cff197/460fa/ethereum-state-transition.png \ No newline at end of file +%TODO: add image like ethereum-evm-illustrated page 9 or https://ethereum.org/static/0aeff9bcdfb1f5fd002610b4a5cff197/460fa/ethereum-state-transition.png + +Σύμφωνα με την ανάλυση της ενότητας \ref{section:1-2-decentralization}, το blockchain είναι αρχιτεκτονικά και πολιτικά αποκεντρωτικό, καθώς δεν διαθέτει δοκιμκά κάποιο κεντρικό σημείο αποτυχίας, ούτε ελέγχεται από κάποιον. Ωστόσο, είναι λογικά συγκεντρωτικό, αφού υπάρχει μία κοινά αποδεκτή κατάσταση και το σύστημα συμπεριφέρεται μακροσκοπικά ως ένας ενιαίος υπολογιστής. diff --git a/chapters/2.theoretical-background/2.6.ethereum.tex b/chapters/2.theoretical-background/2.6.ethereum.tex index 68bbe99..aa2131c 100644 --- a/chapters/2.theoretical-background/2.6.ethereum.tex +++ b/chapters/2.theoretical-background/2.6.ethereum.tex @@ -1,38 +1,103 @@ -\section{Ethereum} +\section{Ethereum} \label{section:2-6-ethereum} -\begin{figure}[H] - \centering - \includegraphics[width=2cm]{assets/figures/ethereum-logo.png} - \caption{Ethereum logo} -\end{figure} +\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{Smart Contracts \& DApps} -Με απλά λόγια, τα smart contracts αποτελούν αυτόνομα κομμάτια κώδικα τα οποία είναι αποθηκευμένα στο blockchain και ενεργοποιούνται μέσω συναλλαγών. Μπορούν να διαβάζουν και να γράφουν δεδομένα επί του blockchain, κληρονομώντας ιδιότητες όπως τη διαφάνεια (transparency), την εγκυρότητα (validability) και την αμεταβλητότητα (immutability). +\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). -Ένα παράδειγμα της καθημερινότητας που μπορεί να παρομοιασθεί λειτουργικά με smart contract είναι ο αυτόματος πωλητής\cite{2.6-ethereum-smart-contracts}. Ένας αυτόματος πωλητής ορίζεται ως ένα αυτόνομο μηχάνημα που διανέμει αγαθά ή παρέχει υπηρεσίες όταν εισάγονται σε αυτόν κέρματα ή κάποια ηλεκτρονική πληρωμή. Οι αυτόματοι πωλητές είναι προγραμματισμένοι να εκτελούν συγκεκριμένους κανόνες που θα μπορούσαν να οριστούν σε ένα συμβόλαιο. +Οι λογαριασμοί εξωτερικής κατοχής δημιουργούνται χωρίς κόστος και ελέγχονται μέσω ιδιωτικών κλειδιών. Μπορούν να πραγματοποιούν μόνο συναλλαγές μεταφοράς ETH ή κάποιου token. -Με όμοιο τρόπο, σε ένα smart contract μπορούν να κωδικοποιηθούν αυθαίρετες συναρτήσεις μετάβασης, επιτρέποντας τη δημιουργία ποικίλων αποκεντρωμένων εφαρμογών. Οι εφαρμογές αυτές μπορούν να χωριστούν σε τρεις κατηγορίες: +Από την άλλη, οι λογαριασμοί συμβολαίων απαιτούν κάποιο κόστος δημιουργίας, καθώς χρησιμοποιούν αποθηκευτικό χώρο επί του 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. Πριν την εγγραφή τους στο 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 Οικονομικές εφαρμογές, οι οποίες παρέχουν στους χρήστες ισχυρότερους τρόπους διαχείρισης και σύναψης συμβάσεων χρησιμοποιώντας τα χρήματά τους. Αυτό περιλαμβάνει υπο-νομίσματα, χρηματοοικονομικά παράγωγα, συμβάσεις αντιστάθμισης κινδύνου, πορτοφόλια αποταμίευσης, διαθήκες, και, τελικά, ακόμη και ορισμένες κατηγορίες συμβάσεων εργασίας πλήρους κλίμακας. + \item Δυσκολία συντήρησης: Συντηρούνται δυσκολότερα από τις συγκεντρωτικές εφαρμογές, εξαιτίας της αμεταβλητότητας του κώδικα και των δεδομένων επί του blockchain. + \item Επιβάρυνση απόδοσης: Υπάρχει τεράστια επιβάρυνση απόδοσης (performance overhead) και η κλιμάκωση (scaling) είναι πολύ δύσκολη, καθώς απαιτείται όλοι οι κόμβοι να εκτελούν και να αποθηκεύουν όλες τις συναλλαγές. + \item Συμφόρηση δικτύου: Επί του παρόντος, το δίκτυο μπορεί να επεξεργαστεί μόνο περίπου 10-15 συναλλαγές ανά δευτερόλεπτο. Εάν οι συναλλαγές αποστέλλονται με ταχύτερο ρυθμό από αυτόν, θα αυξάνονται παράλληλα και οι μη επιβεβαιωμένες συναλλαγές που αναμένουν να εκτελεστούν. + \item Κακή εμπειρία χρήστη: Επί του παρόντος, είναι δύσκολο για τον μέσο τελικό χρήστη να αλληλεπιδράσει με το blockchain με ευκολία και ασφάλεια, καθώς απαιτούνται ενέργειες όπως η εγκατάσταση ειδικών εργαλείων για τη διασύνδεση με αυτό, η δημιουργία wallet, η διαφύλαξη του ιδιωτικού του κλειδιού και η προσθήκη ETH για την εξόφληση των τελών. +\end{itemize} + +Παρ' όλα τα μειονεκτήματα, τα οποία μετριάζονται με τον καιρό μέσω συνεχών αναβαθμίσεων της πλατφόρμας, υπάρχει ήδη ένα ευρύ φάσμα εφαρμογών που μπορούν να υλοποιηθούν στο Ethereum, αξιοποιώντας τα ισχυρά του πλεονεκτήματα. Οι εφαρμογές αυτές μπορούν να διακριθούν σε τρεις κατηγορίες: +\begin{enumerate} + \item Οικονομικές εφαρμογές, οι οποίες παρέχουν στους χρήστες ισχυρούς τρόπους διαχείρισης και σύναψης συμβάσεων χρησιμοποιώντας τα χρήματά τους. Αυτό περιλαμβάνει υπονομίσματα, χρηματοοικονομικά παράγωγα, συμβάσεις αντιστάθμισης κινδύνου, πορτοφόλια αποταμίευσης, διαθήκες και ακόμα και ορισμένες κατηγορίες συμβάσεων εργασίας πλήρους κλίμακας. - \item Ημι-οικονομικές εφαρμογές, όπου εμπλέκονται χρήματα, αλλά η λειτουργία τους εμπεριέχει παράλληλα και μία αξιοσημείωτη μη νομισματική πλευρά. Ένα τέτοιο παράδειγμα είναι οι αυτόματες πληρωμές για λύσεις σε υπολογιστικά προβλήματα (βλ. Gitcoin). + \item Ημι-οικονομικές εφαρμογές, όπου εμπλέκονται χρήματα, αλλά η λειτουργία τους εμπεριέχει παράλληλα και μία αξιοσημείωτη μη νομισματική πλευρά. Ένα τέτοιο παράδειγμα είναι οι αυτόματες πληρωμές για λύσεις σε υπολογιστικά προβλήματα (βλ. Gitcoin). - \item Μη οικονομικές εφαρμογές, όπως η αποκεντρωμένη αποθήκευση δεδομένων, συστήματα ταυτότητας (identity) και φήμης (reputation), διαδικτυακές ψηφοφορίες και αποκεντρωμένη διακυβέρνηση. Οι τελευταίες εισάγουν και την έννοια των Αποκεντρωμένων Αυτόνομων Οργανώσεων (Decentralized Autonomous Organizations ή DAOs), οντοτήτων που ενεργούν αυτόνομα, χωρίς την ανάγκη διαμεσολάβησης κάποιας συγκεντρωτικής (centralized) αρχής.\cite{2.6-ethereum-whitepaper} + \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} -\subsection{EVM} -Τα smart contracts εκτελούνται από την εικονική μηχανή του Ethereum (Ethereum Virtual Machine ή EVM). Η EVM αποτελεί μία quasi\footnote{"quasi" επειδή όλες οι διαδικασίες εκτέλεσης περιορίζονται σε έναν πεπερασμένο αριθμό υπολογιστικών βημάτων από την ποσότητα gas που είναι διαθέσιμη για οποιαδήποτε εκτέλεση ενός smart contract.}–Turing-complete μηχανή καταστάσεων αρχιτεκτονικής βασισμένης σε στοίβα (stack-based architecture). Σε υψηλό επίπεδο, η EVM μπορεί να θεωρηθεί ως ένας παγκόσμιος αποκεντρωμένος υπολογιστής που περιέχει εκατομμύρια εκτελέσιμα αντικείμενα, το καθένα με τη δική του μόνιμη αποθήκη δεδομένων. +Ένα σημαντικό κριτήριο κατηγοριοποίησης των 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, φορτωμένο με τον bytecode του smart contract προς εκτέλεση. + \item Έναν αμετάβλητο κώδικα προγράμματος σε εικονική μνήμη ROM, φορτωμένο με τον \textenglish{bytecode} του smart contract προς εκτέλεση. \item Μία πτητική (volatile) μνήμη, με κάθε θέση ρητά αρχικοποιημένη στο μηδέν. \item Ένας χώρος μόνιμης αποθήκευσης, που είναι μέρος του Ethereum state, επίσης αρχικά μηδενισμένος. \end{itemize} -Υπάρχει, επίσης, ένα σύνολο μεταβλητών περιβάλλοντος και δεδομένων, που είναι διαθέσιμα κατά την εκτέλεση.\cite{2.6-ethereum-mastering} - -% TODO: Add account types, addressing, token types, fees,... +Υπάρχει, επίσης, ένα σύνολο μεταβλητών περιβάλλοντος και δεδομένων, τα οποία είναι διαθέσιμα κατά την εκτέλεση.\cite{2.6-ethereum-mastering} diff --git a/chapters/2.theoretical-background/2.7.ipfs.tex b/chapters/2.theoretical-background/2.7.ipfs.tex index 0e79694..fdca289 100644 --- a/chapters/2.theoretical-background/2.7.ipfs.tex +++ b/chapters/2.theoretical-background/2.7.ipfs.tex @@ -1,10 +1,6 @@ -\section{IPFS} +\section{IPFS} \label{section:2-7-ipfs} -\begin{figure}[H] - \centering - \includegraphics[width=2cm]{assets/figures/ipfs-logo.png} - \caption{IPFS logo} -\end{figure} +\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} @@ -14,13 +10,14 @@ \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{figure}[H] - \centering - \includegraphics[width=15cm]{assets/figures/merkle-dag.png} + + \begin{enumitemcenteredfigure} + \includegraphics[width=.95\textwidth]{assets/figures/chapter-2/2.7.merkle-dag.png} \caption{Merkle DAG\cite{2.7-merkle-dags-proto-school}} - \end{figure} + \end{enumitemcenteredfigure} + Στο παραπάνω Merkle DAG τα baf...i αποτελούν τα CID των αρχείων και των φακέλων. Το δένδρο δημιουργείται από κάτω προς τα πάνω, υπολογίζοντας κάθε φορά τα κατάλληλα hashes/CIDs. Σε περίπτωση που το περιεχόμενο ενός κόμβου αλλάξει, τότε αλλάζει τόσο το CID του, όσο και τα CIDs όλων των προγόνων του. - \item \textbf{Ανακάλυψη περιεχομένου μέσω κατανεμημένων πινάκων κατακερματισμού (Distributed Hash Tables ή DHTs)}. Ο DHT είναι ένα κατανεμημένο σύστημα για την αντιστοίχιση κλειδιών σε τιμές. Στο IPFS αποτελεί το θεμελιώδες συστατικό του συστήματος δρομολόγησης περιεχομένου και λειτουργεί ως διασταύρωση μεταξύ καταλόγου και συστήματος πλοήγησης. Πρακτικά πρόκειται για ένα πίνακα που αποθηκεύει ποιος έχει ποια δεδομένα και, μέσω του οποίου, ο χρήστης βρίσκει τον peer που έχει αποθηκευμένο το επιθυμητό περιεχόμενο. + \item \textbf{Ανακάλυψη περιεχομένου μέσω κατανεμημένων πινάκων κατακερματισμού (\textenglish{Distributed Hash Tables ή DHTs})}. Ο DHT είναι ένα κατανεμημένο σύστημα για την αντιστοίχιση κλειδιών σε τιμές. Στο IPFS αποτελεί το θεμελιώδες συστατικό του συστήματος δρομολόγησης περιεχομένου και λειτουργεί ως διασταύρωση μεταξύ καταλόγου και συστήματος πλοήγησης. Πρακτικά πρόκειται για ένα πίνακα που αποθηκεύει ποιος έχει ποια δεδομένα και, μέσω του οποίου, ο χρήστης βρίσκει τον peer που έχει αποθηκευμένο το επιθυμητό περιεχόμενο. \end{itemize} Κάτι που θα πρέπει να σημειωθεί είναι πως, σαν προεπιλογή, οι IPFS κόμβοι αντιμετωπίζουν τα αποθηκευμένα δεδομένα ως προσωρινή μνήμη (cache), πράγμα που σημαίνει ότι δεν υπάρχει καμία εγγύηση ότι εκείνα θα συνεχίσουν να παραμένουν αποθηκευμένα σε αυτούς. Για την αποφυγή της διαγραφής τους από τον garbage collector, τα δεδομένα θα πρέπει να σημανθούν ως σημαντικά, μέσω του "καρφιτσώματος" (pinning). Έτσι, για την ομαλή λειτουργία π.χ. μίας DApp που βασίζεται στο IPFS, θα πρέπει το περιεχόμενό της να είναι pinned από αρκετούς peers και/ή να γίνεται χρήση κάποιου pinning service, ώστε να εξασφαλίζεται διαθεσιμότητά του. diff --git a/chapters/3.application-design/3.0.application-design.tex b/chapters/3.application-design/3.0.application-design.tex index 4a4560c..99d3dcd 100644 --- a/chapters/3.application-design/3.0.application-design.tex +++ b/chapters/3.application-design/3.0.application-design.tex @@ -1,8 +1,10 @@ -\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} +\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} diff --git a/chapters/3.application-design/3.1.application-parts.tex b/chapters/3.application-design/3.1.application-parts.tex deleted file mode 100644 index 371db99..0000000 --- a/chapters/3.application-design/3.1.application-parts.tex +++ /dev/null @@ -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 τους. diff --git a/chapters/3.application-design/3.1.idea-conception.tex b/chapters/3.application-design/3.1.idea-conception.tex new file mode 100644 index 0000000..f8f08d3 --- /dev/null +++ b/chapters/3.application-design/3.1.idea-conception.tex @@ -0,0 +1,11 @@ +\section{Σύλληψη της ιδέας} \label{section:3-1-idea-conception} + +Η σύλληψη της ιδέας για τη δημιουργία της εφαρμογής της παρούσας διπλωματικής εργασίας είχε ως εφαλτήριο την αναγνώριση ενός διδιάστατου προβλήματος. + +Η πρώτη διάσταση εστιάζει στον χώρο των μέσων κοινωνικής δικτύωσης. Εκεί παρατηρείται αδιαμφισβήτη επικράτηση πλατφορμών επικοινωνίας συγκεντρωτικής μορφής (π.χ. Facebook, Twitter, Instagram), ενώ προσπάθειες δηιουργίας αντίστοιχων αποκεντρωτικών εφαρμογών βρίσκονται σε πρώιμα στάδια, τόσο ανάπτυξης, όσο και υιοθέτησης από το ευρύ κοινό. Όπως αναλύθηκε και στην ενότητα \ref{section:1-3-problem-definition}, η τρέχουσα αυτή κατάσταση θέτει αξιοσημείωτα προβλήματα τεχνικής φύσεως (έλλεψη ασφάλειας και διαθεσιμότητας) και, κυρίως, πολιτικής (έλλειψη εμπιστοσύνης, εγγύησης της αυθεντικότητας των δεδομένων και της ελευθερίας του λόγου). + +Η δεύτερη διάσταση εστιάζει στον χώρο της ψηφιακής δημοκρατίας (digital democracy). Συγκεκριμένα, παρατηρείται έλλειψη εργαλείων, ικανών να παρέχουν τη δυνατότητα διενέργειας αυθεντικών δημοκρατικών διαδικασιών. Ψηφοφορίες και αυτοδιαχείριση εντός συστημάτων κεντροποιημένης λογικής αδυνατούν, για αρχιτεκτονικούς λόγους, να εξασφαλίσουν τις απαραίτητες θεμελιώδεις ιδιότητες τέτοιων διαδικασιών, δηλαδή της ανωνυμίας και της επαληθευσιμότητας. + +Βάσει των παραπάνω, γεννήθηκε η ιδέα δημιουργίας μίας εφαρμογής, η οποία, μέσω ενός προτεινόμενου συνδυασμού αποκεντρωτικών τεχνολογιών, να ορίσει έναν ψηφιακό χώρο που θα έρθει αντιμέτωπος με τα παραπάνω. Έτσι, κεντρικός στόχος της πιλοτικής εφαρμογής Concordia, είναι να αποτελέσει μία αυτόνομη κοινωνική πλατφόρμα, που θα κατοχυρώνει στους χρήστες της ελευθερία του λόγου και πλήρη κυριότητα επί των δεδομένων τους. Επιπλέον, θα παρέχει τη δυνατότητα διενέργειας αυθεντικών, ανώνυμων ψηφοφοριών, κάτι που θα την καθιστά ένα αξιόπιστο δημοκρατικό βήμα για τη λήψη αποφάσεων εντός αυτοδιαχειριζόμενων κοινοτήτων της. + +\newpage \ No newline at end of file diff --git a/chapters/3.application-design/3.2.technology-stack.tex b/chapters/3.application-design/3.2.technology-stack.tex new file mode 100644 index 0000000..8202535 --- /dev/null +++ b/chapters/3.application-design/3.2.technology-stack.tex @@ -0,0 +1,20 @@ +\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/JS. + + \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} + +Τελικά, με τη διασύνδεση των προαναφερθέντων τεχνολογιών, προκύπτει σχηματικά η ακόλουθη διάταξη: + +% TODO: Create proper diagram +\begin{figure}[H] + \centering + \includegraphics[width=.75\textwidth]{assets/figures/chapter-3/3.2.technology.stack} + \caption{Τεχνολογική στοίβα} +\end{figure} diff --git a/chapters/3.application-design/3.2.user-categories.tex b/chapters/3.application-design/3.2.user-categories.tex deleted file mode 100644 index 06ed76d..0000000 --- a/chapters/3.application-design/3.2.user-categories.tex +++ /dev/null @@ -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 diff --git a/chapters/3.application-design/3.3.design-methodology.tex b/chapters/3.application-design/3.3.design-methodology.tex new file mode 100644 index 0000000..bc4eab4 --- /dev/null +++ b/chapters/3.application-design/3.3.design-methodology.tex @@ -0,0 +1,3 @@ +\section{Μεθολογία σχεδίασης} \label{section:3-3.design-methodology} + +% TODO: add Agile stuff etc \ No newline at end of file diff --git a/chapters/3.application-design/3.3.use-cases.tex b/chapters/3.application-design/3.3.use-cases.tex deleted file mode 100644 index c1e3ed1..0000000 --- a/chapters/3.application-design/3.3.use-cases.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Σενάρια χρήσης} diff --git a/chapters/3.application-design/3.4.technology-stack.tex b/chapters/3.application-design/3.4.technology-stack.tex deleted file mode 100644 index 55173a4..0000000 --- a/chapters/3.application-design/3.4.technology-stack.tex +++ /dev/null @@ -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 για την ανάκτηση τους, πράγμα που σημαίνει ότι θα πρέπει να γίνει παροχή υποδομής από τους χρήστες ικανής να υποστηρίξει έναν ελάχιστο αριθμό κόμβων αποθήκευσης. - -Πρόκειται για συμπληρωματικές τεχνολογίες στις παραπάνω που στόχο έχουν την οργάνωση των αποθηκευμένων πληροφοριών σε μορφή βάσεων δεδομένων. diff --git a/chapters/3.application-design/3.4.user-categories.tex b/chapters/3.application-design/3.4.user-categories.tex new file mode 100644 index 0000000..d5b6731 --- /dev/null +++ b/chapters/3.application-design/3.4.user-categories.tex @@ -0,0 +1,48 @@ +\section{Κατηγορίες χρηστών} \label{section:3-4-user-categories} + +Οι χρήστες (actors) της πλατφόρμας χωρίζονται σε πρωτεύοντες ή ενεργούς και δευτερεύοντες ή παθητικούς. Πρωτεύοντες χρήστες είναι εκείνοι που εκκινούν διεργασίες στο σύστημα. Δευτερεύοντες είναι οι χρήστες με τους οποίους αλληλεπιδρά το σύστημα, αλλά οι ίδιοι δεν εκκινούν διεργασίες σε αυτό. Συνολικά οι χρήστες που συμμετέχουν στο σύστημα είναι οι: + +\begin{itemize} + \item Επισκέπτες + \item Εγγεγραμμένα μέλη + \item Δημιουργοί κοινοτήτων %TODO: Έχει νόημα σαν ρόλος ή μπορεί να είναι απλά "εγγεγραμμένο μέλος"; + \item Συμβόλαια κοινοτήτων +\end{itemize} + +\subsection{Ενεργοί χρήστες} + +Οι ενεργοί χρήστες στο σύστημα είναι οι επισκέπτες, τα εγγεγραμμένα μέλη και οι δημιουργοί κοινοτήτων. + +Όλοι οι χρήστες στο σύστημα είναι αρχικά επισκέπτες. Οι επισκέπτες έχουν τη δυνατότητα να βλέπουν το περιεχόμενο της κοινότητας, αλλά δε μπορούν να συμμετέχουν δημιουργώντας νέο περιεχόμενο (δημοσιεύοντας νέα θέματα ή μηνύματα). Επίσης, δε μπορούν να συμμετέχουν στις ψηφοφορίες της κοινότητας ή να ψηφίσουν τα μηνύματα. + +Όταν ένας επισκέπτης εγγράφεται στο σύστημα, αποκτά έναν μοναδικό, αύξοντα αριθμό χρήστη και αποτελεί πλέον εγγεγραμμένο μέλος της κοινότητας. Τα εγγεγραμμένα μέλη έχουν τα δικαιώματα των επισκεπτών και μπορούν επιπλέον να προσθέσουν περιεχόμενο στην πλατφόρμα μέσω της δημιουργίας νέων θεμάτων, της δημοσίευσης μηνυμάτων και της ψήφισης στις ψηφοφορίες στις οποίες έχουν δικαίωμα. + +Οι δημιουργοί κοινοτήτων είναι οι χρήστες οι οποίοι χρησιμοποιούν την δυνατότητα του συστήματος να δημιουργήσει κοινότητες, τα μέλη των οποίων διαφοροποιούνται βάσει ενός εξωτερικού token. Το token που ορίζει τα μέλη μίας κοινότητας προέρχεται από ένα έξυπνο συμβόλαιο το οποίο ορίζεται κατά τη δημιουργία της κοινότητας. Οι δημιουργοί κοινοτήτων πρέπει να είναι εγγεγραμμένα μέλη της κοινότητας. Ένας δημιουργός κοινότητας δεν έχει παραπάνω δικαιώματα από αυτά των απλών εγγεγραμμένων χρηστών. + +\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}{Κατηγορία χρήστη} &\multicolumn{9}{c}{Δικαιώματα} \\ [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] + Δημιουργοί κοινοτήτων & \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} diff --git a/chapters/3.application-design/3.5.implementation-methodology-specification.tex b/chapters/3.application-design/3.5.implementation-methodology-specification.tex deleted file mode 100644 index f4d9d5f..0000000 --- a/chapters/3.application-design/3.5.implementation-methodology-specification.tex +++ /dev/null @@ -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 θα μπορούσε να τεθεί ως στόχος η κατά το δυνατόν μείωση των τελών για τη λειτουργία της πλατφόρμας, ανεπτυγμένα χαρακτηριστικά επικοινωνίας όπως δόμηση των συζητήσεων σε κατηγορίες, προφίλ χρηστών και άλλα χαρακτηριστικά ευκολίας χρήσης. diff --git a/chapters/3.application-design/3.5.software-requirements.tex b/chapters/3.application-design/3.5.software-requirements.tex new file mode 100644 index 0000000..06b96eb --- /dev/null +++ b/chapters/3.application-design/3.5.software-requirements.tex @@ -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, το σύστημα θα πρέπει να μην επιτρέπει στον χρήστη να συνεχίσει και να προβάλει αντίστοιχο μήνυμα λάθους. Τα πεδία "Profile picture URL" και "Location" είναι προαιρετικά.} + {5}{Η απαίτηση είναι ύψιστης προτεραιότητας για τους επισκέπτες καθώς μόνο μέσω της εγγραφής μπορούν να χρησιμοποιήσουν τα υπόλοιπα χαρακτηριστικά της εφαρμογής.} + {5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για το σύστημα επειδή επηρεάζει τη λειτουργικότητά του.} + + \sysReqItem + {\label{srs:functional-srs-sign-in}} + {Ο χρήστης πρέπει να συνδέεται αυτόματα, εφόσον είναι εγγεγραμμένος.} + {Το σύστημα πρέπει να διαπιστώνει αυτόματα εάν το τρέχον Ethereum address έχει λογαριασμό στην εφαρμογή και εάν ναι, να συνδέει να τον χρήστη, ανακτώντας το Username του από το blockchain και προβάλλοντας το στο μενού.} + {5}{Η απαίτηση είναι ύψιστης προτεραιότητας για τους επισκέπτες καθώς μέσω της σύνδεσης ενεργοποιούνται τα χαρακτηριστικά της δημιουργίας θεμάτων και δημοσίευσης μηνυμάτων.} + {1}{Η σύνδεση αφορά μόνο τη γραφική διεπαφή του χρήστη με την πλατφόρμα και δεν αποτελεί στοιχείο που επιδρά στο υπόλοιπο σύστημα.} + + \sysReqItem + {\label{srs:functional-srs-create-user-databases}} + {Το σύστημα πρέπει να δημιουργεί τις βάσεις δεδομένων του χρήστη.} + {Το σύστημα πρέπει να δημιουργεί τις βάσεις δεδομένων του χρήστη, εάν αυτές δεν υπάρχουν ήδη τοπικά. Όταν ο χρήστης ξεκλειδώσει τον Ethereum λογαριασμό του, το σύστημα θα πρέπει να τον προτρέπει να υπογράψει με το ιδιωτικό του κλειδί μία συναλλαγή που θα εξασφαλίζει τη γνησιότητα των βάσεών του και των δεδομένων που αυτές θα εμπεριέχουν.} + {5}{Η απαίτηση αυτή είναι υψηλής σημασίας για τον χρήστη καθώς η δημιουργία των βάσεων είναι απαραίτητη για την διατήρηση των δεδομένων που δημοσιοποιεί.} + {5}{Η απαίτηση αυτή είναι υψηλής σημασίας για το σύστημα για τους ίδιους λόγους.} + + \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-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}{Η απαίτηση αυτή είναι μέτριας σημασίας για τους χρήστες καθώς αποτελεί ένα χρήσιμο αλλά όχι απαραίτητο χαρακτηριστικό.} + {4}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα επειδή δημιουργεί δεδομένα τα οποία είναι χρήσιμα για τον υπολογισμό της εμπιστοσύνης των χρηστών.} + + \sysReqItem + {\label{srs:functional-srs-create-polls}} + {Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί ψηφοφορίες (polls).} + {Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί ψηφοφορίες. Αυτό το επιτυγχάνει πατώντας "Add Poll" στην οθόνη δημιουργία θέματος και συμπληρώνοντας τα απαραίτητα πεδία.} + {5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για τους χρήστες καθώς οι αμεσοδημοκρατικές διαδικασίες αποτελούν μία από τις κυριότερες χρήσεις της πλατφόρμας} + {5}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα επειδή αποτελεί βασική προδιαγραφή του.} + + \sysReqItem + {\label{srs:functional-srs-vote-polls}} + {Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να ψηφίζει σε ψηφοφορίες.} + {Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να ψηφίζει σε ψηφοφορίες, σύμφωνα με τους εκάστοτε κανόνες.} + {5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για τους χρήστες καθώς αποτελεί μία από τις ---- insert same as above} + {5}{Η απαίτηση αυτή είναι υψηλής σημασίας για το σύστημα καθώς αποτελεί σημαντικό χαρακτηριστικό του.} + + \sysReqItem + {\label{srs:functional-srs-delete-local-data}} + {Ο χρήστης πρέπει να μπορεί να διαγράφει τα τοπικά δεδομένα.} + {Ο χρήστης πρέπει να μπορεί να διαγράφει τα τοπικά δεδομένα. Αυτό το επιτυγχάνει πατώντας στο κουμπί "Clear databases" του μενού και επιβεβαιώνοντας τη διαγραφή μέσω ενός pop-up διαλόγου.} + {2}{Η απαίτηση αυτή είναι χαμηλής σημασία για τους χρήστες, διότι αποτελεί απλά μία διευκόλυνση για τη διαγραφή των δεδομένων που έχουν αποθηκεύσει τοπικά.} + {3}{Η απαίτηση αυτή είναι μέτριας σημασίας για το σύστημα καθώς συνάδει με την φιλοσοφία της πλατφόρμας σχετικά με την κυριότητα των δεδομένων από τους χρήστες.} + + \sysReqItem + {\label{srs:functional-srs-create-communities}} + {Ο χρήστης πρέπει να μπορεί να δημιουργεί κοινότητες.} + {Ο χρήστης πρέπει να μπορεί να δημιουργεί κοινότητες, μέσω κουμπιού της αρχικής οθόνης.} + {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}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί απαίτηση υψίστης σημασίας για τον χρήστη, καθώς διασφαλίζει την ελευθερία του λόγου του κτλ --κεφ 1.2} + {5}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί απαίτηση υψίστης σημασίας για το σύστημα, καθώς το καθιστά ασφαλές σε επιθέσεις κτλ --κεφ 1.2} + + \sysReqItem + {\label{srs:non-functional-srs-minimize-fees}} + {Τα fees για τη χρήση του Ethereum blockchain πρέπει να ελαχιστοποιούνται.} + {Τα fees που πρέπει να καταβάλλονται για τη χρήση του Ethereum blockchain εξαρτώνται άμεσα τόσο από τον όγκο των δεδομένων προς αποθήκευση, όσο και από τους κύκλους επεξεργασίας των smart contracts της εφαρμογής. Ως προς τα δεδομένα, οι προγραμματιστές θα πρέπει να μεριμνούν ώστε ο κύριος όγκος τους να αποθηκεύεται επί του IPFS, ενώ επί του blockchain να αποθηκεύονται μόνο όσα πραγματικά χρειάζονται. Ως προς την απαιτούμενη επεξεργαστική ισχύ, πρέπει να βελτιστοποιείται ο κώδικας των smart contracts, έτσι ώστε οι διάφορες λειτουργίες τους να εκτελούνται με τους λιγότερους δυνατούς επεξεργαστικούς κύκλους.} + {4}{Η απαίτηση αυτή είναι μεγάλης σημασίας για τους χρήστες καθώς ναι μεν δεν είναι απαραίτητη για τη χρήση της αλλά είναι ιδιαίτερα σημαντική για την ένταξη χρηστών με χαμηλότερες οικονομικές δυνατότητες.} + {5}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα διότι αποτελεί σημαντικό παράγοντα που επιδρά στην προσέλκυση και διατήρηση ενεργών χρηστών.} + + \sysReqItem + {\label{srs:non-functional-srs-upgrade-contracts}} + {Τα contracts της εφαρμογής πρέπει να είναι αναβαθμίσιμα.} + {Τα contracts της εφαρμογής πρέπει μπορούν να αναβαθμιστούν, έτσι ώστε να μπορούν να προστίθενται λειτουργίες και να διορθώνονται σφάλματα. Η αναβαθμισιμότητά τους θα πρέπει να επιτυγχάνεται με μεθόδους που να μην υπονομεύουν τη λειτουργικότητα των προηγούμενων εκδόσεων.} + {2}{Η απαίτηση αυτή είναι χαμηλής σημασίας για τους χρήστες καθώς αφορά την ανάπτυξη και όχι τη χρήση της.} + {5}{Η απαίτηση αυτή είναι υψηλής σημασίας για το σύστημα επειδή προσφέρει τη δυνατότητα εξέλιξης και υλοποίησης νέων χαρακτηριστικών.} +\end{enumerate} diff --git a/chapters/3.application-design/3.6.architecture.design.tex b/chapters/3.application-design/3.6.architecture.design.tex deleted file mode 100644 index b83c6d6..0000000 --- a/chapters/3.application-design/3.6.architecture.design.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Αρχιτεκτονική} diff --git a/chapters/3.application-design/3.6.use-cases.tex b/chapters/3.application-design/3.6.use-cases.tex new file mode 100644 index 0000000..facf84c --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases.tex @@ -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} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.1.use-case-sign-up.tex b/chapters/3.application-design/3.6.use-cases/3.6.1.use-case-sign-up.tex new file mode 100644 index 0000000..e7b29d3 --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.1.use-case-sign-up.tex @@ -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}} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.10.use-case-create-community.tex b/chapters/3.application-design/3.6.use-cases/3.6.10.use-case-create-community.tex new file mode 100644 index 0000000..6e9923f --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.10.use-case-create-community.tex @@ -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}} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.2.use-case-sign-in.tex b/chapters/3.application-design/3.6.use-cases/3.6.2.use-case-sign-in.tex new file mode 100644 index 0000000..64e5b1d --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.2.use-case-sign-in.tex @@ -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} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.3.use-case-create-topic.tex b/chapters/3.application-design/3.6.use-cases/3.6.3.use-case-create-topic.tex new file mode 100644 index 0000000..45ebb3e --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.3.use-case-create-topic.tex @@ -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}} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.4.use-case-fetch-topic.tex b/chapters/3.application-design/3.6.use-cases/3.6.4.use-case-fetch-topic.tex new file mode 100644 index 0000000..bb71884 --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.4.use-case-fetch-topic.tex @@ -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-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} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.5.use-case-create-post.tex b/chapters/3.application-design/3.6.use-cases/3.6.5.use-case-create-post.tex new file mode 100644 index 0000000..f491fe4 --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.5.use-case-create-post.tex @@ -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}} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.6.use-case-modify-post.tex b/chapters/3.application-design/3.6.use-cases/3.6.6.use-case-modify-post.tex new file mode 100644 index 0000000..a492342 --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.6.use-case-modify-post.tex @@ -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}} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.7.use-case-vote-in-poll.tex b/chapters/3.application-design/3.6.use-cases/3.6.7.use-case-vote-in-poll.tex new file mode 100644 index 0000000..c6dce44 --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.7.use-case-vote-in-poll.tex @@ -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} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.8.use-case-vote-post.tex b/chapters/3.application-design/3.6.use-cases/3.6.8.use-case-vote-post.tex new file mode 100644 index 0000000..03c933f --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.8.use-case-vote-post.tex @@ -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} diff --git a/chapters/3.application-design/3.6.use-cases/3.6.9.delete-local-data.tex b/chapters/3.application-design/3.6.use-cases/3.6.9.delete-local-data.tex new file mode 100644 index 0000000..352574e --- /dev/null +++ b/chapters/3.application-design/3.6.use-cases/3.6.9.delete-local-data.tex @@ -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} diff --git a/chapters/3.application-design/3.7.architecture-design.tex b/chapters/3.application-design/3.7.architecture-design.tex new file mode 100644 index 0000000..39f2b7b --- /dev/null +++ b/chapters/3.application-design/3.7.architecture-design.tex @@ -0,0 +1,21 @@ +\section{Αρχιτεκτονική σχεδίαση} \label{section:3-7-architecture-design} + +Στο κεφάλαιο αυτό περιγράφεται η αρχιτεκτονική του συστήματος, όπως προέκυψε από την επιλεγμένη τεχνολογική στοίβα και τις προαναφερθείσες απαιτήσεις του. Θα πρέπει να σημειωθεί ότι η παρουσιαζόμενη αρχιτεκτονική είναι πρώιμη και δεν αποτελεί την τελική υλοποίηση της πλατφόρμας, η οποία περιγράφεται στο κεφάλαιο \ref{chapter:4-application-implementation}. + +Συνοπτικά, η αρχιτεκτονική του συστήματος αποτυπώνεται στο παρακάτω διάγραμμα: + +% TODO: Add proper figure +\begin{figure}[H] + \centering + \includegraphics[width=.75\textwidth]{assets/figures/chapter-3/3.7.architecture-design} + \caption{Αρχιτεκτονική του συστήματος (στάδιο σχεδίασης)} +\end{figure} + +Αξίζει να σημειωθούν τα εξής: + +\begin{itemize} + \item Ο κώδικας του frontend εκτελείται αποκλειστικά στο σύστημα του χρήστη, χωρίς να απαιτείται κάποιος εξυπηρετητής. Δηλαδή, ο χρήστης αρκεί απλά να έχει τον κώδικα αποθηκευμένο στον υπολογιστή του. + \item Ο χρήστης αλληλεπιδρά άμεσα με το UI και το MetaMask. Το MetaMask αποτελεί browser add-on, το οποίο διαχειρίζεται τα ιδιωτικά κλειδιά Ethereum του χρήστη και πραγματοποιεί τις συναλλαγές του τελευταίου με τα smart contracts. Στην προκειμένη περίπτωση, περιέχει τα κλειδιά που σχετίζονται αφενός με τη διεύθυνση με την οποία ο χρήστης εγγράφεται στην πλατφόρμα, αφετέρου με τις διευθύνσεις που περιέχουν τα NFTs των κοινοτήτων στις οποίες ανήκει και έχει δικαιώματα ψήφου. + \item Στο frontend εκτελείται στο παρασκήνιο ένας κόμβος για το IPFS. Αυτός συνδέεται με άλλους κατάλληλους κόμβους, διαμοιράζοντας τον κύριο όγκο των δεδομένων της εφαρμογής (π.χ. του περιεχομένου των μηνυμάτων). + \item Τέλος, στο Ethereum blockchain υπάρχουν τόσο τα contracts της εφαρμογής, όσο και τα εξωτερικά contracts που παρέχουν τα tokens των κοινοτήτων. Τα μεν λειτουργούν ως το σημείο αναφοράς της εφαρμογής, επί του οποίου εκτελούνται οι ενέργειες και αποθηκεύονται οι μεταβλητές που είναι απολύτως απαραίτητες για τη λειτουργία της πλατφόρμας (π.χ. εγγεγραμμένοι χρήστες, δημιουργημένες κοινότητες). Τα δε, δημιουργούνται από εξωτερικές οντότητες, οι οποίες ορίζουν κατά τη βούλησή τους τον ακριβή τρόπο δημιουργίας και διαμοιρασμού των tokens τους στους χρήστες. +\end{itemize} \ No newline at end of file diff --git a/chapters/3.application-design/3.8.implementation-methodology-specification.tex b/chapters/3.application-design/3.8.implementation-methodology-specification.tex new file mode 100644 index 0000000..6da38ce --- /dev/null +++ b/chapters/3.application-design/3.8.implementation-methodology-specification.tex @@ -0,0 +1,20 @@ +\section{Προδιαγραφή μεθόδου υλοποίησης και χρονοπρογραμματισμός} \label{section:3-8-implementation-methodology-specification} + +Κατά τον χρονοπρογραμματισμό ακολουθήθηκαν οι τακτικές που ορίζει το Scrum. Το συνολικό προγραμματιστικό έργο χωρίστηκε σε επιμέρους, διακριτούς στόχους και κάθε στόχος αντιστοιχήθηκε σε ένα Sprint. Τα Sprints αποτελούνται από επιμέρους διαχωρισμό της εργασίας σε epic tasks. Σε αυτό το στάδιο χρονοπρογραμματισμού δεν έγινε αναλυτικότερη περιγραφή των επιμέρους tasks, κάθε epic χωρίστηκε σε tasks κατά το αρχικό στάδιο της υλοποίησης του. + +Ως σημαντικότερος στόχος της ανάπτυξης ορίζεται η δημιουργία ενός ελάχιστου βιώσιμου προϊόντος (Minumum Viable Product - MVP). Σε αυτό τον στόχο περιλαμβάνονται πιο στοιχειώδεις λειτουργίες μίας πλατφόρμας επικοινωνίας οι οποίες την κάνουν χρήσιμη, η δυνατότητα εγγραφής, δημιουργίας θεμάτων και μηνυμάτων και ανάγνωσης του υπάρχοντος περιεχομένου. Επειδή ο στόχος αυτός περιέχει από μόνος του σημαντική περιπλοκότητα και δυσκολία κρίθηκε αναγκαίος ο περαιτέρω διαχωρισμός του σε τρία Sprints. + +Στο πρώτο Sprint ορίστηκε ο στόχος της δημιουργίας μίας βάσης κώδικα (codebase), της εξοικείωσης με τα προγραμματιστικά εργαλεία του οικοσυστήματος των DApps και της επιτυχής δημιουργίας του πρώτου contract. Στο δεύτερο Sprint ο στόχος ορίστηκε ως η δημιουργία των τεχνικών χαρακτηριστικών που αφορούν τους χρήστες της πλατφόρμας και που οι ίδιοι (οι χρήστες) έχουν συνηθίσει να περιμένουν από μία τέτοια πλατφόρμα. Στο τρίτο Sprint συμπεριλήφθηκαν τα τεχνικά χαρακτηριστικά που απομένουν ώστε να δημιουργηθεί το MVP. + +Τα επόμενα τρία Sprints χτίζουν διαδοχικά πάνω στην υπάρχουσα δουλειά και υποδομή. Στο τέταρτο μέρος εργασίας ως στόχος ορίστηκε η προσθήκη των χαρακτηριστικών ψηφοφορίας πάνω στα μηνύματα και δημιουργίας ψηφοφοριών θεμάτων (polls). Το επόμενο Sprint περιλαμβάνει εργασίες δημιουργίας υποδομής και την πρώτη ημι-δημόσια εγκατάσταση της εφαρμογής σε περιβάλλον δοκιμής. Το τελευταίο Sprint αποτελεί το τελικό προϊόν και περιέχει tasks σχετικά με την δημιουργία κοινοτήτων και την beta εγκατάσταση της εφαρμογής. + +Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:3.8.implementation-methodology-specification-sprints}). + +\begin{figure}[H] + \centering + \includegraphics[width=.8\textwidth]{assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png} + \caption{Διαχωρισμός σε sprints} + \label{figure:3.8.implementation-methodology-specification-sprints} +\end{figure} + +TODO: add tasks for serve (front and contracts) thru IPFS, upgradability diff --git a/chapters/4.application-implementation/4.0.application-implementation.tex b/chapters/4.application-implementation/4.0.application-implementation.tex index df2cd3e..25f3cd3 100644 --- a/chapters/4.application-implementation/4.0.application-implementation.tex +++ b/chapters/4.application-implementation/4.0.application-implementation.tex @@ -1,6 +1,7 @@ -\chapter{Υλοποίηση εφαρμογής} +\chapter{Υλοποίηση εφαρμογής}\label{chapter:4-application-implementation} -\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} +\input{chapters/4.application-implementation/4.1.implementation-methodology} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack} +\input{chapters/4.application-implementation/4.3.implementation-architecture} +\input{chapters/4.application-implementation/4.4.problems-faced} +\input{chapters/4.application-implementation/4.5.implemented-parts} diff --git a/chapters/4.application-implementation/4.1.implementation-methodology.tex b/chapters/4.application-implementation/4.1.implementation-methodology.tex new file mode 100644 index 0000000..985407d --- /dev/null +++ b/chapters/4.application-implementation/4.1.implementation-methodology.tex @@ -0,0 +1,60 @@ +\section{Μεθοδολογία υλοποίησης} \label{subsection:4-1-implementation-methodology} + +Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της εργασίας που απαιτείται σε διαχειρίσιμα μέρη, σχεδιάστηκε η χρήση διάφορων εργαλείων και μεθόδων ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git, η μέθοδος οργάνωσης Scrum και οι διαδικασίες ανάπτυξης DevOps. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύγχρονη ανάπτυξη λογισμικού. + +Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διαρκούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφείς και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερωμένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγή τελμάτων κατά τη συγγραφή του κώδικα. + +Το Git είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση (merge) κλαδιών (branches). + +Για τους σκοπούς της παρούσας διπλωματικής χρησιμοποιήθηκε το μοντέλο GitHub flow\cite{4.1-github-flow}. Το μοντέλο αυτό ορίζει ότι κάθε προγραμματιστής ανοίγει ένα νέο branch για τη ανάπτυξη ενός χαρακτηριστικού της εφαρμογής ή τη διόρθωση ενός μέρους του κώδικα. Έπειτα, όταν η δουλειά έχει ολοκληρωθεί, δημιουργείται ένα αίτημα ένωσης (pull request) με το βασικό κλαδί ανάπτυξης (develop) της εφαρμογής. Η δουλειά υπόκειται σε αξιολόγηση από την υπόλοιπη ομάδα (review) και όταν κριθεί ότι ικανοποιεί τις ανάγκες του έργου, το branch γίνεται merge με το develop. Όταν το develop φτάσει σε ικανό σημείο σταθερότητας και αλλαγών, γίνεται merge με το branch παραγωγής (master). Από το master δημιουργούνται οι τελικές εκδόσεις της εφαρμογής οι οποίες διανέμονται για χρήση στην παραγωγή (production versions), ενώ από το develop δημιουργούνται οι δοκιμαστικές εκδόσεις αιχμής της εφαρμογής οι οποίες χρησιμοποιούνται κατά τον έλεγχο (staging versions). + +Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από tasks τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των tasks πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί. + +Λόγω του πολύ μικρού μεγέθους της ομάδας, το Scrum ακολουθήθηκε ελαστικά. Συγκεκριμένα, δεν ορίστηκε ένας συγκεκριμένος επιμελητής του board αλλά κάθε μέλος της ομάδας φρόντιζε για τον ορισμό και την περιγραφή ενός μέρους των tasks. Τα sprints δεν ήταν συνεχόμενα και δεν είχαν πάντα τον ίδιο χρόνο εκτέλεσης αλλά προσαρμόζονταν ανάλογα με τις εκάστοτε ανάγκες και τον χρόνο των μελών. Κατά βάση, χρησιμοποιήθηκε η μέθοδος Kanban (που χρησιμοποιείται από το ίδιο το Scrum), για την οπτικοποίηση των tasks. Τα tasks χωρίστηκαν σε λίστες οι οποίες περιλαμβάνουν: + +\begin{itemize} + \item σε αναμονή (backlog), περιλαμβάνει tasks τα οποία δεν έχουν ακόμα εισαχθεί σε κάποιο sprint + \item ενεργό sprint (sprint/todo), περιλαμβάνει tasks τα οποία συμμετέχουν στο ενεργό (τωρινό) sprint + \item εκτέλεση (in progress/doing), περιλαμβάνει tasks για τα οποία έχει ξεκινήσει η ανάπτυξη από κάποιο μέλος της ομάδας + \item έλεγχος και αξιολόγησης (testing/code review), περιλαμβάνει tasks των οποίων η ανάπτυξη έχει ολοκληρωθεί και βρίσκονται στο στάδιο ελέγχου (testing) ή αναμονής σε pull request + \item ολοκλήρωση (done), περιλαμβάνει tasks τα οποία έχουν τελειώσει, δηλαδή των οποίων η ανάπτυξη έχει ολοκληρωθεί και το pull request έχει γίνει merge +\end{itemize} + +Τέλος, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί tasks που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή. Για παράδειγμα, μέχρι τέσσερα tasks στην λίστα εκτέλεσης. Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των tasks από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task. + +\begin{figure}[H] + \centering + \includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4.1.implementation-methodology-kanban.png} + \caption{Στιγμιότυπο οθόνης της διαδικτυακής υπηρεσίας Trello που χρησιμοποιήθηκε για την υλοποίηση του Scrum} + \label{figure:4.1.implementation-methodology-kanban} +\end{figure} + +Κατά την διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά το deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην απρόσκοπτη, αυτοματοποιημένη και γρήγορα ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι: + +\begin{itemize} + \item συνεχής έλεγχος (continuous testing) + \item συνεχής ολοκλήρωση (continuous integration) + \item συνεχής παράδοση (continuous delivery) + \item συνεχής εγκατάσταση (continuous deployment) +\end{itemize} + +Για την υλοποίηση των τακτικών αυτών επιλέχθηκε μετά από εκτενή έρευνα η πλατφόρμα Jenkins. Το Jenkins συνδυάστηκε με την πλατφόρμα εικονοποίησης Docker ώστε να ακολουθηθούν οι τελευταίες ενδεδειγμένες πρακτικές της βιομηχανίας. Έγινε συγγραφή του αρχείου Jenkinsfile το οποίο περιγράφει με κώδικα την ροή εργασιών (pipeline) που πρέπει να ακολουθηθεί μετά από κάθε αλλαγή στον κώδικα. Η εκτέλεση του pipeline πραγματοποιείται αυτόματα από το Jenkins. + +Το pipeline αποτελείται από στάδια και βήματα τα οποία φαίνονται στο σχήμα \ref{figure:4.1.implementation-methodology-jenkins-pipeline}: + +\begin{enumerate} + \item Αρχικά εκτελείται το βήμα "Version", το οποίο συλλέγει στοιχεία σχετικά με την εκτέλεση του pipeline όπως το κλαδί του κώδικα που πυροδότησε τη ροή και ποια από τα πακέτα λογισμικού που περιλαμβάνονται στο git repository περιέχουν αλλαγές. + \item Έπειτα εκτελείται το στάδιο "TEST" το οποίο περιέχει δύο βήματα που εκτελούνται παράλληλα και πραγματοποιούν έλεγχο του κώδικα των πακέτων. + \item Αν το κλαδί πυροδότησης είναι ένα feature branch η ροή σταματά εδώ, ενώ αν πρόκειται για ένα από τα βασικά κλαδιά (master ή develop) τότε η ροή συνεχίζει με το στάδιο "BUILD" στο οποίο εκτελούνται παράλληλα τα βήματα που χτίζουν τα docker images των πακέτων εκείνων τα οποία περιέχουν αλλαγές. + \item Στο στάδιο "PUBLISH", αν το κλαδί πυροδότησης είναι το κύριο κλαδί παραγωγής (master), τότε εκτελούνται παράλληλα βήματα τα οποία δημοσιεύουν τα docker images που δημιουργήθηκαν στο αποθετήριο Dockerhub. + \item Τέλος, εκτελείται το στάδιο "DEPLOY", κατά το οποίο πραγματοποιείται η εγκατάσταση των υπηρεσιών στο ανάλογο περιβάλλον, staging για το κλαδί develop και production για το κλαδί master. +\end{enumerate} + +\begin{figure}[H] + \centering + \includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4.1.implementation-methodology-jenkins-pipeline.png} + \caption{Διάγραμμα ροής εργασιών Jenkins} + \label{figure:4.1.implementation-methodology-jenkins-pipeline} +\end{figure} + +Με την χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με την χρήση του συγκεκριμένου pipeline γίνεται σίγουρο ό,τι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης ο κώδικας ελέγχεται και τα αποτελέσματα των tests είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker images, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλουν τα μέλη της ομάδας σε αυτό. diff --git a/chapters/4.application-implementation/4.1.implemented-parts.tex b/chapters/4.application-implementation/4.1.implemented-parts.tex deleted file mode 100644 index bd50354..0000000 --- a/chapters/4.application-implementation/4.1.implemented-parts.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Χαρακτηριστικά που υλοποιήθηκαν} diff --git a/chapters/4.application-implementation/4.2.implementation-methodology.tex b/chapters/4.application-implementation/4.2.implementation-methodology.tex deleted file mode 100644 index 2e3ce98..0000000 --- a/chapters/4.application-implementation/4.2.implementation-methodology.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Μεθοδολογία υλοποίησης} diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack.tex new file mode 100644 index 0000000..78e99a7 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack.tex @@ -0,0 +1,8 @@ +\section{Τεχνολογίες υλοποίησης} \label{subsection:4-2-implementation-technology-stack} + +Η παρούσα ενότητα απαρτίζεται από υποενότητες, στις οποίες διατυπώνονται οι \textbf{σημαντικότερες} τεχνολογίες που χρησιμοποιήθηκαν για την υλοποίηση της εφαρμογής. Όλες οι τεχνολογίες αποτελούν δωρεάν λογισμικό ανοιχτού κώδικα. + +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies} diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies.tex new file mode 100644 index 0000000..cf35e8d --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies.tex @@ -0,0 +1,9 @@ +\subsection{Τεχνολογίες σχετικές με το development} + +Σε αυτήν την υποενότητα περιγράφονται ορισμένα θεμελιώδη εργαλεία και frameworks που συνετέλεσαν στην ανάπτυξη της εφαρμογής. + +%TODO: Add janus and build steps diagram + +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.1.node.js} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.2.docker} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins} diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.1.node.js.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.1.node.js.tex new file mode 100644 index 0000000..289dfe2 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.1.node.js.tex @@ -0,0 +1,9 @@ +\subsubsection{Node.js} \label{subsection:4-2-1-1-node.js} + +\logo{chapter-4/4.2.node.js-logo}{Node.js logo} + +Το Node.js\footnote{\url{https://nodejs.org/}} είναι ένα περιβάλλον χρόνου εκτέλεσης Javascript πολλαπλών πλατφορμών, το οποίο εκτελείται στη μηχανή V8\footnote{\url{https://v8.dev/}} και παρέχει τη δυνατότητα εκτέλεσης κώδικα Javascript εκτός περιηγητών ιστού. Επιτρέπει στους προγραμματιστές να χρησιμοποιούν Javascript για τη σύνταξη εργαλείων γραμμής εντολών και τη δημιουργία κλιμακωτών διαδικτυακών εφαρμογών (κυρίως για εξυπηρετητές). Έχει αρχιτεκτονική βασισμένη σε συμβάντα (event-driven architecture), με δυνατότητα ασύγχρονης εισόδου/εξόδου (asynchronous I/O).\cite{4.2-node.js} + +Ένα από τα σημαντικότερα χαρακτηριστικά του Node.js είναι ο ενσωματωμένος διαχειριστής πακέτων του, ο οποίος ονομάζεται npm. Με τον npm γίνεται εφικτή η εγκατάσταση πακέτων (βιβλιοθηκών) από το μητρώο npm (npm registry\footnote{\url{https://www.npmjs.com/}}), καθώς και η οργάνωση και η διαχείρισή τους στα πλαίσια της ανάπτυξης μίας εφαρμογής που εξαρτάται από αυτά. + +Το Node.js έχει το αποθετήριό του στο GitHub (\url{https://github.com/nodejs/node}). \ No newline at end of file diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.2.docker.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.2.docker.tex new file mode 100644 index 0000000..f99936c --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.2.docker.tex @@ -0,0 +1,15 @@ +\subsubsection{Docker} \label{subsection:4-2-1-2-docker} + +\logo{chapter-4/4.2.docker-logo}{Docker logo} + +Το Docker αποτελεί μία πλατφόρμα η οποία παρέχει λογισμικό εικονοποίησης (virtualization) στο επίπεδο του λειτουργικού συστήματος καθώς και ολοκληρωμένα συστήματα διαμοιρασμού και εκτέλεσης των παραγόμενων εικόνων. + +Δίνει την δυνατότητα σύνθεσης εικονικών περιβαλλόντων λειτουργικού συστήματος τα οποία ονομάζονται εικόνες (images). Μέσα στις εικόνες είναι δυνατή η εκτέλεση προγραμμάτων σε ασφαλή, απομονωμένα και προβλέψιμα περιβάλλοντα τα οποία εγγυούνται τις ίδιες συνθήκες εκτέλεσης παντού. Έτσι, οι προγραμματιστές δεν χρειάζεται να ανησυχούν για το περιβάλλον εκτέλεσης του κώδικα και την ρύθμιση των παραμέτρων σε κάθε ξεχωριστή εγκατάσταση. + +Ταυτόχρονα, η πλατφόρμα του Docker παρέχει συστήματα και τυποποιημένες μεθόδους για το πακετάρισμα των εικόνων, την μεταφόρτωση και την εκτέλεσή τους σε απομακρυσμένα συστήματα. Με αυτό τον τρόπο αποτελεί πολύτιμο εργαλείο το οποίο έχει γίνει το στάνταρ στη βιομηχανία λογισμικού για τον διαμοιρασμό και την εγκατάσταση ολοκληρωμένων εφαρμογών σε περιβάλλοντα δοκιμής (staging environments) και παραγωγής (production environment). + +Τέλος, η δυνατότητα τοπικής εκτέλεσης των εικόνων στο σύστημα ανάπτυξης του κώδικα δίνει την ευκαιρία ελέγχου (testing) και αποσφαλμάτωσης (debug) τοπικά σε ένα περιβάλλον ίδιο με αυτό της εκτέλεσης. Αυτό είναι εξαιρετικά σημαντικό επειδή αποκλείει τυχών μεταβολές στην πορεία εκτέλεσης του προγράμματος που μπορεί να έρχονταν από την εκτέλεση σε ένα διαφορετικό περιβάλλον. + +% example citations +% Merkel, Dirk. “Docker: Lightweight Linux Containers for Consistent Development and Deployment.” Linux Journal, vol. 2014, no. 239, 2014, p. 2. +% Anderson, Charles. “Docker [Software Engineering].” IEEE Software, vol. 32, no. 3, 2015. diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins.tex new file mode 100644 index 0000000..92fd81f --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins.tex @@ -0,0 +1,14 @@ +\subsubsection{Jenkins} \label{subsection:4-2-1-3-jenkins} + +\logo{chapter-4/4.2.jenkins-logo}{Jenkins logo} + +Το Jenkins είναι ένας πλήρως παραμετροποιήσιμος και επεκτάσιμος διακομιστής αυτοματοποίησης (automation server). Ο διακομιστής μπορεί να αυτοματοποιήσει τις διαδικασίες ελέγχου, ολοκλήρωσης, παράδοσης και εγκατάστασης του κώδικα, υλοποιώντας έτσι βασικές διαδικασίες που ορίζει το DevOps, συνεχή έλεγχο (continuous testing), συνεχή ολοκλήρωση (continuous integration), συνεχή παράδοση (continuous delivery) και συνεχή εγκατάσταση (continuous deployment). Επίσης, το Jenkins μπορεί να παραμετροποιηθεί μέσω των ρυθμίσεων που προσφέρει και των επεκτάσεων (plugins) που υπάρχουν ώστε να παρέχει τις δυνατότητες αυτές για οποιαδήποτε πλατφόρμα, γλώσσα και περιβάλλον ανάπτυξης. + +Στο Jenkins είναι δυνατός ο ορισμός με χρήση κώδικα (σε Groovy και στο DSL που παρέχεται από το Jenkins) πολλαπλών γραμμών εργασιών (pipeline). Οι γραμμές εργασιών συντίθενται από πολλαπλά βήματα τα οποία επιτελούν ξεχωριστούς στόχους προς το τελικό αποτέλεσμα της γραμμής. Τα βήματα μπορούν να τρέχουν σειριακά ή παράλληλα. Ενώ δίνεται η δυνατότητα εκτέλεσης σε πολλαπλά, διανεμημένα συστήματα καθώς και άλλες προχωρημένες λειτουργικότητες. + +Το Jenkins συνδυάζεται αποτελεσματικά με την πλατφόρμα του Docker που περιγράφηκε προηγουμένως. Μέσω του συνδυασμού δίνεται η ευκαιρία της αυτοματοποίησης του μεγαλύτερου μέρους του DevOps σε ένα απολύτως προβλέψιμο περιβάλλον το οποίο παραμένει σταθερό από την ανάπτυξη του κώδικα μέχρι την τελική εγκατάσταση. Με αυτή την μέθοδο βελτιώνεται σημαντικά η αποτελεσματικότητα των ομάδων ανάπτυξης κώδικα. + +% example citations +% Shahin, Mojtaba, et al. “Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices.” IEEE Access, vol. 5, 2017, pp. 3909–3943. +% Meyer, Mathias. “Continuous Integration and Its Tools.” IEEE Software, vol. 31, no. 3, 2014, pp. 14–16. +% Virmani, Manish. “Understanding DevOps & Bridging the Gap from Continuous Integration to Continuous Delivery.” Fifth International Conference on the Innovative Computing Technology (INTECH 2015), 2015, pp. 78–82. diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies.tex new file mode 100644 index 0000000..4bbea95 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies.tex @@ -0,0 +1,9 @@ +\subsection{Τεχνολογίες σχετικές με το UI} + +Στην παρούσα υποενότητα περιγράφονται όσες τεχνολογίες σχετίζονται με τη διεπαφή του χρήστη (UI), δηλαδή με το Presentation tier. + +% TODO: add technologies like redux, sagas + +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.1.react} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.2.redux} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.3.redux-saga} \ No newline at end of file diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.1.react.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.1.react.tex new file mode 100644 index 0000000..da0aa74 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.1.react.tex @@ -0,0 +1,11 @@ +\subsubsection{React} \label{subsection:4-2-2-1-react} + +\logo{chapter-4/4.2.react-logo}{React logo} + +Η React\footnote{\url{https://reactjs.org/}} αποτελεί βιβλιοθήκη Javascript, η οποία χρησιμοποιείται για την κατασκευή διεπαφών χρήστη. Είναι δηλωτική (declarative) και βασίζεται σε components, τα οποία διαχειρίζονται την κατάστασή τους (state) και συντίθενται για να δημιουργήσουν πολύπλοκα διαδραστικά UIs. + +%TODO: When https://2021.stateofjs.com/en-US/ is available, add to the paragraph above that is the most popular js front-end framework (by usage), according to https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/ and also add this beautiful chart. + +Ένα σημαντικό εργαλείο για την ταχεία ανάπτυξη web εφαρμογών σε React είναι το Create React App\footnote{\url{https://create-react-app.dev/}}. Με τη χρήση μίας και μόνο εντολής (\texttt{npx create-react-app my-app}), εγκαθίσταται αυτόματα ένας development server σε περιβάλλον Node.js (ως μία μοναδική βιβλιοθήκη). Αυτός εμπεριέχει μία πληθώρα από build tools (π.χ. Webpack, Babel, ESLint), τα οποία προσφέρουν ισχυρές δυνατότητες, όπως άμεσα reloads και παραγωγή βελτιστοποιημένων bundles. Έτσι, η διαδικασία της υλοποίησης αποκτά ποικίλες διευκολύνσεις, χωρίς να απαιτεί την εκμάθηση, την χειροκίνητη εγκατάσταση και την προηγμένη διαμόρφωση των τεχνολογιών στο εσωτερικό. + +Η React έχει το αποθετήριό της στο GitHub (\url{https://github.com/facebook/react/}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/react}). diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.2.redux.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.2.redux.tex new file mode 100644 index 0000000..0855fed --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.2.redux.tex @@ -0,0 +1,27 @@ +\subsubsection{Redux} \label{subsection:4-2-2-1-redux} + +\logo{chapter-4/4.2.redux-logo}{Redux logo} + +Το Redux\footnote{\url{https://redux.js.org/}} αποτελεί μία βιβλιοθήκη Javascript, η χρήση της οποίας προσφέρει στην εφαρμογή ένα πλήρως διαχειρίσιμο global state. + +%TODO: When https://2021.stateofjs.com/en-US/ is available, add to the paragraph above that is the most popular data layer technology (by usage), according to https://2020.stateofjs.com/en-US/technologies/datalayer/ and also add this beautiful chart. + + +Τα δομικά στοιχεία του Redux είναι τα εξής: +\begin{itemize} + \item \textbf{Actions}: Αντικείμενα τα οποία περιέχουν νέα πληροφορία για την τροποποίηση του state της εφαρμογής. + \item \textbf{Reducers}: Συναρτήσεις οι οποίες λαμβάνοντας ένα action και διαβάζοντας το τρέχον state, εφαρμόζουν κάποια λογική για την παραγωγή ενός νέου state. + \item \textbf{Store}: Το αντικείμενο στο οποίο βρίσκεται αποθηκευμένο το state της εφαρμογής. Η βασική ιδιότητα του state είναι ότι παραμένει αμετάβλητο και, για την ανανέωσή του, παράγεται πάντα ένα νέο state object μέσω των reducer. + \item \textbf{Middleware}: Προαιρετικά κομμάτια κώδικα που λαμβάνουν actions πριν εκείνα φτάσουν στους reducers και εκτελούν κάποιο side effect. Συνήθως χρησιμοποιούνται για ενέργειες όπως logging και error reporting ή για να ενώσουν το Redux με εξωτερικά APIs. +\end{itemize} + +Αν και το ίδιο το Redux είναι μικροσκοπικό σε μέγεθος, ο τρόπος υλοποίησής του έχει επιτρέψει τη δημιουργία ενός τεράστιου οικοσυστήματος εργαλείων και επεκτάσεων, τα οποία συνδέονται μαζί του ή βασίζονται σε αυτό. Για παράδειγμα, μία από τις κύριες χρήσεις του είναι η κατασκευή διεπαφών χρήστη σε συνδύασμό με άλλες βιβλιοθήκες, όπως με την React. Σε αυτήν την περίπτωση, συνδέεται μαζί της με το npm πακέτο \texttt{react-redux} και η λειτουργία του υπό ανάπτυξη UI προκύπτει ως εξής: + +%TODO: Add proper diagram +\begin{figure}[H] + \centering + \includegraphics[width=.75\textwidth]{assets/figures/chapter-4/4.2.react-redux} + \caption{Λειτουργία του Redux σε συνδυασμό με React} +\end{figure} + +Το Redux έχει το αποθετήριό του στο GitHub (\url{https://github.com/reduxjs/redux}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/redux}). diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.3.redux-saga.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.3.redux-saga.tex new file mode 100644 index 0000000..d5e4838 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.3.redux-saga.tex @@ -0,0 +1,7 @@ +\subsubsection{Redux-Saga} \label{subsection:4-2-2-3-redux-saga} + +\logo{chapter-4/4.2.redux-saga-logo}{Redux-Saga logo} + +Το Redux-Saga\footnote{\url{https://redux.js.org/}} αποτελεί μία βιβλιοθήκη Javascript του οικοσυστήματος του Redux. Πρόκειται για ένα Redux middleware, το οποίο χρησιμοποιεί ESG generator functions\footnote{\url{https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*}} για την εκτέλεση και διαχείριση ποικίλων ασύγχρονων side effect. Αυτές οι συναρτήσεις (sagas) παρέχουν μία πληθώρα επιλογών για την παράλληλη εκτέλεση κώδικα που μπορεί να σχετίζεται με εξωτερικά APIs, όπως με ένα blockchain ή μία βάση δεδομένων. Με αυτόν τον τρόπο, τα τελευταία μπορούν να συμπεριληφθούν στο κεντρικό Redux store και τη διαχείριση του συνολικού state της εφαρμογής. + +Το Redux-Saga έχει το αποθετήριό του στο GitHub (\url{https://github.com/redux-saga/redux-saga}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/redux-saga}). diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies.tex new file mode 100644 index 0000000..52b6776 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies.tex @@ -0,0 +1,6 @@ +\subsection{Τεχνολογίες σχετικές με το Ethereum} \label{subsection:4-2-3-ethereum-technologies} + +Στην παρούσα υποενότητα περιγράφονται εκείνες οι τεχνολογίες που σχετίζονται με το Ethereum, δηλαδή με το Application tier της τεχνολογικής στοίβας. + +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.1.truffle} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.2.ganache} diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.1.truffle.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.1.truffle.tex new file mode 100644 index 0000000..40bcc51 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.1.truffle.tex @@ -0,0 +1,11 @@ +\subsubsection{Truffle} \label{subsection:4-2-3-1-truffle} + +\logo{chapter-4/4.2.truffle-logo}{Truffle logo} + +Το Truffle\footnote{\url{https://trufflesuite.com/truffle/}} είναι ένα από τα δημοφιλέστερα Ethereum development frameworks και αποτελεί τμήμα της σουίτας Truffle. + +Μέσω του Truffle πραγματοποιείται η διαχείριση των έξυπνων συμβολαίων. Αυτή περιλαμβάνει τη δοκιμή, τη σύνδεση και τη μεταγλώττισή τους, καθώς και την ανάπτυξη τους στο blockchain. + +Επίσης, το Truffle περιέχει πρόσθετα σχετικά εργαλεία, όπως διαδραστική κονσόλα για άμεση αλληλεπίδραση με τα contracts και εκτελεστής εξωτερικών σεναρίων (external script runner). + +Έχει το αποθετήριό του στο GitHub (\url{https://github.com/trufflesuite/truffle}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/truffle}). \ No newline at end of file diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.2.ganache.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.2.ganache.tex new file mode 100644 index 0000000..9c87174 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.2.ganache.tex @@ -0,0 +1,21 @@ +\subsubsection{Ganache} \label{subsection:4-2-3-2-ganache} + +\logo{chapter-4/4.2.ganache-logo}{Ganache logo} + +Το Ganache\footnote{\url{https://trufflesuite.com/ganache/}} είναι ένα λογισμικό που παρέχει ένα βοηθητικό προσωπικό Ethereum blockchain για ταχεία ανάπτυξη αποκεντρωμένων εφαρμογών και αποτελεί επίσης τμήμα της σουίτας Truffle. Διατίθεται τόσο ως desktop εφαρμογή με UI, όσο και ως CLI (command-line interface). + +To Ganache παρέχει ισχυρά εργαλεία για την ανάπτυξη έξυπνων συμβολαίων, όπως: +\begin{itemize} + \item Block explorer, μέσω του οποίου μπορούν να εξεταστούν λεπτομερώς όλα τα blocks και οι συναλλαγές που έλαβαν χώρα. + \item Εξρεύνηση των εσωτερικών των contracts και των πυροδοτημένων event τους. + \item Ενδελεχές αρχείο καταγραφής της εξόδου του blockchain, το οποίο περιλαμβάνει σημαντικές πληροφορίες για τον εντοπισμό σφαλμάτων. + \item Δυνατότητα διαμόρφωσης του χρόνου εξόρυξης των block, έτσι ώστε να αρμόζει με τις εκάστοτε ανάγκες (αυτόματη εξόρυξη ή εξόρυξη σε προσαρμοσμένο χρονικό διάστημα). +\end{itemize} + +\begin{figure}[H] + \centering + \includegraphics[width=.95\textwidth]{assets/figures/chapter-4/4.2.ganache-gui} + \caption{Ganache (desktop εφαρμογή)} +\end{figure} + +Το Ganache έχει το αποθετήριό του στο GitHub (\url{https://github.com/trufflesuite/ganache}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/ganache}). \ No newline at end of file diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies.tex new file mode 100644 index 0000000..b4c51cb --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies.tex @@ -0,0 +1,7 @@ +\subsection{Τεχνολογίες σχετικές με το IPFS} + +Σε αυτήν την υποενότητα περιγράφονται όσες τεχνολογίες σχετίζονται με το IPFS (βλ. ενότητα \ref{section:2-7-ipfs}), δηλαδή με το Data tier της τεχνολογικής στοίβας της εφαρμογής. + +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.1.js-ipfs} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.2.orbit-db} +\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.3.libp2p} diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.1.js-ipfs.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.1.js-ipfs.tex new file mode 100644 index 0000000..096c59b --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.1.js-ipfs.tex @@ -0,0 +1,7 @@ +\subsubsection{js-ipfs} \label{subsection:4-2-4-1-js-ipfs} + +\logo{chapter-4/4.2.js-ipfs-logo}{js-ipfs logo} + +H υλοποίηση του IPFS που χρησιμοποείται στην εφαρμογή Concordia είναι αυτή σε Javascript και ονομάζεται js-ipfs. Μέσω αυτής της βιβλιοθήκης, παρέχεται η δυνατότητα δημιουργίας ενός IPFS κόμβου, τόσο σε έναν Node.js server, όσο και σε ένα περιβάλλον browser. + +Το js-ipfs έχει το αποθετήριό του στο GitHub (\url{https://github.com/ipfs/js-ipfs}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/ipfs}). diff --git a/chapters/2.theoretical-background/2.8.orbit-db.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.2.orbit-db.tex similarity index 55% rename from chapters/2.theoretical-background/2.8.orbit-db.tex rename to chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.2.orbit-db.tex index c9f2a23..6cebc57 100644 --- a/chapters/2.theoretical-background/2.8.orbit-db.tex +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.2.orbit-db.tex @@ -1,14 +1,10 @@ -\section{OrbitDB} +\subsubsection{OrbitDB} \label{subsection:4-2-4-2-orbit-db} -\begin{figure}[H] - \centering - \includegraphics[width=2cm]{assets/figures/orbitdb-logo.png} - \caption{OrbitDB logo} -\end{figure} +\logo{chapter-4/4.2.orbitdb-logo}{OrbitDB logo} -Η OrbitDB είναι μία P2P βάση δεδομένων ανοιχτού κώδικα. Χρησιμοποιεί το IPFS για την αποθήκευση των δεδομένων και το IPFS Pubsub για τον αυτόματο συγχρονισμό των βάσεων δεδομένων μεταξύ των peers. Είναι μία τελικά συνεπής (eventually consistent) και χρησιμοποιεί CRDTs (Conflict-Free Replicated Data Types) για συγχωνεύσεις βάσεων δεδομένων χωρίς συγκρούσεις, πράγμα που την καθιστά εξαιρετική επιλογή για DApps και offline-first web applications.\cite{2.8-orbitdb} +Η OrbitDB είναι μία P2P βάση δεδομένων ανοιχτού κώδικα. Χρησιμοποιεί το IPFS για την αποθήκευση των δεδομένων και το IPFS Pubsub για τον αυτόματο συγχρονισμό των βάσεων δεδομένων μεταξύ των peers. Είναι τελικά συνεπής (eventually consistent) και χρησιμοποιεί CRDTs (Conflict-Free Replicated Data Types) για συγχωνεύσεις βάσεων δεδομένων χωρίς συγκρούσεις, πράγμα που την καθιστά εξαιρετική επιλογή για DApps και offline-first web applications.\cite{4.2-orbitdb} -Κάποια Βασικά χαρακτηριστικά της είναι τα εξής: +Κάποια βασικά χαρακτηριστικά της είναι τα εξής: \begin{itemize} \item \textbf{Stores}: Η OrbitDB παρέχει διάφορους τύπους βάσεων (stores) για διαφορετικά μοντέλα δεδομένων και περιπτώσεις χρήσης: @@ -22,16 +18,17 @@ Όλα τα stores υλοποιούνται πάνω στο \texttt{ipfs-log}, μία αμετάβλητη, operation-based CRDT για κατανεμημένα συστήματα, ενώ υπάρχει και η δυνατότητα δημιουργίας προσαρμοσμένων stores ανάλογα με την περίπτωση. - \item \textbf{Address}: Κάθε βάση δεδομένων λαμβάνει κατά τη δημιουργία της μία διεύθυνση της μορφής: \texttt{/orbitdb/CID/DATABASE\_NAME}, όπου CID είναι το IPFS multihash του μανιφέστου της, ενώ το DATABASE\_NAME είναι το όνομα της βάσης\cite{2.8-orbitdb-guide}. Το μανιφέστο είναι ένα IPFS object που περιέχει πληροφορίες της βάσης όπως το όνομα, τον τύπο και έναν δείκτη στον ελεγκτή πρόσβασης (access controller). + \item \textbf{Address}: Κάθε βάση δεδομένων λαμβάνει κατά τη δημιουργία της μία διεύθυνση της μορφής \texttt{/orbitdb/CID/DATABASE\_NAME}, όπου \texttt{CID} είναι το IPFS multihash του μανιφέστου της και \texttt{DATABASE\_NAME} το όνομα της βάσης.\cite{4.2-orbitdb-guide}Το μανιφέστο είναι ένα IPFS object που περιέχει πληροφορίες της βάσης όπως το όνομα, τον τύπο και έναν δείκτη στον ελεγκτή πρόσβασης (access controller). \item \textbf{Identity}: Κάθε φορά που προστίθεται μία εγγραφή στη βάση υπογράφεται από τον δημιουργό της, ο οποίος προσδιορίζεται από μία ταυτότητα (identity). Το Identity object, πέρα από τον προεπιλεγμένο τρόπο λειτουργίας, μπορεί να προσαρμοστεί έτσι ώστε να συνδέεται με κάποιο εξωτερικό αναγνωριστικό. - Η μορφή του έχει ως εξής (βλ. και \url{https://github.com/orbitdb/orbit-db-identity-provider}): + Η μορφή του έχει ως εξής\footnote{Βλ. και \url{https://github.com/orbitdb/orbit-db-identity-provider}}: - \begin{figure}[H] - \centering - \includegraphics[width=12cm]{assets/figures/orbitdb-identity.png} + \begin{enumitemcenteredfigure} + \simplelisting[width=.95\textwidth]{orbit-db-identity.js} \caption{OrbitDB Identity} - \end{figure} + \end{enumitemcenteredfigure} - \item \textbf{Access Control}: Κατά τη δημιουργία μίας βάσης μπορούν να οριστούν όσοι θα έχουν δικαίωμα να γράψουν σε αυτήν μέσω ενός ελεγκτή πρόσβασης (access controller). Ο ελεγκτής θα περιλαμβάνει τα public keys τους, τα οποία μπορούν να ανακτηθούν από το identity του καθενός. Από προεπιλογή και αν δεν ορίζεται διαφορετικά, δίνεται πρόσβαση εγγραφής μόνο στον δημιουργό της βάσης. + \item \textbf{Access Control}: Κατά τη δημιουργία μίας βάσης μπορούν να οριστούν όσοι θα έχουν δικαίωμα εγγραφής σε αυτή, μέσω ενός ελεγκτή πρόσβασης (access controller). Ο ελεγκτής θα περιλαμβάνει τα public keys τους, τα οποία μπορούν να ανακτηθούν από το identity του καθενός. Από προεπιλογή και αν δεν ορίζεται διαφορετικά, δίνεται πρόσβαση εγγραφής μόνο στον δημιουργό της βάσης. \end{itemize} + +Η OrbitDB έχει το αποθετήριό της στο GitHub (\url{https://github.com/orbitdb/orbit-db}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/orbit-db}). diff --git a/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.3.libp2p.tex b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.3.libp2p.tex new file mode 100644 index 0000000..4b23253 --- /dev/null +++ b/chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.3.libp2p.tex @@ -0,0 +1,9 @@ +\subsubsection{Libp2p} \label{subsection:4-2-4-3-libp2p} + +\logo{chapter-4/4.2.libp2p-logo}{Libp2p logo} + +Η libp2p είναι ένα αρθρωτό σύστημα πρωτοκόλλων, προδιαγραφών και βιβλιοθηκών που επιτρέπουν την ανάπτυξη p2p εφαρμογών. Αποτελεί το υποκείμενο επίπεδο δικτύου του IPFS.\ref{2.7-ipfs-docs} + +Ένα από τα υλοποιημένα πρωτόκολλα μεταφοράς δεδομένων της libp2p είναι το libp2p-webrtc-star\footnote{\url{https://github.com/libp2p/js-libp2p-webrtc-star}}. Αποτελεί το πρωτόκολλο μεταφοράς δεδομένων της εφαρμογής, καθώς υποστηρίζεται τόσο από Node.js servers, όσο και από browsers. Περιλαμβάνει, επίσης, έναν signalling server, που επιτρέπει τη γρήγορη διασύνδεση των peers. + +Το libp2p-webrtc-star έχει το αποθετήριό του στο GitHub (\url{https://github.com/libp2p/js-libp2p-webrtc-star}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/libp2p-webrtc-star}). diff --git a/chapters/4.application-implementation/4.3.implementation-architecture.tex b/chapters/4.application-implementation/4.3.implementation-architecture.tex new file mode 100644 index 0000000..340c7f3 --- /dev/null +++ b/chapters/4.application-implementation/4.3.implementation-architecture.tex @@ -0,0 +1,316 @@ +\section{Αρχιτεκτονική υλοποίησης} \label{section:4-3-implementation-architecture} + +Το σύστημα υλοποιήθηκε χρησιμοποιώντας το μοντέλο αρχιτεκτονικής των μικροϋπηρεσιών. Το μοντέλο των μικροϋπηρεσιών βασίζεται στην αποδόμηση του συστήματος σε μικρές μονάδες, οι οποίες συνεργάζονται ώστε να προσφέρουν ένα ενιαίο αποτέλεσμα. Η προσέγγιση αυτή έχει πολλά πλεονεκτήματα σε σύγκριση με την ανάπτυξη μονολιθικών εφαρμογών % todo: add reference +. Ο βασικός λόγος για τον οποίο επιλέχθηκε η αρχιτεκτονική μικροϋπηρεσιών είναι η ευκολία που προσφέρει στη γρήγορη ανάπτυξη καινούριων χαρακτηριστικών, ταυτόχρονα από διαφορετικά μέλη μίας ομάδας, ασύγχρονα και χωρίς την ανάγκη συνεχής επικοινωνίας και συνεννόησης μεταξύ τους. Αυτό συμβαίνει επειδή κάθε μέρος του συστήματος (υπηρεσία) είναι αυτόνομο και η ανάπτυξή του είναι διαχωρισμένη από το υπόλοιπο σύστημα με το οποίο είναι αδύναμα συνδεδεμένο (loosely coupled). + +Το σύστημα συντίθεται από διάφορες μικροϋπηρεσίες, κάποιες από τις οποίες αναπτύχθηκαν στα πλαίσια αυτής της εργασίας ενώ άλλες αποτελούν δωρεάν λογισμικό ανοιχτού κώδικα. Οι μικροϋπηρεσίες αυτές συνοψίζονται στον παρακάτω πίνακα (πίνακας \ref{table:4-3-microservice-summary}). + +\begin{table}[H] + \begin{center} + \begin{tabularx}{\textwidth}{l X} + \toprule + \textbf{Μικροϋπηρεσία} & \textbf{Σύντομη περιγραφή - Αντικείμενο/Στόχος} \\ + \midrule + Concordia Application & Υπηρεσία με την οποία αλληλεπιδρούν οι χρήστες. \\ [0.5ex] + Concordia Contracts Migrator & Υπηρεσία μεταφόρτωσης των συμβολαίων (contracts) στο blockchain. \\ [0.5ex] + Concordia Pinner & Υπηρεσία καρφιτσώματος δεδομένων. \\ [0.5ex] + Concordia Contracts Provider & Υπηρεσία διαμοιρασμού των contract artifacts μέσω HTTP. \\ [0.5ex] + Ganache & Τοπικό, ιδιωτικό Ethereum blockchain. \\ [0.5ex] + Rendezvous Server & Υπηρεσία εύρεσης ομότιμων χρηστών. \\ [0.5ex] + \bottomrule + \end{tabularx} + \end{center} + \caption{Σύντομη περιγραφή υπηρεσιών συστήματος.} + \label{table:4-3-microservice-summary} +\end{table} + +Στα πλαίσια της εργασίας αναπτύχθηκαν επίσης διάφορα αρθρώματα, κυρίως με τη μορφή βιβλιοθηκών Javascript. Τα αρθρώματα χρησιμοποιούνται από τις υπηρεσίες για την επίτευξη των επιμέρους εργασιών. Η ανάπτυξη του λογισμικού σε ξεχωριστά αρθρώματα επιτρέπει την εύκολη επαναχρησιμοποίηση του κώδικα καθώς και τον διαχωρισμό των αυτόνομων τμημάτων κώδικα. Τα αρθρώματα συνοψίζονται στον παρακάτω πίνακα (πίνακας \ref{table:4-3-software-units-summary}). + +\begin{table}[H] + \begin{center} + \begin{tabularx}{\textwidth}{l X} + \toprule + \textbf{Άρθρωμα} & \textbf{Σύντομη περιγραφή - Αντικείμενο/Στόχος} \\ + \midrule + Άρθρωμα concordia-shared & Χρήσιμα εργαλεία και σταθερές συστήματος. \\ [0.5ex] + Άρθρωμα concordia-contracts & Μεταγλώττιση των contracts και διάθεση των artifacts. \\ [0.5ex] + Άρθρωμα eth-identity-provider & Δημιουργία μοναδικού αναγνωριστικού χρήστη για τη βάση OrbitDB. \\ [0.5ex] + Άρθρωμα drizzle & Βελτιωμένη προγραμματιστική διεπαφή επικοινωνίας με το blockchain. \\ [0.5ex] + Άρθρωμα breeze & Βελτιωμένη προγραμματιστική διεπαφή χρήσης της βάσης OrbitDB. \\ [0.5ex] + \bottomrule + \end{tabularx} + \end{center} + \caption{Σύντομη περιγραφή αρθρωμάτων συστήματος.} + \label{table:4-3-software-units-summary} +\end{table} + +Τα αρθρώματα και οι υπηρεσίες θα περιγραφούν σε μεγαλύτερη ανάλυση στα επόμενα κεφάλαια. Στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-architecture-overview}) φαίνεται η συνολική αρχιτεκτονική του συστήματος. + +\begin{figure}[H] + \centering + \includegraphics[width=.75\textwidth]{assets/figures/chapter-4/4.3.architecture-architecture-overview.png} + \caption{Διάγραμμα αρχιτεκτονικής συστήματος} + \label{figure:4-3-architecture-overview} +\end{figure} + +% ===== ===== +% Common software units +% ===== ===== +\subsection{Αρθρώματα} \label{subsection:4-3-software-units} + +Στο κεφάλαιο αυτό θα περιγραφούν με μεγαλύτερη λεπτομέρεια τα αρθρώματα που αναπτύχθηκαν. + +\vspace{0.5cm} +\textbf{Άρθρωμα concordia-shared} + +Το άρθρωμα concordia-shared αποτελεί μία βιβλιοθήκη χρήσιμων εργαλείων και σταθερών. Εδώ περιέχεται όλο το λογισμικό το οποίο πρέπει ή είναι επιθυμητό να συμπεριφέρεται με τον ίδιο τρόπο συνολικά στο σύστημα, όπως για παράδειγμα μέθοδοι παραμετροποίησης των υπηρεσιών και μέθοδοι καταγραφής (logging). Το άρθρωμα αυτό χρησιμοποιείται από το άρθρωμα concordia-contracts καθώς και από τις υπηρεσίες Concordia Application, Concordia Pinner και Concordia Contracts Provider. + +% make more sense +Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή τοπικής βιβλιοθήκης με τη χρήση της βιβλιοθήκης διαχείρισης μοναδικού αποθετηρίου κώδικα (monorepo) lerna. + +\vspace{0.5cm} +\textbf{Άρθρωμα concordia-contracts} + +Το άρθρωμα αυτό επιτελεί δύο ενέργειες. Αρχικά, είναι το άρθρωμα στο οποίο αναπτύσσονται τα contracts που χρησιμοποιούνται από την εφαρμογή. Το άρθρωμα αυτό αναλαμβάνει τη μεταγλώττιση των contracts από κώδικα γλώσσας Solidity, στην κατάλληλη τελική μορφή JSON. Παρέχονται επίσης σενάρια ενεργειών (scripts) ώστε τα contracts να μεταφορτωθούν σε blockchain καθώς και στην υπηρεσία Concordia Contracts Provider. Αποτελεί επίσης βιβλιοθήκη η οποία μετά τη μεταγλώττιση και μεταφόρτωση των contracts σε blockchain παρέχει τα contract artifacts. Χρησιμοποιείται από τις υπηρεσίες Concordia Application και Concordia Pinner. + +Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή τοπικής βιβλιοθήκης με τη χρήση της βιβλιοθήκης διαχείρισης monorepo lerna. + +\vspace{0.5cm} +\textbf{Άρθρωμα eth-identity-provider} + +Η λειτουργία της βάση OrbitDB απαιτεί τη δημιουργία ενός μοναδικού αναγνωριστικού χρήστη (identity). Για την εύκολη εξαγωγή ενός αναγνωριστικού χρήστη το οποίο να είναι μεν μοναδικό αλλά να είναι δυνατός ο επανυπολογισμός, χρησιμοποιήθηκε ο συνδυασμός της διεύθυνσης του χρήστη στο δίκτυο Ethereum με τη διεύθυνση του βασικού contract που χρησιμοποιεί η εφαρμογή. Ο υπολογισμός του συνδυασμού αυτού υλοποιείται από αυτό το άρθρωμα. + +Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του αποθετηρίου λογισμικού npm. + +\vspace{0.5cm} +\textbf{Άρθρωμα drizzle} + +Το άρθρωμα drizzle που χρησιμοποιείται στην υπηρεσία Concordia Application είναι μία τροποποιημένη έκδοση της Javascript βιβλιοθήκης Drizzle που προσφέρεται από τη σουίτα εργαλείων Truffle. Η τροποποιημένη βιβλιοθήκη αναπτύχθηκε στα πλαίσια της διπλωματικής με στόχο τη διευκόλυνση της χρήσης του Drizle και την επιδιόρθωση προβληματικών σημείων της πρωτότυπης βιβλιοθήκης. + +Το άρθρωμα drizzle υλοποιεί τις προγραμματιστικές διεπαφές μέσω των οποίων πραγματοποιείται η επικοινωνία της εφαρμογής με το blockchain. Για την επίτευξη της επικοινωνίας αυτής, η βιβλιοθήκη χρησιμοποιεί τη συλλογή βιβλιοθηκών web3.js η οποία αποτελεί τον πιο διαδεδομένο τρόπο διεπαφής με το blockchain σε αποκεντρωτικές εφαρμογές. + +Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του αποθετηρίου λογισμικού npm. + +\vspace{0.5cm} +\textbf{Άρθρωμα breeze} + +Το άρθρωμα αυτό αποτελεί μία βιβλιοθήκη περίβλημα (wrapper) της βιβλιοθήκης OrbitDB. Η OrbitDB είναι μία βιβλιοθήκη η οποία προσφέρει τις απαραίτητες προγραμματιστικές διεπαφές για τη χρήση της βάσης δεδομένων με το ίδιο όνομα. Μέσα από τη χρήση των βιβλιοθηκών που προσφέρονται από το IPFS για την αποθήκευση δεδομένων, η OrbitDB καταφέρνει να υλοποιήσει μία αποκεντρωμένη βάση δεδομένων. + +Το άρθρωμα breeze κάνει χρήση της βιβλιοθήκης OrbitDB, προσφέρει ωστόσο συγκεκριμένες προγραμματιστικές διεπαφές που διευκολύνουν τόσο την παραμετροποίηση της βάσης όσο και τη χρήση της, ενώ όπως και στο άρθρωμα drizzle το άρθρωμα breeze αναλαμβάνει να διορθώσει ορισμένα προβλήματα της πρωτότυπης βιβλιοθήκης. + +Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του αποθετηρίου λογισμικού npm. + +% ===== ===== +% concordia-app microservice +% ===== ===== +\subsection{Concordia Application} \label{subsection:4-3-concordia-application-service} + +\vspace{0.5cm} +\textbf{Περιγραφή - Στόχοι υπηρεσίας} + +Η εφαρμογή Concordia (Concordia Application) εκθέτει τις γραφικές διεπαφές μέσω των οποίων αλληλεπιδρούν οι χρήστες με το σύστημα. Αποτελεί τον δίαυλο επικοινωνίας του τελικού χρήστη με το blockchain και με τη βάση OrbitDB. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο σχήμα \ref{figure:4-3-concordia-application-architecture}. Μέσω της εφαρμογής Concordia οι χρήστες μπορούν να: + +\begin{itemize} + \item περιηγηθούν και διαβάσουν το περιεχόμενο της πλατφόρμας + + \item δημιουργήσουν λογαριασμό χρήστη + + \item δημοσιεύσουν και τροποποιήσουν προσωπικές τους πληροφορίες όπως η τοποθεσία και η εικόνα προφίλ + + \item δημιουργήσουν θέματα (topics) + + \item δημιουργήσουν ψηφοφορίες (polls), καθώς και να ψηφίσουν σε αυτές + + \item δημιουργήσουν και τροποποιήσουν μηνύματα (posts) + + \item υπερψηφίσουν (up-vote) ή καταψηφίσουν (down-vote) μηνύματα άλλων χρηστών +\end{itemize} + +Η υπηρεσία αποτελείται από κώδικα γραμμένο σε Javascript ο οποίος γίνεται διαθέσιμος στους τελικούς χρήστες με τη μορφή εφαρμογής διαδικτύου (web application) μέσω ενός διακομιστή (server). Παρόλο που η υπηρεσία προσφέρει τη γραφική διεπαφή χρήστη μόνο στην αγγλική γλώσσα, έχει παραμετροποιηθεί ώστε να είναι δυνατή η εύκολη μεταγλώττιση της χωρίς την ανάγκη πραγματοποίησης μεγάλων αλλαγών στον κώδικα. + +Χρησιμοποιείται η βιβλιοθήκη React για την οργάνωση και ανάπτυξη των συνθετικών τμημάτων (components) του γραφικού περιβάλλοντος. Για το γραφικό περιβάλλον γίνεται χρήση του framework της Semantic UI. Χρησιμοποιείται η βιβλιοθήκη Redux για τη διαχείριση κατάστασης της εφαρμογής (state management), % todo: find a better greek translation +καθώς και η βιβλιοθήκη Redux-Saga για τη διαχείριση ασύγχρονων παράπλευρων ενεργειών (side-effects) σε ένα σύστημα βασισμένο σε συμβάντα (event-based). Άλλες βιβλιοθήκες χρησιμοποιούνται για διάφορα μέρη της υπηρεσίας, ενώ χρησιμοποιούνται επίσης τα αρθρώματα που περιγράφηκαν προηγουμένως για την επίτευξη διαφορετικών στόχων. Ο πλήρης κατάλογος των βιβλιοθηκών και αρθρωμάτων μπορεί να βρεθεί στον κώδικα της υπηρεσίας στο παράρτημα. % todo: add reference to the appendix containing the code or a link to it in the repo + +\begin{figure}[H] + \centering + \includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png} + \caption{Αρχιτεκτονική υπηρεσίας Concordia Application} + \label{figure:4-3-concordia-application-architecture} +\end{figure} + +Για τη λειτουργία της υπηρεσία Concordia Application είναι απαραίτητα τα αντικείμενα (artifacts) που προκύπτουν από τη μεταγλώττιση των contracts και τη μεταφόρτωση/δημοσίευσή τους στο blockchain. Για την εισαγωγή των artifacts στην υπηρεσία έχουν αναπτυχθεί δύο μέθοδοι. + +Η πρώτη μέθοδος είναι η μεταγλώττιση και μεταφόρτωση των contracts πριν την παραγωγή του πακέτου λογισμικού της υπηρεσίας για τελική χρήση (production build). Με αυτό τον τρόπο η υπηρεσία θα έχει πρόσβαση στα artifacts μέσω της βιβλιοθήκης που παράγεται από το άρθρωμα concordia-contracts. Αυτή η μέθοδος έχει το μειονέκτημα ότι το τελικό πακέτο λογισμικού (production build) ``δένεται'' με όποια συγκεκριμένη έκδοση των contracts είναι διαθέσιμη κατά τη δημιουργία του πακέτου. Αυτό σημαίνει ότι σε ενδεχόμενη ενημέρωση των contracts πρέπει αναγκαστικά να δημιουργηθεί και νέα έκδοση του πακέτου λογισμικού της υπηρεσίας Concordia Application. + +Για την αποφυγή του παραπάνω προβλήματος αναπτύχθηκε η δεύτερη μέθοδος προσκόμισης των contract artifacts, η οποία είναι η λήψη τους (download) από μία άλλη τοποθεσία στο διαδίκτυο. Σε αυτή τη μέθοδο, η εφαρμογή κατά την εκκίνησή της πραγματοποιεί ένα HTTP αίτημα (HTTP request) σε διεύθυνση η οποία δίνεται ως μεταβλητή περιβάλλοντος (environment variable). Η απάντηση του αιτήματος αναμένεται να περιέχει τα artifacts ώστε η εφαρμογή να τα χρησιμοποιήσει. + +\vspace{0.5cm} +\textbf{Διανομή} + +Η υπηρεσία Concordia Application πακετάρεται μαζί με τον διακομιστή nginx και γίνεται διαθέσιμη για χρήση ως εικόνα docker (docker image) μέσω του αποθετηρίου εικόνων dockerhub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της εκτέλεσης όπως η διεύθυνση του εξυπηρετητή (host location) της εφαρμογής και οι τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider. + +% ===== ===== +% concordia-contracts-migrator microservice +% ===== ===== +\subsection{Concordia Contracts Migrator} \label{subsection:4-3-concordia-contracts-migrator} + +\vspace{0.5cm} +\textbf{Περιγραφή - Στόχοι υπηρεσίας} + +Η υπηρεσία αυτή αποτελείται από ένα εκτελέσιμο πρόγραμμα γραμμής εντολών βασισμένο στο άρθρωμα concordia-contracts που αναλύθηκε σε προηγούμενη υποενότητα (\ref{subsection:4-3-software-units}). Το πρόγραμμα, κατά την εκτέλεσή του, μεταγλωττίζει τα contracts και έπειτα τα μεταφορτώνει στο blockchain το οποίο είναι ορισμένο με χρήση μεταβλητών περιβάλλοντος. Τέλος, αν οι κατάλληλες μεταβλητές περιβάλλοντος είναι ορισμένες, το πρόγραμμα μεταφορτώνει τα τελικά artifacts σε αποθετήριο Concordia Contracts Provider. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-concordia-contracts-migrator-architecture}). + +\begin{figure}[H] + \centering + \includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png} + \caption{Αρχιτεκτονική υπηρεσίας Concordia Contracts Migrator} + \label{figure:4-3-concordia-contracts-migrator-architecture} +\end{figure} + +\vspace{0.5cm} +\textbf{Διανομή} + +Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν τη διεύθυνση του blockchain και την τοποθεσία της υπηρεσίας Contracts Provider στην οποία το πρόγραμμα θα μεταφορτώσει τα contracts και τα artifacts. + +% ===== ===== +% concordia-pinner microservice +% ===== ===== +\subsection{Concordia Pinner} \label{subsection:4-3-concordia-pinner-service} + +\vspace{0.5cm} +\textbf{Περιγραφή - Στόχοι υπηρεσίας} + +Η υπηρεσία καρφιτσώματος περιεχομένου (Concordia Pinner) αποτελεί μία εφαρμογή τερματικού (temrinal application/cmd application) η οποία στοχεύει στο καρφίτσωμα (pinning) του περιεχομένου που αποθηκεύεται στο IPFS μέσω της βάσης OrbitDB. Η υπηρεσία είναι γραμμένη στη γλώσσα προγραμματισμού Javascript. Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-3-concordia-pinner-architecture}. + +\begin{figure}[H] + \centering + \includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png} + \caption{Αρχιτεκτονική υπηρεσίας Concordia Pinner} + \label{figure:4-3-concordia-pinner-architecture} +\end{figure} + +Η υπηρεσία αυτή υλοποιήθηκε για να εγγυηθεί η διαθεσιμότητα του περιεχομένου του συστήματος που αποθηκεύεται στο IPFS (τίτλοι θεμάτων, περιεχόμενο μηνυμάτων και άλλα). Λόγω του τρόπου λειτουργίας % todo: insert reference +του IPFS, το περιεχόμενο που αναρτούν οι χρήστες πρέπει να καρφιτσώνεται από άλλους χρήστες ή αυτόνομες εφαρμογές, όπως η υπηρεσία Concordia Pinner, ώστε να είναι διαθέσιμο. Αν το περιεχόμενο δεν καρφιτσωθεί, τότε θα είναι διαθέσιμο στους υπόλοιπους χρήστες μόνο από %todo: fix gender stuff +τον/τη δημιουργό, έτσι αν αυτός/αυτή δεν είναι ενεργός/ενεργή στο δίκτυο, το περιεχόμενο θα είναι αδύνατο να βρεθεί. + +Η υπηρεσία συνδέεται στο blockchain από όπου παρακολουθεί την κατάσταση του συστήματος και ``ακούει'' για νέους χρήστες, θέματα και μηνύματα. Η υπηρεσία συνδέεται επίσης στο IPFS, έτσι όταν δημιουργηθεί νέο περιεχόμενο στο σύστημα το καρφιτσώνει αυτόματα. Με αυτό τον τρόπο, διατηρώντας την υπηρεσία πάντα διαθέσιμη, για παράδειγμα εκτελώντας τη σε περιβάλλον διακομιστή (server), διαβεβαιώνεται η διαθεσιμότητα του περιεχομένου. + +\vspace{0.5cm} +\textbf{Διανομή} + +Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Κατά την εκτέλεση της εικόνας οι χρήστες μπορούν μέσω μεταβλητών περιβάλλοντος να ορίσουν παραμέτρους της υπηρεσίας όπως τη διεύθυνση του εξυπηρετητή (host location), τη διεύθυνση του blockchain, τις διαδρομές αποθήκευσης των δεδομένων στο σύστημα και τις τοποθεσίες των υπηρεσιών Rendezvous Server και Contracts Provider. + +% ===== ===== +% concordia-contracts-provider microservice +% ===== ===== +\subsection{Concordia Contracts Provider} \label{subsection:4-3-concordia-contracts-provider-service} + +\vspace{0.5cm} +\textbf{Περιγραφή - Στόχοι υπηρεσίας} + +Η υπηρεσία Contracts Provider αποτελεί μία βοηθητική υπηρεσία η οποία υλοποιεί ένα απλό αποθετήριο για τα contract artifacts. Είναι γραμμένη σε Javascript και διαθέτει δύο HTTP \textenglish{endpoints}, ένα για τη μεταφόρτωση (upload) των artifacts προς την υπηρεσία και ένα για τη λήψη (download) από την υπηρεσία. Η υπηρεσία υποστηρίζει επίσης την επισύναψη ετικετών στα artifacts, όπως η έκδοση (version) ή το κλαδί ανάπτυξης (branch, για παράδειγμα \textenglish{master/develop}). Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-3-concordia-contracts-provider-architecture}. + +\begin{figure}[H] + \centering + \includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture.png} + \caption{Αρχιτεκτονική υπηρεσίας Concordia Contracts Provider} + \label{figure:4-3-concordia-contracts-provider-architecture} +\end{figure} + +Η υπηρεσία χρησιμοποιείται σε μία προσπάθεια αποσύνδεσης της βασικής εφαρμογής που υλοποιεί η υπηρεσία Concordia Application από μία συγκεκριμένη έκδοση των contracts. Οι λόγοι που αυτό είναι επιθυμητό αναπτύχθηκαν στην περιγραφή της υπηρεσίας Concordia \textenglish{Application} (υποενότητα \ref{subsection:4-3-concordia-application-service}). Ωστόσο, η υπηρεσία Contracts Provider αποτελεί σημείο κεντροποίησης του συστήματος, για το λόγο αυτό θεωρείται προσωρινή λύση η οποία θα μπορούσε να αντικατασταθεί από αποκεντρωτικές λύσεις όπως η μεταφόρτωση των artifacts στο IPFS και ο διαμοιρασμός τους από εκεί. + +\vspace{0.5cm} +\textbf{Διανομή} + +Η υπηρεσία αυτή γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Οι χρήστες μπορούν χρησιμοποιώντας μεταβλητές περιβάλλοντος να αλλάξουν παραμέτρους της εκτέλεσης όπως η διαδρομή αποθήκευσης των μεταφορτωμένων contract artifacts. + +% ===== ===== +% rendezvous-ganache microservice +% ===== ===== +\subsection{Ganache} \label{subsection:4-3-ganache-service} + +\vspace{0.5cm} +\textbf{Περιγραφή - Στόχοι υπηρεσίας} + +Η υπηρεσία Ganache αποτελεί μία εφαρμογή τερματικού η οποία είναι μέρος της δωρεάν σουίτας ανοιχτού λογισμικού Truffle. Η εφαρμογή δημιουργεί ένα τοπικό, ιδιωτικό blockchain το οποίο ακολουθεί το πρότυπο του Ethereum. Επίσης, η εφαρμογή δρα ως minner στο δίκτυο, διεκπεραιώνοντας όλες τις συναλλαγές. + +\vspace{0.5cm} +\textbf{Διανομή} + +Για τη χρήση της υπηρεσίας αυτής αναπτύχθηκε μία νέα εικόνα docker που βασίζεται στην επίσημη εικόνα που διατίθεται από τη σουίτα και προσθέτει μερικές χρήσιμες λειτουργικότητες όπως η δυνατότητα αποκάλυψης των κλειδιών που δημιουργούνται κατά την εκτέλεση. Η υπηρεσία γίνεται διαθέσιμη για χρήση ως docker image μέσω του αποθετηρίου εικόνων dockerhub. Η εικόνα παρέχει τη δυνατότητα τροποποίησης των παραμέτρων εκτέλεσης με χρήση μεταβλητών περιβάλλοντος. Με αυτό τον τρόπο οι χρήστες μπορούν να αλλάξουν τον αριθμό των λογαριασμών που θα δημιουργηθούν, το ποσό του Ether που θα λάβει κάθε λογαριασμός καθώς και άλλες μεταβλητές. + +% ===== ===== +% rendezvous-server microservice +% ===== ===== +\subsection{Rendezvous Server} \label{subsection:4-3-rendezvous-server-service} + +\vspace{0.5cm} +\textbf{Περιγραφή - Στόχοι υπηρεσίας} + +Η υπηρεσία Rendezvous Server αποτελεί δωρεάν λογισμικό ανοιχτού κώδικα το οποίο χρησιμοποιήθηκε (αλλά δεν αναπτύχθηκε) στα πλαίσια της διπλωματικής και υλοποιεί το πρωτόκολλο rendezvous για την εύρεση ομότιμων χρηστών (peers). Η υπηρεσία είναι απαραίτητη για τη λειτουργία του IPFS, ώστε οι ομότιμοι χρήστες (peers) να μπορούν να ανακαλύψουν τις διευθύνσεις των υπόλοιπων χρηστών του δικτύου. + +\vspace{0.5cm} +\textbf{Διανομή} + +Η υπηρεσία αυτή είναι διαθέσιμη για χρήση από τους δημιουργούς της τόσο ως εφαρμογή μέσω του αποθετηρίου λογισμικού npm αλλά και ως docker image μέσω του αποθετηρίου εικόνων dockerhub. + +% ===== ===== +% microservice communication +% ===== ===== +\subsection{Διασύνδεση υπηρεσιών} \label{subsection:4-3-service-communication} + +Στο μοντέλο των μικροϋπηρεσιών, βασικό χαρακτηριστικό είναι η επικοινωνία των ξεχωριστών υπηρεσιών και η ανταλλαγή μηνυμάτων για την επίτευξη των λειτουργικοτήτων του συστήματος. Σε αυτήν την υποενότητα θα αναλυθεί ο τρόπος με τον οποίο οι μικροϋπηρεσίες επικοινωνούν μεταξύ τους καθώς και η φύση και το περιεχόμενο των μηνυμάτων που ανταλλάσουν. + +Στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-communications-graph}) φαίνεται ο γράφος που οπτικοποιεί τα κανάλια επικοινωνίας μεταξύ των μικροϋπηρεσιών, καθώς και τα κανάλια επικοινωνίας των μικροϋπηρεσιών με το blockchain. + +\begin{figure}[H] + \centering + \includegraphics[width=.9\textwidth]{assets/figures/chapter-4/4.3.communications-diagram.png} + \caption{Γράφος οπτικοποίησης των καναλιών επικοινωνίας των μικροϋπηρεσιών} + \label{figure:4-3-communications-graph} +\end{figure} + +Εδώ αναλύεται η επικοινωνία κάθε μικροϋπηρεσίας: + +\begin{itemize} + \item \textbf{Contracts Migrator}: η υπηρεσία εκτελεί αίτημα HTTP κατά την μεταφόρτωση των \textenglish{contracts} στο Ethereum blockchain, επίσης εκτελεί αίτημα HTTP για την μεταφόρτωση των contract artifacts στην υπηρεσία Contracts Provider + + \item \textbf{Concordia Application}: η υπηρεσία εκτελεί αίτημα HTTP για την λήψη των contract \textenglish{artifacts} από την υπηρεσία Contracts Provider, εκτελεί αιτήματα HTTP για την διενέργεια συναλλαγών στο Ethereum blockchain και τέλος δημιουργεί κανάλι UDP επικοινωνίας με την υπηρεσία Rendezvous Server για την ανακάλυψη ομότιμων χρηστών (peers) στο δίκτυο IPFS + + \item \textbf{Pinner}: η υπηρεσία εκτελεί αίτημα HTTP για την λήψη των contract artifacts από την υπηρεσία Contracts Provider, εκτελεί αιτήματα HTTP για την ανανέωση και παρατήρηση της κατάστασης του contract στο Ethereum blockchain και τέλος δημιουργεί κανάλι UDP επικοινωνίας με την υπηρεσία Rendezvous Server για την ανακάλυψη peers στο δίκτυο IPFS + + \item \textbf{Rendezvous Server}: η υπηρεσία διατηρεί ανοιχτά κανάλια UDP επικοινωνίας με τους ομότιμους χρήστες μέσω των οποίων ενημερώνει την λίστα των διαθέσιμων, ενεργών χρηστών + + \item \textbf{Contracts Provider}: η υπηρεσία δεν υποκινεί καμία επικοινωνία παρά μόνο απαντά σε αιτήματα επικοινωνία από άλλες υπηρεσίες +\end{itemize} + +% ===== ===== +% data flow +% ===== ===== +\subsection{Ροή πληροφορίας} \label{subsection:4-3-data-flow} + +Στην παρούσα υποενότητα θα αναλυθεί η ροή της πληροφορίας στο σύστημα. Λόγω των πολλαπλών υπηρεσιών, της κατάτμησης την πληροφορίας και των διαφορετικών σημείων αποθήκευσης της, η ροή της πληροφορίας στο σύστημα ακολουθεί ένα σχετικά περίπλοκο μονοπάτι (σε σχέση με κλασσικές, μονολιθικές, κεντροποιημένες εφαρμογές). + +Αρχικά θα γίνει αναφορά στη διαδικασία αποθήκευσης των νέων πληροφοριών. Η μοναδική πηγή παραγωγής δεδομένων στο σύστημα είναι οι χρήστες και κατ' επέκταση η υπηρεσία Concordia Application, εφόσον είναι η μοναδική υπηρεσία με την οποία αυτοί αλληλεπιδρούν. Τα δεδομένα που δημιουργούν οι χρήστες (πληροφορίες χρηστών, τίτλοι θεμάτων και περιεχόμενο μηνυμάτων) κατατμήζονται πριν αποθηκευτούν. Η πληροφορία που εισάγεται στο σύστημα κατατμήζεται σε δύο μέρη. Στο blockchain αποθηκεύεται ένας δείκτης προς τα δεδομένα, ενώ τα πραγματικά δεδομένα αποθηκεύονται στη βάση OrbitDB. Ο δείκτης εκτός από την άμεση χρησιμότητα στην εύρεση των δεδομένων, παρέχει και την έμμεση λειτουργικότητα της δημιουργίας απαραίτητων μεταδομένων όπως ο αριθμός των θεμάτων στο σύστημα ή των μηνυμάτων σε ένα θέμα. + +Από την πλευρά της εύρεση των πληροφοριών στο σύστημα, η ροή είναι ως εξής. Αρχικά, είναι απαραίτητη η αναζήτηση στο blockchain για την εύρεση του δείκτη προς τα δεδομένα. Έπειτα, τα δεδομένα μπορούν να ανακτηθούν μέσω του IPFS από τον εκάστοτε χρήστη ή από κάποιον Pinner. + +Τέλος, παρακάτω δίνεται ένα παράδειγμα εισαγωγής πληροφορίας στο σύστημα και έπειτα ανάκτησης της ίδιας πληροφορίας. + +Έστω, χρήστης που δημιουργεί νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Μεταδεδομένα της δημιουργίας είναι η διεύθυνση του/της δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του/της δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, θα επιστραφεί ο αύξων αριθμός του νέου θέματος. Έπειτα, στην προσωπική βάση OrbitDB του/της χρήστη και στον πίνακα των θεμάτων θα προστεθεί εγγραφή με αναγνωριστικό τον αύξων αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-3-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία. + +% todo: UML diagrams might be wrong, should the ethereum and orbitDb blocks be continuous? +\begin{figure}[H] + \centering + \includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png} + \caption{Διάγραμμα ακολουθίας δημιουργίας θέματος} + \label{figure:4-3-data-flow-insert} +\end{figure} + +Έστω, χρήστης που επιθυμεί να διαβάσει το προηγούμενο μήνυμα. Αρχικά, πρέπει να διαβαστεί ο πίνακας θεμάτων από το blockchain. Η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του κάθε θέματος, τα οποία ανακτώνται από τις προσωπικές βάσεις Orbit κάθε χρήστη. Έπειτα, εφόσον το θέμα βρεθεί και ο αύξων αριθμός του είναι γνωστός, πρέπει να διαβαστούν από το blockchain τα μεταδομένα των μηνυμάτων του θέματος και συγκεκριμένα η διευθύνσεις των δημιουργών τους. Τέλος, μέσω του IPFS πρέπει να γίνει αντιγραφή των προσωπικών βάσεων των δημιουργών του κάθε μηνύματος και να αναζητηθούν σε αυτές τα εκάστοτε μηνύματα. Στο σχήμα \ref{figure:4-3-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα. + +\begin{figure}[H] + \centering + \includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png} + \caption{Διάγραμμα ακολουθίας εύρεσης και ανάκτησης θέματος} + \label{figure:4-3-data-flow-read} +\end{figure} diff --git a/chapters/4.application-implementation/4.3.implementation-technology-stack.tex b/chapters/4.application-implementation/4.3.implementation-technology-stack.tex deleted file mode 100644 index f27637d..0000000 --- a/chapters/4.application-implementation/4.3.implementation-technology-stack.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Τεχνολογίες υλοποίησης} diff --git a/chapters/4.application-implementation/4.4.implementation-architecture.tex b/chapters/4.application-implementation/4.4.implementation-architecture.tex deleted file mode 100644 index 7dcaa54..0000000 --- a/chapters/4.application-implementation/4.4.implementation-architecture.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Αρχιτεκτονική υλοποίησης} diff --git a/chapters/4.application-implementation/4.4.problems-faced.tex b/chapters/4.application-implementation/4.4.problems-faced.tex new file mode 100644 index 0000000..84873eb --- /dev/null +++ b/chapters/4.application-implementation/4.4.problems-faced.tex @@ -0,0 +1 @@ +\section{Προβλήματα ανάπτυξης} \label{section:4-5-problems-faced} diff --git a/chapters/4.application-implementation/4.5.implemented-parts.tex b/chapters/4.application-implementation/4.5.implemented-parts.tex new file mode 100644 index 0000000..0e9cfb5 --- /dev/null +++ b/chapters/4.application-implementation/4.5.implemented-parts.tex @@ -0,0 +1,45 @@ +\section{Χαρακτηριστικά που υλοποιήθηκαν} \label{section:4-5-implemented-parts} + +Κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί όπως αναλύθηκε στο προηγούμενο κεφάλαιο και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των tasks. Λόγω των καθυστερήσεων αυτών έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των Sprint καθώς και διαπραγματεύσεις της σημαντικότητας των χαρακτηριστικών. Από τον επανασχεδιασμό και τις προσαρμογές αυτές προέκυψαν μερικές αλλαγές στο τελικό σετ των χαρακτηριστικών της πλατφόρμας σε σχέση με ό,τι είχε αρχικά προδιαγραφεί. Τα χαρακτηριστικά που υλοποιήθηκαν τελικά είναι: + +\begin{itemize} + \item η εγγραφή χρήστη και η δημιουργία των τοπικών βάσεων του όπως περιγράφεται στις \ref{srs:functional-srs-sign-up} \& \ref{srs:functional-srs-create-user-databases} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signup} + \item η αυτόματη είσοδος χρήστη όπως περιγράφεται στην \ref{srs:functional-srs-sign-in} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signin} + \item η δημιουργία θέματος και η δημιουργία ψηφοφοριών όπως περιγράφεται στις \ref{srs:functional-srs-create-topic} \& \ref{srs:functional-srs-create-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-topic} + \item η περιήγηση στα υπάρχοντας θέματα όπως περιγράφεται στην \ref{srs:functional-srs-browse-topics} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-fetch-topic} + \item η δημοσίευση μηνύματος όπως περιγράφεται στην \ref{srs:functional-srs-create-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-post} + \item η επεξεργασία μηνύματος όπως περιγράφεται στην \ref{srs:functional-srs-modify-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-modify-post} + \item η ψήφιση σε ψηφοφορία όπως περιγράφεται στην \ref{srs:functional-srs-vote-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-in-poll} + \item η ψήφιση σε μηνύματα όπως περιγράφεται στην \ref{srs:functional-srs-vote-posts} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-post} + \item η διαγραφή των τοπικών δεδομένων όπως περιγράφεται στην \ref{srs:functional-srs-delete-local-data} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-delete-local-data} +\end{itemize} + +Τα παραπάνω αντιστοιχούν σε 11 ολοκληρωμένες από τις 13 προδιαγεγραμμένες ΛΑ ή πλήρωση 84.6\%, ποσοστό που θεωρείται από τους συγγραφείς επαρκές για την εξαγωγή συμπερασμάτων για τον χώρο των DApps και υπερβάλλων για τα πλαίσια ενός PoC. Στο παράρτημα \ref{screenshots-appendix} παρατίθενται τα στιγμιότυπα οθόνης των υλοποιημένων χαρακτηριστικών. + +Τα χαρακτηριστικά τα οποία παραλήφθηκαν είναι τα παρακάτω: + +\begin{itemize} + \item η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contracts για τα tokens τους όπως περιγράφεται στις \ref{srs:functional-srs-create-communities} \& \ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community} +\end{itemize} + +Τέλος, η ΜΛΑ που αφορά την ελαχιστοποίηση των fees (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε όλη τη διαδικασία σχεδιασμού και υλοποίησης. Η ΜΛΑ σχετικά με την αναβαθμισιμότητα των contracts (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε λόγω του χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. + +Η \ref{srs:non-functional-srs-maximum-decentraliztion} απαιτεί την μεγιστοποίηση της αποκέντρωσης της πλατφόρμας. Παρότι υπάρχουν μέρη τα οποία φαινομενικά έχει παραβιαστεί, όπως η διάθεση της εφαρμογής και των contract artifacts μέσω κεντροποιημένων servers καθώς και η ύπαρξη του rendezvous server, στην πραγματικότητα έχει ακολουθηθεί σε ικανοποιητικό βαθμό. Σχετικά με την εφαρμογή και τα contracts, πάρθηκε η απόφαση να διατεθούν μέσω των αντίστοιχων servers επειδή αυτό προσφέρει μεγάλη ευελιξία και ευκολία στην ανάπτυξη. Θα μπορούσαν εύκολα να διατεθούν μέσω αποκεντρωμένων συστημάτων όπως torrents ή το IPFS και αυτό παραμένει ένα ανοιχτό θέμα. Επίσης ανοιχτό θέμα παραμένει η ανάγκη ύπαρξης του rendezvous server. Λόγω της φύσης του πρωτοκόλλου IPFS και της λειτουργίας που επιτελεί ο server αυτός, είναι αδύνατον να παραληφθεί, ωστόσο είναι ανοιχτό ερευνητικό πεδίο η περαιτέρω αποκέντρωση του πρωτοκόλλου. +% https://mnot.github.io/avoiding-internet-centralization/draft-nottingham-avoiding-internet-centralization.html#name-necessary-centralization + +\subsection{Διαφορές σχεδιασμού-υλοποίησης} \label{subsection:4-6-1-design-implementation-differences} + +Σημαντικές διαφορές υπήρξαν επίσης στην διαδικασία υλοποίησης τόσο όσον αφορά τον αριθμό και τις λειτουργίες των διαφορετικών πακέτων λογισμικού όσο και τον χρονοπρογραμματισμό. Προστέθηκαν τρεις νέες υπηρεσίες, η υπηρεσία "Concordia Contracts Provider", ο προσαρμοσμένος IPFS pinner και η ιστοσελίδα "Concordia Guide". + +Η ανάγκη για τα νέα πακέτα λογισμικού προέκυψε κατά την πορεία υλοποίησης της διπλωματικής και προστέθηκαν στον χρονοπρογραμματισμό που είχε γίνει στην αρχή της εργασίας. Στην προσαρμογή αυτή βοήθησαν ιδιαίτερα οι Agile τακτικές που ακολουθήθηκαν και η προσαρμοστικότητα που προσφέρει το Scrum σε μεταβαλλόμενες απαιτήσεις. + +Τέλος, κατά την υλοποίηση έγινε γρήγορα αντιληπτή η αξία που προσφέρουν ένα δοκιμαστικό περιβάλλον (staging environment) σε συνδυασμό με ένα CI/CD σύστημα. Για το λόγο αυτό πάρθηκε η απόφαση να μεταφερθεί το sprint που αφορούσε αυτά πολύ νωρίτερα στην διαδικασία υλοποίησης, ώστε να μεγιστοποιηθεί η χρήση του. + +Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.6.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα tasks τα οποία υπήρχαν στο χρονοπρογραμματισμό από τη αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία δεν υλοποιήθηκαν. + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png} + \caption{Διαχωρισμός σε sprints} + \label{figure:4.6.design-implementation-differences-sprints} +\end{figure} diff --git a/chapters/5.conclusions-open-areas/5.0.conclusions-open-areas.tex b/chapters/5.conclusions-open-areas/5.0.conclusions-open-areas.tex new file mode 100644 index 0000000..a7bb80f --- /dev/null +++ b/chapters/5.conclusions-open-areas/5.0.conclusions-open-areas.tex @@ -0,0 +1,4 @@ +\chapter[Συμπεράσματα και ανοιχτά θέματα]{Συμπεράσματα \\και ανοιχτά θέματα}\label{chapter:5-conclusions-open-areas} + +\input{chapters/5.conclusions-open-areas/5.1.conclusions} +\input{chapters/5.conclusions-open-areas/5.2.open-areas} \ No newline at end of file diff --git a/chapters/5.conclusions-open-areas/5.1.conclusions.tex b/chapters/5.conclusions-open-areas/5.1.conclusions.tex new file mode 100644 index 0000000..7a6df34 --- /dev/null +++ b/chapters/5.conclusions-open-areas/5.1.conclusions.tex @@ -0,0 +1,20 @@ +\section{Συμπεράσματα}\label{section:5-1-conclusions} + +Συνοψίζοντας, μέσω της ανάπτυξης της πιλοτικής εφαρμογής Concordia γίνεται φανερό ότι είναι εφικτή η υλοποίηση μίας πλήρως αποκεντρωμένης κοινωνικής πλατφόρμας, η οποία να εκπληρώνει τον στόχο που τέθηκε στην \hyperref[section:1-4-thesis-goal]{ενότητα 1.4}, σύμφωνα με τον σχεδιασμό του \hyperref[chapter:3-application-design]{κεφαλαίου 3}. + +Μέσω της αρχιτεκτονικής αποκέντρωσης των τριών επιπέδων της τεχνολογικής στοίβας (βλ. \hyperref[section:3-2-technology-stack]{ενότητα 3.2}), δημιουργείται ένα πολιτικά αποκεντρωμένος ψηφιακός χώρος, ο οποίος κατοχυρώνει την ελευθερία του λόγου των συμμετεχόντων και παρέχει παντοδύναμες αυθεντικές δημοκρατικές διαδικασίες. + +Ωστόσο, θα πρέπει να επισημανθεί ότι η εφαρμογή χαρακτηρίζεται από ορισμένα μειονεκτήματα, τα οποία σχετίζονται, κυρίως, με την πρώιμη κατάσταση ανάπτυξης των επιλεγμένων τεχνολογιών: + +\begin{itemize} + \item Στο Application tier, μέσω της χρήσης του Ethereum, εισάγονται όλα εκείνα τα ζητήματα που συνοδεύουν επί του παρόντος το blockchain και τα smart contracts. Τα βασικότερα από αυτά είναι τα τέλη των συναλλαγών, η ανάγκη χρήσης επιπρόσθετων λογισμικών (π.χ. MetaMask) και η κλιμακοθετησιμότητά (scalability) των DApp. Σε γενικές γραμμές, το κλίμα στην παγκόσμια προγραμματιστική κοινότητα παραμένει αρκέτα πολωμένο ως προς το αν τελικά πλατφόρμες όπως το Ethereum θα μπορέσουν να ξεπεράσουν τα διάφορα προβλήματα και να ανταπεξέλθουν στις προσδοκίες. + + \begin{enumitemcenteredfigure} + \includegraphics[width=.50\textwidth]{assets/figures/chapter-5/5.1.xkcd_2030_voting_software} + \caption{\url{https://xkcd.com/2030/}} + \end{enumitemcenteredfigure} + + \item Στο Data tier, το IPFS και η OrbitDB αποτελούν επίσης ιδιαίτερα καινοτόμα λογισμικά και δε θεωρούνται ακόμα production-ready. Αυτό έχει ως αποτέλεσμα να εισάγουν με τη σειρά τους διάφορα προβλήματα, τα οποία σχετίζονται κυρίως με την εύρεση των peers (το οποίο βασίζεται προσωρινά σε signalling servers\footnote{Βλ. και \url{https://github.com/libp2p/js-libp2p/issues/385}.}) και το replication των δεδομένων. +\end{itemize} + +Τέλος, τονίζεται πως, παρ' όλες τις τρέχουσες δυσκολίες, οι προγραμματιστικές κοινότητες των παραπάνω τεχνολογιών εργάζονται αδιάκοπα για τη βελτίωση τους, ενώ παρόμοια εναλλακτικά project μπορούν ανά πάσα στιγμή να αντικαταστήσουν αυτά που επιλέχθηκαν στην τρέχουσα υλοποίηση. diff --git a/chapters/5.conclusions-open-areas/5.2.open-areas.tex b/chapters/5.conclusions-open-areas/5.2.open-areas.tex new file mode 100644 index 0000000..09274ad --- /dev/null +++ b/chapters/5.conclusions-open-areas/5.2.open-areas.tex @@ -0,0 +1,48 @@ +\section{Ανοιχτά θέματα}\label{section:5-2-open-areas} + +\subsection{Διαχείριση των τελών του Ethereum}\label{subsection:5-2-1-ethereum-fees-management} + +Οι ανάγκες κάθε υπολογιστικού συστήματος σε πόρους που σχετίζονται με τις διάφορες λειτουργίες του (π.χ. επεξεργασία, αποθήκευση δεδομένων, δίκτυα) μεταφράζονται σε κάποιο οικονομικό κόστος. Στην περίπτωση της παρούσας εφαρμογής, ενώ η αποθήκευση των δεδομένων διαμοιράζεται αυτοβούλως ανάμεσα στους συμμετέχοντες κόμβους, η χρήση του Ethereum απαιτεί από τα μέλη την καταβολή τελών για τη δημιουργία συναλλαγών. Αν και αυτά τα τέλη είναι απαραίτητα για τη λειτουργία του blockchain και την προάσπισή του από επιθέσεις, αποτελούν ισχυρό εμπόδιο για την ένταξη των τελικών χρηστών στο οικοσύστημα των αποκεντρωμένων εφαρμογών του Ethereum. + +Στα πλαίσια της εφαρμογής Concordia, η λήψη μέτρων για τη διαχείριση των τελών θεωρείται υψίστης σημασίας. Ωστόσο, η συμπερίληψη ενός τέτοιου μηχανισμού θα περιέπλεκε εξαιρετικά τον σχεδιασμό της και, ως εκ τούτου, λήφθηκε η απόφαση να συμπεριληφθεί ως πρόταση για μελλοντική της επέκταση. Ένας τέτοιος μηχανισμός θα παρείχε τη δυνατότητα στα μέλη της πλατφόρμας να τη χρησιμοποιούν χωρίς να κατέχουν ή να δαπανούν ETH. Αυτό θα ήταν εφικτό μέσω της χρήσης "μετασυναλλαγών"\footnote{Μετασυναλλαγή (meta-transaction) θεωρείται μία συναλλαγή που υπογράφεται από τον Ethereum λογαριασμό του χρήστη και προωθείται σε κάποιον τρίτο για να την εκτελέσει επί του blockchain.}, οι οποίες θα μεταβίβαζαν την αποπληρωμή των τελών στις κοινότητες που ανήκουν οι χρήστες. + +Αυτή τη στιγμή υπάρχουν ήδη προσεγγίσεις υλοποιήσεων τέτοιου είδους μηχανισμών, όπως το Gas Station Network\footnote{\url{https://opengsn.org/}}, ενώ η προγραμματιστική ομάδα του Ethereum εργάζεται ενεργά για την εγγενή υποστήριξη αυτής της δυνατότητας από την ίδια την πλατφόρμα. + +\subsection{Διανομή των Ethereum token}\label{subsection:5-2-2-token-distribution} + +Στον φυσικό κόσμο, η έγκυρη και ανώνυμη διανομή ενός συνόλου μοναδικών πιστοποιητικών αυθεντικοποίησης στα μέλη μίας κοινότητας θα μπορούσε να ήταν μία διαδικασία, η οποία να απαιτούσε την φυσική παρουσία των χρηστών και την επιλογή ενός λαχνού-πιστοποιητικού από μία κληρωτίδα. Σε αυτήν την περίπτωση θα έπρεπε είτε να υπήρχε ολομέλεια και, έτσι, διαμοιρασμός της εμπιστοσύνης σε όλα τα μέλη, είτε να υπήρχε μεταβίβαση της εμπιστοσύνης σε μία επιτροπή. + +Στον ψηφιακό κόσμο, το παραπάνω ζήτημα αποτελεί μία ιδιαίτερη πρόκληση με ποικίλες προσεγγίσεις σχετικά με την επιλογή των συστημάτων που θα χρησιμοποιηθούν, καθώς και των οντοτήτων στις οποίες θα εκχωρηθεί εμπιστοσύνη. + +Στην παρούσα εφαρμογή, η υλοποίηση μηχανισμών για την ανώνυμη διανομή των Ethereum token των κοινοτήτων με τρόπο που να μην απαιτείται η εκχώρηση εμπιστοσύνης σε τρίτους, τέθηκε εκτός του πλαισίου της εργασίας, εξαιτίας της παρέκκλισης από το κεντρικό θέμα και της πολυπλοκότητας της. Όπως είναι σχεδιασμένη αυτήν τη στιγμή, η Concordia δύναται να υποστηρίξει ποικίλες αφηρημένες διαδικασίες οι οποίες να κατοχυρώνουν την εγκυρότητα των εκάστοτε μελών, αλλά όχι την ανωνυμία τους. Εκείνη, όσο η διαδικασία βασίζεται σε κάποια κεντρική οντότητα αυθεντικοποίησης, δε μπορεί να διασφαλιστεί, καθώς θα απαιτεί πάντα την εκχώρηση εμπιστοσύνης από τον τελικό χρήστη στα υπολογιστικά συστήματα της πρώτης. Η εμφάνιση του προβλήματος οφείλεται στο γεγονός ότι η ανωνυμοποίηση των πιστοποιητικών θα πρέπει να λάβει χώρα εντός των των προαναφερθέντων συστημάτων, τα οποία, ως επί το πλείστον, θα είναι συγκεντρωτικής λογικής. + +Για παράδειγμα, έστω ότι μία κεντρική αρχή με δικό της σύστημα αυθεντικοποίησης αρχιτεκτονικής πελάτη-εξυπηρετητή αποφασίζει να συμμετάσχει στην πλατφόρμα της Concordia, δημιουργώντας μία κοινότητα και ορίζοντας ένα εξωτερικό smart contract για τα token των μελών της. Ο μηχανισμός διανομής των token θα μπορούσε να ήταν η εγγραφή του χρήστη στο κεντρικό σύστημα της αρχής, η δήλωση μίας Ethereum διεύθυνσής του και η αποστολή ενός token αυθεντικοποίησης σε αυτήν. Κάτι τέτοιο θα έδινε τη δυνατότητα στους διαχειριστές του συστήματος να εντοπίζουν με ευκολία τις πραγματικές ταυτότητες των μελών της κοινότητας πίσω από κάθε token της, αίροντας, έτσι, την ανωνυμία των τελευταίων. + +Λύση στο παραπάνω πρόβλημα μπορεί να επέλθει μόνο με την υλοποίηση μίας διαδικασίας ανωνυμοποίησης των token επί του blockchain. Αυτό απαιτεί την ύπαρξη ενός μηχανισμού στο οικοσύστημα του Ethereum, ο οποίος να παρέχει τη δυνατότητα μεταφοράς των token αποκρύπτοντας τις διευθύνσεις προέλευσης και προορισμού τους. Έτσι, οι χρήστες απλώς θα μετακινούσαν τα token που αρχικά παρέλαβαν σε μία διεύθυνση μη προσδιορίσιμη από τρίτους. + +Στο ευρύτερο οικοσύστημα των blockchain υπάρχουν ήδη υλοποιήσεις που προσφέρουν αυτήν την δυνατότητα επί του εγγενούς τους νομίσματος (π.χ. Monero, Zcash), ενώ διάφορες ομάδες εργάζονται ενεργά για την ανάπτυξη τέτοιων μηχανισμών και στο Ethereum. Αν και υπάρχουν διαφοροποιήσεις στις προσεγγίσεις τους, η κύρια τεχνολογία στην οποία βασίζονται είναι αυτή των λεγόμενων "zero knowledge proof", με επικρατέστερα πρωτόκολλα τα zk-SNARK και zk-STARK. Ως μία ήδη λειτουργική λύση τύπου μίκτη συναλλαγών θα μπορούσε να θεωρηθεί ο Tornado\footnote{\url{https://tornado.cash/}}, ο οποίος παρέχει τη δυνατότητα ανώνυμης μεταφοράς ETH ή ERC20 token αξιοποιώντας τα zk-SNARK.\cite{5.2-privacy-on-ethereum} + +\subsection{Εναλλακτικά συστήματα ψηφοφορίας}\label{subsection:5-2-3-alternative-voting-systems} + +Επί του παρόντος, η εφαρμογή λειτουργεί αποκλειστικά αμεσοδημοκρατικά, με καθολικές ψηφοφορίες και ισάξιες ψήφους, όπως ορίζεται από το έξυπνο συμβόλαιο \texttt{Voting.sol}. + +Τροποποιώντας την τρέχουσα υλοποίηση, η πλατφόρμα μπορεί να υποστηρίξει εναλλακτικά συστήματα ψηφοφορίας, μέσω της ανάπτυξης προσαρμοσμένων έξυπνων συμβολαίων. Αυτό θα έχει ως αποτέλεσμα να παρέχεται στην κάθε κοινότητα η δυνατότητα να ορίσει το voting smart contract που επιθυμεί, ανάλογα με τις ανάγκες και τις επιδιώξεις της. + +Μερικά συστήματα ψηφοφοριών που μπορούν να ενσωματωθούν (και ακόμα και να συνδυαστούν) στην πλατφόρμα είναι τα παρακάτω: + +\begin{itemize} + \item Ψήφοφορία με σειρά προτίμησης (ranked voting): το εκλογικό σώμα θα έχει τη δυνατότητα να ψηφίζει με σειρά προτίμησης μεταξύ των διαθέσιμων επιλογών των ψηφοφοριών. + \item Πολλαπλή ψήφος: ορισμένοι ψηφοφόροι θα έχουν ισχυρότερη ψήφο βάσει κάποιου κριτηρίου (π.χ. βάσει του reputation τους). + \item Έμμεση ψηφοφορία: κάθε μέλος θα ορίζει αντιπρόσωπο για μία ή περισσότερες ψηφοφορίες, για ορισμένο ή αόριστο χρονικό διάστημα. + \item Μερική ψηφοφορία: επιβολή περιρισμών στο δικαίωμα ψήφου, βάσει κάποιου κριτηρίου (π.χ. ημερομηνία εγγραφής χρήστη). +\end{itemize} + +Φυσικά τα παραπάνω είναι καθαρά ενδεικτικά, πράγμα που σημαίνει ότι θα είναι εφικτό να μπορούν να δημιουργούνται εντελώς διαφορετικά συμβόλαια συστημάτων ψηφοφορίας, ανά πάσα στιγμή και από τον οποιονδήποτε. Η δε σύνδεσή τους με την εφαρμογή θα είναι όμοια με τα ήδη υλοποιημένα, αφού η μοναδική απαιτούμενη ενέργεια θα είναι η αποθήκευση ενός pointer προς το voting contract της εκάστοτε κοινότητας. + +\subsection{Συστήματα απόδοσης εμπιστοσύνης}\label{subsection:5-2-4-reputation-systems} + +Μία επιπλέον προσθήκη στην εφαρμογή μπορεί είναι ένα σύστημα απόδοσης εμπιστοσύνης (reputation system). Μέσω ενός reputation system, οι χρήστες μπορούν να κερδίζουν ή να χάνουν βαθμούς εμπιστοσύνης, με τον τρόπο που ορίζεται από το εκάστοτε smart contract. + +Ορισμένες ενδεικτικές χρήσεις του είναι η συνεργασία του με τους μηχανισμούς που περιγράφονται στις υποενότητες \ref{subsection:5-2-1-ethereum-fees-management} και \ref{subsection:5-2-3-alternative-voting-systems}. Για παράδειγμα, η ισχύς της ψήφου ενός μέλους μίας κοινότητας ή το ποσό των τελών που καλείται να καταβάλλει στο Ethereum θα μπορούσαν να υπολογίζονται αναλογα με τον βαθμό εμπιστοσύνης που έχει αποκτήσει. + +Υιοθετώντας την αφηρημένη λογική που περιγράφηκε στα συστήματα ψηφοφορίας της προηγούμενης παραγράφου, είναι εφικτό να παρέχεται η δυνατότητα σε κάθε κοινότητα να επιλέγει μεταξύ ενός συνόλου διαφορετικών συστημάτων απόδοσης εμπιστοσύνης για τα μέλη της, μέσω εναλλακτικών reputation smart contract. Ήδη υπάρχει μία πλούσια γκάμα τέτοιων συστημάτων που μπορούν να υλοποιηθούν επί του Ethereum, με την ταξινομία τους να ορίζεται επί μίας πληθώρας ανεξάρτητων διαστάσεων.\cite{5.2-taxonomy-of-reputation-systems} Ωστόσο, η περαιτέρω ανάλυση τους, είναι θέμα που εκτείνεται πέρα από τα πλαίσια της παρούσας διπλωματικής εργασίας. diff --git a/chapters/5.conclusions/5.0.conclusions.tex b/chapters/5.conclusions/5.0.conclusions.tex deleted file mode 100644 index 5990f14..0000000 --- a/chapters/5.conclusions/5.0.conclusions.tex +++ /dev/null @@ -1,6 +0,0 @@ -\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} diff --git a/chapters/5.conclusions/5.1.problems-faced.tex b/chapters/5.conclusions/5.1.problems-faced.tex deleted file mode 100644 index e0bc091..0000000 --- a/chapters/5.conclusions/5.1.problems-faced.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Προβλήματα ανάπτυξης} diff --git a/chapters/5.conclusions/5.2.design-implementation-differences.tex b/chapters/5.conclusions/5.2.design-implementation-differences.tex deleted file mode 100644 index 3f750cc..0000000 --- a/chapters/5.conclusions/5.2.design-implementation-differences.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Διαφορές σχεδιασμού-υλοποίησης} diff --git a/chapters/5.conclusions/5.3.open-areas.tex b/chapters/5.conclusions/5.3.open-areas.tex deleted file mode 100644 index f1458b0..0000000 --- a/chapters/5.conclusions/5.3.open-areas.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Ανοιχτά θέματα} diff --git a/chapters/5.conclusions/5.4.conclusion.tex b/chapters/5.conclusions/5.4.conclusion.tex deleted file mode 100644 index 779150e..0000000 --- a/chapters/5.conclusions/5.4.conclusion.tex +++ /dev/null @@ -1 +0,0 @@ -\section{Επίλογος} diff --git a/chapters/appendix/appendix.tex b/chapters/appendix/appendix.tex new file mode 100644 index 0000000..ab50121 --- /dev/null +++ b/chapters/appendix/appendix.tex @@ -0,0 +1 @@ +\input{chapters/appendix/screenshots-appendix} diff --git a/chapters/appendix/screenshots-appendix.tex b/chapters/appendix/screenshots-appendix.tex new file mode 100644 index 0000000..cbb7954 --- /dev/null +++ b/chapters/appendix/screenshots-appendix.tex @@ -0,0 +1,3 @@ +\chapter{Στιγμιότυπα οθόνης πλατφόρμας} \label{screenshots-appendix} + +TODO: add screenshots of application diff --git a/custom-commands/appendix-overrides.tex b/custom-commands/appendix-overrides.tex new file mode 100644 index 0000000..1076d8b --- /dev/null +++ b/custom-commands/appendix-overrides.tex @@ -0,0 +1,2 @@ +\renewcommand{\appendixtocname}{Παραρτήματα} +\renewcommand{\appendixpagename}{Παραρτήματα} diff --git a/custom-commands/custom-enumitem.tex b/custom-commands/custom-enumitem.tex new file mode 100644 index 0000000..d3801c2 --- /dev/null +++ b/custom-commands/custom-enumitem.tex @@ -0,0 +1,13 @@ +% Centered figure inside an item list +\newenvironment{enumitemcenteredfigure} +{ + \begin{minipage}{\linewidth} + \centering + \begin{figure}[H] + \centering + } + { + \end{figure} + \end{minipage} + \medskip +} diff --git a/custom-commands/custom-listings.tex b/custom-commands/custom-listings.tex new file mode 100644 index 0000000..593578a --- /dev/null +++ b/custom-commands/custom-listings.tex @@ -0,0 +1,10 @@ +\newtcbinputlisting{\simplelisting}[2][]{ + listing file={assets/code/#2}, + title={}, + listing only, + boxrule=1pt, + minted language=javascript, + minted style=default, + minted options={breaklines, breaksymbol={}}, + #1 +} \ No newline at end of file diff --git a/custom-commands/custom-logos.tex b/custom-commands/custom-logos.tex new file mode 100644 index 0000000..23606a3 --- /dev/null +++ b/custom-commands/custom-logos.tex @@ -0,0 +1,7 @@ +\newcommand{\logo}[2]{ + \begin{figure}[H] + \centering + \includegraphics[width=.12\textwidth]{assets/figures/#1} + \caption{#2} + \end{figure} +} \ No newline at end of file diff --git a/custom-commands/custom-spheading.tex b/custom-commands/custom-spheading.tex new file mode 100644 index 0000000..d93cef4 --- /dev/null +++ b/custom-commands/custom-spheading.tex @@ -0,0 +1,6 @@ +% Command taken from this stackexchange answer +% https://tex.stackexchange.com/a/96913 +\newcommand{\spheading}[3]{\rotatebox{#1}{\parbox{#2}{\raggedright #3}}} + +% Usage: +% \spheading[][]{} \ No newline at end of file diff --git a/custom-commands/custom-title.tex b/custom-commands/custom-title-page.tex similarity index 94% rename from custom-commands/custom-title.tex rename to custom-commands/custom-title-page.tex index a8723a2..d7101a6 100644 --- a/custom-commands/custom-title.tex +++ b/custom-commands/custom-title-page.tex @@ -20,19 +20,20 @@ \renewcommand\maketitle{ {\raggedright \begin{center} +\thispagestyle{empty} % Make the logo \makeatletter \centering\includegraphics[height=5cm]{\@logo} % Make the title -\vspace{3.44cm} +\vspace{3cm} {\huge \@title} % The authors, school and university name -\vspace{3.72cm} +\vspace{3cm} {\Large \@author} -\vspace{3.94cm} +\vspace{3cm} \begin{tabular}{rl} \textit{Επιβλέπων} & \@supervisor diff --git a/custom-commands/srs-commands.tex b/custom-commands/srs-commands.tex new file mode 100644 index 0000000..2d584ae --- /dev/null +++ b/custom-commands/srs-commands.tex @@ -0,0 +1,9 @@ +\newcommand{\sysReqItem}[7] { + \item #1 \ #2 + \begin{itemize}[label={}, leftmargin=0pt] + \item \textbf{Περιγραφή}: #3 + \item \textbf{User Priority (#4/5)}: #5 + \item \textbf{Technical Priority (#6/5)}: #7 + \end{itemize} + \medskip +} \ No newline at end of file diff --git a/custom-commands/use-case-commands.tex b/custom-commands/use-case-commands.tex new file mode 100644 index 0000000..2fc032b --- /dev/null +++ b/custom-commands/use-case-commands.tex @@ -0,0 +1,61 @@ +\newcommand{\useCaseTable}[8] {{ + \begin{table}[H] + \begin{center} + \begin{tabularx}{\textwidth}{l X} + \toprule + \multicolumn{2}{c}{\textbf{#1}} \\ [0.5ex] + \midrule + Σύντομη περιγραφή & #2 \\ [0.5ex] + Αναφορά ΛΑ & #3 \\ [0.5ex] + Αναφορά ΜΛΑ & #4 \\ [0.5ex] + Πυροδότηση δραστηριότητας & #5 \\ [0.5ex] + Προϋπόθεση & #6 \\ [0.5ex] + \bottomrule + \end{tabularx} + \end{center} + \caption{#7} + #8 + \end{table} +}} + +\newcommand{\useCaseBaseFlowTable}[4] {{ + \begin{table}[H] + \begin{center} + \begin{tabularx}{\textwidth}{p{2.25cm} X X} + \toprule + \multicolumn{3}{c}{\textbf{Βασική ροή}} \\ [0.5ex] + \midrule + \textbf{Γραμμή} & \textbf{Ενέργεια χρήστη συστήματος} & \textbf{Απάντηση Συστήματος} \\ [0.5ex] + \midrule + #1 + \midrule + \textbf{Μετέπειτα κατάσταση:} & \multicolumn{2}{p{\dimexpr\textwidth-2\tabcolsep-0.8pt-2.25cm}}{#2} \\ [0.5ex] + \bottomrule + \end{tabularx} + \end{center} + \caption{#3} + #4 + \end{table} +}} + +\newcommand{\useCaseAlternateFlowTable}[7] {{ + \begin{table}[H] + \begin{center} + \begin{tabularx}{\textwidth}{l X X} + \toprule + \multicolumn{3}{l}{\textbf{Εναλλακτική ροή {#1}:} {#2}} \\ [0.5ex] + \midrule + \multicolumn{3}{p{\dimexpr\textwidth-2\tabcolsep-0.8pt}}{{#3}} \\ [0.5ex] + \midrule + \textbf{Γραμμή} & \textbf{Ενέργεια χρήστη συστήματος} & \textbf{Απάντηση Συστήματος} \\ [0.5ex] + \midrule + #4 \\ [0.5ex] + \midrule + \multicolumn{3}{p{\dimexpr\textwidth-2\tabcolsep-0.8pt}}{{#5}} \\ [0.5ex] + \bottomrule + \end{tabularx} + \end{center} + \caption{#6} + #7 + \end{table} +}} diff --git a/greek-enumerate.sty b/custom-packages/greek-enumerate.sty similarity index 95% rename from greek-enumerate.sty rename to custom-packages/greek-enumerate.sty index 2f7dcde..aee07ab 100644 --- a/greek-enumerate.sty +++ b/custom-packages/greek-enumerate.sty @@ -1,5 +1,5 @@ % https://github.com/jcommelin/greek_enumerate -\ProvidesPackage{greek-enumerate} +\ProvidesPackage{custom-packages/greek-enumerate} \RequirePackage{enumitem} \makeatletter diff --git a/examples-page.tex b/examples-page.tex deleted file mode 100644 index e5b1c37..0000000 --- a/examples-page.tex +++ /dev/null @@ -1,21 +0,0 @@ -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 \ No newline at end of file diff --git a/misc/README.md b/misc/README.md deleted file mode 100644 index 7540c93..0000000 --- a/misc/README.md +++ /dev/null @@ -1,2 +0,0 @@ -Contents -- *carbon-config.json*: A configuration file for https://carbon.now.sh/ diff --git a/misc/carbon-config.json b/misc/carbon-config.json deleted file mode 100644 index dafc479..0000000 --- a/misc/carbon-config.json +++ /dev/null @@ -1 +0,0 @@ -{"paddingVertical":"0px","paddingHorizontal":"0px","backgroundImage":null,"backgroundImageSelection":null,"backgroundMode":"color","backgroundColor":"rgba(0,0,0,0)","dropShadow":true,"dropShadowOffsetY":"20px","dropShadowBlurRadius":"68px","theme":"material","windowTheme":"none","language":"javascript","fontFamily":"Hack","fontSize":"14px","lineHeight":"133%","windowControls":false,"widthAdjustment":false,"lineNumbers":false,"firstLineNumber":1,"exportSize":"2x","watermark":false,"squaredImage":false,"hiddenCharacters":false,"name":"","width":915} \ No newline at end of file diff --git a/misc/hyphenations.tex b/misc/hyphenations.tex new file mode 100644 index 0000000..c955dff --- /dev/null +++ b/misc/hyphenations.tex @@ -0,0 +1,4 @@ +\begin{hyphenrules}{english} + % Custom hyphenations go here + % \hyphenation{ar-ti-fa-cts} +\end{hyphenrules} diff --git a/misc/packages.tex b/misc/packages.tex new file mode 100644 index 0000000..131895a --- /dev/null +++ b/misc/packages.tex @@ -0,0 +1,57 @@ +% 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} %TODO: possibly unused (remove?) + +% Paper size and margins +\usepackage{geometry} + +% --- Languages & Fonts --- +\usepackage{polyglossia} +\input{misc/polyglossia-setup} +\usepackage{fontawesome5} + +% --- Styling --- +\usepackage{hyperref} % Extensive support for hypertext +\usepackage{authblk} % Support for footnote style author/affiliation +\usepackage{enumitem} % For item lists +\usepackage{custom-packages/greek-enumerate} % Greek enumeration for ordered item lists +\usepackage{float} % For \begin{figure}[H] +\usepackage[font={footnotesize, it}]{caption} % For captions under figures +\usepackage{tabularx} % Support for break lines inside table cells +\usepackage{multirow, booktabs} % Useful table styling commands +\usepackage[flushleft]{threeparttable} % Table footnotes +\usepackage[dvipsnames]{xcolor} % Text colors +\usepackage{minted} % Source code highlighting (make sure to add -shell-escape flag!) +\usepackage [autostyle]{csquotes} +\usepackage{tcolorbox} % Colored boxes +\tcbuselibrary{minted} % Make tcolorbox work with minted +\usepackage{graphicx} +\usepackage{appendix} % Appendix helpers + +% --- TikZ and UML diagrams +\usepackage{pgf-umlsd} + +% --- Bibliography --- +\usepackage[sorting=none]{biblatex} + +% --- Custom commands --- +\input{custom-commands/custom-title-page} +\input{custom-commands/custom-lists} +\input{custom-commands/custom-listings} +\input{custom-commands/custom-logos} +\input{custom-commands/custom-enumitem} +\input{custom-commands/srs-commands} +\input{custom-commands/use-case-commands} +\input{custom-commands/custom-spheading} +\input{custom-commands/appendix-overrides} + +% --- Custom styles --- +\renewcommand{\arraystretch}{1.2} % Streches the table row height so text is not crammed between the lines +\MakeOuterQuote{"} % For csquotes package + +% Hyphenations +\input{misc/hyphenations} diff --git a/languages-fonts.sty b/misc/polyglossia-setup.tex similarity index 50% rename from languages-fonts.sty rename to misc/polyglossia-setup.tex index 015e2b2..3a68988 100644 --- a/languages-fonts.sty +++ b/misc/polyglossia-setup.tex @@ -1,11 +1,8 @@ -\ProvidesPackage{languages-fonts} +\setmainfont{Linux Libertine O} +\setsansfont{Linux Libertine O} -\usepackage{polyglossia} - -\newfontfamily\greekfont[Script=Greek]{Linux Libertine O} -\newfontfamily\greekfontsf[Script=Greek]{Linux Libertine O} \newfontfamily\greekfonttt[ - Script=Greek, + Script=Default, Scale=MatchLowercase, Path = assets/fonts/, Extension = .ttf, diff --git a/thesis-details.tex b/misc/title-page.tex similarity index 77% rename from thesis-details.tex rename to misc/title-page.tex index 0f3fd74..20713d8 100644 --- a/thesis-details.tex +++ b/misc/title-page.tex @@ -1,6 +1,6 @@ \universityLogo{assets/figures/auth-logo.png} -\title{Αυτόνομο αμεσοδημοκρατικό κοινωνικό δίκτυο βασισμένο σε τεχνολογίες αποκέντρωσης} +\title{Αυτόνομο κοινωνικό δίκτυο βασισμένο σε τεχνολογίες αποκέντρωσης} \author[1]{Νικολαΐδης Παναγιώτης} \author[2]{Φανάκης Απόστολος} diff --git a/packages.tex b/packages.tex deleted file mode 100644 index 9046ee9..0000000 --- a/packages.tex +++ /dev/null @@ -1,22 +0,0 @@ -% 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[backend=bibtex, sorting=none]{biblatex} -\usepackage{csquotes} -\usepackage{listings} % Typeset source code listings - -% Custom commands -\input{custom-commands/custom-title} -\input{custom-commands/custom-lists} - diff --git a/thesis-general.sty b/thesis-general.sty deleted file mode 100644 index 853fef8..0000000 --- a/thesis-general.sty +++ /dev/null @@ -1,12 +0,0 @@ -\ProvidesPackage{thesis-general} - -% --- Languages & Fonts --- -\usepackage{languages-fonts} - -% --- Styling --- -\usepackage{hyperref} % Extensive support for hypertext -\usepackage{authblk} % Support for footnote style author/affiliation -\usepackage{enumitem} % For item lists -\usepackage{greek-enumerate} % Greek enumeration for ordered item lists -\usepackage{float} % For \begin{figure}[H] -\usepackage[font={footnotesize, it}]{caption} % For captions under figures \ No newline at end of file diff --git a/thesis.pdf b/thesis.pdf index 61ea23b..a7a1002 100644 Binary files a/thesis.pdf and b/thesis.pdf differ diff --git a/thesis.tex b/thesis.tex index eb6a9bf..23cff50 100644 --- a/thesis.tex +++ b/thesis.tex @@ -1,7 +1,7 @@ -\documentclass{report} +\documentclass[12pt]{report} % Custom packages -\input{packages} +\input{misc/packages} % Sets up the bib files \input{bibliography/bib-setup} @@ -9,10 +9,11 @@ % Paper size and margins \geometry{a4paper, top=2.5cm, bottom=2.5cm, left=2.2cm,right=2.2cm} -%TODO: check if it works or remove -\graphicspath{{assets/figures}} +% Make title page +\input{misc/title-page} -\input{thesis-details} +% Avoid reset of footnote counter through chapters +\counterwithout{footnote}{chapter} \begin{document} @@ -28,7 +29,12 @@ \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} +\input{chapters/5.conclusions-open-areas/5.0.conclusions-open-areas} + +\appendix +\appendixpage +\addappheadtotoc +\input{chapters/appendix/appendix} % end of thesis body % -------------------------- diff --git a/tikz/chapter-3/3-6-use-case-create-community-alternate-flow-1-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-create-community-alternate-flow-1-sequence-diagram.tex new file mode 100644 index 0000000..2f04687 --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-create-community-alternate-flow-1-sequence-diagram.tex @@ -0,0 +1,21 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[4]{concordia}{:Concordia}{} + \newinst[4]{eth}{:Ethereum}{} + \newinst{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Create community}{concordia}{Community creation form} + \end{call} + + \begin{call}{actor}{Add external contract}{concordia}{External contract form} + \end{call} + + \begin{call}{actor}{Submit}{concordia}{Created community page} + + \begin{call}{concordia}{Create community}{eth}{New community ID} + \end{call} + + \begin{call}{concordia}{Connect external contract}{eth}{} + \end{call} + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-create-community-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-create-community-sequence-diagram.tex new file mode 100644 index 0000000..144033b --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-create-community-sequence-diagram.tex @@ -0,0 +1,16 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[3]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Create community}{concordia}{Community creation form} + \end{call} + + \begin{call}{actor}{Submit}{concordia}{Created community page} + + \begin{call}{concordia}{Create community}{eth}{New community ID} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-create-post-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-create-post-sequence-diagram.tex new file mode 100644 index 0000000..8b21908 --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-create-post-sequence-diagram.tex @@ -0,0 +1,19 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[3]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Create post}{concordia}{Post creation form} + \end{call} + + \begin{call}{actor}{Submit}{concordia}{Updated topic page} + + \begin{call}{concordia}{Create post}{eth}{New post ID} + \end{call} + + \begin{call}{concordia}{Save post information}{orbit}{} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-create-topic-alternate-flow-1-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-create-topic-alternate-flow-1-sequence-diagram.tex new file mode 100644 index 0000000..11dfa45 --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-create-topic-alternate-flow-1-sequence-diagram.tex @@ -0,0 +1,28 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[4]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Create topic}{concordia}{Topic creation form} + \end{call} + + \begin{call}{actor}{Add poll}{concordia}{Poll creation form} + \end{call} + + \begin{call}{actor}{Submit}{concordia}{New topic-poll page} + + \begin{call}{concordia}{Create topic}{eth}{New topic ID} + \end{call} + + \begin{call}{concordia}{Add poll to topic}{eth}{} + \end{call} + + \begin{call}{concordia}{Save topic information}{orbit}{} + \end{call} + + \begin{call}{concordia}{Save poll information}{orbit}{} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-create-topic-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-create-topic-sequence-diagram.tex new file mode 100644 index 0000000..9a4a269 --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-create-topic-sequence-diagram.tex @@ -0,0 +1,19 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[4]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Create topic}{concordia}{Topic creation form} + \end{call} + + \begin{call}{actor}{Submit}{concordia}{New topic page} + + \begin{call}{concordia}{Create topic}{eth}{New topic ID} + \end{call} + + \begin{call}{concordia}{Save topic information}{orbit}{} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-delete-local-data-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-delete-local-data-sequence-diagram.tex new file mode 100644 index 0000000..b9edcdd --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-delete-local-data-sequence-diagram.tex @@ -0,0 +1,16 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[4]{concordia}{:Concordia}{} + \newinst[1]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Delete local data}{concordia}{Delete confirmation form} + \end{call} + + \begin{call}{actor}{Submit}{concordia}{} + + \begin{call}{concordia}{Delete local DBs}{orbit}{} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram.tex new file mode 100644 index 0000000..e7b0aef --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram.tex @@ -0,0 +1,41 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[2]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Fetch topic}{concordia}{Topic} + + \begin{call}{concordia}{Get topic}{eth}{Topic} + \end{call} + + \begin{call}{concordia}{Get poll}{eth}{Poll} + \end{call} + + \begin{call}{concordia}{Get topic post IDs}{eth}{Post IDs} + \end{call} + + \begin{call}{concordia}{Get posts loop}{concordia}{Posts} + + \begin{call}{concordia}{Get post}{eth}{Post} + \end{call} + + \end{call} + + \begin{call}{concordia}{Retrieve topic information}{orbit}{} + \end{call} + + \begin{call}{concordia}{Retrieve poll information}{orbit}{} + \end{call} + + \begin{call}{concordia}{Validate poll information}{concordia}{} + \end{call} + + \begin{call}{concordia}{Retrieve posts information loop}{concordia}{Posts information} + + \begin{call}{concordia}{Retrieve post information}{orbit}{} + \end{call} + + \end{call} + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-fetch-topic-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-fetch-topic-sequence-diagram.tex new file mode 100644 index 0000000..15f0b95 --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-fetch-topic-sequence-diagram.tex @@ -0,0 +1,32 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[2]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Fetch topic}{concordia}{Topic} + + \begin{call}{concordia}{Get topic}{eth}{Topic} + \end{call} + + \begin{call}{concordia}{Get topic post IDs}{eth}{Post IDs} + \end{call} + + \begin{call}{concordia}{Get posts loop}{concordia}{Posts} + + \begin{call}{concordia}{Get post}{eth}{Post} + \end{call} + + \end{call} + + \begin{call}{concordia}{Retrieve topic information}{orbit}{} + \end{call} + + \begin{call}{concordia}{Retrieve posts information loop}{concordia}{Posts information} + + \begin{call}{concordia}{Retrieve post information}{orbit}{} + \end{call} + + \end{call} + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-modify-post-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-modify-post-sequence-diagram.tex new file mode 100644 index 0000000..c37303b --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-modify-post-sequence-diagram.tex @@ -0,0 +1,16 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[4]{concordia}{:Concordia}{} + \newinst[1]{eth}{:Ethereum}{} + \newinst[2]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Modify post}{concordia}{Post modification form} + \end{call} + + \begin{call}{actor}{Submit}{concordia}{Updated topic page} + + \begin{call}{concordia}{Save modified post information}{orbit}{} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-sign-in-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-sign-in-sequence-diagram.tex new file mode 100644 index 0000000..9473ffb --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-sign-in-sequence-diagram.tex @@ -0,0 +1,16 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[2]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Fetch page}{concordia}{} + + \begin{call}{concordia}{Get user}{eth}{User information} + \end{call} + + \begin{call}{concordia}{Create databases}{orbit}{} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-sign-up-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-sign-up-sequence-diagram.tex new file mode 100644 index 0000000..0220bf1 --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-sign-up-sequence-diagram.tex @@ -0,0 +1,26 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[4]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + \newinst[1]{orbit}{:OrbitDb}{} + + \begin{call}{actor}{Sign up}{concordia}{Sign up form} + \end{call} + + \begin{call}{actor}{Submit}{concordia}{Personal information form} + + \begin{call}{concordia}{Create user}{eth}{New user ID} + \end{call} + + \begin{call}{concordia}{Create databases}{orbit}{} + \end{call} + + \end{call} + + \begin{call}{actor}{Submit}{concordia}{Home page} + + \begin{call}{concordia}{Save personal information}{orbit}{} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-vote-in-poll-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-vote-in-poll-sequence-diagram.tex new file mode 100644 index 0000000..2fb9620 --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-vote-in-poll-sequence-diagram.tex @@ -0,0 +1,12 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[3]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + + \begin{call}{actor}{Submit poll vote}{concordia}{Updated topic page} + + \begin{call}{concordia}{Add poll vote}{eth}{} + \end{call} + + \end{call} +\end{sequencediagram} diff --git a/tikz/chapter-3/3-6-use-case-vote-post-sequence-diagram.tex b/tikz/chapter-3/3-6-use-case-vote-post-sequence-diagram.tex new file mode 100644 index 0000000..404c21b --- /dev/null +++ b/tikz/chapter-3/3-6-use-case-vote-post-sequence-diagram.tex @@ -0,0 +1,12 @@ +\begin{sequencediagram} + \newthread{actor}{Actor}{} + \newinst[3]{concordia}{:Concordia}{} + \newinst[2]{eth}{:Ethereum}{} + + \begin{call}{actor}{Submit post vote}{concordia}{Updated topic page} + + \begin{call}{concordia}{Add post vote}{eth}{} + \end{call} + + \end{call} +\end{sequencediagram}