이더리움은 state transaction machine 을 이용한다. 그리고 nonce 를 사용해서 tx 순서를 지켜서 진행한다.
그래서 앞순서 tx 처리에 문제가 생기면, 뒷 tx 는 계속 pending 된다. 즉 이더리움은 tx 관리가 중요하고 어렵다. 하지만 비트코인은 UTXO 를 활용해서 spend, unspend 로 되어 있어서 tx 순서가 중요하지 않다.
tx 구성요소 4가지
version, inputs, outputs, locktime(tx 유효시점을 규정)
먼저 비트코인 버전은 보통 1인데 2인 경우도 있다.0x01000000 이 16진수 표현이고 1이다.
inputs 은 이전 트랜잭션의 출력 내용과 연관되어 있다. 즉 비트코인을 사용하기 위해서는 먼저 비트코인을 어딘가에서 받아야 한다. 입력에서 본인이 소유한 비트코인을 정확히 가리키기 위해 다음 두가지 상항이 필요하다.
이전에 내가 수신한 비트코인을 가리키는 참조 정보
그 비트코인이 나의 소유라는 증명
대부분 입력은 소유자 개인키로 만든 전자서명을 포함하고 있다. 입력은 여러개가 가능하다.
출력은 비트코인의 거래 후 종착지를 정의한다. 각 트랜잭션은 하나 이상의 출력을 갖고 있다. 출력은 비트코인 금액, 잠금 스크립트(ScriptPubkey) 로 구성되어 있다.
locktime 은 트랜잭션 전파 후 실행을 지연시키는 방법을 제공한다. 600000 의 록타임 값을 갖는 tx 는 600001 블록까지는 블록체인에 포함될 수 없다. 이것은 원래 빈번한 거래 상황을 위해 고안됐고 이후 보안상의 문제가 있음이 밝혀졌다. 입력에 포함된 시퀀스 값이 fffffff 이면 록타임 값은 무시된다. 그리고 록타임의 주요 문제는 록타임에 도달했을 때 트랜잭션 수신자가 트랜잭션이 유효한지 확신 할 수 없다는 점이다. 마치 시간이 많이 지나 부도 가능성이 있는 은행 수표와 유사.
스크립트
비트코인을 잠그고 해제하는 방법이 바로 비트코인의 전송 메커니즘이다. 잠근다는 것은 누군가에 비트코인을 주는 것이고 해제한다는 것은 내가 받은 비트코인을 소비하는 것이다.
스크립트는 프로그래밍 언어다. 주어진 명령어를 한번에 하나씩 스택 기반으로 처리한다.
명령어는 두종류다. element, operation
element 는 스크립트 실행 명령어 집합 안에서 사용되는 데이터를 의미한다. ex) DER 서명, SEC 공개키
operation 은 데이터에 대해 무언가를 한다. OP_CHECKSIG, OP_DUP, OP_HASH160 등이 있다.
OP_DUP 은 스택 위의 원소를 복사해서 만든 원소를 스택 위에 올린다. 즉 동일한 원소 2개가 스택 위에 올라가게 된다. p163
OP_HASH160 은 스택 위의 원소 1개를 가져와서 sha256 해시값의 ripemd160 해시값을 새로운 원소로 스펙 위에 추가한다.
OP_CHECKSIG 는 스택 위 2개 원소를 가져와서 첫 번째 원소는 공개키로, 두번째 원소는 서명으로 간주하여 서명을 공개키로 검증한다.
만약 검증되면 1을 스택 위로 올리고 그렇지 않으면 0을 올린다.
p2sh 스크립트
하나의 비밀키로 큰금액의 비트코인을 관리하면 위험하다. 그래서 다중서명(Multisig) 방식이 나왔다.
다중서명을 이해하려면 먼저 OP_CHECKMULTISIG 명령어를 이해해야 한다. 오피코드는 0xae 다. 이 명령어는 스택 위에 많은 서명과 공개키를 가져와서 유효한 서명의 수가 기준 이상인지 여부를 1과 0으로 반환한다.
다중서명의 문제점
동작은 하지만 비효율적이다. 어쨌든 n개 중 m개의 서명만으로 UTXO 를 사용할 수 있게 해서 비밀키 하나에 모든 비트코인을 보관하는 SPOF(Single Point Of Failure)를 제거한다.
다중서명에는 몇가지 문제점이 있다.
다중서명 잠금 스크립트는 서로 다른 많은 공개키를 갖고 있다. 그래서 잠금 스크립트가 매우 길어진다.
보통 p2pkh 출력보다 5~20배 더 긴 출력이 되기 때문에 이를 처리하는 노드는 더 많은 자원이 필요하다. 노드는 UTXO 집합을 항상 최신의 상태로 유지 관리하는 데 크기가 큰 잠금 스크립트는 그만큼 관리 비용이 증가한다.
크기가 매우 큰 잠금 스크립트가 가능하므로 이를 악용하여 다중서명을 다른 용도로 오용할 수 있다.
p2sh 스크립트
p2sh(Pay to Script Hash) 스크립트는 긴 주소와 긴 잠금 스크립트 문제를 해결하는 방법이다.
머클 트리
머클 트리
머클루트는 특정 트랜잭션의 블록 포함 여부를 알아내는 데 유용하며 이렇게 알아내는 과정을 '단순 지급 검증'이라고 한다.
'단순 지급 검증' 은 단점이 있다. 풀노드는 라이트 노드에게 포함증거를 전달하는데, 풀노드는 라이트 노드의 관심 트랜잭션을 알게 된다. 즉 트랜잭션에 있는 사용자 계정 정보가 알려진다.
머클 패트리샤 트리
이더리움 상태 저장을 위한 트리
패트리샤 트리와 머클트리의 복합형태
World state 는 하나의 트리 형태로 저장되며, 각 블록은 변경된 트리의 루트를 갖게 됌.
1) 머클 패트리샤 트리 배경
⚫ 블록체인 크기가 계속 증가시 많은 데이터 동기화 문제 – 해결 위해 암호 해시 기반 트리 자료구조
2) 머클 패트리샤 트리 활용처
⚫ World State를 하나의 트리 형태로 저장하기 위해 사용
⚫ 머클트리를 통해 하나의 루트 해시값을 이용하여 State의 무결성 검증 ⚫ Key-value 데이터베이스의 Indexing 검색 속도 향상
3) 머클 패트리샤 트리 장점
⚫ 전체정보 검색 필요 없이 연결된 키 값들을 따라 수정, 삭제, 검색을 통해 처리속도 개선, Light
Node도 Root 값만을 통해 거래 정보 검증 가능
블룸필터
위 단순지급검증 문제점을 해결하기 위한 방법이 있다. 라이트 노드가 풀 노드에게 관심 트랜잭션 집합만 알려주는 것이 아니라 이를 포함한 더 많은 트랜잭션이 있는 상위집합을 알려주는 것이다. 이런 상위집합을 알려주기 위해서 블룸 필터를 사용한다.
블룸 필터는 상위 집합에 포함되는 트랜잭션을 선정하는 필터다.
예를 들어 50개 트랜잭션이 있다고 하자. 그중 라이트 노드의 관심 대상인 트랜잭션은 1개다. 라이트 노드는 50개 트랜잭션을 각각 5개씩 10개 그루으로 나눈다. 그러면 10개 그룹 중 한 그룹에 관심 트랜잭션이 있을 것이고 풀 노드에게 이 그룹만을 알려준다. 그러면 풀 노드는 라이트 노드의 관심 대상인 트랜잭션은 알 수 없다.
이를 위해서는 50개의 트랜잭션을 10개의 서로 다른 그룹으로 나누는 필터 함수가 필요하며 풀 노드는 그중에서 관심 트랜잭션이 포함된 한 그룹을 보낸다고 할 수 있다.
블룸필터는 전처리 과정에서 많이쓰인다. 해싱을 통해 나온 값을 인덱스로 해서, 배열을 1로 채우는 흔한 원리다.
해시 충돌 이슈도 있고 하니, 1로 채워진 값이 진짜 그 value 라고 장담할 순 없다. 그래서 "원소가 집합에 속해 있지 않은데 속했다고 말할 가능성이 있다(긍정오류)".
하지만 원소가 집합에 속해 있는데, 속하지 않다고 말하지는 않는다(부정오류). 그래서 엄청 큰 집합안에 원소가 속해 있는지 검사하는 비용을 아끼기 위해 전처리로 사용할 수 있다.
정리하면, 특정 원소가 집합에 없다면 진짜 없는것이다. 하지만 있다고 하면 보장못함
싱글톤 컴퓨터
이더리움을 글로벌 싱글톤 컴퓨터라고 부르는 이유
1) 이더리움에서 스마트 계약 작동 방식
⚫ 스마트 계약을 작성하여 네트워크에 전파하면 동일한 스마트 계약이 모든 노드에 전파되어 저장
⚫ 스마트 계약을 실행하면, 네트워크 모든 노드가 동일한 연산을 수행하여 동일한 결과값 도출 및 저장
2) 글로벌 싱글톤 컴퓨터라 부르는 이유
⚫ 네트워크에 참여한 모든 노드들이 동일한 상태와 동일한 연산 수행하고 동일 결과 저장
⚫ 여러 대의 컴퓨터가 하나의 싱글톤 컴퓨터 역할을 함, 즉 저장된 프로그램 컴퓨터의 범용 컴퓨팅
아키텍처와 탈중앙화된 블록체인을 결합하여 탈중앙화된 단일 상태 월드 컴퓨터 구현
networking
하이브리드 P2P 네트워크
별도 서버에 인덱스 정보 저장됨
최초 인덱스는 client-server 방식이지만 자료 공유는 P2P
개발/관리 편하지만 서버 노드의 의존성에 의한 내결함성과 확장성 떨어짐
순수 P2P 네트워크
별도의 정보를 저장하는 서버 없이 노드 검색 기능 수행
오버레이 네트워크
블록체인의 데이터 교환에 필요한 네트워크 구성은 오버레이 방식으로 한다. 오버레이는 어떤 의미?
비구조화 오버레이
각 인접노드를 알아서 선택
토폴로지가 규정되지 않음
유연성 있는 데이터 전달 가능
메세지 전달 보장 못함
노드 증가에 따라 메세지 양이 증가하여 확장성이 약함
블록체인은 비구조화 오버레이를 따름
구조화 오버레이
연결 상대가 미리 정해짐
특정 알고리즘에 따라 네트워크 토폴로지가 결정됨
노드 식별자에 따라 연결 상대가 결정됨
메세지 수신을 보장하고 확장성이 높음
네트워크 구성의 유연성이 떨어짐
블록체인 P2P 네트워크
동등한 토폴로지를 통해 네트워크를 이룬다. 중앙화나 위계질서 없다. 서비스를 제공함과 동시에 서비스를 이용한다. 분산장부의 공공성을 확보한다. 회복력이 있다(SPOF 저항성) 분산 저장을 기반한 보안성.
옴머블록, 고스트 프로토콜
옴머블록 : 동일한 시점에 채굴된 블록 중 채굴 난이도가 낮아 메인 체인에 연결되지 못한 블록
블록생성 시간이 빠를수록 옴머 블록 발생확률이 높음
고스트 프로토콜: 옴머 블록의 문제점을 개선하기 위한 프로토콜. 제네시스 블록부터 시작하여 가장 많은 sub-tree 를 가진쪽을 선택하도록 함
메타버스 and Web 3.0
플랫폼사의 중개 수수료 문제 및 보안 문제(개인정보 유출)
유틸리티 토큰
ERC-20 표준
토큰 총량을 공개하고 제한함
토큰 소유권을 명확하게 함
토큰 전송을 검증함
등등
DID
Web 2.0 :
ID/PW 생성
내 개인정보 입력
플랫폼에 개인정보 보관 및 우려. 개인정보 보호 방침 마련 필요
Web 3.0 :
내 개인키를 통한 로그인
회원가입, 로그인 필요없음
일체의 개인정보 제공 필요 없음
플랫폼 내 익명성 보장
필요시 제한된 정보만 제공
결론(Web 3.0 아키텍처와 고객)
Web 2.0 : Customers must accept the rules in Closed Environment as a Guest.
Web 3.0 : Customers are in the Community in Open & Public Environment as a n Owner.
트랜잭션
이더리움은 state transaction machine 을 이용한다. 그리고 nonce 를 사용해서 tx 순서를 지켜서 진행한다. 그래서 앞순서 tx 처리에 문제가 생기면, 뒷 tx 는 계속 pending 된다. 즉 이더리움은 tx 관리가 중요하고 어렵다. 하지만 비트코인은 UTXO 를 활용해서 spend, unspend 로 되어 있어서 tx 순서가 중요하지 않다.
tx 구성요소 4가지 version, inputs, outputs, locktime(tx 유효시점을 규정)
먼저 비트코인 버전은 보통 1인데 2인 경우도 있다.
0x01000000이 16진수 표현이고 1이다.inputs 은 이전 트랜잭션의 출력 내용과 연관되어 있다. 즉 비트코인을 사용하기 위해서는 먼저 비트코인을 어딘가에서 받아야 한다. 입력에서 본인이 소유한 비트코인을 정확히 가리키기 위해 다음 두가지 상항이 필요하다.
대부분 입력은 소유자 개인키로 만든 전자서명을 포함하고 있다. 입력은 여러개가 가능하다.
출력은 비트코인의 거래 후 종착지를 정의한다. 각 트랜잭션은 하나 이상의 출력을 갖고 있다. 출력은 비트코인 금액, 잠금 스크립트(ScriptPubkey) 로 구성되어 있다.
locktime 은 트랜잭션 전파 후 실행을 지연시키는 방법을 제공한다. 600000 의 록타임 값을 갖는 tx 는 600001 블록까지는 블록체인에 포함될 수 없다. 이것은 원래 빈번한 거래 상황을 위해 고안됐고 이후 보안상의 문제가 있음이 밝혀졌다. 입력에 포함된 시퀀스 값이
fffffff이면 록타임 값은 무시된다. 그리고 록타임의 주요 문제는 록타임에 도달했을 때 트랜잭션 수신자가 트랜잭션이 유효한지 확신 할 수 없다는 점이다. 마치 시간이 많이 지나 부도 가능성이 있는 은행 수표와 유사.스크립트
비트코인을 잠그고 해제하는 방법이 바로 비트코인의 전송 메커니즘이다. 잠근다는 것은 누군가에 비트코인을 주는 것이고 해제한다는 것은 내가 받은 비트코인을 소비하는 것이다.
스크립트는 프로그래밍 언어다. 주어진 명령어를 한번에 하나씩 스택 기반으로 처리한다. 명령어는 두종류다. element, operation
element 는 스크립트 실행 명령어 집합 안에서 사용되는 데이터를 의미한다. ex) DER 서명, SEC 공개키 operation 은 데이터에 대해 무언가를 한다.
OP_CHECKSIG,OP_DUP,OP_HASH160등이 있다.OP_DUP은 스택 위의 원소를 복사해서 만든 원소를 스택 위에 올린다. 즉 동일한 원소 2개가 스택 위에 올라가게 된다. p163OP_HASH160은 스택 위의 원소 1개를 가져와서 sha256 해시값의 ripemd160 해시값을 새로운 원소로 스펙 위에 추가한다.OP_CHECKSIG는 스택 위 2개 원소를 가져와서 첫 번째 원소는 공개키로, 두번째 원소는 서명으로 간주하여 서명을 공개키로 검증한다. 만약 검증되면 1을 스택 위로 올리고 그렇지 않으면 0을 올린다.p2sh 스크립트
하나의 비밀키로 큰금액의 비트코인을 관리하면 위험하다. 그래서 다중서명(Multisig) 방식이 나왔다. 다중서명을 이해하려면 먼저
OP_CHECKMULTISIG명령어를 이해해야 한다. 오피코드는0xae다. 이 명령어는 스택 위에 많은 서명과 공개키를 가져와서 유효한 서명의 수가 기준 이상인지 여부를 1과 0으로 반환한다.다중서명의 문제점 동작은 하지만 비효율적이다. 어쨌든 n개 중 m개의 서명만으로 UTXO 를 사용할 수 있게 해서 비밀키 하나에 모든 비트코인을 보관하는 SPOF(Single Point Of Failure)를 제거한다.
다중서명에는 몇가지 문제점이 있다.
p2sh 스크립트 p2sh(Pay to Script Hash) 스크립트는 긴 주소와 긴 잠금 스크립트 문제를 해결하는 방법이다.
머클 트리
머클 트리 머클루트는 특정 트랜잭션의 블록 포함 여부를 알아내는 데 유용하며 이렇게 알아내는 과정을 '단순 지급 검증'이라고 한다. '단순 지급 검증' 은 단점이 있다. 풀노드는 라이트 노드에게 포함증거를 전달하는데, 풀노드는 라이트 노드의 관심 트랜잭션을 알게 된다. 즉 트랜잭션에 있는 사용자 계정 정보가 알려진다.
머클 패트리샤 트리 이더리움 상태 저장을 위한 트리 패트리샤 트리와 머클트리의 복합형태 World state 는 하나의 트리 형태로 저장되며, 각 블록은 변경된 트리의 루트를 갖게 됌.
블룸필터
위 단순지급검증 문제점을 해결하기 위한 방법이 있다. 라이트 노드가 풀 노드에게 관심 트랜잭션 집합만 알려주는 것이 아니라 이를 포함한 더 많은 트랜잭션이 있는 상위집합을 알려주는 것이다. 이런 상위집합을 알려주기 위해서 블룸 필터를 사용한다.
블룸 필터는 상위 집합에 포함되는 트랜잭션을 선정하는 필터다. 예를 들어 50개 트랜잭션이 있다고 하자. 그중 라이트 노드의 관심 대상인 트랜잭션은 1개다. 라이트 노드는 50개 트랜잭션을 각각 5개씩 10개 그루으로 나눈다. 그러면 10개 그룹 중 한 그룹에 관심 트랜잭션이 있을 것이고 풀 노드에게 이 그룹만을 알려준다. 그러면 풀 노드는 라이트 노드의 관심 대상인 트랜잭션은 알 수 없다.
이를 위해서는 50개의 트랜잭션을 10개의 서로 다른 그룹으로 나누는 필터 함수가 필요하며 풀 노드는 그중에서 관심 트랜잭션이 포함된 한 그룹을 보낸다고 할 수 있다.
블룸필터는 전처리 과정에서 많이쓰인다. 해싱을 통해 나온 값을 인덱스로 해서, 배열을 1로 채우는 흔한 원리다. 해시 충돌 이슈도 있고 하니, 1로 채워진 값이 진짜 그 value 라고 장담할 순 없다. 그래서 "원소가 집합에 속해 있지 않은데 속했다고 말할 가능성이 있다(긍정오류)".
하지만 원소가 집합에 속해 있는데, 속하지 않다고 말하지는 않는다(부정오류). 그래서 엄청 큰 집합안에 원소가 속해 있는지 검사하는 비용을 아끼기 위해 전처리로 사용할 수 있다.
정리하면, 특정 원소가 집합에 없다면 진짜 없는것이다. 하지만 있다고 하면 보장못함
싱글톤 컴퓨터
이더리움을 글로벌 싱글톤 컴퓨터라고 부르는 이유
networking
하이브리드 P2P 네트워크
순수 P2P 네트워크
오버레이 네트워크
블록체인 P2P 네트워크
옴머블록, 고스트 프로토콜
옴머블록 : 동일한 시점에 채굴된 블록 중 채굴 난이도가 낮아 메인 체인에 연결되지 못한 블록 블록생성 시간이 빠를수록 옴머 블록 발생확률이 높음
고스트 프로토콜: 옴머 블록의 문제점을 개선하기 위한 프로토콜. 제네시스 블록부터 시작하여 가장 많은 sub-tree 를 가진쪽을 선택하도록 함
메타버스 and Web 3.0
플랫폼사의 중개 수수료 문제 및 보안 문제(개인정보 유출)
유틸리티 토큰
ERC-20 표준 토큰 총량을 공개하고 제한함 토큰 소유권을 명확하게 함 토큰 전송을 검증함 등등
DID
Web 2.0 :
Web 3.0 :
결론(Web 3.0 아키텍처와 고객)
Web 2.0 : Customers must accept the rules in Closed Environment as a Guest. Web 3.0 : Customers are in the Community in Open & Public Environment as a n Owner.