Technology, Tutorials, for Developer

BLS signautre 그리고 KIP-113, KIP-114

* 이 아티클은 Klaytn Developer Ambassador인 yhc125 (GitHub / LinkedIn)에 의해 작성된 글입니다.

블록체인 네트워크들은 항상 보안성, 투명성, 그리고 무작위성을 확보하는 데 있어 많은 노력을 기울이고 있습니다. 이러한 문제들 중 하나를 해결하기 위해 주목받는 기술 중 하나는 BLS(Boneh-Lynn-Shacham) signature 체계입니다.

2020년 12월, 이더리움은 이 BLS signature 체계를 적용한 2.0 Phase 0 비콘 체인 (Beacon Chain)을 선보였습니다. 비콘 체인은 이 서명 체계를 통해 검증자의 합의를 처리하고, Verifiable Random Function (VRF)을 통해 무작위성을 실현했습니다. 제출된 서명값들이 시간이 지나며 누적되어 결국에는 특정 시점의 무작위 값을 생성하게 되는데, 이 값은 투명하게 검증 가능하며 참여자의 의도에 의해 왜곡될 수 없습니다.

이와 같은 이더리움의 BLS signature 체계 활용 사례를 참조하여, Klaytn도 자체 네트워크에서 BLS signature 체계의 활용을 검토하고 있습니다. 최근 제안된 Klaytn Improvement Proposals, KIP-113과 KIP-114는 이를 적용하는 방안을 제시하고 있습니다. KIP-113은 BLS signature에 기반한 공개키 등록을 통해 노드의 신원을 확인하는 메커니즘을, KIP-114는 블록 헤더에 새로운 필드를 도입하고, 이를 통해 블록 체인에서 확실하게 검증 가능한 랜덤값을 생성하는 방법을 제안하고 있습니다.

이 글에서는 BLS signature에 대해 가볍게 다루고 KIP-113, KIP-114를 순차적으로 알아보겠습니다.

BLS signature

기존의 사용하던 ECDSA보다 BLS signature가 갖는 강점을 얘기한다면 작은 signature data와 signature aggregation입니다.

[그림 1] ECDSA와 BLS Signature의 알고리즘 비교

두 알고리즘을 비교하기에 앞서 타원 곡선 암호학(ECC)에서의 중요한 개념인 generator에 대해 알아야 합니다.

generator는 특정 타원 곡선 위의 한 점을 말합니다. 이 점은 타원 곡선 위의 모든 다른 점들을 생성하는 데 사용됩니다. 이는 곱셈 연산(doubling)에 의해 이루어지는데, 생성자를 특정 횟수만큼 ‘더하게’되면(이 때 ‘더하기’는 타원 곡선에서의 특수한 연산을 의미합니다, addition), 이에 해당하는 다른 점이 타원 곡선 위에 생성됩니다.

generator는 공개키를 생성하는 데 사용되는 개인키와 결합됩니다. 개인 키는 임의의 숫자이며, 이 숫자를 generator에 곱해(즉, generator를 그 횟수만큼 더해) 공개 키를 생성합니다. 이 연산의 결과로 얻어진 점이 공개키가 됩니다.

다음은 [그림 1]에서 각 과정별로 비교한 내용입니다.

  1. EC Group(s): ECDSA에서는 p256, secp256k1 종류의 타원 곡선을 통해서 generator를 만들지만 BLS Signature에서는 일반적으로 BLS12–381 타원곡선을 사용하여 G1, G2 2개의 generator로 구성합니다. G1, G2는 이후에, 서명과 공개키를 만드는데 사용하게 됩니다.
  2. Key generation: ECDSA, BLS Signatrue 모두 개인키와 그룹과의 곱으로 공개키를 생성합니다. 개인키는 선택된 타원 곡선 범위에서 유한 정수 그룹에서 랜덤으로 선택한 임의의 정수입니다.
  3. Sign (for msg): ECDSA에서는 서명 생성 과정이 약간 복잡합니다. 서명자는 메시지의 해시와 함께 비밀키와 임의의 숫자를 사용하여 서명을 생성합니다. 반면, BLS에서는 서명 생성이 비교적 간단합니다. 서명자는 메시지의 해시와 비밀키만을 사용하여 서명을 생성합니다. 실제로, ECDSA의 서명 데이터의 크기는 64bytes인데 반해, BLS 서명 데이터의 크기는 48bytes입니다.
  4. Verification: ECDSA와 BLS 모두 수신자가 원본 메시지와 서명, 그리고 서명자의 공개키를 사용하여 서명을 검증합니다. 하지만 그 과정이 약간 다릅니다. ECDSA에서는 연산과 나눗셈을 수행한 후, 그 결과가 서명자가 제공한 값과 일치하는지 확인합니다. BLS에서는 Pairing check을 통해 서명이 유효한지 확인합니다.

다만, 3번 과정에서 조금 더 자세히 살펴볼 필요가 있습니다. 분명 ECDSA보다 서명 데이터의 크기가 작은 것은 맞지만 실제로 이더리움 2.0과 클레이튼은 BLS 서명 체계를 사용할 때, 서명 데이터는 96bytes 입니다. 사실, 서명 데이터 크기에 있어서 BLS 서명 체계는 두 가지 변형이 있습니다. 공개키 크기를 작게하는 타입(min-publickey-size)과 서명 데이터를 작게하는 타입(min-signature-size)입니다.

그래서 G1으로 공개키를 생성하면 min-publickey-size 타입, G1으로 서명을 생성하면 min-signature-size 타입이라 부르게 되고 이는 trade-off 관계에 있다고 볼 수 있습니다. 앞에서 설명한대로 서명의 크기를 줄이는 목적이 있었으므로 쓴다면 서명을 G1, 공개키를 G2로 배치해서 사용하면 됩니다.

그런데 클레이튼의 경우에는 공개키의 크기를 줄이고, 공개키 연산을 빠르게 해야 하므로 공개키를 G1, 서명을 G2로 배치합니다. 검증자의 공개키는 스마트 컨트랙트와 클레이튼 체인에 저장되며, 이 공개키는 추후 블록 제안과 같은 과정에서 수많은 전송을 겪게 됩니다. 또한 각 노드에서는 이들 공개키를 이용하여 다양한 연산을 수행해야 합니다 . 이러한 이유로 서명 데이터 크기를 줄이는 것보다 공개키 크기를 줄여 연산 속도를 빠르게 하는 것이 결과적으로 효율성을 높이는 선택이라고 볼 수 있습니다.

[그림 2] Signature Aggregation 예시 (N명이 같은 메세지에 서명하는 경우)

BLS 서명의 가장 큰 장점 중 하나는 서명을 aggregation할 수 있다는 것입니다. 서명 aggregation은 여러 개의 서명을 하나의 서명으로 결합할 수 있다는 의미이며, 이 결합된 서명은 모든 개별 서명을 검증하는 것과 동일한 보안 수준을 제공합니다. 반면, ECDSA는 이러한 aggregation 기능을 가지고 있지 않습니다.

실제로 이더리움 2.0에서 블록 검증을 위해 벨리데이터들은 같은 메세지에 서명을 하는 작업을 할 때 사용하게 됩니다. 이는 N명이 ECDSA를 활용했을 때 대비하여 저장 공간이 1/N이 되는 효과를 얻을 수 있게 됩니다. [그림 2]는 N명이 같은 메세지에 서명을 했을 때, 어떻게 signature aggregation을 진행하는지 보여주고 있습니다.

ECC에 대한 전반적인 개념과 더불어 자세한 설명은 아래 글을 참고하시면 좋을 것 같습니다.

KIP-113

Klaytn도 이러한 BLS signature의 이점을 얻고자 KIP-113 BLS12-381 registry를 설계하였습니다. 다만 이것은 클레이튼의 AddressBook을 대체하는 것이 아니라, signature-based random(KIP-114) 등 다양한 컴포넌트에서 BLS 사용을 용이하게 하기 위해 AddressBook을 보완하는 것입니다.

Klaytn의 AddressBook은 클레이튼 블록체인 네트워크의 노드에 대한 정보를 저장하는 장소로 스마트 컨트렉트로 구현되어있습니다. 각 노드의 주소와 노드 ID를 기록하는데 사용되며, 이 정보는 노드들 사이의 네트워크 연결을 돕는데 필요합니다. 이를 통해 클레이튼 네트워크 상의 노드들은 서로를 찾고, 네트워크를 통해 서로 통신할 수 있게 됩니다.

KIP-113 registry contract는 위와 같은 IKIP113 인터페이스를 구현해야 합니다. 이 인터페이스는 BLS 공개 키 및 소유증명 정보 등을 등록하고 관리하는 기능을 제공합니다.

IKIP-113에 정의되어있는 BLS12-381 공개키의 구조체 BlsPublicKeyInfo는 두 가지 주요 요소를 포함합니다.

  • publicKey: 압축된 BLS12-381 공개키로, 크기는 48 바이트입니다.
  • pop: Proof-of-possession의 약자로, 크기는 96 바이트입니다. 이는 draft-irtf-cfrg-bls-signature-05의 3.3.3절에 명시된 PopProve 알고리즘에 따라 결과가 생성되어야 합니다.

Proof-of-Possession (PoP)는 공개키를 제출하는 참가자가 해당 키에 대응하는 개인키를 실제로 소유하고 있음을 증명하는 메커니즘입니다. 이러한 방식은 소위 Rogue Key Attack을 방지하는 데 중요한 역할을 합니다. 이러한 공격에서는 공격자가 악의적으로 조작된 공개키를 네트워크에 주입하여 그룹의 전체 서명을 손상시키려고 시도합니다. PoP는 이러한 공격을 방지하기 위해 공개키의 유효성을 검사합니다. 그러나 현재 EIP-2537의 부재로 이러한 유효성 검사는 off-chain에서 수행해야 합니다.

KIP-114

KIP-113은 Klaytn에서 BLS 서명 체계를 표준화하는데 주력하며, Verifiable Random Number에 기반한 규정을 제공하였습니다. 이후 KIP-114에서는 이 Verifiable Random Number를 블록 헤더의 randomReveal 필드에 이용하여 mixHash를 계산합니다.

Verifiable Random Number은 참여자의 개입 없이도 신뢰성을 검증할 수 있는 무작위 수를 의미합니다. 이더리움 2.0 비콘 체인에서는 RANDAO 방식으로 VRF를 구현하여 이를 계산합니다. 그리고 클레이튼에서는 mixHash 구현하여 Verifiable Random을 생성하게 됩니다.

KIP-114에서는 Verifiable Random의 UseCase로 블록 제안자를 설명합니다. 다음 블록의 제안자가 최신 블록이 finalized될 때까지 비공개로 유지되거나, 제안자가 다음 블록의 제안자를 선택하는 개입할 수 없도록 할 수 있습니다.

KIP-114에서는 randomReveal과 mixHash라는 두 가지 새로운 필드를 블록 헤더에 도입하고자 제안하였습니다. randomReveal 은 제안자의 서명이며, 제안하는 블록의 randomReveal값의 keccak256 hash와 이전 블록의 mixHash를 XOR 연산하여 mixHash를 생성합니다. 만약 이전 블록이 FORK_BLOCK이라면 그 뒤에는 반드시 mixHash 값은 32bytes의 0으로 구성되어야합니다. 이렇게 생성된 mixHash는 예측할 수 없으며, 검증 가능하고 신뢰할 수 있는 무작위 소스를 제공합니다.

randomReveal은 KIP-113에서 표준화된 BLS 서명 체계를 이용하여 생성되며, 검증자들은 KIP-113 BLS registry의 getInfo(cnNodeId) 함수를 통해 제안자의 공개키와 소유증명 (proof-of-possession, pop)을 확인할 수 있습니다. 검증자들은 pop를 활용하여 제안자의 공개키 유효성을 검증하고, randomReveal이 제안자의 올바른 개인키에 의해 서명되었음을 검증합니다. 이렇게 함으로써, KIP-114는 블록체인에서 예측 불가능하고(Random), 검증 가능하며(Verifiable), 신뢰할 수 있는(Unbiasable) 무작위 값을 제공하고자 합니다.

KIP-114의 UseCase로 들었던 예시는 이후, KIP-146으로 제안합니다. KIP-146은 블록의 제안자를 무작위로 선택하는 정책을 제안하는데 mixHash 를 사용하여 구현하게 됩니다.

전체적인 과정을 다시 살펴보면 다음과 같습니다.

  1. 블록 제안자(Block Proposer)는 BLS 서명 체계를 사용하여 randomReveal을 생성합니다. 이 값은 제안자의 고유한 서명으로 블록 헤더에 포함됩니다.
  2. 검증자들(Validators)은 BLS 레지스트리에서 제안자의 공개 키와 pop를 가져옵니다.
  3. 검증자들은 pop를 사용하여 제안자 공개키의 유효성을 검증하고, randomReveal이 제안자의 개인키에 의해 서명되었는지 검증합니다.
  4. 검증자들은 여러 randomReveal 값과 추가 정보를 혼합하여 mixHash를 계산합니다.

그리고 KIP-114에서는 위 과정에서 고려해야하는 보안 사항도 명시해두었습니다.

  1. Replay Attacks : 블록 제안자가 이전 블록에서 사용한 randomReveal 값을 재사용하는 공격을 방지하기 위해, 각 블록에서 사용된 randomReveal 값은 유일해야 합니다. 이를 통해, 블록 제안자는 자신의 이전 randomReveal 값을 재사용하여 mixHash를 조작하는 것을 방지할 수 있습니다.
  2. Honesty of Block Proposer : 제안자가 정직하게 자신의 randomReveal을 생성하고 제출해야 합니다. 제안자가 자신의 randomReveal 값을 조작하면, 그 결과로 생성되는 mixHash 값도 조작될 수 있습니다. 따라서, 제안자는 자신의 randomReveal 값을 조작하지 않고, 그것을 통해 mixHash를 계산하는 데 필요한 모든 정보를 정직하게 제공해야 합니다.
  3. Secrecy of randomReveal Before Block Proposal : 제안자는 자신의 randomReveal 값을 블록 제안 전까지 비밀로 유지해야 합니다. 이렇게 함으로써, 다른 참가자들이 제안자의 randomReveal 값을 예측하거나, 그 값을 사용하여 mixHash를 조작하는 것을 방지할 수 있습니다.
  4. Validation of randomReveal : randomReveal값은 제안자의 공개키에 의해 서명되어야 하며, 검증자는 이를 검증해야 합니다. 이를 통해, 제안자가 자신의 randomReveal 값을 조작하거나 변조하는 것을 방지할 수 있습니다.

본 글에서는 블록체인의 보안성, 투명성, 그리고 무작위성을 확보하는 중요성에 대해 강조하였습니다. 이 중 무작위성을 확보하는 것은 참여자들의 공정한 참여를 보장하고, 시스템의 신뢰성을 유지하는 데 매우 중요한 요소입니다. 이를 위해 BLS(Boneh-Lynn-Shacham) signature 체계의 사용이 주목받고 있습니다. BLS signature 체계는 작은 signature data와 signature aggregation의 강점을 갖추고 있어, 이더리움 2.0에서도 비콘 체인에 도입되었습니다.

클레이튼도 이러한 BLS signature 체계의 강점을 인식하고, 이를 자체 네트워크에 적용하려는 노력을 진행 중입니다. 이를 위해 최근 제안된 KIP-113과 KIP-114는 BLS signature 체계를 어떻게 클레이튼에 적용할 것인지에 대한 방안을 제시하고 있습니다. 이 글을 통해서 현재 클레이튼 코어 개발의 방향성을 엿볼 수 있으면서 블록체인 기술의 전반적인 발전과 미래를 이해하는 데 조금이나마 도움이 되었으면 하는 기대를 품고 글을 마치겠습니다.

관련 아티클

목록으로