Γεια σας, εργάζομαι στην ομάδα του έργου DRD KP (κατανεμημένο μητρώο δεδομένων για την παρακολούθηση του κύκλου ζωής των σετ τροχών). Εδώ θέλω να μοιραστώ την εμπειρία της ομάδας μας στην ανάπτυξη μιας επιχειρηματικής αλυσίδας blockchain για αυτό το έργο υπό τους περιορισμούς της τεχνολογίας. Θα μιλήσω κυρίως για το Hyperledger Fabric, αλλά η προσέγγιση που περιγράφεται εδώ μπορεί να επεκταθεί σε οποιοδήποτε επιτρεπόμενο blockchain. Ο απώτερος στόχος της έρευνάς μας είναι να προετοιμάσουμε επιχειρηματικές λύσεις blockchain, έτσι ώστε το τελικό προϊόν να είναι ευχάριστο στη χρήση και όχι πολύ δύσκολο στη συντήρηση.
Δεν θα υπάρξουν ανακαλύψεις, απροσδόκητες λύσεις και δεν θα επισημανθούν μοναδικές εξελίξεις εδώ (γιατί δεν έχω). Θέλω απλώς να μοιραστώ τη μέτρια εμπειρία μου, να δείξω ότι "ήταν δυνατό" και, ίσως, να διαβάσω για τις εμπειρίες άλλων ανθρώπων να παίρνουν καλές και όχι τόσο καλές αποφάσεις στα σχόλια.
Πρόβλημα: Οι μπλοκ αλυσίδες δεν κλιμακώνονται ακόμη
Σήμερα, οι προσπάθειες πολλών προγραμματιστών στοχεύουν στο να κάνουν το blockchain μια πραγματικά βολική τεχνολογία και όχι μια ωρολογιακή βόμβα σε ένα όμορφο περιτύλιγμα. Τα κρατικά κανάλια, η αισιόδοξη συνάθροιση, το πλάσμα και ο διαμοιρασμός πιθανότατα θα γίνουν συνηθισμένα. Κάποια μέρα. Ή ίσως η TON θα αναβάλει ξανά την κυκλοφορία για έξι μήνες και το επόμενο Plasma Group θα πάψει να υπάρχει. Μπορούμε να πιστεύουμε στον επόμενο οδικό χάρτη και να διαβάζουμε υπέροχες λευκές βίβλους τη νύχτα, αλλά εδώ και τώρα πρέπει να κάνουμε κάτι με αυτά που έχουμε. Κάντε τα σκατά.
Το έργο που έχει τεθεί για την ομάδα μας στο τρέχον έργο μοιάζει γενικά ως εξής: υπάρχουν πολλά θέματα, που φτάνουν σε αρκετές χιλιάδες, που δεν θέλουν να οικοδομήσουν σχέσεις με βάση την εμπιστοσύνη. Είναι απαραίτητο να δημιουργηθεί μια λύση στο DLT που θα λειτουργεί σε συνηθισμένους υπολογιστές χωρίς ειδικές απαιτήσεις απόδοσης και θα παρέχει μια εμπειρία χρήστη όχι χειρότερη από οποιαδήποτε κεντρικά λογιστικά συστήματα. Η τεχνολογία πίσω από τη λύση πρέπει να ελαχιστοποιεί την πιθανότητα κακόβουλης χειραγώγησης δεδομένων - γι' αυτό το blockchain είναι εδώ.
Συνθήματα από λευκές βίβλους και ΜΜΕ μας υπόσχονται ότι η επόμενη εξέλιξη θα μας επιτρέψει να κάνουμε εκατομμύρια συναλλαγές ανά δευτερόλεπτο. Τι είναι αλήθεια;
Το Mainnet Ethereum τρέχει αυτή τη στιγμή με ~30 tps. Εξαιτίας αυτού και μόνο, είναι δύσκολο να το εκλάβουμε ως blockchain με οποιονδήποτε τρόπο κατάλληλο για τις εταιρικές ανάγκες. Μεταξύ των επιτρεπόμενων λύσεων υπάρχουν σημεία αναφοράς που δείχνουν 2000 tps () ή 3000 tps (, υπάρχει λίγο λιγότερο στη δημοσίευση, αλλά πρέπει να λάβετε υπόψη ότι το σημείο αναφοράς πραγματοποιήθηκε στον παλιό κινητήρα συναίνεσης). ήταν , που δεν έδωσε τα χειρότερα αποτελέσματα, 20000 tps, αλλά μέχρι στιγμής πρόκειται απλώς για ακαδημαϊκή έρευνα, που περιμένει τη σταθερή εφαρμογή της. Είναι απίθανο μια εταιρεία που έχει την οικονομική δυνατότητα να διατηρήσει ένα τμήμα προγραμματιστών blockchain να αντέξει τέτοιους δείκτες. Αλλά το πρόβλημα δεν είναι μόνο η απόδοση, υπάρχει και λανθάνουσα κατάσταση.
Αφάνεια
Η καθυστέρηση από τη στιγμή που ξεκινά μια συναλλαγή μέχρι την τελική έγκρισή της από το σύστημα εξαρτάται όχι μόνο από την ταχύτητα με την οποία το μήνυμα περνά από όλα τα στάδια επικύρωσης και παραγγελίας, αλλά και από τις παραμέτρους σχηματισμού μπλοκ. Ακόμα κι αν το blockchain μας επιτρέπει να δεσμευόμαστε με ταχύτητα 1000000 tps, αλλά απαιτούνται 10 λεπτά για να δημιουργήσουμε ένα μπλοκ 488 MB, θα γίνει πιο εύκολο για εμάς;
Ας ρίξουμε μια πιο προσεκτική ματιά στον κύκλο ζωής της συναλλαγής στο Hyperledger Fabric για να κατανοήσουμε πού ξοδεύεται ο χρόνος και πώς σχετίζεται με τις παραμέτρους δημιουργίας μπλοκ.
παρμένο από εδώ:
(1) Ο πελάτης δημιουργεί μια συναλλαγή, τη στέλνει σε ομότιμους που υποστηρίζουν, οι τελευταίοι προσομοιώνουν τη συναλλαγή (εφαρμόστε αλλαγές που έγιναν με αλυσιδωτό κώδικα στην τρέχουσα κατάσταση, αλλά μην δεσμεύεστε στο καθολικό) και λαμβάνουν RWSet - ονόματα κλειδιών, εκδόσεις και τιμές από τη συλλογή στο CouchDB, (2) οι υποστηρικτές στέλνουν πίσω ένα υπογεγραμμένο RWSet στον πελάτη, (3) ο πελάτης είτε ελέγχει την ύπαρξη υπογραφών όλων των απαραίτητων ομότιμων (endorsers) και στη συνέχεια στέλνει τη συναλλαγή στην υπηρεσία παραγγελίας , ή το στέλνει χωρίς επαλήθευση (ο έλεγχος θα γίνει ακόμα αργότερα), η υπηρεσία παραγγελίας σχηματίζει ένα μπλοκ και (4) το στέλνει πίσω σε όλους τους ομοτίμους, όχι μόνο στους υποστηρικτές. οι όμοιοι ελέγχουν ότι οι βασικές εκδόσεις στο σύνολο ανάγνωσης ταιριάζουν με τις εκδόσεις της βάσης δεδομένων, ότι όλοι οι υποστηρικτές έχουν υπογραφές και τελικά δεσμεύουν το μπλοκ.
Αλλά δεν είναι μόνο αυτό. Οι λέξεις "ο παραγγελέας σχηματίζει ένα μπλοκ" κρύβουν όχι μόνο τη σειρά των συναλλαγών, αλλά και 3 διαδοχικά αιτήματα δικτύου από τον ηγέτη προς τους ακόλουθους και πίσω: ο αρχηγός προσθέτει ένα μήνυμα στο αρχείο καταγραφής, το στέλνει στους ακόλουθους, οι τελευταίοι το προσθέτουν στο αρχείο καταγραφής τους, στέλνει επιβεβαίωση επιτυχούς αναπαραγωγής στον αρχηγό, ο αρχηγός δεσμεύει το μήνυμα , στέλνει επιβεβαίωση δέσμευσης στους ακόλουθους, οι ακόλουθοι δεσμεύονται. Όσο μικρότερο είναι το μέγεθος και ο χρόνος σχηματισμού μπλοκ, τόσο πιο συχνά η υπηρεσία παραγγελιών θα πρέπει να επιτύχει συναίνεση. Το Hyperledger Fabric έχει δύο παραμέτρους για το σχηματισμό μπλοκ: BatchTimeout - χρόνος σχηματισμού μπλοκ και BatchSize - μέγεθος μπλοκ (ο αριθμός των συναλλαγών και το μέγεθος του ίδιου του μπλοκ σε byte). Μόλις μια από τις παραμέτρους φτάσει στο όριο, απελευθερώνεται ένα νέο μπλοκ. Όσο περισσότεροι κόμβοι παραγγελίας, τόσο περισσότερος χρόνος θα διαρκέσει. Επομένως, πρέπει να αυξήσετε το BatchTimeout και το BatchSize. Αλλά δεδομένου ότι τα RWSets είναι εκδομένα, όσο μεγαλύτερο είναι το μπλοκ που κάνουμε, τόσο μεγαλύτερη είναι η πιθανότητα συγκρούσεων MVCC. Επιπλέον, καθώς αυξάνεται το BatchTimeout, το UX υποβαθμίζεται καταστροφικά. Το παρακάτω σχήμα για την επίλυση αυτών των προβλημάτων μου φαίνεται λογικό και προφανές.
Πώς να αποφύγετε την αναμονή για την οριστικοποίηση του μπλοκ και να μην χάσετε τη δυνατότητα παρακολούθησης της κατάστασης συναλλαγής
Όσο μεγαλύτερος είναι ο χρόνος σχηματισμού και το μέγεθος του μπλοκ, τόσο μεγαλύτερη είναι η απόδοση του blockchain. Το ένα δεν προκύπτει άμεσα από το άλλο, αλλά θα πρέπει να θυμόμαστε ότι η δημιουργία συναίνεσης στο RAFT απαιτεί τρία αιτήματα δικτύου από τον ηγέτη προς τους ακόλουθους και πίσω. Όσο περισσότεροι κόμβοι παραγγελίας, τόσο περισσότερος χρόνος θα διαρκέσει. Όσο μικρότερο είναι το μέγεθος και ο χρόνος σχηματισμού μπλοκ, τόσο περισσότερες τέτοιες αλληλεπιδράσεις υπάρχουν. Πώς να αυξήσετε τον χρόνο παραγωγής και το μέγεθος του μπλοκ χωρίς να αυξήσετε τον χρόνο απόκρισης του συστήματος για τον τελικό χρήστη;
Αρχικά, πρέπει να επιλύσουμε με κάποιο τρόπο τις διενέξεις MVCC που προκαλούνται από ένα μεγάλο μέγεθος μπλοκ, το οποίο μπορεί να περιλαμβάνει διαφορετικά σύνολα RW με την ίδια έκδοση. Προφανώς, από την πλευρά του πελάτη (σε σχέση με το δίκτυο blockchain, αυτό θα μπορούσε κάλλιστα να είναι το backend, και το εννοώ) χρειάζεστε Πρόγραμμα χειρισμού διένεξης MVCC, το οποίο μπορεί να είναι είτε ξεχωριστή υπηρεσία είτε κανονικός διακοσμητής πάνω από την κλήση που ξεκινά τη συναλλαγή με λογική επανάληψης.
Η επανάληψη μπορεί να εφαρμοστεί με μια εκθετική στρατηγική, αλλά τότε η καθυστέρηση θα υποβαθμιστεί εξίσου εκθετικά. Επομένως, θα πρέπει να χρησιμοποιήσετε είτε μια τυχαιοποιημένη επανάληψη εντός ορισμένων μικρών ορίων είτε μια σταθερή. Με προσοχή σε πιθανές συγκρούσεις στην πρώτη επιλογή.
Το επόμενο βήμα είναι να κάνουμε την αλληλεπίδραση του πελάτη με το σύστημα ασύγχρονη, ώστε να μην περιμένει για 15, 30 ή 10000000 δευτερόλεπτα, τα οποία θα ορίσουμε ως BatchTimeout. Αλλά ταυτόχρονα, είναι απαραίτητο να διατηρηθεί η δυνατότητα επαλήθευσης ότι οι αλλαγές που ξεκινούν από τη συναλλαγή καταγράφονται/δεν καταγράφονται στο blockchain.
Μια βάση δεδομένων μπορεί να χρησιμοποιηθεί για την αποθήκευση της κατάστασης συναλλαγής. Η απλούστερη επιλογή είναι το CouchDB λόγω της ευκολίας χρήσης του: η βάση δεδομένων έχει ένα UI out of the box, ένα REST API και μπορείτε εύκολα να ρυθμίσετε την αναπαραγωγή και την κοινή χρήση για αυτήν. Μπορείτε απλά να δημιουργήσετε μια ξεχωριστή συλλογή στην ίδια παρουσία του CouchDB που χρησιμοποιεί το Fabric για να αποθηκεύσει την παγκόσμια κατάστασή του. Πρέπει να αποθηκεύσουμε τέτοιου είδους έγγραφα.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Αυτό το έγγραφο εγγράφεται στη βάση δεδομένων πριν σταλεί η συναλλαγή σε ομότιμους, το αναγνωριστικό οντότητας επιστρέφεται στον χρήστη (το ίδιο αναγνωριστικό χρησιμοποιείται ως κλειδί) εάν πρόκειται για λειτουργία δημιουργίας και, στη συνέχεια, τα πεδία Κατάσταση, TxID και Σφάλμα ενημερώνεται καθώς λαμβάνονται σχετικές πληροφορίες από ομοτίμους.
Σε αυτό το σχήμα, ο χρήστης δεν περιμένει να σχηματιστεί τελικά το μπλοκ, παρακολουθώντας τον περιστρεφόμενο τροχό στην οθόνη για 10 δευτερόλεπτα, λαμβάνει μια άμεση απάντηση από το σύστημα και συνεχίζει να εργάζεται.
Επιλέξαμε το BoltDB για την αποθήκευση των καταστάσεων συναλλαγών επειδή πρέπει να εξοικονομήσουμε μνήμη και δεν θέλουμε να χάνουμε χρόνο στην αλληλεπίδραση δικτύου με έναν ξεχωριστό διακομιστή βάσης δεδομένων, ειδικά όταν αυτή η αλληλεπίδραση πραγματοποιείται χρησιμοποιώντας ένα πρωτόκολλο απλού κειμένου. Παρεμπιπτόντως, είτε χρησιμοποιείτε το CouchDB για να εφαρμόσετε το σχήμα που περιγράφεται παραπάνω είτε απλώς για να αποθηκεύσετε την παγκόσμια κατάσταση, σε κάθε περίπτωση είναι λογικό να βελτιστοποιήσετε τον τρόπο αποθήκευσης δεδομένων στο CouchDB. Από προεπιλογή, στο CouchDB, το μέγεθος των κόμβων b-tree είναι 1279 byte, το οποίο είναι πολύ μικρότερο από το μέγεθος του τομέα στο δίσκο, πράγμα που σημαίνει ότι τόσο η ανάγνωση όσο και η επανεξισορρόπηση του δέντρου θα απαιτήσουν περισσότερη φυσική πρόσβαση στο δίσκο. Το βέλτιστο μέγεθος αντιστοιχεί στο πρότυπο και είναι 4 kilobyte. Για βελτιστοποίηση πρέπει να ορίσουμε την παράμετρο btree_chunk_size ίσο με 4096 στο αρχείο διαμόρφωσης CouchDB. Για BoltDB τέτοια χειροκίνητη παρέμβαση .
Backpressure: στρατηγική buffer
Αλλά μπορεί να υπάρχουν πολλά μηνύματα. Περισσότερα από όσα μπορεί να χειριστεί το σύστημα, η κοινή χρήση πόρων με μια ντουζίνα άλλες υπηρεσίες εκτός από αυτές που φαίνονται στο διάγραμμα - και όλα αυτά θα πρέπει να λειτουργούν άψογα ακόμη και σε μηχανήματα στα οποία η εκτέλεση του Intellij Idea θα ήταν εξαιρετικά κουραστική.
Το πρόβλημα της διαφορετικής ικανότητας των συστημάτων επικοινωνίας, παραγωγού και καταναλωτή, επιλύεται με διαφορετικούς τρόπους. Ας δούμε τι μπορούμε να κάνουμε.
Ρίψη: Μπορούμε να ισχυριστούμε ότι είμαστε σε θέση να επεξεργαστούμε το πολύ X συναλλαγές σε T δευτερόλεπτα. Όλα τα αιτήματα που υπερβαίνουν αυτό το όριο απορρίπτονται. Αυτό είναι πολύ απλό, αλλά στη συνέχεια μπορείτε να ξεχάσετε το UX.
Ο έλεγχος: ο καταναλωτής πρέπει να έχει κάποιο είδος διεπαφής μέσω του οποίου, ανάλογα με το φορτίο, μπορεί να ελέγχει το TPS του παραγωγού. Δεν είναι κακό, αλλά επιβάλλει υποχρεώσεις στους προγραμματιστές του πελάτη που δημιουργούν το φορτίο για την υλοποίηση αυτής της διεπαφής. Αυτό είναι απαράδεκτο για εμάς, καθώς το blockchain στο μέλλον θα ενσωματωθεί σε μεγάλο αριθμό συστημάτων που υπάρχουν εδώ και καιρό.
Buffering: Αντί να προσπαθήσουμε να αντισταθούμε στη ροή δεδομένων εισόδου, μπορούμε να αποθηκεύσουμε αυτήν τη ροή και να την επεξεργαστούμε με την απαιτούμενη ταχύτητα. Προφανώς αυτή είναι η καλύτερη λύση εάν θέλουμε να προσφέρουμε μια καλή εμπειρία χρήστη. Υλοποιήσαμε το buffer χρησιμοποιώντας μια ουρά στο RabbitMQ.
Δύο νέες ενέργειες έχουν προστεθεί στο σχήμα: (1) μετά την άφιξη ενός αιτήματος στο API, ένα μήνυμα με τις απαραίτητες παραμέτρους για την κλήση μιας συναλλαγής τοποθετείται στην ουρά και ο πελάτης λαμβάνει ένα μήνυμα ότι η συναλλαγή έγινε αποδεκτή από το σύστημα, (2) το backend διαβάζει τα δεδομένα με την ταχύτητα που καθορίζεται στη διαμόρφωση από την ουρά. εκκινεί μια συναλλαγή και ενημερώνει τα δεδομένα στο χώρο αποθήκευσης κατάστασης.
Τώρα μπορείτε να αυξήσετε τον χρόνο σχηματισμού και να αποκλείσετε τη χωρητικότητα όσο θέλετε, αποκρύπτοντας καθυστερήσεις από τον χρήστη.
Άλλα εργαλεία
Δεν ειπώθηκε τίποτα εδώ για τον αλυσιδωτό κώδικα, επειδή, κατά κανόνα, δεν υπάρχει τίποτα για βελτιστοποίηση σε αυτόν. Ο αλυσιδωτός κώδικας πρέπει να είναι όσο το δυνατόν πιο απλός και ασφαλής - αυτό είναι το μόνο που απαιτείται από αυτόν. Το πλαίσιο μας βοηθά να γράφουμε αλυσιδωτό κώδικα απλά και με ασφάλεια από S7 Techlab και στατικό αναλυτή .
Επιπλέον, η ομάδα μας αναπτύσσει ένα σύνολο βοηθητικών προγραμμάτων για να κάνει την εργασία με το Fabric απλή και ευχάριστη: , ένα βοηθητικό πρόγραμμα για (προσθήκη/αφαίρεση οργανισμών, κόμβων RAFT), βοηθητικό πρόγραμμα για . Αν θέλετε να συνεισφέρετε, είστε ευπρόσδεκτοι.
Συμπέρασμα
Αυτή η προσέγγιση σάς επιτρέπει να αντικαταστήσετε εύκολα το Hyperledger Fabric με Quorum, άλλα ιδιωτικά δίκτυα Ethereum (PoA ή ακόμα και PoW), να μειώσετε σημαντικά την πραγματική απόδοση, αλλά ταυτόχρονα να διατηρήσετε κανονικό UX (τόσο για χρήστες στο πρόγραμμα περιήγησης όσο και για ενσωματωμένα συστήματα). Όταν αντικαθιστάτε το Fabric με το Ethereum στο σχήμα, θα χρειαστεί μόνο να αλλάξετε τη λογική της επανάληψης της υπηρεσίας/διακοσμητή από την επεξεργασία διενέξεων MVCC σε ατομική αύξηση και επαναποστολή. Η προσωρινή αποθήκευση και η αποθήκευση κατάστασης κατέστησαν δυνατή την αποσύνδεση του χρόνου απόκρισης από τον χρόνο σχηματισμού μπλοκ. Τώρα μπορείτε να προσθέσετε χιλιάδες κόμβους παραγγελιών και να μην φοβάστε ότι μπλοκ σχηματίζονται πολύ συχνά και να φορτώσετε την υπηρεσία παραγγελίας.
Βασικά, αυτό ήταν το μόνο που ήθελα να μοιραστώ. Θα χαρώ αν αυτό βοηθήσει κάποιον στη δουλειά του.
Πηγή: www.habr.com