Skip to main content

Page last updated: 11 Αυγούστου 2024

Statelessness, λήξη κατάστασης και ιστορικού

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

Σήμερα, οι υψηλές απαιτήσεις για χώρο στο δίσκο, είναι το κύριο εμπόδιο που εμποδίζει την παγκόσμια πρόσβαση στους κόμβους. Αυτό οφείλεται κυρίως στην ανάγκη αποθήκευσης μεγάλων τμημάτων των δεδομένων κατάστασης του Ethereum. Αυτά τα δεδομένα κατάστασης περιέχουν κρίσιμες πληροφορίες που απαιτούνται για τη σωστή επεξεργασία νέων μπλοκ και συναλλαγών. Αυτή τη στιγμή, συνιστάται ένας γρήγορος 2TB SSD για την εκτέλεση ενός πλήρους κόμβου Ethereum. Για έναν κόμβο που δεν περικόπτει παλαιότερα δεδομένα, η απαίτηση σε αποθηκευτικό χώρο αυξάνεται περίπου στα 14GB ανά εβδομάδα και οι κόμβοι αρχειοθέτησης που αποθηκεύουν όλα τα δεδομένα από τη στιγμή της γένεσης, πλησιάζει τα 12 TB (Φεβρουάριος 2023).

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

Μείωση αποθηκευτικού χώρου κόμβων

Υπάρχουν διάφοροι τρόποι μείωσης του όγκου των δεδομένων που κάθε κόμβος πρέπει να αποθηκεύσει, όπου για τον καθένα απαιτείται ενημέρωση του βασικού πρωτοκόλλου Ethereum σε διαφορετικό βαθμό:

  • Λήξη ιστορικού (History expiry): Επιτρέπει στους κόμβους να απορρίπτουν δεδομένα κατάστασης παλαιότερα από Χ μπλοκ, αλλά δεν αλλάζει τον τρόπο με τον οποίο χειρίζεται τα δεδομένα κατάστασης ο πελάτης Ethereum.
  • Λήξη κατάστασης (State expiry): Επιτρέπει στα δεδομένα κατάστασης που δε χρησιμοποιούνται συχνά να χαρακτηριστούν ανενεργά. Τα ανενεργά δεδομένα μπορούν να αγνοηθούν από τους πελάτες μέχρι την επόμενη χρήση τους.
  • Ασθενής λειτουργία χωρίς κατάσταση (Weak statelessness): Μόνο οι παραγωγοί μπλοκ χρειάζονται πρόσβαση σε δεδομένα πλήρους κατάστασης καθώς οι υπόλοιποι κόμβοι μπορούν να επαληθεύσουν μπλοκ χωρίς τοπική βάση των δεδομένων κατάστασης.
  • Ισχυρή λειτουργία χωρίς κατάσταση (Strong statelessness): Κανένας κόμβος δε χρειάζεται πρόσβαση στα πλήρη δεδομένα κατάστασης.

Λήξη δεδομένων

Λήξη ιστορικού

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

Μια επιλογή είναι οι πελάτες να ζητούν δεδομένα ιστορικού από ομοτίμους χρησιμοποιώντας μια λύση όπως το Δίκτυο Portal. Το Δίκτυο Portal είναι ένα υπό ανάπτυξη δίκτυο peer-to-peer για την εξυπηρέτηση δεδομένων ιστορικού, όπου κάθε κόμβος αποθηκεύει ένα μικρό κομμάτι της ιστορίας του Ethereum έτσι ώστε ολόκληρο το ιστορικό να υπάρχει κατανεμημένο σε όλο το δίκτυο. Τα αιτήματα εξυπηρετούνται αναζητώντας ομοτίμους που αποθηκεύουν τα σχετικά δεδομένα και ζητώντας τα από αυτούς. Εναλλακτικά, δεδομένου ότι οι εφαρμογές απαιτείται να έχουν πρόσβαση σε δεδομένα ιστορικού, μπορεί να είναι δική τους ευθύνη να τα αποθηκεύσουν. Μπορεί επίσης να υπάρχουν αρκετά αλτρουιστικά άτομα στον χώρο του Ethereum που θα ήταν πρόθυμοι να διατηρήσουν ιστορικά αρχεία. Θα μπορούσε να είναι ένα DAO που ενδιαφέρεται για τη διαχείριση της αποθήκευσης δεδομένων ιστορικού ή ιδανικά ένας συνδυασμός όλων αυτών των επιλογών. Αυτοί οι πάροχοι θα μπορούσαν να εξυπηρετήσουν τα δεδομένα με πολλούς τρόπους, όπως σε ένα torrent, FTP, Filecoin ή IPFS.

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

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

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

Λήξη κατάστασης

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

  • Λήξη με ενοικίαση (Expire by rent): Χρέωση σε λογαριασμούς με «ενοίκιο» και λήξη όταν το ενοίκιο τους μηδενιστεί.
  • Χρονική λήξη (Expire by time): Χαρακτηρίζοντας λογαριασμούς ανενεργούς εάν δεν υπάρχει ανάγνωση/εγγραφή για κάποιο χρονικό διάστημα.

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

Ο τρόπος με τον οποίο θα λειτουργούσε αυτό είναι πιθανώς να έχετε ένα δέντρο κατάστασης για συγκεκριμένες χρονικές περιόδους (ίσως ~ 1 έτος). Κάθε φορά που ξεκινά μια νέα περίοδος, κάνει το ίδιο και ένα νέο δέντρο κατάστασης. Μόνο το τρέχον δέντρο κατάστασης μπορεί να τροποποιηθεί, όλα τα άλλα είναι αμετάβλητα. Οι κόμβοι Ethereum αναμένεται να διατηρούν μόνο το τρέχον δέντρο κατάστασης και το επόμενο πιο πρόσφατο. Αυτό απαιτεί έναν τρόπο για τη χρονική σήμανση μιας διεύθυνσης με την περίοδο στην οποία υπάρχει. Υπάρχουν διάφοροι πιθανοί τρόποιopens in a new tab για να γίνει αυτό, αλλά η κύρια επιλογή απαιτεί επιμήκυνση των διευθύνσεωνopens in a new tab για να χωρέσουν οι πρόσθετες πληροφορίες με το πλεονέκτημα ότι οι μεγαλύτερες διευθύνσεις είναι πολύ πιο ασφαλείς. Το στοιχείο του οδικού χάρτη που το εφαρμόζει ονομάζεται επέκταση χώρου διεύθυνσηςopens in a new tab.

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

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

Statelessness

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

  • Σχεδόν άμεσο συγχρονισμό.
  • Δυνατότητα επικύρωσης μπλοκ εκτός σειράς.
  • Κόμβοι που μπορούν να εκτελούνται με πολύ χαμηλές απαιτήσεις υλικού (π.χ. σε τηλέφωνα).
  • Οι κόμβοι μπορούν να εκτελούνται από φθηνούς σκληρούς δίσκους επειδή δεν απαιτείται ανάγνωση/εγγραφή δίσκου.
  • Συμβατότητα με μελλοντικές αναβαθμίσεις στην κρυπτογράφηση του Ethereum.

Ασθενής λειτουργία χωρίς κατάσταση

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

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

Για να συμβεί αυτό, τα Verkle trees πρέπει να έχουν ήδη εφαρμοστεί σε πελάτες Ethereum. Τα δέντρα Verkle είναι μια δομή δεδομένων αντικατάστασης για την αποθήκευση δεδομένων κατάστασης Ethereum που επιτρέπουν σε μικρού μεγέθους "μάρτυρες" στα δεδομένα να διαβιβάζονται μεταξύ ομοτίμων και να χρησιμοποιούνται για την επαλήθευση μπλοκ αντί για επαλήθευση μπλοκ σε τοπικές βάσεις δεδομένων. Ο διαχωρισμός πρωτείνοντος - δημιουργού απαιτείται επειδή επιτρέπει στους δημιουργούς μπλοκ να είναι εξειδικευμένοι κόμβοι με πιο ισχυρό υλικό και αυτοί είναι που απαιτούν πρόσβαση στα πλήρη δεδομένα κατάστασης.

Οι προτείνοντες μπλοκ χρησιμοποιούν τα δεδομένα κατάστασης για να δημιουργήσουν "μάρτυρες", το ελάχιστο σύνολο δεδομένων που αποδεικνύουν τις αξίες της κατάστασης που αλλάζουν από τις συναλλαγές σε ένα μπλοκ. Άλλα προγράμματα επικύρωσης δε διατηρούν την κατάσταση, αποθηκεύουν μόνο το root κατάστασης (ένα hash ολόκληρης της κατάστασης). Λαμβάνουν ένα μπλοκ και έναν μάρτυρα και τα χρησιμοποιούν για να ενημερώσουν το root κατάστασης τους. Αυτό κάνει έναν κόμβο επικύρωσης εξαιρετικά ελαφρύ.

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

Ισχυρή λειτουργία χωρίς κατάσταση

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

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

Τρέχουσα πρόοδος

Η ασθενής λειτουργία χωρίς κατάσταση, η λήξη του ιστορικού και η λήξη κατάστασης βρίσκονται όλα στη φάση της έρευνας και αναμένεται να είναι έτοιμα σε αρκετά χρόνια από τώρα. Δεν υπάρχει καμία εγγύηση ότι όλες αυτές οι προτάσεις θα εφαρμοστούν, για παράδειγμα εάν πρώτα εφαρμοστεί η λήξη της κατάστασης, ενδέχεται να μη χρειάζεται να εφαρμοστεί και η λήξη ιστορικού. Υπάρχουν επίσης άλλα στοιχεία οδικού χάρτη ανάπτυξης, όπως τα Verkle Trees και Proposer-builder separation που πρέπει να ολοκληρωθούν πρώτα.

Περισσότερες πληροφορίες

Page last update: 11 Αυγούστου 2024

Ήταν χρήσιμο αυτό το άρθρο;