Blockchain & Bitcoin concept [3] (Algorithm, Protocol, Scalability)

※ 원글 작성 : 22년 4월 26일

Algorithm & Protocol

SPV node

• SPV 노드는 체인의 전체를 받지 않고 헤더만 다운로드 하여 노드의 스토리지 부담이 적음, 1/1000 수준 (그래도 크다...)
• 블록헤더 상에는 머클루트가 포함되어 있기 때문에 각 트랜잭션의 포함 여부를 알 수 있음

Bloom filter

• 특정 원소가 포함되어 있는지 확인하는 확률형 자료구조
• 집합의 크기가 크거나 원소가 많을 경우 정확히 파악하는게 힘들기 때문에 전처리로 집합 내에 포함되지 않을 원소들을 미리 제거 가능
• SPV노드 상에서 Filter 사용
  • SPV노드가 지갑주소가 포함된 특정 거래 정보를 요청 시에 주변 노드에게 전파되어 자신의 정보를 노출할 수 있음

Segwit

• Segregated Witness
• 블록 내 디지털 서명 정보가 차지하는 비율이 큼
• 서명부분을 witness 데이터 형식으로 변환하여 더 많은 거래 데이터를 처리할 수 있도록 비트코인 업데이트 진행
• Soft fork로 진행했음

HD wallet

• BIP32 표준 상 정의
• Root seed로 부터 생성. 부모키가 자식키를, 자식키가 손자키를 생성 가능(계층적 생성)
• HD wallet은 트랜잭션 마다 새로운 주소를 생성, 개인정보 보호목적
• BIP32 HD wallet → BIP 39 니모닉 코드 단어 → BIP 43 다목적 HD 지갑 구조 → BIP 44 복수화폐 및 복수계정 지갑

Bech32

• BIP173에 명시된 비트코인 주소 형식
• 장점
  • 대소문자 구분하지 않음
  • 주소 QR코드 변환 시 크기가 더 작음
  • Segwit의 전체 성능을 사용할 수 있음
• 문자열 구성
  • 최대 90자
  • HRP(Human-Readable Part)
    • 1-83자의 US-ASCII문자가 포함되어야 하며, 각 문자는 [33-126] 범위를 가져야 함
    • HRP 유효성은 특정 용도에 의해 더욱 제한될 수 있음
  • Seperator : 사람이 읽을 수 있는 부분안에 "1"이 허용되는 경우, 문자열 마지막 부분은 구분기호 "1"
  • Data : 길이가 최소 6자고, "1","b","i""o"를 제외한 영숫자로만 구성
• 주소는 bc1로 시작, 해당 접두사 때문에 기존 주소나 P2SH 주소보다 김
• 기본 Segwit 주소 형식

Ghost protocol

• Greedy Heaviest Object Subtree Protocol
• 메인체인 선택 시 가장 긴 체인을 선택하는 알고리즘
• 블록을 트리형태로 생성하여 해당 블록의 부모블록들로 가중치 값을 계산하여 블록 길이 선택
• 특징
  • 속도가 느린 블록체인은 고아블록(엉클블록) 생성확률이 낮아 보안성 높고, 블록생성이 빠른 블록체인은 고아블록 생성확률이 높음
  • 고스트 프로토콜은 어느체인이 가장 긴 것인지 계산할 때 고아블록도 포함하며 네트워크 보안 손실 문제를 해결
  • 어느 블록이 가장 큰 PoW를 가지고 있는지 계산함에 있어 부모+고아+자손블록을 더함

Anchoring

• 프라이빗, 사이드체인 BC에 기록된 데이터의 해시값을 주기적으로 퍼블릭 BC에 포함
• 프라이빗 해킹을 방지하기 위해 거래 데이터 또는 블록 데이터의 해시값을 주기적으로 퍼블릭에 포함시켜 데이터 위변조 방지

Epoch

• 블록체인 검증인들이 검증작업을 진행하는 체크포인트의 블록 간격
• 다수의 블록을 하나의 단위로 묶음(블록 50개 정도)
• 이더리움은 전용 채굴기(ASIC)를 사용할 수 없도록 일정 시간마다 알고리즘을 변경, 그 시간 간격을 epoch이라 함
• 특징
  • 완결성 : 두개의 완료된 경쟁 체크포인트가 존재하지 않도록, 완결이 잘못되면 검증자의 1/3 슬래싱
  • 타당성 : 검증자가 체크포인트에 투표하고 어떤것이 헤드가 될것인지 결정P2PKH
• Pay to Public Key Hash
• 비트코인 내에서 가장 일반적인 스크립트 형식으로 비트코인 프로토콜에 대한 지불 거래 유형
• 주소는 1로 시작
  • Segwit을 지원하는 새로운 주소 3또는 BC1로 시작하는 주소보다 비쌈
  • 공개키의 간단한 hash이며 이를 주소로 사용 가능
• 거래 방식
  • P2PKH는 alice가 전형적인 비트코인 주소로 사토시를 보낼 수 있도록 함
  • Bob은 암호화키 쌍을 사용하여 사토시를 추가로 사용할 수 있음
  • Bob이 먼저 공개/개인키쌍을 작성하여 alice가 일부 사토시를 보낼 수 있게 함(비트코인 ECDSA 사용)
  • Bob은 공개키의 암호화 해시를 생성
  • Bob은 공개키의 hash를 alice에게 보냄, 해시는 비트코인 주소로 인코딩
  • alice는 bob의 주소를 가지므로 트랜잭션 생성 가능
  • P2PKH 트랜잭션 출력에는 bob의 이전 생성 개인키를 제어하는 모든 사람에 대한 권한이 포함(이런 명령어를 Pubkey script or scriptPubkey라 함)
  • Alice는 블록체인에 추가할 트랜잭션을 broadcast, 트랜잭션은 UTXO로 인식
  • Bob의 지갑에는 이 UTXO의 금액이 지출 가능한 금액으로 표시
  • Bob은 이 금액 중 일부를 사용하기로 하면 alice는 거래 해시와 해당 출력 번호를 만들고 서명 스크립트를 작성

Scalability

Scalability 방안

phemex.com

TPS 증가

• Segwit
  • 거래 서명 데이터를 줄여 더 많은 트랜잭션 정보를 블록에 추가
• Sidechain
  • 메인체인 기능 보조
  • 오프체인
    • 블록체인 네트워크를 사용하지 않고 트랜잭션을 발생시켜 사전 거래를 진행
    • 차후 온체인과 연동하여 최종 검증을 통해 블록 생성
• Consensus algorithm 변경

Sidechain

• Main chain과 상이한 consensus algo, 검증방식, 추가기능(추가 스토리지 업션, 허가형 접근, 영지식증명, 대안적 수수료)을 탑재 가능
• 사이드체인 사용 이유
  • DB로의 접근
    • 시스템에 상당량의 거래, 데이터 로드가 있는 경우 데이터 저장, 접근 방식을 맞춤형으로 구성 필요
    • (사용자 정보)빠른 읽기 액세스를 위한 수평적 샤딩된 NoSql/(거래정보)빠른 query를 위해 많이 인덱싱된 RDB/(미디어파일)블록 스토리지/(관계데이터) Graph DB 등 데이터 형식에 따른 다양한 기능으로 세분화
  • MSA로의 접근
    • 여러 어플리케이션이 기능적으로 API, RPC, Queue, DB, 서버리스 함수 호출 등 워크 플로우 조정
    • 어플리케이션의 확장과 새로운 기능 추가 쉽게함
    • 변경 내용을 쉽게 분리 가능해 개발 속도 up, 업데이트 주기 빨라짐
• 사이드체인 장점
  • 개발 민첩성 향상
    • 분산화된 앱과 프로토콜을 쉽게 개발, 적용 빠름
    • 상태관리/작업 동기화를 위한 효과적인 인터체인 메시징 솔루션을 사용하면 런칭 빨라짐
  • 성능향상
    • 거래종류에 맞게 최적화 가능
    • 각 이벤트(자산 담보화, 시장 조성, 게임 플레이 등)는 상이한 거래 커밋 시간을 가져서, 데이터/거래 종류에 맞게 여러 사이드 체인에서 실행하면 성능 향상 가능
  • 네트워크 경제성 향상
    • 모든 거래를 메인넷에 담는것은 비쌈
    • 최종 상태의 거래를 메인넷에 적용시켜 경제성을 향상
  • 스토리지 향상
    • 스토리지 요금/커밋시간/액세스 및 조회 매커니즘을 고려하여 적절한 스토리지 위치로 데이터 R/W 최적화 가능

참고
http://wiki.hash.kr/index.php/%EB%8C%80%EB%AC%B8
https://skale.network/blog/danil-hyeongsig-vs-meolticein-wae-jeogjeolhan-diaeb-akitegceoga-jungyohanga
https://www.sciencedirect.com/science/article/pii/B9780128198162000150