블록체인 애플리케이션을 위한 안전한 난수 생성 기술 구축
많은 블록체인 애플리케이션은 안전한 데이터 소스에서 생성된 난수를 사용해야 한다.
예를 들어, NFT PFP 시리즈 에어드롭은 각 NFT 이미지에 대해 무작위 속성 조합을 선택해야 하며, 체인 상 게임은 보물을 열 때 아이템을 무작위로 드롭해야 할 수 있다. 두 경우 모두 안전한 난수 생성기는 사용자가 애플리케이션 앞에서 공정성을 유지할 수 있도록 보장한다. 또한 이는 단지 난수의 일부 가능한 활용 사례일 뿐이며 일반적으로 난수는 다양한 유형의 알고리즘 문제를 해결하는 데 유용한 도구이다.
불행히도, 블록체인의 고유한 특성 때문에 난수 생성 과정은 그리 간단하지 않다. 블록체인 상태는 결정론적 규칙 집합에 따라 진행되며, 각 거래는 주어진 입력값에 따라 특정 출력 상태를 생성한다. 이러한 규칙은 결정론적이어야 하는데, 그 이유는 블록체인이 모든 검증자가 각 거래 처리 과정을 검증할 수 있어야 하기 때문이다. 만약 규칙이 결정론적이지 않다면 검증자들이 상태에 대해 서로 다른 견해를 가질 수 있기 때문이다.
블록체인상에는 다양한 방식의 난수 생성 방법이 존재한다. 본문은 이러한 방법들 중 일부를 설명하고 그 장단점을 분석한다.
참여자
난수 생성 프로토콜은 일반적으로 여러 다른 참여자를 포함한다. 각 참여자는 프로토콜의 일원이거나 결과 생성에 관심 있는 사람이다. 방법에 따라 관련되는 참여자의 하위 집합이 달라질 수 있다. 가능한 참여자들은 다음과 같다.
애플리케이션 개발자 — 개발자는 난수를 요청하고 사용하는 소프트웨어를 작성하는 책임이 있다. 개발자는 일반적으로 난수 생성 과정에 직접 참여하지 않지만, 결과가 진정으로 무작위이기를 원한다. 예를 들어, NFT 시리즈 개발자는 누구도 희귀 속성을 모두 가진 NFT를 얻기 위해 NFT 민팅 프로세스에서 부정행위를 할 수 없도록 보장하려고 한다.
사용자 — 사용자는 프로토콜과 상호작용하여 난수 생성 요청을 시작한다. 예를 들어, 사용자는 NFT를 민팅하는 사람일 수 있다.
검증자 — 많은 난수 생성 프로토콜은 블록체인의 입력 데이터를 사용한다. 블록체인의 검증자(또는 마이너/시퀀서 등 상황에 따라 다름)는 입력 데이터에 대해 어느 정도 제어권을 가질 수 있다.
서비스 제공자 — 많은 프로토콜에서는 지정된 오프체인 서비스 제공자가 난수 생성 절차의 일부를 담당한다. 해당 서비스 제공자는 중립적인 제3자여야 하지만, 이를 통해 부여되는 신뢰를 최소화하기 위해 더 복잡한 난수 생성 방법이 필요하다.
주의할 점은 한 사람이 여러 참여자의 역할을 동시에 수행할 수 있다는 것이다. 예를 들어, 사용자 자신이 블록체인 네트워크 상에서 검증자를 운영할 수 있다. 이러한 프로토콜의 많은 공격 벡터들은 여러 참여자 간의 비밀 협력에서 비롯된다.
속성
난수 생성 방법을 논의하기 전에, 우리가 기대하는 난수 생성기의 속성에 대해 공통된 이해를 해야 한다.
모든 난수 생성기는 두 단계로 작동한다. 먼저 요청 단계에서 사용자가 생성기에 난수를 요청한다. 다음으로 공개 단계에서 생성기가 난수를 생성하여 블록체인에 게시한다. 각 단계는 최소한 하나의 블록체인 트랜잭션을 필요로 한다 — 단일 트랜잭션 내에서 안전하게 체인 상 난수를 생성하는 것은 불가능하다. 그러나 서로 다른 프로토콜마다 각 단계에서 수행되는 정확한 계산은 다를 수 있다.
우리가 주목하는 보안 속성은 세 가지다.
예측 불가능성 — 난수를 요청하기 전에 어떤 참여자도 난수를 예측할 수 없다. 이 속성은 '무작위성'의 공식적인 정의이다.
결정성 — 난수를 요청한 후에는 오직 하나의 가능한 값만 존재해야 한다. 이 속성은 결과 요청 후 참여자가 결과에 영향을 미칠 수 없음을 보장한다.
활성성 — 난수를 요청한 후 프로토콜 실행이 즉시 완료되어야 한다. 즉, 요청 단계의 완료와 공개 단계의 완료가 동시에 발생해야 한다.
난수 생성 프로토콜의 핵심 질문은 바로: 이러한 속성들이 어떤 조건 하에서 성립하는가? 예를 들어, 프로토콜은 서비스 제공자가 정직함을 유지해야 한다고 요구할 수 있다. 이러한 조건들이 바로 프로토콜의 신뢰 가정이다. 신뢰 가정이 적을수록 프로토콜은 더 안전하다.
난수 생성 방법
신뢰할 수 있는 제3자
가장 간단한 난수 프로토콜은 서비스 제공자가 난수를 생성하도록 하는 것이다. 사용자가 난수를 요청하면, 서비스 제공자는 오프체인에서 난수를 생성한 후 블록체인에 다시 게시하기만 하면 된다.
이 방법은 매우 간단하지만 강력한 신뢰 가정을 필요로 한다: 참여자들은 서비스 제공자의 정직성을 신뢰해야 한다. 서비스 제공자는 난수를 자유롭게 선택할 수 있으며 프로토콜을 중단할 능력도 있다. 이러한 가정은 서비스 제공자가 Intel SGX 같은 보안 격리 환경 내에서 계산을 수행하도록 함으로써 부분적으로 개선될 수 있지만, 그러한 격리 환경은 이미 여러 번 불완전하다는 것이 입증된 바 있다(SgxPectre 공격).
블록 해시
간단한 난수 생성 전략 중 하나는 미래 블록의 블록 해시 값을 사용하는 것이다. 난수 생성 요청 트랜잭션은 현재(또는 미래)의 블록 번호를 저장한다. 이후 네트워크 검증자가 해당 블록의 블록 해시를 계산한다. 블록 해시가 사용 가능해지면 생성기는 생성 트랜잭션을 게시한다.
블록 해시 생성 방법은 간단하며 모든 블록체인에서 쉽게 사용할 수 있다. 그러나 이 방법 역시 강력한 신뢰 가정이 필요하다: 참여자들은 검증자의 정직성을 신뢰해야 한다. 검증자는 재정렬하거나 거래를 무시함으로써 블록 해시를 조작할 수 있다. 따라서 프로토콜 사용자가 검증기를 운영하거나 검증자와 공모하는 것은 사용자가 유리한 난수를 얻도록 보장하는 잠재적 공격 위험을 초래한다.
검증 가능한 난수 함수(VRF)
이전에 논의한 방법들의 주요 문제점은 단일 참여자가 난수 생성 결과에 영향을 줄 수 있다는 점에서 기인한다(따라서 예측 가능해진다). 검증 가능한 난수 함수(VRF)는 여러 참여자가 공동으로 협력하여 난수 생성 결과에 영향을 미치도록 요구함으로써 이러한 공격 벡터를 제거한다.
VRF는 함수f_s(x) = (y, p)이며, 출력값 y는 무작위처럼 보이지만 입력값 x와 비밀키 s에 의해 결정적으로 계산된다. 또한 이 함수는 증명값 p를 반환하는데, 누구나 이를 통해 y가 올바른 출력값인지 검증할 수 있다(매우 간략한 설명이다. VRF에 대한 자세한 설명은 IETF RFC 참고).
블록체인 상에서 VRF는 일반적으로 다음과 같이 동작한다. 먼저 입력값 x는 사용자가 제공하는 부분과 블록 해시로부터 오는 부분으로 구성된다. 오프체인 서비스 제공자는 비밀키 s를 사용해 블록체인 상의 요청을 모니터링하고, 체인 상에 대응값 (y, p)를 제출한다. 게시 트랜잭션은 증명값 p를 확인하여 y가 올바른 값인지 검증한 후 게시를 진행한다.
VRF의 장점은 이전 방법들보다 신뢰 가정을 개선했다는 점이다: 사용자, 검증자, 서비스 제공자가 모두 공모해야만 난수를 예측할 수 있다. VRF의 주요 우려사항은 활성성인데, 참여자들은 서비스 제공자가 거래를 검열하지 않을 것임을 신뢰해야 한다. 서비스 제공자는 생성된 난수를 볼 수 있으며, 이를 블록체인에 제출할지 여부를 선택할 수 있다. 예를 들어, 사용자가 동전 던지기 요청을 제출한 후 VRF 제공자와 공모하여 결과가 앞면일 경우에만 요청을 완료하는 공격이 가능하다. 그러나 애플리케이션 개발자는 이러한 공격을 완화할 수 있다 — 특히 사용자가 게시 실패로부터 이득을 얻을 수 없다면, 이러한 공격을 수행할 동기가 없어진다.
VRF의 또 다른 단점은 암호학적으로 비교적 복잡하고 계산 집약적이라는 점이다. 대부분의 블록체인은 필요한 모든 암호학적 기본 프로토콜을 내장하지 못하므로, 난수 게시는 많은 가스를 소비하거나 여러 트랜잭션이 필요할 수 있다.
커밋-오픈
VRF 외에도 난수 생성의 신뢰 가정을 개선하는 또 다른 방법은 서로 신뢰하지 않는 두 당사자 사이에서 난수를 생성하는 커밋-오픈 프로토콜이다. 이 프로토콜의 기본 작동 방식은 다음과 같다.
-
요청 단계에서 사용자와 서비스 제공자는 모두 비밀 난수를 생성한다. 그리고 각자는 난수의 해시값을 블록체인에 제출한다. 이 해시값을 커밋값이라 한다.
-
공개 단계에서 사용자와 서비스 제공자는 각각 자신의 난수를 공개한다. 각 참여자는 다른 참여자가 공개한 숫자가 자신의 커밋값과 일치하는지 확인한다. 이 단계가 완료되면 최종 난수는 두 난수의 해시값이 된다. 블록체인 배포의 경우 요청 트랜잭션의 블록 해시도 마지막 해시 연산 단계에 포함될 수 있다.
초기 방법들과 비교했을 때, 커밋-오픈 프로토콜은 마찬가지로 신뢰 가정을 개선한다: 사용자, 검증자, 서비스 제공자가 모두 공모해야만 난수를 예측할 수 있다. 또한 이 프로토콜은 단순한 암호 기술만 사용한다 — 해시 함수만 필요하므로 구현이 용이하다. 그러나 이 프로토콜은 VRF와 유사한 활성성 문제를 가지고 있다: 사용자나 서비스 제공자 중 어느 한쪽이 즉시 난수를 공개하지 않음으로써 프로토콜을 중단시킬 수 있다. VRF와 마찬가지로 애플리케이션 개발자는 위에서 언급한 VRF용 기술과 동일한 방법을 사용하여 이러한 공격 벡터를 완화할 수 있다.
기본적인 커밋-오픈 구현 방식은 사용자와 서비스 제공자가 각 단계에서 개별적으로 트랜잭션을 보내야 하므로 두 건 이상의 트랜잭션이 필요하다는 점에 유의해야 한다. 이 단점은 서비스 제공자가 미리 여러 난수를 커밋할 수 있도록 허용하는 더 복잡한 배포 방식으로 해결할 수 있다. Pyth Entropy는 커밋-오픈 프로토콜의 고급 구현 사례이다.
VRF와 커밋-오픈 프로토콜 모두 애플리케이션 개발자가 활성성을 희생함으로써 예측 불가능성을 얻을 수 있게 해준다. 개발자가 단일 서비스 제공자만을 신뢰하는 것에 대해 우려한다면, 간단히 N개의 서비스 제공자에게 난수를 요청한 후 결과를 결합할 수 있다. 이 방법은 예측 불가능성을 향상시킨다 — 모든 N개 제공자가 협력해야 결과에 영향을 줄 수 있다 — 하지만 활성성은 저하된다 — N개 제공자 중 어느 하나라도 난수 게시를 중단시킬 수 있다. 그러나 주의할 점은 N개의 서비스 제공자 중 어느 하나도 최종 난수가 무엇인지 알지 못하므로, 그 지식을 이용해 언제 프로토콜을 중단할지를 결정할 수 없다는 것이다.
기타 방법
안전한 난수를 생성하기 위한 더 고급 방법들도 존재한다. 이러한 방법들은 상위 레벨에서 예측 불가능성과 활성성 간의 트레이드오프를 개선하여 프로토콜 중단을 위해 >1개의 제공자가 필요하도록 설계된다. 그 중 하나는 VRF의 비밀키 s를 여러 참여자 사이에 분할 저장하는 임계값 VRF(threshold VRF)이며, 다른 하나는 랜덤 비컨(random beacon)이다. 이러한 방법들은 위의 방법들보다 더 나은 보안 트레이드오프를 제공하지만, 대부분의 애플리케이션에서는 활성성 문제가 애플리케이션 설계를 통해 개선될 수 있기 때문에 다소 과도하다고 볼 수 있다.
결론
본문은 블록체인 상에서 난수를 생성하는 여러 방법을 소개하고 그 장단점을 분석했다. 만약 안전한 난수 생성기가 필요한 애플리케이션을 개발 중이라면 Pyth Entropy를 살펴보고, Discord, Telegram 또는 기타 소셜 채널을 통해 Pyth 기여자들과 연락하여 이 혁신적인 제품을 어떻게 사용할 수 있는지 알아보기 바란다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@PythNetwork
