출처: Denglian 커뮤니티
소개하다
Web3 암호화 사용자가 직면한 주요 문제점은 개인 정보 보호가 부족하다는 것입니다. 모든 거래는 공개 원장에 표시되며 명확하게 보이는 ENS 이름과 점점 더 연관되어 있습니다. 이로 인해 사용자가 특정 활동을 수행하려는 동기가 낮아지거나 사용자 경험에 마찰을 가하는 방식으로 이러한 활동을 수행하게 됩니다. 예를 들어 단순히 핫 지갑에서 콜드 지갑으로 또는 그 반대로 자금을 이체하는 경우가 있습니다. 사용자는 콜드 지갑 잔액 표시되는 것을 원하지 않을 수 있으므로 한 지갑이 다른 지갑에 연결되는 것을 원하지 않을 수 있습니다. 현재 이더 주소는 개인 은행 계좌처럼 작동하지 않습니다. 모든 사람이 귀하의 지갑을 볼 수 있고 점점 더 귀하의 소셜 활동(SBT, 증명, 다양한 dapp에서의 활동 등)이 표시될 것이기 때문입니다. 이 때문에 Vitalik은 이더 일반 사용자에게 유용하기 위해 거쳐야 하는 세 가지 주요 기술 변화 중 하나로 개인 정보 보호를 꼽습니다.
Tornado Cash와 같은 기존 개인 정보 보호 솔루션을 사용하면 여러 가지 이유로 경험이 이상적이지 않습니다. 첫째, 사용자는 자신의 주소가 중앙화 거래소 나 기타 플랫폼에서 블랙리스트에 오르는 것에 대해 합법적으로 걱정할 것입니다. 둘째, Tornado Cash와 같은 서비스와 상호 작용하는 사용자 경험은 사용자 친화적이지 않으며 실제로 고도로 숙련된 사용자에게만 적합합니다.
스텔스 주소는 개인 은행 계좌에서 당연하게 여기는 것과 유사한 수준의 개인 정보 보호를 사용자에게 제공하지만 이해하기 쉬운 방식으로 제공합니다. 또한 스텔스 주소에 대한 혁신은 여러 관할권의 자금세탁 방지 규정을 준수하는 방식으로 이를 수행할 수 있음을 의미합니다.
개인 정보 보호에 대한 사용자 요구 사항
개인 정보 보호에 대한 웹 및 Web3 사용자의 태도에 대한 연구는 광범위하지 않지만 웹 검색을 통해 거래 개인 정보 보호에 대한 명확한 필요성을 나타내는 광범위하고 일관된 결과를 나타내는 다음 연구를 발견했습니다.
Simin Ghesmati 등이 2022년 블록체인의 사용자 인식 개인 정보 보호 라는 제목의 논문에서 발표한 설문 조사에 따르면 " 응답자의 절반은 거래 개인 정보 보호가 매우 중요하다고 답했습니다 ." 이 연구는 비트코인과 더 관련이 있지만 이더 사용자도 비슷한 태도를 가질 수 있습니다. 그러나 본 연구의 표본 크기는 상대적으로 작았습니다(참가자 14명).
블록체인 사용자의 정치적, 경제적, 거버넌스 태도 라는 제목으로 Frontiers 에 발표된 2022년의 또 다른 흥미로운 연구는 총 3,710명의 암호화폐 사용자를 대상으로 보다 포괄적인 조사를 실시했습니다. 그 결과, 응답자의 약 4분의 1이 개인 정보 보호가 " 블록체인 및 암호화폐에서 가장 중요한 기능 "이라고 답한 것으로 나타났습니다.
개인 정보 보호에 대한 전반적인 태도 측면에서 Consensys는Web3 및 암호화폐 글로벌 설문 조사 2023 이라는 연구를 발표했습니다. 이 연구에서는 15개국의 15,158명을 대상으로 암호화뿐 아니라 웹과 관련된 다양한 주제에 대해 온라인 설문 조사를 실시했습니다. 설문 조사에 따르면 응답자의 83%가 데이터 개인 정보 보호가 중요하다고 생각하는 반면, 45%만이 데이터 및 개인 정보에 대해 현재 인터넷 서비스를 신뢰한다고 답했습니다.
2023년 4월에 발표된 영국 금융 서비스 보상 제도(UK Financial Services Compensation Scheme)에서 실시한 설문 조사 에 따르면 응답자의 9%가 암호화폐에 투자하는 이유로 " 익명성/개인 정보 보호에 대한 욕구 "를 꼽았습니다.
비밀 거래 프로토콜 채택
Railgun 사용 수치는 인상적이며, 프로토콜 사용은 시간이 지남에 따라 꾸준히 증가하여 2024년 11월 기준 총 고정 가치(TVL)가 7천만 달러 이상, 거래량이 20억 달러에 달합니다.
이더 메인넷의 TVL (USD) Railgun — 출처: Railgun — DefiLlama
Umbra 사용자 수(ENS에 개인 주소를 등록하는 사람 수)도 꾸준히 증가하여 2024년 11월 현재 거의 77,000명에 달합니다.
Umbra 등록 누적 수(크로스체인) — 출처: dune.com
이더 에서 가장 널리 알려진(지금은 불행하게도 악명 높은) 개인 정보 보호 프로토콜인 Tornado Cash를 살펴보면 계약 주소가 기술적으로 OFAC의 SDN 목록에 있음에도 불구하고 여전히 대량 사용되고 있음을 알 수 있습니다.
아래 차트는 시간 경과에 따른 Tornado Cash의 TVL을 보여줍니다. 2021년 10월경 정점을 기점으로 TVL의 첫 번째 큰 하락은 암호화폐 시장의 전반적인 매도와 동시에 발생했으며, 두 번째 큰 하락은 OFAC의 Tornado Cash 상장과 동시에 발생한 2022년 8월에 발생했습니다. SDN 목록. 세 번째 주요 삭제는 2022년 11월 OFAC의 재지정에 해당합니다. 그러나 그 이후로 제재에도 불구하고 Tornado Cash 사용량은 꾸준히 증가하여 TVL이 6억 달러에 육박했습니다. 이는 이더 에서 기본적인 거래 프라이버시가 필요하다는 강력한 증거입니다.
이더 메인넷의 TVL (USD) 토네이도 캐시 — 출처: Tornado Cash — DefiLlama
스텔스 주소의 현재 상태
이 연구에서는 현재 온체인 생산되는 4가지 주요 솔루션을 확인했습니다.
플루이드키
암영부
미궁
레일건
Fluidkey와 Umbra는 다음과 같은 이더 표준을 기반으로 합니다.
ERC-5564: 스텔스 주소 프로토콜
ERC-6538: 암호화 메타 주소 등록
Labyrinth와 Railgun은 사용자가 자금을 예치하는 보호 풀을 사용하는 zerocash 프로토콜 ( zcash 도 기반)을 기반으로 합니다. Zerocash는 기본적으로 가치를 암호화하여 표현하는 "노트" 개념을 사용하여 개인 거래를 가능하게 합니다. 각 메모에는 숨겨진 값, 소유자 키 및 고유 번호(무효자)가 포함되어 있으며 zk-SNARK를 사용하여 세부 정보를 공개하지 않고 소유권을 확인함으로써 메모의 값을 전송합니다. 메모가 사용되면 이중 지출을 방지하기 위해 무효자가 공개되고 수신자를 위해 새 메모가 생성되어 보호 풀 내에 UTXO 시스템이 형성됩니다.
높은 수준에서 스텔스 주소의 이론적 근거는 제3자가 존재하지 않는 주소로 자금을 보낼 수 있고 의도된 수신자가 해당 주소를 찾아 제어할 수 있다는 것입니다(즉, 나중에 자금을 사용할 수 있음).
erc-5564 표준은 수신자가 새로운 이더 주소를 파생할 수 있는 암호화 메타 주소를 게시할 수 있는 메커니즘을 지정합니다. 수취인에게 자금을 보내려는 사람은 누구나 암호화된 메타 주소에서 새 주소를 생성하고 수취인이 직접적인 통신 없이 자금에 대해 알 수 있도록 할 수 있습니다. 모든 스텔스 주소 구현은 이 기본 전제를 기반으로 합니다.
스텔스 주소 작동 방식
스텔스 메타주소는 본질적으로 "지출 키"와 "보기 키"로 알려진 두 개의 압축된 공개 키를 연결한 것입니다. 스텔스 메타주소는 "st:" 접두사가 추가된 EIP-3770 체인별 주소 형식을 사용합니다. 다음은 스텔스 주소의 예입니다.
st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507
단순화하기 위해 이 스텔스 주소는 일반 이더 주소(및 ENS)와 연결될 수 있으므로 스텔스 주소 소유자에게 자금을 더 쉽게 보낼 수 있습니다. 자금을 보내기 위해 보낸 사람은 위 주소를 구문 분석하고 EIP-5564 표준을 사용하여 스텔스 주소가 파생되는 임시 공개 키를 만듭니다. 발신자는 일반적으로 모든 스텔스 주소 수신자가 이벤트를 수신하는 싱글톤 계약을 통해 새로운 스텔스 주소로 자금을 보냅니다. 계약은 수신자가 구독할 수 있는 "공지" 이벤트를 발생시킵니다. 공지 이벤트가 전송될 때마다 수신자는 공지에 포함된 임시 공개 키를 확인하고 이를 보고 있는 개인 키와 결합한 후 스텔스 주소로 전송된 자금을 사용할 수 있는지 여부를 확인합니다. 그렇다면 사용 중인 지갑/클라이언트는 스텔스 주소와 해당 자금을 기억하고 이를 사용자의 표시된 잔액 에 추가합니다. 해당 자금을 실제로 사용하려면 개인 지출 키를 사용하여 거래에 서명할 수 있습니다.
다음 다이어그램은 전체 프로세스에 대한 보다 명확한 개요를 제공합니다.
이 프로세스는 완전히 비대화형이라는 점을 명심하세요. 즉, 발신자와 수신자 사이에 직접적인 통신이 없다는 의미입니다. 이는 실제로 발신자와 수신자 사이에 제3자가 관찰할 수 있는 링크가 없다는 의미입니다.
그러나 이것이 제대로 작동하려면 수신자가 발신자에게 비밀 주소를 알려야 합니다. 이를 달성하는 한 가지 방법은 eip-6538 스텔스 메타 주소 레지스트리를 사용하는 것입니다. 이는 사용자가 보낸 사람이 조회할 수 있는 일반 이더 주소에 스텔스 메타 주소를 등록할 수 있도록 하는 싱글톤 계약입니다. 이를 통해 발신자는 ENS에서 일반 주소를 확인한 다음 레지스트리에서 관련 스텔스 메타 주소를 조회할 수 있습니다.
이 계획은 발신자와 수신자 사이의 연결을 끊어 두 사람 모두 자신의 업무에 대해 전 세계가 알지 못하도록 합니다. 그러나 몇 가지 주의 사항이 있습니다.
수취인이 자금을 사용하러 가면 자금을 이체하는 사람은 해당 자금이 원래 보낸 사람에게서 온 것인지 확인할 수 있습니다(예: 자금이 이체된 주소와 이전에 해당 주소로 자금을 보낸 사람을 볼 수 있음). 이는 전송 체인이 손상되지 않고 추적 가능하지만 문제의 수신자에게만 연결되어 있음을 의미합니다(수취인이 자신에게 알려진 스텔스 주소가 아닌 주소로 자금을 보내는 등의 작업을 수행하지 않는 한). 이는 Railgun 또는 Labyrinth가 아닌 erc-5564 구현에만 적용됩니다.
위 문제의 또 다른 부작용은 최적의 개인 정보 보호를 유지하기 위해 사용자가 자금을 하나의 주소 아래에 통합하는 대신 실제로 필요할 때까지 원래 전송된 스텔스 주소에 자금을 보관하기를 원할 수 있다는 것입니다. 이는 주소를 기억한 후 해당 주소에 자금을 지출하는 추가 오버헤드를 나타냅니다. 왜냐하면 이체하려는 금액은 여러 다른 주소의 자금 조합에서 파생되어야 하기 때문입니다.
이 주소에서 자금을 이체하려면 수령인은 가스 비용을 지불하기 위해 주소에 일부 ETH를 제공해야 하며, 이로 인해 수령인의 익명성이 상실될 수 있습니다. 이는 스텔스 주소와 관련된 알려진 문제이며 많은 구현이 eip-4337 및 지불자를 지원하는 이유 중 하나입니다.
스텔스 주소 체계의 한 가지 단점은 수신자가 블록체인에서 공지 이벤트를 모니터링하고 각 공지를 확인하여 자금을 받았는지 여부를 확인해야 한다는 것입니다. 이는 특히 여러 네트워크에서 자금을 받을 때 대부분의 사용자에게 비현실적인 오버헤드입니다. 이 프로세스를 보다 효율적으로 만들기 위해 표준에서는 분명히 의도하지 않은 트랜잭션을 신속하게 삭제하는 데 사용할 수 있는 공유 비밀에서 파생된 잘린 해시인 "뷰 태그"를 지정합니다. 보기 탭을 사용하면 데스크톱에서는 성능이 그다지 나쁘지 않지만 모바일에서는 더 눈에 띄게 나타날 수 있습니다. 성능 저하가 실제로 눈에 띄는 유일한 경우는 지갑이 복구되는 경우입니다. 이 경우 지갑은 온 온체인 계약이 배포된 이후 모든 주소를 스캔해야 하며 이는 매우 시간이 많이 걸립니다.
이 문제를 해결하기 위해 사용자는 개인 보기 키를 신뢰할 수 있는 제3자와 공유하도록 선택할 수 있습니다. 이 제3자 서비스는 다양한 네트워크를 모니터링하고 자금을 받으면 사용자에게 알립니다. 물론 여기에는 절충점이 있습니다. 제3자는 실제로 사용자의 자금을 사용할 수 없지만(개인 지출 키가 없음) 특정 수신자에게 전송된 모든 자금을 볼 수 있습니다. 그들의 프라이버시를 믿으십시오. Fluidkey는 기본적으로 이 작업을 수행합니다.
표준 스텔스 주소 프로토콜인 ERC-5564는 개인 정보 보호 전송을 용이하게 하도록 설계되었지만 비재무적 사용 사례(예: 임의의 스마트 계약 기능 호출)에는 더 많은 엔지니어링이 필요하며 구현에 따라 달라지는 경우가 많습니다.
비교 행렬
이 기사에서 살펴본 네 가지 스텔스 주소 구현을 비교할 수 있는 여러 가지 방법이 있습니다. 모든 구현에는 미묘한 차이와 장단점이 있지만 아마도 가장 중요한 점은 추적 가능성과 가치 난독화에 관한 것입니다.
Fluidkey와 Umbra는 모두 수신자의 신원에 대한 링크를 끊으면서 표준 이더 주소로 자금을 이체할 수 있도록 허용하지만 여전히 거래 추적성을 유지합니다. 즉, 비밀 주소의 거래 내역을 조사하는 사람은 발신자를 볼 수 없습니다. 보이는. 즉, 숨겨진 주소에서 자금을 받으면 해당 자금을 보내기로 결정한 사람이 해당 자금의 출처를 확인할 수 있습니다. 또한 전송된 실제 값도 볼 수 있습니다. Railgun과 Labyrinth는 보낸 사람과 전송되는 값을 숨기지만, 이 모든 것이 일반 이더 주소에 대한 일반적인 거래가 아닌 단일 계약 내에서 발생합니다.
아래 그림은 이 기사에서 논의하는 프로토콜이 두 가지 중요한 비교 측면에서 서로 어떻게 비교되는지 보여줍니다.
이러한 차이점을 더 자세히 살펴보기 위해 다음은 6가지 주요 차원에 따른 4가지 주요 스텔스 주소 프로토콜의 비교 매트릭스입니다.
완전한 엔드투엔드 개인정보 보호(발신자와 수신자만 결제 정보를 볼 수 있음)
순방향 비밀. 스텔스 거래를 통해 받은 자금은 두 번째 수신자가 자금 출처를 볼 수 없도록 합니다.
erc-5564 및 erc-6538 표준을 준수합니다.
타사 dapp과의 통합을 허용하는 확장 가능한 모듈 아키텍처 구현
구현 시 개발자가 통합에 사용할 수 있는 SDK를 제공합니까?
솔루션은 일종의 익명화 지원을 통해 규정 준수를 제공합니까?
디자인이 전송된 금액/가치의 난독화를 지원합니까?
다음 섹션에서는 몇 가지 추가적인 뉘앙스와 차이점을 더 자세히 설명합니다. 각 구현에는 사용 사례에 영향을 미칠 수도 있고 그렇지 않을 수도 있는 흥미로운 뉘앙스가 있습니다.
예를 들어 Fluidkey에서는 모든 거래가 온체인 스텔스 주소로 직접 이동하는 반면 Umbra**:** ETH만 온체인 스텔스 주소로 이동하고 토큰은 Railgun 및 Labyrinth와 마찬가지로 중앙 계약으로 이동합니다. , 모든 거래는 모두 온체인 숨겨진 주소로 직접 전송되지 않고 핵심 계약으로 전송됩니다.
스텔스 주소 구현에 대한 심층적 논의
플루이드키
Fluidkey 는 사용자가 ETH 및 ERC-20 토큰을 보내고, 받고, 교환하고 연결할 수 있도록 하는 erc-5564의 구현입니다. 글을 쓰는 시점에서 Fluidkey는 Base, Optimism, Arbitrum, Polygon, Gnosis 및 이더 메인넷에 배포되었습니다.
사용자는 웹 사용자 인터페이스를 통해 Fluidkey와 상호 작용합니다. 지갑을 사용하여 처음 로그인하면 보기 및 지출 키가 파생되는 키 생성 메시지에 서명합니다. 사용자가 앱에 들어갈 때마다 동일한 키가 동일한 방식으로 다시 생성됩니다.
Fluidkey는 여러 면에서 다른 구현과 다릅니다. 차이점 중 하나는 사용자가 개인 보기 키를 Fluidkey(실제로는 BIP-32 파생 노드)와 공유한다는 것입니다. 이를 통해 Fluidkey는 사용자를 위한 스텔스 주소를 생성하고 해당 주소로 지불금을 받을 때 사용자에게 알릴 수 있습니다. 그러나 이는 또한 Fluidkey가 사용자의 들어오는 거래와 잔액 볼 수 있는 기능을 가지고 있음을 의미하며 이는 절충안입니다. 그러나 Fluidkey는 완전한 자기 관리권을 유지합니다.
Fluidkey 디자인의 또 다른 흥미로운 측면은 각각의 새로운 스텔스 주소에 대해 스마트 계약 계정을 배포한다는 것입니다. 이는 클로킹된 주소에서 자금을 조달한 자금이 사용되는 경우에만 발생합니다. 스마트 계정은 가스 후원 등의 운영이 가능한 1/1 보안 계정으로 다양한 스텔스 주소를 보다 쉽게 관리할 수 있습니다. 이에 대한 자세한 내용은 해당 기술 설명을 확인하세요.
Fluidkey는 사용자 계정에 대한 가시성을 유지하므로 규정 준수와 관련하여 잠재적으로 이점이 될 수 있지만 Fluidkey가 잠재적인 향후 법 집행 요청을 처리하는 방법에 대한 정확한 프레임 아직 공개되지 않았습니다. 그들은 스위스에 본사를 두고 있으며 현지 법률이 적용되지만 데이터 보호법은 매우 명확하고 강력합니다. 데이터를 공유해야 하는 매우 명확한 이유가 있어야 하며 해당 문제는 법원 검토의 대상이 됩니다. 스위스 개인정보 보호법).
또한 사용자는 자신의 거래를 완전히 내보내거나 제3자(예: 회계사)와 보기 키를 공유할 수 있으며 이는 특히 비즈니스에 유용합니다. ERC-5564 사양에 따르면 공개 키 공유는 "전부 아니면 전무"라는 점에 주목할 가치가 있습니다. 즉, 단일 트랜잭션을 분리하여 공개할 수 없다는 의미입니다. 또한 모든 erc-5564 구현과 마찬가지로 추적성은 깨지지 않고 사용자와의 상관관계만 유지됩니다. 즉, 각 스텔스 주소의 거래 내역은 보기 키를 가진 모든 사람에게 공개됩니다. Fluidkey의 잘 알려지지 않은 기능은 보기 키를 순환하는 기능입니다. 이를 통해 사용자는 매달 새로운 보기 키를 사용하고 특정 달의 보기 액세스 권한만 제3자와 공유할 수 있습니다.
Fluidkey 접근 방식의 한 가지 이점은 스텔스 주소 자체가 발신자에 의해 생성되는 것이 아니라 ENS를 쿼리할 때마다 Fluidkey에 의해 의사 무작위로 생성된다는 것입니다. 사용자는 자신이 수신자인 거래를 식별하기 위해 공지 이벤트를 샅샅이 조사할 필요가 없기 때문에 더 빠릅니다. 이는 또한 보내는 사람이 받는 사람을 위한 스텔스 주소를 생성하기 위해 스텔스 주소 지갑이 필요하지 않다는 것을 의미합니다. 그들은 다른 주소처럼 간단히 자금을 보낼 수 있습니다. 이는 등록 계약이 필요하지 않다는 의미이기도 합니다. 이는 Fluidkey의 고유한 디자인이자 주요 장점입니다.
Fluidkey는 완전한 자체 보관을 위해 최선을 다하고 있으며 스텔스 계정 툴킷 라이브러리를 오픈 소스로 제공했으며 Fluidkey가 하룻밤 사이에 사라지는 경우에 대비하여 여러 가지 독립적으로 개발된 복구 기능을 갖추고 있다는 점을 언급할 가치가 있습니다. 인터페이스를 사용할 수 있으므로 자금이 잠기거나 정체되지 않습니다.
주소 추상화
Fluidkey는 스마트 계약 계정을 사용하여 각 숨겨진 주소를 자동으로 추상화하고 관리할 수 있습니다. 이는 다양한 스텔스 주소의 잔액 에서 특정 수취인에게 특정 금액을 이체하려는 경우 Fluidkey가 자동으로 주소 조합을 계산하여 자금 이체, 모든 가스 수수료 및 계약 배포를 처리할 수 있음을 의미합니다. 이 모든 작업은 백그라운드에서 발생합니다. Fluidkey를 사용하면 사용자가 주소를 다른 범주로 태그 수 있는 태그 라는 멋진 기능을 통해 어떤 주소가 결합되는지를 어느 정도 제어할 수 있습니다.
ENS 분석
Fluidkey를 사용하려면 사용자가 Fluidkey에 고유한 ENS 이름을 생성해야 합니다. 이러한 정적 이름은 username.fkey.id 및 username.fkey.eth의 두 가지 형식으로 제공됩니다. 하나는 누군가에게 자금을 보내기 위한 웹 인터페이스의 URL이고, 다른 하나는 지갑과 함께 사용할 수 있는 표준 ENS 이름입니다.
ENS 설정은 ENS 오프체인 확인자 ( erc-3668: CCIP Read 라고도 함)를 사용하여 스텔스 주소를 반환합니다. 오프라인 확인자는 쿼리될 때마다 해당 ENS 이름에 대한 새로운 스텔스 주소를 생성하고 반환합니다. 이는 결과 스텔스 주소를 ENS 이름으로 추적할 수 없기 때문에 사용자가 스텔스 주소의 개인 정보를 유지하면서 사람이 읽을 수 있는 단일 ENS 이름을 가질 수 있다는 점에서 훌륭한 기능입니다.
비용
Fluidkey는 무료로 사용할 수 있으며 수수료도 없습니다. 자금을 사용하려면 자금이 있는 각 주소에 Safe 계약 수수료를 배포해야 합니다. 그러나 메인넷에서는 상대적으로 비용이 많이 들지만 L2에서는 실제로 사소한 일이며, 여러 스텔스 주소가 단일 전송으로 결합되는 경우에도 종종 1센트 미만입니다.
그들은 또한 안전 배포를 통해 가스 후원을 할 수 있습니다. 가스 비용을 계산하여 사용자 잔액 에서 공제합니다. 토큰인 경우에도 마찬가지입니다. 이 경우 전달자는 안전을 배포하고 사용자를 대신하여 토큰을 전송합니다.
움브라 캐시
Umbra는 Scopelift의 eip-5564 + eip6538 구현입니다. 사용자가 Umbra 앱에 로그인하면 지출 및 보기 키와 해당 스텔스 메타 주소가 파생되는 메시지에 서명하는 설정 단계를 거치게 됩니다. 그런 다음 이 스텔스 메타 주소를 기본 지갑 주소의 온체인 레지스트리에 등록합니다. 이것이 Fluidkey와 구현이 다른 점입니다.
Umbra의 erc-5564 구현은 사용자 키에 액세스할 수 없으므로 사양에 가장 가깝습니다. 이는 Umbra(또는 다른 사람)가 사용자의 자금을 볼 수 없다는 것을 의미하지만, 자금을 받으려면 송금인이 스텔스 메타 주소를 생성하기 위한 ERC-5564 호환 지갑(또는 Umbra 앱)이 있어야 함을 의미합니다.
누군가가 사용자에게 돈을 보내 려고 할 때 일반적으로 Umbra 앱을 사용하여 보냅니다. 기본적으로 Umbra 앱은 ENS 이름/지갑 주소에 등록된 스텔스 메타 주소를 찾아 스텔스 주소를 생성합니다. 수령인은 Umbra 앱에 로그인하여 마지막 로그인 이후 자신의 스텔스 주소로 전송된 자금을 스캔할 수 있습니다. 일부 영리한 캐싱 덕분에 주간 검색에 10~15초밖에 걸리지 않는 것 같습니다. 하지만 사용자는 검색 범위를 좁히기 위해 블록 범위를 지정하도록 선택할 수도 있습니다. Umbra v2에는 뷰 태그 사용이 포함되어 프로세스 속도가 더욱 빨라집니다.
전달자
앞서 언급한 스텔스 주소의 한 가지 문제점은 수신자가 스텔스 주소로 전송된 자금을 사용하려면 해당 주소에 거래 수수료를 충당하기 위해 ETH 또는 기타 필요한 가스 토큰이 있어야 한다는 것입니다. 대부분의 네트워크에서 스텔스 주소가 처음에 ETH를 받은 경우 일반적으로 문제가 되지 않습니다. 그러나 스텔스 주소가 ERC-20 토큰이나 NFT를 수신하는 경우 해당 주소를 ETH로 가스 처리하는 행위는 해당 주소를 사용자의 다른 주소와 연결하여 개인 정보를 잃을 수 있습니다.
이 문제를 해결하기 위해 Umbra는 전달자 와 관련된 구성을 사용합니다. ETH가 아닌 자산이 Umbra 사용자에게 전송되면 실제로는 스텔스 주소로 직접 전송되기보다는 특별 계약을 통해 전송됩니다. 사용자는 Umbra 애플리케이션에서 Umbra 전달자에게 메타 트랜잭션을 전송하여 스텔스 주소로 전송된 자금을 사용할 수 있습니다. Umbra 전달자는 사용자를 대신하여 스마트 계약에서 자금을 이체합니다. 리포스터는 가스 비용을 충당하기 위해 일부 토큰을 공제하며 처음에는 특정 수의 토큰만 지원합니다.
비용
Umbra 계약은 또한 스팸을 억제하기 위해 낮은 거래 수수료 네트워크로 자금을 이동할 때 소액의 수수료를 부과합니다. 스팸은 관련 거래를 식별하기 위해 거래를 검색하는 비용을 증가시키므로 이는 허용 가능한 절충안으로 간주됩니다.
지원되는 네트워크
Umbra는 현재 이더 메인넷과 Optimism, Polygon, Gnosis Chain 및 Arbitrum에 배포되어 있습니다.
Umbra 등록 계약은 흥미로운 디자인을 가지고 있습니다. 배포 방법은 create2와 표준 create2 배포자를 사용하며 스마트 계약 주소는 모든 네트워크에서 동일합니다. 즉, 특정 네트워크에 계약이 존재하는 경우 클라이언트는 해당 계약이 올바른지 확인할 수 있습니다. 네트워크를 추가하도록 클라이언트를 구성할 수 있으며 누구나 모든 네트워크에 배포할 수 있습니다. 그들은 계약에 소유자가 없도록 바이트코드를 표준화했습니다. 이를 통해 누구나 허가 없이 모든 온체인 에 등록 및 발표 계약을 배포할 수 있습니다.
움브라 v2
Scopelift는 현재 새로운 토큰 표준이나 비지불 사용 사례를 지원하기 위해 핵심 계약을 확장할 수 있는 새로운 모듈 아키텍처를 도입하는 Umbra 버전 2를 개발 중입니다. 이 새로운 아키텍처를 사용하여 타사 개발자는 erc-1155, erc-7621, erc-4337 지불자 지원 또는 생각할 수 있는 모든 유형의 토큰 표준에 대한 모듈 구축할 수 있습니다. 현재 Umbra 코어 계약은 ETH와 Erc-20의 두 가지 시나리오를 지원합니다. V2는 다양한 시나리오를 지원합니다.
미궁
Labyrinth 는 eip-5564 + eip6538을 기반으로 하지 않지만 영지식 증명을 사용하여 거래에 익명성과 개인 정보 보호를 추가하는 프로토콜입니다. Labyrinth의 백서 이를 "zkFi" 미들웨어로 설명합니다. " zkFi는 규정 준수 기능이 내장된 개인 정보 보호 미들웨어 역할을 하는 패키지 솔루션을 제공합니다 ." 내장된 규정 준수는 투명성과 개방성을 유지하면서 특정 거래를 승인된 특정 당사자(예: Interpol 등의 법률 기관)에 대해 익명화할 수 있는 정교한 솔루션인 Labyrinth의 "선택적 익명화"를 의미합니다.
Labyrinth에서 사용하는 핵심 스마트 계약에는 다중 거래 및 다중 자산 풀이 포함되어 있어 사용자는 단일 거래에서 여러 자산을 거래할 수 있습니다. 자산을 사용하기 위해 사용자는 네트워크를 스캔하여 암호화된 티켓 데이터를 얻고, 티켓의 암호를 해독하고, 사용하려는 자산을 필터링합니다. 그런 다음 사용자는 사용하려는 거래와 관련된 메모에 대한 거래 및 서명 키를 포함하는 ZKP를 생성합니다.
Labyrinth 핵심 계약의 일부에는 기본적으로 외부 계약의 프록시인 모듈 프록시 계약과 인터페이스하는 변환 계약이 포함되어 있습니다. 예를 들어 사용자가 Labyrinth를 사용하여 Uniswap과 상호 작용하려는 경우 사용자는 Uniswap의 프록시 계약을 통해 Uniswap 풀에서 스왑 작업을 호출하기 위해 변환 계약을 사용하는 트랜잭션을 구성합니다.
Labyrinth의 zkFi 프로토콜은 "티켓"을 사용하여 잔액 과 이체를 추적합니다. 메모는 기본적으로 자산의 특정 금액과 해당 자산이 속한 주소를 설명하는 데이터 구조입니다. 클라이언트는 티켓을 재구성하는 데 필요한 정보를 저장하고 이 정보를 사용하여 자산을 소비합니다. 메모에 대한 약속(자산 ID, 소유자 및 가치의 해시)은 온체인 머클 트리에 저장됩니다. 실제로 Labyrinth는 두 개의 Merkle 트리를 사용합니다. 하나는 티켓용이고 다른 하나는 루트 주소용입니다.
메모 데이터 구조에는 다음 내용이 포함됩니다.
assetId: 이 노트가 나타내는 자산의 식별자(ETH, WBTC, MATIC 등)입니다.value: 메모에 표시된 값 또는 금액입니다.leafIndex: 이 노트가 삽입될 Promise Merkle 트리의 리프 노드 인덱스입니다.blinding: 무작위 보호 요소.rootAddress: 지출 권한이 있는 사용자의 루트 주소입니다.revoker: 선택한 취소자의 공개 키 포인트입니다.
위의 데이터 구조에는 자산 소유자 에 대한 참조가 포함되어 있지 않다는 것을 알 수 있습니다. 이는 노트 Merkle 트리에 기록된 약속이 자산 ID, 값 및 소유자 의 해시이기 때문에 이상합니다. 실제로 소유자는 루트 주소, 실행 취소자 및 임의 보호 요소로 계산되므로 외부 관찰자에게 소유자는 실제로 각각의 새 거래에서 생성된 새 주소입니다.
보호 풀
Labyrinth에서 특히 흥미로운 점은 자산 풀이 실제로 거래의 기밀성을 위한 프런트엔드를 제공하는 보호된 UTXO 풀을 생성하기 위해 노트 개념을 활용하는 보호된 풀이라는 점에서 기존의 스텔스 주소 기반 프로토콜과 약간 다르다는 것입니다. . eip-5564 구현에서는 사용자 전송 수신자가 해당 자금의 출처를 볼 수 있다는 점을 기억하세요. 즉, Alice는 스텔스 주소로 Bob에게 지불하고 Bob은 Charlie에게 지불하므로 이제 Charlie는 Bob이 원래 Alice로부터 이러한 자금을 받았음을 알 수 있습니다. Labyrinth의 보호 풀은 그렇지 않습니다.
이 보호 풀의 작동 방식을 이해하려면 프로토콜 내에서 자금이 이동되는 방식을 살펴봐야 합니다.
보호 풀에 있는 사용자의 잔액 은 해당 자산의 메모의 합계입니다. 이 노트를 사용하려면 사용자는 해당 노트의 "무효 플래그"를 공개해야 합니다. 유효하지 않은 ID는 해당 지폐와 고유하게 연결되며, 일단 지폐가 사용되면 이중 지출을 방지하기 위해 유효하지 않은 ID가 태그 되고 지출된 지폐를 기반으로 새 지폐가 생성됩니다. 동일한 자산에 대한 여러 메모를 병합하고 여러 개의 새 메모를 만들 수 있습니다. 유효하지 않은 플래그는 (?,?,?)의 해시입니다. 여기서 ?는 노트의 Merkle 트리에 있는 노트의 약속 인덱스이고, ?는 보호 요소라고도 하는 무작위 요소입니다.
스텔스 거래 전송 수신자는 핵심 계약에서 발생하는 이벤트를 수신하고 자금을 보낼 수 있는 스텔스 주소를 결정하고 이 주소를 로컬로 기록한다는 점에서 eip-5564와 동일한 방식으로 전송을 식별합니다. 애플리케이션 수명주기 전반에 걸쳐 보기 태그와 비동기식 로컬 캐싱 및 메모 동기화를 활용하여 들어오는 자금을 식별하는 속도도 향상됩니다.
현재 Discovery가 자금 지원을 받는 프로세스의 속도를 높이기 위한 연구가 진행 중입니다. Aztec의 제안을 확인하세요: 제안 요청: Note Discovery Protocol — Aztec .
자금 지출과 관련하여 사용자는 기본적으로 일반적인 이더 주소인 erc-6654 구현과 달리 zk 증명도 생성해야 합니다. 증명을 생성하려면 호환 가능한 지갑이 필요하며 중급 Android 기기에서 약 20초가 소요될 정도로 비교적 잘 수행됩니다.
패커 및 변환기
Labyrinth는 암호화폐 거래의 문제점 중 일부를 해결하는 몇 가지 멋진 기능을 제공합니다. Labyrinth 핵심 계약으로 전송된 트랜잭션은 erc-4337 패키저를 통해 사용자 작업으로 전송됩니다. 이 설정을 사용하면 사용자가 erc-4337 지불자를 활용하여 가스 비용을 지불하고 개인 정보 보호 계층을 추가할 수 있으므로 거래에서 ETH 또는 가스 토큰이 필요 없이 메모를 사용할 수 있습니다. 유일한 예외는 사용자 작업으로 제출되지 않은 최초 입금입니다. erc-4337 지불자를 사용하는 또 다른 이점은 erc-20 토큰이더라도 이전되는 자산으로 가스 비용을 지불할 수 있다는 점입니다. 따라서 Labyrinth는 가스 가격 오라클 API를 공개합니다.
Labyrinth의 또 다른 아주 좋은 기능은 모듈 식 아키텍처로, 변환기 계약이 제3자 탈중앙화 애플리케이션의 프록시 역할을 할 수 있도록 해줍니다. 이를 통해 사용자는 스텔스 거래를 통해 자금을 이동할 수 있을 뿐만 아니라 Uniswap, Aave, Lido 등과 같은 DEX와 같은 제3자 탈중앙화 애플리케이션과 상호 작용할 수도 있습니다. 이러한 에이전트 " 변환기 " 계약은 기본적으로 특정 자산의 입력을 받고 일부 자산을 출력하는 기능을 구현합니다. 기본 논리는 타사 계약에 존재합니다.
규정 준수 솔루션
Labyrinth는 SeDe(Selective Deanonymization)라는 프레임 통해 규정 준수 및 규제 준수를 보장합니다.
노트의 데이터 구조에는 "실행 취소"라는 필드가 포함되어 있다는 점을 기억하세요. 철회자는 익명화 프로세스를 시작할 수 있는 특정 엔터티의 주소입니다. 사용자는 미리 정의된 목록에서 하나 이상의 취소자를 선택해야 합니다. 철회자는 잠재적으로 불법적이거나 부적절한 활동을 식별하는 데 단독으로 책임을 지지 않으며 법 집행 기관의 요청에 응답할 수도 있습니다.
실행 취소자는 거래를 직접 익명화 해제할 수 있는 개별 능력은 없지만 익명화 해제 요청을 시작하는 역할을 담당합니다. 이러한 요청은 개인정보 보호 및 규정 준수를 감독하는 기관인 Guardian에 공개적으로 게시됩니다. 보호자는 익명화 거래를 허용할지 여부에 대해 투표해야 합니다. 보호자가 정족수에 도달하고 찬성 투표를 할 수 있는 경우 실행 취소자는 거래 데이터를 해독하여 거래 체인이 완전히 익명화될 때까지 관련 거래를 이전 거래에 연결할 수 있습니다.
이 시스템은 일련의 견제와 균형을 만들어냅니다. 왜냐하면 보호자가 거래 데이터 공개를 혼자서 결정할 수 없고, 공모하더라도 보호자의 과반수 표결 없이는 혼자서는 아무것도 할 수 없는 실행 취소자 없이는 아무것도 할 수 없기 때문입니다.
레일건
RAILGUN 은 이더, Binance Smart Chain, Polygon 및 Arbitrum에 배포된 비밀 거래 개인 정보 보호 시스템입니다. 이 프로토콜은 Merkle 트리에 약속으로 저장되어 UTXO 세트를 형성하는 메모를 기반으로 한다는 점에서 어떤 면에서는 Labyrinth와 유사합니다. 즉, 다른 수신자가 지출할 새 메모를 생성합니다. 이는 노트의 소유자만이 무효화 ID를 계산할 수 있다는 것을 의미합니다. 이는 종종 지출 키의 해시와 Merkle 트리의 노트 인덱스에서 생성됩니다.
Railgun의 스텔스 메타 주소는 공개 보기 키와 공개 지출 키의 조합인 eip-5564와 유사한 "0zk" 접두사를 사용합니다. 그러나 Railgun은 ECDSA 및 secp256k1 대신 BabyJubJub 곡선에서 Ed25519 키를 사용합니다. eip-5564와 마찬가지로 사용자는 Railgun 계약에서 생성된 모든 이벤트를 스캔하고 보기 키를 사용하여 어떤 이벤트가 지갑으로의 전송을 나타내는지 결정합니다.
Railgun은 사용자의 메타 트랜잭션을 수신하고 실제 트랜잭션을 해당 블록체인에 브로드캐스팅하여 사용자를 대신하여 가스 요금을 지불하는 실제로 중계자인 브로드캐스터 네트워크를 사용합니다. 사용자와 방송사 사이의 거래는 Waku 프로토콜을 사용하여 암호화 및 전달되므로 최종 사용자의 익명성이 보호됩니다.
Railgun은 외부 스마트 계약과 상호 작용할 수 있는 모듈 식 아키텍처를 갖추고 있어 단순한 전송 이상의 기능을 제공합니다. 외부 계약(예: 안전하지 않은 토큰 A, 일부 AMM의 교환 토큰 B, 보호된 토큰 B를 원래 소유자에게 다시 전송)과 상호 작용하기 전후에 토큰을 보호하고 보안을 해제하는 AdaptRelay 계약을 통해 이를 달성합니다.
버전 3에서 Railgun은 eip-4337을 활용하고 기존 메타 트랜잭션을 지원할 계획입니다. 그들은 Railgun을 위한 전용 eip-4337 userop 메모리 풀을 유지함으로써 독립 해결사들이 브로드캐스터로 참여할 수 있기를 희망합니다. 그들은 현재 Umbra와 협력하여 이 문제를 연구하고 극단적인 사례와 해결 방법을 식별하고 있습니다. 자세한 내용은 아래 Railgun v3 섹션을 참조하세요.
비용
Railgun 프로토콜은 입출금에 대해 0.25%의 수수료를 부과합니다. 이러한 수수료는 DAO 재무부로 보내지며, 시간이 지남에 따라 RAIL 거버넌스 토큰 스테이킹 에게 지급됩니다. 방송사는 일반적으로 0.25%의 입출금 수수료 외에도 자체 수수료를 부과하는데, 이는 일반적으로 실제 온 온체인 거래에 대한 가스 수수료의 약 10%에 해당합니다.
통치
Railgun에는 모든 형태의 제안을 제출할 수 있는 거버넌스 시스템이 있습니다. 핵심 계약(금융 및 거버넌스 계약 포함)에 대한 변경 사항은 DAO 제안을 거쳐야 합니다. 일반적으로 Railgun의 다양한 인스턴스에는 자체 거버넌스가 있습니다. 예를 들어 Railgun은 온체인 별도의 거버넌스 시스템과 토큰을 가지고 있습니다 .
SDK 및 요리책
Railgun은 지갑 또는 DApp 개발자가 Railgun 지원을 통해 스텔스 주소 기능을 구축하는 데 사용할 수 있는 포괄적이고 잘 문서화된 SDK를 제공합니다. Railgun에는 DApp 개발자가 Railgun용 모듈 제공하여 사용자가 Railgun을 사용하여 DApp과 상호 작용할 수 있도록 하는 "레시피"를 제공하는 커뮤니티에서 관리하는 요리책 도 있습니다. 예를 들어, 개발자는 Railgun에 토큰 잔액 있는 사용자가 개인적으로 토큰을 교환할 수 있도록 하는 DEX에 대한 레시피를 작성할 수 있습니다.
레일건 v3
Railgun의 다음 버전에서는 거래 비용이 50%에서 60%까지 절감됩니다. 버전 3의 다른 변경 사항은 전용 메모리 풀을 통해 구현된 eip-4337 userops에 대한 지원입니다. 또한 v3는 인텐트 기반 아키텍처를 지원하므로 솔버가 최상의 실행을 위해 경쟁할 수 있지만 이 글을 쓰는 시점에서 세부 사항은 여전히 매우 높은 수준입니다. 그들은 현재 CowSwap 과 협력하고 있으며 해결사가 자금에 접근할 수 있도록 사전 및 사후 후크를 사용할 계획입니다.
레일건 커넥트
아마도 제안에서 가장 흥미로운 변화는 Railgun Connect라는 도구입니다. 이 도구는 WalletConnect와 유사하며 이러한 DApp이 사용자 정의 모듈 통해 Railgun과의 통합을 명시적으로 제공하지 않고도 개인 용도로 대부분의 프런트엔드에 0zk 주소를 연결할 수 있도록 해줍니다.
Railgun Connect는 실제로 HardHat 로컬 복사 체인의 상태를 사용하고 로컬 HardHat 버전 체인에 대한 RPC 엔드포인트와 함께 자체 web3 공급자를 DApp에 삽입하는 브라우저 확장입니다. 이를 통해 평소와 같이 DApp 계약과 상호 작용하고 거래를 기록한 다음 일괄 처리하고 스나크 증명을 생성하여 온체인 Railgun 계약으로 보낼 수 있습니다. 이 설명은 다소 단순하지만 일반적인 아이디어를 전달합니다. 이를 통해 기본적으로 모든 DApp과 상호 작용할 수 있습니다(추가 오프체인 처리가 필요한 DApp의 일부 극단적인 경우가 있을 수 있음). 체인 상태를 로컬에 저장하는 것은 리소스 집약적인 작업이지만 일단 완료되면 Railgun의 스텔스 주소를 사용하여 일반 지갑을 사용하는 것과 아무런 차이 없이 DApp과 상호 작용할 수 있습니다.
결론적으로
현재 이더 프로토콜에 스텔스 주소를 설정하기 위한 몇 가지 흥미로운 제안이 있습니다. 예를 들어 Inco는 일반 ERC-20 계약을 캡슐화하고 모든 잔액 암호화하는 ERC-20 “래퍼” 개념을 사용합니다. 전송 및 승인은 완전 동형 암호화를 사용하여 암호화된 상태에서 발생합니다. Inco는 현재 자체 네트워크에만 존재하지만 향후 이더 으로 이동할 수 있는 사전 컴파일에 의존합니다.
EIP-7503: Zero-Knowledge Wormholes 라는 또 다른 제안이 있습니다. 이 제안은 "소각 증명"이라는 설계를 기반으로 합니다. 하지만 이 제안은 아마도 EVM에 대한 업데이트가 필요하기 때문에 광범위한 관심을 얻지 못한 것 같습니다. 실제로 토큰 수준에서만 구현할 수 있는 이 업데이트는 eip-7503을 지원하기 위해 특별히 erc-20 설계를 사용합니다(또는 특정 L2가 EVM opcode에 대한 지원을 추가하기로 결정한 경우).
Aztec은 가장 정교한 개인 정보 보호 기술일 수 있지만 이를 사용하려면 사용자가 Aztec에 자금을 연결해야 하며 이는 대부분의 사용자에게 허용되지 않을 수 있습니다. 그러나 이더 사용자 사이에서 기본 거래 개인 정보 보호에 대한 수요가 증가하면 Aztec은 고유한 가치 제안을 갖게 될 수 있으며 DApp과 사용자가 기본적으로 개인 정보 보호를 제공하는 플랫폼으로 마이그레이션함에 따라 매우 가치 있는 L2가 될 수 있습니다.
마찬가지로 Intmax 는 규제 준수 측면도 갖춘 개인 정보 보호 중심의 이더 L2(플라즈마 기반 설계)로서 ZKP 기반 AML 증명을 통해 개인 자금의 적법성을 확인하고 거래 금액에 제한을 부과합니다. Intmax는 전송에 대한 개인 정보 보호를 제공하는 데 제한이 있는 반면 EVM 스마트 계약 작업에는 개인 정보 보호가 없습니다. 그러나 Aztec과 달리 스마트 계약은 Solidity로 작성될 수 있으며 일부 개발자는 이를 선호할 수 있습니다(사용 사례에 따라 다름).
지갑 지원
스텔스 주소 프로토콜 채택이 증가하고 있다는 점은 긍정적인 신호이지만, 여전히 해결해야 할 과제가 많습니다. 가장 중요한 과제는 주류 이더 지갑에서 (적어도 아직은) 완전히 지원되지 않는다는 것입니다. 주류 지갑은 스텔스 주소를 지원할 때 여러 가지 선택을 해야 할 수도 있습니다. 이러한 옵션에는 다음이 포함됩니다.
단일 구현에 대한 독선적인 지원을 제공할 것인가, 아니면 여러 프로토콜에 걸쳐 일종의 포괄적인 수집기를 구축하고 유지할 것인가? 후자는 개발 및 유지 관리 비용이 많이 들 수 있습니다.
규제적 고려 사항이 있을 것이며 선택적 익명화 해제의 범위와 메커니즘에 대한 입장을 취해야 합니까(Labyrinth의 경우처럼)?
스텔스 주소에는 레지스트리 계약(Fluidkey 제외)을 통한 온체인 구성 요소가 필요합니다. 이는 각 EVM 네트워크가 지갑에서 명시적으로 지원되어야 함을 의미합니다(Umbra의 설계는 레지스트리의 무허가 배포를 용이하게 하지만).
Stealth는 Etherscan과 같은 블록 감지기와의 기존 통합을 복잡하게 만듭니다. 예를 들어, 지갑에 총 잔액 표시되기 때문에 "탐지기에서 보기" 버튼은 스텔스 메타 주소에 대해 작동하지 않습니다. 이 문제는 전송에도 존재할 수 있습니다. 이러한 극단적인 경우를 심각하게 고려해야 합니다.
기본 구현에 따라 사용자는 특정 DApp 세트, 즉 기본 프로토콜에서 지원하는 스텔스 주소만 효과적으로 사용할 수 있습니다. 모듈 식 스텔스 주소 아키텍처가 이를 가능하게 합니다. 그러나 모든 DApp이 지원되는 것은 아니며 사용자에게 어떤 방식으로든 알려야 합니다. eip-5506을 사용하면 비교적 쉽지만 지갑의 사용자 경험에 스며들 수 있는 복잡성과 엣지 케이스가 여전히 존재합니다.
열악한 사용자 개인 정보 위생을 예방하는 데에도 개선의 여지가 있습니다. " 이더리움의 Umbra 스텔스 주소 체계에 대한 익명성 분석 " 기사를 참조하세요. 여기서 저자는 이더 메인넷에서 스텔스 거래의 48.5%를 성공적으로 익명화했습니다. 그들이 사용하는 경험적 방법은 프로토콜 및 개인 정보 보호 위생과 관련이 없습니다. 예를 들어 사용자는 자신이 관리하는 은폐된 주소로 자금을 보낸 다음 추적성이 손상되었다고 잘못 믿고 해당 자금을 원래 보낸 주소로 다시 보냅니다. 전반적으로 저자는 스텔스 주소 트랜잭션의 익명화를 해제하는 데 사용할 수 있는 6가지 휴리스틱을 식별했는데, 이는 대부분 모범 사례를 따르지 않는 것을 기반으로 합니다. 그러나 이는 해결해야 할 중요한 사용자 경험 문제입니다.
전반적으로 나는 이더 의 스텔스 주소와 개인 정보 보호에 대해 상당히 낙관적입니다. 저는 우리가 매우 인상적인 진전을 이뤘으며 해결 가능한 몇 가지 문제를 확인했다고 생각합니다. 나는 주류 지갑이 스텔스 주소에 대한 지원을 제공하여 사용자가 기대하고 마땅한 정상적인 수준의 개인 정보 보호로 이러한 주소를 쉽게 사용할 수 있도록 하는 방법을 찾을 것이라고 믿습니다.
이 게시물에서 언급한 4가지 프로토콜을 포함하여 스텔스 주소 인프라를 연구하고 구축하는 데 시간과 노력을 투자한 모든 팀에게 감사드립니다. 그들의 노력과 끈기는 이더 에 큰 영향을 미칠 것입니다!
