소개

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

암호화의 절대적으로 강력한 암호 개념과 마찬가지로 실제 "공개적으로 검증 가능한 무작위 비콘"(이하 PVRB) 프로토콜은 가능한 한 이상적인 체계에 가까워지려고 노력합니다. 실제 네트워크에서는 순수한 형태로는 적용할 수 없습니다. 즉, XNUMX비트에 대해 엄격하게 동의해야 하고, 많은 라운드가 있어야 하며, 모든 메시지는 완벽하게 빠르고 항상 전달되어야 합니다. 물론 실제 네트워크에서는 그렇지 않습니다. 따라서 현대 블록체인의 특정 작업을 위해 PVRB를 설계할 때 결과적인 무작위성과 암호화 강도를 제어할 수 없다는 점 외에도 훨씬 더 많은 순전히 구조적, 기술적 문제가 발생합니다.

PVRB의 경우 블록체인 자체는 본질적으로 메시지 = 트랜잭션인 통신 매체입니다. 이를 통해 네트워크 문제, 메시지 미전달, 미들웨어 문제를 부분적으로 추상화할 수 있습니다. 이러한 모든 위험은 분산형 네트워크에서 가정되며 PVRB의 주요 가치는 이미 전송된 트랜잭션을 취소하거나 손상시킬 수 없다는 것입니다. 참가자들이 합의에 대한 성공적인 공격을 수행하지 않는 한 프로토콜 참여를 거부하는 것을 허용하지 않습니다. 이 수준의 보안은 허용 가능하므로 PVRB는 메인 블록체인 체인과 정확히 동일한 정도로 참가자의 공모에 저항해야 합니다. 또한 이는 네트워크가 유일하게 공정한 결과 무작위에 동의하더라도 네트워크가 메인 블록체인에 동의하는 경우 PVRB가 합의의 일부가 되어야 함을 암시합니다. 또는 PVRB는 블록체인 및 블록과 관련하여 비동기적으로 작동하는 스마트 계약에 의해 구현된 단순한 독립형 프로토콜입니다. 두 방법 모두 장점과 단점이 있으며 둘 중 하나를 선택하는 것은 매우 중요합니다.

PVRB를 구현하는 두 가지 방법

PVRB를 구현하기 위한 두 가지 옵션, 즉 블록체인과 독립적인 스마트 계약을 사용하여 작동하는 독립형 버전과 네트워크가 블록체인에 동의하는 프로토콜에 내장된 합의 통합 버전을 더 자세히 설명하겠습니다. 포함할 거래. 모든 경우에 나는 인기 있는 블록체인 엔진을 의미합니다. 즉, 이더리움, EOS 및 스마트 계약을 호스팅하고 처리하는 방식에서 이와 유사한 모든 엔진을 의미합니다.

독립형 계약

이 버전에서 PVRB는 무작위 생산자(이하 RP)의 거래를 수락하고 이를 처리하고 결과를 결합하여 결과적으로 모든 사용자가 이 계약에서 받을 수 있는 특정 가치에 도달하는 스마트 계약입니다. 이 값은 계약에 직접 저장되지 않을 수 있으며 오히려 결과 무작위의 단 하나의 값만 결정론적으로 얻을 수 있는 데이터로만 표시됩니다. 이 체계에서 RP는 블록체인의 사용자이며 누구나 생성 프로세스에 참여할 수 있습니다.

독립형 계약 옵션이 좋습니다.

• 이식성(계약을 블록체인에서 블록체인으로 끌어올 수 있음)
• 구현 및 테스트 용이성(계약서 작성 및 테스트가 용이함)
• 경제적 계획 구현의 편의성(PVRB의 목적에 부합하는 논리를 가진 자체 토큰을 만드는 것은 쉽습니다)
• 이미 작동 중인 블록체인에서 출시 가능성

또한 단점도 있습니다:

• 컴퓨팅 리소스, 트랜잭션 볼륨 및 스토리지(즉, CPU/mem/io)에 대한 강력한 제한
• 계약 내 작업 제한(모든 지침을 사용할 수 있는 것은 아니며 외부 라이브러리 연결이 어렵습니다)
• 트랜잭션보다 빠르게 메시징을 구성할 수 없음이 블록체인에 포함됨

이 옵션은 기존 네트워크에서 실행해야 하고 복잡한 암호화를 포함하지 않으며 많은 상호 작용이 필요하지 않은 PVRB를 구현하는 데 적합합니다.

합의 통합

이 버전에서 PVRB는 블록체인 노드 코드에 구현되어 내장되거나 블록체인 노드 간 메시지 교환과 병렬로 실행됩니다. 프로토콜의 결과는 생성된 블록에 직접 기록되고 프로토콜 메시지는 노드 간 P2P 네트워크를 통해 전송됩니다. 프로토콜은 블록에 기록될 숫자를 생성하므로 네트워크는 이에 대한 합의에 도달해야 합니다. 이는 트랜잭션과 같은 PVRB 메시지가 노드에 의해 검증되고 블록에 포함되어 모든 네트워크 참가자가 PVRB 프로토콜 준수 여부를 확인할 수 있어야 함을 의미합니다. 이는 자동으로 확실한 해결책으로 이어집니다. 네트워크가 블록과 그 안의 트랜잭션에 대한 합의에 동의하면 PVRB는 독립 실행형 프로토콜이 아니라 합의의 일부가 되어야 합니다. 그렇지 않으면 합의 관점에서는 블록이 유효하지만 PVRB 프로토콜을 따르지 않아 PVRB 관점에서 블록을 수락할 수 없는 경우가 발생할 수 있습니다. 따라서 "합의 통합" 옵션을 선택하면 PVRB는 합의의 중요한 부분이 됩니다.

네트워크 합의 수준에서 PVRB 구현을 설명할 때 최종성 문제를 결코 피할 수는 없습니다. 완결성은 병렬 포크가 발생하더라도 결코 버려지지 않는 최종 블록(및 그로 이어지는 체인)을 잠그는 결정론적 합의에 사용되는 메커니즘입니다. 예를 들어, 비트코인에는 그러한 메커니즘이 없습니다. 더 복잡한 체인을 게시하면 체인 길이에 관계없이 덜 복잡한 체인을 대체합니다. 그리고 예를 들어 EOS에서 최종 블록은 소위 마지막 비가역 블록(Last Irreversible Block)으로, 평균 432개 블록(12*21 + 12*15, 사전 투표 + 사전 커밋)마다 나타납니다. 이 프로세스는 본질적으로 블록 생산자(이하 BP)의 2/3 서명을 기다리고 있습니다. 마지막 LIB보다 오래된 포크가 나타나면 간단히 폐기됩니다. 이 메커니즘을 사용하면 거래가 블록체인에 포함되고 공격자가 어떤 리소스를 가지고 있더라도 롤백되지 않도록 보장할 수 있습니다. 또한 최종 블록은 Hyperledger, Tendermint 및 기타 pBFT 기반 합의에서 2/3 BP가 서명한 블록입니다. 또한 최종성을 보장하기 위한 프로토콜을 합의에 대한 추가 기능으로 만드는 것이 합리적입니다. 왜냐하면 블록 생성 및 게시와 비동기식으로 작동할 수 있기 때문입니다. 여기 좋은 게 있어요 기사 Ethereum의 최종성에 대해.

완결성은 사용자에게 매우 중요합니다. 완결성이 없으면 BP가 블록을 "보유"하고 네트워크가 좋은 거래를 "본" 후 이를 게시하는 "이중 지출" 공격의 피해자가 될 수 있습니다. 최종성이 없으면 게시된 포크는 블록을 "좋은" 거래로 대체합니다. 즉, "나쁜" 포크에서 동일한 자금이 공격자의 주소로 전송됩니다. PVRB의 경우 최종성에 대한 요구 사항은 훨씬 더 엄격합니다. 왜냐하면 PVRB용 포크를 구축한다는 것은 공격자가 가장 수익성 있는 옵션을 게시하기 위해 여러 가지 무작위 옵션을 준비할 수 있는 기회를 의미하고 가능한 공격 시간을 제한하는 것은 좋은 해결책.

따라서 가장 좋은 옵션은 PVRB와 최종성을 하나의 프로토콜로 결합하는 것입니다. 그런 다음 최종화된 블록 = 최종화된 무작위이며 이것이 바로 우리가 얻어야 했던 것입니다. 이제 플레이어는 N초 안에 무작위를 보장받으며 이를 롤백하거나 다시 재생할 수 없다는 것을 확신할 수 있습니다.

합의 통합 옵션이 좋습니다.

• 블록 생성과 관련된 비동기 구현 가능성 - 블록은 평소와 같이 생성되지만 이와 동시에 PVRB 프로토콜이 작동할 수 있으며 이는 모든 블록에 대해 무작위성을 생성하지 않습니다.
• 스마트 계약에 부과된 제한 없이 무거운 암호화를 구현할 수 있는 능력
• 트랜잭션보다 빠르게 메시지 교환을 구성하는 기능이 블록체인에 포함되어 있습니다. 예를 들어 프로토콜의 일부는 네트워크를 통해 메시지를 배포하지 않고도 노드 간에 작동할 수 있습니다.

또한 단점도 있습니다:

• 테스트 및 개발의 어려움 - 네트워크 오류, 노드 누락, 네트워크 하드 포크를 에뮬레이션해야 합니다.
• 구현 오류에는 네트워크 하드포크가 필요합니다

PVRB를 구현하는 두 가지 방법 모두 생명권이 있지만 현대 블록체인의 스마트 계약 구현은 컴퓨팅 리소스가 여전히 상당히 제한되어 있으며 심각한 암호화로의 전환이 불가능한 경우가 많습니다. 그리고 아래에서 설명하는 것처럼 심각한 암호화가 필요합니다. 이 문제는 분명히 일시적이지만 많은 문제를 해결하려면 계약에 심각한 암호화가 필요하며 점차 나타나고 있습니다(예: Ethereum의 zkSNARK에 대한 시스템 계약).

투명하고 안정적인 프로토콜 메시징 채널을 제공하는 블록체인은 무료로 제공되지 않습니다. 모든 분산형 프로토콜은 Sybil 공격의 가능성을 고려해야 합니다. 모든 작업은 여러 계정의 공동 힘에 의해 수행될 수 있으므로 설계 시 공격자가 임의의 수의 프로토콜을 생성할 수 있는 능력을 고려해야 합니다. 공모하는 참가자들.

PVRB 및 블록 변수.

아직 많은 도박 애플리케이션에서 테스트한 좋은 PVRB를 블록체인에 구현한 사람이 아무도 없다고 말했을 때 나는 거짓말을 하지 않았습니다. 그렇다면 이더리움과 EOS에서 그렇게 많은 도박 애플리케이션은 어디에서 왔습니까? 이것은 여러분을 놀라게 하는 만큼 저를 놀라게 합니다. 완전히 결정적인 환경에서 그렇게 많은 "지속적인" 무작위를 어디서 얻었습니까?

블록체인에서 무작위성을 얻는 가장 좋은 방법은 블록에서 일종의 "예측할 수 없는" 정보를 가져와서 이를 기반으로 무작위 정보를 만드는 것입니다. 간단히 하나 이상의 값을 해싱하면 됩니다. 그러한 계획의 문제점에 관한 좋은 기사 여기에. 예를 들어 블록 해시, 트랜잭션 수, 네트워크 복잡성 및 기타 사전에 알 수 없는 값과 같이 "예측할 수 없는" 값을 블록에서 가져올 수 있습니다. 그런 다음 하나 이상을 해시하면 이론적으로 실제 무작위를 얻을 수 있습니다. 귀하의 계획이 "양자 방지 해시 함수가 있기 때문에 :)"라는 내용을 백서에 추가할 수도 있습니다.

하지만 포스트퀀텀 보안 해시만으로는 충분하지 않습니다. 그 비밀은 PVRB의 요구 사항에 있습니다. 이전 기사에서 그 내용을 상기시켜 드리겠습니다.

1. 결과는 입증 가능한 균일한 분포를 가져야 합니다. 즉, 입증 가능한 강력한 암호화를 기반으로 해야 합니다.
2. 결과의 어떤 비트도 제어할 수 없습니다. 따라서 결과를 미리 예측할 수 없습니다.
3. 프로토콜에 참여하지 않거나 공격 메시지로 네트워크에 과부하를 주어 생성 프로토콜을 방해할 수 없습니다.
4. 위의 모든 사항은 허용되는 부정직한 프로토콜 참가자 수(예: 참가자의 1/3)의 공모에 저항해야 합니다.

이 경우 요구사항 1만 충족되고 요구사항 2는 충족되지 않습니다. 블록에서 예측할 수 없는 값을 해싱하면 균일한 분포와 좋은 무작위성을 얻을 수 있습니다. 그러나 BP는 최소한 "블록을 게시할지 여부"에 대한 옵션을 가지고 있습니다. 따라서 BP는 최소한 두 가지 무작위 옵션, 즉 "자체"와 다른 사람이 블록을 만들면 나올 옵션 중에서 선택할 수 있습니다. BP는 블록을 게시하면 어떤 일이 일어날지 미리 "스누핑"할 수 있으며 이를 수행할지 여부를 간단히 결정할 수 있습니다. 따라서 예를 들어 룰렛에서 "짝수-홀수" 또는 "빨간색/검은색"을 플레이할 때 그는 승리한 경우에만 블록을 게시할 수 있습니다. 이는 또한 예를 들어 "미래에서 온" 블록 해시를 사용하는 전략을 실행 불가능하게 만듭니다. 이 경우, 그들은 “현재 데이터와 미래 블록의 해시를 예를 들어 N + 42 높이로 해싱하여 얻은 무작위가 사용됩니다. 여기서 N은 현재 블록 높이입니다. 이는 계획을 약간 강화하지만, 미래에도 불구하고 BP가 블록을 보유할지 아니면 게시할지 선택할 수 있도록 허용합니다.

이 경우 BP 소프트웨어는 더 복잡해지지만 그리 많지는 않습니다. 간단히 말해서, 거래를 검증하고 블록에 포함시킬 때 승리할 것인지를 빠르게 확인하고, 높은 승리 확률을 얻기 위해 하나의 거래 매개변수를 선택할 수도 있습니다. 동시에, 그러한 조작을 위해 스마트 BP를 잡는 것은 거의 불가능하며, 매번 새로운 주소를 사용하고 의심을 불러일으키지 않고 조금씩 승리할 수 있습니다.

따라서 블록의 정보를 사용하는 방법은 PVRB의 보편적 구현으로 적합하지 않습니다. 베팅 크기 제한, 플레이어 수 제한 및/또는 KYC 등록(한 플레이어가 여러 주소를 사용하는 것을 방지하기 위해)이 있는 제한된 버전에서는 이러한 계획이 소규모 게임에 효과적일 수 있지만 그 이상은 아닙니다.

PVRB 및 커밋 공개.

좋아요, 해싱 덕분에 그리고 적어도 블록 해시와 기타 변수의 상대적 예측 불가능성 덕분입니다. 선두에 있는 채굴자들의 문제를 해결한다면, 좀 더 적합한 것을 얻어야 합니다. 이 계획에 사용자를 추가해 보겠습니다. 무작위성에 영향을 미치도록 하세요. 모든 기술 지원 직원은 IT 시스템에서 가장 무작위적인 것이 사용자의 행동이라고 말할 것입니다. :)

사용자가 단순히 난수를 보내고 그 결과가 예를 들어 합계의 해시로 계산되는 순진한 방식은 적합하지 않습니다. 이 경우, 마지막 플레이어는 자신의 무작위를 선택하여 결과가 어떻게 될지 제어할 수 있습니다. 이것이 바로 매우 널리 사용되는 커밋-공개 패턴이 사용되는 이유입니다. 참가자는 먼저 무작위(커밋)에서 해시를 보낸 다음 무작위를 직접 엽니다(공개). "공개" 단계는 필요한 커밋이 수집된 후에만 시작되므로 참가자는 이전에 보낸 무작위 해시를 정확하게 보낼 수 있습니다. 이제 이 모든 것을 블록의 매개변수와 함께 결합해 보겠습니다. 미래에서 가져온 것보다 낫습니다(무작위성은 미래 블록 중 하나에서만 찾을 수 있음). 짜잔 - 무작위성이 준비되었습니다! 이제 모든 플레이어는 결과적인 무작위성에 영향을 미치고 사전에 알려지지 않은 자신의 무작위성으로 이를 무시함으로써 악의적인 BP를 "패배"할 수 있습니다... 공개 단계에서 프로토콜을 열지 않음으로써 프로토콜을 방해하는 것에 대한 보호 기능을 추가할 수도 있습니다. 커밋할 때 거래에 특정 금액을 첨부하도록 요구합니다. 보증금은 공개 절차 중에만 반환됩니다. 이 경우 공개하지 않고 저지르는 것은 수익성이 없습니다.

좋은 시도였고 게임 DApp에도 이러한 방식이 존재하지만 아쉽게도 이것만으로는 충분하지 않습니다. 이제 채굴자뿐만 아니라 프로토콜에 참여하는 모든 참가자도 결과에 영향을 미칠 수 있습니다. 변동성을 줄이고 비용을 들여 가치 자체를 제어하는 ​​것이 여전히 가능하지만, 채굴자의 경우처럼 추첨 결과가 PVRB 프로토콜 참여 수수료보다 더 가치가 있는 경우 무작위로 -생산자(RP)는 공개 여부를 결정할 수 있으며 적어도 두 가지 무작위 옵션 중에서 선택할 수 있습니다.
하지만 범죄를 저지르고 밝히지 않는 사람을 처벌하는 것이 가능해졌고, 이 제도가 도움이 될 것입니다. 단순성은 심각한 이점입니다. 더 심각한 프로토콜에는 훨씬 더 강력한 계산이 필요합니다.

PVRB 및 결정적 서명.

RP가 "사전 이미지"가 제공되는 경우 영향을 미칠 수 없는 의사 난수를 제공하도록 강제하는 또 다른 방법이 있습니다. 이는 결정론적 서명입니다. 예를 들어 이러한 서명은 RSA이며 ECS는 아닙니다. RP에 RSA와 ECC라는 한 쌍의 키가 있고 개인 키로 특정 값에 서명하는 경우 RSA의 경우 단 하나의 서명을 얻게 되며 ECS의 경우 원하는 수의 서명을 생성할 수 있습니다. 유효한 서명이 다릅니다. 이는 ECS 서명을 생성할 때 서명자가 선택한 임의의 숫자가 사용되며 어떤 방식으로든 선택할 수 있어 서명자가 여러 서명 중 하나를 선택할 수 있는 기회를 제공하기 때문입니다. RSA의 경우: “XNUMX개의 입력 값” + “XNUMX개의 키 쌍” = “XNUMX개의 서명”. 다른 RP가 어떤 서명을 받게 될지 예측하는 것은 불가능하므로 동일한 값에 서명한 여러 참가자의 RSA 서명을 결합하여 결정적 서명을 가진 PVRB를 구성할 수 있습니다. 예를 들어 이전 무작위입니다. 이 계획은 많은 자원을 절약합니다. 서명은 프로토콜에 따른 올바른 동작을 확인하는 동시에 무작위성의 원천입니다.

그러나 결정론적 서명이 있더라도 이 체계는 여전히 "마지막 행위자" 문제에 취약합니다. 마지막 참가자는 서명을 게시할지 여부를 결정하여 결과를 제어할 수 있습니다. 계획을 수정하고, 블록 해시를 추가하고, 결과를 미리 예측할 수 없도록 라운드를 만들 수 있지만 이러한 모든 기술은 많은 수정을 고려하더라도 한 참가자가 집단에 미치는 영향 문제는 여전히 해결되지 않은 상태로 남아 있습니다. 결과적으로 신뢰할 수 없는 환경이 발생하며 경제적, 시간적 제약이 있는 경우에만 작업할 수 있습니다. 또한 RSA 키(1024 및 2048비트)의 크기가 상당히 커서 블록체인 트랜잭션의 크기는 매우 중요한 매개변수입니다. 문제를 해결하는 간단한 방법은 없는 것 같습니다. 계속 진행하겠습니다.

PVRB 및 비밀 공유 체계

암호화에는 네트워크가 단 하나의 PVRB 값에 동의하도록 허용하는 체계가 있으며, 이러한 체계는 일부 참가자의 악의적인 행동에 저항합니다. 숙지할 가치가 있는 유용한 프로토콜 중 하나는 Shamir의 비밀 공유 체계입니다. 비밀(예: 비밀 키)을 여러 부분으로 나누고, 이 부분을 N명의 참가자에게 배포하는 역할을 합니다. 비밀은 N개 중 M개 부분이 복구하기에 충분하고 M개 부분이 될 수 있는 방식으로 배포됩니다. 손가락에 기능을 알 수 없는 그래프가 있는 경우 참가자는 그래프에서 포인트를 교환하고 M 포인트를 받은 후 전체 기능을 복원할 수 있습니다.
좋은 설명이 에 나와 있습니다. 위키 하지만 프로토콜을 머릿속에서 재생하기 위해 실제로 가지고 노는 것은 다음과 같은 경우에 유용합니다. 데모 페이지.

FSSS(Fiat-Shamir Secret Sharing) 방식을 순수한 형태로 적용할 수 있다면 파괴할 수 없는 PVRB가 될 것입니다. 가장 간단한 형태의 프로토콜은 다음과 같습니다.

• 각 참가자는 자신의 무작위를 생성하고 그로부터 다른 참가자에게 공유를 배포합니다.
• 각 참가자는 다른 참가자의 비밀 중 자신의 부분을 공개합니다.
• 참가자가 M개 이상의 공유를 보유한 경우 이 참가자의 수는 계산될 수 있으며 공개된 참가자 세트에 관계없이 고유합니다.
• 밝혀진 무작위의 조합이 원하는 PVRB입니다.

여기서 무작위성 공개 임계값의 달성이 자신에게만 의존하는 경우를 제외하고 개별 참가자는 더 이상 프로토콜 결과에 영향을 미치지 않습니다. 따라서 이 프로토콜은 프로토콜에서 작동하고 사용 가능한 RP의 필수 비율이 있는 경우 작동하며 암호화 강도에 대한 요구 사항을 구현하고 "마지막 행위자" 문제에 저항합니다.

이는 이상적인 옵션이 될 수 있습니다. Fiat-Shamir 비밀 공유를 기반으로 하는 이 PVRB 체계는 예를 들어 다음에서 설명됩니다. 이 기사. 하지만 위에서 언급한 것처럼 이를 블록체인에 정면으로 적용하려고 하면 기술적 한계가 나타난다. 다음은 EOS 스마트 계약의 프로토콜 구현 테스트와 가장 중요한 부분인 게시된 공유 참가자 확인의 예입니다. 암호. 증명 검증에는 여러 스칼라 곱셈이 필요하며 사용되는 숫자가 매우 크다는 것을 코드에서 볼 수 있습니다. 블록체인에서는 블록 생산자가 거래를 처리하는 순간 검증이 이루어지며, 일반적으로 모든 참가자는 프로토콜의 정확성을 쉽게 검증해야 하므로 검증 기능의 속도에 대한 요구 사항이 매우 심각하다는 점을 이해해야 합니다. . 이 옵션에서는 검증이 거래 제한(0.5초) 내에 맞지 않아 옵션이 효과가 없는 것으로 나타났습니다.

검증 효율성은 일반적으로 블록체인의 고급 암호화 체계를 사용하는 데 가장 중요한 요구 사항 중 하나입니다. 증거 생성, 메시지 준비 - 이러한 절차는 오프체인으로 수행되어 고성능 컴퓨터에서 수행될 수 있지만 검증을 우회할 수는 없습니다. 이는 PVRB의 또 다른 중요한 요구 사항입니다.

PVRB 및 임계값 서명

비밀 공유 계획에 대해 알게 된 우리는 "임계값"이라는 키워드로 통합된 전체 프로토콜 클래스를 발견했습니다. 일부 정보를 공개하려면 N 중 M명의 정직한 참가자의 참여가 필요하고 정직한 참가자 집합이 N의 임의의 하위 집합일 수 있는 경우 "임계값" 방식을 사용합니다. 우리가 "마지막 행위자" 문제를 처리할 수 있도록 허용한 것은 바로 그들이었습니다. 이제 공격자가 자신의 비밀 부분을 공개하지 않으면 다른 정직한 참가자가 그를 대신해 이를 수행할 것입니다. 이러한 계획은 일부 참가자가 프로토콜을 방해하더라도 단 하나의 의미에 대한 합의를 허용합니다.

결정론적 서명과 임계값 체계의 조합을 통해 PVRB 구현을 위한 매우 편리하고 유망한 체계를 개발할 수 있었습니다. 이는 결정론적 임계값 서명입니다. 여기 기사 임계값 서명의 다양한 용도에 대해 설명하고 여기에 또 다른 좋은 내용이 있습니다. longread 대시에서.

마지막 기사에서는 BLS 서명에 대해 설명합니다(BLS는 Boneh-Lynn-Shacham을 의미하며, 여기에 기사)는 프로그래머에게 매우 중요하고 매우 편리한 품질을 가지고 있습니다. 공개, 비밀, 공개 키 및 BLS 서명은 간단한 수학적 연산을 사용하여 서로 결합될 수 있으며, 이들의 조합은 유효한 키와 서명으로 유지되므로 많은 항목을 쉽게 집계할 수 있습니다. 서명은 하나에, 여러 공개 키는 하나로 묶습니다. 또한 결정적이며 동일한 입력 데이터에 대해 동일한 결과를 생성합니다. 이러한 품질 덕분에 BLS 서명의 조합은 그 자체로 유효한 키이며, 이를 통해 N 참가자 중 M이 M이 열릴 때까지 결정적이고 공개적으로 검증 가능하며 예측할 수 없는 단 하나의 서명을 생성하는 옵션을 구현할 수 있습니다. 참가자 .

임계값 BLS 서명이 있는 방식에서 각 참가자는 BLS(예: 이전 무작위)를 사용하여 무언가에 서명하고 공통 임계값 서명은 원하는 무작위입니다. BLS 서명의 암호화 속성은 무작위 품질에 대한 요구 사항을 충족하고, 임계값 부분은 "최종 행위자"로부터 보호하며, 키의 고유한 결합 가능성을 통해 예를 들어 프로토콜 메시지의 효율적인 집계를 허용하는 더 많은 흥미로운 알고리즘을 구현할 수 있습니다. .

따라서 블록체인에 PVRB를 구축하는 경우 BLS 임계값 서명 체계를 사용하게 될 가능성이 높으며 여러 프로젝트에서 이미 이를 사용하고 있습니다. 예를 들어 DFinity(여기에 회로를 구현하는 벤치마크, 그리고 여기에 검증 가능한 비밀 공유의 구현 예) 또는 Keep.network(여기에 임의의 비콘이 있습니다) 노란 종이, 그러나 예 프로토콜을 제공하는 스마트 계약).

PVRB 구현

불행하게도 우리는 보안과 안정성이 입증된 PVRB 블록체인에 구현된 기성 프로토콜을 아직 볼 수 없습니다. 프로토콜 자체는 준비되어 있지만 기술적으로 기존 솔루션에 적용하는 것은 쉽지 않습니다. 중앙 집중식 시스템의 경우 PVRB는 의미가 없으며 분산형 시스템은 CPU, 메모리, 스토리지, I/O 등 모든 컴퓨팅 리소스에서 엄격하게 제한됩니다. PVRB 설계는 최소한 일부 실행 가능한 블록체인에 대한 모든 요구 사항을 충족하는 무언가를 만들기 위해 다양한 프로토콜을 조합하는 것입니다. 한 프로토콜은 더 효율적으로 계산하지만 RP 간에 더 많은 메시지가 필요하고, 다른 프로토콜은 매우 적은 메시지가 필요하지만 증명을 만드는 데 수십 분 또는 심지어 몇 시간이 걸리는 작업이 될 수 있습니다.

고품질 PVRB를 선택할 때 고려해야 할 요소를 나열하겠습니다.

• 암호화 강도. PVRB는 단일 비트를 제어할 수 없어 엄격하게 편견이 없어야 합니다. 일부 구성표에서는 그렇지 않으므로 암호 전문가에게 전화하십시오.
• "마지막 배우" 문제. PVRB는 하나 이상의 RP를 제어하는 ​​공격자가 두 가지 결과 중 하나를 선택할 수 있는 공격에 저항해야 합니다.
• 프로토콜 파괴 문제. PVRB는 하나 이상의 RP를 제어하는 ​​공격자가 무작위인지 여부를 결정하고 이에 영향을 미칠 수 있는 확률이 보장되거나 주어진 공격에 저항해야 합니다.
• 메시지 수 문제. 귀하의 RP는 블록체인에 최소한의 메시지를 보내야 하며 "정보를 보냈고 특정 참가자의 응답을 기다리고 있습니다."와 같은 상황과 같은 동기식 작업을 최대한 피해야 합니다. P2P 네트워크, 특히 지리적으로 분산된 네트워크에서는 빠른 응답을 기대해서는 안 됩니다.
• 계산 복잡성 문제. PVRB 온체인의 모든 단계에 대한 검증은 네트워크의 모든 전체 클라이언트에 의해 수행되기 때문에 매우 쉽습니다. 스마트 계약을 사용하여 구현을 수행하는 경우 속도 요구 사항이 매우 엄격합니다.
• 접근성과 활력의 문제. PVRB는 일정 기간 동안 네트워크의 일부를 사용할 수 없고 RP의 일부가 작동을 멈추는 상황에 대한 복원력을 갖추기 위해 노력해야 합니다.
• 신뢰할 수 있는 설정 및 초기 키 배포 문제. PVRB가 프로토콜의 기본 설정을 사용하는 경우 이는 별개의 크고 심각한 이야기입니다. 여기 예. 참가자가 프로토콜을 시작하기 전에 서로 키를 알려야 하는 경우 참가자의 구성이 변경되는 경우에도 문제가 됩니다.
• 개발 문제. 필요한 언어로 된 라이브러리의 가용성, 보안 및 성능, 홍보, 복잡한 테스트 등

예를 들어 임계값 BLS 서명에는 심각한 문제가 있습니다. 작업을 시작하기 전에 참가자는 키를 서로에게 배포하여 임계값이 작동할 그룹을 구성해야 합니다. 이는 분산형 네트워크에서 최소한 한 번의 교환 라운드를 기다려야 함을 의미하며, 예를 들어 생성된 랜드가 게임에서 거의 실시간으로 필요하다는 점을 고려하면 이는 이 단계에서 프로토콜을 방해할 수 있음을 의미합니다. , 그리고 임계값 방식의 장점은 상실됩니다. 이 문제는 이미 이전 문제보다 간단하지만 여전히 임계 그룹 형성을 위한 별도의 절차 개발이 필요하며, 이를 따르지 않는 참가자의 자금 예치 및 인출(슬래싱)을 통해 경제적으로 보호되어야 합니다. 규약. 또한 허용 가능한 수준의 보안을 갖춘 BLS 검증은 예를 들어 표준 EOS 또는 Ethereum 거래에 적합하지 않습니다. 즉, 검증할 시간이 충분하지 않습니다. 계약 코드는 가상 머신에 의해 실행되는 WebAssembly 또는 EVM입니다. 암호화 기능은 아직 기본적으로 구현되지 않았으며 기존 암호화 라이브러리보다 수십 배 느리게 작동합니다. 많은 프로토콜은 단순히 키 볼륨을 기준으로 한 요구 사항을 충족하지 않습니다. 예를 들어 RSA의 경우 1024 및 2048비트는 비트코인 ​​및 이더리움의 표준 트랜잭션 서명보다 4~8배 더 큽니다.

다양한 프로그래밍 언어로 구현된 것 또한 중요한 역할을 합니다. 특히 새로운 프로토콜의 경우 그 수가 적습니다. 합의 통합 옵션을 사용하려면 플랫폼 언어로 프로토콜을 작성해야 하므로 geth의 경우 Go, Parity의 경우 Rust, EOS의 경우 C++에서 코드를 찾아야 합니다. 모든 사람은 JavaScript 코드를 찾아야 하며 JavaScript와 암호화는 특별히 가까운 친구가 아니기 때문에 WebAssembly가 도움이 될 것입니다. WebAssembly는 이제 확실히 차세대 인터넷 표준이라고 주장합니다.

결론

전편에 바랍니다 기사 저는 블록체인에서 난수를 생성하는 것이 분산형 네트워크 수명의 여러 측면에 매우 중요하다는 점을 확신시켰으며, 이 기사를 통해 이 작업이 매우 야심적이고 어렵지만 좋은 솔루션이 이미 존재한다는 것을 보여주었습니다. 일반적으로 프로토콜의 최종 설계는 설정부터 결함 에뮬레이션까지 모든 측면을 고려하는 대규모 테스트를 수행한 후에만 가능하므로 팀 백서 및 기사에서 기성 레시피를 찾을 가능성이 거의 없으며 우리는 절대 그렇지 않습니다. 다음 XNUMX~XNUMX년 안에 결정하세요. “이렇게 하세요, 딱 맞습니다.”라고 쓰세요.

안녕하십니까, 개발 중인 블록체인의 PVRB에 대해 하야, 우리는 임계값 BLS 서명을 사용하기로 결정했으며, 허용 가능한 수준의 보안을 갖춘 스마트 계약의 검증이 아직 불가능하기 때문에 합의 수준에서 PVRB를 구현할 계획입니다. 한 번에 두 가지 방식을 사용할 수 있습니다. 첫째, 장기 Random_seed를 생성하기 위한 값비싼 비밀 공유, 그리고 이를 결정론적 임계값 BLS 서명을 사용하는 고주파 무작위 생성의 기초로 사용합니다. 아마도 우리는 다음으로만 제한할 것입니다. 계획 중 하나. 불행히도 프로토콜이 무엇인지 미리 말하는 것은 불가능합니다. 유일하게 좋은 점은 과학에서와 마찬가지로 공학 문제에서도 부정적인 결과도 결과이며 문제를 해결하려는 각각의 새로운 시도는 다음 단계라는 것입니다. 문제와 관련된 모든 사람의 연구. 비즈니스 요구 사항을 충족하기 위해 우리는 게임 애플리케이션에 신뢰할 수 있는 엔트로피 소스를 제공하는 구체적인 실제 문제를 해결하므로 블록체인 자체, 특히 체인 최종성 및 네트워크 거버넌스 문제에도 주의를 기울여야 합니다.

실제 애플리케이션, 다중 감사, 로드 및 물론 실제 공격을 통해 테스트하기에 충분한 시간 동안 사용되었을 블록체인에서 입증된 저항성 PVRB를 아직 볼 수는 없지만 가능한 경로의 수는 다음을 확인합니다. 해결책이 존재하며, 이러한 알고리즘 중 어떤 것이 결국 문제를 해결할 것인가. 우리는 결과를 공유하게 되어 기쁘게 생각하며, 엔지니어가 동일한 갈퀴를 두 번 밟지 않도록 하는 기사와 코드에 대해 이 문제를 작업하고 있는 다른 팀에도 감사드립니다.

따라서 분산형 랜덤을 설계하는 프로그래머를 만날 때 세심하고 배려하며 필요한 경우 심리적 도움을 제공하십시오 :)

출처 : habr.com