OByte(ByteBall)轻钱包工作原理

OByte(ByteBall)轻钱包工作原理

轻钱包需要设置信任的服务商（vendor）才能正常工作，服务商通常为hub。轻钱包本身仅仅存储与其地址相关的交易单元，其它数据都需要从服务商那里获取，比如见证人列表、新交易单元通知、证据链等。实际上，轻钱包最核心的功能就是查询交易历史，接收转账，以及利用私钥签名进行发送交易数据。

轻钱包主要的通信协议

轻钱包与服务商之间的通信协议与网络中其它节点之间的通信协议类似，节点间的通信协议可以参考这里。轻钱包的主要通协议主要包括以下几部分内容：

常规通信协议

• heartbeat：保持与服务商之间的心跳连接
• get_joint：获取交易单元
• post_joint：发送交易单元
• get_witnesses：获取见证人列表
• joint：当有新的未确认交易单元产生时，服务商通过该消息通知轻钱包
• exchange_rates：当前价格信息

轻钱包专用协议

• light/have_updates：当有交易单元达到稳定，服务商通过该消息通知轻钱包，轻钱包需重新刷新交易历史记录
• light/new_address_to_watch：向服务商请求监控轻钱包地址
• light/get_history：获取交易历史记录
• light/get_balances：获取地址余额
• light/get_parents_and_last_ball_and_witness_list_unit：获取构造新交易的相关参数，包括父单元、最近稳定单元、见证人列表单元
• light/pick_divisible_coins_for_amount：给定发送金额选择utxo
• light/get_definition：获取地址定义
• light/get_link_proofs：获取隐私资产花费证明
• light/get_attestation：验证某个认证字段
• light/get_attestations：获取所有认证字段
• light/get_profile_units：获取个人档案单元

hub相关协议

• hub/login：登录hub
• hub/refresh：获取新消息
• hub/delete：删除消息
• hub/deliver：发送加密消息
• hub/challenge：登录hub时的握手消息
• hub/message：新消息到达
• hub/message_box_status：收件箱状态
• hub/get_temp_pubkey：获取对端临时公钥
• hub/temp_pubkey：更新自己的临时公钥
• hub/enable_notification：开启消息提醒
• hub/disable_notification：关闭消息提醒
• hub/get_bots：获取机器人列表
• hub/get_asset_metadata：获取资产属性

轻钱包基本工作流程

轻钱包与服务商之间采用websocket进行连接通信，可以采用network.js或者byteballjs来实现轻钱包与服务商的通信。通信过程中涉及的几个核心过程和基本步骤如下：

轻钱包生成过程

• 随机生成钱包私钥、公钥和地址；
• 设定服务商地址。

轻钱包初始化过程

• 向服务商通过light/new_address_to_watch请求监控地址；
• 向服务商通过get_witnesses请求见证人列表；
• 向服务商通过light/get_history请求交易历史记录；
• 向服务商通过light/get_balance获取余额信息；
• 向服务商通过heartbeat消息保持websocket连接。

轻钱包接收过程：

• 监控服务商发出的joint消息，从而及时得到新的交易单元；
• 监控服务商发出的light/have_updates消息，获取交易单元已达到稳定，从而及时更新交易历史记录；

轻钱包发送过程：

• 向服务商通过light/get_parents_and_last_ball_and_witness_list_unit获取构造新交易的相关参数；
• 向服务商通过light/pick_divisible_coins_for_amount获取新交易中所需的inputs参数；
• 构造新交易单元，并通过post_joint广播发送新交易单元。

轻钱包交易历史记录获取方法

轻钱包请求交易历史记录所需参数包括：

• witnesses：见证人列表；
• addresses：需要查询哪些地址的交易历史；
• requested_joints：需要查询哪些交易单元；
• last_stable_mci：已知的最近稳定单元序号；
• known_stable_units：已知已经达到稳定的交易单元。

其中，可以选择请求某些地址或者某些单元的历史记录，last_stable_mci一般设为0。在实际实现时，last_stable_mci固定为0，在查询历史时没有使用。可以考虑将last_stable_mci用在查询历史中，这样可以减少查询数量。如果查询结果数量大于MAX_HISTORY_ITEMS，应该进行分段查询。目前，是用known_stable_units来传递已知的交易单元，这样可以减少返回结果的数量。

返回的结果中包括：

• unstable_mc_joints：当前主链还未达到稳定的交易单元；
• witness_change_and_definition_joints：见证人定义发生变化的交易单元；
• joints：交易历史记录；
• proofchain_balls：已稳定交易单元的证据链。

其中，unstable_mc_joints和witness_change_and_definition_joints共同构成见证人证明。轻钱包需要对返回的交易历史记录进行处理，从而发现新交易单元，验证证据链并更新已有的交易单元。关于证据链，我们将在下面进行详细讨论。

证据链构建及验证方法

对于已经达到稳定状态的交易单元，全节点可以构造其相应的证据链，用于证明该交易单元的状态确实已经达到稳定状态。那么，在给定见证人列表和交易单元的条件下，如何构造这个交易单元的证据链？

证据链构建的基本流程如下：

• 对于给定的见证人列表，全节点需要获取见证人证明，从而得到当前DAG在给定见证人列表的视角下最近稳定的主链序号last_ball_mci。对于主链序号小于等于last_ball_mci的交易单元可以构造证据链。
• 从last_ball_mci出发开始沿着主链进行回溯，回溯方式采用父单元连接单跳方式。
• 当遇到的稳定单元具有跳跃列表时，采用跳跃列表方式进行回溯，从选择最大跳跃距离开始，当快接近目标单元时逐渐减小跳跃距离；
• 当跳跃列表中最小跳跃距离使得回溯超过目标单元时，重新切换回父单元连接单跳方式，直至到达目标单元。

证据链proofchain_balls中包含一组从last_ball_mci开始跳跃至目标单元的稳定单元，每个稳定单元包括的内容为unit、ball、is_nonserial、parent_balls、skiplist_balls。

在进行证据链验证时：

• 通过见证人证明得到可信的last_ball_unit。
• 对于证据链中的每个稳定单元，根据unit、is_nonserial、parent_balls、skiplist_balls这几项内容检查ball是否正确。
• 按照从后到前的顺序检查是否可以从最后一个稳定单元last_ball_unit回溯到目标单元。

如果能够从last_ball_unit回溯到目标单元，则说明该证据链证明了该目标单元的内容可信。

总结

本文讨论了OByte(ByteBall)轻钱包的工作原理，包括轻钱包与服务商的通信协议以及轻钱包的基本工作流程。特别地，我们详细分析了轻钱包获取交易历史记录的方法，以及稳定交易单元证据链的构建和验证方法。通过上述的讨论分析，我们可以比较清晰地了解轻钱包的基本工作原理，可以在此基础上创建自己的轻钱包客户端。