Μια αγαπημένη ερώτηση για οποιοδήποτε κατανεμημένο σύστημα από ένα μη τεχνικό άτομο είναι "Πόσα tps υπάρχουν στο blockchain σας;" Ωστόσο, ο αριθμός που δίνεται ως απάντηση συνήθως έχει λίγα κοινά με αυτά που θα ήθελε να ακούσει ο ερωτών. Στην πραγματικότητα, ήθελε να ρωτήσει «θα ταιριάζει το blockchain σας στις απαιτήσεις της επιχείρησής μου» και αυτές οι απαιτήσεις δεν είναι ένας αριθμός, αλλά πολλές προϋποθέσεις - εδώ είναι η ανοχή σφαλμάτων δικτύου, οι απαιτήσεις οριστικότητας, τα μεγέθη, η φύση των συναλλαγών και πολλές άλλες παράμετροι. Έτσι, η απάντηση στην ερώτηση "πόσα tps" είναι απίθανο να είναι απλή και σχεδόν ποτέ πλήρης. Ένα κατανεμημένο σύστημα με δεκάδες ή εκατοντάδες κόμβους που εκτελούν αρκετά περίπλοκους υπολογισμούς μπορεί να βρίσκεται σε έναν τεράστιο αριθμό διαφορετικών καταστάσεων που σχετίζονται με την κατάσταση του δικτύου, το περιεχόμενο του blockchain, τεχνικές βλάβες, οικονομικά προβλήματα, επιθέσεις στο δίκτυο και πολλούς άλλους λόγους . Τα στάδια στα οποία είναι πιθανά προβλήματα απόδοσης διαφέρουν από τις παραδοσιακές υπηρεσίες και ένας διακομιστής δικτύου blockchain είναι μια υπηρεσία δικτύου που συνδυάζει τη λειτουργικότητα μιας βάσης δεδομένων, διακομιστή web και πελάτη torrent, γεγονός που τον καθιστά εξαιρετικά περίπλοκο όσον αφορά το προφίλ φόρτωσης σε όλα τα υποσυστήματα : επεξεργαστής, μνήμη, δίκτυο, αποθήκευση

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

Στάδια αιτήματος υπηρεσίας από πελάτη blockchain

Για να μιλήσετε με ειλικρίνεια για την ποιότητα οποιασδήποτε περισσότερο ή λιγότερο περίπλοκης υπηρεσίας, πρέπει να λάβετε υπόψη όχι μόνο τις μέσες τιμές, αλλά και τις μέγιστες/ελάχιστες, διάμεσους, εκατοστιαίες τιμές. Θεωρητικά, μπορούμε να μιλάμε για 1000 tps σε κάποιο blockchain, αλλά αν 900 συναλλαγές ολοκληρώθηκαν με τεράστια ταχύτητα και οι 100 «κόλλησαν» για λίγα δευτερόλεπτα, τότε ο μέσος χρόνος που συλλέγεται σε όλες τις συναλλαγές δεν είναι μια απολύτως δίκαιη μέτρηση για έναν πελάτη. που δεν μπόρεσα να ολοκληρώσω τη συναλλαγή σε λίγα δευτερόλεπτα. Προσωρινές «τρύπες» που προκαλούνται από χαμένους γύρους συναίνεσης ή διαχωρισμούς δικτύου μπορούν να καταστρέψουν σε μεγάλο βαθμό μια υπηρεσία που έχει δείξει εξαιρετική απόδοση σε πάγκους δοκιμών.

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

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

Τώρα ας ρίξουμε μια πιο προσεκτική ματιά σε αυτά τα στάδια και ας περιγράψουμε τα πιθανά προβλήματα απόδοσης σε κάθε στάδιο. Σε αντίθεση με τα κεντρικά συστήματα, θα εξετάσουμε επίσης την εκτέλεση κώδικα σε πελάτες δικτύου. Πολύ συχνά, κατά τη μέτρηση του TPS, ο χρόνος επεξεργασίας της συναλλαγής συλλέγεται από τους κόμβους και όχι από τον πελάτη - αυτό δεν είναι απολύτως δίκαιο. Ο πελάτης δεν ενδιαφέρεται για το πόσο γρήγορα ο κόμβος επεξεργάστηκε τη συναλλαγή του· το πιο σημαντικό πράγμα για αυτόν είναι η στιγμή που αξιόπιστες πληροφορίες σχετικά με αυτήν τη συναλλαγή που περιλαμβάνονται στο blockchain γίνονται διαθέσιμες σε αυτόν. Αυτή η μέτρηση είναι ουσιαστικά ο χρόνος εκτέλεσης της συναλλαγής. Αυτό σημαίνει ότι διαφορετικοί πελάτες, ακόμη και με την αποστολή της ίδιας συναλλαγής, μπορούν να λαμβάνουν εντελώς διαφορετικούς χρόνους, οι οποίοι εξαρτώνται από το κανάλι, το φορτίο και την εγγύτητα του κόμβου κ.λπ. Επομένως, είναι απολύτως απαραίτητο να μετρηθεί αυτός ο χρόνος στους πελάτες, καθώς αυτή είναι η παράμετρος που πρέπει να βελτιστοποιηθεί.

Προετοιμασία συναλλαγής από την πλευρά του πελάτη

Ας ξεκινήσουμε με τα δύο πρώτα σημεία: η συναλλαγή σχηματίζεται και υπογράφεται από τον πελάτη. Παραδόξως, αυτό μπορεί επίσης να είναι ένα εμπόδιο στην απόδοση του blockchain από την πλευρά του πελάτη. Αυτό είναι ασυνήθιστο για κεντρικές υπηρεσίες, οι οποίες αναλαμβάνουν όλους τους υπολογισμούς και τις λειτουργίες με δεδομένα, και ο πελάτης απλώς προετοιμάζει ένα σύντομο αίτημα που μπορεί να ζητήσει μεγάλο όγκο δεδομένων ή υπολογισμούς, λαμβάνοντας ένα έτοιμο αποτέλεσμα. Στις blockchains, ο κώδικας πελάτη γίνεται όλο και πιο ισχυρός και ο πυρήνας του blockchain γίνεται όλο και πιο ελαφρύς και τεράστιες εργασίες υπολογιστών συνήθως μεταφέρονται στο λογισμικό πελάτη. Στις blockchains, υπάρχουν πελάτες που μπορούν να προετοιμάσουν μια συναλλαγή για αρκετό καιρό (μιλάω για διάφορα merkle proofs, συνοπτικές αποδείξεις, υπογραφές κατωφλίου και άλλες πολύπλοκες λειτουργίες από την πλευρά του πελάτη). Ένα καλό παράδειγμα εύκολης επαλήθευσης στην αλυσίδα και βαριάς προετοιμασίας μιας συναλλαγής στον πελάτη είναι η απόδειξη της ιδιότητας μέλους σε μια λίστα που βασίζεται στο Merkle-tree, εδώ άρθρο.

Επίσης, μην ξεχνάτε ότι ο κώδικας πελάτη δεν στέλνει απλώς συναλλαγές στο blockchain, αλλά πρώτα ερωτά την κατάσταση του blockchain - και αυτή η δραστηριότητα μπορεί να επηρεάσει τη συμφόρηση του δικτύου και των κόμβων blockchain. Έτσι, όταν λαμβάνετε μετρήσεις, θα ήταν λογικό να μιμείται η συμπεριφορά του κώδικα πελάτη όσο το δυνατόν πληρέστερα. Ακόμα κι αν στο blockchain σας υπάρχουν απλοί πελάτες light που βάζουν μια κανονική ψηφιακή υπογραφή στην απλούστερη συναλλαγή για να μεταφέρουν κάποιο περιουσιακό στοιχείο, κάθε χρόνο εξακολουθούν να γίνονται πιο μαζικοί υπολογισμοί στον πελάτη, οι αλγόριθμοι κρυπτογράφησης γίνονται ισχυρότεροι και αυτό το μέρος της επεξεργασίας μπορεί μετατραπεί σε σημαντικό εμπόδιο στο μέλλον. Επομένως, να είστε προσεκτικοί και να μην χάσετε την κατάσταση όταν, σε μια συναλλαγή διάρκειας 3.5 δευτερολέπτων, δαπανώνται 2.5 δευτερόλεπτα για την προετοιμασία και την υπογραφή της συναλλαγής και 1.0 για την αποστολή της στο δίκτυο και την αναμονή απάντησης. Για να αξιολογήσετε τους κινδύνους αυτής της συμφόρησης, πρέπει να συλλέγετε μετρήσεις από μηχανήματα πελατών και όχι μόνο από κόμβους blockchain.

Αποστολή συναλλαγής και παρακολούθηση της κατάστασής της

Το επόμενο βήμα είναι να στείλετε τη συναλλαγή στον επιλεγμένο κόμβο blockchain και να λάβετε την κατάσταση αποδοχής της στο χώρο συγκέντρωσης συναλλαγών. Αυτό το στάδιο είναι παρόμοιο με μια κανονική πρόσβαση στη βάση δεδομένων· ο κόμβος πρέπει να καταγράψει τη συναλλαγή στο pool και να αρχίσει να διανέμει πληροφορίες σχετικά με αυτήν μέσω του δικτύου p2p. Η προσέγγιση για την αξιολόγηση της απόδοσης εδώ είναι παρόμοια με την αξιολόγηση της απόδοσης των παραδοσιακών μικρουπηρεσιών Web API και οι ίδιες οι συναλλαγές σε blockchains μπορούν να ενημερωθούν και να αλλάξουν ενεργά την κατάστασή τους. Γενικά, η ενημέρωση των πληροφοριών συναλλαγών σε ορισμένες αλυσίδες μπλοκ μπορεί να συμβεί πολλές φορές, για παράδειγμα κατά την εναλλαγή μεταξύ των πιρουνιών αλυσίδας ή όταν οι BP ανακοινώνουν την πρόθεσή τους να συμπεριλάβουν μια συναλλαγή σε ένα μπλοκ. Τα όρια στο μέγεθος αυτού του pool και του αριθμού των συναλλαγών σε αυτό μπορούν να επηρεάσουν την απόδοση του blockchain. Εάν η ομάδα συναλλαγών γεμίσει στο μέγιστο δυνατό μέγεθος ή δεν χωράει στη μνήμη RAM, η απόδοση του δικτύου μπορεί να μειωθεί απότομα. Οι αλυσίδες μπλοκ δεν διαθέτουν κεντρικά μέσα προστασίας από μια πλημμύρα ανεπιθύμητων μηνυμάτων και εάν το blockchain υποστηρίζει συναλλαγές μεγάλου όγκου και χαμηλές χρεώσεις, αυτό μπορεί να προκαλέσει υπερχείλιση της δεξαμενής συναλλαγών—ένα άλλο πιθανό εμπόδιο στην απόδοση.

Στα blockchains, ο πελάτης στέλνει μια συναλλαγή σε όποιον κόμβο blockchain του αρέσει, ο κατακερματισμός της συναλλαγής είναι συνήθως γνωστός στον πελάτη πριν από την αποστολή, οπότε το μόνο που χρειάζεται να κάνει είναι να επιτύχει τη σύνδεση και, μετά τη μετάδοση, να περιμένει να αλλάξει το blockchain. κατάστασή του, επιτρέποντας τη συναλλαγή του. Σημειώστε ότι μετρώντας «tps» μπορείτε να λάβετε εντελώς διαφορετικά αποτελέσματα για διαφορετικές μεθόδους σύνδεσης σε έναν κόμβο blockchain. Αυτό μπορεί να είναι ένα κανονικό HTTP RPC ή ένα WebSocket που σας επιτρέπει να εφαρμόσετε το μοτίβο "εγγραφής". Στη δεύτερη περίπτωση, ο πελάτης θα λάβει μια ειδοποίηση νωρίτερα και ο κόμβος θα ξοδέψει λιγότερους πόρους (κυρίως μνήμη και κίνηση) σε απαντήσεις σχετικά με την κατάσταση της συναλλαγής. Επομένως, κατά τη μέτρηση "tps" είναι απαραίτητο να ληφθεί υπόψη ο τρόπος με τον οποίο οι πελάτες συνδέονται με τους κόμβους. Επομένως, για να αξιολογήσει τους κινδύνους αυτού του σημαδιού συμφόρησης, το blockchain αναφοράς πρέπει να μπορεί να μιμείται πελάτες με αιτήματα WebSocket και HTTP RPC, σε αναλογίες που αντιστοιχούν σε πραγματικά δίκτυα, καθώς και να αλλάζει τη φύση των συναλλαγών και το μέγεθός τους.

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

Μετάδοση συναλλαγών και μπλοκ μέσω δικτύου p2p

Στις blockchains, η δικτύωση peer-to-peer (p2p) χρησιμοποιείται για τη μεταφορά συναλλαγών και μπλοκ μεταξύ των συμμετεχόντων. Οι συναλλαγές εξαπλώνονται σε όλο το δίκτυο, ξεκινώντας από έναν από τους κόμβους, μέχρι να φτάσουν σε παραγωγούς ομότιμων μπλοκ, οι οποίοι συσκευάζουν τις συναλλαγές σε μπλοκ και, χρησιμοποιώντας το ίδιο p2p, διανέμουν νέα μπλοκ σε όλους τους κόμβους δικτύου. Η βάση των περισσότερων σύγχρονων δικτύων p2p είναι διάφορες τροποποιήσεις του πρωτοκόλλου Kademlia. Εδώ μια καλή περίληψη αυτού του πρωτοκόλλου και εδώ - ένα άρθρο με διάφορες μετρήσεις στο δίκτυο BitTorrent, από το οποίο μπορεί κανείς να καταλάβει ότι αυτός ο τύπος δικτύου είναι πιο περίπλοκος και λιγότερο προβλέψιμος από ένα άκαμπτα διαμορφωμένο δίκτυο μιας κεντρικής υπηρεσίας. Επίσης, εδώ άρθρο σχετικά με τη μέτρηση διαφόρων ενδιαφέρουσες μετρήσεις για κόμβους Ethereum.

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

Έτσι, η συναλλαγή πρέπει τώρα να διανεμηθεί σε όλο το δίκτυο, ώστε οι παραγωγοί μπλοκ να μπορούν να τη δουν και να την συμπεριλάβουν στο μπλοκ. Ο κόμβος «διανέμει» ενεργά μια νέα συναλλαγή σε όλους και ακούει το δίκτυο, περιμένοντας ένα μπλοκ στο ευρετήριο του οποίου θα εμφανιστεί η απαιτούμενη συναλλαγή για να ειδοποιήσει τον πελάτη σε αναμονή. Ο χρόνος που χρειάζεται το δίκτυο για να μεταφέρει πληροφορίες σχετικά με νέες συναλλαγές και μπλοκ μεταξύ τους σε δίκτυα p2p εξαρτάται από έναν πολύ μεγάλο αριθμό παραγόντων: τον αριθμό των ειλικρινών κόμβων που εργάζονται κοντά (από την άποψη του δικτύου), το "θερμό- up» των κρυφών μνήμων αυτών των κόμβων, το μέγεθος των μπλοκ, τις συναλλαγές, τη φύση των αλλαγών, τη γεωγραφία του δικτύου, τον αριθμό των κόμβων και πολλούς άλλους παράγοντες. Οι σύνθετες μετρήσεις των μετρήσεων απόδοσης σε τέτοια δίκτυα είναι ένα πολύπλοκο ζήτημα· είναι απαραίτητο να αξιολογείται ταυτόχρονα ο χρόνος επεξεργασίας αιτημάτων τόσο στους πελάτες όσο και στους ομοτίμους (κόμβους αλυσίδας μπλοκ). Προβλήματα σε οποιονδήποτε από τους μηχανισμούς p2p, λανθασμένη απομάκρυνση και αποθήκευση δεδομένων, αναποτελεσματική διαχείριση λιστών ενεργών ομότιμων και πολλοί άλλοι παράγοντες μπορούν να προκαλέσουν καθυστερήσεις που επηρεάζουν την αποτελεσματικότητα ολόκληρου του δικτύου στο σύνολό του, και αυτό το σημείο συμφόρησης είναι το πιο δύσκολο να αναλυθεί , δοκιμή και ερμηνεία των αποτελεσμάτων.

Επεξεργασία Blockchain και ενημέρωση κρατικής βάσης δεδομένων

Το πιο σημαντικό μέρος του blockchain είναι ο αλγόριθμος συναίνεσης, η εφαρμογή του σε νέα μπλοκ που λαμβάνονται από το δίκτυο και η επεξεργασία των συναλλαγών με την καταγραφή των αποτελεσμάτων στην κρατική βάση δεδομένων. Η προσθήκη ενός νέου μπλοκ στην αλυσίδα και στη συνέχεια η επιλογή της κύριας αλυσίδας θα πρέπει να λειτουργήσει όσο το δυνατόν γρηγορότερα. Ωστόσο, στην πραγματική ζωή, το «πρέπει» δεν σημαίνει «έργα», και μπορεί κανείς, για παράδειγμα, να φανταστεί μια κατάσταση όπου δύο μακριές ανταγωνιστικές αλυσίδες εναλλάσσονται συνεχώς μεταξύ τους, αλλάζοντας τα μεταδεδομένα χιλιάδων συναλλαγών στο pool σε κάθε μεταγωγή. και επαναφέρει συνεχώς τη βάση δεδομένων κατάστασης. Αυτό το στάδιο, όσον αφορά τον ορισμό του bottleneck, είναι απλούστερο από το επίπεδο δικτύου p2p, επειδή Η εκτέλεση συναλλαγών και ο αλγόριθμος συναίνεσης είναι αυστηρά ντετερμινιστικοί και είναι ευκολότερο να μετρηθεί οτιδήποτε εδώ.
Το κύριο πράγμα είναι να μην συγχέουμε την τυχαία υποβάθμιση στην απόδοση αυτού του σταδίου με προβλήματα δικτύου - οι κόμβοι είναι πιο αργοί στην παράδοση μπλοκ και πληροφοριών σχετικά με την κύρια αλυσίδα και για έναν εξωτερικό πελάτη αυτό μπορεί να μοιάζει με αργό δίκτυο, αν και το πρόβλημα έγκειται στο ένα εντελώς διαφορετικό μέρος.

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

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

Λήψη από τον πελάτη ειδοποίησης σχετικά με τη συμπερίληψη μιας συναλλαγής στο blockchain

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

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

Συμπέρασμα

Ως αποτέλεσμα, μπορούμε να περιγράψουμε τους τύπους λειτουργιών που εκτελούνται σε blockchains και να τις χωρίσουμε σε διάφορες κατηγορίες:

κρυπτογραφικές μετατροπές, κατασκευή απόδειξης
δικτύωση peer-to-peer, συναλλαγές και αναπαραγωγή μπλοκ
επεξεργασία συναλλαγών, εκτέλεση έξυπνων συμβολαίων
εφαρμογή αλλαγών στην αλυσίδα μπλοκ στην κρατική βάση δεδομένων, ενημέρωση δεδομένων για συναλλαγές και μπλοκ
αιτήματα μόνο για ανάγνωση για κατάσταση βάσης δεδομένων, API κόμβου blockchain, συνδρομητικές υπηρεσίες

Γενικά, οι τεχνικές απαιτήσεις για τους σύγχρονους κόμβους blockchain είναι εξαιρετικά σοβαρές - γρήγορες CPU για κρυπτογραφία, μεγάλη ποσότητα μνήμης RAM για αποθήκευση και γρήγορη πρόσβαση στη βάση δεδομένων κατάστασης, αλληλεπίδραση δικτύου με τη χρήση μεγάλου αριθμού ταυτόχρονα ανοιχτών συνδέσεων και μεγάλο αποθηκευτικό χώρο. Τέτοιες υψηλές απαιτήσεις και η αφθονία διαφορετικών τύπων λειτουργιών οδηγούν αναπόφευκτα στο γεγονός ότι οι κόμβοι μπορεί να μην έχουν αρκετούς πόρους και, στη συνέχεια, οποιοδήποτε από τα στάδια που συζητήθηκαν παραπάνω μπορεί να γίνει άλλο ένα εμπόδιο για τη συνολική απόδοση του δικτύου.

Κατά το σχεδιασμό και την αξιολόγηση της απόδοσης των blockchains, θα πρέπει να λάβετε υπόψη όλα αυτά τα σημεία. Για να γίνει αυτό, πρέπει να συλλέξετε και να αναλύσετε μετρήσεις ταυτόχρονα από πελάτες και κόμβους δικτύου, να αναζητήσετε συσχετίσεις μεταξύ τους, να υπολογίσετε το χρόνο που απαιτείται για την παροχή υπηρεσιών σε πελάτες, να λάβετε υπόψη όλους τους κύριους πόρους: cpu/μνήμη/δίκτυο/αποθήκευση , κατανοούν πώς χρησιμοποιούνται και επηρεάζουν ο ένας τον άλλον. Όλα αυτά κάνουν τη σύγκριση των ταχυτήτων διαφορετικών blockchains με τη μορφή "πόσα TPS" μια εξαιρετικά άχαρη εργασία, καθώς υπάρχει ένας τεράστιος αριθμός διαφορετικών διαμορφώσεων και καταστάσεων. Σε μεγάλα κεντρικά συστήματα, συμπλέγματα εκατοντάδων διακομιστών, αυτά τα προβλήματα είναι επίσης πολύπλοκα και απαιτούν επίσης τη συλλογή μεγάλου αριθμού διαφορετικών μετρήσεων, αλλά σε blockchains, λόγω δικτύων p2p, εικονικών μηχανών που επεξεργάζονται συμβόλαια, εσωτερικές οικονομίες, τον αριθμό των βαθμών η ελευθερία είναι πολύ μεγαλύτερη, γεγονός που κάνει τη δοκιμή ακόμη και σε αρκετούς διακομιστές, δεν είναι ενδεικτική και δείχνει μόνο εξαιρετικά κατά προσέγγιση τιμές που δεν έχουν σχεδόν καμία σχέση με την πραγματικότητα.

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

Έτσι, όταν λάβετε την ερώτηση "πόσα TPS υπάρχουν στο blockchain σας;", προσφέρετε στον συνομιλητή σας λίγο τσάι και ρωτήστε εάν είναι έτοιμος να δει δώδεκα γραφήματα και επίσης να ακούσει και τα τρία κουτιά με προβλήματα απόδοσης του blockchain και τις προτάσεις σας για λύνοντάς τα...

Πηγή: www.habr.com

Πόσα TPS υπάρχουν στο blockchain σας;