# Νέα για το DAVINCI: η εργασία δημοσιεύτηκε και ο sequencer τρέχει πλέον στο ZisK

Μόλις δημοσιεύσαμε την εργασία για το DAVINCI στο IACR Cryptology ePrint Archive: [eprint.iacr.org/2026/2282](https://eprint.iacr.org/2026/2282). **Είναι η πρώτη φορά που ολόκληρο το πρωτόκολλο καταγράφεται σε ένα σημείο**, με την ανάλυση ασφάλειας δίπλα σε μια λειτουργική υλοποίηση και σε πραγματικά νούμερα από αυτήν. Ο Pau Escrich την έγραψε μαζί με τη Marta Bellés-Muñoz (Universitat Pompeu Fabra), τον Roger Baig (Universitat Politècnica de Catalunya) και τον Jordi Piñana (Vocdoni).

Αν παρακολουθείτε [αυτό το blog](/blog/davinci-universal-voting-protocol), ξέρετε ήδη την ιδέα: **μια εκλογική διαδικασία είναι ένα ZK rollup**. Οι ψηφοφόροι κρυπτογραφούν τα ψηφοδέλτιά τους, οποιοσδήποτε μπορεί να τρέξει έναν sequencer που τα ομαδοποιεί σε παρτίδες και αποδεικνύει ότι η παρτίδα επεξεργάστηκε σύμφωνα με τους κανόνες, και το Ethereum δέχεται τη νέα κατάσταση της εκλογικής διαδικασίας μόνο αν η απόδειξη επαληθεύεται. Χωρίς απόδειξη δεν υπάρχει ενημέρωση κατάστασης, ούτε πλαστό αποτέλεσμα.

Αυτό που φέρνει καινούργιο η εργασία είναι το τεχνικό σκέλος, και γι' αυτό το κομμάτι μιλά το άρθρο: πώς παράγεται η απόδειξη μιας ψήφου στον περιηγητή ενός κινητού, πώς ο sequencer ξαναγράφτηκε ως πρόγραμμα για το zkVM [ZisK](https://zisk.technology), το precompile που συνεισφέραμε στο ίδιο το ZisK για να γίνει όλο αυτό γρήγορο, και πόσο κοστίζουν όλα αυτά.

## Εν συντομία

- Η εργασία για το DAVINCI είναι δημοσιευμένη στο [eprint.iacr.org/2026/2282](https://eprint.iacr.org/2026/2282).
- Η απόδειξη ενός ψηφοδελτίου παράγεται στον περιηγητή σε **περίπου 3 δευτερόλεπτα σε φορητό υπολογιστή και 6,4 δευτερόλεπτα σε κινητό**.
- Ο sequencer είναι πλέον **ένα ενιαίο πρόγραμμα Rust που αποδεικνύεται από το zkVM ZisK**, αντί για κυκλώματα γραμμένα με το χέρι.
- Συνεισφέραμε ένα **precompile BabyJubJub στο ZisK**, που συγχωνεύτηκε στο κύριο έργο και κυκλοφόρησε στην v1.3.0-alpha.
- Μία GPU οικιακής χρήσης διακανονίζει **περίπου 6 ψήφους ανά δευτερόλεπτο**, πάνω από 21.000 ψήφους την ώρα.
- Στο mainnet του Ethereum με 1 gwei, μια ψήφος κοστίζει **περίπου 0,15 σεντ**· στο Gnosis Chain, περίπου 0,0004 σεντ.

## Δύο provers, ένα πρωτόκολλο

Το DAVINCI έχει δύο πολύ διαφορετικές δουλειές απόδειξης, γι' αυτό χρησιμοποιεί δύο πολύ διαφορετικούς provers.

### Ο ψηφοφόρος αποδεικνύει στον περιηγητή

**Η δουλειά του ψηφοφόρου είναι μικρή και πρέπει να τρέχει παντού.** Το κύκλωμα του ψηφοδελτίου είναι γραμμένο σε Circom και η απόδειξη παράγεται στον περιηγητή με το snarkjs, ως απόδειξη Groth16 πάνω στην BN254. Το κύκλωμα ελέγχει ότι:

- το ψηφοδέλτιο είναι έγκυρη επιλογή για την εκλογική διαδικασία (εντός των επιτρεπτών τιμών, εντός του προϋπολογισμού, με μοναδικές επιλογές αν το απαιτεί η εκλογική διαδικασία),
- είναι σωστά κρυπτογραφημένο,
- το αναγνωριστικό της ψήφου προκύπτει σωστά.

Έχει περίπου **65K περιορισμούς** και χειρίζεται έως 16 κρυπτογραφημένα πεδία, αρκετά για να κωδικοποιηθούν ψηφοδέλτια μονής επιλογής, πολλαπλής επιλογής, έγκρισης, κατάταξης και τετραγωνικής ψηφοφορίας.

Για αυτό το κομμάτι μένουμε σκόπιμα στο Circom και στο snarkjs. Το snarkjs τρέχει σε WebAssembly σε κάθε σύγχρονο περιηγητή, παραλληλίζει τη δουλειά σε web workers και είναι ο πιο ώριμος prover για Groth16 σε περιηγητή που έχουμε βρει. Το σύνολο λειτουργεί ως στατική ιστοσελίδα: **κανείς δεν χρειάζεται να εγκαταστήσει εγγενή prover και κανείς δεν χρειάζεται να στείλει την ψήφο του σε μη κρυπτογραφημένη μορφή σε μια υπηρεσία παραγωγής αποδείξεων.** Για μια εφαρμογή ψηφοφορίας, αυτό μετράει περισσότερο από το να γλιτώσει κανείς ένα δευτερόλεπτο στην απόδειξη.

Η παραγωγή της απόδειξης για ένα ψηφοδέλτιο παίρνει περίπου **3 δευτερόλεπτα** σε φορητό υπολογιστή (AMD Ryzen AI 5 340, Brave) και περίπου **6,4 δευτερόλεπτα** σε ένα Google Pixel 7a με Chrome, μετά από μια εφάπαξ λήψη του κλειδιού απόδειξης των 35,5 MiB και της γεννήτριας witness των 6,5 MiB. Σε ένα κινητό, αυτό είναι μια μπάρα προόδου, όχι πρόβλημα.

### Ο sequencer αποδεικνύει σε διακομιστή

**Η δουλειά του sequencer είναι μεγάλη και τρέχει σε διακομιστή.** Για κάθε παρτίδα πρέπει:

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

Εδώ μπαίνει στο παιχνίδι το ZisK.

## Γιατί μεταφέραμε τον sequencer στο ZisK

### Τα κυκλώματα αλλάζουν δύσκολα

Μέχρι τώρα, η λογική του sequencer ζούσε σε κυκλώματα γραμμένα με το χέρι. Τα κυκλώματα είναι εξαιρετικά σε αυτό που κάνουν και απαίσια όταν πρέπει να αλλάξουν: κάθε μικρή αλλαγή σε έναν κανόνα σημαίνει νέα εξαγωγή των περιορισμών, νέα εκτέλεση των setups και νέο έλεγχο. Για ένα πρωτόκολλο που περιμένουμε να συνεχίσει να εξελίσσεται, **αυτό είναι ένας φόρος σε κάθε βελτίωση.**

### Τι είναι το ZisK

Το [ZisK](https://zisk.technology) είναι ένα zkVM ανοικτού κώδικα, μια εικονική μηχανή μηδενικής γνώσης φτιαγμένη για να κάνει την παραγωγή αποδείξεων ταχύτερη και φθηνότερη. Γράφετε προγράμματα σε Rust (ή σε άλλες γλώσσες υψηλού επιπέδου, όπως C++ ή Go) χωρίς να χρειάζεστε βαθιά κρυπτογραφική εξειδίκευση, και η αρχιτεκτονική του στοχεύει σε χαμηλή καθυστέρηση και χαμηλό κόστος με ασφάλεια 128 bit. Ξεκίνησε ως έργο της Polygon Labs, από την ομάδα πίσω από το Polygon zkEVM· τον Ιούνιο του 2025 η ομάδα αυτή το συνέχισε ανεξάρτητα, και σήμερα το διαχειρίζεται η SilentSig ως έργο ανοικτού κώδικα που καθοδηγείται από την κοινότητα.

![Λογότυπο του zkVM ZisK: το λευκό λεκτικό σήμα «ZisK VM» πάνω σε σκούρη κάρτα](/blog/images/2026/10/zisk-logo.webp)

Για εμάς λειτουργεί ως εξής: γράφετε κανονική Rust, τη μεταγλωττίζετε σε RISC-V και το ZisK παράγει μια απόδειξη STARK ότι το πρόγραμμα εκτελέστηκε σωστά με τις δεδομένες εισόδους. Το STARK είναι ένα είδος απόδειξης που δεν χρειάζεται trusted setup και παράγεται γρήγορα, με τίμημα το μεγάλο του μέγεθος. **Η μετάβαση κατάστασης του DAVINCI είναι πλέον ένα ενιαίο πρόγραμμα Rust που υλοποιεί κάθε κανόνα του πρωτοκόλλου**, και τα benchmarks της εργασίας τρέχουν στο ZisK v1.3.0-alpha.

### Τα precompiles κάνουν τη βαριά κρυπτογραφία

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

- SHA-256
- Keccak
- pairing BN254
- secp256k1
- αριθμητική υπολοίπων 256 bit
- και, από αυτή την έκδοση, BabyJubJub

Το πρόγραμμα μετάβασης στηρίζεται σε όλα εκτός από το Keccak, και θα επανέλθουμε στο γιατί το Keccak έχει σημασία ούτως ή άλλως. Οι αποδείξεις Groth16 που παράγονται στον περιηγητή, για παράδειγμα, δεν επαληθεύονται μία μία: **το πρόγραμμα συμπτύσσει ολόκληρη την παρτίδα σε έναν μόνο έλεγχο pairing**, σταθμισμένο με τυχαίους συντελεστές που παράγει από τις ίδιες τις αποδείξεις, πάνω στο precompile pairing BN254 του ZisK.

### Από το STARK σε μια απόδειξη που επαληθεύει το Ethereum

Το STARK είναι πολύ μεγάλο για να πάει απευθείας στο Ethereum. Το ZisK το συμπιέζει αναδρομικά και περιτυλίγει το αποτέλεσμα σε μια απόδειξη PLONK πάνω στην BN254, την οποία το συμβόλαιο διακανονισμού επαληθεύει με τα precompiles pairing που διαθέτει το Ethereum από το Byzantium. Δημοσιεύεται μόνο αυτή η τελική απόδειξη, και είναι μηδενικής γνώσης, οπότε κρύβει το witness του sequencer.

Το STARK δεν χρειάζεται trusted setup· το περιτύλιγμα PLONK χρησιμοποιεί τα καθολικά powers-of-tau του Hermez. **Η μόνη τελετή για συγκεκριμένο κύκλωμα που απομένει σε όλο το σύστημα είναι αυτή για το κύκλωμα ψηφοδελτίου του περιηγητή**, και επαναχρησιμοποιείται από τη μία εκλογική διαδικασία στην άλλη.

### Αναβαθμίσεις χωρίς νέο επαληθευτή

Υπάρχει και ένα μπόνους που μας αρέσει πολύ. Το κύκλωμα του περιτυλίγματος PLONK το ορίζει το ZisK· το πρόγραμμά μας μπαίνει σε αυτό μόνο ως μια δέσμευση κώδικα που κλειδώνει το συμβόλαιο διακανονισμού. **Η αναβάθμιση του προγράμματος μετάβασης σημαίνει ενημέρωση μίας αποθηκευμένης δέσμευσης**, όχι εγκατάσταση νέου επαληθευτή ή εκτέλεση νέου setup. Ο μηχανισμός επί της αλυσίδας μένει ως έχει ενώ το πρωτόκολλο βελτιώνεται.

## Συνεισφέραμε ένα precompile BabyJubJub στο ZisK

Το DAVINCI κρυπτογραφεί τα ψηφοδέλτια με ElGamal πάνω στην BabyJubJub, την καμπύλη του circomlib. Είναι η φυσική επιλογή από την πλευρά του περιηγητή: το σώμα βάσης της BabyJubJub είναι το βαθμωτό σώμα της BN254, οπότε η κρυπτογράφηση είναι εγγενής αριθμητική μέσα σε ένα κύκλωμα Circom.

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

Γι' αυτό γράψαμε ένα precompile. Το [PR #1152](https://github.com/0xPolygonHermez/zisk/pull/1152) προσθέτει πλήρη πρόσθεση σημείων σε αφινικές συντεταγμένες στην BabyJubJub (ο ίδιος τύπος καλύπτει και τον διπλασιασμό) ως αποκλειστική βασική λειτουργία του ZisK, συμβατή με τις παραμέτρους καμπύλης του circomlib. Η ομάδα του ZisK το εξέτασε, το προσάρμοσε στις εσωτερικές της συμβάσεις και **το συγχώνευσε στις 27 Αυγούστου**. Κυκλοφόρησε στο [ZisK v1.3.0-alpha](https://github.com/0xPolygonHermez/zisk/releases/tag/v1.3.0-alpha) στις 21 Σεπτεμβρίου, και οι σημειώσεις έκδοσης το περιγράφουν ως «a dedicated BabyJubJub point-add precompile compatible with circomlib». Ευχαριστούμε τον Héctor Masip και την υπόλοιπη ομάδα του ZisK που το ενσωμάτωσαν στο κύριο έργο αντί να μας αφήσουν σε ένα fork.

Αυτό είναι το κομμάτι που επιτρέπει στα δύο μισά του DAVINCI να μιλούν την ίδια κρυπτογραφία. Ο περιηγητής κρυπτογραφεί πάνω στην BabyJubJub μέσα σε ένα κύκλωμα Circom· ο sequencer επανακρυπτογραφεί και συσσωρεύει πάνω στην BabyJubJub μέσα στο ZisK· και οι αποδείξεις Groth16 που τα συνδέουν επαληθεύονται με το pairing BN254 του ZisK. **Τίποτα δεν χρειάζεται να μεταφραστεί από καμπύλη σε καμπύλη**, και όποιος άλλος χτίζει πάνω στην καμπύλη του circomlib αποκτά την ίδια βασική λειτουργία δωρεάν.

## Το μέρισμα του Ethereum: secp256k1 και Keccak

### secp256k1: το πορτοφόλι είναι το διαπιστευτήριο

Οι ψηφοφόροι του DAVINCI υπογράφουν το αναγνωριστικό της ψήφου τους με το ίδιο κλειδί ECDSA που βρίσκεται πίσω από τη διεύθυνσή τους στο Ethereum. Το ZisK επαληθεύει αυτή την υπογραφή εγγενώς, οπότε η επιλεξιμότητα είναι μια απόδειξη Merkle πάνω σε απλές διευθύνσεις Ethereum και **το πορτοφόλι του ψηφοφόρου είναι το διαπιστευτήριό του**, χωρίς επιπλέον κλειδί εγγραφής.

### Keccak: κατάλογοι ψηφοφόρων που το Ethereum έχει ήδη

Το Keccak είναι αυτό που μας ενθουσιάζει περισσότερο. Τα συστήματα ψηφοφορίας ZK, μαζί και το DAVINCI, χτίζουν μέχρι σήμερα τα δέντρα Merkle του καταλόγου ψηφοφόρων με Poseidon, επειδή η απόδειξη του Poseidon είναι φθηνή ενώ του Keccak δεν ήταν. Το τίμημα πληρώνεται επί της αλυσίδας: ένα hash Poseidon σε Solidity είναι πολλές φορές ακριβότερο από το `keccak256`, που είναι ένα μόνο opcode. Τα έργα που διατηρούν δέντρα Poseidon επί της αλυσίδας ζουν με αυτό το κόστος σε κάθε εισαγωγή.

Τα περισσότερα μητρώα, στιγμιότυπα token και λίστες μελών multisig που υπάρχουν ήδη στο Ethereum χρησιμοποιούν hash Keccak, οπότε μέχρι τώρα ένας κατάλογος ψηφοφόρων για ψηφοφορία ZK δεν μπορούσε να τα αξιοποιήσει χωρίς ένα βήμα μετατροπής. Τώρα που το ZisK αποδεικνύει το Keccak εγγενώς, **ο sequencer μπορεί να επαληθεύσει τη συμμετοχή σε ένα δέντρο Keccak** χωρίς το κόστος που παλιότερα το απέκλειε. Ένα DAO θα μπορούσε να διατηρεί το μητρώο ψηφοφόρων του επί της αλυσίδας με το hash που ήδη χρησιμοποιεί, και το DAVINCI θα μπορούσε να το αξιοποιεί απευθείας.

Το πρωτότυπο της εργασίας χρησιμοποιεί ακόμη δέντρο Merkle Poseidon για τον κατάλογο ψηφοφόρων και SHA-256 για το δέντρο κατάστασης, οπότε δείτε τους καταλόγους ψηφοφόρων με Keccak ως το επόμενο βήμα και όχι ως κάτι που έχει περάσει από benchmarks. Η αλλαγή όμως είναι φθηνότερη απ' όσο ακούγεται: η απόδειξη ένταξης στον κατάλογο ελέγχεται από τον sequencer, όχι από το κύκλωμα του ψηφοδελτίου, οπότε **ένας κατάλογος με Keccak είναι αλλαγή στο πρόγραμμα Rust**, όχι στο κύκλωμα του περιηγητή ή στην τελετή του.

## Τα νούμερα

### Η διάταξη

Όλα τα νούμερα του sequencer προέρχονται από ένα μηχάνημα: μια **NVIDIA RTX 5090 (32 GiB)** με AMD Ryzen 9 9950X3D 16 πυρήνων και 64 GiB RAM. Ο χρόνος που μετράμε είναι η κρίσιμη διαδρομή του sequencer, από την υποβολή της δουλειάς έως μια επαληθευμένη απόδειξη PLONK, μαζί με την αναδρομή, την περιτύλιξη και την επαλήθευση από τον ίδιο τον prover. Η παραγωγή της απόδειξης του ψηφοφόρου γίνεται στη συσκευή του και δεν περιλαμβάνεται.

Δύο πράγματα καθορίζουν το κόστος:

- **το μέγεθος της παρτίδας**, και
- **το `n`, ο αριθμός των ενεργών πεδίων ψηφοδελτίου** στη μορφή ψηφοδελτίου της εκλογικής διαδικασίας. Μια μονή επιλογή ανάμεσα σε δύο εναλλακτικές είναι `n = 2`· ένα ψηφοδέλτιο κατάταξης ή τετραγωνικής ψηφοφορίας με πολλές επιλογές μπορεί να χρησιμοποιήσει και τα 16.

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

### Χρόνος απόδειξης και ρυθμός επεξεργασίας

| Παρτίδα | Χρόνος, n = 2 | Ψήφοι/s, n = 2 | Blobs, n = 2 | Χρόνος, n = 16 | Ψήφοι/s, n = 16 | Blobs, n = 16 |
| --- | --- | --- | --- | --- | --- | --- |
| 2 | 15,6 s | 0,1 | 1 | 15,7 s | 0,1 | 1 |
| 64 | 22,5 s | 2,8 | 1 | 30,3 s | 2,1 | 2 |
| 128 | 30,1 s | 4,3 | 1 | 45,7 s | 2,8 | 3 |
| 256 | 46,2 s | 5,5 | 1 | 76,7 s | 3,3 | 5 |
| 512 | 84,3 s | 6,1 | 2 | 164,3 s | 3,1 | 9 |
| 1024 | 171,2 s | 6,0 | 3 | 363,9 s | 2,8 | 17 |

Πώς διαβάζεται: υπάρχει ένα **σταθερό κόστος περίπου 16 δευτερολέπτων ανά παρτίδα**, σχεδόν όλο από την αναδρομή, την περιτύλιξη και την επαλήθευση. Πάνω σε αυτό, κάθε ψηφοδέλτιο κοστίζει περίπου 0,11 s με `n = 2` και 0,23 s με `n = 16`.

Οι μεγαλύτερες παρτίδες αποσβένουν το σταθερό κόστος, γι' αυτό ο ρυθμός επεξεργασίας ανεβαίνει σε περίπου **6 ψήφους ανά δευτερόλεπτο** στα 512 ψηφοδέλτια για απλά ψηφοδέλτια και σε **3,3 ψήφους ανά δευτερόλεπτο** στα 256 ψηφοδέλτια για ψηφοδέλτια 16 πεδίων. Πέρα από αυτό το σημείο οι αποδείξεις ένταξης στον κατάλογο γίνονται βαθύτερες και, πάνω από τα 512 ψηφοδέλτια, ο prover θυσιάζει λίγα τοις εκατό σε ταχύτητα για να εξοικονομήσει RAM· το 1024 είναι το ανώτατο όριο της υλοποίησης, που το θέτει η μνήμη του μηχανήματος (περίπου 41 GB σε αυτό το μέγεθος), και γι' αυτό ο πίνακας σταματά εκεί.

![Χρόνος απόδειξης του sequencer ανά παρτίδα: η καμπύλη των δύο πεδίων ανεβαίνει από 15,6 s στα 2 ψηφοδέλτια σε 171 s στα 1024· η καμπύλη των δεκαέξι πεδίων από 15,7 s σε 364 s· και οι δύο πατούν σε σταθερό κόστος 16 δευτερολέπτων.](/blog/images/2026/10/davinci-proving-time.webp)

![Ρυθμός επεξεργασίας ενός sequencer: οι ψήφοι ανά δευτερόλεπτο αυξάνονται με το μέγεθος της παρτίδας και κορυφώνονται στις 6,1 για ψηφοδέλτια δύο πεδίων (512) και στις 3,3 για ψηφοδέλτια δεκαέξι πεδίων (256)· τα σημεία των δεκαέξι πεδίων στα 512 και 1024 είναι κενά επειδή ξεπερνούν τα έξι blobs.](/blog/images/2026/10/davinci-throughput.webp)

Έξι ψήφοι ανά δευτερόλεπτο σε μία GPU οικιακής χρήσης σημαίνουν **πάνω από 21.000 ψήφους την ώρα από έναν μόνο sequencer**. Μέσα σε μία εκλογική διαδικασία, οι παρτίδες σχηματίζουν μια αλυσίδα από ρίζες κατάστασης και το συμβόλαιο τις διακανονίζει με τη σειρά, οπότε αν δύο sequencers ανταγωνίζονται πάνω στην ίδια ρίζα, ο ένας από τους δύο έχει σπαταλήσει την απόδειξή του· τα νούμερα αυτά είναι ανά εκλογική διαδικασία και ανά sequencer. Ανάμεσα σε διαφορετικές εκλογικές διαδικασίες, οι sequencers είναι ανοικτοί σε όλους και ανεξάρτητοι, οπότε η χωρητικότητα μεγαλώνει με τα μηχανήματα που συνδέει ο κόσμος.

### Τα blobs είναι ο περιορισμός του Ethereum

Κάθε ενημέρωση θέσης δημοσιεύεται σε blobs EIP-4844 ώστε οποιοσδήποτε να μπορεί να ανακατασκευάσει την κατάσταση, και **το EIP-7594 περιορίζει μια συναλλαγή στα έξι blobs**. Οι δύο τελευταίες γραμμές των στηλών `n = 16` (9 και 17 blobs) ξεπερνούν αυτό το όριο, οπότε είναι νούμερα μόνο για την παραγωγή αποδείξεων· ένας sequencer που διακανονίζει στο mainnet επιλέγει το μέγεθος της παρτίδας με βάση το `n`, και οι διαμορφώσεις με τον βέλτιστο ρυθμό επεξεργασίας χωρούν άνετα.

![Blobs ανά μετάβαση ανάλογα με το μέγεθος της παρτίδας: οι παρτίδες δύο πεδίων χρειάζονται από 1 έως 3 blobs· οι παρτίδες δεκαέξι πεδίων χρειάζονται 1, 2, 3, 5, 9 και 17, με τις δύο τελευταίες πάνω από τη διακεκομμένη γραμμή των έξι blobs.](/blog/images/2026/10/davinci-blobs-per-batch.webp)

## Πόσο κοστίζει μια ψήφος επί της αλυσίδας

Ο διακανονισμός μιας παρτίδας κοστίζει περίπου **498K gas με ένα blob, συν περίπου 56K για κάθε επιπλέον blob**, όποιο κι αν είναι το μέγεθος της παρτίδας. Η επαλήθευση της απόδειξης PLONK είναι η ίδια δουλειά είτε η παρτίδα περιέχει 2 ψηφοδέλτια είτε 1024, οπότε το κόστος ανά ψήφο είναι το κόστος της παρτίδας διαιρεμένο με το μέγεθός της. Οι μεγαλύτερες παρτίδες βγαίνουν φθηνότερες ανά ψήφο· περισσότερα πεδία ψηφοδελτίου σημαίνουν περισσότερα blobs και λίγο ακριβότερη παρτίδα.

### Οι παραδοχές τιμών

Ο παρακάτω πίνακας κοστολογεί κάθε διαμόρφωση του benchmark που μπορεί να διακανονιστεί με **1 gwei και 2.500 USD ανά ETH** για το mainnet, κάτι σκόπιμα συντηρητικό: ο μέσος όρος του Etherscan τη μέρα που γράφαμε αυτό το άρθρο ήταν 0,12 gwei και η διάμεσος του τελευταίου έτους ήταν 0,74 gwei. Για το Gnosis Chain χρησιμοποιούμε τη διάμεσό του, 5,2 gwei, με πληρωμή σε xDAI στο 1 USD. Το κόστος κλιμακώνεται γραμμικά με την τιμή του gas, οπότε με τα σημερινά 0,12 gwei διαιρέστε τη στήλη του mainnet με το οκτώ, και σε μια αιχμή των 5 gwei πολλαπλασιάστε την επί πέντε.

| Πεδία ψηφοδελτίου | Παρτίδα | Blobs | Gas ανά παρτίδα | Mainnet, ανά παρτίδα | Mainnet, ανά ψήφο | Gnosis, ανά ψήφο |
| --- | --- | --- | --- | --- | --- | --- |
| 2 | 64 | 1 | 498K | 1,25 USD | 1,9 σεντ | 0,004 σεντ |
| 2 | 128 | 1 | 498K | 1,25 USD | 1,0 σεντ | 0,002 σεντ |
| 2 | 256 | 1 | 498K | 1,25 USD | 0,5 σεντ | 0,001 σεντ |
| 2 | 512 | 2 | 554K | 1,39 USD | 0,27 σεντ | 0,0006 σεντ |
| 2 | 1024 | 3 | 612K | 1,53 USD | 0,15 σεντ | δ/ε (βλ. παρακάτω) |
| 16 | 64 | 2 | 554K | 1,39 USD | 2,2 σεντ | 0,0045 σεντ |
| 16 | 128 | 3 | 612K | 1,53 USD | 1,2 σεντ | δ/ε (βλ. παρακάτω) |
| 16 | 256 | 5 | ~722K | ~1,80 USD | 0,7 σεντ | δ/ε (βλ. παρακάτω) |

![Κόστος διακανονισμού ανά ψήφο σε λογαριθμική κλίμακα: στο mainnet με 1 gwei πέφτει από 1,9 σεντ (64 ψηφοδέλτια) σε 0,15 σεντ (1024 ψηφοδέλτια)· το Gnosis Chain είναι περίπου 500 φορές φθηνότερο, από 0,004 σεντ έως 0,0006 σεντ, για τις παρτίδες που χωρούν στο όριο των δύο blobs.](/blog/images/2026/10/davinci-cost-per-vote.webp)

### Mainnet του Ethereum

Με 1 gwei, **ένα εκατομμύριο ψήφοι με απλό ψηφοδέλτιο διακανονίζονται με περίπου 1.500 USD** σε παρτίδες των 1024 ψηφοδελτίων, και με τη σημερινή τιμή του gas με λιγότερα από 200 USD. Τα μετρημένα νούμερα διακανονισμού της εργασίας φτάνουν έως τα τέσσερα blobs· η γραμμή των πέντε blobs είναι προέκταση με το ίδιο βήμα των 56K.

### Gnosis Chain

Στο Gnosis Chain η ίδια επαλήθευση είναι περίπου **500 φορές φθηνότερη**, επειδή το gas πληρώνεται σε token συνδεδεμένο με το δολάριο, σε τιμές που κάνουν μια ολόκληρη παρτίδα να κοστίζει περίπου ένα τέταρτο του σεντ. Ο περιορισμός εκεί είναι διαφορετικός: ένα block του Gnosis χωράει το πολύ δύο blobs, κάτι που περιορίζει μια μετάβαση στα 744 ψηφοδέλτια για εκλογικές διαδικασίες δύο πεδίων και στα 121 για όσες έχουν δεκαέξι πεδία.

Μέσα σε αυτά τα όρια, **ένα εκατομμύριο ψήφοι με απλό ψηφοδέλτιο διακανονίζονται στο Gnosis με λιγότερα από 5 USD**, περίπου 0,0004 σεντ η καθεμία. Για τους περισσότερους οργανισμούς, το κόστος διακανονισμού στο Gnosis είναι σφάλμα στρογγυλοποίησης μπροστά στον χρόνο GPU.

Τα τέλη των blobs είναι ξεχωριστή αγορά και δεν περιλαμβάνονται στον πίνακα· στο mainnet ήταν πολύ χαμηλότερα από το κόστος επαλήθευσης κατά το διάστημα των μετρήσεών μας, και στο Gnosis το κατώτατο τέλος blob του 1 gwei προσθέτει περίπου 0,0001 USD ανά blob.

## Σιωπηλή επαναψήφιση, αφού εμφανίζεται στα νούμερα

Τα benchmarks αυτά περιλαμβάνουν ανανεώσεις επειδή **το DAVINCI πληρώνει το τίμημα της ανθεκτικότητας στον εξαναγκασμό σε κάθε παρτίδα**, και θέλαμε να μετρήσουμε το πραγματικό κόστος και όχι το ωραιοποιημένο.

### Πώς λειτουργεί

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

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

### Τι κοστίζει

Στον πίνακα, αυτό κοστίζει περίπου **1,6 δευτερόλεπτα ανά παρτίδα 128 ψηφοδελτίων με `n = 2`** και περίπου 5 δευτερόλεπτα με `n = 16`. Αυτό που εξασφαλίζει είναι ότι ένας αγοραστής ψήφων δεν μπορεί να επιβεβαιώσει ότι η ψήφος που πλήρωσε έμεινε στη θέση της. Για εμάς, είναι κελεπούρι.

## Διαβάστε το, τρέξτε το, σπάστε το

Η εργασία βρίσκεται στο [eprint.iacr.org/2026/2282](https://eprint.iacr.org/2026/2282). Η Ενότητα 6 περιέχει τις λεπτομέρειες υλοποίησης και τα benchmarks· η Ενότητα 5 την ανάλυση ασφάλειας, μαζί με την τυπική διατύπωση του τι κρύβει η σιωπηλή επαναψήφιση.

Ο κώδικας είναι ανοικτός:

- [davinci-circom](https://github.com/vocdoni/davinci-circom): το κύκλωμα ψηφοδελτίου σε Circom και ο prover του περιηγητή, με μια δοκιμαστική εφαρμογή web που μπορείτε να χρησιμοποιήσετε στον δικό σας περιηγητή.
- [davinci-zkvm](https://github.com/vocdoni/davinci-zkvm): το πρόγραμμα μετάβασης για το ZisK και ο sequencer.
- [ZisK PR #1152](https://github.com/0xPolygonHermez/zisk/pull/1152): το precompile BabyJubJub.