스텔스 주소 (Stealth Address)에 대하여
원문은 2023년 1월 20일에 게시되었습니다.
이 글의 검토와 피드백을 맡아주신 Ben DiFrancesco, Matt Solomon, Toni Wahrstätter, 그리고 Antonio Sanso께 감사드립니다.
이더리움 생태계에 남아있는 가장 큰 문제 중 하나는 바로 ‘프라이버시’입니다. 기본적으로 퍼블릭 블록체인에 올라가는 모든 것들은 모두에게 공개됩니다. 이는 돈의 움직임이나 금융 트랜잭션에만 해당하는 것이 아니고, 날이 갈수록 ENS 이름, POAP, NFT, 귀속 토큰 (SBT;Soulbound tokens) 등 더 다양한 유형의 데이터의 문제가 되고 있습니다. 실제로 이더리움 생태계 내의 어플리케이션을 두루두루 섭렵하려면 당신의 삶의 상당한 부분을 누구나 볼 수 있고 분석할 수 있도록 공개할 수밖에 없습니다.
이러한 문제를 개선하는 것은 아주 중대한 사안이라고 여겨지며, 또 많은 이들이 이를 인지하고 있습니다. 그러나 프라이버시에 관한 담론은 현재 주로 ETH나 주요 ERC20 토큰들의 이동 (혹은 자기 자신에게로 이체하는 ) 데이터의 프라이버시 유지로 집중되어 있습니다. 이 글은 여러 상황에서 이더리움의 현 프라이버시 문제를 개선할 수 있는 또다른 도구, “스텔스 주소(Stealth Addresses)” 의 사용 사례와 작동 방식 등에 대해서 설명하고자 합니다.
스텔스 주소란 무엇인가
Alice가 Bob에게 자산을 보내려고 한다고 가정해봅시다. 여기서 보내는 자산은 암호화폐(예를 들어 1ETH, 500 RAI)일 수도, NFT일 수도 있습니다. Bob은 Alice로부터 자산을 받았을 때 그 사실을 전세계 사람들에게 알리고 싶지 않습니다. 자산의 이동이 발생했다는 것을 숨기는 것은 불가능한 일입니다. 특히 온체인 사본이 하나밖에 없는 NFT의 경우 수신자가 누구인지 숨기는 것이 훨씬 더 쉬운 길일 수 있습니다.
또, Alice와 Bob은 게으릅니다. 이들은 결제 플로우가 우리가 현재 사용하는 것과 동일한 시스템이길 바랍니다. Bob은 Alice에게 (혹은 ENS에 등록하여) 그에게 돈을 보내는 방법을 암호화(encoding)한 주소를 보내고, Alice(혹은 그 외 어느 누구라도)는 그 정보만 알고 있으면 그에게 자산을 보낼 수 있기를 원합니다.
여기서 의미하는 프라이버시가 토네이도 캐시와 같은 곳에서 말하는 프라이버시와는 다른 종류임을 기억해주시길 바랍니다. 토네이도 캐시는 ETH나 주요 ERC20 토큰들과 같은 대체 가능한 토큰들의 이동을 숨길 수 있는 어플리케이션으로 (물론 스스로에게 보내는 것으로 사용하는 사람들이 많지만), 희귀한 ERC20 토큰들의 이동을 숨기는 것은 잘 해내지 못하며 NFT의 이동은 전혀 숨기지 못합니다.
스텔스 주소는 이러한 체계를 제공할 수 있습니다. 스텔스 주소는 Alice나 Bob이 생성할 수 있지만 오직 Bob만이 제어할 수 있는 주소입니다. Bob은 지출 키(spending key)를 생성하고 이를 혼자만 간직합니다. 이 키를 사용하여 스텔스 메타 주소(Stealth Meta-Address)를 생성, 이 메타 주소를 Alice에게 직접 전달하거나 ENS에 등록합니다.
Alice는 이 메타 주소에 대한 연산을 수행하여 Bob에게 속하는 스텔스 주소를 생성할 수 있습니다. 그러면 Alice는 이 주소로 자신이 보내고자 하는 자산을 보낼 수 있게 되며, Bob은 자산을 받은 뒤 제어하고 지출할 수 있게 됩니다. 자산의 전송과 함께 Alice는 Bob이 이 주소가 자신에게 속한 주소임을 쉽게 파악할 수 있도록 몇 가지 추가적인 암호화 데이터 (임시 pubkey; ephemeral pubkey)를 온체인에 게시합니다.
이렇게 설명할 수도 있을 것 같습니다. 스텔스 주소는 Bob이 트랜잭션을 날릴 때마다 새로운 주소를 생성하는 것과 같은 프라이버시를 제공할 수 있으며, Bob은 이를 위해 그 어떤 인터랙션을 하지 않아도 됩니다.
스텔스 주소 체계의 전체 플로우는 다음과 같이 볼 수 있습니다.
- Bob은 루트 지출키 (
m)과 스텔스 메타 주소 (M)을 생성합니다. - Bob은
bob.eth에 대한 스텔스 메타 주소로M을 등록하기 위해 ENS 기록을 추가합니다. - Alice는 Bob의 ENS 주소가
bob.eth임을 이미 알고 있습니다. Alice는 Bob의 스텔스 메타 주소M을 ENS에서 찾아봅니다. - Alice는 그녀만 아는 임시 키 를 생성합니다. 이 키는 딱 한번만 사용하게 될 것이며, 특정 스텔스 주소를 생성하기 위해 사용될 것입니다.
- Alice는 어떤 알고리즘을 통해 그녀가 생성한 일시적 키와 Bob의 메타 주소를 합쳐 스텔스 주소를 만듭니다. 이제 Alice는 그 주소로 자산을 보낼 수 있게 됩니다.
- Alice는 그녀의 임시 pubkey를 생성하고, 이를 임시 pubkey 레지스트리에 게시합니다. (이는 스텔스 주소에 자산을 보내는 트랜잭션에서 함께 처리될 수 있습니다.)
- Bob이 스텔스 주소가 자신에게 속하는 주소라는 것을 알기 위해선, 모든 사람의 임시 pubkey를 갖고 있는 레지스트리를 스캔해야만 합니다. (그가 마지막으로 스캔한 이후 게시된 임시 pubkey의 전체 리스트를 의미합니다.)
- Bob은 각각의 임시 pubkey를 갖다가 자신의 루트 지출 키와 결합하여 스텔스 주소를 생성하려는 시도를 합니다. 그리고 그 주소 안에 자산이 있는지를 확인합니다. 만약 있다면, 그 주소에 대해 지출 키를 연산하고 이를 기억해둡니다.
이 모든 것은 두 종류의 암호학 속임수를 사용하는 것입니다. 먼저, 공유 비밀을 만들기 위한 한 쌍의 알고리즘이 필요합니다. 하나는 Alice의 비밀(임시 키)과 Bob의 공개 정보(메타 주소)을 사용하는 알고리즘이고, 다른 하나는 Bob의 비밀(루트 지출 키)와 Alice의 공개 정보 (임시 pubkey)를 사용하는 것입니다. 이는 여러 가지 방법으로 수행할 수 있는데, Diffie-Hellman 키 교환은 현대 암호학 분야의 기반이 된 알고리즘 중 하나였으며 정확히 방금 설명한 것을 수행하기 위한 프로토콜입니다.
그러나 공유 비밀만으로는 충분하지 않습니다. 공유 비밀로부터 프라이빗 키를 생성하면 Alice와 Bob 모두 이 주소에서 지출을 할 수 있게 됩니다. Bob에게 다른 주소로 자산을 옮기게 하는 방식으로 이대로 내버려둘 수도 있겠지만, 이는 비효율적이며 불필요한 보안성 문제입니다. 따라서 여기에 한 쌍의 알고리즘인 키 블라인드 메커니즘(key blinding mechanism)을 추가해볼까 합니다. Bob은 공유 비밀을 자신의 루트 지출 키와 결합할 수 있고, Alice은 공유 비밀을 Bob의 메타주소와 결합하여 스텔스 주소를 생성할 수 있습니다. Bob은 그 스텔스 주소를 위한 지출 키를 생성할 수 있으며, 이 과정에선 스텔스 주소와 Bob의 메타 주소 (혹은 어느 스텔스 주소와 다른 스텔스 주소) 간의 공개된 연관성은 만들어지지 않습니다.
타원 곡선 암호화를 이용한 스텔스 주소
타원 곡선 암호학을 이용한 스텔스주소는 2014년 Peter Todd에 의해 비트코인의 맥락에서 이미 소개된 바 있습니다. 이 기술은 다음과 같이 작동합니다. (기본적인 타원곡선 암호학에 대한 사전 지식이 있다는 것을 가정합니다. 튜토리얼을 위해선 이 글, 이 글, 그리고 이 글을 참조하시길 바랍니다.)
- Bob은 키
m을 생성,M = G * m을 계산합니다. 여기서G는 타원곡선에 대해 합의된 생성자 점입니다. 스텔스 메타 주소는M을 인코딩한 것입니다. - Alice 는 임시 키
r을 생성, 임시 퍼블릭키R = G * r을 게시합니다. - Alice는 공유 비밀
S = M * r을 연산할 수 있으며, Bob 또한 같은 공유 비밀S = m * R을 연산할 수 있습니다. - 전반적으로, 비트코인과 이더리움 모두에서(올바르게 설계된 ERC-4337 포함), “주소”는 그 주소로부터 발생하는 트랜잭션을 검증하는 데 사용되는 퍼블릭키를 포함한 해시를 의미합니다. 그러므로 퍼블릭 키를 연산할 수 있다면 주소 또한 연산할 수 있습니다. 퍼블릭 키를 연산하려면 Alice나 Bob이
P = M + G * hash(S)을 연산하면 됩니다. - 그 주소에 대한 프라이빗 키를 연산하기 위해선, Bob 은
p = m + hash(S)을 연산하면 됩니다.
이 방법은 우리가 앞서 언급한 조건들을 모두 충족할 수 있으며 아주 간단한 방법입니다!
이더리움의 스텔스 주소 표준을 정의하기 위한 EIP도 존재하는데, 이 방식을 지지함과 동시에 다른 접근법 또한 다른 유저들이 발전시킬 수 있도록 대화의 창을 열어주고 있습니다. (예를 들어 Bob이 서로 다른 지출 키와 뷰잉 키를 갖고 있는다든지, 혹은 양자 저항성을 위해 다른 암호학 기술을 사용한다든지 등의 접근법이 있을 수 있겠습니다.) 여기까지만 들으면 스텔스 주소는 어려운 것이 아니며, 이론적으로 이미 토대가 탄탄하며, 이것을 도입시키는 것은 단순히 구현 문제에 지나지 않는다고 생각하실지도 모르겠습니다. 하지만 문제는 사실 ‘구현’이 진정으로 효과적으로 실현되려면 꼭 해결해야 할 큰 구현 문제들이 남아있습니다.
스텔스 주소와 Tx 수수료 지불
누군가 당신에게 NFT를 보낸다고 가정해봅시다. 당신의 프라이버시를 보호해주기 위해 그 사람은 당신이 제어할 수 있는 스텔스 주소로 이를 보냅니다. 당신의 지갑은 온체인 임시 pubkey를 스캔해본 뒤 해당 주소를 알아냅니다. 이제 이 NFT의 소유권을 자유롭게 증명하고 다른 누군가에게 보낼 수도 있게 됩니다. 하지만 여기에는 문제가 있습니다! 이 계정에는 0 ETH이 있기 때문에, 트랜잭션 수수료를 지불할 수가 없는 것입니다. ERC-4337 토큰 페이마스터조차도 대체 가능한 ERC20 토큰만을 다루기 때문에 이 문제를 해결할 수 없습니다. 당신의 메인 지갑에서 돈을 보낼 수도 없습니다. 왜냐하면 공개적으로 계정 간의 관계성을 알리고 싶지 않기 때문입니다.
이 문제를 해결하는 “쉬운” 길이 하나 있습니다. ZK-SNARK를 사용하여 자금을 이체하고 수수료를 지불하는 것입니다! 그러나 이 방식은 단 한번의 거래를 위해 아주 많은 가스, 수십만 개의 가스를 추가적으로 소모합니다.
또 다른 영리한 접근 방식은 (MEV 쪽에선 “searcher”라고 부르는) 전문화된 트랜잭션 애그리게이터(aggregator)를 신뢰하는 것입니다. 이러한 애그리게이터는 사용자가 딱 한번의 지불로 온체인 거래 수수료 지불에 사용할 수 있는 “티켓” 세트를 구매할 수 있도록 합니다. 유저가 다른 자산은 하나도 갖고 있지 않는 스텔스 주소에서 NFT를 지출하려면, 애그리게이터에게 이 티켓 하나를 제공합니다. (이 때 Chaumian 블라인딩 스킴을 사용해 이를 암호화 합니다.) 이것은 1980~1990년대에 제안된 프라이버시 보호를 위한 중앙화 e-캐시 체계에 사용된 프로토콜입니다. Searcher는 이 티켓을 받고, 그 트랜잭션이 블록에 성공적으로 담길 때까지 자신의 번들에 무료로 계속해서 포함시켜줍니다. 여기에 필요한 자금의 규모가 적고, 그 자금이 트랜잭션 수수료 지불에만 사용될 수 있다는 점에서 중앙화 프라이버시 보호 e-캐시 체계를 온전히 구현하는 것보다 훨씬 신뢰나 규제 문제가 완화될 수 있다는 장점이 있습니다.
스텔스 주소와 지출 키, 뷰잉 키를 분리하기
Bob이 모든 작업을 수행할 수 있는 마스터 “루트 지출 키”를 갖는 대신, Bob이 서로 다른 루트 지출 키와 뷰잉 키를 갖고 싶어한다고 가정해봅시다. 뷰잉 키는 Bob의 모든 스텔스 주소를 볼 수는 있지만 지출할 수는 없습니다.
타원 곡선 세계에서 이는 매우 간단한 암호화 트릭을 사용하여 해결할 수 있습니다.
- Bob의 메타 주소
M은 이제(K, V)형식이며G * k및G * v를 인코딩합니다. 여기서k는 지출 키이고v는 뷰잉 키입니다. - 이제 공유 비밀은
S = V * r = v * R입니다. 여기서r은 여전히 Alice의 임시 키이고R은 Alice가 게시하는 임시 퍼블릭 키입니다. - 스텔스 주소의 퍼블릭 키는
P = K + G * hash(S)이고 프라이빗 키는p = k + hash(S)입니다.
첫번째 암호화 단계(공유 비밀 생성)은 뷰잉 키를 사용하고, 두번째 암호화 단계(스텔스 주소와 프라이빗 키를 생성하는 Alice와 Bob의 병렬 알고리즘)는 루트 지출 키를 사용한다는 것을 봐두시면 좋을 것 같습니다.
많은 사용 사례가 있을 것입니다. 예를 들어 Bob이 POAP를 받으려는 경우, Bob은 자신의 POAP 지갑(또는 그다지 보안성이 높지 않은 웹 인터페이스)에 뷰잉 키를 제공하여 체인을 스캔하고 모든 POAP를 볼 수 있습니다. 이 인터페이스가 POAP를 지출할 수 있는 리스크는 지지 않고 말입니다.
스텔스 주소와 더 쉬운 스캐닝 방법
임시 퍼블릭 키의 전체 셋을 스캔하는 게 쉬워지려면, 각 임시 퍼블릭 키에 뷰 태그(view tag)를 달아주는 방법이 있습니다. 위에 설명한 메커니즘에 이를 적용하려면 공유 비밀의 1byte로 뷰태그를 만들어주는 방식이 있습니다. (예를 들어 S 모듈로 256의 x 좌표, 혹은 hash(S) 의 첫번째 바이트)
이 방법을 통해 Bob은 각 임시 퍼블릭키에 대해 단일 타원 곡선 곱셈만 수행해도 공유 비밀을 연산할 수 있으며, 전체 주소를 생성하고 체크하려면 필요했던 시간에 비해 1/256의 시간만 들이고도 이를 해낼 수 있습니다.
스텔스 주소와 양자 내성 보안
위의 체계는 타원 곡선을 따르는 것으로, 타원 곡선은 물론 훌륭하지만 양자 컴퓨터에 취약하다는 단점을 갖고 있습니다. 양자 컴퓨터가 문제가 될 시점이면 우리 모두 양자 내성이 높은 알고리즘으로 바꿔야 할 수도 있습니다. 타원 곡선 아이소제니 격자가 그에 해당하는 후보일 것입니다.
타원 곡선 아이소제니는 타원 곡선을 기반으로 하는 매우 다른 수학적 프로토콜로, 위에서 본 것과 유사한 암호화 트릭을 수행할 수 있는 선형성 속성을 갖지만, 동시에 양자 컴퓨터의 이산 로그 공격에 취약할 수 있는 순환 그룹이 구성되는 것을 방지할 수 있습니다.
아이소제니 기반 암호학의 주요 약점은 매우 복잡한 기본 수학과 이러한 복잡성 때문에 잠재적으로 발생할 수 있는 공격이 가려질 위험이 있다는 것입니다. 일부 아이소제니 기반 프로토콜이 작년에 깨어진 바 있지만, 나머지는 여전히 안전하게 남아있긴 합니다. 아이소제니의 주요 강점은 상대적으로 작은 키의 크기와, 여러 종류의 타원 곡선 기반 접근 법을 직접 포트할 수 있는 능력입니다.
격자는 타원 곡선 아이소제니보다 훨씬 더 간단한 수학에 의존하는 (매우 다른) 암호화 구조이며 몇몇 강력한 능력(예: 완전 동형 암호화)을 갖고 있습니다. 스텔스 주소 체계는 격자를 기반으로 구축될 수 있지만 무엇이 최상의 설계일지는 여전히 논의가 많이 필요합니다. 그러나 격자 기반 구조는 훨씬 더 큰 키 크기를 갖는 경향이 있습니다.
세 번째 접근 방식은 일반 블랙박스 프리미티브(다른 이유로 많은 사람들이 필요로 하는 기본 요소)에서 스텔스 주소 체계를 구성하는 것입니다. 공유 비밀 생성 부분이 퍼블릭 키 암호화 시스템의 중요한 구성 요소인 키 교환에 직접 매핑되는 것입니다. 더 어려운 부분은 Alice가 지출 키는 제외, 스텔스 주소만 생성하고 Bob이 지출 키를 생성하도록 하는 병렬 알고리즘 부분입니다.
안타깝게도 퍼블릭 키 암호화 시스템을 구축하는 데 필요한 것보다 더 간단하게 스텔스 주소를 구축할 수는 없습니다. 이에 대한 간단한 증거도 있습니다. 스텔스 주소 체계로부터 퍼블릭 키 암호화 시스템을 구축할 수 있다는 것입니다. Alice가 Bob에게 메시지를 암호화하려는 경우, Alice는 N개의 트랜잭션을 보낼 수 있으며 각 트랜잭션은 Bob의 스텔스 주소 혹은 그녀의 스텔스 주소로 보내질 것이며, Bob은 메시지를 읽기 위해 그가 받은 트랜잭션이 무엇인지를 볼 수 있습니다. 이는 해시만으로는 퍼블릭 키 암호화를 수행할 수 없지만, 해시만으로도 영지식 증명을 수행할 수 있다는 수학적 증거가 있음을 의미하므로 중요한 사실입니다. 따라서 해시만으로는 스텔스 주소 체계를 구축할 수 없습니다.
상대적으로 간단한 요소를 사용하는 접근 방식도 있습니다. 해시로 만들 수 있는 영지식 증명과 (키 숨김) 퍼블릭 키 암호화 방식입니다. 여기서 Bob의 메타 주소는 퍼블릭 암호화 키에 해시 h = hash(x)를 더한 것이고, 그의 지출 키는 해당 복호화 키에 x를 더한 것입니다. 스텔스 주소를 생성하기 위해 Alice는 값 c를 생성하고, Bob이 읽을 수 있는 c의 암호화(encryption)를 임시 퍼블릭 키로 게시합니다. 이 주소는 그 자체로 ERC-4337 계정으로, 트랜잭션들이 값 x와 c 의 소유권을 증명하는 영지식 증거와 함께 오도록 요구함으로써 계정의 코드 자체로 트랜잭션을 검증할 수 있는 계정입니다 (k = hash(hash(x), c) . 여기서 k 는 계정 코드의 일부) x와 c 를 알면 Bob은 이 주소를 재구성하고 직접 코드할 수 있게 됩니다.
c 의 암호화는 Bob 이외의 어느 누구에게도 정보를 누설하지 않으며, k 는 해시이므로 c 에 대해 거의 아무 것도 드러내지 않습니다. 지갑의 코드에는 k 만 포함되며, c 가 프라이빗하게 남는다는 것은 k 를 h 로 역추적할 수 없음을 의미합니다.
그러나 이를 위해선 STARK가 필요하고, STARK는 거대한 영역입니다. 저는 양자 이후 이더리움 세계에는 STARK를 사용하는 많은 응용 프로그램이 등장할 가능성이 높다고 생각합니다. 그러므로 공간을 줄이기 위해 STARK를 단일 재귀 STARK로 합칠 수 있는, 여기에 설명된 것과 같은 애그리게이션 프로토콜들을 지지합니다.
스텔스 주소와 소셜 계정 복구, 그리고 멀티-L2 지갑들
저는 오랫동안 소셜 복구 지갑 (social recovery wallets)을 좋아해왔습니다. 기관들, 장치들, 혹은 친구들 간에 서로 키를 공유하여 멀티 시그 메커니즘으로 사용할 수 있는 지갑들을 의미합니다. 이 멀티 시그에 포함된 키의 다수 % 이상이 찬성하면 프라이머리 키를 잃어버린 당신이 다시 계정을 복구할 수 있는 지갑 말입니다.
그러나 소셜 복구 지갑과 스텔스 주소를 붙이기가 여간 까다로운 것이 아닙니다. 계정을 복구해야 하는 경우(즉, 계정을 제어하는 프라이빗 키 변경), N 스텔스 지갑들의 계정 검증 로직을 변경하기 위한 몇 가지 단계를 밟아야 합니다. 이것은 N 개의 트랜잭션을 요구할 것이며, 그에 따라 수수료, 편의성 및 개인 정보 보호 등에 높은 비용이 발생할 것입니다.
소셜 복구와 수많은 L2 프로토콜이 존재하는 세계의 상호 작용에서도 비슷한 문제가 발생합니다. 만약 만약 Optimism, Arbitrum, Starknet, Scroll, Polygon 에 계정을 갖고 있다고 가정해봅시다. 이러한 롤업 중 몇몇은 아마 확장성을 위해 여러 병렬 인스턴스를 갖고 있을 것이며, 당신이 그러한 프로토콜에 각기 계정을 갖고 있다면, 키를 변경하는 것은 아주아주 복잡한 과정이 될 수 있습니다.
한 가지 방법은 그냥 이 어려움을 인정하는 것으로, 소셜 복구가 자주 발생하는 일이 아니며 그러므로 복잡하고 비용이 많이 들어도 괜찮다고 결론짓는 것입니다. 시간 기반 연결의 효율성을 줄이기 위해 자동화된 소프트웨어가 2주 동안 주기적으로 새로운 스텔스 주소로 자산을 전송하도록 하는 방법도 있습니다. 이것은 아주 불완전한 방식입니다. 또 다른 방법은 스마트 컨트랙트 복구를 사용하기보다 가디언(계정 복구에 대한 권한을 갖는 사람들) 간에 루트 키를 비밀 공유하는 것입니다. 그러나 이것은 당신의 계정을 복구할 수 있는 가디언의 권한을 비활성화하는 기능을 없애는 것으로, 장기적으로는 위험한 선택이라고 볼 수 있습니다.
보다 정교한 방식은 영지식 증명을 사용하는 것입니다. 위의 ZKP 기반 방식을 고려하되, 로직을 다음과 같이 수정합니다. k = hash(hash(x), c)를 직접 보유하는 대신, 계정은 체인에서 k의 위치에 대한 (숨겨진) 커밋먼트를 갖게 됩니다. 그런 다음 해당 계정에서 무엇인가를 지출하려면 (i) 해당 커밋과 일치하는 위치를 알고 있으며, (ii) 해당 위치의 개체에 당신이 공개하지 않는 값 k가 포함되어 있다는 영지식 증명을 제공해야 합니다. 또 k = hash(hash(x), c)를 만족하는 값 x 와 c 를 갖고 있음을 증명해야 합니다.
이렇게 하면 (여러 L2 프로토콜에 걸쳐 있더라도) 여러 계정을 하나의 값 k (베이스 체인이나 L2에 있는 값일 것입니다.)으로 제어할 수 있게 되며, 이 값 하나를 변경하면 당신의 계정 전체의 소유권을 변경할 수 있게 됩니다. 각 계정 간의 연관성을 노출하지 않고도 말입니다.
결론
간단한 스텔스 주소는 지금도 상당히 빠르게 구현할 수 있으며 실제로 이더리움 유저들의 프라이버시 문제를 크게 개선할 수 있습니다. 물론 이를 지원하기 위해선 지갑 쪽에서도 작업이 필요합니다. 저는 다른 프라이버시 관련 문제들을 고려해봤을 때도 결국 지갑이 다중 주소 모델 (multi-address model)로 나아가야 한다고 생각합니다. (예를 들어, 당신이 상호작용하는 각각의 어플리케이션을 위해 새로운 주소를 만드는 것 또한 옵션일 수 있습니다.)
그러나 스텔스 주소에는 아직 소셜 복구의 어려움과 같은 장기적인 사용성 문제가 남아있습니다. 어쩌면 현재로서는 그저 이러한 문제들을 인정하고 받아들이는 것이 좋을지 모릅니다. 예를 들어 소셜 복구가 프라이버시의 위험이나 (제 3자가 제공하는) 다양한 자산으로 복구 트랜잭션을 천천히 릴리즈하기 위한 2주 지연 등을 어쩔 수 없이 수반할 수밖에 없다는 것을 인정하는 것입니다. 아주아주 장기적인 관점에서 이런 문제들이 언젠가는 해결될 수도 있겠으나, 현재 중장기적인 관점에서는 영지식 증명을 사용하는 방식으로 크게 나아가게 될 것 같습니다.
