ZIP 317 단계적 도입 로드맵
ZIP 317 수수료 개편을 지갑, 릴레이, 합의 순서로 단계 배포하는 로드맵이 논의됐다
안건별 요약 9
Zebra 업데이트 - beta.14와 월렛 기능 질문
Zcash Foundation · Marek, Deirdre, Dodger
- 일주일 전 Zebra beta.14를 릴리스했다. CI가 안정적으로 동작하고 zebrad 실행 시 start 명령이 기본값이 됐다.
- 체크포인트 구간이 끝난 뒤 블록마다 트리 상태를 두 번 갱신하던 문제를 고쳐 동기화가 빨라졌다. rayon 스레드로 트랜잭션을 역직렬화하며 생긴 lightwalletd 동기화 회귀는 되돌렸다.
- Zebra 릴리스 후보의 릴리스 과정을 매끄럽게 만드는 작업을 하고 있다. 신규 엔지니어 Arya가 합류했다.
- Adi의 질문에 Dodger는 Zebra 자체에 지갑을 내장할 계획은 로드맵에 없다고 답했다. 현재는 lightwalletd 대체 지원과 getblocktemplate에 집중하고 있다.
- 마이너 내장 계획도 없으며, getblocktemplate로 채굴자가 Zebra에서 블록 템플릿을 받아 각자의 소프트웨어로 채굴하게 할 계획이다.
Zcashd 업데이트 - 동기화 개선과 메모리 사용량
Electric Coin Company · Steven, Daira
- 5.1.0과 5.2.0으로 노드 쪽은 상당히 개선됐고, 이제 지갑 동기화 속도 개선에 집중하고 있다.
- 동기화 중 메모리 사용량이 늘어 일부 사용자가 OOM을 겪는다는 보고가 있었다. 재현에 성공해 최대 메모리를 줄일 초기 수정안을 찾았고, 누수가 아니라 처리량 증가가 원인으로 보인다.
- Daira는 차폐 주소를 스캔하지 않는 사용자에게도 OOM이 있어 다른 요인이 있을 수 있다고 했다. 8GB VM에서 정상 상태 사용량이 9GB를 넘는 경우도 확인됐다.
수수료 메커니즘 변경 - ZIP 317 논의
Electric Coin Company · Steven, Nate, Daira, Adi, Str4d
- Nighthawk의 Adi가 올린 ZIP 317(PR 631)에 대해 Nate는 파라미터 조정을 전제로 ECC가 대체로 지지한다고 밝혔다. 사용자 연구와 온체인 분석을 함께 반영하고, 장기 수수료 개선의 일부로 보고 있다.
- ECC 신규 엔지니어 Greg가 과거 트랜잭션이 얼마를 냈고 수수료 변경 시 얼마를 낼지 분석하고 있다. 일반 사용에 미칠 영향을 데이터로 확인하려는 것이다.
- Nate는 ZIP 317 배포를 단계로 나누자고 제안했다. 지갑이 규칙을 먼저 구현하고, 이후 릴레이 규칙을 바꾸며, 둘 다 합의 변경이 필요 없어 빠르게 가능하다. 혼잡도 연동 같은 확장과 로드맵은 별도로 다루자고 했다.
- Daira는 투명 지갑은 이미 체인 상황에 맞춰 수수료를 조정하므로 큰 문제가 없다고 했다. 다만 기존 고정 수수료 10,000 zat를 쓰는 일부 지갑은 기본 수수료의 10배를 넘는 경우 문제가 생긴다고 인정했다.
- Nate는 입출력 비례 수수료가 채굴 풀, 거래소 등 다양한 사용 사례에 영향을 주므로 전형적 사용자만 상정하지 말자고 했다. Adi는 차폐 채굴자 거래는 입출력 50~100개 수준이라 큰 변화는 아니라고 보았다.
- 낮은 수수료 트랜잭션은 결국 릴레이 제한으로 걸러질 것이라고 Daira가 예상했다. Nate는 지갑이 거절을 알 수 있는지 등 UX 문제를 지적했다.
ZIP 317 - 배포 섹션과 트랜잭션 만료 높이
Electric Coin Company · Str4d, Dodger, Kris
- ZIP 편집자들이 ZIP 317 검토 때 배포 섹션을 채워달라는 의견을 여러 건 냈고, 아직 반영되지 않았다고 Str4d가 전했다.
- ECC가 관리하는 트랜잭션 빌더의 기본 만료 높이는 40블록이다. 일부 Bitcoin 파생 빌더는 이 필드를 0으로 고정하고, 만료 높이가 설정된 거래를 파싱하지 못하는 구현도 있다.
- Greg의 분석에서는 실제 트랜잭션에 설정된 만료 높이도 통계로 수집하고 있다고 Kris가 밝혔다.
ZSA 수수료 제안
QEDIT · Daniel Benarroch
- ZSA용 수수료 제안을 작성 중이며 1~2주 안에 올릴 예정이다. Sapling과 transparent는 그대로 두고, ZSA만 달리 책정한다.
- ZSA 사용 유도를 위해 바이트와 action당 가격을 낮추고, 발행에는 발행당 고정 수수료와 출력당 소액 수수료를 매기는 안이다.
- ZEC를 핵심 통화로 유지하고 쓰레기 자산을 막는 것이 목적이다. 발행 수수료를 1 ZEC 정도로 높이고 번영 기금이나 Zcash Foundation, Grants Committee 기금 등으로 보내는 아이디어를 냈다.
- Adi는 ZSA가 내년 이후 메인넷에 올 것이라 우선순위는 여전히 ZIP 317이며, ZSA 장려와 스팸 방지를 함께 봐야 한다고 했다. 수수료 변경은 지갑, 거래소, 하드웨어 지갑까지 조율해 배포해야 한다고도 했다.
모바일 SDK 동기화 개선 로드맵
Electric Coin Company · Steven, Str4d, Daira, Adi
- ECC의 최우선 엔지니어링 과제는 모바일 SDK의 빠른 동기화이며, Edge, Unstoppable, Nighthawk가 주요 수혜자다. 개선은 여러 단계로 나눠 배포한다.
- 내부 테스트에 달렸지만 iOS SDK를 먼저, Android를 곧이어 내는 것이 목표이며, 다음 주 iOS 첫 업데이트 패키징을 노리고 있다.
- 다음 SDK는 unified address(UA) 마이그레이션과 시도 복호화 병렬화를 포함한다. 이어 커밋먼트 트리와 증인 갱신 방식 변경이 나오고, 전체 DAGSync는 SDK 인터페이스가 달라질 수 있어 그 이후다.
- 병렬 시도 복호화 코드는 있고 Sapling에는 통합됐지만, Orchard에도 적용했는지는 Str4d가 기억하지 못했다. SDK에는 아직 Orchard 지원이 없어 현재는 영향이 없다.
UA와 Orchard 롤아웃 논의
Electric Coin Company · Str4d, Daira
- UA 마이그레이션에서 지출 키 백엔드에는 Orchard 키가 포함되지만, SDK는 지출 시 Orchard를 고르지 않고 Sapling을 고른다. 이후 업데이트에서 Orchard 출력의 시도 복호화가 추가된다.
- Daira는 Orchard를 받을 수 있기 전에 Orchard 구성요소를 담은 UA를 내보내면 안 된다고 짚었고, 이를 확인하기 위해 librustzcash에 이슈 630을 올리기로 했다.
- SDK 지갑은 UA의 Orchard 구성요소를 무시하고 Sapling 구성요소로 보낸다. Zecwallet Lite가 만드는 Orchard 전용 UA는 다음 SDK에서 작동하지 않는다.
ZSA 진행 상황 - 회로 크기와 값 표현
QEDIT · Daniel Benarroch, Daira, Str4d, Nate
- ZSA 제안의 마일스톤을 설계와 구현, 배포와 장기 테스트로 나눠 재구성해 제출할 예정이며, Grants Committee의 Adi와 절차를 상의하겠다고 했다.
- 회로 구현은 절반 정도 진행됐고, 회로 크기가 목표 한도를 넘을 수 있어 제약을 재검토해야 할 수 있다. Daira는 2^11 대비 얼마나 넘는지 물었지만 구체 수치는 아직 없었다.
- 비용이 큰 부분은 타입을 붙이기 위한 Sinsemilla 해시 라운드 추가다. Daira는 고정 기저 곱셈이 가변 기저로 바뀌는 점과, 가변 기저 곱셈 구현에 개선 여지가 많다는 점을 짚었다.
- Str4d는 Ethereum 브리지 때문에 u64를 넘는 값 표현이 필요할 수 있다고 했다(wei, ERC20의 u256). Daira는 u192도 가능하며 브리지에서 하위 자리를 0으로 요구하면 된다고 답했다.
- Daira는 ZIP 회로 섹션에서 dummy 처리 설명이 누락됐다고 지적했다. split일 때는 V old가 0이 아님을 강제해 머클 경로 검증을 유지해야 하며, Str4d도 ZIP에서 명확히 해야 한다고 했다.
Unified Spending Key와 Unified Viewing Key
Electric Coin Company · Hazel Ohearn, Kris, Str4d, Dodger, Daira
- Hazel이 USK와 UFVK가 프로토콜 수준 개념이 아니고 doc(hidden)인 이유를 물었다. Kris는 UFVK는 ZIP 316에 인코딩이 정의돼 있고, USK는 ZIP 316에 도출 방식만 있다고 답했다.
- FFI 경계를 넘기 위한 USK 인코딩 PR이 곧 병합되며, 지갑용 내부 편의일 뿐 백업이나 전달용이 아니다. React Native처럼 ASCII 문자열만 쓰는 환경을 위한 것이며 불안정 기능 플래그로 보호한다.
- UA는 송금 상대에게, UFVK는 열람 권한을 줄 소수에게 전달하지만, 지출 권한의 뿌리인 USK는 주고받지 않는다. 복구는 니모닉 시드가 맡는다. Kris는 SSH 개인키를 다른 기기로 복사하지 않는 것에 빗댔다.
- Dodger와 Daira는 하드웨어 지갑이 일부 풀만 지원하는 상황이 올 수 있다고 했다. Str4d는 새 풀이 생기면 모든 USK를 갱신해야 해 USK 전달은 잘못된 기능이라고 했다.
한국어 요약은 원문을 바탕으로 정리한 것으로, 정확한 내용은 원문을 확인하세요.