Kaspa'nın Toccata Hard Fork'u: Sözleşmeler, ZK Opcode'ları ve Yeni Bir Haziran Hedefi

KaspaYakında çıkacak olan Toccata hard fork'u, ağa iki yeni programlanabilirlik yolu ekleyecek: yerel L1 sözleşme programlaması ve sıfır bilgi (zk) uygulama altyapısı. Ana ağ aktivasyonu ise orijinal 5 Mayıs hedefinden ertelenerek 5-20 Haziran 2026 tarihleri ​​arasına alındı.

Kaspa Core'dan Michael Sutton bir yayın yaptı. ayrıntılı güncelleme Hard fork'un neleri içerdiği, tarihin neden değiştirildiği ve önümüzdeki birkaç ayın nasıl geçmesinin beklendiği hakkında bilgi veriyoruz. Fork, başlangıçta Ori Newman tarafından, kısmen Bitcoin çevrelerindeki OP_CAT tartışmasına yanıt olarak, Kaspa'nın komut dosyası motoruna sözleşmeleri getirme çabası olarak başlatılmıştı. O zamandan beri oldukça büyük bir şeye dönüştü.

Toccata Hard Fork Nedir?

Toccata, Kaspa ağı için planlanmış bir hard fork'tur ve yeni yetenekleri doğrudan temel katmana entegre eder. Hard fork, daha az aşina olanlar için, geriye dönük uyumluluğu olmayan bir protokol yükseltmesidir. Ağda yer almaya devam etmek için tüm düğümlerin yükseltme yapması gerekir.

Bu isim, Kaspa'nın büyük geliştirmelerde müzikal referanslar kullanma geleneğini sürdürüyor. Bu model, adını klasik bir müzik formu olan toccata'dan alıyor; toccata, bir klavye enstrümanında teknik beceriyi sergilemek için tasarlanmış bir eserdir.

Özetle, Toccata, Kaspa'ya iki şey ekler:

• Yerli L1 sözleşme programlaması Silverscript adlı yeni bir derleyici aracılığıyla
• ZK tabanlı uygulama altyapısıaynı ahit temelleri üzerine inşa edilmiş

Bunlar birbirinin yerine kullanılabilen sistemler değildir. Farklı kullanım durumlarına hizmet ederler ve farklı geliştirici kitlelerini hedeflerler.

Sözleşmeler Nedir ve Kaspa İçin Neden Önemlidir?

Sözleşmeler, bir işlem çıktısındaki fonların gelecekte nasıl harcanabileceğine dair getirilen şartlardır. Standart bir Bitcoin veya Kaspa işleminde, paralar gönderildikten sonra alıcı onlarla istediğini yapabilir. Sözleşmeler, harcama kurallarını doğrudan işleme yerleştirerek bunu değiştirir.

Kaspa, Bitcoin'e benzer şekilde, her işlemin mevcut çıktıları tükettiği ve yenilerini oluşturduğu bir UTXO modeli kullanır. UTXO sistemindeki sözleşmeler, temel hesaplama her UTXO'ya özgü kalsa bile, geliştiricilerin şaşırtıcı derecede karmaşık, durum bilgisi içeren çoklu sözleşme akışları oluşturmasına olanak tanır.

Sözleşme geliştirme sürecini daha erişilebilir hale getirmek için Kaspa Core, Ori Newman, Michael Sutton, IzioDev ve Manyfest tarafından başlatılan Silverscript adlı derleyiciyi son haline getiriyor. Silverscript, geliştiricilerin ham komut dosyası motoru seviyesinde çalışmasına gerek kalmadan, karmaşık sözleşmeleri doğrudan Kaspa L1 üzerinde yazmayı ve dağıtmayı daha kolay ve güvenli hale getirmek için tasarlanmıştır.

ZK Tabanlı Uygulamalar Nelerdir?

Toccata'da tanıtılan ikinci programlanabilirlik sütunu, zk uygulamalarına dayanmaktadır. Bu, ikisi arasında teknik olarak daha yoğun olanıdır ve dikkatlice incelenmeye değerdir.

Umut Vaat Eden Projeleri Keşfedin...

Umut Vadeden Projeler...

(İlan)

Makale devam ediyor...

ZK, sıfır bilgi anlamına gelir ve bir tarafın altta yatan verileri ifşa etmeden bir şeyin doğru olduğunu kanıtlamasına olanak tanıyan bir kriptografik yöntemdir. ZK ispatları, zincir dışı hesaplamaların zincir üzerinde ucuz ve güvenli bir şekilde doğrulanmasına olanak tanıdığı için blok zinciri ölçeklendirmesinde giderek daha fazla kullanılmaktadır.

Bu bağlamda "tabanlı" ifadesi, zk sisteminin L1 sıralamasını tamamen takip ettiği anlamına gelir. Tabanlı bir zk uygulaması, bağımsız olarak işlem ekleyemez veya silemez. Kaspa'nın kendi işlem sırasına bağlıdır; bu da onu ayrı bir sıralayıcıya ihtiyaç duymadan güvenilir kılar.

Toccata bunu desteklemek için çeşitli bileşenler sunmaktadır:

• ZK doğrulama işlem kodlarıEsnek bir Groth16 doğrulayıcı ve bir RISC Zero STARK doğrulayıcı da dahil olmak üzere
• Sıralama taahhüdü erişim işlem koduBu sayede, uygulamaların kendilerini L1 sıralamasına bağlamaları mümkün olmaktadır.
• KIP-21Bu, bir ZK uygulamasının ispat maliyetlerinin genel DAG etkinliğiyle değil, kendi etkinliğiyle orantılı olarak artmasını sağlayan, bölümlere ayrılmış bir sıralama taahhüt mimarisidir.

RISC Zero STARK doğrulayıcısı, test ağı 12'de zaten uygulanmış ve etkinleştirilmiştir. Ana ağda etkinleştirilip etkinleştirilmeyeceğine henüz karar verilmemiştir.

Maliyetleri Kanıtlamanın Önemi

Herhangi bir zk uygulamasının pratik olabilmesi için, kanıt üretme maliyetinin uygulamanın kendisinin yaptığı işlerle orantılı kalması gerekir. Eğer bir zk uygulaması, daha geniş DAG üzerindeki tüm faaliyetlere göre işi kanıtlamak zorunda kalsaydı, maliyetler öngörülemez ve yönetilemez hale gelirdi. KIP-21, sıralama taahhütlerini bölümlere ayırarak ve her uygulamanın iş yükünü kendi içinde tutarak bu sorunu çözer.

Hali hazırda neler var?

Hard fork'un önemli bir kısmı zaten uygulandı. Aşağıdaki özellikler zaten oluşturuldu:

• KIP-17 kapsamında, temel sözleşmelerin omurgasını oluşturan genişletilmiş komut dosyası motoru işlem kodu desteği.
• KIP-20 kapsamında, soy ağacı yönetimi için konsensüs ve motor özelliği olarak sözleşme kimlikleri.
• Alexander Safstrom tarafından geliştirilen KIP-16 kapsamında, zk-verifier ön derleme alt sistemine sahip ZK işlem kodları.
• Sıralama taahhüdü erişim işlem kodu
• Sutton tarafından kaleme alınan ve Maxim Biryukov tarafından uygulanan KIP-21, tamamen hayata geçirildi ve inceleme aşamasında.

Maxim tarafından, KAS kanonik köprüsü içeren sıralı zk sözleşmeleri ve temel zk sözleşmeleri de dahil olmak üzere, kavram kanıtı aşamaları tamamlandı ve bu aşamalar, çatalın nihai tasarımının şekillenmesinde etkili oldu.

Hard Fork Tarihi Neden Haziran'a Alındı?

Ana ağın asıl hedef tarihi 5 Mayıs 2026 idi. Daha sonra bu tarih 5-20 Haziran 2026 arasına çekildi.

Bunun nedeni mimaridir. ZK devreleri ve çalışma ortamları bir sıralama taahhüdü karma yapısına bağlandıktan sonra, sonradan yapılan herhangi bir yapısal değişiklik, sistemin bozulmasına yol açan değişikliklere dönüşür. Tasarımı yanlış yapmak ve daha sonra yamalamak, şimdi fazladan zaman ayırmaktan çok daha fazla aksamaya neden olur.

KIP-21, Kaspa'nın senkronize olarak birleştirilebilir doğrulanabilir programlar için uzun vadeli yol haritası olan vprogs'un nihayetinde gerektireceği taahhüt şemasıyla gelecekte uyumlu olacak şekilde tasarlanmıştır. Ana ağ aktivasyonundan önce doğru yapıyı sabitlemek, daha sonraki maliyetli geçişlerden kaçınmayı sağlar.

Yeni özelliklerin geliştirilmesinin 15 Nisan 2026'da sonlandırılması bekleniyor.

Özellik Dondurma Aşaması ile Ana Ağ Sürümü Arasında Neler Oluyor?

15 Nisan'daki özellik dondurma işleminden sonra, Kaspa Core, tüm nihai özellik setini içeren özel test ağı TN12'nin temiz bir şekilde yeniden başlatılmasını planlıyor. Bu, hard fork geçişinin bir simülasyonu değil. Bu, tüm özellik setinin nihai haliyle test edilmesi için oluşturulmuş temiz bir ağdır.

Ekip, buradan yola çıkarak uzun süredir beklemede olan bir dalda biriken aylarca süren çalışmaları ana kod tabanına geri entegre edecek. Bu süreç, son denetimi, açık maddelerin kapatılmasını, hard fork etkinleştirme mantığının mükemmelleştirilmesini ve veritabanı yükseltilebilirliğinin ele alınmasını içerir.

Bu çalışma tamamlandıktan sonra, tam bir ana ağ geçişini simüle etmek için uzun vadeli test ağı olan TN10 üzerinde bir test amaçlı hard fork çalıştırılacaktır. Ana ağın açılış tarihi, ancak bu deneme çalışması ekibin memnuniyetini sağlayacak şekilde tamamlandıktan sonra kesin olarak belirlenecektir.

Düğüm Operatörlerinin Beklentisi Neler Olmalıdır?

Madenciler ve düğüm operatörleri için yükseltme işlemi oldukça basit olacak şekilde tasarlandı. Düğümlerin güncellenmesi gerekiyor ve mevcut işlevsellik çalışmaya devam etmeli. Disk alanı gereksinimlerinin yaklaşık %20 ila %50 oranında artması bekleniyor. Altyapıda önemli değişiklikler beklenmiyor.

Toccata Kaspa İçin Gerçekte Ne Sağlıyor?

Toccata, Kaspa'nın temel katmanına iki çalışan programlanabilirlik sistemi ekliyor: Silverscript aracılığıyla yerel L1 sözleşme betikleme ve KIP-16, KIP-20 ve KIP-21 aracılığıyla zk tabanlı uygulama altyapısı. Teknik çalışmaların büyük bir kısmı zaten tamamlandı. Geriye kalanlar, arayüzlerin son halini vermek, bekleyen dalı ana dala birleştirmek ve ana ağ tarihinin onaylanmasından önce TN10 üzerinde tam bir deneme çalıştırmaktır.

5-20 Haziran 2026 tarihleri ​​arasındaki zaman dilimi, ekibin sıralama taahhüt mimarisini canlı koşullar altında daha sonra düzeltmek yerine ilk seferde doğru bir şekilde kurmayı tercih etmesinden kaynaklanmaktadır. Düğüm operatörleri için yükseltme, disk alanında mütevazı bir artış dışında büyük altyapı değişiklikleri gerektirmeyen, basit bir şekilde tasarlanmıştır.

Kaynaklar

1. Kaspa X'te: Gönderi (Nisan 2026)

2. Michael Sutton tarafından yazılan blog yazısı: Kaspa Covenants++ “Toccata” Sert Çatal Görünümü