Wallet

개요 signTypedData는 EIP-712 표준을 구현한 서명 메서드로 구조화된 데이터에 서명하기 위한 표준 인터페이스를 제공함 지갑은 사람이 읽을 수 있는 형태로 서명 내용을 표시하고, 서명은 특정 도메인과 체인에 귀속되어 재사용 공격을 줄임 signTypedData와 EIP-712의 관계 정의 signTypedData는 EIP-712 규격을 따르는 구조화 데이터 서명 메서드 이더리움 지갑 및 제공자에서 eth_signTypedData, eth_signTypedData_v3, eth_signTypedData_v4 형태로 노출 버전 signTypedData 최초 버전 signTypedData_v3 signTypedData_v4 가장 널리 사용되는 최신 버전 라이브러리 사용 ethers에서는 _signTypedData로 제공 const signature = await signer._signTypedData(domain, types, value) 지갑 연동은 일반적으로 provider에 직접 요청하는 방식 사용 const signature = await ethereum.request({ method: 'eth_signTypedData_v4', params: [account, JSON.stringify({ domain, types, message: value })], })동작 원리 요약 타입화된 구조체 정의 예시 구조체와 필드 타입을 정형화해 명세 도메인 분리자 사용 이름, 버전, 체인 ID, 검증 컨트랙트 주소를 포함해 서명 범위 고정 타입 해시와 데이터 해시 생성 타입 정의를 keccak256으로 해싱 후 데이터 인코딩 해시 생성 최종 해시에 서명 및 검증 지갑에서 서명 생성, 컨트랙트에서 도메인과 타입을 동일하게 재현해 검증 사용 예시 간단한 도메인, 타입, 메시지 구성 예시 const domain = { name: 'MyApp', version: '1', chainId, verifyingContract } const types = { Action: [ { name: 'user', type: 'address' }, { name: 'amount', type: 'uint256' } ] } const value = { user: userAddress, amount } // ethers 서명 const sig = await signer._signTypedData(domain, types, value) // 지갑 요청 v4 서명 const sig2 = await ethereum.request({ method: 'eth_signTypedData_v4', params: [account, JSON.stringify({ domain, types, message: value })], }) 컨트랙트 검증 예시 요약 // OpenZeppelin EIP712, ECDSA 사용 가정 bytes32 digest = _hashTypedDataV4( keccak256(abi.encode( keccak256("Action(address user,uint256 amount)"), user, amount )) ) require(ECDSA.recover(digest, signature) == signer, "Invalid signature")EIP-712 핵심 개념 정리 목적 사람이 읽을 수 있는 서명 메시지 제공 도메인에 귀속된 서명으로 리플레이 공격 저감 구조 타입화된 데이터 스키마와 도메인 분리자 타입 해시와 데이터 해시를 조합한 최종 해시 장점 지갑 UI에서 의미 있는 정보 노출로 UX 개선 다른 dApp이나 체인에서 재사용 어려움으로 보안 강화 주의사항과 팁 v4 사용 권장 v4는 가장 널리 지원되고 구조체 및 배열 표현이 안정적임 provider 요청 방식 web3 라이브러리 함수보다 ethereum.request의 eth_signTypedData_v4 사용이 호환성 측면에서 안전함 타입 정의 일치 컨트랙트와 클라이언트의 타입 이름, 필드 순서, 정수 크기 등 완전 일치 필요 도메인 정합성 chainId와 verifyingContract가 실제 네트워크와 배포 주소와 일치해야 검증 성공 데이터 인코딩 JS 측 정수값은 문자열 또는 BigNumber 형태 사용 권장, 오버플로와 반올림 이슈 회피 ethers 사용 시 types에 EIP712Domain을 포함하지 않음, _signTypedData가 도메인을 별도로 처리함 v4 메시지 포맷 params에 JSON.stringify로 { domain, types, message } 형태 전달 필요 마무리 signTypedData는 곧 EIP-712 사용을 의미하며 구조화된 데이터에 대한 안전한 서명을 가능하게 함 ethers의 _signTypedData 또는 지갑의 eth_signTypedData_v4를 사용해 서명하고, 컨트랙트에서는 동일한 도메인과 타입으로 해시를 재현해 검증하면 됨 명세 일치와 도메인 정합성만 확보하면 안전하고 예측 가능한 서명 흐름을 구현 가능 ...

개요 Viem은 이더리움 계열 체인과 상호작용하는 경량 Web3 클라이언트 라이브러리임 ethers나 web3.js와 같은 범용 라이브러리와 동일한 범주의 도구지만, 모듈 분리 구조와 타입 안전성, 빌드 사이즈, 성능에서 강점이 있음 프로덕션에서 자주 필요한 읽기와 쓰기 흐름을 중심으로, 설치부터 블록 조회, 컨트랙트 읽기, 컨트랙트 쓰기까지의 필수 개념과 실용 팁 정리 핵심 개념과 정의 Public Client 퍼블릭 RPC를 통해 체인 데이터 읽기 전용 호출 수행하는 클라이언트 블록, 트랜잭션, 로그 조회, read-only 컨트랙트 호출 담당 Wallet Client ...

개요 프라이빗키 관리 방식에 따라 암호화폐 월렛은 커스토디얼(custodial) 과 논커스토디얼(noncustodial) 로 구분됨 각 방식의 차이와 선택 기준, 보안·운영 리스크와 대응 방안을 초보자도 이해할 수 있게 정리하면서 실무자가 바로 적용할 수 있는 체크리스트까지 제시함 핵심 개념 커스토디얼 월렛 제3자 서비스가 사용자의 프라이빗키를 보관하고 서명을 대행하는 구조 로그인·출금 등은 서비스 인증 절차를 거쳐 처리됨 논커스토디얼 월렛 사용자가 프라이빗키를 직접 보유·관리하는 구조 브라우저 확장 지갑·모바일 앱 지갑·하드웨어 지갑이 대표적 사례임 핵심 차이 한 줄 정리 키의 소유·통제 주체가 제3자인가 사용자 본인인가의 차이 ...

서문 NFT는 몇 년 새 대중의 관심을 받았지만 개념과 절차가 분산돼 있어 입문자가 막히기 쉬움 이 글은 실무자 관점에서 NFT의 핵심 개념을 단계적으로 정리하고 구매·발행·보관 시 유의사항과 운영 관행을 담는 것을 목표로 함 개념과 배경 NFT는 Non‑Fungible Token의 약자이며 대체 불가능한 토큰을 의미함 동일 단위끼리 교환 가능한 자산은 펀저블 토큰이라 부르고 NFT는 각 토큰이 고유 식별자와 속성을 가져 상호 교환 시 동일 가치를 보장하지 않음 블록체인에 기록된 소유권은 변경이 어렵고 거래 이력이 투명하게 남는다는 장점이 있음 온체인 소유권이 저작권·초상권 등 법적 권리와 자동 동치가 아님에 유의해야 함 ...