<div dir="ltr"><div>Καλησπέρα!<br></div><div>Έχουμε πολλές απορίες που μας εμποδίζουν να προχωρήσουμε την εργασία, κυρίως σχετικά με το κομμάτι του consensus και τον χειρισμό των UTXO:</div><div><br></div><div>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);<br></div><div><br></div><div>2) Πώς πρέπει να διαχειριστούμε το γεγονός ότι κάποιο block μας μπορεί να καταλήξει να γίνει orphaned; Έχει νόημα να διατηρούμε κάποιο transaction pool, από τη στιγμή που όλα τα transactions είναι ίδια για όλους (όλοι τα ακούνε, όλοι τα κάνουν mine και μάλιστα στα ίδια ακριβώς blocks);</div><div><br></div><div>3) Εν τέλει, ποιο είναι το νόημα του consensus στο noobcoin από τη στιγμή που (α) όλοι δημιουργούν ΑΚΡΙΒΩΣ τα ίδια blocks με ΑΚΡΙΒΩΣ τις ίδιες συναλλαγές και (β) εάν μιλάμε για αλυσίδα μεγαλύτερου μήκους, εκ των πραγμάτων δεν μιλάμε για 51% consensus, αφού αρκεί ένας από τους κόμβους να μας δώσει τη μεγαλύτερη αλυσίδα;</div><div><br></div><div>4) Κατά την εκτέλεση της resolve_conflict() δεν θα πρέπει να παίρνουμε και blockchains από τους άλλους, εκτός από το μήκος τους; Εάν ναι, τότε δεν θα πρέπει και εδώ να καλείται η validate_chain() κάθε φορά (στην εκφώνηση αναφέρετε ότι καλείται μόνο κατά την είσοδο ενός κόμβου στο δίκτυο);<br></div><div><br></div><div>5) Δεδομένου του ότι τα transaction μας δεν έχουν fees, φαίνεται redundant να δημιουργούνται τα transaction outputs κατά τη δημιουργία του (πριν γίνει broadcasted), αφού όλοι μπορούν να τα υπολογίσουν όταν το λάβουν και το κάνουν validate, όπως περιγράφετε και στην εκφώνηση. Συνεπώς, τα outputs φτιάχνονται κατά την validate και το transaction γίνεται broadcasted χωρίς αυτά ή φτιάχνονται πριν και περιέχονται στο broadcast; Εάν πούμε ότι φτιάχνονται κατά την validate (όπως λέτε ρητά στην εκφώνηση), πότε θα τα φτιάξει ο ίδιος ο κόμβος που έφτιαξε το transaction; Πριν κάνει broadcast το transaction (που φαίνεται πιο λογικό αλλά πηγαίνει ενάντια στην εκφώνηση) ή μετά (το οποιο υποννοεί ότι θα το κάνει broadcast και στον εαυτό του για να μπει στη διαδικασία του validation, το οποίο ακούγεται χαζό);<br></div><div><br></div><div>6) Το timestamp των blocks πρέπει να αντιπροσωπεύει την στιγμή (α) που το block αρχίζει να γίνεται mine (οπότε και θα περιέχεται στο hash) ή (β) όταν θα μπει στο blockchain, οπότε εκ των πραγμάτων δεν θα μπορεί να περιέχεται στο hash (αλλά θα φέρει πιο ακριβή πληροφορία ως προς το πότε ένα σύνολο συναλλαγών θεωρήθηκε έγκυρο και μέρος του blockchain);<br></div></div>