작성자: benma & Sebastian
출처: https://blog.bitbox.swiss/en/understanding-silent-payments-part-two/
이전 글에서는 정적 지불의 기술적 기초를 배웠습니다. 이제 하드웨어 서명기(예: BitBox)에서 정적 지불이 어떻게 작동하는지 자세히 살펴보겠습니다.
본 시리즈의 이전 글을 먼저 읽는 것을 강력히 추천합니다. 이전 글에서 다룬 개인키와 공개키의 특성 및 정적 지불의 작동 원리를 바탕으로 하고 있기 때문입니다. 이전 글과 마찬가지로, 본문에서는 개인키는 소문자로, 공개키는 대문자로 표기합니다. 예를 들어:A = a × G .
요약하자면, Alice가 Bob에게 정적 지불을 보낼 때, Bob에게 할당된 거래 출력은 Bob의 정적 지불 주소와 Alice의 개인키에서 동적으로 파생됩니다:
P = B_spend + hash(input_hash × S) × G
여기서 S는 Alice와 Bob의 공유 비밀 값입니다. Alice의 하드웨어 서명기는 자신의 개인키 a와 Bob의 공개키 B_scan을 사용하여 이를 계산할 수 있습니다:
S = a x B_scan
여기서 Alice가 사용하는 B_spend와 B_scan은 모두 Bob의 정적 지불 주소에서 얻어지며, a는 해당 거래의 모든 입력의 개인키 합입니다.
거래 생성 및 서명
먼저 이해해야 할 것은 정적 지불이 하드웨어 서명기의 비트코인(BTC) 거래 처리 역할을 크게 변화시킨다는 점입니다.
이전 지불 방식에서는 호스트 지갑(컴퓨터나 휴대폰의 소프트웨어, 예: BitBoxApp)이 거래를 생성하고, 하드웨어 서명기(예: BitBox02)는 단순히 이를 검증하고 서명(허가)했습니다.
그러나 정적 지불에서는 상황이 다릅니다. 하드웨어 서명기는 서명뿐만 아니라 거래의 일부, 특히 Bob에 대한 거래 출력을 생성해야 합니다. 이는 Bob에 대한 거래 출력 생성에 Alice의 개인키가 필요하며, 이를 알고 있는 것은 오직 그녀의 하드웨어 서명기뿐이기 때문입니다.
이러한 패러다임 전환은 몇 가지 새로운 리스크를 가져옵니다:
- 메모리 손상: 하드웨어 서명기에 버그가 있거나 메모리 오류가 발생하면 잘못된 출력을 파생시켜 자금을 사용할 수 없는 주소로 보내 실제로 돈을 잃을 수 있습니다.
- 악의적 행위: 하드웨어 서명기가 손상된 경우, 호스트 지갑이 모르는 사이에 공격자(Bob 대신)에게 직접 출력을 생성할 수 있습니다.
이 문제는 호스트 지갑이 하드웨어 서명기가 생성한 정적 지불 출력의 정확성을 검증하도록 함으로써 우아하게 해결될 수 있습니다. 이는 개념적으로 "anti-klepto"와 유사합니다 - 하드웨어 서명기가 부적절한 행동을 하지 않도록 호스트 지갑이 검증하는 또 다른 사례입니다.
(이하 생략)- 만약 다시 계산된 정적 지불 출력이 하드웨어 서명기가 반환한 출력과 일치한다면, 호스트 지갑은 안전하게 최종 처리하고 거래를 브로드캐스트할 수 있습니다. 왜냐하면 정적 지불 출력이 올바르고 변조되지 않았음을 알기 때문입니다.
흐름 요약
- 앨리스의 하드웨어 서명기는 정적 지불 출력을 생성하고, DLEQ 증거를 사용하여 올바른 개인 키를 사용했음을 증명합니다.
- 호스트 지갑은 증거를 검증하여 공유 비밀 값이 올바르게 계산되었음을 보장합니다.
- 호스트 지갑은 공유 비밀 값과 거래의 알려진 출력을 사용하여 정적 지불 출력을 다시 계산하고 검증합니다. 모든 검사를 통과하면 거래를 확정합니다.
이 방법은 하드웨어 서명기가 하드웨어 손상이나 악의적인 활동으로 인해 부정한 행위를 할 수 없음을 나타냅니다.
출시
정적 지불의 보안성을 보장하는 특성과 본문에서 설명한 정확성 검사는 BitBoxApp의 다음 버전 4.45와 BitBox 펌웨어 버전 9.21에서 출시될 예정입니다.
BitBox02는 정적 지불 전송을 지원하는 최초의 하드웨어 서명기입니다. 광범위한 생태계가 정적 지불 전송을 지원하지 않는다면, 다른 지갑 소프트웨어, 거래소, 서비스 제공업체 등을 설득하여 정적 지불 지원을 추가하는 것은 어려울 것입니다. 이는 닭이 먼저냐 달걀이 먼저냐의 문제입니다. 우리는 이러한 방식으로 정적 지불의 채택을 돕고 싶습니다.
오픈소스 협업에 대한 감사
우리가 처음으로 정적 지불에 대해 들은 것은 2023년 BTC Azores 언컨퍼런스에서, BIP 작성자 josibake와 Ruben Somsen의 발표였습니다. 이 BIP 자체는 매우 많은 고품질 리뷰를 받았습니다.
BitBox02에서의 구현을 초안 작성하기 시작했을 때, 나는 앞서 언급한 리스크에 대해 생각하기 시작했고 트윗을 작성하여 내 우려 사항을 나열했습니다. Josie, Ruben, Andrew Toth는 DLEQ 증거가 가능한 해결책임을 친절하게 지적하고 이 주제에 대한 매우 유용한 읽을거리를 제공했습니다. 유일하게 누락된 퍼즐 조각은 고품질의 검토된 DLEQ 구현이었습니다.
Andrew Toth가 DLEQ를 자세히 설명하는 BIP 초안을 작성하기 시작했을 때, 암호학자 Tim Ruffing는 secp256k1-zkp 코드 라이브러리에 이미 구현이 있음을 상기시켰고, 그때 BitBox02는 이미 해당 코드 라이브러리에 의존하고 있었습니다. 그것은 jesseposner가 다른 사용 사례를 위해 제공한 것이었지만, 다행히도 이 구현이 정적 지불에도 매우 적합한 것으로 입증되었습니다.
BIP의 테스트 인터페이스, 위의 DLEQ 구현, 그리고 유용한 참조 구현의 도움으로(하드웨어 서명기에는 다른 요구 사항이 있어 직접 사용할 수는 없었지만), 우리는 BitBox에 정적 지불 지원을 원활하게 통합할 수 있었습니다.
이렇게 많은 사람들이 자발적으로 자신의 시간과 노력을 기여하고 개방된 환경에서 무언가를 만들어 결국 모래를 쌓아 산을 이루는 것은 항상 새롭고 흥분되는 일입니다.
Josie, Ruben, Andrew, 그리고 이 기능을 완성하는 데 도움을 준 많은 다른 분들께 진심으로 감사드립니다.
