안녕하세요! 제 아이디어(연구 + PoC)를 발표하고 피드백이나 의견을 듣고 싶습니다.
핵심 요점:
루트 키는 기존 7702 계정일 수 있습니다.
지출 키와 조회 키는 안전한 보관함(예: KMS/HSM/MPC)에 보관해야 합니다.
스텔스 주소 검색에는 이더리움 요청 사항(ERC)-5564 메타데이터(
viewTag(1바이트) 및ephemeralPublicKey(33바이트))를 저장해야 합니다.이 메타데이터는 계약 저장소, 이벤트 로그, 로컬/클라이언트 저장소 또는 백엔드에 저장할 수 있습니다(사용자 경험 및 개인정보 보호 요구 사항에 따라 다름).
참고:
하나의 메타 주소로부터 N개의 스텔스 주소를 도출하는 것이 가능합니다.
파생된 각 주소는 구독, 개인 거래, 개인 결제 또는 결제 채널을 위한 전용 하위 계정을 나타낼 수 있습니다.
계정 생성 요청은 제3자(API를 통해)로부터 시작될 수 있으며, 사용자의 승인을 받은 후 온체인의 하위 계정에 대한 지출 정책과 함께 계정 구현에 적용됩니다.
하위 계정은 프라이버시 풀 또는 시장에서 이용 가능한 기타 프라이버시 자금 조달 메커니즘을 사용하여 연결되지 않는 방식으로 충전할 수 있습니다.
예시 (바로가기):
다음을 기반으로 함: stealth/contracts/STEALTH_ARCHITECTURE.md openfort-xyz/stealth-addresses Bob은 7702번 계정을 소유했습니다. 구현에는 다음이 포함됩니다.
event Announcement ( uint256 indexed schemeId, address indexed caller, bytes1 indexed viewTag, bytes ephemeralPubKey, bytes metadata ) ;bytes public stealthMetaAddress; error InvalidEphemeralPubKeyLength () ; error EmptyMetadata () ; function announce ( uint256 schemeId, bytes calldata ephemeralPubKey, bytes calldata metadata ) external { // Validate ephemeral public key length (66) if (ephemeralPubKey.length != 66 ) { revert InvalidEphemeralPubKeyLength () ;} // Validate metadata contains at least viewTag if (metadata.length == 0 ) { revert EmptyMetadata () ;} // Extract viewTag from first byte of metadata bytes1 viewTag = metadata[ 0 ]; emit Announcement ( schemeId, msg.sender, viewTag, ephemeralPubKey, metadata ) ;} 이 경우 Bob은 st:eth:0x<spendingPubKey><viewingPubKey> 를 기반으로 스텔스 계정을 생성하고 Stealth.announce() 를 호출하여 데이터를 게시할 수 있습니다.
이렇게 하면 이벤트가 발생하고 데이터가 저렴한 비용으로 Bob의 메인 계정에 연결됩니다.
외부 관찰자의 관점에서 보면 무작위 데이터처럼 보일 것입니다. 스텔스 주소나 키를 추론하는 것은 불가능합니다. 관찰자는 밥이 스텔스 주소를 사용하고 있다고 추측할 수는 있지만, 밥이 자신의 스텔스 주소를 공개했는지 아니면 다른 사용자의 스텔스 주소를 공개했는지는 여전히 링크(Chainlink) 수 없습니다.
반면에 앨리스는 밥에게 밥이 요청한 비밀 주소로 송금을 했다고 알릴 수도 있습니다.
두 경우 모두, 우리는 은밀한 주소와 그 소유자 간의 연결 불가능성을 유지합니다.
또한, 개인 보기 키는 메타데이터를 스캔하여 특정 지출 공개 키에 대해 스텔스 주소가 생성되었는지 감지하고 이를 알리는 신뢰할 수 있는 모니터링 시스템에 위임할 수 있습니다. 그런 다음 스텔스 주소를 복구하기 위해 오프라인(예: 안전한 환경)에서 작업을 수행하고 개인 키를 안전하게 복구하여 프런트엔드에서 7702 계정 소유자와 스텔스 주소를 연결할 수 있습니다.
이는 클라이언트나 백엔드에 은밀한 개인 키를 저장하지 않고 은밀한 주소 메타데이터를 저장하는 가장 저렴하고 무신뢰성 방법입니다.
ERC5564(스텔스 주소)란 무엇인가요?: https://github.com/openfort-xyz/-stealth-addresses/tree/0xkoiner/dev/documentation
액터/키
ROOT 7702 계정 : 사용자의 기본 계정(자금 조달 + 관리).
KMS : 이더리움 요청 사항(ERC)-5564 형식의 사용/조회 비밀 키를 저장하거나 HSM/MPC를 통해 보호합니다.
P-256 추출 불가능 키 : 하위 계정 구현을 위한 장기 서명자입니다.
개인 정보 보호 풀 : 하위 계정에 자금을 연결되지 않도록 지원하는 데 사용됩니다.
0단계 — "스텔스 메타 주소"(이더리움 요청 사항(ERC)-5564) 제공
지출 키 쌍 과 보기 키 쌍 (이더리움 요청 사항(ERC)-5564 수신자 키)을 생성합니다.
KMS 에 spend_sk 와 view_sk를 저장합니다(가급적 스레스홀드(Threshold) /분할 제어를 사용하는 것이 좋습니다. 자세한 내용은 아래 참조).
숨겨진 메타 주소 (spend_pk + view_pk)를 원하는 곳(사용자 프로필, 앱 레지스트리, QR 코드 등)에 게시하세요.
이것이 중요한 이유는 다음과 같습니다. 저장하지 않고도 여러 개의 일회용 은밀 주소를 확실하게 생성할 수 있습니다.
당신의 지적은 맞습니다. 파생된 스텔스 개인 키는 저장하지 않고 , 루트 수신자 키만 저장합니다.
1단계 — 새 하위 계정 주소 생성(이더리움 요청 사항(ERC)-5564 파생)
새 하위 계정을 만들 때마다 다음을 수행하세요.
임시 키 쌍을 생성합니다.
이더리움 요청 사항(ERC)-5564에 따라
(epk, metaAddress)에서(stealthAddress, viewTag)를 계산합니다.선택적으로 지갑에서 해당 계정을 찾을 수 있도록 공지 기록/이벤트를 생성할 수 있습니다(타사 결제 사용자 경험을 원하는 경우, 자체 관리 하위 계정에는 필수 사항이 아닙니다).
이제 여러분은 7702 하위 계정이 될 새로운 EOA 주소를 갖게 되었습니다.
2단계 — 파생된 EOA 키를 사용하여 7702 하위 계정을 부트스트랩합니다(저장 공간 없음).
목표: 스텔스 주소의 ECDSA(secp256k1) 기능을 정확히 한 번 사용하여 코드 설치 및 권한 회전을 수행합니다.
신뢰할 수 있는 서비스 경계 내부에서, 은밀한 개인 키를 적시에 생성합니다.
view_sk사용하여 대상을 스캔/식별하세요(또는 제작자라면 이미 어떤 대상인지 알고 있을 것입니다).spend_sk+epk(및 이더리움 요청 사항(ERC)-5564에서 지정하는 파생 방식)를 사용하여 해당 스텔스 주소에 대한 일회용 개인 키를 계산합니다.
파생된 개인 키는 계정의 코드를 설정하는 이더리움 개선 제안(EIP)-7702 인증에 서명할 때만 사용하십시오(사용자 지정 구현).
동일한 설정 흐름에서
initialize(...)호출하여 다음을 수행합니다.P-256 공개키를 기본 서명자(추출 불가능)로 설정합니다.
모듈/권한 제한을 설정하세요.
선택적으로 "위임/세션 키" 정책을 설정할 수 있습니다.
생성된 스텔스 개인 키를 메모리에서 즉시 0으로 초기화합니다 .
중요한 뉘앙스 (보안):
파생된 스텔스 개인 키를 "삭제"하더라도, 나중에 누군가 KMS를 해킹하여 지출/조회 비밀 키를 재계산할 수 있게 되면, 해당 키를 다시 파생시켜 새로운 7702 권한 부여에 서명할 수 있습니다. 따라서 진정한 루트 오브 루트는 KMS가 됩니다 . 하드웨어 지갑 수준의 자산처럼 취급해야 합니다.
3단계 - 프라이버시 풀을 통해 하위 계정에 비공개로 자금을 입금합니다.
ROOT 7702는 이더리움(ETH)/USDC 이더리움 클래식(ETC) 을 프라이버시 풀에 예치합니다.
나중에 Privacy Pools에서 stealthAddress(현재 7702 스마트 계정) 로 자금을 인출하세요.
모범 사례: 하위 계정 에 자금이 입금되기 전에 가스 비용으로 사용할 이더리움(ETH) 미리 있어야 하는 상황을 방지하려면 프라이버시 풀의 기본 중계/수수료 메커니즘(또는 중계기)을 사용하십시오.
4단계 — AA를 정상적으로 사용하기 시작하세요 (4337 + 페이마스터)
현재 하위 계좌에 자금이 있으며 장기 관리권은 P-256이 보유하고 있습니다.
P-256 이 서명한 4337 userOps를 사용하십시오.
스폰서 주유를 원하시면:
서브 계정에 이더리움(ETH) 일부 보유하거나,
이더리움 요청 사항(ERC)-20 수수료를 부과하고 실행 패턴과 호환되는 페이마스터를 사용하십시오.
Paymaster + “동일 사용자 작업에서 인출 및 승인”
주의: 지급기관 검증은 실행 전에 이루어집니다. 따라서 "인출 후 승인, 지급기관에 상환" 방식은 지급기관이 위험을 감수하도록 설계되지 않은 경우 위험을 초래할 수 있습니다. 더 안전한 방식은 다음과 같습니다.
- PP 인출은 먼저 계좌에 자금을 입금한 다음, 사용자 운영팀에서 안전하게 결제/승인할 수 있도록 합니다.
사용 사례: 판매자가 생성하고 연결할 수 없는 구독 하위 계정
목표
신뢰할 수 있는 서비스(Spotify/YouTube/ChatGPT)를 통해 구독 전용 하위 계정을 생성하세요. 이 계정은 다음과 같은 기능을 제공합니다.
사용자의 ROOT 계정에 온체인으로 연결할 수 없습니다 .
판매자가 관리 하므로 매달 요금을 청구할 수 있습니다.
지출 한도가 엄격하게 정해져 있어 (판매자가 자금을 고갈시킬 수 없음)
사용자는 언제든지 취소하고 남은 금액을 환불받을 수 있습니다 .
신뢰할 수 있는 서비스(Spotify, YouTube, ChatGPT 등)는 API를 통해 사용자에게 자체 전용 구독 하위 계정을 요청할 수 있습니다.
사용자는 ROOT 7702 계정에서 이 요청을 승인합니다. 여기에는 구독 정책(월별 한도, 허용 토큰, 허용 수신자)과 지출을 제어할 서비스의 P-256 공개 키가 포함됩니다.
승인이 완료되면 플랫폼은 KMS를 통해 새로운 이더리움 요청 사항(ERC)-5564 스텔스 주소를 생성합니다(따라서 파생된 개인 키를 저장할 필요는 없지만 복구는 가능합니다). 그런 다음 사용자의 ROOT 계정은 프라이버시 풀에 자금을 예치하고, 나중에 해당 자금은 ROOT 계정과 하위 계정 간의 온체인 연결을 방지하는 방식으로 새로 생성된 스텔스 하위 계정으로 인출됩니다.
하위 계정에 자금이 입금되면 이더리움 개선 제안(EIP)-7702 인증을 통해 맞춤형 스마트 계정 구현으로 업그레이드되고 초기화되어 서비스의 P-256 키가 활성 서명자가 되며, 엄격한 지출 한도와 실행 권한이 온체인에서 적용됩니다.
그 시점부터 서비스는 구성된 제약 조건 내에서 반복적인 구독 요금을 부과할 수 있으며, 사용자는 언제든지 루트 키를 통해 서비스를 취소하고 (KMS 기반 파생/복구 경로를 통해) 제어권을 되찾고 메인 ROOT 계정과의 직접적인 온체인 연결을 노출하지 않고 남은 잔액을 인출할 수 있는 안전장치를 유지합니다.
