@censo-custody/censo-solana-wallet
Solana 钱包适配器模块 监护
将Censo 保管纳入您的 dApp
在高层,支持 Censo 保管 在你的 dApp 就像 支持由 solana 钱包适配器支持的任何其他钱包. 但作为一个基于程序的多西格钱包, Censo 保管钱包工作 与其他钱包不同。 因为Censo保管钱包 程序数据(程序衍生账户),不可能 Censo 保管钱包来实际签名交易或信件. Censo 保管钱包上还有一些交易 强制。 我们努力工作,以尽量减少这些影响 差异,但支持 Censo 保管钱包可能仍然 需要 dApp 开发者进行一些小的修改.
保管钱包是如何运作的
鉴于Censo 保管钱包是 PDA ,它可能不是立即 明确我们如何支持 dApp 交易 。 解释如何 我们这样做,这将是有帮助的 首先描述如何 检查保管 钱包一般有效。 所有交易 在Censo保管钱包, 或 dApp 交易, 在一个“ multisig op”账户中执行.
首先,执行“启动”交易,从而创建和 初始化多西格 op账户。 多西格业务账户商店 说明请求的交易和“核准” 每个多西格签名者的记录.
随后,分别办理"设置审批处分"事项 记录每个签字人的处置状况(核准或拒绝).
一旦批准或拒绝的门槛值记录在 multisig op帐号, multisig op 可能是“ 最终化”, 它 执行交易所需的逻辑,然后删除 多西格业务账户.
Censo 保管钱包如何处理 dApp 交易
如上所述,当一个 dApp 要求 Censo 保管钱包 发送或签名交易, Censo 将首先启动多西格操作 那个DApp交易。 交易指令是序列化的 并持续在多西格业务账户中 1 或更多"供给" 指令性交易。 不考虑多西格行动 "启动",直到所有的供应指令交易 执行.
收到核准处分的门槛值
执行最终交易, Censo 保管钱包
程序然后将指令补水并使用
invoke_signed()。 。 。 .
如果DApp打电话 signTransaction 或者说 signAllTransactions
钱包适配器中的方法,然后是签名交易
返回不是DApp要求的原始交易,
而是最后的交易 同样,如果DApp有
名为 sendTransaction 在钱包适配器和
提供了1个或更多额外的签名符,然后是 Censo 保管钱包
适配器将等待它收到最终交易
从Censo后端, 而这是交易
额外的签名.
这对你的DApp意味着什么
Censo 保管钱包设计有两种主要影响 dApp整合。 首先是Censo不能支持dApp 在转到钱包前预先签名的交易 适配器,第二个是最终交易强制要求 就交易规模、使用量、呼叫量而言 有点高 深度,并计算预算.
如果 dApp 在传递到钱包前预先签名交易
适配器( 无论通过 sendTransaction, (中文(简体) ), signTransaction,或
signAllTransactionsCenso 将返回此错误消息 :
Censo does not support this signing mode围绕这一点开展工作
错误, dApp 只需等待签名即可
交易返回( 如果 signTransaction 或者说 signAllTransactions
或使用 signers 选项(如果 sendTransaction 曾经
电话). 请注意,有可能核实返回的
最终交易确实符合请求
通过阅读多西格操作和
比较他们.
对大多数dApps来说,最终交易的主要影响 dApp交易使用多少账户. 最终交易需要增加3个账户 -- -- 账户 censo 钱包程序, 多西格 op 账户和 Censo 费用 支付者,为了符合1232字节的交易, 限制 dApp 交易可用账户的最大数量 至 31 (当有一个单一的签名符和 dApp 交易使用时) 钱包账户)。 注意任何指令参数已经 坚持多西格行动,在定稿时不需要 交易.
就预算计算而言,最后审定的间接费用是公平的 最少,大约21500个计算单位。 最终交易 消耗允许调用深度为 4 的一个关卡。 堆积使用量 更难计算,但至少最终交易 需要补水 dApp 交易指令 记忆.