Αρχιτεκτονική Αποκεντρωμένων Εφαρμογών: Back End, Security and Design Patterns

Οι αποκεντρωμένες εφαρμογές, ή ÐApps, απαιτούν ειδικό σχεδιασμό συστήματος για υψηλή ασφάλεια και αξιοπιστία. Σε αυτό το άρθρο θα καλύψω αρκετές βασικές αρχές για το πώς να σχεδιάζω και να εφαρμόζω σωστά back-end και έξυπνες συμβάσεις για αποκεντρωμένες εφαρμογές, λαμβάνοντας το Ethereum ως πρωταρχικό παράδειγμα, αν και μεγάλο μέρος του θα ισχύει για EOS, Tron και άλλες αποκεντρωμένες πλατφόρμες δεδομένων.

Στιγμιότυπα άρθρου :

  • Πώς να αποθηκεύσετε ιδιωτικά κλειδιά στο πίσω μέρος χωρίς προβλήματα ασφαλείας
  • Πώς να σχεδιάσετε σωστά τις έξυπνες συμβάσεις και τι να "αποκεντρώσετε"
  • Παραδείγματα αρχιτεκτονικής αποκεντρωμένων και ημι-κεντρικών εφαρμογών
  • Πώς να χειριστείτε πράγματα χαμηλού επιπέδου όπως φόρτωση δικτύου και αστοχίες

Θα είναι μεγάλο, ας το κάνουμε!

Αποκεντρωμένα προγράμματα και Blockchain

Παρά το γεγονός ότι το blockchain αντιμετωπίζει πολλές δυσκολίες υιοθέτησης και ρύθμισης σήμερα, είναι ένα είδος τεχνολογίας που είναι εδώ για να μείνει, είτε πρόκειται για blockchain, hashgraph, tempo ή οποιαδήποτε άλλη τεχνολογία κατανεμημένου καθολικού που θα έρθει, ανεξάρτητα από τον αλγόριθμο.

Η κύρια αξία που φέρνουν το blockchain και άλλες παρόμοιες τεχνολογίες μπορούν να γενικευτούν ως εξής: επιτρέπουν στους χρήστες να γράφουν και να εκτελούν προγράμματα τα οποία, στην πράξη, δεν μπορούν να αλλάξουν μετά τη δημιουργία ούτε να παραβιαστούν κατά την εκτέλεση. Με άλλα λόγια, αυτά τα προγράμματα λειτουργούν πάντα όπως έχουν σχεδιαστεί και κανένα μέρος δεν μπορεί να επηρεάσει τη συμπεριφορά τους.

Αυτός ο ορισμός ισχύει για πολλά κρυπτονομίσματα που υπάρχουν σήμερα, αν τα θεωρήσουμε ως προγράμματα που καθορίζουν τον τρόπο μεταφοράς νομισμάτων. Αυτό εξηγεί επίσης γιατί τα κρυπτονομίσματα και πολλά είδη διακριτικών έχουν πραγματική αξία: δεν μπορούν να δημιουργηθούν από τον αέρα, από τα καθορισμένα «υποκείμενα προγράμματα» τους.

Οι πλατφόρμες Ethereum / EOS / Tron /…, σε αντίθεση με το Bitcoin, εφαρμόζουν ένα πιο σύνθετο επίπεδο προγράμματος, το οποίο με τη σειρά του εφαρμόζει το περιβάλλον εκτέλεσης που επιτρέπει σε οποιονδήποτε να γράψει τα δικά του αποκεντρωμένα προγράμματα στην κορυφή της πλατφόρμας. Αυτά τα προγράμματα που καθορίζονται από τον χρήστη εκτελούνται πάντα όπως έχουν σχεδιαστεί, χωρίς εξαιρέσεις και η ασφάλειά τους είναι εγγυημένη από την πλατφόρμα.

Αποκεντρωμένες Εφαρμογές

Αυτά τα ασφαλή και αμετάβλητα προγράμματα που εκτελούνται σε αποκεντρωμένο δίκτυο σε συνδυασμό με παραδοσιακές τεχνολογίες front-end και back-end είναι αυτό που ονομάζουμε αποκεντρωμένες εφαρμογές (ÐApps) σήμερα. Μέσω ορισμένων από αυτά μπορούν να είναι ημι-συγκεντρωτικά, ένα μεγάλο μέρος των δραστηριοτήτων στην πραγματικά αποκεντρωμένη εφαρμογή θα πρέπει να πραγματοποιηθεί υπό τον έλεγχο ενός κεντρικού κόμματος.

Για να φανταστείτε αυτό που ονομάζουμε αποκεντρωμένες εφαρμογές σήμερα, πάρτε οποιονδήποτε υπάρχον κεντρικό πόρο ιστού όπως _YouTube_ ή _Instagram_ ως παράδειγμα και φανταστείτε ότι αντί για έναν κεντρικό λογαριασμό που προστατεύεται με κωδικό πρόσβασης έχετε τη « ταυτότητα κρυπτογράφησης » συνδεδεμένη με τον πόρο ιστού / κινητής τηλεφωνίας.

Αυτό σας παρέχει το Λογισμικό Πορτοφολιού. Το ιδιωτικό κλειδί από αυτήν την ταυτότητα (ένα μυστικό, με το οποίο, μπορείτε να ενεργήσετε εκ μέρους αυτής της ταυτότητας) είναι αποθηκευμένο στην τοπική σας συσκευή και δεν πηγαίνει ποτέ στο διαδίκτυο, καθιστώντας κανέναν σε θέση να ελέγξει αυτήν την ταυτότητα εκτός από εσάς. Με αυτή την ταυτότητα, μπορείτε να εκτελέσετε διάφορες ενέργειες τόσο σε κεντρικό επίπεδο (διαδικτυακή πηγή που ελέγχεται από μια κεντρική αρχή) και αποκεντρωμένη (το οποίο είναι ένα διαφορετικό δίκτυο από την παραδοσιακή www, ο στόχος του οποίου είναι να εξαλείψει η κεντρική αρχή) δίκτυα , χρησιμοποιώντας την ιστοσελίδα ως σημείο πρόσβασης ή / και ως γραφικό περιβάλλον χρήστη. Ολόκληρο το σημείο αυτής της «ταυτότητας κρυπτογράφησης» είναι ότι οι ενέργειές σας είναι κρυπτογραφικά ασφαλείς και κανείς δεν μπορεί να αλλάξει αυτό που έχετε υπογράψει ούτε την υπογραφή σας.

Σήμερα, οι υπολογιστικές δυνατότητες και οι δυνατότητες αποθήκευσης των ανθεκτικών σε σφάλματα αποκεντρωμένων δικτύων όπως το Ethereum, το EOS ή το Tron είναι περιορισμένες. Εάν ήταν επεκτάσιμα, θα μπορούσαμε να χρησιμοποιήσουμε αποκεντρωμένα δίκτυα για να αποθηκεύσουμε ολόκληρη την αποκεντρωμένη εφαρμογή, συμπεριλαμβανομένης της γραφικής διεπαφής χρήστη, δεδομένων και επιχειρηματικής λογικής. Σε αυτήν την περίπτωση, θα ονομάζαμε αυτές τις εφαρμογές πραγματικά αποκεντρωμένες / διανεμημένες.

Ωστόσο, επειδή αυτά τα δίκτυα δεν είναι επεκτάσιμα σήμερα, συνδυάζουμε διαφορετικές προσεγγίσεις για να επιτύχουμε το μέγιστο επίπεδο αποκέντρωσης για τις εφαρμογές μας. Το «παραδοσιακό» πίσω μέρος, όπως γνωρίζουμε, δεν πηγαίνει πουθενά. Για παράδειγμα:

  • Χρησιμοποιούμε το back end για να φιλοξενήσουμε το front end για μια αποκεντρωμένη εφαρμογή.
  • Χρησιμοποιούμε back end για ενοποιήσεις με άλλες υπάρχουσες τεχνολογίες και υπηρεσίες. Οι πραγματικές εφαρμογές παγκόσμιας κλάσης δεν μπορούν να ζήσουν σε ένα απομονωμένο περιβάλλον.
  • Χρησιμοποιούμε το back end για την αποθήκευση και την επεξεργασία οτιδήποτε είναι αρκετά μεγάλο για ένα αποκεντρωμένο δίκτυο (συγκεκριμένα το blockchain). Πρακτικά, ολόκληρη η εφαρμογή και η επιχειρηματική της λογική αποθηκεύονται κάπου στον κόσμο, εξαιρουμένου μόνο του τμήματος blockchain. Για να μην αναφέρουμε, το IPFS και παρόμοια επίπεδα αποθήκευσης δεν μπορούν να εγγυηθούν την προσβασιμότητα των αρχείων, επομένως δεν μπορούμε να βασιστούμε σε αυτά χωρίς να φιλοξενήσουμε ούτε τα αρχεία. Με άλλα λόγια, υπάρχει πάντα ανάγκη για έναν αποκλειστικό διακομιστή που τρέχει.

Δεν υπάρχει τρόπος δημιουργίας μιας ασφαλούς και μερικώς αποκεντρωμένης εφαρμογής χωρίς τη χρήση ενός σταθερού back end από σήμερα και το βασικό σημείο αυτού του άρθρου είναι να εξηγήσουμε πώς να το κάνουμε αυτό σωστά.

(De) συγκεντρωτισμός και διακριτικά

Συμβαίνει ότι σχεδόν όλες οι αποκεντρωμένες εφαρμογές σήμερα κατασκευάζονται γύρω από τα λεγόμενα tokens - προσαρμοσμένα (ή απλά κλωνοποιημένα) κρυπτονομίσματα που οδηγούν σε μια συγκεκριμένη αποκεντρωμένη εφαρμογή. Τα κουπόνια είναι απλά ένα προγραμματιζόμενο νόμισμα ή στοιχεία, αυτό είναι.

Συνήθως, ένα διακριτικό είναι ένα «έξυπνο συμβόλαιο» (ένα προσαρμοσμένο πρόγραμμα) γραμμένο πάνω από την αποκεντρωμένη πλατφόρμα όπως το Ethereum. Με την κατοχή ορισμένων διακριτικών, μπορείτε ουσιαστικά να αποκτήσετε διαφορετικές υπηρεσίες σε έναν πόρο ιστού ή μια εφαρμογή για κινητά και να ανταλλάξετε αυτό το διακριτικό για κάτι άλλο. Το βασικό σημείο εδώ είναι ότι το διακριτικό ζει από μόνο του και δεν ελέγχεται από μια κεντρική αρχή.

Υπάρχουν πολλά παραδείγματα εφαρμογών που δημιουργούνται γύρω από μάρκες: από πολλά συλλεκτικά παιχνίδια όπως CryptoKitties (διακριτικά ERC721) έως περισσότερες εφαρμογές προσανατολισμένες στις υπηρεσίες, όπως το δίκτυο LOOM, ή ακόμα και προγράμματα περιήγησης όπως Brave και πλατφόρμες παιχνιδιών όπως το DreamTeam (μάρκες συμβατές με ERC20).

Οι ίδιοι οι προγραμματιστές καθορίζουν και αποφασίζουν πόσο έλεγχο θα έχουν (ή δεν θα έχουν) στις εφαρμογές τους. Μπορούν να δημιουργήσουν ολόκληρη την επιχειρηματική λογική της εφαρμογής πάνω από έξυπνα συμβόλαια (όπως έκανε η CryptoKitties) ή, δεν μπορούν να κάνουν καθόλου χρήση έξυπνων συμβάσεων, συγκεντρώνοντας τα πάντα στους διακομιστές τους. Ωστόσο, η καλύτερη προσέγγιση είναι κάπου στη μέση.

Back End για αποκεντρωμένα δίκτυα

Από τεχνική άποψη, πρέπει να υπάρχει μια γέφυρα που συνδέει μάρκες και άλλα έξυπνα συμβόλαια με την εφαρμογή Ιστού / κινητής τηλεφωνίας.

Στις σημερινές πλήρως αποκεντρωμένες εφαρμογές, όπου οι πελάτες αλληλεπιδρούν απευθείας με έξυπνα συμβόλαια, αυτή η γέφυρα περιορίζεται σε δυνατότητες JSON RPC API δημόσιων API ή ομαδικών κόμβων όπως το Infura, τα οποία με τη σειρά τους αναγκάζονται να υπάρχουν εξαιτίας του γεγονότος ότι δεν μπορεί να γίνει κάθε συσκευή εκτελέστε και υποστηρίξτε τον μεμονωμένο κόμβο δικτύου του. Ωστόσο, αυτό το API παρέχει ένα μόνο βασικό και πολύ στενό σύνολο λειτουργιών, οι οποίες μόλις επιτρέπουν την πραγματοποίηση απλών ερωτημάτων ούτε την αποτελεσματική συγκέντρωση δεδομένων. Εξαιτίας αυτού, τελικά, το προσαρμοσμένο back end ξεκινά, καθιστώντας την εφαρμογή ημι-κεντρική.

Η όλη αλληλεπίδραση με το αποκεντρωμένο δίκτυο μπορεί να μειωθεί σε μόλις ένα ή δύο σημεία, ανάλογα με τις ανάγκες της εφαρμογής:

  1. Ακούγοντας τα συμβάντα δικτύου (όπως μεταφορές διακριτικών)/ ανάγνωση της κατάστασης δικτύου .
  2. Δημοσίευση συναλλαγών (επίκληση λειτουργιών έξυπνων συμβολαίων που αλλάζουν κατάσταση, όπως μεταφορά διακριτικών)

Η εφαρμογή και των δύο αυτών σημείων είναι αρκετά δύσκολη, ειδικά αν θέλουμε να οικοδομήσουμε μια ασφαλή και αξιόπιστη λύση back-end. Εδώ είναι τα κύρια σημεία που θα αναλύσουμε παρακάτω:

  • Πρώτα απ 'όλα, στο Ethereum, η ανάκτηση συμβάντων δεν είναι έτοιμη για παραγωγή. Λόγω πολλών λόγων: οι κόμβοι δικτύου μπορούν να αποτύχουν κατά τη λήψη μεγάλου αριθμού συμβάντων, τα συμβάντα μπορεί να εξαφανιστούν ή να αλλάξουν λόγω δικράνων κλπ. Πρέπει να δημιουργήσουμε ένα επίπεδο αφαίρεσης για να συγχρονίσουμε συμβάντα από το δίκτυο και να εγγυηθούμε την αξιόπιστη παράδοσή τους.
  • Το ίδιο για τη δημοσίευση συναλλαγών, πρέπει να αφαιρέσουμε τα πράγματα χαμηλού επιπέδου της Ethereum όπως οι μετρητές nonce και οι εκτιμήσεις φυσικού αερίου, καθώς και η αναδημοσίευση συναλλαγών, παρέχοντας μια αξιόπιστη και σταθερή διεπαφή. Επιπλέον, η δημοσίευση συναλλαγών συνεπάγεται τη χρήση ιδιωτικών κλειδιών, η οποία απαιτεί προηγμένη ασφάλεια back-end.
  • Ασφάλεια. Θα το πάρουμε στα σοβαρά και θα αντιμετωπίσουμε ότι είναι αδύνατο να εγγυηθούμε ότι τα ιδιωτικά κλειδιά δεν θα τεθούν ποτέ σε κίνδυνο. Ευτυχώς, υπάρχει μια προσέγγιση για το σχεδιασμό μιας αποκεντρωμένης εφαρμογής, χωρίς καν την ανάγκη για back-end λογαριασμούς σε μεγάλο βαθμό ασφάλειας.

Στην πρακτική μας, όλα αυτά μας έκαναν να δημιουργήσουμε μια ισχυρή λύση για το Ethereum που ονομάζουμε Ethereum Gateway . Αφαιρεί άλλες μικρο-υπηρεσίες από τη διασκέδαση του Ethereum και παρέχει ένα αξιόπιστο API για να συνεργαστεί με αυτό.

Ως μια ταχέως αναπτυσσόμενη εκκίνηση, δεν μπορούμε να αποκαλύψουμε την πλήρη λύση (ακόμα) για προφανείς λόγους, αλλά θα μοιραστώ όλα όσα πρέπει να γνωρίζετε για να κάνετε την αποκεντρωμένη εφαρμογή σας άψογη. Ωστόσο, εάν έχετε συγκεκριμένες ερωτήσεις ή απορίες, μη διστάσετε να επικοινωνήσετε μαζί μου. Τα σχόλια σε αυτό το άρθρο εκτιμούνται επίσης πολύ!

Αρχιτεκτονική Αποκεντρωμένων Εφαρμογών

Αυτό το μέρος του άρθρου εξαρτάται σε μεγάλο βαθμό από τις ανάγκες μιας συγκεκριμένης αποκεντρωμένης εφαρμογής, αλλά θα προσπαθήσουμε να διευθετήσουμε ορισμένα βασικά μοτίβα αλληλεπίδρασης πάνω από τα οποία έχουν κατασκευαστεί αυτές οι εφαρμογές (ÐPlatform = Αποκεντρωμένη Πλατφόρμα = Ethereum / EOS / Tron / Οτιδήποτε):

Πελάτης lat ÐPlatform : πλήρως αποκεντρωμένες εφαρμογές .

Ο πελάτης (πρόγραμμα περιήγησης ή εφαρμογή για κινητά) μιλά απευθείας στην αποκεντρωμένη πλατφόρμα με τη βοήθεια του λογισμικού Ethereum "wallet" όπως το Metamask, το Trust ή τα πορτοφόλια υλικού όπως το Trezor ή το Ledger. Παραδείγματα δημιουργίας DApps με τέτοιο τρόπο είναι τα CryptoKitties, Loom's Delegated Call, τα ίδια τα πορτοφόλια κρυπτογράφησης (Metamask, Trust, Tron Wallet, άλλα), αποκεντρωμένες ανταλλαγές κρυπτογράφησης όπως η Etherdelta και ούτω καθεξής.

ÐPlatformΠελάτηςBack EndÐPlatform : κεντρικές ή ημι-συγκεντρωτικές εφαρμογές .

Η αλληλεπίδραση πελάτη με την αποκεντρωμένη πλατφόρμα και τον διακομιστή έχει ελάχιστα κοινά. Το καλό παράδειγμα αυτού είναι οποιαδήποτε ( κεντρική ) ανταλλαγή κρυπτογράφησης σήμερα, όπως το BitFinex ή το Poloniex: τα νομίσματα που ανταλλάσσετε σε ανταλλαγές καταγράφονται απλώς στην παραδοσιακή βάση δεδομένων. Μπορείτε να "συμπληρώσετε" το υπόλοιπο της βάσης δεδομένων στέλνοντας στοιχεία σε μια συγκεκριμένη διεύθυνση (ÐPlatform ⬌ Client) και στη συνέχεια να αποσύρετε στοιχεία μετά από ορισμένες ενέργειες στην εφαρμογή (Back End ⬌ ÐPlatform), ωστόσο, ό, τι κάνετε σε σχέση με ένα "Ð App" ο ίδιος (πελάτης ⬌ Back End) δεν συνεπάγεται την άμεση αλληλεπίδρασή σας με το ÐPlatform.

Ένα άλλο παράδειγμα είναι το Etherscan.io, το οποίο χρησιμοποιεί ημι-συγκεντρωτική προσέγγιση: μπορείτε να κάνετε όλες τις χρήσιμες αποκεντρωμένες ενέργειες εκεί, αλλά η ίδια η εφαρμογή δεν έχει νόημα χωρίς το ολοκληρωμένο back end τους (το Ethercan συγχρονίζει συνεχώς τις συναλλαγές, αναλύει τα δεδομένα και τα αποθηκεύει, τελικά παρέχοντας ένα ολοκληρωμένο API / UI).

Κάτι στο μεταξύ: ακίνητες, κεντρικές ή ημι-συγκεντρωτικές εφαρμογές .

Οι παραπάνω προσεγγίσεις συνδυάζονται. Για παράδειγμα, μπορούμε να έχουμε μια εφαρμογή που παρέχει διάφορες υπηρεσίες με αντάλλαγμα την κρυπτογράφηση, επιτρέποντάς σας να συνδεθείτε και να υπογράψετε πληροφορίες με την ταυτότητά σας κρυπτογράφησης.

Ας ελπίσουμε ότι, το μοτίβο αλληλεπίδρασης των πλήρως αποκεντρωμένων εφαρμογών (Client Ð ÐPlatform) δεν δημιουργεί ερωτήματα. Βασιζόμενοι σε τέτοιες καταπληκτικές υπηρεσίες όπως το Infura ή το Trongrid, κάποιος μπορεί απλά να δημιουργήσει μια εφαρμογή που δεν απαιτεί καθόλου διακομιστή. Σχεδόν όλες οι βιβλιοθήκες από την πλευρά του πελάτη όπως το Ether.js για το Ethereum ή το Tron-Web για το Tron μπορούν να συνδεθούν σε αυτές τις δημόσιες υπηρεσίες και να επικοινωνήσουν με το δίκτυο. Ωστόσο, για πιο σύνθετα ερωτήματα και εργασίες, ίσως χρειαστεί να διαθέσετε τον δικό σας διακομιστή.

Τα υπόλοιπα μοτίβα αλληλεπίδρασης που περιλαμβάνουν back end κάνουν τα πράγματα πιο ενδιαφέροντα και περίπλοκα. Για να τα βάλουμε όλα αυτά σε μια εικόνα, ας φανταστούμε μια περίπτωση όπου το πίσω μέρος μας αντιδρά σε κάποιο συμβάν στο δίκτυο. Για παράδειγμα, ο χρήστης δημοσιεύει μια συναλλαγή αποζημίωσης που μας δίνει την άδεια να τις χρεώσουμε. Για να πραγματοποιήσουμε μια χρέωση, πρέπει να δημοσιεύσουμε τη συναλλαγή χρέωσης ως απάντηση στο συμβάν εκπομπής:

Από την οπίσθια όψη, τι συμβαίνει:

  1. Ακούμε ένα συγκεκριμένο συμβάν δικτύου με συνεχή δημοσκόπηση του δικτύου.
  2. Μόλις λάβουμε ένα συμβάν, εκτελούμε κάποια επιχειρηματική λογική και μετά αποφασίζουμε να δημοσιεύσουμε μια συναλλαγή ως απάντηση.
  3. Πριν από τη δημοσίευση της συναλλαγής, θέλουμε να διασφαλίσουμε ότι θα εξορύσσεται πιθανώς (στο Ethereum, η επιτυχής εκτίμηση αερίου συναλλαγών σημαίνει ότι δεν υπάρχουν σφάλματα έναντι της τρέχουσας κατάστασης δικτύου ). Ωστόσο, δεν μπορούμε να εγγυηθούμε ότι η συναλλαγή θα εξορύσσεται με επιτυχία .
  4. Χρησιμοποιώντας ένα ιδιωτικό κλειδί, υπογράφουμε και δημοσιεύουμε τη συναλλαγή. Στο Ethereum πρέπει επίσης να καθορίσουμε την τιμή και το όριο φυσικού αερίου της συναλλαγής.
  5. Μετά τη δημοσίευση της συναλλαγής, εξετάζουμε συνεχώς το δίκτυο για την κατάστασή του.
  6. Εάν χρειάζεται πολύς χρόνος και δεν μπορούμε να πάρουμε την κατάσταση της συναλλαγής, πρέπει να την δημοσιεύσουμε ξανά ή να ενεργοποιήσουμε ένα «σενάριο αποτυχίας». Οι συναλλαγές μπορεί να χαθούν για διάφορους λόγους: συμφόρηση δικτύου, πτώση συνομηλίκων, αύξηση φορτίου δικτύου κ.λπ. Στο Ethereum, μπορείτε επίσης να εξετάσετε το ενδεχόμενο να υπογράψετε ξανά μια συναλλαγή με διαφορετική (πραγματική) τιμή αερίου.
  7. Αφού τελικά εξορύξουμε τη συναλλαγή μας, μπορούμε να εκτελέσουμε περισσότερη επιχειρηματική λογική εάν χρειαστεί. Για παράδειγμα, μπορούμε να ειδοποιήσουμε άλλες υπηρεσίες back-end για το γεγονός ότι η συναλλαγή έχει ολοκληρωθεί. Επίσης, σκεφτείτε να περιμένετε μερικές επιβεβαιώσεις προτού λάβετε τελικές αποφάσεις σχετικά με τη συναλλαγή: το δίκτυο διανέμεται και ως εκ τούτου το αποτέλεσμα μπορεί να αλλάξει σε λίγα δευτερόλεπτα.

Όπως μπορείτε να δείτε, υπάρχουν πολλά! Ωστόσο, η εφαρμογή σας ενδέχεται να μην απαιτεί κάποια από αυτά τα βήματα, ανάλογα με το τι προσπαθείτε να επιτύχετε. Όμως, η οικοδόμηση ενός στιβαρού και σταθερού οπίσθιου άκρου απαιτεί να υπάρχει λύση για όλα τα προβλήματα που αναφέρονται παραπάνω. Ας το καταρρίψουμε.

Αποκεντρωμένες εφαρμογές Back End

Εδώ θέλω να επισημάνω ορισμένα από τα σημεία που προκύπτουν από τις περισσότερες ερωτήσεις, συγκεκριμένα:

  • Ακούγοντας συμβάντα δικτύου και ανάγνωση δεδομένων από το δίκτυο
  • Δημοσίευση συναλλαγών και πώς να το κάνετε με ασφάλεια

Ακούγοντας εκδηλώσεις δικτύου

Στο Ethereum, καθώς και σε άλλα αποκεντρωμένα δίκτυα, μια έννοια των συμβάντων έξυπνων συμβολαίων (ή των αρχείων καταγραφής συμβάντων ή απλώς των αρχείων καταγραφής) επιτρέπει στις εφαρμογές εκτός αλυσίδας να γνωρίζουν τι συμβαίνει στο blockchain. Αυτά τα συμβάντα μπορούν να δημιουργηθούν από προγραμματιστές έξυπνων συμβολαίων σε οποιοδήποτε σημείο του κώδικα έξυπνης σύμβασης.

Για παράδειγμα, στο γνωστό πρότυπο ERC20 token, κάθε μεταφορά token πρέπει να καταγράψει το συμβάν μεταφοράς, αφήνοντας έτσι τις εφαρμογές εκτός αλυσίδας να γνωρίζουν ότι υπήρξε μεταφορά διακριτικών. «Ακούγοντας» αυτά τα γεγονότα μπορούμε να κάνουμε οποιαδήποτε (εκ νέου) δράση. Για παράδειγμα, ορισμένα κινητά κρυπτογραφικά πορτοφόλια σάς στέλνουν μια ειδοποίηση push / email όταν μεταφέρονται μάρκες στη διεύθυνσή σας.

Στην πραγματικότητα, δεν υπάρχει αξιόπιστη λύση για την ακρόαση ακουστικών εκδηλώσεων δικτύου. Διαφορετικές βιβλιοθήκες σας επιτρέπουν να παρακολουθείτε / να ακούτε συμβάντα, ωστόσο, υπάρχουν πολλές περιπτώσεις όπου κάτι μπορεί να πάει στραβά, με αποτέλεσμα χαμένα ή μη επεξεργασμένα συμβάντα. Για να αποφύγουμε την απώλεια συμβάντων, πρέπει να δημιουργήσουμε ένα προσαρμοσμένο back end, το οποίο θα διατηρήσει τη διαδικασία συγχρονισμού συμβάντων.

Ανάλογα με τις ανάγκες σας, η εφαρμογή μπορεί να διαφέρει. Αλλά για να σας βάλουμε σε μια εικόνα εδώ είναι μία από τις επιλογές για το πώς μπορείτε να δημιουργήσετε αξιόπιστη παράδοση εκδηλώσεων Ethereum από την άποψη της αρχιτεκτονικής μικροϋπηρεσιών:

Αυτά τα στοιχεία λειτουργούν με τον ακόλουθο τρόπο:

  1. Η εκδήλωση συγχρονισμού back end service κάνει δημοσκοπήσεις συνεχώς στο δίκτυο, προσπαθώντας να ανακτήσει νέα συμβάντα. Μόλις υπάρχουν μερικά νέα συμβάντα διαθέσιμα, στέλνει αυτά τα συμβάντα στο λεωφορείο μηνυμάτων. Με την επιτυχή υποβολή συμβάντων στο λεωφορείο μηνυμάτων, όπως και για το blockchain, μπορούμε να αποθηκεύσουμε το μπλοκ του τελευταίου συμβάντος, προκειμένου να ζητήσουμε νέα συμβάντα από αυτό το μπλοκ την επόμενη φορά. Λάβετε υπόψη ότι η ανάκτηση πάρα πολλών συμβάντων ταυτόχρονα μπορεί να οδηγήσει σε αποτυχία πάντα των αιτημάτων, επομένως πρέπει να περιορίσετε τον αριθμό των συμβάντων / αποκλεισμών που ζητάτε από το δίκτυο.
  2. Το λεωφορείο μηνυμάτων (για παράδειγμα, Rabbit MQ) δρομολογεί το συμβάν σε κάθε ουρά που έχει ρυθμιστεί ξεχωριστά για κάθε υπηρεσία back end. Πριν από τη δημοσίευση εκδηλώσεων, η υπηρεσία συγχρονισμού παρασκηνίου καθορίζει το κλειδί δρομολόγησης (για παράδειγμα, μια έξυπνη διεύθυνση συμβολαίου + θέμα συμβάντος), ενώ οι καταναλωτές (άλλες υπηρεσίες υποστήριξης) δημιουργούν ουρές που έχουν εγγραφεί μόνο για συγκεκριμένα συμβάντα.

Ως αποτέλεσμα, κάθε υπηρεσία back-end λαμβάνει μόνο τα γεγονότα που χρειάζεται. Επιπλέον, το λεωφορείο μηνυμάτων εγγυάται την παράδοση όλων των εκδηλώσεων μόλις δημοσιευθούν σε αυτό.

Φυσικά, μπορείτε να χρησιμοποιήσετε κάτι άλλο αντί για το δίαυλο μηνυμάτων: Επιστροφές HTTP, πρίζες κ.λπ. Σε αυτήν την περίπτωση, θα πρέπει να μάθετε πώς να εγγυηθείτε μόνοι σας την παράδοση επιστροφής κλήσεων: διαχειριστείτε εκθετικές / προσαρμοσμένες επαναλήψεις επιστροφής κλήσης, εφαρμόστε προσαρμοσμένη παρακολούθηση σύντομα.

Δημοσίευση συναλλαγών

Υπάρχουν μερικά βήματα που πρέπει να κάνουμε για να δημοσιεύσουμε μια συναλλαγή στο αποκεντρωμένο δίκτυο:

  1. Προετοιμασία της συναλλαγής. Μαζί με τα δεδομένα συναλλαγών, αυτό το βήμα συνεπάγεται το αίτημα της κατάστασης του δικτύου προκειμένου να διαπιστωθεί εάν αυτή η συναλλαγή είναι έγκυρη και πρόκειται να εξορυχθεί (εκτίμηση αερίου στο Ethereum) και ο διαδοχικός αριθμός της συναλλαγής (nonce στο Ethereum). Ορισμένες από τις βιβλιοθήκες προσπαθούν να το κάνουν αυτό κάτω από την κουκούλα, ωστόσο, αυτά τα βήματα είναι σημαντικά.
  2. Υπογραφή της συναλλαγής. Αυτό το βήμα συνεπάγεται τη χρήση του ιδιωτικού κλειδιού. Πιθανότατα, εδώ θα θελήσετε να ενσωματώσετε την προσαρμοσμένη λύση συναρμολόγησης ιδιωτικού κλειδιού (για παράδειγμα).
  3. Δημοσίευση και αναδημοσίευση της συναλλαγής. Ένα από τα βασικά σημεία εδώ είναι ότι η δημοσιευμένη συναλλαγή σας έχει πάντα την ευκαιρία να χαθεί ή να πέσει από το αποκεντρωμένο δίκτυο. Για παράδειγμα, στο Ethereum, η δημοσιευμένη συναλλαγή μπορεί να μειωθεί εάν η τιμή φυσικού αερίου του δικτύου αυξηθεί ξαφνικά. Σε αυτήν την περίπτωση, πρέπει να αναδημοσιεύσετε τη συναλλαγή. Επιπλέον, ίσως θελήσετε να αναδημοσιεύσετε τη συναλλαγή με άλλες παραμέτρους (τουλάχιστον με υψηλότερη τιμή φυσικού αερίου) για να την εξορύξετε το συντομότερο δυνατό. Συνεπώς, η αναδημοσίευση της συναλλαγής μπορεί να σημαίνει εκ νέου υπογραφή της, εάν η συναλλαγή αντικατάστασης δεν είχε προ-υπογραφεί πριν (με διαφορετικές παραμέτρους)

Χρησιμοποιώντας τις παραπάνω προσεγγίσεις, μπορείτε να δημιουργήσετε κάτι παρόμοιο με αυτό που παρουσιάζεται στο παρακάτω διάγραμμα ακολουθίας. Σε αυτό το συγκεκριμένο διάγραμμα ακολουθίας, δείχνω (γενικά!) Πώς λειτουργεί η επαναλαμβανόμενη χρέωση blockchain (υπάρχουν περισσότερα σε ένα συνδεδεμένο άρθρο):

  1. Ο χρήστης εκτελεί μια λειτουργία σε ένα έξυπνο συμβόλαιο, το οποίο τελικά επιτρέπει στο back end να πραγματοποιήσει μια επιτυχημένη συναλλαγή χρέωσης.
  2. Μια υπηρεσία back-end που είναι υπεύθυνη για μια συγκεκριμένη εργασία ακούει το γεγονός της αποζημίωσης χρέωσης και δημοσιεύει μια συναλλαγή χρέωσης.
  3. Μετά την εξόρυξη της συναλλαγής χρέωσης, αυτή η υπηρεσία back end που είναι υπεύθυνη για μια συγκεκριμένη εργασία λαμβάνει ένα συμβάν από το δίκτυο Ethereum και εκτελεί κάποια λογική (συμπεριλαμβανομένου του καθορισμού της επόμενης ημερομηνίας χρέωσης).

Ασφάλεια και έξυπνες συμβάσεις

Η δημοσίευση συναλλαγών περιλαμβάνει πάντα τη χρήση ενός ιδιωτικού κλειδιού . Ίσως αναρωτιέστε εάν είναι δυνατόν να διατηρήσετε τα ιδιωτικά κλειδιά ασφαλή. Λοιπόν, ναι και όχι. Υπάρχουν πολλές πολύπλοκες στρατηγικές και διαφορετικοί τύποι λογισμικού που επιτρέπουν την ασφαλή αποθήκευση ιδιωτικών κλειδιών στο πίσω μέρος. Ορισμένες λύσεις αποθήκευσης ιδιωτικών κλειδιών χρησιμοποιούν γεω-κατανεμημένες βάσεις δεδομένων, ενώ άλλες προτείνουν ακόμη και τη χρήση ειδικού υλικού. Ωστόσο, σε κάθε περίπτωση, το πιο ευάλωτο σημείο μιας ημι-κεντρικής εφαρμογής είναι όπου το ιδιωτικό κλειδί συναρμολογείται και χρησιμοποιείται για την υπογραφή μιας συναλλαγής (ή, σε περίπτωση ειδικού υλικού, ένα σημείο ενεργοποίησης μιας διαδικασίας υπογραφής συναλλαγής). Ως εκ τούτου, θεωρητικά, δεν υπάρχει 100% αξιόπιστη λύση που θα επιτρέπει προστασία από αλεξίσφαιρα από τον κίνδυνο παραβίασης των αποθηκευμένων ιδιωτικών κλειδιών.

Τώρα σκεφτείτε έτσι. Σε πολλές περιπτώσεις, δεν χρειάζεται καν να ασφαλίζετε ιδιωτικά κλειδιά στο πίσω μέρος που συχνά. Αντ 'αυτού, μπορείτε να σχεδιάσετε έξυπνα συμβόλαια και ολόκληρη την εφαρμογή με τέτοιο τρόπο ώστε η διαρροή ιδιωτικού κλειδιού να μην επηρεάσει τη συνηθισμένη συμπεριφορά τους . Με αυτήν την προσέγγιση, δεν έχει σημασία πώς οι εξουσιοδοτημένοι λογαριασμοί αλληλεπιδρούν με το έξυπνο συμβόλαιο. Απλώς "ενεργοποιούν" ένα έξυπνο συμβόλαιο για να κάνουν τη συνήθη δουλειά τους και το ίδιο το έξυπνο συμβόλαιο εκτελεί οποιαδήποτε απαιτούμενη επικύρωση. Το ονομάζω «επιχειρησιακό μοτίβο λογαριασμών».

Με αυτόν τον τρόπο, σε περίπτωση έκτακτης ανάγκης:

  • Το μόνο πράγμα που μπορεί να κλέψει ο εισβολέας είναι ένα μικρό ποσό Ether (από το Ethereum) που έχει κατατεθεί στους επιχειρησιακούς λογαριασμούς για τη δημοσίευση συναλλαγών
  • Ο εισβολέας δεν θα είναι σε θέση να βλάψει τη λογική της έξυπνης σύμβασης ούτε κανέναν που εμπλέκεται στη διαδικασία
  • Οι συμβιβαστικοί λειτουργικοί λογαριασμοί μπορούν να αντικατασταθούν γρήγορα με άλλους, ωστόσο, αυτό απαιτεί είτε τη μη αυτόματη αντικατάσταση (δημιουργία νέων λογαριασμών και επαναπροσδιορισμός λογαριασμών σε όλες τις έξυπνες συμβάσεις) είτε την ανάπτυξη μιας πρόσθετης λύσης που θα κάνει όλη τη μαγεία με μία μόνο συναλλαγή από ένα σούπερ -ασφαλικός λογαριασμός (υλικό ή multi-sig).

Για παράδειγμα, στην επαναλαμβανόμενη χρέωσή μας για τη λύση Ethereum, ανεξάρτητα από το τι συμβαίνει στο πίσω μέρος, το έξυπνο συμβόλαιο επαναλαμβανόμενης χρέωσης έχει σχεδιαστεί με τέτοιο τρόπο ώστε να έχουμε έναν ολόκληρο μήνα για την αντικατάσταση των παραβιασμένων λογαριασμών, εάν κάποιοι από αυτούς παραβιάζονται .

Ωστόσο, αν θέλετε να αποκτήσετε τον ιδιωτικό σας αποθηκευτικό χώρο κλειδιού όσο το δυνατόν πιο ασφαλείς, μπορείτε να δοκιμάσετε να χρησιμοποιήσετε το Vault με μια εξαιρετική προσθήκη για το Ethereum, το οποίο αποθηκεύει και διαχειρίζεται λογαριασμούς Ethereum (επίσης, παρακολουθείτε τις ενότητες ανοιχτού κώδικα - πρόκειται να κυκλοφορήσουν κάτι παρόμοιο σύντομα). Δεν πρόκειται να εμβαθύνω στις λεπτομέρειες εδώ, αν και μπορείτε να επισκεφθείτε τα συνδεδεμένα έργα και να μάθετε από εκεί μόνοι σας.

Δεν είναι καν αυτό που έχω να πω. Ωστόσο, αυτό το άρθρο αποδείχθηκε πολύ μεγαλύτερο από ό, τι περίμενα, γι 'αυτό πρέπει να σταματήσω. Εγγραφείτε στο Medium / άλλα δίκτυα μου εάν ενδιαφέρεστε για λογισμικό, κρυπτογράφηση, ταξιδιωτικές συμβουλές ή απλώς θέλετε να ακολουθήσετε κάτι ενδιαφέρον. Ελπίζω να έχω δώσει μια πολύτιμη πληροφορία και θα τις βρείτε χρήσιμες. Μη διστάσετε να σχολιάσετε και να διαδώσετε αυτό το άρθρο!