블록체인 합의 분석을 위한 간단한 프레임워크

特邀专栏作者

2019-06-26 04:26

이 기사는 약 3615자로, 전체를 읽는 데 약 6분이 소요됩니다

이 글은 서로 다른 블록체인 합의를 간단하게 비교하기 위해 블록체인 합의를 분석하기 위한 간단한 프레임워크를 제안하려고 합니다.

첫 번째 레벨 제목

블록체인 합의 비교
[1] 지연은 트랜잭션이 합의에 의해 확인되는 데 필요한 시간입니다. 낮음: <10초, 중간: 10초-600초, 높음: >=600초
[2] 합의 성능을 유지하면서 허용되는 합의 노드의 수. 낮음: <100, 중간: >=100, 높음: 제한 없음
[4] EOS 홍보는 BFT를 의미하지만 일부 친구들과 의사 소통을 한 후 여전히 NC가 사용된다는 것을 알게 되었으며 이는 EOS의 DPoS와 BitShares의 DPoS가 동일해야 함을 의미합니다.

첫 번째 레벨 제목

프레임워크 아이디어

첫 번째 레벨 제목

기본 요구 사항

합의의 기본 메트릭에는 정확성과 성능이라는 두 가지 측면이 포함됩니다. 정확성에는 다음이 포함됩니다.
활성 - 요청/트랜잭션은 항상 한정된 시간 내에 처리됩니다.

텍스트비동기 네트워크가운데가운데항상 일관성과 활성을 보장하는 것은 매우 어려운 작업입니다.

, 그래서 합의 설계는 일반적으로 특정 경우에 한 점을 보장하고 다른 점을 포기하는 것을 선택합니다.예를 들어 Bitcoin에서 사용하는 Nakamoto 합의는 활성을 보장하는 데 우선 순위를 두는 반면 BFT 합의는 일관성을 보장하는 데 우선 순위를 둡니다.

기능은 다음과 같습니다.처리량
- 단위 시간당 시스템이 처리할 수 있는 요청 수지연 시간- 시작부터 완료까지의 요청/트랜잭션/확실히

소요시간

합의 노드 수, 합의 메시지의 복잡성, 메시지 검증에 필요한 시간, 합의에 사용 가능한 대역폭, 합의 설계 경향 등 처리량과 대기 시간에 영향을 미치는 많은 요소가 있습니다. 일반적으로 말해서 합의 메시지 복잡도가 더 낮기 때문에 처리량과 대기 시간을 모두 갖기가 어렵습니다. ? 전혀 모른다). 짧은 대기 시간을 원하면 가능한 한 빨리 각 요청/트랜잭션에 동의해야 합니다. 즉, 단일 요청/트랜잭션에는 더 높은 메시지 복잡성이 필요합니다. 이는 단일 요청/트랜잭션의 메시지 복잡성을 줄여주지만 높은 대기 시간을 유발하기도 합니다.합의 성능에 대해 Nervos 연구팀의 Zhang Ren이 제안한 보다 유익한 지표는 다음과 같습니다.: 동일한 대역폭에서 합의가 차지하는 대역폭이 낮을수록 합의 처리량은 높아집니다.

첫 번째 레벨 제목

블록체인 컨센서스의 특징

동적 참가자 집합무허가 여부("권한이 필요하지 않음"으로 번역하면 너무 복잡합니다."퍼블릭 체인"을 사용하는 것은 정확하지 않습니다.

, 여기서는 여전히 단어 사용) 또는 허가된 블록체인, 가장 중요한 기능은 오래 실행되는 개방형 시스템이라는 것입니다. 장기 운영과 공개 중첩의 결과 합의 참여자는 항상 변경되며, 때때로 이전 합의 노드가 떠나고 새로운 합의 노드가 합류합니다. 합의 참여자는 동적 집합입니다. 합의 참여자들의 동적인 변화에 어떻게 대처하느냐는 블록체인 합의의 핵심 이슈입니다.

블록체인 합의와 달리 전통적인 합의 연구는 종종 고정된 참가자 집합을 먼저 가정한 다음 이 집합 내에서 합의에 도달하는 방법을 연구하고 때때로 참가자 집합의 변경을 처리하는 방법을 논의하며 기본적으로 무엇을 신경 쓰지 않습니다. 컨센서스 자격에 참여해야 합니다. 연구의 초점은 합의의 정확성(예: 일관성 및 활성도)을 보장하는 방법이며 합의 집합을 형성하는 방법은 부수적인 주제일 뿐입니다. 전통적인 합의의 응용 시나리오는 종종 중앙 집중식 제어 네트워크이며 증감 서버는 모두 자체적이므로 그러한 초점을 형성하는 것은 당연합니다.

많은 수의 참가자

분산화는 무허가 블록체인 합의 프로토콜의 고유한 목표입니다. 우리는 보통 탈중앙화의 정도를 합의 참여 임계값으로 측정합니다(이것이 왜 좋은 측정일까요?). 참여 임계값이 낮을수록 탈중앙화 정도는 높아집니다. 낮은 참여 임계값의 자연스러운 결과는 컨센서스 참여자 집합이 매우 클 수 있으므로 컨센서스 프로토콜의 설계는 참여자의 증가로 인해 컨센서스 효율성이 감소하지 않도록 이를 고려해야 합니다.

최소 신뢰 모델

합의 알고리즘을 실행하는 목적은 계산 요청에 대해 일관된 계산 결과를 생성하는 것이며, 이 과정에서 요청을 시작하는 노드와 요청을 처리하는 노드가 있어야 합니다. 전통적인 합의 모델에서 일부 합의 알고리즘은 요청 처리 노드 집합 내에서 완전히 실행되고 일부 합의 알고리즘은 요청 개시 노드와 처리 노드에서 함께 실행됩니다.어쨌든 신뢰 경계는 일반적으로 요청 개시 노드 사이입니다. 그리고 요청 실행 노드. , 시작 노드는 계산 요청을 실행 노드로 보내고, 실행 노드는 결과를 계산하여 시작 노드로 반환하며, 시작 노드는 실행 노드의 계산 결과를 신뢰한다(반대로, 실행 노드가 반드시 프로세스를 신뢰하지는 않음).

블록체인 합의의 신뢰 모델은 상당히 다르며 신뢰에 대한 요구 사항은 종종 훨씬 작습니다. 무허가형 블록체인 네트워크에서는 동일한 노드가 트랜잭션을 시작하고 합의에 참여하며 노드는 단순히 다른 노드의 합의 결과를 신뢰하는 것이 아니라 합의 결과를 검증해야 합니다. 비트코인을 예로 들면 풀 노드가 채굴에 참여하면 요청(트랜잭션)을 시작하는 노드인 동시에 요청(트랜잭션)을 처리하는 노드입니다. 조용한 풀노드만 원하고 마이닝에 참여하지 않더라도 받은 요청 처리 결과(블록)를 스스로 검증하며 다른 합의 노드가 제공한 결과를 신뢰하지 않는다. 이러한 풀 노드는 다수 컴퓨팅 파워가 선택한 트랜잭션의 순서를 따르기로 선택할 뿐 다수 컴퓨팅 파워가 제공하는 트랜잭션 결과를 믿지 않습니다. 이것은 최소 신뢰 모델입니다.

SPV/라이트 노드는 풀 노드보다 더 강력한 신뢰 모델을 사용하고(강할수록 신뢰에 대한 더 많은 가정을 의미함) 트랜잭션 실행을 확인하지 않고 블록 헤더의 유효성만 확인합니다. 블록 헤더의 유효성을 검증하는 방법은 블록체인 합의 설계의 또 다른 핵심 문제입니다. 유효성이 블록 헤더에 첨부된 비대칭 서명에 의해서만 검증된다면, 이 신뢰 모델은 기존 합의의 요청 처리 노드도 결과에 서명을 추가할 수 있기 때문에 기본적으로 기존 합의의 신뢰 모델과 동일합니다. 모델은 잘 알려진 장거리 공격과 같은 동적 액터 세트를 결합할 때 일련의 문제가 발생합니다. PoW를 통해 블록헤더의 유효성을 검증하면 이런 문제는 없을 것인데 블록헤더의 검증효율을 어떻게 더 높일 것인가가 주류 연구방향이다.

간단한 분석 프레임워크

위의 분석을 기반으로 다양한 블록체인 합의를 비교하기 위한 간단한 블록체인 합의 분석 프레임워크를 분류할 수 있습니다.
입력 방법* - 컴퓨팅 파워 구매 / 모기지 토큰 / …
블록 생성 방법* - 차례로 블록 생성/PoW 무작위 선택/온체인 의사 무작위/VRF 무작위 선택/…
합의 방식* - Nakamoto Consensus / BFT /…
종료 방법* - 채굴 중지 / 언스테이크 / ...
일관성 - 얼마나 많은 악성 노드/컴퓨팅 파워/지분/…이 허용될 수 있습니까?
Liveness - 얼마나 많은 악성 노드/컴퓨팅 파워/지분/…이 허용될 수 있습니까?
대기 시간 - 트랜잭션이 완전히 확인되는 데 걸리는 시간(번복될 확률은 x보다 작음)
대역폭 효율성 - 컨센서스에 의한 대역폭 활용률, 높을수록 좋음

노드 수 - 합의 노드 수의 상한이 높은지 낮은지 여부

[1] 예를 들어:
99% 확실성[2] 고려
[3] 이기적인 채굴정상적인 컴퓨팅 파워가 아무리 작더라도 블록을 생성할 수 있는 기회가 있습니다.
[4] https://github.com/tendermint...
[5] https://medium.com/nervosnetw...

블록체인 합의 프로토콜의 경우 처음 4개 지점(* 포함)은 기본적으로 다음과 같은 특성을 결정합니다. 우리가 일반적으로 "PoW 합의" 또는 "PoS 합의"라고 부르는 것이 매우 모호한 설명이라는 것도 이 프레임워크를 통해 쉽게 알 수 있습니다. 좋다. 토큰을 스테이킹하여 참여하고, PoW를 통해 블록 노드를 선택하고, Nakamoto Consensus를 통해 가장 긴(무거운) 체인을 형성해야 하는 프로토콜을 설계하는 것과 같이 매우 혼합된 합의 프로토콜을 설계할 수도 있습니다. 스테이킹 핫스팟) 또는 PoW(일정 난이도를 충족하는 PoW를 제공해야 합의에 참여)를 통해 참여해야 하는 프로토콜을 설계하고 VRF를 통해 블록 노드를 선택하고 BFT(이를 PoW라고도 함)를 통해 합의에 도달합니다. +VRF/BFT, 첫눈에 진심으로 프로페셔널한 느낌을 줍니다.)