Agave 2.0 Özeti

Agave doğrulayıcı istemci v2.0'nin piyasaya sürülmesi, Solana'nın daha güçlü, çoklu istemci ekosistemi yolculuğunda önemli bir kilometre taşını işaret ediyor. Bu güncelleme, ağ performansını, güvenilirliğini ve verimliliğini artırmak için birkaç kritik iyileştirme getiriyor. Bu güncellemedeki temel değişiklikler şunları içerir:

‍

• Kapsamlı kod tabanı yeniden düzenlemeleri ve optimize edilmeleri
• Bölünmüş dönem ödülleri
• Doğrulayıcılara tam öncelik ücreti ödülü vermek
• Yeni merkezi zamanlayıcı artık varsayılan olarak açık
• ZK ElGamal Kanıt programı
• Get-Sysvar Sistem Çağrısı
• GetEpochStake Syscall
• MoveStake ve MoveLamports
• Eski RPC yöntemlerinin kaldırılması
• Kutu yeniden adlandırmaları

‍

Bir doğrulayıcı çalıştırıyor olun, platformda projeler geliştiriyor olun veya Solana'yı aktif olarak kullanıyor olun, Agave 2.0 güncellemesine dair bu kapsamlı genel bakış, en son yeniliklerin anlaşılması ve avantajlarının kullanılması için gerekli olan bilgileri sağlayacaktır.

2.0'ı Büyük Bir Sürüm Güncellemesi Yapan Nedir?

Artık tek bir 'Solana doğrulayıcısı' yok. Agave 2.0, Solana'nın yeni çoklu istemci dünyasını benimser ve eskiyle tamamen kopar.Solana Labs GitHub deposu. Solana Labs deposu arşivlenecek ve yeni çekme istekleri veya sorunlar artık kabul edilmeyecek. Daha önce bu depo, Agave deposundan faaliyetleri yansıtıyordu. Geliştiriciler tüm faaliyetleriAnza Agave GitHub deposueğer henüz yapmadılarsa. TheSolana Labs'un Agave göç süreci1 Mart'ta başladı ve GitHub üzerinden halka açık olarak takip ediliyor.

‍

Ekosistem geliştikçe, operatörler bir veya daha fazla istemci çalıştırmaya adapte olmalıdır. Bu değişikliği takiben, birkaç kasa yeniden adlandırılıyor ve ad alanını temizleyerek bağımsız geliştirici ekipleri tarafından yönetilen, özellikle Firedancer gibi birden fazla istemciyi desteklemek için uygun hale getiriliyor. Anza tarafından yönetilen kasalar artık “agave” ile başlayan bir ön ek alacak ve bu şekilde çoklu istemci ortamında Anza'ya özgü bağımlılıklar olarak kolayca tanımlanabilecek.

‍

‍

Etkilenen kasa tipleri:

‍

solana-validator, solana-ledger-tool, solana-watchtower, solana-install, solana-geyser-plugin-interface, solana-cargo-registry

‍

Ayrıntılarıyla belirtildiği gibi Önceki Geçiş Kılavuzu, 2.0 güncellemesi birkaç önemli değişiklik getiriyor, özellikle birkaç eski ve kullanımdan kaldırılan uç noktanın kaldırılması - tüm Solana geliştiricilerinin artık farkında olması gereken önemli güncellemeler. RPC değişikliklerinin tam detayları bu makalenin sonunda yer almaktadır.

Özelliklerin Yayınlanması

Yazı yazıldığı sırada, doğrulayıcıların yaklaşık %20.7'si 2.0.14 sürümünü çalıştırıyor. Ana ağdaki özellik kapı etkinleştirmeleri geçici olarak durduruldu, böylece v2.0 benimsenmesi test ağı ve geliştirici ağındaki etkinleştirmelerle daha yakından uyumlu hale gelebilir. Ana ağ kümesi geniş çapta v2.0'ı benimseyince, özellik kapı etkinleştirmelerinin yeniden başlayacağı öngörülmektedir.planlanmış etkinleştirme emri.

‍

Aşağıdaki bölümlerde tartışılan yeni tam özellikler şu anda aktif değildir ve 2.0 yaşam döngüsü boyunca özellik kapısı sistemi kullanılarak yavaş yavaş devreye alınacaktır. Özellikler, göreli önceliğe ve testnet ve devnet kümelerinde devreye alındıkları sıraya dayalı olarak belirli çağlarda etkinleştirilir.

‍

Ödül Tam Öncelikli Ücreti Doğrulayıcılara

Bu çok beklenen veçok tartışılan ekonomik güncellemeöneri sonrası uygulanmaya başlandı.SIMD-0096, Mayıs ayında bir doğrulayıcı yönetim oylamasından geçti. Oylama 620. dönemin sonunda tamamlandı ve bahislerin %51.17'si katıldı ve %77.77'si lehte oy kullandı. Özellik kapılı güncelleme ağın işleyişini temel olarak değiştirecek.öncelikli ücretler. Mevcut modelin aksine, ücretleri %50 yakılan ve %50 doğrulayıcılara ödüllendirilen bir şekilde paylaşan yeni model, öncelikli ücretlerin tamamını doğrudan doğrulayıcılara tahsis edecektir.

Yukarıda: Solana haftalık öncelikli ücretlerin USD değeri (kaynak)

‍

Öncelik ücretleri teknik olarak isteğe bağlı olsa da, Solana üzerindeki ekonomik faaliyet arttıkça standart uygulama haline gelmiştir. Bu ücretler, formül kullanılarak her hesaplama birimi başına mikro-lamport (bir lamportun milyonda biri) cinsinden hesaplanır.

‍

önceliklendirme ücreti = hesaplama birimi fiyatı (mikro-lamport) x hesaplama birimi sınırı

‍

Bundan sonra, tüm öncelik ücretleri blok üreticilerine verilecektir. Bu, teşviklerin daha güçlü bir hizalanmasını oluşturur ve doğrulayıcıların protokol dışı düzenlemelere girmelerinin, geçmişte bir sorun olmuş olan işlemin dahil edilmesi için olasılığını azaltır.

‍

Ücret yakmalarının kaldırılması SOL'un net enflasyon oranını hafifçe artırsa da, staking ödülleri aracılığıyla yeni jeton çıkarımı çok daha önemli bir etkiye sahiptir. Okuyucular, daha önceki Helius blog yazımıza bakabilirler.Solana'nın ihraç ve enflasyon takvimibu dinamiklerin daha detaylı bir açıklaması için.

‍

Bölünmüş Çağ Ödülleri

Bölümlü dönem ödülleridağıtmayı hedeflestake ödülleriçoklu blok üzerinde dağılımının konsantre ödül dağıtımına bağlı performans sorunlarını hafifletirken. Her yeni dönemin ilk bloğu içindeki ödül dağıtımına odaklanarak performans sorunlarını hafifletir. Bu süreçteki ana darboğaz, şu anda yaklaşık 1.4 milyon olan aktif hisse hesaplarındaki güncellemeleri geri yazma gerekliliğidir.

Bu yeni yaklaşıma göre, kazanç ödülü hesaplama ve epok sınırında dağıtımı iki farklı aşamaya bölünecektir:

‍

• Ödül Hesaplama Aşaması: Bu aşamada, tüm aktif pay hesapları için çağ ödülleri hesaplanır ve dağıtım programlanmış parçalara bölünür.
• Ödül Dağıtım Aşaması: Aktif pay hesapları için önceden hesaplanmış dönem ödülleri ilgili şekilde dağıtılır.

‍

İşlemi kolaylaştırmak ve izlemek için bir Sysvar hesabı,EpochRewards, dağıtım aşaması boyunca ödül dağıtımlarını izleyecek ve doğrulayacak. EpochRewards Sysvar, ödül dağıtım aşamasının devam edip etmediğini ve bir anlık görüntüden başlarken dağıtımın devam ettirilmesi için gereken bilgileri kaydeder.

Ödül Hesaplama

Ödül hesaplamaları epokun ilk bloğunda gerçekleştirilecektir. Hesaplandıktan sonra, ödüller, dağıtım aşamasında dağıtılacak olan bankada depolanan dağıtım parçacıklarına bölünür.

‍

Ödül dağıtım aşamasında blok işleme süresine olan etkiyi en aza indirmek ve her bir bloğun ödüllerin belirli bir alt kümesini belirli bir şekilde dağıtmasını sağlamak için blok başına 4.096 bahis ödülü hedeflenir. Bahis hesaplarının sayısında dramatik bir artışa karşı korunmak için blok sayısı bir dönemdeki toplam yuvaların yüzde 10'uyla sınırlıdır. Ancak bu blok sınırına ulaşılırsa, bölüm başına hesap sayısı 4.096 hedefini aşabilir.

Ödül Dağıtımı

Ödül dağıtımı, ödül hesaplama aşamasından hemen sonra başlar ve dönemin ikinci bloğundan itibaren gerçekleşir. Ödül dağıtımları normal işlem işleme öncesinde bloğun üstünde gerçekleşir.

‍

Sonuç olarak, kullanıcılar ödüllerin hesaplarına önceki zamana göre birkaç blok daha sonra yazıldığını görebilirler. Bununla birlikte, genel deneyim benzer kalır çünkü önceki dönem sınırındaki uzun ilk blok zamanı kullanıcının stake hesaplarına erişimini geciktirirdi. Bu yaklaşımın ek bir faydası, stake dışı işlemlerin sorunsuz bir şekilde devam edebilmesidir. Önceden ödül dağıtımı sırasında bu işlemler engellenirdi.

‍

Seçim hesaplarının oldukça düşük sayısı, yaklaşık 1.500, nedeniyle, dönem sınırının ilk bloğunda oy ödüllerini dağıtmak için mevcut mekanizma değişmeyecek. Sadece pay ödülleri birden fazla blok üzerinde dağıtılacaktır.

‍

Merkezi Zamanlayıcı Artık Varsayılan Olarak Açık

v1.18 güncellemesinde bir özellik sürümü olarak tanıtılan merkezi zamanlayıcı, önceki adıyla “zamanlayıcı” olarak bilinmekteydi ve varsayılan olarak etkin değildi. Doğrulayıcı başlatılırken operatörler tarafından —block-production-method central-scheduler bayrağı kullanılarak etkinleştirilmesi gerekiyordu. Şu anda varsayılan olarak etkindir. Önceki zamanlayıcı uygulamasının performansı olumsuz etkileyebilecek birkaç sorunu bulunmaktaydı. İşlem işleme noktaları genellikle işlemin sıralama ve önceliklendirme konusunda titreme veya tutarsızlık yaşanmasına neden olurdu.

‍

Yeni uygulama, dört bağımsız bankacılık iş parçacığı modelini değiştirir ve her biri kendi işlem önceliklendirme ve işleme yönetimini gerçekleştirir. Bu revize edilmiş yapıda, merkezi zamanlayıcı TPU'nun SigVerify aşamasından işlemleri tek alıcıdır. Öncelikli bir kuyruk oluşturur ve çakışan işlemlerin işleme ve önceliklendirme yönetimini daha iyi yönetmek için bir bağımlılık grafiği olan prio-grafı kullanır. Bu yeni zamanlayıcı tasarımı, önceki kilit çatışmalarının artmasından kaynaklanan endişeler olmadan daha fazla iş parçacığına izin veren ölçeklenebilirlik ve esneklik sağlar. Merkezi zamanlayıcının ilk dağıtımının, birçok operatör için daha iyi kazançlar elde etmek için daha iyi ödüller ürettiği gösterilmiştir. Solana v1.18 güncellemesi üzerine yapılan önceki Helius gönderimimiz kapsamlı bir şekilde ele alınmıştır.merkezi planlayıcının nasıl çalıştığı.

‍

ZK ElGamal Kanıt programı

ZK Token Proof programı, başlangıçta 1.17 sürümüne dahil edilmesi planlanan ancak şimdi kullanımdan kaldırılan ve daha çok yönlü, uygulama bağımsız bir şekilde yerini alacakZK ElGamal Proof programYeni ZK ElGamal Proof programı, bir ElGamal şifreleme metninde şifrelenen değerlerin aralığının doğruluğunu veya bir halka açık anahtarın geçerliliğini doğrulamak gibi geniş kapsamlı uygulamalara uygulanan ZK Token Proof programının bölümlerini korur. Ancak SPL Token transfer talimatları için gereken sıfır-bilgi kanıtı doğrulaması gibi uygulama özel öğeleri çıkartır. Yeni ZK ElGamal Proof programı, adresin yerleşik program listesine dahil edilecektir.ZkE1Gama1Proof11111111111111111111111111111.

‍

ZK Token Kanıt Programı hakkında daha fazla bilgi edinmek için, bizim okuyun Helius blogundaki orijinal yazı.

Get-Sysvar Sistem Değişkeni Çağrısı

Syscalls, veya sistem çağrıları, işletim sistemi çekirdeğinden hizmet talep eder. Solana bağlamında, bir Syscall, Solana Sanal Makinesi (SVM) içinde çalışan programların dış kaynaklar ve hizmetlerle etkileşimde bulunmasını sağlar.

‍

Sysvars, örneğin son blok hash'i ve dönem ödülleri gibi küme durumu bilgilerini açığa çıkarır. Bu hesaplar bilinen adreslerde yerleştirilir. Programlar, bir Sysvar hesabı aracılığıyla veya bir Syscall aracılığıyla Sysvars'a erişebilir. Zincir üstü programlar, geniş bir kullanım alanı için birçok Sysvars kullanır ve belirli Sysvars ağın işleyişi için esastır.

‍

Get-Sysvar Syscall, başlangıçta önerildiAnza mühendisi Joe Caulfield tarafından SIMD-127Syscall verilerine erişmek için birleşik bir Syscall arayüzü tanıtıldı. Bu yükseltme, SlotHashes ve StakeHistory de dahil olmak üzere önceden erişilemez Sysvar verilerinin alınmasını mümkün kılar. Bu yeni arayüzle, geliştiriciler Sysvar verilerinin belirli parçalarına erişebilirler - örneğin, çağrı yaparakSlotHashes::get_slot(slot)veStakeHistory :: get_entry (dönem)—tüm veri yapılarını çoğaltmaya gerek duymadan.

‍

Güncelleme ayrıca Sysvar veri düzenlerini değiştirirken veya yeni Sysvars eklerken üstünlükleri en aza indirir. Önceden, her yeni Sysvar'ın eklenmesi, zamanla şişen Syscall arayüzünü ve karmaşık bakımı kolaylaştıran sıkı bir ilişki yaratıyordu. Şimdi, tek bir sol_get_Sysvar Syscall, tüm Sysvar arayüzlerine hizmet edecek ve herhangi bir Sysvar'dan tutarlı ve verimli veri almayı mümkün kılacak.

‍

Yeni Syscall'ın kullanıma sunulması, yeni Sysvar'ları değiştirme ve ekleme işlemini basitleştirir. Syscall arayüzünün karmaşıklığını ve bakım gereksinimlerini önemli ölçüde azaltır. Ek olarak, bu güncelleme, BPF programının Sysvar verilerine erişimini genişletmenin yolunu açarak, zincir üstü programların işlem boyutunu etkilemeden daha fazla Sysvar bilgisi okumasını sağlar.

‍

GetEpochStake Syscall

YeniGetEpochStake SyscallGeçerli epok için bir oy hesabının devredilen stakini almak için çok talep edilen bir özelliği tanıtacağız, bu bilgiyi on-chain almak için daha verimli ve doğrudan bir yöntem sağlar.

‍

Şu anda programlar, mevcut dönem için belirli oy hesaplarına devredilen stake hakkındaki gerçek zamanlı verilere erişemiyor ve bu da doğrulayıcı yönetişimi ve ikincil konsensüs mekanizmaları gibi kullanım durumları için bir engel oluşturuyor. Bu verilerin zincir üzerinde sorgulanmasının etkinleştirilmesi, bu uygulamaların kilidini açacak ve gelecekteki kullanım durumlarının önünü açacaktır.

GetEpochStake ile, geliştiriciler 32 bayt oylama hesabı adresi sağlarlar ve sistem çağrısı, sağlanan adresin geçerli bir oylama hesabına veya var olmayan bir hesaba karşılık gelmediği durumlarda sadece 0 döndürürken, oylama hesabına şu anda atanmış toplam etkin payı temsil eden bir u64 tamsayı döndürecektir.

‍

MoveStake ve MoveLamports

İki yeni stake programı talimatı, MoveStake ve MoveLamports, stake hesapları arasında değer transferlerini kolaylaştırmak için tanıtılıyor. Bu talimatlar, ilk olarak önerildiğindeSIMD-0148, geliştiricilere, çekilme yetkilisinin kontrolü olmadan eşleşen yetkilere sahip hesaplar arasında fonların aktarılmasına izin vererek yardımcı olun.

‍

Daha önce, kullanıcı bahislerini yöneten protokoller, bahisleri birden fazla doğrulayıcıya bölme ve düzenli olarak yeniden yönlendirme konusunda zorluklarla karşılaşmıştır. Bir protokol, bir kullanıcının etkinleştirmek için bahisini bölerken, yeni hesap için kira muafiyeti lambalarını finanse etmelidir. Protokol, bu bölünmüş hesapları birleştirdiğinde kira muafiyeti lambalarını geri alamaz.

MoveStake: Bu talimat, aktif stake'in hesaplar arasında taşınmasına olanak tanır, böylece bir aktif hesaptan diğerine veya bir aktif hesaptan bir aktif olmayana transfer edilir ve böylece hesap yeniden etkinleştirilir. Tüm kaynak hesap tahsisatı taşındığında, kaynak hesap etkin olmaz. Tüm senaryolarda muaf kira bakiyesi dokunulmamış kalır ve minimum tahsis kuralları aktif hesaplar için korunur.

‍

MoveLamports: Fazla lamport'ları bir aktif veya aktif olmayan hesaptan başka bir aktif veya aktif olmayan hesaba taşıyın, burada "fazla lamport'lar", ne devredilmiş ne de kira muafiyeti için gerekli olmayan lamport'ları ifade eder. MoveLamports, birleştirilmiş hesaplardan lamportları geri alma ve kullanılmayan fonları konsolide etme gibi temizlik görevlerini sağlar.

‍

Uygulamayı kolaylaştırmak için, bu değişiklikler hesapları etkinleştirme veya devre dışı bırakma veya kısmen aktif olan pay hesaplarını etkilememe konusunda destek sağlamaz. Bu yeni program talimatları mevcut işlevselliği değiştirmez.

‍

Bonus: Solana-SVM Sandığı

Agave 2.0'nın piyasaya sürülmesiyle birlikteyepyeni solana-svm sandığı geliştiricilere, tam doğrulayıcı çerçevesinden bağımsız olarak kolaylaştırılmış bir API aracılığıyla temel SVM bileşenlerine doğrudan erişim sunar. Bu, Solana'nın zincir dışı hizmetler, hafif istemciler, durum kanalları ve toplamalar gibi doğrulayıcının ötesindeki uygulamalar için yüksek performanslı işlem işlemesini açar.

‍

API'yi çalışma zamanının geri kalanından ayırarak, bu kasa, Bank örnekleri gibi bileşenlerin gerekliliğini ortadan kaldırarak işletme fazlasını azaltır. Geliştiriciler artık Solana'nın mainnet-beta'sını destekleyen sağlam bileşenleri kullanarak hafif istemciler, durum kanalları, toplamalar ve zincir-dışı hizmetler gibi özel SVM projeleri inşa edebilirler. Bu API'nin çekirdeği, uygulamaların Solana işlemlerini tam yığın aşağı akışlı Agave bileşenlerinin yanı sıra BPF Yükleyici, eBPF ve sanal makine dahil olmak üzere işlemesi için TransactionBatchProcessor yapılandırmasına olanak tanır.

‍

Yukarıda: işlem toplu işleyicisi (görsel kaynak: Anza)

‍

Ayrıntılı incelemeyi okuyunAnza'nın Yeni SVM API'si Bu heyecan verici gelişmeyle ilgili tüm ayrıntılar için.

‍

Kaldırılan RPC Uç Noktaları

Birden fazla eskimiş ve kullanımdan kaldırılmış v1 Agave RPC uç noktası kaldırıldı. Helius Devrel ekibi bu uç noktaları kullanan tüm müşterilerle iletişime geçti. İç analiz yoluyla daha önce aşağıdaki kaldırılacak uç noktaları aktif olarak kullanan küçük bir müşteri grubu belirledik:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Yine, tüm geliştiricilerin bu çağrılara yapılan referansları kontrol etmelerini ve önerilen değişikliklerle uygun şekilde güncellemelerini şiddetle tavsiye ederiz.

‍

Yukarıda: kaldırılacak eski ve kullanım dışı v1 Agave RPC uç noktalarının tam listesi

‍

N.B. Resimde gösterilen getAccountInfo için alternatif yaklaşımburada bulunabilir.

‍

SDK kırılma değişiklikleri şunları içerir:

‍

• Borsh v0.9 desteği kaldırıldı, lütfen v1 veya v0.10 kullanın (#1440)
• Kopyalama özelliği artık türetilmiyor Kira ve EpochSchedule'da; clone() kullanmaya geçme
• solana-sdk: eski semboller) kaldırıldı
• solana-program: kullanım dışı semboller kaldırıldı

‍

Doğrulayıcı operatörler için, Agave v2.0'ın piyasaya sürülmesiyle kullanımdan kaldırılan birkaç doğrulayıcı argümanı kaldırılacaktır. Bunların tam bir listesi bulunabilirburada.

‍

Sonuç

Agave 2.0 güncellemesi, çok sayıda özellik uygulaması ve çalışma zamanı optimizasyonunu içeren Solana için önemli bir ilerlemeye işaret ediyor. Bu sürüm, güçlü yeni Syscall'lar, genişletilmiş işlevsellik ve kasa yeniden adlandırmaları, kullanımdan kaldırılan RPC yöntemi kaldırmaları ve kolaylaştırılmış doğrulayıcı bağımsız değişkenleri dahil olmak üzere kapsamlı temizlik ile sınırları zorlamaya devam ediyor. Agave 2.0, Solana'nın yeteneklerini genişletir ve performansını ve kullanılabilirliğini iyileştirir. İster geliştirici, ister doğrulayıcı veya aktif kullanıcı olun, Agave 2.0 güncellemesi Solana ekosistemindeki herkes için heyecan verici yeni olanaklar sunuyor.

‍

Ek Kaynaklar / Daha Fazla Okuma

• Agave v2.0 Yayın Tarihleri
• Agave v2.0 Değişiklik Günlüğü
• Agave Sürüm Sürümleri

Açıklama:

1. Bu makale [den tekrar basılmıştırhelius)]. Tüm telif hakları orijinal yazarına aittir [Kayıp]. Bu yeniden basım konusunda itirazlarınız varsa, lütfen iletişime geçin.Gate Öğrenekip, ve bunu hızlı bir şekilde ele alacaklar.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya kopyalanması yasaktır.