본문 바로가기

Web3

블록체인 서비스기획 1주차 - 3일 수업 노트

비트코인 백서 분석

1. 9 page

2. 12 chapters, 9개 techs, 3개 intro, conclusion, calculation

 

Techs

  1. Transactions
  2. TimeStamp Server
  3. Proof of work(합의 알고리즘)
  4. Network
  5. Incentive(토큰 이코노미)
  6. Reclaiming Disk space
  7. Simplified payment verification
  8. Combining and Splitting Value
  9. Privacy

📌 이중지불문제(double-spending)

E.g. 복사본 파일을 보낸다? = 데이터의 사본이 전달된다. 

► 만약 가치저장의 수단인 돈이라면? 계속 복제되니까 늘어나는 양만큼의 실체가치는 1/N으로 감소하게 됨

► 돈을 보내면 내 지갑에서는 사라져야된다!

► 현재 은행에서는 데이터베이스 숫자 더하기 빼기 계산해서 디스플레이만 하는 것

 

비트코인 백서 레퍼런스 살펴보기

► Time stamp

► Security 등의 단어가 많이 언급됨

 

비트코인 초록/서론

► 이중지불 문제 해결 하기 위한 P2P 네트워크 + TimeStamp

► Tx-hash on chain(PoW) + TimeStamp

 

사토시가 제시하는 문제점

►중계기간 사실상 중재비용 증가

►최소 거래 규모 제한, 작은 일상거래 제한

►철회가능성 → 높은 신뢰수준 요구→ 상호 많은 정보를 요구

(E.g. 패스워드 변경, 패스워드 기준이 자꾸 높아짐... → 고객입장에서 불편 → 악순환)

 

그래서 우리에게 필요한 것

► 신뢰대신 암호학적 증명기반 전자지불 시스템 without TTP(Trusted Third Party)
     → 당사자간 직접거래 가능, 에스크로 메커니즘 쉽게 구현

 

✓ 에스크로 메커니즘?

구매자와 판매자 사이의 제3자가 구매자의 돈을 받아서 판매자가 물건을 보내기전까지 대금을 보관 + 수수료 지불
👉🏻 스마트컨트랙트를 사용하여 에스크로 매커니즘을 쉽게 구현하면 비용이 대폭 절감된다.

 

► 거래의 시간적 순서에 대한 계산적 증명 by 분산 타임스탬프 서버(=노드) → 이중지불 문제 해결

 

분산 타임스탬프가 찍는 것?

물리적인 시간 + 실제 블록체인에서의 block height!

트랜잭션 앞뒤의 전후관계를 확실하게 하기 위함 → 이중지불문제를 해결하기 위해서

 

거래(Transaction)

► 전자화폐(Electronic coin)을 전자서명의 체인으로 정의

 

거래1 소유자1의 공개키 → 해쉬 → 소유자0의 서명 : 소유자0이 1의 공개키를 이용해서 거래를 일으킴!

✓ 서명 : 어떤 해쉬값을 내 개인키를 암호화(해쉬)시키는 것 → 개인키가 개입되는 것

발신자 소유자0 → 수신자 소유자1 ; 이때 1의 개인키는 알 수 없지만 공개키를 가져와서 트랜잭션을 발생시킴

 

거래2 소유자2의 공개키 → 해쉬 → 소유자1의 서명 

거래3 소유자3의 공개키 → 해쉬 → 소유자2의 서명

...

👉🏻 똑같은 양의 비트코인이 이동했다고 했을 때 각각의 트랜잭션에서 소유자만 계속 바뀌는 것(name tag만 변경)

 

► 기존 시스템의 문제점

수취인이 이전 소유자들이 이중지불 여부 확인불가

해결책의 문제점은 전체 통화 시스템의 운명이 이 조폐국을 운영하는 회사에 의존해야 한다는 것

 

► 필요한 것

이전 소유자가 앞선 거래에 서명한 사실이 없음을 수취인이 확인할 수 있어야함

거래 부재확인의 유일한 방법은 '모든' 거래를 확인해야함

참가자들, 거래순서에 대한 단일 기록에 동의할 수 있는 시스템이 필요

 

타임스탬프 서버(Timestamp Server) =  노드

► 타임스탬프 서버는 타임스탬핑을 할 항목들의 블록에 대한 해시를 계산해 이를 신문이나 유즈넷(Usenet)포스트처럼 넓게 퍼뜨리는 방식으로 동작

→ 해당 시점에 그 데이터가 해시계산에 들어가기 위해서 명백히 존재했음을 증명

→ 각 타임스탬프는 이전 타임스탬프를 해시에 포함하여 각각의 추가 타임스탬프가 이전의 타임스탬프들을 보강 증명하는 체인을 형성

 

► 타임스탬프

해당 시점 항목이 명백한 존재 증명

거래 부재확인의 유일한 방법, 모든 거래 확인

참가자들, 거래순서에 대한 단일기록에 동의할 수 있는 시스템 필요

수취인, 매 거래마다 과반수의 노드들이 그것이 첫 사용 동의 증명 필요

 

작업증명(Proof- of- work)

► 해시캐시(Hash cash) 방식으로 작업증명은 SHA-256같은 것을 사용해 계산된 해시가 일정 개수의 0으로 시작하는 것을 찾는 작업
→ 일련의0을 포함하는 블록내의 nonce를 증가시키는 것으로 작업증명을 구현

→ 블록들은 체인으로 연결되기 때문에 하나의 블록을 변경하기 위해서는 그 이후 모든 블록들에 대한 작업증명을 다시 해야 한다.

 

► 작업증명은 한 CPU당 한표 방식 , 다수결에 의한 결정은 가장 긴 체인으로 나타냄

→ 블록의 해시값이 틀어지면 뒤에 해시값도 달라짐 ... 하나를 조작하려고 한다면 어차피 뒤에 나오는 블록들이 연결되지 않아 탈락됨

→ 순식간에 블록전체를 조작해야 조작할 수 있음

 

난이도(Difficulty)는 이동평균(Moving average)- 시간당 평균 블록생성 수 목표- 로 결정

→ 논스를 찾기 어렵게 하면 난이도가 올라감(첫번째0→두번째0...하나씩 더 찾으라고하면됨)  → 시간당 평균 블록생성이 감소

→ 2주단위(2016시간)로 파악해서 난이도를 조절함 → 목표 10분에 1개씩 생성되게끔 난이도를 조절함!

→ 유닉스 타임을 따라감!(😁썸머타임없음)

 

네트워크(Network)

► 네트워크 순서

Tx 브로드 캐스팅 → 각 노드들이 Tx 수집 → 작업증명(마이닝)

→ 마이닝성공노드가 블록 브로드캐스팅 → 승인 → 해당블록해시사용 다음 블록 마이닝으로 해당 블록 승인 표현

 

► 네트워크 특징

Tx 모든 노드에 도달할 필요 없음

블록 브로드캐스트 메시지 유실 감내(Tolerant)

블록 미 수령시 해당블록요청(Block height)

→ 수수료가 많은 비싼 Tx들 먼저 밈풀에서 골라서 Hash를 만들어 던짐 → 맞으면 승인해줌 → 그다음 블록으로 통과

 

📌 블록체인의 DDoS 공격?

블록체인 노드들에 DDoS공격을 할수가 있으므로 노드의 숫자가 보안에 중요한 역할을 함

노드 숫자가 적으면 서비스가 위험할 수 있음.

블록체인 프로그래밍의 특징은 반복문을 허용하지 않음.(이더의 경우는 가스비용도 적용되어 루프를 집중적으로 제한함)

 

📌 노드와 밸리데이터?

큰 의미에서는 노드안에 밸리데이터가 포함됨

대신 구분하는 이유는 밸리데이터는 주로 POS계열이라 구분

POW는 마이너 POS계열은 밸리데이터로 구분

 

인센티브(Incentive)

► 네트워크 유지수단으로 인센티브제공

► 중앙 발행기관이 부재하므로 처음 존재하는 Primary market이 된다

► 금 채굴과 유사(컴퓨터와 전기 사용)

► 보안 코인 + Sum(Tx 수수료)

정해진 수량 모두 발행시 → Tx 수수료 체제로 전환

► Inflation Free

► 인센티브는 노드들이 정직함을 유지하도록 함

► 큰 컴퓨팅 파워보유자: Fraud < 새코인 마이닝 ► 내가 조작하면 네트워크 신뢰성이 떨어져서 가치를 잃을 수 있음!

 

 

저장공간 재확보

UTXO(Unspend transaction)

Spend 된 것들은 모두 날려버린다!

 

간소화된 지불 검증

- Light node vs Full node ► head만 가지고 있음 vs 모든 Tx을 다 가지고 있음 

- 가지고 있지 않은 정보는 Full node에 요청

- 모두가 Full node를 유지하면 부하가 심해지기 때문

 

금액 병합과 분할

- 금액을 나누거나 합치기 가능

- 한거래 여러개의 입력과 출력 포함

- 거래 입력은 크거나 같은 값을 입력 ► 전달되야 하는 금액보다 무조건 크거나 같아야함. 아니면 Tx 일어나지 않음.

- 보통 입력: 더 큰 단일 또는 작은 여러개의 금액

           출력: 최대 2개 존재, 지불/거스름돈 두 가지가 일어남

 

프라이버시

- 공개키를 익명으로 보존

- 해당 거래를 특정인과 연결 불가

- 시간과 거래 규모는 공개되지만 거래자가 누구인지는 비공개 ► 증권거래소와 유사(정부공개수준과 유사)

 

결론

► 신뢰에 의존하지 않는 전자지불 시스템을 제안한다.

► 이 네트워크는 구조적이지않은 단순함에 있어서 견고하다. ► The network is robust in its unstructured simplicity.

 

 

그외 중요한 개념들

블록헤드의 구조(80byte)

- Bits: 비츠는 채굴의 성공 여부를 판단하는 정보

- Nonce: 채굴자들은 논스 값(=해답)

- Coinbase Tx: 채굴자가 이 블록을 생성한 댓가로 받는 보상을 자기 지갑으로 송금하는 1st Tx로 생성(보상 btc + Tx fee 총합)

 

 

난이도(심화)

- 난이도 : Genesis 블록보다 얼마나 어려워졌는지 표시

- Bits 계산: Bits 16진수 전환, 앞 2자리:지수, 뒤6자리:계수  ► 계산된 블록 해시값은 목표값보다 작다 ► 마이닝 성공

- 난이도는 2016 블록(대략 14일)이 생성시마다 조정

 

마이닝(Nonce 값 찾기)

- Bits의 조건을 만족하는 해쉬값 = 이전 블록의 해쉬값 + Nonce 조합 < Bits 조건을 만족하는 Nonce값 찾기

 

 ✓ 해쉬? 앞의 숫자가 0이 나올 때까지 여러가지 값들을 해쉬(암호화)

http://www.sha1-online.com/

 

SHA1 online

sha-1 md5 md2 md4 sha256 sha384 sha512 ripemd128 ripemd160 ripemd256 ripemd320 whirlpool tiger128,3 tiger160,3 tiger192,3 tiger128,4 tiger160,4 tiger192,4 snefru gost adler32 crc32 crc32b haval128,3 haval160,3 haval192,3 haval224,3 haval256,3 haval128,4 ha

www.sha1-online.com

📌 마이닝을 왜 해야할까요?

- 인센티브? 블록생성? ► 여러사람이 같이 참가 누구한명이 블록을 generate 시켜야한다면? 여러개의 노드들 중에서 한 명을 선택 ► 그 사람에게 블록생성 권한을 준다 왜 한명에게만 줄까? 여러사람이 합의하면 블록하나 생성하는데 너무 이해관계가 많아짐 
► 리더를 한명 뽑아서 블록생성 권한을 줌 ►인센티브를 몰아준다? 

그래서 다른 방식으로 리더를 뽑는 layer1 들이 탄생함 e.g. 알고랜드 : 랜덤하게 선택

공평하게 리더역할을 나눠주기 위해서 + 해싱파워에 워크를 집어넣어 에너지가 쌓여있음 ► 바꾸기 어려움

 

마이닝을 하는 이유 ► 리더를 한명 뽑기 위해서 ► 리더가 블록을 생성할 수 있는 권한을 가짐 

그러나 공평하게 뽑아야함 ► 워크를 열심히 한 사람 중 한 명을 뽑기로 함 탈중앙성을 확보하기 위해서

 

POS? proof of stake ► 스테이킹을 많이 한 사람이 리더가됨

 

UTXO

장점

- 확장성이 뛰어남

- 개인정보 보호가 확실, 모든 Tx 새 주소 생성

- UTXO가 각각의 입력을 추적, 간편함- 이중지불 식별 유용 ► spent가 일어나면 없어져버림

- 안전하고 검증 가능한 오프체인 트랜잭션을 가능

- 특정유형의 스마트계약(언어에 구애받지 않는 스마트계약)을 허용 - escrow

 

단점

- 높은 거래 수수료(개별 개별로 signing을 해야함)

- Dust 축적 가능 ► 금액이 너무 작을 때 지불하지 못하는 작은 금액들 ► 나중에 큰 combine 덩어리가능 ► 그전까지는 dust화...

- 공간효율 떨어짐

► 그럼에도 불구하고 이중지불 문제에 대해 굉장히 효과적임!

 

UTXO VS 계좌 기반 모델

개념 : 계좌기반 모델은 '단위' ► 각 사용자에 대해 별도 계좌 생성, 모든 계좌 추적, 항상 잔액 기억

          UTXO는 '객체' ► 한덩어리는 추적하기 쉽지 않으나 각각 개체! 각 객체 기록저장, 필요할 때 사용, 소유권은 통화를 보낼 때만 확인

트랜잭션 저장공간: 계좌기반모델은 불필요, UTXO는 많이 필요함(각각 객체, 숫자의 sum이 아니라 객체로 저장)

상태저장: 계좌기반모델은 노드, UTXO는 트랜잭션

보안: 계좌기반모델은 취약, UTXO는 뛰어남 ► 단위니까 단위만 바뀌면 계좌기반 모델의 금액이 변화 🔥 매우 안전함! 

트랜잭션계산: 계좌기반모델은 복잡(추적이 쉽지 않음). UTXO는 간단(spent되면 expire되므로 간단)

대량 트랜잭션 효율성: 계좌기반모델은 항상 효율적임, UTXO는 대량 트래픽은 효율이 매우 저하됨

 

► 목적과 특징이 매우 다름! 맞는 것을 찾아서 써야한다.