עסקאות

עסקה היא בקשה חתומה לביצוע עבודה ב-blockchain. המטען המשולב יכול להיות רצף של הוראות , שיחת חוזה, IVM קוד בייט, או ביצוע מוכר IVM . ראו חוות חכמות למודל הנוכחי של ביצוע חוזים.

עסקים מבצעים עבודות שינויים במצב או ביצועיות. בדיקת קריאה בלבד משתמשת בשאלות חתומות או נקודות קצה קריאה ציבוריות ולא יוצרת עסקאות.

עסקאות שנערכו בבלוק מחויב מאוחסרות עם תוצאה ביצועה, כולל סירוב ביצוע. בקשות שנערכו לפני קבלת הבלוק, כגון מעטפה לא חוקית או עסקאות שנסרבו על ידי השורה, אינן מאוחסות בלוק.

עבור תנועת נכסים שמרות על פרטיות, ראה עסקים אנונימיים. עסקי אנונימיים משתמשים בנקודות נכסים מחוסרות, התחייבויות, ביטוליות וראיות של ידע אפס במקום שינויים בשווי חשבונות ציבוריים.

עבור ראיות הוכחה על אפקטים יישומים שקופים נבחרים, ראה FastPQ. FastPQ צורך עדים ביצוע לאחר ביצוע עסקאות נורמלי ובונה סוגי ראיות דטרמיסטיות עבור המעברים של מצב תומכים.

נסה את זה על Taira

השתמשו במסלול Explorer כדי לבחון בלוקים ציבוריים Taira ומצבים של עסקאות חדשים ללא חשבון חתימה:

curl -fsS 'https://taira.sora.org/v1/explorer/blocks?page=1&per_page=3' \
  | jq '{pagination, blocks: [.items[] | {height, hash, transactions_total, transactions_rejected}]}'

curl -fsS 'https://taira.sora.org/v1/explorer/transactions?page=1&per_page=5' \
  | jq '{pagination, txs: [.items[] | {hash, block, status, executable}]}'

כדי לעקוב אחר עסקאות שהפליקציה שלך הוציאה קודם לכן, עותק את hash מהרשימה ולבדוק את מסלול הפרטים של המחקור:

TX_HASH='<transaction-hash>'

curl -fsS "https://taira.sora.org/v1/explorer/transactions/$TX_HASH" \
  | jq '{hash, block, status, authority, executable}'

זה עדיין רק קריאה. כדי להגיש עסקאות, נדרש מעטפה Norito חתומה, שרשרת נכונה ID, מטא נתונים על דמי העלות וחשבון Taira הממומן על ידי מכונת מים.

לדוגמאות של תשלומים על Taira, להציל את עוזר המנקה קבל Testnet XOR על Taira כמו taira_faucet_claim.py, ואז תממן את החותם דרך המזרקה הציבורית תחילה:

export TAIRA_ACCOUNT_ID='<TAIRA_I105_ACCOUNT_ID>'
export TAIRA_FEE_ASSET=6TEAJqbb8oEPmLncoNiMRbLEK6tw

curl -fsS https://taira.sora.org/v1/accounts/faucet/puzzle | jq .
python3 taira_faucet_claim.py "$TAIRA_ACCOUNT_ID"

iroha --config ./taira.client.toml ledger asset get \
  --definition "$TAIRA_FEE_ASSET" \
  --account "$TAIRA_ACCOUNT_ID"

אם הפאזל של המזרקה או מסלול התביעה חוזר 502, חכו ותנסיו שוב לפני שתתקן את העסקה עצמה.

לאחר מכן לצרף את הנתונים המטאטאליים של נכס התשלום Taira בעת הגשת העסקת:

printf '{"gas_asset_id":"%s"}\n' "$TAIRA_FEE_ASSET" > taira.tx-metadata.json

iroha --config ./taira.client.toml \
  --metadata ./taira.tx-metadata.json \
  ledger transaction ping --msg "faucet-funded taira transaction"

עסקאות לא מקוונות

Iroha יש שתי זלילי עבודה של עסקאות מקוונת:

• חתימה מקוונת יוצרת עסקה חתומה נורמלית בעוד המכשיר החותם מנותק. העסקה אינה מעובדת עד לקוח מקוון מספק את המעטפה חתומה ל Torii, כך שהיא עדיין צריכה את שרשרת הנכונה ID, סמכות, אישורים, עמלות ותחלת חיי העסקה.
• קגמושה מקוונת מזומנים מעלה את הארנק בזמן שהוא באינטרנט, תומך בהעברת ארנק לארנק שהוקמה על ידי המקבל בזמן ששני הארנקים מקוונים, ומחזיר את מצב הערת הנוצרת כאשר הקבל חוזר באינטרנט.

Torii חושף את מחזור החיים של Kagemusha כולו תחת /v1/offline/*:

שיטה ונקודת סוף	מטרה.
GET /v1/offline/readiness	להעריך את הכנות של Kagemusha עבור אחד asset_definition_id
POST /v1/offline/receiver-lineage	לפתור שושלת רישום פעילה עם הוכחה עבור בקשה חתומה של מקבל
POST /v1/offline/top-up	להגיש מבצע תוספת חתום מקוון לא מקוונים
POST /v1/offline/redeem	להגיש מבצע חידוש מקוונת חתום
GET /v1/offline/operations/{operation_id}	קרא את הסטטוס הקנוני של תוספת או פידוי

בדוק את הכנות של הנכס לפני הקמת פעולת מקוונת:

curl -fsS --get https://taira.sora.org/v1/offline/readiness \
  --data-urlencode 'asset_definition_id=<canonical_asset_definition_id>' \
  | jq '{ready, blockers, artifact_set}'

התכוננות מחברת את הארנק לגשר הפעיל ABI 21 ואת קבוצת הארטפקטים V4 מאותית. בקשות השורש, תוספת וחיסכון משתמשים בארכיונים מודפסים application/x-norito. תשובת תוספת וחיסוי 202 Accepted עם כותרת Location שמצביעה למשאב הפעולה; המבצע המשתולל שאינו אפס ID מספק את מפתח היכולת של חסינות.

זרימת הטיפוסית היא:

1. שאל את הכנות והפסק אם ready הוא שקר או כל חסין מתאים.
2. השתמשו בארנק Swift או JVM עם טופס כדי לבנות את הארכיון הקנוני, להגיש אותו ולשמור גם את מצב הערת הכניסה וגם את הפעולה ID עד שהפעולה תגיע למצב של שרשרת סופי.
3. לפתור את שושלת הרישום של המקבל כאשר זה נדרש, לבנות ולבדוק כל העברת עמיתים מקומית, ולהישאר במצב הודעה מוצפן לפני הכרה בהעברה .
4. כאשר המקבל הוא מקוון, לבנות את הארכיון הגאולה הקנוני, להגיש אותו, וסקר את משאבי הפעלה שלו עד הסוף.

הספר הגדול לא יכול לציין העברת מקוונת סותרת עד מצב הערות חוזר במהלך מחזור החיים באינטרנט. מדיניות הארנק והמפעיל יש לפיכך ליישם גבולות ערך, ירידה, משקיעים מוכרים, אחסון מקומי קבוע, וחלונות פיצוי.

הנה דוגמה של יצירת עסקאות חדשות עם ההוראה Grant. בעסקה זו, עכבר נותן לאליס את התפקיד המפורט (role_id). בדוק הדוגמה המלאה .

let grant_role = Grant::account_role(role_id, alice_id);
let grant_role_tx = TransactionBuilder::new(chain_id, mouse_id)
    .with_instructions([grant_role])
    .sign(mouse_private_key);