# 4. 身份识别与权限控制

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

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

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

针对上述3类<mark style="color:blue;">**写指令**</mark>，系统按照其不同的行为性质、影响范围，综合采用3种不同的身份识别方法。

<details>

<summary>🚦 4.1 合约层面的角色权限控制机制</summary>

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

#### **1. 所有权合约**

<mark style="color:blue;">**所有权合约**</mark>是一个可复用、可继承、组件类智能合约，专门负责在智能合约层面定义<mark style="color:blue;">“</mark><mark style="color:blue;">**所有者**</mark>”及“<mark style="color:blue;">**注册中心合约**</mark>”的账户地址。通过<mark style="color:blue;">**注册中心**</mark>创建的<mark style="color:blue;">**克隆和代理合约**</mark>，均是<mark style="color:blue;">**所有权合约**</mark>的子合约。<mark style="color:blue;">**注册中心**</mark>的合约地址一经设定不可改变，而<mark style="color:blue;">**所有者**</mark>则可将其角色权限转让给其他账户。

#### **2. 访问控制合约**

<mark style="color:blue;">**访问控制合约**</mark>也是一个组件类智能合约，是<mark style="color:blue;">**所有权合约**</mark>的子合约，专门负责定义角色分组及其校验算法。系统中的每一个智能合约均是继承了它的子合约，因此均可使用其定义的角色分组来校验控制写操作权限。

<mark style="color:blue;">**访问控制合约**</mark>设定有“<mark style="color:blue;">**直接管理人**</mark>”和“<mark style="color:blue;">**总管理人**</mark>”两个特别角色。

#### **3. 撰写控制合约**

<mark style="color:blue;">**撰写控制合约**</mark>是一种可复用、可继承、组件类智能合约，专门负责在智能合约层面定义角色分组及其验证逻辑。<mark style="color:blue;">**撰写控制合约**</mark>是<mark style="color:blue;">**访问控制合约**</mark>的子合约，并引入了一个名为“<mark style="color:blue;">**律师**</mark>”的专门角色组，“<mark style="color:blue;">**律师**</mark>”的管理员被称为“<mark style="color:blue;">**法务总监**</mark>”。只有拥有“<mark style="color:blue;">**律师**</mark>”角色的外部账户（EOA）才能编辑或配置投资协议或股东协议的条款。

因此，<mark style="color:blue;">**投资协议、股东协议、优先权条款、反稀释条款、锁定期条款**</mark>以及<mark style="color:blue;">**期权条款**</mark>都是<mark style="color:blue;">**撰写控制合约**</mark>的子合约。

#### 4. 所有者

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

<mark style="color:blue;">**所有者**</mark>可以将其角色转让给另一个账户，转让后会失去自身的“<mark style="color:blue;">**所有者**</mark>”身份。

“<mark style="color:blue;">**管理人**</mark>”是唯一不受<mark style="color:blue;">**所有者**</mark>影响的角色，从而确保其角色任命和控制权限的相对独立性，从制度维护和职责独立的角度上制衡”<mark style="color:blue;">**所有者**</mark>“。&#x20;

#### 5. 直接管理人

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

<mark style="color:blue;">**直接管理人**</mark>可以将其角色转让给另一个账户，转让后会失去自身的“<mark style="color:blue;">**直接**</mark><mark style="color:blue;">**管理人**</mark>“身份。总管理人合约及所有登记簿合约均继承了“UUPSUpgradeable”标准智能合约，因此具备在不改变各自地址或状态变量的情况下进行升级的能力。只有直接管理人或总管理人有权调用“upgradeTo()”函数。据此，公司可通过以下任一方式选择升级其总管理人合约或登记簿合约：（i）利用总管理人合约向目标智能合约传输预编程的有效载荷以触发升级函数，或（ii）将直接管理人角色转让给外部账户（EOA），并由该外部账户直接调用升级函数。前一种方式须经股东表决程序，因此更为安全；后一种方式则相对更易执行，无需编程或编码复杂的有效载荷。

***

各<mark style="color:blue;">**分项管理人合约**</mark>的所有接口均被设计为仅能通过各自总管理人合约发起的委托调用（delegatecall）来调用；据此，所有计算均在调用方总管理人合约的环境中执行。通过此种方式，分项管理人合约发出的任何读写指令，仅能指向调用方总管理人合约通过其“getBook()”函数检索到的登记簿合约地址。由此，外部账户及第三方合约被有效排除于干扰公司治理活动的可能之外，从而确保公司簿记系统可安全且不受人为干预地自动运行。

此外，所有登记簿合约的写操作API均仅限于其各自的直接管理人或总管理人访问。在公司簿记系统的创建和初始化过程中，每个登记簿合约的直接管理人角色均被设定为相关的总管理人合约。此后，登记簿合约写操作API的访问权限将仅限于总管理人合约。该限制作为第二层安全机制，用于防止未经授权的外部访问。

***

<mark style="color:blue;">**总管理人合约**</mark>的”<mark style="color:blue;">**直接**</mark><mark style="color:blue;">**管理人**</mark>“，具备如下特殊权限：

① 设定及变更<mark style="color:blue;">**各分项管理人合约**</mark>及<mark style="color:blue;">**登记簿合约**</mark>的合约地址注册；

② 设定或撤销<mark style="color:blue;">**各分项管理人合约**</mark>和<mark style="color:blue;">**登记簿合约**</mark>的”<mark style="color:blue;">**管理人**</mark>“任命；

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

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

因此，其权限特点非常接近于”<mark style="color:blue;">**公司秘书**</mark>“或”<mark style="color:blue;">**总会计师**</mark>“。

如果<mark style="color:blue;">**总管理人合约**</mark>的<mark style="color:blue;">**直接管理人**</mark>将其角色转让给总管理人合约，则意味着彻底放弃了人为干预公司簿记系统的可能性，系统将严格按照股东协议由智能合约自动运行。

#### 6. 律师组及法务总监

<mark style="color:blue;">**法务总监**</mark>是<mark style="color:blue;">**律师**</mark>角色组的管理员，有权给任何账户地址赋予<mark style="color:blue;">**律师**</mark>角色。

作为角色组成员的<mark style="color:blue;">**律师**</mark>，可调用”辞职“接口辞去合同律师身份。

作为角色组管理员的<mark style="color:blue;">**法务总监**</mark>，可调用”撤销角色组“接口一次性解除对所有合同律师的聘任。

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

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

需要强调的是，如果没有将合约的”<mark style="color:blue;">**所有者**</mark>“转让给”零地址“，则”<mark style="color:blue;">**所有者**</mark>“可通过再次任命”<mark style="color:blue;">**法务总监**</mark>“的方式继续修改合约内容。

</details>

<details>

<summary>🚏  4.2 公司内部的指令路由机制</summary>

<mark style="color:blue;">**总管理人合约**</mark>是所有法律行为相关写指令的唯一入口，并维护两个映射表，用于根据<mark style="color:blue;">**分项管理人合约**</mark>和<mark style="color:blue;">**登记簿合约**</mark>各自的序列号来记录、检索并将指令路由至其地址。据此，总管理人合约在收到任何写指令后，均会利用分项管理人合约映射表将该指令路由至相应地址。

<mark style="color:blue;">**分项管理人合约**</mark>构成控制身份验证、条件、程序及相关行为法律后果的核心计算层。它们不存储任何状态变量，运行方式类似于库，仅能通过总管理人合约发起的委托调用进行调用。据此，任何经由分项管理人合约路由的调用均在总管理人合约的上下文环境中执行，使得总管理人合约被记录为“msg.sender”。

所有登记簿合约的写操作API均仅限于其各自的直接管理人或总管理人合约访问。在每个登记簿合约创建时，总管理人合约的地址即被永久记录其中，且在初始化过程中，直接管理人角色即被转让给总管理人合约。据此，由总管理人合约发起、经分项管理人合约通过委托调用路由的指令调用，将被适当验证并获准访问登记簿合约的相关API。反之，任何源自总管理人合约以外账户的未经授权调用，均将被有效排除并予以阻断。

通过该机制，总管理人合约自动将写指令路由至相应的分项管理人合约，且各分项管理人合约中定义的具体算法均在总管理人合约的上下文环境中执行，使得所有计算均针对总管理人合约的状态进行。

由此，外部账户及第三方合约被有效排除于干扰公司治理活动的可能之外，从而确保公司簿记记录可安全且自主地运行，无需人为干预。

</details>

<details>

<summary>🏛️ 4.3 整个平台的用户身份识别机制</summary>

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

<mark style="color:blue;">**ComBoox平台**</mark>中的“用户”：

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

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

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

因此，ComBoox采用独立的<mark style="color:blue;">**注册中心合约**</mark>来专门管理整个平台上所有用户的数字身份。&#x20;

***

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

这种“<mark style="color:blue;">**去标识化**</mark>”的身份管理模式，一方面是公有区块链的技术特点决定的，另一方面也有利于保护用户的隐私信息。

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

***

借鉴分布式数字身份的理念，<mark style="color:blue;">**注册中心合约**</mark>通过一个专门的<mark style="color:blue;">**用户编号**</mark>表来注册、管理用户身份，同时提供了一个可供平台内已注册合约随时校验账户身份的查询接口。&#x20;

#### （1）用户编号表&#x20;

用户编号表，以账户地址为检索键、以无符号整数为映射值（address => uint256），可通过专门接口来查询获取特定账户地址对应的<mark style="color:blue;">**用户编号**</mark>。

用户行权时，公司相关的<mark style="color:blue;">**分项管理人合约**</mark>会通过一个<mark style="color:blue;">**许可费收取**</mark>（Royalty Charge）的专用库合约，调用<mark style="color:blue;">**注册中心合约**</mark>的查询接口。<mark style="color:blue;">**许可费收取合约**</mark>使分项管理人合约能够获取指令发出账户的用户编号，然后系统根据相应<mark style="color:blue;">**登记簿合约**</mark>的记录验证用户的身份和访问权限。

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

#### （2）用户注册&#x20;

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

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

#### （3）备用钥匙

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

#### （4）用户编号查询权限

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

</details>

## 相关源代码

{% content-ref url="/spaces/bTRjM2PujnZxSvv5X3VP/pages/9ZMiKighnM6XPGZbAe4t" %}
[RolesRepo](https://comboox.gitbook.io/whitepaper-en/comboox-source-code/source-code/libraries/rolesrepo)
{% endcontent-ref %}

{% content-ref url="/spaces/bTRjM2PujnZxSvv5X3VP/pages/AckwCdzakJ5vn6ldkTzJ" %}
[AccessControl](https://comboox.gitbook.io/whitepaper-en/comboox-source-code/source-code/components/accesscontrol)
{% endcontent-ref %}

{% content-ref url="/spaces/bTRjM2PujnZxSvv5X3VP/pages/zIlEIrCIHVPgvhdO80zi" %}
[GeneralKeeper](https://comboox.gitbook.io/whitepaper-en/comboox-source-code/source-code/bookkeepers/generalkeeper)
{% endcontent-ref %}

{% content-ref url="/spaces/bTRjM2PujnZxSvv5X3VP/pages/sVRunf2QgjBl93FrdSyP" %}
[UsersRepo](https://comboox.gitbook.io/whitepaper-en/comboox-source-code/source-code/libraries/usersrepo)
{% endcontent-ref %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://comboox.gitbook.io/whitepaper-cn/xi-tong-zong-shu/4.-shen-fen-shi-bie-yu-quan-xian-kong-zhi.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.