មើលវីដេអូមេរៀន៖ ការការពារឧបករណ៍ AI ជាមួយវិក្កយបត្រក្រសូត
(វីដេអូមេរៀន និងរូបភាពគំរូនឹងត្រូវបានក្រុមមាតិកា Microsoft បន្ថែមបន្ទាប់ពីការរួមបញ្ចូលដោយផ្អែកលើគំរូមេរៀន ១៤ / ១៥)
មេរៀននេះនឹងគ្របដណ្តប់ពី៖
បន្ទាប់ពីបានបញ្ចប់មេរៀននេះ អ្នកនឹងដឹង៖
សូមស្រមៃថាអ្នកបានដាក់ជួញដូរ AI agent មួយសម្រាប់ Contoso Travel។ អេជិនត៍នេះអានសំណើរបស់អតិថិជន ហៅ API ជាមួយសេវាហោះហើរ ដើម្បីស្វែងរកជម្រើស ហើយកក់កៅអីសម្រាប់អតិថិជន។ ឆ្នាំមុន, អេជិនត៍នេះបានដំណើរការការកក់ ៥០,០០០ កម្ដៅ។
ថ្ងៃនេះ អ្នកត្រួតពិនិត្យមកដល់។ គេសួរពីសំណួរងាយៗមួយ៖ “បង្ហាញខ្ញុំឲ្យដឹងថាអេជិនត៍របស់អ្នកបានធ្វើអ្វី។”
អ្នកផ្តល់ឯកសារកំណត់ត្រារបស់អ្នក។ អ្នកត្រួតពិនិត្យមើលវា ហើយសួរចម្ងល់ដែលលំបាកជាង៖ “តើខ្ញុំធ្វើដូចម្តេចដើម្បីដឹងថាកំណត់ត្រាទាំងនេះមិនបានកែប្រែ?”
នេះគឺជាបញ្ហា audit-trail។ ការដាក់ឧបករណ៍ AI នៅថ្ងៃនេះភាគច្រើនពឹងផ្អែកលើ៖
គ្មានអ្វីខ្លះអាចឆ្លើយសំនួររបស់អ្នកត្រួតពិនិត្យដោយមិនបង្ខំឲ្យគេទុកចិត្តใម្នាក់ (អ្នក, អ្នកផ្គត់ផ្គង់ពពក, អ្នកផ្គត់ផ្គង់មូលដ្ឋានទិន្នន័យ)។ សម្រាប់ការប្រើប្រាស់ក្នុងផ្ទៃខាងក្នុង ការទុកចិត្តនេះជារឿងអាចទទួលយកបាន។ សម្រាប់ការងារក្នុងប្រព័ន្ធត្រួតពិនិត្យ (ហិរញ្ញវត្ថុ, សុខភាព, ឬអ្វីដែលជាប់ប្រកាន់តាមច្បាប់ EU AI Act) វាមិនអាចទទួលយកបានទេ។
វិក្កយបត្រក្រសូតដោះស្រាយបញ្ហានេះដោយធ្វើអោយសកម្មភាពនីមួយៗរបស់អេជិនត៍អាចបញ្ជាក់បានដោយឯករាជ្យ។ អ្នកត្រួតពិនិត្យមិនចាំបាច់ទុកចិត្តអ្នកទេ គេត្រូវបានត្រឹមតែមានគន្លងសាធារណៈ និងវិក្កយបត្រតែប៉ុណ្ណោះ។
វិក្កយបត្រជាវត្ថុ JSON មួយដែលកត់ត្រាអ្វីដែលអេជិនត៍បានធ្វើ ហើយបានចុះហត្ថលេខាចំពោះវា។
flowchart LR
A[ភ្នាក់ងារហៅឧបករណ៍មួយ] --> B[បង្កើតទិន្នន័យប័ណ្ណ]
B --> C[ធ្វើឲ្យ JSON RFC 8785 មានទ្រង់ទ្រាយត្រឹមត្រូវ]
C --> D[បង្កើតហាស SHA-256]
D --> E[ហត្ថលេខា Ed25519]
E --> F[ប័ណ្ណជាមួយហត្ថលេខា]
F --> G[អ្នកត្រួតពិនិត្យផ្ទៀងផ្ទាត់ក្រៅបណ្តាញ]
G --> H{ហត្ថលេខាត្រឹមត្រូវទេ?}
H -- yes --> I[ភស្តុតាងមិនអាចកែប្រែបាន]
H -- no --> J[ប័ណ្ណត្រូវបានបដិសេធ]
វិក្កយបត្រតិចតួចមួយមានរូបរាងដូចខាងក្រោម៖
{
"type": "agent.tool_call.v1",
"agent_id": "contoso-travel-bot",
"tool_name": "lookup_flights",
"tool_args_hash": "sha256:a3f9c1...",
"result_hash": "sha256:7b2e1d...",
"policy_id": "contoso-travel-policy-v3",
"timestamp": "2026-04-25T14:30:00Z",
"sequence": 47,
"previous_receipt_hash": "sha256:9d4e6a...",
"signature": {
"alg": "EdDSA",
"sig": "c5af83...",
"public_key": "8f3b2c..."
}
}
លក្ខណៈទីបីដែលកំពុងអនុវត្តកម្ម៖
ហត្ថលេខា។ វិក្កយបត្រត្រូវបានចុះហត្ថលេខាដោយ gateway របស់អេជិនត៍ប្រើ Ed25519 private key។ អ្នកណាមួយដែលមានសោសាធារណៈត្រូវតែអាចផ្ទៀងផ្ទាត់ហត្ថលេខានៅក្រៅបណ្តាញបាន។ ការបម្លែងខុសមួយណាក្នុងវាលណាមួយនឹងធ្វើអោយហត្ថលេខាបាត់សុពលភាព។
ការត encode ទៅ canonical។ មុនពេលចុះហត្ថលេខា វិក្កយបត្រត្រូវបានធ្វើលំហូរការសំណុំ JSON ដោយប្រើ JSON Canonicalization Scheme (JCS, RFC 8785)។ វានៅនេះធ្វើអោយកម្មវិធីពីរដែលផលិតវិក្កយបត្រដូចគ្នាគ្រប់គ្នា ផលិតលទ្ធផល byte ដែលដូចគ្នា។ បើគ្មានការត encode canonical នេះ អ្នកផលិត JSON ផ្សេងៗនឹងផ្លាស់ប្ដូរហត្ថលេខាផ្សេងគ្នា។
ចងខ្សែ hash។ វាល previous_receipt_hash តំណភ្ជាប់វិក្កយបត្រនីមួយៗទៅវិក្កយបត្រមុន។ ការដក ឬ ប្តូរមួយវិក្កយបត្រជាប្រព័ន្ធ នឹងបំបែកខ្សែពេញលេញ។ ការបម្លែងខុសកើតឡើងនៅកម្រិតខ្សែល្បែង បើទោះពាក្យហត្ថលេខាអាចជៀសវាងបាន។
លក្ខណៈទាំងនេះផ្តល់ធានារួមគ្នា៖
អ្នកមិនចាំបាច់មានបណ្ណាល័យពិសេសដើម្បីបង្កើតវិក្កយបត្រទេ។ វិធីសាស្ត្រក្រសូតគឺបានមានក្នុង Python និងលោហអක්ෂរមួយចំនួនប៉ុណ្ណោះ។
លំហាត់ដៃជាក់លាក់ក្នុង code_samples/18-signed-receipts.ipynb នឹងដឹកនាំអ្នកតាមជំហានពេញលេញ។ រូបរាងសង្ខេប៖
import json
import hashlib
import base64
from nacl import signing
from jcs import canonicalize # JSON canonical RFC 8785
def b64url_nopad(data: bytes) -> str:
return base64.urlsafe_b64encode(data).decode("ascii").rstrip("=")
def sha256_canonical(obj) -> str:
"""SHA-256 of a Python object's JCS-canonical JSON form."""
return f"sha256:{hashlib.sha256(canonicalize(obj)).hexdigest()}"
# បង្កើតឬផ្ទុកកូនសោចុះហត្ថលេខា (នៅក្នុងការផលិត សូមរក្សាទុកក្នុងស្តុកកូនសោ)
signing_key = signing.SigningKey.generate()
verify_key = signing_key.verify_key
# បង្កើតដំណើរការទទួលបាន (មិនទាន់មានហត្ថលេខា)
tool_args = {"origin": "SYD", "destination": "LAX"}
tool_result = [{"flight": "QF11", "price": 1850, "stops": 0}]
payload = {
"type": "agent.tool_call.v1",
"agent_id": "contoso-travel-bot",
"tool_name": "lookup_flights",
"tool_args_hash": sha256_canonical(tool_args),
"result_hash": sha256_canonical(tool_result),
"policy_id": "contoso-travel-policy-v3",
"timestamp": "2026-04-25T14:30:00Z",
"sequence": 0,
"previous_receipt_hash": None,
}
# ធ្វើឲ្យមានរចនាសម្ព័ន្ធ, ដំណាក់កាល, ចុះហត្ថលេខា។
canonical_bytes = canonicalize(payload)
message_hash = hashlib.sha256(canonical_bytes).digest()
signature_bytes = signing_key.sign(message_hash).signature
# បន្ថែមអ объект(signature) មានរចនាសម្ព័ន្ធ។
receipt = {
**payload,
"signature": {
"alg": "EdDSA",
"sig": b64url_nopad(signature_bytes),
"public_key": b64url_nopad(bytes(verify_key)),
},
}
នេះជាជំហានចុះហត្ថលេខាទាំងមូល។ លំហាត់ក្នុង notebook នឹងដើរតាមជំហាននីមួយខែក្នុងតំណរ។
ការផ្ទៀងផ្ទាត់គឺជាប្រតិបត្តិការវិលត្រឡប់៖
import base64
import hashlib
from nacl import signing
from nacl.exceptions import BadSignatureError
from jcs import canonicalize
def b64url_decode(s: str) -> bytes:
padding = "=" * ((4 - len(s) % 4) % 4)
return base64.urlsafe_b64decode(s + padding)
def verify_receipt(receipt: dict) -> bool:
# ហត្ថលេខាគឺជាវត្ថុដែលមានរចនាសម្ព័ន្ធ៖ {"alg", "sig", "public_key"}។
sig_obj = receipt.get("signature")
if not sig_obj or sig_obj.get("alg") != "EdDSA":
return False
# សម្រួលឡើងវិញ payload ដែលបានហត្ថលេខាពិតប្រាកដ (គ្រប់យ៉ាងលើកលែង Signature)។
payload = {k: v for k, v in receipt.items() if k != "signature"}
canonical_bytes = canonicalize(payload)
message_hash = hashlib.sha256(canonical_bytes).digest()
try:
verify_key = signing.VerifyKey(b64url_decode(sig_obj["public_key"]))
verify_key.verify(message_hash, b64url_decode(sig_obj["sig"]))
return True
except BadSignatureError:
return False
មុខងារនេះទទួលបានវិក្កយបត្រ ហើយត្រឡប់តម្លៃ True ប្រសិនបើហត្ថលេខាត្រឹមត្រូវ, False ប្រសិនបើមិនត្រឹមត្រូវ។ គ្មានការហៅបណ្តាញ, គ្មានការពឹងផ្អែកទៅលើសេវាកម្មណាមួយ ហើយមិនចាំបាច់ទុកចិត្តអ្នកណាទេ។
ដើម្បីឃើញការរកឃើញការបម្លែងដំណើរការមានប្រសិទ្ធភាព ចំណុចបង្ហាញក្នុង notebook មាន៖
tool_args_hash។នេះជាការបង្ហាញជាក់ស្តែងថាវិក្កយបត្រទាំងអស់ជាមានការជ្រៀតជ្រែកចាំបាច់៖ ការផ្លាស់ប្ដូរមួយចំនួនប៉ុន្មានគឺបំផ្លាញហត្ថលេខា។
វិក្កយបត្រដែលបានចុះហត្ថលេខាយក្សារការពារសកម្មភាពមួយ។ ខ្សែវិក្កយបត្រការពារសំណុំរបស់វា។
flowchart LR
R0[បង្កាន់ដៃ 0<br/>ដើម] --> R1[បង្កាន់ដៃ 1]
R1 --> R2[បង្កាន់ដៃ 2]
R2 --> R3[បង្កាន់ដៃ 3]
R1 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
វិក្កយបត្រមួយៗកត់ត្រា hash នៃវិក្កយបត្រមុន។ ដើម្បីលុបវិក្កយបត្រលេខ ២ ដោយមិនឲ្យមានអ្នកដឹង អ្នកវាយប្រហារត្រូវតែ៖
previous_receipt_hash របស់វិក្កយបត្រលេខ ៣ (បំបែកហត្ថលេខាវិក្កយបត្រលេខ ៣) ឬបើសោឯកជននៅក្នុង hardware key vault ហើយអ្នកផ្សាយគន្លងសាធារណៈជាមួយវិក្កយបត្រនីមួយៗ ការវាយប្រហារទាំងពីរនេះមិនអាចធ្វើបានដោយគ្មានការរកឃើញឡើយ។
notebook នឹងដើរតាម៖
previous_receipt_hash របស់វិក្កយបត្រនីមួយៗផ្គូផ្គងនឹង hash ពិតប្រាកដនៃវិក្កយបត្រមុន។នេះជារបៀបបង្កើត audit trail ដែលអ្នកត្រួតពិនិត្យខាងក្រៅអាចផ្ទៀងផ្ទាត់ដោយមិនទុកចិត្តអ្នកបាន។
នេះជាផ្នែកសំខាន់បំផុតនៃមេរៀននេះ។ វិក្កយបត្រមានអំណាចប៉ុន្តែអំណាចនោះមានដែនកំណត់។
វិក្កយបត្របញ្ជាក់បណ្តារអ្វីទាំងប្រាំបី៖
វិក្កយបត្រមិនបញ្ជាក់៖
policy_id មិនចាំបាច់បានត្រូវបានវាយតម្លៃ ឬអនុញ្ញាតសកម្មភាពនេះក្នុងការត្រួតពិនិត្យ។ វិក្កយបត្រថតអ្វីដែលបានអ្នកបញ្ជាក់ មិនមែនអ្វីដែលបានអនុវត្ត។ដែនកំណត់នេះមានសារៈសំខាន់ពីរគោលហេតុ៖
កំហុសទូទៅគឺគិតថា “យើងមានវិក្កយបត្រ” មានន័យថា “យើងត្រូវគ្រប់គ្រង”។ វាមិនដូចនេះទេ។ វិក្កយបត្រជាមូលដ្ឋានមួយ។ ការគ្រប់គ្រងគឺជាប្រព័ន្ធដែលអ្នកបង្កើតនៅលើវា។
កូដ Python ក្នុងមេរៀននេះមានលក្ខណៈតិចតួច ដូច្នេះអ្នកអាចអានជួរដេកនីមួយៗ និងយល់ពីអ្វីកំពុងកើតឡើង។ នៅក្នុងផលិតផលពិត, អ្នកមានជម្រើសពីរមាន៖
សង់ដោយផ្ទាល់លើ primitives cryptographic។ ជួរដេក ៥០ ដែលអ្នកបានមើលខាងលើគ្រប់គ្រាន់សម្រាប់ករណីប្រើជាច្រើន។ PyNaCl (Ed25519) និងកញ្ចប់ jcs (JSON canonical) គឺជាបណ្ណាល័យដែលបានថែរក្សា និងត្រូវបានពិនិត្យ។
ប្រើបណ្ណាល័យទទួលវិក្កយបត្រផលិតផល។ គម្រោង open-source ច្រើនដែលអនុវត្តមូតភាពដូចគ្នានេះដោយបន្ថែមមុខងារ (ការបង្វិលកូនសោ, ការផ្ទៀងផ្ទាត់ជាប្រព័ន្ធក្រុម, ការចែក JWK Set, រួមបញ្ចូលជាមួយម៉ាស៊ីនគោលនយោបាយ)៖
draft-farley-acta-signed-receipts) កំពុងក្នុងដំណើរការស្តង់ដារ។protect-mcp (npm) និង @veritasacta/verify (npm) ផ្តល់អនុវត្តន៍ Node របស់ការចុះហត្ថលេខា និងផ្ទៀងផ្ទាត់ក្រៅបណ្តាញ ជាចម្បងសម្រាប់ផ្ដល់မျက်មុននៃ audit trail tamper-evident ទៅលើម៉ាស៊ីន MCPណាមួយ។ការជ្រើសរើសរវាងបង្កើតផ្ទាល់ និងប្រើបណ្ណាល័យ ស្រដៀងនឹងការជ្រើសរើសរវាងសរសេរបណ្ណាល័យ JWT ផ្ទាល់ និងប្រើបណ្ណាល័យដែលបានស្ថាបនាជាស្រេច៖ ទាំងពីររាល់ពីរជាជម្រើសល្អ; បណ្ណាល័យជួយសុវត្ថិភាព និងកាត់បន្ថយវិស័យ audit; របៀបតាំងពីដើមជំរុញឲ្យអ្នកយល់គ្រប់ primitive។ មេរៀននេះបង្រៀនរបៀបពីដើម ដូច្នេះអ្នកមានមូលដ្ឋានសម្រាប់ជ្រើសរើសណាមួយ។
សាកល្បងយល់ដឹងរបស់អ្នកមុនចូលរួមលំហាត់អនុវត្ត។
១. វិក្កយបត្រត្រូវបានចុះហត្ថលេខាជាមួយកូនសោឯកជន Ed25519 របស់អេជិនត៍។ អ្នកត្រួតពិនិត្យមានតែមួយគន្លងសាធារណៈតែប៉ុណ្ណោះ។ តើអ្នកត្រួតពិនិត្យអាចផ្ទៀងផ្ទាត់វិក្កយបត្រនៅក្រៅបណ្តាញបានទេ?
២. អ្នកវាយប្រហារបំលែងវាល policy_id នៃវិក្កយបត្រដើម្បីថាផែនការគ្រប់គ្រងបានប្រើគោលនយោបាយទាក់ទាញច្រើន។ ហត្ថលេខាត្រូវបានគណនាលើផ្ទុកដើម។ តើមានអ្វីកើតឡើងក្នុងការផ្ទៀងផ្ទាត់?
៣. ហេតុអ្វីបានជាវិក្កយបត្រមាន tool_args_hash និង result_hash ជំនួស arguments និងលទ្ធផលដើម?
៤. វាល previous_receipt_hash តំណភ្ជាប់វិក្កយបត្រនីមួយៗទៅមុនរបស់វា។ ប្រសិនបើអ្នកវាយប្រហារលុបវិក្កយបត្រមួយខាងមួយក្នុងខ្សែមួយដោយមិនឲ្យគេដឹង តើអ្វីខ្លះដែលមិនត្រឹមត្រូវ?
៥. វិក្កយបត្រត្រូវបានផ្ទៀងផ្ទាត់ដោយរលូន។ តើវាបញ្ជាក់ថាសកម្មភាពរបស់អេជិនត៍ត្រឹមត្រូវ ឬផ្អែកលើគោលនយោបាយ ឬអនុវត្តត្រឹមត្រូវទេ?
បើក code_samples/18-signed-receipts.ipynb និងបញ្ចប់ផ្នែកទាំងបួន៖
បញ្ហាស្វែងរកលំហាត់បន្ថែម ១៖ បន្តពង្រីករាងវិក្កយបត្រជាមួយវាលបន្ថែមដោយជម្រើសផ្ទាល់របស់អ្នក (ឧទាហរណ៍ លេខសំណើសម្រាប់តាមដាន), ផ្លាស់ប្ដូរពិភាក្សាចុះហត្ថលេខាឲ្យរួមបញ្ចូលវាលនេះ ហើយបញ្ជាក់ថាវិក្កយបត្ររបស់អ្នកនៅតែវាស់ចូលក្រោមការផ្ទៀងផ្ទាត់។ បន្ទាប់មកបម្លែងវាលនេះបន្ទាប់ពីចុះហត្ថលេខា ហើយបញ្ជាក់ថាការផ្ទៀងផ្ទាត់បរាជ័យ។ វាគឺជាការបង្ខំឲ្យអ្នកយល់ពីរបៀប byte នីមួយៗនៃវិធី encode canonical មានតួនាទីជាមួយហត្ថលេខា។ បញ្ហាស្ទេច ២៖ SHA-256-ហាសពីរនៃបង្កាន់ដៃរបស់អ្នកជាមួយគ្នា (ភ្ជាប់បៃ canonical របស់ពួកវាជាលំដាប់ដែលកំណត់បាន) ហើយបញ្ចូលឲ្យអត្ថបទលទ្ធផលមួយជាព្រិត្តិផលថ្មីមួយលើបង្កាន់ដៃទីបីមុនពេលចុះហត្ថលេខា។ ពិនិត្យឲ្យប្រាកដថាបង្កាន់ដៃទាំងបីនេះនៅតែអាចធ្វើរបាយការណ៍ត្រលប់វិញបាន។ អ្នកទើបតែបង្កើតការបញ្ជាក់រួមបញ្ចូលជារបៀបមួយជាដំណាក់កាលតែមួយ៖ មនុស្សណាដែលកាន់បង្កាន់ដៃទីបីអាចបញ្ជាក់បានថាបង្កាន់ដៃទីមួយពីរនេះមាននៅពេលវាត្រូវបានចុះហត្ថលេខា ដោយមិនចាំបាច់បង្ហាញខ្លួននូវមាតិការបស់ពួកវាទេ។ នេះគឺជាគំរូដែលបង្កាន់ដៃបង្ហាញជ្រើសរើសប្រើនៅល្បឿនធំ (ការយក Merkle ជាបំណះបំណាល, RFC 6962)។
បង្កាន់ដៃពហុព័ត៌មានផ្តល់ឱ្យភ្នាក់ងារពហុវិជ្ជាជីវៈនូវសម្រង់ត្រួតពិនិត្យដែលមាន៖
ពួកវាមិនមែនជាជំនួសសម្រាប់ការត្រួតពិនិត្យមាតិកា ឬការអនុវត្តគោលការណ៍ ឬសំណុំហេតុអត្តសញ្ញាណ។ ពួកវាគឺជាមូលដ្ឋានសម្រាប់ស្រទាប់ទាំងនោះ។ ពេលដែលអ្នកកំពុងបង្ហាញភ្នាក់ងារដែលមានបទបញ្ជាដាក់ចេញទៅក្នុងបរិស្ថានដែលមានការគ្រប់គ្រង ឬដំណើរការពហុអង្គភាព ឬករណីណាមួយដែលអ្នក auditor អនាគតមិនអាចទុកចិត្តអ្នកបាន ការបង្កាន់ដៃគឺជាវិធីដែលអ្នកធ្វើឲ្យខ្សែត្រួតពិនិត្យជាការត្រឹមត្រូវ។
ចំណុចសំខាន់បំផុត៖ បង្កាន់ដៃបញ្ជាក់ថា អ្នកណាបាននិយាយអ្វី ពេលណា។ ពួកវាមិនបញ្ជាក់ថាអ្វីដែលបាននិយាយគឺពិត ឬត្រឹមត្រូវឡើយ។ រក្សាទុកភាពខុសគ្នានេះយ៉ាងម៉ត់ចត់។ នេះគឺជាភាពខុសគ្នារវាងប្រព័ន្ធដើមផលិតភាពស្មោះត្រង់និងប្រព័ន្ធដែលធ្វើឲ្យអ្នកច្រឡំ។
ពេលដែលអ្នកបានត្រៀមខ្លួនបញ្ចប់មេរៀននេះ និងចង់ដាក់ភ្នាក់ងារចុះហត្ថលេខាបង្កាន់ដៃនៅក្នុងបរិស្ថានពិត៖
https://your-org.example.com/.well-known/agent-keys.json។ចូលរួមក្នុង Microsoft Foundry Discord ដើម្បីជួបជាមួយអ្នករៀនផ្សេងទៀត ចូលរួមក្នុងម៉ោងការិយាល័យ និងទទួលបានចម្លើយសំណួរផ្សេងៗអំពី AI Agents។
មេរៀននេះគ្របដណ្តប់ការចុះហត្ថលេខាបង្កាន់ដៃតែមួយ និងខ្សែហាសឈ្នាន់។ គន្លងដដែលសម្របសម្រួលទៅជាគំរូកម្រិតខ្ពស់ឆាប់ៗដែលអ្នកប្រហែលជាអាចជួបនៅពេលការគ្រប់គ្រងរបស់អ្នកកំពុងរីកចម្រើន៖
authorization_*) និង post-execution (result_*) ដោយមានហត្ថលេខាឯករាជ្យ, មានប្រយោជន៍ពេលការសម្រេចកំពុងអនុញ្ញាត និងលទ្ធផលដែលសង្កេតឃើញដោយអ្នកផ្សេងគ្នាឬនៅពេលខុសគ្នា។ នេះជាការបូកបញ្ចូលលើរចនាសម្ព័ន្ធបង្កាន់ដៃដែលបានបង្រៀនក្នុងមេរៀននេះ។result_hash។ payload ពិតប្រាកដជាទូទៅមានរ្រមាប់ជាងលទ្ធផលឧបករណ៍តែមួយ៖ ការពិចារណាជាមុន - ការព្យាករណ៍ម៉ូដែល, ជម្រើសបានពិចារណា, ប្រភពអត្ថសញ្ញាអោយ, គោលបំណងហានិភ័យ, សេងខ្សែការទទួលខុសត្រូវ, លទ្ធផលច្រកចេញ - អាចរស់នៅក្នុង payload ក្រោមបង្កាន់ដៃតែមួយ។ នេះរក្សាប្រភេទបង្កាន់ដៃឲ្យមានទំហំតូច មួយពេលខ្លួនអោយស្គេម payload អភិវឌ្ឍទៅតាមដែន។signature.alg អាចផ្ទុក ML-DSA-65 (ស្តង់ដាហត្ថលេខាថ្មី[post-quantum] នៃ NIST) បើអ្នកចាំបាច់បម្លែង។ គម្រោងសម្រាប់រយៈពេលចំហ ដែលបង្កាន់ដៃទាំងពីរជាហត្ថលេខាផ្សំ។ការរចនាភ្នាក់ងារបំពានប្រើកុំព្យូទ័រ (CUA)
(នៅក្នុងការកំណត់ដោយអ្នកគ្រប់គ្រងកម្មវិធីរៀន)
ការបដិសេធ: ឯកសារនេះត្រូវបានបម្លែងភាសា ដោយប្រើសេវាបម្លែងភាសា AI Co-op Translator។ ទោះយើងខ្ញុំមានក្តីប្រាថ្នាឱ្យបានច្បាស់លាស់ តែសូមយល់ដឹងថាការបម្លែងដោយស្វ័យប្រវត្តិក៏អាចមានកំហុសឬភាពមិនត្រឹមត្រូវ។ ឯកសារដើមជាភាសាទីតាំងគួរត្រូវបានគេប្រើជាប្រភពច្បាស់លាស់។ សម្រាប់ព័ត៌មានសំខាន់ៗ សូមណែនាំឱ្យប្រើប្រាស់ការប្រែដោយមនុស្សជំនាញ។ យើងខ្ញុំមិនទទួលខុសត្រូវចំពោះការយល់ច្រឡំ ឬការបកស្រាយខុសបន្ទាប់ពីការប្រើប្រាស់ការបម្លែងនេះនោះទេ។