5 분 소요

Public blockchain Security Threat & Scalability Issues

Table of Contents

  • Security Threat Analysis
  • Scalability Issues

오늘의 주제는 퍼블릭 체인에서의 보안 위협 분석과 확장성 문제, 현재 알려진 확장성 문제 솔루션에 대한 소개 & 위협과의 연관성에 대해 소개한 논문을 읽고 정리하려고 합니다.

Public Blockchain을 간단하게 설명하면
시스템을 관리하는 중앙기관 대신 네트워크 사용자들의 합의에 기반하여 시스템을 유지합니다.
신뢰할 수 없는 사용자 간의 합의 기술 : PoW 방식으로 신뢰성 보장하지만 제한된 처리량을 가지게 됩니다.
그 이유는 기본적으로 누구나 블록 후보를 만들어 제출하기 때문에 네트워크에서 블록을 공유하는 시간이 있고 너무 많은 블록을 동시에 만들어지면 하나의 블록을 선택하기 어렵기 때문입니다.

이러한 제한된 처리량으로 인증받지 못하는 상태에서 계속 처리가 지연되어 보안성이 떨어지게 됩니다. 그래서 제한된 처리량으로 인한 확장성 문제 해결의 필요성을 분석하고 대표적인 해결방법을 알아보겠습니다.

1. Public Blockchain Security Threat

Public Blockchain 공격 목적

  • 이중 지불
  • 블록 채굴 보상 시스템 상의 개인 혹은 단체가 독점
  • 결제 시스템 자체를 무력화

Public Blockchain 공격 유형

  • 이중 지불
  • 블록 보류
  • 네트워크 지연



※ Public Blockchain 공격 유형

우선! 비트코인 결제 시스템에서의 유효한 거래 기록으로 간주하는 경우를 보겠습니다.

생성한 트랜잭션이 miner에 의해 블록에 포함되어 네트워크에 전파되고 해당 블록을 이전 블록으로 하는 새로운 블록이 6개 이상 추가되었을 경우 (6-Confirmations)
=> 동일한 블록을 이전 블록으로 하는 블록이 2개 이상 존재할 경우 일시적으로 네트워크에 분기(fork)가 발생하기 때문입니다. => 먼저 새로운 블록이 연결되는 블록체인이 주 체인이되는 경쟁이 시작되는 메커니즘을 따르기 때문입니다.

그렇기 때문에! 매 10분마다 하나의 블록이 추가되는 비트코인 시스템의 특성상 6개의 승인을 얻기 위해서는 1시간이 필요합니다.
그래서 나온 것이 zero comfirmation을 사용하는 것입니다. (소액 거래의 경우 트랜잭션이 블록에 포함되는 것만 확인하는 것)

-> 이러한 제로 컨펌을 기반으로 하는 공격들을 살펴보겠습니다.



1) 이중지불

이중 지불이란 이미 소비된 코인은 다른 거래에 사용될 수 없어야 하지만 이미 사용된 코인을 재사용하는 것

모든 코인은 고유한 식별정보(transaction identifier)를 가짐


기본적으로 화폐와 달리 디지털데이터로서 무단 복사 및 해킹 등 취약합니다.
그래서 사용자의 거래기록을 하나의 공개 장부로 만들어 블록체인으로 저장하고 네트워크의 모든 사용자가 이를 유지하고 관리하는 것입니다.

< 분기를 이용한 기본적인 이중 지불 시나리오 >

  1. 이중 지불 공격자 A는 판매자 V의 물품 구입을 위한 대금 지불 트랜잭션 ㄱ 을 생성하여 블록체인 네트워크에 전파
  2. 동시에 동일한 비트코인을 소비하는 트랜잭션 ㄴ을 생성하여 네트워크에 전파(자신에게 보내는 것)
  3. 판매자는 네트워크에 전파된 정상 거래 트랜잭션 ㄱ이 블록에 포함된 것을 확인하고 물품을 전달
  4. But 동시에 이중 지불 트랜잭션 ㄴ이 정상 거래 트랜잭션 ㄱ과 다른 블록에 포함되어 분기가 발생
    => 동일한 UTXO 정보를 사용한 트랜잭션을 한 블록에 담을 수 없음
  5. 이후 경쟁에서 정상 거래 트랜잭션이 포함된 블록이 경쟁에서 패배할 경우 정상 거래 트랜잭션 ㄱ은 취소
  6. 공격자는 코인의 소비 없이 물품을 구매할 수 있음


이와 같은 공격과정에서 공격의 성공은 3가지 등의 영향을 받습니다.

  • 분기의 발생 여부
  • 분기의 발생 시점
  • 분기 발생 이후 경쟁에서 공격 트랜잭션의 승리

결론부터 이야기하면, 공격에 성공할 확률을 매우 낮습니다.

=> 정상 트랜잭션과 공격 트랜잭션이 네트워크에 동시에 존재하더라도 정상 트랜잭션이 먼저 블록에 포함되어 모든 네트워크에 전파 (분기의 발생 여부, 분기의 발생 시점) : 실패

=> 그런데, 만약 분기가 발생하였거나 공격 트랜잭션이 먼저 블록에 포함되어 있어도 경쟁에서 질 경우 : 실패



블록 보류(Block Withholding)

블록 보류는 이중 지불 트랜잭션의 생성 이후 공격자가 공격 성공률을 높이기 위해 공격에 관여하고 최종적으로 분기된 이중 지불 트랜잭션의 블록이 경쟁에서 승리하도록 유도하는 것입니다.

[블록 보류를 통한 이중 지불 공격인 Finney 공격 시나리오]

  1. 공격자 A는 사전에 이중 지불 트랜잭션 ㄴ을 포함한 블록 B를 생성함
  2. 생성한 블록을 네트워크에 전파하지 않고 보관한 뒤 정상적인 지불 트랜잭션 ㄱ을 네트워크에 전파하고 판매자 V에게 확인될 때까지 대기함
    => 0컨펌 내역이 있는지 확인하더라도 공격자의 의도 파악하기 어려움
  3. 판매자에게 확인된 이후 사전에 생성된 블록 B를 네트워크에 전파하여 분기를 발생시킴
  4. 이후의 경쟁에서 B가 승리하여 주 체인이 될 경우 정상적인 트랜잭션을 포함한 블록 A에 포함된 트랜잭션들은 취소되고 공격자는 이중 지불 공격에 성공 가능



3) 네트워크 지연

네트워크 지연은 2가지의 공격을 소개하고 이러한 공격들을 이용하여 공격자는 임의의 분기를 발생시키고 원하는 분기 블록을 경쟁에서 승리하도록 유도하여 이중 지불 공격 혹은 다른 공격에 성공하도록 하는 것이 가능합니다.

  • 시빌 공격(sybil attack)
  • 이클립스 공격(eclipse attack)

시빌 공격(sybil attack)

공격자는 네트워크 더미 노드를 설치하여 자신의 블록이 보다 빨리 전체 네트워크에 전파되도록 하고 경쟁 블록은 전파하지 않음으로써 네트워크에서 공격자의 블록의 점유율이 증가하도록 유도합니다.

이클립스 공격(eclipse attack)

특정한 개인 혹인 집단의 P2P 네트워크에서의 연결을 공격자가 제어 가능한 노드만으로 구성되도록 유도하여 특정 대상을 블록체인 네트워크로부터 고립되도록 하여 공격자가 원하는 데이터만 대상에게 전달되도록 하는 것입니다.

2. Public Blockchain Scalabiliy

Public Blockchain 확장성 접근방법

  • 파라미터 재설정
  • 페이먼트 채널

확장성이 나오게 된 이유

- 비트코인 시스템이 평균적으로 10분에 하나의 블록 처리
- 블록의 최대 크기 1MB
- 포함되는 트랜잭션이 2개의 입력과 3개의 출력 <br>

이 3가지 가정을 한다면, 특정 시간대에 처리를 기다리는 트랜잭션의 수가 시간당 최대 처리량을 초과할 경우 처리되지 못한 트랜잭션 평균 대기 시간보다 더 오랜 시간을 대기하거나 처리되지 못할 가능성이 존재합니다.
따라서 IOT와 같은 방대한 데이터를 처리하는 분야에 이러한 시스템을 그대로 적용할 경우 확장성 문제에 직면할 수 있습니다.

앞에 언급된 많은 공격은 무엇에 기반?

- 트랜잭션 처리 지연 혹은 분기된 트랜잭션의 취소에 기반
- 지연이나 분기의 증가에 따라 공격 확률이 증가하므로 치명적일 수 있음

-> 이러한 확장성 문제에 대한 대중적인 접근방법 중 파라미터 재설정과 페이먼트 채널에 대해 소개하겠습니다.



1) 파라미터 재설정(Repartmeterization)

2가지의 방법과 방법에 대한 또 다른 문제가 발생할 가능성에 대한 내용을 알아보겠습니다.

  • 블록의 최대 크기를 증가시켜 블록에 포함되는 트랜잭션의 수를 증가

블록의 크기가 증가할수록 모든 네트워크 노드가 블록을 수신하는데 걸리는 시간이 증가(전파 지연)

지연 시간의 증가는 하나의 블록이 네트워크에 전파되는 도중에 새로운 블록의 전파가 발생하는 분기의 발생 확률이 증가함을 의미


  • 새로운 블록 추가에 필요한 생성 주기를 감소

실질적으로 전체 처리량을 증가시킬 수 있지만 생성 주기의 감소를 위해서는 PoW의 난이도(difficulty)를 감소시켜야하므로 블록의 크기와 마찬가지로 새로운 블록의 발견 확률이 증가하므로 분기 발생 가능성이 증가



2) 페이먼트 채널(Payment Channel)

페이먼트 채널은 특정한 사람들 간에 하나의 채널을 형성하여 트랜잭션을 자주 주고받는 상황에서 생성되는 모든 트랜잭션이 아닌 일부만을 블록체인 상에(on-chain) 저장하고 나머지는 해당 사용자 간에 채널에(off-chain)에 보관하는 형태입니다.
채널 간 거래는 블록체인 외부에서 처리하는 개념입니다.

**<양방향 페이먼트="" 채널의="" 생성="">**

  1. 채널을 생성하기를 원하는 사용자 A와 B는 자신이 보유한 UTXO를 사용하여 하나의 2-of-2 다중서명(multi-signature)출력을 생성하는 담보(deposit) 트랜잭션을 생성함 => 신뢰가능, 블록체인에 트랜잭션을 올림
  2. 담보 트랜잭션의 출력을 사용하여 1)에서 각 사용자가 소비한 출력을 원래 사용자에게로 반환하는 반환 트랜잭션을 타임락(timelock) t와 함께 생성함 => 작성된 타임락 시간 안에 주고 받아야함
  3. A는 1)의 담보 트랜잭션의 출력을 사용하여 A와 B에게 금액을 배분하는 확약(commitment) 트랜잭션 tx1을 타임락 t-1과 함께 생성하여 서명 후 B에게 전달함 =>B는 타임락 t-1 안에 넘겨줘야함
  4. B는 3)에서 생성한 tx1의 내용에 동의할 경우 tx1에 대한 자신의 서명을 첨부하여 A에게 전달함
  5. 3)~4)의 과정을 더 이상 거래가 필요하지 않다고 판단될 때까지 반복하여 tx1을 수정하여 최종적으로 생성된 txn을 시간 t 이전에 블록체인에 전파함 => 최종적으로 업데이트된 트랜잭션만 올리는데 타임락t 안에 해결해야함


생성된 트랜잭션

  • 최초의 담보 트랜잭션
  • 담보를 반환하는 반환 트랜잭션
  • 사용자간 주고받는 (tx1…txn)
    => n + 2

실제 블록체인 상 생성된 트랜잭션

  • 담보 트랜잭션
  • 최종적으로 업데이트된 txn

반환 트랜잭션은?

최정적으로 합의된 트랜잭션 txn이 시간 t 이전에 블록체인에 추가될 경우 동일한 출력을 사용하는 반환 트랜잭션은 이중 지불로 인해 네트워크의 노드들에 의해 취소됩니다.

페이먼트 채널을 쓰는 이유?

- 네트워크에 전파되는 트랜잭션의 수를 감소
- 전파된 트랜잭션이 블록에 포함되어 추가되는 것을 기다릴 필요가 없음
=> 그만큼 처리속도가 빠름
- 사용자 간에만 트랜잭션을 주고받음으로써 사용자의 프라이버시 또한 보장받을 수 있음

=> But! 오프체인에서 생성된 트랜잭션은 채널이 종료되어 블록체인에 포함될 때까지 제3자에게 트랜잭션의 유효성을 인정받을 수 없다는 것이 문제

확장성 2가지에 대한 내용을 보면 완전하게 해결할 수 있는 단일 솔루션은 존재하지 않다는 것을 알 수 있습니다.

따라서, 블록체인 어플리케이션을 적용하고자하는 시스템의 특성과 사용하는 네트워크 성능에 따라 현재 존재하는 여러 솔루션을 복합적으로, 혹은 단일로 사용하여 시스템 환경에 맞는 방법을 적용하는 방법이 블록체인 시스템 구축 전에 필요할 것으로 보임




참고 논문 : (1)퍼블릭 블록체인의 보안 위협과 블록체인 확장성 문제의 연관성에 대한 분석.pdf

댓글남기기

참고