Loading...
14 Eylül 2026'da kapanan NU7 coinholder anketinde, yaklaşık 2.397.669 ZEC, ZIP 218 lehinde oy kullandı ve 141,6 ZEC buna karşı oy verdi; sonuç %99,9 oldu. Haberlerin çoğu bunu "Zcash blokları hızlanıyor" diye özetledi. Bu doğru, ancak teklifin yaptıklarının ve kasıtlı olarak aynı bıraktıklarının büyük kısmını dışarıda bırakıyor.
Bu sayfa, ZIP 218'i kendi metni üzerinden açıklıyor: nelerin değiştiğini, nelerin değişmediğini ve maliyetini.
| Bugün | ZIP 218'den sonra | |
|---|---|---|
| Hedef blok aralığı | 75 saniye | 25 saniye |
| Günlük blok sayısı | 1.152 | 3.456 |
| Blok sübvansiyonu (mevcut yarılanma dönemi) | 1,5625 ZEC | 0,52083333 ZEC |
| Günlük yeni ZEC | değişmez | değişmez |
| Yarılanma aralığı | 1.680.000 blok | 5.040.000 blok |
| Blok başına korumalı işlem sınırları | yok (yalnızca 2 MB boyut sınırı) | havuz başına sınırlarla birlikte toplam 330 |
| Orchard işlem hacmi (2 işlemli işlemler) | saniyede yaklaşık 2,9 | saniyede yaklaşık 6,6 |
Üç kat daha fazla blok, her biri üçte bir kadar ödeme yapıyor. Arz takvimi olduğu yerde kalıyor.
Ana hedef daha kısa bekleme süresi. Bugün, ağ yükünden bağımsız olarak bir ödeme ilk onayı için ortalama 75 saniye bekler. 25 saniyede bu süre ortalama 25 saniyeye düşer. ZIP, bundan en çok etkilenen kullanım alanları olarak satış noktası ödemelerini, borsa yatırmalarını ve zincirler arası köprüleri sıralıyor.
ZIP'ten iki noktayı akılda tutmakta fayda var:
ZIP ayrıca, daha yüksek işlem hacminin tek başına daha büyük blok boyutuyla elde edilebileceğini belirtiyor. Bunun yerine daha kısa blokların seçilmesinin nedeni gecikmedir.
Blok sayısının üçe katlanması, başka hiçbir şey değişmezse günlük ihracı üçe katlardı. ZIP 218, NU7 etkin olduğunda blok başına sübvansiyonu üç ek katsayıyla bölerek bunu önler.
Mevcut yarılanma döneminde bu, blok sübvansiyonunu 1,5625 ZEC'den 0,52083333 ZEC'ye (52.083.333 zatoshi) düşürür. 156.250.000 zatoshi üçe tam bölünmediği için, her blok zatoshi'nin üçte biri kadar aşağı yuvarlanır. Tam 5.040.000 blokluk bir yarılanma aralığında bu, toplamda yaklaşık 0,0168 ZEC eder.
Sübvansiyon, blok başına oluşturulan toplam yeni ZEC miktarıdır. Mevcut geliştirme fonu payı hâlâ bundan alınır; dolayısıyla madenciler, bugün olduğu gibi, tam tutardan daha azını alır.
0,26041666 ZEC rakamı hakkında bir not. Taslak ZIP'in açıklayıcı notu, NU7 sonrası sübvansiyonu floor(156250000 / 6) = 0,26041666 ZEC olarak yazıyor ve bazı haberler bunu tekrarladı. Bu not iki kat hatalıdır: 156.250.000 zatoshi zaten Blossom sonrası sübvansiyondur; dolayısıyla bunu altıya bölmek, NU7'ün üç katsayısına ek olarak Blossom'ün iki katsayısını ikinci kez uygular. Normatif formül, mevcut yarılanma endeksinde floor(1,250,000,000 / (2 · 3 · 4)) = 52.083.333 zatoshi verir. Bu değişiklik için Zebra'in uygulama sorunu (#11463), notun Blossom katsayısını iki kez saydığını kaydeder, uygulayıcılara "notu değil, formülü uygulayın" der ve ZIP için bir düzeltme sunulduğunu belirtir. Etkinleştirme sırasındaki doğru rakam 0,52083333 ZEC'dir.
Yarılanma aralığı 1.680.000 bloktan 5.040.000 bloğa üçe katlanır. Bloklar üç kat daha sık geldiğinden, yarılanmalar değişiklik olmasaydı gerçekleşecekleri zamana yaklaşık olarak aynı noktada gerçekleşir. Toplam arz üst sınırı etkilenmez.
Bu, NU7 anketindeki diğer ihraç sorusundan ayrıdır; orada coinholder'lar yarılanmaları yumuşatılmış bir eğriyle değiştirmek yerine korumaya oy verdi. ZIP 218 mevcut yarılanma modeliyle çalışır ve onu değiştirmez.
ZIP 218, tek bir bloğun barındırabileceği korumalı etkinlik miktarına sınırlar ekler:
| Sınır | Blok başına azami |
|---|---|
| Tüm korumalı havuzlar birleşik | 330 (her Sprout JoinSplit 2 sayılır) |
| Orchard işlemleri | 330 |
| Sapling girdileri artı çıktıları | 300 |
| Sprout JoinSplit'leri | 25 |
İşlemlerin şeffaf bölümleri etkilenmez ve 2 MB blok boyutu sınırı geçerliliğini korur.
Bu sınırlar vardır çünkü daha fazla blok, aksi takdirde cüzdanlar ve düğümler için daha fazla iş anlamına gelirdi. Sınırlar uygulandığında, üç kat daha fazla blokla bile en kötü durum aslında bugünkünden daha iyi olur:
Sapling ve Sprout sınırları kasıtlı olarak sıkıdır. Mayıs 2026 itibarıyla Orchard, korumalı ZEC'in %87,9'unu, Sapling %11,6'sını ve Sprout %0,5'ini barındırıyordu; dolayısıyla daha küçük havuzlar gerçek kullanımları için yeterli alan bulurken saldırganın kötüye kullanabileceği alan azalır. ZIP 317 ücretleri her havuzda mantıksal işlem başına aynı ücreti aldığından, saldırganın bir havuzu diğerine göre spamlamasından kazanç sağlaması mümkün değildir.
Blok başına 330 Orchard işlemiyle, standart 2 işlemli bir Orchard işlemi blok başına ⌊330 / 2⌋ = 165 kez sığar. Her 25 saniyede bir blokla bu, saniyede yaklaşık 6,6 işlem eder; bugünkü yaklaşık 2,9'dan yükselerek — ZIP bunu normal Orchard işlem hacminde 2,3× artış olarak adlandırır. Sapling saniyede yaklaşık 3,0'a ulaşır; bu da Orchard'ün bugün başarabildiğinin üzerinde kalır.
Zorluk algoritması, yakın zamandaki bloklardan oluşan bir pencere üzerinden ortalama alır. ZIP 218, bu pencereyi 17 bloktan 102 bloğa çıkarır; böylece, Zcash 150 saniyelik bloklarla başlatıldığında kapsadığı süreyle aynı olan yaklaşık 2.550 saniyelik gerçek zamanı kapsamaya devam eder. ZIP iki neden veriyor: zorluk manipülasyonu saldırılarını kolaylaştırmamak (Litecoin'in Nisan 2026'daki MWEB olayına atıfta bulunuyor) ve blok sürelerindeki kısa vadeli değişkenliği yumuşatmak.
Etkinleştirmeden hemen sonra blok sürelerinin yeni hedefte dengelenmesi biraz zaman alacaktır. Bu beklenir ve Blossom'te, Zcash 150 saniyeden 75 saniyeye indiğinde yaşananları yansıtır.
Bunlar fikir birliği kuralları yerine uygulamalar için önerilerdir:
Daha hızlı bloklar ücretsiz değildir. Bayat blok, başka bir blok ağa önce ulaştığı için zincire dahil edilme yarışını kaybeden geçerli bir bloktur. Bloklar arasındaki aralık ne kadar kısa olursa bu durum o kadar sık yaşanır ve ZIP bayatlık oranını blok yayılımına, doğrulama süresine ve madencilik merkezileşmesi riskine bağlıyor.
İki küçük maliyet daha vardır. Hafif cüzdanlar, kompakt blok başlıkları için günde yaklaşık 200 KB daha fazla indirir. Ayrıca üç kat daha fazla blok olduğundan, çevrimdışı kalmış tam bir düğüm güncellendiğinde, her blok doğrulamak için daha ucuz olsa bile işlemesi gereken blok sayısı daha fazladır. ZIP her ikisini de kabul ediyor.