Solidus Protokol Spesifikasyonu

Sürüm: 1.0.0-draft Durum: Taslak Tarih: 2026-03-11 Yazarlar: Solidus Çekirdek Ekibi

İçindekiler

1. Giriş
2. Kriptografik İlkeller
3. DID Yöntemi Spesifikasyonu
4. Doğrulanabilir Kimlik Bilgileri
5. Doğrulama Protokolü
6. Sıfır Bilgi Kanıtları
7. Konsensüs: Kimliğe Sabitlenmiş Doğrulayıcılarla HotStuff’tan İlham Alan BFT
8. Programlanabilirlik ve Durum
9. Kimlik Doğrulama SDK’sı
10. Ağ Katmanı
11. Yönetişim: Solidus İyileştirme Teklifleri
12. Ücret Tarifesi
13. Güvenlik Hususları

1. Giriş

Solidus, merkeziyetsiz bir kimlik ve doğrulanabilir kimlik bilgileri protokolüdür. Merkeziyetsiz kimlik tanımlayıcılarını (DID’ler), W3C uyumlu doğrulanabilir kimlik bilgilerini, sıfır bilgi kanıtlarını ve doğrulayıcı kümesi doğrulanmış insan kimliğine sabitlenmiş (“Kimlik Kanıtı” uygunluk modeli) HotStuff’tan ilham alan bir Bizans Hata Toleranslı (BFT) konsensüs motoru çalıştıran, özel amaçlı bir Layer 1 blok zincirini birleştirerek internet için bir güven katmanı sağlar.

Protokol, uygulamaların kullanıcılar hakkındaki iddiaları — yaş, meslek, konum, itibar — temeldeki kişisel veriyi ifşa etmeden doğrulamasına olanak tanır. Geliştiriciler, Firebase Auth veya Auth0 gibi geleneksel kimlik doğrulama sağlayıcılarıyla aynı şekilde davranan bir SDK aracılığıyla Solidus ile etkileşime girerken, temeldeki doğrulama merkeziyetsiz ve gizliliği koruyan niteliktedir.

1.1 Tasarım İlkeleri

• Öz-egemenlik. Kullanıcılar kimliklerine sahiptir ve onu kontrol eder. Hiçbir merkezi otorite bir DID’e erişimi iptal edemez.
• Varsayılan olarak gizlilik. Seçici ifşa ve sıfır bilgi kanıtları, yalnızca minimum gerekli bilginin ifşa edilmesini sağlar.
• Geliştirici ergonomisi. Auth SDK, tüm protokol karmaşıklığını tanıdık login() / verifyToken() arayüzlerinin arkasında soyutlar.
• Sybil direnci. Kimliğe sabitlenmiş doğrulayıcı modeli (“Kimlik Kanıtı”), doğrulayıcı uygunluğunu doğrulanmış insan kimliğine bağlar, bu da stake-öğütmeyi (stake-grinding) ve bot güdümlü saldırıları önler.
• Deterministik kesinlik. HotStuff’tan ilham alan BFT motoru, kesinliğe bir 3 zincirli onay kuralı aracılığıyla ulaşır; bloklar ve doğrulama sonuçları iki saniyeden kısa sürede kesinleşir.

1.2 Terminoloji

2. Kriptografik İlkeller

Solidus’taki tüm kriptografik işlemler aşağıdaki ilkeller üzerine inşa edilmiştir. Algoritma seçimleri değişmezdir ve yönetişim aracılığıyla değiştirilemez.

2.1 Dijital İmzalar

Algoritma: Ed25519 (RFC 8032)

Ed25519 birincil imza şemasıdır. Tüm DID işlemleri, kimlik bilgisi düzenleme ve doğrulayıcı tasdikleri Ed25519 imzalarını kullanır. Şema, 128 bit güvenlik, hızlı doğrulama ve deterministik imzalama sağlar.

2.2 Şifreleme

Algoritma: Curve25519-XSalsa20-Poly1305 (NaCl crypto_box)

DID denetleyicileri arasında şifrelenmiş eşler arası iletişim için ve aktarım sırasında kimlik bilgisi yüklerini şifrelemek için kullanılır.

2.3 Hash’leme

Algoritma: BLAKE3

BLAKE3, adres türetme, Merkle ağaçları ve içerik adresleme için birincil hash fonksiyonudur. BLAKE3, önemli ölçüde daha yüksek verim ve daha basit bir tasarımla BLAKE2b’nin yerini alır. Dış sistemlerle birlikte çalışabilirliğin gerektirdiği yerlerde, SHA-256 ikincil bir hash olarak kullanılır (özellikle taahhüt şemalarında ve kimlik bilgisi hash kaydında).

Adres türetme yalnızca BLAKE3 kullanır — RIPEMD-160 veya başka bir ikincil hash adımı yoktur:

address = BLAKE3(Ed25519_public_key)[0..20]

2.4 Seçici İfşa ve Sıfır Bilgi Kanıt Sistemleri

2.5 Taahhüt Şemaları

• ZK devrelerinde değerleri gizlemek için Pedersen taahhütleri.
• Zincir üzerinde kimlik bilgisi hash kaydı için SHA-256 taahhütleri.

2.6 Anahtar Türetme

Solidus, yerleşik standartları izleyen hiyerarşik deterministik anahtar türetme kullanır:

1. Bir BIP39 anımsatıcısı (mnemonic) üretin (12 veya 24 kelime).
2. Anımsatıcı tohumundan bir BIP32 ana anahtarı türetin.
3. Farklı DID’ler için, her biri benzersiz bir türetme yolunda olan alt anahtarlar türetin.

mnemonic (BIP39)
    |
    v
master_seed (PBKDF2)
    |
    v
master_key (BIP32)
   / \
  v   v
DID_0  DID_1  ...  (child derivation paths)

2.7 Anahtar Rotasyonu

Anahtar rotasyonu, bir DID denetleyicisinin DID’ini değiştirmeden aktif anahtar çiftini değiştirmesine olanak tanır.

1. Yeni bir Ed25519 anahtar çifti üretin.
2. Geçerli (eski) anahtarla bir anahtar rotasyonu işlemi imzalayın.
3. Rotasyon işlemini ağa gönderin.
4. 7 günlük bir süre tanıma dönemi başlar. Bu dönem boyunca hem eski hem de yeni anahtarlar geçerlidir.
5. Süre tanıma döneminden sonra, eski anahtar devre dışı bırakılır.

Süre tanıma dönemi, kazara kilitlenmeye karşı korur ve hizmetlerin önbelleğe alınmış anahtar materyalini güncellemesine olanak tanır.

2.8 Sosyal Kurtarma

Bir kullanıcı anahtarlarına erişimini kaybederse, sosyal kurtarma gözetimsiz bir yedek sağlar.

• Kullanıcı, kurulum sırasında N vasi (diğer DID’ler) belirler.
• Ana anahtar, Shamir Sır Paylaşımı kullanılarak N paya bölünür.
• Kurtarma, paylarını gönderen M-of-N vasi gerektirir.
• Yeniden oluşturulan anahtar, yeni bir anahtar çiftine anahtar rotasyonu gerçekleştirmek için kullanılır.

Eşik M ve toplam N kullanıcı tarafından seçilir. Tipik bir yapılandırma 3-of-5’tir.

3. DID Yöntemi Spesifikasyonu

3.1 Yöntem Adı

Solidus DID yöntemi, solidus yöntem adını kullanır. W3C DID Yöntemi Kayıt Defterinde kayıtlıdır (w3c/did-extensions PR #713, 2026-07-04’te birleştirildi) — bir kayıt defteri listelemesi, bir W3C standardı veya onayı değil.

3.2 DID Söz Dizimi

did:solidus:<network>:<identifier>

Tanımlayıcı türetme:

identifier = Base58(BLAKE3(Ed25519_public_key)[0..20])

Bu, Bölüm 2.3’te tanımlanan aynı türetmedir — yalnızca BLAKE3, ikincil bir hash adımı yok.

Örnek DID (mainnet):

did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs

Örnek DID (testnet):

did:solidus:testnet:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs

3.3 DID Belgesi

Çözümlenmiş bir DID belgesi, W3C DID Core spesifikasyonuna uyar ve aşağıdaki bölümleri içerir.

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1",
    "https://solidus.network/ns/did/v1"
  ],
  "id": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs",
  "controller": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs",
  "verificationMethod": [
    {
      "id": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs",
      "publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
    }
  ],
  "authentication": [
    "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs#key-1"
  ],
  "assertionMethod": [
    "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs#key-1"
  ],
  "service": [
    {
      "id": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs#solid-pod",
      "type": "SolidPod",
      "serviceEndpoint": "https://pod.solidus.network/5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs"
    }
  ]
}

3.4 DID İşlemleri

3.4.1 Oluşturma

Solidus ağında yeni bir DID kaydedin.

• Ücret: 0,001 SLDS
• Girdi: Ed25519 açık anahtarı, isteğe bağlı hizmet uç noktaları, imzalanmış işlem.
• Süreç: Ağ, tanımlayıcıyı açık anahtardan hesaplar, ilk DID belgesini oluşturur ve zincir üzerinde saklar.
• İdempotenlik: Zaten var olan bir DID’i oluşturmak reddedilir.

3.4.2 Güncelleme

Bir DID belgesini değiştirin (anahtar ekleme/kaldırma, hizmet uç noktalarını güncelleme).

• Ücret: 0,0001 SLDS
• Yetkilendirme: İşlem, belgenin authentication dizisinde listelenen bir anahtarla imzalanmalıdır.
• Kapsam: id hariç, DID belgesindeki herhangi bir alan güncellenebilir.

3.4.3 Devre Dışı Bırakma

Bir DID’i kalıcı olarak devre dışı bırakın. Bu işlem geri döndürülemez.

• Ücret: 0,0001 SLDS
• Yetkilendirme: Bir authentication anahtarıyla imzalanır.
• Etki: DID belgesi devre dışı bırakılmış olarak işaretlenir. Çözümleme, meta veride deactivated: true ile belgeyi döndürür. DID hiçbir zaman yeniden etkinleştirilemez veya yeniden atanamaz.

3.5 DID Çözümleme

DID’ler, RESTful bir uç nokta aracılığıyla çözümlenir.

İstek:

GET /1.0/identifiers/did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs
Accept: application/did+ld+json

Yanıt:

{
  "didDocument": {
    "@context": ["https://www.w3.org/ns/did/v1"],
    "id": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs",
    "verificationMethod": ["..."],
    "authentication": ["..."],
    "assertionMethod": ["..."],
    "service": ["..."]
  },
  "didDocumentMetadata": {
    "created": "2026-01-15T10:30:00Z",
    "updated": "2026-02-20T14:22:00Z",
    "deactivated": false,
    "versionId": "3",
    "nextUpdate": "",
    "equivalentId": []
  },
  "didResolutionMetadata": {
    "contentType": "application/did+ld+json",
    "duration": 42,
    "retrieved": "2026-03-11T08:00:00Z"
  }
}

4. Doğrulanabilir Kimlik Bilgileri

Solidus, zincir üzerinde kayıt, çoklu imza düzenleme ve sıfır bilgi seçici ifşa için protokole özgü uzantılarla W3C Doğrulanabilir Kimlik Bilgileri Veri Modeli v2.0’ı uygular.

4.1 Kimlik Bilgisi Türleri

4.2 Kimlik Bilgisi Şeması

Bir Solidus doğrulanabilir kimlik bilgisi, çoklu doğrulayıcı düzenleme ve zincir üzerinde sabitleme için ek alanlarla W3C VC yapısını izler.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://solidus.network/ns/credentials/v1"
  ],
  "id": "urn:solidus:credential:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "type": ["VerifiableCredential", "KYCCredential"],
  "issuer": {
    "id": "did:solidus:1:validatorSetMultisig",
    "name": "Solidus Validator Consortium"
  },
  "issuanceDate": "2026-03-01T12:00:00Z",
  "expirationDate": "2027-03-01T12:00:00Z",
  "credentialSubject": {
    "id": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs",
    "kycLevel": 2,
    "verifiedAttributes": ["name", "dateOfBirth", "governmentId", "address"],
    "jurisdiction": "US"
  },
  "credentialStatus": {
    "id": "https://solidus.network/revocation/list/42#94567",
    "type": "RevocationList2020Status",
    "revocationListIndex": "94567",
    "revocationListCredential": "https://solidus.network/revocation/list/42"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-01T12:00:00Z",
    "verificationMethod": "did:solidus:1:validatorSetMultisig#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic76UMkqESTgrlCHjMGTow..."
  },
  "solidusExtensions": {
    "onChainHash": "0x7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b",
    "validatorSignatures": [
      {
        "validator": "did:solidus:1:validator1addr",
        "signature": "z3hY7k..."
      },
      {
        "validator": "did:solidus:1:validator2addr",
        "signature": "z9pQ2m..."
      }
    ],
    "consensusRound": 148203
  }
}

4.3 Düzenleme Akışı

Kimlik bilgisi düzenleme, çoklu doğrulayıcı konsensüs sürecini izler:

1. İstek. Kullanıcı (kimlik bilgisi konusu), istenen kimlik bilgisi türünü belirterek ve destekleyici kanıt sağlayarak ağa bir kimlik bilgisi isteği gönderir.

2. Doğrulayıcı seçimi. Ağ, istek için VRF kullanarak bir doğrulayıcı kümesi seçer (bkz. Bölüm 7).

3. Doğrulama. Seçilen her doğrulayıcı, gönderilen kanıtı kimlik bilgisi türü için gereksinimlere karşı bağımsız olarak doğrular.

4. Konsensüs. Doğrulayıcılar tasdiklerini gönderir. Kanıtın geçerli olduğu konusunda 2/3 süper çoğunluk (21 doğrulayıcıdan 14’ü) hemfikir olmalıdır.

5. Düzenleme. Konsensüse ulaşıldığında, çoklu imzalı bir kimlik bilgisi oluşturulur. Kimlik bilgisi, doğrulayıcı konsorsiyum anahtarıyla imzalanır.

6. Teslimat. Düzenlenen kimlik bilgisi, kullanıcının SolidPod’una teslim edilir.

7. Zincir üzerinde kayıt. Kimlik bilgisinin bir SHA-256 hash’i zincir üzerinde kaydedilir ve defterde hiçbir kişisel veri saklamadan kurcalamaya karşı korumalı bir sabitleme sağlar.

4.4 İptal

Solidus, kimlik bilgisi iptali için RevocationList2020 şemasını kullanır.

• Her iptal listesi, zincir üzerinde saklanan sıkıştırılmış bir bit dizesidir.
• Her kimlik bilgisi, bir iptal listesi içindeki belirli bir indekse referans verir.
• Bir kimlik bilgisini iptal etmek için, düzenleyici (veya bir yönetişim eylemi) ilgili biti ayarlar.
• Doğrulayanlar, kimlik bilgisi doğrulaması sırasında iptal listesini kontrol eder.
• İptal kalıcıdır. İptal edilen bir kimlik bilgisi geri alınamaz.

Bit dizesi, zincir üzerindeki depolamayı en aza indirmek için zlib deflation kullanılarak sıkıştırılır. Tek bir iptal listesi 131.072 kimlik bilgisine kadar destekler (16 KiB bit alanı).

5. Doğrulama Protokolü

Doğrulama protokolü, bir güvenen tarafın bir konu hakkındaki iddiaların kanıtını nasıl istediğini ve aldığını tanımlar.

5.1 Doğrulama İsteği

Bir güvenen taraf, ihtiyaç duyduğu iddiaları belirten bir doğrulama isteği oluşturur.

{
  "version": "1.0",
  "requestId": "req-7f8e9d0c-1a2b-3c4d-5e6f-7a8b9c0d1e2f",
  "timestamp": "2026-03-11T10:00:00Z",
  "requester": {
    "did": "did:solidus:1:appServiceDid123",
    "purpose": "Age-gated content access"
  },
  "subject": {
    "did": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs"
  },
  "requiredClaims": [
    {
      "type": "AgeVerificationCredential",
      "constraints": {
        "minimumAge": 18
      },
      "acceptZKProof": true
    },
    {
      "type": "EmailVerificationCredential",
      "constraints": {},
      "acceptZKProof": false
    }
  ],
  "signature": "z3hY7kLmNpQrStUvWxYz...",
  "fee": "0.005"
}

5.2 Doğrulama Yanıtı

{
  "version": "1.0",
  "requestId": "req-7f8e9d0c-1a2b-3c4d-5e6f-7a8b9c0d1e2f",
  "timestamp": "2026-03-11T10:00:01Z",
  "verified": true,
  "claims": [
    {
      "type": "AgeVerificationCredential",
      "satisfied": true,
      "issuer": "did:solidus:1:validatorSetMultisig",
      "issuanceDate": "2026-02-15T08:00:00Z",
      "expirationDate": "2027-02-15T08:00:00Z",
      "proofType": "zk-snark",
      "zkProofReference": "0xabc123..."
    },
    {
      "type": "EmailVerificationCredential",
      "satisfied": true,
      "issuer": "did:solidus:1:validatorSetMultisig",
      "issuanceDate": "2026-01-10T12:00:00Z",
      "expirationDate": "2027-01-10T12:00:00Z",
      "proofType": "direct"
    }
  ],
  "validatorSignatures": [
    {
      "validator": "did:solidus:1:validator1addr",
      "signature": "z9pQ2m..."
    },
    {
      "validator": "did:solidus:1:validator2addr",
      "signature": "zKw4Rx..."
    }
  ],
  "consensusProof": {
    "totalValidators": 21,
    "agreedValidators": 19,
    "threshold": 14,
    "roundId": 148210
  }
}

5.3 Doğrulama Algoritması

Doğrulama algoritması, seçilen her doğrulayıcı tarafından bağımsız olarak yürütülür:

VERIFY(request):
  1. Parse the verification request.
  2. Validate the requester's signature and fee payment.
  3. Resolve the subject's DID document.
  4. For each required claim in request.requiredClaims:
     a. Retrieve the relevant credential from the subject's SolidPod
        or from on-chain references.
     b. Verify the credential signature against the issuer's DID document.
     c. Check that the credential has not expired (current time < expirationDate).
     d. Query the revocation registry; reject if the credential's bit is set.
     e. Evaluate constraint satisfaction:
        - If acceptZKProof is true, verify the ZK proof against public inputs.
        - If acceptZKProof is false, verify claim values directly.
     f. Record the claim result (satisfied or unsatisfied) with metadata.
  5. Aggregate per-claim results into a final verified boolean.
     - verified = true only if ALL required claims are satisfied.
  6. Sign the verification result.
  7. Submit the signed result to the consensus round.

Tüm doğrulayıcılar gönderdikten sonra, ağ sonuçları toplar. 21 doğrulayıcıdan en az 14’ü sonuç üzerinde hemfikir olursa, konsensüs kanıtı oluşturulur ve yanıt istekte bulunana döndürülür.

6. Sıfır Bilgi Kanıtları (Yol Haritası)

Sıfır bilgi kanıtları, bir konunun temeldeki veriyi ifşa etmeden bir iddianın doğru olduğunu kanıtlamasına olanak tanır. Solidus’un bugünkü seçici ifşası BBS+ imzalarını kullanır (testnet’te canlı); bu bölümde açıklanan Groth16 tabanlı yüklem kanıtı devreleri yol haritasıdır, henüz yayınlanmamıştır.

6.1 Yaş Doğrulama (ZK-SNARK, Yol Haritası)

Yaş doğrulama devresi, bir konunun yaşının gerçek doğum tarihini ifşa etmeden bir eşiği aştığını kanıtlar.

Devre tanımı (Groth16):

Herkese açık girdiler:

• commitment: Doğum tarihine Pedersen taahhüdü.
• ageThreshold: Gereken minimum yaş (ör. 18).
• currentDate: Kanıtın üretildiği tarih.

Özel girdiler (tanık):

• birthdate: Gerçek doğum tarihi.
• randomness: Pedersen taahhüdünde kullanılan körleştirme faktörü.

Kısıtlamalar:

1. Pedersen(birthdate, randomness) == commitment
2. currentDate - birthdate >= ageThreshold * 365.25 days
3. birthdate is a valid calendar date

Doğrulayan, kanıtı herkese açık girdilere karşı kontrol eder. Kanıt geçerliyse, konunun yaşı eşiği karşılar. Doğrulayan hiçbir zaman gerçek doğum tarihini öğrenmez.

6.2 Konum Doğrulama (ZK-SNARK)

Konum doğrulama devresi, bir konunun tam koordinatlarını ifşa etmeden tanımlanmış bir coğrafi bölge içinde olduğunu kanıtlar.

Herkese açık girdiler:

• commitment: Koordinatlara Pedersen taahhüdü.
• regionPolygon: Kabul edilen coğrafi bölgeyi tanımlayan bir dizi köşe.

Özel girdiler (tanık):

• latitude: Gerçek enlem.
• longitude: Gerçek boylam.
• randomness: Körleştirme faktörü.

Kısıtlamalar:

1. Pedersen((latitude, longitude), randomness) == commitment
2. point_in_polygon((latitude, longitude), regionPolygon) == true

6.3 BLS İmza Toplama (konsensüste yayınlandı)

Doğrulayıcılar, kimlik anahtarları olan Ed25519’un yanı sıra bir BLS12-381 anahtarı tutar ve konsensüs oylarını bununla imzalar. 2/3 süper çoğunluk bir blok için oy verdiğinde, bireysel BLS imzaları tek bir kompakt çoklu imzada (Boneh-Lynn-Shacham) toplanır — quorum sertifikası (§7.4). Bu, testnet’te canlıdır ve konsensüs motorunun çekirdeğidir, yol haritası değildir; ayrıca çoklu doğrulayıcı tasdiklerinin kaydedildiği her yerde zincir üzerindeki depolamayı ve doğrulama maliyetini azaltır.

14 doğrulayıcıdan toplanmış bir imza, imzalayan sayısından bağımsız olarak sabit zamanda doğrulanır.

6.4 Aralık Kanıtları için Bulletproofs

Bulletproofs, tam bir ZK-SNARK devresinin aşırı olacağı genel amaçlı aralık kanıtları için kullanılır. Tipik kullanımlar şunları içerir:

• Bir itibar puanının bir eşiğin üzerinde olduğunu kanıtlamak.
• Tam bakiyeyi ifşa etmeden bir hesap bakiyesinin bir minimumu aştığını kanıtlamak.
• Bir kimlik bilgisinin bir tarih aralığında düzenlendiğini kanıtlamak.

Bulletproofs, Groth16 SNARK’larından farklı olarak güvenilir bir kurulum gerektirmez.

7. Konsensüs: Kimliğe Sabitlenmiş Doğrulayıcılarla HotStuff’tan İlham Alan BFT

Solidus ağı, Rust ile temel ilkelerden inşa edilmiş, HotStuff’tan ilham alan bir Bizans Hata Toleranslı (BFT) konsensüs motoru çalıştırır — mevcut herhangi bir zincirin çatalı değil, özel amaçlı bir Layer 1’dir. Üzerine katmanlanan, Sybil direncini doğrulanmış insan kimliğine köklendiren “Kimlik Kanıtı” (PoI) doğrulayıcı-uygunluğu modelidir. PoI ayrı bir konsensüs algoritması değildir; kimin doğrulayabileceğini yönetir, BFT motoru ise blokların nasıl anlaşmaya varıldığını yönetir.

7.1 Özellikler

7.2 Doğrulayıcı Uygunluğu

Solidus stake ağırlıklı doğrulayıcı kademeleri kullanır. Her kademenin farklı bir minimum stake’i ve önerilen donanımı vardır; tüm kademeler aynı tam düğümü çalıştırır ve konsensüse katılır — kademe, farklı bir konsensüs rolü değil, stake ağırlığını belirler.

Tüm kademeler şunları gerektirir:

KYC gereksinimi, her doğrulayıcının benzersiz bir doğrulanmış insana karşılık gelmesini sağlar. Bu, tek bir varlığın sermayeden bağımsız olarak birden çok doğrulayıcı çalıştırmasını (Sybil saldırısı) önler.

Çalışma süresi notu: %95 minimum (≈36 saat/ay tolerans), merkeziyetsiz doğrulayıcı düğümlerine uygulanır. Solidus tarafından işletilen altyapı (auth ağ geçidi, API uç noktaları) %99,5’lik bir SLO hedefler, ancak bu merkezi altyapı için bir hizmet düzeyi taahhüdüdür, merkeziyetsiz bir ağ gereksinimi değil.

7.3 Doğrulayıcı Seçimi

Her doğrulama isteği veya blok önerisi için, subnet başına 100 doğrulayıcıya kadar uygun doğrulayıcı havuzundan 21 doğrulayıcıdan oluşan bir komite seçilir. 21 doğrulayıcılı komite, tur başına aktif komitedir; 100 doğrulayıcılı sınır, komite üyelerinin çekildiği subnet başına maksimum uygun havuzdur.

Seçim mekanizması: Doğrulanabilir Rastgele Fonksiyon (VRF).

Her uygun doğrulayıcı, VRF’yi kendi özel anahtarı ve geçerli tur tohumuyla değerlendirir. En düşük VRF çıktılarına sahip 21 doğrulayıcı seçilir. VRF çıktısı, herhangi bir gözlemcinin doğrulayabileceği bir seçim kriptografik kanıtı görevi görür.

vrf_output, vrf_proof = VRF_evaluate(validator_private_key, round_seed)
selected = (vrf_output < selection_threshold)

Tur tohumu, öngörülemezliği sağlamak için önceki blok hash’inden türetilir.

7.4 BFT Konsensüs Algoritması

Konsensüs motoru HotStuff’tan ilham alır: BLS toplanmış oylara, quorum sertifikalarına (QC’ler) ve deterministik kesinlik için bir 3 zincirli onay kuralına sahip lider tabanlı bir protokol.

PROPOSE
  - The round leader (selected by VRF, see 7.3) speculatively executes
    the block's transactions, commits to the resulting state root in the
    header, and broadcasts the proposal (carrying the parent QC).

VOTE
  - Each committee validator re-executes the block, verifies the state
    root and the leader's VRF proof, checks the locked-QC safety rule,
    then broadcasts a BLS-signed vote on the block hash.

QUORUM CERTIFICATE (QC)
  - When a validator collects votes from a 2/3 supermajority (14 of 21),
    it aggregates the BLS signatures into a single QC certifying the block.
    The QC becomes the parent QC for the next round, forming a chain.

3-CHAIN COMMIT
  - A block is finalized once it is extended by a chain of QCs two rounds
    deep (round + 2 ≤ highest certified round). On commit the block and
    its receipts are persisted and finality is irreversible.

Görünüm değişiklikleri (pacemaker): Bir tur, pacemaker zaman aşımı içinde bir QC üretmezse, doğrulayıcılar BLS imzalı zaman aşımı oyları yayınlar; bunların 2/3 quorumu, görünümü VRF sırasındaki bir sonraki lidere ilerleten bir Zaman Aşımı Sertifikası (TC) oluşturur. Pacemaker, kötü ağlar altında canlılığı kurtarmak için zaman aşımında üstel geri çekilme kullanır.

7.5 Slashing Koşulları

Protokol kurallarını ihlal eden doğrulayıcılar, stake edilen SLDS’lerinin bir yüzdesi slashing edilerek cezalandırılır.

Slashing edilen fon dağıtımı:

• Slashing edilen SLDS’nin %50’si yakılır (toplam arzdan kaldırılır).
• %50’si, slashing kanıtını gönderen raporlayana verilir.

7.6 Konsensüs Eşiği

2/3 süper çoğunluk (21’de 14) eşiği tüm konsensüs kararlarına uygulanır:

• Blok kesinleştirme.
• Doğrulama sonucu anlaşması.
• Kimlik bilgisi düzenleme anlaşması.

Bu eşik, komitenin 1/3’ünden azının Bizans olduğu varsayımı altında güvenliği sağlar.

8. Programlanabilirlik ve Durum

8.1 Durum Modeli (yayınlandı)

Solidus’ta bugün genel amaçlı bir sözleşme sanal makinesi yoktur. Durum geçişleri yerel ve tiplidir: protokol, her biri özel bir Rust işleyicisine gönderilen sabit bir işlem yükü kümesi sunar — Transfer, DID işlemleri (DidCreate/DidUpdate/DidDeactivate), kimlik bilgisi işlemleri (CredentialIssue, BBS+ düzenleme, iptal) ve stake etme (Stake/Unstake). Konsensüs açısından kritik yolda güvenilmeyen bayt kodu yoktur.

Dünya durumu, RocksDB üzerinde kalıcı hale getirilen (birden çok sütun ailesi: hesaplar, onaylanmış hesaplar, DID’ler, kimlik bilgileri, bloklar, makbuzlar, Merkle düğümleri, stake etme ve daha fazlası), BLAKE3 ile anahtarlanmış bir Sparse Merkle Tree’dir (SMT). Her blok, başlığında yürütme sonrası SMT kökünü sabitler; doğrulayıcılar oy vermeden önce kökü yeniden yürütür ve doğrular. Yürütme şu anda deterministik bir seri döngüdür; paralel yürütme (Block-STM) performans yol haritasındadır.

8.2 Programlanabilirlik yol haritası (subnet aracılığıyla EVM)

Genel amaçlı akıllı sözleşmeler, L1 doğrulayıcı kümesini bir Avalanche tarzı subnet deseni altında paylaşan bir EVM subnet’i (REVM yürütme motoru) olarak yol haritasında teslim edilir — L1’e cıvatalanmış bir WASM sanal makinesi değil ve temel katmanda bir EVM değil. L1 sıcak yolu sözleşme bayt koduna dokunulmadan kalır; kimlik ilkelleri, L1’in kesinleşmiş DID/kimlik bilgisi köklerine karşı dahil olma kanıtlarını doğrulayan önceden derlenmiş sözleşmeler (precompiles) aracılığıyla Solidity’ye sunulur. Bu bölümün geri kalanı (§8.3–§8.5), yol haritası programlanabilirlik yüzeyini açıklar; bu tasarım niyetidir, yayınlanan davranış değil.

8.3 Kimlik Host Fonksiyonları (yol haritası)

Sözleşme çalışma zamanı, kimlik farkında host fonksiyonlarını (subnet modelinde EVM precompile’ları) sunar. Bunlar, sözleşmelerin temeldeki kimlik bilgisi belgelerine erişmeden işlem katılımcıları hakkındaki iddiaları doğrulamasına olanak tanır.

Veri izolasyonu ilkesi: Sözleşmeler vc_hash, issuer_did, schema_id ve zk_proof_reference alır. Hiçbir zaman tam kimlik bilgisi belgesini, konunun kişisel verisini veya iddiayı değerlendirmek için gerekenin ötesinde herhangi bir bilgiyi almazlar.

8.4 Gaz Ölçümü (yol haritası)

EVM subnet’inde, yürütme gaz cinsinden ölçülür: her opcode ve precompile çağrısının önceden tanımlanmış bir maliyeti vardır ve bir çağrının tükettiği toplam, gönderenin gaz sınırını aşamaz. Kimlik precompile’ları, gerektirdikleri dahil olma kanıtı doğrulamasını ve durum aramalarını yansıtmak için temel opcode’lardan daha fazla maliyete sahiptir.

8.5 Örnek: Kimlik Bilgisine Göre Erişim Kontrolü (yol haritası)

Aşağıdaki açıklayıcı sözleşme — yol haritasındaki kimlik-precompile yüzeyine karşı yazılmıştır — bir fonksiyonu geçerli bir doktor lisansı kimlik bilgisine sahip olanlarla kısıtlar:

use solidus_sdk::prelude::*;
 
#[solidus_contract]
impl MedicalRecords {
    /// Only callable by a DID that holds a valid doctor_license credential.
    #[access_control]
    pub fn view_patient_record(&self, patient_id: PatientId) -> Result<Record, Error> {
        // The #[access_control] macro expands to:
        //   if !ctx.has_claim("doctor_license_valid") {
        //       return Err(Error::Unauthorized);
        //   }
 
        let record = self.storage.get(&patient_id)?;
        Ok(record)
    }
 
    /// Manual claim check example (without macro).
    pub fn prescribe_medication(
        &self,
        ctx: &Context,
        patient_id: PatientId,
        medication: Medication,
    ) -> Result<PrescriptionId, Error> {
        if !ctx.has_claim("doctor_license_valid") {
            return Err(Error::Unauthorized("Valid doctor license required"));
        }
        if !ctx.has_claim("prescribing_authority") {
            return Err(Error::Unauthorized("Prescribing authority required"));
        }
 
        let prescription = Prescription::new(patient_id, medication, ctx.sender_did());
        self.storage.insert(prescription.id(), &prescription)?;
        Ok(prescription.id())
    }
}

8.6 EVM Subnet’i (yol haritası)

Programlanabilirlik, L1 doğrulayıcı kümesini paylaşan özel bir EVM subnet’i (REVM yürütme motoru) olarak teslim edilir — temel katmandaki bir yan yürütücü değil, birincil akıllı sözleşme yüzeyi. Solidity sözleşmeleri, standart ETH tarzı araçlarla (MetaMask, ethers, Hardhat, Foundry) dağıtılır; kimlik host fonksiyonları, L1’in kesinleşmiş DID/kimlik bilgisi köklerine karşı dahil olma kanıtlarını doğrulayan EVM precompile’ları olarak sunulur. L1’in kendisi hiçbir sözleşme bayt kodu çalıştırmaz, bu da gecikmesini ve denetim yüzeyini korur.

9. Kimlik Doğrulama SDK’sı

Solidus Auth SDK’sı, uygulama geliştiricilerine tanıdık bir kimlik doğrulama arayüzü sağlar. Geliştiricinin bakış açısından, Firebase Auth veya Auth0 ile aynı şekilde çalışır: login()’i çağırın, bir JWT alın ve arka uçta verifyToken()’ı kullanın.

9.1 Kimlik Doğrulama Akışı

+--------+        +---------+       +------------+       +----------+
|  App   |        | Wallet  |       | Auth Bridge|       | Solidus  |
|        |        |         |       | Gateway    |       | Network  |
+---+----+        +----+----+       +-----+------+       +----+-----+
    |                  |                  |                    |
    | 1. login({       |                  |                    |
    |  requiredClaims})|                  |                    |
    |----------------->|                  |                    |
    |                  | 2. Generate VP   |                    |
    |                  |  (select VCs,    |                    |
    |                  |   sign)          |                    |
    |                  |----------------->|                    |
    |                  | 3. POST          |                    |
    |                  |  /auth/verify    |                    |
    |                  |                  | 4. Validate VP     |
    |                  |                  |    signature       |
    |                  |                  |------------------->|
    |                  |                  | 5. Check revocation|
    |                  |                  |    status          |
    |                  |                  |------------------->|
    |                  |                  | 6. Confirm claims  |
    |                  |                  |<-------------------|
    |                  |                  |                    |
    |                  | 7. Return JWT    |                    |
    |                  |<-----------------|                    |
    | 8. JWT with DID  |                  |                    |
    |  and claims      |                  |                    |
    |<-----------------|                  |                    |
    |                  |                  |                    |

1. Uygulama, gereken iddiaların bir listesiyle login()’i çağırır.
2. Kullanıcının cüzdanı uygun doğrulanabilir kimlik bilgilerini seçer, bir Doğrulanabilir Sunum (VP) oluşturur ve imzalar.
3. SDK, VP’yi POST /auth/verify aracılığıyla Auth Bridge Gateway’e gönderir.
4. Ağ geçidi, VP imzasını konunun DID belgesine karşı doğrular.
5. Ağ geçidi, dahil edilen her kimlik bilgisi için iptal durumunu kontrol eder.
6. Ağ geçidi, gereken iddiaların karşılandığını onaylar.
7. Ağ geçidi, konunun DID’ini ve doğrulanmış iddiaları içeren kısa ömürlü bir JWT düzenler.
8. Uygulama JWT’yi alır ve onu oturum yönetimi için kullanır.

9.2 Auth Ağ Geçidi

Auth Bridge Gateway, OIDC uyumludur. Standart OpenID Connect uç noktalarını sunar:

9.3 Tarayıcı SDK’sı

import { SolidusAuth } from '@solidus-network/auth';
 
const auth = new SolidusAuth({
  appId: 'app-xyz-123',
  network: 'mainnet',
  gatewayUrl: 'https://auth.solidus.network',
});
 
// Login with required claims
const session = await auth.login({
  requiredClaims: ['email_verified', 'age_over_18'],
});
 
console.log(session.did);    // "did:solidus:1:5dK3fP7v..."
console.log(session.claims); // ["email_verified", "age_over_18"]
console.log(session.jwt);    // "eyJhbGciOiJFZDI1NTE5..."
 
// Check current session
const current = await auth.getSession();
if (current) {
  console.log('Authenticated as', current.did);
}
 
// Logout
await auth.logout();

9.4 Arka Uç SDK’sı

import { SolidusVerifier } from '@solidus-network/auth/server';
 
const verifier = new SolidusVerifier({
  gatewayUrl: 'https://auth.solidus.network',
});
 
// Middleware: verify JWT on every request
app.use(async (req, res, next) => {
  const token = req.headers.authorization?.replace('Bearer ', '');
  try {
    req.identity = await verifier.verifyToken(token);
    next();
  } catch (err) {
    res.status(401).json({ error: 'Invalid or expired token' });
  }
});
 
// Route-level claim enforcement
app.get('/medical/records', verifier.requireClaim('doctor_license_valid'), (req, res) => {
  // Only reachable if the caller has a valid doctor license credential
  const records = getRecordsFor(req.query.patientId);
  res.json(records);
});

9.5 JWT Yapısı

Auth Gateway tarafından düzenlenen JWT aşağıdaki iddiaları içerir:

{
  "iss": "https://auth.solidus.network",
  "sub": "did:solidus:1:5dK3fP7vLm8Qw2xNz9Rb4YcJ6tHgAs",
  "aud": "app-xyz-123",
  "iat": 1741683600,
  "exp": 1741687200,
  "solidus_claims": ["email_verified", "age_over_18"],
  "solidus_network": "1",
  "nonce": "a1b2c3d4e5f6"
}

JWT, ağ geçidinin anahtar çiftini kullanarak Ed25519 ile imzalanır. Açık anahtar, çevrimdışı doğrulama için JWKS uç noktasında mevcuttur.

10. Ağ Katmanı

Solidus ağ katmanı, eşler arası iletişimi, mesaj yayılımını ve taşıma güvenliğini yönetir.

10.1 Taşıma

Çerçeve: libp2p

10.2 Eş Keşfi

Eş keşfi iki aşamalı bir yaklaşım kullanır:

1. Bootstrap düğümleri. Yeni düğümler, Solidus Vakfı tarafından bakımı yapılan bir dizi iyi bilinen bootstrap düğümüne bağlanır. Bootstrap düğüm adresleri, istemci yazılımında sabit kodlanmıştır ve her sürümde güncellenir.

2. Dağıtık Hash Tablosu (DHT). Bootstrap düğümlerine bağlandıktan sonra, yeni düğüm Kademlia DHT aracılığıyla yönlendirme tablosunu doldurur. Sonraki eş keşfi tamamen merkeziyetsizdir.

10.3 Mesaj Yayılımı (Gossip)

Mesajlar (işlemler, bloklar, doğrulama istekleri), bir gossip protokolü kullanarak ağ üzerinden yayılır:

1. Kaynak düğüm mesajı imzalar.
2. Mesaj, rastgele seçilen 8 eşe (fanout = 8) yayınlanır.
3. Alan her eş, mesaj imzasını doğrular, ardından onu kendi eşlerinden 8’ine iletir (göndereni hariç tutarak).
4. Yayılım üsteldir: 8 -> 64 -> 512 -> …
5. 10.000 düğüme kadar olan ağlar için tam ağ kapsamı 500 milisaniyeden kısa sürede elde edilir.

Tekilleştirme: Her düğüm, yinelenen mesajların işlenmesini veya iletilmesini önlemek için kısa ömürlü bir mesaj kimliği önbelleği (TTL = 30 saniye) tutar.

10.4 Ağ Güvenliği

11. Yönetişim: Solidus İyileştirme Teklifleri

Solidus protokolü, resmi bir yönetişim süreci aracılığıyla gelişir. Değişiklikler, tanımlanmış bir yaşam döngüsüne göre önerilir, tartışılır, oylanır ve etkinleştirilir.

11.1 SIP Yaşam Döngüsü

DRAFT -> REVIEW -> DISCUSSION (30 days) -> VOTE -> IMPLEMENTATION -> ACTIVATION

11.2 Oylama

• Oylama gücü, stake edilen SLDS ile ağırlıklandırılır.
• Bir SIP, %67 onay ile geçer (baş sayısına göre değil, stake ağırlığına göre ölçülür).
• Quorum: toplam stake edilen SLDS’nin en az %30’u oylamaya katılmalıdır.

11.3 Değiştirilebilir Parametreler

Aşağıdaki protokol parametreleri SIP yönetişimi aracılığıyla değiştirilebilir:

• İşlem ve kimlik bilgisi ücretleri.
• Doğrulayıcı stake gereksinimleri.
• Slashing yüzdeleri.
• Konsensüs komite boyutu ve eşikleri.
• Gaz ağırlık tarifeleri.
• İptal listesi kapasitesi.

11.4 Değişmez Özellikler

Aşağıdaki özellikler genesis’te sabittir ve yönetişim aracılığıyla değiştirilemez:

• Kriptografik algoritmalar. Ed25519, BLAKE3, BBS+, BLS12-381 ve diğer yayınlanmış çekirdek ilkeller değiştirilemez. (Gerekirse post-kuantum algoritmalara geçiş, bir SIP oylaması değil, geniş bir sosyal konsensüse sahip bir hard fork gerektirir.)
• Toplam token arzı. SLDS’nin maksimum arzı sabittir.
• Çekirdek güvenlik özellikleri. BFT güvenlik garantileri, 2/3 süper çoğunluk gereksinimi ve kimlik ile doğrulayıcı uygunluğu arasındaki bağ.

12. Ücret Tarifesi

Tüm ücretler SLDS cinsinden ifade edilir ve işlem göndereni tarafından ödenir.

12.1 DID İşlemleri

12.2 Kimlik Bilgisi Düzenleme

12.3 Doğrulama İstekleri

Doğrulama isteği ücretleri istekte bulunan tarafından belirlenir ve dahil olan kimlik bilgisi türleri için minimum ücreti karşılamalıdır. Doğrulayıcılar, tazminat olarak ücretin bir payını alır.

12.4 Ücret Dağıtımı

Ücret miktarları SIP aracılığıyla yönetişimle ayarlanabilir (bkz. Bölüm 11.3).

Not: Bu işlem başına ücret dağıtımı (%70/%20/%10), kurumsal abonelikler ve diğer işlem dışı protokol gelir akışlarına uygulanan protokol düzeyindeki gelir dağıtımından (%40 stake edenler / %30 hazine / %25 yakım / %5 geliştirme fonu) ayrıdır.

13. Güvenlik Hususları

13.1 Tehdit Modeli

Protokol aşağıdaki düşman yeteneklerini varsayar:

• Düşman, doğrulayıcı komitesinin %33’üne kadar (21’de 7) kontrol edebilir.
• Düşman, tüm ağ trafiğini gözlemleyebilir.
• Düşman, birden çok kimlik oluşturarak Sybil saldırıları girişiminde bulunabilir.
• Düşman, doğrulama istekleri genelinde kullanıcı etkinliğini ilişkilendirmeye çalışabilir.

13.2 Azaltımlar

13.3 Gizlilik Garantileri

• Kişisel veri hiçbir zaman zincir üzerinde saklanmaz. Yalnızca kimlik bilgisi hash’leri kaydedilir.
• ZK kanıtları, veri ifşası olmadan iddia doğrulamasına olanak tanır.
• Seçici ifşa, kullanıcıların tüm kimlik bilgilerini değil, yalnızca istenen iddiaları sunmasına izin verir.
• SolidPod, kullanıcının münhasır kontrolü altındadır; hiçbir üçüncü taraf, kullanıcının rızası olmadan ona erişemez.

13.4 Kriptografik Varsayımlar

Protokolün güvenliği şunlara dayanır:

• Curve25519 üzerinde Ayrık Logaritma Probleminin zorluğu (Ed25519 ve Curve25519 şifrelemesi için).
• BLAKE3 ve SHA-256’nın çakışma direnci.
• Eşleştirme dostu gruplarda q-SDH varsayımı altında BBS+ imzalarının sahtelenemezliği (seçici ifşa kimlik bilgileri için).
• Computational Diffie-Hellman varsayımı altında BLS imzalarının sahtelenemezliği.

Ek A: Tel Biçimi Özeti

Tüm protokol mesajları, HTTP API’leri üzerinden iletildiğinde JSON-LD olarak ve libp2p gossip katmanı üzerinden iletildiğinde CBOR olarak serileştirilir. CBOR, konsensüs açısından kritik yolda kompaktlık ve ayrıştırma hızı için kullanılır.

Ek B: Sürüm Geçmişi

Bu belge, Solidus Protokolü için yetkili spesifikasyondur. Uygulamalar, burada açıklanan davranışlara uymalıdır. Belirsizlik olduğunda, referans uygulama geçerlidir.