Axelar 网络: 将应用程序与区块链生态系统连接起来

摘要

1. 简介

区块链系统正在迅速普及,并吸引了资产代币化、去中心化金融和其他分布式应用程序的新用例。以太坊、门罗币等几大平台,EOS、Cardano、Terra、Cosmos、Avalanche、Algorand、Near、Celo 和 Polkadot 提供独特的功能,使它们对不同的应用程序、用例和最终用户具有吸引力的开发环境

[5, 11, 4, 21, 20, 23, 24, 19, 6, 14, 25]。但是,每个新平台的有用功能目前只提供给不到 1% 的生态系统用户,即该平台上原生代币的持有者。

我们能否让平台开发人员轻松地将他们的区块链插入其他生态系统?我们可以启用应用程序构建器,在满足其需求的最佳平台上构建,同时仍然跨多个区块链生态系统?我们可以允许用户直接从他们的钱包的任何区块链上与任何应用程序交互吗?

为了连接区块链生态系统并使应用程序能够在它们之间无摩擦地通信,我们提出了 Axelar 网络。验证者共同运行拜占庭共识协议,促进跨链请求。任何人都可以加入网络、参与和使用它。底层网络针对跨链请求特有的高安全性和活性要求进行了优化。阿克塞尔网络还包括协议套件和 API。

核心协议是:

• 跨链网关协议(CGP)。该协议类似于互联网边界网关协议。该协议用于连接多个自治区块链生态系统,并且负责在它们之间进行路由。区块链不需要“讲任何自定义语言”,它们的平台开发者不需要对他们的链进行任何自定义更改,他们的链可以轻松接入全球网络。

• 跨链传输协议(CTP)。该协议类似于应用级协议文件传输,互联网上的超文本传输协议。它是一个应用层协议,栈位于路由协议(如 CGP 和其他路由技术)之上。应用程序开发人员可以在任何链上连接他们的 dapps 来执行跨链请求。用户可以使用CTP协议,类似于 HTTP GET/POST 的简单 API 调用任何链上的应用程序交互要求。开发者可以在区块链平台上的任意两个地址之间锁定、解锁和转移资产,执行跨链应用程序触发器(例如,链 A 上的 dapps,可以更新其状态,如果链 B 上的其他应用程序满足某些搜索条件(利率 > X),以及

跨链应用之间执行通用的跨链请求(链A上的智能合约可以调用更新链 B 上智能合约的状态)。该协议支持程序的可组合性跨区块链生态系统。

Axelar 网络具有以下优点:

• 对于区块链平台建设者:能够轻松地将他们的区块链插入所有其他区块链生态系统。只需在链上设置门槛账户即可接入网络。

• 对于dapps 构建者:应用程序构建者可以在任何地方托管他们的dapps,锁定、解锁、转移资产,并通过CTP API 与任何其他链上的应用程序通信。

• 对于用户:用户可以直接从他们的钱包与生态系统中的所有应用程序进行交互。

最后,Axelar 网络是一个面向开发人员和全球社区的平台。它的治理模式对任何人开放。开发者可以提出新的集成点、路由和应用级协议,用户可以通过对提案进行投票来决定是否采用它们,如果获得批准,验证者将采用这些更改。

以前解决跨区块链互操作性的尝试属于以下四类之一:集中式交换、可互操作的生态系统、封装资产和令牌桥。我们在下面简要总结了这些方法。

中心化系统。今天,中心化系统是唯一真正满足生态系统互操作性需求的可扩展的解决方案。他们可以相对轻松地列出任何资产或登上任何平台。然而,众所周知,中心化系统存在各种安全问题,无法为需要强大安全性、透明度和开放治理的新兴去中心化金融系统提供动力。他们无法在分散的应用程序增长时为其提供动力。

互操作性中心。 Cosmos、Polkadot、Ava 实验室等项目,使用自定义链间通信协议解决了其生态系统原生侧链之间的互操作性 [23、25、24]。例如,可以启动一个可以与 Cosmos Hub 通信的侧链(Cosmos 区域)。侧链必须基于 Tendermint 共识,并使用 Cosmos Hub 本地理解的协议。把使用不同语言的其他区块链和生态系统的连接留给外部技术。

成对桥。包裹资产(例如包裹比特币)试图填补生态系统中缺失的跨链互操作性空白。一个例子是 tBTC [9],这是一种自定义协议,其中巧妙地结合了智能合约和抵押品来保护传输。这些解决方案需要大量的工程来构建 — — 对于每个链,开发人员必须在目标链上构建一个新的智能合约,从源链解析状态证明(类似于原则上每个侧链如何解析状态其他链)。使用这种方法只部署了少数网桥。当底层区块链之一想要升级其共识规则或交易格式时,这些方法不会扩展。这是因为所有依赖于这些链状态的智能合约都需要升级。还必须设置验证器并要求它们锁定不同的资产,以便对任何资产转移进行超额抵押,这限制了此类转移的经济效率。

我们还看到了其他一些平台开发人员的单一用途的桥梁,它们重写了智能合约中的状态转换逻辑,以连接到其他生态系统 [1, 7]。它们遭受多个可扩展性问题,不允许生态系统统一扩展,并为应用程序引入额外的依赖项。例如,如果一个平台发生变化,那么所有网桥上的所有智能合约都需要升级。这最终将使生态系统陷入僵局,没有人能够升级。 最后,如果一个单用途网桥连接平台 A 和 B,第二个单用途网桥连接 B 和 C,这并不意味着 A 上的应用程序将能够与 C 上的应用程序对话。可能需要创建另一个单一用途的桥接或重新布线应用程序逻辑。

解决互操作性的其他尝试包括联合预言机(例如 Ren [8])和特定于应用程序的可互操作区块链 [10]。

总而言之,现有的互操作性解决方案需要平台开发人员和应用程序构建人员进行繁重的工程工作,他们必须了解不同的通信协议才能在每对生态系统之间进行通信。 因此,互操作性在当今的区块链空间中几乎不存在。归根结底,平台开发人员希望专注于构建平台并针对其用例对其进行优化,并能够轻松插入其他区块链。 应用程序开发人员希望在满足其需求的最佳平台上构建 dapps,同时仍能利用用户、流动性并与其他链上的其他 dapps 进行通信。

2. 对可扩展的跨链通信的探索

从本质上讲,跨链通信需要异构网络找到使用相同语言进行通信的能力。为了解决这个问题,我们解释了 Axelar 协议套件,描述了它的高级属性,并解释了这些属性如何解决可扩展跨链通信的核心问题。

1.“即插即用”集成。不应该要求区块链平台构建者执行繁重的工程或集成工作以使用某种“自定义语言”来支持跨链。跨链协议应该能够无摩擦地插入任何现有的或新的区块链。应该以最少的努力添加新资产。

2. 跨链路由。发现网络地址、路由路径和网络等功能是互联网的核心,并由 BGP 和其他路由协议提供便利。同样,为了促进跨区块链生态系统的通信,我们需要支持跨越地址、应用程序和路由的发现。

3. 升级支持。如果其中一个区块链生态系统发生变化,不应影响其他区块链的互操作性。系统需要识别更新,应该尽量减少工作量,需要支持它们(即,不应重写“状态转换逻辑”,并且应用程序不应中断)。

4. 应用程序的统一语言。应用程序需要一个简单的协议来锁定、解锁、传输和与其他应用程序通信,无论它们驻留在哪条链上。该协议必须与链无关并支持简单的调用,类似于 HTTP/HTTPS 协议,允许用户和浏览器与任何网络服务器进行通信。随着越来越多的网络和资产加入较低级别的路由协议,应用程序应该能够使用它们进行通信而无需重写其软件堆栈。

接下来,我们总结了这些协议必须满足的安全要求。

1. 去中心化的信任。网络和协议必须是去中心化的、开放的,并允许每个人公平参与。

2.安全性高。系统必须满足高安全保证。系统需要在跨链网络处理过程中保护资产和状态的安全。

3. 高流动性。系统必须保证高流动性,以支持利用其跨链特性的应用程序。

满足这些属性的一个子集很容易。例如,您可以与他们的朋友创建一个联合多重签名帐户,并在相应的链上锁定/解锁资产。这种系统本质上很容易受到串通和审查攻击,并且缺乏对验证者保护它们的适当激励。创建一个去中心化的网络和协议套件,任何人都可以在受到正确激励的情况下参与其中,实现无摩擦的跨链通信,但解决它是一个困难的问题,需要谨慎结合共识、加密和机制设计协议。

3. Axelar 网络

Axelar 网络为跨链通信提供了一个统一的解决方案,满足了平台开发者的需求 — — 他们不需要集成工作,应用程序构建者 — — 一个简单的协议和 API 来访问全球流动性并与整个生态系统进行通信。

Axelar 网络由一个去中心化网络组成,该网络连接了使用不同语言的区块链生态系统和一个带有 API 的协议套件,使应用程序可以轻松执行跨链请求。该网络连接现有的独立区块链,如比特币、Stellar、Terra、Algorand、和互操作性中心,例如 Cosmos、Avalanche、以太坊和 Polkadot 等解决方案。我们的使命是使应用程序开发人员能够使用通用协议和 API ,更轻松地构建此类应用程序,而无需在底层推出其专有的跨链协议或重写应用程序作为新的桥梁。为此,我们设计了一个协议套件,包括跨链网关协议(见第 6 节)和跨链传输协议(见第 7 节)。

网络的核心组件是底层的去中心化协议。验证者共同维护 Axelar 网络并运行保护 Axelar 区块链的节点。他们被选为用户的委托过程。验证者根据委托的股权按比例获得投票权给他们。验证者就平台连接的多个区块链的状态达成共识。区块链负责维护和运行跨链路由和传输协议。治理规则允许网络参与者制定协议决策,例如桥接哪些区块链以及支持哪些资产。

Axelar 区块链遵循类似于 Cosmos Hub 的委托权益证明 (DPoS) 模型。用户选举验证者,他们必须将他们的权益抵押,以参与共识并保持高质量的服务。 DPoS 模型允许维护大型去中心化验证器集和强大的激励机制,以保证验证器负责维护加密阈值方案的桥梁和份额。作为共识的一部分,验证者运行其他区块链的轻客户端软件,允许他们验证其他区块链状态。验证者将这些状态报告Axelar 区块链,一旦有足够多的验证者报告,比特币、以太坊和其他链的状态就会记录在 Axelar 上。

随后,Axelar 基础层随时了解外部区块链的状态,从而创建来自其他区块链的“传入桥梁”。验证者共同维护其他区块链上的阈值签名自然账户(例如,80% 的验证者必须批准并共同签署任何交易),这允许他们跨链锁定和解锁资产和状态,并在其他区块链上发布区块链状态,“输出的桥梁”。总而言之,可以将 Axelar 网络视为去中心化的跨链读写预言机。

文档的其余部分描述了网络背后的预备知识和构建块(第 4 节)、网络的一些技术细节(第 5 节)、跨链网关协议(第 6 节)以及跨链传输协议(第 7 节)。

4.预备知识

令 V r 表示 R 轮 Axelar 验证者的集合。每个验证者都有一个权重,(0, 1] 中的数字表示该特定验证者的投票权。所有验证者的权重加起来为 1。验证者是正确的,如果她运行一个符合 Axelar 协议规则的节点。为了完成区块,或者签署跨链请求, Axelar 需要正确的总权重 > F 的验证器。我们称参数 F ∈ [0.5, 1]协议阈值。

Axelar 可以基于即时终结性委托证明的区块链。验证者在每一轮 i 运行拜占庭容错 (BFT) 共识以完成第 i 个区块。一旦第 i 个区块被敲定,就会运行新的 BFT 共识来敲定第 i+1 个块,依此类推。验证人通过权益委托选举产生。拥有一些权益的用户可以选择运行验证器节点,或者将他们的投票权(权益)委托给现有的验证器,然后由后者代表他们进行投票。验证者集合可以更新,验证者加入/离开集合,用户委托/取消委托他们的投票权。

不同的区块链在不同的网络假设下工作。同步通信意味着在传递消息所需的时间上有一个固定的上限 Δ,其中 Δ 是已知的并且可以内置到协议中。异步通信意味着消息的传递可能需要任意长的时间,众所周知,即使只有一个恶意验证器存在,也无法为异步网络构建 BFT 协议。同步和异步之间的现实折衷是假设部分同步通信。在某个未知的全局稳定时间 (GST) 之前,网络可能是完全异步的,但在 GST 通信之后变得与已知上限 Δ 同步 [17]。

典型的区块链在 > F 正确验证器的假设下工作。对于同步网络通常设置 F = 1/2,但对于部分同步网络的较弱假设,F = 2/3。比特币、它的分叉和当前的以太坊工作量证明版本仅在假设同步的情况下工作。其他像 Algorand 和 Cosmos 只需要部分同步。通过 Axelar 连接链条时,连接工作假设这些链中最强的网络假设,例如在连接比特币和 Cosmos 的情况下是同步的。 Axelar 区块链本身在部分同步设置中工作,因此需要 F = 2/3,但可以通过假设其他现有区块链是安全的并利用其安全性来提高阈值要求。

数字签名。数字签名方案是一组算法(Keygen、Sign、Verify)。 Keygen 输出一对密钥(PK、SK)。只有 SK 的所有者才能对消息进行签名,但任何人都可以验证消息

给定公钥 PK 的签名。今天大多数区块链系统使用标准签名方案之一,例如 ECDSA、Ed25519 或它们的一些变体 [2, 3]。

阈值签名。阈值签名方案使一组 n 方能够以这样的方式拆分签名方案的秘密密钥,即 t + 1 或更多方的任何子集都可以合作产生一个签名,但没有 t 方或更少方的子集可以产生签名,甚至无法了解有关密钥的任何信息。 ECDSA 和 EdDSA 的阈值协议生成的签名看起来与独立算法生成的签名相同。

阈值签名方案用分布式 n 方协议 T.Keygen、T.Sign 代替普通签名方案的 Keygen 和 Sign 算法。这些协议通常需要各方之间的公共广播信道和私有成对信道,并且它们通常涉及多轮通信。成功完成 T.Keygen 后,每个用户都持有一个秘密密钥 SK 和相应公钥 PK 的共享 si。 T.Sign 协议允许这些参与方为在公钥 PK 下有效的给定消息生成签名。任何人都可以使用原始签名方案的验证算法来验证此签名。

对于去中心化网络,阈值方案可能具有以下几个特性:

安全防范不诚实的多数。一些阈值方案有这样的限制,即只有当 n 方中的大多数是诚实时,它们才是安全的。因此,阈值参数 t 必须比 n/2更小 [15]。这种限制通常伴随着需要 2t+1 个诚实方进行签名的事实,即使只有 t+1 个损坏方可以串通来恢复密钥。方案不受这种限制的人据说可以安全地抵御不诚实的多数。正如稍后在第 5.2 节中讨论的那样,跨链平台必须最大限度地提高其网络的安全性,并能够容忍尽可能多的腐败方。因此,能够容忍不诚实多数的方案是必要的。

预签名,非交互式在线签名。为了减少各方签署消息的通信负担,最近的几个协议已经确定了在知道要签名的消息之前,为可以“离线”完成的签名工作 [18, 13]。此离线阶段的输出称为预签名。预签名的产生被视为与 T.Keygen 和 T.Sign 不同的单独协议 T.Presign。预签名协议的输出必须由各方保密,直到他们在签名阶段使用它们。后来,当消息签名成为已知的,只有少量额外的“在线”工作需要在 T.Sign 中完成才能完成签名。在线 T.Sign 阶段不需要各方之间的任何沟通。每一方只是简单地对消息和预签名进行本地计算,然后宣布她的份额签名。 (一旦公开,这些签名份额 s1、…、st+1 很容易被任何人组合以显示实际签名 s。)此属性称为非交互式在线签名。

稳健性。阈值方案仅保证恶意方的子集无法签署消息或学习密钥。然而,这种保证并不排除不良行为者可以阻止其他人,生成密钥或签名的可能性。在某些方案中,即使是单方的恶意行为也可能导致 T.Keygen 或 T.Sign 中止而没有任何有用的输出。唯一的办法是可能与不同的各方重新启动协议。相反,对于去中心化网络,我们希望 T.Keygen 和 T.Sign 成功,即使某些恶意方发送格式错误的消息或丢弃消息协议,至少 t + 1 方是诚实的。这种特性称为稳健性。

故障归因。在 T.Keygen 或 T.Sign 中识别不良行为者的能力称为故障归因。

如果没有过错归因,就很难可靠地排除或惩罚不良行为者,在这种情况下,不良行为者施加的成本必须由每个人承担。这个属性对于去中心化网络也很重要。恶意行为应该通过削减规则来识别和经济上的抑制。

并发设置中的安全性。签名方案需要在并发设置中是安全的,其中密钥生成器和签名算法的多个实例可以并行参与。(Drijvers 等人[16] 例如,在这些设置中展示了对 Schnorr 多重签名方案的攻击)。有满足这些属性的 ECDSA 和 Schnorr 方案的版本 [13, 22]。

ECDSA 和 EdDSA 是迄今为止区块链领域部署最广泛的签名方案。因此,这两种方案的阈值版本一直是最近研究和开发复兴的焦点。对最先进技术感兴趣的读者可以参考 [22, 13, 18] 和最近的调查论文 [12]。

5. Axelar 网络

Axelar 网络维护的桥梁由阈值帐户支持,因此(几乎)所有验证者必须共同授权任何跨链请求。设计一个任何人都可以参与的网络。为确保这些桥梁安全,需要满足以下技术要求:

• 开放会员。任何用户都应该能够成为验证者(遵循网络规则)。

• 成员资格更新。当验证者诚实地离开系统时,他们的密钥需要被适当地撤销。

• 奖励和削减。恶意验证者应该是可识别的,他们的行为必须被识别并由协议解决。

• 共识。阈值方案本身被定义为独立协议。为了在节点之间传播消息,我们需要广播和点对点私人频道。此外,验证器需要就每次调用阈值方案的最新状态达成一致,因为它们通常有多个一轮互动。

• 密钥管理。正如任何 PoS 系统中的普通验证者必须小心保护他们的密钥一样,所以Axelar 验证者也必须保护他们的阈值份额。密钥需要轮换,在线之间分割

和离线部分等。

Axelar 从委托权益证明模型开始,社区选择一组验证器来运行共识。请注意,标准阈值方案对每个玩家都一视同仁,并且没有共识中的“权重”。因此,网络必须考虑验证者的权重来调整它们。一种简单的方法是将多个阈值份额分配给更大的验证器。下面概述了三个基本的验证者共同执行的功能。

• 阈值密钥生成。标准区块链的现有阈值密钥生成算法签名方案(ECDSA,Ed25519)是多个参与者之间的交互协议(见第 4 节)。Axelar 网络上的一项特殊交易指示验证者开始执行这个有状态的协议。每个验证器运行一个阈值守护进程,负责安全地保持秘密状态。

对于协议的每个阶段:

1. 验证器将协议状态保存在其本地存储器中。

2. 调用秘密守护进程,根据协议描述为其他进程生成消息验证器。

3. 它通过广播或通过私有渠道将消息传播给其他验证者。

4. 每个验证器执行状态转换函数以更新其状态,进入下一阶段的协议,并重复上述步骤。在协议的最后,在 Axelar 链上生成一个阈值公钥,它可以是

显示给用户(例如,用于存款)或生成初始请求的应用程序。

• 阈值签名。 Axelar 网络上的签名请求的处理类似于密钥生成要求。例如,当用户想要从其中一个提取资产时调用这些链。这些是交互协议,轮次之间的状态转换,通过 Axelar 区块链视图和每个验证器的本地内存传播的消息的功能被触发。

• 处理验证者成员资格变更。验证器集需要定期轮换以允许新的利益相关者加入集合。在验证器集更新时,我们需要更新阈值,并在新集合中共享密钥。因此,如果我们允许任何人随时加入,我们将不得不非常频繁地更新阈值键。为了防止这种情况,我们每 T 个区块轮换验证器。T 轮之内的间隔,集合 V R 和阈值键是固定的。在每一轮都是一个整体数 T 的倍数,我们更新验证器集如下:

1. 在任何 R 轮中,Axelar 状态都会跟踪当前验证器集 V R。 V R+1 = V R 除非 R + 1 是 T 的倍数。

2. 在轮次 ((i − 1)T, iT] 期间,用户发布绑定/解绑消息。

3. 在回合 iT 结束时,将这些消息应用于 ViT -1 以获得 ViT

  • 在轮换验证者存在的情况下生成阈值密钥和签名。 Axelar 区块链可能会在 R 轮发出对新密钥或阈值签名的请求。签名过程需要增加一轮,我们不想拖慢共识,所以我们要求在 R + 10 轮开始之前生成签名。特别是,验证者只有在看到 R + 9 轮的证书和 R 轮发出的每个密钥生成/签名请求的签名后才开始 R + 10 轮。所有 R 轮请求的结果必须包含在 R + 11 块中。换句话说,R 轮区块提案不包含 R — 11 轮的结果,被认为是无效的,验证者不会对其进行投票。为了确保在验证器集更新之前对所有阈值消息进行签名,Axelar 在等于 -1、-2、…的轮次期间不会发出任何阈值请求。 . . , −9 模 T。

区块链系统的安全性依赖于各种密码学和博弈论协议,以及网络的去中心化。例如,在权益证明区块链中,如果没有适当的激励,验证者可能串通并重写历史,在此过程中窃取其他用户的资金。在工作量证明网络中,如果没有足够的去中心化,很容易创建长分叉和双花,正如对比特币黄金和以太坊经典的多次攻击所证明的那样。

大多数关于区块链安全的研究都集中在主权链上。但是一旦链互操作,就必须考虑新的攻击向量。例如,假设以太坊通过两个智能合约控制的直接桥接器与小型区块链 X 对话,一个在以太坊上,一个在 X 上。 除了我们在第 1.1 节中总结的工程挑战之外,人们必须决定当信任假定时会发生什么违反了 X 的规定。在这种情况下,如果 ETH 转移到 X,X 的验证者可能会串通伪造 X 的历史,他们持有所有 ETH,在以太坊上发布伪造的共识证明并窃取 ETH。当 X 通过直接桥与多个其他链连接时,情况更糟,如果 X 分叉,则效果会通过每个桥传播。为每个成对桥设置恢复治理指南对于任何单个项目来说都是一项艰巨的任务。

Axelar 网络使用以下机制解决安全问题:

• 最大的安全性。 Axelar 将安全阈值设置为 90%,这意味着几乎所有验证者都需要串通提取任何被其网络锁定的资金或伪造状态证明1。在实践中,已经观察到 PoS 验证器的正常运行时间非常长(接近 100%),假设它们得到适当的激励。因此,即使有这么高的阈值,Axelar 网络也会产生区块。然而,在出现问题和网络停顿的极少数情况下,网络需要健壮后备机制来重新启动接下来描述的系统。

• 最大程度的权力下放。由于网络使用阈值签名方案,因此验证器的数量可以尽可能多。网络不受我们验证者数量的限制可以支持,因在不同链上使用多重签名而产生的交易限制或费用,其中复杂性(和费用)随验证者2数量线性增加。

• 稳健的回退机制。在具有上述高安全阈值的网络中必须解决的第一个问题是当网络本身停顿时会发生什么。假设 Axelar 网络本身停滞。我们是否可以有一个回退机制,让用户能够收回他们的资金?为了解决 Axelar 网络本身的任何潜在问题,Axelar 验证者共同控制的区块链 X 上的每个阈值桥接账户都有一个“紧急解锁密钥”。该密钥可以在数千方之间共享,甚至可能是区块链 X 的自定义密钥,在该链的社区中共享。 因此,如果 Axelar 网络停止运行,此密钥将作为后备并启用资产恢复(更多详细信息见下文)。

1 可能会调整将为网络部署选择的最终参数。

2 对于一些区块链,多重签名提供了一种合理的替代方案,其中 gas fes 很小且支持消息格式是合适的。但它们不能扩展到两个最大的平台,如比特币和以太坊。

• 后备机制的最大权力下放。这种回退机制包括一个二级用户恢复集,任何人都可以免费参与其中。这些用户不需要在线、运行节点或相互协调。只有在 Axelar 网络停止且无法恢复时,他们才会“值班”。网络的安全性通过对主要的非常高的阈值而得到增强验证器集和最大程度分散的辅助恢复集。

• 共享治理。通用协议管理 Axelar 网络。总的来说,用户可以投票决定应该通过其网络支持哪条链。该网络还将分配一个资金池,用于在发生意外紧急情况时补偿用户,并通过治理协议进行控制。

下面讨论各种安全机制。

回退机制。当 Axelar 由于高阈值而停止时,“紧急解锁密钥”会控制网络。有多种方法可以实例化此解锁密钥,某些链/应用程序可能会选择对“恢复集”使用不同的变体或完全退出3:

• 选项 a。在区块链项目的基金会和社区中的知名人士之间共享密钥。

• 选项b。共享通过委托 PoS 机制选出的各方。

• 选项c。对于管理链/应用程序 X 的资产和信息的帐户,在 X 的利益相关者/验证者之间共享自定义密钥。假设 X 有治理机制,如果 Axelar 停止,可以应用相同的治理机制来确定行动方案。

现在,给定恢复用户的身份和他们的公钥,一个简单的协议会生成一个没人知道的恢复密钥份额。此外,恢复集的用户不需要在线,直到通过治理机制调用恢复。遵循标准的分布式密钥生成协议,每个 Axelar 验证器共享一个随机值。恢复密钥是通过将这些值相加而生成的。不是以明文形式进行求和,而是在恢复用户的公钥下对所有共享进行加密,然后以同态方式相加(这假定附加同态加密和附加的零知识层,两者都很容易获得)。该协议的结果是恢复公钥 RPK 以及分发给其所有者(例如,发布在链上)的相应密钥 Enci(si) 的共享的潜在数以千计的加密(在恢复用户的公钥下)。 Axelar 桥梁合同包括在特定条件下使用 RPK 收回资金的选项。最后,还可以更新此恢复密钥,甚至更改持有其股份的用户集,而无需参与股东的任何工作。

如果连接到 Axelar 的链 X 断开,则有几个选项:

• 对可以在任何一天移入/移出 X 的资产的美元价值施加限制。因此,恶意链 X 只能窃取 Axelar 之前桥接的所有资产的一小部分验证器检测到这一点,并从以下项目符号开始的治理机制。

• Axelar 治理模块可用于对在这些情况下发生的事情进行投票。例如,如果出现良性错误并且社区重新启动 X,Axelar 治理可以决定从它停止的地方重新启动连接。

  • 如果 ETH 已转移到 X,则自定义以太坊恢复密钥可以确定 ETH 资产会发生什么情况。

3 Axelar 网络上的最终部署将在接近网络启动时完成。

在本节中,我们将通过许多应用程序需求中常见的两个核心示例来解释跨链网关协议和路由机制:

状态同步(第 6.2 节)。将有关源区块链 S 状态的信息发布到目标区块链 D 的状态中。(例如,将比特币区块头发布到以太坊区块链。)

资产转移(第 6.3 节)。将数字资产从 S 转移到 D,然后再返回。(例如,将比特币从比特币区块链转移到以太坊区块链,然后返回到比特币区块链。)

为简单起见,我们假设链 D 对智能合约的支持最少,但 S 可以是任何区块链。

为了桥接不同的链,在每条链上创建阈值账户来控制价值流和他们之间的信息。对于chain Chain,用ChainAxelar 表示账户。

比特币账户。对于比特币和其他非智能合约链,Axelar 验证器创建了一个门槛。根据第 5.1 节的 ECDSA 密钥。此密钥控制比特币上的 ECDSA 帐户,并且是目的地用户发送存款的地址。可以根据用户请求创建个性化的阈值键。钥匙可能会定期更新,通过查询一个Axelar可以找到最新的key和个性化key节点。

具有智能合约的链上的阈值桥接帐户。用 SC 表示链。验证器根据第 5.1 节创建阈值 ECDSA 或 ED25519 密钥,具体取决于链的密钥类型支持。当我们所指的链没有歧义时,我们用PKAxelar 表示这个密钥。这个key控制着SC上的一个智能合约账户,用SCAxelar表示,SC上的任何应用都可以查询 SCAxelar 以了解该密钥的 PK 地址。这样,任何 SC 应用程序都可以识别由 SCAxelar 签署的消息。该协议还需要考虑 PKAxelar 的旋转值。

1. 在 SC 上初始化 SCAxelar。它将 PKAxelar 作为其状态的一部分存储,该状态在 Axelar 上被初始化为它的创世值。 SCAxelar 还包括更新 PK 的规则。

2. 更新PKAxelar,必须提交一个格式为(update, PKnew)的交易并带有签名来自当前的 SKAxelar。然后合约设置PKAxela= PKnew。

3. 每次验证者从 PKI 更新 SC 的阈值密钥到 PKI+1,Axelar 要求验证者使用 SKi签署(更新,PKi+1)。随后这个签名被发布到 SCAxelar,更新 PKAxelar。

令 qS 表示关于链 S 状态的任意问题。此类问题的示例包括:

• “在哪个区块(如果有)出现ts交易?”

• “某个数据字段的值是多少?”

• “第 314159 轮区块 S 的整个状态的默克尔根哈希是多少?”

让 aS 表示对 qS 的正确答案,并假设最终用户或应用程序要求发布 aS到链 D.Axelar 网络满足这个需求如下:

1. 用户在其中一个桥接帐户上发布请求 qS(随后由验证器)或直接到 Axelar 区块链。

2. 作为 Axelar 共识的一部分,每个验证者必须运行链 S、D 的节点软件。 Axelar 验证者查询他们的链S节点软件的API以获得答案aS并将答案报告给Axelar链。

3. 一旦 > F 加权验证者在 R 轮报告相同的答案,Axelar 要求验证者签署 aS。

4. 验证者使用阈值密码术签署 aS。签名包含在块 R + 11 中。

5. 任何人都可以从区块 R+11 中取出有符号的值 aS 并将其发布到 D。

6. 请求已被处理。 D 上的任何应用程序现在都可以采用带符号的值 aS,查询 DAxelar获取最新的PKAxelar,并验证aS的签名是否对应PKAxelar。验证器

还将 aS 发布到链 D 上的桥接帐户,应用程序可以检索该帐户。

网络通过扩展状态同步工作流,实现数字资产的跨链转移第 6.2 节。

DAxelar 在初始化时会打印和控制充足的 peged-S 代币供应。认用户要求用源链 S 上的 x 数量的代币交换源链 S 上的 x 数量的挂钩 S 代币目标链 D,存放在用户选择的 D 地址 wD。我们提供了完全通用的工作流,支持任意源链 S — — 甚至比特币等不支持智能链合同:

1. 用户(或代表用户的应用程序)向阈值发布转移请求 (x, wD)桥接帐户随后被路由到 Axelar 网络。

2. Axelar 验证者使用阈值密码,为 S 集体创建一个新的存款地址 dS。他们将 dS 发布到 Axelar 区块链。

3. 用户(或代表用户的应用程序)通过监控 Axelar 区块链来学习 dS。用户使用她最喜欢的,通过普通的 S 交易 tx S 发送 x 数量的 S 代币到地址 dS链 S 的软件。(由于 dS 的阈值属性,除非达到阈值数量,否则不能从 dS 花费令牌验证者协调这样做。)

4. tx S 发布在 Axelar 上。验证者查询其链 S 节点软件的 API 是否存在

tx S,如果响应为“真”,则将答案报告给 Axelar 链。

5. 一旦 > F 加权验证者在 R 轮报告 tx S 为“真”,Axelar 要求验证者签署一份从 DAxelar 向 wD 发送 x 数量的挂钩 S 代币的交易 aD。

6. 验证者使用阈值密码术签署 AD。签名包含在块 R + 11 中。

7. 任何人都可以从区块 R+11 中取出有符号的值 aD 并将其发布到 D。

8. 请求已被处理,一旦在 D 上发布了 aD,就处理传输。

现在假设用户要求将 x0 数量的包装 S 代币从链 D 赎回链 S,以存入用户选择的 S 地址 wS。工作流程如下:

1. 用户通过将 x0 数量的包裹-S 代币存入 cD 来发起转账请求 (x0, wS)

使用她最喜欢的软件进行链 D 的普通 D 交易。

2. (x0 , wS) 发布在 Axelar 上。验证者查询其链 D 节点软件的 API 是否存在(x0 , wS) 并且,如果响应为“true”,则将答案报告给 Axelar 链。

3. 一旦 > F 加权验证者在 R 轮报告 (x0 , wS) 为“真”,Axelar 要求验证者签署一份将 x0 数量的 S 代币从 SAxelar 发送到 wS 的交易 aS。

4. 验证者使用阈值密码术签署 aS。签名包含在块 R + 11 中。

5. 任何人都可以从区块 R+11 中取出签名值 aS 并将其发布到 S。

6. 请求已被处理,一旦 aS 被发布到 S 上,传输就被处理。

CGP 路由层支持的其他请求包括锁定、解锁或转移资产跨链。

实现原子跨链交易流。根据跨链请求类型,Axelar试图确保相应的交易在多条链上执行或不执行。对此,在 Axelar 区块链中,每个请求都可以处于以下状态之一:(初始化、挂起、完成、时间到)。如果挂起阶段的超时被触发,请求将返回错误代码。一些超时事件也开始退款事件:例如,如果来自一个链的资产需要转移到另一条链上的资产,如果接收链没有处理交易,则资产退还给原用户。

CTP 是一种应用程序级协议,它使应用程序可以轻松利用跨链功能。我们通过关注资产转移功能(例如,在 DeFi 中使用)来解释集成。 这些应用通常由三个主要组件组成:前端 GUI、单链智能合约和中间节点在前端和智能合约之间发布交易。 前端与用户的钱包接受存款,处理取款等。 应用程序可以利用跨链功能

通过调用类似于 HTTP/HTTPS GET/POST 方法的 CTP 查询。 这些查询随后由 CGP 层拾取执行并将结果返回给用户。

• CTP 查询。应用程序开发人员可以在任何链上托管他们的应用程序,并将他们的智能合约与阈值桥接账户集成以执行 CTP 查询。

• 阈值桥接帐户。假设一个应用程序开发者在链 A 上构建他们的合约,然后他们将引用阈值桥接合约以获得跨链支持。本合同允许应用到:

– 注册一个它想要与之通信的区块链。

– 在该区块链上注册它想要利用的资产。

– 对资产执行操作,例如接受存款、处理取款和其他功能(类似于 ERC-20 合约调用)。

假设本地驻留在链 A 上的著名 DeFi 应用程序 MapleSwap 注册了阈值桥接帐户。 Axelar 验证者在相应的链上共同管理合约本身。假设用户想要将存款提交到分别位于两条链上的资产 X 和 Y 之间的交易对中。然后,当用户提交这样的请求时,它会通过阈值桥接账户路由到 Axelar 网络进行处理。在那里形成,执行以下步骤:

1. Axelar 网络了解到,该应用程序注册了跨资产的跨链支持。它利用阈值密码学和用户共识生成存款密钥相应的链 A 和 B。

2. 关联的公钥返回给应用程序并展示给用户,用户可以使用自己喜欢的钱包提交存款。相应的密钥在所有 Axelar 验证器之间共享。

3. 存入确认后,Axelar 更新其跨链目录,以记录相应链上的用户已存入这些资产。

4. Axelar 验证器执行多方协议以生成阈值签名,该签名允许更新应用程序所在链 A 上的阈值桥接账户。

5. 然后将 CTP 查询返回给 DeFi 应用程序智能合约,DeFi 应用程序智能合约可以更新其状态、更新其收益率公式、汇率或执行其他与应用程序状态相关的条件。

在整个过程中,Axelar 网络在高层充当去中心化的跨链读写预言机,CGP 是链之间的路由层,CTP 是应用协议。

额外的跨链请求。 CTP 支持跨区块链的应用程序之间通用的跨链,

例如:

• 执行公钥名称服务 (PKNS)。这是一个将公钥映射到电话号码/推特的通用目录(一些项目,例如 Celo,在其内部提供了这些功能平台)。

• 跨链应用程序触发器。如果链 B 上的另一个应用程序满足搜索条件(利率 < X),则链 A 上的应用程序可以更新其状态。

• 智能合约可组合性。链 A 上的智能合约可以根据链 B 上的合约状态更新其状态,或者触发更新链 B 上智能合约的动作。

在高层上,这些请求可以被共同处理,因为协议 CTP、CGP , 和阿克塞尔网络可以跨区块链传递和写入任意可验证的状态信息。

在接下来的几年里,重要的应用程序和资产将建立在多个区块链生态系统之上。 Axelar 网络可用于将这些区块链插入到统一的跨链通信中层。该层提供满足平台构建者和应用程序开发者需求的路由和应用层协议。应用程序开发人员可以在满足其需求的最佳平台上进行构建,并且利用简单的协议和 API与其他链用户进行全球跨链流动。

1] Althea peggy. https://github.com/cosmos/peggy. [Cited on page 2.]

[2] Deterministic usage of the digital signature algorithm (dsa) and elliptic curve digital signature algorithm

(ecdsa). https://tools.ietf.org/html/rfc6979. [Cited on page 5.]

[3] Edwards-curve digital signature algorithm (eddsa). https://tools.ietf.org/html/rfc8032. [Cited on

page 5.]

[4] Eos.io technical white paper v2.

https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md. [Cited on page

1.]

[5] Ethereum: A secure decentralised generalised transaction ledger.

https://ethereum.github.io/yellowpaper/paper.pdf. [Cited on page 1.]

[6] The near white paper. https://near.org/papers/the-official-near-white-paper/. [Cited on page

1.]

[7] Rainbow bridge. https://github.com/near/rainbow-bridge. [Cited on page 2.]

[8] Ren: A privacy preserving virtual machine powering zero-knowledge fifinancial applications. https:

//whitepaper.io/document/419/ren-litepaper. [Cited on page 3.]

[9] tbtc: A decentralized redeemable btc-backed erc-20 token. https://docs.keep.network/tbtc/index.

pdf. [Cited on page 2.]

[10] Thorchain: A decentralized liquidity network. https://thorchain.org/. [Cited on page 3.]

[11] Kurt M. Alonso. Zero to monero. https://www.getmonero.org/library/Zero-to-Monero-1-0-0.

pdf. [Cited on page 1.]

[12] Jean-Philippe Aumasson, Adrian Hamelink, and Omer Shlomovits. A survey of ecdsa threshold signing.

Cryptology ePrint Archive, Report 2020/1390, 2020. https://eprint.iacr.org/2020/1390. [Cited on

page 6.]

[13] Ran Canetti, Nikolaos Makriyannis, and Udi Peled. Uc non-interactive, proactive, threshold ecdsa.

Cryptology ePrint Archive, Report 2020/492, 2020. https://eprint.iacr.org/2020/492. [Cited on

page 6.]

[14] cLabs Whitepapers. https://celo.org/papers. [Cited on page 1.]

[15] Ivan Damg˚ard, Thomas Pelle Jakobsen, Jesper Buus Nielsen, Jakob Illeborg Pagter, and

Michael Bæksvang Østerg˚ard. Fast threshold ECDSA with honest majority. In SCN, volume 12238

of Lecture Notes in Computer Science, pages 382–400. Springer, 2020. [Cited on page 6.]

[16] Manu Drijvers, Kasra Edalatnejad, Bryan Ford, Eike Kiltz, Julian Loss, Gregory Neven, and Igors

Stepanovs. On the security of two-round multi-signatures. In IEEE Symposium on Security and Privacy,

pages 1084–1101. IEEE, 2019. [Cited on page 6.]

14[17] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony.

https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf. [Cited on page 5.]

[18] Rosario Gennaro and Steven Goldfeder. One round threshold ecdsa with identififiable abort. Cryptology

ePrint Archive, Report 2020/540, 2020. https://eprint.iacr.org/2020/540. [Cited on page 6.]

[19] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling

byzantine agreements for cryptocurrencies. Proceedings of the 26th Symposium on Operating Systems

Principles, 2017. https://dl.acm.org/doi/pdf/10.1145/3132747.3132757. [Cited on page 1.]

[20] Evan Kereiakes, Do Kwon, Marco Di Maggio, and Nicholas Platias. Terra money: Stability and adop[1]

tion.

https://terra.money/Terra_White_paper.pdf. [Cited on page 1.]

[21] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably

secure proof-of-stake blockchain protocol. https://eprint.iacr.org/2016/889.pdf. [Cited on page 1.]

[22] Chelsea Komlo and Ian Goldberg. Frost: Flexible round-optimized schnorr threshold signatures. Cryp[1]

tology ePrint Archive, Report 2020/852, 2020. https://eprint.iacr.org/2020/852. [Cited on page

6.]

[23] Jae Kwon and Ethan Buchman. Cosmos: A network of distributed ledgers.

https://cosmos.network/resources/whitepaper. [Cited on pages 1 and 2.]

[24] Avalanche Team. Avalanche platform.

https://www.avalabs.org/whitepapers. [Cited on pages 1 and 2.]

[25] Gavin Wood. Polkadot: Vision for a heterogeneous multi-chain framework.

https://polkadot.network/PolkaDotPaper.pdf. [Cited on pages 1 and 2.]


0 条评论

发表回复

Avatar placeholder

您的电子邮箱地址不会被公开。