※ 원글 작성 : 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..

※ 원글 작성 : 22년 4월 26일 Algorithm & Protocol SPV node SPV 노드는 체인의 전체를 받지 않고 헤더만 다운로드 하여 노드의 스토리지 부담이 적음, 1/1000 수준 (그래도 크다...) 블록헤더 상에는 머클루트가 포함되어 있기 때문에 각 트랜잭션의 포함 여부를 알 수 있음 Bloom filter 특정 원소가 포함되어 있는지 확인하는 확률형 자료구조 집합의 크기가 크거나 원소가 많을 경우 정확히 파악하는게 힘들기 때문에 전처리로 집합 내에 포함되지 않을 원소들을 미리 제거 가능 SPV노드 상에서 Filter 사용 SPV노드가 지갑주소가 포함된 특정 거래 정보를 요청 시에 주변 노드에게 전파되어 자신의 정보를 노출할 수 있음 Segwit Segregated Witness ..

※ 원글 작성 : 22년 4월 26일 UTXO 비트코인 트랜잭션 내에 출금이 이루어지지 않은 기록 Wallet은 사용자의 계좌 상에 오고 간 전체 입출금 기록을 확인하여 거래 목록을 추적 Wallet 상의 balance는 UTXO의 합으로 표현 UTXO model & Account model 대표적으로 전자는 비트코인, 후자는 이더리움 Account model은 각 사용자의 계정 상 잔액을 글로벌로 retrieve UTXO 장점 확장성 : 동시에 tx처리 가능 프라이버시 : Account에 비해 개인정보 보호 Account 장점 단순성 : State 추적 가능, state를 저장하지 않는 모델은 거래처리 및 조회가 복잡 효율성 : Account의 잔액만 확인하여 출금 진행 가능 (이중지불이 발생할 수 있..

※ 원글 작성 : 22년 4월 26일 Base PoW & PoS safety와 liveness Safety : 블록체인을 구성하는 문제가 없는 노드들 사이에서는 잘못된 합의가 이루어지지 않음 Liveness : 문제가 없는 노드들은 반드시 합의를 함 PoW : 현재 노드가 보유하고 있는 체인보다 더 긴 체인이 존재할 경우(더 긴 체인을 만들 해시파워가 존재할 경우) 언제든지 긴 체인으로 변경 Finality가 보장되지 않음 Liveness를 위해 safety를 희생 Casper : 기존의 PoW로 liveness를 보장하고, 50블록마다 투표하여 (epoch) safety가 보장되는 지점을 생성 블록체인 트릴레마 확장성 : 블록체인이 사용자 수, 트랜잭션/블록 수 등이 증가함에 따라 기존 수행능력을 보유..