Ana içeriğe geç

Doğrulayıcı Çalıştırma

Bu kılavuz, QoreChain ağında bir doğrulayıcı (validator) oluşturmayı, havuz sınıflandırma tasarımını anlamayı, kuantuma dayanıklı güvenlik için bir PQC anahtarı kaydetmeyi ve düğümünüzü izlemeyi kapsar.

not

Bu kılavuz qorechain-vladi ana ağını (EVM zincir kimliği 9801) hedefler; 29 Haziran 2026'dan beri canlı olup v3.2.1 düğüm sürümünü çalıştırır (konsensüs kuralları, 2.981.742 yüksekliğinde uygulanan v3.2.0 yükseltmesinden gelir). qorechain-diana test ağı (EVM zincir kimliği 9800, v3.2.2), canlıya geçmeden önce kurulumunuzu prova etmek için önerilir. Hedef ağınız için uygun --chain-id değerini kullanın. Blok süreleri farklıdır: ana ağda yaklaşık 3,2 sn, test ağında yaklaşık 1,0 sn; bu nedenle blok sayılarını her ağ için ayrı ayrı süreye çevirin.

Kaynak derlemesi değil, yayın (release) ikili dosyasını kullanın

Bir doğrulayıcı, canlı manifestte (https://download.qore.host/mainnet/latest.json; bkz. Düğüm Çalıştırma) belirtilen yayın sürümü qorechaind dosyasını çalıştırmalıdır. Herkese açık kaynaktan derlenen bir ikili dosyada stub keeper'lar bulunur ve kuantum sonrası imzalayıcı yoktur: ağın konsensüs durumunu yeniden üretemez ve create-validator ile diğer tüm Cosmos yolu işlemlerinin gerektirdiği hibrit imzayı oluşturamaz (bkz. Kaynaktan Derleme). Yeni bir ana ağ düğümü v3.2.0 veya üstünü gerektirir; sistem saatini NTP ile senkronize tutun, çünkü v3.2.1'den itibaren düğüm, saati 60 saniyeden fazla saptığında durur.

Bu sayfanın hangi bölümleri canlı

Blok üretimi standart, stake ağırlıklı doğrulayıcı rotasyonunu kullanır; slashing ve yönetişim ise aşağıda gösterilen parametrelerle standart Cosmos SDK modüllerini kullanır. Triple-Pool CPoS mantığı (havuz sınıflandırması, havuz ağırlıklı blok önereni seçimi, bonding eğrisi ve kademeli slashing) x/qca modülünde uygulanmıştır ve parametreleri zincir üzerindedir, ancak henüz blok üretimine, ödüllere veya slashing'e bağlı değildir. Bu konulardaki bölümler tasarımı anlatır; bugün havuz üyeliğinin veya itibarın blok önerme payınızı ya da ödüllerinizi değiştireceğini varsayarak plan yapmayın.


Ön Koşullar​

  • Tam olarak senkronize edilmiş bir yayın sürümü qorechaind düğümü (bkz. Ana Ağa Bağlanma veya prova için Test Ağına Bağlanma)
  • Operatör hesabında kayıtlı bir ML-DSA-87 PQC anahtarı (bkz. PQC Anahtar Kaydı) — create-validator hibrit imzayı gerektirir
  • İlk öz-delegasyon için en az 100.000 QOR (100.000.000.000 uqor) bakiyeli, fonlanmış bir hesap — bu minimum zincir üzerinde zorunlu kılınır ve bunun altında create-validator reddedilir
  • Hesabınızda etkin bir validator_operator lisansı — aşağıdaki nota bakın; bu lisans olmadan, ne kadar QOR öz-bağlarsanız bağlayın, create-validator ErrUnauthorized hatasıyla başarısız olur
  • Staking ve Delegasyon modeline aşinalık

Doğrulayıcı Oluşturma​

Lisans kontrolü: validator_operator​

create-validator, ikisi de zincir üzerinde uygulanan iki bağımsız kontrolle kısıtlanır ve ikisine de ihtiyacınız vardır — yalnızca büyük bir öz-bağlama yeterli değildir:

  1. Minimum 100.000 QOR öz-bağlama.
  2. İşlemi gönderen hesapta etkin bir validator_operator lisansı.

Lisanslar zincir üzerinde lisans otoritesi tarafından verilir (başvuru adımları için bkz. Tools Hub); kendi lisansınızı GET /qorechain/license/v1/check/{grantee}/validator_operator ile kontrol edin. Bir lisansın expires_at değeri bir tarih veya süre değil, bir blok yüksekliğidir — 0 süresiz geçerlilik anlamına gelir. Lisans eksik veya süresi dolmuşsa, ne kadar öz-bağlama yaparsanız yapın create-validator ErrUnauthorized hatasıyla başarısız olur; iyi fonlanmış bir denemenin açıklanamaz görünüp başarısız olmasının en yaygın tek nedeni budur. Bu kontrol, özellikle EVM yürütme yolunun bunu görüp uygulayamaması nedeniyle vardır (oradaki tek bir ante dekoratörü bunu tamamen atlar) — staking ve doğrulamanın yalnızca Native yolunda kalmasının nedenlerinden biri de budur.

Bir validator.json dosyası oluşturun (bayrak tabanlı biçim mevcut SDK'dan kaldırılmıştır):

{
"pubkey": {"@type": "/cosmos.crypto.ed25519.PubKey", "key": "<base64 key from: qorechaind comet show-validator>"},
"amount": "100000000000uqor",
"moniker": "my-validator",
"identity": "",
"website": "",
"security": "",
"details": "",
"commission-rate": "0.10",
"commission-max-rate": "0.20",
"commission-max-change-rate": "0.01",
"min-self-delegation": "1"
}

Ardından işlemi oluşturup imzalayın (her Cosmos yolu işlemi gibi hibrit imza gerektirir; bkz. İşlem Komutları):

qorechaind tx staking create-validator validator.json \
--from mykey --chain-id qorechain-vladi \
--gas 600000 --fees 60000uqor \
--generate-only > tx.json

qorechaind tx pqc cosign tx.json --from mykey --pqc-key mypqc --chain-id qorechain-vladi

Ağ ücret tabanı gas birimi başına 0,1 uqor'dur; dolayısıyla 600.000 gas limiti en az 60.000 uqor gerektirir.

validator.json alanıAçıklama
amountÖz-delegasyon miktarı — minimum 100.000 QOR (100000000000uqor)
pubkeyDoğrulayıcı konsensüs açık anahtarı (ed25519)
monikerDoğrulayıcınız için okunabilir ad
commission-rateBaşlangıç komisyon oranı (ör. 0.10 = %10)
commission-max-rateMaksimum komisyon oranı (oluşturulduktan sonra değişmez)
commission-max-change-rateMaksimum günlük komisyon değişim oranı
min-self-delegationOperatörün öz-delege etmesi gereken minimum token miktarı

İşlem onaylandıktan sonra doğrulayıcınızı doğrulayın:

qorechaind query staking validator $(qorechaind keys show mykey --bech val -a)

Havuz Sınıflandırması​

Tasarım; blok üretiminde henüz etkin değil

Aşağıdaki havuz sınıflandırması x/qca tasarımıdır. Parametreleri zincir üzerindedir (qorechaind query qca config), ancak blok önerenler henüz havuza göre seçilmez ve havuzlar ödülleri veya slashing'i henüz değiştirmez.

QoreChain'in x/qca (Quantum Consensus Allocation) modülü bir üç havuzlu sınıflandırma sistemi tanımlar. Her 1.000 blokta bir (ana ağın 3,2 sn'lik bloklarında yaklaşık 54 dakika), doğrulayıcıların itibarlarına ve stake'lerine göre üç havuzdan birine yeniden sınıflandırılması amaçlanır:

HavuzKriterBlok Tahsisi
RPoS (Reputation Proof-of-Stake)İtibar >= 70. yüzdelik dilim VE stake >= medyanBlokların %40'ı
DPoS (Delegated Proof-of-Stake)Toplam delegasyon >= 10.000 QORBlokların %35'i
PoS (Proof-of-Stake)Kalan tüm aktif doğrulayıcılarBlokların %25'i

Tasarımda, her havuz içindeki blok önerenler etkin stake'leri ile orantılı ağırlıklı rastgele seçimle belirlenir; böylece hem yüksek itibarlı hem de yüksek delegasyonlu doğrulayıcılar adil temsil edilirken, daha küçük doğrulayıcılar da katılabilir.

Havuz Yapılandırmasını Sorgulama​

# Pool weights and classification parameters (there is no per-validator classification query)
qorechaind query qca config

JSON-RPC üzerinden:

Henüz sunulmuyor: yayımlanmış hiçbir düğüm sürümü qor_ JSON-RPC ad alanını sunmaz; bu nedenle bu çağrı bugün tüm herkese açık uç noktalarda -32601 (method not found) döndürür. Bkz. qor_ ad alanı.

curl -X POST http://localhost:8545 \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "qor_getPoolClassification",
"params": ["qorvaloper1..."],
"id": 1
}'

Bağlanma Eğrisi (Bonding Curve)​

Tasarım; henüz etkin değil

Bağlanma eğrisi x/qca içinde uygulanmıştır ancak henüz ödül dağıtımına bağlı değildir; staking ödülleri bugün standart distribution modülünü izler. Aşağıdaki formül tasarımdır.

Bir doğrulayıcının staking ödülünün, birden fazla faktörü birleştiren bir bağlanma eğrisi ile belirlenmesi tasarlanmıştır:

R = beta * S * (1 + alpha * log(1 + L)) * Q(r) * P(t)
DeğişkenAçıklama
RÖdül miktarı
betaTemel ödül oranı
SEtkin stake
alphaSadakat ölçekleme sabiti
LSadakat süresi (kesintisiz staking süresi)
Q(r)İtibar kalite faktörü, aralık [0.75 - 1.25]
P(t)Protokol aşaması çarpanı (ağ yaşam döngüsü boyunca ayarlanır)

Önemli çıkarımlar:

  • Sadakat süresi bonusu: Tasarım, kesintisiz staking süresi için logaritmik bir terim ekler.
  • İtibar kalite faktörü: 0.75 (zayıf itibar) ile 1.25 (mükemmel itibar) arasında değişir. İtibar formülü ağırlıkları zincir üzerindedir (qorechaind query reputation params).
  • Protokol aşaması çarpanı: Ağ farklı aşamalardan (başlangıç, büyüme, olgunluk) geçerek olgunlaştıkça ayarlanır.

Slashing​

Bu yazının hazırlandığı sırada geçerli olan ve canlı olarak sorgulanabilen temel ihlal cezaları:

qorechaind query slashing params
ParametreDeğer
İmzalanan blok penceresi10.000 blok (ana ağda blok başına 3,2 sn ile yaklaşık 8,9 saat; test ağında daha kısa)
Pencere başına gereken minimum imza%5 (min_signed_per_window = 0.05): bir doğrulayıcı, son 10.000 bloğun %5'inden azını imzaladığında, yani %95'ten fazlasını kaçırdığında hapse atılır
Çevrimdışı kalma hapis süresi600 saniye (10 dakika)
Çevrimdışı kalma slashing oranıStake'in %1'i
Çifte imza slashing oranıStake'in %5'i

Hapse atılma, sabit cezalı sabit 10 dakikalık bir zaman aşımıdır. Unbonding 21 gün (1.814.400 sn) sürer, aktif küme en fazla 100 doğrulayıcı barındırır (max_validators) ve her delegatörün en fazla 7 unbonding kaydı olabilir (max_entries). Aşağıdaki kademeli model ayrı bir tasarımdır; tekrarlayan ihlallerin üzerine ek, artan sonuçlar katmanlayacaktır ve henüz bağlı değildir.

Kademeli Slashing​

Tasarım; henüz etkin değil

Kademeli slashing x/qca içinde uygulanmıştır ancak slashing'e bağlı değildir: yürürlükteki cezalar yukarıdaki tablodaki standart x/slashing değerleridir. Aşağıdaki parametreler tasarımdır (qorechaind query qca config).

Kademeli slashing tasarımı, tekrarlayan ihlallerde cezaları kademeli olarak artırır, ancak doğrulayıcıların zamanla toparlanmasına da izin verir:

penalty = base_rate * escalation^effective_count * severity
ParametreDeğer
Olay başına maksimum cezaStake'in %33'ü
Yarı ömür (decay half-life)100.000 blok
Çevrimdışı kalma önem derecesi1.0
Çifte imza önem derecesi2.0
Hafif istemci saldırısı önem derecesi3.0
  1. Her ihlal, etkin sayacı artırır. Her ihlal (çevrimdışı kalma, çifte imza vb.) doğrulayıcının etkin sayacını artırır ve bu da gelecekteki cezaları etkiler.

  2. Ceza üstel olarak artar. Ceza, yukarıdaki formüle göre etkin sayaca bağlı olarak artar; bu nedenle tekrar eden ihlaller çok daha büyük cezalarla karşılaşır.

  3. Etkin sayaç zamanla azalır. Etkin sayaç, 100.000 bloklık bir yarı ömürle azalır (ana ağın 3,2 sn'lik bloklarında yaklaşık 3,7 gün), bu da doğrulayıcıların iyi davranış süresinin ardından toparlanmasına imkân tanır.

  4. Tekil olaylar ile tekrarlayan ihlaller. Kazara oluşan tek bir çevrimdışı kalma olayı küçük bir cezayla sonuçlanırken, tekrarlayan ihlaller üstel olarak artan sonuçlar doğurur.


PQC Anahtar Kaydı​

Post-kuantum kriptografik (PQC) açık anahtarınızı — ML-DSA-87 — bir doğrulayıcı lisansına başvurmadan veya create-validator komutunu çalıştırmadan önce kaydedin. Bu isteğe bağlı değildir ve otomatik gerçekleşmez: zincir, her Cosmos yolu işleminde hibrit bir PQC imzası zorunlu kılar, MsgCreateValidator muaf tutulan mesaj türlerinden biri değildir ve hiçbir hesap anahtarını otomatik olarak kaydetmez: kayıt, her hesabın (doğrulayıcı operatörleri dahil) önceden kendisinin göndermesi gereken açık bir işlemdir. Önce anahtarı oluşturun:

qorechaind tx pqc gen-key mypqc # prints the public key (hex); stored unencrypted under ~/.qorechaind/pqc/
qorechaind tx pqc register-key-v2 dilithium5 <pubkey-hex> hybrid \
--from mykey \
--chain-id qorechain-vladi \
--gas 600000 --fees 60000uqor \
-y
ParametreAçıklama
dilithium5Algoritma (ML-DSA-87)
<pubkey-hex>Hex kodlamasında 2592 bayt uzunluğunda ML-DSA-87 açık anahtarı
hybridAnahtar türü (hybrid = hem klasik hem PQC)

(qorechaind tx pqc register-key <pubkey-hex> hybrid, Dilithium-5 için eşdeğer eski biçimdir.)

--gas değerini açıkça belirtin

ML-DSA-87 açık anahtarı 2.592 bayt uzunluğundadır ve bunu zincir üzerine yazmak varsayılan 200.000 gas limitini aşabilir (ana ağdaki kayıtlar 220.000 ile 350.000 arasında gas kullanmıştır). --gas 600000 (veya daha yüksek) belirtilmeden işlem, belirsiz bir out of gas hatasıyla başarısız olabilir. Ücret en az gas limitinin 0,1 uqor ile çarpımı kadar olmalıdır; dolayısıyla --gas 600000 için --fees 60000uqor veya daha fazlası gerekir.

Kaydı doğrulayın:

qorechaind query pqc account <account-address>

~/.qorechaind/pqc/ altındaki anahtar dosyası, hesabın kuantum sonrası imzalama anahtarıdır: onu anımsatıcı (mnemonic) gibi yedekleyin ve mümkün olduğunca konsensüs anahtarını çalıştıran makineden uzak tutun. Kurtarma ve rotasyon için bkz. Kuantum Sonrası İmzalama.


İzleme​

Prometheus Metrikleri​

QoreChain, 26660 portunda Prometheus metrikleri sunar:

http://localhost:26660/metrics

Uç noktayı, config.toml dosyasındaki [instrumentation] bölümünde prometheus = true ayarlayarak etkinleştirin. Düğüm, konsensüs motorunun standart metriklerini (blok yüksekliği, konsensüs turları, doğrulayıcı kümesi, eşler, mempool) sunar; düğümünüzün neleri sunduğunu curl -s localhost:26660/metrics | grep -i -E 'height|validator|peers|mempool' ile listeleyin. Doğrulayıcı başına imzalama sağlığı en güvenilir şekilde zincirin kendisinden okunur (aşağıdaki Sağlık Kontrollerine bakın); çünkü hapse atmaya karar veren, zincirin kendi kaydıdır.

İtibar Parametrelerini Sorgulama​

# Formula weights only (there is no per-validator score query)
qorechaind query reputation params

JSON-RPC üzerinden:

Henüz sunulmuyor: yayımlanmış hiçbir düğüm sürümü qor_ JSON-RPC ad alanını sunmaz; bu nedenle bu çağrı bugün tüm herkese açık uç noktalarda -32601 (method not found) döndürür. Bkz. qor_ ad alanı.

curl -X POST http://localhost:8545 \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "qor_getReputationScore",
"params": ["qorvaloper1..."],
"id": 1
}'

Sağlık Kontrolleri​

# Node status
qorechaind status | jq '.sync_info'

# Validator signing info (uptime, missed blocks)
qorechaind query slashing signing-info $(qorechaind comet show-validator)

# Check if your validator is in the active set
qorechaind query staking validators --status BOND_STATUS_BONDED | grep "my-validator"

Operasyonel En İyi Uygulamalar​

  1. Sentry düğüm mimarisi kullanın. Doğrulayıcınızı DDoS saldırılarından korumak için sentry düğümlerinin arkasında çalıştırın. Yalnızca sentry düğümlerini genel ağa açık tutun.

  2. Uyarı sistemi kurun. Kaçırılan bloklar, düşük çalışma süresi ve beklenmedik yeniden başlatmalar için uyarılar yapılandırın. Birkaç kaçırılan blok normaldir; sürekli kaçırmalar slashing tetikler.

  3. Yüksek çalışma süresini koruyun. Sürekli kesinti, doğrulayıcının hapse atılmasına (son 10.000 bloğun %5'inden azının imzalanması) ve slashing'e yol açar; bkz. Slashing.

  4. Yazılımı güncel tutun. QoreChain sürümlerini takip edin ve güncellemeleri hızlıca uygulayın. Zincir yükseltmeleri için doğrulayıcı topluluğuyla koordinasyon sağlayın.

  5. Anahtarlarınızı güvende tutun. Doğrulayıcı konsensüs anahtarı için bir donanım güvenlik modülü (HSM) veya uzak imzalayıcı kullanın. Anahtarları asla düğümle aynı makinede saklamayın.

  6. Önce bir PQC anahtarı kaydedin. Operatör hesabının, bir doğrulayıcı oluşturabilmesi veya başka herhangi bir Cosmos yolu işlemi gönderebilmesi için kayıtlı bir ML-DSA-87 anahtarına ihtiyacı vardır.

  7. Saati senkronize tutun. Bir NTP istemcisi çalıştırın; v3.2.1'den itibaren düğüm, saati 60 saniyeden fazla saptığında durur.


Doğrulayıcı Komutları Referansı​

# Edit validator metadata
qorechaind tx staking edit-validator \
--new-moniker "new-name" \
--website "https://myvalidator.com" \
--details "Description of my validator" \
--from mykey --gas 400000 --fees 40000uqor --generate-only > tx.json

# Unjail after downtime slashing
qorechaind tx slashing unjail --from mykey --gas 300000 --fees 30000uqor --generate-only > tx.json

# Delegate additional stake
qorechaind tx staking delegate $(qorechaind keys show mykey --bech val -a) \
500000000uqor --from mykey --gas 400000 --fees 40000uqor --generate-only > tx.json

# Withdraw rewards and commission
qorechaind tx distribution withdraw-rewards $(qorechaind keys show mykey --bech val -a) \
--commission --from mykey --gas 400000 --fees 40000uqor --generate-only > tx.json

# Sign and broadcast any of the above (hybrid signature):
qorechaind tx pqc cosign tx.json --from mykey --pqc-key mypqc --chain-id qorechain-vladi

Ağ ücret tabanı gas birimi başına 0,1 uqor'dur. Kayıtlı PQC anahtarı olmayan bir operatör hesabı unjail işlemini yine klasik yöntemle gönderebilir; bir anahtar kaydedildikten sonra ise her işlem (unjail dahil) hibrit imza gerektirir.


Bağlı Ağları Doğrulama​

Henüz etkin bir bağlı ağ yok

Köprü modülü ana ağda ve test ağında dağıtılmıştır, ancak hiçbir köprü rotası etkin değildir: 37 zincir yapılandırmasının tamamı pending durumundadır, kayıtlı köprü doğrulayıcısı yoktur, hiçbir köprü işlemi hiç oluşturulmamıştır ve hiçbir IBC kanalı yoktur. Aşağıdaki çerçeve tasarımı anlatır; bugün bağlı bir ağda doğrulanacak bir şey yoktur.

Tasarım (v3.1.80 zincir sürümünden beri), bir QoreChain doğrulayıcısının köprü aracılığıyla bağlanan ağların doğrulanmasına da yardımcı olmasına olanak tanır. Bu, lisansa bağlı ve isteğe bağlı (opt-in) bir işlevdir:

  1. Lisansa sahip olun. Doğrulayıcının, hedef ağ için etkin bir validator_<chain> (veya qcb_bridge) lisansına sahip olması gerekir. Orkestratör, bu lisans olmadan harici bir istemciyi başlatmayı reddeder (fail-closed).
  2. Etkinleştirme istemciyi otomatik olarak sağlar. Lisans etkinleştirildiğinde QoreChain, ilgili ağın istemcisini düğümünüzde sağlar — sabitlenmiş istemciyi indirir, yapılandırmasını oluşturur ve QoreChain'in orkestrasyonu altında çalıştırır. Etkinleştirme öncesinde hiçbir şey indirilmez.
  3. Ağın anahtarlarını ve stake'ini siz sağlayın. Harici ağın doğrulayıcı/stake ve imzalama anahtarları ağ başına operatör tarafından sağlanır; QoreChain, sürücü çerçevesini ve zorunlu lisans kontrolünü sunar, harici zincirdeki stake'inizi değil.

37 köprü ağının tümü için sürücüler mevcuttur; bir doğrulayıcının nasıl katılabileceğine göre sınıflandırılır:

SınıfKatılımÖrnekler
İzinsiz (permissionless) doğrulayıcıStake yapıp çalıştırmaSolana, Ethereum, Avalanche, Sui, Aptos, Cardano, Tezos, Algorand, Starknet
Sınırlı / seçilmiş / kabul temelliBir sınıra veya seçime tabi stakeBSC, Polygon, Polkadot, TRON, Sei, Injective, NEAR, Hedera
L2 tam düğümTam düğüm çalıştırma (staking yok)Optimism, Base, zkSync Era, Linea, Scroll, Arbitrum
Staking yapmayan / güven listesiStaking yapmadan gözlemleme / katılımBitcoin, Filecoin, XRPL, Stellar
not

İstemci sürüm sabitlemeleri en iyi çaba (best-effort) esasına dayanır; üretim ortamında etkinleştirmeden önce hedef ağınız için üst akış (upstream) istemci sürümünü doğrulayın.

Sonraki Adımlar​