Introduction
A depositor who locks BTC behind Citrea’s bridge is not asking a signing committee to hand it back. The custody question has been replaced by a vigilance question: will at least one member of a permissioned watchtower set be running, funded, and correct at the moment an operator submits a false claim? On 27 January 2026 that substitution went into production. Citrea announced mainnet live, positioned around lending, trading, and settlement, with Clementine as its native bridge and BitVM2 as the mechanism underneath. A day later GOAT Network opened a public Testnet V3 on the same primitive, emphasizing permissionless exit.
The distinction matters because the two questions fail differently. A federation fails when enough of its members decide to steal, or when enough of their keys are taken. A dispute game fails when nobody shows up. The first is a coordination problem for attackers. The second is an uptime problem for defenders, and uptime degrades for reasons that have nothing to do with malice: fee spikes, monitoring outages, misconfigured software, or an operator data feed going stale during the window when it mattered.
What is live at Citrea is Clementine v1, and the trust-minimization claims worth taking seriously are the ones that apply to v1 specifically. Clementine v1 uses BitVM2 script-based disputes, requires operators to lock collateral, and requires operators to pre-fund user withdrawals from their own balance sheets before being reimbursed. The more efficient constructions circulating in Bitcoin research, including Citrea’s own Clementine v2 design built on garbled circuits and TOOP, are explicitly research-stage. Citrea describes v2 as the first upgrade planned after mainnet launch. It is not what today’s depositors are relying on.
Our reading is that Clementine v1 is a genuine reduction in trust relative to every widely-used BTC bridge that preceded it, and that the reduction is narrower than the phrase “trust-minimized” suggests. It converts a discretionary custody assumption into a liveness assumption over a permissioned set. Liveness assumptions are auditable in a way custody assumptions are not, which is progress. They are also continuously consumable: the assumption has to hold every day, in every challenge window, under whatever the Bitcoin fee market happens to be doing.
What Bitcoin adjudicates, and what it never executes
Bitcoin script cannot loop, cannot hold state between transactions, and cannot constrain how its own outputs are spent, because covenant opcodes such as CheckTemplateVerify and CheckSigFromStack are not active on mainnet. A SNARK verifier expressed directly in Bitcoin script is far too large to fit in a block. Anything resembling a rollup bridge therefore cannot be built by asking Bitcoin to check a validity proof.
BitVM2 works around this by never asking Bitcoin to check anything, unless someone objects. An operator makes a claim about off-chain computation, typically that a particular Citrea state is valid and that a particular set of peg-outs follows from it. The claim is published on Bitcoin as an assert transaction that commits to the intermediate values of a verifier’s execution. If the claim is honest, nothing else happens and the operator eventually spends a presigned reimbursement path. If the claim is dishonest, a challenger identifies the single step where the operator’s committed intermediate values are inconsistent and spends a disprove path that executes only that step in script. Bitcoin adjudicates one contested fragment of a computation it never ran.
The absence of covenants shapes the entire construction. Because Bitcoin cannot enforce “this output may only be spent by a transaction of the following shape,” BitVM2 designs enforce it socially at setup time instead. Every participant signs every branch of a transaction graph in advance, and the unsigned branches simply do not exist as spendable options. The security of the graph therefore rests on the setup ceremony: the correct set of signatures over the correct set of transactions, with signing keys for unwanted variants never produced. This is a very different failure surface from a smart contract, and it is the source of the audit-complexity concern that the House of ZK analysis flags as one of three hard constraints on BitVM2-style designs in production, alongside dispute economics and operational liveness.
Two properties follow. First, the participant set is fixed when the graph is signed. Adding or rotating an operator is not a governance transaction but a new ceremony. Second, the cost of an honest path is small and the cost of a contested path is large, because the disprove branch has to carry enough data for Bitcoin to re-execute the contested step. In BitVM2 as originally specified, that disprove transaction runs to roughly 4MB, which is a full block of Bitcoin capacity spent on a single argument. The efficiency work described below is aimed almost entirely at that number.
One honest party, permanently on call
The 1-of-N framing is accurate and incomplete. Written out operationally, the assumption is that at least one participant among N simultaneously satisfies all of the following at the moment of an attack: it is honest; it is running infrastructure that observes both Bitcoin and Citrea closely enough to detect an inconsistent claim; it holds or can reconstruct the setup data needed to build a disprove witness; it can pay the Bitcoin fees required to get a large transaction confirmed; and it does all of this inside a protocol-defined challenge window whose duration is fixed in advance.
Each conjunct is a separate way to fail. An honest participant with a stale node fails. An honest, well-monitored participant that cannot get a multi-megabyte transaction into a block during a fee spike fails. A participant that is honest, awake, and funded but discovers the fraud one block after the window closes fails. The House of ZK analysis puts this plainly: the 1-of-N honest challenger assumption is really an uptime and monitoring requirement. Nothing in the cryptography compensates for an empty watchtower.
Collusion degrades the model in a specific pattern. With N-1 participants colluding, safety is intact in principle, because a single honest challenger can still disprove. In practice the marginal value of that last honest participant is now the entire bridge reserve, which changes the attacker’s calculus from “steal” to “identify and neutralize one specific counterparty.” Neutralizing does not require compromising them cryptographically. It requires making them miss a window, which is a much lower bar. If all operators and all watchtowers collude, the sources available to us do not describe any recourse, and we treat that scenario as functionally equivalent to a federation compromise.
Permissioning is what makes this analysis uncomfortable. Citrea describes Clementine’s network as permissioned, and it is the permissioning that makes the v2 garbled-circuit construction feasible at all, since a dedicated circuit can be prepared between each operator and each watchtower only if both sets are known in advance. A known, bounded, enumerable set of challengers is a set that can be approached, pressured, or jointly regulated. The sources we reviewed do not specify how watchtowers are selected, who may add or remove them, how many exist at mainnet, or how long the challenge windows run. Those parameters determine whether 1-of-N is a strong claim or a decorative one, and they are not public in the material available to us.
There is also a griefing dimension that optimistic protocols in general have to price. If challenging is free, an adversary can force operators to publish expensive assert transactions repeatedly and drain them through fees alone. Designs in this family typically require the challenger to post something at challenge time to make that attack costly. Whatever Clementine’s specific parameters are, the tension is structural: raising the cost of a frivolous challenge also raises the cost of a legitimate one, and it is legitimate challenges that the entire security argument depends on.
Clementine v1: collateral, float, and a global stop button
Two requirements define what is actually running. Per Citrea’s own description, Clementine v1 requires operators to lock large collateral to make malice costly, and requires operators to pre-pay withdrawals to users upfront and collect reimbursement afterward.
The second requirement produces an underappreciated property of the user experience. When someone exits Citrea, an operator sends them BTC from its own balance immediately. The dispute game that follows is not about the user’s payout. It is about whether that operator is entitled to reimburse itself from the bridge reserve. The user is made whole first and the adjudication happens behind them. The party exposed to the outcome of the dispute is the reserve, which is to say the remaining holders of the pegged asset, not the individual who withdrew.
That structure has a capital consequence. An operator must simultaneously post bonded collateral and carry enough free BTC to front withdrawal demand. Both are idle capital, and the yield an operator earns has to cover both. Citrea itself identifies these as constraints that limited scalability and decentralized participation, which is the stated motivation for the v2 research. The economics push toward a small number of well-capitalized operators, and a small operator set is a small N. The capital requirements that exist to secure the bridge also compress the diversity of the set whose diversity is the security argument. That tension is not resolved by anything currently deployed.
Clementine’s round-based structure is the third element worth understanding. Operators progress through rounds, and detected fraud in one round halts progression and blocks the next round from opening. Citrea describes this as a circuit breaker, and its immediate purpose in the v2 design is efficiency: it means a garbled circuit can be established once at setup rather than regenerated per deposit, because a cheating operator cannot simply proceed to the next opportunity. The security implication runs further. A successful disprove is not a localized slash against one bad claim. It stops the machine. Safety is preserved by halting, which means the recovery path after a genuine fraud event is a governance and ceremony problem rather than an automatic one, and none of the available sources describe what that path looks like.
Garbling the verifier
The dominant cost in BitVM2 is the disprove transaction, and the dominant cost in the disprove transaction is that Bitcoin has to re-execute a contested step in script. Clementine v2 proposes removing script execution from the dispute entirely.
The construction compiles a Groth16 SNARK verifier into a boolean circuit of AND and XOR gates, then garbles it. Garbling encrypts each gate’s truth table so that the evaluator can decrypt exactly one output label per gate and learns nothing else. The verifier is evaluated off-chain by the challenger, who ends up holding an output preimage that exists only if the operator’s claim was false. Bitcoin then checks a hash of that preimage. The disprove transaction becomes a single hashing script. Citrea reports this as approximately a 100,000x improvement over the previous ~4MB BitVM2 disprove transaction, and reports the assert transaction shrinking from 1.3MB to 80kB, stated elsewhere as roughly 20k vbytes. These are the team’s own figures for a design that has not shipped, and no third-party benchmark of them appears in the material we reviewed.
Citrea credits Jeremy Rubin’s Delbrag paper for the underlying idea of using garbled circuits for cheaper Bitcoin fraud proofs, and notes the tradeoff Delbrag identifies: less on-chain data, more out-of-band exchange between participants. That tradeoff has a governance shape. A garbled circuit is designated-verifier by construction. The party who garbles prepares it for a specific evaluator, so Clementine’s design establishes a dedicated circuit between each operator and each watchtower, producing a graph of operator-by-watchtower setups. Citrea says this reduces the model to a simple 1-of-N honest assumption among watchtowers.
It also narrows who can dispute. In script-based BitVM2, the disprove path is executable by anyone who can construct the witness, because Bitcoin itself checks the contested computation and the check is universally verifiable. Under garbling, only a party holding a pre-established circuit with that specific operator can produce the preimage. Cheaper disputes are purchased with a more explicitly enumerated challenger set. Whether that is a net loss depends entirely on whether the 4MB script path was ever realistically executable by an unaffiliated outsider during a fee spike, and the honest answer is that it probably was not. The v2 design may be formalizing a permissioning that already existed economically.
Two caveats sit on this section. First, proving that the garbled circuit was constructed correctly currently takes approximately 14 days according to Citrea, which the team states it is working to reduce. A setup step measured in weeks constrains how often the participant set can change. Second, the topic that prompted this analysis attributes to BitVM3 a roughly 1,000x reduction in worst-case dispute cost, to around five dollars. The BitVM3 paper we retrieved could not be parsed into readable text, and we are not restating those figures as sourced. The direction is well attested by Citrea’s own numbers and by the House of ZK summary of parallel efforts, including Alpen’s Glock, which that source characterizes as claiming hundreds-of-x efficiency gains over BitVM2 using garbled locks and a designated-verifier SNARK, and Ideal’s Argo pursuing similar cost reductions. A dollar figure for a dispute is in any case a statement about a fee environment rather than a protocol property. The relevant question is what the disprove costs relative to block capacity during the congestion an attacker would deliberately induce.
TOOP and the float problem
Garbled circuits attack dispute cost. They do nothing about the operator’s requirement to front liquidity, which is a separate problem with a separate proposed fix.
TOOP, built by Fairgate Labs, restructures reimbursement so that operators do not have to pay users first. At setup, operators pre-sign reimbursement transactions covering every subset of the operator set. At withdrawal time, operators encrypt and send private keys to the user, who selects a subset of signers and assembles the payout themselves. The operator’s role shifts from advancing capital to authorizing a claim on capital that is already locked.
Pre-signing for every subset is combinatorially expensive, and while the sources do not state the resulting bound, the scaling implies a hard practical ceiling on operator-set size. That is a constraint on N from a mechanism intended to make participation easier, and it deserves scrutiny as the design matures. TOOP’s independent maturity is also unknown to us. We found no audit or deployment of it outside the Clementine context.
Taken together, v2 aims at both capital requirements at once: garbled circuits reduce what an operator must post to make dishonesty punishable, and TOOP reduces what an operator must hold to make withdrawals fast. If both work as described, the operator role becomes cheap enough that N can be larger and more varied, which is the only path by which 1-of-N becomes a stronger assumption rather than a differently-shaped one. That is the argument to test when v2 ships, not the transaction-size numbers.
Where Clementine sits against older bridge designs
The useful axis for comparing bridge designs is not throughput or supported chains. It is which party must behave correctly for the backing to remain intact, and which party must be present for a withdrawal to complete. Those are often different parties, and conflating them is how bridges get described as safer than they are. The table below is our synthesis, not a sourced benchmark.
| Design | Who must be honest for funds to stay backed | Who must be present for exit | Failure signature |
|---|---|---|---|
| Custodial wrapped BTC | The custodian | The custodian | Reserve is spent or frozen; holders discover it from an off-chain disclosure |
| Federated peg (n-of-m) | Any n of m signers acting together | The same n signers | A quorum signs an unauthorized spend, or fewer than n remain reachable and the peg stops |
| Off-chain attestation bridge | The oracle and relayer set attesting to remote events | The same set | Destination chain mints against an event that never occurred; the destination cannot detect it because verification was delegated |
| BitVM2 bridge (Clementine v1) | No specific party, provided one honest challenger acts in time | An operator with collateral and float, plus a live challenger set | A false claim finalizes because no challenger disputed within the window |
The structural change in the bottom row is that no named party can unilaterally authorize a spend. Bitcoin enforces the outcome of the dispute, and the presigned graph forecloses every branch that was not signed at setup. That is exactly the property the House of ZK analysis uses to separate real Bitcoin L2s from sidechains: a system earns the label only if a user can exit under Bitcoin’s consensus rules even when operators and committees are offline, malicious, or uncooperative.
The change also relocates the failure rather than eliminating it. A federation’s failure requires an active decision by a quorum. A dispute game’s failure requires an absence. Absences do not need to be organized, they do not leave a trail of coordination, and they correlate with exactly the conditions an attacker can manufacture, namely fee congestion and infrastructure stress. The comparison favors BitVM2 on any reasonable weighting, and it favors it less than the phrase “no trusted party” implies.
One more asymmetry deserves attention. Under a federated peg, bonded collateral has to be large relative to the reserve, because a colluding quorum’s payoff is the reserve and their cost is the bond. Under BitVM2 the payoff structure differs: a disproved operator does not steal and get punished, it fails to steal and gets punished, because the disprove path prevents the reimbursement from being taken at all. Collateral is therefore priced against griefing and operational misbehavior rather than against the full value of the reserve. The loss function is discontinuous. If one honest watchtower acts, the loss is roughly zero. If none do, the loss is bounded by whatever the graph allows an operator to claim. Everything depends on which side of that discontinuity the system lands on, and nothing about collateral sizing moves the boundary.
Presigned graphs, absent covenants
Every structural constraint discussed above traces back to the same missing primitive. Because Bitcoin cannot express “this output may only be spent by a transaction matching this template,” Clementine has to approximate covenants by pre-signing. The consequences compound: the participant set is fixed at ceremony time, rotation requires a fresh ceremony, the number of presigned artifacts grows with rounds and with subset combinations under TOOP, and the security of the whole arrangement depends on ceremony hygiene that no on-chain observer can verify after the fact.
CheckTemplateVerify would let an output commit directly to the hash of its permitted spending transaction, so the constraint would be enforced by consensus instead of by the completeness of a signature set. CheckSigFromStack would allow script to verify signatures over arbitrary messages, which opens delegation and attestation patterns that currently have to be baked into presigned branches. Neither is active, and none of the sources we reviewed discuss how Clementine’s specific constructions would be simplified if they were. What we can say is that the parts of the design that scale worst, the ceremony duration, the subset presigning, and the rigidity of the participant set, are exactly the parts that exist because presigning is standing in for consensus enforcement. If covenants activate, the interesting question is not whether disputes get cheaper but whether N can become fluid.
The shape of a failure
Four distinct failure modes are worth separating, because they have different probabilities and different victims.
A liveness failure is the base case the design explicitly accepts. An operator claims falsely, no challenger disputes in time, and the reimbursement finalizes. The reserve is short by the claimed amount. Users who already exited keep their BTC. The shortfall lands on remaining holders of the pegged asset, presumably as a fractional reserve, though no source we reviewed describes how such a shortfall would be allocated or whether any backstop exists.
A dispute-economics failure is a liveness failure with a cause. If Bitcoin fees rise enough that a multi-megabyte disprove transaction cannot be confirmed inside the window, honest and attentive challengers are priced out. The garbled-circuit work targets this directly and, if it ships, largely removes it as an independent risk. Until it does, the live system carries it.
A full-collusion failure returns the system to federated-peg semantics. The sources do not describe recourse, and we do not assume any exists.
A construction failure is the one the 1-of-N framing does not address at all. If the transaction graph is signed incorrectly, or a branch that should not have existed does exist, or the ceremony leaked a key, then the honest watchtower has nothing to disprove because the theft is a valid spend. This is the audit-complexity constraint, and it is not a smart contract audit. It is a review of an entire presigned transaction-graph protocol stack. We found no published independent security assessment of Clementine v1 as deployed, separate from the team’s own design writeups.
The parameters that would let an outsider price these risks are not public in what we reviewed: the number of watchtowers, the selection and removal process, the challenge window durations, the collateral requirement in BTC terms, and the ratio of bridge reserve to aggregate operator collateral. Those are the disclosures worth waiting for, more than the next efficiency multiple. A bridge whose disprove transaction costs a few dollars but whose challenger set is three companies in one jurisdiction has moved the cost curve without moving the trust boundary.
References
- R&D for Clementine v2: Eliminating Collateral and Liquidity Requirements with Garbled Circuits and TOOP, Citrea
- Bitcoin L2s in 2026: A Reality Check, House of ZK
- BitVM3 paper (we were unable to extract readable text from the retrieved file)
서론
Citrea의 브릿지 뒤에 BTC를 락업하는 예치자는 서명 위원회에게 돈을 돌려달라고 요구하는 것이 아니다. 커스터디의 문제는 감시의 문제로 대체되었다. 오퍼레이터가 허위 클레임을 제출하는 그 순간, 권한을 가진 워치타워 세트 중 최소 한 명이라도 작동 중이고, 자금이 있고, 정확하게 대응할 것인가라는 문제다. 2026년 1월 27일 이 대체가 프로덕션에 올라갔다. Citrea는 메인넷 가동을 발표하며 대출, 트레이딩, 결제를 중심으로 포지셔닝했고, 네이티브 브릿지로 Clementine을, 그 기반 메커니즘으로 BitVM2를 내세웠다. 하루 뒤 GOAT Network는 같은 프리미티브 위에서 퍼미션리스 출금을 강조하며 공개 테스트넷 V3를 열었다.
이 구분은 중요한데, 두 질문이 실패하는 방식이 다르기 때문이다. 페더레이션은 충분한 수의 멤버가 훔치기로 결정하거나, 충분한 수의 키가 탈취될 때 실패한다. 분쟁 게임은 아무도 나타나지 않을 때 실패한다. 전자는 공격자 입장에서의 조정 문제다. 후자는 방어자 입장에서의 가동 시간(uptime) 문제이며, 가동 시간은 악의와 무관한 이유로도 떨어진다. 수수료 급등, 모니터링 다운, 소프트웨어 설정 오류, 결정적인 순간에 오퍼레이터의 데이터 피드가 갱신되지 않는 경우 등이다.
지금 Citrea에서 가동 중인 것은 Clementine v1이며, 진지하게 받아들일 만한 신뢰 최소화 주장은 정확히 v1에 적용되는 것들이다. Clementine v1은 BitVM2 스크립트 기반 분쟁을 사용하고, 오퍼레이터에게 담보 락업을 요구하며, 오퍼레이터가 상환받기 전에 자신의 대차대조표에서 사용자 출금을 선지급하도록 요구한다. 비트코인 연구계에서 돌고 있는 더 효율적인 구조들, 그중 Citrea 자체의 Clementine v2 설계(garbled circuit과 TOOP 기반)를 포함해서, 이들은 명시적으로 연구 단계에 머물러 있다. Citrea는 v2를 메인넷 출시 이후 첫 번째 업그레이드로 계획하고 있다고 설명한다. 오늘 예치자들이 의존하는 것은 v2가 아니다.
우리의 판단은 이렇다. Clementine v1은 그 이전에 널리 쓰인 모든 BTC 브릿지에 비해 실질적인 신뢰 축소를 이룬 것이 맞지만, 그 축소의 폭은 “신뢰 최소화”라는 표현이 암시하는 것보다 좁다. 이 설계는 재량적 커스터디 가정을 권한을 가진 특정 집합에 대한 가동 시간 가정으로 전환한다. 가동 시간 가정은 커스터디 가정과 달리 감사가 가능하다는 점에서 진전이다. 하지만 이 가정은 지속적으로 소모된다. 매일, 모든 챌린지 윈도우에서, 그리고 비트코인 수수료 시장이 어떤 상태에 있든 이 가정은 계속 성립해야 한다.
비트코인이 판정하는 것, 비트코인이 결코 실행하지 않는 것
비트코인 스크립트는 반복문을 돌릴 수 없고, 트랜잭션 간 상태를 유지할 수 없으며, 자신의 아웃풋이 어떻게 소비될지를 제약할 수도 없다. CheckTemplateVerify나 CheckSigFromStack 같은 covenant 옵코드가 메인넷에서 활성화되어 있지 않기 때문이다. SNARK 검증기를 비트코인 스크립트로 직접 구현하면 블록에 들어가기엔 너무 크다. 따라서 롤업 브릿지와 유사한 무언가를 비트코인이 유효성 증명을 직접 확인하도록 만들어서 구축할 수는 없다.
BitVM2는 이 문제를 우회한다. 누군가 이의를 제기하지 않는 한, 비트코인에게 아무것도 확인해 달라고 요구하지 않는 방식이다. 오퍼레이터는 오프체인 연산에 대한 클레임, 전형적으로는 특정 Citrea 상태가 유효하며 그로부터 특정 peg-out 집합이 도출된다는 클레임을 제기한다. 이 클레임은 검증기 실행의 중간값들을 커밋하는 assert 트랜잭션 형태로 비트코인에 게시된다. 클레임이 정직하면 아무 일도 일어나지 않고, 오퍼레이터는 결국 사전 서명된 상환 경로를 사용한다. 클레임이 부정직하면, 챌린저는 오퍼레이터가 커밋한 중간값이 일관성을 잃는 단일 지점을 찾아내고, 그 단계만 스크립트로 실행하는 disprove 경로를 사용한다. 비트코인은 자신이 한 번도 실행한 적 없는 연산 중, 다툼이 있는 단 하나의 조각만을 판정한다.
covenant의 부재는 이 구조 전체를 형성한다. 비트코인이 “이 아웃풋은 다음 형태의 트랜잭션에 의해서만 소비될 수 있다”를 강제할 수 없기 때문에, BitVM2 설계는 이를 대신 셋업 시점에 사회적으로 강제한다. 모든 참여자는 트랜잭션 그래프의 모든 분기에 대해 미리 서명하고, 서명되지 않은 분기는 애초에 소비 가능한 옵션으로 존재하지 않는다. 따라서 이 그래프의 안전성은 셋업 세리머니에 달려 있다. 올바른 트랜잭션 집합에 대해 올바른 서명 집합이 만들어지고, 원치 않는 변형에 대한 서명 키는 결코 생성되지 않아야 한다는 것이다. 이는 스마트 컨트랙트와는 전혀 다른 실패 표면이며, House of ZK 분석이 분쟁 경제학과 운영상의 가동 시간과 더불어 BitVM2 스타일 설계의 프로덕션 배포를 가로막는 세 가지 강한 제약 중 하나로 지목한 감사 복잡성 문제의 원인이다.
여기서 두 가지 성질이 따라 나온다. 첫째, 참여자 집합은 그래프에 서명하는 순간 고정된다. 오퍼레이터를 추가하거나 교체하는 것은 거버넌스 트랜잭션이 아니라 새로운 세리머니다. 둘째, 정직한 경로의 비용은 작고 다툼이 있는 경로의 비용은 크다. disprove 분기가 비트코인이 다툼이 있는 단계를 재실행할 수 있을 만큼의 데이터를 담아야 하기 때문이다. 원래 명세된 BitVM2에서 이 disprove 트랜잭션은 약 4MB에 달하는데, 이는 단 하나의 논증에 비트코인 블록 하나 분량의 용량 전체를 소비하는 셈이다. 아래에서 다룰 효율화 작업들은 거의 전적으로 이 숫자를 겨냥한다.
정직한 한 명이 상시 대기 상태로
1-of-N이라는 표현은 정확하지만 불완전하다. 운영 측면에서 풀어 쓰면, 이 가정은 N명의 참여자 중 최소 한 명이 공격이 벌어지는 바로 그 순간에 다음 조건을 동시에 만족해야 한다는 것이다. 정직해야 하고, 비트코인과 Citrea를 모두 밀착 관찰하여 일관성 없는 클레임을 탐지할 수 있는 인프라를 운영 중이어야 하고, disprove 위트니스를 구성하는 데 필요한 셋업 데이터를 보유하거나 복원할 수 있어야 하고, 대용량 트랜잭션을 컨펌시키는 데 필요한 비트코인 수수료를 지불할 수 있어야 하며, 이 모든 것을 프로토콜이 사전에 정한 챌린지 윈도우 안에서 해내야 한다.
이 조건들 각각이 별개의 실패 지점이다. 정직하지만 노드가 낡은 참여자는 실패한다. 정직하고 모니터링도 잘하지만 수수료 급등기에 수 메가바이트짜리 트랜잭션을 블록에 넣지 못하는 참여자도 실패한다. 정직하고, 깨어 있고, 자금도 있지만 부정을 윈도우가 닫힌 뒤 한 블록 늦게 발견하는 참여자도 실패한다. House of ZK 분석은 이를 단도직입적으로 지적한다. 1-of-N 정직한 챌린저 가정은 실제로는 가동 시간과 모니터링에 대한 요구사항이라는 것이다. 암호학의 어떤 부분도 텅 빈 워치타워를 보완해 주지 않는다.
담합은 특정한 양상으로 이 모델을 약화시킨다. N-1명이 담합하는 경우, 원칙적으로는 안전성이 유지된다. 정직한 챌린저 한 명만으로도 disprove가 가능하기 때문이다. 그러나 실제로는 마지막 정직한 참여자 한 명이 갖는 한계 가치가 곧 브릿지 준비금 전체가 되며, 이는 공격자의 계산법을 “훔친다”에서 “특정 거래상대방 한 명을 식별해 무력화한다”로 바꿔놓는다. 무력화가 반드시 암호학적 침해를 요구하는 것도 아니다. 그저 윈도우를 놓치게 만들면 되는데, 이는 훨씬 낮은 문턱이다. 모든 오퍼레이터와 모든 워치타워가 담합하는 경우, 우리가 확인한 자료에는 어떤 구제책도 서술되어 있지 않으며, 우리는 이 시나리오를 기능적으로 페더레이션 침해와 동등하게 취급한다.
퍼미션 구조라는 점이 이 분석을 불편하게 만든다. Citrea는 Clementine의 네트워크를 permissioned로 설명하며, 이 퍼미션 구조가 있어야만 v2의 garbled-circuit 구성이 애초에 가능하다. 각 오퍼레이터와 각 워치타워 사이에 전용 회로를 준비하려면 양쪽 집합이 모두 사전에 알려져 있어야 하기 때문이다. 알려져 있고, 유한하며, 열거 가능한 챌린저 집합은 접근하거나, 압박하거나, 공동으로 규제할 수 있는 집합이기도 하다. 우리가 검토한 자료는 워치타워가 어떻게 선정되는지, 누가 추가하거나 제거할 권한을 갖는지, 메인넷 시점에 몇 명이 존재하는지, 챌린지 윈도우가 얼마나 지속되는지를 명시하지 않는다. 이 파라미터들이야말로 1-of-N이 강력한 주장인지 장식적인 주장인지를 가르는데, 우리가 확보한 자료에는 공개되어 있지 않다.
일반적으로 옵티미스틱 프로토콜이 반드시 가격에 반영해야 하는 그리핑(griefing) 측면도 있다. 이의 제기가 공짜라면, 공격자는 오퍼레이터로 하여금 값비싼 assert 트랜잭션을 반복해서 게시하게 만들어 수수료만으로도 고갈시킬 수 있다. 이 계열의 설계들은 대개 챌린저가 이의 제기 시점에 무언가를 예치하도록 요구해서 이 공격을 비싸게 만든다. Clementine의 구체적인 파라미터가 무엇이든, 여기에는 구조적인 긴장이 존재한다. 무의미한 이의 제기 비용을 높이면 정당한 이의 제기 비용도 함께 오른다. 그런데 전체 보안 논거가 의존하는 것은 바로 그 정당한 이의 제기다.
Clementine v1: 담보, float, 그리고 전역 정지 버튼
실제로 가동 중인 것을 정의하는 두 가지 요구사항이 있다. Citrea 자체의 설명에 따르면, Clementine v1은 오퍼레이터에게 악의적 행위를 비싸게 만들기 위한 대규모 담보 락업을 요구하고, 오퍼레이터가 사용자에게 출금액을 먼저 선지급하고 이후에 상환받도록 요구한다.
두 번째 요구사항은 사용자 경험에서 제대로 인지되지 않는 성질을 만들어낸다. 누군가 Citrea에서 출금할 때, 오퍼레이터는 자신의 잔고에서 즉시 BTC를 보낸다. 이후 벌어지는 분쟁 게임은 사용자의 지급과는 무관하다. 그 오퍼레이터가 브릿지 준비금에서 자신을 상환할 자격이 있는지에 관한 것이다. 사용자는 먼저 온전히 보상받고, 판정은 그 뒤에서 벌어진다. 분쟁의 결과에 노출되는 쪽은 준비금, 즉 출금한 개인이 아니라 페그된 자산을 여전히 보유하고 있는 나머지 사람들이다.
이 구조는 자본 측면에서 하나의 결과를 낳는다. 오퍼레이터는 본딩된 담보를 예치함과 동시에 출금 수요를 선지급할 만큼 충분한 여유 BTC를 보유해야 한다. 둘 다 유휴 자본이며, 오퍼레이터가 벌어야 하는 수익률은 이 둘을 모두 커버해야 한다. Citrea 스스로도 이것들이 확장성과 참여자 다변화를 제한하는 제약이라고 지목하며, 이것이 v2 연구의 명시적 동기다. 이 경제학은 자본력이 큰 소수의 오퍼레이터로 쏠리게 만드는 방향으로 작동하는데, 오퍼레이터 수가 적다는 것은 곧 N이 작다는 뜻이다. 브릿지를 지키기 위해 존재하는 자본 요구사항이, 보안 논거의 근거가 되는 바로 그 집합의 다양성을 압축시킨다. 이 긴장은 현재 배포된 어떤 것으로도 해소되지 않는다.
Clementine의 라운드 기반 구조도 이해할 필요가 있는 세 번째 요소다. 오퍼레이터는 라운드를 거쳐 진행하며, 한 라운드에서 부정이 탐지되면 진행이 멈추고 다음 라운드가 열리지 못한다. Citrea는 이를 서킷 브레이커라고 설명하며, v2 설계에서 이것의 즉각적인 목적은 효율성이다. garbled circuit을 매 예치마다 재생성하지 않고 셋업 시점에 한 번만 구성할 수 있게 해주는데, 부정을 저지른 오퍼레이터가 그냥 다음 기회로 넘어갈 수 없기 때문이다. 보안 측면의 함의는 더 나아간다. 성공적인 disprove는 하나의 부정 클레임에 대한 국지적 슬래싱이 아니다. 기계 전체를 멈춰 세운다. 안전성은 정지를 통해 유지되며, 이는 실제 부정 행위 이후의 복구 경로가 자동적인 것이 아니라 거버넌스와 세리머니의 문제라는 뜻이다. 그리고 그 경로가 어떤 모습인지 서술한 자료는 어디에도 없다.
검증기를 Garbling하기
BitVM2에서 지배적인 비용은 disprove 트랜잭션이며, disprove 트랜잭션에서 지배적인 비용은 비트코인이 스크립트로 다툼이 있는 단계를 재실행해야 한다는 점이다. Clementine v2는 스크립트 실행 자체를 분쟁에서 제거하는 방안을 제안한다.
이 구성은 Groth16 SNARK 검증기를 AND와 XOR 게이트로 이루어진 불리언 회로로 컴파일한 다음 이를 garbling한다. Garbling은 각 게이트의 진리표를 암호화하여, 평가자가 게이트당 정확히 하나의 출력 레이블만 복호화할 수 있고 그 외에는 아무것도 알 수 없게 만든다. 검증기는 챌린저에 의해 오프체인에서 평가되며, 챌린저는 결과적으로 오퍼레이터의 클레임이 거짓일 때만 존재하는 출력 프리이미지를 손에 넣는다. 그러면 비트코인은 그 프리이미지의 해시만 확인하면 된다. disprove 트랜잭션은 단일 해싱 스크립트가 된다. Citrea는 이를 기존 약 4MB짜리 BitVM2 disprove 트랜잭션 대비 약 10만 배의 개선이라고 보고하며, assert 트랜잭션도 1.3MB에서 80kB로(다른 곳에서는 약 2만 vbyte로) 줄어든다고 보고한다. 이는 아직 출시되지 않은 설계에 대한 팀 자체의 수치이며, 우리가 검토한 자료에서 이를 뒷받침하는 제3자 벤치마크는 발견되지 않았다.
Citrea는 저렴한 비트코인 부정 증명을 위해 garbled circuit을 사용한다는 근본 아이디어의 출처로 Jeremy Rubin의 Delbrag 논문을 인용하며, Delbrag가 지적한 트레이드오프도 함께 언급한다. 온체인 데이터는 줄지만, 참여자 간 오프밴드 교환은 늘어난다는 것이다. 이 트레이드오프는 거버넌스적 함의를 갖는다. Garbled circuit은 구성상 designated-verifier 방식이다. Garbling을 수행하는 쪽은 특정 평가자를 위해 회로를 준비하므로, Clementine 설계는 각 오퍼레이터와 각 워치타워 사이에 전용 회로를 구축하고, 결과적으로 오퍼레이터 대 워치타워 셋업의 그래프가 만들어진다. Citrea는 이것이 워치타워 사이의 단순한 1-of-N 정직성 가정으로 모델을 축소시킨다고 말한다.
이는 또한 누가 이의를 제기할 수 있는지도 좁힌다. 스크립트 기반 BitVM2에서는 위트니스를 구성할 수 있는 누구나 disprove 경로를 실행할 수 있다. 비트코인 자체가 다툼이 있는 연산을 확인하고, 그 확인은 누구나 검증 가능하기 때문이다. Garbling 하에서는 해당 특정 오퍼레이터와 사전에 회로를 구축해 둔 당사자만이 프리이미지를 만들어낼 수 있다. 더 저렴한 분쟁은 더 명시적으로 열거된 챌린저 집합을 대가로 얻어진다. 이것이 순손실인지 여부는 전적으로, 4MB 스크립트 경로가 수수료 급등기에 비연관 외부자에 의해 현실적으로 실행 가능했던 적이 있었는지에 달려 있으며, 솔직한 답은 아마 그런 적이 없었다는 것이다. v2 설계는 이미 경제적으로 존재하던 퍼미션 구조를 형식화하고 있는 것일 수 있다.
이 절에는 두 가지 유보 사항이 있다. 첫째, Garbled circuit이 올바르게 구성되었음을 증명하는 데 현재 Citrea에 따르면 약 14일이 걸리며, 팀은 이를 줄이기 위해 작업 중이라고 밝힌다. 몇 주 단위로 측정되는 셋업 단계는 참여자 집합이 얼마나 자주 바뀔 수 있는지를 제약한다. 둘째, 이 분석의 계기가 된 주제는 BitVM3가 최악의 경우 분쟁 비용을 약 1,000배 줄여 약 5달러 수준으로 낮춘다고 언급한다. 우리가 확보한 BitVM3 논문은 읽을 수 있는 텍스트로 파싱되지 않았으며, 우리는 그 수치를 출처가 확인된 것으로 재서술하지 않는다. 다만 그 방향성은 Citrea 자체의 수치와, House of ZK가 정리한 병행 연구들, 즉 garbled lock과 designated-verifier SNARK를 사용해 BitVM2 대비 수백 배의 효율 개선을 주장한다고 서술된 Alpen의 Glock, 그리고 유사한 비용 절감을 추구하는 Ideal의 Argo에 의해 충분히 뒷받침된다. 어쨌든 분쟁 비용을 달러로 표현하는 것은 프로토콜의 속성이라기보다는 수수료 환경에 대한 진술이다. 관건이 되는 질문은, 공격자가 의도적으로 유발할 수 있는 혼잡 상황에서 disprove 비용이 블록 용량 대비 얼마나 되느냐다.
TOOP과 float 문제
Garbled circuit은 분쟁 비용을 공략한다. 이는 오퍼레이터가 유동성을 선지급해야 한다는 요구사항에는 아무런 영향을 주지 않는데, 이는 별도의 해법이 제안된 별도의 문제다.
Fairgate Labs가 구축한 TOOP은 상환 구조를 재편하여 오퍼레이터가 사용자에게 먼저 지불하지 않아도 되게 만든다. 셋업 시점에 오퍼레이터들은 오퍼레이터 집합의 모든 부분집합을 커버하는 상환 트랜잭션에 미리 서명한다. 출금 시점이 되면 오퍼레이터들은 개인키를 암호화하여 사용자에게 전송하고, 사용자는 서명자 부분집합을 선택하여 스스로 지급을 조립한다. 오퍼레이터의 역할은 자본을 선지급하는 것에서, 이미 락업된 자본에 대한 클레임을 승인하는 것으로 바뀐다.
모든 부분집합에 대해 사전 서명하는 것은 조합적으로 비싸며, 자료에는 그 결과로 생기는 상한이 명시되어 있지 않지만, 스케일링 방식을 보면 오퍼레이터 집합 크기에 대한 실질적인 상한이 있음을 시사한다. 이는 참여를 더 쉽게 만들려는 메커니즘에서 오히려 N에 제약이 생기는 셈이며, 설계가 성숙해감에 따라 면밀히 검토할 가치가 있다. TOOP 자체의 성숙도도 우리로서는 알 수 없다. Clementine 맥락 바깥에서 이루어진 감사나 배포 사례는 발견하지 못했다.
종합하면, v2는 두 자본 요구사항을 동시에 겨냥한다. Garbled circuit은 부정을 처벌 가능하게 만들기 위해 오퍼레이터가 예치해야 하는 것을 줄이고, TOOP은 출금을 신속하게 만들기 위해 오퍼레이터가 보유해야 하는 것을 줄인다. 둘 다 설명대로 작동한다면, 오퍼레이터 역할의 비용이 충분히 낮아져 N이 더 크고 다양해질 수 있으며, 이것이야말로 1-of-N이 형태만 다른 가정이 아니라 실제로 더 강한 가정이 될 수 있는 유일한 경로다. 그것이야말로 v2가 출시될 때 검증해야 할 논거이며, 트랜잭션 크기 수치가 아니다.
Clementine이 기존 브릿지 설계와 비교해 서 있는 위치
브릿지 설계를 비교하는 데 유용한 기준은 처리량이나 지원 체인의 수가 아니다. 담보가 온전히 유지되기 위해 누가 올바르게 행동해야 하는지, 그리고 출금이 완료되기 위해 누가 반드시 존재해야 하는지다. 이 둘은 종종 다른 당사자이며, 이를 혼동하는 것이야말로 브릿지가 실제보다 안전하게 서술되는 방식이다. 아래 표는 우리의 종합 분석이며, 출처가 명시된 벤치마크가 아니다.
| 설계 | 자금이 계속 담보로 유지되기 위해 정직해야 하는 주체 | 출금을 위해 반드시 존재해야 하는 주체 | 실패 시그니처 |
|---|---|---|---|
| 커스터디 방식 래핑 BTC | 커스터디언 | 커스터디언 | 준비금이 소진되거나 동결됨; 보유자는 오프체인 공시를 통해서만 이를 알게 됨 |
| 페더레이션 페그 (n-of-m) | m명 중 함께 행동하는 n명 | 동일한 n명의 서명자 | 쿼럼이 승인되지 않은 지출에 서명하거나, n명 미만만 연락 가능해져 페그가 정지됨 |
| 오프체인 어테스테이션 브릿지 | 원격 이벤트를 증언하는 오라클 및 릴레이어 집합 | 동일한 집합 | 대상 체인이 발생한 적 없는 이벤트에 대해 민팅함; 검증이 위임되었기 때문에 대상 체인은 이를 탐지할 수 없음 |
| BitVM2 브릿지 (Clementine v1) | 특정 주체 없음, 단 정직한 챌린저 한 명이 제때 행동한다는 조건 | 담보와 float을 갖춘 오퍼레이터, 그리고 가동 중인 챌린저 집합 | 챌린저가 윈도우 내에 이의를 제기하지 않아 허위 클레임이 확정됨 |
맨 아래 행의 구조적 변화는, 특정 이름을 가진 어떤 당사자도 단독으로 지출을 승인할 수 없다는 점이다. 비트코인이 분쟁의 결과를 강제하고, 사전 서명된 그래프는 셋업 시점에 서명되지 않은 모든 분기를 원천 차단한다. 이는 정확히 House of ZK 분석이 진짜 비트코인 L2와 사이드체인을 구분할 때 사용하는 성질이다. 오퍼레이터와 위원회가 오프라인이거나, 악의적이거나, 비협조적일 때에도 사용자가 비트코인 합의 규칙 하에서 출금할 수 있어야만 그 명칭을 획득할 자격이 있다는 것이다.
이 변화는 실패를 제거하는 것이 아니라 재배치한다. 페더레이션의 실패는 쿼럼의 능동적인 결정을 필요로 한다. 분쟁 게임의 실패는 부재를 필요로 한다. 부재는 조직될 필요가 없고, 조정의 흔적을 남기지 않으며, 공격자가 만들어낼 수 있는 조건, 즉 수수료 혼잡과 인프라 스트레스와 정확히 상관관계를 갖는다. 합리적인 어떤 가중치를 적용해도 비교는 BitVM2 쪽에 유리하지만, “신뢰할 당사자가 없다”는 표현이 암시하는 것보다는 덜 유리하다.
한 가지 비대칭성이 더 주목할 만하다. 페더레이션 페그 하에서는 본딩된 담보가 준비금 대비 커야 한다. 담합하는 쿼럼의 대가는 준비금이고 비용은 본드이기 때문이다. BitVM2에서는 대가 구조가 다르다. Disprove된 오퍼레이터는 훔친 후 처벌받는 것이 아니라, 훔치는 데 실패하고 처벌받는다. Disprove 경로가 애초에 상환을 가로채지 못하게 막기 때문이다. 따라서 담보는 준비금 전체 가치가 아니라 그리핑과 운영상의 위법 행위에 대해 가격이 매겨진다. 손실 함수는 불연속적이다. 정직한 워치타워 한 명이라도 행동하면 손실은 거의 0이다. 아무도 행동하지 않으면 손실은 그래프가 오퍼레이터에게 허용하는 클레임 범위만큼 발생한다. 모든 것은 시스템이 이 불연속 지점의 어느 쪽에 놓이느냐에 달려 있으며, 담보 규모를 조정한다고 해서 이 경계선 자체가 움직이지는 않는다.
사전 서명된 그래프, 부재하는 Covenant
위에서 논의한 모든 구조적 제약은 결국 같은 빠진 프리미티브로 거슬러 올라간다. 비트코인이 “이 아웃풋은 이 템플릿과 일치하는 트랜잭션에 의해서만 소비될 수 있다”를 표현할 수 없기 때문에, Clementine은 사전 서명을 통해 covenant를 근사해야 한다. 그 결과는 누적된다. 참여자 집합은 세리머니 시점에 고정되고, 교체를 위해서는 새로운 세리머니가 필요하며, 사전 서명된 아티팩트의 수는 라운드가 늘어날수록, TOOP 하의 부분집합 조합이 늘어날수록 함께 증가하고, 전체 배치의 안전성은 사후에 온체인 관찰자가 검증할 수 없는 세리머니 위생 상태에 의존한다.
CheckTemplateVerify가 있다면 아웃풋이 허용된 지출 트랜잭션의 해시를 직접 커밋할 수 있게 되어, 이 제약이 서명 집합의 완전성이 아니라 합의(consensus)를 통해 강제될 것이다. CheckSigFromStack이 있다면 스크립트가 임의의 메시지에 대한 서명을 검증할 수 있게 되어, 현재는 사전 서명된 분기에 미리 구워 넣어야 하는 위임 및 어테스테이션 패턴이 열릴 것이다. 어느 쪽도 활성화되어 있지 않으며, 우리가 검토한 어떤 자료도 이것들이 활성화되었을 때 Clementine의 구체적인 구성이 어떻게 단순화될지 논의하지 않는다. 우리가 말할 수 있는 것은, 이 설계에서 가장 확장성이 떨어지는 부분들, 즉 세리머니 소요 시간, 부분집합 사전 서명, 참여자 집합의 경직성이, 정확히 사전 서명이 합의 강제를 대신하고 있기 때문에 존재하는 부분들이라는 점이다. Covenant가 활성화된다면, 흥미로운 질문은 분쟁이 더 저렴해지느냐가 아니라 N이 유동적으로 될 수 있느냐다.
실패의 모양
네 가지 서로 다른 실패 모드를 구분할 가치가 있는데, 각각의 발생 확률과 피해자가 다르기 때문이다.
가동 시간 실패는 이 설계가 명시적으로 받아들이는 기본 케이스다. 오퍼레이터가 허위 클레임을 제기하고, 챌린저가 시간 내에 이의를 제기하지 않으며, 상환이 확정된다. 준비금은 클레임된 금액만큼 부족해진다. 이미 출금한 사용자는 자신의 BTC를 그대로 보유한다. 부족분은 페그된 자산을 계속 보유하고 있는 나머지 사람들에게, 아마도 부분지급준비 형태로 전가되겠지만, 우리가 검토한 어떤 자료도 이런 부족분이 어떻게 배분되는지, 혹은 어떤 백스톱이 존재하는지 설명하지 않는다.
분쟁 경제학 실패는 원인이 있는 가동 시간 실패다. 비트코인 수수료가 충분히 올라 수 메가바이트짜리 disprove 트랜잭션을 윈도우 안에 컨펌시킬 수 없게 되면, 정직하고 주의 깊은 챌린저조차 배제된다. Garbled-circuit 작업은 이를 직접 겨냥하며, 만약 출시되면 이 위험을 사실상 독립적인 리스크에서 제거한다. 아직 출시되지 않은 지금, 현재 가동 중인 시스템은 이 리스크를 그대로 안고 있다.
완전 담합 실패는 시스템을 페더레이션 페그와 동일한 성격으로 되돌린다. 자료들은 구제책을 서술하지 않으며, 우리는 어떤 구제책이 존재한다고 가정하지 않는다.
구성 실패는 1-of-N 프레이밍이 전혀 다루지 않는 유형이다. 트랜잭션 그래프가 잘못 서명되었거나, 존재해서는 안 될 분기가 실제로 존재하거나, 세리머니에서 키가 유출된 경우, 정직한 워치타워는 disprove할 대상이 없다. 절도가 유효한 지출이기 때문이다. 이는 감사 복잡성 제약이며, 스마트 컨트랙트 감사가 아니다. 사전 서명된 트랜잭션 그래프 프로토콜 스택 전체에 대한 검토다. 우리는 배포된 Clementine v1에 대해 팀 자체의 설계 문서와 별개로 발표된 독립적인 보안 평가를 찾지 못했다.
외부인이 이런 위험을 가격 매길 수 있게 해줄 파라미터들은 우리가 검토한 자료에는 공개되어 있지 않다. 워치타워의 수, 선정 및 제거 절차, 챌린지 윈도우의 지속 시간, BTC 기준 담보 요구액, 그리고 브릿지 준비금 대비 오퍼레이터 총담보의 비율이다. 다음 효율성 배수보다 이런 공시들을 기다릴 가치가 있다. disprove 트랜잭션 비용이 몇 달러에 불과하더라도, 챌린저 집합이 한 관할권 안의 세 개 회사라면, 비용 곡선만 이동했을 뿐 신뢰의 경계선은 이동하지 않은 것이다.
참고자료
- R&D for Clementine v2: Eliminating Collateral and Liquidity Requirements with Garbled Circuits and TOOP, Citrea
- Bitcoin L2s in 2026: A Reality Check, House of ZK
- BitVM3 paper (검색한 파일에서 읽을 수 있는 텍스트를 추출하지 못했음)
はじめに
Citrea のブリッジに BTC をロックする預け入れ者は、署名委員会に返還を求めているわけではない。カストディの問題は、警戒の問題に置き換えられた。オペレータが虚偽の主張を提出した瞬間に、許可制ウォッチタワーの少なくとも1人が稼働し、資金を確保し、正しく動作しているかどうかという問題だ。2026年1月27日、この置き換えが本番稼働した。Citrea はメインネットのライブ稼働を発表し、レンディング、取引、決済を軸に据え、ネイティブブリッジとして Clementine を、その裏側の仕組みとして BitVM2 を採用した。翌日には GOAT Network が同じプリミティブに基づく Testnet V3 を公開し、パーミッションレスな出口を強調している。
この違いは重要だ。なぜなら2つの問いは異なる形で失敗するからだ。フェデレーションが失敗するのは、十分な数のメンバーが盗もうと決めたとき、あるいは十分な数の鍵が奪われたときだ。ディスピュートゲームが失敗するのは、誰も現れないときだ。前者は攻撃者側の協調問題であり、後者は防御側の稼働率の問題であって、稼働率が低下する理由は悪意とは無関係なことが多い。手数料の急騰、監視システムの停止、ソフトウェアの設定ミス、あるいは肝心な時間帯にオペレータのデータフィードが古くなっていた、といった具合だ。
Citrea で稼働しているのは Clementine v1 であり、真剣に検討する価値があるトラストミニマイゼーションの主張は、v1 に特有に当てはまるものに限られる。Clementine v1 は BitVM2 のスクリプトベースのディスピュートを用い、オペレータに担保のロックを義務づけ、さらにオペレータが自らのバランスシートからユーザーの引き出しを立て替え、その後に払い戻しを受けるという仕組みを採る。ビットコイン研究の中で流通しているより効率的な構成、たとえば Citrea 自身が設計する、ガーブル回路と TOOP を基盤とする Clementine v2 は、明確に研究段階にとどまる。Citrea は v2 をメインネット公開後最初のアップグレードとして位置づけている。つまり、今日の預け入れ者が依拠しているものではない。
私たちの見立てでは、Clementine v1 は、これまで広く使われてきたあらゆる BTC ブリッジと比べて本物のトラストの削減を実現しているが、その削減幅は「トラストミニマイズド」という言葉が示唆するよりも狭い。それは、裁量的なカストディの前提を、許可制の参加者集合に対する稼働率の前提に置き換えるものだ。稼働率の前提はカストディの前提とは違って監査可能であり、それは前進と言える。しかし同時に、それは絶え間なく消費され続けるものでもある。この前提は、毎日、あらゆるチャレンジウィンドウにおいて、ビットコインの手数料市場がどんな状態であろうと、成立し続けなければならない。
ビットコインが裁定するもの、決して実行しないもの
ビットコインスクリプトはループできず、トランザクション間で状態を保持できず、自らのアウトプットの使われ方を制約することもできない。CheckTemplateVerify や CheckSigFromStack といったコベナントopcodeがメインネットで有効化されていないためだ。SNARK検証器をビットコインスクリプトで直接表現すると、ブロックに収まらないほど巨大になる。したがって、ロールアップブリッジに類するものは、ビットコインに妥当性証明を検証させる形では構築できない。
BitVM2 はこの制約を、誰かが異議を唱えない限りビットコインに何も検証させない、という形で回避する。オペレータはオフチェーンの計算について主張を行う。典型的には、ある特定の Citrea の状態が有効であり、そこから特定のペグアウトの集合が導かれる、という主張だ。この主張は、検証器の実行における中間値をコミットしたアサートトランザクションとしてビットコイン上に公開される。主張が正しければ、それ以上は何も起こらず、オペレータは最終的に事前署名済みの払い戻しパスを使う。主張が虚偽であれば、チャレンジャーがオペレータのコミットした中間値に矛盾が生じている一手を特定し、その一手だけをスクリプトで実行するディスプルーブパスを使う。ビットコインは、自らが実行したことのない計算のうち、争われた一部分だけを裁定する。
コベナントの不在が、この構成全体の形を決めている。ビットコインは「このアウトプットは次の形式のトランザクションによってのみ使用可能」という条件を強制できないため、BitVM2 の設計はそれをセットアップ時の社会的な合意によって代替する。すべての参加者が事前にトランザクショングラフのすべての分岐に署名し、署名されていない分岐は使用可能な選択肢として単に存在しない。したがってグラフの安全性は、セットアップの儀式、つまり正しいトランザクション集合に対する正しい署名集合が揃い、望ましくないバリアントの署名鍵が決して生成されないこと、に依存する。これはスマートコントラクトとはまったく異なる失敗の様相であり、House of ZK の分析が BitVM2 スタイルの設計を本番運用する上での3つの厳しい制約の1つとして挙げる、監査の複雑性という懸念の源泉でもある。もう2つの制約は、ディスピュートの経済性と運用上の稼働率だ。
ここから2つの性質が導かれる。第一に、参加者集合はグラフが署名された時点で固定される。オペレータの追加やローテーションは、ガバナンストランザクションではなく新たな儀式を意味する。第二に、正直なパスのコストは小さく、争われるパスのコストは大きい。なぜならディスプルーブブランチは、ビットコインが争われた一手を再実行できるだけのデータを載せなければならないからだ。当初仕様の BitVM2 では、そのディスプルーブトランザクションはおよそ4MBに達し、これはビットコインのブロック容量まるごと1つ分を単一の主張のために費やすことに等しい。以下で述べる効率化の取り組みは、ほぼこの数値だけを標的にしている。
常時待機する、たった1人の正直者
1-of-N という枠組みは正確ではあるが、不完全でもある。運用面に落とし込むと、この前提は、攻撃が起きた瞬間に N 人の参加者のうち少なくとも1人が以下のすべてを同時に満たすことを意味する。正直であること。ビットコインと Citrea の双方を、矛盾する主張を検知できるだけの精度で観測するインフラを稼働させていること。ディスプルーブの証拠を構築するために必要なセットアップデータを保有しているか再構築できること。巨大なトランザクションをブロックに取り込ませるのに必要なビットコインの手数料を支払えること。そしてこれらすべてを、あらかじめ定められた期間のチャレンジウィンドウの中でやり遂げること。
それぞれの条件が、独立した失敗の経路になる。ノードが古くなっている正直な参加者は失敗する。正直で監視も行き届いているが、手数料が急騰している最中に数メガバイトのトランザクションをブロックに入れられない参加者も失敗する。正直で、目を光らせていて、資金もあるのに、ウィンドウが閉じた1ブロック後に不正を発見した参加者も失敗する。House of ZK の分析はこれを率直に指摘している。1-of-N の正直なチャレンジャーという前提は、実質的には稼働率と監視の要件にすぎない。ウォッチタワーが空っぽであれば、暗号技術の側では何も補ってくれない。
共謀はこのモデルを特定のパターンで劣化させる。N-1 人が共謀していても、原理上は安全性が保たれる。1人の正直なチャレンジャーが残っていればディスプルーブできるからだ。しかし実際には、その最後の正直な参加者1人の限界的な価値は、いまやブリッジの準備金そのものと等しくなり、攻撃者の計算は「盗む」から「その1人の特定の相手を突き止めて無力化する」へと変わる。無力化には暗号学的な突破は必要ない。ウィンドウを逃させるだけでよく、これはずっと低いハードルだ。すべてのオペレータとすべてのウォッチタワーが共謀した場合、私たちが参照した資料には何の対抗策も記載がなく、私たちはこのシナリオを機能的にフェデレーションの侵害と同等と見なす。
許可制であることが、この分析を居心地悪くしている。Citrea は Clementine のネットワークをパーミッションドと説明しており、実はこの許可制こそが v2 のガーブル回路構成をそもそも可能にしている。専用回路を各オペレータと各ウォッチタワーの間で用意できるのは、両方の集合があらかじめわかっている場合に限られるからだ。既知で、境界があり、列挙可能なチャレンジャー集合は、接近し、圧力をかけ、あるいは共同で規制することができる集合でもある。私たちが確認した資料は、ウォッチタワーがどう選ばれるか、誰が追加・削除できるか、メインネットで何人存在するか、チャレンジウィンドウがどのくらいの長さかを明記していない。これらのパラメータが、1-of-N が強い主張なのか見せかけの主張なのかを決めるが、私たちが入手できた資料の中では公開されていない。
一般に楽観的プロトコルが価格に織り込まなければならない、グリーフィングの側面もある。異議申し立てが無料であれば、攻撃者はオペレータに高価なアサートトランザクションを繰り返し公開させ、手数料だけで消耗させることができる。このファミリーの設計は通常、この攻撃のコストを上げるために、チャレンジ時にチャレンジャー側にも何かを供託させる。Clementine の具体的なパラメータが何であれ、緊張関係は構造的だ。軽薄な異議申し立てのコストを上げれば、正当な異議申し立てのコストも上がる。そして、セキュリティの主張全体が依拠しているのは、まさにその正当な異議申し立てなのだ。
Clementine v1: 担保、フロート、そしてグローバルな停止ボタン
実際に稼働しているものを定義するのは、2つの要件だ。Citrea 自身の説明によれば、Clementine v1 はオペレータに、悪意を働くコストを高くするための大きな担保のロックを義務づけ、さらにユーザーへの引き出しを先に立て替え払いし、後から払い戻しを受けることを義務づけている。
第二の要件が、ユーザー体験のあまり評価されていない特性を生む。誰かが Citrea から出るとき、オペレータは即座に自らの残高から BTC を送る。その後に続くディスプュートゲームは、ユーザーへの支払いをめぐるものではない。そのオペレータがブリッジ準備金から自身を払い戻す権利を持つかどうかをめぐるものだ。ユーザーは先に満額を受け取り、裁定はその背後で行われる。ディスピュートの結果に晒されるのは準備金、つまりペグ資産を保有し続ける残りの保有者であって、引き出した本人ではない。
この構造は資本上の帰結を持つ。オペレータは、供託担保の投稿と、引き出し需要に応えるだけの潤沢な BTC の保有を、同時にこなさなければならない。どちらも遊休資本であり、オペレータが得る利回りはその両方をまかなわなければならない。Citrea 自身、これらが拡張性と参加者の分散を制限する制約であると認めており、これが v2 研究の明示された動機となっている。この経済性は少数の資本力に恵まれたオペレータへと集約を促し、小さなオペレータ集合は小さな N を意味する。ブリッジを守るために存在する資本要件が、その集合の多様性、まさにセキュリティの根拠となっている多様性そのものを圧縮している。この緊張関係は、現在稼働しているどの仕組みによっても解消されていない。
Clementine のラウンドベースの構造は、理解しておくべき3つ目の要素だ。オペレータはラウンドを進行していき、あるラウンドで不正が検知されると進行は停止し、次のラウンドの開始がブロックされる。Citrea はこれをサーキットブレーカーと説明しており、v2 設計における直接の目的は効率性にある。すなわち、ガーブル回路をデポジットごとに再生成するのではなく、セットアップ時に一度だけ確立できるようにすることだ。不正を働くオペレータが単純に次の機会へ進むことができなくなるためだ。しかしセキュリティ上の含意はさらに先へ及ぶ。ディスプルーブの成功は、1つの悪い主張に対する局所的なスラッシングではない。機械全体を止めるのだ。安全性は停止によって保たれるということであり、つまり本物の不正事件の後の復旧経路は、自動的なものではなくガバナンスと儀式の問題になる。しかし入手可能などの資料も、その経路がどのようなものかを説明していない。
検証器をガーブルする
BitVM2 における支配的なコストはディスプルーブトランザクションであり、ディスプルーブトランザクションにおける支配的なコストは、ビットコインが争われた一手をスクリプトで再実行しなければならないという点にある。Clementine v2 は、ディスピュートからスクリプト実行そのものを取り除くことを提案している。
この構成は、Groth16 の SNARK 検証器を AND と XOR ゲートからなるブール回路にコンパイルし、それをガーブルする。ガーブリングは各ゲートの真理値表を暗号化し、評価者がゲートごとにちょうど1つの出力ラベルだけを復号でき、それ以外は何も学べないようにする。検証器はオフチェーンでチャレンジャーによって評価され、その結果、オペレータの主張が虚偽であった場合にのみ存在する出力プリイメージをチャレンジャーが手にすることになる。ビットコインはそのプリイメージのハッシュを検証するだけだ。ディスプルーブトランザクションは単一のハッシュ検証スクリプトになる。Citrea はこれを、従来のおよそ4MBの BitVM2 ディスプルーブトランザクションに対しておよそ10万倍の改善と報告しており、アサートトランザクションについても1.3MBから80kBへ、別の箇所ではおよそ20k vbytesへと縮小すると報告している。これらはまだ出荷されていない設計に関するチーム自身の数値であり、私たちが確認した資料の中に第三者によるベンチマークは見当たらない。
Citrea は、ガーブル回路を使ってビットコインの不正証明を安く行うという基本的なアイデアについて、Jeremy Rubin の Delbrag 論文をクレジットしており、Delbrag が指摘するトレードオフにも言及している。オンチェーンデータは減るが、参加者間のオフバンドでのやり取りは増える、というものだ。このトレードオフはガバナンス上の形を持つ。ガーブル回路は構造上、指定検証者向けだ。ガーブルする側は特定の評価者に向けてそれを準備するため、Clementine の設計は各オペレータと各ウォッチタワーの間に専用回路を確立し、オペレータ×ウォッチタワーのセットアップからなるグラフを生み出す。Citrea はこれによって、ウォッチタワー間のシンプルな1-of-Nの正直性の前提に還元されると述べている。
これは同時に、誰が異議を申し立てられるかを狭める。スクリプトベースの BitVM2 では、ディスプルーブパスは証拠を構築できる誰にとっても実行可能だった。争われた計算をビットコイン自身が検証し、その検証が普遍的に検証可能だったからだ。ガーブリングの下では、その特定のオペレータとの間で事前に確立された回路を保有する当事者だけがプリイメージを生成できる。安価なディスピュートは、より明示的に列挙されたチャレンジャー集合と引き換えに得られている。それが正味の損失かどうかは、そもそも4MBのスクリプトパスが手数料急騰時に無関係な部外者によって実際に実行可能だったのかどうかに完全に依存し、正直な答えは、おそらくそうではなかった、というものだ。v2 の設計は、経済的にすでに存在していた許可制を、単に形式化しているだけなのかもしれない。
このセクションには2つの留保がある。第一に、ガーブル回路が正しく構築されたことを証明するのに、Citrea によれば現在約14日を要し、チームはこれを短縮しようと取り組んでいるとしている。セットアップの手順が週単位で測られるということは、参加者集合をどのくらいの頻度で変更できるかを制約する。第二に、この分析のきっかけとなったトピックは、BitVM3 が最悪ケースのディスピュートコストをおよそ1,000倍、約5ドル程度まで削減すると述べている。私たちが取得した BitVM3 の論文は読み取り可能なテキストとして解析できず、この数値を出典があるものとして再掲することはしない。方向性自体は、Citrea 自身の数値と、House of ZK による並行する取り組みのまとめによって十分裏付けられている。それには Alpen の Glock、ガーブルロックと指定検証者向け SNARK を用いて BitVM2 に対し数百倍の効率向上を主張していると同資料が特徴づけるもの、そして同様のコスト削減を追求する Ideal の Argo が含まれる。いずれにせよ、ディスピュートのドル建て金額は、プロトコルの性質というより手数料環境についての言明にすぎない。本質的な問いは、攻撃者が意図的に引き起こす混雑状況において、ディスプルーブのコストがブロック容量に対してどれだけかということだ。
TOOP とフロート問題
ガーブル回路が攻撃するのはディスピュートのコストだ。オペレータが流動性を前渡ししなければならないという要件については、これとは別の問題であり、別に提案された解決策がある。
Fairgate Labs が構築した TOOP は、オペレータがユーザーに先に支払う必要がないよう払い戻しの構造を組み替える。セットアップ時に、オペレータはオペレータ集合のあらゆる部分集合をカバーする払い戻しトランザクションに事前署名しておく。引き出し時には、オペレータは秘密鍵を暗号化してユーザーに送り、ユーザーは署名者の部分集合を選んで自ら支払いを組み立てる。オペレータの役割は、資本を前渡しすることから、すでにロックされている資本への請求権を承認することへと変わる。
あらゆる部分集合について事前署名することは組み合わせ論的にコストがかかり、資料はその結果生じる上限を明記していないが、そのスケーリングはオペレータ集合の規模に対して実用上の厳しい天井が存在することを示唆している。これは、参加をより容易にすることを意図した仕組みから生じる N への制約であり、設計が成熟していく過程で精査に値する。TOOP 自体がどれほど成熟しているかも、私たちにはわからない。Clementine の文脈以外での監査や導入事例は見つからなかった。
まとめると、v2 は両方の資本要件を同時に狙っている。ガーブル回路は、不正を罰則可能にするためにオペレータが供託しなければならない額を減らし、TOOP は、引き出しを迅速にするためにオペレータが保有しなければならない額を減らす。両方が謳い通りに機能すれば、オペレータの役割は十分に安くなり、N をより大きく、より多様にできるようになる。それこそが、1-of-N が形を変えただけの前提ではなく、より強い前提になるための唯一の道筋だ。v2 が出荷された際に検証すべきなのは、トランザクションサイズの数値ではなく、この論点だ。
Clementine を旧来のブリッジ設計と並べてみると
ブリッジ設計を比較する際に有用な軸は、スループットでも対応チェーン数でもない。裏付け資産が無傷であり続けるためにどの当事者が正しく振る舞わなければならないか、そして引き出しが完了するためにどの当事者が存在しなければならないか、という軸だ。この2つはしばしば異なる当事者であり、両者を混同することが、実態以上に安全だとブリッジが説明されてしまう原因になる。以下の表は私たちによる整理であり、出典に基づくベンチマークではない。
| 設計 | 資産の裏付けが保たれるために誰が正直でなければならないか | 出口のために誰が存在しなければならないか | 失敗の兆候 |
|---|---|---|---|
| カストディアル型ラップド BTC | カストディアン | カストディアン | 準備金が使い込まれるか凍結され、保有者はオフチェーンの開示によってそれを知る |
| フェデレーテッドペグ (n-of-m) | m人のうち共同で行動する任意のn人の署名者 | 同じn人の署名者 | クォーラムが未許可の支出に署名する、あるいはn人未満しか連絡が取れなくなりペグが停止する |
| オフチェーンアテステーション型ブリッジ | リモートイベントを証言するオラクルとリレイヤーの集合 | 同じ集合 | 発生していないイベントに対して送金先チェーンがミントし、検証を委任していたため送金先チェーンはそれを検知できない |
| BitVM2 ブリッジ (Clementine v1) | 特定の当事者はなく、1人の正直なチャレンジャーが時間内に行動すれば足りる | 担保とフロートを持つオペレータ、および稼働中のチャレンジャー集合 | ウィンドウ内に誰も異議を申し立てず、虚偽の主張が確定してしまう |
一番下の行における構造的な変化は、いかなる特定の当事者も一方的に支出を承認できないという点だ。ビットコインはディスピュートの結果を強制執行し、事前署名済みグラフは、セットアップ時に署名されなかったすべての分岐を封じる。これはまさに、House of ZK の分析が本物のビットコインL2とサイドチェーンを区別するために用いる性質だ。オペレータや委員会がオフラインになろうと、悪意を持とうと、非協力的であろうと、ユーザーがビットコインのコンセンサスルールの下で出られる場合に限り、そのシステムはその呼称に値する。
この変化は失敗を消し去るのではなく、その所在を移すだけでもある。フェデレーションの失敗にはクォーラムによる能動的な決定が必要だ。ディスピュートゲームの失敗には、不在で足りる。不在は組織される必要がなく、協調の痕跡も残らず、そして攻撃者が人為的に作り出せる条件、すなわち手数料の混雑とインフラの負荷、とちょうど相関する。この比較はどんな妥当な重み付けをしても BitVM2 に有利だが、「信頼される当事者は存在しない」という言葉が示唆するほどには有利ではない。
もう1つ、注目に値する非対称性がある。フェデレーテッドペグの下では、供託担保は準備金に対して大きくなければならない。共謀するクォーラムの見返りは準備金そのものであり、コストは供託額だからだ。BitVM2 の下では見返りの構造が異なる。ディスプルーブされたオペレータは盗んで罰せられるのではなく、盗むのに失敗して罰せられる。ディスプルーブパスが払い戻しの取得そのものを阻止するからだ。したがって担保は、準備金全体の価値に対してではなく、グリーフィングと運用上の不正行為に対して価格づけられる。損失関数は不連続だ。1人の正直なウォッチタワーが行動すれば、損失はほぼゼロになる。誰も行動しなければ、損失はグラフがオペレータに許す請求額によって上限が定まる。すべては、このシステムが不連続点のどちら側に着地するかにかかっており、担保のサイズ設定はその境界を動かさない。
事前署名済みグラフと欠けているコベナント
これまで論じてきた構造的な制約はすべて、同じ欠けているプリミティブに行き着く。ビットコインが「このアウトプットはこのテンプレートに一致するトランザクションによってのみ使用可能」と表現できないため、Clementine は事前署名によってコベナントを近似せざるを得ない。この結果は複合的に効いてくる。参加者集合は儀式の時点で固定される。ローテーションには新たな儀式が必要になる。事前署名済みの成果物の数は、ラウンドの数や TOOP における部分集合の組み合わせとともに増大する。そして仕組み全体の安全性は、事後に外部の観察者が検証できない儀式の衛生管理に依存する。
CheckTemplateVerify があれば、アウトプットは許可された使用先トランザクションのハッシュに直接コミットできるようになり、その制約はコンセンサスによって強制される、署名集合の完全性によって強制されるのではなく。CheckSigFromStack があれば、スクリプトが任意のメッセージに対する署名を検証できるようになり、現在は事前署名済みの分岐に焼き込まれるしかない委任やアテステーションのパターンが開ける。どちらも有効化されておらず、私たちが確認した資料のいずれも、これらが有効化された場合に Clementine の具体的な構成がどう簡素化されるかを論じていない。言えるのは、この設計の中で最もスケールしにくい部分、すなわち儀式の所要時間、部分集合の事前署名、参加者集合の硬直性が、まさに事前署名がコンセンサスによる強制の代替として存在しているために生じている、ということだ。もしコベナントが有効化されれば、興味深い問いはディスピュートが安くなるかどうかではなく、N が流動的になり得るかどうかだ。
失敗の形
4つの異なる失敗モードを区別する価値がある。それぞれ発生確率も、被害を受ける当事者も異なるからだ。
稼働率の失敗は、この設計が明示的に受け入れているベースケースだ。オペレータが虚偽の主張をし、誰もチャレンジャーとして時間内に異議を唱えず、払い戻しが確定する。準備金は主張された金額の分だけ不足する。すでに出金したユーザーは BTC を手元に残す。その不足分は、ペグ資産を保有し続ける残りの保有者にのしかかり、おそらく部分準備という形になるが、私たちが確認したどの資料も、そのような不足がどう配分されるか、あるいは何らかのバックストップが存在するかを説明していない。
ディスピュート経済性の失敗は、原因のある稼働率の失敗だ。ビットコインの手数料が十分に上がり、数メガバイトのディスプルーブトランザクションがウィンドウ内に確定できなくなれば、正直で注意深いチャレンジャーも締め出される。ガーブル回路の取り組みはこれを直接標的にしており、出荷されれば独立したリスクとしてはほぼ解消される。それまでは、稼働中のシステムはこのリスクを抱え続ける。
全面共謀の失敗は、システムをフェデレーテッドペグの意味論へと引き戻す。資料は対抗策を記述しておらず、私たちも何らかの対抗策が存在すると想定しない。
構成の失敗は、1-of-N の枠組みがまったく扱っていないものだ。トランザクショングラフが誤って署名されていたり、存在すべきでない分岐が存在していたり、儀式で鍵が漏洩していたりすれば、正直なウォッチタワーには異議を唱えるものが何もない。窃取が有効な支出になってしまうからだ。これは監査の複雑性という制約であり、スマートコントラクトの監査とは違う。事前署名済みトランザクショングラフのプロトコルスタック全体をレビューする作業だ。私たちは、Clementine v1 の実際の展開について、チーム自身の設計文書とは別の独立したセキュリティ評価が公開されているのを見つけられなかった。
外部者がこれらのリスクを価格づけるために必要なパラメータは、私たちが確認した資料の中では公開されていない。ウォッチタワーの数、選定と解任のプロセス、チャレンジウィンドウの期間、BTC建ての担保要件、そしてブリッジ準備金とオペレータ担保合計の比率だ。待つ価値があるのは、次の効率化倍率よりも、こうした開示のほうだ。ディスプルーブトランザクションのコストが数ドルまで下がっても、チャレンジャー集合が単一の法域にある3社に過ぎないブリッジは、コスト曲線を動かしただけで、信頼の境界は動かしていない。
References
- R&D for Clementine v2: Eliminating Collateral and Liquidity Requirements with Garbled Circuits and TOOP, Citrea
- Bitcoin L2s in 2026: A Reality Check, House of ZK
- BitVM3 paper (we were unable to extract readable text from the retrieved file)
引言
把 BTC 锁进 Citrea 桥的存款人,并不是在请求一个签名委员会把币还给自己。托管问题已经被替换成了一个警惕性问题:当某个操作者提交虚假声明的那一刻,一个受许可看门人（watchtower）集合中,是否至少有一个成员正在运行、有资金、且行为正确?2026年1月27日,这种替换正式进入生产环境。Citrea 宣布主网上线,定位围绕借贷、交易和结算展开,原生桥为 Clementine,底层机制是 BitVM2。第二天,GOAT Network 在同一原语上开放了公开测试网 V3,强调无需许可的退出。
这个区分很重要,因为这两类问题失败的方式不同。联盟机制的失败,发生在足够多成员决定作恶,或者足够多密钥被盗取的时候。争议博弈的失败,发生在没有人出面应对的时候。前者是攻击者的协调问题。后者是防守方的在线率问题,而在线率的下降往往与恶意无关:手续费飙升、监控中断、软件配置错误,或者操作者的数据源恰好在关键窗口期失效。
Citrea 目前上线的是 Clementine v1,值得认真对待的信任最小化说法,也应该专门针对 v1 本身。Clementine v1 使用基于 BitVM2 脚本的争议机制,要求操作者锁定抵押品,并要求操作者在获得偿付之前先用自己的资产负债表垫付用户提款。比特币研究圈内流传的更高效构造,包括 Citrea 自家基于混淆电路和 TOOP 的 Clementine v2 设计,明确还处于研究阶段。Citrea 将 v2 描述为主网上线后计划推出的第一个升级。这不是今天存款人所依赖的东西。
我们的判断是:相较于此前所有被广泛使用的 BTC 桥,Clementine v1 确实是信任层面的实质性削减,但这种削减比“信任最小化”这个说法所暗示的要窄。它把一种可自由裁量的托管假设,转换成了一种针对受许可集合的在线率假设。在线率假设比托管假设更容易被审计,这是进步。但它也需要持续地被消耗:这个假设必须每天成立,在每一个挑战窗口期成立,不管比特币手续费市场当时在发生什么。
比特币能裁决什么,又从不执行什么
比特币脚本不能循环,不能在交易之间保存状态,也无法约束自己的输出该如何被花费,因为诸如 CheckTemplateVerify 和 CheckSigFromStack 这样的 covenant 操作码在主网上并未激活。直接用比特币脚本表达的 SNARK 验证器体积过大,无法装进一个区块。因此,任何类似 rollup 桥的东西,都不能靠让比特币去检查一个有效性证明来构建。
BitVM2 绕开这个问题的方式是:除非有人提出异议,否则从不要求比特币检查任何东西。操作者会就链下计算作出声明,通常是声明某个特定的 Citrea 状态是有效的,且某组特定的 peg-out 是由此推导出来的。这个声明会作为一笔 assert 交易发布到比特币链上,其中承诺了验证器执行过程的中间值。如果声明是诚实的,不会发生别的事情,操作者最终会走一条预先签署好的偿付路径。如果声明是不诚实的,挑战者会找出操作者所承诺的中间值中不一致的那一步,并花费一条 disprove 路径,该路径仅在脚本中执行那一个步骤。比特币裁决的,是一个它从未真正运行过的计算中,存在争议的一小段片段。
covenant 的缺失塑造了整个构造。因为比特币无法强制执行“这笔输出只能被某种特定形式的交易花费”,BitVM2 的设计转而在建立阶段用社会性方式来强制执行这一点。每个参与者事先对交易图中的每一个分支进行签名,而没有被签名的分支根本不存在,不构成可花费的选项。因此,这张图的安全性取决于建立仪式本身:是否对正确的一组交易签署了正确的一组签名,而不想要的变体的签名密钥从未被生成。这是一种和智能合约完全不同的失效面,也是 House of ZK 分析将其列为 BitVM2 类设计在生产环境中三大硬约束之一的原因,另外两个是争议经济学和运营在线率。
由此可以推出两个特性。第一,参与者集合在图被签署时就已固定。新增或轮换操作者不是一笔治理交易,而是一次全新的仪式。第二,诚实路径的成本很小,而有争议路径的成本很大,因为 disprove 分支必须携带足够的数据,才能让比特币重新执行有争议的那一步。在最初规范的 BitVM2 中,disprove 交易的体积达到约 4MB,相当于把整个比特币区块的容量都花在了一个论证上。下文所述的效率优化工作,几乎全部针对这个数字。
一个诚实的参与者,永久待命
“1-of-N”这个说法是准确的,但也是不完整的。从操作层面展开来说,这个假设是:在攻击发生的那一刻,N 个参与者中至少有一个同时满足以下所有条件:诚实;运行的基础设施足以同时观察比特币和 Citrea,并能察觉不一致的声明;持有或能够重建构建 disprove 见证所需的建立阶段数据;能支付将一笔大交易确认所需的比特币手续费;并且这一切都发生在协议规定的、时长事先固定的挑战窗口之内。
每一个条件都是一种独立的失败方式。一个节点已经过时的诚实参与者会失败。一个诚实、监控良好,但在手续费飙升期间无法把一笔数兆字节的交易打包进区块的参与者会失败。一个诚实、清醒、有资金,却在窗口关闭后一个区块才发现欺诈的参与者也会失败。House of ZK 的分析说得很直白:1-of-N 诚实挑战者假设,本质上是一个在线率和监控要求。密码学本身不能弥补一个空无一人的看门人集合。
合谋会以一种特定的方式使这个模型退化。当 N-1 个参与者合谋时,安全性在原则上仍然成立,因为一个诚实的挑战者仍然可以提出反证。但在实践中,那最后一个诚实参与者的边际价值,现在等同于整个桥的储备金,这就把攻击者的算计从“偷窃”变成了“找出并使那一个特定的对手方失效”。使其失效不需要在密码学层面攻破它,只需要让它错过一个窗口期即可,这个门槛要低得多。如果所有操作者和所有看门人都合谋,我们所参考的资料没有描述任何补救措施,我们将这种场景在功能上等同于联盟机制被攻破。
许可制正是让这种分析变得令人不安的原因。Citrea 将 Clementine 的网络描述为受许可的,而正是这种许可制才使得 v2 的混淆电路构造成为可能,因为只有在双方集合都事先已知的情况下,才能在每个操作者和每个看门人之间准备一条专用电路。一个已知的、有界的、可枚举的挑战者集合,是一个可以被接触、施压或联合监管的集合。我们审阅的资料并未说明看门人如何被选出、谁有权增删看门人、主网上线时有多少个看门人,以及挑战窗口持续多长时间。这些参数决定了“1-of-N”究竟是一个强有力的主张,还是一个装饰性的说法,而这些参数在我们所能获得的材料中并未公开。
这里还有一个通用于乐观协议的“骚扰攻击”维度需要考虑。如果发起挑战是免费的,攻击者就可以迫使操作者反复发布昂贵的 assert 交易,单靠手续费就把他们耗尽。这一类设计通常要求挑战者在发起挑战时也要抵押一些东西,以增加发动此类攻击的成本。不管 Clementine 的具体参数是什么,这里的张力都是结构性的:提高恶意挑战的成本,同时也会提高正当挑战的成本,而整个安全论证恰恰依赖于正当的挑战能够发生。
Clementine v1:抵押品、垫付资金和一个全局停止按钮
两项要求定义了目前真正在运行的东西。根据 Citrea 自己的描述,Clementine v1 要求操作者锁定大额抵押品以使作恶付出高昂代价,并要求操作者先用自己的资金预付用户提款,事后再获得偿付。
第二项要求带来了一个容易被低估的用户体验特性。当某人从 Citrea 退出时,操作者会立即从自己的余额中给他发送 BTC。随后进行的争议博弈,与该用户拿到的支付无关。它关系的是该操作者是否有权从桥的储备金中偿付自己。用户先被兑付,裁决在他们身后进行。真正暴露在争议结果风险之下的,是储备金,也就是说是挂钩资产的剩余持有者,而不是那个已经提款的人。
这种结构会带来资本层面的后果。一个操作者必须同时抵押保证金,又要持有足够的自由 BTC 来垫付提款需求。这两笔都是闲置资本,操作者赚取的收益必须同时覆盖两者。Citrea 自己也承认,这些正是限制其可扩展性和参与去中心化程度的约束条件,也是 v2 研究的既定动机。这种经济结构会推动市场走向少数资本雄厚的操作者,而一个小的操作者集合就是一个小的 N。为保护桥的安全而存在的资本要求,恰恰也压缩了这个集合的多样性,而这个集合的多样性正是安全论证的基础。目前部署的任何东西都没有解决这一张力。
Clementine 的“轮次”结构是第三个值得理解的要素。操作者按轮次推进,在某一轮中检测到的欺诈会中止该轮的推进,并阻止下一轮开启。Citrea 将其描述为一种断路器机制,在 v2 设计中,其直接目的是效率:这意味着一条混淆电路只需在建立阶段生成一次,而不必对每一笔存款都重新生成,因为作弊的操作者无法简单地推进到下一个机会。这一机制的安全含义走得更远。一次成功的反证,并不是针对某一个坏声明的局部罚没。它会让整台机器停下来。安全性是靠“停机”来维持的,这意味着在真实的欺诈事件之后的恢复路径,是一个治理和仪式问题,而不是一个自动化的过程,而现有资料均未描述这条恢复路径究竟是什么样子。
把验证器混淆化
BitVM2 中占主导地位的成本是 disprove 交易,而 disprove 交易中占主导地位的成本,是比特币必须在脚本中重新执行有争议的那一步。Clementine v2 提议将脚本执行彻底从争议流程中移除。
该构造把一个 Groth16 SNARK 验证器编译成一个由 AND 和 XOR 门组成的布尔电路,然后对其进行混淆。混淆过程会加密每个门的真值表,使得评估者恰好能解密出每个门的一个输出标签,而无法获知其他任何信息。验证器由挑战者在链下进行评估,评估者最终会持有一个原像,而这个原像只有在操作者的声明为假时才存在。比特币随后只需检查这个原像的哈希值。disprove 交易由此变成了一段单一的哈希脚本。Citrea 报告称,相较于此前约 4MB 的 BitVM2 disprove 交易,这大约带来了 10 万倍的改进,并报告 assert 交易从 1.3MB 缩小到 80kB,在别处的表述中约为 2 万 vbytes。这些是团队针对一个尚未上线的设计给出的自有数据,我们审阅的资料中没有出现任何第三方对这些数字的基准验证。
Citrea 将利用混淆电路来降低比特币欺诈证明成本这一底层思路,归功于 Jeremy Rubin 的 Delbrag 论文,并指出了 Delbrag 所指出的权衡:链上数据更少,但参与者之间需要交换更多带外信息。这种权衡带有治理层面的形态。混淆电路从构造上就是“指定验证者”式的。混淆方是为特定的评估者准备电路的,因此 Clementine 的设计会在每个操作者和每个看门人之间建立一条专用电路,由此形成一张操作者与看门人一一对应的建立图谱。Citrea 表示,这将模型简化为看门人之间一个简单的 1-of-N 诚实假设。
这也缩小了谁能够发起争议的范围。在基于脚本的 BitVM2 中,任何能够构造出见证的人都可以走 disprove 路径,因为比特币本身会检查有争议的计算,而这种检查具有普遍可验证性。在混淆电路方案下,只有持有与该特定操作者预先建立好的电路的一方,才能生成对应的原像。更便宜的争议是以一个被更明确枚举出来的挑战者集合为代价换来的。这究竟是不是净损失,完全取决于那条 4MB 的脚本路径,在手续费飙升期间,是否真的曾经现实可行地被一个非关联的外部人执行过,而诚实的答案很可能是并没有。v2 设计或许只是把一种早已在经济层面存在的许可制正式化而已。
这一部分还有两点需要说明。第一,根据 Citrea 的说法,证明混淆电路被正确构造出来目前大约需要 14 天,团队表示正在设法缩短这个时间。一个以周为单位的建立步骤,限制了参与者集合能够变动的频率。第二,促成本文分析的话题中,把最坏情况下争议成本降低约 1000 倍(降到约五美元)归功于 BitVM3。我们检索到的 BitVM3 论文无法解析出可读文本,因此我们不会把这些数字当作有出处的说法重复陈述。这个方向大体上能得到 Citrea 自己的数据,以及 House of ZK 对若干平行工作的总结的支持,其中包括 Alpen 的 Glock,该资料将其描述为声称利用混淆锁(garbled locks)和指定验证者 SNARK,相较 BitVM2 实现数百倍的效率提升,以及 Ideal 的 Argo 也在追求类似的成本削减。无论如何,某次争议的美元成本本身说的是一个特定手续费环境下的情况,而不是协议的固有属性。真正相关的问题是,相较于攻击者会刻意制造的拥堵状况下的区块容量,disprove 的成本占多大比例。
TOOP 与垫资问题
混淆电路解决的是争议成本问题。它无法解决操作者必须垫付流动性这一要求,这是一个独立的问题,有一个独立的拟议解法。
由 Fairgate Labs 构建的 TOOP,重新设计了偿付流程,使操作者无需先垫付用户资金。在建立阶段,操作者会预先签署覆盖操作者集合每一个子集的偿付交易。在提款时,操作者将私钥加密并发送给用户,由用户选择一个签名者子集,并自行组装出支付交易。操作者的角色由“垫付资本”转变为“对已经锁定的资本上的一项索取权进行授权”。
针对每个子集都预先签名,组合复杂度极高,尽管资料中没有说明由此产生的具体边界,但这种规模增长意味着操作者集合的规模存在一个硬性的实际上限。对于一个本意是让参与更容易的机制来说,这反而对 N 构成了约束,随着设计的成熟,这一点值得关注。TOOP 本身的成熟度对我们来说也是未知的。我们没有找到在 Clementine 语境之外,针对 TOOP 的任何审计或部署案例。
综合来看,v2 同时瞄准了两项资本要求:混淆电路降低了操作者为了让不诚实行为可被惩罚而必须抵押的数额,TOOP 降低了操作者为了让提款快速完成而必须持有的数额。如果两者都能按描述的那样发挥作用,操作者这个角色就会变得足够廉价,从而使 N 能够变得更大、更多样化,而这是让“1-of-N”变成一个更强的假设,而不仅仅是换了个形态的假设的唯一途径。这才是 v2 上线后应该被检验的论点,而不是那些交易体积数字。
Clementine 相较于旧式桥设计的位置
比较各种桥设计时,有用的评判轴不是吞吐量或支持的链数量。而是:哪一方必须行为正确,储备才能保持完整;以及哪一方必须在场,提款才能完成。这往往是两个不同的角色,而把二者混为一谈,正是桥被描述得比实际更安全的原因。下表是我们自己的归纳整理,不是有出处的基准数据。
| 设计 | 要让资金维持挂钩,谁必须诚实 | 要完成退出,谁必须在场 | 失败特征 |
|---|---|---|---|
| 托管型包装 BTC | 托管方 | 托管方 | 储备被挪用或冻结;持有者通过链下披露才得知 |
| 联盟制锚定(n-of-m) | m 个签名者中的任意 n 个共同行动 | 同样的 n 个签名者 | 一个法定人数联合签署了未经授权的支出,或可触达的签名者不足 n 个,锚定机制随之停摆 |
| 链下证明桥 | 对远端事件进行证明的预言机和中继者集合 | 同样的一组人 | 目标链针对一个从未发生过的事件进行了铸造;目标链无法察觉,因为验证工作被外包出去了 |
| BitVM2 桥(Clementine v1) | 没有特定的一方,只要有一个诚实的挑战者及时行动即可 | 一个持有抵押品和垫付资金的操作者,加上一个活跃的挑战者集合 | 一个虚假声明最终生效,因为没有任何挑战者在窗口期内提出异议 |
最下面一行的结构性变化在于:没有任何一个具名的角色可以单方面授权一笔支出。比特币强制执行争议的结果,而预先签署好的图谱排除了所有在建立阶段未被签署的分支。这正是 House of ZK 分析用来区分真正的比特币 L2 和侧链的那个属性:只有当用户能够在比特币的共识规则下退出,即便操作者和委员会离线、作恶或不配合,系统才配得上这个标签。
这种变化也只是把失败搬到了别处,而没有消除它。联盟机制的失败,需要一个法定人数主动做出决定。争议博弈的失败,只需要一种缺席。缺席不需要组织,不会留下协调的痕迹,而且恰好与攻击者能够人为制造的条件相关联,也就是手续费拥堵和基础设施压力。无论怎么权衡,这个对比都对 BitVM2 有利,但有利的程度,比不上“无需信任任何一方”这句话所暗示的那么大。
还有一个不对称之处值得关注。在联盟制锚定下,抵押品必须相对于储备金规模而言足够大,因为一个合谋的法定人数的收益是整个储备金,而他们的成本仅是那笔保证金。在 BitVM2 下,收益结构则不同:一个被反证的操作者不是“偷到了钱然后被惩罚”,而是“没能偷到钱、还被惩罚”,因为 disprove 路径会直接阻止偿付被领取。因此,抵押品的定价针对的是骚扰攻击和运营不当行为,而不是针对储备金的全部价值。损失函数是不连续的:如果有一个诚实的看门人行动了,损失大致为零;如果没有一个行动,损失则以图谱允许操作者索取的金额为上限。一切都取决于系统落在这个不连续点的哪一侧,而抵押品规模的大小并不能移动这条分界线。
预签名的图谱,缺席的 Covenant
上文讨论的每一个结构性约束,都能追溯到同一个缺失的原语。因为比特币无法表达“这笔输出只能被匹配某个模板的交易花费”,Clementine 只能通过预先签名来近似实现 covenant。由此产生的后果会不断累积:参与者集合在仪式阶段就已固定,轮换需要重新举行仪式,预签名产物的数量会随着轮次的增加以及 TOOP 下子集组合的增多而增长,而整套安排的安全性,取决于仪式过程的严谨程度,而这一点在事后是无法被任何链上观察者验证的。
CheckTemplateVerify 能让一笔输出直接承诺其被允许的花费交易的哈希值,这样一来,该约束就能由共识机制强制执行,而不是依赖于一整套签名的完备性。CheckSigFromStack 则能让脚本验证针对任意消息的签名,从而开启目前必须硬编码进预签名分支中的委托和证明模式。这两者都尚未激活,而且我们审阅过的资料都没有讨论,如果它们被激活,Clementine 具体的构造会如何被简化。我们能说的是,这个设计中扩展性最差的那些部分,即仪式时长、子集预签名,以及参与者集合的僵化程度,恰恰都是因为预签名在替代共识层面的强制执行才存在的。如果 covenant 被激活,值得关注的问题就不再是争议是否会变得更便宜,而是 N 能否变得可流动。
失败的形态
有四种截然不同的失败模式值得区分,因为它们发生的概率不同,受害者也不同。
在线率失败,是这个设计明确接受的基本情形。一个操作者作出虚假声明,没有挑战者在时限内提出异议,偿付最终生效。储备金因此短缺相应金额。那些已经退出的用户仍然持有他们的 BTC。这个缺口落在挂钩资产的剩余持有者身上,大概会以部分准备金的形式体现,尽管我们审阅的资料都没有说明这样的缺口该如何分摊,也没有说明是否存在任何后备保障机制。
争议经济学失败,是一种有明确成因的在线率失败。如果比特币手续费上涨到一定程度,以至于一笔数兆字节的 disprove 交易无法在窗口期内被确认,即便是诚实且警觉的挑战者也会被挤出局。混淆电路方面的工作正是针对这一点,如果它成功上线,基本上可以把这个问题从独立风险中消除。但在此之前,现行系统仍然携带着这个风险。
全面合谋失败,会让系统退化为联盟制锚定的语义。资料中没有描述任何补救措施,我们也不假设存在任何补救措施。
构造失败,是“1-of-N”框架完全没有涉及的一种。如果交易图被错误地签署了,或者存在一个本不应该存在的分支,又或者仪式过程泄露了某个密钥,那么诚实的看门人根本没有什么可以反证的,因为那笔盗窃在形式上是一笔有效的支出。这属于审计复杂性方面的约束,而且这不是一次智能合约审计,而是对整个预签名交易图协议栈的审查。除了团队自己的设计文档之外,我们没有找到任何针对已部署的 Clementine v1 的独立安全评估。
在我们审阅的资料中,能让外部人士对这些风险进行定价的参数并未公开:看门人的数量、选拔和罢免流程、挑战窗口的时长、以 BTC 计价的抵押品要求,以及桥储备金与操作者总抵押品之间的比例。比起下一个效率倍数,这些才是更值得等待的信息披露。一座 disprove 交易只需几美元、但挑战者集合只是同一司法辖区内三家公司的桥,只是移动了成本曲线,而没有移动信任边界。
参考资料
- R&D for Clementine v2: Eliminating Collateral and Liquidity Requirements with Garbled Circuits and TOOP,Citrea
- Bitcoin L2s in 2026: A Reality Check,House of ZK
- BitVM3 论文(我们未能从检索到的文件中提取出可读文本)
Introducción
Un depositante que bloquea BTC detrás del bridge de Citrea no le está pidiendo a un comité firmante que se lo devuelva. La pregunta sobre la custodia ha sido reemplazada por una pregunta sobre vigilancia: ¿estará al menos un miembro de un conjunto permisionado de watchtowers activo, financiado y en lo correcto en el momento en que un operador presente una reclamación falsa? El 27 de enero de 2026 esa sustitución entró en producción. Citrea anunció su mainnet en vivo, posicionada en torno a préstamos, trading y liquidación, con Clementine como su bridge nativo y BitVM2 como el mecanismo subyacente. Un día después, GOAT Network abrió una Testnet V3 pública sobre la misma primitiva, con énfasis en la salida sin permisos.
La distinción importa porque las dos preguntas fallan de formas distintas. Una federación falla cuando suficientes miembros deciden robar, o cuando les roban suficientes claves. Un juego de disputa falla cuando nadie se presenta. La primera es un problema de coordinación para los atacantes. La segunda es un problema de uptime para los defensores, y el uptime se degrada por razones que no tienen nada que ver con la malicia: picos de comisiones, caídas de monitoreo, software mal configurado o un feed de datos del operador que queda desactualizado justo en la ventana en que importaba.
Lo que está en vivo en Citrea es Clementine v1, y las afirmaciones sobre minimización de confianza que vale la pena tomar en serio son las que aplican específicamente a v1. Clementine v1 usa disputas basadas en scripts de BitVM2, exige que los operadores bloqueen colateral y exige que los operadores prefinancien los retiros de los usuarios desde sus propios balances antes de ser reembolsados. Las construcciones más eficientes que circulan en la investigación sobre Bitcoin, incluido el propio diseño de Citrea para Clementine v2 basado en circuitos garbled y TOOP, están explícitamente en etapa de investigación. Citrea describe v2 como la primera actualización planeada después del lanzamiento de mainnet. No es en lo que se apoyan los depositantes de hoy.
Nuestra lectura es que Clementine v1 representa una reducción genuina de confianza respecto a todos los bridges de BTC ampliamente usados que lo precedieron, y que esa reducción es más estrecha de lo que sugiere la frase “trust-minimized”. Convierte un supuesto de custodia discrecional en un supuesto de liveness sobre un conjunto permisionado. Los supuestos de liveness son auditables de una manera en que los supuestos de custodia no lo son, lo cual es un avance. También son de consumo continuo: el supuesto tiene que sostenerse todos los días, en cada ventana de disputa, bajo lo que sea que esté haciendo el mercado de comisiones de Bitcoin en ese momento.
Lo que Bitcoin arbitra, y lo que nunca ejecuta
El script de Bitcoin no puede hacer loops, no puede mantener estado entre transacciones, y no puede restringir cómo se gastan sus propios outputs, porque los opcodes de covenants como CheckTemplateVerify y CheckSigFromStack no están activos en mainnet. Un verificador SNARK expresado directamente en script de Bitcoin es demasiado grande para caber en un bloque. Cualquier cosa parecida a un bridge de rollup, por lo tanto, no puede construirse pidiéndole a Bitcoin que verifique una prueba de validez.
BitVM2 evita esto no pidiéndole nunca a Bitcoin que verifique nada, a menos que alguien objete. Un operador hace una afirmación sobre un cómputo off-chain, típicamente que un estado particular de Citrea es válido y que un conjunto particular de peg-outs se deriva de él. La afirmación se publica en Bitcoin como una transacción assert que compromete los valores intermedios de la ejecución de un verificador. Si la afirmación es honesta, no pasa nada más y el operador eventualmente gasta una ruta de reembolso presignada. Si la afirmación es deshonesta, un challenger identifica el paso específico donde los valores intermedios comprometidos por el operador son inconsistentes y gasta una ruta de disprove que ejecuta únicamente ese paso en script. Bitcoin arbitra un único fragmento disputado de un cómputo que nunca ejecutó.
La ausencia de covenants moldea toda la construcción. Como Bitcoin no puede imponer “este output solo puede gastarse mediante una transacción con la siguiente forma”, los diseños BitVM2 lo imponen socialmente en el momento del setup. Cada participante firma de antemano cada rama de un grafo de transacciones, y las ramas no firmadas simplemente no existen como opciones gastables. La seguridad del grafo depende, por lo tanto, de la ceremonia de setup: el conjunto correcto de firmas sobre el conjunto correcto de transacciones, sin que se generen jamás claves de firma para variantes no deseadas. Esta es una superficie de fallo muy distinta a la de un contrato inteligente, y es el origen de la preocupación por la complejidad de auditoría que el análisis de House of ZK marca como una de tres restricciones duras para los diseños tipo BitVM2 en producción, junto con la economía de las disputas y el liveness operacional.
De ahí se derivan dos propiedades. Primero, el conjunto de participantes queda fijo cuando se firma el grafo. Agregar o rotar un operador no es una transacción de gobernanza sino una nueva ceremonia. Segundo, el costo de una ruta honesta es pequeño y el costo de una ruta disputada es grande, porque la rama de disprove tiene que cargar suficientes datos para que Bitcoin pueda reejecutar el paso disputado. En BitVM2 tal como se especificó originalmente, esa transacción de disprove llega a ocupar aproximadamente 4MB, lo cual es un bloque completo de capacidad de Bitcoin gastado en un solo argumento. El trabajo de eficiencia descrito más abajo apunta casi por completo a ese número.
Una parte honesta, permanentemente de guardia
El marco 1-de-N es correcto pero incompleto. Descrito en términos operativos, el supuesto es que al menos un participante entre N satisface simultáneamente todo lo siguiente en el momento de un ataque: es honesto; opera infraestructura que observa tanto Bitcoin como Citrea con suficiente detalle para detectar una afirmación inconsistente; posee o puede reconstruir los datos de setup necesarios para construir un testigo de disprove; puede pagar las comisiones de Bitcoin requeridas para conseguir que una transacción grande se confirme; y hace todo esto dentro de una ventana de disputa definida por el protocolo cuya duración está fijada de antemano.
Cada condición es una forma distinta de fallar. Un participante honesto con un nodo desactualizado falla. Un participante honesto y bien monitoreado que no puede meter una transacción de varios megabytes en un bloque durante un pico de comisiones falla. Un participante que es honesto, está despierto y financiado pero descubre el fraude un bloque después de que la ventana se cerró, falla. El análisis de House of ZK lo plantea sin rodeos: el supuesto del challenger honesto 1-de-N es en realidad un requisito de uptime y monitoreo. Nada en la criptografía compensa un watchtower vacío.
La colusión degrada el modelo de una manera específica. Con N-1 participantes coludidos, la seguridad se mantiene intacta en principio, porque un único challenger honesto todavía puede hacer el disprove. En la práctica, el valor marginal de ese último participante honesto es ahora la reserva completa del bridge, lo cual cambia el cálculo del atacante de “robar” a “identificar y neutralizar a una contraparte específica”. Neutralizar no requiere comprometerla criptográficamente. Requiere hacer que se pierda una ventana, lo cual es un umbral mucho más bajo. Si todos los operadores y todos los watchtowers se coluden, las fuentes disponibles no describen ningún recurso, y tratamos ese escenario como funcionalmente equivalente al compromiso de una federación.
El carácter permisionado es lo que vuelve incómodo este análisis. Citrea describe la red de Clementine como permisionada, y es justamente el permisionamiento lo que hace viable la construcción de circuitos garbled de v2, ya que un circuito dedicado solo puede prepararse entre cada operador y cada watchtower si ambos conjuntos se conocen de antemano. Un conjunto de challengers conocido, acotado y enumerable es un conjunto que puede ser abordado, presionado o regulado en bloque. Las fuentes que revisamos no especifican cómo se seleccionan los watchtowers, quién puede agregarlos o quitarlos, cuántos existen en mainnet, ni cuánto duran las ventanas de disputa. Esos parámetros determinan si 1-de-N es una afirmación sólida o meramente decorativa, y no son públicos en el material que tuvimos disponible.
También hay una dimensión de griefing que los protocolos optimistas en general tienen que tarifar. Si disputar es gratis, un adversario puede forzar a los operadores a publicar transacciones assert costosas repetidamente y drenarlos solo mediante comisiones. Los diseños de esta familia normalmente exigen que el challenger deposite algo al momento de disputar para encarecer ese ataque. Cualesquiera que sean los parámetros específicos de Clementine, la tensión es estructural: subir el costo de una disputa frívola también sube el costo de una legítima, y son las disputas legítimas de las que depende todo el argumento de seguridad.
Clementine v1: colateral, float y un botón de parada global
Dos requisitos definen lo que realmente está funcionando. Según la propia descripción de Citrea, Clementine v1 exige que los operadores bloqueen colateral grande para que la malicia resulte costosa, y exige que los operadores prepaguen los retiros a los usuarios por adelantado y cobren el reembolso después.
El segundo requisito produce una propiedad de la experiencia de usuario que suele pasarse por alto. Cuando alguien sale de Citrea, un operador le envía BTC desde su propio balance de inmediato. El juego de disputa que sigue no trata sobre el pago del usuario. Trata sobre si ese operador tiene derecho a reembolsarse a sí mismo desde la reserva del bridge. Al usuario se le paga primero y la adjudicación ocurre a sus espaldas. La parte expuesta al resultado de la disputa es la reserva, es decir, los tenedores restantes del activo pegged, no la persona que retiró.
Esa estructura tiene una consecuencia de capital. Un operador debe simultáneamente depositar colateral vinculado y mantener suficiente BTC libre para adelantar la demanda de retiros. Ambas cosas son capital ocioso, y el rendimiento que gana un operador tiene que cubrir ambas. La propia Citrea identifica estas como restricciones que limitaron la escalabilidad y la participación descentralizada, lo cual es la motivación declarada para la investigación de v2. La economía empuja hacia un número pequeño de operadores bien capitalizados, y un conjunto pequeño de operadores es un N pequeño. Los requisitos de capital que existen para asegurar el bridge también comprimen la diversidad del conjunto cuya diversidad es el argumento de seguridad. Esa tensión no está resuelta por nada de lo que hoy está desplegado.
La estructura por rondas de Clementine es el tercer elemento que vale la pena entender. Los operadores avanzan a través de rondas, y un fraude detectado en una ronda detiene el avance y bloquea la apertura de la siguiente ronda. Citrea lo describe como un circuit breaker, y su propósito inmediato en el diseño de v2 es la eficiencia: significa que un circuito garbled puede establecerse una sola vez en el setup en lugar de regenerarse por cada depósito, porque un operador tramposo no puede simplemente pasar a la siguiente oportunidad. La implicación de seguridad va más allá. Un disprove exitoso no es un slash localizado contra una afirmación mala. Detiene la máquina. La seguridad se preserva deteniendo el sistema, lo cual significa que la ruta de recuperación tras un evento de fraude genuino es un problema de gobernanza y de ceremonia, no algo automático, y ninguna de las fuentes disponibles describe cómo luce esa ruta.
Garblear al verificador
El costo dominante en BitVM2 es la transacción de disprove, y el costo dominante dentro de la transacción de disprove es que Bitcoin tiene que reejecutar un paso disputado en script. Clementine v2 propone eliminar por completo la ejecución de script de la disputa.
La construcción compila un verificador SNARK Groth16 en un circuito booleano de compuertas AND y XOR, y luego lo garbelea. El garbling encripta la tabla de verdad de cada compuerta de modo que el evaluador pueda descifrar exactamente una etiqueta de salida por compuerta y no aprenda nada más. El verificador se evalúa off-chain por el challenger, quien termina poseyendo una preimagen de salida que solo existe si la afirmación del operador era falsa. Bitcoin entonces verifica un hash de esa preimagen. La transacción de disprove se convierte en un único script de hashing. Citrea reporta esto como una mejora de aproximadamente 100.000x respecto a la anterior transacción de disprove de BitVM2 de ~4MB, y reporta que la transacción assert se reduce de 1.3MB a 80kB, cifra expresada en otro lugar como aproximadamente 20k vbytes. Estas son cifras propias del equipo para un diseño que aún no se ha lanzado, y ningún benchmark de terceros aparece en el material que revisamos.
Citrea le atribuye al paper Delbrag de Jeremy Rubin la idea subyacente de usar circuitos garbled para pruebas de fraude más baratas en Bitcoin, y señala el trade-off que identifica Delbrag: menos datos on-chain, más intercambio fuera de banda entre participantes. Ese trade-off tiene una forma de gobernanza. Un circuito garbled es, por construcción, de verificador designado. La parte que garbelea lo prepara para un evaluador específico, de modo que el diseño de Clementine establece un circuito dedicado entre cada operador y cada watchtower, produciendo un grafo de configuraciones operador-por-watchtower. Citrea dice que esto reduce el modelo a un supuesto simple de 1-de-N honesto entre watchtowers.
Esto también estrecha quién puede disputar. En BitVM2 basado en scripts, la ruta de disprove es ejecutable por cualquiera que pueda construir el testigo, porque el propio Bitcoin verifica el cómputo disputado y la verificación es universalmente comprobable. Bajo el garbling, solo una parte que posea un circuito preestablecido con ese operador específico puede producir la preimagen. Las disputas más baratas se compran con un conjunto de challengers más explícitamente enumerado. Que eso sea una pérdida neta depende enteramente de si la ruta de script de 4MB alguna vez fue realmente ejecutable por un tercero sin afiliación durante un pico de comisiones, y la respuesta honesta es que probablemente no lo era. El diseño de v2 puede estar formalizando un permisionamiento que ya existía económicamente.
Dos advertencias sobre esta sección. Primero, probar que el circuito garbled se construyó correctamente toma actualmente alrededor de 14 días según Citrea, algo que el equipo dice estar trabajando en reducir. Un paso de setup medido en semanas limita la frecuencia con que puede cambiar el conjunto de participantes. Segundo, el tema que motivó este análisis le atribuye a BitVM3 una reducción de aproximadamente 1.000x en el costo de disputa en el peor caso, hasta unos cinco dólares. El paper de BitVM3 que obtuvimos no pudo procesarse en texto legible, y no estamos repitiendo esas cifras como si tuvieran fuente confirmada. La dirección está bien respaldada por las propias cifras de Citrea y por el resumen de House of ZK sobre esfuerzos paralelos, incluido Glock de Alpen, que esa fuente caracteriza como una afirmación de ganancias de eficiencia de cientos de veces sobre BitVM2 usando garbled locks y un SNARK de verificador designado, y Argo de Ideal, que persigue reducciones de costo similares. Una cifra en dólares para una disputa es, en todo caso, una afirmación sobre un entorno de comisiones más que sobre una propiedad del protocolo. La pregunta relevante es cuánto cuesta el disprove en relación con la capacidad de bloque durante la congestión que un atacante induciría deliberadamente.
TOOP y el problema del float
Los circuitos garbled atacan el costo de las disputas. No hacen nada respecto al requisito de que el operador adelante liquidez, que es un problema distinto con una solución propuesta distinta.
TOOP, construido por Fairgate Labs, reestructura el reembolso para que los operadores no tengan que pagarle primero a los usuarios. En el setup, los operadores firman de antemano transacciones de reembolso que cubren cada subconjunto posible del conjunto de operadores. Al momento del retiro, los operadores encriptan y envían claves privadas al usuario, quien selecciona un subconjunto de firmantes y ensambla el pago por sí mismo. El rol del operador pasa de adelantar capital a autorizar un reclamo sobre capital que ya está bloqueado.
Presignar para cada subconjunto es combinatoriamente costoso, y aunque las fuentes no indican el límite resultante, el escalamiento implica un techo práctico duro para el tamaño del conjunto de operadores. Esa es una restricción sobre N que proviene de un mecanismo pensado para facilitar la participación, y merece escrutinio a medida que el diseño madure. La madurez independiente de TOOP también nos es desconocida. No encontramos ninguna auditoría ni despliegue de TOOP fuera del contexto de Clementine.
En conjunto, v2 apunta a ambos requisitos de capital al mismo tiempo: los circuitos garbled reducen lo que un operador debe depositar para que la deshonestidad resulte punible, y TOOP reduce lo que un operador debe mantener disponible para que los retiros sean rápidos. Si ambos funcionan como se describe, el rol de operador se vuelve suficientemente barato como para que N pueda ser más grande y más variado, que es el único camino por el cual 1-de-N se convierte en un supuesto más sólido en lugar de simplemente distinto. Ese es el argumento que hay que poner a prueba cuando v2 se lance, no las cifras de tamaño de transacción.
Dónde se ubica Clementine frente a diseños de bridge anteriores
El eje útil para comparar diseños de bridge no es el throughput ni las cadenas soportadas. Es qué parte debe comportarse correctamente para que el respaldo se mantenga intacto, y qué parte debe estar presente para que un retiro se complete. A menudo son partes distintas, y confundirlas es cómo los bridges terminan siendo descritos como más seguros de lo que son. La tabla siguiente es nuestra síntesis, no un benchmark con fuentes.
| Diseño | Quién debe ser honesto para que los fondos sigan respaldados | Quién debe estar presente para la salida | Firma del fallo |
|---|---|---|---|
| BTC envuelto custodial | El custodio | El custodio | La reserva se gasta o se congela; los tenedores se enteran por una divulgación off-chain |
| Peg federado (n-de-m) | Cualquier n de m firmantes actuando en conjunto | Los mismos n firmantes | Un quórum firma un gasto no autorizado, o quedan menos de n firmantes accesibles y el peg se detiene |
| Bridge de atestación off-chain | El conjunto de oráculos y relayers que atestiguan eventos remotos | El mismo conjunto | La cadena de destino acuña contra un evento que nunca ocurrió; la cadena de destino no puede detectarlo porque la verificación fue delegada |
| Bridge BitVM2 (Clementine v1) | Ninguna parte específica, siempre que un challenger honesto actúe a tiempo | Un operador con colateral y float, más un conjunto de challengers activo | Una afirmación falsa se finaliza porque ningún challenger disputó dentro de la ventana |
El cambio estructural en la fila inferior es que ninguna parte identificada puede autorizar unilateralmente un gasto. Bitcoin impone el resultado de la disputa, y el grafo presignado descarta toda rama que no fue firmada en el setup. Esa es exactamente la propiedad que el análisis de House of ZK usa para separar los verdaderos L2 de Bitcoin de las sidechains: un sistema se gana la etiqueta solo si un usuario puede salir bajo las reglas de consenso de Bitcoin incluso cuando los operadores y comités están fuera de línea, son maliciosos o no cooperan.
El cambio también reubica el fallo en lugar de eliminarlo. El fallo de una federación requiere una decisión activa de un quórum. El fallo de un juego de disputa requiere una ausencia. Las ausencias no necesitan estar organizadas, no dejan rastro de coordinación, y correlacionan exactamente con las condiciones que un atacante puede fabricar, a saber, la congestión de comisiones y el estrés de infraestructura. La comparación favorece a BitVM2 bajo cualquier ponderación razonable, y lo favorece menos de lo que sugiere la frase “sin parte de confianza”.
Hay una asimetría más que merece atención. Bajo un peg federado, el colateral vinculado tiene que ser grande en relación con la reserva, porque el beneficio de un quórum coludido es la reserva completa y su costo es el bono. Bajo BitVM2 la estructura de beneficios es distinta: un operador al que se le hace disprove no roba y luego es castigado, fracasa en robar y es castigado, porque la ruta de disprove impide que el reembolso se tome en absoluto. El colateral, por lo tanto, se tariza contra el griefing y el mal comportamiento operacional, no contra el valor total de la reserva. La función de pérdida es discontinua. Si un watchtower honesto actúa, la pérdida es prácticamente cero. Si ninguno lo hace, la pérdida está acotada por lo que el grafo le permita reclamar a un operador. Todo depende de en qué lado de esa discontinuidad caiga el sistema, y nada en el dimensionamiento del colateral desplaza esa frontera.
Grafos presignados, covenants ausentes
Cada restricción estructural discutida arriba se remonta a la misma primitiva faltante. Como Bitcoin no puede expresar “este output solo puede gastarse mediante una transacción que coincida con esta plantilla”, Clementine tiene que aproximar los covenants presignando. Las consecuencias se acumulan: el conjunto de participantes queda fijo en el momento de la ceremonia, la rotación requiere una nueva ceremonia, el número de artefactos presignados crece con las rondas y con las combinaciones de subconjuntos bajo TOOP, y la seguridad de todo el arreglo depende de una higiene de ceremonia que ningún observador on-chain puede verificar después del hecho.
CheckTemplateVerify permitiría que un output comprometa directamente el hash de su transacción de gasto permitida, de modo que la restricción quedaría impuesta por el consenso en lugar de por la completitud de un conjunto de firmas. CheckSigFromStack permitiría que el script verifique firmas sobre mensajes arbitrarios, lo cual abre patrones de delegación y atestación que hoy tienen que quedar incorporados en ramas presignadas. Ninguno está activo, y ninguna de las fuentes que revisamos discute cómo se simplificarían las construcciones específicas de Clementine si lo estuvieran. Lo que sí podemos decir es que las partes del diseño que peor escalan, la duración de la ceremonia, el presignado de subconjuntos y la rigidez del conjunto de participantes, son exactamente las partes que existen porque el presignado está haciendo las veces de la aplicación por consenso. Si los covenants se activan, la pregunta interesante no es si las disputas se abaratan, sino si N puede volverse fluido.
La forma de un fallo
Vale la pena separar cuatro modos de fallo distintos, porque tienen probabilidades y víctimas diferentes.
Un fallo de liveness es el caso base que el diseño acepta explícitamente. Un operador afirma algo falso, ningún challenger disputa a tiempo, y el reembolso se finaliza. La reserva queda corta en el monto reclamado. Los usuarios que ya salieron conservan su BTC. El faltante recae en los tenedores restantes del activo pegged, presumiblemente como una reserva fraccionaria, aunque ninguna fuente que revisamos describe cómo se asignaría tal faltante o si existe algún respaldo.
Un fallo de economía de disputas es un fallo de liveness con una causa. Si las comisiones de Bitcoin suben lo suficiente como para que una transacción de disprove de varios megabytes no pueda confirmarse dentro de la ventana, los challengers honestos y atentos quedan excluidos por precio. El trabajo de circuitos garbled apunta directamente a esto y, si se lanza, lo elimina en gran medida como riesgo independiente. Hasta que eso ocurra, el sistema en vivo lo carga.
Un fallo de colusión total devuelve al sistema a la semántica de un peg federado. Las fuentes no describen ningún recurso, y no asumimos que exista alguno.
Un fallo de construcción es el que el marco 1-de-N no aborda en absoluto. Si el grafo de transacciones se firmó incorrectamente, o existe una rama que no debería existir, o la ceremonia filtró una clave, entonces el watchtower honesto no tiene nada que disputar porque el robo es un gasto válido. Esta es la restricción de complejidad de auditoría, y no es una auditoría de contrato inteligente. Es una revisión de toda una pila de protocolo de grafos de transacciones presignados. No encontramos ninguna evaluación de seguridad independiente publicada de Clementine v1 tal como está desplegado, separada de los documentos de diseño del propio equipo.
Los parámetros que le permitirían a un tercero tarifar estos riesgos no son públicos en lo que revisamos: el número de watchtowers, el proceso de selección y remoción, la duración de las ventanas de disputa, el requisito de colateral en términos de BTC, y la proporción entre la reserva del bridge y el colateral agregado de los operadores. Esas son las divulgaciones que vale la pena esperar, más que el próximo múltiplo de eficiencia. Un bridge cuya transacción de disprove cuesta unos pocos dólares pero cuyo conjunto de challengers son tres empresas en una misma jurisdicción ha movido la curva de costos sin mover la frontera de confianza.
Referencias
- R&D for Clementine v2: Eliminating Collateral and Liquidity Requirements with Garbled Circuits and TOOP, Citrea
- Bitcoin L2s in 2026: A Reality Check, House of ZK
- BitVM3 paper (no pudimos extraer texto legible del archivo obtenido)
Read next다음으로 읽기次に読む继续阅读Leer a continuación
【BTCFiシリーズ第6回】バビロン vs EigenLayer 徹底比較
バビロンのビットコインネイティブステーキングとEigenLayerのETHリステーキングを構造的に比較——スラッシング、報酬、オペレーター選定、そしてその波及効果を詳しく解説。
【BTCFi シリーズ 5】Babylon と BTCFi のセキュリティ拡張エコシステム：ビットコインのセキュリティの金融化に関する徹底分析
ビットコインを単なる価値保存手段から Web3 エコシステムの「生産的な資本」へと転換しようとする Babylon とその拡張エコシステムを深く分析します。
【BTCFi シリーズ 4】ビットコイン レイヤー2ネットワークの技術分析と比較：BTCFiの未来を形づくる三つのアプローチ
ブリッジの信頼モデル再設計、ZK（零知識）による信頼の最小化、そしてビットコイン流動化プラットフォームという BTC L2 の三つの主要アプローチに焦点を当て、各プロジェクトの技術的特徴と含意を深掘り比較します。
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.