🚷身份识别与权限控制

系统的平稳安全运行及各项功能实现，严格依赖于对写操作的权限控制和写操作指令的路由控制，也就是对可能改变各智能合约状态的调用指令（“写指令”），需要在处理前严格审核验证指令发出账户的身份和权限，同时严格控制每个智能合约自身发出的写指令所指向的目标合约地址及API接口，从“收、发”两个方向严格控制写指令的行进路径，从而确保整个系统的状态信息可按既定的商业法律逻辑有序更新。

系统中可能发生的写指令主要分为三大类：

系统配置类：由外部账户触发，不直接导致法律后果的合同起草、系统配置行为；
法律行为类：由外部账户触发，会产生直接法律后果的股权交易、公司治理行为；及
算法控制类：被前两类写指令调用后，管理人合约根据系统预设算法有序发出的，可改变登记簿合约、股东协议合约、投资协议合约等其他智能合约状态的写操作指令。

针对上述3类写指令，系统按照其不同的行为性质、影响范围，综合采用3种不同的身份识别方法。

🚦 合约层面的角色权限控制机制

系统配置类和算法控制类指令，并不涉及系统所簿记的法律权益处分，一般只在本公司的簿记系统内部起作用，属于系统配置、算法设计、运营维护等技术活动范畴，因此采用可继承、具有组件属性的访问控制合约在每个智能合约层面进行身份校验，以账户地址来识别指令发出者的身份。

访问控制合约，是一个可复用、可继承、组件类智能合约，专门负责在智能合约层面定义角色分组及其校验算法。系统中的每一个智能合约均是继承了它的子合约，因此均可使用其定义的角色分组来校验控制写操作权限。

访问控制合约设定有“所有者”和“管理人”两个特别角色，以及一个角色组--“律师组”（律师组的管理员为“法务总监”），根据写指令发出者的账户地址来识别其角色身份。

1. 所有者

所有者在创设智能合约时由部署该合约的账户自由设定，具备自由创建角色组并任命角色组管理员的权力，在商业法律逻辑上映射”股东“身份，其权限设计体现了股东对合同、章程、决议等法律文件的提案权、内容审核权和决策权。

所有者可以将其角色转让给另一个账户，转让后会失去自身的“所有者”身份。

“管理人”是唯一不受所有者影响的角色，从而确保其角色任命和控制权限的相对独立性，从制度维护和职责独立的角度上制衡”所有者“。

2. 管理人

管理人在创设智能合约时由部署该合约的账户自由设定，具备特殊的系统配置权限，在商业法律逻辑上映射”公司秘书或会计师“身份，其权限设计体现了公司秘书和会计师相对独立于股东、高管的制度维护职权和独立责任承担的特点。

管理人可以将其角色转让给另一个账户，转让后会失去自身的“管理人“身份。

各分项管理人合约的所有接口均设定为只有”管理人“才有调用权限，因此在这些合约部署完成后，会将总管理人合约地址设定为它们的”管理人“，从而将其写操作权限全部收归总管理人合约统一调用，进而排除任何其他外部账户或系统外合约干扰公司治理活动的可能，确保公司簿记系统可以安全其不受人力干扰的自动运行。

总管理人合约的”管理人“，具备如下特殊权限：

① 设定及变更各分项管理人合约及登记簿合约的合约地址注册；

② 设定或撤销各分项管理人合约和登记簿合约的”管理人“任命；

③ 向系统输入作为行权触发条件的链外数据（例如，营收、净利润等财务数据）；及

④ 设定实缴出资的哈希锁，从而使得新股东在链下或跨链实缴出资时可自动获得公司的出资证明书。

因此，其权限特点非常接近于”公司秘书“或”总会计师“。

如果总管理人合约的管理人将“零地址“设定为新任”管理人“，就相当于彻底放弃了人为干预公司簿记系统运行的可能性，将系统完全交由智能合约体系自动运行。

作为代价，这种自动运行的簿记系统将不能进行部分合约的模版升级，也不能再以链外数据作为特殊股东权利的触发条件了。

3. 律师组及法务总监

法务总监是律师角色组的管理员，有权给任何账户地址赋予律师角色。

作为角色组成员的律师，可调用”辞职“接口辞去合同律师身份。

作为角色组管理员的法务总监，可调用”撤销角色组“接口一次性解除对所有合同律师的聘任。

对于股东协议、投资协议这两类特殊的合约，只有具备“律师”角色的账户才能调用相关写操作接口去“起草”合同内容，如公司治理的各项行为规则、权益条款...股权交易的标的股权、价格、数量等交易要素，以及设定合同当事方、签约期限、交割截止日等合同履行要素。

因此，股东在创设股东协议或投资协议合同后，需要以”所有者“身份任命”法务总监“（法务总监可再任命一名或多名律师），由法务总监或律师负责起草合同内容；起草完成后，经”所有者“确认合同内容无误再调用”合同定稿“接口，一次性撤销”律师“角色组，并将”所有者“身份转让给“零地址”，从而使得合同内容不能再做人为改动。

需要强调的是，如果没有将合约的”所有者“转让给”零地址“，则”所有者“可通过再次任命”法务总监“的方式继续修改合约内容。

🚏 公司内部的指令路由机制

登记簿合约的API通常会允许若干个分项管理人合约来调用，因此在单一合约层面依靠角色分组来控制写操作权限就会很不经济。所以，系统在总管理人合约中设置了两个地址注册表，专门解决算法控制类指令在公司内部簿记合约间的路由需求。

总管理人合约设置有两个特殊的地址注册表，分别用来记录“分项管理人合约”和“登记簿合约“两大类智能合约的地址信息。这两个注册表以正整数为检索键、以合约地址为映射值，可以很方便的检索并获取对应的合约地址。

系统部署时，将各分项管理人合约和登记簿合约的合约地址按其各自的编号录入注册表；系统运行时，相关写指令接口就会在处理写操作之前，自动调用总管理人合约的查询接口，查询并验证指令发出账户的地址是否与注册表中特定合约的地址相符，从而完成算法指令的身份校验。

比如，股权登记簿的股权转让接口，在交割股转交易时需要由投资协议簿记管理人合约来调用，在执行反稀释权益时又需要由特殊股东权益管理人合约来调用，因此其调用权限就不能通过访问控制合约中唯一的“管理人”角色来授权，而是通过查询总管理人合约的地址注册表来校验，只要指令发出账户的地址与前述两合约中的任何一个相符，即通过权限验证。

🏛️ 整个平台的用户身份识别机制

法律行为类指令，直接影响簿记权益处分，具备商业法律意义，而且可能与ComBoox平台(“平台”)上其他公司发生法律关系，属于股权交易、公司治理等法律行为范畴，因此系统专门设计了注册中心合约以及与用户身份管理相关的系列算法，在整个平台范围内识别验证指令发出者的身份和权限。

ComBoox平台中的“用户”：

① 可能是某公司内部的股东、董事、高管，也可能是公司外部的债权人、受托人或代理人；

② 不但可能与一家公司建立契约或投资关系，而且可能与多家公司同时存在法律关系；

③ 不但可能是通过外部账户控制其链上行为的自然人，而且可能是通过合约账户来行使公司权利的法人。

因此，ComBoox采用独立的注册中心合约来专门管理整个平台上所有用户的数字身份。

需要说明的是，ComBoox平台的用户身份以EVM账户地址为识别标签，并不涉及自然人姓名、法人登记号、国籍、住所等社会属性信息，所以严格说仅能称为用户的“数字身份”。

这种“去标识化”的身份管理模式，一方面是公有区块链的技术特点决定的，另一方面也有利于保护用户的隐私信息。

但是，各国对投资、融资、借贷、支付、汇兑等商事活动均存在KYC、反洗钱等实名制要求，因此请各您自行依法管理、维护与本公司相关的用户社会身份信息，必要时请咨询相关法域的法律专家。

借鉴分布式数字身份的理念，注册中心合约通过一个专门的用户编号表来注册、管理用户身份，同时提供了一个可供平台内已注册合约随时校验账户身份的查询接口。

（1）用户编号表

用户编号表，以账户地址为检索键、以40位无符号整数为映射值，可通过专门接口来查询获取特定账户地址对应的用户编号。

用户行权时，公司簿记系统的总管理人合约会调用注册中心合约的查询接口获取指令发出账户的用户编号，然后将反馈的编号值作为追加参数传递给特定分项管理人合约，分项管理人合约再根据特定登记簿合约的记录验证用户的身份权限。

例如，股东行使表决权时，总管理人合约会向注册中心合约查询指令发出账户的用户编号，然后其传递给股东会纪要管理人合约，后者会继续调取股东名册合约来验证该编号用户是否为公司股东，若是股东则继续后续操作，否则终止程序并返回错误信息。

（2）用户注册

在使用ComBoox系统的写操作功能之前，需要先申请注册系统用户（单纯查阅平台上簿记的公司信息并不需要注册）。注册中心合约会给申请账户地址分配一个系统唯一的用户编号。

在创设公司簿记系统之后，可调用总管理人合约的“制备公章”接口为公司注册一个专门的用户编号，该编号的检索键为公司总管理人合约地址，这意味着可以用总管理人合约地址发出写指令，代表公司在链上完成法律行为、行使法律权利。（若通过调用注册中心合约的“创建公司”接口来创建新簿记系统，其内置的脚本代码会自动为新公司注册一个用户编号。）

（3）备用钥匙

为防止因遗失私钥而丧失用户控制权，系统允许已注册用户追加设定一个账户地址作为“备用钥匙”（注册时使用的账户地址为“主钥匙”）。但是，为防止规避锁定期、优先权等合同义务，系统禁止变更备用钥匙或追加更多的钥匙。因此，一个用户最多可以拥有主钥匙、备用钥匙两个账户，两者可互换角色。通过备用钥匙账户发出的写指令，在注册中心合约中也会检索获取到与主钥匙相同的用户编号。不论是主钥匙还是备用钥匙，均只能对应唯一的用户编号，用过的账户地址不能再用于注册其他用户编号。

（4）用户编号查询权限

注册中心合约的用户编号查询接口仅面向平台中已注册的合约账户及用户本人开放。在满足用户身份校验目的的前提下，尽最大可能避免外部合约访问可能带来的安全风险。