Loading...
In der am 14. September 2026 abgeschlossenen Coinholder-Umfrage von NU7 stimmten etwa 2.397.669 ZEC für ZIP 218 und 141,6 ZEC dagegen – ein Ergebnis von 99,9 %. Die meisten Berichte fassten es so zusammen: „Zcash-Blöcke werden schneller.“ Das stimmt, lässt aber den Großteil dessen aus, was der Vorschlag bewirkt und was er bewusst unverändert lässt.
Diese Seite erläutert ZIP 218 anhand seines eigenen Textes: was sich ändert, was nicht und welche Kosten damit verbunden sind.
| Heute | Nach ZIP 218 | |
|---|---|---|
| Zielabstand zwischen Blöcken | 75 Sekunden | 25 Sekunden |
| Blöcke pro Tag | 1.152 | 3.456 |
| Blocksubvention (aktuelle Halving-Ära) | 1,5625 ZEC | 0,52083333 ZEC |
| Neue ZEC pro Tag | unverändert | unverändert |
| Halving-Intervall | 1.680.000 Blöcke | 5.040.000 Blöcke |
| Grenzen für abgeschirmte Aktionen pro Block | keine (nur die 2-MB-Größenbegrenzung) | 330 insgesamt, mit Limits je Pool |
| Orchard-Durchsatz (Transaktionen mit 2 Aktionen) | etwa 2,9 pro Sekunde | etwa 6,6 pro Sekunde |
Dreimal so viele Blöcke, die jeweils ein Drittel so viel auszahlen. Der Emissionsplan bleibt unverändert.
Das Hauptziel ist eine geringere Wartezeit. Heute wartet eine Zahlung unabhängig von der Netzwerkauslastung durchschnittlich 75 Sekunden auf ihre erste Bestätigung. Bei 25 Sekunden sinkt dies durchschnittlich auf 25 Sekunden. ZIP nennt Point-of-Sale-Zahlungen, Börseneinzahlungen und Cross-Chain-Bridges als die Anwendungen, die dies am stärksten spüren.
Zwei Punkte aus ZIP sollten berücksichtigt werden:
ZIP weist außerdem darauf hin, dass ein höherer Durchsatz allein auch mit einer größeren Blockgröße hätte erreicht werden können. Die Latenz ist der Grund, stattdessen kürzere Blöcke zu wählen.
Eine Verdreifachung der Blockzahl würde die tägliche Emission verdreifachen, wenn sich sonst nichts änderte. ZIP 218 verhindert dies, indem die Subvention pro Block nach Aktivierung von NU7 um einen weiteren Faktor drei geteilt wird.
In der aktuellen Halving-Ära sinkt die Blocksubvention dadurch von 1,5625 ZEC auf 0,52083333 ZEC (52.083.333 zatoshi). Da sich 156.250.000 zatoshi nicht gleichmäßig durch drei teilen lassen, wird jeder Block um ein Drittel eines zatoshi abgerundet. Über ein vollständiges Halving-Intervall von 5.040.000 Blöcken ergibt das insgesamt etwa 0,0168 ZEC.
Die Subvention ist die gesamte Menge neuer ZEC, die pro Block erzeugt wird. Der bestehende Anteil für Entwicklungsfinanzierung wird weiterhin daraus entnommen, sodass Miner – genau wie heute – weniger als den vollen Betrag erhalten.
Eine Anmerkung zur Zahl von 0,26041666 ZEC. Die erläuternde Anmerkung im Entwurf von ZIP gibt die Subvention nach NU7 als floor(156250000 / 6) = 0,26041666 ZEC an, und einige Nachrichtenberichte haben dies wiederholt. Diese Anmerkung liegt um den Faktor zwei falsch: 156.250.000 zatoshi sind bereits die Subvention nach Blossom, sodass eine Division durch sechs den Blossom-Faktor zwei zusätzlich zum NU7-Faktor drei ein zweites Mal anwendet. Die normative Formel ergibt beim aktuellen Halving-Index floor(1,250,000,000 / (2 · 3 · 4)) = 52.083.333 zatoshi. Das Implementierungs-Issue von Zebra für diese Änderung (#11463) hält fest, dass die Anmerkung den Blossom-Faktor doppelt zählt, fordert Implementierer auf, „die Formel, nicht die Anmerkung“ umzusetzen, und besagt, dass eine Korrektur für ZIP eingereicht wurde. Der korrekte Wert bei Aktivierung ist 0,52083333 ZEC.
Das Halving-Intervall verdreifacht sich von 1.680.000 auf 5.040.000 Blöcke. Da Blöcke dreimal so häufig eintreffen, finden Halvings weiterhin ungefähr zum selben Zeitpunkt statt, zu dem sie ohne diese Änderung stattgefunden hätten. Die Gesamtobergrenze des Angebots bleibt unberührt.
Dies ist getrennt von der anderen Emissionsfrage in der Umfrage von NU7, bei der Coinholder dafür stimmten, Halvings beizubehalten, statt sie durch eine geglättete Kurve zu ersetzen. ZIP 218 arbeitet mit dem bestehenden Halving-Modell und verändert es nicht.
ZIP 218 führt Obergrenzen dafür ein, wie viel abgeschirmte Aktivität ein einzelner Block enthalten darf:
| Grenze | Maximum pro Block |
|---|---|
| Alle abgeschirmten Pools zusammen | 330 (jeder Sprout JoinSplit zählt als 2) |
| Orchard-Aktionen | 330 |
| Sapling-Eingaben plus -Ausgaben | 300 |
| Sprout JoinSplits | 25 |
Transparente Teile von Transaktionen sind nicht betroffen, und die 2-MB-Blockgrößenbegrenzung gilt weiterhin.
Die Grenzen bestehen, weil mehr Blöcke sonst mehr Arbeit für Wallets und Knoten bedeuten würden. Mit den Obergrenzen wird der schlimmste Fall trotz dreimal so vieler Blöcke tatsächlich besser als heute:
Die Obergrenzen für Sapling und Sprout sind absichtlich eng. Im Mai 2026 enthielt Orchard 87,9 % der abgeschirmten ZEC, Sapling 11,6 % und Sprout 0,5 %. Daher erhalten die kleineren Pools genügend Raum für ihre tatsächliche Nutzung, während ein Angreifer weniger missbrauchen kann. Da die Gebühren von ZIP 317 in jedem Pool pro logischer Aktion gleich hoch sind, gewinnt ein Angreifer nichts, wenn er einen Pool statt eines anderen spammt.
Bei 330 Orchard-Aktionen pro Block passt eine Standardtransaktion von Orchard mit 2 Aktionen ⌊330 / 2⌋ = 165-mal in einen Block. Bei einem Block alle 25 Sekunden sind das etwa 6,6 Transaktionen pro Sekunde, gegenüber heute etwa 2,9 – ZIP nennt dies einen Anstieg des normalen Orchard-Durchsatzes um das 2,3-Fache. Sapling liegt bei etwa 3,0 pro Sekunde und damit weiterhin über dem, was Orchard heute bewältigt.
Der Schwierigkeitsalgorithmus bildet einen Durchschnitt über ein Fenster jüngerer Blöcke. ZIP 218 erhöht dieses Fenster von 17 auf 102 Blöcke, sodass es weiterhin etwa 2.550 Sekunden Echtzeit abdeckt – denselben Zeitraum, den es bei der Einführung von Zcash mit 150-Sekunden-Blöcken abdeckte. ZIP nennt zwei Gründe: Schwierigkeitsmanipulationsangriffe nicht zu erleichtern (es verweist auf den MWEB-Vorfall bei Litecoin im April 2026) und kurzfristige Schwankungen der Blockzeiten zu glätten.
Unmittelbar nach der Aktivierung werden die Blockzeiten eine Weile brauchen, um sich auf das neue Ziel einzupendeln. Das wird erwartet und entspricht dem, was bei Blossom geschah, als Zcash von 150 auf 75 Sekunden sank.
Dies sind Empfehlungen für Implementierungen und keine Konsensregeln:
Schnellere Blöcke sind nicht kostenlos. Ein veralteter Block ist ein gültiger Block, der das Rennen um die Aufnahme in die Chain verliert, weil ein anderer Block das Netzwerk zuerst erreicht. Je kürzer der Abstand zwischen Blöcken, desto häufiger passiert dies, und ZIP verknüpft die Rate veralteter Blöcke mit Blockweiterleitung, Verifizierungszeit und dem Risiko der Mining-Zentralisierung.
Daneben gibt es zwei kleinere Kosten. Light Wallets laden pro Tag etwa 200 KB mehr an kompakten Block-Headern herunter. Und weil es dreimal so viele Blöcke gibt, muss ein Full Node, der offline war, beim Aufholen mehr Blöcke verarbeiten, obwohl jeder einzelne Block günstiger zu verifizieren ist. ZIP akzeptiert beides.