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

[Σωτήρης Νιάρχος]

Καλησπέρα!
Έχουμε πολλές απορίες που μας εμποδίζουν να προχωρήσουμε την εργασία,
κυρίως σχετικά με το κομμάτι του 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);

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

3) Εν τέλει, ποιο είναι το νόημα του consensus στο noobcoin από τη στιγμή
που (α) όλοι δημιουργούν ΑΚΡΙΒΩΣ τα ίδια blocks με ΑΚΡΙΒΩΣ τις ίδιες
συναλλαγές και (β) εάν μιλάμε για αλυσίδα μεγαλύτερου μήκους, εκ των
πραγμάτων δεν μιλάμε για 51% consensus, αφού αρκεί ένας από τους κόμβους να
μας δώσει τη μεγαλύτερη αλυσίδα;

4) Κατά την εκτέλεση της resolve_conflict() δεν θα πρέπει να παίρνουμε και
blockchains από τους άλλους, εκτός από το μήκος τους; Εάν ναι, τότε δεν θα
πρέπει και εδώ να καλείται η validate_chain() κάθε φορά (στην εκφώνηση
αναφέρετε ότι καλείται μόνο κατά την είσοδο ενός κόμβου στο δίκτυο);

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

6) Το timestamp των blocks πρέπει να αντιπροσωπεύει την στιγμή (α) που το
block αρχίζει να γίνεται mine (οπότε και θα περιέχεται στο hash) ή (β) όταν
θα μπει στο blockchain, οπότε εκ των πραγμάτων δεν θα μπορεί να περιέχεται
στο hash (αλλά θα φέρει πιο ακριβή πληροφορία ως προς το πότε ένα σύνολο
συναλλαγών θεωρήθηκε έγκυρο και μέρος του blockchain);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cslab.ece.ntua.gr/pipermail/distrib/attachments/20190305/39165393/attachment.htm>