※ 원글 작성 : 22년 4월 27일 Transaction Flow (User) Transaction 생성 요청 (HFC) Proposal 생성, Endorsing peer로 proposal 전달 (Endorsing peer) Proposal 검증, 이상없으면 서명 인증, HFC로 response (HFC) Orderer로 transaction 전달 (Orderer) 수신한 transaction을 시간 순서대로 정렬 후 블록 생성, commitment peer로 블록 전달 (Commitment peer) 블록 검증 후 이상없으면 블록체인 연결 Nonce Relay attack을 막기위해 Fabric 내에서 random으로 생성 Nonce를 이용하여 transaction ID 생성, Transaction ..

※ 원글 작성 : 22년 4월 27일 Smart contract Solidity 이더리움 smart contract를 개발하기 위한 언어 솔리디티 변수는 context에 따라 메모리 or 파일 시스템에 저장 상태변수 : contract 최상위단에 선언된 변수 = Storage 저장 로컬변수 : 함수 아래에 선언된 변수 = Storage 저장, memory keywordfh 메모리 저장 가능 데이터 유형 bool uint8, uint16, uint24, ..., uint256 - 부호없는 8, 16,, 비트의 정수) ufixed0x8, ufixed0x16, ..., ufixed0x256 - 부호없는 실수 fixed0x8, ...., fixed0x256 - 부호있는 실수 address : 16진수 할당, 최..

※ 원글 작성 : 22년 4월 27일 EVM Smart contrat bytecode를 실행하는 32바이트 스택 기반 실행환경 스택의 최대 크기는 1024 이더리움 각 노드는 EVM을 포함 바이트코드를 OP코드로 변환하고 스택 기반으로 각각의 OP코드 실행 구조 Volatile(휘발성) Stack : OP코드 실행하는 stack영역 Args : contract call 시 인자 저장 Memory : 아이템을 저장하는 바이트 배열 Non-volatile(비휘발성) Storage : State 저장 code : smart contract의 컴파일된 바이트코드 저장 동작과정 바이트코드를 내부 OP코드로 재해석 e.g. 1+2 ? 1+2를 계산하는 바이트코드 '6001600201' 바이트코드를 치환하여 OP코드..

※ 원글 작성 : 22년 4월 27일 Plasma Child/Side chain의 정보를 ETH mainnet에 제출 이더리움에 추가된 사이드 체인 블록의 단일 해시만 사용하여 수백개의 사이드체인의 트랜잭션을 오프체인으로 처리 결함 사이드체인에서 자금 철회 시 exit 수행 필요, 이 때 사용자는 유효성 검증을 위해 충분한 양의 이더리움 블록 데이터를 보유 필요 자금 철회 기간 내에 온라인 상태 유지, 어길 시 보상금 잃음 Roll up Layer1(ETH) 외부에서 트랜잭션을 수행하지만 layer1에 트랜잭션 데이터 게시 속성 레이어1 외부에 트랜잭션 실행 데이터/트랜잭션 증거는 레이어1에 위치 레이어1의 트랜잭션 데이터를 사용하여 레이어2에서 올바른 트랜잭션을 시행할 수 있는 레이어1의 롤업 스마트 ..

※ 원글 작성 : 22년 4월 27일 Recursive Length Prefix 다양하고 복잡한 형식의 데이터를 하나의 정형화된 형식으로 직렬화 후 저장/전송 바이너리 데이터로 표현 이더리움 헤더의 state root, transaction root, receipt root 등과 통신 프로토콜 상 메시지 등 이더리움에서 전체적으로 사용 Definition 값이 단일 바이트일 경우, [0x00, 0x7f] 해당 바이트를 그대로 적용 String 길이가 0~55바이트인 경우 0x80 스트링 길이를 더한값을 앞에 붙이고 이어서 string을 붙임(dog = 0x80 + 0x03이 앞에) String이 55바이트를 초과하는 경우 0xb7 단일 바이트에 문자열 길이 바이트를 더한 다음, 문자열 길이 + strin..

※ 원글 작성 : 22년 4월 27일 이더리움 트랜잭션 구성 이더리움 트랜잭션 검증 방식 디지털서명 검증(ECDSA) 이더리움 account와 개인키의 소유자가 이더 지출 or contract를 이행했음을 승인 부인 방지(Non repudiation) 보장 트랜잭션이 서명된 후에는 트랜잭션 데이터가 수정되지 않았고 어느 누구도 트랜잭션 데이터를 수정할 수 없음 이더리움 nonce account를 가진 user가 트랜잭션을 생성시마다 1씩 증가, 중복된 트랜잭션을 만들지 않기 때문에 이중 지불 방지 비트코인은 account 기반이 아닌 UTXO 기반이기 때문에 트랜잭션 생성자의 nonce가 없음 (nonce는 블록 해시를 생성시에 임의의 값으로 존재) 트랜잭션 처리 과정 TX Pool 상의 transact..