이 글은 비트코인 분야의 독학 교육자이자 기술 중심의 비트코인 팟캐스트 호스트인 신오비의 의견 기고문입니다.
이 글을 읽기 전에 제가 작성한 이전 기사를 읽어보시기를 권장합니다. 그 기사에서는 Nostr가 무엇인지와 어떻게 작동하는지를 높은 수준에서 설명했습니다. 그 시점에서 시스템의 핵심 설계에 대한 좋은 아이디어를 갖게 될 것이므로, 이제 채택이 증가함에 따라 발생할 가능성이 있는 문제들을 살펴보겠습니다. 이 플랫폼이 비트코인 커뮤니티에서 인기 있는 플랫폼이 되면서, 이러한 문제들은 인지해야 할 사항입니다.
이전 기사에서 논의한 바와 같이, 사용자 공개/비공개 키 쌍은 Nostr가 프로토콜로서 작동하는 데 필수적입니다. 사용자 이름이나 개별 사용자와 연결될 수 있는 어떤 식별자도 중계 서버가 제어하지 않습니다. 단순히 사용자의 키만이 완전히 그들의 통제 하에 있습니다.
이는 실제 사용자와 그들이 다른 사람들에 의해 어떻게 식별되는지를 긴밀하게 결합하여 중계 서버가 이 두 가지를 분리할 수 없도록 합니다. 즉, 누군가의 식별자를 다른 사용자에게 제공하는 것을 방지합니다. 이는 사람들 간의 통신을 위한 플랫폼에서 가장 큰 근본적인 문제 중 하나인 사용자 자신의 신원에 대한 통제 부족을 해결합니다. 그러나 이는 비공개 키를 소유한 사람이 직면하는 모든 키 관리 문제를 도입합니다. 키는 분실될 수 있고, 키는 손상될 수 있으며, 그런 사건이 발생하면 사용자는 도움을 요청할 사람이 없습니다. 비트코인과 마찬가지로 고객 지원이 없어 복구할 수 없습니다. 잃어버리면 그게 전부입니다.
이는 사용자들이 프로토콜을 통해 상호작용하는 다른 사용자들에게 검증 가능하고 발견 가능한 방식으로 한 키 쌍에서 다른 키 쌍으로 전환할 수 있는 계획을 필연적으로 필요로 하게 될 것입니다. 전체 프로토콜은 특정 사용자(신원 키)로부터 이벤트가 발생했음을 증명하는 데 기반하고 있으므로, 누군가의 키가 손상되면 모든 보장이 사라집니다.
그것을 어떻게 처리합니까? 그들의 트위터 계정을 확인하나요? 그렇다면, 결국 그들의 신원을 확인하기 위해 중앙 집중식 플랫폼을 사용해야 한다면, 이는 매우 분산된 시스템이 아닙니다.
다른 사용자가 새로운 키의 정당성을 증명하게 하시겠습니까? 이는 대량 키 손상과 같은 상황이나, 그들과 가까운 사람을 충분히 신뢰할 수 없는 경우를 해결하지 못합니다.
Nostr는 한 키의 회전을 다른 키에 연결하는 실제 암호화 계획이 필요합니다. 개발자 fiatjaf의 제안이 이 문제를 해결할 수 있는 기본 계획을 제시합니다. 기본 아이디어는 단일 마스터 시드에서 파생된 긴 주소 세트를 가져와 Taproot 트리가 비트코인 키에 커밋되는 방식과 유사하게 “조정된” 키 세트를 만드는 것입니다. Taproot는 Taproot 트리의 머클 트리 루트를 가져와 공개 키에 “추가”하여 새로운 공개 키를 생성합니다. 이는 해당 머클 트리 루트를 비공개 키에 추가하여 새로운 공개 키에 대한 일치하는 비공개 키를 얻는 방식으로 복제할 수 있습니다. fiatjaf의 아이디어는 각 조정된 키가 다음 조정된 키가 생성되었음을 증명하는 증거를 실제로 포함하도록 끝에서 시작으로 커밋을 연결하는 것입니다.
따라서, 체인의 마지막에 있는 키 Z로 시작한다고 상상해 보십시오. 당신은 이것을 무엇인가로 조정하고, 그 다음 뒤로 가서 조정된 Z 키를 사용하여 키 Y의 조정된 버전을 생성합니다(Z’ + Y = Y’). 여기서 Y’를 가져와서 그것을 사용하여 X를 조정합니다(Y’ + X = X’). 이렇게 하여 키 A까지 거슬러 올라가 A’를 얻고, 그 키를 사용하기 시작합니다. 그것이 손상되면 사용자는 조정되지 않은 키 A와 조정된 키 B’가 포함된 이벤트를 방송할 수 있습니다. 이는 B’가 A’ 생성에 사용되었음을 보여주는 데 필요한 모든 데이터를 포함할 것입니다. 사용자는 즉시 A’의 팔로우를 중단하고 대신 B’의 팔로우를 시작할 수 있습니다. 그들은 B’가 그 사용자의 다음 키라는 것을 확실히 알고 그것을 따라야 합니다.
그러나 이 제안에는 여전히 몇 가지 문제가 있습니다. 첫째, 사용하려는 모든 키를 미리 생성해야 하며, 전체 새로운 키 세트로 회전할 방법이 없습니다. 이는 이러한 회전을 공증할 수 있는 마스터 키에 커밋하거나, 처음부터 매우 큰 키 세트를 생성함으로써 해결할 수 있습니다. 두 경로 모두 유효한 선택이지만, 궁극적으로는 루트 키 또는 키 자료를 안전하게 유지하고 개별 핫키만 Nostr 클라이언트에 노출해야 합니다.
그러나 이 계획은 루트 키 자료가 분실되거나 손상된 경우 사용자 보호나 신원 복구 메커니즘을 제공하지 않습니다. 이제 fiatjaf의 계획에 이점이 없다는 것은 아닙니다. 분명히 이점이 있지만, 어떤 솔루션도 모든 문제를 해결하지는 않는다는 점을 강조하는 것이 중요합니다.
여기에서 잠재적 솔루션에 대해 약간 논의하자면, 그가 제안한 조정된 키의 체인 대신, 키가 이벤트를 한 키에서 다른 키로 회전하는 것을 서명하는 데 사용해야 하는 마스터 콜드 키로 조정된다고 상상해 보십시오. 키 A’는 A와 M(마스터 키)을 추가하여 파생되며, 회전 이벤트는 A, M 및 B’(B와 M을 추가하여 생성됨)로 M의 서명이 포함됩니다. M은 다중 서명 임계값 키일 수 있습니다 — 3개 중 2개, 5개 중 3개 등. 이는 손실에 대한 중복성을 추가할 수 있을 뿐만 아니라 키 회전을 위한 안전한 메커니즘을 제공할 수 있습니다. 이는 또한 복구를 돕기 위한 서비스를 사용하거나, 신뢰할 수 있는 친구들에게 일부 키를 분산시키는 길을 열어줍니다. 이는 비트코인 자체의 다중 서명과 동일한 유연성을 제공합니다.
NIP26 또한 이 문제를 처리하는 데 매우 유용할 수 있는 제안입니다. 이는 이벤트에 대한 프로토콜 확장을 지정하여 한 키의 서명이 다른 키가 그를 대신하여 이벤트를 게시하도록 승인할 수 있게 합니다. “토큰” 또는 위임의 서명 증명은 첫 번째 키를 대신하여 두 번째 공개 키가 게시한 모든 이벤트에 포함됩니다. 이는 위임 토큰이 자동으로 만료되고 갱신해야 하는 시간 제한을 설정할 수도 있습니다.
궁극적으로, 어떻게 해결되든, 이 문제는 Nostr의 장기적인 관점에서 반드시 해결되어야 합니다. 신원으로 사용되는 공개/비공개 키 쌍에 전적으로 기반한 프로토콜은 이러한 신원의 무결성을 보호하고 유지할 수 없다면 traction과 채택을 얻을 수 없습니다. 이는 결국 새로운 키를 확인하고 사람들이 새로운 신원을 따르도록 조정하기 위해 지속적으로 외부 및 중앙 집중식 플랫폼을 사용해야 하게 되며, 그 시점에서 다른 플랫폼은 혼란을 초래하고 검열에 관여하는 수단이 됩니다.
키 관리 및 보안 문제는 매우 큰 설계 공간과 많은 거래 및 문제점이 있는 큰 문제이지만, Nostr가 작동하기 위해서는 이러한 문제를 해결해야 합니다. 다음 기사에서는 Nostr 개발자들이 직면해야 할 중계 서버 아키텍처 및 확장성 문제에 대해 제가 보고 있는 몇 가지 문제를 요약할 것입니다.
읽고 계신 분들 중에서 제가 분산 식별자(DIDs)에 대해 언급하지 않은 이유를 궁금해 하시는 분들을 위해: 네, 이는 이러한 문제에 대한 잠재적 솔루션이며, 제 생각에는 매우 포괄적입니다. 그러나 Nostr 개발자들은 Nostr 프로토콜 외부의 의존성을 생성할 수 있다는 이유로 DIDs를 프로토콜이나 클라이언트에 통합하는 데 매우 주저하는 것 같습니다. DIDs가 기술적으로 어떻게 작동하는지 잘 모르시고 관심이 있으시다면, Level 39의 이 기사는 그들이 어떻게 작동하는지에 대한 잘 작성된 요약입니다.
이 글은 신오비의 게스트 포스트입니다. 표현된 의견은 전적으로 그들의 것이며 BTC Inc 또는 Bitcoin Magazine의 의견을 반드시 반영하지는 않습니다.
