Inco Lightning授权核对：handle、解密证明与跨应用Session
链小知 · 进阶 · 核验 · 依官方文档整理
检查更新后的密文访问、明文/重加密结果和Session Voucher覆盖范围，避免把查看会话当单应用授权。
开始前准备
- 准备已有的Base或Base Sepolia版本、handle、访问记录、脱敏解密证明和会话范围材料；保留链与时间。
1. 先固定Lightning实现和网络
当前Introduction将Lightning定义为TEE机密计算，列Base主网、Base Sepolia；Solana Devnet另为beta。第三方泛FHE概述不替代具体实现，也不能把EVM方法及地址直接套到Solana。
从已有记录固定链、库版本、handle及所属数据；handle只是隐藏值标识，不等于明文、当前业务成功或读取权。
检查结果：实际产品/TEE模型、EVM链和handle身份明确，未套其他路线或SVM方法。
2. 追踪handle更新后的访问权
e.allow授予对应handle的查看、公开解密和计算访问；handle不可变，更新变量会产生新handle，需要重新授权。合约后续还要计算该值时应保留e.allowThis，不能只给用户地址就推定合约也有持久权。
e.reveal会让该handle永久公开，不能当仅对当前用户展示。官方提醒，任何曾获访问的地址都应视为已知并可能保存/再分享该值；transient不意味着已知明文更容易收回，且e.transientAllow文档仍标SDK未提供。
检查结果：新旧handle和对应账户/合约访问分别核，公开reveal及暂态权未误称可逆保密。
3. 核Session Voucher的跨应用范围
Allowance Voucher由原持有者授权临时decrypter在一段时间内代为查看/计算；默认验证器只核到期与decrypter，不按dApp或合约缩窄，覆盖分享者所有有权handle，可能包括别的应用。记录实际decrypter、expiresAt、链和验证器，不能从某应用发起就判断只读该应用。
签名结构中的warning是已签载荷的一部分，不能删改，否则InvalidVoucherWarning或签名校验失败。自定义canUseSession逻辑可以另设条件，但只有读到实际策略材料才能认定收窄；示例的小时/一天都不当统一默认期限。
检查结果：voucher的读取者、到期与验证器有证据，默认跨应用范围和warning完整性已明确。
4. 分清明文、重加密和可回链证明
attestedDecrypt需要e.allow或e.reveal对应权限，通常返回plaintext.value及covalidator证明；选择reencryptPubKey时结果改为面向指定接收方的encryptedPlaintext，不能把密文字节当明文值。只有同时适配对应keypair并本地解开后，才有该接收方的明文结果。
已有回链材料应分别核isValidDecryptionAttestation的签名校验和decryption.handle等于预期handle；示例两项都检查。拿到证明不等于已经回链或业务执行完成，attestedReveal面向已公开handle，不能拿它替保密查看。
检查结果：输出模式与接收方匹配；若有回链，签名有效与handle一致分别有材料，未把取得证明当已执行。
5. 按全量失效与费用责任结案
updateActiveVouchersSessionNonce会立即令所有既有voucher失效，不只当前应用或一个decrypter；需要继续访问者需按实际策略重新发授权。已有撤销材料不能说明对方删除了此前明文。
外部加密输入和随机数创建等有Inco费用，按当时getFee和实际操作数/付款方核，可由用户msg.value或合约余额付；示例常量不是当前报价，网络Gas另列。解密失败、未取得结果与链上证明缺失分开留待核，不用补零消除未知。
检查结果：全量nonce失效与后续授权有界，费用/付款方按原记录，历史明文和失败缺项未伪造结果。
怎样确认完成
- 得到handle、访问范围、结果模式与会话退出对照；官方方法已核，个人实际权限及证明执行结果待原材料确认。
常见错误与边界
- Lightning当前TEE模型不等同泛FHE方案。
- 新handle需要新访问权；reveal和共享明文不能撤回。
- 默认voucher跨应用；撤销nonce会使全部既有voucher失效。