# مجوزدهی و اجرای داده‌های مصنوعی مبتنی بر قراردادهای هوشمند با Formize

داده‌های مصنوعی به‌عنوان یک ستون فقرات برای آموزش مدل‌های هوش مصنوعی در حالی که حریم خصوصی را حفظ می‌کند، شناخته شده‌اند، اما گسترش سریع ژنراتورهای داده یک مجموعه جدید از چالش‌های مجوزدهی و انطباق ایجاد می‌کند. توافق‌نامه‌های مجوزدهی سنتی ثابت، به‌صورت دستی اجرا می‌شوند و اغلب نتوانند با طبیعت پویا خطوط لوله داده‌های مصنوعی همگام شوند.

ورود **قراردادهای هوشمند**—کد خود‑اجرا بر روی بلاکچین که می‌تواند شرایط مجوز را کدگذاری، سیاست‌های استفاده را اجرا و مسیرهای حسابرسی غیرقابل تغییر را فراهم کند. وقتی با **Formize**، یک پلتفرم ارکستراسیون صفر‑اعتماد برای حاکمیت داده ترکیب شود، سازمان‌ها می‌توانند به‌صورت **زمان‑واقعی، خودکار و به‌صورت قابل اثبات انطباق**، داده‌های مصنوعی را بین تیم‌های داخلی، شرکای تجاری و بازارهای خارجی به اشتراک بگذارند.

در این مقاله ما:

1. توضیح می‌دهیم چرا مجوزدهی داده‌های مصنوعی به یک لایه برنامه‌پذیر و غیرقابل تغییر نیاز دارد.  
2. معماری ترکیبی Formize با لایه داده صفر‑اعتماد و قراردادهای هوشمند بلاکچین را به‌صورت جزئیات شرح می‌دهیم.  
3. یک جریان کاری کامل انتها‑به‑انتها را، همراه با نمودارهای Mermaid، قدم به قدم مرور می‌کنیم.  
4. مزایای انطباق، حسابرسی و تجاری را برجسته می‌کنیم.  
5. راهنمایی‌های عملی برای پیاده‌سازی و یک قطعه کد کوتاه برای قرارداد مجوزدهی مبتنی بر Solidity ارائه می‌دهیم.

---

## 1. شکاف مجوزدهی در اکوسیستم‌های داده مصنوعی

| چالش | رویکرد سنتی | رویکرد مبتنی بر قرارداد هوشمند |
|-----------|----------------------|---------------------------------|
| **حقوق استفاده پویا** | بندهای ثابت در PDFها، به‌روزرسانی‌های دستی | حقوق برنامه‌پذیر که می‌توانند در زنجیره پرس‌وجو و تغییر یابند |
| **قابلیت حسابرسی** | ردپای کاغذی، لاگ‌های ایمیل | دفتر کل بلاکچین غیرقابل تغییر |
| **اجرای قوانین** | نظارت دستی، اخطاریه‌های قانونی | لغو خودکار و جریمه‌ها از طریق منطق قرارداد |
| **انطباق چند‑قضایی** | بازبینی حقوقی مخصوص هر کشور | قراردادهای هوشمند می‌توانند قوانین خاص حوزه قضایی را تعبیه و به‌صورت خودکار نسخه‌بندی کنند |

ژنراتورهای داده مصنوعی (مانند GANها، مدل‌های انتشار) می‌توانند روزانه میلیاردها رکورد تولید کنند. بنابراین مجوزدهی باید **قابل مقیاس، قابل خواندن توسط ماشین و قابل اجرا در لایه دسترسی به داده** باشد. Formize پیش از این یک موتور **کنترل دسترسی داده صفر‑اعتماد** فراهم می‌کند که هر درخواست را احراز هویت می‌کند، منبع را لاگ می‌گیرد و انطباق سیاست را اعتبارسنجی می‌کند. افزودن لایه قرارداد هوشمند مبتنی بر بلاکچین این امکان را می‌دهد که **تصمیمات مجوزدهی از تیم حقوقی به موتور زمان اجرا منتقل شوند** و هر عملیات خواندن/نوشتن داده مطابق با شرایط توافق شده باشد.

---

## 2. نمای کلی معماری

راه‌حل از سه لایه به‌هم‌پیوسته تشکیل شده است:

1. **لایه تولید داده مصنوعی** – مدل‌های هوش مصنوعی که مجموعه‌های داده مصنوعی را خروجی می‌دهند.  
2. **لایه حاکمیت صفر‑اعتماد (Formize)** – احراز هویت، کنترل دسترسی مبتنی بر ویژگی (ABAC) و ارزیابی سیاست زمان واقعی را مدیریت می‌کند.  
3. **لایه قرارداد هوشمند بلاکچین** – شرایط مجوز، شمارنده‌های استفاده و منطق اجرای قوانین را ذخیره می‌کند.

### 2.1 نمودار جریان داده

```mermaid
graph LR
    A["ژنراتور داده مصنوعی"] --> B["هاب داده Formize"]
    B --> C["ثبت‌نام قرارداد هوشمند (Ethereum/Polygon)"]
    D["مصرف‌کننده داده"] --> B
    B --> E["موتور تصمیم‌گیری دسترسی"]
    E --> F["تحویل داده"]
    C --> G["لاگ حسابرسی (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
```

* **مرحله ۱ – ثبت‌نام**: وقتی یک مجموعه داده مصنوعی ایجاد می‌شود، ژنراتور با استفاده از **API هاب داده Formize** دارایی را ثبت می‌کند. Formize متادیتا (هش، طرح، منبع) را ذخیره می‌کند و به‌صورت خودکار یک **قرارداد مجوز** را در بلاکچین انتخابی ایجاد می‌کند که شناسه مجموعه داده را به آدرس قرارداد پیوند می‌دهد.  
* **مرحله ۲ – درخواست مصرف**: یک مصرف‌کننده از طریق Formize (OAuth، SSO یا DID غیرمتمرکز) احراز هویت می‌شود. درخواست شامل آدرس کیف پول مصرف‌کننده است.  
* **مرحله ۳ – ارزیابی سیاست**: Formize وضعیت مجوز فعلی مصرف‌کننده را از قرارداد هوشمند می‌خواند (مثلاً سهم باقی‌مانده، تاریخ انقضا). **موتور تصمیم‌گیری دسترسی** این اطلاعات را با قوانین داخلی ABAC (نقش، هدف، جغرافیا) ترکیب می‌کند.  
* **مرحله ۴ – اجرا**: اگر قرارداد نشان‌دهنده تخلف باشد (مثلاً سهم بیش از حد مصرف شده)، Formize درخواست را رد می‌کند و به‌صورت اختیاری یک جریمه زنجیره‌ای (مانند کسر توکن) را فعال می‌سازد.  
* **مرحله ۵ – حسابرسی**: هر تصمیم به همراه تصویر لحظه‌ای وضعیت قرارداد، در یک **لاگ حسابرسی مبتنی بر IPFS** غیرقابل تغییر نوشته می‌شود که توسط هش تراکنش بلاکچین ارجاع می‌شود.

---

## 3. الگوهای طراحی قرارداد هوشمند

در زیر یک قرارداد **Solidity** حداقل آورده شده است که ویژگی‌های اساسی مجوزدهی را در بر می‌گیرد. این قرارداد به‌صورت آموزشی ساده است؛ پیاده‌سازی‌های تولیدی باید قابلیت ارتقا (مثلاً با استفاده از OpenZeppelin Transparent Proxy) و کنترل دسترسی مبتنی بر نقش را نیز داشته باشند.

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

contract SyntheticDataLicense {
    address public owner;          // ارائه‌دهنده داده
    address public dataHash;       // IPFS CID مجموعه داده (به‌صورت address برای سادگی)
    uint256 public expiry;         // زمان یونیکس
    uint256 public maxAccesses;    // حداکثر تعداد خواندن‌های مجاز
    uint256 public usedAccesses;   // شمارنده

    mapping(address => bool) public whitelisted; // لیست سفید اختیاری برای هر مصرف‌کننده

    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 جهت پرس‌وجو از وضعیت مجوز
    function getLicenseStatus() external view returns (uint256 remaining, bool active) {
        remaining = maxAccesses - usedAccesses;
        active = (block.timestamp <= expiry) && (remaining > 0);
    }
}
```

**نکات کلیدی**:

* **شرایط غیرقابل تغییر** – `expiry` و `maxAccesses` در زمان استقرار تنظیم می‌شوند و بدون ایجاد نسخه جدید قرارداد قابل تغییر نیستند.  
* **لغو پویا** – ارائه‌دهنده می‌تواند به‌سرعت حق دسترسی یک مصرف‌کننده را با `revokeConsumer` لغو کند.  
* **رویدادهای زنجیره‌ای** – `AccessGranted` و `LicenseRevoked` صادر می‌شوند و به Formize امکان دریافت به‌روزرسانی‌های زمان واقعی را می‌دهند.  
* **پرس‌وجوی سبک** – `getLicenseStatus` به Formize اجازه می‌دهد وضعیت جاری را بدون هزینه گاز (فقط خواندنی) دریافت کند.

---

## 4. ادغام Formize با قرارداد هوشمند

**آداپتور Web3** Formize می‌تواند:

1. **حالت قرارداد را در Redis** برای تأخیر زیر ثانیه کش کند.  
2. **به رویدادهای قرارداد** از طریق یک ارائه‌دهنده WebSocket (مانند Alchemy یا Infura) مشترک شود.  
3. **آدرس‌های زنجیره‌ای** را به شناسه‌های کاربری Formize با استفاده از **ثبت‌نام DID‑to‑wallet** نگاشت کند.

### 4.1 نمونه قانون سیاست (YAML)

```yaml
policy:
  name: synthetic_data_license_check
  description: قبل از اعطای دسترسی، مجوز زنجیره‌ای را تأیید کنید
  conditions:
    - type: web3
      contract: "{{dataset.contractAddress}}"
      method: getLicenseStatus
      args: []
      expect:
        active: true
        remaining: ">0"
  actions:
    - allow: true
    - log: true
```

هنگامی که درخواست می‌رسد، Formize این قانون را ارزیابی می‌کند. اگر قرارداد `active: false` یا `remaining: 0` گزارش دهد، درخواست رد می‌شود و یک **رویداد حسابرسی** ثبت می‌گردد.

---

## 5. انطباق و مزایای تجاری

| مزیت | توضیح |
|------|-------|
| **هم‌راستایی با مقررات** | سوابق غیرقابل تغییر مجوز، الزامات GDPR، CCPA و مقررات نوظهور AI که نیاز به اثبات استفاده قانونی داده دارند را برآورده می‌کند. |
| **کاهش بار حقوقی** | لغو خودکار نیاز به نامه‌های توقف‑و‑دستگیری دستی را از بین می‌برد. |
| **امکان‌پذیری کسب‌وکار** | ارائه‌دهندگان می‌توانند مجوزهای مبتنی بر استفاده (پرداخت‑به‑دسترسی) بفروشند و پرداخت را از طریق انتقال توکن‌های تعبیه‌شده در قرارداد اعمال کنند. |
| **شفافیت برای حسابرسان** | حسابرسان می‌توانند مستقیماً به بلاکچین مراجعه کنند و وابستگی به مستندات داخلی را کاهش دهند. |
| **اعتماد بین‌سازمانی** | احراز هویت صفر‑اعتماد ترکیب‌شده با تأیید زنجیره‌ای، یک مدل «اعتماد‑اما‑تأیید» ایجاد می‌کند که در مرزهای شرکتی کار می‌کند. |

---

## 6. موارد استفاده واقعی

### 6.1 کنسرسیوم پژوهشی بهداشت و درمان

یک کنسرسیوم از بیمارستان‌ها داده‌های بیمار مصنوعی را برای آموزش مدل‌های AI به اشتراک می‌گذارند. هر عضو یک **مجوز مبتنی بر سهم** دریافت می‌کند که در یک شبکه خصوصی Ethereum ذخیره می‌شود. Formize اطمینان می‌دهد که هر درخواست پژوهشگر بر اساس قرارداد اعتبارسنجی می‌شود و در صورت اتمام سهم یا خروج پژوهشگر از کنسرسیوم، دسترسی به‌صورت خودکار لغو می‌شود.

### 6.2 بازار رسانه‌های مصنوعی

بازاری داده‌های تصویری تولید شده توسط AI را تحت یک **مجوز بدون حق امتیاز** برای تعداد محدودی استفاده تجاری می‌فروشد. قرارداد هوشمند هر بار دانلود را ردیابی می‌کند؛ پس از رسیدن به حد مجاز، Formize دانلودهای بیشتر را مسدود و به خریدار اطلاع می‌دهد. بازار می‌تواند یک بند **سهم درآمد** تعبیه کند که به‌صورت توکن، پس از هر دسترسی موفق به سازنده اصلی پرداخت می‌کند.

### 6.3 به‌روزرسانی‌های firmware دستگاه‌های Edge‑AI

تولیدکنندگان داده‌های ترافیک مصنوعی را به دستگاه‌های لبه برای تنظیم دقیق مدل‌های محلی توزیع می‌کنند. مجوزها به شماره سریال دستگاه (به‌عنوان آدرس کیف پول) متصل می‌شوند. اگر دستگاهی به خطر بیفتد، Formize می‌تواند بلافاصله مجوز آن را از طریق قرارداد لغو کند و از نشت بیشتر داده جلوگیری نماید.

---

## 7. چک‌لیست پیاده‌سازی

| فاز | وظایف |
|-----|-------|
| **برنامه‌ریزی** | شناسایی مجموعه‌های داده، تعریف شرایط مجوز (سهم، تاریخ انقضا، جغرافیا)، انتخاب بلاکچین (عمومی یا مجوزی). |
| **توسعه قرارداد** | نوشتن، تست و ممیزی قراردادهای Solidity؛ ادغام کتابخانه‌های OpenZeppelin برای امنیت. |
| **گسترش Formize** | استقرار آداپتور Web3، پیکربندی قوانین سیاست، نگاشت هویت کاربران به آدرس‌های کیف پول. |
| **آزمون یکپارچگی** | شبیه‌سازی درخواست‌های مصرف‌کننده، تأیید به‌روزرسانی‌های وضعیت زنجیره‌ای، تأیید ورودهای لاگ حسابرسی در IPFS. |
| **راه‌اندازی تولید** | استقرار قراردادها در شبکه اصلی یا زنجیره کنسرسیوم، فعال‌سازی داشبوردهای نظارتی، آموزش تیم‌های حاکمیتی. |
| **بهبود مستمر** | بازبینی دوره‌ای نسخه‌های قرارداد، افزودن بندهای جدید (مثلاً حق فراموشی GDPR)، به‌روزرسانی سیاست‌های Formize. |

---

## 8. مسیرهای آینده

1. **اثبات‌های صفر‑دانش (ZKP)** – امکان تأیید حریم‌خصوصی‌محور رعایت مجوز را بدون افشای هویت مصرف‌کننده فراهم می‌کند.  
2. **مدل‌های قیمت‌گذاری پویا** – قراردادهای هوشمند می‌توانند با استفاده از اوراکل‌ها قیمت‌ها را بر اساس تقاضای بازار برای داده‌های مصنوعی تنظیم کنند.  
3. **قابلیت تعامل بین‌زنجیره‌ای** – استفاده از پل‌های **Polkadot** یا **Cosmos** برای شناخت مجوزها در چندین اکوسیستم بلاکچینی.  
4. **بندهای قرارداد تولید شده توسط AI** – استفاده از LLMها برای تولید خودکار بندهای مجوز بر پایه قالب‌های قانونی، سپس کامپایل آن‌ها به کد Solidity.

---

## مطالب مرتبط

- [کتابخانه قراردادهای OpenZeppelin – الگوهای امن قرارداد هوشمند](https://github.com/OpenZeppelin/openzeppelin-contracts)  
- [پیشنهاد بهبود Ethereum 4337 – حسابداری برای مدل‌های پرداخت‑به‑استفاده](https://eips.ethereum.org/EIPS/eip-4337)