Mimari

Solidus, merkeziyetsiz kimlik için özel olarak inşa edilmiş, sıfırdan Rust ile yazılmış yeni bir Layer 1 blok zinciridir. Avalanche’ın, avalanchego’nun veya herhangi bir mevcut zincirin bir çatalı (fork) değildir — onlarla hiçbir kod tabanını paylaşmaz. Tasarımı HotStuff ve Tendermint ailesi BFT konsensüsünden ilham alır ve yol haritası Avalanche’ın subnet desenini (mimari fikri, uygulamayı değil) ödünç alır. Genel amaçlı zincirlerin aksine, her tasarım kararı — konsensüs, durum modeli, işlem türleri — kimlik işlemleri için optimize edilmiştir: DID’ler oluşturmak, kimlik bilgileri düzenlemek ve kanıtları doğrulamak.

Bugün Canlı Olan

Yayınlanmış, testnet’te canlı olan protokol tek bir Layer 1 zincirdir:

• VRF lider seçimi, BLS imza toplama ve 3 zincirli kesinliğe sahip HotStuff’tan ilham alan BFT konsensüsü
• Her blok başlığında sabitlenen, RocksDB üzerinde Sparse Merkle Tree durumu
• Bir akıllı sözleşme sanal makinesi olmadan tipli yerel işlemler — DID yaşam döngüsü, BBS+ kimlik bilgileri, transferler ve stake etme
• Blok, oy ve işlem yayılımı için libp2p ağ oluşturma

“Bugün Canlı Olan” altındaki her şey çalışan kodu tanımlar. Bir sonraki bölümdeki subnet modeli yol haritasıdır, açıkça bu şekilde etiketlenmiştir.

Canlı Layer 1

Temel katman şunları yönetir:

• Doğrulayıcı kümesi yönetimi — hangi düğümlerin konsensüse katıldığı (stake ağırlıklı, kimliğe sabitlenmiş)
• Blok üretimi — işlemlerin sıralanması ve onaylanması
• DID kayıt defteri — DID Belgelerinin ve yaşam döngüsü durumlarının saklanması
• Kimlik bilgisi sabitleme — kimlik bilgisi hash’lerinin, BBS+ taahhütlerinin ve iptallerin kaydedilmesi
• Token transferleri — ücretler ve stake etme için SLDS token hareketleri

Tüm DID’ler ve kimlik bilgisi sabitlemeleri, şu anda rpc.solidus.network’te testnet üzerinde canlı olan katman olan bu zincirde yaşar.

Yol Haritası — Kimlik Subnet’leri

Kimlik Subnet’leri, şu anda yayınlanmamış, planlanan bir gelecek yetenektir. Tasarım, Avalanche tarzı subnet desenini — L1 doğrulayıcı kümesini paylaşan isteğe bağlı zincirler — ödünç alır, ancak bir çatal değil, bağımsız bir uygulamadır. Her subnet, L1’e sabitlenirken kendi doğrulayıcı katılımını, konsensüs parametrelerini ve kimlik bilgisi türlerini taşıyacaktır.

Değerlendirilen örnek kullanım durumları:

• İzinli doğrulayıcılara sahip KYC kimlik bilgileri için özel bir subnet işleten bir finans kurumu
• Tıbbi kayıtlar için özel kimlik bilgisi türlerine sahip bir sağlık subnet’i
• Egemenliğe uygun veri ikametiyle ulusal kimlik kimlik bilgileri için bir devlet subnet’i

Bunlar ileriye dönüktür; şu anki testnet yalnızca tek bir L1 olarak çalışır. Aşamalı plan için aşağıdaki ölçeklendirme yol haritasına bakın.

Konsensüs: HotStuff’tan İlham Alan BFT

Solidus, düşük gecikmeyle deterministik kesinlik elde eden, lider tabanlı bir protokol olan HotStuff’tan ilham alan bir Bizans Hata Toleranslı (BFT) konsensüs motoru kullanır. Bu, Rust ile sıfırdan yazılmış, uygulanmış mekanizmadır. (Erken bir tasarım bunu “Kimlik Kanıtı / PoI” olarak adlandırmıştı; bu isim kimliğe sabitlenmiş doğrulayıcıların niyetini tanımlıyordu, ancak yayınlanan konsensüs HotStuff BFT’dir. Kimliğe sabitleme, doğrulayıcı seçiminin bir özelliğidir, ayrı bir konsensüs algoritması değil.)

Nasıl Çalışır

Her turda, tek bir lider bir blok önerir ve komite oy verir; oylar bir quorum sertifikasında toplanır ve 3 zincirli onay kuralı blokları kesinleştirir:

┌────────────┐   ┌────────────┐   ┌────────────┐
│  PROPOSE   │ → │    VOTE    │ → │   COMMIT   │
│            │   │            │   │            │
│ VRF-elected│   │ Committee  │   │ 3-chain    │
│ leader     │   │ signs (BLS)│   │ rule       │
│ proposes   │   │ → quorum   │   │ finalizes  │
│ a block    │   │ certificate│   │ the block  │
└────────────┘   └────────────┘   └────────────┘

1. Öner (Propose) — tur için VRF ile seçilen lider, bekleyen işlemleri toplar, bunları spekülatif olarak yürütür ve yürütme sonrası durum köküne taahhüt eden bir blok önerir
2. Oy ver (Vote) — doğrulayıcılar bloğu yeniden yürütür, durum kökünü doğrular ve BLS ile imzalar; oyların bir quorumu (2/3+) toplandığında, imzalar tek bir quorum sertifikasında (QC) birleşir
3. Onayla (Commit) — 3 zincirli onay kuralı (round + 2 ≤ highest QC round) bloğu kesinleştirir; kesinlik deterministiktir ve geri döndürülemez

Temel Özellikler

VRF lider seçimi. Her tur için önerici, önceki turun VRF çıktısından tohumlanan bir Doğrulanabilir Rastgele Fonksiyon (Ed25519 tabanlı VRF) ile seçilir. Bu, doğrulanabilir şekilde rastgele ve tahmin edilemezdir — hiçbir doğrulayıcı kendi seçimini garanti edemez veya manipüle edemez. (Yerel test için bir round-robin geliştirme modu vardır ancak üretimde kullanılmaz.)

BLS12-381 imza toplama. Doğrulayıcı oyları ayrı ayrı BLS ile imzalanır ve komite büyüdükçe sertifikaları küçük tutarak QC başına tek, kompakt bir imzada (blst aracılığıyla) toplanır.

3 zincirli kesinlik. Bir blok, üzerine iki QC daha oluşturulduğunda kesinlik kazanır (3 zincirli onay kuralı). Şu anki testnet’te ~2,5 saniyelik blok süreleriyle, kesinlik en iyi durumda yaklaşık 7,5 saniyede gerçekleşir.

Pacemaker ve görünüm değişiklikleri. Bir pacemaker, tur zaman aşımlarını yönetir (2 saniye minimum, 16 saniyeye kadar üstel geri çekilme). Bir lider sessiz kalırsa, doğrulayıcılar bir zaman aşımı sertifikasında (TC) toplanan zaman aşımı oyları yayınlar, bu da durmuş olan lider olmadan turu ilerletir.

Kimliğe sabitlenmiş, stake ağırlıklı doğrulayıcılar. Doğrulayıcılar stake ağırlıklıdır (minimum 1000 SLDS stake) ve kimliğe sabitlenmiştir. Slashing, eşdeğerlik (equivocation) / çift imzalamayı ve çevrimdışı kalmayı kapsar. Bu, HotStuff’un üzerine katmanlanmış bir doğrulayıcı seçim özelliğidir — yerine geçen bir konsensüs algoritması değil.

Bizans hata toleransı. Ağ, f < n/3 olduğu sürece (n = toplam doğrulayıcı) f adede kadar hatalı veya kötü niyetli doğrulayıcıya tolerans gösterir. Şu anki 5 doğrulayıcıyla, ağ 1 hatalı doğrulayıcıya tolerans gösterir.

Doğrusal mesaj karmaşıklığı. Tur başına O(n²) mesaj gerektiren PBFT’nin aksine, QC tabanlı tasarım tur başına mesaj karmaşıklığını O(n)‘de tutar, doğrulayıcı kümesi büyüdükçe daha verimli ölçeklenir.

Şu Anki Testnet Parametreleri

Durum Modeli: Sparse Merkle Tree

Zincir durumu, RocksDB üzerinde kalıcı hale getirilen, BLAKE3 hash’lemeli 256 bitlik bir ağaç olan Jellyfish tarzı bir Sparse Merkle Tree’de (SMT) saklanır. Bu ağacın kök hash’i her blok başlığına dahil edilir ve her blok yüksekliğindeki tüm duruma kriptografik bir taahhüt sağlar.

Ne Saklanır

Durum, tümü tek bir küresel kök altında sabitlenen dört mantıksal alt ağaca (hesaplar, DID’ler, kimlik bilgileri, doğrulayıcılar) ad alanına ayrılmıştır:

• DID kayıt defteri — DID’den DID Belgesine eşleme (doğrulama yöntemleri, kimlik doğrulama anahtarları, devre dışı bırakma durumu)
• Kimlik bilgisi sabitlemeleri — kimlik bilgisi hash’inden düzenleme meta verisine eşleme (düzenleyici DID’i, konu DID’i, BBS+ açık anahtar taahhüdü, zaman damgası, iptal durumu)
• Hesap bakiyeleri — adresten SLDS token bakiyesine ve nonce’a eşleme
• Doğrulayıcı kümesi — geçerli doğrulayıcı açık anahtarları, stake’ler ve itibar

Spekülatif ve Onaylanmış Görünümler

RocksDB deposu (14 sütun ailesi), iki hesap görünümü tutar. Bir blok önerildiğinde ve doğrulandığında, etkileri spekülatif görünüme (CF_ACCOUNTS) yazılır; yalnızca 3 zincirli onay kuralı bloğu kesinleştirdiğinde, dokunulan hesaplar onaylanmış görünüme (CF_COMMITTED_ACCOUNTS) yansıtılır. getBalance / getNonce gibi RPC okumaları onaylanmış görünümü hedefler, bu yüzden çağıranlar hiçbir zaman doğrulanmış ancak henüz kesinleşmemiş blokların etkilerini gözlemlemez.

Neden Sparse Merkle Tree

Bir Sparse Merkle Tree, çoğu yaprağın boş (varsayılan değer) olduğu bir Merkle ağacıdır. Bu yapının kimlik için iki önemli özelliği vardır:

Verimli varlık ve yokluk kanıtları. Bir DID’in durumda var olduğunu (varlık kanıtı) veya bir kimlik bilgisinin iptal edilmediğini (iptal kümesinde yokluk kanıtı) kanıtlayabilirsiniz. Her iki kanıt da boyut olarak O(log n)‘dir.

Deterministik durum kökleri. Aynı durum girdileri kümesi, ekleme sırasından bağımsız olarak her zaman aynı kök hash’i üretir. Bu, tüm doğrulayıcıların aynı işlemleri işledikten sonra aynı durum köküne ulaşacağı anlamına gelir, bu da konsensüs için kritiktir.

BLAKE3 Hash’leme

Solidus, Merkle ağacı için hash fonksiyonu olarak (SHA-256 veya Keccak değil) BLAKE3 kullanır. BLAKE3 şunlar için seçildi:

• Hız — BLAKE3, modern donanımda SHA-256’dan birkaç kat daha hızlıdır
• Paralellik — BLAKE3, büyük hash hesaplamaları için SIMD ve çoklu iş parçacığından yararlanabilir
• Güvenlik — bilinen pratik saldırısı olmayan 256 bit çıktı

Her blok başlığındaki state_root, tüm Sparse Merkle Tree’nin BLAKE3 kök hash’idir.

Blok Yapısı

Her blok şunları içerir:

Block
├── Header
│   ├── height: u64
│   ├── timestamp: u64
│   ├── previous_hash: [u8; 32]
│   ├── state_root: [u8; 32]     ← Sparse Merkle Tree root
│   ├── transactions_root: [u8; 32]
│   ├── proposer: PublicKey
│   └── signature: Signature
└── Body
    └── transactions: Vec<Transaction>

state_root, hafif istemci doğrulamasını mümkün kılan şeydir — hafif bir düğüm, kesinleşmiş bir blok başlığındaki state_root’a karşı bir Merkle kanıtını kontrol ederek herhangi bir durum sorgusunu doğrulayabilir.

İşlem Türleri

Akıllı sözleşme sanal makinesi yoktur. Durum değişiklikleri yalnızca sabit bir dokuz tipli işlem yükü (TxPayload) kümesi aracılığıyla gerçekleşir, her biri yerel Rust mantığı tarafından işlenir. Bu, sıcak yolu hızlı ve denetim yüzeyini küçük tutar.

DidCreate

Zincirde yeni bir DID kaydeder. İşlem, ilk doğrulama yöntemi ve hizmet uç noktalarıyla birlikte DID Belgesini içerir.

DidCreate
├── public_key: [u8; 32]
├── service_endpoints: Vec<Service>
├── nonce: u64
└── signature: Signature

DidUpdate

Mevcut bir DID Belgesine sıralı bir yama kümesini atomik olarak uygular (anahtarları döndürme, hizmet uç noktaları ekleme veya kaldırma).

DidUpdate
├── did: String
├── patches: Vec<DidPatch>
├── nonce: u64
└── signature: Signature

DidDeactivate

Bir DID’i kalıcı olarak devre dışı bırakılmış olarak işaretler. Bu işlem kesinleştikten sonra, DID’in doğrulama yöntemleri temizlenir.

DidDeactivate
├── did: String
├── nonce: u64
└── signature: Signature

CredentialIssue

Zincir üzerinde bir kimlik bilgisi hash’ini sabitler. Kimlik bilgisinin kendisi saklanmaz — yalnızca BLAKE3 hash’i meta veriyle birlikte saklanır.

CredentialIssue
├── credential_hash: [u8; 32]
├── issuer: String
├── subject: String
├── credential_type: String
├── nonce: u64
└── signature: Signature

CredentialIssueBbs

Seçici ifşayı mümkün kılan bir BBS+ kimlik bilgisini sabitler. Düzenleyici, sabit uzunlukta bir mesaj vektörü üzerinden zincir üzerinde bir BBS+ açık anahtarına taahhüt eder; imza ve mesajlar sahibiyle birlikte zincir dışında yaşar. Doğrulayanlar daha sonra seçici ifşa kanıtlarını zincir üzerindeki bbs_pubkey’e karşı kontrol eder.

CredentialIssueBbs
├── subject_did: String
├── credential_type: CredentialType
├── bbs_pubkey: ...
├── nonce: u64
└── signature: Signature

CredentialRevoke

Daha önce düzenlenmiş bir kimlik bilgisini iptal edilmiş olarak işaretler. Bu kimlik bilgisini kontrol eden doğrulayanlar iptali görecektir.

CredentialRevoke
├── credential_hash: [u8; 32]
├── issuer: String
├── nonce: u64
└── signature: Signature

Transfer

Hesaplar arasında SLDS token’larını taşır. İşlem ücretleri ve stake etme için kullanılır.

Transfer
├── to: Address
├── amount: u64
├── nonce: u64
└── signature: Signature

Stake / Unstake

Doğrulayıcı olmaya (veya kalmaya) yönelik SLDS bağlar veya çözer. Aktif olmak için minimum 1000 SLDS stake gereklidir; unbonding 21 günlük bir unbonding süresine tabidir.

Stake                    Unstake
├── amount: u64          ├── amount: u64
├── nonce: u64           ├── nonce: u64
└── signature: Signature └── signature: Signature

Düğüm Türleri

Ağ üç tür düğümü destekler:

Tam Düğüm

Geçerli tam durumu saklar ve tüm blokları ve işlemleri doğrular. Tam düğümler, doğrulayıcı kümesindeyse konsensüse katılır.

• Saklar: geçerli durum ağacı, son bloklar, işlem havuzu
• Doğrular: tüm işlemler ve bloklar
• Sunar: geçerli durum için RPC sorguları

Hafif Düğüm

Yalnızca blok başlıklarını saklar ve durumu Merkle kanıtları aracılığıyla doğrular. Hafif düğümler, tam zinciri saklamadan durumu doğrulaması gereken mobil cüzdanlar ve uygulamalar için uygundur.

• Saklar: yalnızca blok başlıkları
• Doğrular: blok başlığı durum köklerine karşı Merkle kanıtları
• Sunar: bireysel durum sorgularının yerel doğrulaması

Arşiv Düğümü

Tüm blokların ve durum geçişlerinin tam geçmişini saklar. Arşiv düğümleri, blok gezgini ve geçmişe dönük sorgular için kullanılır.

• Saklar: tüm bloklar, tüm geçmiş durum ağaçları
• Doğrular: tüm işlemler ve bloklar
• Sunar: geçmişe dönük sorgular, blok gezgini verisi

Ağ Oluşturma

Eşler arası (peer-to-peer) ağ oluşturma, birkaç davranışı birleştiren libp2p üzerine inşa edilmiştir:

• gossipsub — ağ genelinde blok ve işlem yayılımı
• request-response — doğrulayıcılar arasında oyların ve konsensüs mesajlarının doğrudan değişimi
• identify — eş meta verisi değişimi
• Kademlia DHT — açık eş keşfi, böylece yeni düğümler sabit kodlanmış bir eş listesi olmadan katılabilir

Doğrulayıcılar statik bir komite ağı (mesh) oluşturur; Kademlia ve Identify, açık keşfi ve konsensüse katılmadan zinciri takip eden düğümler için tam düğüm salt-okunur kopya modunu desteklemek üzere eklenmiştir.

Kriptografi

Protokol Uygulaması

Solidus protokolü Rust ile sıfırdan uygulanmıştır. Çalışma alanı bugün 18 crate’e büyümüştür; aşağıdaki 7 tanesi bu sayfada açıklanan canlı, testnet’e hizmet veren protokolü oluşturur. Kalan crate’ler, aşağıdaki Ölçeklendirme Yol Haritasındaki öğelere doğru devam eden çalışmalardır ve yayınlanan kısmın parçası değildir.

DID’ler did:solidus:<network>:<id> olarak çözümlenir. Kaynak kodu github.com/solidusnetwork/protocol  adresinde mevcuttur.

Ölçeklendirme Yol Haritası

Aşağıdaki verim ve gecikme iyileştirmeleri yol haritasıdır, şu anki bir yetenek değildir. Bugünün testnet’i, seri bir yürütücüye ve 4 doğrulayıcılı bir komiteye sahip tek parçalı (single-shard) bir L1’dir. Aşamalı plan, çok fazlı, denetim kapılı bir mühendislik çabası üzerinden ödeme sınıfı verimi (~50K TPS) hedefler:

• Block-STM paralel yürütme — tipli yük işleyicilerini olduğu gibi korurken eşzamanlı işlem yürütme
• HotStuff-2 (2 zincirli kesinlik) artı saniyenin altında bir pacemaker — kesinlik gecikmesini düşürmek için bir konsensüs turunu kısaltmak
• Narwhal tarzı DAG mempool’u — işlem yayılımını konsensüs sıralamasından ayırmak
• Avalanche tarzı subnet’ler — L1 doğrulayıcı kümesini paylaşan isteğe bağlı zincirler (desen, bağımsız olarak uygulanmış — herhangi bir zincirin çatalı değil)
• EVM subnet’i — kimlik ilkellerini önceden derlenmiş sözleşmeler (precompiles) olarak sunan REVM tabanlı bir subnet, böylece L1 sıcak yolu EVM bayt koduna dokunulmadan kalır
• Üretim mainnet’i için 21 doğrulayıcılı, çok bölgeli topoloji

Bunların hiçbiri bugün canlı değildir; her biri mühendislik yol haritasında ayrı, ayrı ayrı kıyaslanan bir aşama olarak çerçevelenmiştir.

Sonraki Adımlar

• Ağ ve Testnet — canlı testnet’e bağlanın, RPC yöntemleri, gezgin
• DID’ler — DID’lerin durum ağacını ve anahtar türetmeyi nasıl kullandığı
• Kimlik Bilgileri — kimlik bilgisi sabitlemelerinin ve iptallerin nasıl çalıştığı
• Başlarken — SDK ile mimarinin üzerine inşa edin