2026년 1월, 전자증권법과 자본시장법 개정안이 국회를 통과했다. 토큰증권이 법적으로 유효한 증권으로 인정받는 구조가 2027년 초부터 생긴다.

지금은 그 사이 구간이다. 법은 통과됐고, 시행은 아직이다.

이 구간에서 많은 팀이 PoC를 마치고 다음 단계를 준비 중이다. 그런데 준비의 방향이 대부분 같은 곳에서 멈춘다. 스마트 컨트랙트 설계, 체인 선택, 커스터디 구조. 여기까지는 논의가 된다.

논의가 잘 안 되는 부분이 있다. 이 시스템이 지금 운영 중인 기존 시스템과 어떻게 연결되는가.

블록체인이 스스로 알 수 없는 것들

토큰증권 인프라를 실제로 운영한다고 가정해보자.

현재 채권 가격은 어디서 오는가. 이 투자자가 적격 요건을 갖췄는지는 누가 확인하는가. 수익분배는 어떤 조건에서 자동으로 실행되는가.

이 질문들에 대한 답은 어떤 것도 블록체인 위에 없다. 전부 기관이 수십 년째 운영해온 시스템 안에 있다.

블록체인 네트워크는 결정론적 폐쇄 시스템이다. 모든 노드가 동일한 코드를 동일한 데이터에 실행해야 한다. 외부 데이터를 자체적으로 가져올 수 없다. 스마트 컨트랙트가 아무리 정교하게 설계되어 있어도, 외부에서 데이터가 들어오지 않으면 판단을 내릴 수 없다.

오라클은 이 간격을 메우는 컴포넌트다. 기존 시스템에서 데이터를 가져오고, 암호학적 서명으로 진위를 증명하고, 스마트 컨트랙트가 신뢰할 수 있는 형태로 전달한다.

이것이 미들웨어 문제처럼 들린다면, 실제로 운영해본 사례를 보는 것이 빠르다.

홍콩이 먼저 겪은 것

홍콩은 정부 토큰화 채권을 실제 발행까지 끌고 간 대표적 선행 사례다. 2023년 2월, 홍콩 정부는 세계 최초의 정부 토큰화 녹색채권을 발행했고, Project Evergreen에서 발행일 T+1 정산 구조를 구현했다.

그 직후 HKMA가 낸 보고서(Bond Tokenisation in Hong Kong - HKMA 2023.08) 에 이런 문장이 있다.

"currently there is no connectivity between existing custody systems and the digital platform. Reconciliations between the digital platform and custody system records are done manually."

“현재 기존 커스터디 시스템과 디지털 플랫폼 사이에 연결이 없다. 두 시스템 간의 대사(reconciliation)는 수동으로 이루어지고 있다.”

세계 최초 프로덕션 배포. 수동 대사.

온체인 정산 기록은 남았지만, 그 기록을 기존 커스터디 시스템과 맞추는 작업은 담당자가 매일 수작업으로 했다는 뜻이다.

2025년, HKMA가 113개 금융기관을 대상으로 DLT 도입 장벽을 조사했고, 이 결과 65%가 “기존 시스템과의 통합”을 가장 큰 과제로 꼽았다. 보안(62%)보다 높고, 규제 불확실성(53%)보다 높다.

• HKMA, Distributed Ledger Technology in the Financial Sector: A Study on the Opportunities and Challenges (2025)

Oracle 연동 공식 언급 (p4):

“enhanced connectivity between on-chain and off-chain interactions via oracles, which play an important role in connecting digital and traditional ecosystems”

(HKMA, Distributed Ledger Technology in the Financial Sector, p.4)

홍콩은 규제가 먼저 정비된 곳이다. 규제가 정비된 이후에도 기존 시스템 통합이 최대 장벽으로 남았다는 것이 이 데이터의 의미다.

한국에서 오라클이 없으면 막히는 세 지점

2027년 전자증권법 시행 이후 토큰증권 인프라를 실제로 운영하려면, 오라클 없이는 통과할 수 없는 지점이 세 곳 있다.

첫째, 투자자 적격성 집행이다. 증권형 토큰이 이체될 때, 수신 주소가 필요한 자격 요건을 갖췄는지 확인이 필요하다. 이 검증은 기관의 KYC 시스템에서 일어난다. 체인 레벨의 이체 제한을 실제로 집행하려면, 그 결과가 이체가 실행되는 순간 스마트 컨트랙트 안에 있어야 한다. 오라클이 없으면 집행이 오프체인에서만 일어나고, 온체인 기록의 신뢰 모델이 깨진다.

둘째, 가격 산정이다. 토큰화 채권과 RWA 토큰의 가격은 기존 금융 시스템의 데이터를 참조한다. 이 데이터가 온체인 정산 로직에 검증 가능한 방식으로 주입되지 않으면, 정산 기록은 남지만 그 정산이 올바른 가격에 일어났다는 증명이 없다. 감사 관점에서 이것은 기록이 있지만 신뢰할 수 없는 기록이다.

셋째, 정산 자동화다. 수익분배, 이자 지급, 쿠폰 정산은 외부 조건에 바인딩된다. 기준금리 변동, 정해진 지급일, 기초 자산 가격의 임계값 도달. 스마트 컨트랙트는 이 조건들을 스스로 알 수 없다. 오라클이 전달하지 않으면, 자동화라고 부르는 것이 실제로는 담당자가 수동으로 트리거를 넣는 구조가 된다.

세 지점 모두 현재 주요 오라클 제공자들이 기관용 완성품으로 제공하지 않는다. 시장 가격 피드는 Chainlink 같은 탈중앙화 오라클로 커버된다. 그러나 KYC 상태나 규제 플래그처럼 단일 권위 있는 소스에서만 오는 데이터는 아직 기관별 시스템/규제 요건에 맞춘 설계가 필요한 영역으로 남아 있다.

지금 이 구간에서 해야 할 것

법이 시행되고 나서 오라클 설계를 시작하면 늦다. 오라클 레이어는 스마트 컨트랙트 설계, 커스터디 구조, 기존 시스템 연동과 동시에 설계되어야 한다. 나중에 붙이는 것이 구조적으로 가능하지 않다.

지금 이 구간에서 정리해야 할 것들이 있다.

어떤 데이터가 온체인에 들어와야 하는가. 정산에 필요한 데이터를 목록으로 만들고, 각각이 어떤 시스템에서 오는지, 누가 권위 있는 소스인지 정의해야 한다.

감사 추적을 어떻게 설계할 것인가. 규제 당국은 모든 정산의 모든 입력이 기록되고 검증 가능하기를 요구한다. 오라클 데이터의 서명과 타임스탬프가 이 요건을 충족할 수 있지만, 처음부터 설계에 포함되어야 한다.

기존 시스템과의 자동 동기화를 어떻게 할 것인가. 홍콩 사례의 수동 reconciliation 문제가 여기서 온다. 온체인 기록과 기존 시스템 기록이 자동으로 동기화되지 않으면, 운영팀이 매일 두 시스템을 수작업으로 맞춰야 한다.

누가 오라클 비용을 소유하는가. 오라클 인프라는 운영 비용이 발생한다. 이것이 자본 지출인지 운영 비용인지 정리되지 않으면, 법 시행 시점에 예산 논쟁으로 일정이 밀린다.

지금 이 글을 읽는 사람이 가져가야 할 것

PoC 검토를 시작하는 팀이라면 스마트 컨트랙트 설계와 동시에 오라클 레이어를 설계해야 한다. 체인 선택, 커스터디 구조를 논의하는 시점에 “기존 시스템에서 어떤 데이터가 온체인에 들어와야 하는가”가 함께 정의되어야 한다.

이미 PoC를 마친 팀이라면 지금 당장 기존 시스템 연동 목록을 만들어야 한다. 가격 데이터는 어디서 오는가. KYC 상태는 누가 권위 있는 소스인가. 정산 트리거는 어떤 조건에서 발동되는가. 이 목록이 없으면 오라클 설계가 시작되지 않는다.

2027년 시행 시점에 이것이 없으면, 법적 장치가 생겨도 운영팀이 수작업으로 채워 넣게 된다. 홍콩이 그랬던 것처럼.

B-Harvest에서는 블록체인 인프라를 개발하고, 운영합니다. 저는 Ethereum과 Polygon 메인넷에서 Chainlink 오라클 노드를 직접 운영했고, 현재 기관 블록체인 인프라를 연구하고 있습니다. 이 글의 내용은 개인 의견입니다.

You set up a new node. Sync doesn’t finish. The logs show blocks being processed, but the speed is wrong. So you check the network first: peer count, firewall rules, bandwidth.

Not the wrong instinct. But in my experience, the real culprit is the disk.

How a blockchain node actually uses storage

A blockchain node doesn’t behave like a typical web server. Web servers mostly read; writes are logs. A blockchain node does something different: it stores and verifies every transaction the network has ever processed, locally. That data runs into hundreds of gigabytes or multiple terabytes depending on the chain.

The problematic phase is block sync. When a node first joins a network, it has to replay the entire transaction history from genesis to catch up to the current tip. During this phase, disk read patterns get intense. The node isn’t reading sequentially. It’s verifying multiple blocks in parallel, jumping around the disk at random. Running nodes across multiple chains in the Cosmos ecosystem, I measured read IOPS exceeding 5K io/s during this phase on some chains.

IOPS is the number of I/O operations the disk handles per second. The higher the number, the more concurrent read/write requests the disk is fielding.

Why cloud storage struggles with this pattern

AWS EBS and similar cloud block storage are network-attached. The disk isn’t physically inside the server. Every I/O request travels over a network hop to reach it. That hop adds latency to every single operation.

A bare metal server with NVMe is different. The drive sits in a PCIe slot, directly connected. No network traversal between the CPU and the disk.

This structural difference shows up clearly in workloads with high random read IOPS, exactly what block sync produces. I ran the same chain on AWS EBS and an OVH bare metal server side by side.

The wait time gap is about 34x. The queue size tells the same story. On EBS, I/O requests pile up waiting. On bare metal, they clear almost instantly.

Can’t you just provision more IOPS on EBS?

Yes. AWS EBS gp3 goes up to 16K io/s and 1000 MB/s throughput. Provisioning beyond the baseline (3K IOPS, 125 MB/s) closes the gap.

But the moment you go past the baseline, you pay extra. Compare the monthly cost of a high-spec EBS volume against a bare metal server and see which wins on performance per dollar. For workloads that need sustained high IOPS around the clock, the math usually doesn’t favor EBS.

The filesystem matters too

Storage choice is one variable. Filesystem is another. On Linux, the main options are EXT4 and XFS.

EXT4 works well under 1K IOPS and 200 MB/s. Block sync on most chains pushes past both thresholds. XFS handles high IOPS and parallel I/O better. For blockchain nodes, where block sync dominates the disk profile, XFS is the right choice.

Summary

If your node is slow, check the disk before anything else. Three concrete steps:

First, use bare metal NVMe over cloud-attached storage. The network hop in EBS is a structural disadvantage for random-read-heavy workloads like block sync.

Second, use XFS. It handles the IOPS and parallel I/O that block sync generates better than EXT4 does.

Third, measure your workload before changing hardware. Know which phase is slow before you pick a fix.

Upgrade the instance type last. In most cases, the answer is already in the storage layer.

The LayerZero post-mortem is technically clear. The protocol code was not compromised. DVN contracts, key management, OApp Solidity code, none of that was touched. What was compromised were two op-geth RPC nodes polled by the LayerZero Labs DVN, plus a DDoS on healthy external RPCs that forced failover to the poisoned ones.

No on-chain code was broken, yet a “verified” cross-chain message was forged and executed. Understanding how that is possible means looking at what the DVN structurally verifies. That structure becomes sharper when you contrast it with how Cosmos IBC is designed.

1. DVNs see a signature. Light clients see the state.

When Ethereum accepts “this message originated on Unichain” in LayerZero, the Ethereum endpoint checks exactly one thing: did the DVN set configured by the OApp post an attestation over this message’s payloadHash?

If the attestation arrives, the message executes. Ethereum does not store Unichain block headers. It does not recompute Unichain’s state transitions. It trusts the DVN’s claim that the event happened. The DVN produces that claim by polling a configured RPC endpoint for the source-chain event, taking whatever answer comes back, and signing it for posting to the destination. That is the full chain of custody.

What the destination chain ultimately trusts is the DVN signer’s signature, not the source chain’s state.

IBC is designed differently. A light client of the source chain lives on the destination chain. That light client knows the source chain’s validator set. When a new header comes in, it verifies directly that at least 2/3 of the validator set has signed it. Validator set rotations are tracked through UpdateClient. When a packet arrives, the destination chain independently runs a Merkle proof against the AppHash held by the light client, checking that the message is actually included in the source chain’s state, following ICS-23.

A relayer carries the headers and proofs, but the relayer is not trusted. The destination chain recomputes everything itself, so a lying relayer just produces a proof that fails verification. The unit of trust is not “who delivered it” or “who signed it,” but “the source chain’s own consensus.”

This model is not fully trustless. The ibc-go documentation calls IBC “trust-minimized,” not trustless. If 2/3 or more of the source chain’s validators collude, the AppHash they produce can itself be a lie, and the light client gets deceived. The cost of that attack, however, is capturing the source chain’s consensus, which is on-chain economic security. That is a different economic unit from compromising a handful of off-chain nodes.

Both models carry real tradeoffs. The light-client approach is bounded by chain-pair feasibility. Consensus types must be compatible, the client implementation has to be deployed on the destination, and update frequency and gas cost are nontrivial. Connecting arbitrary chains quickly is hard. The attestation approach works across any pair and is cheap, but it pushes the question of “how does the verifier know the source chain’s state” onto each operator.

This incident is what happens when that question breaks down. The DVN does not independently reconstruct chain state. It asks an RPC and takes the answer. Poison those RPCs and DDoS the healthy ones, and the DVN’s picture of the source chain is itself fabricated. On top of a fabricated picture, the DVN signed honestly and the destination chain verified the signature honestly. There is no line of code anywhere that you can point to and say “this is where the lie entered.”

2. Multi-DVN is necessary but not sufficient

LayerZero’s public position is simple. KelpDAO ran a 1-of-1 DVN setup, so it got hit. A multi-DVN setup would have prevented this. The post-mortem states that multi-DVN redundancy has been LayerZero’s consistent recommendation to integrators.

KelpDAO pushed back publicly. It says it has been running on LayerZero since January 2024, had a direct communication channel open since July 2024, and had the default configuration confirmed as appropriate when rsETH expanded to L2s. Kelp says it was never told to change the DVN setup specifically.

The numerics from Dune shortly after the incident: of 2,665 active LayerZero OApps, 47% use a 1-of-1 DVN setup. Why that fraction is so large is not a mystery. The sample layerzero.config.ts in the LayerZero V2 OApp Quickstart ships with one required DVN and zero optional DVNs. Yearn’s banteg confirmed separately that LayerZero’s public deployment code ships single-source verification as the reference across Ethereum, BSC, Polygon, Arbitrum, and Optimism. The official recommendation and the default shipping 1/1 can both be true at the same time.

Set the default problem aside and ask the structural question. Does having N DVNs actually give you N times the safety?

If five “independent” DVNs all read source-chain state from the same three RPC providers, an attacker who poisons those three providers forces all five DVNs to see the same forged state and produce the same valid signatures. M-of-N only does real work when each N is an independent failure domain.

This incident fits that proposition exactly. KelpDAO’s rsETH bridge was configured at the OApp layer with one required DVN. That is the 1-of-1 configuration. Whether that single DVN internally uses one signer or a multi-signer setup has not been disclosed publicly by LayerZero. Whatever the internal signing policy is, if the input to that policy, the observation of the source chain, comes through the same RPC, the outcome is the same. Multiple signers observe the same lie and produce multiple valid signatures. They do not cross-check independent observations.

Majority safety comes from how many different observations exist, not how many signatures exist. This attack is the case where that distinction was real on paper and absent in operation.

Assume we raised the DVN count at the OApp layer from 1 to 3. If those three DVNs all run the same binary image that LayerZero Labs distributes and all depend on the same class of public RPC provider, the attack surface is materially unchanged. The count goes up, the correlation stays the same.

Correlation axes worth auditing:

1. Binary implementation. Do they share the same image or the same codebase? LayerZero typically distributes the DVN binary to partner operators, which creates shared-implementation risk by default.

2. RPC dependency. Do they hit the same public endpoints (Infura, Alchemy) or run independent full nodes? Are RPCs IP-whitelisted private, or open public?

3. Client implementation. All op-geth? All Reth? Is there a single client-level zero-day exposure?

4. Hosting. All on AWS us-east-1? Are regions, clouds, and ISPs diversified?

5. Operating entity. Legally separate companies, or different brands under the same parent? Contractually independent?

SEAL’s advisory, published two days after the incident, calls this out directly. Teams need to exhaustively map their supply chain. The real risk is hidden correlation, the “3-of-5 multisig where 4 signers use the same custodian” pattern. Raising the count is trivial. Actually achieving independence requires deliberate work on each axis.

The contrast with the light-client model is sharp. Imagine running three independent light-client instances. What each verifies is the source chain’s validator signatures and its AppHash. Forging those signatures requires actually compromising 2/3 of the source chain’s validator set. Even if all three instances happen to read header data from the same RPC, signature verification still runs independently in each instance. A lying RPC produces a proof that fails verification, not a forged state that propagates. The light client verifies what is attached to the data, not how the data was delivered.

The DVN verifies the RPC response itself. Nothing is attached to that response. Poison the RPC and the whole thing travels downstream.

3. April 18: how the difference showed up

Two large incidents hit 18 days apart in 2026. Drift Protocol lost $285M on April 1. KelpDAO lost $290M on April 18. Combined: $575M. Both are attributed to North Korea’s Lazarus Group, specifically the TraderTraitor sub-unit.

Neither was a smart-contract bug. Drift was social engineering against governance signers. KelpDAO was infrastructure penetration against the RPCs the DVN depended on. As Blockaid noted, both exits sit outside the scope of smart-contract audits.

The attack, step by step:

1. Reconnaissance, RPC list acquisition. The attacker obtained the list of RPC nodes the LayerZero Labs DVN polls. The LayerZero statement says only that “the attacker was able to gain access to the list of RPCs our DVN uses.” How that list leaked is not disclosed. The initial intrusion vector remains unexplained in the public record.

2. RPC node compromise, binary swap. The binaries running on two op-geth nodes, hosted in separate clusters, were replaced with malicious versions. The DVN instances themselves were not breached. Least-privilege isolation held.

3. Selective forgery, monitoring evasion. The malicious binary returned forged data only to the DVN’s IP, while returning honest data to every other IP (LayerZero Scan, external observers). LayerZero wrote that the design “was carefully designed to prevent any security monitoring from noticing anomalies.” LayerZero’s own anomaly detection was effectively blinded during the window.

4. DDoS to force failover. The DVN runs a redundant RPC setup across internal and external providers, so compromising two nodes was not enough. A DDoS was mounted against the healthy external RPCs, forcing failover to the poisoned ones. The window was 10:20 a.m. to 11:40 a.m. PT on April 18. LayerZero published the external RPC traffic graph showing the DDoS peak.

5. Message forgery. Once failover triggered, the poisoned nodes reported a Unichain transaction that never happened. Whatever internal signing policy the DVN uses, its input all came from the same poisoned RPC, so a valid attestation was produced and the 1-DVN requirement Kelp had configured was met. The Ethereum OFTAdapter then released 116,500 rsETH to the attacker through lzReceive.

6. Anti-forensics. Once the window closed, the malicious binary self-destructed. LayerZero’s statement: “It was designed to self-destruct once the attack could no longer be performed, disabling the RPCs, deleting the malicious binary and corresponding local logs and configs.” Disable the RPC daemons, wipe the binary, wipe the logs, wipe the configs. That pattern is standard APT tradecraft.

What matters here is that the attacker thought like a network operator, not a smart-contract attacker. Reconnaissance, pivot, selective deception, availability-to-integrity downgrade, anti-forensics. Those are familiar to a web2 security team, not to a Solidity auditor.

The structural reason this attack succeeded is that the destination chain only verifies “what the DVN said.” If the destination chain had verified “what the source chain’s validators signed,” RPC poisoning and DDoS would produce failures, but not forged messages. None of the six steps above forges a source-chain validator signature.

In the DVN model, the compromise of off-chain nodes propagates all the way to destination-chain approval. In the light-client model, off-chain compromise stops at “signature verification failed.” That difference is structural.

Closing

This is not a takedown of LayerZero specifically. Attestation-based verifier models are a legitimate option for chain pairs that a light client cannot reach, and this incident does not invalidate that design choice. Where the destination chain cannot natively run the source’s light client, whether because of a missing implementation or an incompatible proof system, an attestation layer like the DVN is a practical way around the limit.

The design decision, though, requires that “what is the verifier ultimately looking at” be asked explicitly. DVNs see RPC responses. Light clients see validator signatures and Merkle proofs. The first accepts “someone’s report about the chain’s state.” The second accepts “the chain’s state itself.” What broke on April 18 was the first model’s premise.

When evaluating cross-chain infrastructure, “how many DVNs in the set” is the second question. The first question is “what are those verifiers ultimately looking at.” The answer to that determines whether an attacker has to break a handful of off-chain nodes, or the source chain’s consensus itself.

References

• LayerZero, “KelpDAO Incident Statement,” Apr 19, 2026. Primary source for the attack chain, multi-DVN recommendation, selective deception, DDoS window, and self-destruct routine.

• Security Alliance, “Initial Takeaways on LayerZero DVN Security Incident,” Apr 20, 2026

• The Defiant, “Dune Analytics Reveals 47% of LayerZero OApps Use Minimal DVN Security Following KelpDAO Hack,” Apr 20, 2026

• CoinDesk, “Kelp DAO hits back at LayerZero for trying to shift the blame after a massive exploit,” Apr 20, 2026

• CoinDesk, “LayerZero blames Kelp’s setup for $290 million exploit, attributes it to North Korea’s Lazarus,” Apr 20, 2026

• The Block, “LayerZero says North Korea’s Lazarus likely behind Kelp DAO exploit; blames single-point setup,” Apr 20, 2026

• Blockaid, “How a Single LayerZero DVN Compromise Drained $292M from KelpDAO,” Apr 20, 2026

• ibc-go, Tendermint light client overview

• ICS-02 client semantics

2026년 4월 18일, KelpDAO의 rsETH 116,500개가 사라졌다. 피해액 약 2.9억 달러로 올해 DeFi 최대 규모의 해킹이다.

LayerZero가 사건 직후 공개한 post-mortem은 기술적으로는 명확하다. 프로토콜 코드는 뚫리지 않았다. DVN 컨트랙트도, 개인키 관리도, OApp의 Solidity 코드도 뚫리지 않았다. 뚫린 것은 LayerZero Labs가 운영하는 DVN이 조회하던 op-geth RPC 노드 2대와, 정상 트래픽을 고립시키기 위한 외부 RPC 대상의 DDoS였다.

체인 위의 어떤 코드도 뚫리지 않았는데 “검증된” cross-chain 메시지가 위조됐다. 이게 어떻게 가능한지를 이해하려면 DVN이 구조적으로 무엇을 검증하는지부터 봐야 한다. 그리고 그 구조는 Cosmos IBC가 설계된 방식과 대조했을 때 가장 선명하게 드러난다.

1. DVN은 서명을 보고, light client는 상태를 본다

LayerZero에서 Ethereum이 “Unichain에서 이 메시지가 발생했다”고 받아들일 때, Ethereum 쪽 endpoint가 실제로 검증하는 것은 하나다. OApp이 설정한 DVN set이 이 메시지의 payloadHash에 대해 attestation을 올렸는가.

DVN set의 attestation이 들어오면 메시지는 실행된다. Ethereum은 Unichain의 블록 헤더를 보관하지 않는다. Unichain의 state transition이 실제로 일어났는지 스스로 재계산하지 않는다. DVN의 “나는 봤다”는 선언을 신뢰할 뿐이다. DVN이 그 선언을 만들어내는 방식은 자신이 설정된 RPC 엔드포인트에 source chain의 이벤트를 물어보는 것이고, 답이 오면 그 답을 서명해서 destination에 올린다. 끝이다.

destination chain이 궁극적으로 신뢰하는 것은 DVN signer의 서명이지 source chain의 상태가 아니다.

IBC는 다르게 설계됐다. Destination chain 위에 source chain의 light client가 올라가 있다. 이 light client는 source chain의 validator set을 알고 있고, 새 block header가 올라올 때 해당 헤더에 validator set의 2/3 이상 서명이 있는지 직접 검증한다. Validator set 자체가 교체되면 그 교체까지 UpdateClient 경로로 추적한다. Packet이 도착하면 destination chain은 light client가 보관 중인 AppHash를 루트로 Merkle proof를 돌려 “이 메시지가 source chain의 state에 실제로 포함됐는가”를 ICS-23 규약에 따라 스스로 계산한다.

Relayer라는 외부 주체가 헤더와 proof를 운반하긴 하지만, relayer는 신뢰되지 않는다. Destination chain이 스스로 재계산하기 때문에 relayer가 거짓말을 하면 proof가 검증에 실패한다. 신뢰의 단위는 “누가 운반했는가”나 “누가 서명했는가”가 아니라 “source chain의 합의 자체”다.

이 모델도 완전히 무신뢰는 아니다. ibc-go 공식 문서는 IBC를 “trustless”가 아니라 “trust-minimized“로 규정한다. Source chain의 validator 2/3 이상이 악의적으로 합의를 장악하면 그 체인이 내는 AppHash 자체가 거짓이 될 수 있고, 그러면 light client도 속는다. 다만 이 경우의 공격 비용은 “source chain 합의 장악”이라는 on-chain 경제 보안 수준이 된다. off-chain 노드 몇 대 침투와는 경제적 단위가 다르다.

두 모델 모두 명확한 trade-off가 있다. Light client 방식은 chain 쌍마다 feasibility가 달라진다. Consensus 타입이 맞아야 하고, light client 구현체가 destination chain 위에 올라가 있어야 하며, update 빈도와 gas 비용도 부담이다. 임의의 체인을 빠르게 연결하기 어렵다. Attestation 방식은 임의의 체인 쌍을 연결할 수 있고 경제성도 좋지만, verifier가 “체인 상태를 어떻게 아는가”의 책임을 각자 져야 한다.

이번 사건은 그 책임이 깨지는 경로를 보여준 사례다. DVN은 체인 상태를 독립적으로 재구성하지 않는다. RPC 노드에 물어보고 답을 받는다. 그 RPC 노드들을 오염시키고 건강한 나머지를 DDoS로 가리면 DVN의 ‘체인 상태에 대한 인식’ 자체가 조작된다. 조작된 인식 위에서 DVN은 정직하게 서명했고 destination chain은 그 서명을 정직하게 검증했다. 어떤 단계에서도 “속였다”고 말할 수 있는 코드가 없었다.

2. Multi-DVN은 필요조건이지 충분조건이 아니다

LayerZero 공식 입장은 단순하다. KelpDAO가 1-of-1 DVN 설정을 썼기 때문에 뚫렸다. Multi-DVN이었다면 막혔다. 공식 post-mortem은 multi-DVN redundancy가 자사가 모든 integrator에게 지속적으로 권고해온 구성이라고 단언했다.

KelpDAO는 이 서술에 공개적으로 반박했다. 2024년 1월부터 LayerZero 인프라 위에서 운영해왔고, 2024년 7월부터 직접 커뮤니케이션 채널이 열려 있었으며, L2 확장 시점에 default 설정이 적절하다는 확인까지 받았다는 것이다. rsETH의 DVN 설정을 바꾸라는 구체적 권고를 받은 적 없다고 Kelp는 주장한다.

Dune Analytics가 사건 직후 공개한 숫자를 보자. LayerZero 활성 OApp 2,665개 중 47%가 1-of-1 DVN 설정이다. 이게 절반에 가까운 디폴트가 된 이유는 분명하다. LayerZero V2 OApp Quickstart의 샘플 layerzero.config.ts가 required DVN 1개, optional DVN 0개로 와이어링되어 있다. Yearn Finance의 banteg는 별도 분석에서 LayerZero의 공개 deployment 코드가 Ethereum, BSC, Polygon, Arbitrum, Optimism 모두에서 single-source verification을 reference로 배포하고 있음을 확인했다. LayerZero의 공식 주장과 디폴트가 1/1이라는 사실이 동시에 참이다.

디폴트 문제를 제쳐놓고 구조적인 질문을 하자. N개의 DVN이 있으면 정말 N배 안전한가?

5개의 “독립된” DVN이 같은 3개의 RPC 프로바이더에서 체인 상태를 읽고 있다면, 공격자가 그 3개를 오염시키는 순간 5개의 DVN이 모두 같은 위조된 상태를 보고 같은 유효 서명을 올린다. M-of-N은 각 N이 서로 독립된 failure domain일 때만 의미가 있다.

이번 사건이 이 명제에 그대로 들어맞는다. KelpDAO의 rsETH 브릿지는 OApp 레이어에서 required DVN 1개로 설정됐다. 이게 1-of-1 DVN이라고 불리는 구성이다. 그 한 개의 DVN이 내부적으로 서명을 어떻게 형성하는지, 단일 서명인지 multi-signer 구조인지는 LayerZero가 공개적으로 밝히지 않았다. 다만 DVN이 어떤 내부 서명 정책을 쓰든, 그 서명의 입력이 되는 “source chain에 대한 관찰”이 모두 같은 RPC에서 나온다면 결과는 같다. 여러 signer가 거짓을 보고 여러 서명이 형성될 뿐, 독립된 관찰이 교차 검증된 게 아니다.

다수결의 안전성은 “몇 개의 서명이 붙었는가”가 아니라 “몇 개의 서로 다른 관찰이 있었는가”에서 나온다. 이번 공격은 이 구분이 서류상으로만 존재하고 운영상으로는 존재하지 않았던 경우다.

OApp 레이어에서 DVN 개수를 1에서 3으로 늘렸다고 가정해보자. 만약 그 3개 DVN이 모두 LayerZero Labs가 배포한 같은 바이너리 이미지를 돌리고, 같은 종류의 퍼블릭 RPC 프로바이더에 의존한다면, 공격 표면은 실질적으로 그대로다. 카운트는 올랐는데 상관관계는 그대로다.

점검해야 할 correlation 축을 꼽으면 다음과 같다.

1. DVN 바이너리 구현:

   1. 같은 이미지 혹은 같은 구현체를 공유하는가. LayerZero는 파트너 DVN 운영자에게 LayerZero가 작성한 바이너리 이미지를 배포해서 돌리는 구조가 일반적이다.

2. RPC 프로바이더 의존성:

   1. 같은 퍼블릭 endpoint (예: Infura, Alchemy) 에 의존하는가, 각자 full node를 돌리는가. IP whitelisting이 걸린 private RPC인가, 공개 endpoint인가.

3. 클라이언트 구현:

   1. 모두 op-geth인가, Reth인가. 같은 클라이언트 제로데이에 동시 노출되는가.

4. 호스팅 인프라:

   1. 모두 AWS us-east-1인가. 리전, 클라우드, ISP가 분산되어 있는가.

5. 운영 entity:

   1. legally 서로 다른 회사인가, 같은 모회사 산하인가. 계약적으로 독립인가.

SEAL(Security Alliance)이 사건 이틀 뒤 공개한 권고문이 이 지점을 정확히 잡았다. 팀은 supply chain 전체를 exhaustively 매핑해야 한다. “3-of-5 multisig인데 4명이 같은 custodian을 쓴다”는 종류의 hidden correlation이 진짜 리스크다. 카운트를 올리는 건 쉽고, 독립성을 확보하는 건 각 축마다 의도적 작업이 필요하다.

light client 모델과 비교하면 이 점이 더 선명해진다. 3개의 서로 다른 light client 인스턴스를 돌린다고 했을 때, 각 인스턴스가 보는 것은 전부 source chain의 validator 서명과 AppHash다. 그 서명을 위조하려면 source chain의 validator 2/3를 실제로 뚫어야 한다. 3개의 light client 인스턴스가 같은 RPC에서 데이터를 받아오더라도 서명 검증 자체는 각 인스턴스가 각자 한다. RPC가 거짓 블록을 주면 서명 검증이 실패할 뿐, 위조된 상태가 통과되지 않는다. Light client가 보는 것은 “데이터를 운반한 경로”가 아니라 “데이터에 붙은 validator 서명”이기 때문이다.

DVN의 경우 “보는 것”은 RPC 응답 자체다. 서명이 데이터에 붙어 오지 않는다. 그래서 RPC를 오염시키면 전체가 넘어간다.

3. 4월 18일, 그 차이가 어떻게 드러났는가

2026년 18일 간격으로 두 건의 대형 사건이 터졌다. Drift Protocol 2.85억 달러(4월 1일), KelpDAO 2.9억 달러(4월 18일). 합계 5.75억 달러. 둘 다 북한 Lazarus Group의 소행으로 추정되고, 구체적으로는 Lazarus 내부의 TraderTraitor 서브유닛이 실행 주체로 지목됐다.

두 사건 다 스마트 컨트랙트가 뚫리지 않았다. Drift은 거버넌스 서명자 대상 social engineering이었고, KelpDAO는 DVN이 의존하는 RPC에 대한 infrastructure 침투였다. Blockaid 분석에서 지적됐듯이, 두 사건 모두 스마트 컨트랙트 audit이 잡아낼 수 있는 범위 바깥에서 터졌다.

이번 공격의 설계를 단계별로 뜯어보면 다음과 같다.

1. 정찰, RPC 리스트 획득.

   1. 공격자가 LayerZero Labs DVN이 조회하는 RPC 노드 목록을 사전에 확보했다. LayerZero 공식 성명은 “the attacker was able to gain access to the list of RPCs our DVN uses”라고만 기술했고, 어떤 경로로 그 리스트가 유출됐는지는 공개되지 않았다. 초기 침투 벡터는 현재 공개된 정보 기준으로는 미해명 상태다.

2. RPC 노드 침투, 바이너리 교체.

   1. 서로 다른 클러스터에서 돌던 op-geth 노드 2대의 바이너리를 악성 버전으로 교체했다. DVN 인스턴스 자체는 least-privilege 원칙 때문에 뚫지 못했다.

3. 선택적 위조, monitoring 회피.

   1. 악성 바이너리는 DVN의 IP에만 위조 데이터를 반환하고, 다른 IP (예: LayerZero Scan, 외부 옵저버) 에는 정상 데이터를 반환하도록 설계됐다.

   2. LayerZero는 “The message was only shown to the DVN while the node explicitly told the truth to any other IP addresses... This was carefully designed to prevent any security monitoring from noticing anomalies”라고 직접 서술했다. 이 선택적 위조로 인해 LayerZero 자체 모니터링 시스템의 anomaly detection이 사건 중 정상 작동하지 않았다.

4. DDoS로 fail-over 강제.

   1. DVN은 내부/외부 RPC 중복 구성이라 2대 침투만으로는 부족했다. 건강한 외부 RPC에 DDoS를 날려 DVN이 오염된 노드로 fail-over하도록 강제했다. 공격 window는 미국 태평양 시간(PT) 기준 10:20 a.m.부터 11:40 a.m.이며, LayerZero는 이 시간대 외부 RPC 트래픽 그래프에서 DDoS 피크를 직접 공개했다.

5. 메시지 위조.

   1. fail-over가 트리거되자 오염된 노드가 "발생하지 않은 Unichain 트랜잭션"을 DVN에 보고했다. DVN이 내부적으로 어떤 서명 정책을 쓰든 그 정책의 입력이 모두 같은 오염된 RPC에서 왔기 때문에 정상적인 attestation이 형성됐고, OApp 레이어에서 Kelp가 요구한 "1 DVN의 attestation"이 충족됐다. 결과적으로 Ethereum 측 OFTAdapter가 lzReceive를 통해 116,500 rsETH를 공격자 주소로 release했다.

6. 증거 인멸 (anti-forensics).

   1. 공격 종료 후 악성 바이너리는 자기 제거 루틴을 실행했다. LayerZero 성명에 따르면 “It was designed to self-destruct once the attack could no longer be performed, disabling the RPCs, deleting the malicious binary and corresponding local logs and configs.”

   2. 즉, RPC 데몬 disable, 악성 바이너리 삭제, 로컬 로그 삭제, 설정 파일 삭제 순으로 자기 흔적을 제거하도록 설계된 말웨어였다. 이 패턴은 APT 계열에서 표준적인 anti-forensics 기법이다.

여기서 중요한 것은 공격자가 스마트 컨트랙트 공격자의 사고방식이 아니라 네트워크 공격자의 사고방식으로 움직였다는 점이다. Reconnaissance, pivot, selective deception, availability-to-integrity downgrade, anti-forensics. 이것들은 웹2 보안 팀이 익숙한 어휘이지 Solidity audit의 어휘가 아니다.

그리고 이 공격이 성립한 근본 이유는 destination chain이 “DVN이 뭐라고 말했는가”만 검증하기 때문이다. destination chain이 “source chain의 validator가 뭐라고 서명했는가”를 직접 검증했다면, RPC 오염과 DDoS는 failure를 유발해도 forged message를 통과시킬 수 없다. 공격의 6단계 중 어느 한 단계도 source chain의 validator 서명을 위조하지 못한다.

다시 말해, DVN 모델에서는 off-chain 노드의 compromise가 destination chain의 승인까지 전달된다. Light client 모델에서는 off-chain 노드의 compromise는 “서명 검증 실패”에서 멈춘다. 이 차이가 구조적이다.

닫으며

LayerZero 개별 비판이 이 글의 목적은 아니다. Attestation 기반 verifier 모델은 light client 모델이 닿을 수 없는 체인 쌍을 연결해주는 유효한 선택지이고, 그 선택이 이번 사건으로 부정되지 않는다. Ethereum과 Unichain 같이 서로 다른 consensus family에 속한 체인을 light client로 연결하려면 별도의 zk proof 시스템이나 새로운 client 구현이 필요하다. DVN 같은 attestation 레이어는 이 한계를 실용적으로 우회하는 방법이다.

다만 설계 결정을 할 때 “verifier가 궁극적으로 무엇을 보고 있는가”가 명시적으로 질문되어야 한다. DVN이 보는 것은 RPC 응답이다. Light client가 보는 것은 validator 서명과 Merkle proof다. 전자는 “chain 상태에 대한 타인의 보고”를 받아들이는 모델이고, 후자는 “chain 상태 자체”를 받아들이는 모델이다. 4월 18일에 뚫린 것은 DVN 모델의 이 전제였다.

Cross-chain 인프라를 평가할 때 “DVN set이 몇 개인가”는 두 번째 질문이다. 첫 번째 질문은 “그 verifier들이 궁극적으로 무엇을 보고 있는가”다. 그 답에 따라 공격자가 뚫어야 하는 것이 “off-chain 노드 몇 대”인지 “source chain 합의”인지가 갈린다.

References

1. The Block, “LayerZero says North Korea’s Lazarus likely behind Kelp DAO exploit; blames single-point setup”, Apr 20, 2026.

2. LayerZero, “KelpDAO Incident Statement”, Apr 19, 2026. (공격 체인 기술 서술, multi-DVN 권고, selective deception, DDoS window, self-destruct 루틴의 1차 출처)

3. CoinDesk, “Kelp DAO hits back at LayerZero for trying to shift the blame after a massive exploit”, Apr 20, 2026. (Kelp 반박 statement, banteg 분석, V2 OApp Quickstart 디폴트)

4. The Defiant, “Dune Analytics Reveals 47% of LayerZero OApps Use Minimal DVN Security Following KelpDAO Hack”, Apr 20, 2026.

5. Harry Donnelly, “Inside the Kelp/LayerZero Hack: How Lazarus Forged $292M Into Existence”, Apr 20, 2026.

6. Security Alliance (samczsun et al.), “Initial Takeaways on LayerZero DVN Security Incident”, Apr 20, 2026.

7. CoinDesk, “LayerZero blames Kelp’s setup for $290 million exploit, attributes it to North Korea’s Lazarus”, Apr 20, 2026.

8. Blockaid, “How a Single LayerZero DVN Compromise Drained $292M from KelpDAO”, Apr 20, 2026.

A Korean security researcher disclosed a CometBFT blocksync vulnerability yesterday (issue #5801). Claimed severity: CVSS 7.1 High.

The vendor, Cosmos Labs, has declined to treat it as a security vulnerability and reclassified a related prior bug (CVE-2025-24371) as Informational. I think both assessments miss.

The technical analysis in the disclosure is correct. The decision to go public, given the timeline, is defensible. But 7.1 is over-priced, and Informational is under-priced. As someone who has developed on the Cosmos-SDK and operated Cosmos chains in production, here is how I would split the problem.

The bug

Two functions in the blockpool matter: pickIncrAvailablePeer and SetPeerRange.

pickIncrAvailablePeer filters peers with height < peer.base || height > peer.height. That check is fine in isolation.

SetPeerRange is where the invariant breaks. When a peer reports (base, height), the function only rejects values that are lower than previously seen:

if base < peer.base || height < peer.height {
    pool.removePeer(peerID)
    pool.banPeer(peerID)
    return
}

It never checks whether base is sane relative to pool.height. A malicious peer can advertise (base=1_000_000, height=1_000_100) while the chain sits at 151. maxPeerHeight inflates to 1,000,100. The sync target shifts to a block no one can serve. The peer is not banned because nothing went down. Every iteration of the requester picks this peer as “available,” fails, and retries forever. The node is wedged in blocksync permanently.

This is the same class of bug as CVE-2025-24371. The prior patch banned peers for reporting lower values. The new path bypasses it through higher values. Patch bypass is what makes #5801 non-trivial.

Why 7.1 is over-priced

The “chain halt at $8B+ ecosystem” framing in the disclosure requires several conditions stacking at once. Many validators must restart simultaneously. They must come up via blocksync rather than statesync. They must peer with the malicious node rather than through curated sentries. Their p2p topology must fail to filter the peer at any tier.

Each of these is unlikely in a production Cosmos chain. Validators restart rarely. Most operators prefer statesync for fresh joins. Anyone running sentries uses persistent_peers and private_peer_ids to control who their validator talks to.

Then there is the attacker-incentive dimension CVSS does not capture. No theft is possible. Shorting a chain with a blocksync-only DoS requires coordinated visibility the attack cannot deliver. The malicious peer is trivially identifiable. If you cannot make money and you will be caught, you do not run this.

One more point. The researcher’s own CVSS vector is SA:N (Subsequent System Availability: None). The score itself says “this deadlocks a single node,” but the prose says “ecosystem halt.” Those are not compatible. If the real impact were ecosystem-level, the vector would be SA:H, and the score would rise correspondingly.

My read: CVSS 4.5 to 5.5. Medium to low-medium.

Why Informational is under-priced

Cosmos Labs does not get a pass either. A bug that causes permanent, unrecoverable blocksync deadlock, bypasses an existing patch, reproduces trivially, and affects both validators and full nodes is not Informational.

The reclassification of CVE-2025-24371 to Informational (Negligible Impact, Possible Likelihood), done the day after a new researcher report landed, reads as a post-hoc severity adjustment rather than a principled reassessment.

The HackerOne response summary says the attack is not feasible but the bug has impact. That is internally inconsistent. If the bug has impact, it is a security bug. The question is degree, not whether.

The disclosure fight

Two things are being conflated in the public narrative, and they should be pulled apart.

First, operational failures. The researcher’s second report was marked as spam on HackerOne. The day after, a core maintainer opened issue #5670: “Create whitelist of known-good HackerOne submitters,” citing the false-positive as the trigger. That is the team acknowledging their own process broke, and proposing a public fix. That is the right response.

The problem is #5670 has sat open for six weeks with no PR, no label, no assignee action. Acknowledgment and resolution are different things.

I don’t say this from a distance. People I work with have had bug reports to the Cosmos team sit for over a month without review. The operational failure the researcher describes is not unique to this case, and calling out the pattern has some merit.

Second, the severity judgment. A CVSS reclassification the day after a new researcher report landed looks like something other than triage capacity. Ignoring a network-level PoC for over a month without technical rebuttal also does not fit the “we’re overwhelmed” story. I don’t have visibility into Cosmos Labs’ internal review process, so I won’t call it a methodology failure outright. But the timing sits outside what the spam-filter explanation covers.

The “AI-generated bug bounty spam is overwhelming maintainers” framing explains operational slowness. It explains less about severity reclassifications done on the same timeline. Readers who want to defend Cosmos Labs on the first point should be careful not to extend the defense to the second.

What operators should actually do

If you run a Cosmos-SDK chain, the practical risk depends on your peer policy, not on the CVSS number.

Blocksync is an edge path. Most production operators already use statesync for new nodes and rarely restart validators. If that describes you, real-world exposure is low.

If you use public seeds directly, or your sentry layer is not curated, you are in scope. Tighten persistent_peers and private_peer_ids on the validator. Make sure first-tier full nodes filter untrusted peers at the p2p layer.

The researcher’s “do not restart until patched” guidance is right for that narrow case but oversold as a general recommendation.

Patch will likely land within days now that the issue is public. Track CometBFT’s v0.38.x and v1.x release branches.

Closing

This is not a “researcher versus vendor” story, though it is being written that way on Twitter. It is a story about two separate failures.

A bug that got classified too softly by the maintainer, and a severity claim that reaches beyond what the CVSS vector itself supports. Both can sit outside what the evidence supports at the same time. Both do.

The right response is not to pick a side. It is to hold both positions at once: this is a medium-severity invariant bug that needs a real patch, and the disclosure process for it exposed gaps in how Cosmos Labs handles security reports. Those gaps are partly explained by the “too much AI spam” defense. Partly is not fully.

The patch will ship. The triage process is still the open question.

2026년 전자금융기반시설 보안 취약점 평가기준 안내서에는 정보보호 관리체계 항목만 175개가 있다. 이 중에서 블록체인 인프라를 넣는 순간 답을 못 하게 되는 항목이 여럿 있다. 그런데 가상자산 거래소 대상 평가기준에는 블록체인 22개, 월렛 25개, 스마트컨트랙트 15개 항목이 이미 있다. 노드 분산 배치, 포크 발생 시 이중지불 방지, 51% 공격 대응, 멀티시그 적용 같은 것들이다.

금융기관용 평가기준에는 이런 항목이 하나도 없다.

거래소에는 블록체인 전용 평가 체계가 있고, 금융기관에는 없다. 이 공백이 금융기관의 블록체인 도입을 막는 가장 실질적인 병목이다. 기술이 안 돼서가 아니라, 평가 기준이 어디서 오는지가 정해져 있지 않기 때문이다.

구체적으로 어디서 막히는가

금융기관이 블록체인을 도입할 때 기존 감독규정과 충돌하는 지점은 크게 세 가지다.

1. 온체인 원장에서 오류가 발생하면 어떻게 수정하는가

감독규정 제27조(전산원장 통제)는 원장의 변경 대상과 방법, 변경 권한자 지정, 변경 전후 내용의 자동기록과 보존, 변경 내용의 제3자 확인을 요구한다. 평가 항목이 8개다.

대차대조표 등 중요자료 계상액과 각종 보조부/거래기록/전산원장파일의 계상액에 대한 상호일치여부에 대한 전산시스템을 통한 주기적인 확인 여부
— 평가항목 #102

전산원장 불일치 원인과 조치 내용을 전산자료형태로 5년간 보존 여부
— 평가항목 #103

중요원장의 조회, 수정, 삭제, 삽입한 작업자와 작업내용 기록 및 5년간 보존 여부
— 평가항목 #104

블록체인 원장은 기본적으로 변경이 안 된다. 그러면 “변경 통제절차”를 적용할 수 없다. 오류가 발생했을 때 어떻게 수정하는가?

현실적으로 두 가지 방향이 있다.

A안: 보정 트랜잭션 방식.

온체인 원장을 직접 수정하지 않고, 원본 트랜잭션을 참조하는 보정(correction) 트랜잭션을 발행한다. 변경 전후 상태를 메타데이터로 기록하고, 보정 권한자의 서명을 온체인에 남긴다. 감독규정이 요구하는 “변경 전후 내용의 자동기록”과 “변경 권한자 지정”을 온체인 레벨에서 충족시킬 수 있다. 다만 원장의 최종 잔액 산출 로직이 복잡해지고, 보정 트랜잭션 자체의 유효성 검증 체계를 별도로 설계해야 한다.

B안: 오프체인 reconciliation 레이어.

온체인 원장은 원본 그대로 유지하고, 금융기관 내부 DB에서 보정 처리를 수행한다. 온체인 원장과 내부 원장 사이의 대조(reconciliation) 기록을 별도로 보존하고, 불일치 원인과 조치 내용을 5년간 보관한다. 기존 금융기관 시스템과의 통합이 상대적으로 쉽지만, 온체인 원장이 “보조 원장” 역할로 격하되면서 블록체인 도입의 실질적 의미가 줄어든다.

현행 규정은 이 두 방향 중 어느 것이 요건을 충족하는지에 대해 아무 말이 없다.

2. 블록체인 프라이빗 키를 기존 키 관리 체계에 어떻게 넣는가

감독규정 제19조(암호프로그램 및 키 관리 통제)는 암호 및 인증시스템에 적용되는 키에 대해 주입, 운용, 갱신, 폐기의 절차와 방법을 마련할 것을 요구한다.

암호 및 인증시스템에 적용되는 키에 대하여 주입/운용/갱신/폐기에 대한 절차 및 방법 마련 여부
— 평가항목 #80

블록체인 프라이빗 키는 기존 금융기관의 암호키와 성격이 다르다. 기존 키는 세션 암호화나 전자서명용이고, HSM 안에서 생성-운용-갱신-폐기 생명주기가 관리된다. 블록체인 프라이빗 키는 자산 통제 권한 그 자체이고, 키가 유출되면 자산이 직접 이동한다.

A안: HSM 기반 키 래핑.
기존 금융기관 키 관리 인프라(HSM)에 블록체인 프라이빗 키를 통합한다. HSM 내부에서 키 생성, 서명 연산을 수행하고, 키가 HSM 외부에 노출되지 않는 구조다. 기존 감독규정의 “주입/운용/갱신/폐기” 절차에 자연스럽게 매핑된다. 다만 블록체인 네트워크별 서명 알고리즘(secp256k1, ed25519 등)을 HSM이 지원해야 하고, 키 갱신(rotation) 시 온체인 주소가 바뀌는 문제를 처리해야 한다.

B안: MPC 기반 분산 서명.
프라이빗 키를 여러 파티에 분산시켜 단일 장소에 키가 존재하지 않는 구조다. 키 유출 리스크를 구조적으로 줄일 수 있지만, 현행 규정의 “키 주입” 개념과 맞지 않는다. 키가 한 번도 한 장소에 모이지 않는데 “주입”이란 무엇인가? “폐기” 절차는 각 파티의 키 조각을 개별 폐기하는 것으로 충분한가? 현행 규정 체계에서 이 질문에 대한 답이 없다.

멀티시그도 대안이지만, 이건 키 관리 방식이 아니라 승인 구조의 문제이므로 감독규정 제19조와는 다른 층위의 논의다.

3. 노드가 이미 분산되어 있으면 재해복구센터를 어떻게 적용하는가

감독규정 제23조(비상대책 등의 수립·운용)는 주전산센터와 일정 거리 이상 떨어진 안전장소에 재해복구센터를 구축하고 운영할 것을 요구한다.

주전산센터와 일정거리 이상 떨어진 안전장소에 재해복구센터 구축 및 운영 여부
— 평가항목 #123

블록체인 노드는 설계상 여러 지역에 분산 배치된다. 분산 자체가 장애 복원력을 제공한다. 그러면 별도의 재해복구센터라는 개념을 어떻게 적용하는가?

A안: 노드 분산 자체를 재해복구로 인정받는 논리 구성. 블록체인 네트워크의 지리적 분산, 합의 알고리즘에 의한 데이터 복제, 노드 장애 시 자동 복구 메커니즘이 전통적 DR센터의 기능을 구조적으로 대체한다는 논리다. 이 논리가 받아들여지려면 “어떤 수준의 분산이 감독규정의 재해복구 요건을 충족하는가”에 대한 기준이 필요하다. 현재는 없다.

B안: 기존 DR센터 구조를 유지하면서 블록체인 노드를 그 안에 배치. 물리적 DR센터를 구축하고, 그 안에 블록체인 풀노드와 관련 미들웨어를 운용한다. 감독규정 형식을 확실히 충족하지만, 블록체인의 분산 아키텍처와 중복되는 인프라 비용이 발생하고, 분산 네트워크의 장점을 상당 부분 포기하게 된다.

왜 이렇게 되었는가

한국 금융 IT 규제는 세 개의 층으로 되어 있다. 첫 번째 층은 법률이다. 전자금융거래법, 자본시장법, 전자증권법. “무엇을 해야 한다”를 선언하는 수준이고 기술적 디테일은 없다. 두 번째 층은 감독규정이다. 전자금융감독규정(금융위원회 고시)과 시행세칙(금융감독원)이 “어떻게 해야 하는지”를 구체화한다. 세 번째 층은 금융보안원이 매년 발행하는 보안 취약점 평가기준 안내서다. 금융기관은 연 1회 이상 이 기준에 따라 취약점 분석·평가를 받아야 한다.

법률 자체는 기술 중립성을 명시하고 있다.

금융위원회는 제2항의 기준을 정할 때 특정 기술 또는 서비스의 사용을 강제하여서는 아니 되며, 보안기술과 인증기술의 공정한 경쟁이 촉진되도록 노력하여야 한다.
— 전자금융거래법 제21조(안전성의 확보의무) 제3항

기술 중립성을 선언했지만, 그 아래의 감독규정과 평가기준이 “전산원장 변경 통제”, “재해복구센터 구축”, “전용회선 사용” 같은 전통 인프라 전제 위에 설계되어 있다. 법은 블록체인을 막지 않는데, 평가 체계가 블록체인을 전제하지 않는다.

블록체인 업계에서 “규제가 문제다”라고 할 때, 대부분 첫 번째 층인 법률만 이야기한다. 실무에서 실제로 걸리는 건 두 번째, 세 번째 층이다.

독일이 다르게 접근한 이유

독일은 2021년에 전자증권법(eWpG)을 제정하면서 블록체인 기반 증권을 “암호증권(Kryptowertpapiere)”이라는 별도 카테고리로 규율하는 체계를 만들었다. 기존 법에 블록체인을 끼워넣는 게 아니라, 블록체인 원장의 특성에 맞는 별도 통제 체계를 설계한 것이다.

여기서 뽑을 수 있는 원칙은 하나다. 불변성과 분산성을 가진 원장에 “변경 통제”와 “중앙 복구센터”를 적용하려면, 기존 규정을 그대로 적용하는 게 아니라 동등한 수준의 보호를 다른 방식으로 달성하는 별도 기준이 필요하다는 것이다.

한국은 이와 반대 방향이다. 기존 법체계를 유지한 채 “블록체인 기술을 쓸 수 있다”만 허용했다. 그래서 금융기관의 기존 원장이 주(主) 원장이어야 하고, 블록체인 원장은 보조적 역할로 제한되는 구조가 자연스럽게 형성된다.

이 상태에서 블록체인을 도입하려면 현실적으로 필요한 것이 있다. 온체인 원장 위에 기존 감독규정의 통제 요건을 충족시키는 오프체인 compliance layer다. 보정 처리 절차, 키 생명주기 관리, reconciliation 체계, 감사 추적 기록을 기존 평가 항목에 매핑할 수 있는 설계가 그 안에 들어가야 한다. 규정이 바뀌기를 기다리는 것은 전략이 아니다. 현행 규정 체계 안에서 평가를 통과할 수 있는 설계를 먼저 만드는 것이 출발점이다.

B-Harvest가 하고 있는 작업

B-Harvest는 금융기관에 블록체인 인프라를 제공하기 위해 이 갭을 어떤 설계로 메울 수 있는지 탐색하고 있다. 위에서 제시한 A안/B안은 아직 규정이 확정하지 않은 영역이고, 어떤 방식이 평가를 통과할 수 있는지는 규제기관과의 대화 없이는 확정할 수 없다. 그 대화의 출발점이 되는 것이 이 글의 목적이다.

참고 자료

• 전자금융거래법 전문 (법제처)

• 전자금융감독규정 전문 (법제처)

• 독일 전자증권법(eWpG) 해설 (BaFin)

• 독일 eWpG 개요 (Library of Congress)

All blockchains today operate in the same way. When a block is proposed, every validator re-executes every transaction to verify the result. If there are 100 validators, the same computation is repeated 100 times. This is how blockchains ensure correctness. “I ran it too, and got the same result, so it must be correct.”

It works, but it is fundamentally wasteful.

Succinct proofs, often grouped under the term “ZK,” propose a different approach. Instead of re-execution, an executor generates a mathematical proof that the computation was performed correctly. Validators verify only the proof. A computation that takes a billion steps to execute can be verified in roughly thirty.

First, clarify the terminology. “Zero-knowledge” strictly refers to a privacy property, where nothing is revealed beyond the validity of the proof. For blockchain scaling, the more important property is succinctness. Regardless of how large the original computation is, the proof remains small and verification remains fast. Jolt Pro currently implements succinct proofs. Full zero-knowledge privacy is on the near-term roadmap. In this article, “ZK” refers primarily to verifiable succinct computation, not privacy.

This is the core idea behind LayerZero’s Zero chain and its proving system, Jolt Pro. Most explanations of these systems either stay at an abstract "math magic" level or jump directly into research papers. This one starts from basic questions such as what polynomials are and why they are useful for detecting false claims, and builds up to how Jolt Pro proves 1.61 billion RISC-V cycles per second.

Finite fields: where the math happens

Before discussing proofs, we need to define the environment where the math operates.

Standard arithmetic uses an infinite sequence of numbers: 1, 2, 3, and so on. Computers cannot handle infinity, and cryptographic protocols require exact arithmetic without rounding errors. The solution is a finite field. It is a number system with a finite set of elements where addition, subtraction, multiplication, and division all work cleanly.

Think of a clock. On a 12-hour clock, 10 + 5 equals 3, not 15. Once it exceeds 12, it wraps around. A finite field follows the same idea, but uses a prime number p instead of 12.

In the finite field F₇ = {0, 1, 2, 3, 4, 5, 6}, all operations are performed modulo 7:

• Addition: 3 + 5 = 8 mod 7 = 1

• Multiplication: 3 × 4 = 12 mod 7 = 5

• Division: 3 / 2 = 3 × (inverse of 2) = 3 × 4 = 12 mod 7 = 5

Division works through multiplicative inverses. In F₇, the inverse of 2 is 4 because 2 × 4 = 8, and 8 mod 7 = 1. Every non-zero element has an inverse, which is why the modulus must be prime. If it is composite, some elements do not have inverses, and division breaks.

Why does ZK use finite fields? Two reasons. First, computers can perform exact integer arithmetic without floating point errors. Second, the security of ZK protocols depends on sampling random values from a large set. In practice, ZK systems use prime fields with around 2^256 elements. The space is large enough that randomly hitting a “bad” value is effectively impossible.

Polynomials: why lying fails

The central object is the polynomial.

A polynomial is a function composed of addition, multiplication, and exponentiation of variables:

f(x) = 3x² + 2x + 1

If x = 2, then f(2) = 12 + 4 + 1 = 17.

Polynomials have structural properties that are extremely useful for proofs.

A line is determined by two points.
Consider a degree-1 polynomial f(x) = ax + b. There are two unknowns, a and b. One point, for example f(1) = 5, is not enough. There are infinitely many lines passing through a single point. But two points, such as f(1) = 5 and f(3) = 11, produce two equations:

a + b = 5
3a + b = 11

Solving gives a = 3 and b = 2. There is exactly one line that passes through both points.

A parabola is determined by three points.

For a degree-2 polynomial f(x) = ax² + bx + c, there are three unknowns. Three points determine it uniquely.

General rule. A degree d polynomial has d + 1 unknowns, and is uniquely determined by d + 1 points. This implies:

Two different degree-d polynomials can agree on at most d points.

If they agree on more than d points, they must be the same polynomial.

Schwartz-Zippel lemma: catching lies with randomness

This property becomes a lie detector.

Suppose a prover claims a polynomial f(x), but the true polynomial is g(x), and f ≠ g. Both have degree at most d. Their difference h(x) = f(x) − g(x) is a non-zero polynomial of degree at most d. Therefore, h(x) = 0 for at most d values.

If a verifier picks a random point r from a finite field of size p:

Pr[f(r) = g(r)] ≤ d / p

If d = 1,000,000 and p = 2^256, the probability is about 10^-71.

This is the Schwartz-Zippel lemma. A single random evaluation detects a false polynomial with overwhelming probability. This fact underlies most ZK proof systems.

Sum-Check protocol: efficient verification

The Sum-Check protocol applies polynomial lie-detection to computation.

The problem

Given a multivariate polynomial f(x, y), we want to verify the sum over all binary inputs:

H = f(0,0) + f(0,1) + f(1,0) + f(1,1)

With m variables, there are 2^m terms. For m = 30, that is about one billion evaluations. The verifier cannot afford to compute this directly.

The prover claims H = 14. Can the verifier check this without computing all 2^m terms?

The core idea

The Sum-Check protocol reduces the problem one variable at a time.

Instead of checking the whole sum at once, the verifier asks the prover to “partially evaluate” the polynomial. In each round, one variable is replaced by a random challenge, and the remaining sum shrinks by half. After m rounds, the sum reduces to a single point evaluation, which the verifier can check directly.

At each step, the Schwartz-Zippel lemma guarantees that a dishonest prover is caught with overwhelming probability.

Walkthrough

Let f(x, y) = 2xy + 3x + y + 1.

The true values are:

f(0,0) = 1, f(0,1) = 2, f(1,0) = 4, f(1,1) = 7

H = 1 + 2 + 4 + 7 = 14.

Round 1: eliminate y

The prover “sums out” y, producing a polynomial in x alone:

g₁(x) = f(x, 0) + f(x, 1)

Expanding:

• f(x, 0) = 2x·0 + 3x + 0 + 1 = 3x + 1

• f(x, 1) = 2x·1 + 3x + 1 + 1 = 5x + 2

So g₁(x) = (3x + 1) + (5x + 2) = 8x + 3.

Consistency check. If the prover is honest, then g₁(0) + g₁(1) must equal H, because:

• g₁(0) = f(0,0) + f(0,1) = 3

• g₁(1) = f(1,0) + f(1,1) = 11

• 3 + 11 = 14 = H

This check alone does not prove correctness. The prover could have sent a different polynomial that also satisfies g₁(0) + g₁(1) = 14.

For example, g₁(x) = 14x passes: g₁(0) + g₁(1) = 0 + 14 = 14, but it is the wrong polynomial.

Random challenge. The verifier picks a random r₁ = 3 and evaluates g₁(3) = 8·3 + 3 = 27. This value becomes the target for the next round.

Here is why this works: if the prover lied about g₁, then by Schwartz-Zippel, the false g₁ and the true g₁ almost certainly disagree at a random point. The random challenge locks in the prover’s claim at a specific value, making it difficult to maintain a consistent lie in later rounds.

Round 2: eliminate x (now fixed at r₁ = 3)

The prover computes:

g₂(y) = f(3, y) = 2·3·y + 3·3 + y + 1 = 7y + 10

Consistency check. The verifier checks that g₂(0) + g₂(1) equals the target from Round 1:

• g₂(0) = f(3, 0) = 10

• g₂(1) = f(3, 1) = 17

• 10 + 17 = 27 = g₁(3)

This links Round 2 back to Round 1. If either round contains a lie, this equation breaks with high probability.

The verifier picks r₂ = 5 and evaluates g₂(5) = 7·5 + 10 = 45.

Final check: verify against the original polynomial

All previous checks ensured internal consistency between rounds. But they were all based on polynomials sent by the prover. The verifier has not yet touched the original polynomial f.

Now the verifier computes f(r₁, r₂) = f(3, 5) directly:

f(3, 5) = 2·3·5 + 3·3 + 5 + 1 = 30 + 9 + 5 + 1 = 45

Compare: g₂(5) = 45 = f(3, 5)

This step ties the prover’s claims back to the actual polynomial. Without it, the prover could have constructed rounds that are internally consistent but have nothing to do with f.

Why the prover cannot cheat

Each round forces the prover to commit to a polynomial before seeing the random challenge. If any committed polynomial differs from the honest one, Schwartz-Zippel catches the discrepancy with probability at least 1 - d/p.

A lie in Round 1 propagates to Round 2 through the random challenge, and collides with the final direct evaluation.

Efficiency

The verifier performs m rounds of: receiving a low-degree polynomial, checking one equation, and sampling one random point. The final step is a single evaluation of f. Total work: O(m) instead of O(2^m).

For m = 30: about 30 operations instead of one billion.

Committing to polynomials: making claims binding

The Sum-Check protocol assumes the prover can “send” a polynomial to the verifier. In the walkthrough, the prover sent g₁(x) = 8x + 3. But what does “send” mean concretely?

If the prover sends the polynomial’s coefficients, the verifier receives them, and the protocol works. But for large polynomials, this is expensive. And more importantly, the prover could send one polynomial in Round 1 and quietly swap it in Round 2. The protocol needs a way to lock the prover into a specific polynomial cheaply.

A polynomial commitment scheme has three operations. The prover first computes a short fingerprint of the polynomial, called a commitment, which is a single group element regardless of the polynomial's size. Later, the verifier picks a random point r and asks for f(r). The prover responds with the value and an opening proof. The verifier checks the proof against the commitment. If the prover lied about f(r), verification fails.

The commitment is binding. Once sent, the prover cannot change the polynomial without being caught. The binding property turns the interactive Sum-Check protocol into something enforceable.

Jolt uses a commitment scheme based on multiscalar multiplication (MSM). The key property: when the committed values are small (say, entries from a lookup table that fit in a few bits), the MSM cost drops significantly compared to committing arbitrary field elements. This matters because Lasso’s lookup tables produce exactly this situation. The committed field elements are small even though the underlying finite field is large.

Other proof systems use different commitment schemes. KZG commitments require a trusted setup. FRI (used by STARKs) avoids trusted setup but produces larger proofs. Jolt’s MSM-based approach sits between them: no trusted setup, and prover cost scales well when committed values are small.

The rest of this article assumes polynomial commitments exist and work. The important point is that every time the prover “sends a polynomial,” it actually sends a commitment, and every evaluation is backed by an opening proof that the verifier checks.

Lookup argument: replacing computation with table lookup

The Sum-Check protocol verifies polynomial sums efficiently. Polynomial commitments make the prover’s claims binding. To prove CPU execution, one more idea is needed.

The problem with circuits

Suppose we want to prove that a CPU correctly executed an ADD instruction: ADD(3, 4) = 7.

The traditional approach encodes this as an arithmetic circuit:

a + b - c = 0

The prover assigns a = 3, b = 4, c = 7, and proves the constraint is satisfied.

This works for ADD. But a CPU has dozens of instructions. Each one needs a different circuit: AND requires bitwise decomposition, SLT (set-less-than) requires comparison logic, MULHU (unsigned upper multiply) requires carry propagation. Each circuit must be hand-written and audited. Bugs in any single circuit break soundness.

The lookup alternative

Jolt takes a different approach. Instead of proving the computation directly, it proves that the input-output triple exists in a precomputed table.

For ADD: the prover shows that (3, 4, 7) appears in a table containing all valid additions.

For AND: the prover shows that (0b1010, 0b1100, 0b1000) appears in a table containing all valid bitwise ANDs.

The same protocol handles every instruction. The prover never constructs instruction-specific circuits. It only proves membership in the correct table.

Adding a new instruction to the VM means adding a new table. No new circuits, no new constraint logic, no new audit surface.

The size problem

This idea has an obvious flaw. For a 64-bit ADD instruction, each operand has 2⁶⁴ possible values. The full table has 2⁶⁴ × 2⁶⁴ = 2¹²⁸ rows. No one can store or commit to a table with 2¹²⁸ entries.

Prior lookup arguments (plookup, Halo2’s lookup) required the prover to commit to the entire table. This made large tables impractical and confined lookups to small, hand-picked tables.

Lasso: decomposing large tables into small ones

Lasso solves the size problem by exploiting table structure.

Consider 16-bit addition. The full table has 2³² rows. But 16-bit addition decomposes into two 8-bit additions with a carry:

ADD(a, b) where a = (a_hi, a_lo) and b = (b_hi, b_lo)

Step 1: Compute a_lo + b_lo. This gives a partial sum and a carry bit.

Step 2: Compute a_hi + b_hi + carry.

Each of these sub-operations only requires a table with 2⁸ × 2⁸ = 2¹⁶ rows (for 8-bit operands). That is 65,536 entries. Entirely manageable.

More generally, a 64-bit addition decomposes into eight 8-bit additions. The total table size becomes 8 × 2¹⁶ = 524,288 entries instead of 2¹²⁸.

Why decomposition works: the structure property

Not every table can be decomposed this way. Lasso requires that the table is decomposable, which means:

A single lookup into a table T of size N can be answered by performing c lookups into subtables T₁, T₂, ..., Tₗ, each of size N^(1/c), and then combining the results with a known function.

The combination function depends on the instruction: carry propagation for addition, concatenation for bitwise AND, and a more involved recombination for shifts.

The critical insight from the Jolt paper: all RISC-V instructions have this decomposable structure. Addition, subtraction, bitwise operations, comparisons, shifts, multiplications. Every one of them can be broken into small subtable lookups that recombine correctly.

How Lasso proves a lookup

Suppose the prover claims it performed m lookups into a table T, and each lookup returned the correct value.

Lasso needs to prove two things: that each subtable lookup returned the right entry, and that the subtable results were combined correctly. For the first, the prover commits to the subtable entries it accessed (small values, so MSM-based commitment is cheap). The verifier uses Sum-Check to confirm these values match the known subtable contents. For the second, the combination function (carry propagation, concatenation, etc.) is also verified through Sum-Check.

Because the committed values are small (they come from 8-bit subtables), the prover’s commitment cost is dominated by O(m + n) group operations, where m is the number of lookups and n is the subtable size. This is far cheaper than prior lookup arguments that scaled with the full table size.

Concrete example

A program executes two instructions:

ADD(300, 200) = 500
ADD(250, 30) = 280

The prover decomposes each into subtable lookups:

For ADD(300, 200): Decompose 300 into (1, 44) and 200 into (0, 200) as two 8-bit chunks.
Low byte: 44 + 200 = 244, carry = 0.
High byte: 1 + 0 + 0 = 1.
Result: (1, 244) = 256 + 244 = 500.

The chunks recombine without carry, but the high byte is nonzero, showing that the subtable split is not trivial for numbers above 255.

For ADD(250, 30): Decompose 250 into (0, 250) and 30 into (0, 30).
Low byte: 250 + 30 = 280, which overflows a single byte. 280 mod 256 = 24, carry = 1.
High byte: 0 + 0 + 1 = 1.
Result: (1, 24) = 256 + 24 = 280.

Here the low byte overflows. The carry bit propagates from the low subtable to the high subtable, and the combination function must account for it.

The prover commits to all subtable access values and combination results. The verifier checks, via Sum-Check, that every subtable access is valid and every combination is correct.

At no point does anyone materialize the full 2¹²⁸-row table. The verifier evaluates the subtable polynomials directly at random challenge points, using the fact that the subtables are small and their multilinear extensions can be computed efficiently.

Jolt: proving a full CPU execution

Lasso proves that individual lookups are correct. A running CPU does more than individual instructions. It fetches instructions from memory, reads and writes registers, and follows a program counter that jumps and branches. Jolt combines Lasso with three other mechanisms to cover the full execution.

Component 1: Instruction execution (Lasso lookups)

This is the core. Every RISC-V instruction in the execution trace is proven correct via Lasso lookup, as described above.

The prover generates an execution trace: a step-by-step record of what the CPU did. For each step, the trace records the instruction, the input operands, and the output.

Component 2: Bytecode consistency (offline memory checking)

The CPU must fetch the correct instruction at each step. If the program has instruction “ADD r1, r2, r3” at address 0x04, then whenever the program counter equals 0x04, the fetched instruction must be ADD with those operands.

This is a memory consistency problem. The program bytecode is stored in memory. The CPU reads from it at every step. Jolt needs to ensure that every read returns the correct value.

Jolt uses offline memory checking, a technique from the Spice protocol (optimized with Lasso). The idea:

Think of memory as a sequence of (address, value, timestamp) tuples. Every read operation must return the value from the most recent write to that address. To verify this, the prover sorts all memory operations by address, then by timestamp. Adjacent operations on the same address must form valid read-after-write pairs. This constraint is expressible as a polynomial identity, checkable via Sum-Check.

For bytecode specifically: the program is written once (at “time 0”) and only read during execution. So the check simplifies to confirming that every instruction fetch matches the original bytecode at that address.

For example, address 0x04 is written at time 0 with value ADD. The CPU reads 0x04 at time 5 and again at time 12. The checker verifies both reads return ADD.

Component 3: Read-write memory (registers and RAM)

The same offline memory checking technique applies to registers and RAM, but now with both reads and writes during execution.

When the CPU executes “ADD r1, r2, r3”, it reads the values in registers r1 and r2, computes the sum, and writes the result to r3.

The memory checking argument ensures that values read from r1 and r2 match the most recent writes to those registers, and that the write to r3 is recorded correctly for future reads.

Lasso handles range checks within this component. When the memory checker needs to verify that a timestamp is in a valid range, it treats the range check as a lookup into the table [0, 1, ..., m-1]. This keeps everything within the lookup framework.

Component 4: Control flow (R1CS constraints)

The program counter must advance correctly. This is the one part of Jolt that uses traditional arithmetic constraints instead of lookups. For sequential instructions, PC increments by the instruction size. For branches, PC jumps to the target if the condition is true and increments otherwise.

These constraints are simple linear relations. They glue the execution trace together, ensuring that each step follows from the previous one according to the program’s control flow.

How the components connect

The four components share the same execution trace. Instruction execution proves each step is computed correctly. Bytecode consistency proves the right instruction was fetched. Memory consistency proves that register and RAM reads/writes are valid. Control flow proves the program counter advanced correctly.

Each component produces a separate set of polynomial claims. The verifier checks all of them using Sum-Check and polynomial commitment openings. If any component fails, the overall proof is rejected.

The architecture is deliberately lookup-heavy. Three of the four components rely on Lasso (instruction execution, bytecode, memory). Only control flow uses R1CS, and those constraints are simple. This uniformity is what makes Jolt simpler than prior zkVMs, where each component often required a different proving technique.

From Jolt to Jolt Pro

Jolt is an open-source zkVM from a16z. It runs on CPU and proves RISC-V execution using the lookup architecture described above.

Jolt Pro is LayerZero’s fork. It targets a specific operational requirement: prove blocks fast enough that validators can verify proofs in real time, within the block time of the Zero chain. This is not an academic benchmark target. If the prover cannot keep up with block production, the chain stalls.

Three modifications move Jolt toward this target.

1. GPU-accelerated prover

The most performance-critical operation in Jolt is the multiscalar multiplication (MSM) used in polynomial commitments. MSM computes a weighted sum of elliptic curve points:

C = a₁·G₁ + a₂·G₂ + ... + aₙ·Gₙ

This operation is embarrassingly parallel. Each scalar-point multiplication is independent, and partial sums can be combined in a tree structure. GPUs, with thousands of cores optimized for parallel arithmetic, are a natural fit.

Jolt Pro runs the prover on GPU clusters. A proving cell consists of 64 colocated NVIDIA RTX 5090 GPUs. On this hardware, the prover achieves 1.61 billion RISC-V cycles per second (1.61 GHz).

For context: Jolt on CPU proves in the low tens of millions of cycles per second. SP1 and RISC Zero, also CPU-based, operate in a similar range. The 100x speedup claim compares a 64-GPU cluster against single-machine CPU provers. It is a real performance number, but it reflects a hardware difference as much as an algorithmic one. A fairer comparison would normalize by cost (dollars per proven cycle), which LayerZero has not published.

The roadmap targets 4 GHz per cell by 2027, presumably through a combination of hardware upgrades and further MSM optimization.

2. Inlines instead of precompiles

Other zkVMs (RISC Zero, SP1) add “precompiles” for expensive operations like SHA-256, Keccak, or elliptic curve arithmetic. A precompile is a dedicated circuit, hand-optimized for that specific operation, that runs alongside the main VM proof.

Precompiles are fast for the operations they cover. But each one is a separate constraint system that must be independently designed, implemented, and audited. A soundness bug in a single precompile breaks the entire proof. As more precompiles are added, the audit surface grows.

Jolt Pro takes the opposite approach. Instead of precompiles, it uses “inlines”: optimized sequences of standard RISC-V instructions that implement the same operation. SHA-256 is expressed as a series of ADD, XOR, SHIFT, and AND instructions. Each of those instructions is proven through the same Lasso lookup pipeline as everything else.

Inlines are slower to prove per operation than a hand-tuned precompile would be. But they eliminate the need for operation-specific circuits entirely. The entire prover runs through one uniform code path, compensating for per-operation overhead with raw GPU throughput and gaining auditability in return.

Whether this tradeoff holds depends on workload composition. If a program spends 90% of its cycles on SHA-256, a precompile-based system will be more efficient. If the workload is diverse (general smart contract execution), inlines suffer less of a penalty and the simplicity advantage dominates. Zero targets EVM execution for financial applications, which tends to be diverse.

3. ZeroOS: system call support

Vanilla Jolt proves pure computation: a function takes inputs and produces outputs, with no interaction with the outside world. A running program needs more than that. It needs to allocate memory, read input data, write output data, and access environmental information (block number, timestamp, caller address).

ZeroOS adds a system call layer at the RISC-V level. When the guest program executes an ECALL instruction (the RISC-V system call mechanism), ZeroOS intercepts it and handles the request. The prover includes the system call inputs and outputs in the execution trace, and Jolt’s memory checking ensures consistency.

This means standard Rust programs, compiled to RISC-V with a thin runtime, can be proven without modification. The developer writes normal Rust, uses standard library features (allocation, I/O, formatting), and the compiled binary runs inside the Jolt Pro prover as-is.

Without ZeroOS, guest programs would be limited to pure functions with fixed-size inputs, the way most current zkVM guest programs are written. ZeroOS removes that constraint, which is necessary for running a full EVM implementation inside the prover.

What Jolt Pro does not change

Jolt Pro does not modify the underlying cryptographic protocol. The Sum-Check arguments, Lasso lookup decompositions, offline memory checking, and R1CS constraints are the same as in Jolt. The polynomial commitment scheme is the same MSM-based approach. The soundness guarantees are inherited from the original Jolt construction.

The modifications are at the engineering layer: where the computation runs (GPU vs. CPU), how complex operations are expressed (inlines vs. precompiles), and what the guest program can do (system calls vs. pure functions). The math underneath is unchanged.

Open question: auditability

Jolt is open source under a16z. Jolt Pro is not. The proof is publicly verifiable: anyone can check a Jolt Pro proof against the verification algorithm. But the prover implementation — the code that generates proofs — cannot be independently reviewed.

This matters for two reasons. First, a bug in the prover could generate invalid proofs that happen to pass verification (a soundness failure). Second, institutions evaluating Zero for financial infrastructure will want to audit the full stack, not just the verifier. The closed-source prover creates an asymmetry: the math is trustless, but the implementation requires trusting LayerZero.

Whether this is acceptable depends on the threat model. If verification is sound, a buggy prover only hurts the prover (it might fail to generate valid proofs, not generate false ones). But proving this argument rigorously requires seeing the code.

Open questions

Several points remain unresolved.

Performance claims are based on demo environments, not mainnet workloads.

Hardware costs are high. A single proving cell requires 64 GPUs.

Only a small number of entities may produce blocks, raising censorship concerns.

What comes next

This article covered the path from polynomial arithmetic to Jolt Pro.

Jolt Pro is one part of the Zero stack. Other components include:

• QMDB: ZK-optimized state database

• FAFO: parallel execution scheduler

• SVID: data availability scheme

Future articles will cover these.

The goal is to allow validators to verify proofs instead of re-executing transactions. This enables parallel execution across independent environments, called Atomicity Zones.

Each zone functions like a full EVM, but runs in parallel. This removes the single-thread bottleneck found in most blockchains.

Zero’s Atomicity Zones are governed by a single protocol. Ethereum’s rollups are independently operated, each with its own security assumptions and upgrade governance. This difference matters for financial institutions: a single protocol means one audit target, one trust boundary, and one set of security guarantees.

For infrastructure targeting financial institutions, this distinction determines system design, security guarantees, and trade-offs.

The math is the same. The design choices differ.

This is Article 1 of the Dissecting Zero series.
Next: QMDB and ZK-native state storage.

I am a blockchain platform engineer at B-Harvest. Over the past two years, I have operated validator and RPC infrastructure across more than ten networks and contributed to core chain development with Cosmos SDK and CometBFT. My current focus is building a development tooling platform for financial institutions entering Web3.

Feedback is welcome. Reach out on LinkedIn or Twitter (@jinuahn05).

Disclaimer: 본 글은 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 “Deep dive into AutobahnBFT: DAG와 PBFT의 만남”을 주제로 작성되었습니다. 해당 글은 DAG 기반 병렬 전파 계층과 PBFT 스타일…

For teams building high-performance chains, Commonware offers freedom to build without fighting framework assumptions.

“” is published by Jinu Ahn in Decipher Media ｜디사이퍼 미디어.

Disclaimer: 본 글은 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 “Deep dive into Sui”를 주제로 Weekly Session에서 발표한 내용을 바탕으로 작성되었습니다. 해당 글은 Sui에 대한 전반적인 내용을…