Introduction
An ERC-20 transfer publishes the amount moved and the resulting balances of both parties to anyone with an RPC endpoint. For a payroll run, a treasury rebalance, or a block trade, that property is disqualifying, and the standard workaround has been to keep the transaction off-chain, settling only a netted result.
Zama’s Confidential Blockchain Protocol proposes a different arrangement. Per its litepaper, it is a cross-chain confidentiality layer that sits on top of existing public blockchains rather than a new L1 or L2, combining fully homomorphic encryption for computation on encrypted values, multi-party computation for threshold key management, and zero-knowledge proofs used narrowly to verify that user inputs were encrypted correctly. The stated roadmap put testnet live before the litepaper’s publication, Ethereum mainnet at end of 2025, other EVM chains in H1 2026, and Solana in H2 2026. Zama’s own explainer for ERC-7984, the confidential token standard, is dated 17 February 2026 and describes the standard as technology-agnostic, with the FHE implementation built jointly with OpenZeppelin.
Several numbers attached to this launch in market commentary do not appear in primary documentation: a current throughput of roughly 20 transactions per second, a 500 to 1,000 transaction-per-second target after GPU rollout, deployment volumes in confidential USDC, a named institutional OTC trade, the mechanics and date of a $ZAMA token event, and the audit status of the OpenZeppelin ERC-7984 implementation. We could not verify any of these against Zama’s litepaper, its ERC-7984 explainer, or the Fhenix and Inco documentation. They remain unconfirmed, and the analysis reasons from what the vendor documents state.
The cryptography is the mature part of this stack. Three seams carry the weight instead: the gap between what the onchain contract records and what an offchain coprocessor network computes, the asynchronous path by which an encrypted value becomes plaintext, and the committee of nodes that collectively holds the decryption key.
The cost of arithmetic nobody can see
Fully homomorphic encryption permits a party holding only ciphertexts to compute a function on them, producing a ciphertext of the result, without learning the inputs or the output. Applied to a token, an addition on two encrypted balances yields an encrypted new balance, and the machine performing that addition learns neither operand.
The overhead is structural. FHE ciphertexts in lattice-based schemes are far larger than the plaintexts they hide, and each homomorphic operation adds noise to the ciphertext. Past a threshold, noise destroys the value, so schemes periodically run a noise-reduction step that is itself the dominant cost of the computation. Zama claims its implementation is over 100x faster than five years ago and is post-quantum secure, the latter following from the lattice assumptions these schemes rest on. Both are vendor claims from a self-produced document without an independent benchmark.
The more consequential constraint for contract authors is control flow. A program cannot branch on an encrypted condition, because taking a branch reveals which branch was taken, and observers watching gas consumption or state access patterns would learn the comparison result the encryption was meant to hide. Conditionals therefore become arithmetic: both outcomes are evaluated and an encrypted selector bit multiplexes between them. A confidential transfer costs the same whether the sender has sufficient balance or not, and produces a state transition either way.
That single property propagates through the entire design. It determines how ERC-7984 handles a failed transfer, why liquidation logic is awkward to express, and why the gap between confidential and plaintext execution cost is a multiple rather than a margin. Fhenix’s CoFHE documentation exposes the same shape in its API surface, with encrypted types such as euint32 and ebool, operations such as FHE.add and FHE.sub, and explicit access-control calls such as FHE.allowThis and FHE.allowSender that govern who may later decrypt a value. Permission to decrypt is not ambient in these systems. It is an explicit grant that a contract must execute; omitting it leaves a value permanently unreadable.
Handles, coprocessors, and a gateway
Zama’s ERC-7984 explainer describes a four-part architecture, and the division of labor between the parts is where the engineering risk concentrates.
The onchain contract stores encrypted handles, which are pointers to encrypted values rather than the ciphertexts themselves. When a confidential token contract adds two encrypted balances, the Ethereum transaction does not perform lattice arithmetic. It records that an addition relating three handles is to be performed and returns the output handle immediately. The contract’s storage and the transaction’s gas cost reflect bookkeeping over handles, not the cost of the cryptography.
The actual FHE math happens offchain, in a network of coprocessors that consume the recorded operations and materialize the corresponding ciphertexts. A Gateway orchestrates those coprocessors, enforces access control over which address may read which handle, and routes decryption requests. Decryption itself is performed by a threshold key management system in which multiple independent nodes must cooperate, so that no single operator can unilaterally recover a user’s balance.
Two properties follow directly from this split. First, onchain settlement finalizes faster than the encrypted computation behind it. A transfer confirms when the handle bookkeeping is included in a block, but the ciphertext that handle points to exists only once a coprocessor has produced it. The natural failure mode under load is therefore a backlog: symbolic state advances at Ethereum’s pace while materialization falls behind, and the delay surfaces at the moment someone asks to read a value. Anything that needs a plaintext answer, including a user checking a balance or a contract awaiting a decryption callback, inherits that queue.
Second, the ZK component does far less work here than in a shielded pool. Zero-knowledge proofs are used to establish that a user-submitted input was encrypted correctly and is bound to the submitter, not to prove that any state transition was executed correctly. A malformed or adversarially crafted ciphertext accepted into the system could corrupt downstream computation or become a channel for probing the network key, so the proof functions as an input filter. In a zk-SNARK shielded pool, the proof carries the entire correctness argument and the encrypted state is never computed over by a third party. These are different security architectures that happen to share an acronym.
Zama states that existing chains require no protocol-level upgrade to support this arrangement. That claim is narrow and architecturally plausible: execution happens either in contract code or off-chain. It does not establish whether existing applications can consume the resulting state.
What ERC-7984 changes inside the contract
At the code level the standard is a type substitution with consequences. Where ERC-20 exposes uint256, transfer, and balanceOf, ERC-7984 exposes euint64, confidentialTransfer, and confidentialBalanceOf. The logical operations survive; the operands become encrypted handles that the contract itself cannot read.
The narrowing from 256 bits to 64 is not cosmetic. FHE cost scales with the bit width of the encrypted integer, so a confidential token pays directly for every unused bit of range. A 64-bit balance cannot represent an 18-decimal supply of any size, which forces confidential tokens toward fewer decimals and a smaller maximum supply than their transparent counterparts. Any wrapper bridging an existing 18-decimal ERC-20 into a confidential representation has to define a scaling convention and accept the rounding it introduces.
Insufficient-balance handling is the second structural change, and it follows from the no-branching constraint. A conventional ERC-20 reverts when a sender lacks funds, and the revert is public information. A confidential transfer cannot revert on an encrypted comparison without leaking the comparison result to observers. The design computes an encrypted transferred amount that equals the requested amount when funds suffice and zero when they do not, letting the transaction succeed either way. Callers learn what happened only by decrypting the returned value, if they hold permission to do so. Every integration that treats a successful transaction as proof of a completed transfer requires revision.
Selective disclosure as a contract feature
Zama’s implementation addresses compliance requirements through Observers, addresses such as auditors or regulators that can be granted decryption access to specified values, alongside optional extension modules for KYC and AML checks, balance freezing, and real-world-asset compliance rules. Disclosure operates as a permission grant rather than a default, enforced by the Gateway’s access control rather than operator discretion.
This design represents the core of the institutional proposal, and also the section with the least published detail. Whether an Observer grant is revocable, whether it applies prospectively or retroactively to handles created before the grant, and who may issue one on a user’s behalf are governance questions the available documentation does not settle. A freeze module in particular reintroduces a privileged actor into a system whose premise is that no privileged actor can see user state. Those two properties are compatible in principle, since freezing acts on handles without reading them, but the combination requires verification in contract code rather than feature specifications.
Where encrypted balances meet existing DeFi
The claim that Ethereum needs no upgrade is distinct from the claim that Uniswap or Aave can hold ERC-7984 tokens. The second claim is more difficult, driven by the mechanisms detailed above.
A constant-product AMM prices a swap from public reserves. If reserves are encrypted, the pool cannot publish a price, arbitrageurs cannot compute one, and the invariant check that protects the pool from mispriced trades must be evaluated homomorphically on every swap. A lending market has a sharper problem: liquidation requires that third parties verify a position is underwater, which means either the health factor is public, defeating confidentiality, or liquidators must request decryption and act on the result, turning an atomic transaction into a multi-block request-and-callback sequence with an adversary free to move collateral in between.
Asynchrony is the general obstacle. Any composition that requires a plaintext value mid-execution cannot complete within one transaction, because the decryption path runs through the Gateway and the threshold committee. Protocols designed around atomic settlement inside a single call frame do not adapt to this via simple parameterization; they require redesign.
This leaves a near-term composability surface centered on applications where confidentiality is the primary requirement and latency tolerance is inherent: payroll, where the payer knows every amount and third parties do not price assets; institutional settlement between counterparties sharing information bilaterally; and sealed-bid auctions, where the mechanism depends on values remaining hidden until a scheduled reveal, and where waiting for threshold decryption at the close is structural. Inco’s marketing for its Lightning product lists a similar set, including blind auctions, money markets, delivery-versus-payment escrow, and token vesting, claiming confidential ERC20 and SPL support “without breaking composability.” That claim requires the same standard of evaluation: not whether the base chain accepts the token, but whether an unmodified third-party protocol can price and liquidate against it.
The throughput ceiling and what it excludes
Zama’s litepaper frames scaling in three stages. Current performance runs on general-purpose processors. GPUs are described as enabling a move toward “100+ transactions/s.” Dedicated accelerators, FPGAs and ASICs, are projected to reach “thousands of transactions per second” at an unspecified future date. These are forward-looking vendor targets without a published baseline measurement.
The specific figures circulating around this launch, roughly 20 transactions per second today and a 500 to 1,000 range with GPUs, do not appear in the litepaper and could not be verified. The higher estimate exceeds Zama’s published GPU language by a factor of five to ten. What the vendor’s numbers imply is that the GPU milestone places confidential execution at a throughput comparable to a single mid-sized L2 doing plaintext work, shared across every application on the layer.
That ceiling sorts DeFi workloads cleanly. Payroll, vesting, and periodic institutional settlement generate transaction counts measured in hundreds or thousands per day, where confirmation latency of seconds to minutes is operationally manageable. Sealed-bid auctions and OTC settlement operate as batch processes. None of these are throughput-constrained on the published roadmap.
Continuous markets face different constraints. Spot AMM trading, perpetuals funding updates, oracle-driven liquidations, and intra-block execution strategies require both throughput and bounded latency, with latency being the binding constraint. Even at higher throughputs, a system in which reading a value requires a threshold decryption round cannot support competitive liquidation. If FHE-based confidentiality serves those markets, it will do so by concealing specific fields, such as order sizes or collateral composition, inside systems with public price formation. That is a narrower product than general confidential DeFi.
There is also an unaddressed cost dynamic. Onchain gas for handle bookkeeping is low; FHE computation occurs on coprocessors that require compensation. How that cost is metered, who bears it, and whether the pricing model withstands demand spikes are economics not established in available documentation. A system whose primary computational cost sits outside the settlement layer’s fee market must establish a secondary fee market where congestion will concentrate. Fhenix’s documentation offers a relevant note: its local mock environment simulates FHE by storing plaintext onchain, and the documentation notes that mock gas costs differ from production. Pre-mainnet benchmarks from these stacks should be evaluated with that gap in mind.
Who holds the key shares
The threshold key management system is the component of this architecture that most resembles a conventional trust assumption, and the available sources provide the least specification for it.
Zama states that decryption requires multiple independent nodes to cooperate, preventing any single party from decrypting user data unilaterally. The documentation does not disclose the total node count, the reconstruction threshold, the selection and removal mechanics for operators, operator jurisdictions, or whether the key can be resharded without a plaintext reconstruction step. Each variable directly affects system-level balance security.
Direct comparison clarifies the trust trade-offs. On a plain public L1 there is no decryption step, leaving no committee to compromise or compel; the trade-off is complete transparency. In a hardware-enclave design, confidentiality depends on the processor vendor’s secure execution environment and the absence of side-channel vulnerabilities, concentrating trust in the hardware supply chain. In a threshold scheme, confidentiality holds as long as fewer than the threshold number of node operators collude or are compelled, distributing trust across operators without eliminating custody assumptions entirely.
Two failure modes require distinct evaluation. Confidentiality fails if a threshold-sized coalition reconstructs the key, which depends on jurisdictional distribution. Liveness fails if the committee declines to process decryption requests. A user whose balance remains encrypted but who cannot obtain a decryption cannot prove ownership or exit through contracts requiring plaintext values. Censorship in a confidential system takes the form of unfulfilled decryption requests rather than rejected transactions.
Zama’s litepaper includes a comparison table scoring its protocol as simultaneously secure, decentralized, verifiable, composable, scalable, and easy to use, while classifying TEE-based approaches as lacking security and verifiability, and other FHE, MPC, and ZK systems as deficient in scalability or usability. That comparison represents vendor positioning. The underlying technical trade-off remains concrete: hardware trust and threshold trust present distinct failure modes.
Matching the mechanism to the adversary
The current state of implementations remains varied across providers. Zama’s litepaper lists Ethereum mainnet as an end-of-2025 target, with an ERC-7984 explainer published in February 2026 discussing use cases. Fhenix’s CoFHE documentation specifies support for Ethereum Sepolia, Arbitrum Sepolia, and Base Sepolia, with production mainnet support pending. Inco markets Lightning as a library import offering native chain speed with no new VM, while claiming post-quantum security without naming the underlying mechanism. Near-native latency is inconsistent with standard FHE overhead profiles, leading to assumptions that hardware enclaves are used, though primary documentation does not confirm this.
| Approach | Trust required | What stays hidden | Binding constraint |
|---|---|---|---|
| FHE with threshold decryption | Fewer than threshold-many key-share holders collude or are compelled | Inputs, intermediate state, and stored balances, during computation | Throughput and asynchronous decryption latency |
| Hardware enclave execution | Processor vendor integrity, absence of side channels | Inputs and state, while inside the enclave | Supply-chain and side-channel exposure; limited external verifiability |
| ZK proof of computation | Trusted setup where applicable, soundness of the proof system | Whatever the prover chooses not to reveal; requires separate machinery for persistent encrypted state | Proving cost; no third party can compute over hidden state |
| Plain public execution | None beyond consensus | Nothing | Full transparency |
Selecting an approach depends on the threat model rather than feature lists. Where an application must compute over data the user cannot withhold, and where latency on the order of seconds is acceptable, FHE with threshold decryption provides strong cryptographic isolation within low-frequency throughput limits. Where native base-chain latency is required, enclave-based execution is the active alternative, accepting hardware-level trust assumptions. Where the goal is proving valid execution without state computation by third parties, zero-knowledge proofs offer a lower-overhead construction.
Confidential payroll and bilateral settlement fit threshold FHE architectures. Order-flow privacy in continuous markets does not, as implementing it under current constraints introduces trusted operators or structural latency.
Where the thesis can break
The primary open questions are operational rather than cryptographic. Documenting the composition and governance of the threshold committee will establish whether decryption relies on operators across multiple legal jurisdictions or a concentrated group. Independent mainnet benchmarks measuring latency from transaction submission to readable output will clarify practical throughput. An audit report for the OpenZeppelin ERC-7984 implementation would confirm whether clamped-transfer and access-control semantics hold under adversarial sequencing.
Economic factors require equal scrutiny. Coprocessor computation represents the scarce resource and is priced outside the base settlement market. Until fee mechanisms are formalized, congestion dynamics remain uncharacterized. A confidentiality layer where decryption latency spikes under load risks making account balances temporarily unreadable.
Adoption metrics should be evaluated by protocol integrations rather than isolated transfer volumes. Confidential transfers between known counterparties demonstrate the standard’s basic execution path rather than general composability. The critical milestone to monitor is an unmodified third-party protocol, such as a lending market or AMM developed without ERC-7984 integration, pricing and settling against an encrypted balance in production. Until that integration is demonstrated, encrypted balances operate primarily within bounded multi-party workflows rather than open DeFi architectures.
서론
ERC-20 전송은 이동한 금액과 양측의 최종 잔액을 RPC 엔드포인트에 접근할 수 있는 누구에게나 공개한다. 급여 지급, 트레저리 리밸런싱, 대량 거래에서는 이 속성 자체가 결격 요인이며, 표준적인 우회 방법은 트랜잭션을 오프체인에 두고 순액 결과만 정산하는 것이었다.
Zama의 Confidential Blockchain Protocol은 다른 구조를 제안한다. 라이트페이퍼에 따르면 이는 새로운 L1이나 L2가 아니라 기존 퍼블릭 블록체인 위에 얹히는 크로스체인 기밀성 레이어로, 암호화된 값에 대한 연산을 위한 완전동형암호(FHE), 임계값 키 관리를 위한 다자간 연산(MPC), 그리고 사용자 입력이 올바르게 암호화되었는지 검증하는 용도로 좁게 사용되는 영지식 증명을 결합한다. 발표된 로드맵에 따르면 테스트넷은 라이트페이퍼 발행 전에 이미 가동 중이고, 이더리움 메인넷은 2025년 말, 다른 EVM 체인은 2026년 상반기, 솔라나는 2026년 하반기로 예정되어 있다. 기밀 토큰 표준인 ERC-7984에 대한 Zama의 자체 설명 문서는 2026년 2월 17일 자로, 이 표준을 기술 중립적이라 설명하며 FHE 구현은 OpenZeppelin과 공동으로 만들었다고 밝힌다.
이번 출시를 둘러싼 시장 논평에는 1차 문서에 나오지 않는 여러 숫자가 붙어 있다. 현재 초당 처리량 약 20건, GPU 도입 이후 초당 500~1,000건 목표, 기밀 USDC 배포 규모, 특정 기관 OTC 거래 사례, $ZAMA 토큰 이벤트의 메커니즘과 일정, OpenZeppelin ERC-7984 구현의 감사 상태 같은 것들이다. 우리는 Zama의 라이트페이퍼, ERC-7984 설명 문서, Fhenix와 Inco의 문서 어디에서도 이 숫자들을 확인할 수 없었다. 이들은 미확인 상태로 남아 있으며, 이 분석은 벤더 문서에 명시된 내용을 바탕으로 추론한다.
이 스택에서 암호학 자체는 성숙한 부분이다. 무게가 실리는 곳은 세 개의 이음새다. 온체인 컨트랙트가 기록하는 것과 오프체인 코프로세서 네트워크가 실제로 연산하는 것 사이의 간극, 암호화된 값이 평문이 되는 비동기 경로, 그리고 복호화 키를 공동으로 보유하는 노드 위원회다.
아무도 볼 수 없는 연산의 비용
완전동형암호(FHE)는 암호문만 보유한 당사자가 입력값이나 결과값을 알지 못한 채 그 위에서 함수를 연산하여 결과의 암호문을 만들어낼 수 있게 한다. 토큰에 적용하면, 암호화된 두 잔액을 더하는 연산은 암호화된 새 잔액을 산출하며, 그 덧셈을 수행하는 기계는 어느 피연산자도 알지 못한다.
오버헤드는 구조적이다. 격자 기반 스킴의 FHE 암호문은 숨기는 평문보다 훨씬 크고, 동형 연산 하나마다 암호문에 노이즈가 더해진다. 특정 임계치를 넘으면 노이즈가 값을 파괴하기 때문에, 스킴들은 주기적으로 노이즈 감소 단계를 실행하는데 이것이 오히려 연산의 지배적인 비용이 된다. Zama는 자사 구현이 5년 전보다 100배 이상 빠르고 양자 내성을 갖췄다고 주장하는데, 후자는 이 스킴들이 기반하는 격자 가정에서 따라 나오는 성질이다. 두 주장 모두 독립적인 벤치마크 없이 자체 제작한 문서에서 나온 벤더 주장이다.
컨트랙트 작성자에게 더 중요한 제약은 제어 흐름이다. 프로그램은 암호화된 조건에 따라 분기할 수 없다. 분기를 타는 것 자체가 어느 분기를 탔는지를 드러내기 때문이며, 가스 소비량이나 상태 접근 패턴을 지켜보는 관찰자는 암호화가 숨기려 했던 비교 결과를 알아낼 수 있다. 따라서 조건문은 산술 연산이 된다. 두 결과를 모두 계산한 뒤 암호화된 선택 비트로 결과 사이를 멀티플렉싱한다. 기밀 전송은 발신자의 잔액이 충분한지 여부와 무관하게 같은 비용이 들고, 어느 경우든 상태 전이를 만들어낸다.
이 단 하나의 속성이 설계 전체로 퍼져나간다. ERC-7984가 전송 실패를 어떻게 처리하는지, 청산 로직을 표현하기가 왜 까다로운지, 기밀 실행과 평문 실행의 비용 차이가 왜 여유분이 아니라 배수 단위로 벌어지는지를 결정한다. Fhenix의 CoFHE 문서도 API 표면에서 같은 형태를 드러낸다. euint32, ebool 같은 암호화된 타입, FHE.add, FHE.sub 같은 연산, 그리고 이후 누가 특정 값을 복호화할 수 있는지를 관리하는 FHE.allowThis, FHE.allowSender 같은 명시적 접근제어 호출이 그것이다. 이 시스템들에서 복호화 권한은 자연스럽게 주어지는 것이 아니다. 컨트랙트가 명시적으로 실행해야 하는 부여 행위이며, 이를 빠뜨리면 해당 값은 영구히 읽을 수 없게 된다.
핸들, 코프로세서, 게이트웨이
Zama의 ERC-7984 설명 문서는 4단계 아키텍처를 묘사하는데, 각 부분 사이의 역할 분담이 엔지니어링 리스크가 집중되는 지점이다.
온체인 컨트랙트는 암호문 자체가 아니라 암호화된 값에 대한 포인터인 핸들을 저장한다. 기밀 토큰 컨트랙트가 암호화된 두 잔액을 더할 때, 이더리움 트랜잭션은 격자 산술을 수행하지 않는다. 세 핸들과 관련된 덧셈이 수행될 것임을 기록하고 즉시 출력 핸들을 반환할 뿐이다. 컨트랙트의 스토리지와 트랜잭션의 가스 비용은 암호학 자체의 비용이 아니라 핸들에 대한 부기 작업을 반영한다.
실제 FHE 연산은 오프체인의 코프로세서 네트워크에서 일어나며, 이들이 기록된 연산을 소비해 해당하는 암호문을 실체화한다. 게이트웨이가 이 코프로세서들을 조율하고, 어떤 주소가 어떤 핸들을 읽을 수 있는지에 대한 접근제어를 강제하며, 복호화 요청을 라우팅한다. 복호화 자체는 여러 독립적인 노드가 협력해야 하는 임계값 키 관리 시스템에 의해 수행되므로, 어떤 단일 운영자도 사용자의 잔액을 단독으로 복원할 수 없다.
이 분리 구조로부터 두 가지 성질이 직접 도출된다. 첫째, 온체인 정산이 그 배후에 있는 암호화 연산보다 먼저 확정된다. 전송은 핸들 부기 작업이 블록에 포함되는 순간 확정되지만, 그 핸들이 가리키는 암호문은 코프로세서가 실제로 산출한 뒤에야 존재한다. 따라서 부하가 걸릴 때 자연스러운 장애 형태는 지연 누적이다. 심볼릭 상태는 이더리움의 속도로 전진하지만 실체화는 그 뒤로 밀리며, 이 지연은 누군가 값을 읽어달라고 요청하는 순간에 표면화된다. 잔액을 확인하려는 사용자든 복호화 콜백을 기다리는 컨트랙트든, 평문 답변이 필요한 모든 것이 이 대기열을 물려받는다.
둘째, ZK 구성요소는 여기서 실드 풀보다 훨씬 적은 일을 한다. 영지식 증명은 사용자가 제출한 입력이 올바르게 암호화되었고 제출자에게 귀속됨을 입증하는 데 쓰이며, 어떤 상태 전이가 올바르게 실행되었음을 증명하는 데 쓰이지 않는다. 손상되거나 악의적으로 조작된 암호문이 시스템에 받아들여지면 하위 연산을 오염시키거나 네트워크 키를 캐내는 통로가 될 수 있으므로, 이 증명은 입력 필터로 작동한다. zk-SNARK 실드 풀에서는 증명이 전체 정당성 논증을 지탱하며 암호화된 상태에 대해 제3자가 연산하는 일 자체가 없다. 이들은 우연히 같은 약어를 공유하는, 서로 다른 보안 아키텍처다.
Zama는 이 구조를 지원하는 데 기존 체인이 프로토콜 수준의 업그레이드를 필요로 하지 않는다고 밝힌다. 이 주장은 범위가 좁고 아키텍처상 그럴 법하다. 실행은 컨트랙트 코드 안에서 일어나거나 오프체인에서 일어날 뿐이다. 다만 이 주장은 기존 애플리케이션이 그 결과 상태를 소비할 수 있는지는 확립해주지 않는다.
ERC-7984가 컨트랙트 내부에서 바꾸는 것
코드 수준에서 이 표준은 결과가 뒤따르는 타입 치환이다. ERC-20이 uint256, transfer, balanceOf를 노출하는 곳에서, ERC-7984는 euint64, confidentialTransfer, confidentialBalanceOf를 노출한다. 논리적 연산은 그대로 남지만, 피연산자는 컨트랙트 자신도 읽을 수 없는 암호화된 핸들이 된다.
256비트에서 64비트로 좁아진 것은 겉치레가 아니다. FHE 비용은 암호화된 정수의 비트 폭에 비례해 늘어나므로, 기밀 토큰은 사용하지 않는 비트 하나하나에 대해서도 직접 비용을 지불한다. 64비트 잔액은 18자리 소수점을 가진 임의 규모의 발행량을 표현할 수 없으므로, 기밀 토큰은 투명한 대응 토큰보다 소수점 자리수가 적고 최대 발행량이 작은 쪽으로 밀린다. 기존 18자리 소수점 ERC-20을 기밀 표현으로 감싸는 어떤 래퍼든 스케일링 규칙을 정의해야 하고 그로 인한 라운딩을 받아들여야 한다.
잔액 부족 처리는 두 번째 구조적 변화이며, 분기 금지 제약에서 따라 나온다. 일반적인 ERC-20은 발신자에게 자금이 부족하면 리버트하고, 그 리버트는 공개 정보다. 기밀 전송은 관찰자에게 비교 결과를 유출하지 않는 한 암호화된 비교로 리버트할 수 없다. 이 설계는 자금이 충분하면 요청된 금액과 같고, 부족하면 0이 되는 암호화된 전송 금액을 계산하여 트랜잭션이 어느 경우든 성공하게 만든다. 호출자는 반환된 값을 복호화할 권한이 있을 때만, 복호화를 통해서만 실제로 무슨 일이 일어났는지 알 수 있다. 성공한 트랜잭션을 전송 완료의 증거로 취급하는 모든 통합은 수정이 필요하다.
컨트랙트 기능으로서의 선택적 공개
Zama의 구현은 규제 요구사항을 Observer를 통해 다룬다. 감사인이나 규제기관 같은 주소에 지정된 값에 대한 복호화 접근 권한을 부여할 수 있으며, 여기에 KYC와 AML 검사, 잔액 동결, 실물자산(RWA) 컴플라이언스 규칙을 위한 선택적 확장 모듈이 곁들여진다. 공개는 기본값이 아니라 권한 부여로 작동하며, 운영자의 재량이 아니라 게이트웨이의 접근제어에 의해 강제된다.
이 설계는 기관용 제안의 핵심이면서 동시에 공개된 세부사항이 가장 적은 부분이다. Observer 부여가 철회 가능한지, 부여 이전에 만들어진 핸들에도 소급 적용되는지 아니면 이후로만 적용되는지, 사용자를 대신해 누가 이를 발급할 수 있는지는 현재 공개된 문서가 정리해주지 않는 거버넌스 문제다. 특히 동결 모듈은 특권 행위자가 사용자 상태를 볼 수 없다는 것이 전제인 시스템에 다시 특권 행위자를 들여온다. 이 두 속성은 원칙적으로 양립 가능하다. 동결은 핸들을 읽지 않고도 핸들에 작용할 수 있기 때문이다. 하지만 이 조합은 기능 명세가 아니라 실제 컨트랙트 코드에서 검증이 필요하다.
암호화된 잔액과 기존 DeFi의 접점
이더리움이 업그레이드가 필요 없다는 주장과 Uniswap이나 Aave가 ERC-7984 토큰을 보유할 수 있다는 주장은 별개다. 두 번째 주장이 더 어렵고, 앞서 설명한 메커니즘들이 그 어려움을 만든다.
상수곱 AMM은 공개된 리저브를 바탕으로 스왑 가격을 정한다. 리저브가 암호화되어 있으면 풀은 가격을 공개할 수 없고, 차익거래자는 가격을 계산할 수 없으며, 풀을 잘못된 가격의 거래로부터 보호하는 불변식 검사는 모든 스왑마다 동형으로 평가되어야 한다. 대출 시장의 문제는 더 날카롭다. 청산은 제3자가 어떤 포지션이 부실 상태임을 확인해야 하는데, 이는 헬스 팩터가 공개되어야 함을 의미하며 그러면 기밀성이 깨지고, 그렇지 않으면 청산자가 복호화를 요청하고 그 결과에 따라 행동해야 하는데 이는 원자적 트랜잭션을 여러 블록에 걸친 요청-콜백 시퀀스로 바꿔버리고 그 사이에 적대적 행위자가 담보를 자유롭게 옮길 수 있게 만든다.
일반적인 걸림돌은 비동기성이다. 실행 중간에 평문 값을 필요로 하는 어떤 조합도 하나의 트랜잭션 안에서 완결될 수 없다. 복호화 경로가 게이트웨이와 임계값 위원회를 거치기 때문이다. 단일 호출 프레임 안에서의 원자적 정산을 전제로 설계된 프로토콜은 단순한 파라미터 조정으로 여기에 적응하지 못하며, 재설계가 필요하다.
이렇게 되면 단기적으로 조합 가능한 영역은 기밀성이 일차 요구사항이고 지연에 대한 허용치가 본질적으로 존재하는 애플리케이션에 집중된다. 지급자가 모든 금액을 알고 제3자가 자산 가격을 매기지 않는 급여, 정보를 양자 간에 공유하는 거래상대방 사이의 기관 정산, 그리고 값이 예정된 공개 시점까지 숨겨져 있어야 하는 메커니즘 자체를 가진 봉인 경매가 그것이며, 봉인 경매는 마감 시점에 임계값 복호화를 기다리는 것이 구조적으로 당연하다. Inco는 자사의 Lightning 제품 마케팅에서 봉인 경매, 대출 시장, 인도-결제 동시 에스크로, 토큰 베스팅 등 유사한 목록을 나열하며 “조합성을 깨지 않고” 기밀 ERC20과 SPL을 지원한다고 주장한다. 이 주장 역시 같은 잣대의 평가가 필요하다. 기반 체인이 토큰을 받아들이는지가 아니라, 수정되지 않은 제3자 프로토콜이 그 토큰에 대해 가격을 매기고 청산할 수 있는지가 관건이다.
처리량 상한선과 그것이 배제하는 것
Zama의 라이트페이퍼는 스케일링을 세 단계로 구성한다. 현재 성능은 범용 프로세서에서 돌아간다. GPU는 “초당 100건 이상”으로의 이행을 가능케 하는 것으로 묘사된다. 전용 가속기인 FPGA와 ASIC은 명시되지 않은 미래 시점에 “초당 수천 건”에 도달할 것으로 전망된다. 이들은 공개된 기준선 측정치가 없는, 앞을 내다보는 벤더 목표치다.
이번 출시를 둘러싸고 유포되는 구체적인 숫자들, 현재 초당 약 20건이라거나 GPU 도입 시 500~1,000건 범위라는 것들은 라이트페이퍼에 등장하지 않으며 검증할 수 없었다. 상위 추정치는 Zama가 공개한 GPU 관련 표현을 5~10배 초과한다. 벤더 자신의 숫자가 함의하는 바는, GPU 마일스톤이 기밀 실행을 레이어 전체의 모든 애플리케이션이 나눠 쓰는, 중형 L2 하나가 평문 작업을 처리하는 정도에 비견되는 처리량에 놓는다는 것이다.
이 상한선은 DeFi 워크로드를 명확하게 갈라놓는다. 급여, 베스팅, 주기적 기관 정산은 하루 수백에서 수천 건 수준의 트랜잭션 수를 발생시키며, 수 초에서 수 분 사이의 확인 지연은 운영상 감당할 만하다. 봉인 경매와 OTC 정산은 배치 프로세스로 작동한다. 공개된 로드맵상 이들 중 어느 것도 처리량에 제약받지 않는다.
연속 시장은 다른 제약을 받는다. 스팟 AMM 거래, 영구선물의 펀딩비 갱신, 오라클 기반 청산, 블록 내 실행 전략은 처리량과 유한한 지연을 모두 요구하며, 여기서 구속력을 갖는 것은 지연이다. 처리량이 더 높아지더라도 값을 읽는 데 임계값 복호화 라운드가 필요한 시스템은 경쟁적인 청산을 지탱할 수 없다. FHE 기반 기밀성이 이런 시장에 쓰인다면, 그것은 주문 규모나 담보 구성 같은 특정 필드를 공개적인 가격 형성이 이루어지는 시스템 안에서 숨기는 방식으로 이루어질 것이다. 이는 일반적인 기밀 DeFi보다 훨씬 좁은 제품이다.
다뤄지지 않은 비용 역학도 있다. 핸들 부기용 온체인 가스는 낮지만, FHE 연산은 보상이 필요한 코프로세서에서 일어난다. 이 비용을 어떻게 미터링하고, 누가 부담하며, 수요 급증에도 가격 모델이 버틸 수 있는지는 공개된 문서에서 확립되지 않은 경제학이다. 주된 연산 비용이 정산 레이어의 수수료 시장 바깥에 놓인 시스템은 혼잡이 집중될 2차 수수료 시장을 별도로 확립해야 한다. Fhenix의 문서는 관련 있는 단서를 제공한다. 그들의 로컬 목업 환경은 평문을 온체인에 저장하는 방식으로 FHE를 시뮬레이션하며, 문서에는 목업 가스 비용이 프로덕션과 다르다고 명시되어 있다. 이 스택들에서 나온 메인넷 이전 벤치마크는 이 간극을 염두에 두고 평가해야 한다.
키 조각을 누가 쥐고 있는가
임계값 키 관리 시스템은 이 아키텍처에서 통상적인 신뢰 가정과 가장 닮은 구성요소이며, 확보 가능한 자료가 가장 적게 명세하는 부분이기도 하다.
Zama는 복호화에 여러 독립 노드의 협력이 필요하며, 이는 단일 당사자가 사용자 데이터를 단독으로 복호화하는 것을 방지한다고 밝힌다. 문서는 전체 노드 수, 재구성 임계값, 운영자 선정과 제거 메커니즘, 운영자의 관할권, 그리고 평문 복원 단계 없이 키를 재분배(resharding)할 수 있는지를 공개하지 않는다. 이 각각의 변수가 시스템 수준의 잔액 보안에 직접 영향을 미친다.
직접 비교해보면 신뢰 트레이드오프가 명확해진다. 평범한 퍼블릭 L1에는 복호화 단계 자체가 없으므로 침해하거나 강제할 위원회도 없지만, 그 대가는 완전한 투명성이다. 하드웨어 엔클레이브 설계에서는 기밀성이 프로세서 벤더의 보안 실행 환경과 사이드채널 취약점의 부재에 의존하여, 신뢰가 하드웨어 공급망에 집중된다. 임계값 스킴에서는 임계값 수를 밑도는 노드 운영자가 결탁하거나 강제되지 않는 한 기밀성이 유지되며, 신뢰가 여러 운영자에게 분산되지만 그렇다고 커스터디 가정이 완전히 사라지지는 않는다.
두 가지 장애 형태는 각기 다른 평가가 필요하다. 임계값 규모의 연합이 키를 재구성하면 기밀성이 무너지며, 이는 관할권의 분산 여부에 달려 있다. 위원회가 복호화 요청 처리를 거부하면 가용성이 무너진다. 잔액이 암호화된 상태로 남아 있지만 복호화를 얻지 못하는 사용자는 소유권을 증명할 수도, 평문 값을 요구하는 컨트랙트를 통해 빠져나올 수도 없다. 기밀 시스템에서 검열은 트랜잭션 거부가 아니라 처리되지 않은 복호화 요청의 형태로 나타난다.
Zama의 라이트페이퍼에는 자사 프로토콜을 안전성, 분산성, 검증 가능성, 조합성, 확장성, 사용 편의성 모두에서 동시에 높게 평가하고, TEE 기반 접근법은 안전성과 검증 가능성이 부족하다고, 다른 FHE, MPC, ZK 시스템은 확장성이나 사용성이 부족하다고 분류하는 비교표가 실려 있다. 이 비교는 벤더 포지셔닝을 나타낸다. 그 배후의 기술적 트레이드오프는 여전히 구체적이다. 하드웨어 신뢰와 임계값 신뢰는 서로 다른 장애 형태를 갖는다.
메커니즘을 위협 모델에 맞추기
구현체의 현재 상태는 제공업체마다 다양하다. Zama의 라이트페이퍼는 이더리움 메인넷을 2025년 말 목표로 명시하며, 2026년 2월에 발행된 ERC-7984 설명 문서는 사용 사례를 논한다. Fhenix의 CoFHE 문서는 이더리움 세폴리아, 아비트럼 세폴리아, 베이스 세폴리아 지원을 명시하며, 프로덕션 메인넷 지원은 미확정이다. Inco는 새 VM 없이 네이티브 체인 속도를 낸다는 라이브러리 임포트 형태로 Lightning을 마케팅하며, 근간 메커니즘을 명시하지 않은 채 양자 내성 보안을 주장한다. 네이티브에 가까운 지연은 표준적인 FHE 오버헤드 프로파일과 맞지 않아, 하드웨어 엔클레이브가 쓰였을 것이라는 추정으로 이어지지만, 1차 문서는 이를 확인해주지 않는다.
| 접근법 | 필요한 신뢰 | 숨겨지는 것 | 구속력을 갖는 제약 |
|---|---|---|---|
| 임계값 복호화를 갖춘 FHE | 임계값 미달의 키 조각 보유자가 결탁하거나 강제되지 않을 것 | 연산 중의 입력, 중간 상태, 저장된 잔액 | 처리량과 비동기 복호화 지연 |
| 하드웨어 엔클레이브 실행 | 프로세서 벤더의 무결성, 사이드채널 부재 | 엔클레이브 내부에 있는 동안의 입력과 상태 | 공급망 및 사이드채널 노출; 외부 검증 가능성의 한계 |
| 연산의 ZK 증명 | 해당하는 경우 트러스티드 세팅, 증명 시스템의 완전성 | 증명자가 공개하지 않기로 선택한 모든 것; 지속적인 암호화 상태에는 별도 장치가 필요 | 증명 비용; 제3자가 숨겨진 상태에 대해 연산할 수 없음 |
| 일반 퍼블릭 실행 | 합의 외에 별도 신뢰 불필요 | 없음 | 완전한 투명성 |
접근법 선택은 기능 목록이 아니라 위협 모델에 좌우된다. 사용자가 숨길 수 없는 데이터를 애플리케이션이 연산해야 하고 수 초 단위의 지연이 허용되는 경우, 임계값 복호화를 갖춘 FHE는 낮은 처리량 한계 안에서 강력한 암호학적 격리를 제공한다. 기반 체인 수준의 네이티브 지연이 요구되는 경우, 엔클레이브 기반 실행이 현재 유효한 대안이며 하드웨어 수준의 신뢰 가정을 받아들여야 한다. 목표가 제3자에 의한 상태 연산 없이 유효한 실행을 증명하는 것이라면, 영지식 증명이 더 낮은 오버헤드의 구성을 제공한다.
기밀 급여와 양자 간 정산은 임계값 FHE 아키텍처에 맞는다. 연속 시장에서의 주문 흐름 기밀성은 맞지 않는다. 현재 제약 하에서 이를 구현하려면 신뢰받는 운영자를 들이거나 구조적 지연을 도입해야 한다.
이 논지가 무너질 수 있는 지점
가장 먼저 답이 필요한 질문들은 암호학적인 것이 아니라 운영상의 것이다. 임계값 위원회의 구성과 거버넌스를 문서화하면 복호화가 여러 법적 관할권에 걸친 운영자들에게 의존하는지 아니면 소수 집단에 집중되어 있는지가 밝혀질 것이다. 트랜잭션 제출부터 읽을 수 있는 결과 산출까지의 지연을 측정하는 독립적인 메인넷 벤치마크는 실질적인 처리량을 명확히 해줄 것이다. OpenZeppelin ERC-7984 구현에 대한 감사 보고서는 적대적인 시퀀싱 아래에서도 잔액 클램핑과 접근제어 시맨틱이 유지되는지를 확인해줄 것이다.
경제적 요인도 같은 수준의 검증이 필요하다. 코프로세서 연산이 희소 자원이며, 이는 기반 정산 시장 바깥에서 가격이 매겨진다. 수수료 메커니즘이 정형화되기 전까지 혼잡 역학은 특성이 규명되지 않은 채로 남는다. 부하가 걸릴 때 복호화 지연이 급증하는 기밀성 레이어는 계정 잔액을 일시적으로 읽을 수 없게 만들 위험이 있다.
채택 지표는 개별적인 전송 볼륨이 아니라 프로토콜 통합을 기준으로 평가해야 한다. 알려진 거래상대방 사이의 기밀 전송은 이 표준의 기본적인 실행 경로를 보여줄 뿐 일반적인 조합성을 증명하지는 않는다. 지켜봐야 할 핵심 마일스톤은 ERC-7984 통합 없이 개발된 대출 시장이나 AMM 같은, 수정되지 않은 제3자 프로토콜이 프로덕션에서 암호화된 잔액에 대해 실제로 가격을 매기고 정산하는 순간이다. 그 통합이 입증되기 전까지, 암호화된 잔액은 열린 DeFi 아키텍처보다는 경계가 한정된 다자간 워크플로 안에서 주로 작동하게 된다.
はじめに
ERC-20の送金は、RPCエンドポイントを持つ誰に対しても、移動した金額と両者の残高を公開する。給与支払い、トレジャリーのリバランス、あるいはブロックトレードにとって、この性質は致命的であり、標準的な回避策はトランザクションをオフチェーンに留め、ネットの結果だけをオンチェーンで決済することだった。
Zamaの Confidential Blockchain Protocol は、これとは異なる構成を提案している。litepaperによれば、これは新たなL1やL2ではなく、既存のパブリックブロックチェーンの上に乗る形のクロスチェーン機密性レイヤーであり、暗号化された値に対する計算のための完全準同型暗号（FHE）、しきい値鍵管理のためのマルチパーティ計算（MPC）、そしてユーザー入力が正しく暗号化されたことを検証する狭い用途に限定したゼロ知識証明を組み合わせている。示されたロードマップでは、testnetはlitepaperの公開前に稼働開始しており、Ethereumメインネットは2025年末、他のEVMチェーンは2026年上半期、Solanaは2026年下半期を予定している。機密トークン規格であるERC-7984についてのZama自身の解説記事は2026年2月17日付けで、この規格を技術非依存として説明しており、FHE実装はOpenZeppelinと共同で構築されたとしている。
このローンチに関する市場での言説には、一次資料には見当たらない数値がいくつも付随している。現在のスループットが毎秒約20トランザクションであるという数字、GPU導入後に毎秒500〜1,000トランザクションを目指すという目標値、confidential USDCでの導入規模、名指しされた機関投資家向けOTC取引、$ZAMAトークンイベントの仕組みと日付、OpenZeppelinによるERC-7984実装の監査状況。これらはいずれもZamaのlitepaper、そのERC-7984解説記事、FhenixやIncoのドキュメントで裏付けを取ることができなかった。未確認のまま残るため、以下の分析はベンダーが公開している文書の記述に基づいて進める。
このスタック内で成熟している部分は暗号技術そのものである。重みを支えているのはむしろ3つの継ぎ目だ。オンチェーンのコントラクトが記録する内容とオフチェーンのコプロセッサネットワークが計算する内容の間のギャップ、暗号化された値が平文になるまでの非同期経路、そして復号鍵を集合的に保持するノードの委員会である。
誰にも見えない算術のコスト
完全準同型暗号（FHE）は、暗号文しか持たない当事者が、それらに対して関数を計算し、入力も出力も知ることなく結果の暗号文を生成することを可能にする。トークンに適用すれば、2つの暗号化された残高の加算は暗号化された新しい残高を生み、その加算を実行するマシンはどちらのオペランドも知らない。
このオーバーヘッドは構造的なものだ。格子ベース方式のFHE暗号文は、隠している平文よりもはるかに大きく、準同型演算のたびに暗号文にノイズが加わる。しきい値を超えるとノイズは値を破壊してしまうため、方式は定期的にノイズ削減ステップを実行する必要があり、これ自体が計算全体で支配的なコストとなる。Zamaは自社の実装が5年前と比べて100倍以上高速であり、耐量子安全性を備えていると主張している。後者はこれらの方式が依拠する格子問題の仮定から導かれるものだ。どちらもベンダー自身が作成した文書に基づく主張であり、独立したベンチマークによる裏付けはない。
コントラクト開発者にとってより深刻な制約は制御フローだ。プログラムは暗号化された条件で分岐することができない。分岐を取ればどちらの分岐が取られたかが露呈し、ガス消費量やステート・アクセスのパターンを観察している者は、暗号化によって隠すはずだった比較結果を知ってしまうからだ。したがって条件分岐は算術に置き換えられる。両方の結果を計算し、暗号化されたセレクタービットでどちらかを多重化して選ぶのだ。機密送金は、送信者の残高が十分であってもなくても同じコストがかかり、いずれにせよステート遷移を生成する。
この単一の性質が設計全体に波及する。ERC-7984が失敗した送金をどう扱うか、清算ロジックの表現がなぜぎこちなくなるか、そして機密実行とプレーンテキスト実行のコスト差がわずかな差ではなく倍数になるのはなぜか、これらすべてを決定づけている。FhenixのCoFHEドキュメントも、そのAPI表面に同じ形を露呈させている。euint32やeboolといった暗号化型、FHE.addやFHE.subといった演算、そしてFHE.allowThisやFHE.allowSenderといった、誰が後にその値を復号できるかを管理する明示的なアクセス制御呼び出しがそれだ。これらのシステムでは復号の許可は暗黙のものではない。コントラクトが実行しなければならない明示的な付与であり、それを怠れば値は永久に読めないままになる。
ハンドル、コプロセッサ、そしてゲートウェイ
ZamaのERC-7984解説記事は4部構成のアーキテクチャを記述しており、各部分の間の役割分担こそがエンジニアリング上のリスクが集中する場所だ。
オンチェーンのコントラクトは、暗号文そのものではなく暗号化された値へのポインタであるハンドルを保存する。機密トークンのコントラクトが2つの暗号化残高を足し合わせるとき、Ethereumのトランザクションは格子演算を実行しているわけではない。3つのハンドルに関わる加算が実行されるべきことを記録し、出力ハンドルを即座に返すだけだ。コントラクトのストレージとトランザクションのガスコストが反映しているのは、ハンドルに関する帳簿処理であって、暗号技術そのもののコストではない。
実際のFHE演算はオフチェーンで、記録された演算を消費して対応する暗号文を実体化するコプロセッサのネットワーク内で行われる。Gatewayがそれらのコプロセッサをオーケストレーションし、どのアドレスがどのハンドルを読めるかというアクセス制御を強制し、復号リクエストをルーティングする。復号自体は、複数の独立したノードが協調しなければならないしきい値鍵管理システムによって実行され、単一のオペレータが一方的にユーザーの残高を復元できないようになっている。
この分割から2つの性質が直接導かれる。第一に、オンチェーンの決済は、その裏にある暗号化計算よりも先に確定する。送金はハンドルの帳簿処理がブロックに含まれた時点で確定するが、そのハンドルが指す暗号文はコプロセッサが生成した時点で初めて存在する。したがって負荷がかかった状況での自然な障害モードはバックログだ。シンボリックなステートはEthereumのペースで進む一方、実体化はそれに遅れを取り、その遅延は誰かが値を読もうとした瞬間に表面化する。残高を確認しようとするユーザーであれ、復号のコールバックを待つコントラクトであれ、平文の答えを必要とするものはすべてこのキューを引き継ぐことになる。
第二に、ZKの構成要素がここで担う役割は、シールドプールにおけるそれよりもはるかに小さい。ゼロ知識証明はここでは、ユーザーが提出した入力が正しく暗号化され、提出者に紐づいていることを立証するために使われるのであって、何らかのステート遷移が正しく実行されたことを証明するためではない。システムに受け入れられた不正な形式の暗号文や敵対的に細工された暗号文は、下流の計算を破損させたり、ネットワーク鍵を探るチャネルになったりしうるため、この証明は入力フィルターとして機能する。zk-SNARKによるシールドプールでは、証明が正しさの議論全体を担い、暗号化されたステートを第三者が計算することは決してない。同じ頭字語を共有しているとはいえ、これらは異なるセキュリティアーキテクチャである。
Zamaは、既存のチェーンがこの構成をサポートするのにプロトコルレベルのアップグレードを必要としないと述べている。この主張は限定的であり、アーキテクチャ上も妥当だ。実行はコントラクトコード内かオフチェーンのどちらかで行われるからである。しかし、既存のアプリケーションが結果として生じるステートを消費できるかどうかについては何も語っていない。
ERC-7984がコントラクト内部で変えるもの
コードレベルでは、この規格は影響を伴う型の置き換えである。ERC-20がuint256、transfer、balanceOfを公開するのに対し、ERC-7984はeuint64、confidentialTransfer、confidentialBalanceOfを公開する。論理的な操作は残るが、オペランドはコントラクト自身も読めない暗号化されたハンドルになる。
256ビットから64ビットへの縮小は見た目だけの話ではない。FHEのコストは暗号化された整数のビット幅に応じて増大するため、機密トークンは使われないレンジのビットひとつひとつに対して直接コストを支払うことになる。64ビットの残高は18桁の小数を持つ供給量をどんな規模でも表現できないため、機密トークンは透明なトークンよりも小数点以下の桁数が少なく、最大供給量も小さくなる方向へ押しやられる。既存の18桁小数のERC-20を機密表現にラップするものは何であれ、スケーリングの規約を定義し、それが持ち込む丸め誤差を受け入れる必要がある。
残高不足の扱いは2番目の構造的変更であり、分岐禁止という制約から直接生じる。従来のERC-20は送信者に資金が不足しているとリバートし、そのリバートは公開情報だ。機密送金は、暗号化された比較の結果を観察者に漏らすことなくリバートすることができない。この設計では、資金が十分な場合はリクエストされた金額と等しく、不足している場合はゼロとなるような暗号化された送金額を計算し、どちらの場合もトランザクションが成功するようにする。呼び出し元は、権限を持っていればその返り値を復号することによってのみ何が起きたかを知る。成功したトランザクションを送金完了の証拠として扱うすべての連携先は改修が必要になる。
コントラクト機能としての選択的開示
Zamaの実装は、監査人や規制当局のようなアドレスに指定した値への復号アクセスを付与できるObserverという仕組みと、KYCやAMLチェック、残高凍結、実世界資産（RWA）のコンプライアンスルールのためのオプションの拡張モジュールを通じて、コンプライアンス要件に対応している。開示はデフォルトではなく権限の付与として機能し、オペレータの裁量ではなくGatewayのアクセス制御によって強制される。
この設計は機関投資家向け提案の核心をなす部分であり、同時に公開されている詳細が最も少ない部分でもある。Observerの付与が取り消し可能かどうか、付与前に作成されたハンドルに遡及的に適用されるのかそれとも将来に向けてのみ適用されるのか、誰がユーザーに代わって付与を発行できるのか、これらはガバナンス上の問いであり、現在入手可能なドキュメントでは決着していない。特に凍結モジュールは、いかなる特権的主体もユーザーのステートを見ることができないという前提に立つシステムに、特権的主体を再び持ち込むことになる。凍結はハンドルを読まずにそれに対して作用するため、この2つの性質は原理的には両立可能だが、この組み合わせは機能仕様書ではなくコントラクトコードでの検証を要する。
暗号化された残高が既存のDeFiと出会う場所
Ethereumがアップグレードを必要としないという主張と、UniswapやAaveがERC-7984トークンを保有できるという主張は別物だ。後者の方が難しく、それは上で詳述した仕組みによって引き起こされる。
定数積AMMは公開されたリザーブから取引価格を算出する。リザーブが暗号化されていれば、プールは価格を公開できず、裁定取引者もそれを計算できず、プールを不適正な価格の取引から守る不変条件のチェックは、すべてのスワップにおいて準同型的に評価されなければならない。レンディングマーケットにはさらに鋭い問題がある。清算には、あるポジションが債務超過であることを第三者が検証する必要があるが、これはヘルスファクターが公開されて機密性が失われるか、あるいは清算人が復号をリクエストしてその結果に基づいて行動するかのどちらかを意味し、後者はアトミックなトランザクションを複数ブロックにまたがるリクエスト・コールバックのシーケンスに変え、その間敵対者が担保を自由に動かせる状態にしてしまう。
非同期性が一般的な障壁だ。実行の途中で平文の値を必要とする合成は、1つのトランザクション内で完結できない。復号経路がGatewayとしきい値委員会を通るからだ。単一のコールフレーム内でのアトミックな決済を前提に設計されたプロトコルは、単純なパラメータ変更ではこれに適応できず、再設計を必要とする。
そのため、当面のコンポーザビリティの余地は、機密性が主要な要件であり、レイテンシへの許容度がもともと組み込まれているアプリケーションを中心に絞られる。給与支払い（支払者はすべての金額を知っており、第三者が資産の価格付けを行うわけではない）、二者間で情報を共有する機関投資家間の決済、そして封印入札オークション（メカニズム自体が値がスケジュールされた開示まで隠されていることに依存しており、締め切り時にしきい値復号を待つことが構造的に組み込まれている）である。Incoが自社のLightning製品向けに掲げるマーケティングも似たようなリストを挙げており、封印入札オークション、マネーマーケット、受渡決済（DvP）エスクロー、トークンベスティングを含め、機密ERC20とSPLのサポートが「コンポーザビリティを損なうことなく」実現すると謳っている。この主張も同じ評価基準を要する。ベースチェーンがそのトークンを受け入れるかどうかではなく、改変されていない第三者製のプロトコルがそのトークンに対して価格付けと清算を行えるかどうかだ。
スループットの上限とそれが除外するもの
Zamaのlitepaperはスケーリングを3段階で描いている。現在のパフォーマンスは汎用プロセッサ上で稼働している。GPUは「毎秒100件超のトランザクション」への移行を可能にするものとして説明されている。専用アクセラレータ（FPGAやASIC）は、未確定の将来時点で「毎秒数千トランザクション」に達すると見込まれている。これらはいずれも公開済みのベースライン測定値を伴わない、先を見据えたベンダーの目標値だ。
このローンチをめぐって流布している具体的な数字、すなわち現在毎秒約20トランザクション、GPU使用時に500〜1,000という範囲は、litepaperには見当たらず、検証もできなかった。上限側の推定はZamaが公表しているGPUに関する記述を5〜10倍上回っている。ベンダーの数字が意味することは、GPUのマイルストーンが機密実行のスループットを、レイヤー上のすべてのアプリケーションで共有される、中規模のL2が平文処理で出せる程度の水準に置くということだ。
この上限はDeFiのワークロードを明確に選り分ける。給与支払い、ベスティング、定期的な機関投資家間決済は、1日あたり数百から数千件のトランザクション数を生み、秒から分単位の確認レイテンシは運用上許容できる。封印入札オークションとOTC決済はバッチ処理として動作する。これらはいずれも、公開されているロードマップ上でスループット制約に直面しない。
継続的なマーケットは異なる制約に直面する。スポットAMMの取引、パーペチュアルの資金調達率の更新、オラクル駆動の清算、ブロック内での実行戦略は、スループットとレイテンシの両方を必要とし、レイテンシが拘束条件となる。より高いスループットであっても、ある値を読むためにしきい値復号のラウンドを要するシステムは、競争力のある清算をサポートできない。FHEベースの機密性がそれらのマーケットに資するとすれば、それは注文サイズや担保構成といった特定のフィールドを、公開された価格形成を持つシステムの中に隠すという形でだろう。それは一般的な機密DeFiよりも狭い製品だ。
未解決のコスト力学もある。ハンドルの帳簿処理に対するオンチェーンのガスは低いが、FHE計算はコプロセッサ上で発生し、それには対価が必要だ。このコストがどのように計測されるのか、誰が負担するのか、そしてその価格モデルが需要の急増に耐えられるのか、これらの経済性は入手可能なドキュメントでは確立されていない。主要な計算コストが決済レイヤーの手数料市場の外にあるシステムは、混雑が集中する二次的な手数料市場を確立しなければならない。Fhenixのドキュメントには関連する注記がある。そのローカルなモック環境はFHEを平文をオンチェーンに保存することでシミュレートしており、モックのガスコストは本番環境と異なるとドキュメントに記されている。これらのスタックによるメインネット前のベンチマークは、そのギャップを念頭に置いて評価すべきだ。
誰が鍵の断片を保持するのか
しきい値鍵管理システムは、このアーキテクチャの中で従来型の信頼前提に最も近い構成要素であり、入手可能な資料が最も仕様を示していない部分でもある。
Zamaは、復号には複数の独立したノードが協調する必要があり、単一の当事者が一方的にユーザーデータを復号することを防ぐと述べている。ドキュメントは、ノードの総数、再構成に必要なしきい値、オペレータの選任・解任の仕組み、オペレータの管轄区域、平文への再構成ステップなしに鍵を再分配できるかどうかを開示していない。これらの変数はそれぞれ、システムレベルでの残高セキュリティに直接影響する。
直接比較すると信頼上のトレードオフが明確になる。単純なパブリックL1では復号ステップ自体が存在せず、妥協や強制の対象となる委員会も存在しない。その代わり完全な透明性というトレードオフを負う。ハードウェアエンクレーブ方式では、機密性がプロセッサベンダーの安全な実行環境と、サイドチャネル脆弱性の不在に依存し、信頼はハードウェアのサプライチェーンに集中する。しきい値方式では、しきい値未満の数のノードオペレータが結託または強制されない限り機密性は保たれ、信頼はオペレータ間に分散されるが、カストディの前提が完全に排除されるわけではない。
2つの障害モードは別々に評価する必要がある。しきい値規模の連合が鍵を再構成できてしまえば機密性は失われ、これは管轄の分布に依存する。委員会が復号リクエストの処理を拒否すればライブネスが失われる。残高は暗号化されたままだが復号を得られないユーザーは、平文の値を要求するコントラクトを通じて所有権を証明したり出口を確保したりできない。機密システムにおける検閲は、拒否されたトランザクションではなく、満たされない復号リクエストという形を取る。
Zamaのlitepaperには、自社のプロトコルを、安全性、分散性、検証可能性、コンポーザビリティ、スケーラビリティ、使いやすさのすべてを同時に満たすものとして評価する一方、TEEベースのアプローチを安全性と検証可能性に欠けるものとして、その他のFHE、MPC、ZKシステムをスケーラビリティまたは使いやすさに欠けるものとして分類する比較表が含まれている。この比較はベンダーによるポジショニングである。基礎にある技術的トレードオフは具体的なまま残っている。ハードウェアへの信頼としきい値への信頼は、それぞれ別個の障害モードを提示するのだ。
メカニズムを敵対者モデルに合わせる
実装の現状はプロバイダーによってまちまちだ。Zamaのlitepaperは2025年末をEthereumメインネットの目標時期として挙げており、2026年2月に公開されたERC-7984解説記事はユースケースについて論じている。FhenixのCoFHEドキュメントはEthereum Sepolia、Arbitrum Sepolia、Base Sepoliaへのサポートを明記しており、本番のメインネットサポートは未定だ。Incoは、Lightningをネイティブチェーンと同等の速度を提供するライブラリインポートとしてマーケティングしており、新たなVMを必要としないとし、耐量子安全性を主張しているが、その根底にあるメカニズムは名指ししていない。ネイティブに近いレイテンシは標準的なFHEのオーバーヘッドのプロファイルと矛盾しており、ハードウェアエンクレーブが使われているという推測につながっているが、一次資料はこれを確認していない。
| アプローチ | 必要な信頼 | 隠されたままになるもの | 拘束条件 |
|---|---|---|---|
| しきい値復号を伴うFHE | しきい値未満の数の鍵断片保持者が結託または強制されないこと | 計算中の入力、中間ステート、保存された残高 | スループットと非同期復号のレイテンシ |
| ハードウェアエンクレーブ実行 | プロセッサベンダーの完全性、サイドチャネルの不在 | エンクレーブ内にある間の入力とステート | サプライチェーンとサイドチャネルへの露出、外部からの検証可能性の限界 |
| 計算のZK証明 | 該当する場合はトラステッドセットアップ、証明システムの健全性 | 証明者が開示しないことを選んだあらゆるもの、永続的な暗号化ステートには別の仕組みが必要 | 証明生成コスト、隠されたステートに対して第三者が計算することはできない |
| プレーンなパブリック実行 | コンセンサス以外に何もなし | なし | 完全な透明性 |
どのアプローチを選ぶかは機能の一覧ではなく脅威モデルに依存する。ユーザーが差し控えることのできないデータに対して計算を行う必要があり、秒単位のレイテンシが許容できるアプリケーションでは、しきい値復号を伴うFHEが低頻度のスループット制約の範囲内で強力な暗号学的隔離を提供する。ベースチェーンネイティブのレイテンシが求められる場合、エンクレーブベースの実行が有力な代替であり、ハードウェアレベルの信頼前提を受け入れることになる。第三者によるステート計算なしに正しい実行を証明することが目標である場合、ゼロ知識証明はより低いオーバーヘッドの構成を提供する。
機密給与支払いと二者間決済はしきい値FHEのアーキテクチャに適合する。継続的なマーケットにおける注文フローのプライバシーはそうではなく、現行の制約下でこれを実装しようとすれば、信頼されたオペレータか構造的なレイテンシのいずれかを持ち込むことになる。
この論旨が崩れうる箇所
主要な未解決の問いは、暗号技術というよりも運用に関わるものだ。しきい値委員会の構成とガバナンスを文書化することで、復号が複数の法域にまたがるオペレータに依拠しているのか、それとも集中したグループに依拠しているのかが明らかになるだろう。トランザクション送信から読み取り可能な出力までのレイテンシを測定する独立したメインネットのベンチマークは、実際のスループットを明確にするはずだ。OpenZeppelinによるERC-7984実装の監査報告書は、クランプされた送金処理とアクセス制御のセマンティクスが敵対的なシーケンシングの下でも成立するかどうかを裏付けることになるだろう。
経済的な要因も同程度の精査を要する。コプロセッサの計算能力は希少な資源であり、ベースの決済市場の外側で価格付けされる。手数料メカニズムが形式化されるまで、混雑の力学は特徴づけられないままだ。負荷がかかると復号レイテンシが急上昇する機密性レイヤーは、アカウントの残高を一時的に読み取れなくしてしまうリスクを抱える。
導入の指標は、単発の送金量ではなくプロトコルとの統合によって評価すべきだ。既知の当事者間での機密送金は、この規格の基本的な実行パスを示すにすぎず、一般的なコンポーザビリティを示すものではない。注視すべき重要なマイルストーンは、ERC-7984との統合を前提とせずに開発されたレンディングマーケットやAMMのような、改変されていない第三者製のプロトコルが、本番環境で暗号化された残高に対して価格付けと決済を行うことだ。その統合が実証されるまで、暗号化された残高は開かれたDeFiアーキテクチャの中というよりも、限定された多者間ワークフローの内部で主に機能することになる。
引言
一笔 ERC-20 转账会把转移的金额以及双方的最终余额,公开给任何拥有 RPC 端点的人。对于发薪、资金池调仓,或一笔大宗交易而言,这个特性是致命的,标准的应对办法一直是把交易放到链下处理,只把净额结果结算上链。
Zama 的 Confidential Blockchain Protocol 提出了另一种安排。根据其 litepaper,这是一个跨链的机密性层,架在现有的公共区块链之上,而不是新的 L1 或 L2。它结合了用于对加密数值进行计算的全同态加密(FHE)、用于门限密钥管理的多方计算(MPC),以及零知识证明——但零知识证明的用途很窄,仅用于验证用户输入是否被正确加密。litepaper 给出的路线图是:测试网在 litepaper 发布之前已经上线,以太坊主网在 2025 年底上线,其他 EVM 链在 2026 年上半年上线,Solana 在 2026 年下半年上线。Zama 自己针对机密代币标准 ERC-7984 的说明文档标注日期为 2026 年 2 月 17 日,称该标准是技术无关的,而其 FHE 实现是与 OpenZeppelin 联合开发的。
市场评论中围绕这次发布流传的几个数字,并没有出现在一手文档里:目前约每秒 20 笔交易的吞吐量,GPU 部署后 500 至 1000 TPS 的目标,以机密 USDC 计价的部署规模,一笔具名的机构 OTC 交易,$ZAMA 代币事件的机制与日期,以及 OpenZeppelin 的 ERC-7984 实现的审计状态。我们无法在 Zama 的 litepaper、其 ERC-7984 说明文档,或 Fhenix 与 Inco 的文档中核实这些数字。它们仍未得到证实,以下分析只依据供应商文档中确实写明的内容展开。
这套技术栈中,密码学部分是成熟的。真正承重的是三条接缝:链上合约记录的内容与链下协处理器网络计算的内容之间的差距;加密数值变为明文所经过的异步路径;以及集体持有解密密钥的节点委员会。
谁也看不见的运算,代价是什么
全同态加密允许一方仅持有密文就能对其计算某个函数,产生结果的密文,而不必获知输入或输出。应用到代币上,对两个加密余额做加法,得到一个加密的新余额,执行加法的机器对两个操作数都一无所知。
这里的开销是结构性的。基于格的 FHE 方案中,密文远大于其隐藏的明文,而且每一次同态运算都会给密文增加噪声。噪声超过某个阈值就会破坏数值,所以这些方案需要定期执行降噪步骤,而这一步恰恰是整个计算中开销最大的部分。Zama 宣称其实现比五年前快 100 倍以上,并具备后量子安全性——后者源于这些方案所依赖的格假设。这两个说法都来自厂商自己发布的文档,没有独立的基准测试佐证。
对合约开发者而言,更实质的限制是控制流。程序不能根据加密条件分支,因为选择走哪个分支这件事本身就会泄露信息——观察 gas 消耗或状态访问模式的人能借此推断出本该被加密隐藏的比较结果。因此条件判断必须变成算术运算:两种结果都被计算出来,再用一个加密的选择位在两者间做多路复用。一次机密转账的开销,无论发送者余额是否充足都是一样的,而且无论哪种情况都会产生状态变更。
这一个特性贯穿整个设计。它决定了 ERC-7984 如何处理失败的转账,决定了为什么清算逻辑表达起来很别扭,也决定了为什么机密执行和明文执行之间的成本差距是倍数级的,而不是边际的。Fhenix 的 CoFHE 文档在其 API 层面呈现出同样的形态:加密类型如 euint32、ebool,操作如 FHE.add、FHE.sub,以及显式的访问控制调用如 FHE.allowThis、FHE.allowSender,后者决定谁之后能解密某个数值。在这些系统中,解密权限不是默认存在的,而是必须由合约显式授予的;如果遗漏了授予,该数值就会永久不可读。
句柄、协处理器与一个网关
Zama 的 ERC-7984 说明文档描述了一个四部分的架构,工程风险恰恰集中在各部分之间的分工上。
链上合约存储的是加密的句柄(handle),它们是指向加密数值的指针,而不是密文本身。当一个机密代币合约把两个加密余额相加时,以太坊上的交易本身并不执行格运算,它只是记录下”这三个句柄之间需要执行一次加法”,并立即返回输出句柄。合约的存储和交易的 gas 成本反映的是对句柄的记账,而不是密码学运算本身的成本。
真正的 FHE 运算发生在链下,由一个协处理器网络消费这些被记录下来的运算,并生成对应的密文。一个网关(Gateway)负责协调这些协处理器,执行谁能读取哪个句柄的访问控制,并转发解密请求。解密本身由一套门限密钥管理系统执行,需要多个独立节点协作完成,这样单一运营方就无法单方面恢复用户的余额。
由此直接产生两个特性。第一,链上结算的完成速度快于其背后加密计算的完成速度。一笔转账在句柄记账被打入区块时就算确认了,但该句柄所指向的密文只有在协处理器生成之后才真正存在。因此在负载压力下,自然的失效模式就是积压:符号状态以以太坊的速度前进,而实际的密文生成却跟不上,这个延迟会在有人请求读取某个数值时暴露出来。任何需要明文答案的操作——包括用户查看余额,或合约等待解密回调——都会继承这个队列。
第二,ZK 组件在这里承担的工作远比在屏蔽池(shielded pool)中少。零知识证明在这里用来证明用户提交的输入被正确加密并且绑定到提交者,而不是用来证明某次状态转换被正确执行了。一个格式错误或被恶意构造的密文如果被系统接受,可能破坏下游计算,或者成为探测网络密钥的通道,所以这个证明起到的是输入过滤器的作用。而在一个 zk-SNARK 屏蔽池里,证明承载了整套正确性论证,第三方永远不会对加密状态本身进行计算。这是两种不同的安全架构,只是碰巧共用了同一个缩写。
Zama 声称现有链不需要协议层升级就能支持这套安排。这个说法范围很窄,而且在架构上是合理的:执行发生在合约代码里,或者发生在链下。但这并不能说明现有应用能否消费由此产生的状态。
ERC-7984 在合约层面改变了什么
在代码层面,这个标准本质上是一次类型替换,但带来了连锁后果。ERC-20 暴露的是 uint256、transfer、balanceOf,ERC-7984 暴露的是 euint64、confidentialTransfer、confidentialBalanceOf。逻辑操作保留下来,但操作数变成了加密句柄,连合约本身也读不了。
从 256 位收窄到 64 位不是表面上的调整。FHE 的成本随加密整数的位宽增长,所以机密代币要为每一个未被用到的取值范围位直接付出代价。一个 64 位的余额无法表示任意规模的 18 位小数供应量,这迫使机密代币走向更少的小数位和比其明文对应物更小的最大供应量。任何把现有 18 位小数 ERC-20 打包成机密表示形式的封装合约,都必须定义一套缩放规则,并接受由此引入的舍入误差。
余额不足的处理是第二个结构性变化,它直接源于”不能分支”这一限制。普通的 ERC-20 在发送者资金不足时会 revert,而这个 revert 本身就是公开信息。机密转账不能在一个加密比较的基础上 revert,否则会向观察者泄露比较结果。设计上的做法是计算一个加密的”实际转账金额”:资金充足时等于请求金额,不充足时等于零,无论哪种情况交易都会成功。调用者只能通过解密返回值才能知道实际发生了什么——前提是他们持有解密权限。任何把”交易成功”当作”转账已完成”证明的集成逻辑,都需要重新审视。
作为合约功能的选择性披露
Zama 的实现通过观察者(Observers)来满足合规要求——观察者可以是审计方或监管方之类的地址,可被授予对指定数值的解密权限,此外还配有可选的扩展模块,用于 KYC/AML 检查、余额冻结,以及针对真实世界资产(RWA)的合规规则。披露是一种权限授予行为,而不是默认状态,由网关的访问控制来执行,而不是由运营方自行裁量。
这个设计是整个机构级方案提案的核心所在,同时也是公开细节最少的部分。观察者的授权是否可撤销、是否适用于授权之前就已存在的句柄(即是否有追溯效力),以及谁能代表用户发出这样的授权——这些治理问题,现有文档并未给出答案。冻结模块尤其重新引入了一个特权角色,而这与整个系统”没有任何特权角色能看到用户状态”的前提有所冲突。原则上这两点是可以兼容的,因为冻结操作可以作用于句柄而不必读取它,但这种兼容性需要在合约代码里得到验证,而不是靠功能说明书来担保。
加密余额与现有 DeFi 的交汇处
“以太坊不需要升级”这个说法,和”Uniswap 或 Aave 能否持有 ERC-7984 代币”是两个不同的说法。后者更难,原因就在上文提到的那些机制里。
一个恒定乘积 AMM 是根据公开的储备量为一次交易定价的。如果储备量是加密的,资金池就无法公布价格,套利者也无法计算价格,而那个保护资金池不被错误定价交易冲击的不变量检查,必须在每次交易时以同态方式计算。借贷市场的问题更尖锐:清算需要第三方验证某个仓位已经资不抵债,这意味着要么健康因子是公开的(这就违背了机密性),要么清算人必须发起解密请求并根据结果行动,把一个原子交易变成一个跨多个区块的”请求-回调”序列,而对手方在这期间完全可以自由转移抵押品。
异步性是普遍的障碍。任何在执行过程中需要一个明文数值的组合逻辑,都无法在单笔交易内完成,因为解密路径要经过网关和门限委员会。围绕单个调用帧内原子结算设计的协议,不能靠简单调参来适应这种情况,它们需要重新设计。
这就把近期可组合的应用范围收窄到那些机密性是首要需求、且天然能容忍延迟的场景:发薪场景中,付款方本来就知道每一笔金额,而第三方不需要为资产定价;交易对手双边共享信息的机构结算;以及密封投标拍卖,这类机制本身就依赖数值在预定揭示之前保持隐藏,等待门限解密在收标时完成本就是结构性的。Inco 为其 Lightning 产品做的宣传列出了一组类似的场景,包括盲拍、货币市场、货银对付(DvP)托管以及代币归属计划,并宣称支持机密 ERC20 和 SPL,“不破坏可组合性”。这个说法需要用同样的标准去检验:不是问基础链能不能接受这个代币,而是问一个未经修改的第三方协议能不能对它进行定价和清算。
吞吐量天花板,以及它排除了什么
Zama 的 litepaper 把扩容分成三个阶段来讲。目前的性能运行在通用处理器上。GPU 被描述为能推动系统迈向”100+ 笔/秒”。专用加速器(FPGA 和 ASIC)预计在一个未指明的未来日期能达到”每秒数千笔交易”。这些都是厂商展望性的目标,没有公开的基线测量数据。
围绕这次发布流传的具体数字——目前约 20 TPS,GPU 阶段 500 到 1000 TPS 的区间——并没有出现在 litepaper 里,也无法得到核实。较高的那个估计比 Zama 公开的 GPU 说法高出五到十倍。厂商给出的数字所暗示的是:GPU 这个里程碑达成后,机密执行的吞吐量大致相当于一个中型 L2 做明文运算的水平,而且这个吞吐量还要被该层上的所有应用共同分摊。
这个天花板对 DeFi 的工作负载做出了清晰的划分。发薪、代币归属,以及周期性的机构结算,每天产生的交易数以百或千计,几秒到几分钟的确认延迟在操作上是可以接受的。密封投标拍卖和 OTC 结算本质上是批处理流程。按照公开的路线图,这些都不会受制于吞吐量。
持续运作的市场面临不同的约束。现货 AMM 交易、永续合约的资金费率更新、由预言机驱动的清算,以及区块内的执行策略,这些都需要吞吐量和有限延迟同时满足,而延迟是那个硬约束。即便吞吐量再高,一个”读取一个数值需要一轮门限解密”的系统也无法支持具有竞争力的清算。如果基于 FHE 的机密性要服务这些市场,大概只能通过隐藏某些具体字段——比如订单规模或抵押品构成——嵌入到一个价格发现仍是公开的系统中来实现。那是一个比”通用机密 DeFi”窄得多的产品。
还有一个尚未被讨论的成本动态。链上用于句柄记账的 gas 很低,而 FHE 计算发生在协处理器上,这需要另外的补偿机制。这笔成本如何计量、由谁承担、定价模型能否在需求高峰时撑住,这些经济学问题在现有文档中都没有说清楚。一个主要计算成本落在结算层费用市场之外的系统,必然要另建一个次级费用市场,而拥堵会集中在那里。Fhenix 的文档给出了一个相关的提示:它的本地模拟环境用把明文存到链上的方式来模拟 FHE,文档里也提到模拟环境的 gas 成本和生产环境不同。评估这些技术栈在主网上线前的基准测试时,应该把这个差距记在心里。
谁持有密钥份额
门限密钥管理系统是这套架构里最接近传统信任假设的组件,而现有资料对它的说明也最少。
Zama 表示解密需要多个独立节点协作,防止任何单一方单方面解密用户数据。文档没有披露节点总数、重建所需的门限值、运营方的准入与移除机制、运营方所在的司法管辖区,也没说密钥能否在不经过明文重建步骤的情况下重新分片。每一个变量都直接影响系统层面的余额安全性。
直接对比能厘清这里的信任权衡。在一条普通的公开 L1 上,不存在解密这一步,也就没有一个委员会可以被攻破或胁迫,代价是完全透明。在基于硬件可信执行环境(TEE)的设计里,机密性取决于处理器厂商的安全执行环境,以及是否存在侧信道漏洞,信任集中在硬件供应链上。在门限方案里,只要串通或被胁迫的节点运营方数量少于门限值,机密性就能保住,信任分散到各个运营方之间,但并没有完全消除托管假设。
这里有两种失效模式,需要分别评估。机密性失效发生在一个达到门限规模的联盟成功重建密钥时,这取决于运营方的司法管辖区分布。活性失效发生在委员会拒绝处理解密请求时。一个余额仍然被加密、但拿不到解密结果的用户,无法证明所有权,也无法通过要求明文数值的合约退出。在机密系统里,审查表现为未被满足的解密请求,而不是被拒绝的交易。
Zama 的 litepaper 里有一张对比表,把自家协议同时打上安全、去中心化、可验证、可组合、可扩展、易用这几项高分,同时把基于 TEE 的方案归为缺乏安全性和可验证性,把其他 FHE、MPC、ZK 系统归为在可扩展性或易用性上有欠缺。这个对比是厂商的立场表态。而底层真实的技术权衡是具体的:硬件信任和门限信任呈现的是不同的失效模式。
把机制匹配到对手模型
各家实现目前的状态在不同供应商之间差异很大。Zama 的 litepaper 把以太坊主网列为 2025 年底的目标,2026 年 2 月发布的 ERC-7984 说明文档讨论了使用场景。Fhenix 的 CoFHE 文档说明支持以太坊 Sepolia、Arbitrum Sepolia 和 Base Sepolia,生产环境的主网支持仍待推出。Inco 把 Lightning 宣传为一个可作为库导入的产品,提供接近原生链的速度,不需要新的虚拟机,同时宣称具备后量子安全性,但没有说明底层依赖的具体机制。接近原生链的延迟与标准 FHE 的开销特征不符,这让人推测其中用到了硬件可信执行环境,不过一手文档并未证实这一点。
| 方案 | 所需信任 | 隐藏的内容 | 硬约束 |
|---|---|---|---|
| FHE + 门限解密 | 串通或被胁迫的密钥份额持有者数量少于门限值 | 计算过程中的输入、中间状态和存储的余额 | 吞吐量与异步解密延迟 |
| 硬件可信执行环境执行 | 处理器厂商的完整性,不存在侧信道 | 在可信执行环境内的输入和状态 | 供应链与侧信道暴露风险;外部可验证性有限 |
| 计算的零知识证明 | 适用时的可信设置,证明系统的健全性 | 证明方选择不披露的一切;持久化的加密状态需要额外机制 | 证明生成成本;第三方无法对隐藏状态进行计算 |
| 普通公开执行 | 除共识机制外无额外信任 | 无 | 完全透明 |
选择哪种方案取决于对手模型,而不是功能列表。如果一个应用必须对用户无法拒绝提供的数据进行计算,并且可以接受秒级延迟,那么 FHE 加门限解密能在较低的吞吐量限制内提供强的密码学隔离性。如果需要接近原生链的延迟,基于可信执行环境的执行是目前活跃的替代方案,代价是接受硬件层面的信任假设。如果目标是证明执行有效,而不需要第三方对状态本身进行计算,零知识证明提供了开销更低的构造方式。
机密发薪和双边结算适合门限 FHE 架构。持续运作市场中的订单流隐私则不适合——在当前的约束条件下实现它,要么引入受信任的运营方,要么带来结构性的延迟。
这套论点可能在哪里崩塌
主要的开放问题是操作层面的,而不是密码学层面的。厘清门限委员会的组成和治理方式,能确定解密到底依赖跨多个法律管辖区的运营方,还是依赖一个集中的小团体。独立的主网基准测试——测量从交易提交到得到可读输出的延迟——能厘清实际的吞吐量水平。针对 OpenZeppelin 的 ERC-7984 实现的审计报告能确认限额转账和访问控制的语义在对抗性排序下是否依然成立。
经济层面的因素同样需要仔细审视。协处理器计算是稀缺资源,而它的定价发生在基础结算市场之外。在费用机制被正式确定之前,拥堵的动态特征仍无法刻画清楚。一个在负载压力下解密延迟会飙升的机密性层,有可能导致账户余额暂时无法读取。
评估采用情况时,应该看协议层面的集成,而不是孤立的转账量。已知交易对手之间的机密转账,只能证明标准的基本执行路径,证明不了通用的可组合性。真正值得关注的关键里程碑,是一个未经修改的第三方协议——比如一个开发时未针对 ERC-7984 做过集成的借贷市场或 AMM——能在生产环境中对一笔加密余额进行定价和结算。在这个集成得到证实之前,加密余额主要还是运行在受限的多方工作流里,而不是开放的 DeFi 架构中。
Introducción
Una transferencia ERC-20 publica el monto movido y los balances resultantes de ambas partes a cualquiera con acceso a un endpoint RPC. Para una nómina, un rebalanceo de tesorería o una operación de bloque, esa propiedad es descalificante, y la solución habitual ha sido mantener la transacción fuera de la cadena, liquidando solo un resultado neto.
El Protocolo de Blockchain Confidencial de Zama propone un arreglo distinto. Según su litepaper, se trata de una capa de confidencialidad cross-chain que se sitúa sobre blockchains públicas existentes en lugar de ser una nueva L1 o L2, combinando cifrado totalmente homomórfico para computar sobre valores cifrados, computación multipartita para la gestión de claves por umbral, y pruebas de conocimiento cero usadas de forma acotada para verificar que las entradas del usuario fueron cifradas correctamente. La hoja de ruta declarada puso el testnet en vivo antes de la publicación del litepaper, la mainnet de Ethereum a fines de 2025, otras cadenas EVM en el primer semestre de 2026, y Solana en el segundo semestre de 2026. La explicación de Zama sobre ERC-7984, el estándar de token confidencial, tiene fecha del 17 de febrero de 2026 y describe el estándar como agnóstico a la tecnología, con la implementación FHE construida en conjunto con OpenZeppelin.
Varias cifras asociadas a este lanzamiento en comentarios de mercado no aparecen en la documentación primaria: un throughput actual de aproximadamente 20 transacciones por segundo, un objetivo de 500 a 1.000 transacciones por segundo tras el despliegue de GPU, volúmenes de despliegue en USDC confidencial, una operación OTC institucional específica, la mecánica y fecha de un evento del token $ZAMA, y el estado de auditoría de la implementación ERC-7984 de OpenZeppelin. No pudimos verificar ninguno de estos datos contra el litepaper de Zama, su explicación de ERC-7984, ni la documentación de Fhenix e Inco. Permanecen sin confirmar, y el análisis razona a partir de lo que declaran los documentos del proveedor.
La criptografía es la parte madura de este stack. Tres costuras cargan el peso en su lugar: la brecha entre lo que registra el contrato onchain y lo que computa una red de coprocesadores offchain, la vía asíncrona por la cual un valor cifrado se convierte en texto plano, y el comité de nodos que en conjunto sostiene la clave de descifrado.
El costo de la aritmética que nadie puede ver
El cifrado totalmente homomórfico permite que una parte que solo posee textos cifrados compute una función sobre ellos, produciendo un texto cifrado del resultado, sin conocer las entradas ni la salida. Aplicado a un token, una suma sobre dos balances cifrados produce un nuevo balance cifrado, y la máquina que ejecuta esa suma no conoce ninguno de los dos operandos.
El sobrecosto es estructural. Los textos cifrados FHE en esquemas basados en retículas son mucho más grandes que los textos planos que ocultan, y cada operación homomórfica añade ruido al texto cifrado. Superado un umbral, el ruido destruye el valor, así que los esquemas ejecutan periódicamente un paso de reducción de ruido que es en sí mismo el costo dominante de la computación. Zama afirma que su implementación es más de 100 veces más rápida que hace cinco años y que es segura post-cuántica, esto último derivado de los supuestos de retículas sobre los que descansan estos esquemas. Ambas son afirmaciones del proveedor provenientes de un documento propio sin benchmark independiente.
La restricción más relevante para quienes escriben contratos es el flujo de control. Un programa no puede ramificarse según una condición cifrada, porque tomar una rama revela cuál rama se tomó, y observadores que miden el consumo de gas o los patrones de acceso al estado descubrirían el resultado de la comparación que el cifrado buscaba ocultar. Los condicionales se convierten entonces en aritmética: se evalúan ambos resultados y un bit selector cifrado multiplexa entre ellos. Una transferencia confidencial cuesta lo mismo si el emisor tiene saldo suficiente o no, y produce una transición de estado en ambos casos.
Esa única propiedad se propaga por todo el diseño. Determina cómo maneja ERC-7984 una transferencia fallida, por qué la lógica de liquidación resulta incómoda de expresar, y por qué la brecha entre el costo de ejecución confidencial y en texto plano es un múltiplo y no un margen. La documentación de CoFHE de Fhenix expone la misma forma en su superficie de API, con tipos cifrados como euint32 y ebool, operaciones como FHE.add y FHE.sub, y llamadas explícitas de control de acceso como FHE.allowThis y FHE.allowSender que gobiernan quién puede descifrar un valor más adelante. El permiso para descifrar no es ambiente en estos sistemas. Es una concesión explícita que un contrato debe ejecutar; omitirla deja un valor permanentemente ilegible.
Handles, coprocesadores y un gateway
La explicación de Zama sobre ERC-7984 describe una arquitectura de cuatro partes, y la división del trabajo entre ellas es donde se concentra el riesgo de ingeniería.
El contrato onchain almacena handles cifrados, que son punteros a valores cifrados y no los textos cifrados en sí. Cuando un contrato de token confidencial suma dos balances cifrados, la transacción de Ethereum no ejecuta aritmética de retículas. Registra que debe realizarse una suma que relaciona tres handles y devuelve inmediatamente el handle de salida. El almacenamiento del contrato y el costo de gas de la transacción reflejan contabilidad sobre handles, no el costo de la criptografía.
La aritmética FHE real ocurre fuera de la cadena, en una red de coprocesadores que consumen las operaciones registradas y materializan los textos cifrados correspondientes. Un Gateway orquesta esos coprocesadores, impone el control de acceso sobre qué dirección puede leer qué handle, y enruta las solicitudes de descifrado. El descifrado en sí lo realiza un sistema de gestión de claves por umbral en el que múltiples nodos independientes deben cooperar, de modo que ningún operador individual pueda recuperar unilateralmente el balance de un usuario.
De esta división se desprenden dos propiedades directamente. Primero, la liquidación onchain finaliza más rápido que la computación cifrada que hay detrás. Una transferencia se confirma cuando la contabilidad de handles queda incluida en un bloque, pero el texto cifrado al que apunta ese handle existe solo una vez que un coprocesador lo ha producido. El modo de falla natural bajo carga es entonces un rezago: el estado simbólico avanza al ritmo de Ethereum mientras la materialización se atrasa, y la demora se manifiesta en el momento en que alguien pide leer un valor. Cualquier cosa que necesite una respuesta en texto plano, incluyendo a un usuario que revisa su balance o un contrato que espera un callback de descifrado, hereda esa cola.
Segundo, el componente ZK hace mucho menos trabajo aquí que en un pool blindado. Las pruebas de conocimiento cero se usan para establecer que una entrada enviada por el usuario fue cifrada correctamente y está vinculada a quien la envía, no para probar que alguna transición de estado se ejecutó correctamente. Un texto cifrado malformado o creado de forma adversarial que sea aceptado en el sistema podría corromper la computación posterior o convertirse en un canal para sondear la clave de la red, así que la prueba funciona como un filtro de entrada. En un pool blindado con zk-SNARK, la prueba lleva todo el argumento de corrección y el estado cifrado nunca es computado por un tercero. Son arquitecturas de seguridad distintas que casualmente comparten una sigla.
Zama afirma que las cadenas existentes no requieren ninguna actualización a nivel de protocolo para soportar este arreglo. Esa afirmación es acotada y arquitectónicamente plausible: la ejecución ocurre ya sea en el código del contrato o fuera de la cadena. No establece si las aplicaciones existentes pueden consumir el estado resultante.
Lo que ERC-7984 cambia dentro del contrato
A nivel de código, el estándar es una sustitución de tipos con consecuencias. Donde ERC-20 expone uint256, transfer y balanceOf, ERC-7984 expone euint64, confidentialTransfer y confidentialBalanceOf. Las operaciones lógicas sobreviven; los operandos se vuelven handles cifrados que el propio contrato no puede leer.
La reducción de 256 bits a 64 no es cosmética. El costo de FHE escala con el ancho de bits del entero cifrado, así que un token confidencial paga directamente por cada bit de rango que no usa. Un balance de 64 bits no puede representar un suministro de 18 decimales de cualquier tamaño, lo que empuja a los tokens confidenciales hacia menos decimales y un suministro máximo menor que sus contrapartes transparentes. Cualquier wrapper que conecte un ERC-20 existente de 18 decimales con una representación confidencial tiene que definir una convención de escala y aceptar el redondeo que introduce.
El manejo de saldo insuficiente es el segundo cambio estructural, y se deriva de la restricción de no ramificación. Un ERC-20 convencional revierte cuando el emisor carece de fondos, y esa reversión es información pública. Una transferencia confidencial no puede revertir sobre una comparación cifrada sin filtrar el resultado de la comparación a los observadores. El diseño computa un monto transferido cifrado que equivale al monto solicitado cuando los fondos son suficientes y a cero cuando no lo son, dejando que la transacción tenga éxito en ambos casos. Quienes llaman al contrato solo se enteran de lo ocurrido al descifrar el valor devuelto, si tienen permiso para hacerlo. Cada integración que trata una transacción exitosa como prueba de una transferencia completada requiere revisión.
Divulgación selectiva como función del contrato
La implementación de Zama aborda los requisitos de cumplimiento mediante Observers, direcciones como auditores o reguladores a quienes se les puede conceder acceso de descifrado sobre valores específicos, junto con módulos de extensión opcionales para verificaciones KYC y AML, congelamiento de balances, y reglas de cumplimiento para activos del mundo real. La divulgación opera como una concesión de permiso más que como valor por defecto, impuesta por el control de acceso del Gateway y no por discreción del operador.
Este diseño representa el núcleo de la propuesta institucional, y también la sección con menos detalle publicado. Si una concesión de Observer es revocable, si aplica prospectiva o retroactivamente a handles creados antes de la concesión, y quién puede emitir una en nombre de un usuario son preguntas de gobernanza que la documentación disponible no resuelve. Un módulo de congelamiento en particular reintroduce a un actor privilegiado en un sistema cuya premisa es que ningún actor privilegiado puede ver el estado del usuario. Esas dos propiedades son compatibles en principio, ya que el congelamiento actúa sobre handles sin leerlos, pero la combinación requiere verificación en el código del contrato y no solo en especificaciones de funciones.
Dónde los balances cifrados se encuentran con el DeFi existente
La afirmación de que Ethereum no necesita una actualización es distinta de la afirmación de que Uniswap o Aave pueden sostener tokens ERC-7984. La segunda afirmación es más difícil, impulsada por los mecanismos detallados arriba.
Un AMM de producto constante fija el precio de un swap a partir de reservas públicas. Si las reservas están cifradas, el pool no puede publicar un precio, los arbitrajistas no pueden calcular uno, y la verificación del invariante que protege al pool de operaciones mal valoradas debe evaluarse de forma homomórfica en cada swap. Un mercado de préstamos tiene un problema más agudo: la liquidación requiere que terceros verifiquen que una posición está en negativo, lo que significa que o el factor de salud es público, anulando la confidencialidad, o los liquidadores deben solicitar el descifrado y actuar según el resultado, convirtiendo una transacción atómica en una secuencia de solicitud y callback de varios bloques, con un adversario libre de mover el colateral en el intermedio.
La asincronía es el obstáculo general. Cualquier composición que requiera un valor en texto plano a mitad de la ejecución no puede completarse dentro de una sola transacción, porque la vía de descifrado pasa por el Gateway y el comité de umbral. Los protocolos diseñados en torno a liquidación atómica dentro de un solo marco de llamada no se adaptan a esto mediante simple parametrización; requieren rediseño.
Esto deja una superficie de composabilidad a corto plazo centrada en aplicaciones donde la confidencialidad es el requisito primario y la tolerancia a la latencia es inherente: nóminas, donde quien paga conoce cada monto y terceros no fijan precio de los activos; liquidación institucional entre contrapartes que comparten información bilateralmente; y subastas de sobre cerrado, donde el mecanismo depende de que los valores permanezcan ocultos hasta una revelación programada, y donde esperar el descifrado por umbral al cierre es estructural. El marketing de Inco para su producto Lightning enumera un conjunto similar, incluyendo subastas ciegas, mercados monetarios, escrow de entrega contra pago, y vesting de tokens, reclamando soporte para ERC20 y SPL confidenciales “sin romper la composabilidad”. Esa afirmación requiere el mismo estándar de evaluación: no si la cadena base acepta el token, sino si un protocolo de terceros sin modificar puede fijar precio y liquidar contra él.
El techo de throughput y lo que excluye
El litepaper de Zama enmarca el escalamiento en tres etapas. El desempeño actual corre sobre procesadores de propósito general. Las GPU se describen como habilitadoras de un avance hacia “100+ transacciones/s”. Los aceleradores dedicados, FPGA y ASIC, se proyectan para alcanzar “miles de transacciones por segundo” en una fecha futura no especificada. Son objetivos prospectivos del proveedor sin una medición base publicada.
Las cifras específicas que circulan en torno a este lanzamiento, aproximadamente 20 transacciones por segundo hoy y un rango de 500 a 1.000 con GPU, no aparecen en el litepaper y no pudieron verificarse. La estimación más alta supera el lenguaje publicado por Zama sobre GPU por un factor de cinco a diez. Lo que implican las cifras del proveedor es que el hito de GPU coloca la ejecución confidencial en un throughput comparable al de una sola L2 de tamaño mediano haciendo trabajo en texto plano, compartido entre todas las aplicaciones de la capa.
Ese techo ordena claramente las cargas de trabajo de DeFi. Nóminas, vesting y liquidación institucional periódica generan cantidades de transacciones medidas en cientos o miles por día, donde una latencia de confirmación de segundos a minutos es operativamente manejable. Las subastas de sobre cerrado y la liquidación OTC operan como procesos por lotes. Ninguno de estos casos está limitado por throughput según la hoja de ruta publicada.
Los mercados continuos enfrentan restricciones distintas. El trading spot en AMM, las actualizaciones de tasa de financiación en perpetuos, las liquidaciones impulsadas por oráculos, y las estrategias de ejecución intrabloque requieren tanto throughput como latencia acotada, siendo la latencia la restricción vinculante. Incluso con mayores throughputs, un sistema en el que leer un valor requiere una ronda de descifrado por umbral no puede soportar liquidación competitiva. Si la confidencialidad basada en FHE sirve a esos mercados, lo hará ocultando campos específicos, como los tamaños de las órdenes o la composición del colateral, dentro de sistemas con formación de precios pública. Ese es un producto más acotado que el DeFi confidencial general.
También hay una dinámica de costos sin abordar. El gas onchain para la contabilidad de handles es bajo; la computación FHE ocurre en coprocesadores que requieren compensación. Cómo se mide ese costo, quién lo asume, y si el modelo de precios resiste picos de demanda son cuestiones económicas no establecidas en la documentación disponible. Un sistema cuyo costo computacional principal se sitúa fuera del mercado de comisiones de la capa de liquidación debe establecer un mercado de comisiones secundario donde se concentrará la congestión. La documentación de Fhenix ofrece una nota relevante: su entorno mock local simula FHE almacenando texto plano onchain, y la documentación indica que los costos de gas mock difieren de los de producción. Los benchmarks previos a mainnet de estos stacks deben evaluarse teniendo en cuenta esa brecha.
Quién sostiene las porciones de clave
El sistema de gestión de claves por umbral es el componente de esta arquitectura que más se asemeja a un supuesto de confianza convencional, y las fuentes disponibles ofrecen la especificación más escasa sobre él.
Zama afirma que el descifrado requiere que múltiples nodos independientes cooperen, impidiendo que una sola parte descifre unilateralmente los datos del usuario. La documentación no divulga el número total de nodos, el umbral de reconstrucción, la mecánica de selección y remoción de operadores, las jurisdicciones de los operadores, ni si la clave puede resegmentarse sin un paso de reconstrucción en texto plano. Cada una de estas variables afecta directamente la seguridad de los balances a nivel de sistema.
La comparación directa aclara las contrapartidas de confianza. En una L1 pública sencilla no hay paso de descifrado, así que no hay comité que comprometer o coaccionar; la contrapartida es la transparencia total. En un diseño de enclave de hardware, la confidencialidad depende del entorno de ejecución segura del fabricante del procesador y de la ausencia de vulnerabilidades de canal lateral, concentrando la confianza en la cadena de suministro de hardware. En un esquema de umbral, la confidencialidad se mantiene mientras menos del número umbral de operadores de nodos colude o es coaccionado, distribuyendo la confianza entre operadores sin eliminar por completo los supuestos de custodia.
Dos modos de falla requieren evaluación distinta. La confidencialidad falla si una coalición del tamaño del umbral reconstruye la clave, lo cual depende de la distribución jurisdiccional. La disponibilidad falla si el comité se niega a procesar solicitudes de descifrado. Un usuario cuyo balance permanece cifrado pero que no puede obtener un descifrado no puede probar la titularidad ni salir mediante contratos que requieren valores en texto plano. La censura en un sistema confidencial toma la forma de solicitudes de descifrado no atendidas más que de transacciones rechazadas.
El litepaper de Zama incluye una tabla comparativa que califica a su protocolo como simultáneamente seguro, descentralizado, verificable, componible, escalable y fácil de usar, mientras clasifica los enfoques basados en TEE como deficientes en seguridad y verificabilidad, y otros sistemas de FHE, MPC y ZK como deficientes en escalabilidad o usabilidad. Esa comparación representa el posicionamiento del proveedor. La contrapartida técnica subyacente sigue siendo concreta: la confianza en hardware y la confianza por umbral presentan modos de falla distintos.
Ajustar el mecanismo al adversario
El estado actual de las implementaciones sigue siendo dispar entre proveedores. El litepaper de Zama enumera la mainnet de Ethereum como objetivo para fines de 2025, con una explicación de ERC-7984 publicada en febrero de 2026 discutiendo casos de uso. La documentación de CoFHE de Fhenix especifica soporte para Ethereum Sepolia, Arbitrum Sepolia y Base Sepolia, con el soporte de mainnet en producción pendiente. Inco comercializa Lightning como una librería importable que ofrece velocidad nativa de la cadena sin una nueva VM, mientras reclama seguridad post-cuántica sin nombrar el mecanismo subyacente. Una latencia casi nativa es inconsistente con los perfiles estándar de sobrecosto de FHE, lo que lleva a suponer que se usan enclaves de hardware, aunque la documentación primaria no lo confirma.
| Enfoque | Confianza requerida | Qué permanece oculto | Restricción vinculante |
|---|---|---|---|
| FHE con descifrado por umbral | Que menos del número umbral de titulares de porciones de clave colude o es coaccionado | Entradas, estado intermedio y balances almacenados, durante la computación | Throughput y latencia del descifrado asíncrono |
| Ejecución en enclave de hardware | Integridad del fabricante del procesador, ausencia de canales laterales | Entradas y estado, mientras están dentro del enclave | Exposición de cadena de suministro y canal lateral; verificabilidad externa limitada |
| Prueba ZK de computación | Configuración confiable donde aplique, solidez del sistema de pruebas | Lo que el probador decida no revelar; requiere maquinaria separada para estado cifrado persistente | Costo de generar la prueba; ningún tercero puede computar sobre el estado oculto |
| Ejecución pública plana | Ninguna más allá del consenso | Nada | Transparencia total |
Elegir un enfoque depende del modelo de amenaza y no de una lista de funciones. Donde una aplicación debe computar sobre datos que el usuario no puede retener, y donde una latencia del orden de segundos es aceptable, FHE con descifrado por umbral ofrece un fuerte aislamiento criptográfico dentro de límites de throughput bajo. Donde se requiere latencia nativa de la cadena base, la ejecución basada en enclaves es la alternativa activa, aceptando supuestos de confianza a nivel de hardware. Donde el objetivo es probar la ejecución válida sin que terceros computen el estado, las pruebas de conocimiento cero ofrecen una construcción de menor sobrecosto.
La nómina confidencial y la liquidación bilateral encajan con arquitecturas de FHE por umbral. La privacidad del flujo de órdenes en mercados continuos no encaja, ya que implementarla bajo las restricciones actuales introduce operadores confiables o latencia estructural.
Dónde puede romperse la tesis
Las preguntas abiertas principales son operativas más que criptográficas. Documentar la composición y gobernanza del comité de umbral establecerá si el descifrado depende de operadores repartidos en múltiples jurisdicciones legales o de un grupo concentrado. Benchmarks independientes en mainnet que midan la latencia desde el envío de la transacción hasta la obtención de un resultado legible aclararán el throughput práctico. Un informe de auditoría de la implementación ERC-7984 de OpenZeppelin confirmaría si la semántica de transferencia acotada y de control de acceso se sostiene bajo secuenciación adversarial.
Los factores económicos requieren igual escrutinio. La computación de coprocesadores representa el recurso escaso y se fija fuera del mercado base de liquidación. Hasta que se formalicen los mecanismos de comisiones, la dinámica de congestión permanece sin caracterizar. Una capa de confidencialidad donde la latencia de descifrado se dispara bajo carga corre el riesgo de dejar los balances de cuenta temporalmente ilegibles.
Las métricas de adopción deben evaluarse por integraciones de protocolo más que por volúmenes de transferencia aislados. Las transferencias confidenciales entre contrapartes conocidas demuestran la vía de ejecución básica del estándar más que una composabilidad general. El hito crítico a monitorear es que un protocolo de terceros sin modificar, como un mercado de préstamos o un AMM desarrollado sin integración con ERC-7984, fije precio y liquide contra un balance cifrado en producción. Hasta que se demuestre esa integración, los balances cifrados operan principalmente dentro de flujos de trabajo multipartitos acotados y no dentro de arquitecturas de DeFi abiertas.
Read next다음으로 읽기次に読む继续阅读Leer a continuación
수수료 스위치 시대: Uniswap, Aave, 그리고 바이백 설계
유니스왑의 수수료 스위치와 아베의 자동 바이백은 프로토콜 가치 포착을 하나의 템플릿으로 만들었다. 이 메커니즘들이 실제로 무엇을, 누구로부터 가져가는지 살펴본다.
예측 시장에서 진실은 누가 결정하는가
폴리마켓이 UMIP-189에 따라 UMA 오라클에 제안자 화이트리스트를 추가했다. 리졸루션 실패 모드의 분류 체계와 각 유형에서 살아남는 오라클 설계는 무엇인가.
FTX 이후 등장한 파이프라인, 대차대조표를 키우다
거래소 밖 결제(off-exchange settlement)는 FTX식 실패 유형 하나를 제거했지만 나머지는 그대로 남겨두었다. ClearLoop, Interchange, BitGo의 거래상대방 리스크를 짚어본다.
Follow the next market structure breakdown 다음 시장 구조 분석 받기 次の市場構造分析をフォロー 关注下一篇市场结构分析 Sigue el próximo análisis de estructura de mercado
New Steadyrain research is published several times a week across DeFi risk, BTCFi, stablecoins, and RWA. Steadyrain은 DeFi 리스크, BTCFi, 스테이블코인, RWA 분석을 매주 여러 차례 발행합니다. SteadyrainはDeFiリスク、BTCFi、ステーブルコイン、RWAの分析を毎週公開しています。 Steadyrain 每周发布 DeFi 风险、BTCFi、稳定币和 RWA 研究。 Steadyrain publica análisis sobre riesgo DeFi, BTCFi, stablecoins y RWA varias veces por semana.