[Distrib] (Πολλές) απορίες για την εργασία

[Katerina Doka]

Καλημέρα,

απαντάω in line

On Tue, Mar 5, 2019 at 1:08 AM Σωτήρης Νιάρχος <sot.niarchos at gmail.com>
wrote:

> Καλησπέρα!
> Έχουμε πολλές απορίες που μας εμποδίζουν να προχωρήσουμε την εργασία,
> κυρίως σχετικά με το κομμάτι του consensus και τον χειρισμό των UTXO:
>
> 1) Δεδομένου του ότι όλοι οι nodes είναι και miners και πως όλοι ακούν όλα
> τα transactions (και κάθε κόμβος/miner βάζει όλα τα transactions στο μπλοκ
> που, όταν ολοκληρωθεί, θα το κάνει mine), όλοι καταλήγουν να κάνουν mine
> ακριβώς τα ίδια blocks, με τα ίδια transactions (θεωρούμε δεδομένο ότι δεν
> χάνονται transactions στο δίκτυο). Αυτό σημαίνει ότι υπάρχει η περίπτωση,
> για παράδειγμα, να συμπληρωθούν "ταυτόχρονα" από όλους τα transactions που
> απαιτούνται για να γίνει mine το πρώτο block. Συνεπώς, αρχίζουν όλοι
> "ταυτόχρονα" να κάνουν mine τα block τους. Τέλος, "ταυτόχρονα" προσθέτουν
> το block που έκαναν mine στο τοπικό τους blockchain και έπειτα το κάνουν
> "ταυτόχρονα" broadcast. Σε αυτήν την περίπτωση, θα βρεθούμε να έχουμε στο
> δίκτυο n διαφορετικές αλυσίδες μήκους 2, με n διαφορετικά δεύτερα blocks
> (το πρώτο είναι το genesis που είναι κοινό). Πώς μπορεί να δουλέψει σε
> αυτήν την περίπτωση το consensus όπως το περιγράφετε στην εκφώνηση, από τη
> στιγμή που δεν υπάρχει αλυσίδα μεγαλύτερου μήκους; Μπορεί να χρειαστεί να
> ασχοληθούμε με threads (ένα thread να ακούει για εισερχόμενα blocks, ένα
> για να κάνει mine);
>

Σε αυτήν τη φάση που περιγράφεις, αν θεωρήσουμε για απλότητα ότι έχει γίνει
fork σε 2 παρακλάδια το chain, αφού δεν υπάρχει μεγαλύτερη αλυσίδα θα
υπάρχουν κάποιοι κόμβοι που θα κάνουν mine στην μία version και κάποιοι που
θα κάνουν mine στην άλλη. Το resolution θα γίνει όταν γίνει mine το επόμενο
block - θα επικρατήσει το παρακλάδι πάνω στο οποίο χτίστηκε το νέο block,
μιας και θα αποκτήσει μεγαλύτερο μέγεθος. Αν πάλι γίνουν ταυτόχρονα mined
νεα blocks και στα 2 παρακλάδια τότε περιμένουμε να δούμε ποιο παρακλάδι θα
επικρατήσει στο επόμενο block mining. Όσο μεγαλώνει το difficulty, τόσο πιο
απίθανο γίνεται να έχουμε μακρά forks. Αν στην περίπτωσή σας δείτε ότι
έχετε πολύ συχνά forks με το δεδομένο difficulty, τότε μπορείτε να
δοκιμάσετε με μεγαλύτερο - εμάς μας έπαιξε καλά για το νούμερο που σας
δώσαμε, αλλά αν δείτε κάτι διαφορετικό μπορείτε να πειραματιστείτε με την
τιμή του difficulty.

>
> 2) Πώς πρέπει να διαχειριστούμε το γεγονός ότι κάποιο block μας μπορεί να
> καταλήξει να γίνει orphaned; Έχει νόημα να διατηρούμε κάποιο transaction
> pool, από τη στιγμή που όλα τα transactions είναι ίδια για όλους (όλοι τα
> ακούνε, όλοι τα κάνουν mine και μάλιστα στα ίδια ακριβώς blocks);
>
Θα μπορούσες να διατηρείς ένα transaction pool για να τσεκάρεις αν υπάρχουν
transactions που έχεις λάβει, τα οποία δεν υπάρχουν στα νέα blocks που
πήρες.

>
> 3) Εν τέλει, ποιο είναι το νόημα του consensus στο noobcoin από τη στιγμή
> που (α) όλοι δημιουργούν ΑΚΡΙΒΩΣ τα ίδια blocks με ΑΚΡΙΒΩΣ τις ίδιες
> συναλλαγές και (β) εάν μιλάμε για αλυσίδα μεγαλύτερου μήκους, εκ των
> πραγμάτων δεν μιλάμε για 51% consensus, αφού αρκεί ένας από τους κόμβους να
> μας δώσει τη μεγαλύτερη αλυσίδα;
>
α) θα μπορούσε να υπάρχει κάποιος κακόβουλος miner που να κάνει mine blocks
με fake transactions, double spending κλπ,  β) Σε πραγματικές συνθήκες δεν
παίρνουν όλοι τα ίδια transactions και με την ίδια σειρά (κόμβοι κρασάρουν,
το latency του δικτύου είναι διαφορετικό σε κάθε ζευγάρι κόμβων, κλπ). Το
51% αναφέρεται σε υπολογιστική ισχύ, όχι στον αριθμό των κόμβων και είναι
είδος attack, όχι είδος consensus. Αν ένας από τους κόμβους έχει πάνω από
το 50% της συνολικής υπολογιστικής ισχύος τότε κάνει mine με πιο γρήγορο
ρυθμό από τους άλλους, άρα φτιάχνει πιο μακριές αλυσίδες, άρα η αλυσίδα του
επικρατεί των υπολοίπων (και μπορεί κι όλας να αλλαξει την ιστορία, να
αλλάξει δλδ προηγούμενα blocks και να προλάβει να τα κάνει mine
δημιουργώντας μεγαλύτερη αλυσίδα).

>
> 4) Κατά την εκτέλεση της resolve_conflict() δεν θα πρέπει να παίρνουμε και
> blockchains από τους άλλους, εκτός από το μήκος τους; Εάν ναι, τότε δεν θα
> πρέπει και εδώ να καλείται η validate_chain() κάθε φορά (στην εκφώνηση
> αναφέρετε ότι καλείται μόνο κατά την είσοδο ενός κόμβου στο δίκτυο);
>
Εξαρτάται από το πώς θα το υλοποιήσεις. Καλύτερα να πάρεις τα blocks που
σου λείπουν σε περίπτωση που δεις ότι υπάρχει conflict και ότι η άλλη
αλυσίδα είναι πιο μακρά (όλο το blockchain θα είναι πολύ μεγάλο για να το
πηγαινοφέρνεις μέσω δικτύου). Σε κάθε block που λαμβάνεις κάνεις validation.

>
> 5) Δεδομένου του ότι τα transaction μας δεν έχουν fees, φαίνεται redundant
> να δημιουργούνται τα transaction outputs κατά τη δημιουργία του (πριν γίνει
> broadcasted), αφού όλοι μπορούν να τα υπολογίσουν όταν το λάβουν και το
> κάνουν validate, όπως περιγράφετε και στην εκφώνηση. Συνεπώς, τα outputs
> φτιάχνονται κατά την validate και το transaction γίνεται broadcasted χωρίς
> αυτά ή φτιάχνονται πριν και περιέχονται στο broadcast; Εάν πούμε ότι
> φτιάχνονται κατά την validate (όπως λέτε ρητά στην εκφώνηση), πότε θα τα
> φτιάξει ο ίδιος ο κόμβος που έφτιαξε το transaction; Πριν κάνει broadcast
> το transaction (που φαίνεται πιο λογικό αλλά πηγαίνει ενάντια στην
> εκφώνηση) ή μετά (το οποιο υποννοεί ότι θα το κάνει broadcast και στον
> εαυτό του για να μπει στη διαδικασία του validation, το οποίο ακούγεται
> χαζό);
>
 Θεωρούμε ότι και ο κόμβος που φτιάχνει το transaction το κάνει validate
πριν το βάλει στο block του. Προφανώς δεν το στέλνει στον εαυτό του μέσω
δικτύου.

>
> 6) Το timestamp των blocks πρέπει να αντιπροσωπεύει την στιγμή (α) που το
> block αρχίζει να γίνεται mine (οπότε και θα περιέχεται στο hash) ή (β) όταν
> θα μπει στο blockchain, οπότε εκ των πραγμάτων δεν θα μπορεί να περιέχεται
> στο hash (αλλά θα φέρει πιο ακριβή πληροφορία ως προς το πότε ένα σύνολο
> συναλλαγών θεωρήθηκε έγκυρο και μέρος του blockchain);
>
Πρέπει να περιέχεται στο hash.

> _______________________________________________
> Distrib mailing list
> Distrib at lists.cslab.ece.ntua.gr
> http://lists.cslab.ece.ntua.gr/mailman/listinfo/distrib
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cslab.ece.ntua.gr/pipermail/distrib/attachments/20190305/5d53a31c/attachment-0001.htm>