vLEI 沙盒
一個可在幾秒鐘內運行、無需任何基礎設施的 GLEIF 可驗證 LEI 信任鏈工作模型，同時在模擬不足時提供通往真實 KERIA 堆疊的路徑。
為什麼存在
vLEI 的入門成本很高，而且大多是附帶的。這些概念——KERI 金鑰事件日誌、ACDC 鏈式憑證、CESR 編碼、GLEIF 治理層級——都是可以學習的，但通常的第一步是啟動 Docker 容器、解析 OOBI 以及協調多重簽名儀式，然後才能發行一個憑證。對於任何試圖弄清楚 vLEI 是否適合他們問題的人來說，這個順序是顛倒的。
這個技能反轉了這個過程。模擬模式為您提供真實的 Ed25519 簽名、真實的 CESR 編碼、真實的自定址識別符號以及真實的邊界運算子強制執行，除了 Python 之外沒有任何依賴項。您可以在一個下午、在筆記型電腦上、離線設計一個憑證方案、故意破壞它，並確切理解驗證者會接受和不接受什麼。然後再進階。
兩種模式
| 模擬（預設） | 真實 | |
|---|---|---|
| 需求 | Python 3.8+ | Docker Compose v2.23+ |
| 啟動時間 | 瞬間 | ~60秒 映像拉取 |
| 簽名 | 真實 Ed25519 | 真實 Ed25519 |
| SAID / CESR | 真實 | 真實 |
| 見證者、OOBI、IPEX | 已建模抽象 | 實際協議 |
| 多重簽名、委派儀式 | 簡化 | 完整 |
| 適用於 | 憑證設計、驗證者邏輯、教學、示範 | 整合、協議行為、預生產測試 |
除非使用者明確需要協議層級的行為，否則請從模擬模式開始。大多數應用設計問題在那裡能更快得到解答。
開始使用
所有操作都透過一個腳本執行。從技能目錄執行：
python scripts/vlei_sandbox.py demo
這將建立完整的六步信任鏈——GLEIF 認證一個 QVI，QVI 發行一個 Legal Entity 憑證，該實體授權一個官方角色，QVI 發行 OOR 憑證，該實體直接發行一個 ECR 憑證——然後將結果驗證回信任根，並列印它執行的每個檢查。首先運行它。敘述性輸出是關於生態系統如何組合在一起的最快可用的解釋，而且它是一個很棒的現場示範。
然後展示哪些會中斷：
python vlei_sandbox.py status # 列出憑證和 SAID
python vlei_sandbox.py revoke --said <LE SAID> # 撤銷實體憑證
python vlei_sandbox.py verify --said <OOR SAID> # 現在會失敗——鏈已崩潰
這個順序——撤銷一個憑證並觀察其下所有內容都失敗——比任何圖表都更能體現核心概念：權威是連結的，而非斷言的。
命令參考
設定
python vlei_sandbox.py init [--force]
python vlei_sandbox.py demo [--lei <18 chars>] [--person NAME] [--role ROLE] [--context-role ROLE]
python vlei_sandbox.py status
參與者（AID 控制器）
python vlei_sandbox.py actor add --alias gleif --registry gleifRegistry --root
python vlei_sandbox.py actor add --alias qvi --registry qviRegistry --delegator gleif
python vlei_sandbox.py actor list
python vlei_sandbox.py actor rotate --alias qvi # 預先輪換：AID 存活
--root 標記生態系統的信任根。--delegator 產生一個委派創始（dip）事件，鏡像 GLEIF 將 AID 委派給 QVI 的方式。
憑證
python vlei_sandbox.py issue --type qvi --issuer gleif --holder qvi --lei <LEI>
python vlei_sandbox.py issue --type le --issuer qvi --holder le --lei <LEI> --auth <QVI SAID>
python vlei_sandbox.py issue --type oor-auth --issuer le --holder qvi --lei <LEI> \
--person "Jane Doe" --role "Chief Executive Officer" --subject-aid <person AID> --auth <LE SAID>
python vlei_sandbox.py issue --type oor --issuer qvi --holder person --lei <LEI> \
--person "Jane Doe" --role "Chief Executive Officer" --auth <OOR AUTH SAID>
python vlei_sandbox.py issue --type ecr --issuer le --holder person --lei <LEI> \
--person "Jane Doe" --context-role "Trade Finance Officer" --auth <LE SAID>
python vlei_sandbox.py revoke --said <SAID>
python vlei_sandbox.py verify --said <SAID>
python vlei_sandbox.py present --said <SAID> --out presentation.json
為 issue 添加 --json 以列印完整的 ACDC。使用 --data '{"key":"value"}' 來指定內建標誌之外的屬性。
該工具會拒絕會破壞治理規則的發行——例如沒有授權邊界的憑證、連接到錯誤憑證類型的邊界、或校驗和失敗的 LEI。這些拒絕值得展示；它們顯示模型在執行某些強制規則，而不僅僅是裝飾 JSON。
LEI 算術（ISO 17442-1）
python vlei_sandbox.py lei make YZ83GD8L7GG84979J5 # -> YZ83GD8L7GG84979J516
python vlei_sandbox.py lei check YZ83GD8L7GG84979J516 # -> VALID
圖表
python vlei_sandbox.py chain --out chain.mmd # Mermaid，適用於簡報或文件
真實環境
python vlei_sandbox.py real scaffold # 將 docker-compose.yaml 複製到專案中
python vlei_sandbox.py real up
python vlei_sandbox.py real status
python vlei_sandbox.py real logs
python vlei_sandbox.py real down
與使用者合作
根據他們實際想要決定的內容來匹配深度。
「向我解釋 vLEI」——執行 demo 並逐步講解其輸出。不要先講理論；成品比理論更有說服力，而輸出中的敘述會按照它們成為必要時的順序來涵蓋這些概念。
「vLEI 能解決 <問題> 嗎？」——在回答之前先閱讀 references/application-patterns.md。誠實的回答通常是「部分可以」，而其中的約束條件（LEI 成本、可驗證與可信賴之間的區別）對於實際決策比能力更重要。
「幫我為 X 設計憑證」——在模擬模式中建模。建立參與者，發行鏈，然後故意攻擊它：嘗試在未經授權的情況下發行，連結到錯誤的類型，撤銷父級。能夠在模擬模式下倖存的設計才值得為真實環境構建。
「我該如何整合這個？」——閱讀 references/real-environment.md。推動將 KERI 保持在邊緣：一個負責協議通訊的驗證者服務，下游使用普通 JSON。
「我的 X.509 / 現有 PKI 是捷徑嗎？」——直說。ISO 17442-2（X.509 中的 LEI）和 17442-3（ACDC 中的 LEI）是平行路徑，而不是轉換管道。現有的 PKI 作為提供身分保證以支援 QVI 驗證公司代表的身分，確實很有價值，但沒有標準化的格式轉換，並且將其描述為轉換管道將無法通過 GLEIF 或監管機構的審查。references/trust-chain.md 中有詳細資訊。
參考資料
根據需要閱讀，而不是預先全部閱讀：
references/trust-chain.md——憑證類型、ACDC 結構、邊界運算子、完整的驗證者檢查清單、ISO 17442 系列映射、眾所周知的模式 SAID。在回答任何有關憑證結構或「已驗證」含義的問題之前，請先閱讀。references/real-environment.md——Docker 堆疊、Signify-TS 客戶端模式、IPEX 呈現、已知的摩擦點、走向生產的路徑。在接觸real模式或撰寫整合程式碼之前，請先閱讀。references/application-patterns.md——四種可行的應用模式、如何擴展到五種標準憑證類型之外、驗證者設計檢查清單，以及在懷疑者提出之前值得提出的兩個約束條件。在定義範圍或推銷應用程式之前，請先閱讀。
實作說明
- 保真度。 SAID、CESR 資格判定、邊界運算子、TEL 撤銷語意以及預先輪換都按規範運作。簽名是真實的 Ed25519，在每次
verify呼叫時進行驗證。 - 摘要演算法。 KERI 的預設是 Blake3-256（CESR 代碼
E）。Blake3 不在 Python 標準函式庫中，因此沙盒回退到 Blake2b-256（代碼F）——這也是一個有效的 CESR 摘要代碼。因此，除非安裝了可選的blake3套件（pip install blake3），否則識別符號將以F而不是E開頭，在這種情況下它們會與生產環境完全匹配。如果使用者注意到前綴差異，請提及這一點；這是一個替代，而不是錯誤。 - 簽名後端。 當存在時使用
cryptography或PyNaCl，否則使用無依賴的純 Python Ed25519。init會報告使用了哪個。 - 狀態。 工作目錄中的一個可讀的
.vlei/state.json。可以自由檢查——將 KEL 和 TEL 視為純 JSON 是有啟發性的。它包含私鑰種子，因此它是一個沙盒產物，絕不應該被提交或用於任何真實用途。 - 刻意省略的內容。 見證者收據、透過網路解析 OOBI、IPEX 訊息交換、多重簽名閾值、觀察者。這些是協議關注點，不會改變憑證設計。當它們成為問題時，請使用
real模式。
可攜性
這個技能是純 Python 加上 Markdown，沒有框架依賴項，因此它可以在 Claude Code、Codex、Gemini CLI 或純終端機中無需修改地運行。一個能夠讀取檔案和執行 shell 命令的代理程式擁有它所需的一切。如果您的代理程式讀取的是 AGENTS.md 而不是 SKILL.md，則兩者都存在並指向相同的內容。