合约管理

管理

StarkEx合约由一个或多个管理者管理,发起管理人是合约的部署者。
管理者拥有执行以下操作的唯一权限:
1.Nominate additional governors (mainNominateNewGovernor) 提名其他管理员(主要提名新管理员)
2.Remove other governors (mainRemoveGovernor)除名其他管理员(主要除名管理员)
3.Add new Verifiersand AvailabilityVerifiers添加新的验证器和验证器的可用性
4.Remove Verifiersand AvailabilityVerifiersafter a time-lock allows it在时间锁定允许的情况下删除验证器和验证器的可用性
5.Nominate Operator (see Operator) and Token Administrators (see Tokens) 提名操作员(请参阅操作员)和代币管理员(请参见代币)
添加管理者的过程分为两步:
1.首先,现有管理者提名新管理人(mainNominateNewGovernor主要提名新管理人)
2. 然后,新管理人必须接受管理权才能成为管理人(mainAcceptGovernance主要接受管理权)
此两步流程可确保除非存在具有相应私钥的实体,否则无法提名管理者的公钥。 这是为了防止添加过程中的错误。
管理者的私钥通常应保存在安全的冷钱包中。

操作员

合约的操作员是有权通过调用updateState(状态更新)提交状态更新请求的实体。
合约管理者可以立即任命或移除一名操作员(如上所述)。
通常,操作员是StarkEx服务的热钱包,用于提交证明以实现状态更新。

代币

注册新资产需要在系统中定义新资产类型,并将其与字节的assetInfo(资产信息)数组和量化因子(quantum量子)相关联。
要注册新资产,tokenAdmin(代币管理员)调用registerToken(注册代币),提供assetType(资产类型)和assetInfo(资产信息)。 有关如何计算两者的完整说明,请参见此处
一旦注册,资产就无法从系统中删除,因为链下账户可能会使用它们的ID。
合约Governor管理者可以立即任命或撤消tokenAdmin(代币管理员)(如上所述)。 通常,tokenAdmin(代币管理员)的私钥应保存在冷钱包中。

验证器

验证程序合约是贯彻实施STARK验证器的体现,StarkEx服务将STARK证明发送给STARK验证器(请参阅STARK Cairo验证器)。 另外,StarkEx合约可以调用验证器,以检查有效证明是否被给定状态的转换所接受(通常被描述为假定证明在公共输入上的哈希值)。
StarkEx合约通常将仅查询一个验证器合约以进行证明有效性检查。 但是,如果需要更新验证器算法,额外的验证器可能会被合约管理者registered注册)。 然后,也要求这些新的验证器来证明状态转换的有效性,并且仅当所有的验证器证明状态转换有效时,才接受状态转换。
这个验证器是我们的Universal Cairo verifier,通用Cairo验证器,能够验证任何Cairo程序。
为了确认Cairo验证器已验证链下Cairo程序是正确的,StarkEx智能合约将链下程序的哈希值与Cairo验证器验证的程序哈希值进行比较。 该哈希值与证明一起被打包输入到Cairo验证器。
移除验证器也是管理者的职责。 移除过程比验证器注册更为敏感,因为它可能会影响系统的稳健性。 因此要分两步执行:
宣布移除验证器的意图。
2.VERIFIER_REMOVAL_DELAY(验证器移除延迟)时间锁到期后,可以通过调用removeVerifier(移除验证器)进行实际的删除。
移除延迟确保了关心系统稳健性的用户有充足的时间离开交易所。

可用性验证器

委员会合约是交易所服务发送委员会成员签名的合约,以证明他们拥有数据的副本,在该数据上,新的Merkel根将被接受为新的状态根(请参见此处)。 此外,交易所合约可以调用availability verifier(可用性验证器),以验证这种签名是否确实依照“给定状态转换的委员会合约”中定义的足够数量的委员会成员提供(如新旧保险库和订单根中所示) 。
仅当StarkEx在Validium 模式下工作时,才需要委员会机制。 当StarkEx在ZK-Rollup mode模式下工作时,所有相关数据作为证明输出的一部分出现在链上-因此无需委员会。
交易所合约通常只对一个委员会合约进行数据可用性检查。 但是,如果需要更新委员会,额外的验证器可能会被合约管理者registered注册。然后,还需要此类新的可用性验证器来证明状态转换的可用性,并且仅当所有可用性验证器都对其进行证明时,状态转换才被接受。
移除可用性验证器也是管理者的职责。 移除过程比可用性验证器注册更为敏感,因为它可能会影响系统的稳健性。 因此,要分两步执行:
1.管理者首先通过调announceAvailabilityVerifierRemovalIntent
宣布移除可用性验证器的意图。
2. VERIFIER_REMOVAL_DELAY(验证器移除延迟)时间锁到期后,可以通过调用removeAvailabilityVerifier(移除可用性验证器)进行实际的删除。
移除延迟确保了关心系统稳健性的用户有充足的时间离开交易所。

状态更新

StarkEx合约通过存储保险库状态(链下账户状态)和订单状态(包括订单和转款)的Merkle根来跟踪链下交易所服务的状态。
Operator操作员是唯一有权通过调用“updateState(更新状态)”来提交状态更新的实体,并且仅在合约未处于冻结状态时才允许这样做(请参见“FullWithdrawals全额提款”)。 该调用包括STARK证明的publicInput(公共输入),以及其他数据(applicationData应用程序数据),其中包括未被该证明验证的信息。
publicInput(公共输入)包括如上所述的当前(初始)和下一个(最终)Merkle根,Merkle树的高度,保险库操作列表和条件性转账列表。

保险库操作

保险库操作可以是斜坡操作(存款/提款),也可以是清除强制操作请求的指示。 每个保险库操作均用3个字编码,如下所示:
1.字0:保险库持有者的Stark Key(或请求者表示全额提款为假的Stark Key)。
2.字1:资产ID表示要么是货币(同质化代币)或唯一代币ID及其链上合约关联(用于非同质化代币)。
3.字2:
1.链下账户保险库的ID
2.保险库余额变化以偏差表示(超出2 ** 63)。 余额变动为负表示提取,而金额为正表示存款。余额零更改可用于表示非上述两者的操作(例如全额提款请求为假)。
3.指示操作是否需要清除全额提款请求的一数字位。
上述信息由交易所合约使用,以便更新用于存款提款的待处理帐户。
publicInput(公共输入)中的下一部分是与批处理中的条件性转款相对应的编码条件的列表。
applicationData(应用程序数据)包含以下信息:
1.当前批次的ID(操作员正要为其提交更新)。
2.链上接受的最后一批的预期ID。 这允许操作员提交状态更新,以确保在先前不同的批次中可能已经生成了多个有效更新的情况下,相同的批次订单依然按照操作员的意图在链上被接受(这不太可能但有可能发生的事件)。
3.对于批处理中的每个条件性转账,会涉及两个字符:
1.字0:事实注册表合约的地址。
2.字1:上述合约中有待核实的事实,证明该条件已在链上得到满足。
证明了状态更新的有效性的STARK凭证,是由交易所服务单独提交给(一个或多个)STARK完整性验证器合约。同样,证明了保险库和订单数据的可用性的委员会成员的签名,是由交易所服务单独提交给了(一个或多个)可用性验证器合约。
仅当完整性验证器合约和可用性验证器合约确实已收到健全性和数据可用性的证明时,StarkEx合约才会接受状态更新。
一旦状态更新成功,将广播 LogRootUpdate(根更新记录)事件。
Last modified 6mo ago