개요 블록체인 기술에서 모든 것을 온체인(On-chain)으로 처리하는 것은 비효율적이거나 불가능한 경우가 많음 이때 오프체인 서명 검증(Off-chain Signature Verification)은 오프체인(서버)의 유연성과 온체인(컨트랙트)의 신뢰성을 결합하는 강력한 해결책이 됨 쉽게 비유하자면, 클럽 매니저(서버)가 VIP 손님(사용자)에게만 특별한 싸인이 담긴 입장권(서명)을 발급하고, 입구의 가드(스마트 컨트랙트)는 그 싸인만 확인하고 들여보내는 것과 같음 가드는 매번 매니저에게 연락할 필요 없이, 위조되지 않은 싸인인지 확인만 하면 됨 이 글에서는 오프체인 서명 검증이 무엇인지, 어떤 용어들이 사용되는지, 그리고 가장 중요하게는 어떤 원리로 동작하는지 상세히 알아봄 ...
개요 블록체인 서비스에서 사용자가 겪는 가장 큰 장벽 중 하나는 단연 가스비(Gas Fee)임 아무리 좋은 서비스를 만들어도, 사용자가 지갑에 가스비로 쓸 코인(ETH 등)을 보유하고 있어야 한다는 점은 대중화를 가로막는 결정적인 요인임 이 문제를 해결해 사용자가 가스비 걱정 없이 서비스 핵심 가치에만 집중하게 만드는 것, 즉 가스리스 트랜잭션(Gasless Transaction)을 구현하는 것이 이번 개발의 최종 목표였음 zkSync Era는 이를 위해 페이마스터(Paymaster)라는 강력한 시스템을 제공함. 페이마스터는 서비스 제공자 같은 제3자가 사용자를 대신해 트랜잭션 수수료를 지불할 수 있게 해주는 스마트 컨트랙트임 ...
개요 OpenZeppelin의 contracts-upgradeable은 업그레이드 가능한 스마트 컨트랙트를 안전하게 구현하기 위한 베이스 라이브러리 프록시 Proxy 패턴으로 사용자 호출 주소와 로직 컨트랙트를 분리하고 delegatecall로 로직을 실행 Transparent Proxy와 UUPS 두 방식을 공식 지원 이 글은 Hardhat 환경에서 @openzeppelin/hardhat-upgrades 플러그인과 함께 UUPS를 중심으로 배포와 업그레이드 흐름을 정리하고, Transparent와의 차이점을 요약 핵심 개념 Proxy 컨트랙트와 Implementation 컨트랙트를 분리하여 배포 사용자는 Proxy 주소로 상호작용, Proxy는 delegatecall로 Implementation의 로직 실행 업그레이드는 Proxy가 가리키는 Implementation 주소를 교체하는 방식 EIP-1967 표준 슬롯을 사용해 Implementation 주소 보관 방식 요약 ...
개요 이더리움 단위 체계는 10의 지수 기반으로 딱 떨어지게 설계됨 EVM은 부동소수점을 지원하지 않으므로 모든 값은 정수로 표현, 단위 나눔과 스케일링이 필수 단위 환산 1 ETH = 10^9 Gwei = 10^18 Wei 풀어서 보면 다음과 같음 1 ETH = 1,000,000,000 Gwei (10억 그웨이) = 1,000,000,000,000,000,000 Wei (100경 웨이) 용도별 구분 Wei: 최소 단위, 스마트 컨트랙트 내부 연산에 사용. Solidity에 소수점 개념 없음 Gwei: 10^9 Wei. 가스 가격 표시 단위로 사용, 사람이 읽고 비교하기 쉬움 Ether: 10^18 Wei. 지갑 잔고, 일상적 송금 금액 표시에 사용 개발자 상식: ERC-20 decimals = 18 ERC-20 토큰에서 decimals를 18로 두는 관례는 이더리움 기본 최소 단위(Wei) 스케일을 그대로 따름 의미: 토큰 1개가 10^18의 최소 단위로 분할 가능 예외: 스테이블 코인처럼 법정화폐 소수 자리를 맞추는 토큰은 decimals 6 등으로 설정하는 경우 있음 ...
개념/배경 CEI 패턴은 Checks-Effects-Interactions의 약자 스마트 컨트랙트 함수에서 실행 순서를 명확히 해 재진입 공격을 줄이는 코드 규칙 핵심은 검증 후 상태 변경을 먼저 완료하고, 외부 호출을 마지막에 수행하는 흐름 유지 3단계 순서 1. Checks (검증) ↓ 2. Effects (상태 변경) ↓ 3. Interactions (외부 호출)이 순서를 지키면 외부로 제어권이 나가기 전에 내부 상태가 이미 안전하게 반영됨 재진입 시도는 변경된 상태에 의해 자연스럽게 차단됨 예시로 이해하기 잘못된 순서 위험 function withdraw(uint256 amount) external { // 1. Checks require(balances[msg.sender] >= amount); // 2. Interactions ← 너무 빠름 (bool success, ) = msg.sender.call{value: amount}(""); require(success); // 3. Effects ← 너무 늦음 balances[msg.sender] -= amount; }문제점 ...
개요 리엔트란시 재진입은 외부 호출 중 컨트랙트의 같은 함수 또는 다른 함수가 다시 호출되는 상황을 의미함 상태 변경 전 외부 호출이 발생하면 공격자가 재진입을 통해 상태 검증을 우회하거나 중복 실행을 유도할 수 있음 대표적 피해 사례로 The DAO 사건이 알려져 있음 실무 기본 원칙은 CEI 패턴 Checks-Effects-Interactions 준수와 ReentrancyGuard를 통한 보강 적용임 두 방법을 함께 쓰는 것이 표준에 가까움 유명한 사례와 최소 취약 패턴 취약한 순서 패턴 핵심 외부 전송 또는 외부 컨트랙트 호출이 상태 변경보다 먼저 발생 이후 상태 변경이 이루어져도 재진입 시점에는 이전 상태가 유효하여 중복 집행 가능 최소 취약 스니펫 예시 ...
개요 ERC-721에서 전송 권한 위임을 처리하는 두 가지 승인 방식 정리 권한 범위와 사용 시나리오가 달라 오용 시 과권한 위험 발생 가능 핵심 동작과 권한 확인 패턴 중심으로 정리 핵심 개념 approve(address to, uint256 tokenId) 특정 NFT 1개에 대한 전송 권한만 부여 예 123번 토큰만 지정한 대상이 전송 가능 토큰별 개별 승인 필요 setApprovalForAll(address operator, bool approved) 소유한 모든 NFT에 대한 전송 권한 일괄 부여 한 번 승인 시 현재 보유분 + 이후 수령분까지 포함 관리 편의성 높지만 권한 범위 큼 권한 확인 패턴 컨트랙트에서 호출 주체가 대상 토큰에 대해 승인 받았는지 확인 필요 두 방식 모두 대응하는 조건을 만족해야 안전 ...
개요 ERC-1155는 게임 아이템처럼 대량의 토큰을 효율적으로 관리하기 위해 등장한 멀티 토큰 표준으로, ERC-721의 전송·배포 측면 비효율을 줄이려는 목적을 가짐 편의점 비유로 직관화 가능 ERC-721 개별 포장 모델, 물건 10개 결제에 결제 10번·영수증 10장 ERC-1155 장바구니 모델, 물건 10개를 한 번에 결제·영수증 1장 핵심 개념 ERC-721 단일 NFT 표준, 토큰 ID 하나가 유일한 자산을 대표 ERC-1155 멀티 토큰 표준, 하나의 컨트랙트에서 다수의 ID 발행과 각 ID별 수량 관리 동일 ID에 수량이 붙는 구조로 FT·NFT·SFT를 한 컨트랙트에서 혼합 가능 세미 펀지블 SFT, 같은 ID를 공유하는 동일 품질의 여러 개 토큰을 표현 동작과 구조 단일 컨트랙트에 다수의 tokenId와 balance 맵핑 보유 전송 함수 safeTransferFrom 단건, safeBatchTransferFrom 묶음 전송 지원 이벤트는 TransferSingle과 TransferBatch로 발행, 동일 ID 다건 이동에 최적화 메타데이터는 ID 기반 템플릿 URI 방식 활용이 일반적 {id} 플레이스홀더 패턴 사용 장점 비교 A. 가스비 및 처리량 개선 ...