Εισαγωγή

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Όπως και με την ιδέα ενός απολύτως ισχυρού κρυπτογράφησης από κρυπτογραφία, τα πραγματικά πρωτόκολλα «Publicly Verifiable Random Beacon» (εφεξής PVRB) προσπαθούν να προσεγγίσουν όσο το δυνατόν περισσότερο το ιδανικό σχήμα, επειδή σε πραγματικά δίκτυα δεν ισχύει στην καθαρή του μορφή: είναι απαραίτητο να συμφωνήσετε αυστηρά σε ένα κομμάτι, πρέπει να υπάρχουν πολλοί γύροι και όλα τα μηνύματα πρέπει να είναι τέλεια γρήγορα και να παραδίδονται πάντα. Φυσικά, αυτό δεν συμβαίνει στα πραγματικά δίκτυα. Επομένως, όταν σχεδιάζουμε PVRB για συγκεκριμένες εργασίες σε σύγχρονες αλυσίδες μπλοκ, εκτός από την αδυναμία ελέγχου της προκύπτουσας τυχαιότητας και κρυπτογραφικής ισχύος, προκύπτουν πολλά ακόμη καθαρά αρχιτεκτονικά και τεχνικά προβλήματα.

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

Δύο τρόποι εφαρμογής PVRB

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

Αυτόνομη σύμβαση

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

Η επιλογή με αυτόνομο συμβόλαιο είναι καλή:

• φορητότητα (τα συμβόλαια μπορούν να συρθούν από blockchain σε blockchain)
• ευκολία υλοποίησης και δοκιμής (τα συμβόλαια είναι εύκολο να γραφτούν και να δοκιμαστούν)
• ευκολία στην εφαρμογή οικονομικών προγραμμάτων (είναι εύκολο να φτιάξετε το δικό σας διακριτικό, του οποίου η λογική εξυπηρετεί τους σκοπούς του PVRB)
• δυνατότητα εκκίνησης σε μπλοκ που ήδη λειτουργούν

Έχει επίσης μειονεκτήματα:

• ισχυροί περιορισμοί στους υπολογιστικούς πόρους, τον όγκο συναλλαγών και την αποθήκευση (με άλλα λόγια, cpu/mem/io)
• περιορισμοί στις λειτουργίες εντός της σύμβασης (δεν είναι διαθέσιμες όλες οι οδηγίες, είναι δύσκολο να συνδεθούν εξωτερικές βιβλιοθήκες)
• αδυναμία οργάνωσης των μηνυμάτων γρηγορότερα από ό,τι οι συναλλαγές περιλαμβάνονται στο blockchain

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

Ολοκληρωμένη συναίνεση

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

Κατά την περιγραφή των εφαρμογών PVRB σε επίπεδο συναίνεσης δικτύου, δεν μπορεί κανείς με κανέναν τρόπο να αποφύγει ζητήματα οριστικού χαρακτήρα. Το τελικό είναι ένας μηχανισμός που χρησιμοποιείται σε ντετερμινιστικές συναινέσεις που κλειδώνει σε ένα μπλοκ (και την αλυσίδα που οδηγεί σε αυτό) που είναι τελικό και δεν θα πεταχτεί ποτέ, ακόμα κι αν συμβεί παράλληλη διχάλα. Για παράδειγμα, στο Bitcoin δεν υπάρχει τέτοιος μηχανισμός - εάν δημοσιεύσετε μια αλυσίδα μεγαλύτερης πολυπλοκότητας, θα αντικαταστήσει οποιαδήποτε λιγότερο περίπλοκη, ανεξάρτητα από το μήκος των αλυσίδων. Και στο EOS, για παράδειγμα, τα τελικά είναι τα λεγόμενα Last Irreversible Blocks, τα οποία εμφανίζονται κατά μέσο όρο κάθε 432 μπλοκ (12*21 + 12*15, pre-vote + pre-commit). Αυτή η διαδικασία ουσιαστικά περιμένει τις υπογραφές των 2/3 των μπλοκ-παραγωγών (εφεξής καλούμενες BP). Όταν εμφανίζονται πιρούνια που είναι παλαιότερα από το τελευταίο LIB, απλώς απορρίπτονται. Αυτός ο μηχανισμός καθιστά δυνατή τη διασφάλιση ότι η συναλλαγή περιλαμβάνεται στο blockchain και δεν θα επαναφερθεί ποτέ, ανεξάρτητα από τους πόρους που διαθέτει ο εισβολέας. Επίσης, τα τελικά μπλοκ είναι μπλοκ υπογεγραμμένα από 2/3 BP σε Hyperledger, Tendermint και άλλες συναινέσεις που βασίζονται στο pBFT. Επίσης, είναι λογικό να γίνει ένα πρωτόκολλο για τη διασφάλιση της τελικότητας ως πρόσθετο στη συναίνεση, καθώς μπορεί να λειτουργεί ασύγχρονα με την παραγωγή και τη δημοσίευση μπλοκ. Εδώ είναι ένα καλό άρθρο σχετικά με την οριστικότητα στο Ethereum.

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

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

Η ενσωματωμένη με συναίνεση επιλογή είναι καλή:

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

Έχει επίσης μειονεκτήματα:

• Δυσκολίες στη δοκιμή και την ανάπτυξη - θα πρέπει να μιμηθούν σφάλματα δικτύου, κόμβους που λείπουν, σκληρά πιρούνια δικτύου
• Τα σφάλματα υλοποίησης απαιτούν hardfork δικτύου

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

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

Μεταβλητές PVRB και μπλοκ.

Δεν είπα ψέματα όταν είπα ότι κανείς δεν έχει εφαρμόσει ακόμη ένα καλό PVRB, δοκιμασμένο από πολλές εφαρμογές τζόγου, σε blockchains. Τότε από πού προέρχονται τόσες πολλές εφαρμογές τζόγου στο Ethereum και στο EOS; Αυτό με εκπλήσσει όσο και εσένα, από πού βρήκαν τόσα «επίμονα» τυχαία σε ένα εντελώς ντετερμινιστικό περιβάλλον;

Ο αγαπημένος τρόπος για να αποκτήσετε τυχαιότητα στο blockchain είναι να πάρετε κάποιο είδος «απρόβλεπτης» πληροφορίας από το μπλοκ και να δημιουργήσετε μια τυχαία με βάση αυτό - απλώς κατακερματίζοντας μία ή περισσότερες τιμές. Καλό άρθρο για τα προβλήματα τέτοιων συστημάτων εδώ. Μπορείτε να λάβετε οποιαδήποτε από τις «απρόβλεπτες» τιμές στο μπλοκ, για παράδειγμα, τον κατακερματισμό του μπλοκ, τον αριθμό των συναλλαγών, την πολυπλοκότητα του δικτύου και άλλες τιμές άγνωστες εκ των προτέρων. Στη συνέχεια, κατακερματίστε τα, ένα ή περισσότερα, και, θεωρητικά, θα πρέπει να πάρετε ένα πραγματικό τυχαίο. Μπορείτε ακόμη και να προσθέσετε στο wihitepaper ότι το σχέδιό σας είναι "μετα-κβαντικά ασφαλές" (καθώς υπάρχουν συναρτήσεις κατακερματισμού με κβαντική προστασία :)).

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

1. Το αποτέλεσμα πρέπει να έχει αποδεδειγμένα ομοιόμορφη κατανομή, δηλαδή να βασίζεται σε αποδεδειγμένα ισχυρή κρυπτογραφία.
2. Δεν είναι δυνατός ο έλεγχος κανενός από τα κομμάτια του αποτελέσματος. Κατά συνέπεια, το αποτέλεσμα δεν μπορεί να προβλεφθεί εκ των προτέρων.
3. Δεν μπορείτε να σαμποτάρετε το πρωτόκολλο δημιουργίας μη συμμετέχοντας στο πρωτόκολλο ή υπερφορτώνοντας το δίκτυο με μηνύματα επίθεσης
4. Όλα τα παραπάνω πρέπει να είναι ανθεκτικά στη συμπαιγνία ενός επιτρεπτού αριθμού ανέντιμων συμμετεχόντων στο πρωτόκολλο (για παράδειγμα, το 1/3 των συμμετεχόντων).

Σε αυτήν την περίπτωση, ικανοποιείται μόνο η απαίτηση 1 και η απαίτηση 2 δεν ικανοποιείται. Κατακερματίζοντας απρόβλεπτες τιμές από το μπλοκ, θα έχουμε ομοιόμορφη κατανομή και καλές τυχαίες τιμές. Αλλά η BP έχει τουλάχιστον την επιλογή «να δημοσιεύσει το μπλοκ ή όχι». Έτσι, η BP μπορεί τουλάχιστον να επιλέξει από ΔΥΟ τυχαίες επιλογές: «τη δική της» και αυτή που θα αποδειχθεί εάν κάποιος άλλος κάνει το μπλοκ. Η BP μπορεί να «κατασκοπεύσει» εκ των προτέρων τι θα συμβεί εάν δημοσιεύσει ένα μπλοκ και απλώς αποφασίσει να το κάνει ή όχι. Έτσι, όταν παίζει, για παράδειγμα, «ζυγός-μονός» ή «κόκκινο/μαύρο» στη ρουλέτα, μπορεί να δημοσιεύσει ένα μπλοκ μόνο αν δει μια νίκη. Αυτό καθιστά επίσης αδύνατη τη στρατηγική χρήσης, για παράδειγμα, ενός κατακερματισμού μπλοκ "από το μέλλον". Σε αυτήν την περίπτωση, λένε ότι «θα χρησιμοποιηθεί τυχαία, η οποία προκύπτει με κατακερματισμό των τρεχόντων δεδομένων και του κατακερματισμού ενός μελλοντικού μπλοκ με ύψος, για παράδειγμα, N + 42, όπου N είναι το τρέχον ύψος μπλοκ. Αυτό ενισχύει λίγο το σύστημα, αλλά εξακολουθεί να επιτρέπει στην BP, αν και στο μέλλον, να επιλέξει αν θα κρατήσει το μπλοκ ή θα δημοσιεύσει.

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

Έτσι, οι μέθοδοι που χρησιμοποιούν πληροφορίες από το μπλοκ δεν είναι κατάλληλες ως καθολική υλοποίηση του PVRB. Σε μια περιορισμένη έκδοση, με περιορισμούς στα μεγέθη στοιχημάτων, περιορισμούς στον αριθμό των παικτών ή/και εγγραφή KYC (για να αποτρέψετε έναν παίκτη από τη χρήση πολλαπλών διευθύνσεων), αυτά τα σχήματα μπορούν να λειτουργήσουν για μικρά παιχνίδια, αλλά τίποτα περισσότερο.

PVRB και δέσμευση-αποκάλυψη.

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

Ένα αφελές σχήμα, όταν οι χρήστες στέλνουν απλώς τυχαίους αριθμούς και το αποτέλεσμα υπολογίζεται, για παράδειγμα, ως κατακερματισμός του αθροίσματος τους, δεν είναι κατάλληλο. Σε αυτή την περίπτωση, ο τελευταίος παίκτης μπορεί, επιλέγοντας το δικό του τυχαίο, να ελέγξει ποιο θα είναι το αποτέλεσμα. Αυτός είναι ο λόγος για τον οποίο χρησιμοποιείται το πολύ ευρέως χρησιμοποιούμενο μοτίβο δέσμευσης-αποκάλυψης. Οι συμμετέχοντες στέλνουν πρώτα hashes από τα τυχαία τους (commits) και μετά ανοίγουν οι ίδιοι τα τυχαία (αποκαλύπτει). Η φάση «αποκάλυψης» ξεκινά μόνο αφού συγκεντρωθούν οι απαραίτητες δεσμεύσεις, ώστε οι συμμετέχοντες να μπορούν να στείλουν ακριβώς τον τυχαίο κατακερματισμό από τον οποίο έστειλαν νωρίτερα. Τώρα ας τα βάλουμε όλα αυτά μαζί με τις παραμέτρους ενός μπλοκ, και καλύτερα από ένα που λαμβάνεται από το μέλλον (η τυχαιότητα μπορεί να βρεθεί μόνο σε ένα από τα μελλοντικά μπλοκ) και voila - η τυχαιότητα είναι έτοιμη! Τώρα οποιοσδήποτε παίκτης επηρεάζει την προκύπτουσα τυχαιότητα και μπορεί να «νικήσει» το κακόβουλο BP παρακάμπτοντάς το με τη δική του, άγνωστη εκ των προτέρων, τυχαιότητα... Μπορείτε επίσης να προσθέσετε προστασία από την υπονόμευση του πρωτοκόλλου μη ανοίγοντάς το στο στάδιο της αποκάλυψης - απλά με την απαίτηση να επισυναφθεί ένα ορισμένο ποσό στη συναλλαγή κατά τη δέσμευση — μια εγγύηση, η οποία θα επιστραφεί μόνο κατά τη διαδικασία αποκάλυψης. Σε αυτή την περίπτωση, η δέσμευση και η μη αποκάλυψη θα είναι ασύμφορη.

Ήταν μια καλή προσπάθεια, και τέτοια σχήματα υπάρχουν και στα gaming DApps, αλλά δυστυχώς, αυτό και πάλι δεν είναι αρκετό. Τώρα όχι μόνο ο εξορύκτης, αλλά και οποιοσδήποτε συμμετέχων στο πρωτόκολλο μπορεί να επηρεάσει το αποτέλεσμα. Είναι ακόμα δυνατός ο έλεγχος της ίδιας της τιμής, με λιγότερη μεταβλητότητα και με κόστος, αλλά, όπως στην περίπτωση του εξορύκτη, εάν τα αποτελέσματα της κλήρωσης είναι πιο πολύτιμα από το τέλος συμμετοχής στο πρωτόκολλο PVRB, τότε το τυχαίο -Ο παραγωγός (RP) μπορεί να αποφασίσει αν θα αποκαλύψει και μπορεί να επιλέξει από τουλάχιστον δύο τυχαίες επιλογές.
Αλλά κατέστη δυνατό να τιμωρηθούν όσοι διαπράττουν και δεν αποκαλύπτουν, και αυτό το σχέδιο θα είναι χρήσιμο. Η απλότητά του είναι ένα σοβαρό πλεονέκτημα - πιο σοβαρά πρωτόκολλα απαιτούν πολύ πιο ισχυρούς υπολογισμούς.

PVRB και ντετερμινιστικές υπογραφές.

Υπάρχει ένας άλλος τρόπος για να αναγκάσετε το RP να παρέχει έναν ψευδοτυχαίο αριθμό που δεν μπορεί να επηρεάσει εάν του παρέχεται μια «προεικόνα» - αυτή είναι μια ντετερμινιστική υπογραφή. Μια τέτοια υπογραφή είναι, για παράδειγμα, RSA και δεν είναι ECS. Εάν το RP έχει ένα ζεύγος κλειδιών: RSA και ECC, και υπογράφει μια συγκεκριμένη τιμή με το ιδιωτικό του κλειδί, τότε στην περίπτωση του RSA θα έχει ΜΙΑ ΚΑΙ ΜΟΝΟ ΜΙΑ υπογραφή και στην περίπτωση του ECS μπορεί να δημιουργήσει οποιονδήποτε αριθμό διαφορετικές έγκυρες υπογραφές. Αυτό συμβαίνει επειδή κατά τη δημιουργία μιας υπογραφής ECS, χρησιμοποιείται ένας τυχαίος αριθμός, που επιλέγεται από τον υπογράφοντα, και μπορεί να επιλεγεί με οποιονδήποτε τρόπο, δίνοντας στον υπογράφοντα την ευκαιρία να επιλέξει μία από τις πολλές υπογραφές. Στην περίπτωση του RSA: «μία τιμή εισόδου» + «ένα ζεύγος κλειδιών» = «μία υπογραφή». Είναι αδύνατο να προβλεφθεί τι υπογραφή θα έχει ένα άλλο RP, επομένως ένα PVRB με ντετερμινιστικές υπογραφές μπορεί να οργανωθεί συνδυάζοντας τις υπογραφές RSA πολλών συμμετεχόντων που υπέγραψαν την ίδια τιμή. Για παράδειγμα, το προηγούμενο τυχαίο. Αυτό το σχήμα εξοικονομεί πολλούς πόρους, γιατί Οι υπογραφές είναι ταυτόχρονα επιβεβαίωση της σωστής συμπεριφοράς σύμφωνα με το πρωτόκολλο και πηγή τυχαίας.

Ωστόσο, ακόμη και με ντετερμινιστικές υπογραφές, το σύστημα εξακολουθεί να είναι ευάλωτο στο πρόβλημα του «τελευταίου παράγοντα». Ο τελευταίος συμμετέχων μπορεί να αποφασίσει αν θα δημοσιεύσει την υπογραφή ή όχι, ελέγχοντας έτσι το αποτέλεσμα. Μπορείτε να τροποποιήσετε το σχήμα, να προσθέσετε κατακερματισμούς μπλοκ σε αυτό, να κάνετε κύκλους έτσι ώστε το αποτέλεσμα να μην μπορεί να προβλεφθεί εκ των προτέρων, αλλά όλες αυτές οι τεχνικές, ακόμη και λαμβάνοντας υπόψη πολλές τροποποιήσεις, εξακολουθούν να αφήνουν άλυτο το πρόβλημα της επιρροής ενός συμμετέχοντος στη συλλογικότητα έχει ως αποτέλεσμα ένα μη αξιόπιστο περιβάλλον και μπορεί να λειτουργήσει μόνο υπό οικονομικούς και χρονικούς περιορισμούς. Επιπλέον, το μέγεθος των κλειδιών RSA (1024 και 2048 bit) είναι αρκετά μεγάλο και το μέγεθος για τις συναλλαγές blockchain είναι μια εξαιρετικά σημαντική παράμετρος. Προφανώς δεν υπάρχει απλός τρόπος να λυθεί το πρόβλημα, ας προχωρήσουμε.

PVRB και συστήματα κοινής χρήσης μυστικών

Στην κρυπτογραφία, υπάρχουν σχήματα που μπορούν να επιτρέψουν στο δίκτυο να συμφωνήσει σε μία και μόνο τιμή PVRB, ενώ τέτοια σχήματα είναι ανθεκτικά σε τυχόν κακόβουλες ενέργειες ορισμένων συμμετεχόντων. Ένα χρήσιμο πρωτόκολλο με το οποίο αξίζει να εξοικειωθείτε είναι το μυστικό σχέδιο κοινής χρήσης του Shamir. Χρησιμεύει για να χωρίσει ένα μυστικό (για παράδειγμα, ένα μυστικό κλειδί) σε πολλά μέρη και να διανείμει αυτά τα μέρη σε N συμμετέχοντες. Το μυστικό διανέμεται με τέτοιο τρόπο ώστε M μέρη από το Ν να είναι αρκετά για να το ανακτήσουν, και αυτά μπορεί να είναι οποιαδήποτε M μέρη. Εάν βρίσκονται στα δάχτυλα, τότε έχοντας ένα γράφημα μιας άγνωστης συνάρτησης, οι συμμετέχοντες ανταλλάσσουν πόντους στο γράφημα και αφού λάβουν πόντους M, ολόκληρη η λειτουργία μπορεί να αποκατασταθεί.
Δίνεται μια καλή εξήγηση wiki αλλά το να παίζετε με αυτό πρακτικά για να παίξετε το πρωτόκολλο στο κεφάλι σας είναι χρήσιμο για διαδήλωση σελίδα.

Εάν το σύστημα FSSS (Fiat-Shamir Secret Sharing) ήταν εφαρμόσιμο στην καθαρή του μορφή, θα ήταν ένα άφθαρτο PVRB. Στην απλούστερη μορφή του, το πρωτόκολλο μπορεί να μοιάζει με αυτό:

• Κάθε συμμετέχων δημιουργεί το δικό του τυχαίο και διανέμει μερίδια από αυτό σε άλλους συμμετέχοντες
• Κάθε συμμετέχων αποκαλύπτει το μέρος του από τα μυστικά των άλλων συμμετεχόντων
• Εάν ένας συμμετέχων έχει περισσότερες από M μετοχές, τότε ο αριθμός αυτού του συμμετέχοντος μπορεί να υπολογιστεί και θα είναι μοναδικός, ανεξάρτητα από το σύνολο των αποκαλυφθέντων συμμετεχόντων
• Ο συνδυασμός των αποκαλυπτόμενων τυχαίων είναι το επιθυμητό PVRB

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

Αυτή θα μπορούσε να είναι μια ιδανική επιλογή, αυτό το σχήμα PVRB που βασίζεται στην κοινή χρήση μυστικών Fiat-Shamir περιγράφεται για παράδειγμα στο αυτό άρθρο. Αλλά, όπως αναφέρθηκε παραπάνω, αν προσπαθήσετε να το εφαρμόσετε κατά μέτωπο στο blockchain, εμφανίζονται τεχνικοί περιορισμοί. Ακολουθεί ένα παράδειγμα δοκιμαστικής εφαρμογής του πρωτοκόλλου στο έξυπνο συμβόλαιο EOS και το πιο σημαντικό μέρος του - έλεγχος του δημοσιευμένου συμμετέχοντος κοινής χρήσης: κώδικας. Μπορείτε να δείτε από τον κώδικα ότι η επικύρωση απόδειξης απαιτεί αρκετούς βαθμωτούς πολλαπλασιασμούς και οι αριθμοί που χρησιμοποιούνται είναι πολύ μεγάλοι. Πρέπει να γίνει κατανοητό ότι στις αλυσίδες μπλοκ, η επαλήθευση συμβαίνει τη στιγμή που ο παραγωγός μπλοκ επεξεργάζεται τη συναλλαγή και γενικά, οποιοσδήποτε συμμετέχων πρέπει να επαληθεύει εύκολα την ορθότητα του πρωτοκόλλου, επομένως οι απαιτήσεις για την ταχύτητα της λειτουργίας επαλήθευσης είναι πολύ σοβαρές . Σε αυτήν την επιλογή, η επιλογή αποδείχθηκε αναποτελεσματική, καθώς η επαλήθευση δεν χωρούσε εντός του ορίου συναλλαγής (0.5 δευτερόλεπτα).

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

PVRB και υπογραφές κατωφλίου

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

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

Το τελευταίο άρθρο περιγράφει τις υπογραφές BLS (το BLS σημαίνει Boneh-Lynn-Sacham, εδώ άρθρο), τα οποία έχουν μια πολύ σημαντική και εξαιρετικά βολική ποιότητα για προγραμματιστές - δημόσια, μυστικά, δημόσια κλειδιά και υπογραφές BLS μπορούν να συνδυαστούν μεταξύ τους χρησιμοποιώντας απλές μαθηματικές πράξεις, ενώ οι συνδυασμοί τους παραμένουν έγκυρα κλειδιά και υπογραφές, επιτρέποντάς σας να συγκεντρώνετε εύκολα πολλά υπογραφές σε ένα και πολλά δημόσια κλειδιά σε ένα. Είναι επίσης ντετερμινιστικά και παράγουν το ίδιο αποτέλεσμα για τα ίδια δεδομένα εισόδου. Χάρη σε αυτήν την ποιότητα, οι συνδυασμοί υπογραφών BLS είναι οι ίδιοι έγκυρα κλειδιά, γεγονός που επιτρέπει την εφαρμογή μιας επιλογής στην οποία ο Μ από τους Ν συμμετέχοντες παράγει μία και μόνο μία υπογραφή που είναι ντετερμινιστική, δημόσια επαληθεύσιμη και απρόβλεπτη έως ότου ανοίξει από το Mth συμμετέχων .

Σε ένα σχήμα με υπογραφές κατωφλίου BLS, κάθε συμμετέχων υπογράφει κάτι χρησιμοποιώντας το BLS (για παράδειγμα, το προηγούμενο τυχαίο) και η κοινή υπογραφή κατωφλίου είναι η επιθυμητή τυχαία. Οι κρυπτογραφικές ιδιότητες των υπογραφών BLS ικανοποιούν τις απαιτήσεις για τυχαία ποιότητα, το τμήμα κατωφλίου προστατεύει από τον "τελευταίο παράγοντα" και η μοναδική συνδυαστικότητα των κλειδιών καθιστά δυνατή την εφαρμογή πολλών πιο ενδιαφέρων αλγορίθμων που επιτρέπουν, για παράδειγμα, αποτελεσματική συγκέντρωση μηνυμάτων πρωτοκόλλου .

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

Εφαρμογή PVRB

Δυστυχώς, ακόμα δεν βλέπουμε έτοιμο πρωτόκολλο να εφαρμόζεται σε blockchains PVRB που να έχει αποδείξει την ασφάλεια και τη σταθερότητά του. Παρόλο που τα ίδια τα πρωτόκολλα είναι έτοιμα, η τεχνική εφαρμογή τους σε υπάρχουσες λύσεις δεν είναι εύκολη. Για τα κεντρικά συστήματα, τα PVRB δεν έχουν νόημα και τα αποκεντρωμένα είναι αυστηρά περιορισμένα σε όλους τους υπολογιστικούς πόρους: CPU, μνήμη, αποθήκευση, I/O. Ο σχεδιασμός ενός PVRB είναι ένας συνδυασμός διαφορετικών πρωτοκόλλων προκειμένου να δημιουργηθεί κάτι που να πληροί όλες τις απαιτήσεις για τουλάχιστον κάποιο βιώσιμο blockchain. Το ένα πρωτόκολλο υπολογίζει πιο αποτελεσματικά, αλλά απαιτεί περισσότερα μηνύματα μεταξύ των RP, ενώ το άλλο απαιτεί πολύ λίγα μηνύματα, αλλά η δημιουργία μιας απόδειξης μπορεί να είναι μια εργασία που διαρκεί δεκάδες λεπτά ή ακόμα και ώρες.

Θα απαριθμήσω τους παράγοντες που θα πρέπει να λάβετε υπόψη όταν επιλέγετε ένα ποιοτικό PVRB:

• Κρυπτογραφική δύναμη. Το PVRB σας πρέπει να είναι αυστηρά αμερόληπτο, χωρίς δυνατότητα ελέγχου ούτε ενός bit. Σε ορισμένα σχήματα αυτό δεν συμβαίνει, οπότε καλέστε έναν κρυπτογράφο
• Το πρόβλημα του «τελευταίου ηθοποιού».. Το PVRB σας πρέπει να είναι ανθεκτικό σε επιθέσεις όπου ένας εισβολέας που ελέγχει ένα ή περισσότερα RP μπορεί να επιλέξει ένα από τα δύο αποτελέσματα.
• Πρόβλημα σαμποτάζ πρωτοκόλλου. Το PVRB σας πρέπει να είναι ανθεκτικό σε επιθέσεις όπου ένας εισβολέας που ελέγχει ένα ή περισσότερα RP αποφασίζει εάν θα είναι τυχαίο ή όχι και μπορεί είτε να είναι εγγυημένο είτε με δεδομένη πιθανότητα να επηρεάσει αυτό
• Πρόβλημα με αριθμό μηνυμάτων. Οι RP σας θα πρέπει να στέλνουν ελάχιστα μηνύματα στο blockchain και να αποφεύγουν όσο το δυνατόν περισσότερο τις σύγχρονες ενέργειες, όπως καταστάσεις όπως "Έστειλα κάποιες πληροφορίες, περιμένω απάντηση από έναν συγκεκριμένο συμμετέχοντα". Σε δίκτυα p2p, ειδικά σε γεωγραφικά διασκορπισμένα, δεν πρέπει να υπολογίζετε σε γρήγορη απόκριση
• Το πρόβλημα της υπολογιστικής πολυπλοκότητας. Η επαλήθευση οποιουδήποτε σταδίου του PVRB on-chain θα πρέπει να είναι εξαιρετικά εύκολη, καθώς εκτελείται από όλους τους πλήρεις πελάτες του δικτύου. Εάν η υλοποίηση γίνεται με χρήση έξυπνου συμβολαίου, τότε οι απαιτήσεις ταχύτητας είναι πολύ αυστηρές
• Το πρόβλημα της προσβασιμότητας και της ζωντάνιας. Το PVRB σας θα πρέπει να προσπαθεί να είναι ανθεκτικό σε καταστάσεις όπου μέρος του δικτύου καθίσταται μη διαθέσιμο για κάποιο χρονικό διάστημα και μέρος του RP απλώς σταματά να λειτουργεί
• Το πρόβλημα της αξιόπιστης εγκατάστασης και της αρχικής διανομής κλειδιών. Εάν το PVRB σας χρησιμοποιεί την κύρια ρύθμιση του πρωτοκόλλου, τότε αυτή είναι μια ξεχωριστή μεγάλη και σοβαρή ιστορία. Εδώ παράδειγμα. Εάν οι συμμετέχοντες πρέπει να πουν ο ένας στον άλλο τα κλειδιά τους πριν ξεκινήσουν το πρωτόκολλο, αυτό είναι επίσης πρόβλημα εάν αλλάξει η σύνθεση των συμμετεχόντων
• Αναπτυξιακά θέματα. Διαθεσιμότητα βιβλιοθηκών στις απαιτούμενες γλώσσες, ασφάλεια και απόδοσή τους, δημοσιότητα, σύνθετες δοκιμές κ.λπ.

Για παράδειγμα, οι υπογραφές κατωφλίου BLS έχουν ένα σημαντικό πρόβλημα - πριν ξεκινήσουν να εργάζονται, οι συμμετέχοντες πρέπει να διανείμουν κλειδιά ο ένας στον άλλο, οργανώνοντας μια ομάδα εντός της οποίας θα λειτουργήσει το όριο. Αυτό σημαίνει ότι τουλάχιστον ένας γύρος ανταλλαγής σε ένα αποκεντρωμένο δίκτυο θα πρέπει να περιμένει, και δεδομένου ότι το παραγόμενο rand, για παράδειγμα, είναι απαραίτητο στα παιχνίδια, σχεδόν σε πραγματικό χρόνο, αυτό σημαίνει ότι είναι δυνατή η δολιοφθορά του πρωτοκόλλου σε αυτό το στάδιο , και τα πλεονεκτήματα του συστήματος κατωφλίου χάνονται. Αυτό το πρόβλημα είναι ήδη απλούστερο από τα προηγούμενα, αλλά εξακολουθεί να απαιτεί την ανάπτυξη μιας ξεχωριστής διαδικασίας για το σχηματισμό ομάδων κατωφλίου, οι οποίες θα πρέπει να προστατευθούν οικονομικά, μέσω καταθέσεων και ανάληψης κεφαλαίων (slashing) από συμμετέχοντες που δεν ακολουθούν πρωτόκολλο. Επίσης, η επαλήθευση BLS με αποδεκτό επίπεδο ασφάλειας απλά δεν ταιριάζει, για παράδειγμα, σε μια τυπική συναλλαγή EOS ή Ethereum - απλά δεν υπάρχει αρκετός χρόνος για επαλήθευση. Ο κωδικός σύμβασης είναι WebAssembly ή EVM, που εκτελείται από μια εικονική μηχανή. Οι κρυπτογραφικές συναρτήσεις δεν έχουν εφαρμοστεί εγγενώς (ακόμη) και λειτουργούν δεκάδες φορές πιο αργά από τις συμβατικές κρυπτογραφικές βιβλιοθήκες. Πολλά πρωτόκολλα δεν πληρούν τις απαιτήσεις απλώς με βάση τον όγκο των κλειδιών, για παράδειγμα 1024 και 2048 bit για RSA, 4-8 φορές μεγαλύτερα από την τυπική υπογραφή συναλλαγής στο Bitcoin και στο Ethereum.

Ρόλο παίζει και η παρουσία υλοποιήσεων σε διαφορετικές γλώσσες προγραμματισμού - από τις οποίες υπάρχουν λίγες, ειδικά για νέα πρωτόκολλα. Η επιλογή με την ενσωμάτωση στη συναίνεση απαιτεί τη σύνταξη ενός πρωτοκόλλου στη γλώσσα της πλατφόρμας, επομένως θα πρέπει να αναζητήσετε κώδικα στο Go for geth, στο Rust για Parity, στο C++ για EOS. Όλοι θα πρέπει να ψάξουν για κώδικα JavaScript και δεδομένου ότι η JavaScript και η κρυπτογραφία δεν είναι ιδιαίτερα στενοί φίλοι, το WebAssembly θα βοηθήσει, το οποίο πλέον ισχυρίζεται ότι είναι το επόμενο σημαντικό πρότυπο Διαδικτύου.

Συμπέρασμα

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

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

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

Έτσι, όταν συναντάτε έναν προγραμματιστή που σχεδιάζει αποκεντρωμένα τυχαία, να είστε προσεκτικοί και προσεκτικοί και παρέχετε ψυχολογική βοήθεια εάν είναι απαραίτητο :)

Πηγή: www.habr.com