MonadBFT: 블록체인 합의 보안을 재정의하다, 테일 분기 위험에서 벗어나다
저자: michaellwy
블록체인의 핵심은 엄격한 글로벌 합의(strict global consensus)를 구현하는 데 있다. 즉, 네트워크 노드가 어느 국가나 시간대에 분포하든 모든 참여자가 결국 동일한 객관적 결과에 일치해야 한다는 것이다.
그러나 현실의 분산 네트워크는 완벽하지 않다. 일부 노드는 오프라인이 되거나 거짓말을 하며, 심지어 일부러 교란을 일으키는 경우도 있다. 이러한 상황에서 시스템은 어떻게 여전히 “모두 같은 말”을 하고 일관성을 유지할 수 있을까?
이것이 바로 합의 프로토콜(consensus protocol)이 해결해야 할 문제이다. 본질적으로 이는 서로 독립적이며 완전히 신뢰되지 않는 노드들이 각 트랜잭션의 순서와 내용에 대해 통일된 결정을 내릴 수 있도록 지침을 제공하는 일련의 규칙이다.
이러한 “엄격한 합의”가 확립되면, 디지털 소유권 보호, 인플레이션 저항형 통화 모델, 확장 가능한 사회 협업 구조 등 많은 핵심 기능을 활용할 수 있게 된다. 그러나 전제 조건은 합의 프로토콜 자체가 다음 두 가지 기본 요소를 동시에 보장해야 한다는 점이다:
-
서로 충돌하는 두 개의 블록이 모두 확인되는 일이 없어야 한다.
-
네트워크는 정체되거나 멈추지 않고 계속 진행되어야 한다.
MonadBFT는 바로 이러한 방향에서 이루어진 최신 기술적 돌파구이다.
합의 프로토콜의 간략한 발전 과정
합의 메커니즘은 사실 수십 년간 연구되어 온 분야이다. 초기 프로토콜들 중 하나인 PBFT(Practical Byzantine Fault Tolerance)는 이미 매우 현실적인 상황을 처리할 수 있었다. 즉, 네트워크 내 일부 노드가 실패하거나 악의를 품고 잘못된 정보를 전달하더라도, 그 수가 전체의 1/3을 넘지 않으면 시스템은 여전히 합의에 도달할 수 있다.
이러한 초기 프로토콜의 설계 방식은 다소 “전통적”이었다. 각 라운드마다 하나의 리더(leader)를 선출하고, 리더가 제안을 제기하면 나머지 검증자들이 다수 차례에 걸쳐 투표하며, 점차적으로 거래 순서를 확정한다.
투표 과정은 일반적으로 pre-prepare, prepare, commit, reply 등의 여러 단계를 거친다. 각 단계에서 모든 검증자들은 서로 통신해야 한다. 즉, 모든 사람이 다른 모든 사람에게 메시지를 보내야 하므로, 메시지 수량은 “메시지 망” 형태로 폭발적으로 증가하게 된다.
이러한 통신 구조의 복잡도는 n²이다. 예를 들어, 검증자가 100명인 네트워크에서는 한 번의 합의 과정에서 거의 1만 건의 메시지가 전달될 수 있다.
이 정도면 소규모 네트워크에서는 큰 문제가 되지 않지만, 검증자 수가 많아지면 시스템의 통신 부담이 급격히 감당 불가능해지고, 효율성이 크게 저하된다.
자료 출처:
https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
이처럼 “모든 사람이 모든 사람과 통신”하는 2차원적 통신 구조는 매우 비효율적이다. 예를 들어, 검증자 100명으로 구성된 네트워크에서는 각 합의 라운드마다 수만 건의 메시지를 처리해야 한다.
이 정도면 소규모 그룹 내에서는 감내할 수 있지만, 전 세계적으로 개방된 체인 네트워크에서는 통신 부하가 곧바로 수용 불가능해진다. 그래서 PBFT나 Tendermint와 같은 초기 BFT 프로토콜은 일반적으로 허가형 네트워크(permissioned network) 또는 검증자 수가 극히 적은 시스템에서만 겨우 작동 가능하다.
BFT 프로토콜이 무허가형, 공개형 블록체인 환경에서도 사용 가능하도록 하기 위해, 새로운 세대의 설계들은 더 가벼운 통신 방식을 추구하기 시작했다. 즉, 검증자들이 모두 서로 통신하는 대신 리더와만 통신하는 방식이다.
이를 통해 메시지 복잡도를 기존의 n²에서 n으로 줄여, 시스템 부담을 크게 완화할 수 있다.
HotStuff 프로토콜은 2018년 이러한 확장성 문제를 해결하기 위해 제안되었다. 그 설계 철학은 명확했다. PBFT의 복잡한 투표 절차를 대체하여, 더 간결하고 리더 중심의 통신 구조를 채택하는 것이다.
HotStuff의 핵심 특징은所谓的 선형 통신(linear communication)이다. 이 메커니즘에서 각 검증자는 자신의 투표를 현재 리더에게만 전송하고, 리더는 이를 취합해 Quorum Certificate(QC, 정족수 증명서)를 생성한다.
이 QC는 본질적으로 집단 서명이며, “대다수 노드가 이 제안에 동의했다”는 것을 네트워크 전체에 증명한다.
반면, PBFT는 “모두에게 방송”하는 방식으로, 마치 그룹 채팅에서 모두 동시에 말하는 것처럼 혼란스러울 수 있다. HotStuff는 “한 사람이 수집하고, 한 번에 패키징”하는 방식으로, 네트워크의 크기에 관계없이 효율적으로 작동할 수 있다.
위 이미지는 HotStuff의 스포크형 통신 구조와 PBFT의 전면 연결 모드를 비교함
자료 출처:
https://www.mdpi.com/1424-8220/24/16/5417
선형 통신 외에도, HotStuff는 파이프라이닝 버전(pipelined HotStuff)으로 업그레이드되어 효율성을 더욱 높일 수 있다.
기본 HotStuff에서는 동일한 검증자가 여러 라운드 동안 연속해서 리더를 맡으며, 블록이 완전히 확정될 때까지 진행한다. 이 과정은 “한 번에 하나의 블록 처리”이며, 모든 자원이 현재 블록에 집중된다.
반면 파이프라이닝 HotStuff에서는 메커니즘이 더욱 유연하다. 각 라운드마다 새로운 리더를 선출하며, 각 리더의 임무는 두 가지이다:
-
이전 라운드의 투표를 정족수 증명서(QC)로 취합하여 전체 네트워크에 방송한다.
-
새로운 블록을 제안하여 다음 라운드를 준비한다.
즉, “하나를 완료한 후 다음을 처리하는” 방식이 아니라, 생산 라인처럼 서로 다른 리더가 각 단계를 번갈아 담당하는 것이다. 앞의 리더가 블록을 제안하면, 다음 리더가 이를 확인하고 동시에 새 블록을 제안하며, 합의 과정이 마치 계주처럼 이어진다.
이것이 “파이프라인”이라는 비유의 의미이다. 현재 블록이 아직 확정 절차를 밟고 있는 사이, 다음 블록이 이미 준비되고 있다. 여러 단계를 병렬로 수행하여 처리 효율을 높이는 것이다.
요약하자면, HotStuff와 같은 프로토콜은 전통적인 BFT에 비해 두 가지 측면에서 중대한 개선을 이루었다:
-
통신 부하가 가벼워짐: 각 검증자는 리더와만 통신하면 됨.
-
처리 효율이 향상됨: 여러 블록의 확정 절차를 병렬로 수행 가능.
이로 인해 HotStuff는 현대 PoS 블록체인 합의 메커니즘 설계의 주요 템플릿이 되었다. 그러나 모든 것에는 장점과 단점이 따르는데, 파이프라인 구조는 성능은 뛰어나지만, 드러나지 않은 구조적 위험을 조용히 도입하고 있다.
다음으로 우리는 이 핵심 문제인 꼬리 포크(Tail Forking)에 대해 깊이 살펴볼 것이다.
꼬리 포크 문제 (Tail-Forking)
HotStuff — 특히 파이프라인 버전 — 은 합의 프로토콜의 확장성 문제를 해결했지만, 동시에 몇 가지 새로운 도전 과제를 야기했다. 그 중 가장 중요하면서도 쉽게 간과되기 쉬운 것이所谓 '꼬리 포크'(Tail Forking) 문제이다.
꼬리 포크란 무엇인가? 간단히 말해, 블록체인의 “꼬리 부분”에서 예기치 않게 블록 재구성(reorg)이 발생하는 것이다.
구체적으로, 어떤 블록이 유효하며, 대부분의 검증자에게 성공적으로 전파되었고, 또한 충분한 투표를 획득하여 원칙적으로 곧 확인되어 메인체인에 기록될 예정이었으나, 마지막 순간에 “넘어뛰어졌고”, 폐기(orphaned)되었으며, 같은 높이(height)에서 다른 새로운 블록으로 대체된 상황을 말한다.
이것은 버그도 아니고 공격도 아니다. 프로토콜 자체의 설계 구조 내에 이러한 “꼬리를 놓치는” 가능성< strong>이 존재하기 때문이다. 공평하지 않아 보이지 않는가? 그렇다면 이것이 어떻게 발생하는가?
앞서 언급했듯, 파이프라인 HotStuff의 각 리더는 두 가지 임무를 갖는다:
-
A. 새로운 블록 제안 (예: Bₙ₊₁)
-
B. 이전 리더의 블록에 대한 투표를 수집하고 QC 생성 (예: Bₙ의 최종 확정 완료)
이 두 작업은 병렬로 이루어지며, 서로 이어받는다. 하지만 문제는 바로 여기에 있다.
예를 들어보자. 앨리스(Alice)가 n번째 높이에서 블록 Bₙ을 제안하였고, 이 블록은 초과 다수(super majority)의 투표를 얻어 “거의 확정 직전” 상태가 되었다고 하자.
다음 리더인 밥(Bob)은 다음 블록 Bₙ₊₁을 추진할 책임이 있으며, 동시에 Bₙ의 QC(정족수 증명서)를 자신의 제안에 포함하여 Bₙ의 최종 확정을 완료해야 한다.
그러나 만약 이때 밥이오프라인 상태이거나, 의도적으로 Bₙ의 QC를 제출하지 않는다면 문제가 생긴다.
앨리스의 블록에 대한 QC 패키징을 해줄 사람이 없기 때문에, Bₙ에 대한 투표 기록이 전파되지 못하고, 이 본래 확정되어야 할 블록은 “냉대” 당하게 되며, 결국 전체 네트워크에 의해 무시된다.
이것이 꼬리 포크의 본질이다: 이전 리더의 블록이 다음 리더의 부주의 혹은 악의적인 행동으로 인해 넘어가는 것.
왜 꼬리 포크가 심각한가?
꼬리 포크 문제는 주로 두 가지 측면에서 심각하다: 1) 인센티브 메커니즘이 파괴됨, 2) 시스템의 활성(liveness)이 위협받음.
첫째, 보상 손실:
블록이 폐기되면, 이를 제안한 리더는 어떠한 보상도 받지 못한다. 블록 생성 보상이든 트랜잭션 수수료든 상관없다. 예를 들어 앨리스가 유효한 블록을 제안하고 초과 다수의 투표를 받았음에도 불구하고, 밥의 실수나 악의적인 조작으로 인해 해당 블록이 확정되지 않아, 결국 앨리스는 일분의 보상을 받지 못한다. 이는 잘못된 인센티브 구조를 초래한다. 밥과 같은 악의적인 노드는 경쟁자의 블록을 건너뛰는 방식으로 그들의 보상 원천을 “절단”할 수 있다. 이 행위는 기술적 공격이 필요 없으며, 단지 의도적으로 “협력하지 않기&rdquo>만으로도 경쟁자의 수익을 약화시킬 수 있다. 이러한 일이 반복되면, 결국 전체 시스템의 참여도와 공정성이 저하되며, 노드 간의 공모(collusion)로 이어질 수도 있다.
둘째, MEV 공격 공간 확대:
꼬리 포크는 더 은폐되어 있지만 심각한 문제를 야기한다. MEV(최대 추출 가능 가치)의 악용 가능성이 커진다는 것이다. 예를 들어, 앨리스의 블록에 매우 고수익인 아비트리지 거래가 있다고 하자. 밥이 일을 벌이고 싶다면, 다음 리더 캐롤(Carol)과 공모하여 앨리스의 블록을 고의로 전파하지 않을 수 있다. 그리고 캐롤은 동일한 높이에서 새 블록을 다시 구성하여, 앨리스의 아비트리지 거래를 “복사”하여 MEV 수익을 자신이 가져간다. 이러한 “체인 머리 재정렬 + 공모 횡령”은 겉보기엔 정상적인 블록 생성처럼 보이지만, 실제로는 치밀하게 설계된 약탈이다. 더 심각한 것은, 이로 인해 리더들 사이에 “공모 관계”가 형성되며, 블록 확정이 공공 서비스가 아닌 이익 분배 게임이 될 수 있다는 점이다.
셋째, 확정성 보장 파괴 및 사용자 경험 저하:
Nakamoto 계열 프로토콜과 비교할 때, BFT의 주요 장점 중 하나는 결정론적 확정성(deterministic finality)이다. 즉, 블록이 제출되면 이후 되돌릴 수 없다. 그러나 꼬리 포크는 이 보장을 무너뜨린다. 특히 “투표는 받았지만 아직 공식적으로 확정되지 않은” 블록에 영향을 준다. 고처리량 dapp은 종종 블록 투표 후 즉시 데이터를 읽어 지연을 줄이기를 원하지만, 만약 해당 블록이 갑자기 폐기되면 사용자 상태가 롤백될 수 있다. 예를 들어 계좌 잔액 이상, 완료된 고레버리지 거래가 사라짐, 게임 상태가 갑자기 리셋되는 등의 문제가 발생할 수 있다.
넷째, 연쇄적 장애 유발 가능성:
일반적으로 꼬리 포크는 특정 블록의 확정이 한 라운드 늦춰지는 정도의 영향만 미치므로 그리 심각하지 않을 수 있다. 그러나 일부 극단적 상황에서, 연속된 여러 리더가 이전 블록을 건너뛰기로 선택하면, 시스템은 정체 상태에 빠질 수 있다. 누구도 “이전 블록을 받아들이려” 하지 않는 것이다. 전체 체인의 진행이 막혀, 마침내 “책임을 떠안겠다”는 리더가 나타날 때까지 진행되지 않는다.
이전에도 BeeGees 프로토콜과 같은 일부 해결책이 있었지만, 종종 성능을 희생해야 했다. 예를 들어 2차원 통신 복잡도를 다시 도입하거나 매 라운드마다 추가 통신 프로세스를 실행하는 방식은 실용적으로 부담이 크다.
무엇이 MonadBFT인가?
MonadBFT는 꼬리 포크 문제를 해결하기 위해 설계된 차세대 합의 프로토콜이다. 그 강점은 구조적 결함을 해결하면서도 파이프라인 HotStuff가 제공하는 성능 이점을 희생하지 않았다는 점이다. 즉, MonadBFT는 기존 구조를 완전히 폐기하는 것이 아니라, HotStuff의 핵심 프레임워크를 기반으로 한 추가 최적화이다. 다음 세 가지 핵심 특성을 유지한다:
1) 리더 순환(rotating leader): 각 라운드마다 새로운 리더를 선출하여 체인을 추진함;
2) 파이프라인 커밋(pipelined commits): 여러 블록의 확정 과정을 중첩하여 수행 가능;
3) 선형 통신(linear messaging): 각 검증자는 리더와만 통신하면 되어 네트워크 오버헤드를 크게 줄임.
하지만 이 세 가지만으로는 충분히 안전하지 않다. 꼬리 포크라는 구조적 취약점을 막기 위해, MonadBFT는 다음 두 가지 핵심 메커니즘을 추가하였다:
1) 강제 재제안 메커니즘 (Re-Proposal)
2) 비승인 증명서 (NEC, No-Endorsement Certificate)
재제안 메커니즘 (Re-Proposal)
BFT 프로토콜에서 시간은 여러 라운드(view)로 나뉘며, 각 라운드마다 리더가 새로운 블록을 제안한다. 리더가 실패하면(예: 제시간에 블록을 제안하지 않거나, 무효한 제안), 시스템은 다음 라운드로 전환하고 새로운 리더를 선출한다.
MonadBFT는 추가 메커니즘을 도입하여, 뷰 전환 과정에서 정직하게 제안된 블록이 리더 순환으로 인해 “사라지지 않도록” 보장한다.
현재 뷰의 리더가 실패하면, 검증자들은 서명된 뷰 전환 메시지(view change)를 발행하여 현재 뷰가 타임아웃되었음을 알린다.
특히 이 메시지는 단순히 “타임아웃”을 알리는 것뿐만 아니라, 해당 검증자가 가장 최근에 투표한 블록 정보를 포함해야 한다. 마치 “합법적인 제안을 받지 못했으며, 제가 현재 보고 있는 최신 블록은 이것입니다”라고 말하는 것과 같다.
새로운 뷰의 리더는 초과 다수(2f+1)의 검증자로부터 이러한 타임아웃 메시지를 수집하고, 이를 결합하여 타임아웃 증명서(Timeout Certificate, TC)를 생성한다. 이 TC는 이전 뷰가 실패했을 때, 네트워크 전체가 “체인 머리 블록”에 대해 가지고 있던 공통 인식 스냅샷을 의미한다. 새로운 리더는 이 TC 내에서 가장 높은 높이(또는 최신 뷰 번호)의 블록, 즉所谓 high_tip을 선택한다.
MonadBFT는 요구한다: 새로운 리더의 제안은 유효한 TC를 반드시 포함해야 하며, TC 내의 가장 높은 미확정 블록을 반드시 재제안해야 한다. 이를 통해 해당 블록이 다시 확정 기회를 얻게 된다.
왜 그런가? 앞서 설명했듯이, 거의 확정 직전이었던 블록이 사라지는 것을 원하지 않기 때문이다.
예를 들어보자. 앨리스가 view 5의 리더로서 유효한 블록을 제안하고 다수의 투표를 받았다. 다음 리더인 밥(view 6)이 오프라인이 되어 체인 진행을 추진하지 못했다. 캐롤이 view 7의 리더가 되었을 때, MonadBFT의 규칙에 따라 그녀는 TC를 포함하고 앨리스의 블록을 재제안해야 한다. 이렇게 하면 앨리스의 정직한 작업이 헛되지 않는다.
캐롤이 앨리스의 블록을 가지고 있지 않다면, 다른 노드에게 요청할 수 있다. 노드들은 다음과 같이 응답할 수 있다:
-
해당 블록을 제공하거나,
-
서명된 “비승인 메시지(No-Endorsement, NE)”를 반환하여 자신이 해당 블록을 받지 못했음을 표시한다(자세한 메커니즘은 아래 참조). (최대 f개의 비잔틴 노드는 요청을 무시하고 응답하지 않을 수 있음.)
캐롤이 앨리스의 블록을 재제안하면, 그녀는 추가적인 제안 기회를 얻게 되며, 이전 리더의 실패로 인해 “연좌제”를 당하지 않게 된다.
이 재제안 메커니즘의 목적은 명확하다. 체인 추진이 공정하게 이루어지며, 어떠한 유효한 작업도 운이 나쁘거나 누군가 방해한다고 해서 조용히 폐기되지 않도록 보장하는 것이다.
비승인 증명서 (NEC)
이전 예시를 계속 살펴보자. 밥의 뷰가 타임아웃된 후, 캐롤은 다른 검증자들에게 high_tip 블록(즉 앨리스의 블록)을 제공해 달라고 요청한다. 이때 최소 2f+1명의 검증자가 응답한다:
-
앨리스의 블록을 제공하거나,
-
서명된 NE 메시지를 보내 자신이 앨리스의 블록을 받지 못했다고 알린다.
캐롤이 앨리스의 블록을 받으면, 규칙에 따라 반드시 이를 재제안해야 한다. 단, 최소한 f+1명의 검증자가 NE 메시지에 서명한 경우에만, 캐롤은 해당 블록을 건너뛰고 새로운 블록을 제안할 수 있다.
왜 f+1인가? 3f+1명의 검증자로 구성된 BFT 시스템에서, 최대 f명만이 악의적일 수 있다. 앨리스의 블록이 실제로 초과 다수의 투표를 받았다면, 적어도 2f+1명의 정직한 노드가 그것을 수신했어야 한다.
따라서 캐롤이 “저는 앨리스의 블록을 받을 수 없습니다”라고 주장한다면, 그녀는 f+1명의 검증자가 서명한 NE 메시지를 제출해야 한다. 이를 통해 비승인 증명서(No-Endorsement Certificate, NEC)가 구성된다.
NEC는 리더가 “면책”되는 증거이다. 이는 이전 블록이 아직 확정 준비가 되지 않았음을 입증하는 검증 가능한 증거이며, 악의적으로 건너뛴 것이 아니라 정당한 이유로 “포기”한 것이다.
재제안 + 비승인 증명서 = 꼬리 포크 해결
MonadBFT는 재제안 메커니즘(Re-Proposal)과 비승인 증명서(NEC, No-Endorsement Certificate)를 도입하여, 체인 머리 처리에 대한 엄격하고 명확한 규칙을 수립한다:
또는 “거의 확정 직전”인 블록을 최종 제출하거나,
또는 해당 블록이 아직 확정 조건을 갖추지 못했다는 충분한 증거를 제공하거나,
그렇지 않으면, 이전 블록을 건너뛰거나 대체할 수 없다.
이 메커니즘은 법정 다수의 투표를 이미 획득한 블록이 리더의 실수나 고의 회피로 인해 폐기되지 않도록 보장한다.
꼬리 포크의 구조적 위험이 체계적으로 해소되며, 프로토콜은 부적절한 건너뛰기 행동에 대해 명확한 제약을 형성할 수 있다.
어떤 리더가正当한 이유 없이 이전 블록을 건너뛰려 시도하지만 NEC로 입증하지 못하면, 프로토콜은 즉시 이를 식별하고 거부한다. 암호학적 증거가 없는 점프는 불법으로 간주되며, 네트워크 합의의 지지를 받지 못한다.
경제적 인센티브 측면에서 보면, 이 설계는 검증자들에게 명확한 보호를 제공한다:
-
정직하게 제안하고 투표를 받은 블록은 후속 단계의 장애로 인해 보상이 박탈되지 않는다;
-
극단적인 상황에서도, 예를 들어 어떤 노드가 자신의 제안 라운드를 고의로 건너뛰어 다른 사람에게 이전 블록의 MEV를 빼앗기도록 돕는다고 해도, 프로토콜은 후속 리더가 원래 블록을 우선 재제안하도록 강제하며, 공격자가 건너뛰기 절차를 통해 경제적 이득을 얻는 것을 막는다.
더욱 중요한 것은, MonadBFT가 보안성 향상을 위해 프로토콜의 성능을 희생하지 않았다는 점이다.
이전의 일부 꼬리 포크 대응 설계(예: BeeGees 프로토콜)는 어느 정도 보호 기능을 갖췄지만, 종종 높은 통신 복잡도(n²)나 매 라운드마다 추가 통신 프로세스를 활성화하는 데 의존하여, 실제 적용 시 시스템 부담을 크게 증가시켰다.
MonadBFT의 설계 전략은 훨씬 정교하다:
뷰 실패 또는 이상이 발생할 때에만 추가 통신(예: 타임아웃 메시지, 블록 재제안)을 시작한다. 대부분의 정직한 리더가 연속적으로 블록을 생성하는 정상 경로에서는, 프로토콜이 여전히 가볍고 효율적인 상태를 유지한다.
이러한 성능과 보안성 사이의 동적 균형이 바로 MonadBFT가 이전 세대 프로토콜보다 가지는 핵심 장점 중 하나이다.
요약
본문은 전통적인 PBFT 합의의 기본 메커니즘을 되짚고, HotStuff 프로토콜의 발전 경로를 정리하며, 특히 MonadBFT가 파이프라인 HotStuff 내재적 꼬리 포크 문제를 프로토콜 수준 구조에서 어떻게 해결하는지를 집중적으로 설명하였다.
꼬리 포크는 블록 제안자의 경제적 인센티브를 왜곡할 뿐 아니라 네트워크의 활성에 잠재적 위협을 가한다. MonadBFT는 재제안 메커니즘과 비승인 증명서(NEC)를 도입하여, 정직한 리더가 제안하고 법정 다수의 투표를 받은 블록이 폐기되거나 건너뛰지 않도록 보장한다.
다음 글에서는 MonadBFT의 또 다른 두 핵심 특징을 계속 탐구할 예정이다:
1) 준확정성(Speculative Finality)
2) 낙관적 응답성(Optimistic Responsiveness)
그리고 이러한 메커니즘이 검증자와 개발자에게 가지는 실제적 의미를 추가로 분석할 것이다.
계속됩니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
