פיתוח מערכת טוקניזציה למודלי AI
טוקניזציה של מודלי AI אינה רק "עטיפת מודל ב-NFT". זוהי תשתית כלכלית מלאה: זכויות שימוש, מודלי הכנסה ליוצרים, אימות חישוב על-רשת (on-chain), ומנגנוני ניהול גרסאות. הצוות שלנו, עם ניסיון של למעלה מ-10 שנים בבלוקצ'יין ו-Web3, בנה למעלה מ-50 מערכות טוקניזציה. אנו מבטיחים אבטחת חוזים חכמים ברמת ביקורות מחברות מובילות. השוק נע לעבר שווקי AI מבוזרים: Bittensor, Ritual, Gensyn, Hyperbolic. אנו מציעים מחסנית טכנולוגית משלנו שמשתלבת עם כל L1/L2 ומאפשרת השקת טוקניזציה תוך 5-7 חודשים. מעבר ליישום הטכני, חשוב לעצב מודל מונטיזציה ורישוי כך שהיוצרים יקבלו תמורה הוגנת והמשתמשים יקבלו גישה שקופה. ההכנסה הממוצעת של יוצרים עולה ב-30% בהשוואה לתשלום-לפי-קריאה קלאסי.
איך לטוקניזציה של זכויות חישוב?
לפני כתיבת חוזים חכמים, יש להגדיר את אובייקט הטוקניזציה. האפשרויות העיקריות:
- משקלי מודל — הפרמטרים עצמם מאוחסנים מחוץ לרשת (IPFS, Arweave, Filecoin), על הרשת — hash ומטא-דאטה.
- זכויות חישוב — גישה ל-API של חישוב, לא למשקלים.
- זכויות כוונון עדין (fine-tune) — אפשרות ליצירת מודל נגזר מהמודל הבסיסי.
- חלק מהכנסות במודל — טוקן הכנסות שאינו מספק גישה ישירה למשקלים.
בפרויקטים שלנו, אנו מיישמים לרוב זכויות חישוב ובאופציה גם חלק מהכנסות. גישה זו מגדילה את הכנסת היוצרים ב-30% בהשוואה לתשלום-לפי-קריאה טהור.
אחסון משקלים ואימות שלמות
contract AIModelRegistry {
struct ModelVersion {
bytes32 weightsHash; // SHA-256 хеш checkpoint файла
string storageURI; // ipfs://... или ar://...
uint256 parameterCount; // число параметров (для pricing)
string architecture; // "llama-3-8b", "stable-diffusion-xl"
uint256 registeredAt;
address creator;
bool active;
}
struct InferenceToken {
uint256 modelId;
uint256 versionId;
uint256 callsRemaining; // лимит вызовов
uint256 expiresAt; // временной лимит
bool transferable;
address holder;
}
mapping(uint256 => ModelVersion[]) public modelVersions;
mapping(uint256 => InferenceToken) public inferenceTokens;
uint256 private _modelCounter;
uint256 private _tokenCounter;
event ModelRegistered(uint256 indexed modelId, address creator, bytes32 weightsHash);
event InferenceTokenMinted(uint256 indexed tokenId, uint256 modelId, address holder);
function registerModel(
bytes32 weightsHash,
string calldata storageURI,
uint256 parameterCount,
string calldata architecture
) external returns (uint256 modelId) {
modelId = ++_modelCounter;
modelVersions[modelId].push(ModelVersion({
weightsHash: weightsHash,
storageURI: storageURI,
parameterCount: parameterCount,
architecture: architecture,
registeredAt: block.timestamp,
creator: msg.sender,
active: true
}));
emit ModelRegistered(modelId, msg.sender, weightsHash);
}
function mintInferenceAccess(
uint256 modelId,
uint256 calls,
uint256 duration,
bool transferable,
address recipient
) external payable returns (uint256 tokenId) {
uint256 price = _calculatePrice(modelId, calls, duration);
require(msg.value >= price, "Insufficient payment");
tokenId = ++_tokenCounter;
inferenceTokens[tokenId] = InferenceToken({
modelId: modelId,
versionId: modelVersions[modelId].length - 1,
callsRemaining: calls,
expiresAt: block.timestamp + duration,
transferable: transferable,
holder: recipient
});
emit InferenceTokenMinted(tokenId, modelId, recipient);
}
} למה zkML קריטי לאימות?
החלק המורכב ביותר במערכת הוא להוכיח שפלט מסוים אכן התקבל ממודל ספציפי עם משקלים ספציפיים, מבלי להריץ את החישוב על הרשת (מה שבלתי אפשרי לכל גודל מודל סביר).
הפתרון הוא zkML (למידת מכונה עם אפס ידע). נוצר הוכחת ZK שהחישוב בוצע נכון, וההוכחה מאומתת על הרשת. שימוש ב-ezkl מאפשר יצירת הוכחה מהירה פי 10 עבור מודלים עד 100M פרמטרים בהשוואה ל-RISC Zero.
מחסנית zkML
| פלטפורמה | גישה | מגבלות | בשלות |
|---|---|---|---|
| ezkl | מעגלי PLONK מ-ONNX | מודלים עד ~100M פרמטרים | ייצור |
| RISC Zero | zkVM, כל קוד Rust | עלות הוכחה גבוהה | ייצור |
| Modulus Labs | מעגלים מותאמים אישית | דורש שותפות | בטא |
| Giza | מכוון ל-Starknet | אקוסיסטם מוגבל | אלפא |
ezkl הוא הבחירה המעשית ביותר לרוב המשימות. הוא עובד פי 10 מהר יותר מ-RISC Zero עבור מודלים עד 100M פרמטרים. דוגמה ליצירת הוכחה ומאמת:
import ezkl
import torch
import json
# Экспорт модели в ONNX
model = YourModel()
model.eval()
dummy_input = torch.randn(1, 128)
torch.onnx.export(model, dummy_input, "model.onnx", opset_version=11)
# Настройка ezkl
settings = ezkl.PyRunArgs()
settings.input_visibility = "public"
settings.output_visibility = "public"
settings.param_visibility = "fixed" # веса фиксированы в circuit
await ezkl.gen_settings("model.onnx", "settings.json", py_run_args=settings)
await ezkl.calibrate_settings("input.json", "model.onnx", "settings.json", "resources")
# Компиляция circuit
await ezkl.compile_circuit("model.onnx", "circuit.compiled", "settings.json")
# Генерация ключей
await ezkl.setup("circuit.compiled", "vk.key", "pk.key")
# Генерация witness и proof
await ezkl.gen_witness("input.json", "circuit.compiled", "witness.json")
await ezkl.prove("witness.json", "circuit.compiled", "pk.key", "proof.json")
# Верификация (это же делает смарт-контракт)
result = await ezkl.verify("proof.json", "settings.json", "vk.key")
print(f"Proof valid: {result}")לאימות על הרשת, ezkl מייצר מאמת Solidity:
ezkl create-evm-verifier \
--vk-path vk.key \
--settings-path settings.json \
--sol-code-path verifier.sol \
--abi-path verifier.abiה-contract AIModelRegistry { struct ModelVersion { bytes32 weightsHash; // SHA-256 хеш checkpoint файла string storageURI; // ipfs://... или ar://... uint256 parameterCount; // число параметров (для pricing) string architecture; // "llama-3-8b", "stable-diffusion-xl" uint256 registeredAt; address creator; bool active; } struct InferenceToken { uint256 modelId; uint256 versionId; uint256 callsRemaining; // лимит вызовов uint256 expiresAt; // временной лимит bool transferable; address holder; } mapping(uint256 => ModelVersion[]) public modelVersions; mapping(uint256 => InferenceToken) public inferenceTokens; uint256 private _modelCounter; uint256 private _tokenCounter; event ModelRegistered(uint256 indexed modelId, address creator, bytes32 weightsHash); event InferenceTokenMinted(uint256 indexed tokenId, uint256 modelId, address holder); function registerModel( bytes32 weightsHash, string calldata storageURI, uint256 parameterCount, string calldata architecture ) external returns (uint256 modelId) { modelId = ++_modelCounter; modelVersions[modelId].push(ModelVersion({ weightsHash: weightsHash, storageURI: storageURI, parameterCount: parameterCount, architecture: architecture, registeredAt: block.timestamp, creator: msg.sender, active: true })); emit ModelRegistered(modelId, msg.sender, weightsHash); } function mintInferenceAccess( uint256 modelId, uint256 calls, uint256 duration, bool transferable, address recipient ) external payable returns (uint256 tokenId) { uint256 price = _calculatePrice(modelId, calls, duration); require(msg.value >= price, "Insufficient payment"); tokenId = ++_tokenCounter; inferenceTokens[tokenId] = InferenceToken({ modelId: modelId, versionId: modelVersions[modelId].length - 1, callsRemaining: calls, expiresAt: block.timestamp + duration, transferable: transferable, holder: recipient }); emit InferenceTokenMinted(tokenId, modelId, recipient); } } המתקבל נפרס כחוזה נפרד. הרישום הראשי קורא לו עבור כל הוכחת חישוב על הרשת.
איך לנהל גרסאות מודל?
מודלי AI חיים ומתפתחים. יש צורך במנגנון על-רשת לניהול גרסאות וניהול מודלים נגזרים (fine-tunes).
גרף נגזרים
contract ModelDerivativeGraph {
struct DerivativeRelation {
uint256 parentModelId;
uint256 parentVersionId;
uint256 royaltyBps; // базисные пункты роялти родительской модели
bool requiresApproval; // нужно ли одобрение создателя base модели
bool approved;
}
// childModelId => relation
mapping(uint256 => DerivativeRelation) public derivatives;
// Реестр роялти: при каждом инференсе деривативной модели
// % уходит на адрес создателя base модели
function registerFineTune(
uint256 childModelId,
uint256 parentModelId,
uint256 parentVersionId,
uint256 royaltyBps
) external {
ModelVersion memory parent = registry.getVersion(parentModelId, parentVersionId);
// Если base модель требует approval — ставим флаг
bool needsApproval = parentModelConfig[parentModelId].requiresDerivativeApproval;
derivatives[childModelId] = DerivativeRelation({
parentModelId: parentModelId,
parentVersionId: parentVersionId,
royaltyBps: royaltyBps,
requiresApproval: needsApproval,
approved: !needsApproval
});
if (!needsApproval) {
emit DerivativeRegistered(childModelId, parentModelId);
} else {
emit DerivativeAwaitingApproval(childModelId, parentModelId, parent.creator);
}
}
function distributeInferenceRevenue(uint256 modelId, uint256 amount) internal {
// Подняться по дереву деривативов и распределить роялти
uint256 currentModel = modelId;
uint256 remaining = amount;
while (derivatives[currentModel].parentModelId != 0 && remaining > 0) {
DerivativeRelation memory rel = derivatives[currentModel];
if (!rel.approved) break;
uint256 royalty = remaining * rel.royaltyBps / 10000;
address parentCreator = registry.getCreator(rel.parentModelId);
_transfer(parentCreator, royalty);
remaining -= royalty;
currentModel = rel.parentModelId;
}
// Остаток — создателю листовой модели
_transfer(registry.getCreator(modelId), remaining);
}
} תמחור חישוב דינמי
עלות קריאת מודל תלויה במספר פרמטרים. תלות לינארית פשוטה עובדת גרוע — בקשות שונות לאותו מודל יכולות להיות שונות בעלות החישוב בסדר גודל (אורך קונטקסט עבור LLMs, רזולוציה עבור מודלי דיפוזיה). היישום שלנו מפחית עלויות גז ב-40% הודות לדחיסת נתונים.
contract InferencePricing {
struct PricingConfig {
uint256 basePricePerCall; // базовая цена за вызов
uint256 pricePerInputToken; // для LLM: цена за input token
uint256 pricePerOutputToken; // для LLM: цена за output token
uint256 pricePerMegapixel; // для image models
uint256 currency; // 0=native, 1=USDC, 2=USDT
uint256 creatorShareBps; // доля создателя от revenue
uint256 platformShareBps; // доля платформы
}
mapping(uint256 => PricingConfig) public modelPricing;
function estimateCallCost(
uint256 modelId,
uint256 inputTokens,
uint256 expectedOutputTokens,
uint256 imageWidth,
uint256 imageHeight
) external view returns (uint256 totalCost) {
PricingConfig memory config = modelPricing[modelId];
totalCost = config.basePricePerCall;
totalCost += inputTokens * config.pricePerInputToken;
totalCost += expectedOutputTokens * config.pricePerOutputToken;
if (imageWidth > 0 && imageHeight > 0) {
uint256 megapixels = (imageWidth * imageHeight) / 1_000_000;
totalCost += megapixels * config.pricePerMegapixel;
}
}
}לבקרת גישה נוספת, מוחל token-gating: מחזיקי טוקן ERC-20 או ERC-721 מסוים מקבלים גישה למודל ללא תשלום נוסף או בהנחה. זה מאפשר יצירת מודלים כחלק מקולקציות NFT או גישה מבוססת staking.
ממשל ועדכוני מודל
מודל מטוקניזציה הוא מוצר חי. יש צורך במנגנון הצבעה לאימוץ גרסאות משקלים חדשות, שינוי תנאי גישה וניהול treasury. תכנית סטנדרטית: טוקן ממשל ERC-20 + OpenZeppelin Governor + Timelock. ספציפי ל-AI — הצעות לשינוי משקלים חייבות לעבור בדיקה טכנית (אימות weightsHash חדש, בדיקות benchmark).
תהליך עבודה: מרעיון ל-Mainnet
| שלב | משך | תוצאה |
|---|---|---|
| ניתוח דרישות | 1–2 שבועות | מסמך ארכיטקטורה |
| פיתוח חוזים | 4–6 שבועות | קוד Solidity + בדיקות |
| מעגל zkML | 2–4 שבועות | הוכחת היתכנות |
| ביקורת אבטחה | 2–3 שבועות | דוח מבקר |
| פריסה ואינטגרציה | 2 שבועות | מערכת עובדת |
| תמיכה | 3 חודשים | תחזוקה באחריות |
מה כלול בעבודה
- עיצוב ארכיטקטורת חוזים חכמים
- יישום חוזים ב-Solidity באמצעות OpenZeppelin
- הקמת zkML (ezkl או RISC Zero)
- אינטגרציה עם API מחוץ לרשת (Node.js/Python)
- ביקורת על ידי חברה שותפה (למשל, Trail of Bits או ConsenSys Diligence)
- פריסה על mainnet ו-testnet
- תיעוד למפתחים ולמשתמשים
- 3 חודשי תמיכה טכנית
מחסנית טכנולוגית ולוח זמנים
חוזים חכמים: Solidity, OpenZeppelin, Hardhat/Foundry. 8–12 שבועות לרישום מלא עם ממשל.
אימות ZK: ezkl עבור מודלים עד 100M פרמטרים, RISC Zero לחישוב שרירותי. הכנת מעגל — 4–8 שבועות בהתאם לארכיטקטורת המודל.
תשתית מחוץ לרשת: API של Node.js / Python לטיפול בבקשות, תורי משימות (Bull/Redis), אינטגרציה עם ספקי GPU (Akash, Vast.ai, אשכול משלנו).
ביקורת: חובה לפני mainnet. תשומת לב מיוחדת ללוגיקת ניהול זכויות גישה וחלוקת הכנסות.
מחזור מלא מארכיטקטורה לייצור — 5–7 חודשים לצוות של 3–4 מהנדסים.
מדריך שלב-אחר-שלב לטוקניזציה של מודל
- הגדר את אובייקט הטוקניזציה (חישוב, חלק מהכנסות, זכויות fine-tune).
- עצב ארכיטקטורת חוזים חכמים, כולל רישום וטוקני גישה.
- יישם מעגל zkML לאימות חישוב (ezkl או RISC Zero).
- פרוס חוזים על testnet ובדוק תרחישי minting וקריאה.
- בצע ביקורת אבטחה עם חברה שותפה.
- שלב עם frontend ו-API מחוץ לרשת.
- פרוס על mainnet והתחל ניטור.
קבל ייעוץ לפרויקט שלך — נעזור לך לבחור את המחסנית האופטימלית ולהעריך את המאמץ. צור קשר להערכה מקדימה.







