# Formize ile Akıllı Sözleşme Tabanlı Sentetik Veri Lisanslama ve Uygulama

Sentetik veri, gizliliği korurken AI modellerinin eğitilmesi için temel bir yapı haline geldi, ancak veri üreticilerinin hızlı artışı yeni lisanslama ve uyumluluk sorunları ortaya çıkarıyor. Geleneksel lisans anlaşmaları statik, manuel olarak uygulanıyor ve genellikle sentetik veri boru hatlarının dinamik doğasına ayak uyduramıyor.  

**Akıllı sözleşmeler**—blokzincirde kendini çalıştıran kod—lisans şartlarını kodlaştırabilir, kullanım politikalarını zorlayabilir ve değiştirilemez denetim izleri sağlayabilir. **Formize** ile birleştirildiğinde, veri yönetişimi için sıfır‑güven orkestrasyon platformu olan Formize, organizasyonların **gerçek‑zamanlı, otomatik ve kanıtlanabilir uyumlu** sentetik veri paylaşımını iç ekipler, ortaklar ve dış pazar yerleri arasında gerçekleştirmesini sağlar.

Bu makalede şunları ele alacağız:

1. Sentetik veri lisanslamasının programlanabilir, değiştirilemez bir katmana neden ihtiyaç duyduğunu açıklamak.  
2. Formize’ın sıfır‑güven veri dokusunu blokzincir akıllı sözleşmeleriyle birleştiren mimariyi detaylandırmak.  
3. Mermaid diyagramlarıyla gösterilen tam uçtan‑uç iş akışını adım adım yürütmek.  
4. Uyumluluk, denetim ve iş faydalarını vurgulamak.  
5. Pratik uygulama rehberi ve Solidity‑tabanlı bir lisans sözleşmesi örnek kodu sunmak.

---

## 1. Sentetik Veri Ekosistemlerindeki Lisanslama Açığı

| Zorluk | Geleneksel Yaklaşım | Akıllı‑Sözleşme‑Destekli Yaklaşım |
|-----------|----------------------|---------------------------------|
| **Dinamik kullanım hakları** | PDF’lerde sabit maddeler, manuel güncellemeler | Zincir üzerinde sorgulanabilir ve değiştirilebilir programatik haklar |
| **Denetlenebilirlik** | Kağıt izleri, e‑posta logları | Değiştirilemez blokzincir defteri |
| **Uygulama** | Manuel izleme, yasal uyarılar | Sözleşme mantığıyla otomatik iptal ve ceza |
| **Çapraz‑yargı uyumu** | Ülke‑spesifik hukuki inceleme | Akıllı sözleşmeler yargı‑spesifik kuralları gömebilir ve otomatik sürümleyebilir |

Sentetik veri üreticileri (ör. GAN’lar, difüzyon modelleri) günde milyarlarca kayıt üretebilir. Lisanslama bu nedenle **ölçeklenebilir**, **makine‑okunabilir** ve **veri‑erişim katmanında uygulanabilir** olmalıdır. Formize zaten **sıfır‑güven veri erişim kontrol** motoru ile her isteği kimlik doğruluyor, kökeni kaydediyor ve politika uyumluluğunu doğruluyor. Blokzincir‑destekli bir akıllı sözleşme katmanı ekleyerek, lisans kararlarını **hukuk ekibinden çalışma zamanı motoruna** taşıyabilir, her veri okuma/yazma işleminin belirlenen şartlara uygun olmasını sağlayabiliriz.

---

## 2. Mimari Genel Bakış

Çözüm üç sıkı bir şekilde bağlanmış katmandan oluşur:

1. **Sentetik Veri Üretim Katmanı** – AI modelleri sentetik veri setleri üretir.  
2. **Sıfır‑Güven Yönetişim Katmanı (Formize)** – Kimlik doğrulama, nitelik‑tabanlı erişim kontrolü (ABAC) ve gerçek‑zamanlı politika değerlendirmesini yönetir.  
3. **Blokzincir Akıllı‑Sözleşme Katmanı** – Lisans şartlarını, kullanım sayaçlarını ve uygulama mantığını depolar.

### 2.1 Veri Akış Diyagramı

```mermaid
graph LR
    A["Sentetik Veri Üreticisi"] --> B["Formize Veri Hub'ı"]
    B --> C["Akıllı Sözleşme Kayıt Defteri (Ethereum/Polygon)"]
    D["Veri Tüketicisi"] --> B
    B --> E["Erişim Karar Motoru"]
    E --> F["Veri Teslimi"]
    C --> G["Denetim Günlüğü (IPFS)"]
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px
    style C fill:#ff9,stroke:#333,stroke-width:2px
    style D fill:#cfc,stroke:#333,stroke-width:2px
    style E fill:#fcc,stroke:#333,stroke-width:2px
    style F fill:#9ff,stroke:#333,stroke-width:2px
    style G fill:#ddd,stroke:#333,stroke-width:2px
```

* **Adım 1 – Kayıt**: Sentetik bir veri seti oluşturulduğunda, üretici Formize’ın **Veri Hub API**’sını çağırarak varlığı kaydeder. Formize meta verileri (hash, şema, köken) saklar ve veri kimliğini sözleşme adresine bağlayan bir **lisans sözleşmesi** otomatik olarak seçilen blokzincirde oluşturur.  
* **Adım 2 – Tüketim Talebi**: Bir tüketici Formize üzerinden kimlik doğrulaması yapar (OAuth, SSO veya merkeziyetsiz DID). Talep, tüketicinin cüzdan adresini içerir.  
* **Adım 3 – Politika Değerlendirmesi**: Formize, tüketicinin mevcut lisans durumunu (ör. kalan kota, sona erme) öğrenmek için akıllı sözleşmeye sorgu gönderir. **Erişim Karar Motoru**, bu bilgiyi iç ABAC kuralları (rol, amaç, coğrafya) ile birleştirir.  
* **Adım 4 – Uygulama**: Sözleşme bir ihlal (ör. kota aşıldı) gösteriyorsa, Formize talebi reddeder ve isteğe bağlı olarak zincir üzerinde bir ceza (ör. token kesintisi) tetikler.  
* **Adım 5 – Denetim**: Her karar, sözleşme durumu anlık görüntüsüyle birlikte değiştirilemez bir **IPFS‑destekli denetim günlüğüne** yazılır ve blokzincir işlem hash’iyle referanslanır.

---

## 3. Akıllı Sözleşme Tasarım Kalıpları

Aşağıda, temel lisanslama özelliklerini yakalayan minimal bir **Solidity** sözleşmesi yer alıyor. Sözleşme kavramları göstermek amacıyla basit tutulmuştur; üretim ortamlarında yükseltilebilirlik (ör. OpenZeppelin Transparent Proxy) ve rol‑tabanlı erişim kontrolü eklenmelidir.

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract SyntheticDataLicense {
    address public owner;          // Veri sağlayıcı
    address public dataHash;       // Veri setinin IPFS CID'si (basitlik için address olarak saklanıyor)
    uint256 public expiry;         // Unix zaman damgası
    uint256 public maxAccesses;    // Toplam izin verilen okuma sayısı
    uint256 public usedAccesses;   // Sayaç

    mapping(address => bool) public whitelisted; // Opsiyonel tüketici beyaz listesi

    event AccessGranted(address indexed consumer, uint256 remaining);
    event LicenseRevoked(address indexed consumer, string reason);

    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }

    constructor(address _dataHash, uint256 _expiry, uint256 _maxAccesses) {
        owner = msg.sender;
        dataHash = _dataHash;
        expiry = _expiry;
        maxAccesses = _maxAccesses;
    }

    function whitelistConsumer(address consumer) external onlyOwner {
        whitelisted[consumer] = true;
    }

    function revokeConsumer(address consumer, string calldata reason) external onlyOwner {
        whitelisted[consumer] = false;
        emit LicenseRevoked(consumer, reason);
    }

    function requestAccess() external returns (bool) {
        require(block.timestamp <= expiry, "License expired");
        require(usedAccesses < maxAccesses, "Quota exhausted");
        require(whitelisted[msg.sender], "Not whitelisted");

        usedAccesses += 1;
        emit AccessGranted(msg.sender, maxAccesses - usedAccesses);
        return true;
    }

    // Formize'ın lisans durumunu sorgulaması için okuma‑only fonksiyon
    function getLicenseStatus() external view returns (uint256 remaining, bool active) {
        remaining = maxAccesses - usedAccesses;
        active = (block.timestamp <= expiry) && (remaining > 0);
    }
}
```

**Önemli noktalar**:

* **Değiştirilemez şartlar** – `expiry` ve `maxAccesses` dağıtımda belirlenir ve yeni bir sözleşme versiyonu olmadan değiştirilemez.  
* **Dinamik iptal** – Sağlayıcı, `revokeConsumer` ile bir tüketicinin haklarını anında iptal edebilir.  
* **Zincir üzeri olaylar** – `AccessGranted` ve `LicenseRevoked` olayları yayınlanır, böylece Formize gerçek‑zamanlı güncellemeleri dinleyebilir.  
* **Hafif sorgu** – `getLicenseStatus` Formize’ın gaz harcamadan (sadece okuma) sözleşme durumunu almasını sağlar.

---

## 4. Formize’ın Akıllı Sözleşme ile Entegrasyonu

Formize’ın **Politika Motoru**, aşağıdaki özelliklere sahip bir **Web3 Adaptörü** ile genişletilebilir:

1. **Sözleşme durumunu Redis önbelleğine** alarak milisaniye seviyesinde gecikme sağlar.  
2. **WebSocket sağlayıcı (Alchemy, Infura vb.)** üzerinden sözleşme olaylarını dinler.  
3. **DID‑to‑wallet kayıtları** sayesinde zincir üzeri adresleri Formize kullanıcı kimlikleriyle eşleştirir.

### 4.1 Örnek Politika Kuralı (YAML)

```yaml
policy:
  name: synthetic_data_license_check
  description: Erişim izni vermeden önce zincir üzeri lisansı doğrula
  conditions:
    - type: web3
      contract: "{{dataset.contractAddress}}"
      method: getLicenseStatus
      args: []
      expect:
        active: true
        remaining: ">0"
  actions:
    - allow: true
    - log: true
```

Bir istek geldiğinde Formize bu kuralı değerlendirir. Eğer sözleşme `active: false` ya da `remaining: 0` döndürürse, istek reddedilir ve bir **denetim olayı** kaydedilir.

---

## 5. Uyumluluk ve İş Faydaları

| Fayda | Açıklama |
|-------|----------|
| **Regülasyon uyumu** | Değiştirilemez lisans kayıtları, GDPR, CCPA ve AI‑özel düzenlemeler gibi veri kullanımının kanıtlanmasını gerektiren yasalara uygunluk sağlar. |
| **Hukuki yükün azalması** | Otomatik iptal, manuel “durdur ve vazgeç” mektuplarına ihtiyaç duymaz. |
| **Gelir modelinin etkinleştirilmesi** | Sağlayıcılar, kullanım‑bazlı lisansları (erişim başına ödeme) satabilir ve ödeme mantığını sözleşmeye gömerek token transferleriyle otomatikleştirebilir. |
| **Denetçiler için şeffaflık** | Denetçiler, iç dökümana bağımlı kalmadan doğrudan blokzinciri sorgulayabilir. |
| **Kurumsallar arası güven** | Sıfır‑güven kimlik doğrulama ile zincir üzeri doğrulama, “güven‑ama‑doğrula” modelini farklı organizasyonlar arasında mümkün kılar. |

---

## 6. Gerçek‑Dünya Kullanım Senaryoları

### 6.1 Sağlık Araştırma Konsorsiyumu

Bir grup hastane, AI model eğitimi için sentetik hasta kayıtlarını paylaşır. Her üye, özel bir Ethereum ağı üzerinde **kota‑bazlı lisans** alır. Formize, bir araştırmacının talebini sözleşmeye göre doğrular, kota aşıldığında ya da araştırmacı konsorsiyumdan ayrıldığında erişimi otomatik olarak iptal eder.

### 6.2 Sentetik Medya Pazar Yeri

Bir pazar yeri, AI‑tarafından üretilen görselleri sınırlı sayıda ticari kullanım için **royalty‑free** lisansla satar. Akıllı sözleşme her indirmeyi sayar; limit aşıldığında Formize daha fazla indirmeyi engeller ve alıcıyı bilgilendirir. Pazar yeri ayrıca her başarılı erişimde sözleşme içinde tanımlı bir token ödemesiyle içerik üreticisine **gelir paylaşımı** yapabilir.

### 6.3 Kenar‑AI Cihaz Firmware Güncellemeleri

Üreticiler, kenar cihazları için sentetik telemetri verilerini dağıtarak cihazda model ince ayarı yapılmasını sağlar. Lisanslar, cihaz seri numaralarına (cüzdan adresi olarak saklanır) bağlanır. Bir cihazın güvenliği ihlal edilirse, Formize sözleşme üzerinden lisansı anında iptal eder ve daha fazla veri sızmasını önler.

---

## 7. Uygulama Kontrol Listesi

| Aşama | Görevler |
|-------|----------|
| **Planlama** | Veri setlerini belirle, lisans şartlarını (kota, sona erme, coğrafi kısıtlama) tanımla, blokzincir seçimini yap (genel vs. izinli). |
| **Sözleşme Geliştirme** | Solidity sözleşmelerini yaz, test et ve güvenlik denetimi yap; OpenZeppelin kütüphanelerini entegre et. |
| **Formize Uzantısı** | Web3 Adaptörünü dağıt, politika kurallarını yapılandır, kullanıcı kimliklerini cüzdan adresleriyle eşleştir. |
| **Entegrasyon Testi** | Tüketici isteklerini simüle et, zincir üzeri durum güncellemelerini doğrula, IPFS denetim kayıtlarını kontrol et. |
| **Üretime Geçiş** | Sözleşmeleri ana ağ ya da konsorsiyum zincirine dağıt, izleme panellerini etkinleştir, yönetişim ekiplerini eğit. |
| **Sürekli İyileştirme** | Sözleşme versiyonlarını periyodik olarak gözden geçir, yeni maddeler ekle (ör. GDPR‑silme hakkı), Formize politikalarını güncelle. |

---

## 8. Gelecek Yönelimler

1. **Sıfır‑Bilgi Kanıtları (ZKP)** – Tüketicinin kimliğini ifşa etmeden lisans uyumluluğunu kanıtlamayı mümkün kılar.  
2. **Dinamik Fiyatlandırma Modelleri** – Akıllı sözleşmeler, piyasa talebine göre ücretleri ayarlayan **oracle‑destekli** fiyatlandırma mekanizmaları içerebilir.  
3. **Çapraz‑Zincir İşbirliği** – **Polkadot** veya **Cosmos** köprüleri sayesinde lisanslar birden fazla blokzincir ekosisteminde tanınabilir.  
4. **AI‑Üretimli Sözleşme Maddeleri** – LLM’ler, düzenleyici şablonlara göre lisans maddelerini otomatik oluşturabilir ve bunları Solidity koduna dönüştürebilir.

---

## İlgili Bağlantılar

- [OpenZeppelin Contracts Kütüphanesi – Güvenli Akıllı Sözleşme Kalıpları](https://github.com/OpenZeppelin/openzeppelin-contracts)  
- [Ethereum İyileştirme Önerisi 4337 – Ödeme‑Başına‑Kullanım Modelleri için Hesap Soyutlaması](https://eips.ethereum.org/EIPS/eip-4337)