Arcium：Solana的隐私2.0

19分钟阅读

2025年2月25日

隐私悖论

加密隐私的故事已经从简单的私人状态和单用户匿名工具发展到一代新的隐私，这种隐私依靠先进的加密基元和隐私增强技术，使共享私人状态和多用户隐私成为可能——隐私 2.0。

Elusiv 是一个隐私应用程序，由 Arcium 背后的同一团队创建，它为隐私 1.0 打下了基础，支持 Solana 上的隐私交易，而 Arcium 则象征着下一阶段：一个模块化的私密计算网络，旨在实现共享私人状态。

隐私是加密领域最大未解决的问题。

透明性限制了最常用区块链的功能，阻碍了现实世界的采用。Arcium 希望通过实现私密计算来改变这一点，允许 Solana 开发者创建数据保持机密但可计算的应用程序。

什么是 Arcium？

Arcium 是一台加密超级计算机——一个去中心化的私密计算网络，利用多方计算（Multi-Party Computation, MPC）来安全有效地处理加密数据。

与其他替代解决方案——全同态加密（Fully Homomorphic Encryption, FHE）、受信执行环境（Trusted Execution Environments, TEEs）和零知识证明（Zero-Knowledge Proofs, ZKPs）——所面临的效率低下、安全漏洞和可用性有限等挑战不同，Arcium 提供了一种高效、去中心化的替代方案。

Arcium 的架构建立在多方执行环境（Multi-Party eXecution Environments, MXEs）之上，允许独立的节点群并行处理加密计算，显著提高了速度和可扩展性。在使用加密证明和经济激励（质押/惩罚）的同时，Arcium 只需一个诚实的参与者即可确保隐私，保证诚实执行。

隐私的演变

在深入细节之前，让我们回顾一下我们是如何走到今天的。一般而言，加密隐私的发展历程是零散的：

阶段 1：特殊目的隐私

匿名加密货币（例如，Monero，Zcash）提供了早期的财务隐私，而工具如 TornadoCash 和 Railgun 通过搅拌器和隐私池为 EVM 生态系统引入了更具程序化的隐私。然而，这些解决方案仍然孤立，功能有限，并且缺乏更广泛的生态系统集成。

阶段 2：私人状态

零知识证明（ZKPs） 在隐私重点的Layer1和Layer2（例如，Aztec、DarkFi、Aleo）上实现了私密交易和智能合约。然而，隐私仍然局限在各个区块链或应用程序内。这些系统支持私人状态而非共享私人状态，因此功能和用例也有限。

阶段 3：共享私人状态

这是加密隐私的重大飞跃，通常被称为“隐私 2.0”。它允许多方协作计算，同时保持机密性，将隐私扩展到财务交易以外的更广泛的通用数据隐私用例。这一转变解锁了以前无法实现的应用程序，例如私密 AI、在 DeFi 的公共区块链上的黑池和私密数据货币化。

单一私人状态 vs 共享私人状态

区块链的透明性既是其优势也是其致命弱点。尽管开放账本提供了可验证性，但它们阻碍了许多行业采用加密基础设施。当前的隐私解决方案功能有限——ZKP 允许可验证计算的同时保持输入私密，但不支持跨应用程序或用户的共享隐私。因此，AI 公司无法使用敏感数据训练模型，DeFi 交易者无法保护其策略，企业无法利用区块链进行私密业务逻辑。

纯 ZK 对隐私的局限

ZKP 允许在不揭示输入的情况下进行验证，但存在一些局限性：

• 没有协作隐私： ZKPs 证明计算，但不允许多个参与方对共享加密数据进行计算。
• 性能瓶颈： 证明正确性计算开销高，使得 ZK 不适用于大规模动态计算。
• 功能有限： ZKP 保护输入和输出，但不维护跨多个交易或方的加密状态。

为了在加密中实现全面的隐私，我们需要共享私人状态——一种系统，其中多个参与方可以在保持机密性的同时进行私密数据的计算。这对解锁新应用和超越单用户隐私解决方案的用例至关重要。

需要共享私人状态的核心用例：

• 黑池 / 中央限制订单簿（CLOBs）： 允许交易者下单而不查看订单簿，确保订单匹配的隐私。
• 私密 AI 推理： 处理专有模型而不暴露模型权重，从而启用 DeFi 策略自动化和个性化 AI 等应用。
• 私密 AI 训练： 能够使模型从私密数据集（如医疗记录）学习，而无须暴露敏感信息。这使得数据所有者与模型创作者之间可以合作，同时保持隐私。
• DeFAI： 门限解密 AI 代理，通过安全管理交易提高用户体验。利用 MPC，钱包的私钥分布在多个方之间，从而在绝不还原或暴露明文密钥的情况下处理交易。
• 私密游戏： 对于需要隐蔽状态以确保公平游戏的游戏，考虑赌场游戏（例如二十一点、德州扑克）和类似于 Doom 的游戏，其中其他状态的位置必须被隐藏。

隐私 1.0 vs 隐私 2.0

启用共享私人状态

加密中的隐私正在从事务匿名演变为一个更广泛的概念：共享私人状态（SPS）。与个人私人状态（PPS）不同，在 PPS 中，数据由单一实体控制和查看，而 SPS 则使多个参与者可以互相交互、计算并更新私人数据而不会妨碍机密性。

SPS 对于解锁需要多方协作的经济模型和应用程序至关重要。

这包括黑池、私密借贷池、机密多人游戏，以及处理私人输入的链上 AI 模型。

挑战在于在允许计算的同时保持隐私——确保与 SPS 的更新或交互不会无意中泄露敏感信息。

核心原语：MPC、FHE、TEEs

多方计算（MPC）

MPC 使多个参与者在不揭示其私人输入的情况下计算一个函数。在参与者之间分配计算消除了信任单一实体的需求，因而非常适合关键管理、协作 AI 训练和私密拍卖。尽管 MPC 灵活，但却存在计算及通信开销，其安全性取决于协议设计和参与者行为。

全同态加密（FHE）

FHE 允许对加密数据进行计算而无须解密，确保整个过程的隐私。这使它在隐私保护的智能合约、加密 AI 推理和符合法规的数据处理应用中非常有价值。然而，FHE 的速度远低于传统计算，资源成本高且验证计算完整性面临挑战。

受信执行环境（TEEs）

TEEs 创建隔离的硬件安全区进行计算，屏蔽数据免受外部访问。它们被用于机密 DeFi 应用、AI 隐私以及将加密与硬件保护相结合的混合安全模型。尽管 TEEs 提供了高性能，但它们依赖硬件厂商的安全性，并且容易受到侧信道攻击。

定义隐私空间

加密技术中充满了复杂的行话和叙述，隐私领域也不例外，随着时间的推移，许多定义相继诞生，用以解释与这一领域相关的各个方面。随着共享私人状态成为启用隐私保留应用的标准技术，出现了一些用于高层次包装此垂直领域的术语和定义。以下是一些你可能会遇到的定义共享私人状态的术语：

• 隐私 2.0： 从孤立的个人私人状态演变到共享私人状态，使多个参与者能够进行协作的、机密的计算。
• 去中心化机密计算（DeCC）： 在去中心化环境中运作的隐私保护计算框架，而不暴露敏感数据。
• 私密计算网络： 私密计算网络利用加密技术或硬件隔离环境，实现安全、保护隐私的计算，以处理不暴露原始输入的数据。

共享私人状态：加密的新空白

Arcium 正在推动从隐私 1.0（私人状态是孤立的）向隐私 2.0 的转变，使共享私人状态实现机密的多方计算在 Solana 上的应用。

通过去除区块链的透明限制，它打开了以前不可能的新经济模型和应用程序。这个转变将隐私从一种特殊目的特性转变为一种通用框架，将其影响扩展超越财务交易。

随着隐私对现实世界采用变得不可或缺，共享私人状态作为加密的新空白出现——解锁全新的应用程序，扩展区块链功能，并提供去中心化系统所需的隐私，以实现扩展。

Arcium 的架构

Arcium 为私密、去中心化和高效的计算而设计，能够支持任何应用程序的共享私人状态。利用多方计算（MPC）等先进的加密技术，Arcium 能够在不依赖于中央权威的情况下，对加密数据进行信任无约束的可验证计算。

为包装 Arcium 的能力和功能，我们将该网络描述为“加密超级计算机”。类似于传统计算堆栈，每个节点都充当一个处理器，为加密超级计算机贡献力量。通过所有这些处理器的组装和统一，超级计算机便现身于此。

arxOS 是一个分布式的加密操作系统（Arcium 的节点网络），用来执行计算。MXEs（多方执行环境）是超级计算机的虚拟机——高度可配置的环境，用于定义和安全执行计算。最后，Arcis 是基于 Rust 的编程语言和 Arcium 的开发者框架。

Arcis

Arcis是一个以Rust为中心的框架，用于在Arcium网络上开发安全的多方计算（MPC）电路，从而在加密数据上实现隐私保护计算。Arcis提供强大直观的接口，使得设计和实现MPC电路变得简单。

基于Rust的安全保证，Arcis将标准类型（例如u8、bool、f64等）替换为掩膜变体。它还支持定长数组和结构体，允许开发者在保留机密性的同时建模复杂数据结构。该框架支持加密类型和明文类型（类型可在电路中间透露以提高速度）之间的算术、逻辑和比较操作。值得注意的是，使用掩膜值的条件逻辑需要两个分支都执行，以防止旁道泄漏，确保数据无关的执行路径。对于数字精度，掩膜 f64 变体采用固定点表示，具有52个小数位和75个整数位（未来将放宽以支持更动态的范围），使得在有限域内处理有理数成为可能。

Arcis 处理的电路输入和输出既可以是明文也可以是密文（使用对称的 Rescue 密码进行加密）。性能优化至关重要：秘密共享乘法开销高，而加法操作和明文交互效率高。需要按位分解的比较操作成本高，控制流不能依赖于秘密值（例如，不能基于加密条件进行提前返回）。

多方执行环境（MXEs）

MXEs 是专用的隔离虚拟环境，用于安全计算执行。它们高度可配置，能够细致调校数据配置和处理，加密方案等。由“计算客户”创建，MXEs 与 MPC 协议无关，运行在集群之上——可以是特定选择的集群，也可以在多个预先选择的集群之间换取可用性进行轮换。MXEs 被定义为“持久”的，意味着可以在未来无限期重复使用，或者是“单次使用”的，指的是该 MXE 可能只用于一个计算，然后自动丢弃。

MXEs 通过客户定义的加密方案处理加密，使用特定的加密密钥在 MXE 的计算中保护数据。为了提高效率，这些加密方案可以在属于同一个计算客户的多个 MXEs 之间共享。

然而，如果没有特定用例的要求，也可以选择禁用加密。当一个 MXE 加入新集群时，会触发一个分布式密钥生成（DKG）系统计算，此时集群中的每个节点收到整体加密密钥的片段（keyshare）。

MXE 的安全保障依赖于其选择的 MPC 协议。在 Arcium 的初始主要 MPC 协议 Cerberus 下，只要集群中至少有一个节点保持诚实，计算完整性便得到保证。然而，像 Manticore 这样的替代协议（也在推出时受到支持）在不同的安全假设下运行，以此来在特定的用例中（例如资源密集型任务如 AI 模型训练）交换更强的安全保障以获得更好的性能。

ArxOS

ArxOS 是 Arcium 的分布式操作系统，由 Arx 节点的分布式网络、它们形成的集群以及在这些集群内执行的 MXEs 组成。

像传统操作系统中的核心和进程一样，arxOS 协调 Arx 节点如何在集群中协同工作以执行 MPC 计算，管理节点之间密钥共享的分配，并通过可配置的 MXE 环境实现并行处理。

该系统支持多种 MPC 协议，如 Cerberus 和 Manticore，根据计算需求的不同，允许不同的安全和性能权衡。在 Solana 区块链处理调度时，arxOS 提供了机密计算发生的分布式计算框架。

支持的 MPC 协议

虽然现有的安全计算解决方案（如受信执行环境 TEEs）需要信任硬件制造商和第三方证明服务，但 Arcium 的去中心化架构使得没有单个实体控制特定计算。它基于多方计算，提供信息理论安全。其工作原理是将数据分布在节点集群之间，确保没有单个参与方能够访问明文。

在这种操作范例下，根据应用程序的安全需求，可以激活许多不同的杠杆。计算通常分为两个阶段：第一阶段是一个预处理阶段，可以在任何数据输入系统之前执行，第二阶段是在线阶段，在该阶段，预处理后的数据被使用以在私人数据上安全地执行程序。

网络的安全保障依赖于协议，提供灵活性来匹配不同用例的信任要求。

Cerberus

Cerberus 是 Arcium 的主要 MPC 计算后端。每个份额都使用消息认证码（MAC）进行验证，允许诚实节点验证完整性并检测篡改，确保一旦检测到恶意行为，计算将被Abort。

在假设给定集群中至少有一个节点诚实时，计算结果可以保证是正确的。预处理数据以配对的方式由节点生成。Cerberus 提供了 Arcium 支持的两个初始 MPC 协议中最强的安全保证。

Manticore

Manticore 以“诚实但好奇”的设置运行，假设节点不会偏离协议指令或篡改数据。它还依赖于一个“可信经销商”——一个生成在线阶段需要的预处理数据的节点，然后再离线。这导致更快的执行时间。

此外，它使用矩阵（而不是单一值）作为基础构建块，更适合于由于机器学习和 AI 应用所需的更复杂操作。然而，这种速度的提升是以削弱安全保证为代价的，正如上文所解释的。Manticore 设计用于在节点是可信操作员并因此被激励正常行为的环境中部署（例如，在许可或部分许可的集群中）。

经济激励

网络的信任模型通过其经济设计进一步得到加强。节点必须对其自身的 Arx 节点进行代币质押，为“行为捆绑”提供了实质保障，使得恶意行为在经济上没有吸引力。节点操作者和第三方代表因不当行为将面临罚金，形成了诚实行事的激励。

此外，集群可能选择要求来自集群内 Arx 节点的 TEE 支持，以增强密钥共享的保护。但这仍是对 MPC 协议核心加密保证的补充。

构建加密 Solana 程序

传统的 CLOB DEX 交易是简单的——你用公开参数（如出价金额、大小和你的公钥）执行交易。然而，黑池交易需要加密的链上订单簿，增加了保护交易隐私的复杂性。让我们来看看 Arcium 如何通过对加密交易数据的计算来实现这一点。

理解计算生命周期

在黑池交易（或使用 Arcium 进行任何加密计算）时，流程如下：

1. 客户端加密

• 客户端加密订单参数
• 通过 MXE（多方执行环境）程序调用计算

2. 程序交互

• MXE 程序格式化参数并执行对 Arcium 程序的 CPI 调用
• Arcium 程序将计算添加到 MXE 的链上内存池中

3. MPC 处理

• MPC 集群从内存池中检索计算
• 使用安全多方计算（MPC）执行计算

4. 结果处理

• 对于小输出：MPC 集群直接调用最终计算指令
• 对于较大输出，数据发送到回调服务器以进行状态更新和最终处理

5. 完成

• Arcium 程序验证结果
• 在 MXE 程序中触发回调函数
• MXE 程序通知用户计算已完成

项目结构与设置

理解了基本流程后，我们可以探讨构建一个加密链上订单簿。这一示例展示了 Arcium 的组件如何协同工作以支持机密交易。

Arcium 的开发工具包以 Anchor 为扩展，使 Solana 开发者感到熟悉。主要区别在于使用 arcium CLI 而不是 anchor CLI。这一基础使得开发者更容易从构建常规 Solana 程序过渡到创建加密应用程序。

使用 Arcium 开发主要有两个组件：

1. 链上程序： 这是你的 Solana Anchor 程序，增加了 Arcium 注释以支持机密计算。
2. 机密计算指令： 这些是你想要保密执行的指令。使用 Arcium 的 Arcis 编译器，你可以用 Rust 定义这些指令，并将其编译为可以在 Arcium 网络上执行的格式。

要构建黑池，我们只需要一个链上加密订单簿。这个订单簿包含一个订单列表，每个订单都有具体字段（出价、大小和拥有者），指定订单的详情。

上面的图片展示了用 arcium init 命令初始化的项目结构。

请注意，除了 Anchor 项目的常规结构外，还有一个名为 confidential-ixs 的新文件夹。

定义加密数据结构

在 confidential-ixs/src/lib.rs 中，我们可以定义 Order 和 OrderBook 结构体，这些结构体具有加密字段。

代码

const ORDER_BOOK_SIZE: usize = 10;

#[derive(ArcisType, Copy, Clone, ArcisEncryptable)]
pub struct OrderBook {
    orders: ArcisArray<Order, ORDER_BOOK_SIZE>,
}

#[derive(ArcisType, Copy, Clone, ArcisEncryptable)]
struct Order {
    size: mu64,
    bid: mbool,
    owner: mu128,
}

在这里，我们定义了 Order 和 OrderBook 结构体，其中 OrderBook 包含一个 Order 结构体的数组。每个 Order 结构体有三个字段：size、bid 和 owner。

你可能注意到字段类型前面带有 m 的前缀，代表掩膜。这表明该字段是加密的，并且在链上不是以正常明文形式存储。

我们还为 Order 结构体派生了 ArcisType 特性，这是一个辅助特性，允许 Arcis 编译器将给定数据用作机密计算的输入/输出。

在加密数据上进行计算

现在我们已定义了数据结构，我们可以定义希望对其执行的指令。例如，我们可以定义一个指令，以向订单簿添加订单。

代码

#[confidential]
fn add_order(
    order: [Ciphertext; 3],
    order_public_key: PublicKey,
    order_nonce: u128,
    ob: &[Ciphertext; 30],
    ob_nonce: u128,
) -> [Ciphertext; 30] {
    let order_cipher = RescueCipher::new_with_client(order_public_key);
    let order = order_cipher.decrypt::<3, Order>(order, order_nonce);
    let ob_cipher = RescueCipher::new_for_mxe();
    let mut ob = ob_cipher.decrypt::<30, OrderBook>(ob, ob_nonce);

    let mut found: mbool = false.into();
    for i in 0..ORDER_BOOK_SIZE {
        let overwrite = ob.orders[i].size.eq(0).bitand(!found);
        ob.orders[i] = overwrite.select(order, ob.orders[i]);
        found = overwrite | found;
    }

    let enc_ob = ob_cipher.encrypt::<30, OrderBook>(ob, ob_nonce);
    enc_ob
}

在这里，我们试图向现有订单簿中添加一个订单。order 参数按值传递，包含其对应的加密公钥和随机数。order_book 参数按引用传递，以便节点将从 Solana 的链上账户中提取数据。同样，由于 order_book 参数是以引用传递的，因此我们仍需为其传递随机数。我们无需对其加密传递公钥，因为它使用的是集群的全局公钥进行加密。

为了使用这些参数进行计算，我们需要将它们解密为各参与节点共享的密文。我们首先为每个参数实例化一个 RescueCipher，然后使用 decrypt 方法解密它们。这会为每个节点生成秘密共享，以便在 MPC 中使用。在此过程中不会泄露明文数据。

在将机密指令处理完毕后，由于 Rust 的预期，order 参数将在处理后消失（正如在常规 Rust 中的预期）。

为了输出新的订单簿，我们会再次使用 Rescue 进行加密，以重新获取 Ciphertext 类型并返回它。

与 Solana 程序的集成

现在我们知道如何在加密状态上进行计算，但这如何与我们的链上 Solana 程序相符合？

在我们的 Solana 程序中，每个计算有三个步骤——其中的一个是在部署程序时的单次设置，其他两个是每次调用计算时相关的。

首先，我们需要为我们的 MXE 初始化每个机密计算指令。使用 arcium CLI 和 Arcis 编译我们的机密指令，将其编译为可由 Arx 节点执行的各自 MPC 字节码。然后，在我们的程序中，我们使用来自 Arcium SDK 的 init_comp_def 辅助函数，基本上是一个对 Arcium 程序的 CPI 调用的封装。

代码

pub fn init_add_order_comp_def(ctx : Context<InitAOCompDef>, finalize_auth : Pubkey) -> Result<()>{
        init_comp_def(ctx.accounts, true, None, Some(finalize_auth))?;
        Ok(())
    }

同样，我们为上下文结构指定了在 arcium_macros crate 中定义的宏。它验证传递的账户以及add_order 机密指令的存在。

代码

#[init_computation_definition_accounts("add_order", payer)]
#[derive(Accounts)]
pub struct InitAOCompDef<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,
    #[account(\
        mut,\
        seeds = [MXE_PDA_SEED, &ID_CONST.to_bytes()],\
        seeds::program = ARCIUM_PROG_ID,\
        bump = mxe_account.bump\
    )]
    pub mxe_account: Box<Account<'info, PersistentMXEAccount>>,
    #[account(mut)]
    /// CHECK: comp_def_account, checked by arcium program.
    /// Can't check it here as it's not initialized yet.
    pub comp_def_account: UncheckedAccount<'info>,
    pub arcium_program: Program<'info, Arcium>,
    pub system_program: Program<'info, System>,
}

现在，每当我们想要向订单簿添加一个订单时，只需使用 queue_computation CPI 包装函数。

代码

pub fn add_order(ctx: Context<AddOrder>, bid: [u8;32], owner: [u8;32], size: [u8;32], encryption_pubkey: [u8;32], nonce: u128) -> Result<()> {
        let args = vec![\
            Argument::EncryptedBool(bid),\
            Argument::EncryptedU128(owner),\
            Argument::EncryptedU16(size),\
            Argument::PublicKey(encryption_pubkey),\
            Argument::PlaintextU128(nonce),\
            // Offset of 8 (discriminator) + 1 (bump) + 2 (update_count) + 16 (nonce) + 32 (encryption pubkey)\
            Argument::Account(ctx.accounts.ob.key(), 8 + 1 + 2 + 16),\
            Argument::PlaintextU128(ctx.accounts.ob.nonce),\
        ];

        // Call the Arcium program to queue the computation
        queue_computation(
            ctx.accounts,
            args,
            vec![CallbackAccount{\
                pubkey: ctx.accounts.ob.key(),\
                is_writable: true,\
            }],
            Some(“callback-server-url”), // None if you can fit the output data within a single transaction
        )?;
        Ok(())
    }

在我们程序的 add_order 函数中，我们只需对机密指令的参数格式化，然后将其传递给 queue_computation。我们传递 CPI 的所需账户、参数、需要为事务返回结果的相关回调函数的账户及可选的回调服务器链接（如果计算的输出超过事务的大小限制）。

代码

#[arcium_callback(confidential_ix = "add_order")]
    pub fn add_order_callback(ctx: Context<AddOrderCallback>, output: Vec<u8>) -> Result<()> {
        let ob_updates : [[u8;32]; 20] = output.chunks_exact(32).map(|c| c.try_into().unwrap()).collect::<Vec<_>>().try_into().unwrap();
        ctx.accounts.ob.orders[0..20].copy_from_slice(&ob_updates);

        emit!(OrderPlaced{timestamp: Clock::get()?.unix_timestamp});
        Ok(())
    }

每个机密计算执行的回调函数必须遵循命名约定 <confidential-ix-name>_callback，并且只能接受一个命名为 output 的 Vec<u8> 类型。

在此回调函数中，我们将输出字节映射回订单簿账户，并发出事件，指明在当前时间戳下已经下达了一个订单。

客户端测试

最后，我们在客户端进行测试。

代码

const privateKey = x25519RandomPrivateKey();
const publicKey = x25519GetPublicKey(privateKey);
const mxePublicKey = [new Uint8Array(/* MXE public key here */)];

const rescueKey = x25519GetSharedSecretWithMXE(privateKey, mxePublicKey);
const cipher = new RescueCipher(rescueKey);

const orderSize = BigInt(1);
const orderBid = BigInt(true);
const orderOwner = BigInt(3);

const plaintext = [orderSize, orderBid, orderOwner];
const nonce = randomBytes(16);
const ciphertext = cipher.encrypt(plaintext, nonce);

// Add an order to the orderbook
const addOrderSig = await program.methods.addOrder(
      ciphertext[0],
      ciphertext[1],
      ciphertext[2],
      Array.from(publicKey),
      new anchor.BN(deserializeLE(nonce).toString())
    ).accountsPartial({
      payer: owner.publicKey,
      clusterAccount: arciumEnv.arciumClusterPubkey,
    }).rpc({
      skipPreflight: true,
      commitment: 'confirmed',
});
console.log("Add order sig is ", addOrderSig);

const finalizeAddOrderSig = await awaitComputationFinalization(
      provider as anchor.AnchorProvider,
      addOrderSig,
      program.programId,
      "confirmed"
);
console.log("Finalize add order sig is ", finalizeAddOrderSig);

在这里，我们生成一个随机的私钥用于与 MXE 公钥共用 x25519 ECDH，查看 Rescue 密码。然后，我们可以在本地使用它加密订单输入，并调用程序的 add_order 函数，带上所需参数。Arcium TS SDK 提供了 awaitComputationFinalization 函数，该函数返回回调事务的签名，允许你跟踪计算的进度。

这就是构建 Arcium 的基本操作。美国股票交易量的高达 40% 发生在黑池中，重大投资者从机密性、价格稳定性和高效执行中获益。然而，这些黑池需要对集中中介的信任以执行，从而导致多家企业因恶性利用而受到罚款。链上的黑池或可缓解这些风险，并为 DeFi 扩展提供一个新的、安全的基座。

结论

隐私在应用程序开发中长期被忽视。隐私 1.0 在用户体验差和功能有限之间挣扎。而现在，隐私 2.0 引入了一个新的范式——共享私人状态为链上应用解锁了一块全新的空白。Arcium 为下一个 DeFi、DePIN 和 AI 时代提供动力，同时推动 Solana 上现有用例的发展。

Solana 构建者现在可以 申请 我们私有测试网的第二阶段——在我们公开测试网发布前的最后阶段。

其他资源

• Arcium 文档
• Arcium 深度探索
• Arcium 博客
• Arcium 白板系列

• 原文链接： helius.dev/blog/solana-p...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～