네트워크 부하 대응과 ZIP 317
ECC가 급증한 네트워크 부하 대응 현황을 공유했고 ZIP 317 수수료 초안이 소개됐다
안건별 요약 6
Zebra 업데이트 - 릴리스 후보 준비
Zcash Foundation · Teor
- 몇 주 전 Zebra 팀 리드가 Teor로 교체됐다. 팀 모두가 컨퍼런스 운영을 도와 이번 달 개발은 느렸다.
- 릴리스 후보(release candidate)를 위해 테스트 정비, 의존성 업데이트, 소소한 성능 개선과 네트워크 프로토콜의 사소한 수정을 진행했다.
- 직전 릴리스에서는 설정에 호환성이 깨지는 변경과 여러 성능 개선이 있었고, 앞으로 몇 번의 릴리스 안에 release candidate를 준비하는 것이 목표다.
Zcashd 업데이트 - 네트워크 부하의 영향과 대응
Electric Coin Company · Steven
- 6월 중순부터 차폐 트랜잭션 부하가 크게 늘었다. 노드 운영과 P2P는 블록 전파가 느려진 것 외에는 영향이 적었고, 풀노드 지갑을 쓰는 채굴자와 거래소는 스캔 시간 증가와 고아 블록 증가를 겪었다.
- 모바일 지갑이 가장 큰 타격을 받았다. SDK 기반 Edge, Unstoppable, Nighthawk는 동기화가 매우 느리거나 실패했고, Ywallet과 Zecwallet Lite는 대체로 잘 동작했다.
- 부하는 6월 중순 Orchard 중심에서 Sapling 중심으로 바뀌었다. 평균 100개 남짓 출력이던 거래가 이제 1000개가 넘는 출력을 갖게 돼 거래 수는 줄었지만 검증 부담은 비슷하다.
- 체인 크기는 6월 중순 이후 약 3배로, 약 30GB에서 약 83GB로 늘었다. 5.1.0은 Sapling과 Orchard 블록 검증 시간을 80% 줄였고, 5.2.0은 전파 시간 단축과 풀노드 지갑 스캔 병렬화를 담았다.
- 파트너 피드백으로는 고아 블록 비율이 한때 8%에서 1.8~2.8%로 내려갔다. 수십만 주소를 가진 대형 zcashd 지갑은 스캔이 느리지만 운영에는 지장이 없다.
Zcashd 업데이트 - 모바일 SDK 동기화와 ECC의 대응 방향
Electric Coin Company · Steven
- 모바일 SDK의 FFI 계층, 동기화 개선, API 보강 가운데 빠른 동기화를 우선순위 최상위로 올렸다. 아직 개발과 벤치마크 전이지만 수 시간~수 일 걸리던 동기화를 1시간 미만으로 줄이는 것이 기대치다.
- ECC는 엔지니어링을 최우선으로 하면서 생태계 파트너에게 상황을 알리고 노드 수준의 남은 문제를 파악하는 활동도 병행하고 있다.
- 연구 인력은 Proof of Stake에서 수수료 메커니즘으로 옮기고 있으며, Nate가 EIP 1559류 아이디어를 검토하고 Adi의 ZIP 제안도 살펴볼 예정이다.
- 수수료 등 어떤 변경이든 모바일 지갑 UX와 멤풀에 미치는 부작용을 종합적으로 평가하겠다고 밝혔다. 성장팀은 사용자 설문을 진행해 결과를 공유하고, 2단계로 장기적 취약점을 미리 찾아 해결할 계획이다.
공개 토론 - 지갑 SDK 통합과 unified address 전환
Electric Coin Company · Daira, Str4d, Steven, Dodger
- 지갑 SDK가 쓰던 librustzcash 포크를 최신 버전으로 통일하는 작업이 거의 끝났다. 성능 작업은 그 위에서 진행하며, 오래 정체된 zcash_client_backend 크레이트 릴리스에도 가까워졌다.
- 새 모바일 SDK는 지갑이 unified address로 전환되는 릴리스다. 뷰잉 키가 transparent, Sapling, Orchard를 담은 unified viewing key로 마이그레이션된다.
- 첫 SDK 릴리스는 Orchard 지출을 지원하지 않으므로 UA의 주소 구성요소에서 Orchard를 일단 뺄 수 있다. 지출 키는 Orchard를 포함해 마이그레이션은 한 번이면 되고, Orchard 지원이 바로 뒤따른다.
- Steven은 unified address를 먼저, Orchard를 이후 업그레이드로 냈으면 좋았을 것이라는 교훈을 언급했다. ECC 지갑도 lightwalletd 구조를 그대로 쓸 계획이다.
공개 토론 - Detection key와 DAGSync
Str4d, Kris, Daira, Dodger, Pacu
- Str4d는 정상 상태 동기화의 병목이 체인상 기존 지갑과 연결되지 않은 새 지출의 탐지, 곧 모든 출력의 시도 복호화라고 설명했다. 큰 개선은 detection key 방식 또는 체인 스캔 없이 거래를 직접 받는 방식에서 나온다.
- Detection key는 송신자 호환과 주소 변경이 필요해 단독 배포는 어렵다. unified address가 자리 잡은 뒤 그 위에 올릴 수 있다.
- Str4d의 DAG sync 아이디어에서는 새로 발견한 자금을 지갑의 그래프에 편입하므로, 시드 복구 때도 전체 선형 스캔 없이 최근 거래만 찾으면 된다. Daira는 시드 복구를 위해 출력이 체인에 남는 점을 짚었다.
- Dodger는 풀노드가 detection key로 스캔을 대신해주고 Tor로 접속한 라이트월렛이 구간을 나눠 맡기는 구상을 냈다. 라이트월렛 서버 중앙화도 줄이며 워크숍을 열자는 의견이 나왔다.
- Pacu는 지갑이 멤풀을 능동적으로 보지 않아 거래 체감 속도를 개선할 여지가 크다고 했다. Str4d는 차폐 잔돈은 채굴 전에는 쓸 수 없어 멤풀이 의미 있는 쪽은 투명 거래라고 답했다.
공개 토론 - 차폐 거래 중단론, 블록 크기, ZIP 317
Steven, Str4d, Daira, Dodger
- 차폐 거래를 일시 중단하자는 질문에 Str4d는 블록은 투명 거래로도 채울 수 있어 효과가 없고 증명 검증 비용만 준다고 했다. Daira는 공격자의 목표 달성이라 안 된다고 했다.
- Daira는 합의 규칙이 아니라 채굴자 옵션으로 실질 블록 크기를 절반으로 줄여 체인 증가와 검증 시간을 대략 절반으로 줄이는 안을 제시했다. 이미 zcashd 옵션으로 가능하다.
- Steven은 블록을 줄이면 일반 차폐 결제가 밀릴 수 있다고 우려했다. Daira는 Blossom 때 블록 시간을 줄이며 한 추정이 병렬 검증 구현 후에도 한계에 가까워 틀렸을 수 있다고 인정했다.
- Dodger는 임시 조치로는 타당하지만 5~10년 뒤 더 큰 거래량을 목표로 하는 만큼 이번 일이 개선을 강제하는 계기라고 봤다. Steven은 Halo 2 재귀 기반 트랜잭션 또는 블록 집계를 장기 해법으로 꼽았다.
- Nighthawk의 Aditya가 입출력 수에 비례하는 수수료를 제안한 초안 ZIP 317(PR 631)이 올라와 있고, Daira는 의견을 남겨달라고 요청했다. Nate가 이를 EIP 1559류 연구와 함께 검토할 예정이다.
한국어 요약은 원문을 바탕으로 정리한 것으로, 정확한 내용은 원문을 확인하세요.