ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΕΡΓΑΣΤΗΡΙΟ ΕΠΕΞΕΡΓΑΣΙΑΣ ΠΛΗΡΟΦΟΡΙΑΣ ΚΑΙ ΥΠΟΛΟΓΙΣΜΩΝ ΟΜΑΔΑ ΚΑΤΑΝΟΗΣΗΣ ΠΟΛΥΜΕΣΩΝ
ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ
ΑΠΟΚΕΝΤΡΩΜΕΝΗ ΥΠΗΡΕΣΙΑ ΔΙΑΘΕΣΗΣ ΕΙΣΙΤΗΡΙΩΝ ΣΤΟ EOS BLOCKCHAIN
Σταύρος Αντωνιάδης ΑΕΜ:8279
υπό την επίβλεψη του Καθηγητή Αναστάσιου Ντελόπουλου
και του Κωνσταντίνου Καρασσάβα Θεσσαλονίκη, 23 Σεπτεμβρίου 2019
When you do enough research, the story almost writes itself. Lines of development spring loose and you’ll have choices galore. Robert Mckee
Περίληψη Μελετήσαμε τη βιομηχανία των εισιτηρίων και τα προβλήματα που αυτή παρουσιάζει λόγω της πολύπλοκης και διαιρεμένης δομής της και την έλλειψη διαφάνειας που υπάρχει σε αυτήν. Μοχλεύοντας το Eos blockchain και τα έξυπνα συμβόλαια δημιουργήσαμε ένα πρωτόκολλο δημιουργίας, έκδοσης, μεταφοράς και μεταπώλησης εισιτηρίων με συγκεκριμένους κανόνες που ορίζει ο εκάστοτε δημιουργός των εισιτηρίων, το οποίο λειτουργεί κάτω από συνθήκες διαφάνειας και ασφάλειας. Ακόμα δημιουργήσαμε μια διασυνδεδεμένη διεπαφή με το πρωτόκολλο ώστε ο χρήστης να είναι σε θέση να επικοινωνήσει με αυτό. Θέματα ασφαλείας στο επίπεδο τόσο των έξυπνων συμβολαίων όσο και στο επίπεδο της εφαρμογής μελετήθηκαν και οι τεχνικές αποφυγής τους εφαρμόστηκαν. Και τέλος, αξιολογήσαμε την αποδοτικότητα των μεθόδων και τεχνικών που ακολουθήσαμε.
Σταύρος Αντωνιάδης [email protected] Σεπτέμβριος, 2019
i
Abstract We study the ticketing industry and the problems that arrive due to the complex and fragmented structure of it and the lack of transparency that lives inside of it. We leverage the Eos blockchain and the smart contracts to create a protocol that transparently and securely performs and provides the possibility of creation, issuing, transferring, reselling and invalidating tickets in respect with the rules that every creator establishes among a variety of choices. Along with the protocol we implemented an app for the user to easily and frictionless interact with the protocol. Security research was conducted both in the level of smart contracts and in the level of the app and best practices have been followed. Finally, we evaluate the efficiency of our implementation.
ii
Ευχαριστίες Σε αυτό το σημείο θα ήθελα να ευχαριστήσω τον καθηγητή μου κύριο Αναστάσιο Ντελόπουλο που μου έδωσε τη δυνατότητα να συνεργαστούμε με σκοπό την εκπόνηση της διπλωματικής μου εργασίας, καθώς και για την καθοδήγηση του.
Ακόμα θα ήθελα να ευχαριστήσω τον κύριο Κωνσταντίνο Καρασάββα για την καθοδήγηση και τις συμβουλές του καθ΄ όλη τη διάρκεια της εργασίας.
Και τέλος, θα ήθελα να ευχαριστήσω την οικογένεια μου για την υποστήριξη και την εμπιστοσύνη τους.
iii
Περιεχόμενα
Περίληψη ...... i Abstract ...... ii Ευχαριστίες ...... iii
1 Εισαγωγή ...... 1 1.1 Υπάρχοντα Προβλήματα ...... 1 1.2 Υφιστάμενες Λύσεις ...... 2 1.2.1 Τεχνολογία ...... 3 1.2.2 Νομοθεσία ...... 4 1.2.3 Επιβολή κανόνων από τους εμπλεκόμενους ...... 5 1.3 Προτεινόμενη Λύση ...... 5 1.4 Διάρθρωση ...... 6
2 Υπόβαθρο ...... 7 2.1 Bitcoin ...... 7 2.2 Blockchain ...... 7 2.2.1 Χαρακτηριστικά ...... 8 2.2.2 Τύποι Blockchain...... 8 2.2.3 Αλγόριθμοι συναίνεσης ...... 9 2.3 Κρυπτογραφία ...... 10 2.3.1 Cryptographic Hash Function ...... 10 2.3.2 Public Key Cryptography ...... 10 2.4 Token Models ...... 12 2.4.1 Κατηγορίες νομισμάτων ...... 12 2.4.2 ΕRC tokens ...... 12 2.5 Eos Blockchain ...... 13 2.5.1 Τι είναι το Eos? ...... 13 2.5.2 Στοίβα (Stack) ...... 14 2.5.3 Λογαριασμοί και Άδειες (Accounts and Permissions) ...... 15 2.5.4 Συναλλαγές (Transactions) ...... 16 2.5.5 Πόροι (Resources) ...... 18 2.5.6 Smart Contracts ...... 19
3 Τεχνικά Πλαίσια & Εργαλεία ...... 21 3.1 Βασικά Εργαλεία ...... 21 3.1.1 Eosio ...... 21 3.1.2 Eosio.cdt ...... 21 3.1.3 Universal Authenticator Library (UAL Core) ...... 22 3.1.4 Eos.js ...... 22 3.1.5 React ...... 22 3.1.6 Redux ...... 22
iv
3.2 Βασικές Τεχνολογίες ...... 23 3.2.1 Τεχνολογίες Web ...... 23 3.2.2 C++ ...... 23
4 Eos & Security ...... 24 4.1 Επιθέσεις στο επίπεδο του Δικτύου ...... 24 4.2 Επιθέσεις και βέλτιστες πρακτικές στο επίπεδο των smart contract ...... 25 4.2.1 Numerical Overflow ...... 25 4.2.2 Authorization Check ...... 26 4.2.3 Apply Check...... 26 4.2.4 Transfer Error Prompt ...... 27 4.2.5 Random Number Generator ...... 27
5 Υλοποίηση ...... 29 5.1 Επιχειρησιακή Λογική ...... 29 5.2 Smart Contract ...... 30 5.2.1 Setconfig action ...... 30 5.2.2 Create action ...... 30 5.2.3 Issue action ...... 32 5.2.4 Burn action ...... 32 5.2.6 Transfer action ...... 33 5.2.5 Listsale action ...... 33 5.2.7 Closesale action ...... 33 5.2.8 Buy action ...... 33 5.2.9 Invalidate action ...... 34 5.3 Εφαρμογή ...... 34 5.3.1 Javascript Scripts ...... 34 5.3.2 Create Event διεπαφή ...... 35 5.3.3 Discover διεπαφή ...... 35 5.3.4 Buy Tickets διεπαφή ...... 36 5.3.4 My Tickets διεπαφή ...... 37 5.3.5 View Tickets διεπαφή ...... 37 5.3.6 Sell Tickets οθόνη ...... 38 5.3.7 Scan Tickets οθόνη ...... 38
6 Αξιολόγηση ...... 39 6.1 Ασφάλεια ...... 39 6.2 Συλλογική Αξιολόγηση ...... 39
7 Συμπεράσματα & Μελλοντικές Προεκτάσεις ...... 41 7.1 Συμπεράσματα ...... 41 7.2 Μελλοντικές Προεκτάσεις ...... 41
Αναφορές ...... 43
v
Λίστα Εικόνων
Εικόνα 1 Μια τυπική αλληλεπίδραση με το Eos Blockchain ...... 14 Εικόνα 2 Αλληλεπίδραση λογαριασμών διαφορετικού είδους ...... 15 Εικόνα 3 Παράδειγμα λογαριασμού πολλών υπογραφών ...... 16 Εικόνα 4 Ένα παράδειγμα συναλλαγής στο Eos ...... 19 Εικόνα 5 Δείγμα “Hello” smart contract ...... 20 Εικόνα 6 Αρχιτεκτονική της UAL βιβλιοθήκης...... 22 Εικόνα 7 Η διαδικασία εκτέλεσης μιας τυπικής συναλλαγής στο Eos ...... 24 Εικόνα 8 Η ροή εκτέλεσης μίας deferred συναλλαγής ...... 25 Εικόνα 9 Ευπαθής Apply function στο EOSBet ...... 27 Εικόνα 10 Η ευπαθής συνάρτηση του EOSDice ...... 28 Εικόνα 11 Μία πιθανή ροή της υλοποίησης ...... 29 Εικόνα 12 Create Event διεπαφή ...... 35 Εικόνα 13 Discover διεπαφή ...... 36 Εικόνα 14 Buy Tickets οθόνη ...... 36 Εικόνα 15 My Tickets οθόνη ...... 37 Εικόνα 16 View Tickets οθόνη ...... 37 Εικόνα 17 Sell Tickets οθόνη ...... 38 Εικόνα 18 Scan Tickets οθόνη ...... 38
vi
Λίστα Πινάκων
Πίνακας 1 tokenconfigs πίνακας ...... 30 Πίνακας 2 ticketsstats πίνακας ...... 32 Πίνακας 3 tickets πίνακας ...... 32 Πίνακας 4 asks πίνακας ...... 33 Πίνακας 5 accounts πίνακας ...... 34 Πίνακας 6 Cpu, Net cost of actions ...... 40
vii
1 Εισαγωγή
Τα εισιτήρια των εκδηλώσεων ψυχαγωγίας διατίθενται για αγορά προς τους καταναλωτές μέσω διαφόρων καναλιών. Η βιομηχανία των εισιτηρίων αποτελείται από 3 κατηγορίες πωλητών: τους πωλητές εισιτηρίων (που συνήθως είναι οι διοργανωτές της εκδήλωσης, όπως ιδιοκτήτες χώρων εκδηλώσεων ή μαγαζιών, ή χρηματοδότες, οι οποίοι πουλάνε τα εισιτήρια απευθείας στους καταναλωτές ), τους φορείς των πρωταρχικών αγορών (στους οποίους αναθέτουν οι διοργανωτές εκδηλώσεων την πώληση των εισιτηρίων της εκάστοτε εκδήλωσης) και τους μεταπωλητές/ δευτερεύουσες αγορές (οι οποίοι προμηθεύονται τα εισιτήρια από τις προηγούμενες δυο κατηγορίες ή από άλλους μεταπωλητές). [1] Τα περισσότερα εισιτήρια στους φορείς των πρωταρχικών αγορών θα πουληθούν στην προκαθορισμένη ονομαστική τους αξία μαζί με τα επιπρόσθετα κόστη ( χρεώσεις κράτησης, χρεώσεις συναλλαγής κλπ.) και θα είναι έγκυρα εισιτήρια που υπό κανονικές συνθήκες θα εξασφαλίζουν στον αγοραστή την είσοδο στην εκδήλωση. Οι αγορές των μεταπωλήσεων υπάρχουν για να δίνουν την δυνατότητα της μεταπώλησης των εισιτηρίων που αγοράστηκαν από τις πρωταρχικές αγορές. Τα εισιτήρια στις αγορές μεταπωλήσεων προσφέρονται σε οποιαδήποτε τιμή και χαίρουν επιπρόσθετες προμήθειες στον πάροχο των υπηρεσιών. [2]
1.1 Υπάρχοντα Προβλήματα
Η βιομηχανία των εισιτηρίων για τις εκδηλώσεις ψυχαγωγίας, όπως κατανοούμε, είναι πολύπλοκη και διαιρεμένη, και οι διαχωριστικές γραμμές μεταξύ των αγορών θολές, γεγονός που οδηγεί σε σύγχυση τους καταναλωτές. Έρευνα έχει δείξει ότι οι καταναλωτές αποτυγχάνουν να ξεχωρίσουν τις πρωταρχικές από τις δευτερεύουσες αγορές· 1 στους 4 καταναλωτές παραδέχεται ότι δεν γνωρίζει από ποια αγορά προμηθεύεται τα εισιτήρια του. [2] Επίσης, η τεχνολογία που χρησιμοποιείται δεν εξελίσσεται με ρυθμούς τέτοιους ώστε να μετριάσει τα προβλήματα που υπάρχουν. Οι εταιρείες που ελέγχουν την βιομηχανία των εκδηλώσεων είναι λίγες και ο κύκλος κλειστός και οι μηχανισμοί που συντηρούνται ευνοούν την διαιώνιση αυτού το ολιγοπωλιακού συστήματος. Ο αδύναμος κρίκος σε αυτή την εξίσωση φαίνεται να είναι ο αγοραστής/υποστηρικτής που καλείται να επωμιστεί τις όποιες αδικαιολόγητες αυξήσεις στην τιμή των εισιτηρίων, χωρίς συγχρόνως να μπορεί να επηρεάσει την αλυσίδα αυτή. [3] Πολλές φορές δε και οι διοργανωτές, οι μάνατζερς ή οι καλλιτέχνες, αφού κοστολογούν τα εισιτήρια σε τιμές χαμηλότερες της αγοράς για να μεγιστοποιήσουν τα επίπεδα
1
Εισαγωγή 2
προσέλευσης και την εμπιστοσύνη/εκτίμηση των υποστηρικτών στοχεύοντας στην αύξηση των κερδών τους από τις πωλήσεις στον χώρο της εκδήλωσης. Οι δευτερεύουσες αγορές, οι οποίες από την φύση τους δεν διέπονται από κανονισμούς, δίνουν την δυνατότητα σε πιθανούς κακόβουλους φορείς να διενεργήσουν παράτυπα με σκοπό την κερδοφορία. Τα εισιτήρια συνήθως εκδίδονται/διατίθενται σε εκτυπώσιμη μορφή και περιέχουν ένα barcode που λειτουργεί ως διαπιστευτήριο για την είσοδο στην εκάστοτε εκδήλωση. Το γεγονός αυτό τα καθιστά στατικά και δίνει την δυνατότητα σε οποιονδήποτε έχει πρόσβαση σε αυτά να τα μοιραστεί και να τα αντιγράψει. Έτσι, οι δευτερεύουσες αγορές τροφοδοτούνται με ψεύτικες απομιμήσεις εισιτηρίων, με αντίγραφα εισιτηρίων που έχουν ήδη χρησιμοποιηθεί ή πουληθεί. [4] Επίσης, Brokers, ανεξάρτητοι scalpers, φορείς φιλοξενίας και εταιρείες χρησιμοποιούνε ειδικά διαμορφωμένα προγράμματα (ticket bots) με σκοπό την άντληση πληροφοριών που αφορούν τα εισιτήρια, την άμεση αγορά των καλύτερων διαθέσιμων εισιτηρίων, ώστε να τα μεταπωλήσουν, και τον συνεχή έλεγχο του αποθέματος των θέσεων (για να είναι οι πρώτοι που θα αγοράσουν τις σπάνιες και προνομιακές θέσεις) [5]. Το γεγονός αυτό έχει ως αποτέλεσμα τα εισιτήρια στις δημοφιλείς εκδηλώσεις να εξαντλούνται από τις πρωταρχικές αγορές και να διατίθενται προς πώληση στις δευτερεύουσες αγορές σε υπέρογκες τιμές. [6] [7] [8]. To 2009, η Europe Economics σε μια έρευνα που έκανε για την καλύτερη κατανόηση της λειτουργίας των δευτερευουσών αγορών κατέληξε σε κάποια ενδιαφέρουσα στατιστικά [9]:
• Για τις δημοφιλείς μουσικές εκδηλώσεις, 20-30% των εισιτηρίων μεταπωλούνται με αυξημένη τιμή περί του 30%. • Για τις high-end μουσικές εκδηλώσεις, 20-40% των εισιτηρίων μεταπωλούνται με αυξημένη τιμή περί του 100-250%. • Για τις πολύ high-end μουσικές εκδηλώσεις, 60-70% των εισιτηρίων μεταπωλούνται συχνά με αυξημένη τιμή που ξεπερνάει το 500%.
1.2 Υφιστάμενες Λύσεις
Έχουν γίνει διάφορες προσπάθειες για να αντιμετωπιστούν αυτές οι κύριες προκλήσεις οι οποίες εντοπίζονται σε τρία διαφορετικά πεδία: στην τεχνολογία, στην νομοθεσία και στους κανόνες που θέτει ο κάθε διοργανωτής/καλλιτέχνης/μάνατζερ/φορέας. Όλες οι παραπάνω προσπάθειες γίνονται προς την κατεύθυνση της ανάπτυξης τρόπων μέσω των οποίων μπορεί να εξασφαλιστεί η εγκυρότητα/αυθεντικότητα των εισιτηρίων που τοποθετούνται στις δευτερεύουσες αγορές και κατ’ επέκταση η δικαιότερη διαχείριση τους και η μεγαλύτερη η ασφάλεια που νιώθει ο καταναλωτής κατά την αγορά τους.
Εισαγωγή 3
1.2.1 Τεχνολογία
Κάποιες πρωταρχικές αγορές όπως το Resident Advisor [10] ή κάποιες πλατφόρμες μεταπώλησης εισιτηρίων από θεατή-σε-θεατή, όπως το Twickets [11], στοχεύουν να εξαλείψουν την υπερκοστολόγηση και τις ανήθικες συμπεριφορές μεταπώλησης με μηχανισμούς που αφήνουν την μεταπώληση των εισιτηρίων μόνο στην ονοματική τους αξία και κάτω.
Η υπηρεσία μεταπώλησης του Resident Advisor είναι διαθέσιμη μετά την εξάντληση των εισιτηρίων και μόνο. Μόλις τα εισιτήρια εξαντληθούν μια ουρά για τα εισιτήρια ενεργοποιείται και εξυπηρετεί με first in first out τρόπο. Ο ενδιαφερόμενος μεταπωλητής τοποθετεί το εισιτήριο του και αυτό είναι διαθέσιμο προς πώληση με τιμή ίση με την τελευταία βαθμίδα τιμολόγησης. Αν για παράδειγμα εισήγαγα ένα εισιτήριο αξίας 10 ευρώ προς πώληση, αλλά το τελευταίο εισιτήριο που πουλήθηκε άξιζε 20 ευρώ, τότε η τιμή πώλησης του θα είναι 20 ευρώ και στον πωλητή θα αποδοθούν τα 10 ευρώ και τα υπόλοιπα θα αποδοθούν στον διοργανωτή αφαιρώντας την αμοιβή τους ως διαμεσολαβητή. [10]
Η διαδικασία που πρέπει να ακολουθήσει ο μεταπωλητής στην πλατφόρμα Twickets αποτελείται από την επιλογή του τύπου και της ονομαστικής τιμής του εισιτηρίου που θέλει να πουλήσει με βάση τις καταχωρήσεις που έχουν για την εκάστοτε εκδήλωση στην βάση δεδομένων τους, δίνοντας του και τη δυνατότητα να προσθέσει 15% για να καλύψει τα έξοδα υπηρεσιών. [11]
Άλλες πλατφόρμες, όπως το Dice.fm [12] και το Songkick [13], έχουν αναπτύξει data-driven τεχνικές για να εξαλείψουν την απάτη από το σημείο/στιγμή της αγοράς του εισιτηρίου και να αναγνωρίσουν τα εισιτήρια που μεταπωλούνται στις δευτερεύουσες αγορές. Το Dice.fm επίσης παραδίδει τα εισιτήρια κατευθείαν στο κινητό του αγοραστή ( δηλαδή στην εφαρμογή του dice στο κινητό) για να αποφευχθεί οποιαδήποτε διαρροή εισιτηρίων προς τις δευτερεύουσες αγορές.
Οι παραπάνω τεχνικές αν και βελτιώνουν την κατάσταση παρουσιάζουν κάποια προβλήματα. Καταρχάς, οι χρήστες είναι αναγκασμένοι να μεταπωλούν τα εισιτήρια τους μόνο στην ονομαστική τιμή και χαμηλότερα, με αποτέλεσμα να δίνει κίνητρα στην μεταπώληση των εισιτηρίων στη μαύρη αγορά. Ακόμα η αναγνώριση των κακόβουλων παραγόντων μέσω του machine learning δεν είναι μια μακροχρόνια λύση, μιας και οι scalpers λόγω των υψηλών κινήτρων που έχουν, δημιουργούν συνεχώς καινούργιες τεχνικές και αλγορίθμους για να παρακάμπτουν τα όποια εμπόδια.
Για το λόγο αυτό οι πιο αποδοτικές λύσεις είναι αυτές που η διαχείριση του αποθέματος γίνεται από πλατφόρμες που ενοποιούν την πρωταρχική και τη δευτερεύουσα αγορά και παρέχουν υπηρεσίες ελέγχου εγκυρότητας των εισιτηρίων. Παρόλα αυτά λόγω την έλλειψης διαφάνειας και της κατακερματισμένης δομής της βιομηχανίας των εισιτηρίων δεν υπάρχει κάποια συγκεκριμένη υπηρεσίας ελέγχου της εγκυρότητας ή μη ενός εισιτηρίου σε οποιαδήποτε στιγμή του κύκλου ζωής του.
Εισαγωγή 4
1.2.2 Νομοθεσία
Τα προβλήματα που μαστίζουν την βιομηχανία των εισιτηρίων και φαίνεται ότι δεν μπορούν να αποφευχθούν μόνο με τη χρήση της τεχνολογίας προσπαθούν να λύσουν οι αρχές με κάποιες νομοθεσίες και έρευνες που διεξάγουν. Οι αρχές προστασίας του πολίτη πολλών χωρών προειδοποιούν τους κακόβουλους παράγοντες και διεξάγουν συνεχώς έρευνες· κάποιες από αυτές τις αρχές είναι το UK’s Advertising Standards Agency (ASA) [14], το Australia’s Competition and Consumer Commission [15], το New Zealand’s Consumer NZ [16], Ireland’s Advertising Standards Authority [17] κ.α. [18]
Το Ευρωπαϊκό Κοινοβούλιο ψήφισε στις 17 Απριλίου του 2019 τον πρώτο σε Ευρωπαϊκό επίπεδο νόμο που απαγορεύει την χρήση bots εισιτηρίων που καταστρατηγούν τους κανόνες τις αγοράς. Αυτός ο νόμος εναρμονίζεται με τους ήδη υπάρχοντες νόμους που είχε θεσπίσει το Ηνωμένο Βασίλειο και ισχυροποιεί το υπάρχον νομοθετικό πλαίσιο που υπάρχει, προσπαθώντας να αυξήσει την προστασία προς τους καταναλωτές. Αυτό είναι το πρώτο βήμα για την εναρμόνιση της νομοθεσίας γύρω από παρεμφερή ζητήματα σε όλη την Ευρώπη [19]. Το Ηνωμένο Βασίλειο που είναι αρκετά δραστήριο όσον αφορά τη βιομηχανία των εισιτηρίων, τον Απρίλιο του 2018 θέσπισε νόμο ώστε τα εισιτήρια που τοποθετούνται για μεταπώληση στις δευτερεύουσες αγορές να έχουν τον μοναδικό αριθμό εισιτήριου που χορηγείται σε κάθε εισιτήριο από τον φορέα των πρωταρχικών αγορών.
Στην Αμερική, το νομοθετικό πλαίσιο ρυθμίζεται ξεχωριστά σε κάθε πολιτεία. Τη δεδομένη στιγμή 28 πολιτείες1 νομοθετούν για την μεταπώληση των εισιτηρίων. Οι νομοθεσίες περιλαμβάνουν όρια στις τιμές μεταπώλησης των εισιτηρίων, περιορισμό στην απόσταση γύρω από έναν χώρο εκδηλώσεων από όπου μπορούν να μεταπωληθούν τα εισιτήρια, άδεια μεταπώλησης των εισιτηρίων από συγκεκριμένα άτομα που πληρούν κάποιες προδιαγραφές και άδεια πώλησης των εισιτηρίων μέσω ίντερνετ σε ιστοσελίδες που πληρούν συγκεκριμένα κριτήρια, καθώς και την απαγόρευση χρησιμοποίησης bots ή άλλα προγράμματα για την άμεση αγορά εισιτηρίων με σκοπό την μεταπώληση τους σε φουσκωμένες τιμές [20] [21].
1 ALA. CODE § 40-12-167 (2003); ARIz. REV. STAT. ANN. § 13-3718 (2001); ARK. CODE ANN. § 5-63- 201 (2005); CAL. PENAL CODE § 346 (West 1999); COL. REV. STAT. § 6-1-718 (2009); CONN. GEN. STAT. § 53-289 (2009); DEL. CODE ANN. tit. 11, § 918(a) (2007); FLA. STAT. § 817.36 (2008), amended by 2009 Fla. Sess. Law Serv. 1446 (West); GA. CODE ANN. § 43-4B-25 (2008); HAw. REV. STAT. § 440- 17 (1993); 720 ILL. COMP. STAT. 375/1.5 (2008); IND. CODE § 25-9-1-26 (2004 & Supp. 2008); Ky. REV. STAT. ANN. § 518.070 (LexisNexis 2008); LA. REV. STAT. ANN. § 4:1 (2003 & Supp. 2009); MD. CODE ANN., Bus. REG. § 4-318 (LexisNexis 2004); MASS. GEN. LAWS ch. 140, § 185A (2008); MICH. COMP. LAWS § 750.465(2) (1981); Miss. CODE ANN. § 97-23-97 (2006); N.J. STAT. ANN. § 56:8-27 (West Supp. 2009); N.M. STAT. § 30-46-1 (2004); N.Y. ARTS & CULT. Ais. LAW § 25.11 (McKinney Supp. 2009) (effective until May 2010); N.C. GEN. STAT. § 14-344 (1995); OHIO REV. CODE ANN. § 715.48 (LexisNexis 2008); 4 PA. STAT. ANN. § 202 (West 2008); R.I. GEN. LAWS § 5-22-26 (2004); S.C. CODE ANN. § 16-17-710 (Supp. 2008); VA. CODE ANN. § 15.2-969 (Supp. 2009); WASH. REV. CODE § 67.70.110 (2008); Wis. STAT § 42.07 (2008).
Εισαγωγή 5
1.2.3 Επιβολή κανόνων από τους εμπλεκόμενους
Λόγω της πίεσης που δέχονται από τους θεατές, τις αρχές προστασίας του πολίτη, τους καλλιτέχνες και τους μάνατζερς πολλές δευτερεύουσες αγορές προσπαθούν να εισάγουν κανόνες στον τρόπο λειτουργίας τους με σκοπό να αποκαταστήσουν την φήμη των δευτερευουσών αγορών και να επαναφέρουν την εμπιστοσύνη των καταναλωτών. Κάποιοι από τους κανόνες αυτούς είναι η εξασφάλιση αποζημίωσης σε περίπτωση ψεύτικων εισιτηρίων ή σε ήδη χρησιμοποιημένα εισιτήρια (Βέβαια αυτό δεν εξασφαλίζει τον αγοραστή πλήρως αφού μπορεί να έχει δαπανήσει επιπλέον χρήματα για να καταφέρει να παρευρεθεί στην εκδήλωση, όπως χρήματα για το ταξίδι ή για την διαμονή κ.α) [2].
Επίσης γνωστοί καλλιτέχνες (όπως ο Ed Sheeran, η Adele, η Taylor Swift, Bruce Springsteen, Iron Maiden κ.α) δίνουν συνεχή για να καθημερινούς αγώνες για να πατάξουν τους κακόβουλους φορείς. Οι μέθοδοι που ακολουθούνται βασίζεται κυρίως στη τεχνολογία Verified Fan, η οποία χρησιμοποιεί δεδομένα για να εξασφαλίσει ότι οι αγοραστές είναι πραγματικοί θεατές λαμβάνοντας υπόψιν τις προηγούμενες αγορές για την εκάστοτε εκδήλωση/τραγουδιστή [22] [23] [24]. Καθώς επίσης και συμφωνίες με τους πωλητές ώστε να εξαλείφουν τις μεταπωλήσεις. [25] Ενώ αυτές οι τακτικές είναι αποτελεσματικές για τους γνωστούς καλλιτέχνες που έχουν και τα κίνητρα και τα πόρους να δώσουν αυτή τη μάχη, οι λιγότερο γνωστοί καλλιτέχνες και οι θεατές τους συνεχίζουν να βλάπτονται από τις κακόβουλες πρακτικές.
1.3 Προτεινόμενη Λύση
Η λύση που προτείνουμε σε αυτή τη διπλωματική σκοπεύει να αφαιρέσει την πολύπλοκη και διαιρεμένη δομή στην βιομηχανία των εισιτηρίων μέσω της δημιουργίας ενός ανοιχτού συστήματος εισιτηρίων όπου όλα τα συμβαλλόμενα μέρη της εφοδιαστικής αλυσίδας θα συνεργάζονται με περισσότερο έλεγχο, περισσότερη διαφάνεια στις μεταξύ τους συναλλαγές και περισσότερη ασφάλεια. Σχεδιάστηκε με τέτοιο τρόπο ώστε να δίνει τον έλεγχο του αποθέματος και της διανομής στους αρμόδιους και με σκοπό να ενώσει τους παράγοντες της εφοδιαστικής αλυσίδας, καθώς επίσης και να βοηθήσει τους αγοραστές να ανακτήσουν την χαμένη τους εμπιστοσύνη προς τη βιομηχανία.
Η λύση αυτή αποτελείται από ένα πρωτόκολλο/smart contract στην πλατφόρμα του Eos και μία εφαρμογή για την αλληλεπίδραση με αυτό. Συγκεκριμένα, το πρωτόκολλο δίνει την δυνατότητα και διευκολύνει τους διοργανωτές μιας εκδήλωσης ή τους διαχειριστές του αποθέματος των εισιτηρίων, να δημιουργήσουν, να διαχειριστούν και να θέσουν τους δικούς τους κανόνες ως προς τον τρόπο με τον οποίο τα εισιτήρια τους θα συναλλάσσονται, θα μεταπωλούνται και θα επικυρώνονται. Ειδικότερα, επιτρέπει στον διοργανωτή μιας εκδήλωσης να βάλει όρια στην τιμή μεταπώλησης των εισιτηρίων, καθώς επίσης να λαμβάνει προμήθεια από κάθε μεταπώληση. Λόγω της χρήσης των smart contracts επιτυγχάνεται η ασφάλεια και ο έλεγχος της εφοδιαστικής αλυσίδας μειώνοντας έτσι την απάτη και δίνοντας προτεραιότητα στις ανάγκες του εκάστοτε αρμόδιου. Τα εισιτήρια είναι αποθηκευμένα στο Blockchain και το καθένα έχει ένα μοναδικό αναγνωριστικό, γεγονός που διευκολύνει στην ανίχνευση του κάθε εισιτηρίου καθ’ όλη τη διαδρομή του και στην απόδειξη ιδιοκτησίας τους.
Εισαγωγή 6
1.4 Διάρθρωση
Το Κεφάλαιο 2 εισάγει τις έννοιες που χρειάζονται για να καταλάβει κανείς τις βασικές αρχές που απαρτίζουν την τεχνολογία του Blockchain. Και στη συνέχεια τις ιδιότητες του Eos Blockchain.
Το Κεφάλαιο 3 αναλύει τα εργαλεία που χρειαστήκαμε για την υλοποίηση όλης της δομής του συστήματος μας.
Το Κεφάλαιο 4 εξετάζει τα πιο σημαντικά θέματα ασφαλείας που έχουν βρεθεί στα Eos smart contracts μέχρι και την ημέρα εκπόνησης της διπλωματικής. Έχοντας κατανοήσει τα θέματα αυτά είμαστε και σε θέση να αξιολογήσουμε και την υλοποίηση μας.
Το Κεφάλαιο 5 αναλύει την υλοποίηση που προτείνουμε για την επίλυση των υφιστάμενων προβλημάτων στην βιομηχανία των εισιτηρίων.
Το Κεφάλαιο 6 περιέχει την αξιολόγηση της υλοποίησης μας σε επίπεδο ασφάλειας όσο και σε επίπεδο κόστους των μεθόδων του smart contract μας.
Το κεφάλαιο 7 συνοψίζουμε όσον αφορά τα ευρήματα μας από την διπλωματική αυτή και προτείνουμε μελλοντικές προεκτάσεις όσον αφορά τη λύση μας.
2 Υπόβαθρο
Σε αυτήν την ενότητα, θα παρουσιαστεί μια θεωρητική επισκόπηση, στην οποία θα εξεταστούν όλα τα απαραίτητα στοιχεία που σχετίζονται με αυτήν τη διπλωματική. Το μεγαλύτερο μέρος αυτού του κεφαλαίου αποτελείται από την εξερεύνηση της τεχνολογίας του Blockchain, με το υπόλοιπο μέρος να καλύπτεται από θέματα κρυπτογραφίας, μία έρευνα στα υπάρχοντα token model στην Εthereum πλατφόρμα και κάποιες ιδιότητες του ΕOS blockchain. Στο τέλος αυτής της ενότητας οι απαραίτητες θεωρητικές γνώσεις των τεχνολογιών που χρησιμοποιούνται στην διπλωματική θα είναι ξεκάθαρες στον αναγνώστη.
2.1 Bitcoin
Η ιδέα του blockchain εισήχθη αρχικά στο whitepaper του Bitcoin από τον Satoshi Nakamoto [26], όπου περιγράφει μια peer-to-peer έκδοση του ηλεκτρονικού χρήματος που θα δίνει την δυνατότητα στα συμβαλλόμενα μέρη να εκτελούν ηλεκτρονικές συναλλαγές απευθείας χωρίς την ανάμειξη κάποιου ενδιάμεσου, όπως χρηματοπιστωτικά ιδρύματα ή τράπεζες μέσω του αποκεντρωμένου ψηφιακού νομίσματος που ονομάζεται Bitcoin. Η υλοποίηση ενός τέτοιου συστήματος εμπεριέχει τον κίνδυνο του double spending, δηλαδή της χρησιμοποίησης της ίδιας ποσότητας χρήματος σε δύο διαφορετικές συναλλαγές. Ο Satoshi Nakamoto προτείνει την δημιουργία ενός peer-to-peer δικτύου για την επίλυση του. Στο δίκτυο αυτό όλοι οι συμμετέχοντες ή αλλιώς οι κόμβοι του συστήματος κρατάνε ένα αντίγραφο της αλυσίδας και επικοινωνούν μεταξύ τους σύμφωνα με τις προδιαγραφές ενός πρωτοκόλλου για την επικύρωση των νέων μπλοκ. Το πρωτόκολλο αυτό που είναι αναγκαίο για την επιτυχή ολική αξιοπιστία του συστήματος παρ’ όλη την ύπαρξη ελλαττωματικών ή κακόβουλων κόμβων ονομάζεται αλγόριθμος συναίνεσης (consensus algorithm).
2.2 Blockchain
Το Blockchain μπορεί να περιγράφει ως μια λίστα από καταχωρήσεις 2 ή αλλιώς μια αλυσίδα από μπλοκ που διαρκώς μεγαλώνει με την πάροδο του χρόνου. Κάθε μπλοκ περιέχει διάφορες πληροφορίες ( metadata ) που είναι γνωστές ως block header και μια λίστα από συναλλαγές3 που είναι γνωστή ως block body. Κάθε μπλοκ συνδέεται με το προηγούμενο μέσω ενός κρυπτογραφικού hash4. Η αλυσίδα των μπλοκ σχηματίζεται όταν το υπό δημιουργία μπλοκ έχει έγκυρη αναφορά στο αμέσως προηγούμενο του μπλοκ. Αυτή η διαδικασία εξασφαλίζει την ακεραιότητα του προηγούμενου μπλοκ φτάνοντας έτσι μέχρι την αρχή της αλυσίδας και το genesis μπλοκ, όπως ονομάζεται το αρχικό μπλοκ. Όσο η
2 Στην επιστήμη των υπολογιστών με τον όρο καταχωρήσεις εννοούμε μια δομή δεδομένων 3 Η συναλλαγή μπορεί να έχει την μορφή μεταφοράς αξίας μεταξύ των συμμετεχόντων του Blockchain ή σε άλλες περιπτώσεις να είναι μία κλήση μίας συνάρτησης ενός έξυπνου συμβολαίου που περιγράφει μια διαδικασία. 4 To hash είναι μια σταθερούς μεγέθους αναπαράσταση χαρακτήρων που παράγεται από μία συνάρτηση κατακερματισμού για δεδομένη είσοδο
7
Υπόβαθρο 8
αλυσίδα μεγαλώνει και προστίθενται νέα μπλοκ, τα προηγούμενα μπλοκ και το περιεχόμενο τους θεωρούνται πιο ασφαλή. Κάθε μπλοκ περιέχει επίσης και μία χρονική σήμανση (timestamp).
2.2.1 Χαρακτηριστικά
Μερικά από τα βασικά χαρακτηριστικά του Blockchain είναι τα εξής :
• Αποκεντρωμένο: Αυτό σημαίνει ότι δεν υπάρχει κάποιο πρόσωπο του δικτύου που να υπερέχει έναντι κάποιου άλλου προσώπου κατ’ οποιονδήποτε τρόπο, οπότε υπάρχει απουσία προτεραιότητας (όποιου είδους), κάποιου προσώπου έναντι κάποιου άλλου. Τα πρόσωπα των συμμετεχόντων στο δίκτυο δεν είναι ίδια, αλλά είναι ίσα μεταξύ τους αναφορικά με οποιαδήποτε διαδικασία εκλογής ή/και επιλογής μεταξύ αυτών. [27] • Διαφάνεια: Η διαφάνεια απορρέει από το γεγονός ότι όλες οι ιδιοκτησίες και οι συναλλαγές όλων των δημόσιων διευθύνσεων είναι ανοιχτές και προσβάσιμες από τον καθένα. Χρησιμοποιώντας έναν εξερευνητή (explorer) και έχοντας μία δημόσια διεύθυνση μπορείς να δεις την περιουσία της και όλες τις συναλλαγές που έχει κάνει. Η διαφάνεια σε μια αλυσίδα βοηθά επίσης στο να επαληθεύσει το δίκτυο ότι δεν παράχθηκε κανένα πλαστό νόμισμα και αποτρέπει το double spending, εξασφαλίζοντας έτσι τον αριθμό και την εγκυρότητα των νομισμάτων που είναι σε κυκλοφορία. Αυτό το επίπεδο διαφάνειας δεν έχει υπάρξει στα χρηματοοικονομικά συστήματα μέχρι σήμερα. [28] • Αμεταβλητότητα: Εφόσον μια συναλλαγή έχει καταγραφεί στο Blockchain από έναν κόμβο κανείς δεν μπορεί να την αλλοιώσει ή να την αφαιρέσει. Αυτή είναι και η βασική διαφορά ενός Blockchain από μία κοινή βάση δεδομένων, στην οποία τα δεδομένα μπορούν να μεταβληθούν ή να διαγραφούν. • Ανοιχτό: Τυπικά έχει να κάνει με την ανοιχτού κώδικα (open-source) φύση των περισσοτέρων δημόσιων Blockchain πρωτοκόλλων.
2.2.2 Τύποι Blockchain
Υπάρχουν τρείς βασικοί τύποι Blockchain, οι οποίοι δεν περιέχουν τις παραδοσιακές βάσεις δεδομένων ή τα διαμοιρασμένα τεχνολογικά λογιστικά βιβλία (distributed ledger technology (DLT)) που συχνά συγχέονται με το Βlockchain [29]:
• Δημόσια (Public or Permissionless): Επιτρέπουν οποιονδήποτε να συμμετέχει στο δίκτυο ως χρήστης, προγραμματιστής, κόμβος ή μέρος της κοινότητας. Επίσης δεν έχουν κάποιον ιδιοκτήτη και όλες οι συναλλαγές σε αυτό είναι πλήρως διαφανείς. [30] [31] [32] • Ιδιωτικά (Private or Permissioned): Για να συμμετέχει κάποιος στο δίκτυο πρέπει να πάρει έγκριση από τους συμμετέχοντες. Είναι περισσότερο κεντροποιημένα από τα δημόσια και οι συναλλαγές που γίνονται σε αυτό είναι διαθέσιμες μόνο στους συμμετέχοντες του δικτύου. [33] [34] [35] • Υβριδικά (Hybrid): Είναι ένας συνδυασμός δημόσιου και ιδιωτικού μέρους, που προσπαθεί να κρατήσει την ιδιωτικότητα των ιδιωτικών blockchain και την
Υπόβαθρο 9
ασφάλεια και διαφάνεια των δημόσιων. Η ακριβής λειτουργία της αλυσίδας ποικίλει ανάλογα με την αποκεντροποίηση-κεντροποίηση που χρησιμοποιείται. Δίνει την ευελιξία στις επιχειρήσεις να επιλέξουν ποια δεδομένα θα είναι δημόσια και διαφανή και ποια θα είναι κρυφά. [36]
Μια ανάλυση σχετικά με τα πλεονεκτήματα και τα μειονεκτήματα των δημόσιων και ιδιωτικών Blockchain από τον δημιουργό του Ethereum, Vitalik Buterin παρατίθεται [37].
2.2.3 Αλγόριθμοι συναίνεσης
Οι αλγόριθμοι συναίνεσης είναι ουσιαστικά ένας τρόπος μέσω του οποίου ένα σύνολο κατανεμημένων υπολογιστών προσπαθεί να καταλήξει σε συμφωνία για μια συγκεκριμένη τιμή δεδομένων ή την κατάσταση (state) ενός διανεμημένου συστήματος. Οι αλγόριθμοι συναίνεσης χρησιμοποιούνται για την επίτευξη της αξιοπιστίας ενός δικτύου, το οποίο αποτελείται από πολλούς διανεμημένους κόμβους, οι οποίοι περιέχουν την ίδια πληροφορία.
Οι πιο γνωστοί αλγόριθμοι συναίνεσης παρουσιάζονται παρακάτω:
• Proof of work (PoW): Είναι η διαδικασία της παραγωγής σωστών αποδείξεων ώστε να προστεθεί ένα καινούργιο μπλοκ στην αλυσίδα των μπλοκ και καλείται εξόρυξη (mining). Τα άτομα που συμμετέχουν στην διαδικασία αυτή καλούνται miners και προσπαθούν να αποδείξουν πως έχουν δαπανήσει υπολογιστική ισχύς για την επίλυση ενός περίπλοκου κρυπτογραφικού παζλ. Πιο συγκεκριμένα, οι κόμβοι ανταγωνίζονται μεταξύ τους για να βρουν ένα μπλοκ ή ένα σύνολο από συναλλαγές σε χρονολογημένη σειρά και να μαντέψουν το nonce. Το nonce είναι ένας τυχαίος αριθμός που μαζί με το hash του μπλοκ μπαίνει ως είσοδος σε μια hash συνάρτηση, η έξοδος της οποίας πρέπει να πληρεί τις προϋποθέσεις που έχουν τεθεί ώστε να είναι αποδεκτό από τους υπόλοιπους miners. Ο miner που βρίσκει πρώτος την λύση το μεταδίδει στους υπόλοιπους κόμβους του δικτύου ώστε το μπλοκ αυτό να προστεθεί στην αλυσίδα και ανταμείβεται με ένα προκαθορισμένο ποσό του κρυπτονομίσματος του συστήματος (block reward). Οι κόμβοι που δεν κατάφεραν να υποθέσουν σωστά το nonce πριν από κάποιον άλλο ξεκινούν από την αρχή, προσπαθώντας να λύσουν το παζλ για το επόμενο μπλοκ. • Proof of stake (PoS): Στον αλγόριθμο απόδειξης ιδιοκτησίας ο δημιουργός του νέου μπλοκ επιλέγεται με ντετερμινιστικό τρόπο με πιθανότητα, η οποία είναι ανάλογη του αριθμού των νομισμάτων που του ανήκουν (δηλαδή τον πλούτο του). Οι συμμετέχοντες στην διαδικασία αυτή ονομάζονται validators. Η διάρκεια κράτησης των νομισμάτων στο πορτοφόλι του κάθε επίδοξου validator λαμβάνεται επίσης υπόψιν σε κάποια συστήματα που υλοποιούν τον αλγόριθμο αυτόν. Τα συστήματα που εφαρμόζουν αυτόν τον αλγόριθμο πρέπει να έχουν εξορύξει ήδη το κρυπτονόμισμα που θα χρησιμοποιηθεί ή να μεταβούν σε αυτόν από έναν proof of work αλγόριθμο, αφού το πλήθος του κρυπτονομίσματος που χρησιμοποιείται δεν αλλάζει. Δεν υπάρχει επιβράβευση για την δημιουργία ενός μπλοκ, οι κόμβοι εισπράττουν μόνο τα τέλη των συναλλαγών. • Delegated proof of stake (DPoS): Ο αλγόριθμος αυτός λειτουργεί όπως μια διαδικασία εκλογής. Οι ενεργοί χρήστες ψηφίζουν τους “αντιπροσώπους” (delegates) τους με το να τοποθετούν τα νομίσματα τους στο όνομα του υποψηφίου
Υπόβαθρο 10
(τα νομίσματα αυτά δεν ξοδεύονται με αυτόν τον τρόπο, απλά αντιπροσωπεύουν την θέση του ψηφοφόρου και παραμένουν στην κατοχή του). Οι αντιπρόσωποι ή αλλιώς “μάρτυρες” (witnesses), όπως συχνά αναφέρονται, είναι υπεύθυνοι για την παραγωγή και την επικύρωση των νέων μπλοκ. Η βαρύτητα της ψήφου είναι ανάλογη του αριθμού των νομισμάτων που κάθε χρήστης κατέχει. Το Eos χρησιμοποιεί μία μορφή του αλγορίθμου αυτού.
2.3 Κρυπτογραφία
2.3.1 Cryptographic Hash Function
Μία hash συνάρτηση είναι μία συνάρτηση που αντιστοιχεί δεδομένα τυχαίου μεγέθους σε δεδομένα προκαθορισμένου μεγέθους. Η έξοδος μίας hash συνάρτησης ονομάζεται hash της εισόδου της. Οι hash συναρτήσεις που χρησιμοποιούνται στην κρυπτογραφία πρέπει να πληρούν επιπλέον κριτήρια ασφαλείας και ονομάζονται κρυπτογραφικές hash συναρτήσεις.
Συγκεκριμένα οι κρυπτογραφικές hash συναρτήσεις πρέπει να έχουν τις εξής ιδιότητες [38]:
• Pre-Image Resistance: Δεδομένης μίας 퐻(푥)5 θα πρέπει να είναι υπολογιστικά αδύνατο να βρεθεί το 푥. • Second Pre-Image Resistance: Δεδομένης 퐻(푥) θα πρέπει να είναι υπολογιστικά αδύνατο να βρεθεί ένα 푥′ τέτοιο ώστε 퐻′(푥) = 퐻(푥). Η επίθεση στο second pre- image επίπεδο σε μια κρυπτογραφική hash συνάρτηση είναι σημαντικά πιο δύσκολη από αυτή στο pre-image επίπεδο λόγω του ότι ο επιτιθέμενος μπορεί να ελέγξει μόνο μία είσοδο της εξίσωσης. • Collision Resistance: Θα πρέπει να είναι υπολογιστικά αδύνατο να βρεθεί 푥 και 푦 τέτοιο ώστε 퐻(푦) = 퐻(푥).
Το Bitcoin και Eos χρησιμοποιούν την SHA-256 κρυπτογραφική hash συνάρτηση, ενώ το Ethereum χρησιμοποιεί την KECCAK-256.
2.3.2 Public Key Cryptography
Η κρυπτογραφία δημόσιου κλειδιού, ή αλλιώς ασύμμετρη κρυπτογραφία, είναι ένας μηχανισμός ο οποίος χρησιμοποιεί ένα ζευγάρι κλειδιών για την κωδικοποίηση και αποκωδικοποίηση των δεδομένων. Τα δύο αυτά κλειδιά ονομάζονται δημόσιο6 και ιδιωτικό7 αντίστοιχα. Το κυριότερο πλεονέκτημα της κρυπτογραφίας δημόσιου κλειδιού είναι ότι
5 Ως 퐻(푥) ορίζουμε το hash του 푥 6 Το δημόσιο κλειδί είναι ένας αριθμός ο οποίος προκύπτει από τον πολλαπλασιασμό ενός σημείου της ελλειπτικής καμπύλης με το ιδιωτικό κλειδί (Pub_key = Priv_key*G, όπου G το επιλεγόμενο σημείο). Το δημόσιο κλειδί είναι η δημόσια διεύθυνση του ιδιοκτήτη. 7 Το ιδιωτικό κλειδί είναι συνήθως ένας μεγάλος αριθμός που είναι γνωστός μόνο στον ιδιοκτήτη του.
Υπόβαθρο 11
εγκαθιδρύει μια ασφαλή επικοινωνία χωρίς την ανάγκη ασφαλούς καναλιού μετάδοσης της πληροφορίας μεταξύ δύο τερματικών.
Η κρυπτογραφία δημόσιου κλειδιού είναι βασισμένη σε κρυπτογραφικούς αλγορίθμους οι οποίοι είναι υπολογιστικά δύσκολο/αδύνατο να λυθούν λόγω των μαθηματικών προβλημάτων που βασίζονται, όπως το πρόβλημα του διακριτού λογαρίθμου (discrete logarithm) για τον Elliptic Curve Digital Signature Algorithm (ECDSA) [39] ή το πρόβλημα της παραγοντοποίησης μεγάλων αριθμών για τον RSA [40].
Η κρυπτογραφία δημόσιου κλειδιού χρησιμοποιείται για τα εξής:
• Εμπιστευτικότητα (Confidentiality): Το κρυπτογραφημένο μήνυμα που θα στείλει ένας αποστολέας θα πρέπει να μην μπορεί να διαβαστεί από κανέναν άλλο εκτός του παραλήπτη. Αυτό επιτυγχάνεται με την κρυπτογράφηση του μηνύματος με το δημόσιο κλειδί του παραλήπτη, αφού ο μόνος τρόπος αποκρυπτογράφησης του μηνύματος είναι μέσω του αντίστοιχου ιδιωτικού κλειδιού που γνωρίζει μόνο ο παραλήπτης. Έτσι επιτυγχάνεται η εμπιστευτικότητα στα υπό μετάδοση μηνύματα. Αυτή η μέθοδος έχει το μειονέκτημα της έλλειψης πιστοποίησης, συνεπώς οποιοσδήποτε μπορεί να υποδυθεί τον αποστολέα. • Πιστοποίηση (Authentication): Ο παραλήπτης πρέπει να είναι σε θέση να επαληθεύσει την ταυτότητα του αποστολέα. Με την κρυπτογράφηση του μηνύματος με το ιδιωτικό κλειδί του αποστολέα, ο μόνος τρόπος αποκρυπτογράφησης του μηνύματος αυτού είναι με το δημόσιο κλειδί του αποστολέα, γεγονός που πιστοποιεί την ταυτότητα του αποστολέα. Το μειονέκτημα της μεθόδου αυτής είναι ότι το μήνυμα μπορεί να διαβαστεί από οποιονδήποτε ενδιάμεσο, αφού το δημόσιο κλειδί του αποστολέα είναι γνωστό σε όλους. • Εμπιστευτικότητα & Πιστοποίηση (Confidentiality and Authentication): Ο παραλήπτης πρέπει να είναι σε θέση να επαληθεύσει τόσο την ταυτότητα του αποστολέα όσο και ότι το μήνυμα δεν διαβάστηκε από κάποιον τρίτο. Στην μέθοδο αυτή το μήνυμα κρυπτογραφείται με το ιδιωτικό κλειδί του αποστολέα και επανακρυπτογραφείται με το δημόσιο κλειδί του παραλήπτη. Έτσι ο παραλήπτης πρώτα αποκρυπτογραφεί το μήνυμα με το ιδιωτικό του κλειδί επιτυγχάνοντας την εμπιστευτικότητα και στη συνέχεια επαληθεύει την ταυτότητα του αποστολέα αποκρυπτογραφώντας την έξοδο της προηγούμενης διαδικασίας με το δημόσιο κλειδί του αποστολέα. • Ακεραιότητα (Integrity): Ο παραλήπτης πρέπει να είναι σε θέση να επαληθεύσει ότι το μήνυμα δεν αλλοιώθηκε κατά τη διάρκεια της μεταφοράς του. Οι ψηφιακές υπογραφές είναι μια έκφανση της μεθόδου αυτής. Πιο συγκεκριμένα στην μέθοδο αυτή, αρχικά υπολογίζεται μια σύνοψη του μηνύματος μέσω μιας συνάρτησης κατακερματισμού. Η σύνοψη κρυπτογραφείται με το ιδιωτικό κλειδί του αποστολέα και πλέον αποτελεί την ψηφιακή υπογραφή, η οποία επισυνάπτεται στο μήνυμα. Κατά τη διαδικασία ελέγχου, η ψηφιακή υπογραφή διαχωρίζεται από το μήνυμα και αποκρυπτογραφείται από το δημόσιο κλειδί του αποστολέα. Η προηγούμενη έξοδος συγκρίνεται με το αποτέλεσμα που προκύπτει από τη σύνοψη του ληφθέντος μηνύματος. Αν οι δύο συνόψεις είναι ίδιες ο παραλήπτης εξασφαλίζει ότι το μήνυμα δεν αλλοιώθηκε.
Υπόβαθρο 12
2.4 Token Models
Στο υποκεφάλαιο αυτό παρατίθεται η έρευνα που έγινε στα μοντέλα των νομισμάτων που υπάρχουν στην πλατφόρμα Ethereum και αφορούν κυρίως την κατηγορία των non-fungible νομισμάτων (NFTs).
2.4.1 Κατηγορίες νομισμάτων
Υπάρχουν τρείς διαφορετικοί κατηγορίες νομισμάτων και είναι οι εξής [41]:
• Fungible tokens (FTs): Τα νομίσματα αυτής της κατηγορίας μπορούν να ανταλλαχθούν με οποιοδήποτε νόμισμα του ίδιου τύπου. Για παράδειγμα ένα χαρτονόμισμα των 5 ευρώ μπορεί να ανταλλαχθεί με οποιοδήποτε άλλο χαρτονόμισμα των 5 ευρώ και να μην έχει καμία απολύτως διαφορά για τον ιδιοκτήτη του. Όλα τα νομίσματα του ίδιου τύπου έχουν την ίδιες προδιαγραφές για αυτό και είναι απαράλλαχτα μεταξύ τους. Τα fungible tokens μπορούν να διαιρεθούν σε μικρότερες μονάδες και δεν έχει σημασία ποιες μονάδες θα πάρεις αρκεί η συνολική αξία να είναι η ίδια. • Non fungible tokens (NFTs): Ένα νόμισμα του τύπου αυτού δεν μπορεί να αντικατασταθεί από ένα άλλο νόμισμα του ίδιου τύπου. Αν δανείσεις ένα νόμισμα αυτή της κατηγορίας σε κάποιον άλλο θα πρέπει να περιμένεις να σου γυρίσει το ίδιο νόμισμα και όχι ένα άλλο νόμισμα του ίδιου τύπου. Κάθε νόμισμα είναι διαφορετικό από όλα τα άλλα νομίσματα του ίδιου τύπου και τα νομίσματα αυτά δεν είναι διαιρέσιμα. • Semi fungible tokens (SFTs): Για τους προγραμματιστές τα νομίσματα αυτά είναι παρόμοια με τα NFTs, αλλά για τον τελικό χρήστη λειτουργούν ως ένα συγκεκριμένο νόμισμα από έναν μεγαλύτερο αριθμό πεπερασμένων νομισμάτων. Για παράδειγμα, τα εισιτήρια σε ένα θέατρο όλα είναι ίδια μεταξύ τους, αφού σου παρέχουν την είσοδο για την ίδια εκδήλωση, αλλά το καθένα έχει μια μοναδική θέση.
2.4.2 ΕRC tokens
O όρος ERC προέρχεται από το ‘Ethereum Request for Comments’ και είναι ένα τεχνικό έγγραφο που δημιουργείται από τους προγραμματιστές των smart contracts στο Ethereum για να ορίσει/προτείνει ένα σύνολο κανόνων. Προτού γίνει πρότυπο, ένα ERC πρέπει να διορθωθεί, να σχολιαστεί και να γίνει αποδεκτό από την κοινότητα. Αφού γίνει πρότυπο οι προγραμματιστές θα πρέπει να ακολουθούν τους αντίστοιχους κανόνες για να υλοποιήσουν ένα νέο νόμισμα στο Ethereum οικοσύστημα. Κάποια από τα πρότυπα αναλύονται παρακάτω:
• ERC-20: δίνει τη δυνατότητα δημιουργίας fungible νομισμάτων και ορίζει έξι διαφορετικές συναρτήσεις. Αυτές οι συναρτήσεις περιλαμβάνουν το τρόπο μεταφοράς των νομισμάτων και το πώς οι χρήστες μπορούν να δουν τις πληροφορίες τους σε σχέση με ένα συγκεκριμένο νόμισμα κ.α. Όλες μαζί, αυτές οι συναρτήσεις/κανόνες βεβαιώνουν ότι τα Ethereum νομίσματα διαφορετικού τύπου
Υπόβαθρο 13
θα λειτουργούν με ενιαίο τρόπο. Το Eth κρυπτονόμισμα ακολουθεί τους κανόνες αυτούς. • ERC-721: το πρότυπο αυτό περιγράφει τον τρόπο με τον οποίο τα non-fungible νομίσματα προγραμματίζονται στο Ethereum Blockchain. Είναι παρόμοιο με το ERC- 20 όσον αφορά την λειτουργικότητα. • ERC-875: το πρότυπο αυτό δίνει την δυνατότητα μεταφοράς πολλών non-fungible νομισμάτων μαζί και περιλαμβάνει μεθόδους για την διευθέτηση παραγγελιών με φθηνό και συγχρόνως ασφαλή και αποκεντρωμένο τρόπο. Στο ERC-875 μπορείς να κάνεις μια παραγγελία υπογράφοντας με την ψηφιακή σου υπογραφή ένα μήνυμα που περιλαμβάνει την τιμή, την διάρκεια που θες να ισχύει αυτή η παραγγελία και την ίδια την υπογραφή. Η διαδικασία αυτή γίνεται έξω από την αλυσίδα (off chain) και μεταδίδεται σε αυτήν μόνο την στιγμή της διευθέτησης. Αυτό σημαίνει ότι μπορείς να ενημερώσεις την παραγγελία σου χωρίς να πληρώσεις gas8. Όταν ένας αγοραστής ενδιαφέρεται το μόνο που χρειάζεται να κάνει είναι να παραλάβει την παραγγελία και να μεταδώσει την συναλλαγή με τις λεπτομέρειες της και το κατάλληλο ποσό ώστε να ολοκληρωθεί η συμφωνία. • ERC-998: δίνει τη δυνατότητα δημιουργίας non-fungible composable νομισμάτων, με άλλα λόγια είναι ένα πρότυπο προέκταση για οποιοδήποτε non-fungible νόμισμα να έχει στην ιδιοκτησία του οποιοδήποτε άλλο non-fungible ERC-721 ή fungible ERC- 20 νόμισμα. Μεταφέροντας το σύνθετο αυτό νόμισμα μεταφέρεται όλη η ιεραρχία των αντικειμένων μέσω μιας μοναδικής συναλλαγής. Αυτό το πρωτόκολλο προσθέτει ένα επίπεδο πολυπλοκότητας παραπάνω στην ψηφιακή ιδιοκτησία. • ERC-1155: δίνει τη δυνατότητα της δημιουργίας fungible, non-fungible και semi- fungible νομισμάτων μέσα από ένα πρότυπο. Τα στοιχεία στο πρότυπο αυτό αποθηκεύονται σε ένα μόνο contract (central smart contract) με τα ελάχιστα πιθανά δεδομένα που χρειάζονται για να ξεχωρίζουν μεταξύ τους τα διαφορετικά νομίσματα. Στο ERC-1155 μπορείς να στείλεις οποιονδήποτε αριθμό νομισμάτων σε έναν ή περισσότερους παραλήπτες με μία μόνο συναλλαγή.
2.5 Eos Blockchain
2.5.1 Τι είναι το Eos?
To Εos είναι ένα δωρεάν, ανοιχτού κώδικα blockchain πρωτόκολλο το οποίο παρέχει στους επιχειρηματίες και τους προγραμματιστές μια πλατφόρμα πάνω στην οποία μπορούν να χτίσουν και να τρέξουν υψηλής απόδοσης αποκεντρωμένες εφαρμογές. Όπως το Ethereum, το EOS είναι μια smart contract πλατφόρμα.
To Εos τρέχει τον αλγόριθμο συναίνεσης DPoS με προκαθορισμένο αριθμό παραγωγών μπλοκ που φτάνει τους 21. Κάτω από αυτόν τον αλγόριθμο, αυτοί που κατέχουν νομίσματα μπορούν να επιλέξουν παραγωγούς μπλοκ μέσα από ένα συνεχόμενο σύστημα ψηφίσματος. Ο καθένας μπορεί να επιλέξει να συμμετάσχει στην παραγωγή μπλοκ και θα του δοθεί η
8 Το gas είναι τα τέλη εκτέλεσης που πληρώνει ο χρήστης για κάθε διαδικασία που γίνεται στο Ethereum.
Υπόβαθρο 14
ευκαιρία δεδομένου ότι θα πείσει τους κατόχους νομισμάτων να τον ψηφίσουν ώστε να είναι ένας από τους 21.
Το Eos επιτρέπει να παράγονται μπλοκ ακριβώς κάθε 0.5 δευτερόλεπτα και ακριβώς ένας παραγωγός είναι εξουσιοδοτημένος να παράξει ένα μπλοκ σε οποιοδήποτε χρονικό σημείο. Αν ένα μπλοκ δεν παραχθεί στη προγραμματισμένη ώρα, τότε το μπλοκ για εκείνο το χρονικό διάστημα παραλείπεται. Όταν ένα ή περισσότερα μπλοκ παραλείπονται, τότε δημιουργείται ένα κενό 0.5 ή περισσοτέρων δευτερολέπτων στο Blockchain.
Τα μπλοκ δημιουργούνται σε γύρους των 126 ( 6 μπλοκ ο καθένας, από τους 21 παραγωγούς, κάθε φορά). Στην αρχή κάθε γύρου 21 μοναδικοί παραγωγοί μπλοκ επιλέγονται, ανάλογα με τις ψήφους που κατέχουν εκείνη τη στιγμή από τους κατόχους των νομισμάτων. Οι επιλεγόμενοι παραγωγοί προγραμματίζουν την παραγωγή με την σειρά που έχει συμφωνηθεί από τους 15 ή παραπάνω παραγωγούς. Εάν ένας παραγωγός χάσει ένα μπλοκ και δεν έχει παράξει μπλοκ τις τελευταίες 24 ώρες τότε σταματάει να λαμβάνεται υπόψιν μέχρι να ειδοποιήσει για την πρόθεση του να ξεκινήσει να παράγει ξανά. Αυτό βεβαιώνει ότι το δίκτυο λειτουργεί ομαλά, μειώνοντας των αριθμό των χαμένων μπλοκ από τους προγραμματισμένους παραγωγούς οι οποίοι είναι αναξιόπιστοι.
2.5.2 Στοίβα (Stack)
Εικόνα 1 Μια τυπική αλληλεπίδραση με το Eos Blockchain
Nodeos
Το nodeos είναι το βασικό daemon9 ενός κόμβου στο Eos. Διάφορα πρόσθετα στοιχεία (plugins) μπορούν να χρησιμοποιηθούν για να ρυθμίσουν το nodeos να λειτουργεί με επιπλέον λειτουργίες. Το nodeos διαχειρίζεται όλη την peer-to-peer (P2P) δικτύωση, τον προγραμματισμό βάση του οποίου θα τρέξει ο κώδικας του contract, καθώς επίσης και το στρώμα αντοχής δεδομένων (data persistence layer) του Blockchain. Για τα περιβάλλοντα ανάπτυξης, το nodeos χρησιμοποιείται για να “στήσει” (set up) ένα blockchain δίκτυο ενός κόμβου.
9 To daemon στην επιστήμη των υπολογιστών είναι ένα πρόγραμμα του υπολογιστή το οποίο τρέχει στο παρασκήνιο και δεν είναι άμεσα ελέγξιμο από τον χρήστη που αλληλεπιδρά με αυτόν.
Υπόβαθρο 15
Cleos
To cleos είναι ένα command-line εργαλείο, το οποίο δίνει τη δυνατότητα στους προγραμματιστές να αλληλεπιδράσουν με το nodeos, καθώς επίσης και να κάνουν deploy, είτε να τεστάρουν τα smart contracts τους.
Keosd
To keosd είναι ένα εργαλείο διαχείρισης κλειδιών για τα Eos Accounts. [42]
2.5.3 Λογαριασμοί και Άδειες (Accounts and Permissions)
Λογαριασμοί
Ένας λογαριασμός στο Eos είναι ένα ανθρώπινα αναγνωρίσιμο όνομα το οποίο αποθηκεύεται στο Blockchain. Ένας λογαριασμός μπορεί να ανήκει σε ένα άτομο ή σε μια ομάδα ατόμων ανάλογα με το πώς έχουν ρυθμιστεί οι άδειες. Η ύπαρξη λογαριασμού είναι απαραίτητη αν κάποιος θέλει να μεταφέρει ή όπως λέγεται να αποστείλει μία συναλλαγή στο Blockchain. Όλοι οι λογαριασμοί στο Eos είναι 12 χαρακτήρες σε μέγεθος ( εκτός αν είναι premium10). Οι λογαριασμοί χωρίζονται σε δύο ειδών:
• Contract accounts: οι λογαριασμοί αυτοί χρησιμοποιούνται για να παρέχουν αποκεντρωμένες υπηρεσίες και ελέγχονται από το ιδιωτικό τους κλειδί και τον Wasm κώδικα τους. Για να κάνει κανείς deploy ένα smart contract χρειάζεται έναν λογαριασμό. Για παράδειγμα ο eosio.token λογαριασμός, ο οποίος είναι ο λογαριασμός που βασίζεται το νόμισμα του Eos, παρέχει λειτουργίες, όπως η δημιουργία, η μεταφορά και η έκδοση νομισμάτων. • Externally owned accounts: οι λογαριασμοί αυτοί είναι οι λογαριασμοί χρήστη και υπάρχουν για τη χρήση κάποιας αποκεντρωμένης εφαρμογής ή κάποιας υπηρεσίας, όπως η μεταφορά χρημάτων, ο στοιχηματισμός κ.α. Οι λογαριασμοί αυτοί ελέγχονται από το ιδιωτικό τους κλειδί/κλειδιά και δεν μπορούν να περιέχουν Wasm κώδικα.
Εικόνα 2 Αλληλεπίδραση λογαριασμών διαφορετικού είδους
10 Στα πλαίσια αυτής της διπλωματικής η εξήγηση της έννοιας δεν θα αναλυθεί μπορεί κάποιος να ανατρέξει στην αναφορά [66]
Υπόβαθρο 16
Άδειες
Οι άδειες ορίζουν τις προϋποθέσεις ώστε μια συναλλαγή να αποσταλεί με βάση αυτήν την άδεια. Ένας Eos λογαριασμός αποτελείται από δύο κλειδιά, το ενεργό κλειδί (active key) και το κλειδί ιδιοκτήτης (owner key). Το ενεργό κλειδί μπορεί να χρησιμοποιηθεί για την μεταφορά νομισμάτων, για την ψήφιση ενός παραγωγού μπλοκ και γενικά για να κάνει μια συναλλαγή στο blockchain. Από την άλλη το κλειδί ιδιοκτήτης δείχνει την ιδιοκτησία ενός λογαριασμού και χρειάζεται για να γίνει οποιαδήποτε αλλαγή στην ιδιοκτησία του λογαριασμού. Πολλές ακόμα ειδικές άδειες ( custom permissions) μπορούν να προστεθούν μέσα σε ένα λογαριασμό, αυτές οι δύο είναι όμως οι βασικές (native). Στο Eos μπορεί κάποιος να αλλάξει την δομή των αδειών και να δημιουργήσει ένα λογαριασμό πολλών υπογραφών ( multi-signature account). Με τον όρο λογαριασμό πολλών υπογραφών εννοούμε ότι είναι δυνατό να απαιτείται περισσότεροι του ενός ατόμου να εγκρίνουν μία συναλλαγή. Ένα παράδειγμα φαίνεται στην Εικόνα 3.
Εικόνα 3 Παράδειγμα λογαριασμού πολλών υπογραφών
Στο παράδειγμα αυτό βλέπουμε ότι χρειάζεται τη συναίνεση του Bob και της Stacy για να σταλθεί μία συναλλαγή ή να γίνει οποιαδήποτε αλλαγή στην άδεια της ιδιοκτησίας. Επίσης, βλέπουμε ότι έχει προστεθεί μια ακόμη άδεια πέρα από τις βασικές, η οποία ας υποθέσουμε ότι είναι η άδεια για να δημοσιευθεί ένα άρθρο σε ένα συγκεκριμένο περιοδικό. Για να επιτευχθεί η δημοσίευση αυτού του άρθρου χρειάζεται είτε την υπογραφή του Bob είτε της Stacy, ενώ το δημόσιο κλειδί που φαίνεται δεν είναι σε θέση μόνο του να δημοσιεύσει το άρθρο. Για την δημιουργία λογαριασμού στο Eos χρειάζεται να χρησιμοποιηθεί ένας ήδη υπάρχον λογαριασμός. [43] [44]
2.5.4 Συναλλαγές (Transactions)
Το Eos λειτουργεί με ένα μοντέλο ιδιοκτησίας όπου ο χρήστης μπορεί να χρησιμοποιήσει πόρους ανάλογα με το μερίδιο ιδιοκτησίας του στο δίκτυο και δεν χρειάζεται να πληρώσει για κάθε συναλλαγή, γεγονός που βοηθάει στην εξάλειψη των προμηθειών συναλλαγής. Ο χρήστης διατηρώντας ένα συγκεκριμένο μερίδιο στην κατοχή του μπορεί να χρησιμοποιεί τις εφαρμογές δωρεάν.
Υπόβαθρο 17
Η συναλλαγή είναι μία ειδικά διαμορφωμένη δομή δεδομένων που υπογράφεται από το ιδιωτικό κλειδί ενός externally owned λογαριασμού και μεταδίδεται σε ένα κόμβο του Eos. Μια συναλλαγή σε μορφή JSON11 στο Eos φαίνεται στην Εικόνα 4.
Τα 4 πρώτα πεδία της συναλλαγής έχουν πάντα αυτή τη μορφή και χρησιμοποιούνται για να υποδείξουν ότι η συναλλαγή μπορεί να προστεθεί μόνο μετά από το συγκεκριμένο μπλοκ (ref_block_num) και πριν από την λήξη της (expiration). Χρησιμοποιείται για να γνωστοποιεί στο δίκτυο σε ποια κατάσταση της αλυσίδας υπέγραψε μια συναλλαγή. Αυτό βοηθάει στην αντιμετώπιση συγκεκριμένων επιθέσεων, όπως τις επιθέσεις επανάληψης όπου ένας κακόβουλος χρήστης προσπαθεί να επαναλάβει την ίδια συναλλαγή, παρόλο που η κατάσταση του δικτύου άλλαξε.
Τα επόμενα 2 έχουν σχέση με τους πόρους που χρειάστηκαν για αυτήν την συναλλαγή. Το kcpu_usage έχει να κάνει με το CPU bandwidth και εξαρτάται από το χρόνο εκτέλεσης της συναλλαγής και το net_usage_words έχει να κάνει με το ΝΕΤ bandwidth και εξαρτάται από το μέγεθος της συναλλαγής σε bytes.
Τα πεδία context_free_actions και context_free_data αφορούν τα actions που δεν εξαρτώνται από την κατάσταση (state) του blockchain και μπορούν να εκτελεστούν παράλληλα. Actions
Μια συναλλαγή μπορεί να έχει ένα ή περισσότερα actions που πρέπει να εφαρμοστούν στην σειρά και ατομικά (όλες να επιτύχουν ή όλες αν αποτύχουν). Στο παράδειγμα αυτό έχουμε μόνο ένα action.
Account
Κάθε action πρέπει να προσδιορίζει ποιός κώδικας θα εκτελεστεί. Στην περίπτωση μας ο currency κώδικας θα εκτελεστεί μέσω της currency::apply_currency_transfer(data) μεθόδου.
Name
Το πεδίο name καθορίζει το είδος του action (και κατ’ επέκταση τη δομή των δεδομένων). Από την οπτική του αντικειμενοστραφή προγραμματισμού μπορούμε να θεωρήσουμε το name ως το όνομα της μεθόδου της κλάσης account. Στην περίπτωση μας το name είναι transfer και ως αποτέλεσμα η transfer μέθοδος θα καλεστεί.
Recipients
Η μέθοδος που καλέστηκε κατά την ανάλυση του account θα καλεστεί επίσης και για την λίστα των recipients και η σειρά εκτέλεσης τους θα είναι η παρακάτω.
1. currency::apply_currency_transfer(data) 2. alice::apply_currency_transfer(data) 3. sam::apply_currency_transfer(data)
11 Η JSON (JavaScript Object Notation) είναι μια ελαφριά μορφή ανταλλάξιμων δεδομένων. Είναι εύκολη για τον άνθρωπο να την διαβάσει και να την γράψει. Και εύκολο για τις μηχανές να τις παράξουν και να την αναλύσουν.
Υπόβαθρο 18
Ο συμβολισμός account:: προσδιορίζει το contract που υλοποιεί την μέθοδο. Η alice και ο sam μπορεί να επιλέξουν να μην υλοποιήσουν αυτήν την μέθοδο αν δεν υπάρχει κάποια συγκεκριμένη λογική να εκτελέσουν κατ’ ακολουθία της εκτέλεσης currency::apply_currency_transfer(data). Ωστόσο, αν ο sam ήταν ένα ανταλλακτήριο θα ήθελε πιθανόν να επεξεργαστεί τις καταθέσεις και τις αναλήψεις κάθε φορά που γίνεται μία μεταφορά ενός νομίσματος. Ο χρήστης που δημιουργεί την συναλλαγή μπορεί να προσθέσει οποιονδήποτε αριθμό recipients. Επιπλέον, κάποια contracts μπορεί να χρειάζεται να ειδοποιήσουν τα άτομα που συμμετέχουν σε μια συναλλαγή. Στην περίπτωση μας η alice και ο sam χρειάζεται να ειδοποιηθούν.
Authorization
Κάθε action μπορεί να απαιτεί εξουσιοδότηση από έναν ή περισσότερους λογαριασμούς. Στο Eos το μήνυμα πρέπει ρητά να ορίζει την άδεια που του παρατέθηκε. Το σύστημα του Eos πιστοποιεί αυτόματα ότι η συναλλαγή υπογράφηκε από όλους τους απαραίτητους λογαριασμούς ώστε να αποδώσει τις εν λόγω εξουσιοδοτήσεις. Στην περίπτωση μας το action ορίζει ότι πρέπει να υπογραφεί από την ενεργή άδεια του sam και o currency κώδικας θα πιστοποιήσει ότι η άδεια αποδόθηκε.
Data
Κάθε contract ορίζει τη δικιά του μορφή δεδομένων. Χωρίς το Application Binary Interface (ABI)12 τα δεδομένα μπορούν μόνο να μεταγλωττιστούν ως δεκαεξαδικά δεδομένα. [45] [46]
2.5.5 Πόροι (Resources)
Όλα τα Blockchain συστήματα είναι περιορισμένων πόρων και για αυτόν το λόγο απαιτούν ένα τρόπο για να αποφύγουν την κατάχρηση τους. Το Eos έχει 3 μεγάλες κλάσεις πόρων που καταναλώνονται από τις εφαρμογές που τρέχουν σε αυτό:
• Bandwidth and log storage (Disk): το πρώτο στοιχείο έχει να κάνει με την στιγμιαία χρήση του συστήματος και δείχνει το μερίδιο της αναπαράστασης δικτύου ενός μπλοκ που μπορεί να χρησιμοποιηθεί για την αποθήκευση της εκάστοτε συναλλαγής καθώς μεταδίδεται στο peer-to-peer (P2P) επίπεδο, ή πιο απλά το μέγεθος της συναλλαγής. Μετριέται σε bytes. Το δεύτερο έχει να κάνει με την μακροχρόνια χρήση του συστήματος και περιέχει ένα αρχείο από actions. Αυτό το αρχείο αποθηκεύεται και μεταφορτώνεται από όλους τους κόμβους. Με αυτό το αρχείο των actions είναι δυνατόν να ανακατασκευαστεί η κατάσταση όλων των εφαρμογών. • Computation and Computational Backlog (CPU): έχει την ίδια μορφή με τον προηγούμενο πόρο και το πρώτο στοιχείο δείχνει το ποσό του χρόνου που πρέπει ένας Eos παραγωγός μπλοκ να διαθέσει για τις συναλλαγές από τον εκάστοτε λογαριασμό. Μετριέται σε microseconds. Το δεύτερο δείχνει τους υπολογισμούς που πρέπει να γίνουν για να ανακατασκευαστεί η κατάσταση από το αρχείο των actions.
12 Είναι μια διεπαφή μεταξύ δύο τμημάτων προγράμματος, συχνά ένα από αυτά τα τμήματα είναι ένα λειτουργικό σύστημα ή μια βιβλιοθήκη και το άλλο είναι το πρόγραμμα που τρέχει ο χρήστης.
Υπόβαθρο 19
{ "expiration": "2015-05-15T14:29:01", "region": 0, "ref_block_num": "12", "ref_block_prefix": "2792049106", "net_usage_words": ..., "kcpu_usage": ..., "delay_sec": 0, "context_free_actions": [], "actions": [ { "account": "currency", "name": "transfer", "recipients": [ "sam", "alice" ], "authorization": [ { "actor": "sam", "permission": "active" } ], "data": "a34a59dcc8000000c9251a0000000000501a00000000000008454f53000000000568656c6c6 f" } ], "signatures": [], "context_free_data": [] }
Εικόνα 4 Ένα παράδειγμα συναλλαγής στο Eos
• State Storage (RAM): είναι δεδομένα που είναι προσβάσιμα από το smart contract. Περιέχει δεδομένα, όπως βιβλία παραγγελιών και το υπόλοιπο των λογαριασμών. Αν τα δεδομένα αυτά δεν διαβάζονται ποτέ από τα smart contract, τότε δεν χρειάζεται να αποθηκεύονται εκεί.
Οι παραγωγοί μπλοκ δημοσιοποιούν την διαθέσιμη χωρητικότητα σε bandwidth, computations και state. Το λογισμικό του Eos επιτρέπει κάθε λογαριασμό να καταναλώσει ένα ποσοστό της διαθέσιμης χωρητικότητας ανάλογο του ποσού των νομισμάτων που έχει κρατημένα σε ένα 3-ημερών staking contract, όπως λέγεται. Ο παραπάνω ισχυρισμός ισχύει για τους 2 πρώτους πόρους, η RAM πρέπει να αγοραστεί από τον ενδιαφερόμενο μέσα από μια ελεύθερη αγορά.
2.5.6 Smart Contracts
Ένα Eos smart contract είναι ένα λογισμικό το οποίο είναι εγγεγραμμένο στο blockchain και εκτελείται από τους Eos κόμβους. Ο ορισμός αυτός υλοποιεί την σημασιολογία του όρου “contract”, του οποίου το βιβλίο των δράσεων (actions) που εκτελούνται αποθηκεύονται στο blockchain. To smart contract ορίζει τη διεπαφή (των δράσεων, των παραμέτρων και της
Υπόβαθρο 20
δομής των δεδομένων) και τον κώδικα που υλοποιεί την διεπαφή αυτή. Ο κώδικας μεταγλωττίζεται σε κανονικοποιημένη bytecode μορφή, την οποία οι κόμβοι μπορούν να ανακτήσουν και να εκτελέσουν [47]. Στο Eos Blockchain σε αντίθεση με το Ethereum, η ανανέωση ενός contract αφού έχει γίνει το deploy είναι εφικτή.
Το Eos υποστηρίζει smart contracts μέσω της WebAssembly13 εικονικής μηχανής [48]. Οποιαδήποτε γλώσσα μπορεί να μεταγλωττιστεί σε WebAssembly (Wasm) μπορεί να χρησιμοποιηθεί για τον προγραμματισμό ενός smart contract στο Eos, ωστόσο η C++ είναι η προτεινόμενη προς χρησιμοποίηση γλώσσα για τους προγραμματιστές. O compiler που χρησιμοποιεί το Eos λέγεται eosio-cpp. Για να κάνει κανείς deploy ένα smart contract, χρειάζονται το WebAssembly (Wasm) και το Application Binary Interface (ABI), τα οποία μπορούν να αποκτηθούν από τον eosio-cpp μεταγγλωττιστή.
1 #include
13 Η WebAssembly (Wasm) είναι μια οδηγία δυαδικής μορφής για stack-based εικονικές μηχανές. Η Wasm είναι σχεδιασμένη ως ένας φορητός σημείο για τη μεταγλώττιση γλωσσών υψηλού επιπέδου όπως η C/C++/Rust, ώστε να επιτρέπει την ανάπτυξη στο διαδίκτυο για client και server εφαρμογές.
3 Τεχνικά Πλαίσια & Εργαλεία
Στο Κεφάλαιο αυτό θα παρουσιάσουμε τα εργαλεία που χρησιμοποιήθηκαν για την υλοποίηση της διπλωματικής καθώς επίσης και τα τεχνικά πλαίσια.
3.1 Βασικά Εργαλεία
3.1.1 Eosio
Αυτό είναι το λογισμικό που πρέπει να εγκαταστήσει ένας smart contract προγραμματιστής κατά τη διάρκεια της υλοποίησης των smart contract για να τα τεστάρει. Μέσω του λογισμικού αυτού ο προγραμματιστής μπορεί να ξεκινήσει το δικό του blockchain τοπικό δίκτυο και να έχει τα κατάλληλα εργαλεία για να αλληλεπιδράσει με αυτό [49] [50] (Τα εργαλεία αυτά αναφέρθηκαν στο Κεφάλαιο 2 στην ενότητα Στοίβα).
Μετά την υλοποίηση και για το τεστάρισμα των smart contract σε ένα περιβάλλον με συνθήκες πιο κοντινές με αυτές του κεντρικού δικτύου (mainnet) ο προγραμματιστής μπορεί να κάνει deploy τα smart contract σε ένα από τα παρακάτω διαθέσιμα δίκτυα τεσταρίσματος (testnets) :
• Jungle Testnet • CryptoKylin Testnet • Telos Testnet
Εμείς επιλέξαμε το πρώτο από τα παραπάνω λόγω την μεγάλης υποστήριξης που έχει από τους παραγωγούς μπλοκ του mainnet.
3.1.2 Eosio.cdt
Το eosio.cdt είναι μια εργαλειοθήκη για την WebAssembly (Wasm) και ένα σύνολο εργαλείων για να διευκολύνει στην συγγραφή smart contract για την Eos πλατφόρμα. Εκτός από το ότι είναι μία γενικού σκοπού εργαλειοθήκη, παρέχει ακόμα συγκεκριμένες βελτιστοποιήσεις (optimizations) στο επίπεδο των smart contract για το Eosio Λογισμικό. Αυτή η εργαλειοθήκη (eosio-cpp) έχει χτιστεί γύρω από το Clang 7 14, που σημαίνει ότι έχει τις πιο πρόσφατες βελτιώσεις και αναλύσεις της υποδομής μεταγλώττισης LLVM [51] [52].
14 Είναι ένα μέρος της υποδομής μεταγλώττισης LLVM.
21
Τεχνικά Πλαίσια & Εργαλεία 22
3.1.3 Universal Authenticator Library (UAL Core)
Είναι μια βιβλιοθήκη, η οποία δίνει τη δυνατότητα στις εφαρμογές να υποστηρίζουν πολλούς παρόχους επιβεβαίωσης γνησιότητας (wallets). Το καταφέρνει αυτό αφαιρώντας την επιχειρηματική λογική (business logic) πολλών παρόχων επιβεβαίωσης γνησιότητας, εκθέτοντας ένα μόνο γενικό API15. Το UAL επίσης παρέχει μία μορφή απεικόνισης, ώστε ο χρήστης να λαμβάνει την ίδια ροή πληροφορίας ανεξάρτητα από τον πάροχο που χρησιμοποιεί. Τα wallets που υποστηρίζει μέχρι την ημέρα εκπόνησης αυτής της διπλωματικής είναι τα Scatter, Lynx, Ledger, Token Pocket [53].
Εικόνα 6 Αρχιτεκτονική της UAL βιβλιοθήκης
3.1.4 Eos.js
Το Eos.js είναι η βιβλιοθήκη που χρησιμοποιείται για την αλληλεπίδραση με έναν τοπικό ή έναν απομακρυσμένο Eos κόμβο χρησιμοποιώντας μια HTTP σύνδεση. Αυτό γίνεται εφικτό μέσω του RPC16 API [54] που εκθέτει το Eos Blockchain [55].
3.1.5 React
H React είναι μια Javascript βιβλιοθήκη για τη δημιουργία διεπαφών χρήστη βασισμένων σε στοιχεία (component-based) [56].
3.1.6 Redux
Η Redux είναι μια Javascript βιβλιοθήκη η οποία βοηθάει στην διαχείριση των δεδομένων που εμφανίζονται στο χρήστη και του τρόπου με τον οποίο αποκρίνεται στην δράσεις του
15 Είναι μία διεπαφή ή ένα πρωτόκολλο επικοινωνίας μεταξύ ενός χρήστης και ενός διακομιστή 16 Remote Procedure Call
Τεχνικά Πλαίσια & Εργαλεία 23
χρήστη μια Javascript εφαρμογή. Θα μπορούσαμε να πούμε ότι λειτουργεί σαν μια βάση δεδομένων για το μπροστινό κομμάτι (frontend) μιας εφαρμογής.
3.2 Βασικές Τεχνολογίες
3.2.1 Τεχνολογίες Web
Οι τεχνολογίες web περιέχουν γλώσσες σήμανσης, όπως την HTML, γλώσσες styling, όπως η CSS, και γλώσσες scripting, όπως η Javascript. Για την εργασία αυτή χρησιμοποιήθηκαν όλες οι παραπάνω στο επίπεδο της υλοποίησης της διεπαφής χρήστη (frontend) που θα επικοινωνεί με την υπόλοιπη εφαρμογή. Για την επικοινωνία της διεπαφής με το πίσω μέρος (backend) της εφαρμογής καθώς επίσης και για την υλοποίηση του πίσω μέρους χρησιμοποιήθηκε πάλι η Javascript 17και κάποια npm πακέτα.
3.2.2 C++
H C++ σε συνδυασμό με την C++ βιβλιοθήκη του Eos χρησιμοποιήθηκαν για τον προγραμματισμό των smart contract.
17 Για το backend μέρος χρησιμοποιήθηκε ο Node.js διακομιστής, ο οποίος επιτρέπει να “τρέχεις” Javascript στον διακομιστή.
4 Eos & Security
Στο κεφάλαιο αυτό θα αναλύσουμε ευπάθειες που έχουν βρεθεί τόσο στο επίπεδο του δικτύου του πρωτοκόλλου του Eos όσο και στο επίπεδο των smart contracts και τις βέλτιστες πρακτικές για την δημιουργία στιβαρών και ασφαλών smart contracts. Πρέπει να σημειωθεί εδώ ότι η ασφάλεια των smart contracts δεν πρέπει να συγχέεται με την ασφάλεια του δικτύου, αυτά τα δύο διαφέρουν μεταξύ τους με κάποιες εξαιρέσεις που το blockchain επίπεδο επηρεάζει αυτό των smart contracts.
4.1 Επιθέσεις στο επίπεδο του Δικτύου
Στις 10 Ιανουαρίου του 2019 ανιχνεύτηκε από μία εταιρεία ασφαλείας ονόματι PeckShield ένα είδος επιθέσεων συμφόρησης συναλλαγών (transaction congestion attacks). Αυτή είναι μια επίθεση denial-of-service στο blockchain επίπεδο όπου ο επιτιθέμενος ξεκινάει πολλές deferred transaction18 με σκοπό να εξαναγκάσει τους παραγωγούς μπλοκ να παράξουν μπλοκ με έγκυρες συναλλαγές, δηλαδή να σταματήσουν τις συναλλαγές των χρηστών του δικτύου από το να μπουν σε μπλοκ και έτσι να παραλύσουν το Eos σύστημα.
Μια τυπική συναλλαγή στο Eos φαίνεται στην Εικόνα 7. Ο χρήστης στέλνει ένα αίτημα συναλλαγής μέσω του cleos ή με άλλο τρόπο στο API ενός κόμβου, το API επεξεργάζεται το αίτημα και τελικά το αίτημα φτάνει στον παραγωγό μπλοκ για να συμπεριληφθεί σε ένα μπλοκ.
Εικόνα 7 Η διαδικασία εκτέλεσης μιας τυπικής συναλλαγής στο Eos
Οι deferred συναλλαγές έχουν προτεραιότητα έναντι των συναλλαγών που έχουν υπογραφεί από τους χρήστες. Πιο συγκεκριμένα, όταν μια deferred συναλλαγή προγραμματιστεί προσπερνάει το επίπεδο του API του κόμβου και φτάνει κατευθείαν στην ουρά εκτέλεσης των παραγωγών μπλοκ και, αφού έχει προτεραιότητα, εκτελείται πριν από τις συναλλαγές των χρηστών. Εκμεταλλευόμενος την παραπάνω διαδικασία ο επιτιθέμενος και αφού μπορεί να δημιουργεί deferred συναλλαγές μέσα από άλλες deferred συναλλαγές, δημιουργεί ένα μεγάλο αριθμό deferred άσκοπων, συμπεριλαμβάνοντας σε αυτές dead loops (ατέρμων
18 H deferred συναλλαγή είναι μία συναλλαγή που προγραμματίζεται να γίνει σε μία μελλοντική στιγμή του χρόνου, αυτή η συναλλαγή μπορεί να γίνει στο επίπεδο των smart contracts
24
Eos & Ασφάλεια 25
βρόγχους), ώστε να προκαλέσει timeout, να χρησιμοποιήσει όλο το CPU χρόνο και να παραλύσει το δίκτυο. Μία απεικόνιση της διαδικασίας εκτέλεσης της deferred συναλλαγής φαίνεται στην Εικόνα 8.
Εικόνα 8 Η ροή εκτέλεσης μίας deferred συναλλαγής
Η επίλυση του προβλήματος αυτού έγινε περιορίζοντας το CPU χρόνο της διευθέτησης των εν αναμονή deferred συναλλαγών στο κάθε μπλοκ , κρατώντας κάποιο CPU χρόνο για τις συναλλαγές των χρηστών [57].
Στις 13 Σεπτεμβρίου του 2019 έλαβε μέρος μια επίθεση, η οποία μοχλεύοντας το eosio.rex19 smart contract του συστήματος κατάφερε να κατακλύσει (flood) το σύστημα με σκοπό να κερδίσει σε μια αποκεντρωμένη εφαρμογή στοιχήματος. Ο επιτιθέμενος λοιπόν, νοίκιασε ένα μεγάλο ποσό CPU και ΝΕΤ από το eosio.rex ανταλλακτήριο πόρων (resource exchange). Ο επιτιθέμενος έκανε stake αυτούς τους πόρους για μερικούς λογαριασμούς χρήστη και ένα λογαριασμό contract που του ανήκαν, παρέλυσε το δίκτυο καταφέρνοντας να χρησιμοποιήσει το Blockchain για να τρέξει μόνο τις δικές του συναλλαγές. Η επίθεση αυτή είναι παρόμοια με τις επιθέσεις spam που έγιναν στο Ethereum και στο Bitcoin δίκτυο και προκάλεσαν την εκτόξευση του κόστους συναλλαγών. Είναι και αυτή μια denial-of-service επίθεση. Δεν έχει προταθεί ακόμα κάποια λύση από την κοινότητα [58] [59].
4.2 Επιθέσεις και βέλτιστες πρακτικές στο επίπεδο των smart contract
Στο Κεφάλαιο αυτό θα δούμε μερικές καλές πρακτικές και κάποιες από τις σημαντικότερες επιθέσεις που έχουν γίνει μέχρι την στιγμή της εκπόνησης της διπλωματικής στο επίπεδο των smart contract [60]. Ένα πλήρες αρχείο όλων των επιθέσεων μπορεί να βρεθεί εδώ [61].
4.2.1 Numerical Overflow
Όταν γίνονται πράξεις στο επίπεδο των smart contract, η έλλειψη ελέγχου των ορίων μπορεί να επιφέρει υπερχείλιση στις μεταβλητές προκαλώντας το χάσιμο των ιδιοκτησιών του χρήστη. Οι προγραμματιστές θα πρέπει, όταν αυτό είναι εφικτό, να χρησιμοποιούν την δομή
19 Το contract αυτό δίνει τη δυνατότητα στους κατόχους νομισμάτων να μισθώσουν τα νομίσματα που τους περισσεύουν σε αποκεντρωμένες εφαρμογές ή σε άλλους που χρειάζονται πόρους, για κάποιο αντίτιμο.
Eos & Ασφάλεια 26 asset20 της βιβλιοθήκης του Eos για τις πράξεις, η οποία φροντίζει για τις περιπτώσεις υπερχείλισης. Δεν υπήρχε επίθεση σχετική με αυτό [62].
4.2.2 Authorization Check
Πρέπει να ελέγχεται αυστηρά ότι οι παράμετροι που έχουν περάσει σε ένα action είναι συνεπείς με τον πραγματικό καλούντα, ώστε οι λειτουργίες που θα εκτελεστούν δεν θα επηρεάσουν κάποιο τρίτο πρόσωπο. Αυτό μπορεί να γίνει χρησιμοποιώντας μία εκ των δυο συναρτήσεων της βιβλιοθήκης του Eos, require_auth ή require_auth2, οι οποίες ελέγχουν το αν η ψηφιακή υπογραφή που δόθηκε κατά την κλήση της συνάρτησης είναι σωστή. Δεν υπήρχε επίθεση σχετική με αυτό [62].
4.2.3 Apply Check
Κατά την υλοποίηση της apply μεθόδου που βρίσκεται στο τέλος κάθε smart contract και καλείται από τον εκάστοτε κόμβο για να τρέξει τα action του εκάστοτε smart contract με τον τρόπο που αυτή ορίζει (ουσιαστικά γίνεται μια χαρτογράφηση του κώδικα που καλείται αναλόγως με το όνομα του action που θα ακούσει το smart contract), πρέπει να εξασφαλίζεται ότι κάθε action και κάθε κώδικας καλείται για τον εν λόγω σκοπό. Έχουν υπάρξει πολλές επιθέσεις σχετικές με αυτή τη συνάρτηση από τις οποίες θα αναλύσουμε την πιο ζημιογόνα. Στην Εικόνα 9 φαίνεται η apply συνάρτηση του EOSBet smart contract, το οποίο στοχοποιήθηκε με αποτέλεσμα να αφαιρεθούν 44,427.4302 EOS από τον λογαριασμό αυτού του contract. Στο αναμενόμενο σενάριο, το contract ακούει μόνο την συνάρτηση transfer του eosio.token21 (στη γραμμή 10 με τον όρο code == N(eosio.token)) contract και την επεξεργάζεται μέσω της δικιάς του συνάρτησης transfer. Ο επιτιθέμενος όμως κατάφερε να καλέσει κατευθείαν την συνάρτηση transfer παρακάμπτοντάς το eosio.token και παρέχοντας ως είσοδο ό,τι τιμές ήθελε με αποτέλεσμα να φαίνεται ότι ποντάρει χωρίς να τοποθετεί στην ουσία λεφτά κερδίζοντας έτσι Eos σε περίπτωση νίκης [63]. Το πρόβλημα λύνεται αντικαθιστώντας την γραμμή 10 της Εικόνα 9 με την γραμμή : if( ((code == self && action != N(transfer) ) || (code == N(eosio.token) && action == N(transfer)) || action == N(onerror)) )
20 Η δομή αυτή αναλύεται περισσότερο στο κεφάλαιο της υλοποίησης 21 Είναι το contract του συστήματος του Eos που διαχειρίζεται το Eos νόμισμα.
Eos & Ασφάλεια 27
1 extern "C" { \ 2 void apply( uint64_t receiver, uint64_t code, uint64_t action ) { \ 3 auto self = receiver; \ 4 if( action == N(onerror)) { \ 5 /* onerror is only valid if it is for the "eosio" code account and authorized by "eosio"'s 6 "active permission */ \ 7 eosio_assert(code == N(eosio), "onerror action's are only valid from the \"eosio\" system 8 account"); \ 9 } \ 10 if( code == self || code == N(eosio.token) || action == N(onerror) ) { \ 11 TYPE thiscontract( self ); \ 12 switch( action ) { \ 13 EOSIO_API( TYPE, MEMBERS ) \ 14 } \ 15 /* does not allow destructor of thiscontract to run: eosio_exit(0); */ \ 16 } \ 17 } \ 18 } 19 Εικόνα 9 Ευπαθής Apply function στο EOSBet
4.2.4 Transfer Error Prompt
Είναι μέρος της προηγούμενης ευπάθειας, αυτήν τη φορά στην συνάρτηση που διεκπεραιώνει την ειδοποίηση που έρχεται από την transfer συνάρτηση του eosio.token μέσω της μεθόδου require_recipient . Η συνάρτηση αυτή πρέπει να βεβαιώνει ότι η μεταφορά των νομισμάτων γίνεται στο λογαριασμό του εκάστοτε contract. Μία τέτοια επίθεση έγινε στο EOSDice smart contract. Ο επιτιθέμενος δημιουργώντας ένα λογαριασμό χρήστη και ένα λογαριασμό contract κατάφερε να “ξεγελάσει” πάλι τους ελέγχους που γίνονταν στην apply συνάρτηση στέλνοντας νομίσματα από το λογαριασμό χρήστη στο λογαριασμό contract που του ανήκαν και μέσω του τελευταίου ανακατεύθυνε την ειδοποίηση που έπαιρνε από την συνάρτηση transfer του eosio.token στο smart contract του EOSDice με τη χρήση της μεθόδου require_recipient. Το EOSDice παρερμήνευε την ειδοποίηση και έτσι ο επιτιθέμενος έπαιζε χωρίς να ποντάρει νομίσματα. Στην Εικόνα 10 φαίνεται το φιλτράρισμα στην συνάρτηση transfer του EOSDice [64]. Η λύση σε αυτήν την ευπάθεια είναι η προσθήκη της γραμμής: if (transfer_data.to != _self) return;
4.2.5 Random Number Generator
Οι αλγόριθμοι παραγωγής τυχαίων αριθμών δεν πρέπει να βασίζονται σε εισόδους (seeds) που είναι ελεγχόμενες ή που μπορούν να προβλεφθούν, όπως κάποια δεδομένα του Blockchain. Μία επίσημη λύση προτείνεται να ακολουθηθεί από τους προγραμματιστές, όταν σχεδιάζουν εφαρμογή που υλοποιεί μια τυχαία κλάση, βλέπε εδώ [65].
Eos & Ασφάλεια 28
1 // source code: https://gitlab.com/EOSBetCasino/eosbetdice_public/blob/ 2 master/EOSBetDice.cpp 3 void transfer(uint64_t sender, uint64_t receiver) { 4 auto transfer_data = unpack_action_data
5 Υλοποίηση
5.1 Επιχειρησιακή Λογική
Ο σκοπός αυτής της υλοποίησης είναι να δώσει στους διοργανωτές εκδηλώσεων την δυνατότητα να μπορούν να ελέγξουν εξολοκλήρου τον κύκλο ζωής των εισιτηρίων τους χωρίς να χρειάζεται να εμπιστευτεί όλους τους πιθανούς εμπλεκόμενους της πορείας αυτής. Ένας διοργανωτής λοιπόν, μπορεί να δημιουργήσει τις κατηγορίες των εν δυνάμει εισιτηρίων και στην συνέχεια είτε άμεσα να τα μεταφέρει στους αγοραστές είτε να τα μεταφέρει στις πιθανές εταιρείες πώλησης των εισιτηρίων για την πώληση τους. Η διαδρομή που θα ακολουθηθεί επαφίεται στον εκάστοτε διοργανωτή. Στην συνέχεια και αφού τα εισιτήρια εκδοθούν θα μπορούν να μεταπωληθούν, να μεταφερθούν, να “καούν” και να επικυρωθούν. Οι πρώτες τρείς διαδικασίες μπορούν να εκτελεστούν μόνο από τον εκάστοτε ιδιοκτήτη ενώ η τέταρτη πρέπει να συμβεί κοινή συναινέσει από τον εκάστοτε ιδιοκτήτη και έναν από τους ορισμένους αρμόδιους τής κάθε εκδήλωσης (που έχει θέσει ο διοργανωτής της). Μια πιθανή ροή της πληροφορίας στην εφαρμογή μας φαίνεται στην Εικόνα 11, αν και άλλες πιθανές ροές μπορούν να λάβουν μέρος.
Εικόνα 11 Μία πιθανή ροή της υλοποίησης
29
Υλοποίηση 30
5.2 Smart Contract
Σε αυτήν την ενότητα θα αναλύσουμε την υλοποίηση και την λογική της κάθε μεθόδου του smart contract. Για την υλοποίηση ακολουθήσαμε την σχεδιαστική αρχή κατά την οποία τα δεδομένα που αποθηκεύονται στο Blockchain είναι τα ελάχιστα δεδομένα που χρειάζονται να επαληθευτούν μέσα από αυτό με έναν τρόπο διαφανή και αδιάβλητο κατά τον οποίο δεν χρειάζεται να υπάρχει εμπιστοσύνη (trustlessly). Οποιαδήποτε επιπλέον δεδομένα χρειάζονται αποθηκεύονται και επεξεργάζονται εκτός του Blockchain. H υλοποίηση έγινε με γνώμονα ότι κάθε μέθοδος μπορεί να χρησιμοποιηθεί μόνο από τον εκάστοτε αρμόδιο μέσω ενός μηχανισμού ελέγχου της ψηφιακής υπογραφής, όπως είδαμε και στο κεφάλαιο 2.
Κατά την “εμψύχωση” (instantiation) ενός πίνακα στα smart contract δύο παράμετροι απαιτούνται. Η πρώτη παράμετρος ονομάζεται “code” και προσδιορίζει τον ιδιοκτήτη του πίνακα, ο οποίος είναι και αυτός που θα χρεωθεί για το κόστος της RAM εκτός αν προσδιορίζεται άλλος λογαριασμός. Μόνο αυτός ο λογαριασμός contract μπορεί να αλλάξει ή να διαγράψει τα δεδομένα σε αυτόν τον πίνακα εκτός αν πληρώνει άλλος λογαριασμός για την RAM. Η δεύτερη παράμετρος είναι το “scope”, το οποίο βεβαιώνει την μοναδικότητα του πίνακα μέσα στο smart contract.
5.2.1 Setconfig action
Η μέθοδος αυτή χρησιμοποιείται για να ορίσει την έκδοση (version) στην οποία βρίσκεται το smart contract, αφού, όπως αναφέραμε, η ανανέωση ενός smart contract μετά το deploy είναι εφικτή στο Eos, καθώς επίσης, και έναν δείκτη, ο οποίος χαρτογραφεί όλες τις κατηγορίες εισιτηρίων όλων των εκδηλώσεων που έχουν δημιουργηθεί σε αυτό από την έναρξη λειτουργίας του. Η διαδικασία αυτή γίνεται χρησιμοποιώντας έναν singleton22 πίνακα, ο οποίος έχει τη μορφή που φαίνεται στον Πίνακας 1.
Πίνακας 1 tokenconfigs πίνακας Name Type Comments standard name23 Always set to diploma version string For versioning event_ticket_id uint64_t Starts from 0
5.2.2 Create action
Η συνάρτηση αυτή καλείται από τον διοργανωτή μιας εκδήλωσης με σκοπό να καταχωρήσει στο Blockchain μια κατηγορία εισιτηρίων – που έχει τη μορφή ενός non-fungible νομίσματος - με συγκεκριμένες ιδιότητες (πίνακας ticketsstats με scope το όνομα της εκδήλωσης, δηλαδή κάθε εκδήλωση (event) έχει τις δικές τους κατηγορίες εισιτηρίων). Την πρώτη φορά που καλείται η create μέθοδος για μία εκδήλωση το όνομα της αποθηκεύεται σε έναν πίνακα
22 Το singleton μοτίβο (pattern) είναι ένα μοτίβο σχεδιασμού λογισμικού το οποίο περιορίζει την “εμψύχωση” μιας κλάσης να έχει μόνο μια περίπτωση (instance). Στην δική μας περίπτωση περιορίζει τον πίνακα να έχει μόνο μία γραμμή. Αυτό είναι χρήσιμο όταν ακριβώς ένα αντικείμενο χρειάζεται για τον συντονισμό των λειτουργιών σε όλο το σύστημα. 23 Είναι και αυτό τύπου uint64_t, ουσιαστικά είναι μια μέθοδος μετατροπείς ενός string σε uint64_t.
Υλοποίηση 31 events μαζί με τον δημιουργό της και έκτοτε μόνο αυτός μπορεί να δημιουργήσει κατηγορίες εισιτηρίων για αυτήν την εκδήλωση. Οι ιδιότητες που μπορεί να ορίσει ο διοργανωτής κάθε φορά που δημιουργεί μια νέα κατηγορία εισιτηρίων καθώς και οι μεταβλητές που βρίσκονται στον πίνακα με τον οποίο αλληλεπιδρά αυτή η μέθοδος είναι:
• event_ticket_id: είναι ο δείκτης που αναφέραμε στο προηγούμενο υποκεφάλαιο και χαρτογραφεί όλες τις κατηγορίες εισιτηρίων όλων των εκδηλώσεων που έχουν δημιουργηθεί σε αυτό από την έναρξη λειτουργίας του smart contract. Η τιμή αυτή διαβάζεται κάθε φορά από τον πίνακα tokenconfigs που αναφέραμε προηγουμένως. • burnable: ορίζει το αν δίνεται η δυνατότητα στον ιδιοκτήτη ενός εισιτηρίου να το διαγράψει/ “κάψει”, δηλαδή να το αφαιρέσει από τη RAM, μειώνοντας έτσι τον αριθμό των υπό κυκλοφορία εισιτήριων (current_supply). • sellable: ορίζει το αν δίνεται η δυνατότητα στον ιδιοκτήτη ενός εισιτηρίου να καταχωρήσει μια παραγγελία πώλησης. • transferable: ορίζει το αν δίνεται η δυνατότητα στον ιδιοκτήτη ενός εισιτηρίου να το μεταφέρει σε κάποιον τρίτο. • issuer: δείχνει το λογαριασμό που δημιούργησε τα εισιτήρια • ticket_name: δείχνει το όνομα μιας κατηγορίας εισιτηρίων • price: ορίζει την τιμή μιας κατηγορίας εισιτηρίων και πρέπει να οριστεί σε Eos νομίσματα. • max_deviation: ορίζει την απόκλιση που μπορεί να έχει στην τιμή η μεταπώληση ενός εισιτηρίου, βάζοντας έτσι πάνω και κάτω όριο σε αυτήν. • max_supply: δείχνει τον μέγιστο αριθμό εισιτηρίων που μπορούν να εκδοθούν σε αυτήν την κατηγορία εισιτηρίων. • current_supply: δείχνει τα εισιτήρια που είναι αυτή τη στιγμή σε κυκλοφορία (τα οποία προκύπτουν από τα εισιτήρια που έχουν γίνει issue (issued_supply) μείον τα εισιτήρια που έχουν καεί). Κατά τη διάρκεια της create μεθόδου η τιμή αυτή θέτεται ίση με το 0. • issued_supply: δείχνει τα εισιτήρια που έχουν γίνει issue. Κατά τη διάρκεια της create μεθόδου η τιμή αυτή θέτεται ίση με το 0. • sale_split: δείχνει το ποσοστό του κέρδους που θα πάρει ο διοργανωτής/issuer από τις μεταπωλήσεις των εισιτηρίων • base_uri: στο πεδίο αυτό μπορεί να προστεθεί ένα url που να περιέχει όλα τα metadata που χρειάζονται να γνωρίζουμε για αυτήν την εκδήλωση, όπως το πότε θα γίνει, το πού θα γίνει, την ώρα που θα ξεκινήσει και θα τελειώσει, τους καλλιτέχνες που θα συμμετέχουν κ.α. • validators: στο πεδίο αυτό μπορούν να προστεθούν όλοι οι λογαριασμοί που θα είναι υπεύθυνοι για την επικύρωση των εισιτηρίων.
Οι τιμές των _supply μεταβλητών εκφράζονται σε CTT μιας και οι μεταβλητές αυτές είναι τύπου asset. Η δομή περιέχει το ποσό (amount), που εκφράζεται σε uint64_t και το σύμβολο (symbol), το οποίο είναι μία δομή που περιέχει το σύμβολο (symbol_code) - που μπορεί να αρχικοποιηθεί χρησιμοποιώντας μια μεταβλητή τύπου string που μεταφράζεται σε uint64_t και αποθηκεύεται, ή απευθείας χρησιμοποιείται μια μεταβλητή τύπου uint64_t - και την ακρίβεια η οποία είναι τύπου uint8_t και ορίζει το πόσα μηδενικά θα πρέπει να έχει μετά την υποδιαστολή η μεταβλητή amount της δομής asset. Στην περίπτωση μας η τιμή είναι μηδέν, δηλαδή παίρνει μόνο ακέραιες τιμές. Στον Πίνακας 2 φαίνονται οι μεταβλητές και οι τύποι τους του πίνακα ticketsstats που αναλύσαμε προηγουμένως.
Υλοποίηση 32
Πίνακας 2 ticketsstats πίνακας Name Type event_ticket_id uint64_t burnable bool sellable bool transferable bool issuer name ticket_name name price asset max_deviation double max_supply asset current_supply asset issued_supply asset sale_split double base_uri string validators vector
5.2.3 Issue action
Η συνάρτηση αυτή καλείται για να αναθέσει ο διοργανωτής τα εισιτήρια που θέλει στον κάθε πωλητή και μετά αυτός να τα βάλει προς πώληση ή να τα αναθέσει κατευθείαν στον θεατή/αγοραστή αν επιλέξει να τα πουλήσει μέσα από έναν κανονικό μηχανισμό πληρωμών. Όποιον τρόπο και να επιλέξει η διαδικασία είναι η ίδια· ο διοργανωτής καλεί την μέθοδο θέτοντας τον παραλήπτη, το όνομα της εκδήλωσης στην κατηγορία των εισιτηρίων που θέλει να αναθέσει, την ποσότητα των εισιτηρίων, ένα url που θα περιέχει κάποια metadata για τα εισιτήρια αυτά - η παράμετρος αυτή είναι προαιρετική - και ένα μήνυμα άμα θέλει. Κατά τη διαδικασία ανάθεσης το εισιτήριο δημιουργείται στον πίνακα tickets (με scope τον λογαριασμό του contract που θα γίνει deploy) του οποίου η μορφή φαίνεται στον Πίνακας 3 και ο λογαριασμός του παραλήπτη πιστώνεται τα εισιτήρια.
Πίνακας 3 tickets πίνακας Name Type Comments id uint64_t αναγνωριστικό το οποίο προκύπτει από όλα τα εισιτήρια serial_number uint64_t αναγνωριστικό το οποίο προκύπτει από τα εισιτήρια της κατηγορίας του event name όνομα της εκδήλωσης owner name όνομα του ιδιοκτήτη ticket_name name όνομα της κατηγορίας εισιτηρίων valid bool δείχνει την εγκυρότητα του εισιτηρίου, δηλαδή αν έχει χτυπηθεί ή όχι relative_uri std::optional
5.2.4 Burn action
Η μέθοδος αυτή μπορεί, εφόσον το έχει ενεργοποιήσει ο διοργανωτής, να καλεστεί από έναν ιδιοκτήτη εισιτηρίου-ων για να διαγράψει το εισιτήριο-α του από τη RAM (να σταματήσει να πληρώνει για αυτήν). Η διαδικασία περιλαμβάνει εκτός από την διαγραφή του-ων εισιτηρίου-ων από τον πίνακα tickets και την αφαίρεση του από τον λογαριασμό του.
Υλοποίηση 33
5.2.6 Transfer action
Η μέθοδος αυτή καλείται από τον ιδιοκτήτη εισιτηρίου-ων, εφόσον του επιτρέπεται από τον διοργανωτή, για να εκτελέσει μία μεταφορά εισιτηρίου-ων προς κάποιον άλλο λογαριασμό.
5.2.5 Listsale action
Η μέθοδος αυτή καλείται από έναν ιδιοκτήτη εισιτηρίου-ων, εφόσον του επιτρέπεται από τον διοργανωτή, για να κάνει μια παραγγελία πώλησης ενός ή περισσοτέρων εισιτηρίων. Η μέθοδος αυτή καλείται με παραμέτρους, οι οποίες είναι ο πωλητής, το όνομα της εκδήλωσης, το όνομα της κατηγορίας του εισιτηρίου-ων και η τιμή πώλησης τους. Κατά την εκτέλεση αυτής της μεθόδου τα εισιτήρια που πρόκειται να πουληθούν καταχωρούνται σε έναν πίνακα που ονομάζεται lockedtick, ο οποίος έχει scope το λογαριασμό που έχει γίνει deploy το smart contract και περιέχει τα id των εισιτηρίων μόνο. Με αυτόν τον τρόπο τα εισιτήρια προς πώληση θεωρούνται κλειδωμένα. Επίσης μια καταχώρηση στον πίνακα asks (scope το λογαριασμό που έχει γίνει deploy το smart contract) εισάγεται. Η δομή του πίνακα αυτού φαίνεται στον Πίνακας 4.
Πίνακας 4 asks πίνακας Name Type Comments batch_id uint64_t ανγνωριστικό της παραγγελίας, εξαρτάται από το πρώτο id του διανύσματος ticket_ids ticket_ids vector
5.2.7 Closesale action
Η μέθοδος αυτή μπορεί να καλεστεί από τον ιδιοκτήτη μιας παραγγελίας ή από οποιονδήποτε για να διαγραφεί μια καταχώρηση παραγγελίας από τον πίνακα asks είτε γιατί ο ιδιοκτήτης άλλαξε γνώμη είτε γιατί θέλουμε να απελευθερωθεί η μνήμη RAM που την αποθηκεύει. Η δεύτερη περίπτωση είναι δυνατόν να συμβεί μόνο όταν η παραγγελία έχει λήξη.
5.2.8 Buy action
Η μέθοδος αυτή καλείται κάθε φορά που γίνεται μια μεταφορά μέσω της συνάρτησης transfer του eosio.token προς τον λογαριασμό του smart contract. Όταν κάποιος θέλει να αγοράσει μια καταχώρηση πώλησης η διαδικασία που πρέπει να ακολουθήσει είναι να στείλει την αξία του κόστους της καταχώρησης πώλησης στον λογαριασμό του smart contract και να βάλει στο μήνυμα το αναγνωριστικό της καταχώρησης πώλησης και το όνομα του
Υλοποίηση 34
λογαριασμού του πωλητή με ένα κόμμα ενδιάμεσα. Όταν εκτελεστεί η παραπάνω διαδικασία με τις σωστές και επιθυμητές παραμέτρους η μέθοδος θα μεταβιβάσει το-α εισιτήριο-α στον αγοραστή και οι ανταμοιβές θα δοθούν (στον πωλητή και ίσως στον διοργανωτή) με σεβασμό στους κανόνες που έχει επιβάλλει ο διοργανωτής της εκδήλωσης. Κατά τη μεταβίβαση ιδιοκτησίας ενός ή περισσοτέρων εισιτηρίων ο πίνακας accounts επεξεργάζεται ανάλογα. Η μορφή του πίνακα, ο οποίος έχει scope τον εκάστοτε λογαριασμό φαίνεται στον Πίνακας 5.
Πίνακας 5 accounts πίνακας Name Type Comments event_ticket_id uint64_t Αναγνωριστικό event name όνομα της εκδήλωσης ticket_name name όνομα κατηγορίας εισιτηρίων amount asset Ποσότητα κατοχής
5.2.9 Invalidate action
Η συνάρτηση αυτή καλείται από τους αρμόδιους που έχουν οριστεί από τον εκάστοτε διοργανωτή για την επικύρωση των εισιτηρίων της συγκεκριμένης εκδήλωσης. Ουσιαστικά αυτό που κάνει είναι να ελέγχει την εγκυρότητα του εισιτηρίου και αν αυτή υφίσταται, την άρει επιτρέποντας την είσοδο στον κάτοχο του.
5.3 Εφαρμογή
Στην ενότητα αυτή θα περιγράψουμε την εφαρμογή που υλοποιήθηκε στα πλαίσια της διπλωματικής. Τα actions των smart contracts εκτελούνται μόνο με την μορφή μιας συναλλαγής που έγινε από κάποιο λογαριασμό, με τον τρόπο που εξηγήθηκε και στο Κεφάλαιο 2. Θέλοντας λοιπόν, να παρέχουμε στο χρήστη μια αυτοματοποιημένη διαδικασία επικοινωνίας αποστολής και λήψης δεδομένων με το επίπεδο του smart contract -που αναλύσαμε ανωτέρω- δημιουργήσαμε μια φιλική και εύχρηστη διεπαφή, η οποία αφαιρεί την οποιαδήποτε τριβή με το Blockchain. Ο χρήστης μπορεί να συνδεθεί στην εφαρμογή και να εκτελέσει οποιαδήποτε συναλλαγή έχοντας απλά ένα πορτοφόλι σε έναν από τους υποστηριζόμενους παρόχους που αναφέραμε στην ενότητα 3.1.3.
5.3.1 Javascript Scripts
Οι συναρτήσεις που υλοποιήθηκαν για την επικοινωνία με Blockchain είναι :
1. createTick: λαμβάνει ως είσοδο από το χρήστη τις πληροφορίες και τις ιδιότητες που θέλει να έχει η κατηγορία εισιτηρίων που θα δημιουργήσει και δημιουργεί μια συναλλαγή στο Blockchain, η οποία καλεί το create action. 2. getEvents: διαβάζει τις εκδηλώσεις που είναι καταχωρημένες στο πίνακα events του smart contract. 3. getTicketsCat: διαβάζει τα δεδομένα μιας κατηγορίας εισιτηρίων που εισήχθηκαν από την συνάρτηση createTick. 4. getTicketSales: διαβάζει όλες τις παραγγελίες πωλήσεων μιας εκδήλωσης.
Υλοποίηση 35
5. buyListSale: δημιουργεί μια συναλλαγή η οποία καλεί το action transfer του eosio.token για την μεταφορά του ποσού του κόστους του εισιτηρίου-ων που θέλει κάποιος χρήστης να αγοράσει από τις διαθέσιμες παραγγελίες πώλησης προς το λογαριασμό που έχει γίνει deploy το smart contract. 6. issueFunc: καλείται για να μεταφερθούν/εκδοθούν ένα ή περισσότερα εισιτήρια σε έναν αγοραστή μετά από μια επιτυχημένη μεταφορά του ποσού κόστους του εισιτηρίου-ων από τον αγοραστή προς το λογαριασμό του contract. 7. getTickets: διαβάζει όλα τα εισιτήρια που κατέχει ένας χρήστης σε κάθε εκδήλωση. 8. pushListSale: δημιουργεί μία συναλλαγή στην οποία καλείται το action listsale του smart contract μας για την καταχώρηση μιας παραγγελίας πώλησης. 9. closeListSale: δημιουργεί μια συναλλαγή στην οποία καλείται το action closesale του smart contract μας για την διαγραφή μιας παραγγελίας πώλησης. 10. scan: καλείται για να ακυρώσει ένα εισιτήριο και για να ελέγξει την εγκυρότητα του από τους αρμόδιους φορείς ( validators). 5.3.2 Create Event διεπαφή
Η οθόνη αυτή φαίνεται στην Εικόνα 12 και είναι αυτή που θα επισκεφθεί ένας διοργανωτής για να δημιουργήσει τις κατηγορίες εισιτηρίων για μια εκδήλωση στο Blockchain καθώς επίσης και για να εισάγει πληροφορίες σχετικές με την εκδήλωση και αποθηκεύονται σε μια βάση δεδομένων MongoDB. Η πληροφορίες που αποθηκεύονται στην MongoDB χρησιμοποιούνται για την καλύτερη παρουσίαση της εκάστοτε εκδήλωσης προς τους χρήστες. Στη διεπαφή αυτή χρησιμοποιείται η πρώτη συνάρτηση της ενότητας 5.3.1.
Εικόνα 12 Create Event διεπαφή
5.3.3 Discover διεπαφή
Η οθόνη αυτή φαίνεται στην Εικόνα 13. Ο χρήστης την επισκέπτεται για να αναζητήσει τις εκδηλώσεις που είναι καταχωρημένες στο Blockchain, ώστε να αγοράσει εισιτήρια. Στην διεπαφή αυτή γίνεται χρήση της δεύτερης συνάρτησης της ενότητας 5.3.1.
Υλοποίηση 36
Εικόνα 13 Discover διεπαφή
5.3.4 Buy Tickets διεπαφή
Μέσω αυτής της διεπαφής ο χρήστης είναι σε θέση να αγοράσει εισιτήριο-α για μια εκδήλωση είτε απευθείας από τον διοργανωτή είτε από παραγγελίες πώλησης άλλων χρηστών (με σεβασμό πάντα στους κανόνες που έχει θέσει ο διοργανωτής). Για την παρουσίαση της πληροφορίας (όπως τιμή, όνομα κατηγορίας εισιτηρίων κτλ.) και την λειτουργικότητα της χρησιμοποιούνται οι συναρτήσεις τέσσερα έως έξι της ενότητας 5.3.1. Η οθόνη αυτή φαίνεται στην Εικόνα 14.
Εικόνα 14 Buy Tickets οθόνη
Υλοποίηση 37
5.3.4 My Tickets διεπαφή
Ο χρήστης μεταβαίνει σε αυτήν την οθόνη για να ελέγξει σε ποιές εκδηλώσεις έχει αγορασμένα εισιτήρια και την ποσότητα τους. Η διεπαφή αυτή χρησιμοποιεί την έβδομη συνάρτηση της ενότητας 5.3.1 και φαίνεται στην Εικόνα 15.
Εικόνα 15 My Tickets οθόνη 5.3.5 View Tickets διεπαφή
Ο χρήστης μεταβαίνει στην οθόνη αυτή για να δει τα barcode των διαθέσιμων εισιτηρίων του και να τα προβάλλει για την ακύρωση τους. Το κάθε barcode περιέχει πληροφορίες, όπως το αναγνωριστικό, το όνομα της εκδήλωσης, το όνομα του ιδιοκτήτη, την κατηγορία του εισιτηρίου και το δημόσιο κλειδί και μια υπογραφή (του αναγνωριστικού του εισιτηρίου και το χρόνο ), ώστε να αποφύγουμε τις “selfie επιθέσεις”. Χρησιμοποιείται και εδώ η έβδομη συνάρτηση της ενότητας 5.3.1 και ένα στιγμιότυπο της φαίνεται στην Εικόνα 16.
Εικόνα 16 View Tickets οθόνη
Υλοποίηση 38
5.3.6 Sell Tickets οθόνη
Ο χρήστης μεταβαίνει στην οθόνη αυτή με σκοπό είτε να κάνει μια παραγγελία πώλησης των εισιτηρίων που κατέχει είτε να ακυρώσει μια τέτοια παραγγελία. Η οθόνη αυτή χρησιμοποιεί την όγδοη και την ένατη συνάρτηση της ενότητας 5.4.1 και φαίνεται στην Εικόνα 17.
Εικόνα 17 Sell Tickets οθόνη
5.3.7 Scan Tickets οθόνη
Οι άνθρωποι που βρίσκονται στις εισόδους για την επικύρωση των εισιτηρίων θα χρησιμοποιήσουν αυτή την οθόνη για την επικύρωση των εισιτηρίων. Η οθόνη αυτή χρησιμοποιεί τη δέκατη συνάρτηση της ενότητας 5.4.1 και φαίνεται στην Εικόνα 18.
Εικόνα 18 Scan Tickets οθόνη
6 Αξιολόγηση
Στο προηγούμενο Κεφάλαιο περιγράψαμε ένα σύστημα το οποίο περιέχει ένα smart contract με διάφορες λειτουργικότητες και ένα γραφικό περιβάλλον διασυνδεδεμένο με αυτό. Μέσω του συστήματος αυτού, οι συμμετέχοντες μπορούν να συμμετέχουν σε ένα ή σε περισσότερα στάδια της ζωής ενός εισιτηρίου. Στο παρόν Κεφάλαιο θα γίνει η αξιολόγηση της απόδοσης της υλοποίησης του συστήματος και η παρουσίαση των αποτελεσμάτων λαμβάνοντας υπόψιν τα ευρήματα του Κεφαλαίου 4.
6.1 Ασφάλεια
Στο επίπεδο της ασφάλειας, έχοντας μελετήσει και κατανοήσει την βιβλιογραφία και τις επιθέσεις που έχουν γίνει στο παρελθόν στο επίπεδο των smart contract, υλοποιήσαμε το σύστημα μας ώστε καμία από τις γνωστές επιθέσεις να μην αναπαραχθεί. Στη δική μας υλοποίηση του smart contract προέκυψε η ανάγκη να χρησιμοποιηθούν οι παρακάτω βέλτιστες τεχνικές που αναπτύχθηκαν στο Κεφάλαιο 4:
• Numerical Overflow • Authorization Check • Transfer Error Prompt • Apply Check
Η προσέγγιση μας στην υλοποίηση του smart contact έγινε με το σκεπτικό να έχει πρόσβαση στο κάθε action του smart contract μόνο ο αρμόδιος, ακολουθώντας την αρχή των ελάχιστων δικαιωμάτων.
Πριν γίνει deploy στο κεντρικό δίκτυο (mainnet) ένα smart contract είναι σύνηθες να περνάει από έλεγχο ασφαλείας (security audit) από αρμόδιες για αυτό το σκοπό εταιρείες, έτσι ώστε να μειωθεί όσο το δυνατόν περισσότερο η οποιαδήποτε πιθανότητα για κάποιο ελάττωμα που θα επιφέρει κάποια πιθανή κλοπή νομισμάτων ή μη αναμενόμενη λειτουργικότητα.
6.2 Συλλογική Αξιολόγηση
Η τελική εφαρμογή ελέγχθηκε μέσω προσομοίωσης η οποία διενεργήθηκε σε έναν Ubuntu 18.04 LTS εικονικό διακομιστή (server) μέσω του Amazon Elastic Compute 2. Η εικονική μηχανή έχει μία εικονική μονάδα επεξεργασίας Intel Xeon με χρονισμό που φτάνει μέχρι και τα 3.3 GHz, μνήμη Ram 1 GB και 8 GB Amazon EBS24 SSD γενικού σκοπού. Επίσης, η βάση δεδομένων έτρεχε σε ένα ίδιο διακομιστή μέσω της υπηρεσίας MongoDB Atlas. Να σημειώσουμε εδώ ότι χρησιμοποιήθηκε ο Nginx διακομιστής μεσολάβησης (proxy server) για
24 Elastic Block Storage
39
Αξιολόγηση 40
την ανακατεύθυνση όλων των αιτημάτων από τους χρήστες στον εικονικό διακομιστή για λόγους τόσο ασφαλείας όσο και απόδοσης.
Ο έλεγχος του smart contract έγινε αρχικά σε ένα τοπικό δίκτυο (local testnet) με έναν κόμβο και στην συνέχεια μετά από τους κατάλληλους ελέγχους σε ένα δημόσιο τεστ δίκτυο (Jungle testnet) κάτω από το diplomaauths λογαριασμό. Δεν έγινε “ανέβασμα” του smart contract στο κεντρικό δίκτυο λόγω του απαιτούμενου κόστους, αλλά εφόσον το “ανέβασμα” στο τεστ δίκτυο ήταν επιτυχημένο περιμένουμε να συμβεί το ίδιο και στο κεντρικό δίκτυο.
Αναλύσαμε στην προσομοίωση αυτή το αναμενόμενο κόστος σε Cpu, Net, και Ram που χρειάζεται τόσο για το “ανέβασμα” της εφαρμογής όσο και για την εκτέλεση κάθε action του smart contract (Τα παρακάτω αποτελέσματα προήλθαν σε συνθήκες που το δίκτυο ήταν σε μια “κανονική” κατάσταση25, τα αποτελέσματα αυτά διαφοροποιούνται ανάλογα με την κατάσταση του συστήματος κάθε φορά). Για το ανέβασμα χρειάστηκαν 769059 bytes Ram και τα αποτελέσματα για το κάθε action φαίνονται στον Πίνακας 6.
Πίνακας 6 Cpu, Net cost of actions
Name Net (bytes) Cpu (us) Ram (byte) setconfig 96 369 244 create 184 273 200-60026 issue 136 307 28227 listsale 152 319 877 closesale 112 249 -877 burn 112 221 -28228 transfer-buy 144 950 0 transfer (ticket) 128 305 0 invalidate 128 204 1
Μια έκδοση του συστήματος που υλοποιήσαμε στην διπλωματική αυτή βρίσκεται σε παραγωγή σε συνεργασία με την εταιρεία ComeTogether ΙΚΕ και εξυπηρετεί κανονικά πελάτες. Μετά από ένα μήνα ζωής μπορούμε να πούμε ότι παραμένει στιβαρή και πλήρως λειτουργική. Μπορεί κανείς να την επισκεφτεί και να αλληλεπιδράσει μαζί της στο διαδίκτυο στην τοποθεσία https://app.cometogether.network.
25 Μπορεί κανείς να δει όλα τα actions που εκτελέστηκαν από το smart contract μας εδώ: https://jungle.bloks.io/account/diplomaauths 26 Εξαρτάται από τις πληροφορίες που εισάγονται και αν η εκδήλωση υπάρχει ήδη ή δημιουργείται για πρώτη φορά 27 Για ένα εισιτήριο 28 Για ένα εισιτήριο
7 Συμπεράσματα & Μελλοντικές Προεκτάσεις
7.1 Συμπεράσματα
Σε αυτήν τη διπλωματική εργασία εξηγήσαμε τα βασικά χαρακτηριστικά που διέπουν την τεχνολογία του Blockchain και στη συνέχεια εκμεταλλευτήκαμε την τεχνολογία αυτή για να δημιουργήσουμε μια λύση στα προβλήματα που μαστίζουν την βιομηχανία των εκδηλώσεων και συγκεκριμένα της πώλησης των εισιτηρίων. Όπως αποδείχθηκε είναι εφικτό να αφομοιωθεί ένα τέτοιο σύστημα στις ήδη υπάρχουσες δομές της αγοράς χωρίς την ανάγκη εισαγωγής κάποιου εμποδίου στην ροή εκτέλεσης των διαδικασιών.
Το Blockchain μπορεί να λειτουργεί ως ένα κεντρικό σύστημα στο οποίο γίνεται η εξακρίβωση της εγκυρότητας και της αυθεντικότητας ενός εισιτηρίου καθώς και της αυθεντικότητας του ιδιοκτήτη του και όλες οι υπόλοιπες πληροφορίες να αποθηκεύονται σε μια κεντροποιημένη βάση δεδομένων όπως γινόταν μέχρι σήμερα. Με αυτό τον τρόπο η μέχρι τώρα πολύπλοκη και διαιρεμένη βιομηχανία των εισιτηρίων θα δρα με προδιαγεγραμμένες κατευθυντήριες γραμμές αφαιρώντας έτσι την όποια διαφθορά υπήρχε καθιστώντας την δίκαιη προς όλους τους εμπλεκόμενους.
Λόγω νεότητας βέβαια η τεχνολογία του Blockchain έρχεται με κάποια μειονεκτήματα ένα από αυτά είναι ο αριθμός εκτέλεσης συναλλαγών σε μια δεδομένη μονάδα χρόνου, που είναι αρκετά μικρός μέχρι και σήμερα. Το γεγονός αυτό οφείλεται κυρίως στους αλγορίθμους συναίνεσής οι οποίοι είναι αρκετά απαιτητικοί και χρονοβόροι. Βήματα για την βελτίωση της απόδοσης γίνονται τόσο στο επίπεδο του δικτύου όσο και στο επίπεδο των smart contract.
7.2 Μελλοντικές Προεκτάσεις
Στο σύνολο, όλοι οι στόχοι της διπλωματικής έχουν επιτευχθεί, ωστόσο θα μπορούσαν να γίνουν κάποιες βελτιώσεις στο επίπεδο του γραφικού περιβάλλοντος και στο τρόπο παρουσίασης της πληροφορίας.
Επίσης θα μπορούσαν να γίνουν προσθήκες στο επίπεδο του smart contract. Θα μπορούσαμε να συμπεριλάβουμε εξωτερικές εξαρτήσεις και πιο σύνθετες λογικές. Για παράδειγμα αν μία εκδήλωση ακυρωθεί να αποζημιώνονταν απευθείας οι αγοραστές σύμφωνα με την αξία του εισιτηρίου.
Τα smart contract θα μας οδηγήσουν σε μια εποχή που όλες οι επικυρώσεις θα γίνονται αυτόματα. Δεν θα χρειάζεται να υπάρχει ο ελεγκτής στην είσοδο μιας εκδήλωσης για τον έλεγχο των εισιτηρίων. Το πορτοφόλι θα διαβάζει αυτόματα την τοποθεσία του ιδιοκτήτη ενός εισιτηρίου και θα του επιτρέπει την είσοδο.
41
Συμπεράσματα & Μελλοντικές Προεκτάσεις 42
Τέλος, θα μπορούσαμε να δημιουργήσουμε ένα δικό μας νόμισμα με επιπλέον λειτουργικότητα και με σκοπό την σταθερότητα στην τιμή του. Έτσι οι συμμετέχοντες σε ένα τέτοιο σύστημα δεν θα φοβόντουσαν κάποια πιθανή υποτίμηση του.
Αναφορές
[1] Aventus Protocol Foundation, Ιουλίου 2018. [Ηλεκτρονικό]. Available: https://aventus.io/doc/whitepaper.pdf. [Πρόσβαση 20 Σεπτεμβρίου 2019].
[2] Waterson, «Independent Review of Consumer Protection Measures concerning Online Secondary Ticketing Facilities,» Μαΐου 2016. [Ηλεκτρονικό]. Available: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attac hment_data/file/525885/ind-16-7-independent-review-online-secondary-ticketing- facilities.pdf. [Πρόσβαση 20 Σεπτεμβρίου 2019].
[3] The Economist , «How big stars maximise their take from tours,» 27 Ιουλίου 2019. [Ηλεκτρονικό]. Available: https://www.economist.com/finance-and- economics/2019/07/27/how-big-stars-maximise-their-take-from-tours. [Πρόσβαση Σεπτεμβρίου 20 2019].
[4] M. Leonhardt, «About 12 percent of people buying concert tickets get scammed,» CNBC, 14 Σεπτεμβρίου 2018. [Ηλεκτρονικό]. Available: https://www.cnbc.com/2018/09/13/about-12-percent-of-people-buying-concert- ticketsget-scammed-.html. [Πρόσβαση 20 Σεπτεμβρίου 2019].
[5] E. Roberts, «Threat Research: How Bots Affect Ticketing,» Distil Research Lab, 2019.
[6] T. Marks, «Why Ticket Prices Are Going Through the Roof,» 30 Ιουνίου 2016. [Ηλεκτρονικό]. Available: https://www.consumerreports.org/money/why-ticket- prices-are-going-through-the-roof/. [Πρόσβαση 21 Σεπτεμβρίου 2019].
[7] R. Davis, «THE TICKET SCALPING ARMS RACE: PERCEPTION AND REALITY OF TICKET RESALE, SCALPING AND,» Μαΐου 2014. [Ηλεκτρονικό]. Available: https://www.academia.edu/9831849/THE_TICKET_SCALPING_ARMS_RACE_PERCEPT ION_AND_REALITY_OF_TICKET_RESALE_SCALPING_AND_ONSELLING_IN_LIVE_MUSI C. [Πρόσβαση 21 Σεπτεμβρίου 2019].
[8] MW17, «Τicket scalping technology and the effects on the arts and cultural markets,» 30 Ιανουαρίου 2017. [Ηλεκτρονικό]. Available: https://mw17.mwconf.org/paper/ticket-scalping-technology-and-effects-on-the-arts- and-cultural-markets/. [Πρόσβαση 21 Σεπτεμβρίου 2019].
[9] Europe Economics Chancery House, «Analysis of the Secondary Sales Market for Tickets for Sporting, Cultural and other Events,» 14 Σεπτεμβρίου 2009. [Ηλεκτρονικό]. Available: www.europe- economics.com/publications/secondary_sales_market.pdf. [Πρόσβαση 22 Σεπτεμβρίου 2019].
43
Αναφορές 44
[10] Resident Advisor, «RA introduces ticket resale service,» Αυγούστου 2014. [Ηλεκτρονικό]. Available: https://www.residentadvisor.net/news/25747. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[11] Twickets, «How it works,» [Ηλεκτρονικό]. Available: https://www.twickets.live/how- it-works. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[12] Dice.fm, [Ηλεκτρονικό]. Available: https://dice.fm/. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[13] Songkick, [Ηλεκτρονικό]. Available: https://www.songkick.com/. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[14] ASA and CAP News, «Clamping down on misleading pricing practices by secondary ticketing providers,» 7 Μαΐου 2018. [Ηλεκτρονικό]. Available: https://www.asa.org.uk/news/clamping-down-on-secondary-ticketing- providers.html. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[15] Steph Harmon-The Guardian, «Viagogo: ACCC launches legal action against 'misleading' ticket reseller,» 28 Αυγούστου 2017. [Ηλεκτρονικό]. Available: https://www.theguardian.com/money/2017/aug/28/viagogo-accc-legal-action- misleading-ticket-reseller. [Πρόσβαση 28 Σεπτεμβρίου 2019].
[16] consumer. now you know, [Ηλεκτρονικό]. Available: https://www.consumer.org.nz/articles/consumer-nz-investigating-ticket-resellers. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[17] Belfast Telegraph, «Secondary ticketing site referred to Trading Standards over misleading pricing,» 30 Μαΐου 2018. [Ηλεκτρονικό]. Available: https://www.belfasttelegraph.co.uk/news/uk/secondary-ticketingsite-referred-to- trading-standards-over-misleading-pricing-36961520.html. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[18] Oisin Lunny - Forbes, «Battle For $15.19 Billion Secondary Ticket Market Heats Up With First Europe-Wide Anti Touting Law,» 24 Ιουνίου 2019. [Ηλεκτρονικό]. Available: https://www.forbes.com/sites/oisinlunny/2019/06/24/the-battle-for-15- 19b-secondary-ticket-market-heats-up-with-first-europe-wide-anti-touting- law/#61571b2a2e02. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[19] The Ticketing Business, «EU bans bots in landmark ruling,» 17 Απριλίου 2019. [Ηλεκτρονικό]. Available: https://www.theticketingbusiness.com/2019/04/17/eu- bans-bots-landmark-ruling/. [Πρόσβαση 23 Σεπτεμβρίου 2019].
[20] S. C. Highfield, «How Modern Trends and Market Economics Have Rendered Anti- Ticket Scalping Legislation Obsolete,» Φθινόπωρο 2010. [Ηλεκτρονικό]. Available: https://via.library.depaul.edu/cgi/viewcontent.cgi?referer=https%3A%2F%2Fwww.go ogle.com%2F&httpsredir=1&article=1183&context=law- review&fbclid=IwAR0ET_Sqti-
Αναφορές 45
UQ6JOdBsQ_ucGtEUdY2cCNJjhLjHoSQOC6bCGzOyfSDyxBTE. [Πρόσβαση 24 Σεπτεμβρίου 2019].
[21] The New York Times, «Congress Moves to Curb Ticket Scalping, Banning Bots Used Online,» 8 Δεκεμβρίου 2016. [Ηλεκτρονικό]. Available: https://www.nytimes.com/2016/12/08/business/media/ticket-scalping-bots- act.html. [Πρόσβαση 24 Σεπτεμβρίου 2019].
[22] D. Kopf, «Taylor Swift is smart enough to not let her shows sell out,» 18 Οκτωμβρίου 2018. [Ηλεκτρονικό]. Available: https://qz.com/quartzy/1427597/taylor-swift-is- smart-enough-to-not-let-her-shows-not-sell-out/. [Πρόσβαση 25 Σεπτεμβρίου 2019].
[23] C. Jordan, «Bruce Springsteen on Broadway UPDATE: The Ticketmaster factor,» 30 Αυγούστου 2017. [Ηλεκτρονικό]. Available: https://eu.app.com/story/entertainment/music/2017/08/28/bruce-springsteen- broadway-ticketmaster-factor/608139001/. [Πρόσβαση 25 Σεπτεμβρίου 2019].
[24] T. Ingham, «Team Adele wages war on ticket touts – and so far it’s working,» 2 Δεκεμβρίου 2015. [Ηλεκτρονικό]. Available: https://www.musicbusinessworldwide.com/team-adele-wage-war-on-ticket-touts- and-so-far-its-working/. [Πρόσβαση 25 Σεπτεμβρίου 2019].
[25] C. McMillan, «Secondary ticketing: the problem and possible solutions, explained,» 15 Νοεμβρίου 2016. [Ηλεκτρονικό]. Available: https://www.theguardian.com/money/2018/jun/22/tout-rout-stars-come-out-to- closedown-ticket-resellers 2018. [Πρόσβαση 25 Σεπτεμβρίου 2019].
[26] S. Nakamoto, «Bitcoin: A Peer-to-Peer Electronic Cash System,» 2009. [Ηλεκτρονικό]. Available: https://bitcoin.org/bitcoin.pdf. [Πρόσβαση 26 Σεπτεμβρίου 2019].
[27] Wikipedia, «Blockchain,» [Ηλεκτρονικό]. Available: https://en.wikipedia.org/wiki/Blockchain. [Πρόσβαση 27 Σεπτεμβρίου 2019].
[28] Lisk, «Blockchain Transparency Explained,» [Ηλεκτρονικό]. Available: https://lisk.io/academy/blockchain-basics/benefits-of-blockchain/blockchain- transparency-explained. [Πρόσβαση 27 Σεπτεμβρίου 2019].
[29] Dragonchain, «What Different Types of Blockchains are There?,» 18 Απριλίου 2019. [Ηλεκτρονικό]. Available: https://dragonchain.com/blog/differences-between-public- private-blockchains. [Πρόσβαση 27 Σεπτεμβρίου 2019].
[30] Bitcoin, [Ηλεκτρονικό]. Available: https://bitcoin.org/en/.
[31] Ethereum, [Ηλεκτρονικό]. Available: https://www.ethereum.org/.
[32] Eos, [Ηλεκτρονικό]. Available: https://eos.io/.
[33] J.P.Morgan, «A permissioned implementation of Ethereum supporting data privacy,» Σεπτεμβρίου 2018. [Ηλεκτρονικό]. Available:
Αναφορές 46
https://drive.google.com/file/d/0B42vMkapQi1MSEVaa2tuVEtXZXM/view. [Πρόσβαση 27 Σεπτεμβρίου 2019].
[34] Hyperledger, [Ηλεκτρονικό]. Available: https://www.hyperledger.org/.
[35] R3, [Ηλεκτρονικό]. Available: https://www.r3.com/.
[36] Dragonchain, [Ηλεκτρονικό]. Available: https://dragonchain.com/.
[37] Vitalik Buterin, «On Public and Private Blockchains,» 6 Αυγούστου 2015. [Ηλεκτρονικό]. Available: https://blog.ethereum.org/2015/08/07/on-public-and- private-blockchains/. [Πρόσβαση 27 Σεπτεμβρίου 2019].
[38] T. S. P. Rogaway, «Cryptographic Hash-Function Basics: Definitions, Implications, and Separations for Preimage Resistance, Second-Preimage Resistance, and Collision Resistance,» 16 Ιουλίου 2009. [Ηλεκτρονικό]. Available: https://eprint.iacr.org/2004/035.pdf. [Πρόσβαση 27 Σεπτεμβρίου 2019].
[39] C. Schätz, «Learn how to code elliptic curve cryptography,» 8 Φεβρουαρίου 2019. [Ηλεκτρονικό]. Available: https://blog.goodaudience.com/learn-how-to-code-elliptic- curve-cryptography-26ecc0940d1f. [Πρόσβαση 27 Σεπτεμβρίου 2019].
[40] A. S. a. L. A. R.L. Rivest, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems,» [Ηλεκτρονικό]. Available: https://people.csail.mit.edu/rivest/Rsapaper.pdf.
[41] 0xcert, «Fungible vs non-fungible tokens on the blockchain,» 26 Απριλίου 2018. [Ηλεκτρονικό]. Available: https://medium.com/0xcert/fungible-vs-non-fungible- tokens-on-the-blockchain-ab4b12e0181a. [Πρόσβαση 28 Σεπτεμβρίου 2019].
[42] Eos, «Big Picture,» [Ηλεκτρονικό]. Available: https://developers.eos.io/eosio- home/docs. [Πρόσβαση 28 Σεπτεμβρίου 2019].
[43] Eos, «Accounts and Permissions,» [Ηλεκτρονικό]. Available: https://developers.eos.io/eosio-nodeos/docs/accounts-and-permissions. [Πρόσβαση 28 Σεπτεμβρίου 2019].
[44] Eos, «EOS.IO Technical White Paper v2,» 16 Μαρτίου 2018. [Ηλεκτρονικό]. Available: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#tr ansaction-as-proof-of-stake-tapos. [Πρόσβαση 28 Σεπτεμβρίου 2019].
[45] Dan Larimer, «EOS.IO Transaction Structure,» 2017. [Ηλεκτρονικό]. Available: https://steemit.com/eos/@dan/eos-developer-s-log-stardate-201707-9. [Πρόσβαση 28 Σεπτεμβρίου 2019].
[46] Eos, «Communication Model,» [Ηλεκτρονικό]. Available: https://developers.eos.io/eosio-nodeos/docs/communication-model. [Πρόσβαση 29 Σεπτεμβρίου 2019].
Αναφορές 47
[47] Eos, «Introduction,» [Ηλεκτρονικό]. Available: https://developers.eos.io/eosio- cpp/docs/introduction. [Πρόσβαση 28 Σεπτεμβρίου 2019].
[48] WebAssemply, [Ηλεκτρονικό]. Available: https://webassembly.org/.
[49] Eos, «Development Environment,» [Ηλεκτρονικό]. Available: https://developers.eos.io/eosio-nodeos/docs/setup-nodeos-for-development. [Πρόσβαση 1 Οκτωμβρίου 2019].
[50] EOSIO, «EOSIO - The Most Powerful Infrastructure for Decentralized Applications,» [Ηλεκτρονικό]. Available: https://github.com/EOSIO/eos. [Πρόσβαση 1 Οκτωμβρίου 2019].
[51] EOSIO/LLVM, [Ηλεκτρονικό]. Available: https://github.com/eosio/llvm. [Πρόσβαση 1 Οκτωμβρίου 2019].
[52] EOSIO, [Ηλεκτρονικό]. Available: https://github.com/EOSIO/eosio.cdt. [Πρόσβαση 1 Οκτωμβρίου 2019].
[53] Eos, «Universal Authenticator Library (UAL Core for short),» [Ηλεκτρονικό]. Available: https://github.com/EOSIO/universal-authenticator-library. [Πρόσβαση 1 Οκτωμβρίου 2019].
[54] Eos, «RPC API,» [Ηλεκτρονικό]. Available: https://developers.eos.io/eosio- nodeos/reference#get_account-1.
[55] Eos, «Eosjs,» [Ηλεκτρονικό]. Available: https://github.com/EOSIO/eosjs.
[56] React, [Ηλεκτρονικό]. Available: https://reactjs.org/.
[57] PeckShield, «EOS “Transaction Congestion Attack”: Attackers Could Paralyze EOS Network with Minimal Cost,» 16 Ιανουαρίου 2019. [Ηλεκτρονικό]. Available: https://medium.com/@peckshield/eos-transaction-congestion-attack-attackers- could-paralyze-eos-network-with-minimal-cost-9adfb4d16c82. [Πρόσβαση 2 Σεπτέμβριος 2019].
[58] «EOS congestion 9/13/2019 and EOSPlay hack,» 15 Σεπτεμβρίου 2019. [Ηλεκτρονικό]. Available: https://medium.com/@dexaran820/eos-congestion-9-13- 2019-and-eosplay-hack-cbafcba2d1dc. [Πρόσβαση 2 Οκτωμβρίου 2019].
[59] GoodBlock, «Addressing the EOSIO REX Exploit,» 17 Σεπτεμβρίου 2019. [Ηλεκτρονικό]. Available: https://medium.com/goodblock-io/addressing-the-eosio- rex-exploit-c73dfdf77811. [Πρόσβαση 2 Οκτωμβρίου 2019].
[60] SlowMist, «EOS Smart Contract Development Security Best Practices,» [Ηλεκτρονικό]. Available: https://github.com/slowmist/eos-smart-contract-security-best- practices/blob/master/README_EN.md. [Πρόσβαση 3 Οκτωμβρίου 2019].
[61] «EOS DApp total loss money by hacked,» [Ηλεκτρονικό]. Available: https://hacked.slowmist.io/en/?c=EOS%20DApp.
Αναφορές 48
[62] Blockgeeks, «Ultimate Guide to EOS Smart Contract Security,» Νοέμβριου 2018. [Ηλεκτρονικό]. Available: https://blockgeeks.com/guides/eos-smart-contract- security/. [Πρόσβαση 3 Οκτωμβρίου 2019].
[63] EOSBetCasino, «EOSBet Transfer Hack Statement,» 2018. [Ηλεκτρονικό]. Available: https://www.reddit.com/r/eos/comments/9fxyd4/eosbet_transfer_hack_statement/ . [Πρόσβαση 2 Οκτωμβρίου 2019].
[64] Quoc Le, «How hackers attack EOS contracts and ways to prevent it,» 30 Νοέμβριος 2018. [Ηλεκτρονικό]. Available: https://medium.com/leclevietnam/hacking-in-eos- contracts-and-how-to-prevent-it-b8663c8bffa6. [Πρόσβαση 3 Οκτώμβριος 2019].
[65] Eos, «Randomization in Contracts,» [Ηλεκτρονικό]. Available: https://developers.eos.io/eosio-cpp/v1.3.2/docs/random-number-generation. [Πρόσβαση 3 Οκτωμβρίου 2019].
[66] Blockgenic, «EOS Accounts: How They Work and How To Get One,» 13 Ιουλίου 2018. [Ηλεκτρονικό]. Available: https://medium.com/@blockgenic/eos-accounts-how-they- work-and-how-to-get-one-87019c0f7bc7. [Πρόσβαση 28 Σεπτεμβρίου 2019].