Έξυπνη αναμέτρηση συμβολαίου: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

Υπάρχουν περισσότεροι από ένας τρόποι για να τοποθετήσετε κώδικα σε ένα blockchain

Στις περισσότερες συζητήσεις για τα blockchains, δεν χρειάζεται πολύς χρόνος για να εμφανιστεί η έννοια των «έξυπνων συμβολαίων». Κατά τη λαϊκή φαντασία, τα έξυπνα συμβόλαια αυτοματοποιούν την εκτέλεση διακομματικών αλληλεπιδράσεων, χωρίς να απαιτούν έναν αξιόπιστο μεσάζοντα. Εκφράζοντας τις νομικές σχέσεις με κώδικα και όχι με λόγια, υπόσχονται να επιτρέψουν στις συναλλαγές να πραγματοποιούνται άμεσα και χωρίς σφάλματα, είτε εσκεμμένα είτε όχι.

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

Σε αυτό το άρθρο, ο στόχος μου είναι να εξετάσω μερικές από τις σημαντικές διαφορές μεταξύ των προσεγγίσεων έξυπνων συμβολαίων και των συμβιβάσεων που αντιπροσωπεύουν. Θα το κάνω αυτό εξετάζοντας τέσσερις δημοφιλείς πλατφόρμες blockchain για επιχειρήσεις που υποστηρίζουν κάποια μορφή προσαρμοσμένου κώδικα on-chain. Πρώτον, της IBM Υφάσματα Hyperledger, η οποία αποκαλεί τις συμβάσεις της «αλυσιδωτό κώδικα». Δεύτερον, η πλατφόρμα μας MultiChain, η οποία εισάγει έξυπνα φίλτρα στην έκδοση 2.0. Τρίτος, Ethereum (και επιτρέπεται Απαρτία και Τρυπώνω spin-offs), το οποίο έκανε δημοφιλή το όνομα «έξυπνο συμβόλαιο». Και τελικά, R3 Corda, η οποία αναφέρεται σε «συμβάσεις» στις συναλλαγές της. Παρά τη διαφορετική ορολογία, τελικά όλα αυτά αναφέρονται στο ίδιο πράγμα – κώδικας για συγκεκριμένη εφαρμογή που ορίζει τους κανόνες μιας αλυσίδας.

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

Βασικά στοιχεία blockchain

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

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

Οι κόμβοι συνδέονται μεταξύ τους με τρόπο peer-to-peer, διαδίδοντας γρήγορα τις συναλλαγές και τα «μπλοκ» στα οποία έχουν χρονοσήμανση και επιβεβαίωση σε όλο το δίκτυο. Η ίδια η αλυσίδα μπλοκ είναι κυριολεκτικά μια αλυσίδα αυτών των μπλοκ, η οποία σχηματίζει ένα ταξινομημένο αρχείο καταγραφής κάθε ιστορικής συναλλαγής. Χρησιμοποιείται ένας «αλγόριθμος συναίνεσης» για να διασφαλιστεί ότι όλοι οι κόμβοι καταλήγουν σε συμφωνία σχετικά με το περιεχόμενο του blockchain, χωρίς να απαιτείται κεντρικός έλεγχος. (Σημειώστε ότι μέρος αυτής της περιγραφής δεν ισχύει για το Corda, στο οποίο κάθε κόμβος έχει μόνο ένα μερικό αντίγραφο της βάσης δεδομένων και δεν υπάρχει παγκόσμιο blockchain. Θα μιλήσουμε περισσότερα γι' αυτό αργότερα.)

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

• Κανόνες συναλλαγών. Εάν κάποιος συμμετέχων μπορεί να αλλάξει απευθείας τη βάση δεδομένων, πώς διασφαλίζουμε ότι ακολουθεί τους κανόνες της εφαρμογής; Τι εμποδίζει έναν χρήστη να καταστρέψει τα περιεχόμενα της βάσης δεδομένων με τρόπο αυτοεξυπηρετούμενο;
• Αιτιοκρατία. Μόλις καθοριστούν αυτοί οι κανόνες, θα εφαρμοστούν πολλές φορές από πολλούς κόμβους κατά την επεξεργασία συναλλαγών για το δικό τους αντίγραφο της βάσης δεδομένων. Πώς διασφαλίζουμε ότι κάθε κόμβος έχει ακριβώς το ίδιο αποτέλεσμα;
• Πρόληψη συγκρούσεων. Χωρίς κεντρικό συντονισμό, πώς αντιμετωπίζουμε δύο συναλλαγές που η καθεμία ακολουθεί τους κανόνες της εφαρμογής, αλλά παρ' όλα αυτά συγκρούονται μεταξύ τους; Οι συγκρούσεις μπορεί να προκύψουν από μια σκόπιμη προσπάθεια να παίξεις το σύστημα ή να είναι το αθώο αποτέλεσμα κακής τύχης και συγχρονισμού.

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

Ας ξεκινήσουμε με τους κανόνες συναλλαγών, την πρώτη από αυτές τις προκλήσεις, και ας δούμε πώς εκφράζονται σε Fabric, MultiChain, Ethereum και Corda αντίστοιχα.

Κανόνες συναλλαγών

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

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

Είσοδοι και έξοδοι

Οι πλατφόρμες blockchain μας βασίζονται σε δύο ευρείες προσεγγίσεις για την έκφραση κανόνων συναλλαγών. Το πρώτο, το οποίο αποκαλώ "μοντέλο εισόδου-εξόδου", χρησιμοποιείται στο MultiChain και το Corda. Εδώ, οι συναλλαγές απαριθμούν ρητά τις σειρές ή τις «καταστάσεις» της βάσης δεδομένων που διαγράφουν και δημιουργούν, σχηματίζοντας ένα σύνολο «εισόδων» και «εξόδων» αντίστοιχα. Η τροποποίηση μιας σειράς εκφράζεται ως η ισοδύναμη λειτουργία της διαγραφής αυτής της σειράς και της δημιουργίας μιας νέας στη θέση της.

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

Δεδομένων αυτών των τριών συνόλων εισόδων, εξόδων και μεταδεδομένων, η εγκυρότητα μιας συναλλαγής σε MultiChain ή Corda ορίζεται από κάποιον κώδικα που μπορεί να εκτελέσει αυθαίρετους υπολογισμούς σε αυτά τα σύνολα. Αυτός ο κωδικός μπορεί να επικυρώσει τη συναλλαγή ή αλλιώς να επιστρέψει ένα σφάλμα με μια αντίστοιχη εξήγηση. Μπορείτε να σκεφτείτε το μοντέλο εισόδου-εξόδου ως έναν αυτοματοποιημένο «επιθεωρητή» που κρατά μια λίστα ελέγχου που διασφαλίζει ότι οι συναλλαγές ακολουθούν κάθε κανόνα. Εάν η συναλλαγή αποτύχει σε κάποιον από αυτούς τους ελέγχους, θα απορριφθεί αυτόματα από όλους τους κόμβους του δικτύου.

Θα πρέπει να σημειωθεί ότι, παρά το κοινό μοντέλο εισόδου-εξόδου, η MultiChain και η Corda το εφαρμόζουν πολύ διαφορετικά. Στο MultiChain, οι έξοδοι μπορούν να περιέχουν στοιχεία ή/και δεδομένα σε JSON, κείμενο ή δυαδική μορφή. Οι κανόνες ορίζονται σε "φίλτρα συναλλαγών" ή "φίλτρα ροής", τα οποία μπορούν να ρυθμιστούν για έλεγχο όλων των συναλλαγών ή μόνο εκείνων που αφορούν συγκεκριμένα στοιχεία ή ομαδοποιήσεις δεδομένων. Αντίθετα, μια «κατάσταση» εξόδου Corda αντιπροσωπεύεται από ένα αντικείμενο στη γλώσσα προγραμματισμού Java ή Kotlin, με καθορισμένα πεδία δεδομένων. Οι κανόνες του Corda ορίζονται σε «συμβάσεις» που συνδέονται με συγκεκριμένα κράτη και η σύμβαση ενός κράτους εφαρμόζεται μόνο σε συναλλαγές που περιέχουν αυτήν την κατάσταση στις εισροές ή τις εκροές του. Αυτό σχετίζεται με το Corda's ασυνήθιστο μοντέλο ορατότητας, στις οποίες οι συναλλαγές μπορούν να δουν μόνο οι αντισυμβαλλόμενοί τους ή εκείνοι των οποίων επηρεάζουν τις μεταγενέστερες συναλλαγές.

Συμβάσεις και μηνύματα

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

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

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

Παραδείγματα κανόνων

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

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

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

Στο μοντέλο σύμβασης – μηνύματος, η σύμβαση του στοιχείου υποστηρίζει ένα μήνυμα «αποστολή πληρωμής», το οποίο λαμβάνει τρεις παραμέτρους: τη διεύθυνση του αποστολέα, τη διεύθυνση του παραλήπτη και την ποσότητα που θα σταλεί. Σε απάντηση, η σύμβαση εκτελεί τα ακόλουθα τέσσερα βήματα:

1. Βεβαιωθείτε ότι η συναλλαγή υπογράφηκε από τον αποστολέα.
2. Ελέγξτε ότι ο αποστολέας έχει επαρκή χρήματα.
3. Αφαιρέστε τη ζητούμενη ποσότητα από τη σειρά του αποστολέα.
4. Προσθέστε αυτήν την ποσότητα στη σειρά του παραλήπτη.

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

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

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

Ενσωματωμένοι κανόνες

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

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

Κατά την ανάπτυξη μιας εφαρμογής σε MultiChain, είναι δυνατό να αγνοήσετε αυτήν την ενσωματωμένη λειτουργία και να εκφράσετε κανόνες συναλλαγής χρησιμοποιώντας μόνο έξυπνα φίλτρα. Ωστόσο, τα έξυπνα φίλτρα έχουν σχεδιαστεί για να συνεργάζονται με τις ενσωματωμένες αφαιρέσεις τους, επιτρέποντας την προεπιλεγμένη συμπεριφορά τους περιορισμένος με εξατομικευμένους τρόπους. Για παράδειγμα, η άδεια για ορισμένες δραστηριότητες μπορεί να ελέγχεται από συγκεκριμένους διαχειριστές και όχι από την προεπιλεγμένη συμπεριφορά που θα κάνει οποιοσδήποτε διαχειριστής. Η μεταβίβαση ορισμένων περιουσιακών στοιχείων μπορεί να περιοριστεί χρονικά ή να απαιτήσει πρόσθετη έγκριση πάνω από ένα ορισμένο ποσό. Τα δεδομένα σε μια συγκεκριμένη ροή μπορούν να επικυρωθούν για να διασφαλιστεί ότι αποτελούνται μόνο από δομές JSON με απαιτούμενα πεδία και τιμές.

Σε όλες αυτές τις περιπτώσεις, τα έξυπνα φίλτρα δημιουργούν πρόσθετες απαιτήσεις για την επικύρωση των συναλλαγών, αλλά δεν το κάνουν αφαιρέστε Οι απλοί κανόνες που είναι ενσωματωμένοι. Αυτό μπορεί να βοηθήσει στην αντιμετώπιση μιας από τις βασικές προκλήσεις στις εφαρμογές blockchain: το γεγονός ότι ένα σφάλμα σε κάποιον κώδικα εντός της αλυσίδας μπορεί να οδηγήσει σε καταστροφικές συνέπειες. Έχουμε δει άπειρα παραδείγματα αυτού του προβλήματος στη δημόσια αλυσίδα μπλοκ Ethereum, το πιο διάσημο στο Demise of The DAO και την Σφάλματα πολλαπλών υπογραφών ισοτιμίας. Ευρύτερες έρευνες έχουν βρει έναν μεγάλο αριθμό κοινών τρωτών σημείων στα έξυπνα συμβόλαια Ethereum που επιτρέπουν στους εισβολείς να κλέψουν ή να παγώσουν τα κεφάλαια άλλων ανθρώπων.

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

Κανόνες συναλλαγών	Ύφασμα	Πολυαλυσίδα	Ethereum	σκοινί
Μοντέλο	Συμβόλαιο – μήνυμα	Εισόδου-εξόδου	Συμβόλαιο – μήνυμα	Εισόδου-εξόδου
Ενσωματωμένα	Κανένας	Άδειες + περιουσιακά στοιχεία + ροές	Κανένας	Κανένας

Αιτιοκρατία

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

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

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

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

Πηγές μη ντετερμινισμού

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

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

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

Ντετερμινιστική εκτέλεση

Ας ξεκινήσουμε με το Ethereum, αφού η προσέγγισή του είναι η πιο «καθαρή». Τα συμβόλαια Ethereum εκφράζονται σε μια μορφή ειδικού σκοπού που ονομάζεται "Ethereum bytecode", η οποία εκτελείται από την εικονική μηχανή Ethereum ("EVM"). Οι προγραμματιστές δεν γράφουν απευθείας bytecode, αλλά τον δημιουργούν ή τον «μεταγλωττίζουν» από μια γλώσσα προγραμματισμού που μοιάζει με JavaScript που ονομάζεται Solidity. (Κάποτε ήταν διαθέσιμες άλλες γλώσσες, αλλά έκτοτε έχουν καταργηθεί.) Ο ντετερμινισμός είναι εγγυημένος από το γεγονός ότι ο bytecode Solidity και Ethereum δεν μπορούν να κωδικοποιήσουν καμία μη ντετερμινιστική πράξη – είναι τόσο απλό.

Τα φίλτρα MultiChain και τα συμβόλαια Corda επιλέγουν μια διαφορετική προσέγγιση, προσαρμόζοντας υπάρχουσες γλώσσες προγραμματισμού και περιβάλλοντα χρόνου εκτέλεσης. Το MultiChain χρησιμοποιεί JavaScript που εκτελείται στο Google V8 κινητήρα, που αποτελεί επίσης τον πυρήνα του προγράμματος περιήγησης Chrome και της πλατφόρμας Node.js, αλλά με πηγές μη ντετερμινισμού απενεργοποιημένες. Ομοίως, το Corda χρησιμοποιεί Java ή Κοτλίν, και τα δύο μεταγλωττίζονται σε "Java bytecode" που εκτελείται σε μια εικονική μηχανή Java ("JVM"). Προς το παρόν, η Corda χρησιμοποιεί το τυπικό μη ντετερμινιστικό JVM της Oracle, αλλά βρίσκονται σε εξέλιξη εργασίες για την ενσωμάτωση ενός ντετερμινιστική εκδοχή. Στο μεταξύ, οι προγραμματιστές συμβάσεων Corda πρέπει να φροντίσουν να μην επιτρέψουν τον μη ντετερμινισμό στον κώδικά τους.

Πώς συγκρίνεται ο καθαρισμός του Ethereum με την εξελικτική προσέγγιση των MultiChain και Corda; Το κύριο πλεονέκτημα για το Ethereum είναι η ελαχιστοποίηση του κινδύνου – μια εικονική μηχανή που έχει σχεδιαστεί για συγκεκριμένο σκοπό είναι λιγότερο πιθανό να περιέχει μια ακούσια πηγή μη ντετερμινισμού. Αν και οποιαδήποτε τέτοια παράβλεψη θα μπορούσε να διορθωθεί με μια ενημέρωση λογισμικού, θα ήταν αναστάτωση σε οποιαδήποτε αλυσίδα που είχε την τύχη να την αντιμετωπίσει. Το πρόβλημα του Ethereum, ωστόσο, είναι ότι το Solidity και το EVM αποτελούν ένα μικροσκοπικό και εκκολαπτόμενο οικοσύστημα στο ευρύτερο πλαίσιο των γλωσσών προγραμματισμού και των περιβαλλόντων χρόνου εκτέλεσης. Συγκριτικά, η JavaScript και η Java είναι τα δύο κορυφαίες γλώσσες στο Github, τρέχουν σε δισεκατομμύρια ψηφιακές συσκευές και έχουν χρόνους εκτέλεσης που έχουν βελτιστοποιηθεί εδώ και δεκαετίες. Πιθανώς αυτός είναι ο λόγος για τον οποίο το δημόσιο blockchain Ethereum εξετάζει το ενδεχόμενο μετάβασης σε eWASM, μια ντετερμινιστική διχάλα του αναδυόμενου προτύπου WebAssembly.

Ντετερμινισμός με επικύρωση

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

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

Για να διευκρινιστεί η διαφορά, ο ντετερμινισμός στις περισσότερες πλατφόρμες blockchain βασίζεται στην ερώτηση: "Ποιο είναι το αποτέλεσμα της εκτέλεσης αυτού του κώδικα σε αυτά τα δεδομένα;" – και πρέπει να είμαστε απολύτως βέβαιοι ότι κάθε κόμβος θα απαντήσει σε αυτήν την ερώτηση πανομοιότυπα. Αντίθετα, ο ντετερμινισμός στο Fabric βασίζεται σε μια διαφορετική ερώτηση: «Συμφωνούν αρκετοί υποστηρικτές σχετικά με το αποτέλεσμα της εκτέλεσης αυτού του κώδικα σε αυτά τα δεδομένα;» Η απάντηση σε αυτό είναι ένα μάλλον απλό θέμα μέτρησης και δεν υπάρχει περιθώριο να εισχωρήσει ο μη-ντετερμινισμός.

Ο ντετερμινισμός του Fabric έχει μια σειρά από ενδιαφέρουσες συνέπειες. Πρώτον, ο αλυσιδωτός κώδικας μπορεί να γραφτεί σε πολλές διαφορετικές γλώσσες προγραμματισμού, καθώς αυτές δεν χρειάζεται να προσαρμοστούν για ντετερμινισμό (προς το παρόν υποστηρίζονται οι Go, Java και JavaScript). Δεύτερον, ο αλυσιδωτός κώδικας μπορεί να κρυφτεί από ορισμένους από τους συμμετέχοντες σε μια αλυσίδα μπλοκ, καθώς χρειάζεται να εκτελεστεί μόνο από πελάτες και υποστηρικτές (η ίδια η βάση δεδομένων είναι παγκοσμίως ορατή). Τέλος και πιο αξιοσημείωτο, το Fabric chaincode μπορεί να κάνει πράγματα που απαγορεύονται σε άλλα περιβάλλοντα blockchain, όπως τον έλεγχο του καιρού χρησιμοποιώντας ένα διαδικτυακό API web. Στη χειρότερη περίπτωση, όπου κάθε υποστηρικτής λαμβάνει διαφορετική απάντηση από αυτό το API, ο πελάτης θα αποτύχει να λάβει αρκετές εγκρίσεις για οποιοδήποτε συγκεκριμένο αποτέλεσμα και δεν θα πραγματοποιηθεί καμία συναλλαγή. (Θα πρέπει να σημειωθεί ότι τα μέλη της ομάδας Fabric εξακολουθούν να συνιστώ χρησιμοποιώντας ντετερμινιστική λογική μέσα στον αλυσιδωτό κώδικα, προκειμένου να αποφευχθούν εκπλήξεις.)

Τι τιμή πληρώνει η Fabric για αυτήν την ευελιξία; Εάν ο σκοπός ενός blockchain είναι να αφαιρέσει τους μεσάζοντες από μια κοινή εφαρμογή που βασίζεται σε βάση δεδομένων, τότε η εξάρτηση της Fabric από τους υποστηρικτές κάνει ένα μεγάλο βήμα μακριά από αυτόν τον στόχο. Για τους συμμετέχοντες στην αλυσίδα, δεν αρκεί πλέον να ακολουθούν τους κανόνες του chaincode – χρειάζονται επίσης ορισμένους άλλους κόμβους για να συμφωνήσουν ότι το έχουν κάνει. Ακόμη χειρότερα, ένα κακόβουλο υποσύνολο εγκριτών θα μπορούσε να εγκρίνει αλλαγές στη βάση δεδομένων που δεν ακολουθούν καθόλου τον αλυσιδωτό κώδικα. Αυτό δίνει στους υποστηρικτές πολύ περισσότερη δύναμη από τους επικυρωτές σε κανονικές αλυσίδες μπλοκ, οι οποίοι μπορούν να λογοκρίνουν τις συναλλαγές αλλά δεν μπορούν να παραβιάζουν τους κανόνες του blockchain. Οι προγραμματιστές εφαρμογών Blockchain πρέπει να αποφασίσουν εάν αυτή η ανταλλαγή έχει νόημα στη συγκεκριμένη περίπτωσή τους.

Αιτιοκρατία	Ύφασμα	Πολυαλυσίδα	Ethereum	σκοινί
Μοντέλο	Εγκρίσεις	Προσαρμοσμένος χρόνος εκτέλεσης	Σκοπός VM	Προσαρμοσμένος χρόνος εκτέλεσης
Γλώσσες	Μετάβαση + Java + JavaScript	το JavaScript	Στερεότητα	Java + Kotlin
Ορατότητα κώδικα	Αντισυμβαλλόμενοι + υποστηρικτές	Blockchain	Blockchain	Αντισυμβαλλόμενοι + εξαρτώμενα άτομα
Επιβολή	Οχι	Ναι	Ναι	Όχι (προς το παρόν)

Πρόληψη συγκρούσεων

Μέχρι στιγμής, έχουμε συζητήσει πώς διαφορετικές πλατφόρμες blockchain εκφράζουν κανόνες συναλλαγής σε κώδικα και πώς διασφαλίζουν ντετερμινιστικά ότι κάθε κόμβος εφαρμόζει αυτούς τους κανόνες με τον ίδιο τρόπο. Τώρα ήρθε η ώρα να μιλήσουμε για μια τρίτη πτυχή της αναμέτρησής μας: Πώς αντιμετωπίζει κάθε πλατφόρμα την πιθανότητα δύο συναλλαγές, που είναι έγκυρες από μόνες τους, να συγκρούονται μεταξύ τους; Στο απλούστερο παράδειγμα, φανταστείτε ότι η Alice έχει 10 $ σε ένα οικονομικό καθολικό και μεταδίδει δύο συναλλαγές – η μία στέλνει 8 $ στον Bob και η άλλη στέλνει 7 $ στον Charlie. Σαφώς, μόνο μία από αυτές τις συναλλαγές μπορεί να επιτραπεί να πετύχει.

Δύο μοντέλα

Μπορούμε να ξεκινήσουμε ομαδοποιώντας την προσέγγιση της MultiChain και της Corda σε αυτό το πρόβλημα μαζί. Όπως περιγράφηκε προηγουμένως, και τα δύο χρησιμοποιούν ένα μοντέλο εισόδου-εξόδου για την αναπαράσταση των συναλλαγών και των κανόνων τους, στο οποίο κάθε είσοδος συναλλαγής ξοδεύει μια προηγούμενη έξοδο συναλλαγής. Αυτό οδηγεί σε μια απλή αρχή για την αποφυγή συγκρούσεων: Κάθε προϊόν μπορεί να δαπανηθεί μόνο μία φορά. Τα φίλτρα MultiChain και τα συμβόλαια Corda μπορούν να βασίζονται στις αντίστοιχες πλατφόρμες τους για την απόλυτη επιβολή αυτού του περιορισμού. Δεδομένου ότι τα 10 $ της Alice αντιπροσωπεύονται από μια προηγούμενη έξοδο συναλλαγής, αυτός ο κανόνας μιας δαπάνης σταματά αυτόματα να τα στέλνει τόσο στον Bob όσο και στον Charlie.

Παρά αυτή την ομοιότητα, είναι σημαντικό να επισημανθεί μια βασική διαφορά στον τρόπο με τον οποίο το MultiChain και το Corda αποτρέπουν τις συγκρούσεις. Στο MultiChain, κάθε κόμβος βλέπει κάθε συναλλαγή και έτσι μπορεί ανεξάρτητα να επαληθεύσει ότι κάθε έξοδος ξοδεύεται μόνο μία φορά. Οποιαδήποτε συναλλαγή που πραγματοποιεί διπλή δαπάνη έναντι μιας προηγουμένως επιβεβαιωμένης συναλλαγής θα απορρίπτεται άμεσα και αυτόματα. Αντίθετα, στο Corda δεν υπάρχει παγκόσμιο blockchain, επομένως απαιτείται από τους «συμβολαιογράφους» να αποτρέψουν αυτές τις διπλές δαπάνες. Κάθε κατάσταση εξόδου Corda εκχωρείται σε συμβολαιογράφο, ο οποίος πρέπει να υπογράψει κάθε συναλλαγή που δαπανά αυτή την έξοδο, επιβεβαιώνοντας ότι δεν έχει δαπανηθεί στο παρελθόν. Οι συμμετέχοντες σε ένα blockchain πρέπει να εμπιστεύονται τους συμβολαιογράφους για να ακολουθήσουν αυτόν τον κανόνα με ειλικρίνεια και οι κακόβουλοι συμβολαιογράφοι μπορούν να προκαλέσουν όλεθρο κατά βούληση. Όπως και με τις εγκρίσεις στο Fabric, αυτό το "μεμονωμένη δαπάνη ως υπηρεσίαΟ σχεδιασμός έχει πλεονεκτήματα όσον αφορά την εμπιστευτικότητα, αλλά επαναφέρει τους μεσάζοντες, αντίθετα με τον κόκκο του blockchain. (Είναι σημαντικό να διευκρινιστεί ότι οι συμβολαιογράφοι της Corda μπορούν να διοικούνται από ομάδες συμμετεχόντων χρησιμοποιώντας έναν αλγόριθμο συναίνεσης, έτσι ώστε η ακεραιότητα του καθολικού να μπορεί ακόμα να προστατεύεται από μεμονωμένους κακούς παράγοντες).

Ας προχωρήσουμε στο Ethereum. Για να θυμηθούμε, το Ethereum χρησιμοποιεί συμβόλαια και μηνύματα παρά εισόδους και εξόδους. Ως αποτέλεσμα, οι συγκρούσεις συναλλαγών, όπως οι δύο πληρωμές της Alice, δεν είναι άμεσα ορατές στη μηχανή blockchain. Αντίθετα, εντοπίζονται και αποκλείονται από το σύμβαση που διεκπεραιώνει τις συναλλαγές, αφού επιβεβαιωθεί η παραγγελία τους στην αλυσίδα. Κατά την επεξεργασία κάθε πληρωμής της Αλίκης, το συμβόλαιο επαληθεύει αν το υπόλοιπό της είναι επαρκές. Εάν η συναλλαγή που πληρώνει $8 στον Bob είναι πρώτη, θα διεκπεραιωθεί ως συνήθως, αφήνοντας την Alice με $2 στον λογαριασμό της. Ως αποτέλεσμα, όταν το συμβόλαιο επεξεργάζεται τη δεύτερη συναλλαγή πληρώνοντας 7 $ στον Τσάρλι, βλέπει ότι η Αλίκη δεν έχει τα απαραίτητα κεφάλαια και η συναλλαγή ματαιώνεται.

Εκροές έναντι συμβάσεων

Μέχρι στιγμής έχουμε δει δύο διαφορετικές τεχνικές για την αποτροπή αντικρουόμενων συναλλαγών – εξόδους μίας δαπάνης στο MultiChain και Corda και επαλήθευση βάσει συμβάσεων στο Ethereum. Ποιο είναι λοιπόν καλύτερο;

Προκειμένου να απαντήσουμε σε αυτήν την ερώτηση, ας εξετάσουμε ένα παράδειγμα λογαριασμού "1-από-2 πολλαπλών υπογραφών" που κατέχει $100 για λογαριασμό του Gavin και της Helen και επιτρέπει σε έναν από τους δύο να ξοδέψει αυτά τα χρήματα ανεξάρτητα. Ο Γκάβιν δίνει εντολή στην αίτησή του να πληρώσει 80 δολάρια στη Ντόνα και λίγα δευτερόλεπτα αργότερα, η Έλεν θέλει να στείλει 40 δολάρια στον Έντουαρντ. Δεδομένου ότι δεν υπάρχουν επαρκή κεφάλαια και για τις δύο πληρωμές, αυτές οι συναλλαγές αναπόφευκτα θα συγκρούονταν. Σε περίπτωση που μεταδίδονται και οι δύο συναλλαγές, το αποτέλεσμα θα καθοριστεί από όποιον μπει πρώτο στην αλυσίδα. Σημειώστε ότι σε αντίθεση με το παράδειγμα της Αλίκης, αυτή η σύγκρουση είναι λάθος, αφού κανείς δεν προσπαθεί να παραβιάσει τους κανόνες της εφαρμογής – απλώς είχαν άτυχο timing.

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

Με το μοντέλο εισόδου-εξόδου, οποιαδήποτε σύγκρουση μεταξύ των συναλλαγών είναι άμεσα ορατή στην πλατφόρμα blockchain, καθώς οι δύο συναλλαγές θα επιχειρούν ρητά να ξοδέψουν την ίδια προηγούμενη έξοδο. Στο MultiChain, αυτό συμβαίνει μόλις η συναλλαγή του Gavin έχει διαδοθεί στον κόμβο της Helen, συνήθως σε ένα δευτερόλεπτο ή λιγότερο. Στην Corda, ο συμβολαιογράφος του output θα αρνηθεί το αίτημα να υπογράψει τη συναλλαγή της Helen, αφού έχει ήδη υπογράψει τη συναλλαγή του Gavin, οπότε η Helen θα καταλάβει αμέσως ότι η πληρωμή της θα αποτύχει. (Αν και ο συμβολαιογράφος της Corda διανεμηθεί ο ίδιος, μπορεί να χρειαστεί να περιμένει μερικά δευτερόλεπτα για μια απάντηση.) Είτε έτσι είτε αλλιώς, δεν χρειάζεται να περιμένετε να επιβεβαιωθεί και να παραγγελθεί μια συναλλαγή στο blockchain.

Τι γίνεται με το μοντέλο του Ethereum; Σε αυτήν την περίπτωση, δεν υπάρχει άμεσος τρόπος για την πλατφόρμα blockchain να γνωρίζει ότι θα προκύψει μια σύγκρουση. Ενώ ο κόμβος της Helen μπορεί να δει τη συναλλαγή του Gavin στο δίκτυο, δεν μπορεί να γνωρίζει πώς αυτό θα επηρεάσει τη συναλλαγή της ίδιας της Helen, αφού από την σκοπιά του αυτά είναι απλώς δύο μηνύματα που αποστέλλονται στο ίδιο συμβόλαιο. Ίσως δέκα δευτερόλεπτα αργότερα, μόλις επιβεβαιωθεί η τελική παραγγελία των αντικρουόμενων συναλλαγών στο blockchain, ο κόμβος της Helen θα υπολογίσει εκ νέου το πραγματικό αντί για το αναμενόμενο αποτέλεσμα και η εφαρμογή της θα ενημερώσει την οθόνη του ανάλογα. Στο μεταξύ, τόσο ο Γκάβιν όσο και η Έλεν θα μείνουν στο σκοτάδι.

Αλλά δεν πρέπει να συμπεράνουμε από αυτό ότι το μοντέλο εισόδου-εξόδου λειτουργεί πάντα καλύτερα. Εξετάστε μια παραλλαγή του παραδείγματος σεναρίου μας, όπου τόσο ο Gavin όσο και η Helen ζητούν μικρότερες πληρωμές 40 $ από το αρχικό υπόλοιπο των 100 $, ακριβώς την ίδια στιγμή. Στο μοντέλο εισόδου-εξόδου, αυτές οι συναλλαγές θα μπορούσαν να έρθουν σε διένεξη, καθώς και οι δύο ξοδεύουν την ίδια σειρά βάσης δεδομένων που περιέχει αυτά τα $100 και μόνο μία από τις πληρωμές θα πετύχαινε. Αλλά στο Ethereum, και οι δύο συναλλαγές θα διεκπεραιώνονται με επιτυχία, ανεξάρτητα από την τελική τους παραγγελία, καθώς ο λογαριασμός περιέχει επαρκή κεφάλαια και για τα δύο. Σε αυτή την περίπτωση, το Ethereum εκπληρώνει πιο πιστά τις προθέσεις του Gavin και της Helen.

Σύνολα ανάγνωσης-εγγραφής

Τέλος, ας μιλήσουμε για το Fabric, του οποίου η προσέγγιση που βασίζεται στην έγκριση είναι ένα υβρίδιο αυτών των δύο τεχνικών. Όπως εξηγήθηκε προηγουμένως, όταν ένας κόμβος «πελάτη» Fabric θέλει να στείλει ένα μήνυμα σε ένα συμβόλαιο, ζητά πρώτα από ορισμένους κόμβους έγκρισης να εκτελέσουν αυτό το μήνυμα για λογαριασμό του. Οι κόμβοι επικύρωσης το κάνουν με παρόμοιο τρόπο με το Ethereum – εκτελώντας το συμβόλαιο έναντι της τοπικής βάσης δεδομένων τους – αλλά αυτή η διαδικασία παρατηρείται αντί να εφαρμόζεται αμέσως. Κάθε υποστηρικτής καταγράφει το σύνολο των σειρών που θα διαβάζονταν και θα γράφονταν, σημειώνοντας επίσης την ακριβή έκδοση αυτών των σειρών σε αυτό το χρονικό σημείο. Αυτό το "σύνολο ανάγνωσης-εγγραφής" σειρών με έκδοση αναφέρεται ρητά στην έγκριση και περιλαμβάνεται στη συναλλαγή που μεταδίδει ο πελάτης.

Οι διενέξεις μεταξύ των συναλλαγών Fabric επιλύονται μόλις οριστικοποιηθεί η παραγγελία τους στην αλυσίδα. Κάθε κόμβος επεξεργάζεται κάθε συναλλαγή ανεξάρτητα, ελέγχοντας τις πολιτικές έγκρισης και εφαρμόζοντας τις καθορισμένες αλλαγές της βάσης δεδομένων. Ωστόσο, εάν μια συναλλαγή διαβάζει ή γράφει μια έκδοση σειράς βάσης δεδομένων που έχει ήδη τροποποιηθεί από προηγούμενη συναλλαγή, τότε αυτή η δεύτερη συναλλαγή αγνοείται. Για να επιστρέψετε στις αντικρουόμενες πληρωμές της Alice στον Bob και τον Charlie, και οι δύο αυτές συναλλαγές θα διαβάσουν και θα τροποποιήσουν την ίδια έκδοση σειράς, που περιέχει τα $10 με τα οποία ξεκίνησε η Alice. Έτσι η δεύτερη συναλλαγή θα ματαιωθεί με ασφάλεια και αυτόματα.

Η προσέγγιση της Fabric στην επίλυση συγκρούσεων λειτουργεί μια χαρά, αλλά από άποψη απόδοσης και ευελιξίας συνδυάζει τα χειρότερα από τα δύο προηγούμενα μοντέλα. Επειδή οι εγκρίσεις μετατρέπουν τις συναλλαγές σε συγκεκριμένα σύνολα ανάγνωσης-εγγραφής, οι ταυτόχρονες αλλά συμβατές πληρωμές 40 $ του Gavin και της Helen θα οδηγούσαν σε μια σύγκρουση που το Ethereum αποφεύγει. Ωστόσο, η Fabric δεν κερδίζει το πλεονέκτημα της ταχύτητας του μοντέλου εισόδου-εξόδου, καθώς οι υποστηρικτές εκτελούν συμβόλαια έναντι της πιο πρόσφατης έκδοσης της βάσης δεδομένων που επιβεβαιώνεται από το blockchain, αγνοώντας τις μη επιβεβαιωμένες συναλλαγές. Έτσι, εάν η Helen ξεκινήσει την πληρωμή της λίγα δευτερόλεπτα μετά τον Gavin, αλλά πριν επιβεβαιωθεί η πληρωμή του Gavin στο blockchain, η Fabric θα δημιουργήσει αντικρουόμενες συναλλαγές που αποφεύγει ένα καθαρό μοντέλο εισόδου-εξόδου.

Πρόληψη συγκρούσεων	Ύφασμα	Πολυαλυσίδα	Ethereum	σκοινί
Μοντέλο	Σύνολα ανάγνωσης-εγγραφής	Ενιαία δαπάνη	Έλεγχοι συμβολαίων	Ενιαία δαπάνη
Επαλήθευση	Ανεξάρτητος	Ανεξάρτητος	Ανεξάρτητος	Αξιόπιστοι συμβολαιογράφοι
Ταχύτητα	~10s (επιβεβαίωση)	~1s (διάδοση)	~10s (επιβεβαίωση)	0~5s (συμβολαιογράφος)

Μια σύνθετη επιλογή

Σε αυτό το κομμάτι, εξετάσαμε πολλούς από τους διαφορετικούς τρόπους με τους οποίους το Corda, το Ethereum, το Fabric και το MultiChain αντιμετωπίζουν τις βασικές προκλήσεις των «έξυπνων συμβολαίων» ή του κώδικα εφαρμογής που είναι ενσωματωμένος σε μια αλυσίδα μπλοκ. Και κάθε πλατφόρμα έχει διαφορετικές απαντήσεις στις τρεις βασικές μας ερωτήσεις: Πώς αντιπροσωπεύονται οι κανόνες συναλλαγών; Πώς εκτελείται ο κώδικας ντετερμινιστικά; Και πώς προλαμβάνουμε τις συγκρούσεις;

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

Παρακαλώ δημοσιεύστε τυχόν σχόλια στο LinkedIn.