Skip to main content

Ledger Servisi

Temel hedef:

  • Her cihaz icin ayri hash-zincirli denetim izi tutmak
  • Zinciri ledger_transactions tablosunda saklamak
  • Ucuncu taraf firmalarin bu tabloyu kopyalayip bagimsiz dogrulama yapabilmesini saglamak
  • Truth source olarak Qapu tarafindaki ledger_transactions tablosunu kabul etmek

Sorumluluk​

  • window.ready.v1 sonrasinda asenkron/eszamanli ledger yazimini baslatmak
  • Cihaz bazli onceki halka hash'ini (previous_hash) bulmak
  • CPS semasina normalize edilmis payload snapshot'ini almak
  • payload_hash ve transaction_hash uretmek
  • ledger_transactions tablosuna yeni halka kaydini yazmak
  • Basarida ledger.committed.v1, hatada ledger.failed.v1 uretmek
Akis Diyagramlari

Servisin normal ve hata akislarini gormek icin:

Veri Katmanlari Yazim Sirasi

DB ve Kafka arasindaki yazim sirasini sequence diyagraminda gormek icin Veri Katmanlari Arasi Yazim Sirasi sayfasina bakiniz.

Ledger Event Envelopeları

ledger.committed.v1 ve ledger.failed.v1 event payload sözleşmeleri merkezi standart belgesinde tanımlanmıştır. Detaylar için Ledger Event Envelopeları sayfasına bakınız.

SSS

Operasyonel sorular ve edge-case davranislari icin Ledger Servisi SSS sayfasina bakiniz.

Ledger Modeli (V1)​

Bu modelde zincir kayitlari dogrudan DB tablosunda tutulur; ayri bir dagitik chain node zorunlu degildir.

  • Zincir kapsamı: cihaz bazli (device_id)
  • Halka kimligi: transaction_hash
  • Onceki halka: previous_hash
  • Payload: ingest sonrasi CPS normalize cikti + stream baglami

Neden Window Sonrasi?​

Kullanilan modelde ledger snapshot'i yalniz ham veri degil, islenmis ciktilari da icerebilir.

Window sonrasi yazimla birlikte tek payload icinde su aileler bulunabilir:

  • base data (kalibre olcum)
  • synthesis data
  • window data

Boylece tek halka, ilgili stream'in ileri asama islenmis gorunumunu kanitlayabilir.

Islem Akisi​

Data Model Referansi​

Ledger kaydi su tabloda tutulur:

Tablo semasi ve tum kolon detaylari yalniz data-model sayfasinda tutulur. Bu index sayfasi zincirin davranisini ve servis sinirlarini anlatir.

Notlar:

  • Zincirin authoritative kaynagi bu tablodur.
  • Tekillik ve iliski kurallari data-model tarafinda tanimlanir.

Payload Kurali​

Ledger tablosundaki payload alani bos bir ozet degil, CPS semasi cikti snapshot'i olmalidir.

Asgari beklenen baglam:

  • device_id
  • stream_id
  • device_time
  • CPS normalize payload bloklari

Opsiyonel genisletme:

  • base (calibrated)
  • synthesis
  • window

Ucuncu Taraf Dogrulama Modeli​

Ucuncu taraflar ledger kayitlarini kopyalayip su adimlarla dogrulama yapabilir:

  1. payload uzerinden payload_hash yeniden hesapla
  2. previous_hash zincir devamini dogrula
  3. transaction_hash esitligini kontrol et

Bu modelde dis sistemler kendi kopyalarinda denetim yapabilir; resmi truth source Qapu DB'dir.

Topic ve Event Standardi​

  • Kafka topic:
    • qapu.ledger.committed
    • qapu.ledger.failed
  • Event:
    • ledger.committed.v1
    • ledger.failed.v1

Cikti​

Servis ciktisi:

  • ledger_transactions tablosunda cihaz bazli zincir halkasi
  • Ucuncu taraf kopyalanabilir denetim izi
  • Kafka uzerinden commit/fail gorunurlugu