FROST

안나, 얀, 에바가 한 단체의 적립금을 관리한다고 가정해 봅시다. 이들은 2 of 3 규칙을 선택합니다. 안나와 얀, 안나와 에바, 또는 얀과 에바가 지급을 승인할 수 있습니다. 각자는 공동 키 정보를 암호학적으로 나눈 서로 다른 비밀 조각을 보관합니다. 하나만으로는 부족하지만, 같은 비밀번호의 복사본 세 개를 뜻하는 것도 아닙니다. 에바가 참여할 수 없다면 나머지 둘이 협력할 수 있습니다. 공격자에게도 같은 기준이 적용됩니다. 충분한 조각을 얻으면 공격자 역시 서명할 수 있습니다. 따라서 기기나 계정 하나가 뚫렸을 때 다른 모든 조각까지 노출되지 않아야 분산 보관의 의미가 있습니다. [1] [2]

앱에 서명 요청이 떴다는 이유만으로 안나가 작업을 승인해서는 안 됩니다. 수신인, 금액, 수수료를 알고 잔돈이 있다면 단체로 돌아오는지 확인해야 합니다. 모든 서명자는 실제 거래를 신뢰할 수 있는 방법으로 검토할 수 있어야 합니다. Hash는 데이터의 짧은 암호학적 지문이지만, 그 자체로 사람에게 내용을 설명해 주지는 않습니다. FROST는 같은 메시지에 대한 협력을 가능하게 할 뿐, 청구서가 진짜인지 또는 사람이 승인 내용을 이해했는지는 판단하지 않습니다. 서명이 완성되어도 지급이 블록에서 확인된 것은 아닙니다. 블록은 Bitcoin 네트워크의 공동 기록에 추가된 거래 묶음입니다. RFC 9591은 정보 제공용 프로토콜 명세이지, 앱 전체의 안전성을 보증하는 인증서가 아닙니다. [1] [2]

Taproot는 해당 키의 서명을 사용하거나 미리 정한 조건을 충족해 자금을 쓸 수 있도록 하는 Bitcoin의 업그레이드입니다. 적절히 구성된 임계값 서명은 Taproot의 키 경로로 자금을 쓸 때 일반적인 단일 키 서명처럼 보일 수 있습니다. 서명만으로는 내부 조각 수나 임계값을 알 수 없습니다. 이는 개인정보 보호와 서명 데이터 크기에 도움이 되지만, 거래 전체나 참여자 간 통신을 익명으로 만들지는 않습니다. Bitcoin은 BIP 340의 정확한 규칙을 요구하므로 키 계산의 수학적 기반인 secp256k1 곡선에서 일반적인 FROST를 사용하는 것만으로는 부족합니다. 그래서 Zcash Foundation (ZF)는 Taproot용 frost-secp256k1-tr을 별도로 제공합니다. Taproot가 사용하는 키 조정도 올바르게 처리해야 합니다. 곡선 이름이 같다고 호환성이 증명되는 것은 아니며, 라이브러리가 있다고 모든 지갑이 지원하는 것도 아닙니다. [3] [4]

단체는 무엇이든 서명하기 전에 조각을 안전하게 만들어야 합니다. 신뢰하는 배포자가 완전한 키를 생성한 뒤 나눌 수 있습니다. 하지만 이때 민감한 순간이 생깁니다. 배포자는 전체 키를 알고 있으며 복사본을 남기면 의도한 공동 승인을 우회할 수 있습니다. 다른 방법은 DKG, 즉 분산 키 생성입니다. 완전한 비밀키가 어느 한 참여자에게도 나타나지 않게 만들 수 있지만, 인증되고 보호되는 통신과 올바른 프로토콜 실행이 필요합니다. 파일 몇 개를 이메일로 보내는 것으로는 부족합니다. RFC 9591은 서명에 초점을 맞추므로 모든 제품이 자동으로 DKG를 제공한다는 뜻은 아닙니다. 장기간 사용하는 키 조각과 특정 지급 한 건의 서명 조각도 서로 다릅니다. [1] [2]

서명 자체는 두 차례의 라운드로 이루어지며, 앞서 키를 만드는 과정은 여기에 포함되지 않습니다. 먼저 선정된 참여자마다 nonce라는 비밀 일회용 값 두 개와 그에 대한 공개 커밋먼트를 만듭니다. 커밋먼트는 해당 nonce에 참여자를 암호학적으로 묶는 값으로, 다른 이들에게 전송됩니다. 이후 공통 메시지와 커밋먼트 목록을 받아 자료를 검토하고 자기 서명 조각을 계산합니다. 조정자가 이를 합칩니다. 결합 계수는 계산을 특정 메시지, 그룹 공개키, 커밋먼트에 연결합니다. 2 of 3 규칙이라면 두 사람을 선택해 세션을 시작할 수 있습니다. 그러나 세 사람 모두를 선택했다면 모두가 기여해야 하며, 응답을 멈춘 사람을 단순히 빼고 진행할 수는 없습니다. [1] [3]

여기서 nonce는 서명 시도 한 번을 위한 비밀 값이지 반복해서 쓰는 비밀번호가 아닙니다. 재사용하면 비밀 키 정보가 노출될 수 있습니다. 얀의 컴퓨터가 서명 조각을 보낸 뒤 고장 났다면, 예전 상태를 복원할 때 이미 사용한 nonce를 새 값으로 취급해서는 안 됩니다. 지급이 완료되지 않았다고 재사용할 수 있는 것도 아닙니다. 안전한 구현에는 충분한 무작위성, 동시 시도의 분리, 소모된 값을 확실히 폐기하는 처리가 필요합니다. 이것이 임의의 스크립트를 모아 FROST를 직접 조립하지 말아야 하는 이유 중 하나입니다. 수학이 정확해도 비밀 데이터를 잘못 다루면 보호할 수 없습니다. [1]

조정자는 메시지를 정리하지만 그 역할만으로 단체를 대신해 서명할 수는 없습니다. 선정된 조각 보유자의 기여가 필요합니다. 다만 통신을 지연시키거나 세션을 중단시킬 수 있고, 참여자의 잘못된 기여로도 실패할 수 있습니다. 검사를 통해 유효하지 않은 서명 조각을 찾을 수 있지만, 특정인에게 원인을 돌리려면 메시지 출처를 신뢰할 수 있어야 합니다. 문제를 발견했다고 완료가 보장되지는 않습니다. 새 시도에는 참여 가능한 정당한 그룹과 새로운 nonce가 필요합니다. 따라서 단체에는 시작 화면의 임계값 숫자뿐 아니라 장애와 의견 충돌에 대응할 계획도 있어야 합니다. [1] [2]

에바가 기기를 잃어버렸을 때 FROST라는 이름만으로 자금이 복구되지는 않습니다. 백업은 에바의 조각, 식별자, 필요한 그룹 정보와 함께 호환 프로그램에서 이를 불러올 방법을 보존해야 합니다. 이것이 곧 일반적인 Seed Phrase, 즉 단어로 된 지갑 백업과 같다는 뜻은 아닙니다. 다른 참여자의 도움으로 조각을 복구하거나 조각을 갱신하는 것은 해당 시스템이 별도로 지원해야 하는 절차입니다. 에바의 조각을 복사해도 같은 조각이므로 독립적인 표가 늘어나지 않습니다. 같은 그룹 키를 유지한 채 갱신해도 이전에 도난당한 충분한 수의 조각을 무력화하지는 못합니다. 실제 적립금을 사용하기 전에는 한 번의 서명 성공뿐 아니라 복구, 장애 대응, 정확한 소프트웨어 버전까지 시험해야 합니다. [2] [3]