🌪️ gNADO

NADO의 포인트 탭의 문구가 바뀌었네요.
😐 NADO Point LB Soon??

no_activity_is_tracked_we_all_going_to_die
→ Points System Initializing

최근 지표도 상당히 양호한 편입니다.

Daily Volume : $300~500M
Daily OI : $30M
Users < 4000

Defillama
- 7day Volume Perp Dex rank : 7th

최근 7day의 평균 Revenue가 $60k 정도 되어보이네요. (프라이빗 알파라고!)

며칠 전, 썼던 글 처럼

커뮤니티가 우려하고 있는 $INK Value의 종속성의 문제는 팀도 인지하고 있다고 하니 ,

포모느끼지 않을 정도의 작업은 할 예정 (일단 실 사용감이 좋고, 상당히 프로덕트를 빌딩한 상태에서 런칭했음)

무엇보다 $INK의 TGE 예정인 내년 상반기면 NADO도 얼추 포인트 시스템이 마무리되지 않을까...?

Ink Chain의 Lending 플랫폼인 Tydro도 최근 wETH supply/borrow cap이 증가하면서 INK TVL도 $400M로 껑충 뛰었네요.

😎 Lighter: A Trading-Native Custom zk Stack

zk-SNARK (Zero-Knowledge Succinct Non-interactive Argument of Knowledge)
- 어떤 계산을 규칙대로 정확히 했다는 걸, 계산 과정을 전부 실행하지 않아도 짧은 증명으로 확인 가능한 방식
- zk-SNARK는 zk-rollup (zkSync, Scroll), Zcash 등에 사용되는 기술 stack으로 이 트랜잭션 묶음이 Ethereum 합의 규칙대로 실행 됐음을 증명하는 로직입니다.

1. zk roll-up은 빠른 verify와 succinct한 게 장점이지만, proving이 비싸고 설계 난이도가 높기 때문에 Lighter 이전의 많은 zk 기반 설계는 범용 VM, 혹은 범용적인 Proving stack 위에서 trading 로직을 얻는 방향이었습니다.

2. Lighter는 Order matching, price-time priority, liquidation 등을 모두 custom arithmetic circuit으로 증명하는, 마치 거래소 전체가 zk-SNARK 증명 시스템을 바탕으로 합니다.
(Lighter의 ZK는 Privacy 목적보다 SNARK를 verifiable computation으로 사용하여 거래소 실행의 correctness를 증명합니다.)

3. Lighter 이전의 zk는 DEX를 구성하기 위한 보조 도구로서 사용되었습니다.
주문 매칭은 off-chain 매칭을 이용했으며, 매칭 순서를 결정하는 sequencer가 있었습니다. ZK proof는 trade 결과가 유효하고, margin 계산, balance update가 정상적인지를 검증하는 정도였습니다

4. 여기서 빠진 내용은 누가 어떤 order를 먼저 올렸는지, price time priority가 지켜졌는지는 증명 대상에서 제외되었습니다.
(오더북 state가 off-chain이면 컨트랙트가 price time priority를 독립적으로 검증하기 어렵고, 그 결과 operator를 신뢰해야 하는 지점이 생깁니다.)

5. 이러한 로직은 탈중앙화를 위한 근본적인 한계를 보여줍니다. 여러 maker order가 같은 price에 있을 때, 어떤 주문을 채우는지 증명되지 않기에 중앙화 문제가 있을 수 있고, 이로 인한 MEV 가능성이 존재합니다. (Sequencer Trust Issue)

"같은 가격에 maker가 여러명 있는데, 내 친구 주문을 먼저 체결해야지"

또한 Order book 전체 state를 zk circuit 다루는 것은 witness와 hashing 비용이 폭증하기 때문에 현실적인 구현이 어렵습니다.

6. 또한 사용자가 플랫폼을 사용할 때 발생하는
1. buy/sell order
2. order cancel
3. partial fill
4. liquidation cascade
와 같은 연속적인 상태 의존적 로직을 증명하기가 불가능합니다.

7. 백서에 따르면 Lighter에서 ZK-Prover가 증명하는 것은
1. price-time-priority order matching
2. liquidation logic
3. margin & risk check
4. funding / mark price update
5. account state transition 전체로 Order book 내부 로직, 그 자체에서 zk curcuit이 작동합니다.

8. 그럼 왜 기존의 Perp DEX는 위와 같은 방법을 도입하지 못했을까요?

기존 cex/dex order book이
- linked list, price level map, heap 구조로 ZK circuit에서 적합한 형태가 아니었기에
- Lighter는 먼저 zk specific order book을 새롭게 설계하여, order book tree라는 data structure를 고안합니다.
- price + time(nonce)를 leaf index에 직접 인코딩하여 구조 자체가 price-time priority를 강제합니다.

9. Lighter의 zk circuit은 Lighter 인앱 내의 발생하는 activity를 모두 circuit이 직접 검증하고 설계 하였기에, Sequencer가 임의로 주문 순서를 변경하지 못합니다.

(체결 결과가 Circuit이 강제한 price-time priority와 불일치 하면
proof 생성이 실패하고 Ethereum state update가 되지 않습니다.)

10. 또한 중앙화 문제를 만들어낼 수 있는 sequencer 권한을 단순히 transaction ordering으로 축소함으로서 주문 matching과 execution correctness는 prover가 증명합니다.

✏️ 2탄에서 계속 ..

저는 업계인이 아닙니다. 열심히 공부하는 사람으로서 내용이 다소 사실과 틀릴 수 있다는 점 양해바랍니다. 뭐 틀리진 않을거에요.