# Inco Lightning授权核对：handle、解密证明与跨应用Session

整理：链小知（AI 辅助）
资料核对日期：2026-10-14
引用地址：https://lianxiaozhi.com/tools/guides/inco-handle-attestation-session-voucher
难度：进阶
核验方式：官方文档整理，未执行真实账户操作

检查更新后的密文访问、明文/重加密结果和Session Voucher覆盖范围，避免把查看会话当单应用授权。

## 使用工具
- [Inco Lightning](https://lianxiaozhi.com/tools/inco-lightning) · [官方入口](https://docs.inco.org/introduction)

## 前置条件
- 准备已有的Base或Base Sepolia版本、handle、访问记录、脱敏解密证明和会话范围材料；保留链与时间。

## 1. 先固定Lightning实现和网络

当前Introduction将Lightning定义为TEE机密计算，列Base主网、Base Sepolia；Solana Devnet另为beta。第三方泛FHE概述不替代具体实现，也不能把EVM方法及地址直接套到Solana。

从已有记录固定链、库版本、handle及所属数据；handle只是隐藏值标识，不等于明文、当前业务成功或读取权。

核对结果：实际产品/TEE模型、EVM链和handle身份明确，未套其他路线或SVM方法。
依据：[Inco：当前Lightning TEE架构与网络](https://docs.inco.org/introduction.md)
依据：[Inco：Attested Decrypt、Reveal与Compute区别](https://docs.inco.org/guide/decryption.md)

## 2. 追踪handle更新后的访问权

e.allow授予对应handle的查看、公开解密和计算访问；handle不可变，更新变量会产生新handle，需要重新授权。合约后续还要计算该值时应保留e.allowThis，不能只给用户地址就推定合约也有持久权。

e.reveal会让该handle永久公开，不能当仅对当前用户展示。官方提醒，任何曾获访问的地址都应视为已知并可能保存/再分享该值；transient不意味着已知明文更容易收回，且e.transientAllow文档仍标SDK未提供。

核对结果：新旧handle和对应账户/合约访问分别核，公开reveal及暂态权未误称可逆保密。
依据：[Inco：逐handle访问与公开披露](https://docs.inco.org/guide/guide-access-control.md)
依据：[Inco：Attested Decrypt、Reveal与Compute区别](https://docs.inco.org/guide/decryption.md)

## 3. 核Session Voucher的跨应用范围

Allowance Voucher由原持有者授权临时decrypter在一段时间内代为查看/计算；默认验证器只核到期与decrypter，不按dApp或合约缩窄，覆盖分享者所有有权handle，可能包括别的应用。记录实际decrypter、expiresAt、链和验证器，不能从某应用发起就判断只读该应用。

签名结构中的warning是已签载荷的一部分，不能删改，否则InvalidVoucherWarning或签名校验失败。自定义canUseSession逻辑可以另设条件，但只有读到实际策略材料才能认定收窄；示例的小时/一天都不当统一默认期限。

核对结果：voucher的读取者、到期与验证器有证据，默认跨应用范围和warning完整性已明确。
依据：[Inco：跨应用Session Voucher范围与撤销](https://docs.inco.org/js-sdk/voucher/allowance-voucher.md)
依据：[Inco：解密结果、重加密及证明核对](https://docs.inco.org/js-sdk/attestations/attested-decrypt.md)

## 4. 分清明文、重加密和可回链证明

attestedDecrypt需要e.allow或e.reveal对应权限，通常返回plaintext.value及covalidator证明；选择reencryptPubKey时结果改为面向指定接收方的encryptedPlaintext，不能把密文字节当明文值。只有同时适配对应keypair并本地解开后，才有该接收方的明文结果。

已有回链材料应分别核isValidDecryptionAttestation的签名校验和decryption.handle等于预期handle；示例两项都检查。拿到证明不等于已经回链或业务执行完成，attestedReveal面向已公开handle，不能拿它替保密查看。

核对结果：输出模式与接收方匹配；若有回链，签名有效与handle一致分别有材料，未把取得证明当已执行。
依据：[Inco：解密结果、重加密及证明核对](https://docs.inco.org/js-sdk/attestations/attested-decrypt.md)
依据：[Inco：Attested Decrypt、Reveal与Compute区别](https://docs.inco.org/guide/decryption.md)

## 5. 按全量失效与费用责任结案

updateActiveVouchersSessionNonce会立即令所有既有voucher失效，不只当前应用或一个decrypter；需要继续访问者需按实际策略重新发授权。已有撤销材料不能说明对方删除了此前明文。

外部加密输入和随机数创建等有Inco费用，按当时getFee和实际操作数/付款方核，可由用户msg.value或合约余额付；示例常量不是当前报价，网络Gas另列。解密失败、未取得结果与链上证明缺失分开留待核，不用补零消除未知。

核对结果：全量nonce失效与后续授权有界，费用/付款方按原记录，历史明文和失败缺项未伪造结果。
依据：[Inco：跨应用Session Voucher范围与撤销](https://docs.inco.org/js-sdk/voucher/allowance-voucher.md)
依据：[Inco：逐handle访问与公开披露](https://docs.inco.org/guide/guide-access-control.md)
依据：[Inco：输入、随机数与费用承担（选读）](https://docs.inco.org/quickstart/fees.md)

## 常见错误
- Lightning当前TEE模型不等同泛FHE方案。
- 新handle需要新访问权；reveal和共享明文不能撤回。
- 默认voucher跨应用；撤销nonce会使全部既有voucher失效。

## 完成检查
- 得到handle、访问范围、结果模式与会话退出对照；官方方法已核，个人实际权限及证明执行结果待原材料确认。

## 相关知识

## 官方依据
- [Inco：当前Lightning TEE架构与网络](https://docs.inco.org/introduction.md)
- [Inco：逐handle访问与公开披露](https://docs.inco.org/guide/guide-access-control.md)
- [Inco：Attested Decrypt、Reveal与Compute区别](https://docs.inco.org/guide/decryption.md)
- [Inco：解密结果、重加密及证明核对](https://docs.inco.org/js-sdk/attestations/attested-decrypt.md)
- [Inco：跨应用Session Voucher范围与撤销](https://docs.inco.org/js-sdk/voucher/allowance-voucher.md)
- [Inco：输入、随机数与费用承担（选读）](https://docs.inco.org/quickstart/fees.md)