article

【BTCFi系列第6期】Babylon与EigenLayer深度对比

Babylon 比特币原生质押与 EigenLayer 以太坊再质押的结构性对比——涵盖罚没机制、奖励分配、运营者选择及下游影响。

14 分钟阅读

cover

Introduction

The phrase “shared security” gets applied to both Babylon and EigenLayer often enough that the two are treated as the Bitcoin and Ethereum versions of one idea: take an existing asset’s economic weight and rent it out to chains or services that cannot bootstrap their own. The framing is convenient and partly true. Both protocols extract security from a base asset and project it onto a set of consumers. Both rely on slashing as the credible threat that gives the rented security teeth.

But the two designs diverge at almost every layer below that surface description, and the divergence is consequential. Babylon’s model is constrained by what Bitcoin script can express and what a non-Turing-complete chain can verify. EigenLayer’s model is constrained by what an Ethereum contract can hold custody of and what an operator set can be coerced into running. These constraints are not symmetric, and they push the two ecosystems toward different equilibria — different operator economics, different consumer-chain shapes, different risk profiles for the underlying stakers.

In this piece we compare the two systems along five axes: how the stake is custodied, how slashing is enforced, how rewards flow, how operators or finality providers are selected, and how capital efficiency compounds. We then turn to what each model implies for the downstream BTCFi and ETHFi ecosystems that depend on them. The goal is not to rank the two protocols against each other — they solve overlapping but distinct problems — but to make the structural differences legible enough that observers can stop conflating them.

How the stake is held

img1

The most fundamental difference between Babylon and EigenLayer is where the staked asset physically sits and who holds the keys.

In Babylon, BTC never leaves Bitcoin. A staker constructs a transaction that locks a UTXO into a script with two principal spending paths: a timelocked unbonding path that returns the BTC to the staker after a delay, and a slashing path that sends the BTC to a burn-style address if a covenant committee co-signs against a misbehaving finality provider. The staker retains the private key to their own funds throughout. There is no bridge, no wrapped representation, no custodian holding pooled BTC on the staker’s behalf. Consumer chains read Bitcoin blocks (typically through a light-client relay or a vote-extension mechanism) to learn which stake is currently active and which finality providers it backs.

In EigenLayer, ETH or a liquid staking token is deposited into a strategy contract on Ethereum. For native restaking, the staker points their beacon-chain withdrawal credential at an EigenPod contract; the protocol can then prove the validator’s status against the beacon state and, in the slashing case, route the stake. For LST restaking, the LST is held by a strategy contract directly. In both cases the asset is custodied by Ethereum smart contracts that the staker no longer unilaterally controls — withdrawal is gated by the protocol’s queue and by whatever AVSs the operator has opted into.

The custodial asymmetry has downstream consequences. Babylon’s stakers face Bitcoin-script risk and covenant-committee risk but no smart-contract execution risk on a separate chain. EigenLayer’s stakers face the full surface of Ethereum smart-contract risk plus the cumulative risk of every AVS their chosen operator has opted into. Conversely, EigenLayer can support arbitrarily complex slashing logic because Ethereum can run arbitrary code, while Babylon must encode every condition in a way Bitcoin script can verify or that a covenant committee can be trusted to attest to.

The covenant compromise

Babylon’s slashing path depends on a pre-signed covenant. At staking time, a committee of covenant signers co-signs a transaction that, if published with a fraud proof of double-signing, sends the staked BTC to an unspendable output. Bitcoin script alone cannot verify a Tendermint-style equivocation proof, so the covenant committee acts as a programmable adapter — it pre-authorizes the slash conditional on evidence that an off-chain process verifies. The committee cannot steal funds (the pre-signed transaction only routes to burn) but it can refuse to sign, which is why the committee is sized and rotated to make collusion expensive. A future Bitcoin upgrade enabling richer script primitives would shrink or eliminate the committee’s role; until then, it is the load-bearing piece that lets Babylon claim Bitcoin-script-enforced slashing.

How shared security is wired into consumers

img2

The shape of the consumer side differs even more than the staking side.

EigenLayer’s consumers are AVSs — actively validated services. An AVS is any system that registers with the EigenLayer contracts, defines its own slashing conditions, and recruits operators. The canonical examples cited in the EigenLayer documentation include data availability layers, oracle networks, bridges, and coprocessors, but the abstraction is broad enough to cover nearly any service that benefits from a bonded operator set. An AVS does not need to be a chain. It does not need to produce blocks. It only needs to define what operators are supposed to do and what evidence will trigger a slash.

Babylon’s consumers are, by contrast, primarily chains — specifically, chains with a finality gadget that can be informed by votes from BTC-backed finality providers. The Babylon design assumes that the consumer has a notion of finality that benefits from external economic weight: a Cosmos-SDK chain wanting fast finality on top of CometBFT, a rollup wanting an external finality layer, an L2 wanting reorg resistance. The slashing condition is constrained to what Bitcoin script and the covenant adapter can verify, which in practice means double-signing or equivocation by a finality provider. Arbitrary off-chain conditions like “operator failed to publish a data blob” are not natively expressible in the same way they are on EigenLayer.

This is the deepest structural difference. EigenLayer is a marketplace where the supply side (ETH) is homogeneous and the demand side (AVSs) is heterogeneous and unconstrained. Babylon is a security pipe where the supply side (BTC) is homogeneous and the demand side is heterogeneous in chain architecture but homogeneous in slashing condition: it is roughly always “don’t equivocate as a finality provider.” The two protocols therefore attract different consumer profiles. EigenLayer attracts services whose security needs are idiosyncratic. Babylon attracts chains that need finality-grade economic backing and are willing to architect around the constraint.

Finality providers vs operators

In Babylon, the entity that votes on consumer-chain blocks is called a finality provider. BTC stakers delegate their stake to one or more finality providers, and the finality provider’s voting weight on a given consumer chain is the sum of BTC delegated to it for that chain. Slashing is per-finality-provider: if a finality provider double-signs, all BTC delegated to it on that chain is at risk through the pre-signed slashing transaction.

In EigenLayer, the analogous role is the operator. Stakers (or LST holders) delegate to an operator, who then opts into a set of AVSs. An operator’s slashable stake on a given AVS is the sum of delegations from stakers who have not explicitly excluded that AVS. The operator chooses which AVSs to run, subject to staker veto. This indirection — operators choosing AVSs, stakers choosing operators — produces a cumulative risk profile that the staker must reason about, since each additional AVS adds to the operator’s slashing surface.

Slashing mechanics

img3

The slashing mechanism is where the two designs differ most concretely, and it is also where the most marketing-grade hand-waving tends to occur.

Babylon’s slashing is enforced by Bitcoin’s settlement. When a finality provider double-signs on a consumer chain, the equivocation is detected (typically by the consumer chain’s own validators or by watchers), the evidence is submitted, the covenant committee co-signs the pre-signed slashing transaction, and the resulting Bitcoin transaction is broadcast. Once it confirms, the staked BTC is at the burn address. The slash is final at Bitcoin-block finality, which is slow (an hour-plus to be safe) but unconditional in the sense that no other chain or contract can roll it back.

EigenLayer’s slashing is enforced by Ethereum smart contracts. When an AVS detects a slashable event, it submits evidence to the slashing contract, which verifies the condition and reduces the operator’s restaked stake (and proportionally, the delegated stake of stakers who had exposure to that AVS). The slash is final at Ethereum’s finality, which is faster than Bitcoin’s, but it is mediated entirely by the EigenLayer contracts and the AVS’s slashing logic. The richness of conditions that can be slashed is bounded only by what an Ethereum contract can verify.

What can actually be slashed

The expressiveness gap matters in practice. EigenLayer can in principle slash for arbitrary verifiable misbehavior: failing to sign a data blob, producing an invalid attestation, going offline beyond a threshold, signing conflicting state roots in a coprocessor. Whether any given AVS actually defines and enforces such conditions is a separate question — the early AVS deployments have generally been conservative — but the framework supports them.

Babylon’s framework is narrower. Equivocation by a finality provider is the canonical slashable offense. Liveness failures (a finality provider going offline) are typically handled by stake unbonding or jailing rather than slashing, because proving a negative on Bitcoin is structurally awkward. This narrower surface is partly a feature: it limits the ways a staker’s BTC can be lost to misbehavior the staker did not commit. But it also means that consumer chains relying on Babylon must design their security model around equivocation-grade guarantees rather than around the broader liveness-and-correctness guarantees an AVS can demand.

Trust assumptions in the slashing path

Babylon’s slashing path trusts the covenant committee not to refuse to sign. EigenLayer’s slashing path trusts the AVS contract logic, the EigenLayer slashing contracts, and the operator’s honest registration of their AVS opt-ins. Neither is trustless in the strict sense. The relevant question is which set of trust assumptions degrades more gracefully under adversarial conditions, and the answer depends on what one is most worried about: a covenant committee colluding to block a slash (Babylon’s failure mode) or a slashing contract bug or AVS misconfiguration that slashes honest operators (EigenLayer’s failure mode).

Rewards, capital efficiency, and operator selection

img4

The reward and selection layer is where economic divergence becomes most visible.

In EigenLayer, an operator who opts into multiple AVSs earns rewards from each, while the underlying ETH continues to earn beacon-chain consensus rewards (in the native restaking case) or LST-yield (in the LST case). The marginal economic argument for an operator is straightforward: each additional AVS adds reward streams while the same stake collateralizes them all. This is the capital-efficiency claim that drove much of EigenLayer’s early growth. The countervailing pressure is risk stacking: each AVS adds slashing surface, and a misconfigured AVS can compromise all the stake collateralizing it.

The staker, in turn, must reason about which operators they delegate to and which AVSs those operators run. The protocol provides mechanisms for stakers to opt out of specific AVSs, but in practice most stakers delegate based on operator reputation and accept the bundle. The result is a system where capital efficiency is high but risk is correlated across services in ways that are difficult to price.

Babylon’s economics work differently. A BTC staker earns rewards from each consumer chain their finality provider serves, paid in the consumer chain’s native token (or whatever the consumer chain chooses to denominate rewards in). The same BTC can in principle back a finality provider serving multiple chains, giving Babylon its own version of the capital-efficiency claim. But the underlying BTC does not earn anything analogous to beacon-chain rewards — Bitcoin has no native staking yield — so the entire reward to a BTC staker is the sum of consumer-chain rewards. This makes the consumer-chain reward design more economically central in Babylon than the AVS reward design is in EigenLayer, where there is always a baseline staking yield underneath.

Selection and concentration

Both systems face a concentration question: how does delegated stake distribute across operators or finality providers, and what does that distribution mean for security?

EigenLayer’s operator set has tended to overlap heavily with the existing Ethereum staking operator set — large LST issuers, established staking-as-a-service providers, and a long tail of smaller operators. The operators that attract the most delegation are typically those with strong reputational track records on the underlying staking layer, which produces concentration similar to the one already present in Ethereum staking. The risk is that a single operator slashing event on a major AVS would propagate to a large fraction of restaked ETH.

Babylon’s finality provider set is structurally newer because it does not inherit a pre-existing operator topology — there is no “Bitcoin staking operator” set that predates the protocol. Finality providers are instead recruited per consumer chain, and the same entity may run finality-provider infrastructure on many chains. The early distribution depends heavily on which entities show up first, and there is meaningful path dependence in how concentrated the eventual distribution becomes.

Reward currency and the BTC stacking problem

There is a subtle economic point worth surfacing. EigenLayer rewards are typically paid in AVS-issued tokens or ETH, which restakers can either hold or convert. The AVS-token case shifts long-term economic exposure from ETH toward the AVS, which is a deliberate design choice — restakers are partly buying into the AVS economy.

Babylon rewards are paid by consumer chains in their own tokens, but the staker’s principal is BTC. A BTC staker who actually wants to remain BTC-denominated must continually convert consumer-chain reward tokens back to BTC, which introduces a slow leak of selling pressure on consumer-chain tokens unless those tokens have organic demand. The reward design for a Babylon consumer chain therefore has to account for the fact that its principal stakers are not natural long-term holders of the reward token.

Downstream consequences for BTCFi and ETHFi

img5

The architectural differences produce different ecosystem shapes downstream.

ETHFi, broadly construed as the universe of services that have grown around restaked ETH, has developed in the direction the EigenLayer abstraction encourages: lots of heterogeneous AVSs, a layer of liquid restaking tokens that bundle exposure across operators and AVSs, and a derivatives layer that prices and trades the resulting yield streams. The capital efficiency story has compounded into a multi-layer financialization that is recognizable to anyone who watched the LST ecosystem mature, just with more degrees of freedom and more correlated risk.

BTCFi, when seen through the Babylon lens, has developed differently. The primary downstream consumers are chains seeking finality backing, not arbitrary services seeking economic security. Liquid staking tokens for Babylon-staked BTC exist and are growing, but the AVS-equivalent layer — a marketplace of heterogeneous services consuming BTC security — is structurally constrained by the slashing-condition limits described earlier. What BTCFi does have, that ETHFi does not, is the credibility of native Bitcoin custody: the underlying asset never leaves its base chain, and that property is itself a product feature for a class of holders who would never have considered wrapped or bridged BTC.

A reasonable summary is that EigenLayer optimizes for the breadth of services that can consume security, while Babylon optimizes for the legitimacy of the security being consumed. Both axes matter, and the two ecosystems are likely to coexist rather than converge.

What to watch and what remains open

The most important variables to watch over the next several quarters are not the headline staked-amount numbers but the structural ones.

For Babylon, the questions are: how the covenant committee evolves as Bitcoin script primitives improve, whether finality-provider concentration produces the kind of correlated-slashing risk EigenLayer faces, and whether consumer chains can design reward structures that retain BTC stakers without forcing them into long exposure to consumer-chain tokens. The deeper open question is whether Babylon’s slashing surface, which is narrower than EigenLayer’s, will prove sufficient for the consumer chains that adopt it, or whether the ecosystem will eventually demand richer conditions that require Bitcoin-side upgrades.

For EigenLayer, the questions are: how slashing actually behaves in production once AVSs begin enforcing live conditions at scale, how risk stacks across AVSs that share operators, and whether the liquid restaking layer introduces enough opacity that stakers cannot meaningfully reason about their cumulative slashing exposure. The broader open question is whether the AVS abstraction, which is generic by design, produces enough genuinely security-needing services to absorb the restaked ETH supply, or whether reward dilution will reshape operator economics.

The comparison is not a horse race. Babylon and EigenLayer are answers to overlapping but different questions, built under different constraints, attracting different consumers, and producing different downstream economies. The useful frame is not which model wins but which design constraints each has internalized and which it has deferred. Babylon has deferred slashing-condition expressiveness in exchange for native custody. EigenLayer has deferred custody guarantees in exchange for slashing-condition expressiveness. The downstream ecosystems are tracking those tradeoffs faithfully, and the most interesting BTCFi and ETHFi developments to come are likely to be the ones that work with each model’s grain rather than against it.

cover

들어가며

“공유 보안(shared security)“이라는 개념은 바빌론과 아이겐레이어 모두에 자주 적용되다 보니, 마치 두 프로토콜이 하나의 아이디어를 비트코인과 이더리움 버전으로 각각 구현한 것처럼 취급되곤 한다. 즉, 기존 자산의 경제적 무게를 자체적으로 보안을 구축하지 못하는 체인이나 서비스에 임대한다는 구도다. 이 틀은 편리하고 어느 정도는 맞다. 두 프로토콜 모두 기반 자산에서 보안을 추출해 소비자 집합에 투사하며, 슬래싱을 임대된 보안에 실질적인 강제력을 부여하는 신뢰할 수 있는 위협 수단으로 활용한다.

그러나 그 표면적 설명 아래로 내려가면 두 설계는 거의 모든 층위에서 갈라지며, 그 분기는 결코 사소하지 않다. 바빌론의 모델은 비트코인 스크립트가 표현할 수 있는 것과 튜링 불완전한 체인이 검증할 수 있는 것에 의해 제약된다. 아이겐레이어의 모델은 이더리움 컨트랙트가 보관할 수 있는 것과 오퍼레이터 집합이 강제로 실행하게 할 수 있는 것에 의해 제약된다. 이 제약들은 대칭적이지 않으며, 두 생태계를 서로 다른 균형점으로 밀어붙인다 — 오퍼레이터 경제구조, 소비자 체인의 형태, 스테이커가 짊어지는 리스크 프로필이 모두 달라진다.

이 글에서는 두 시스템을 다섯 가지 축으로 비교한다: 스테이크가 보관되는 방식, 슬래싱이 집행되는 방식, 보상이 흐르는 방식, 오퍼레이터 또는 파이널리티 프로바이더가 선정되는 방식, 그리고 자본 효율이 복합적으로 작용하는 방식. 이후에는 각 모델이 그에 의존하는 하위 BTCFi 및 ETHFi 생태계에 어떤 함의를 갖는지 살펴본다. 목표는 두 프로토콜의 우열을 가리는 것이 아니다 — 이들은 겹치지만 구분되는 문제를 해결한다 — 구조적 차이를 충분히 명확하게 드러내어 관찰자들이 더 이상 두 프로토콜을 혼동하지 않도록 하는 것이다.

스테이크가 보관되는 방식

img1

바빌론과 아이겐레이어 사이에서 가장 근본적인 차이는 스테이킹된 자산이 물리적으로 어디에 위치하며 누가 키를 쥐고 있느냐다.

바빌론에서 BTC는 비트코인을 떠나지 않는다. 스테이커는 UTXO를 두 가지 주요 지출 경로를 가진 스크립트에 잠그는 트랜잭션을 구성한다. 하나는 일정 지연 후 BTC를 스테이커에게 반환하는 타임락 언본딩 경로이고, 다른 하나는 부정행위를 저지른 파이널리티 프로바이더에 대해 코버넌트 위원회가 공동서명할 경우 BTC를 소각성 주소로 전송하는 슬래싱 경로다. 스테이커는 전 과정에서 자신의 자금에 대한 개인 키를 보유한다. 브릿지도, 래핑된 표현도, 스테이커를 대신해 풀링된 BTC를 보관하는 수탁자도 없다. 소비자 체인은 비트코인 블록을 읽어(보통 라이트 클라이언트 릴레이나 투표 확장 메커니즘을 통해) 현재 어떤 스테이크가 활성 상태이고 어떤 파이널리티 프로바이더를 지지하는지 파악한다.

아이겐레이어에서는 ETH 또는 유동 스테이킹 토큰이 이더리움의 스트래티지 컨트랙트에 예치된다. 네이티브 리스테이킹의 경우, 스테이커는 비콘체인 출금 자격증명을 EigenPod 컨트랙트로 지정한다. 그러면 프로토콜이 비콘 상태에 대해 밸리데이터의 상태를 증명할 수 있고, 슬래싱 발생 시 스테이크를 라우팅할 수 있다. LST 리스테이킹의 경우 LST는 스트래티지 컨트랙트에 직접 보관된다. 두 경우 모두 자산은 스테이커가 더 이상 단독으로 통제하지 못하는 이더리움 스마트 컨트랙트가 수탁한다 — 출금은 프로토콜의 대기열과 오퍼레이터가 옵트인한 AVS의 조건에 의해 통제된다.

이 수탁 비대칭성은 하위 결과를 낳는다. 바빌론의 스테이커는 비트코인 스크립트 리스크와 코버넌트 위원회 리스크에 노출되지만, 별도 체인의 스마트 컨트랙트 실행 리스크는 없다. 아이겐레이어의 스테이커는 이더리움 스마트 컨트랙트 리스크의 전체 표면적에 더해, 자신이 선택한 오퍼레이터가 옵트인한 모든 AVS의 누적 리스크에 노출된다. 반대로, 아이겐레이어는 이더리움이 임의의 코드를 실행할 수 있으므로 임의로 복잡한 슬래싱 로직을 지원할 수 있는 반면, 바빌론은 모든 조건을 비트코인 스크립트가 검증할 수 있거나 코버넌트 위원회가 신뢰할 수 있는 방식으로 증명할 수 있는 형태로 인코딩해야 한다.

코버넌트의 타협

바빌론의 슬래싱 경로는 사전 서명된 코버넌트에 의존한다. 스테이킹 시점에 코버넌트 서명자 위원회가 이중 서명의 사기 증명과 함께 게시될 경우 스테이킹된 BTC를 사용 불가능한 출력으로 보내는 트랜잭션에 공동서명한다. 비트코인 스크립트 자체는 텐더민트 방식의 이중서명(equivocation) 증명을 검증할 수 없으므로, 코버넌트 위원회는 프로그래밍 가능한 어댑터 역할을 한다 — 오프체인 프로세스가 검증하는 증거를 조건으로 슬래싱을 사전 승인하는 것이다. 위원회는 자금을 탈취할 수 없다(사전 서명된 트랜잭션은 소각 주소로만 라우팅된다). 하지만 서명을 거부할 수는 있으며, 이것이 위원회 규모와 교체 주기를 공모 비용이 높도록 설계하는 이유다. 더 풍부한 스크립트 기본 기능을 가능케 하는 향후 비트코인 업그레이드가 이루어진다면 위원회의 역할이 줄어들거나 사라질 것이다. 그 전까지 위원회는 바빌론이 비트코인 스크립트로 강제되는 슬래싱을 주장할 수 있게 하는 핵심 구성요소다.

공유 보안이 소비자에게 연결되는 방식

img2

소비자 측의 형태는 스테이킹 측보다 훨씬 더 크게 다르다.

아이겐레이어의 소비자는 **AVS(능동적으로 검증된 서비스)**다. AVS는 아이겐레이어 컨트랙트에 등록하고, 자체 슬래싱 조건을 정의하며, 오퍼레이터를 모집하는 모든 시스템을 말한다. 아이겐레이어 문서에서 인용하는 대표적인 예시로는 데이터 가용성 레이어, 오라클 네트워크, 브릿지, 코프로세서 등이 있지만, 이 추상화는 결합된 오퍼레이터 집합이 있으면 혜택을 받는 거의 모든 서비스를 포괄할 만큼 광범위하다. AVS는 체인일 필요가 없다. 블록을 생성할 필요도 없다. 오퍼레이터가 무엇을 해야 하는지와 어떤 증거가 슬래싱을 촉발하는지만 정의하면 된다.

바빌론의 소비자는 이와 달리 주로 체인이다 — 구체적으로는 BTC로 뒷받침된 파이널리티 프로바이더의 투표로 정보를 얻을 수 있는 파이널리티 가젯을 갖춘 체인이다. 바빌론의 설계는 소비자가 외부 경제적 무게의 혜택을 받는 파이널리티 개념을 갖추고 있다고 가정한다: CometBFT 위에서 빠른 파이널리티를 원하는 Cosmos-SDK 체인, 외부 파이널리티 레이어를 원하는 롤업, 재편성 저항성을 원하는 레이어 2 등이다. 슬래싱 조건은 비트코인 스크립트와 코버넌트 어댑터가 검증할 수 있는 것으로 제한되며, 실질적으로는 파이널리티 프로바이더의 이중 서명 또는 이중서명을 의미한다. “오퍼레이터가 데이터 블롭 게시에 실패”와 같은 임의의 오프체인 조건은 아이겐레이어에서처럼 기본적으로 표현할 수 없다.

이것이 가장 깊은 구조적 차이다. 아이겐레이어는 공급 측(ETH)이 동질적이고 수요 측(AVS)이 이질적이고 제약이 없는 마켓플레이스다. 바빌론은 공급 측(BTC)이 동질적이고 수요 측이 체인 아키텍처에서는 이질적이지만 슬래싱 조건에서는 동질적인 보안 파이프다: 대략 항상 “파이널리티 프로바이더로서 이중서명하지 말라”는 조건이다. 따라서 두 프로토콜은 서로 다른 소비자 프로필을 끌어들인다. 아이겐레이어는 보안 필요가 특수한 서비스를 끌어들이고, 바빌론은 파이널리티 수준의 경제적 뒷받침이 필요하고 그 제약에 맞게 아키텍처를 설계할 의향이 있는 체인을 끌어들인다.

파이널리티 프로바이더 대 오퍼레이터

바빌론에서 소비자 체인 블록에 투표하는 주체를 파이널리티 프로바이더라고 한다. BTC 스테이커는 하나 이상의 파이널리티 프로바이더에게 스테이크를 위임하며, 특정 소비자 체인에서 파이널리티 프로바이더의 투표 가중치는 해당 체인을 위해 위임된 BTC의 합계다. 슬래싱은 파이널리티 프로바이더 단위로 이루어진다: 파이널리티 프로바이더가 이중 서명을 하면, 사전 서명된 슬래싱 트랜잭션을 통해 해당 체인에서 그에게 위임된 모든 BTC가 위험에 처한다.

아이겐레이어에서 유사한 역할을 하는 것은 오퍼레이터다. 스테이커(또는 LST 보유자)는 오퍼레이터에게 위임하고, 오퍼레이터는 일련의 AVS에 옵트인한다. 특정 AVS에서 오퍼레이터의 슬래싱 가능한 스테이크는 해당 AVS를 명시적으로 제외하지 않은 스테이커들의 위임 합계다. 오퍼레이터는 스테이커의 거부권을 조건으로 실행할 AVS를 선택한다. 이 간접성 — 오퍼레이터가 AVS를 선택하고 스테이커가 오퍼레이터를 선택하는 구조 — 은 스테이커가 추론해야 하는 누적 리스크 프로필을 만들어낸다. 추가 AVS마다 오퍼레이터의 슬래싱 표면이 늘어나기 때문이다.

슬래싱 메커니즘

img3

슬래싱 메커니즘은 두 설계가 가장 구체적으로 다른 지점이며, 동시에 마케팅성 과장이 가장 자주 발생하는 영역이기도 하다.

바빌론의 슬래싱은 비트코인의 결제에 의해 집행된다. 파이널리티 프로바이더가 소비자 체인에서 이중 서명을 하면, 이중서명이 감지되고(보통 소비자 체인의 밸리데이터나 감시자에 의해), 증거가 제출되며, 코버넌트 위원회가 사전 서명된 슬래싱 트랜잭션에 공동서명하고, 해당 비트코인 트랜잭션이 브로드캐스트된다. 트랜잭션이 확인되면 스테이킹된 BTC는 소각 주소에 귀속된다. 슬래싱은 비트코인 블록 파이널리티에서 최종 확정되는데, 이는 느리지만(안전하게 확인하려면 한 시간 이상) 다른 체인이나 컨트랙트가 되돌릴 수 없다는 점에서 무조건적이다.

아이겐레이어의 슬래싱은 이더리움 스마트 컨트랙트에 의해 집행된다. AVS가 슬래싱 가능한 이벤트를 감지하면 슬래싱 컨트랙트에 증거를 제출하고, 컨트랙트는 조건을 검증한 뒤 오퍼레이터의 리스테이킹된 스테이크(그리고 비례적으로 해당 AVS에 노출된 스테이커의 위임된 스테이크)를 감소시킨다. 슬래싱은 이더리움의 파이널리티에서 최종 확정되며, 비트코인보다 빠르지만 전적으로 아이겐레이어 컨트랙트와 AVS의 슬래싱 로직에 의해 중재된다. 슬래싱 가능한 조건의 풍부함은 이더리움 컨트랙트가 검증할 수 있는 것의 범위에 의해서만 제한된다.

실제로 슬래싱될 수 있는 것

이 표현성의 격차는 실제로 중요하다. 아이겐레이어는 원칙적으로 임의의 검증 가능한 부정행위에 대해 슬래싱할 수 있다: 데이터 블롭 서명 실패, 잘못된 증명 생성, 임계값을 초과한 오프라인 상태, 코프로세서에서 충돌하는 상태 루트에 서명하는 행위 등. 특정 AVS가 실제로 이러한 조건을 정의하고 집행하는지는 별개의 문제다 — 초기 AVS 배포는 대체로 보수적이었다 — 하지만 프레임워크 자체는 이를 지원한다.

바빌론의 프레임워크는 더 좁다. 파이널리티 프로바이더의 이중서명이 슬래싱의 표준적인 위반 행위다. 라이브니스 실패(파이널리티 프로바이더의 오프라인)는 보통 슬래싱보다는 스테이크 언본딩이나 제재로 처리된다. 비트코인에서 부재를 증명하는 것은 구조적으로 어색하기 때문이다. 이 좁은 표면은 어느 정도 장점이기도 하다: 스테이커가 저지르지 않은 부정행위로 BTC를 잃을 수 있는 방식을 제한한다. 하지만 그것은 또한 바빌론에 의존하는 소비자 체인이 AVS가 요구할 수 있는 더 광범위한 라이브니스 및 정확성 보장이 아니라 이중서명 수준의 보장을 중심으로 보안 모델을 설계해야 한다는 의미이기도 하다.

슬래싱 경로의 신뢰 가정

바빌론의 슬래싱 경로는 코버넌트 위원회가 서명을 거부하지 않을 것이라는 신뢰에 의존한다. 아이겐레이어의 슬래싱 경로는 AVS 컨트랙트 로직, 아이겐레이어 슬래싱 컨트랙트, 그리고 오퍼레이터의 정직한 AVS 옵트인 등록에 의존한다. 어느 쪽도 엄밀한 의미에서 무신뢰적이지 않다. 관련된 질문은 어떤 신뢰 가정 집합이 적대적 조건에서 더 점진적으로 저하되느냐이며, 그 답은 무엇을 가장 우려하느냐에 달려 있다: 슬래싱을 막기 위해 공모하는 코버넌트 위원회(바빌론의 실패 모드), 아니면 정직한 오퍼레이터를 슬래싱하는 슬래싱 컨트랙트 버그나 AVS 설정 오류(아이겐레이어의 실패 모드).

보상, 자본 효율, 오퍼레이터 선정

img4

경제적 차이가 가장 가시적으로 드러나는 것은 보상과 선정 레이어다.

아이겐레이어에서 여러 AVS에 옵트인한 오퍼레이터는 각각으로부터 보상을 얻는 한편, 기반 ETH는 비콘체인 컨센서스 보상(네이티브 리스테이킹의 경우)이나 LST 수익률(LST의 경우)을 계속 얻는다. 오퍼레이터 입장에서 한계 경제 논리는 간단하다: 추가 AVS마다 동일한 스테이크를 담보로 하면서 보상 흐름이 추가된다. 이것이 아이겐레이어 초기 성장을 이끈 자본 효율 주장이다. 반대 압력은 리스크 누적이다: AVS마다 슬래싱 표면이 추가되며, 잘못 설정된 AVS 하나가 그것을 담보로 하는 모든 스테이크를 위험에 빠뜨릴 수 있다.

스테이커는 차례로 어떤 오퍼레이터에게 위임할지, 그 오퍼레이터가 어떤 AVS를 실행하는지 추론해야 한다. 프로토콜은 스테이커가 특정 AVS를 옵트아웃할 수 있는 메커니즘을 제공하지만, 실제로 대부분의 스테이커는 오퍼레이터 평판을 기반으로 위임하고 번들을 수용한다. 그 결과 자본 효율은 높지만 리스크는 가격 산정이 어려운 방식으로 서비스 전반에 걸쳐 상관되는 시스템이 된다.

바빌론의 경제구조는 다르게 작동한다. BTC 스테이커는 파이널리티 프로바이더가 서비스하는 각 소비자 체인으로부터 해당 체인의 네이티브 토큰(또는 소비자 체인이 보상 단위로 선택한 것)으로 보상을 받는다. 동일한 BTC가 여러 체인을 서비스하는 파이널리티 프로바이더를 원칙적으로 뒷받침할 수 있어, 바빌론도 자체적인 자본 효율 주장을 갖는다. 하지만 기반 BTC는 비콘체인 보상에 해당하는 것을 전혀 얻지 못한다 — 비트코인에는 네이티브 스테이킹 수익률이 없다 — 따라서 BTC 스테이커의 전체 보상은 소비자 체인 보상의 합계다. 이는 바빌론에서 소비자 체인의 보상 설계가 아이겐레이어에서 AVS 보상 설계보다 경제적으로 더 중심적임을 의미한다. 아이겐레이어에서는 그 아래에 항상 기본 스테이킹 수익률이 존재하기 때문이다.

선정과 집중

두 시스템 모두 집중 문제에 직면한다: 위임된 스테이크가 오퍼레이터 또는 파이널리티 프로바이더에 걸쳐 어떻게 분산되며, 그 분산이 보안에 무엇을 의미하는가?

아이겐레이어의 오퍼레이터 집합은 기존 이더리움 스테이킹 오퍼레이터 집합 — 대형 LST 발행자, 확립된 스테이킹-서비스형 공급자, 그리고 소규모 오퍼레이터의 긴 테일 — 과 상당히 겹치는 경향이 있다. 가장 많은 위임을 유치하는 오퍼레이터는 보통 기반 스테이킹 레이어에서 강한 평판 기록을 가진 곳들이며, 이는 이더리움 스테이킹에 이미 존재하는 것과 유사한 집중을 낳는다. 리스크는 주요 AVS에서 단일 오퍼레이터의 슬래싱 이벤트가 리스테이킹된 ETH의 상당 부분으로 전파될 수 있다는 것이다.

바빌론의 파이널리티 프로바이더 집합은 구조적으로 더 신생이다. 프로토콜보다 먼저 존재하는 “비트코인 스테이킹 오퍼레이터” 집합이 없기 때문이다. 파이널리티 프로바이더는 소비자 체인별로 모집되며, 동일한 주체가 많은 체인에서 파이널리티 프로바이더 인프라를 운영할 수 있다. 초기 분산은 어떤 주체가 먼저 참여하느냐에 크게 의존하며, 최종 분산이 얼마나 집중될지에는 의미 있는 경로 의존성이 있다.

보상 통화와 BTC 누적 문제

언급할 가치가 있는 미묘한 경제적 포인트가 있다. 아이겐레이어 보상은 보통 AVS가 발행한 토큰이나 ETH로 지급되며, 리스테이커는 이를 보유하거나 전환할 수 있다. AVS 토큰의 경우 장기적인 경제적 노출이 ETH에서 AVS 쪽으로 이동하는데, 이는 의도적인 설계 선택이다 — 리스테이커는 부분적으로 AVS 경제에 투자하는 것이다.

바빌론 보상은 소비자 체인이 자체 토큰으로 지급하지만, 스테이커의 원금은 BTC다. BTC 단위를 유지하고 싶은 BTC 스테이커는 소비자 체인 보상 토큰을 계속해서 BTC로 전환해야 하며, 이는 소비자 체인 토큰에 유기적 수요가 없는 한 지속적인 매도 압력 누출을 만들어낸다. 따라서 바빌론 소비자 체인의 보상 설계는 주요 스테이커들이 보상 토큰의 자연스러운 장기 보유자가 아니라는 사실을 감안해야 한다.

BTCFi와 ETHFi에 대한 하위 결과

img5

아키텍처적 차이는 하위 생태계에서 서로 다른 형태를 만들어낸다.

ETHFi는, 리스테이킹된 ETH를 중심으로 성장한 서비스들의 총체로 광범위하게 정의할 수 있는데, 아이겐레이어의 추상화가 장려하는 방향으로 발전해왔다: 다양한 이질적 AVS들, 오퍼레이터와 AVS 전반의 노출을 묶는 유동 리스테이킹 토큰 레이어, 그리고 결과적인 수익률 흐름을 가격 산정하고 거래하는 파생상품 레이어. 자본 효율 이야기는 다층적 금융화로 복합되었으며, LST 생태계가 성숙하는 것을 지켜본 사람이라면 친숙하게 느끼겠지만 더 많은 자유도와 더 상관된 리스크를 갖는다.

BTCFi는 바빌론의 렌즈를 통해 보면 다르게 발전해왔다. 주요 하위 소비자는 임의의 서비스가 아니라 파이널리티 뒷받침을 원하는 체인들이다. 바빌론-스테이킹된 BTC를 위한 유동 스테이킹 토큰은 존재하며 성장하고 있지만, AVS 동등 레이어 — BTC 보안을 소비하는 이질적 서비스의 마켓플레이스 — 는 앞서 설명한 슬래싱 조건 한계에 의해 구조적으로 제약된다. BTCFi가 ETHFi에 없는 것을 가진다면, 그것은 네이티브 비트코인 수탁의 신뢰성이다: 기반 자산이 기반 체인을 떠나지 않으며, 그 속성 자체가 래핑되거나 브릿지된 BTC를 결코 고려하지 않았을 보유자 계층에게 하나의 제품 특성이 된다.

합리적인 요약은 이렇다: 아이겐레이어는 보안을 소비할 수 있는 서비스의 폭을 최적화하고, 바빌론은 소비되는 보안의 정당성을 최적화한다. 두 축 모두 중요하며, 두 생태계는 수렴보다는 공존할 가능성이 높다.

주목할 점과 미결 과제

향후 몇 분기 동안 주목해야 할 가장 중요한 변수는 헤드라인 스테이킹 금액이 아니라 구조적인 것들이다.

바빌론에 대한 질문들: 비트코인 스크립트 기본 기능이 개선됨에 따라 코버넌트 위원회가 어떻게 진화할지, 파이널리티 프로바이더 집중이 아이겐레이어가 직면한 것과 같은 상관 슬래싱 리스크를 만들어낼지, 그리고 소비자 체인이 BTC 스테이커를 소비자 체인 토큰에 대한 장기 노출 없이 유지할 수 있는 보상 구조를 설계할 수 있을지다. 더 깊은 미결 질문은 아이겐레이어보다 좁은 바빌론의 슬래싱 표면이 이를 채택하는 소비자 체인에 충분할 것인지, 아니면 생태계가 결국 비트코인 측 업그레이드를 필요로 하는 더 풍부한 조건을 요구하게 될지다.

아이겐레이어에 대한 질문들: AVS가 실제 조건을 대규모로 집행하기 시작할 때 슬래싱이 실제로 어떻게 작동할지, 오퍼레이터를 공유하는 AVS 전반에 걸쳐 리스크가 어떻게 쌓이는지, 그리고 유동 리스테이킹 레이어가 충분한 불투명성을 도입해 스테이커가 누적 슬래싱 노출을 의미 있게 추론할 수 없게 될지다. 더 넓은 미결 질문은 설계상 일반적인 AVS 추상화가 리스테이킹된 ETH 공급을 흡수할 만큼 충분히 보안이 필요한 서비스를 실질적으로 만들어낼지, 아니면 보상 희석이 오퍼레이터 경제구조를 재편할지다.

이 비교는 경마가 아니다. 바빌론과 아이겐레이어는 겹치지만 다른 질문들에 대한 답이며, 서로 다른 제약 조건 아래 구축되고, 서로 다른 소비자를 끌어들이며, 서로 다른 하위 경제를 만들어낸다. 유용한 틀은 어떤 모델이 승리하느냐가 아니라, 각 설계가 어떤 제약을 내재화했고 어떤 것을 유보했는지다. 바빌론은 슬래싱 조건 표현성을 유보하는 대신 네이티브 수탁을 택했다. 아이겐레이어는 수탁 보장을 유보하는 대신 슬래싱 조건 표현성을 택했다. 하위 생태계는 그 트레이드오프를 충실히 반영하고 있으며, 앞으로 나올 가장 흥미로운 BTCFi와 ETHFi의 발전은 각 모델의 결을 거스르는 것이 아니라 결을 따라 작동하는 것들일 가능성이 높다.

cover

はじめに

「共有セキュリティ」という言葉は、バビロンと EigenLayer の両方に頻繁に当てはめられるため、この二つはしばしば一つのアイデアのビットコイン版・イーサリアム版として語られる。すなわち、既存資産の経済的重みを活用し、自力でセキュリティをブートストラップできないチェーンやサービスに貸し出すというコンセプトだ。この切り口は便利であり、部分的には正しい。どちらのプロトコルも、ベース資産からセキュリティを引き出し、コンシューマー側に投影する。また、賃借したセキュリティに実効性をもたせる信頼できる脅威として、スラッシングに依存している点も共通する。

しかし、その表面的な説明の下にある設計は、ほぼすべての層で乖離しており、その乖離は重大な意味を持つ。バビロンのモデルは、Bitcoin スクリプトが表現できること、チューリング完全でないチェーンが検証できることという制約の上に成立している。EigenLayer のモデルは、イーサリアムのコントラクトがカストディできること、オペレーターセットが強制できることという制約の上に成立している。これらの制約は対称ではなく、それぞれのエコシステムを異なる均衡へと向かわせる。オペレーターの経済性、コンシューマーチェーンの形状、基盤となるステーカーのリスクプロファイル、いずれも異なる。

本稿では、五つの軸に沿って両システムを比較する。ステークのカストディ方法、スラッシングの執行方法、報酬の流れ、オペレーター・ファイナリティプロバイダーの選択方法、そして資本効率の複利的な積み重ねだ。そのうえで、各モデルが BTCFi および ETHFi エコシステムに対して何を意味するかを考察する。目的は両プロトコルを序列化することではない。両者は重複しつつも異なる問題を解いている。むしろ、構造的な違いを十分に明確にすることで、安易な同一視を止める助けにすることが狙いだ。

ステークはどのように保持されるか

img1

バビロンと EigenLayer の最も根本的な違いは、ステークされた資産が実際にどこに置かれ、誰が鍵を持つかという点にある。

バビロンでは、BTC はビットコインを離れない。ステーカーは UTXO を二つの主要な支出経路を持つスクリプトにロックするトランザクションを構築する。一つは、遅延後に BTC をステーカーへ返すタイムロック付きのアンボンディング経路、もう一つは、不正を働いたファイナリティプロバイダーに対してコベナントコミッティーが連署した場合に BTC をバーンアドレスに送るスラッシング経路だ。ステーカーは自らの資金の秘密鍵を終始保持する。ブリッジも、ラップされた表現も、ステーカーのためにプールされた BTC を保管するカストディアンも存在しない。コンシューマーチェーンは Bitcoin ブロックを(通常はライトクライアントリレーまたはボートエクステンションのメカニズムを通じて)読み取ることで、どのステークが現在アクティブで、どのファイナリティプロバイダーを支持しているかを把握する。

EigenLayer では、ETH またはリキッドステーキングトークンがイーサリアム上のストラテジーコントラクトに預け入れられる。ネイティブリステーキングの場合、ステーカーはビーコンチェーンの引き出し認証情報を EigenPod コントラクトに向ける。プロトコルはそのバリデータのステータスをビーコン状態に照らして証明し、スラッシングの場合にはステークを適切に処理できる。LST リステーキングの場合は、LST が直接ストラテジーコントラクトによって保持される。いずれの場合も、資産はステーカーが単独で制御できなくなったイーサリアムのスマートコントラクトによってカストディされる。引き出しはプロトコルのキューと、オペレーターがオプトインしている AVS によって制限される。

このカストディの非対称性は下流に影響を与える。バビロンのステーカーは Bitcoin スクリプトリスクとコベナントコミッティーリスクにさらされるが、別チェーン上のスマートコントラクト実行リスクはない。EigenLayer のステーカーは、イーサリアムのスマートコントラクトリスクの全範囲に加え、選択したオペレーターがオプトインしているすべての AVS の累積リスクにさらされる。逆に、EigenLayer はイーサリアムが任意のコードを実行できるため、任意に複雑なスラッシングロジックをサポートできる。一方、バビロンはすべての条件を Bitcoin スクリプトが検証できる形式か、コベナントコミッティーが証明を信頼できる形式でエンコードしなければならない。

コベナントによる妥協

バビロンのスラッシング経路は、事前署名済みのコベナントに依存している。ステーキング時に、コベナント署名者のコミッティーが、二重署名の不正証明と一緒に公開されれば、ステークされた BTC を使用不可能なアウトプットに送るトランザクションに事前署名する。Bitcoin スクリプト単体では Tendermint スタイルの二重送信証明を検証できないため、コベナントコミッティーがプログラマブルなアダプターとして機能する。オフチェーンのプロセスが検証した証拠を条件として、スラッシングをあらかじめ承認するのだ。コミッティーは資金を盗むことはできない(事前署名されたトランザクションはバーンアドレスにのみ送金される)が、署名を拒否することはできる。そのため、コミッティーは結託を高コストにするよう規模が設定され、ローテーションされる。将来的に Bitcoin のアップグレードでより豊富なスクリプトのプリミティブが有効になれば、コミッティーの役割は縮小または排除されるだろう。それまでの間、コベナントコミッティーは、バビロンが「Bitcoin スクリプトによって執行されるスラッシング」を主張するうえで不可欠な存在だ。

共有セキュリティはコンシューマーにどのように接続されるか

img2

コンシューマー側の形状は、ステーキング側以上に異なっている。

EigenLayer のコンシューマーは AVS(Actively Validated Service)だ。AVS とは、EigenLayer コントラクトに登録し、独自のスラッシング条件を定義し、オペレーターを募集する任意のシステムを指す。EigenLayer のドキュメントで挙げられる典型的な例には、データアベイラビリティレイヤー、オラクルネットワーク、ブリッジ、コプロセッサーなどがあるが、この抽象概念は、ボンデッドオペレーターセットの恩恵を受けるほぼあらゆるサービスをカバーできるほど広い。AVS はチェーンである必要はない。ブロックを生成する必要もない。オペレーターが何をすべきか、どのような証拠がスラッシングを引き起こすかを定義するだけでよい。

一方、バビロンのコンシューマーは主にチェーンだ。具体的には、BTC に裏付けられたファイナリティプロバイダーからのボートによって情報を得られるファイナリティガジェットを持つチェーンを対象とする。バビロンの設計は、コンシューマーが外部の経済的重みによって恩恵を受けるファイナリティの概念を持つことを前提としている。CometBFT の上で高速ファイナリティを求める Cosmos SDK チェーン、外部のファイナリティレイヤーを求めるロールアップ、リオーグ耐性を求める L2 などが例として挙げられる。スラッシング条件は Bitcoin スクリプトとコベナントアダプターが検証できるものに限られるため、実際にはファイナリティプロバイダーによる二重署名または二重送信に限定される。「オペレーターがデータブロブの公開に失敗した」といった任意のオフチェーン条件は、EigenLayer のように本来的には表現できない。

これが最も深い構造的な違いだ。EigenLayer は、供給側(ETH)が均質で、需要側(AVS)が不均質かつ制約のないマーケットプレイスだ。バビロンは、供給側(BTC)が均質で、需要側がチェーンアーキテクチャでは不均質だが、スラッシング条件においては均質なセキュリティパイプだ。すなわち、スラッシング条件は大まかに「ファイナリティプロバイダーとして二重送信しない」という一点に集約される。したがって、両プロトコルは異なるコンシューマープロファイルを引き付ける。EigenLayer はセキュリティニーズが特異なサービスを引き付け、バビロンはファイナリティグレードの経済的裏付けを必要とし、その制約を前提に設計する意志のあるチェーンを引き付ける。

ファイナリティプロバイダーとオペレーター

バビロンでは、コンシューマーチェーンのブロックに投票するエンティティを ファイナリティプロバイダー と呼ぶ。BTC ステーカーは自分のステークを一つ以上のファイナリティプロバイダーに委任し、特定のコンシューマーチェーンにおけるファイナリティプロバイダーの投票ウェイトは、そのチェーン向けに委任された BTC の合計となる。スラッシングはファイナリティプロバイダー単位だ。ファイナリティプロバイダーが二重署名した場合、そのチェーンで委任されたすべての BTC が、事前署名済みのスラッシングトランザクションを通じてリスクにさらされる。

EigenLayer では、これに相当する役割が オペレーター だ。ステーカー(または LST ホルダー)はオペレーターに委任し、オペレーターは AVS のセットにオプトインする。特定の AVS におけるオペレーターのスラッシング可能なステークは、その AVS を明示的に除外していないステーカーからの委任の合計だ。オペレーターはどの AVS を運用するかを選択し、ステーカーはそれに対して拒否権を持つ。このような間接性——オペレーターが AVS を選択し、ステーカーがオペレーターを選択する——により、ステーカーが把握すべき累積リスクプロファイルが生まれる。追加 AVS のたびにオペレーターのスラッシング対象面が広がるからだ。

スラッシングの仕組み

img3

スラッシングのメカニズムは、両設計が最も具体的に異なる部分であり、同時にマーケティング的なごまかしが最も多く生じる部分でもある。

バビロンのスラッシングは、Bitcoin の決済によって執行される。ファイナリティプロバイダーがコンシューマーチェーンで二重署名を行うと、二重送信が検出され(通常はコンシューマーチェーン自身のバリデータまたはウォッチャーによって)、証拠が提出され、コベナントコミッティーが事前署名済みのスラッシングトランザクションに連署し、得られた Bitcoin トランザクションがブロードキャストされる。確認が取れると、ステークされた BTC はバーンアドレスに送られる。スラッシングは Bitcoin ブロックのファイナリティで完結する。これは遅く(安全を見れば1時間以上かかる)、しかし他のチェーンやコントラクトがロールバックできないという意味で無条件だ。

EigenLayer のスラッシングは、イーサリアムのスマートコントラクトによって執行される。AVS がスラッシング可能なイベントを検出すると、スラッシングコントラクトに証拠を提出し、コントラクトが条件を検証してオペレーターのリステーキングされたステークを削減する(そして比例的に、その AVS にエクスポージャーを持つステーカーの委任ステークも削減される)。スラッシングはイーサリアムのファイナリティで完結し、Bitcoin よりも高速だが、EigenLayer コントラクトと AVS のスラッシングロジックによって完全に仲介される。スラッシング可能な条件の豊富さは、イーサリアムコントラクトが検証できる範囲に限られる。

実際にスラッシングできる対象

この表現力の差は実際に重要だ。EigenLayer は原理的に、任意の検証可能な不正行為に対してスラッシングできる。データブロブへの署名失敗、無効なアテステーションの生成、閾値を超えたオフライン、コプロセッサーでの矛盾したステートルートへの署名などだ。特定の AVS が実際にそのような条件を定義・執行するかは別の問題であり、初期の AVS デプロイメントは概して保守的だったが、フレームワークとしてはサポートしている。

バビロンのフレームワークはより狭い。ファイナリティプロバイダーによる二重送信が標準的なスラッシング対象だ。活性障害(ファイナリティプロバイダーのオフライン)は、Bitcoin 上でネガティブを証明することが構造的に難しいため、スラッシングではなくステークのアンボンディングやジェイリングで対処されるのが一般的だ。この狭い対象範囲は、ある意味では有利でもある。ステーカー自身が行っていない不正行為によって BTC が失われる経路が限られるからだ。しかし一方で、バビロンに依存するコンシューマーチェーンは、AVS が要求できるより広範な活性・正確性の保証ではなく、二重送信レベルの保証を前提としてセキュリティモデルを設計しなければならない。

スラッシング経路における信頼の前提

バビロンのスラッシング経路は、コベナントコミッティーが署名を拒否しないことを信頼する。EigenLayer のスラッシング経路は、AVS コントラクトのロジック、EigenLayer のスラッシングコントラクト、およびオペレーターによる AVS オプトイン登録の誠実さを信頼する。どちらも厳密な意味でトラストレスではない。重要な問いは、どちらの信頼前提が敵対的な条件下でより緩やかに劣化するかであり、その答えは何を最も懸念するかによって異なる。スラッシングを阻止するためにコベナントコミッティーが結託するリスク(バビロンの失敗モード)か、スラッシングコントラクトのバグや AVS の設定ミスによって誠実なオペレーターがスラッシングされるリスク(EigenLayer の失敗モード)かということだ。

報酬、資本効率、オペレーターの選択

img4

報酬と選択のレイヤーは、経済的な乖離が最も明確に現れる部分だ。

EigenLayer では、複数の AVS にオプトインしたオペレーターはそれぞれから報酬を得る。同時に、基盤となる ETH はビーコンチェーンのコンセンサス報酬(ネイティブリステーキングの場合)または LST の利回り(LST の場合)を引き続き獲得する。オペレーターにとっての限界的な経済的論拠は明快だ。AVS を追加するたびに報酬の流れが増える一方、同じステークがすべてを担保する。これが EigenLayer の初期成長を牽引した資本効率の主張だ。その反作用として、リスクの積み重ねが生じる。各 AVS がスラッシング対象面を広げ、設定を誤った AVS がそれを担保するすべてのステークを危険にさらしうる。

ステーカーは、どのオペレーターに委任するか、そのオペレーターがどの AVS を運用しているかを考慮しなければならない。プロトコルはステーカーが特定の AVS をオプトアウトする仕組みを提供しているが、実際にはほとんどのステーカーはオペレーターの評判を基に委任し、パッケージをそのまま受け入れる。その結果、資本効率は高いが、リスクがサービスをまたいで相関する形で集積し、適切な価格付けが難しくなる。

バビロンの経済性は異なる仕組みで動く。BTC ステーカーは、自分のファイナリティプロバイダーが担当する各コンシューマーチェーンから報酬を得る。報酬はコンシューマーチェーンのネイティブトークン(またはコンシューマーチェーンが報酬の建値として選択したもの)で支払われる。同一の BTC が原理的に複数のチェーンを担当するファイナリティプロバイダーを支持できるため、バビロン独自の資本効率の主張も成立する。しかし、基盤となる BTC はビーコンチェーンの報酬に相当するものを何も得ない。Bitcoin にはネイティブのステーキング利回りがないため、BTC ステーカーへの報酬全体はコンシューマーチェーンからの報酬の合計となる。これにより、コンシューマーチェーンの報酬設計がバビロンにおいてより経済的に中心的な意味を持つ。EigenLayer では常にベースとなるステーキング利回りが下地にあるが、バビロンにはそれがない。

選択と集中

両システムともに集中の問いに直面している。委任されたステークはオペレーターやファイナリティプロバイダーにどのように分散するか、そしてその分布はセキュリティにとって何を意味するか。

EigenLayer のオペレーターセットは、既存のイーサリアムステーキングオペレーターセット——大手 LST 発行者、確立されたステーキング・アズ・ア・サービスプロバイダー、そして多数の中小オペレーター——と大きく重複してきた。最も多くの委任を集めるオペレーターは、通常、基盤となるステーキングレイヤーで強い実績を持つところであり、イーサリアムステーキングですでに存在する集中に類似した集中を生む。リスクは、主要な AVS における単一オペレーターのスラッシングイベントが、リステークされた ETH の大部分に伝播しうるという点だ。

バビロンのファイナリティプロバイダーセットは構造的に新しい。なぜなら、既存のオペレータートポロジーを継承しないからだ。バビロン以前には「Bitcoin ステーキングオペレーター」のセットは存在しない。ファイナリティプロバイダーはコンシューマーチェーンごとに募集され、同一エンティティが多くのチェーンでファイナリティプロバイダーのインフラを運用することもある。初期の分布は、どのエンティティが最初に参加するかに大きく依存し、最終的な集中度には意味のあるパス依存性がある。

報酬通貨と BTC スタッキングの問題

一点、掘り下げる価値のある微妙な経済的論点がある。EigenLayer の報酬は通常 AVS が発行したトークンまたは ETH で支払われ、リステーカーはそれを保持するか換金するかを選べる。AVS トークンの場合、長期的な経済的エクスポージャーが ETH から AVS にシフトする。これは意図的な設計上の選択であり、リステーカーは部分的に AVS のエコノミーに参加することになる。

バビロンの報酬はコンシューマーチェーンが自チェーンのトークンで支払うが、ステーカーの元本は BTC だ。BTC 建てのポジションを維持したい BTC ステーカーは、コンシューマーチェーンの報酬トークンを継続的に BTC に換金しなければならない。これにより、コンシューマーチェーントークンにオーガニックな需要がない限り、じわじわと売り圧力が生じる。したがって、バビロンのコンシューマーチェーンの報酬設計は、主要なステーカーたちが報酬トークンの長期ホルダーには自然となりにくいという事実を考慮しなければならない。

BTCFi と ETHFi への下流の影響

img5

アーキテクチャの違いは、下流のエコシステムの形状にも異なる影響を与える。

広義の ETHFi——リステークされた ETH を中心に成長してきたサービスの総体——は、EigenLayer の抽象概念が促す方向、すなわち多様な AVS が林立し、オペレーターと AVS にまたがるエクスポージャーをバンドルするリキッドリステーキングトークンのレイヤーが生まれ、得られる利回りストリームを価格付けして取引するデリバティブレイヤーが発展するという方向に進んできた。資本効率のストーリーは多層的な金融化へと複利的に積み重なり、LST エコシステムの成熟を見てきた者には見覚えのある光景だが、自由度がより高く、相関リスクも大きい。

BTCFi は、バビロンというレンズを通して見ると、異なる発展を遂げてきた。主要な下流コンシューマーは、経済的なセキュリティを求める任意のサービスではなく、ファイナリティの裏付けを求めるチェーンだ。バビロンでステークされた BTC に対するリキッドステーキングトークンは存在し成長しているが、AVS に相当するレイヤー——BTC セキュリティを消費する多様なサービスのマーケットプレイス——は、先に述べたスラッシング条件の限界によって構造的に制約されている。ETHFi にはないが BTCFi が持つものとして、ネイティブ Bitcoin カストディの信頼性がある。基盤となる資産は決してベースチェーンを離れない。この特性は、ラップや ブリッジされた BTC を検討すら考えなかったホルダー層にとっての、それ自体がプロダクトフィーチャーだ。

まとめると、EigenLayer はセキュリティを消費できるサービスの幅を最大化し、バビロンは消費されるセキュリティの正当性を最大化すると言えるだろう。両軸ともに重要であり、両エコシステムは収束するのではなく共存していく可能性が高い。

注目すべき変数と未解決の問い

今後数四半期で注目すべき最も重要な変数は、ステーク額のヘッドラインナンバーではなく、構造的なものだ。

バビロンについては以下の問いが鍵となる。Bitcoin スクリプトのプリミティブが改善されるにつれてコベナントコミッティーがどのように進化するか、ファイナリティプロバイダーの集中が EigenLayer が直面するような相関スラッシングリスクを生み出すかどうか、そしてコンシューマーチェーンが、BTC ステーカーをコンシューマーチェーントークンへの長期エクスポージャーに晒すことなく引き留められる報酬構造を設計できるかどうかだ。より深い未解決の問いは、EigenLayer のものより狭いバビロンのスラッシング対象面が、採用するコンシューマーチェーンにとって十分であると判明するか、それともエコシステムが最終的に Bitcoin 側のアップグレードを必要とするより豊富な条件を求めるようになるかという点だ。

EigenLayer については以下の問いが鍵となる。AVS が本番環境でライブ条件を本格的に執行し始めた際にスラッシングが実際にどのように機能するか、オペレーターを共有する AVS 間でリスクがどのように積み重なるか、そしてリキッドリステーキングレイヤーが、ステーカーが自らの累積スラッシングエクスポージャーを実質的に把握できなくなるほどの不透明さをもたらすかどうかだ。より広い未解決の問いは、設計上ジェネリックである AVS の抽象概念が、リステークされた ETH の供給を吸収するのに十分な、本当の意味でセキュリティを必要とするサービスを生み出すか、それとも報酬の希薄化がオペレーターの経済性を再形成するかという点だ。

この比較は優劣を争うものではない。バビロンと EigenLayer は、重複しつつも異なる問いに対する答えであり、異なる制約のもとで構築され、異なるコンシューマーを引き付け、異なる下流エコノミーを生み出している。有用な切り口は、どちらのモデルが勝つかではなく、各設計がどの制約を内部化し、どの制約を先送りにしたかという点だ。バビロンはスラッシング条件の表現力を先送りにする代わりに、ネイティブカストディを得た。EigenLayer はカストディの保証を先送りにする代わりに、スラッシング条件の表現力を得た。下流のエコシステムはそのトレードオフを忠実に反映しており、今後登場する最も興味深い BTCFi および ETHFi の展開は、各モデルの本質的な性質に逆らうのではなく、それを活かす形で生まれるものになるだろう。

cover

引言

“共享安全”这一概念频繁地被同时用于描述 Babylon 与 EigenLayer,以至于二者常被当作同一思路在比特币和以太坊两条链上的镜像实现:借用现有资产的经济体量,将其出租给无力自行引导安全性的链或服务。这种表述既简洁,也在一定程度上成立。两个协议都从基础资产中提取安全性,并将其投射到一批消费方。两者都以罚没作为可信威胁,使租用的安全性具备真正的约束力。

但在这层表面描述之下,两种设计几乎在每个维度上都走向了分歧,而这种分歧影响深远。Babylon 的模型受制于比特币脚本所能表达的内容,以及一条非图灵完备链所能验证的边界。EigenLayer 的模型则受制于以太坊合约能够托管的资产范围,以及能够强制要求一组运营者执行的任务。这两种约束并不对称,它们将两个生态系统推向了不同的均衡态——运营者经济学不同、消费方链的形态不同、底层质押者所面临的风险特征也不同。

本文将从五个维度对两套系统进行比较:权益的托管方式、罚没的执行机制、收益的流转路径、运营者或终局性提供者的选择机制,以及资本效率的复合方式。随后,我们将探讨两种模型分别对依赖它们的下游 BTCFi 与 ETHFi 生态意味着什么。本文的目的不在于评判两个协议的优劣——它们解决的是相互交叠但本质不同的问题——而是将二者的结构性差异阐述得足够清晰,以便观察者不再将它们混为一谈。

权益的托管方式

img1

Babylon 与 EigenLayer 之间最根本的差异,在于被质押资产实际所处的位置,以及谁掌握密钥。

在 Babylon 中,BTC 始终留在比特币网络上。质押者构造一笔交易,将一个 UTXO 锁入一个脚本,该脚本包含两条主要的花费路径:一条是有时间锁的解绑路径,延迟后将 BTC 归还给质押者;另一条是罚没路径,若盟约委员会针对行为不端的终局性提供者联署交易,则将 BTC 发送至类销毁地址。质押者自始至终保留自身资金的私钥,不存在跨链桥、无需包装资产,也没有托管方代为持有质押者的 BTC。消费方链通过读取比特币区块(通常借助轻客户端中继或投票扩展机制),获知哪些权益当前处于活跃状态以及它们所支持的终局性提供者。

在 EigenLayer 中,ETH 或流动性质押代币被存入以太坊上的策略合约。对于原生再质押,质押者将其信标链的提款凭证指向 EigenPod 合约;协议随后可以对照信标链状态证明验证者的状态,并在发生罚没时路由相应权益。对于 LST 再质押,LST 则直接由策略合约持有。无论哪种情况,资产均由以太坊智能合约托管,质押者无法再单方面控制——提款受到协议队列以及运营者所选择加入的 AVS 的约束。

托管方式的非对称性带来了连锁影响。Babylon 的质押者面临比特币脚本风险和盟约委员会风险,但不承担另一条链上智能合约执行层面的风险。EigenLayer 的质押者则暴露于以太坊智能合约的全部攻击面,叠加其所选运营者加入的每一个 AVS 的累积风险。反过来,EigenLayer 支持任意复杂的罚没逻辑,因为以太坊能够运行任意代码;而 Babylon 必须将每一个条件编码成比特币脚本可验证的形式,或依赖盟约委员会进行可信证明。

盟约机制的折衷

Babylon 的罚没路径依赖于预签名的盟约交易。在质押时,一个由盟约签名者组成的委员会联署一笔交易:一旦该交易与双签的欺诈证明一同发布,被质押的 BTC 将被发送至一个不可花费的输出。比特币脚本本身无法验证 Tendermint 风格的双签证明,因此盟约委员会充当了一个可编程的适配器——它以链下流程所验证的证据为前提,预先授权执行罚没。委员会无法窃取资金(预签名交易仅将资金路由至销毁地址),但可以拒绝签署,这正是为何委员会的规模和轮换设计旨在使共谋代价高昂。未来若比特币升级引入更丰富的脚本原语,委员会的角色将会收缩乃至消除;在此之前,它是 Babylon 得以声称”由比特币脚本强制执行罚没”的关键承重结构。

共享安全如何接入消费方

img2

消费方侧的形态差异,甚至比质押侧更为显著。

EigenLayer 的消费方是 AVS——主动验证服务。AVS 是任何向 EigenLayer 合约注册、定义自身罚没条件并招募运营者的系统。EigenLayer 文档中列举的典型案例包括数据可用性层、预言机网络、桥以及协处理器,但这一抽象足够宽泛,几乎可以涵盖任何受益于有保证金运营者集合的服务。AVS 不必是一条链,不必出块,只需定义运营者应当执行什么,以及何种证据将触发罚没。

相比之下,Babylon 的消费方主要是链——具体而言,是那些拥有终局性机制、可以接收 BTC 支持的终局性提供者投票的链。Babylon 的设计假设消费方具备某种终局性概念,且该终局性可从外部经济权重中获益:例如,一条希望在 CometBFT 之上实现快速终局的 Cosmos SDK 链、一条需要外部终局性层的 Rollup,或一条追求抗重组能力的 Layer 2。罚没条件受限于比特币脚本和盟约适配器所能验证的范围,这在实践中意味着罚没仅针对终局性提供者的双签或模糊行为。“运营者未能发布数据块”之类的任意链下条件,并不像在 EigenLayer 上那样原生可表达。

这是两者之间最深层的结构性差异。EigenLayer 是一个市场:供给侧(ETH)同质,需求侧(AVS)异质且无约束。Babylon 则是一条安全管道:供给侧(BTC)同质,需求侧在链架构上异质,但在罚没条件上同质——大体上始终是”不得以终局性提供者身份双签”。因此,两个协议吸引的消费方画像截然不同。EigenLayer 吸引的是安全需求具有特殊性的服务;Babylon 吸引的是需要终局性级别经济背书、并愿意围绕这一约束进行架构设计的链。

终局性提供者与运营者

在 Babylon 中,对消费方链区块进行投票的实体称为终局性提供者。BTC 质押者将权益委托给一个或多个终局性提供者,终局性提供者在特定消费方链上的投票权重,等于委托给它在该链上权益的 BTC 总量。罚没以终局性提供者为单位:若某终局性提供者双签,通过预签名的罚没交易,委托给该提供者的所有 BTC 均面临风险。

在 EigenLayer 中,类似的角色是运营者。质押者(或 LST 持有者)将权益委托给运营者,运营者随后选择加入一组 AVS。运营者在某 AVS 上的可罚没权益,等于未明确排除该 AVS 的质押者的委托之和。运营者在质押者否决权的约束下自行选择运行哪些 AVS。这种间接性——运营者选择 AVS,质押者选择运营者——产生了一个累积的风险特征,质押者必须对此进行综合判断,因为每新增一个 AVS,都会扩大运营者的罚没敞口。

罚没机制

img3

罚没机制是两种设计最具体的分歧所在,也是最容易出现营销式模糊表述的地方。

Babylon 的罚没由比特币的结算来执行。当终局性提供者在消费方链上双签时,双签行为被检测到(通常由消费方链自身的验证者或守望者发现),证据被提交,盟约委员会对预签名的罚没交易联署,相应的比特币交易随即广播。一旦确认,被质押的 BTC 便落入销毁地址。罚没在比特币区块终局性层面生效——这一过程较慢(保险起见需要一小时以上),但具有无条件性,其他任何链或合约均无法回滚。

EigenLayer 的罚没由以太坊智能合约执行。当 AVS 检测到可罚没事件时,它向罚没合约提交证据,合约验证条件后削减运营者的再质押权益(以及在该 AVS 有敞口的质押者的委托权益)。罚没在以太坊终局性层面生效,速度快于比特币,但完全由 EigenLayer 合约和 AVS 的罚没逻辑所中介。可被罚没的条件丰富程度,仅受以太坊合约可验证范围的约束。

实际可被罚没的内容

可表达性的差距在实践中至关重要。EigenLayer 原则上可以针对任意可验证的不当行为执行罚没:未能签署数据块、产生无效证明、离线超过阈值、在协处理器中签署冲突的状态根。任何特定 AVS 是否真正定义并执行了上述条件是另一个问题——早期 AVS 部署总体上较为保守——但框架本身支持这些条件。

Babylon 的框架则更为狭窄。终局性提供者的双签是典型的可罚没行为。活跃性故障(终局性提供者离线)通常通过权益解绑或监禁处理,而非罚没,因为在比特币上证明”某事未发生”在结构上颇为棘手。这种更窄的罚没面在一定程度上是一种优势:它限制了质押者的 BTC 因自身未曾实施的不当行为而遭受损失的途径。但同时也意味着,依赖 Babylon 的消费方链在设计安全模型时,必须围绕双签级别的保证,而非 AVS 可要求的更广泛的活跃性与正确性保证来展开。

罚没路径中的信任假设

Babylon 的罚没路径信任盟约委员会不会拒绝签署。EigenLayer 的罚没路径则信任 AVS 合约逻辑、EigenLayer 罚没合约,以及运营者对其 AVS 加入情况的诚实注册。严格意义上,两者都不是无需信任的。核心问题在于:哪组信任假设在对抗性条件下降级得更优雅?答案取决于人们最担忧的风险:是盟约委员会共谋阻止罚没(Babylon 的失效模式),还是罚没合约漏洞或 AVS 配置错误导致诚实运营者被罚没(EigenLayer 的失效模式)。

收益、资本效率与运营者选择

img4

在收益与选择层面,经济上的分歧最为显著。

在 EigenLayer 中,加入多个 AVS 的运营者可从每个 AVS 获取收益,而底层 ETH 同时继续赚取信标链共识奖励(原生再质押场景)或 LST 收益(LST 场景)。运营者的边际经济逻辑一目了然:每新增一个 AVS,便增加一条收益流,而相同的权益为所有 AVS 提供抵押。这正是 EigenLayer 早期高速增长背后的资本效率叙事。反向压力则是风险叠加:每个 AVS 都扩大了罚没面,而一个配置错误的 AVS 可能危及为其提供抵押的全部权益。

质押者则需要判断委托哪个运营者,以及该运营者运行哪些 AVS。协议为质押者提供了退出特定 AVS 的机制,但实践中大多数质押者依据运营者声誉进行委托,并接受整体打包的风险敞口。结果是一个资本效率较高、但跨服务风险相关性强且难以定价的系统。

Babylon 的经济逻辑有所不同。BTC 质押者从其终局性提供者所服务的每条消费方链获取收益,收益以消费方链的原生代币计价(或消费方链自行选择的计价单位)。相同的 BTC 原则上可以为一个服务多条链的终局性提供者提供支持,这赋予了 Babylon 自身版本的资本效率优势。但底层 BTC 不产生任何类似信标链奖励的收益——比特币没有原生质押收益——因此 BTC 质押者的全部回报来自消费方链奖励的总和。这使得消费方链的收益设计在 Babylon 生态中的经济重要性,远超 AVS 收益设计在 EigenLayer 中的地位——在 EigenLayer,底层始终存在一个基础质押收益托底。

选择机制与集中度

两个系统都面临集中度问题:委托权益如何在运营者或终局性提供者之间分布,这种分布对安全性意味着什么?

EigenLayer 的运营者群体与现有以太坊质押运营者群体高度重叠——大型 LST 发行方、成熟的质押服务商以及数量众多的中小运营者。吸引最多委托的运营者,通常是在底层质押层具有强大声誉背书的机构,这产生了与以太坊质押中已有的类似集中态势。风险在于,某主要 AVS 上的单次运营者罚没事件,可能会波及大比例的再质押 ETH。

Babylon 的终局性提供者群体在结构上更为新生,因为它不继承任何既有的运营者生态——在该协议出现之前,并不存在”比特币质押运营者”群体。终局性提供者以消费方链为单位进行招募,同一实体可能在多条链上运营终局性提供者基础设施。早期分布在很大程度上取决于哪些实体率先入场,最终集中度的走向具有显著的路径依赖性。

收益货币与 BTC 计价问题

有一个值得深入探讨的细微经济学要点。EigenLayer 的收益通常以 AVS 发行的代币或 ETH 支付,再质押者可选择持有或转换。以 AVS 代币支付的情形,将长期经济敞口从 ETH 转移至 AVS——这是一个刻意为之的设计选择,再质押者在某种程度上是在买入 AVS 的经济体系。

Babylon 的收益由消费方链以其自身代币支付,但质押者的本金是 BTC。真正希望保持以 BTC 计价的 BTC 质押者,必须持续将消费方链的奖励代币兑换回 BTC,这会对消费方链代币产生持续的抛压,除非这些代币具有有机需求。因此,Babylon 消费方链的收益设计,必须正视这样一个现实:其主要质押者并非消费方链奖励代币的天然长期持有者。

对 BTCFi 与 ETHFi 的下游影响

img5

上述架构差异在下游产生了不同的生态形态。

ETHFi——广义上指围绕再质押 ETH 发展起来的服务全集——沿着 EigenLayer 抽象所鼓励的方向演进:大量异质性 AVS、一层将多个运营者与 AVS 敞口打包的流动性再质押代币,以及对由此产生的收益流进行定价与交易的衍生品层。资本效率叙事已复合演化为多层金融化结构,任何见证过 LST 生态成熟的人对此都不陌生——只是自由度更多,相关风险也更高。

BTCFi 从 Babylon 视角来看,则走向了不同的发展路径。主要的下游消费方是寻求终局性背书的链,而非寻求经济安全性的任意服务。Babylon 质押 BTC 的流动性质押代币已经存在并持续增长,但等效于 AVS 的层次——消费 BTC 安全性的异质服务市场——受到前述罚没条件限制的结构性约束。BTCFi 所拥有而 ETHFi 所没有的,是原生比特币托管的可信度:底层资产从不离开其基础链,而这一属性本身就是一种产品特性,面向那些无论如何都不会考虑持有包装或跨链 BTC 的持有者群体。

一个合理的总结是:EigenLayer 优化的是能够消费安全性的服务广度,Babylon 优化的是被消费的安全性本身的正当性。两个维度同等重要,两个生态很可能长期共存,而非走向融合。

值得关注的变量与尚待解答的问题

未来数个季度最值得关注的变量,不是质押总量这类头部数字,而是结构性指标。

对于 Babylon,核心问题是:随着比特币脚本原语的改进,盟约委员会将如何演变;终局性提供者的集中是否会产生 EigenLayer 所面临的那种相关罚没风险;消费方链能否设计出有效的收益结构,在不强迫 BTC 质押者长期持有消费方链代币的前提下留住他们。更深层的开放性问题是:Babylon 比 EigenLayer 更窄的罚没面,是否足以满足选择它的消费方链的需求,还是说生态系统最终将需要更丰富的条件,从而推动比特币层面的升级。

对于 EigenLayer,核心问题是:当 AVS 开始大规模执行实时罚没条件时,罚没在生产环境中实际表现如何;共享运营者的多个 AVS 之间风险如何叠加;流动性再质押层是否引入了足够的不透明度,以至于质押者无法有效评估自身的累积罚没敞口。更宏观的开放性问题是:这一在设计上高度通用的 AVS 抽象,能否产生足够多真正有安全需求的服务,以吸收再质押 ETH 的供给,还是说收益稀释将重塑运营者的经济逻辑。

这不是一场零和竞争。Babylon 与 EigenLayer 是对相互交叠但本质不同问题的回答,在不同约束下构建,吸引不同的消费方,并孕育不同的下游经济。有价值的分析框架不是哪种模式胜出,而是每种设计内化了哪些约束、又将哪些约束留待日后解决。Babylon 以牺牲罚没条件的表达能力,换取了原生托管;EigenLayer 以放弃托管保障,换取了罚没条件的表达能力。下游生态系统正在如实地追踪这些权衡,而 BTCFi 与 ETHFi 最值得期待的发展,很可能正是那些顺势而为、充分利用各自模型特性的创新,而非逆势而动的尝试。

cover

Introducción

El término “seguridad compartida” se aplica con tanta frecuencia tanto a Babylon como a EigenLayer que ambos protocolos terminan tratándose como las versiones Bitcoin y Ethereum de una misma idea: tomar el peso económico de un activo existente y alquilarlo a cadenas o servicios que no pueden construir la suya propia desde cero. El encuadre es conveniente y, en parte, acertado. Ambos protocolos extraen seguridad de un activo base y la proyectan hacia un conjunto de consumidores. Ambos dependen del slashing como amenaza creíble que le da dientes a esa seguridad arrendada.

Sin embargo, los dos diseños divergen en casi todas las capas por debajo de esa descripción superficial, y esa divergencia tiene consecuencias reales. El modelo de Babylon está acotado por lo que Bitcoin script puede expresar y lo que una cadena no Turing-completa puede verificar. El modelo de EigenLayer está acotado por lo que un contrato inteligente de Ethereum puede custodiar y por lo que se puede coaccionar a un conjunto de operadores a ejecutar. Estas restricciones no son simétricas, y empujan a ambos ecosistemas hacia equilibrios distintos: economía de operadores diferente, perfiles de cadenas consumidoras diferentes, perfiles de riesgo diferentes para los stakers del activo subyacente.

En este análisis comparamos los dos sistemas a lo largo de cinco ejes: cómo se custodia el stake, cómo se aplica el slashing, cómo fluyen las recompensas, cómo se seleccionan los operadores o proveedores de finalidad, y cómo se acumula la eficiencia de capital. Luego examinamos qué implica cada modelo para los ecosistemas BTCFi y ETHFi que dependen de ellos. El objetivo no es jerarquizar un protocolo sobre el otro —resuelven problemas que se solapan pero que son distintos—, sino hacer que las diferencias estructurales sean suficientemente legibles como para que los observadores dejen de confundirlos.

Cómo se custodia el stake

img1

La diferencia más fundamental entre Babylon y EigenLayer reside en dónde se encuentra físicamente el activo en staking y quién tiene las llaves.

En Babylon, el BTC nunca abandona Bitcoin. Un staker construye una transacción que bloquea un UTXO en un script con dos caminos de gasto principales: un camino de desbloqueo con timelock que devuelve el BTC al staker tras un período de espera, y un camino de slashing que envía el BTC a una dirección de tipo quema si un comité de covenant co-firma contra un proveedor de finalidad que ha actuado de forma incorrecta. El staker conserva la clave privada de sus propios fondos en todo momento. No hay bridge, no hay representación envuelta, no hay custodio que tenga BTC agrupado en nombre del staker. Las cadenas consumidoras leen bloques de Bitcoin —típicamente a través de un relay de cliente ligero o un mecanismo de extensión de votos— para saber qué stake está activo y qué proveedores de finalidad respalda.

En EigenLayer, ETH o un token de staking líquido se deposita en un contrato de estrategia en Ethereum. En el caso del restaking nativo, el staker apunta la credencial de retiro de su beacon chain a un contrato EigenPod; el protocolo puede entonces probar el estado del validador frente al estado de la beacon chain y, en caso de slashing, enrutar el stake. En el caso del restaking mediante LST, el token de staking líquido es custodiado directamente por un contrato de estrategia. En ambos casos, el activo queda bajo la custodia de contratos inteligentes de Ethereum que el staker ya no controla de forma unilateral: el retiro está sujeto a la cola del protocolo y a los AVSs en los que el operador se haya inscrito.

La asimetría en custodia tiene consecuencias en cascada. Los stakers de Babylon asumen riesgo de Bitcoin script y riesgo del comité de covenant, pero ningún riesgo de ejecución de contratos inteligentes en una cadena separada. Los stakers de EigenLayer asumen toda la superficie de riesgo de contratos inteligentes de Ethereum, más el riesgo acumulado de cada AVS en el que su operador elegido se haya inscrito. A la inversa, EigenLayer puede soportar lógicas de slashing arbitrariamente complejas porque Ethereum puede ejecutar código arbitrario, mientras que Babylon debe codificar cada condición de forma que Bitcoin script pueda verificarla, o en la que un comité de covenant sea de confianza para atestiguarla.

El compromiso del covenant

El camino de slashing de Babylon depende de un covenant prefirmado. En el momento del staking, un comité de firmantes de covenant co-firma una transacción que, si se publica junto con una prueba de fraude de doble firma, envía el BTC en staking a un output inutilizable. Bitcoin script por sí solo no puede verificar una prueba de equivocación al estilo Tendermint, por lo que el comité de covenant actúa como un adaptador programable: preautoriza el slash condicionado a la evidencia que un proceso fuera de la cadena verifica. El comité no puede robar fondos —la transacción prefirmada solo enruta hacia una dirección quema—, pero puede negarse a firmar, razón por la cual el comité tiene un tamaño y una rotación diseñados para hacer que la colusión sea costosa. Una futura actualización de Bitcoin que habilite primitivas de script más ricas reduciría o eliminaría el rol del comité; hasta entonces, es la pieza estructural que permite a Babylon afirmar que el slashing se aplica mediante Bitcoin script.

Cómo se conecta la seguridad compartida a los consumidores

img2

La forma del lado consumidor difiere incluso más que la del lado del staking.

Los consumidores de EigenLayer son AVSs —servicios activamente validados—. Un AVS es cualquier sistema que se registra en los contratos de EigenLayer, define sus propias condiciones de slashing y recluta operadores. Los ejemplos canónicos que cita la documentación de EigenLayer incluyen capas de disponibilidad de datos, redes de oráculos, bridges y coprocesadores, pero la abstracción es lo suficientemente amplia como para abarcar casi cualquier servicio que se beneficie de un conjunto de operadores con stake comprometido. Un AVS no necesita ser una cadena. No necesita producir bloques. Solo necesita definir qué se supone que deben hacer los operadores y qué evidencia desencadenará un slash.

Los consumidores de Babylon son, en contraste, principalmente cadenas —concretamente, cadenas con un gadget de finalidad que puede ser informado por los votos de los proveedores de finalidad respaldados por BTC—. El diseño de Babylon presupone que el consumidor tiene una noción de finalidad que se beneficia del peso económico externo: una cadena Cosmos-SDK que quiere finalidad rápida sobre CometBFT, un rollup que quiere una capa de finalidad externa, un Layer 2 que quiere resistencia a reorganizaciones. La condición de slashing está acotada a lo que Bitcoin script y el adaptador de covenant pueden verificar, lo que en la práctica significa doble firma o equivocación por parte de un proveedor de finalidad. Condiciones arbitrarias fuera de la cadena —como “el operador no publicó un blob de datos”— no son expresables de forma nativa del mismo modo que lo son en EigenLayer.

Esta es la diferencia estructural más profunda. EigenLayer es un mercado donde el lado de la oferta (ETH) es homogéneo y el lado de la demanda (los AVSs) es heterogéneo e irrestricto. Babylon es un canal de seguridad donde el lado de la oferta (BTC) es homogéneo y el lado de la demanda es heterogéneo en arquitectura de cadenas pero homogéneo en condición de slashing: es, en términos generales, siempre “no equivoques como proveedor de finalidad”. Por tanto, los dos protocolos atraen perfiles de consumidores diferentes. EigenLayer atrae servicios cuyas necesidades de seguridad son idiosincrásicas. Babylon atrae cadenas que necesitan respaldo económico al nivel de la finalidad y están dispuestas a arquitectar su diseño en torno a esa restricción.

Proveedores de finalidad vs. operadores

En Babylon, la entidad que vota en los bloques de la cadena consumidora se denomina proveedor de finalidad. Los stakers de BTC delegan su stake en uno o más proveedores de finalidad, y el peso de voto del proveedor de finalidad en una cadena consumidora dada es la suma del BTC delegado a él para esa cadena. El slashing es por proveedor de finalidad: si un proveedor de finalidad hace doble firma, todo el BTC delegado a él en esa cadena está en riesgo a través de la transacción de slashing prefirmada.

En EigenLayer, el rol análogo es el operador. Los stakers (o titulares de LST) delegan en un operador, quien luego se inscribe en un conjunto de AVSs. El stake sujeto a slashing de un operador en un AVS determinado es la suma de las delegaciones de stakers que no han excluido explícitamente ese AVS. El operador elige qué AVSs ejecutar, sujeto al veto del staker. Esta indirección —operadores eligiendo AVSs, stakers eligiendo operadores— produce un perfil de riesgo acumulado sobre el que el staker debe razonar, ya que cada AVS adicional amplía la superficie de slashing del operador.

Mecánica del slashing

img3

El mecanismo de slashing es donde los dos diseños difieren de manera más concreta, y también donde tiende a abundar más la retórica de marketing sin sustancia.

El slashing de Babylon está aplicado por la liquidación de Bitcoin. Cuando un proveedor de finalidad hace doble firma en una cadena consumidora, la equivocación es detectada —típicamente por los propios validadores de la cadena consumidora o por vigilantes—, la evidencia se presenta, el comité de covenant co-firma la transacción de slashing prefirmada, y la transacción de Bitcoin resultante se transmite. Una vez confirmada, el BTC en staking está en la dirección quema. El slash es definitivo a la finalidad de bloque de Bitcoin, que es lenta —más de una hora para estar seguros—, pero incondicional en el sentido de que ninguna otra cadena o contrato puede revertirlo.

El slashing de EigenLayer está aplicado por contratos inteligentes de Ethereum. Cuando un AVS detecta un evento sujeto a slashing, presenta la evidencia al contrato de slashing, que verifica la condición y reduce el stake resteado del operador (y, proporcionalmente, el stake delegado de los stakers que tenían exposición a ese AVS). El slash es definitivo a la finalidad de Ethereum, que es más rápida que la de Bitcoin, pero está mediado en su totalidad por los contratos de EigenLayer y la lógica de slashing del AVS. La riqueza de las condiciones que pueden desencadenar un slash está acotada únicamente por lo que un contrato de Ethereum puede verificar.

Qué puede realmente ser objeto de slashing

La brecha en expresividad importa en la práctica. EigenLayer puede en principio hacer slashing por cualquier comportamiento verificable indebido: no firmar un blob de datos, producir una atestación inválida, desconectarse más allá de un umbral, firmar raíces de estado contradictorias en un coprocesador. Si un AVS determinado realmente define y aplica esas condiciones es una cuestión separada —los primeros despliegues de AVSs han sido generalmente conservadores—, pero el marco las soporta.

El marco de Babylon es más estrecho. La equivocación por parte de un proveedor de finalidad es la falta sujeta a slashing por excelencia. Los fallos de liveness —un proveedor de finalidad que se desconecta— se gestionan típicamente mediante desbloqueo del stake o inhabilitación, no mediante slashing, porque probar un negativo en Bitcoin es estructuralmente incómodo. Esta superficie más estrecha es en parte una característica: limita las formas en que el BTC de un staker puede perderse por comportamientos incorrectos que el staker no cometió. Pero también significa que las cadenas consumidoras que dependen de Babylon deben diseñar su modelo de seguridad en torno a garantías de nivel de equivocación, en lugar de las garantías más amplias de liveness y corrección que un AVS puede exigir.

Supuestos de confianza en el camino del slashing

El camino de slashing de Babylon confía en que el comité de covenant no se niegue a firmar. El camino de slashing de EigenLayer confía en la lógica del contrato del AVS, en los contratos de slashing de EigenLayer, y en el registro honesto por parte del operador de sus inscripciones en AVSs. Ninguno es sin confianza en el sentido estricto. La pregunta pertinente es cuál de los dos conjuntos de supuestos de confianza se degrada de forma más controlada bajo condiciones adversariales, y la respuesta depende de qué le preocupa más a uno: un comité de covenant coludiendo para bloquear un slash (el modo de fallo de Babylon) o un bug en el contrato de slashing o una mala configuración del AVS que haga slashing a operadores honestos (el modo de fallo de EigenLayer).

Recompensas, eficiencia de capital y selección de operadores

img4

La capa de recompensas y selección es donde la divergencia económica se hace más visible.

En EigenLayer, un operador que se inscribe en múltiples AVSs gana recompensas de cada uno, mientras que el ETH subyacente continúa generando recompensas de consenso de la beacon chain (en el caso del restaking nativo) o el rendimiento del LST (en el caso del LST). El argumento económico marginal para un operador es sencillo: cada AVS adicional añade flujos de recompensas mientras el mismo stake los colateraliza a todos. Esta es la afirmación de eficiencia de capital que impulsó buena parte del crecimiento temprano de EigenLayer. La presión contrarrestante es la acumulación de riesgo: cada AVS amplía la superficie de slashing, y un AVS mal configurado puede comprometer todo el stake que lo colateraliza.

El staker, a su vez, debe razonar sobre a qué operadores delega y qué AVSs ejecutan esos operadores. El protocolo proporciona mecanismos para que los stakers se excluyan de AVSs específicos, pero en la práctica la mayoría delegan basándose en la reputación del operador y aceptan el paquete completo. El resultado es un sistema donde la eficiencia de capital es alta, pero el riesgo está correlacionado entre servicios de maneras difíciles de valorar.

La economía de Babylon funciona de manera diferente. Un staker de BTC gana recompensas de cada cadena consumidora a la que sirve su proveedor de finalidad, pagadas en el token nativo de la cadena consumidora (o en la denominación que la cadena consumidora elija). El mismo BTC puede en principio respaldar a un proveedor de finalidad que sirve a múltiples cadenas, dándole a Babylon su propia versión de la afirmación de eficiencia de capital. Pero el BTC subyacente no genera nada análogo a las recompensas de la beacon chain —Bitcoin no tiene rendimiento nativo de staking—, por lo que la totalidad de la recompensa para un staker de BTC es la suma de las recompensas de las cadenas consumidoras. Esto hace que el diseño de recompensas de la cadena consumidora sea económicamente más central en Babylon que el diseño de recompensas del AVS en EigenLayer, donde siempre existe un rendimiento base de staking por debajo.

Selección y concentración

Ambos sistemas enfrentan una pregunta sobre concentración: cómo se distribuye el stake delegado entre operadores o proveedores de finalidad, y qué implica esa distribución para la seguridad.

El conjunto de operadores de EigenLayer ha tendido a solaparse en gran medida con el conjunto de operadores de staking de Ethereum ya existente: grandes emisores de LST, proveedores consolidados de staking como servicio y una larga cola de operadores más pequeños. Los operadores que atraen mayor delegación suelen ser aquellos con un historial reputacional sólido en la capa de staking subyacente, lo que produce una concentración similar a la ya presente en el staking de Ethereum. El riesgo es que un evento de slashing de un solo operador en un AVS importante se propagaría a una gran fracción del ETH resteado.

El conjunto de proveedores de finalidad de Babylon es estructuralmente más nuevo porque no hereda una topología de operadores preexistente —no existe un conjunto de “operadores de staking de Bitcoin” que predate el protocolo—. Los proveedores de finalidad se reclutan por cadena consumidora, y una misma entidad puede operar infraestructura de proveedor de finalidad en muchas cadenas. La distribución temprana depende en gran medida de qué entidades aparecen primero, y existe una dependencia de camino significativa en cuán concentrada acabe siendo la distribución final.

La moneda de las recompensas y el problema del acumulador de BTC

Hay un punto económico sutil que vale la pena sacar a la luz. Las recompensas de EigenLayer se pagan típicamente en tokens emitidos por el AVS o en ETH, que los restakers pueden retener o convertir. El caso del token del AVS desplaza la exposición económica a largo plazo del ETH hacia el AVS, lo cual es una elección de diseño deliberada: los restakers están, en parte, comprando una participación en la economía del AVS.

Las recompensas de Babylon son pagadas por las cadenas consumidoras en sus propios tokens, pero el principal del staker es BTC. Un staker de BTC que realmente desee mantenerse denominado en BTC debe convertir continuamente los tokens de recompensa de las cadenas consumidoras de vuelta a BTC, lo que introduce una presión de venta lenta y constante sobre los tokens de las cadenas consumidoras, a menos que esos tokens tengan demanda orgánica. El diseño de recompensas para una cadena consumidora de Babylon debe, por tanto, tener en cuenta que sus principales stakers no son tenedores naturales a largo plazo del token de recompensa.

Consecuencias en cascada para BTCFi y ETHFi

img5

Las diferencias arquitectónicas producen formas de ecosistema distintas en sentido descendente.

ETHFi, entendido en sentido amplio como el universo de servicios que ha crecido en torno al ETH resteado, se ha desarrollado en la dirección que fomenta la abstracción de EigenLayer: muchos AVSs heterogéneos, una capa de tokens de restaking líquido que agrupan exposición a operadores y AVSs, y una capa de derivados que valora y negocia los flujos de rendimiento resultantes. La narrativa de eficiencia de capital se ha compuesto en una financialización multicapa reconocible para cualquiera que haya observado madurar el ecosistema de LST, solo que con más grados de libertad y más riesgo correlacionado.

BTCFi, visto a través del prisma de Babylon, se ha desarrollado de manera diferente. Los consumidores principales en sentido descendente son cadenas que buscan respaldo de finalidad, no servicios arbitrarios que buscan seguridad económica. Los tokens de staking líquido para BTC en staking en Babylon existen y están creciendo, pero la capa equivalente a los AVSs —un mercado de servicios heterogéneos que consumen seguridad de BTC— está estructuralmente acotada por los límites en las condiciones de slashing descritos anteriormente. Lo que BTCFi sí tiene, y ETHFi no, es la credibilidad de la custodia nativa en Bitcoin: el activo subyacente nunca abandona su cadena base, y esa propiedad es en sí misma una característica de producto para una clase de tenedores que nunca habrían considerado BTC envuelto o puenteado.

Un resumen razonable es que EigenLayer optimiza la amplitud de servicios que pueden consumir seguridad, mientras que Babylon optimiza la legitimidad de la seguridad que se consume. Ambos ejes importan, y los dos ecosistemas probablemente coexistirán en lugar de converger.

Qué observar y qué sigue abierto

Las variables más importantes a seguir durante los próximos trimestres no son las cifras titulares del monto en staking, sino las estructurales.

Para Babylon, las preguntas son: cómo evoluciona el comité de covenant a medida que mejoran las primitivas de Bitcoin script, si la concentración de proveedores de finalidad produce el tipo de riesgo de slashing correlacionado al que se enfrenta EigenLayer, y si las cadenas consumidoras pueden diseñar estructuras de recompensas que retengan a los stakers de BTC sin forzarlos a una exposición larga en tokens de cadenas consumidoras. La pregunta abierta más profunda es si la superficie de slashing de Babylon, que es más estrecha que la de EigenLayer, resultará suficiente para las cadenas consumidoras que la adopten, o si el ecosistema acabará demandando condiciones más ricas que requieran actualizaciones del lado de Bitcoin.

Para EigenLayer, las preguntas son: cómo se comporta el slashing en producción real una vez que los AVSs comiencen a aplicar condiciones en vivo a escala, cómo se apila el riesgo entre AVSs que comparten operadores, y si la capa de restaking líquido introduce suficiente opacidad como para que los stakers no puedan razonar de forma significativa sobre su exposición acumulada al slashing. La pregunta abierta más amplia es si la abstracción del AVS, que es genérica por diseño, produce suficientes servicios que genuinamente necesitan seguridad para absorber la oferta de ETH resteado, o si la dilución de recompensas acabará reconfigurando la economía de los operadores.

La comparación no es una carrera de caballos. Babylon y EigenLayer son respuestas a preguntas que se solapan pero son distintas, construidas bajo restricciones diferentes, atrayendo consumidores diferentes y produciendo economías descendentes diferentes. El marco útil no es cuál modelo gana, sino qué restricciones de diseño ha internalizado cada uno y cuáles ha diferido. Babylon ha diferido la expresividad de las condiciones de slashing a cambio de custodia nativa. EigenLayer ha diferido las garantías de custodia a cambio de expresividad en las condiciones de slashing. Los ecosistemas en sentido descendente están siguiendo esos compromisos fielmente, y los desarrollos más interesantes de BTCFi y ETHFi que están por venir serán probablemente aquellos que trabajen a favor de la lógica de cada modelo, y no en su contra.