Skip to content

基本模型

Jump to bottom
zouxyan edited this page Jan 10, 2025 · 1 revision

基本概念

跨链通道（Cross Chain Lane）

AntChain Bridge支持合约发送消息给另一条链的另一本合约，必然存在四元组：（发送链域名、发送合约、接收链域名、接收合约），这个四元组就是AntChain Bridge定义的跨链通道（Cross Chain Lane），类似地，定义链与链之间的二元组（发送链域名、接收链域名）。

classDiagram
direction BT
class CrossChainChannel {
  - CrossChainDomain receiverDomain
  - CrossChainDomain senderDomain
}
class CrossChainLane {
  - CrossChainIdentity senderId
  - CrossChainIdentity receiverId
  - CrossChainChannel crossChainChannel
}

CrossChainLane  ..>  CrossChainChannel : «create»
CrossChainLane "1" *--> "crossChainChannel 1" CrossChainChannel
Loading
  • senderId：发送合约的32字节ID，AntChain Bridge要求发送的跨链消息中，所有合约都要映射到32字节的空间中，这往往是BBC插件合约中实现的，比如Ethereum 20bytes的地址通过前缀补零的方式完成映射；
  • receiverId：接收合约的32字节ID；
  • crossChainChannel：CrossChainChannel 发送链与接收链域名；

PTC信任根（PTC Trust Root）

一个PTC加入AntChain Bridge网络之前，必须要将自己至少一个信任根发布到BCDNS，PTCTrustRoot包含了用于验证PTC背书的验证信息，比如Committee PTC的公钥集合，以及PTC开放的网络信息，比如Committee PTC各个节点的IP地址等。

在PTCTrustRoot中，包含了一个版本号-VerifyAnchor验证锚的映射，如果PTC更新了自己的验证信息，比如中继链节点变更了，则需要增加版本号，来增加BCDNS上存储的映射里面的验证锚，已存在版本号的验证锚不得修改，在中继链场景下，这个“版本号”可以理解为中继链块高，AntChain Bridge网络则可以通过新的VerifyAnchor来验证PTC给的证明，比如TpBTA。

classDiagram
direction BT
class PTCTrustRoot {
  - Map~BigInteger, PTCVerifyAnchor~ verifyAnchorMap
  - AbstractCrossChainCertificate ptcCrossChainCert
  - SignAlgoEnum sigAlgo
  - byte[] networkInfo
  - CrossChainDomain issuerBcdnsDomainSpace
  - byte[] sig
}
class PTCVerifyAnchor {
  - BigInteger version
  - byte[] anchor
}

PTCTrustRoot "1" *--> "verifyAnchorMap *" PTCVerifyAnchor
Loading

PTCVerifyAnchor：

  • version：该PTCVerifyAnchor的版本号，版本号必须是递增的，代表先后顺序；
  • anchor：序列化的PTC验证信息，Committee PTC可以参考🔗；

PTCTrustRoot：

  • verifyAnchorMap：上文所提到的验证锚映射，key为版本号，value为VerifyAnchor；
  • ptcCrossChainCert：PTC的跨链身份证书📄；
  • sigAlgo：签名算法，参考枚举类型SignAlgoEnum；
  • networkInfo：PTC的网络信息🛜，不同类型PTC不同，比如Committee PTC参考🔗；
  • issuerBcdnsDomainSpace：签发PTC证书的BCDNS域名空间，比如跟域名空间为空字符串；
  • sig：PTC证书的持有者的签名，使用的上面字段sigAlgo的算法；

区块链信任锚（Blockchain Trust Anchor, BTA）

classDiagram
direction BT
class AbstractBlockchainTrustAnchor {
  - byte[] amId
  - SignAlgoEnum bcOwnerSigAlgo
  - BigInteger initHeight
  - byte[] initBlockHash
  - byte[] bcOwnerSig
  - int subjectVersion
  - ObjectIdentity ptcOid
  - String subjectProduct
  - byte[] extension
  - byte[] subjectIdentity
  - byte[] bcOwnerPublicKey
  - CrossChainDomain domain
}
class BlockchainTrustAnchorV1 {
  - int version = 1
}
class IBlockchainTrustAnchor {
<<Interface>>

}
class SignAlgoEnum {
<<enumeration>>
  +  SM3_WITH_SM2
  +  ED25519
  +  KECCAK256_WITH_SECP256K1
  +  SHA256_WITH_RSA
  +  SHA256_WITH_ECDSA
}

AbstractBlockchainTrustAnchor  ..>  IBlockchainTrustAnchor 
AbstractBlockchainTrustAnchor "1" *--> "bcOwnerSigAlgo 1" SignAlgoEnum 
BlockchainTrustAnchorV1  -->  AbstractBlockchainTrustAnchor
Loading

BTA是区块链接入AntChain Bridge的信任基础信息，其核心作用就是绑定域名和实际的区块链网络，通常包含区块链的一种快照，比如某个高度的共识信息，可以通过这种快照验证区块链数据的合法性、存在性，确认跨链消息是从域名绑定的区块链发出的，BTA是通过域名跨链证书持有者的签名和在subjectIdentity等字段填入区块链快照的方式来实现上面功能的。

  • amId：一般放入AM合约地址，通常会用来验证跨链消息的来源，比如AM合约的事件；
  • bcOwnerSigAlgo：签名算法，参考枚举类型SignAlgoEnum；
  • initHeight：初始区块高度，从该高度开始支持AntChain Bridge跨链；
  • initBlockHash：初始区块hash，从该区块hash开始支持AntChain Bridge跨链，高度和hash会用于PTC出具TpBTA和锚定共识状态验证；
  • bcOwnerSig：区块链域名证书持有者的私钥对整个BTA的签名；
  • subjectVersion：当前BTA数据的版本，将支持BTA更新，每次更新版本号要求大于之前版本，初始为0；
  • ptcOid：要求为BTA对应链进行背书的PTC ObjectIdentity，唯一对应一个PTC服务，表明区块链域名Owner是认可PTC服务的；
  • subjectProduct：BTA对应链的类型，需要和使用的HCDVS插件类型对应；
  • extension：拓展信息，通常包含一些需要携带给PTC的配置信息，比如希望TpBTA背书的跨链通道、Committee的背书策略等；
  • subjectIdentity：区块链的快照主体内容，这需要和HCDVS逻辑相对应，HCDVS会使用这个字段的内容来作为后续验证共识状态和跨链消息的锚定信息:anchor:；
  • bcOwnerPublicKey：区块链域名持有者的X509公钥；
  • domain：该BTA将要绑定的域名，每个域名仅能绑定一个BTA；

第三方区块链信任锚（Third-Party Blockchain Trust Anchor, TpBTA）

classDiagram
direction BT
class ThirdPartyBlockchainTrustAnchor {
  - BigInteger ptcVerifyAnchorVersion
  - int version
  - CrossChainLane crossChainLane
  - byte[] endorseProof
  - int btaSubjectVersion
  - int tpbtaVersion
  - PTCCredentialSubject signerPtcCredentialSubject
  - HashAlgoEnum ucpMessageHashAlgo
  - byte[] endorseRoot
}
class ThirdPartyBlockchainTrustAnchorV1 {
  + int MY_VERSION = 1
}

ThirdPartyBlockchainTrustAnchorV1  -->  ThirdPartyBlockchainTrustAnchor
Loading

TpBTA是PTC在完成BTA验证之后，对某个跨链通道出具的背书证明，TpBTA中包含了用于验证PTC对跨链数据证明的所必需的锚定数据，比如Committee PTC的公钥集合、背书策略等内容，接收链系统合约想要验证跨链证明，则必须先获得对应的TpBTA。

每个TpBTA是针对发送链为起点的跨链通道来进行背书的，每一条跨链SDP消息，都会必须匹配到至少一个TpBTA才可以被验证、背书和发出，同时这也意味着该跨链通道的接收链会接收到该PTC的证明，使用该TpBTA可以验证该证明，按照TpBTA的跨链通道，对于发送链的所有跨链通道可以形成一定的偏序关系，这里对TpBTA做出分类：

  1. 一元组（Blockchain Level）：sender domain

    TpBTA的跨链通道仅包含发送链域名，覆盖范围最广，所有的该链发出的消息都可以匹配该类型。

  2. 二元组（Channel Level）：sender domain, receiver domain

    TpBTA的跨链通道包含发送域名、接收域名，即所有发送、接收链之间的消息都匹配到该类型。

  3. 四元组（Lane Level）：sender domain, sender id, receiver domain, receiver id

    TpBTA的跨链通道包含发送域名、发送合约ID、接收域名、接收合约ID，即所有发送合约、接收合约之间的消息都匹配到该类型，该类型范围最小。

因此形成偏序关系：Blockchain Level >= Channel Level >= Lane Level。

这里规定：

🥇 TpBTA必须是三种类型中的一个，不支持其他跨链通道；

🥈 所有有效的TpBTA之间不允许存在交集，当有交集时，优先选择最大的TpBTA执行跨链验证和背书；

下面介绍字段：

  • ptcVerifyAnchorVersion：PTC信任根中VerifyAnchor的锚定版本号，表示TpBTA是由该版本的VerifyAnchor来提供背书的；

  • version：TpBTA数据结构的版本，当前使用版本1；

  • crossChainLane：当前TpBTA背书的跨链通道；

  • endorseProof：PTC对TpBTA的证明，不同类型PTC结构不同，比如Committee PTC证明参考🔗；

  • btaSubjectVersion：当前TpBTA背书的BTA的版本号；

  • tpbtaVersion：当前TpBTA的版本号，顺序递增，用于未来支持TpBTA更新；

  • signerPtcCredentialSubject：PTC证书中，身份持有者的信息，参考🔗；

  • ucpMessageHashAlgo：用于对UCP消息计算hash值的算法，参考🔗；

  • endorseRoot：PTC为该跨链通道背书的信任根，可以用于验证第三方证明，比如Committee PTC的*CommitteeEndorseRoot*；

共识状态（Consensus State）

区块链的账本一致性依赖于共识状态，区块链的状态往往是线性或者存在最高置信度的，通常用高度来表示状态的版本，AntChain Bridge使用【共识状态】来表示某高度下的区块链状态，比如蚂蚁链的区块头等数据。

classDiagram
direction BT
class ConsensusState {
  - byte[] consensusNodeInfo
  - long stateTimestamp
  - byte[] hash
  - BigInteger height
  - byte[] endorsements
  - byte[] parentHash
  - byte[] stateData
  - CrossChainDomain domain
}
class ValidatedConsensusState {
  - int tpbtaVersion
  - short vcsVersion
  - PTCTypeEnum ptcType
  - ObjectIdentity ptcOid
  - byte[] ptcProof
}
class ValidatedConsensusStateV1 {
  + short MY_VERSION = 1
}

ValidatedConsensusState  -->  ConsensusState 
ValidatedConsensusStateV1  -->  ValidatedConsensusState
Loading

ConsensusState是共识状态的模型实现，在BBC接口中，就有readConsensusState这样的接口，要求插件从异构链的区块映射、组装一个ConsensusState对象并返回，ValidatedConsensusState则是经过PTC验证之后返回的已验证共识状态，简单来讲是经过PTC签名的，HCVDS将收到h高度的ConsensusState，并用h-1高度的ValidatedConsensusState来验证它，并产生h高度的ValidatedConsensusState。

字段介绍：

ConsensusState

  • consensusNodeInfo：在当前高度的共识信息，在BBC插件里面放入，在HCDVS的验证共识状态接口使用，通常是存放共识节点公钥集合等内容；
  • stateTimestamp：当前高度区块的时间戳，单位为毫秒；
  • hash：区块hash值；
  • height：区块块高；
  • endorsements：区块链共识系统对该区块的证明，比如共识节点签名集合；
  • parentHash：当前区块的父区块hash；
  • stateData：共识状态的序列化数据，往往是区块头数据、共识切换证明等内容；
  • domain：该区块所在区块链的域名，BBC插件内部往往不需要填入该字段；

ValidatedConsensusState

  • tpbtaVersion：PTC为该共识状态背书所使用的TpBTA；
  • vcsVersion：当前ValidatedConsensusState结构的版本，当前为1；
  • ptcType：背书的PTC的类型，比如COMMITTEE；
  • ptcOid：背书的PTC的ObjectIdentity，参考上面对于PTC证书的介绍；
  • ptcProof：PTC对ValidatedConsensusState的背书证明，不同的PTC类型不同；

第三方证明（Third-Party Proof, TpProof）

TpProof是PTC为跨链消息开出的证明，保证了这笔跨链消息的确实是从发送链域名对应的AM合约发出的，并对此进行了签名✍️，TpProof可以通过TpBTA中的背书信任根（endorseRoot）来验证👀。

classDiagram
direction BT
class ThirdPartyProof {
  - CrossChainLane tpbtaCrossChainLane
  - byte[] rawProof
  - int tpbtaVersion
  - ThirdPartyResp resp
}
class ThirdPartyResp {
  - byte[] body
}

ThirdPartyProof "1" *--> "resp 1" ThirdPartyResp 
ThirdPartyProof  ..>  ThirdPartyResp : «create»
Loading
  • tpbtaCrossChainLane：用于提供证明的背书信任根的TpBTA的跨链通道；
  • tpbtaVersion：用于提供证明的背书信任根的TpBTA的版本号，它和上面👆tpbtaCrossChainLane唯一确定一个TpBTA；
  • rawProof：PTC对消息给出的证明，Committee PTC可以参考🔗；
  • resp：ThirdPartyResp 包含了跨链消息，即类CrossChainMessage，序列化后放在字段body；
Clone this wiki locally