Ethereum

개요 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. 가스비 및 처리량 개선 ...

개요 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를 사용해 서명하고, 컨트랙트에서는 동일한 도메인과 타입으로 해시를 재현해 검증하면 됨 명세 일치와 도메인 정합성만 확보하면 안전하고 예측 가능한 서명 흐름을 구현 가능 ...

개요 EVM 트랜잭션 수수료 모델은 자동차 연료 비유가 직관적임 Gas는 연료, 트랜잭션 수행은 목적지까지 주행이라는 맥락으로 이해하면 됨 핵심은 두 파라미터, Gas Limit와 Gas Price이며 EIP-1559 이후에는 Base Fee와 Priority Fee로 세분됨 핵심 개념 Gas Limit 이 트랜잭션이 최대 얼마만큼의 연산을 사용할 수 있는지에 대한 상한 단순 ETH 송금은 21,000 가스 고정값 수준 컨트랙트 실행은 로직 복잡도, 저장소 접근, 반복 등에 비례해 증가 사용하지 않은 가스는 환불, 부족하면 Out of Gas로 실패 후 사용한 가스 비용만큼 청구 Gas Price ...

개요 채굴은 트랜잭션을 묶어 블록을 만들고 블록체인에 추가하는 행위이자, 네트워크를 공격으로부터 방어하는 핵심 보안 메커니즘임 역사적으로 비트코인과 이더리움은 작업증명 PoW 기반 채굴에 의존해 합의를 유지했음 이더리움은 2022년 9월 The Merge로 지분증명 PoS로 전환하여 블록 생성에 소모되는 에너지를 크게 줄였고, 지금은 채굴 대신 검증자 스테이킹이 사용됨 아래 내용은 채굴이 사용되던 시기의 개념과 동작 원리를 정리한 것으로, PoW 계열 네트워크나 역사적 맥락을 이해하는 데 목적이 있음 핵심 개념과 정의 블록체인 원장 네트워크 참여자가 공유하는 불변 기록 장부 트랜잭션 계정 상태를 변화시키는 요청 또는 메시지 채굴자 PoW 네트워크에서 블록을 제안하고 검증하는 주체 작업증명 PoW 특정 해시 조건을 만족하는 값을 찾는 계산을 통해 블록의 정당성을 증명하는 합의 규칙 난이도 difficulty 해시 조건의 엄격함을 조절하는 파라미터, 블록 생성 간격을 목표치로 수렴시키는 역할 넌스 nonce 해시 목표를 만족하기 위해 반복적으로 변경하는 값 메모리풀 mempool 블록에 포함되기 전 대기 중인 트랜잭션 집합 블록 보상 block reward 채굴자가 새 블록을 유효하게 제안했을 때 받는 기본 보상과 수수료 총합 왜 채굴이 필요한가 탈중앙 시스템에서는 트랜잭션의 순서에 모두가 합의해야 이중지불을 막을 수 있음 예시 Alice가 Bob에게 1 단위를 보내고 Bob이 그 1 단위를 Charlie에게 보낼 때, 순서가 뒤섞이면 Bob이 실제 보유하지 않은 금액을 전송하려 시도하는 문제가 발생함 채굴자는 유효한 트랜잭션을 모아 순서 있게 블록에 넣고, 작업증명으로 해당 블록이 정당함을 증명함 PoW의 설계는 두 가지 속성을 가짐 생성은 어렵지만 검증은 쉬움 ...

개요 Abstract는 이더리움 보안을 상속하는 ZK Rollup 기반 L2 체인으로, 고비용·저처리량 한계를 완화하는 확장 층 제공 목표 ZK Stack으로 구축되어 체인 개발과 운영 구성 요소를 모듈화하고, 데이터 가용성은 EIP-4844 블롭을 활용해 비용을 절감하는 방향 추구 핵심 차별점은 네이티브 계정 추상화 기반의 트랜잭션 수명주기와 글로벌 지갑 레이어를 통한 사용자 온보딩 간소화에 있음 배경과 목적 이더리움 메인넷의 처리량은 대략 초당 수십 건 수준이며, 수수료 변동성도 큼 저가치 대량 트랜잭션을 직접 L1에서 처리하는 것은 비현실적 L2의 목표는 탈중앙성과 보안을 유지하면서 처리량과 비용 효율을 동시에 개선하는 것 ZK Rollup은 유효성 증명을 통해 상태 전이를 압축·검증하여 온체인 데이터 요구량과 확정 시간을 줄이는 확장 경로 제공 ...

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

개요 블록체인은 중앙 기관 없이 참여자들이 거래를 기록·검증·공유하는 분산 원장 기술임 이 글은 블록체인을 초보자 친화적으로 설명하고, 실무 체크리스트까지 정리함 큰 그림: 시스템 구성 노드(Node): 블록체인 소프트웨어 실행 주체 풀노드: 모든 블록·트랜잭션 검증·저장 라이트 클라이언트: 헤더·머클 증명 기반 최소 검증 (참고) 아카이브 노드: 오래된 상태 포함 전체 상태 유지(필수 아님) 블록(Block): 트랜잭션 묶음 + 메타데이터(블록헤더). 블록들이 선형 체인으로 연결됨 합의(Consensus): 어떤 블록이 정식 이력인지 네트워크가 공동으로 결정하는 규칙 PoW: 작업증명(연산 경쟁) PoS: 지분증명(검증자·보증금 기반) 해시(Hash)와 위·변조 방지 해시 함수(SHA-256, Keccak-256 등): 입력을 고정 길이로 압축하는 일방향 함수임 ...

개요 이 문서는 이더리움의 PoS 합의 구조와 구성 요소를 정리함 개념 정의에 그치지 않고 운영 시 주의점, 보상·출금 흐름, 짧은 체인 재구성(Reorg) 원인과 완화책까지 다룸 개념과 배경 PoS는 PoW의 에너지 경쟁을 대체해 예치된 지분을 바탕으로 검증자를 선정하는 합의 메커니즘임 이더리움은 2022년 9월 더 머지 이후 PoS로 전환했고 전력 소비를 크게 줄이며 검증자 기반 보안 모델로 이행함 주요 속성 요약 에너지 소비 대폭 축소 스테이킹한 ETH 규모에 비례해 역할 참여 기회가 부여됨 위반 시 슬래싱과 페널티로 예치금이 감소함 계층 분리와 Beacon Chain의 역할 이더리움은 합의 계층(Beacon Chain) 과 실행 계층(Execution Layer) 를 분리해 설계함 ...