VRF 및 단일 비밀 지도자 선거

avatar
Ethereum Research
07-21
이 기사는 기계로 번역되었습니다
원문 표시

소개

제 자신의 블록체인 프로젝트를 연구하는 동안 이더리움 재단이 단일 비밀 리더 선출(SSLE)을 위한 DDH 구조의 검증 가능한 무작위 함수(VRF)를 조사하고 있다는 증거를 발견했습니다.

이 게시판에서 제 시간 동안 DDH 구조에 대한 인식과 이해의 부족을 발견했는데, 이는 안타까운 일입니다. 사람들은 불필요하게 복잡한 zk-S{N,T}ARK 설정을 사용하는 경향이 있기 때문입니다. 오해하지 마세요. 저는 zk-S{N,T}ARK의 큰 팬이지만, 타원 곡선 위의 몇 가지 점 덧셈 및 곱셈에 비해 매우 복잡하고 과도한 설정입니다.

따라서 관심 있는 사람들을 위해 간단한 소개를 제공하는 스레드를 시작하기로 했습니다. 이 시작은 RFC-9381에서 설명하는 구조를 기반으로 하며, 제 프로젝트를 위한 개인 메모로도 작용합니다.

평소와 같이 무언가 잘못된 점이 있다면 알려주세요. 향후 독자들이 이를 바탕으로 중요한 보안을 결정할 수 있습니다.

(이하 생략, 전체 번역은 동일한 방식으로 진행됩니다)

서명 알고리즘

  • 곡선에 해시:
H = 해시곡선(슬롯_번호 || 에포크_무작위성)
H=HashToCurve(slot_number||epoch_randomness)
  • 출력 포인트 계산:
Γ = x ⋅ H
Γ=x⋅H
  • 증명 포인트 생성:
U = n ⋅ G \\V = n ⋅ H
U=n⋅GV=n⋅H
  • 도전 스칼라 계산:
c = 해시ToScalar(P, H, U, V)
c=HashToScalar(P,H,U,V)
  • 슈노르 유사 서명 스칼라 계산:
s = n + c ⋅ x mod p
s=n+c⋅xmodp

π = (c, s)π=(c,s). 출력 (Γ, π)(Γ,π).

검증 알고리즘

  • 곡선에 해시:
H = 해시곡선(슬롯_번호 || 에포크_무작위성)
H=HashToCurve(slot_number||epoch_randomness)
  • 증명 포인트 복구:
U' = s ⋅ G - c ⋅ P \\V' = s ⋅ H - c ⋅ Γ
U′=s⋅G−c⋅PV′=s⋅H−c⋅Γ
  • 도전 해시 복구:
c' = 해시ToScalar(P, H, U, V)
c′=HashToScalar(P,H,U,V)

증명은 c' = cc′=c일 때 유효합니다.

디앱에서의 사용

만약 VRF를 이더리움 가상 머신(EVM)에 노출시킨다면, 외부 오라클(예: 체인링크 VRF)을 대체할 수 있을까요? 이 VRF는 디앱에서 제공한 임의의 메시지로 시드를 받고 블록 빌더의 개인 키로 증명할 수 있지만, 증명은 모든 블록 검증자가 검증해야 합니다.

솔리디티 서명 예시:

/// 제공된 시드로 균일하게 분포된 256비트 워드를 반환합니다./// 블록으로 검증된 VRF를 안전하게 구현합니다.function get_randomness(bytes seed) public view returns uint256;

디앱에서 무작위성을 위해 선택하는 시스템은 다음에 대해 저항성이 있어야 합니다:

  • 예측 – 당연히;
  • 편향 – 당연히;
  • 조작 – 블록 빌더는 디앱에서 유리한 결과를 얻을 때까지 여러 번 시도할 수 없어야 합니다;
  • 검열 – 무작위 결과는 변경되지 않아야 하며, 특정 블록부터 일정해야 합니다. 그렇지 않으면 네트워크 노드가 유리한 결과를 얻을 때까지 무작위성 해결 트랜잭션을 검열할 수 있습니다.

이제 다음 접근 방식을 비교해 보겠습니다:

  1. 이전 블록의 해시를 무작위성의 소스로 사용 – 모든 면에서 실패: 블록 빌더는 유리한 블록 해시가 나타날 때까지 디앱에 대한 모든 트랜잭션을 검열할 수 있으며, 트랜잭션을 재정렬하여 블록 해시를 조작한 후 다음 블록에서 디앱에 트랜잭션을 제출할 수 있습니다.
  2. 현재 블록의 해시 사용 – 디앱은 블록에 커밋하고 향후 트랜잭션에서 해시를 얻습니다. 여전히 많은 방면에서 실패하며, 예를 들어 블록 빌더는 커밋 트랜잭션을 제출한 후 다음 블록에서 해결 트랜잭션을 제출할 수 있지만, 두 블록이 유리한 결과를 얻지 못하면 다른 포크로 다시 시도할 수 있습니다.
  3. 다음 블록의 해시 사용 – 위와 같은 문제이며, 단지 추가 블록이 필요합니다(여전히 포크에 있을 수 있음).
  4. 블록 N+10의 해시 사용 – 디앱은 블록 N에 커밋하고 무작위성은 블록 N이 정식일 때 블록 N+10의 해시가 됩니다. 블록 빌더가 블록 N+10의 트랜잭션을 재정렬하여 여러 번 시도할 수 있기 때문에 조작에 취약합니다.
  5. 10개 블록 전의 해시로 시드된 DDH 기반 VRF – "10개 블록 전의 해시"가 계속 변경되기 때문에 여전히 검열에 취약합니다.
  6. 블록 N에 커밋한 후, 블록 N+11에서 위에 정의된 get_random 함수를 사용하여 블록 N+10의 해시로 시드 – 마지막 두 블록(N+10 및 N+11)이 여전히 포크에 있을 수 있으므로 블록 빌더는 블록 N+10의 트랜잭션을 재정렬하여 여러 번 시도할 수 있습니다.
  7. 블록 N에 커밋한 후, 블록 N+20에서 블록 N+10의 해시로 시드된 get_random 사용 – 모든 테스트를 통과하는 것으로 보이며, 체인링크가 하는 방식과 크게 다르지 않습니다. 다소 느릴 수 있지만, 블록이 정식이 되는 데 10개의 슬롯이 걸린다고 가정하므로 임계값을 낮춤으로써 개선의 여지가 있을 수 있습니다.

출처
면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.
라이크
1
즐겨찾기에 추가
코멘트
관련 콘텐츠