← 모든 콜 보기
ARBORIST#47

Orchard 회로 배치 버그 수정

32비트 환경에서 Orchard 증명이 실패하던 Halo 2 회로 배치 버그가 해결돼 다음 크레이트에 담긴다

안건별 요약 9

  1. Zebra 테스트 채굴과 감사 진행

    Zcash Foundation · Pili

    • Zebra의 기본 채굴 기능 구현을 마쳤다. 여러 팀원이 채굴 풀에 연락해 시험 의향을 묻고 있으며, 풀 운영자나 솔로 채굴자가 테스트를 원하면 담당자를 붙여 지원한다.
    • 최근 몇 주간 팀이 Zebra 관련 개인 프로젝트에 쓰는 20% 시간 휴지기를 가졌고, 결과를 블로그 글로 공개할 예정이다.
    • Zebra 감사 팀의 첫 업데이트를 받아 지적 사항별 이슈를 만들기 시작했다.
  2. Orchard 회로 레이아웃 버그

    Electric Coin Company · Jack Grigg, Daira, Nathan

    • 32비트 환경의 Halo 2 Orchard 증명에서 회로 레이아웃 문제가 발견됐고 해결했다. 레이아웃 일부가 불안정한 정렬 함수의 동작에 의존해, 변경되면 검증 키가 달라지는 문제였다.
    • Daira에 따르면 32비트 플랫폼과 최신 Rust 버전(1.69 또는 1.70 이후)에서 영향이 있었다.
    • 수정은 다음 orchard 크레이트와 zcash_primitives 0.11 등 Rust 크레이트 업데이트에 담기며 reddsa 릴리스를 기다리는 중이다.
    • 이론상 합의에 영향을 줄 수 있었지만 32비트에서 합의 노드를 돌리는 곳이 없고, zcashd도 최신 Rust 업그레이드 때 테스트에서 걸러졌을 것이다.
    • 실제 영향은 해당 지갑에서 Orchard 자금을 쓰지 못한 것이며 자금 손실은 없다.
    • Kris는 zcashd 지갑의 트랜잭션 구성 내부 개편이 거의 끝났고, 지갑과 채굴 블록 구성의 ZIP 317 지원을 5.5.0에 담는다고 했다. 5.5.0은 3~4주 뒤로 예상한다.
  3. FROST RFC 승인과 구현 업데이트

    Zcash Foundation · Conrado, Deirdre

    • RFC는 CFRG 의장의 리뷰를 받았고 주로 편집상 문제여서 이번 주 안에 반영해 다음 승인 단계로 가는 것을 목표로 한다.
    • Natalie가 FROST에서 분실한 지분(share)을 복구하는 기능을 구현 중이다. 임계치 이상의 참가자가 프로토콜로 도와주며 전체 비밀을 재구성하지 않고 잃은 지분만 복원한다.
    • FROST 데모 프로그램(지분 생성과 서명)을 계획 중이며 흐름 검증과 개발자 예제를 겸한다. 키 생성에 필요한 브로드캐스트 채널의 권장 구현도 기획 단계다.
    • core와 재랜덤화 크레이트를 막 게시했고 FROST 크레이트는 모두 0.1.0이다. reddsa의 재랜덤화 FROST 지원은 ZIP 312 리뷰 중이라 기본 꺼짐의 실험 기능이다.
  4. ZSA 업데이트와 스펙 정정

    QEDIT · Vivek, Daira, Nathan

    • ZIP 확정을 위한 회의가 순조롭다. 자산 식별자 정의를 내부적으로 바꾸고 이름을 정리했으며, 발행 키 파생은 ZIP 32 절차를 따르되 Orchard 키와 독립적으로 정했다.
    • ZEC 노트에도 더미 노트 대신 split 노트를 쓰자는 논의는 미해결이며 Daira가 검토할 예정이다. 회로는 자산별 기준점이 필요해 가변 기저 스칼라 곱을 값 커밋먼트에 구현 중이고, 클라이언트에는 발행 RPC를 추가했다.
    • QEDIT는 원자 교환과 NU6 항목을 포함한 ZSA 후속 제안을 구상 중이다. Daira는 ZIP 216 소급 적용과 Sapling 관련 소규모 정정을 담은 프로토콜 스펙 업데이트가 있을 것이라고 했다.
    • Nathan은 비동기 연구 토론 포럼 후보로 Zcash 커뮤니티 포럼이나 GitHub Discussions를 검토 중이라고 했다.
  5. ZIP 317 일정과 5.5.0

    Electric Coin Company · Jack Grigg, Kris

    • zcashd 5.5.0은 3~4주 뒤로 예상되며 개발자 DAG에서 5.5.0 노드의 상류에 있는 것이 포함 대상이다. Halo 2 32비트 수정과 ZIP 317이 들어간다.
    • 5.5.0에는 ZIP 317 블록 생산과 수수료 선택이 zcashd 블록 생성기와 지갑에 들어간다. 이후 모바일 SDK에서는 이미 배포돼 있는 기능을 활성화하기만 하면 된다.
    • Zebra는 블록 생산에 ZIP 317을 구현했고 지갑은 없다. Zecwallet Lite와 Ywallet처럼 SDK를 직접 쓰지 않는 지갑도 필요한 부분이 librustzcash에 있다고 Kris가 말했다.
  6. FROST 도입 논의 - ECC 지갑과 zcashd

    Jack Gavigan, Jack Grigg, Nathan, Deirdre

    • ECC가 zcashd나 지갑에 FROST를 넣을 계획이 있는지 묻자 Jack Grigg는 현재 없다고 했다.
    • 차폐 멀티시그는 zcashd 밖의 별도 바이너리가 낫고, PSBT의 Zcash 대응물인 부분 생성 트랜잭션이 선행돼야 한다고 했다.
    • Nathan은 첫 ECC 지갑은 아주 기본적인 기능만 담고, 사회적 복구 등 비밀 관리의 날카로운 부분을 줄이는 방향으로 FROST 활용을 탐색할 수 있지만 로드맵은 없다고 했다.
    • Deirdre는 FROST 서명과 키 생성의 요건이 다르다고 설명했다. 딜러가 있는 trusted keygen이 더 쉽고 완전한 DKG는 브로드캐스트 채널이 필요하다며, 팀이 사용 환경에 맞는 설계를 함께 찾을 수 있다고 했다.
    • Jack Grigg는 Casa처럼 기기가 딜러가 되고 3-of-5 기기로 지출하는 로컬 2FA형 사용 사례를 제안했다. 격주 커뮤니티 지갑 개발자 회의에서 발표도 환영한다고 했다.
  7. Zebra 감사와 이클립스 공격 대응

    Zcash Foundation · Deirdre, Daira, Jack Grigg, Jack Gavigan

    • 감사 업체 NCC의 감사자가 네트워크 수준 이클립스 공격 대응 이력을 물어, Deirdre가 zcashd 쪽의 분석 여부를 문의했다.
    • Daira는 zcashd에 서브넷 등으로 주소를 그룹화하는 복잡한 코드(Bitcoin Core에서 쌓인 것)가 있으나 효과는 모른다고 했다. Zebra에는 출처 기반 처리가 없는 것으로 보인다.
    • Jack Grigg는 아웃바운드 연결을 같은 그룹당 하나로 제한해 인바운드 데이터가 아웃바운드를 좌우하지 않게 하는 점을 들었다. 체인이라는 공유 전역 상태가 있어 외부 연결 하나만 있으면 복구되므로 순수 P2P보다 탄력적이다.
    • DNS seeder도 프로토콜 준수, 버전과 높이 호환, 장기 가동 여부 등의 휴리스틱을 쓴다. Jack Gavigan은 이를 우선순위를 낮추고 새 DNS seeder와 기술 부채 검토로 미루자고 했다.
  8. 보안 연구자 그랜트 경로 문의

    Deirdre, Jack Grigg, Daira, Jack Gavigan

    • Deirdre는 Zcash 프로토콜 보안 분석을 맡길 연구자의 자금 경로를 물었다.
    • Jack Gavigan은 규모에 따라 소액 그랜트(마감 11일 후)나 Zcash Community Grants를 제안했고, 포럼에 먼저 아이디어를 올리라고 했다.
  9. Halo 2 명세와 PLONKish 산술화

    Deirdre, Jack Grigg, Daira, Jack Gavigan

    • Halo 2를 형식 명세 언어로 구현하려는 연구자를 위해 Jack Grigg는 Halo 2 책의 4.2절이 현재 배포된 증명 시스템의 형식 기술이라고 했다.
    • Daira는 독립 구현은 가능하지만 일부 리버스 엔지니어링이 필요하고 코드와의 대조 검토는 아직 없다고 했다.
    • Halo 2라는 이름이 Halo 3의 출현을 뜻하지는 않으며, 재귀를 더한 뒤에도 Halo 2로 부른다. 신뢰 설정이 없어 회로를 바꿔도 이전이 쉽고, 두 산술화 지원은 큰 작업이다.
    • Daira는 비영 회전(rotation)을 추상 열과 힌트로 표현하는 방식을 소개했다. 추상 열로 회로 크기를 줄이고 분석도 쉽게 하며, 힌트가 틀려도 정확성 문제가 없다. 추상화 컴파일의 성능 차이는 대략 3배로 어림했다.
    • PLONKish는 알려진 산술화 최적화를 모두 담고 R1CS보다 곱셈의 자유도가 높아 앞으로도 유지될 것이라고 Daira와 Jack Grigg가 말했다.

한국어 요약은 원문을 바탕으로 정리한 것으로, 정확한 내용은 원문을 확인하세요.