저자: Shew, GodRealmX
최근 시장의 큰 주목을 받고 있는 하이퍼리퀴드는 가장 영향력 있는 온체인 주문장 거래소 중 하나로, 메사리가 '바이낸스 온 더 체인(Binance on the chain)'으로 평가하는 동안 TVL이 20억 달러를 넘어섰습니다. 레이어 3의 관점과 애플리케이션 체인 내러티브가 다시 주목을 받고 있습니다. 토큰 출시 한 달 만에 FDV를 300억 달러로 끌어올리는 눈부신 성과로 Hyperliquid는 일반 사용자부터 실무자까지 광범위한 관심을 얻었습니다. 동시에 Hyperliquid에 대한 수많은 연구 보고서가 시장에 나타났습니다. 기사는 기본적으로 주문장 제품 기능 및 거래 메커니즘의 특징에 초점을 맞추며, 그 뒤에 있는 기술 구조 및 보안 위험을 탐구하지 않았습니다.
이 글의 저자는 이러한 격차를 메우고 순수하게 기술적 구조와 안전성의 관점에서 Hyperliquid를 검토하여 더 많은 사람들이 이 스타 프로젝트의 구조와 원리를 이해할 수 있도록 돕고자 합니다. 우리는 Hyperliquid 크로스 체인 브리지 계약의 구조와 숨겨진 위험, HyperEVM 및 HyperL1의 이중 체인 구조에 대해 자세히 설명하여 모든 사람이 그 뒤에 있는 기술 아키텍처와 구현을 이해할 수 있도록 돕습니다.
(하이퍼리퀴드는 현재 Arbitrum의 총 USDC 공급량의 67%를 차지합니다)
HyperLiquid 크로스체인 브리지 분석
HyperLiquid에는 오픈 소스 핵심 구성 요소가 없지만 오픈 소스 관련 브릿지 계약이 있으므로 브릿지 계약과 관련된 위험을 더 잘 이해할 수 있습니다. Hyperliquid는 사용자가 예치한 USDC 자산을 저장하기 위해 Arbitrum에 브리지 계약을 배포했습니다. Bridge 구성 요소에서 Hyperliquid 노드의 동작 중 일부를 볼 수 있습니다.
검증인 세트
노드 ID 분할의 관점에서 Hyperliquid에는 서로 다른 기능에 해당하는 hotValidatorSet, coldValidatorSet, finalizer 및 locker라는 네 가지 유효성 검사기 그룹이 있습니다. 그 중 hotValidatorSet은 사용자 출금 작업과 같이 빈도가 높은 행위에 응답하는 데 사용됩니다. Hot wallet은 일반적으로 Hyperliquid 사용자의 출금 요청에 언제든지 응답하는 데 사용됩니다.
coldValidatorSet는 주로 hotValidatorSet 또는 락커와 같은 검증기 세트 목록을 다시 작성하거나 브릿지 계약의 잠금 상태를 처리하는 등 시스템 구성을 수정하는 데 사용되며 coldValidatorSet은 특정 출금 요청을 직접 무효화할 권한이 있습니다.
로커는 레이어 2에서 사용하는 "보안 위원회"와 유사하게 특별한 권한을 가진 검증자 그룹입니다. 이들은 일부 긴급 상황에서 크로스 체인 브리지의 운영을 일시 중단할지 여부를 결정하기 위해 투표합니다. 현재 하이퍼리퀴드 브릿지의 라커 세트에는 5개의 주소가 포함되어 있으며 브릿지 계약의 운영을 중단하기 위해 투표하려면 2개의 라커만 필요합니다.
Finalizer의 경우 실제로는 크로스체인 브리지의 상태 변경을 확인하는 데 주로 사용되는 특수 검증자 그룹입니다. 계약 관점에서 주요 확인은 사용자 입출금입니다. Hyperliquid의 크로스체인 브리지는 "제출-확인" 메커니즘을 사용합니다. 예를 들어, 사용자가 출금을 시작한 후에는 즉시 실행되지 않으며 일정 기간(이 기간을 분쟁 기간이라고 함) 기다려야 합니다. 분쟁기간이 종료되고 확정자 회원이 출금거래를 실행한 이후에는 정상적으로 출금이 진행될 수 있습니다.
예를 들어, 크로스체인 브리지에 문제가 발생하면 특정 출금 명세서에 출금할 자산이 사용자가 실제로 소유한 자산 잔액보다 크다고 명시되어 있는 경우 Hyperliquid 노드는 락커를 사용하여 투표를 통해 운영을 중단할 수 있습니다. 분쟁 기간 동안 크로스체인 브리지 계약을 사용하거나 coldValidatorSet를 직접 사용하여 문제가 있는 출금 요청을 무효화합니다.
현재 Hyperliquid에는 4개의 유효성 검사기 노드만 있으므로 hotValidatorSet 및 coldValidatorSet는 4개의 온체인 주소에만 해당합니다. 초기화하는 동안 Hyperliquid는 hotValidatorSet의 주소를 locker 및 finalizer의 구성원으로 자동 등록하는 반면, coldValidatorSet는 Hyperliquid 자체에 의해 공식적으로 제어되며 콜드 지갑을 사용하여 키를 저장합니다.
보증금
Hyperliquid의 브릿지 계약은 EIP-2612의 Permit 방식을 기반으로 사용자 입금 작업을 처리하며 브릿지 계약에서는 사용자가 USDC를 자산으로 입금하는 것만 허용합니다. 기존 승인-전송 모드와 비교하여 Permit은 일괄 작업을 지원하는 것이 더 간단하고 쉽습니다.
Hyperliquid의 브릿지 컨트랙트는 여러 입금을 일괄 처리하기 위해 batedDepositWithPermit 기능을 사용합니다. 여기서 입금 작업은 비교적 간단하고 자금 보안에 대한 위험이 없으며 처리 프로세스는 Permit 방법만 사용하여 UX를 최적화합니다.
돈을 인출하다
예금에 비해 인출은 매우 위험한 작업이므로 인출 논리는 예금보다 훨씬 복잡합니다. 사용자가 출금 요청을 시작하면 Hyperliquid 노드는 브릿지 계약의 batedRequestWithdrawals 기능을 호출합니다. 이때 브릿지 계약에서는 각 출금 요청이 hotValidatorSet의 서명 가중치의 2/3를 수집해야 한다고 요구합니다. 여기서는 많은 문서에서 "서명의 2/3 수집"이라고 설명하지만 실제로 브릿지 계약에서는 " 2/3 시그니처 무게”. 현재 HyperLiquid에는 동일한 가중치를 갖는 노드가 4개만 있으므로 서명 가중치 확인과 서명 수 확인은 일시적으로 동일하지만 향후 HyperLiquid에서 가중치가 높은 노드를 도입할 수 있습니다.
출금 요청이 시작되면 크로스체인 브리지는 계약에 따라 제어되는 USDC를 즉시 전송하지 않지만 사기 방지 프로토콜의 "도전 기간"과 유사한 "분쟁 기간"이 있습니다. 현재 Hyperliquid 브릿지 계약의 분쟁 기간은 200초입니다. 분쟁 기간 동안 두 가지 상황이 발생할 수 있습니다.
1. 라커는 현재 출금 요청에 심각한 문제가 있다고 판단하여 계약을 정지/동결하기 위해 직접 투표할 수 있습니다.
2. 노드는 이때 일부 출금에 문제가 있다고 판단합니다. coldValidatorSet 멤버는 invalidateWithdrawals 함수를 호출하여 출금을 무효화할 수 있습니다.
분쟁 기간 동안 문제가 없으면 분쟁 기간이 종료된 후 종료자 구성원은 브릿지 계약의 batedFinalizeWithdrawals 함수를 호출하여 최종 상태를 완료할 수 있습니다. 이 함수가 실행된 후에야 USDC가 사용자의 지갑 주소로 전송됩니다. 중재에서.
따라서 보안 모델 관점에서 볼 때 악의적인 공격자가 하이퍼리퀴드의 출금 프로세스를 조작하려면 다음 세 가지 방어선을 돌파해야 합니다.
1. hotValidatorSet에 있는 서명 가중치의 2/3를 마스터하십시오. 즉, 특정 수의 개인 키를 획득하거나 공모해야 합니다. 현재 HyperLiquid에는 4개의 검증자만 있으며 공격자에 의해 제어되거나 공모될 가능성은 없습니다. 낮은;
2. 분쟁 기간 동안 공격자는 악의적인 거래가 발견되는 것을 방지해야 합니다. 일단 발견되면 라커는 계약을 잠글 가능성이 높습니다. 이 부분은 아래에서 구체적으로 다루겠습니다.
3. 귀하의 탈퇴 행위를 최종적으로 확인할 수 있도록 최소한 한 명의 종료자 구성원의 개인 키를 얻으십시오. 현재 finalizers 멤버와 hotValidatorSet 멤버는 기본적으로 동일하므로 공격자가 위의 조건 1을 충족하는 한 자동으로 조건 3이 충족됩니다.
브리지 계약 잠금
우리는 이전에 Hyperliquid가 크로스체인 브릿지 계약을 잠그는 기능을 설정했다고 여러 번 언급했습니다. 특히, 크로스체인 브릿지를 잠그려면 라커 멤버가 크로스체인 브릿지 계약에서 voteEmergencyLock 함수를 호출하여 투표해야 합니다. 현재 두 명의 라커가 투표를 위해 이 기능을 호출하면 크로스체인 브릿지 계약이 잠기고 일시 중단됩니다.
그러나 HyperLiquid의 크로스체인 브리지는 unvoteEmergencyLock 기능도 제공하여 라커 회원이 투표를 철회할 수 있도록 한다는 점에 유의해야 합니다. 크로스체인 브리지 계약이 성공적으로 잠기면, coldValidatorSet 멤버 서명 가중치의 2/3 이상을 수집해야 하는 EmergencyUnlock이라는 기능을 통해서만 잠금을 해제할 수 있습니다.
EmergencyUnlock 기능은 또한 잠금을 해제하는 동안 새로운 hotValidatorSet 및 coldValidatorSet 유효성 검사기 주소 세트를 입력하고 즉시 업데이트됩니다.
검증인 세트 업데이트
철회 과정에서 기존 방어선을 돌파하려는 시도보다는 updateValidatorSet 함수를 직접 사용하여 hotValidatorSet 및 coldValidatorSet 유효성 검사기 세트를 업데이트하는 것이 더 나은 공격 방법입니다. 이를 위해서는 호출자가 모든 hotValidatorSet 멤버에 서명해야 하며 작업에는 200초의 분쟁 기간이 있습니다.
분쟁 기간이 끝나면 종료자 구성원은 finalizeValidatorSetUpdate 함수를 호출하여 최종 상태 업데이트를 완료해야 합니다.
지금까지 하이퍼리퀴드 크로스체인 브릿지에 대한 자세한 내용을 대부분 소개했습니다. 이 문서에서는 락커와 종료자의 업데이트 논리를 소개하지 않습니다. 둘 다 업데이트하려면 hotValidatorSet 서명이 필요하고 특정 멤버를 제거하려면 coldValidatorSet 서명이 필요합니다.
요약하자면, 하이퍼리퀴드의 브릿지 계약에는 다음과 같은 위험이 포함되어 있습니다.
1. 해커가 coldValidatorSet를 제어한 후 모든 방해 요소를 무시하고 사용자 자산을 훔칠 수 있습니다. coldValidatorSet에는 EmergencyUnlock 함수의 작동 권한이 있으므로 브릿지 컨트랙트에 대한 락커의 잠금 동작을 무효화하고 노드 목록을 실시간으로 업데이트할 수 있습니다. 현재 하이퍼리퀴드에는 검증인 노드가 4개뿐이고, 개인키가 도난당할 가능성도 낮지 않습니다.
2. 최종결정자는 사용자의 출금 거래 확정을 거부하고 검열 공격을 시작합니다. 이 경우 사용자의 자산은 도난당하지 않지만 사용자는 브릿지 계약에서 돈을 인출할 수 없습니다.
3. 로커는 악의적으로 크로스체인 브리지를 표적으로 삼습니다. 이때 모든 출금 거래는 실행될 수 없으며 coldValidatorSet가 잠금 해제될 때까지만 기다릴 수 있습니다.
HyperEVM 및 이중 체인 상호 작용 아키텍처
개인 거래 및 스마트 계약이 필요한 기타 시나리오를 도입하는 등 주문장 거래를 프로그래밍 가능하게 만들기 위해 Hyperliquid는 HyperEVM이라는 솔루션을 출시했습니다. 기존 EVM에 비해 두 가지 특별한 장점이 있습니다. 첫째, HyperEVM은 HyperLiquid의 주문서 상태를 읽을 수 있고, 둘째, HyperEVM의 스마트 계약은 Hyperliquid 주문서 시스템과 상호 작용할 수 있어 Hyperliquid의 애플리케이션 시나리오를 크게 확장합니다.
간단한 예를 들자면, 사용자가 보류 중인 주문 작업의 개인 정보 보호를 보장해야 하는 경우 Tornado Cash와 유사한 스마트 계약을 통해 HyperEVM에서 개인 정보 보호 계층을 구현한 다음 다음을 통해 HyperLiquid의 주문 장부 시스템에서 보류 중인 주문 작업을 트리거할 수 있습니다. 특정 인터페이스.
HyperEVM을 소개하기 전에 HyperEVM을 위해 Hyperliquid가 준비한 특별한 아키텍처를 소개해야 합니다. 하이퍼리퀴드는 맞춤형 초고성능 오더북 시스템을 갖추고 있기 때문에 EVM 환경에서의 거래 처리 속도는 훨씬 느립니다. 주문서 시스템이 느려지는 것을 방지하기 위해 Hyperliquid는 "이중 체인 솔루션"을 사용합니다. 이는 본질적으로 Hyperliquid 노드 장치가 소프트웨어 수준에서 두 개의 블록체인을 동시에 실행할 수 있도록 하며 각 노드는 두 체인의 데이터를 로컬에 저장합니다. . 두 체인의 거래는 별도로 처리됩니다.
하이퍼리퀴드는 맞춤형 오더북 시스템을 위해 특별히 체인을 구축했으며, EVM 호환 체인(HyperEVM)도 추가했습니다. 이 두 체인의 데이터는 동일한 합의 프로토콜을 통해 노드 그룹 간에 분산되어 통일된 상태로 존재하지만 서로 다른 실행 환경에서 별도로 실행됩니다. 우리는 허가된 주문서 전용 체인인 Hyperliquid L1(L1)을 호출하고 HyperEVM에 사용되는 체인은 허가가 없으며 누구나 계약을 배포할 수 있는 HyperEVM입니다.
Hyperliquid L1의 블록 생성 속도는 HyperEVM 체인의 블록 생성 속도보다 빠르지만 이러한 블록은 여전히 순서대로 실행됩니다. EVM 체인의 계약은 과거 L1 블록의 데이터를 읽고 미래 L1 블록에 데이터를 쓸 수 있습니다. 아래와 같이:
HyperL1과 HyperEVM 간의 상호 작용을 달성하기 위해 Hyperliquid는 사전 컴파일과 이벤트라는 두 가지 기술적 수단을 사용합니다.
사전 컴파일
소위 프리컴파일(Precompiles)은 직설적으로 말하면 스마트 계약에서 구현하기 어렵고 복잡도가 높은 일부 작업을 직접 기본 레이어로 옮기고, Solidity에 비우호적이며 더 많은 계산 프로세스를 옮기는 것입니다. 외부 처리의 경우 이러한 유형의 사전 컴파일된 코드는 Solidity보다 기본 장치에 더 가까운 C, C++ 및 기타 언어로 구현될 수 있습니다.
사전 컴파일된 방법을 통해 EVM은 스마트 계약 개발자의 요구 사항을 쉽게 지원할 수 있는 더욱 발전되고 복잡한 기능을 지원할 수 있습니다. 형식상 사전 컴파일은 본질적으로 특수 스마트 계약 세트입니다. 다른 스마트 계약은 이러한 특수 계약을 직접 호출하고 매개변수를 전달하고 사전 컴파일된 실행의 반환 결과를 얻을 수 있습니다. 현재 ecRecover 명령어는 사전 컴파일을 통해 네이티브 EVM에 구현되어 있으며 EVM 내부에서 secp256k1 서명이 올바른지 확인할 수 있으며 해당 명령어는 0x01 주소에 있습니다.
현재 사전 컴파일을 사용하여 일부 특수 기능을 추가하는 것이 주류입니다. 예를 들어 Base는 사용자가 WebAuth ID 인증 작업을 수행할 수 있도록 P256 사전 컴파일된 코드를 추가했습니다.
(이 사진은 Rollup Codes 웹사이트에서 가져온 것입니다.)
현재 주류 솔루션에 맞춰 HyperEVM은 EVM이 Hyperliquid 주문서 시스템의 상태를 읽을 수 있도록 일련의 사전 컴파일된 코드를 추가했습니다. 현재 알려진 하이퍼리퀴드 사전 컴파일된 코드 주소는 0x000000000000000000000000000000000000800입니다. 이 사전 컴파일된 주소는 최신 L1 블록에서 사용자의 무기한 계약 위치를 읽을 수 있습니다.
이벤트
위에서 HyperEVM이 HyperL1 블록에 데이터를 쓸 수 있으며 쓰기 동작은 이벤트에 따라 다르다고 언급했습니다. 이벤트는 EVM의 기본 개념으로, 스마트 계약이 실행 중에 로그 정보를 외부(예: 프런트엔드 애플리케이션 또는 리스너)로 전송하여 외부 세계에서 스마트 계약의 실행 상태를 모니터링할 수 있도록 합니다.
예를 들어 사용자가 ERC-20 계약의 토큰 전송 기능을 사용하면 계약은 전송에 해당하는 이벤트를 발생시켜 블록 브라우저와 같은 프런트엔드 애플리케이션이 토큰 전송 상황을 학습할 수 있습니다. 이러한 이벤트 정보는 블록에 포함되며 이벤트 로그를 모니터링하고 검색하기 위한 성숙한 솔루션이 많이 있습니다.
요즘에는 많은 크로스체인 관련 시나리오에서 이벤트를 사용하여 크로스체인 매개변수를 전달합니다. 예를 들어 Arbitrum은 Ethereum 메인 네트워크의 브리지 계약에 배포됩니다. 사용자는 관련 함수를 호출하여 Arbitrum에서 트랜잭션을 트리거할 수 있습니다.
알려진 정보에 따르면 HyperLiquid 노드가 수신할 것임을 나타냅니다.
0x33333333333333333333333333333333333 (event address) Events에 포함된 정보를 기반으로 사용자의 의도를 파악하고, 이에 따른 거래 행위로 변환하여 향후 Hyperliquid L1 블록에 씁니다.
예를 들어, 위의 이벤트 주소는 사용자가 이 함수를 호출하면 이벤트 주소가 IocOrder라는 이벤트를 발생시킵니다. Hyper L1 블록이 생성되면 HyperLiquid 노드는 먼저 HyperEVM의 최근 이벤트 주소에서 발생한 이벤트를 쿼리합니다. 새 IocOrder 이벤트가 검색되면 Hyper L1에서 보류 중인 주문 작업으로 변환됩니다.
하이퍼BFT
합의 프로토콜 수준에서 Hyperliquid는 HotStuff 기반의 파생 방식인 HyperBFT라는 프로토콜을 채택합니다. 현재 HutStuff-2는 복잡성이 가장 낮은 최신 합의 프로토콜 중 하나입니다.
데이터에 따르면 HyperLiquid는 처음에는 Cosmos 시스템에서 사용되는 기본 합의 알고리즘인 Tendermint 합의 알고리즘을 사용했지만 이 알고리즘은 각 단계에서 All-to-All 메시지 교환이 필요하며 각 노드가 보고해야 합니다. 다른 모든 노드는 메시지를 보내고 통신 복잡도는 O(n²)입니다. 여기서 n은 노드 수입니다.
Tendermint를 사용하면 Hyperliquid는 초당 최대 20,000개의 주문을 처리할 수 있습니다. 중앙 집중식 교환 속도를 달성하기 위해 HyperLiquid 팀은 HotStuff를 기반으로 HyperBFT 알고리즘을 개발하고 이를 Rust로 구현했으며 이론적으로 초당 최대 200만 건의 주문을 처리할 수 있습니다.
아래 그림은 비병렬 상황에서 HyperBFT 합의의 메시지 전달 방법을 보여줍니다. 모든 메시지가 리더에 의해 균일하게 요약되어 브로드캐스팅되는 것을 볼 수 있으며, 이는 노드 간 메시지 교환 단계를 없애고 복잡성을 크게 줄입니다.
간단히 말하면, HyperBFT는 현재 리더가 블록을 생성하고, 모든 노드가 투표에 참여하고, 투표 결과가 리더에게 균일하게 전송되고, 다음 리더가 순환되는 합의 프로토콜입니다. 실제로 Hotstuff 및 Tendermint와 관련된 구체적인 세부 사항은 훨씬 더 복잡합니다. 이 기사는 길이와 초점에 따라 제한되므로 여기서는 자세히 다루지 않습니다.
개발자를 위한 참고 사항
위에서 언급한 프리컴파일 기반 데이터 읽기 메커니즘은 비교적 완벽합니다. Solidity 개발자는 Hyper L1 상태를 읽을 때 해당 코드를 작성할 필요가 없지만 msg.sender 문제에 주의해야 합니다. 대부분의 Ethereum 두 번째 레이어와 유사하게 HyperLiquid는 사용자가 Hyper L1의 시스템 계약과 직접 상호 작용하고 HyperEVM 체인에서 간접적으로 트랜잭션 작업을 트리거할 수 있도록 합니다. 이때 스마트 계약이 트랜잭션의 msg.sender 필드를 읽으면 해당 작업이 수행됩니다. msg.sender는 HyperL1에서 처음에 트랜잭션을 시작한 사용자의 주소가 아닌 HyperL1 시스템 계약의 주소에 해당하는 것으로 나타났습니다.
EVM과 L1 간의 상호 작용과 관련하여 개발자는 일련의 문제에 주의를 기울여야 합니다. 첫 번째 문제는 상호 작용의 비원자성입니다. 사용자가 HyperEVM에서 앞서 언급한 이벤트 주소를 통해 L1에 간접적으로 주문을 했지만 L1에 자산이 충분하지 않으면 거래는 확실히 실패하지만 사용자는 이벤트 주소를 사용하면 오류 반환 프롬프트가 표시되지 않습니다. 상호 작용의 비원자성 문제로 인해 사용자 자산이 손상될 수 있습니다. 이때 개발자는 EVM 스마트 계약 측에서 보류 중인 주문의 실패를 수동으로 처리해야 합니다. 또한 EVM의 스마트 계약에는 L1에서 사용자 자산이 절대 인출되지 않도록 최종 자금 회수 기능이 있어야 합니다.
둘째, EVM에 해당하는 계약 주소는 L1에 매핑 계정이 있어야 합니다. 사용자가 EVM에 스마트 계약을 배포할 때 L1의 매핑 주소로 소량의 USDC를 전송해야 하며 L1은 해당 계정을 생성해야 합니다. 계약 주소. 작업의 이 부분은 HyperLiquid의 문서에서 분명히 요구되는 HyperLiquid의 기본 합의와 관련될 수 있습니다.
마지막으로 개발자는 몇 가지 특별한 상황, 특히 토큰 잔액에 주의를 기울여야 합니다. Hyper L1에는 자산 전송을 위한 특수 주소가 있지만 사용자가 이 특수 주소로 자산을 보내면 자산이 L1에서 HyperEVM 체인으로 전송됩니다. HyperLiquid 노드는 실제로 EVM 체인과 L1 체인을 동시에 실행하기 때문에 사용자가 자산을 전송한 후 오랫동안 HyperEVM이 블록을 생성하지 않았을 수 있습니다. EVM 체인의 균형.
간단히 말해서, 현재 사용자의 자산은 크로스 체인 브리지에 갇혀 있으며 L1 또는 EVM 체인에서 쿼리할 수 없습니다. 개발자가 구축한 프로토콜은 사용자 간의 패닉을 피하기 위해 위의 특수 상황을 처리해야 합니다.
요약하면 HyperEVM은 Hyperliquid L1을 기반으로 하는 두 번째 계층과 유사합니다. HyperEVM은 미리 컴파일된 코드를 사용하여 L1 상태를 읽고 이벤트를 사용하여 Hyper L1과 상호 작용합니다. L1에는 사용자가 HyperEVM 내에서 트랜잭션을 트리거하거나 크로스체인 자산을 수행하는 데 도움이 되는 일부 시스템 계약도 있습니다. 그러나 일반적인 Layer1-Layer2 아키텍처와 달리 Hyperliquid는 HyperEVM에 더 높은 상호 운용성을 제공합니다.
참고자료
Hyperliquid: 초최적화된 주문서 L1
하이퍼리퀴드덱스/계약
Hyperliquid 사전 컴파일에 대한 아직 확정되지 않은 가이드입니다.
PBFT, Tendermint, HotStuff 및 HotStuff-2의 차이점은 무엇입니까?
