Merlin 기술 방안 해설: 과연 어떻게 작동하는가?
글: Faust, 지식인 web3
2023년 각인의 여름부터 지금까지, 비트코인 레이어2(Layer2)는 항상 전체 Web3 생태계의 핵심 주제였다. 이 분야가 이더리움 레이어2에 비해 훨씬 늦게 등장했음에도 불구하고, POW의 독특한 매력과 현물 ETF의 성공적인 도입 덕분에 증권화 리스크를 우려할 필요 없는 비트코인은 단 6개월 만에 수백억 달러 규모의 자본을 레이어2라는 파생 트랙으로 집중시켰다.
비트코인 레이어2 시장에서 수십억 달러의 TVL을 보유한 Merlin은 의심할 여지 없이 가장 큰 규모와 가장 많은 관심을 받는 프로젝트이다. 명확한 스테이킹 인센티브와 상당한 수익률을 바탕으로 Merlin은 단 몇 개월 만에 급부상하여 Blast를 능가하는 생태계 신화를 창조했다. Merlin의 인기가 치솟으면서 그들의 기술 방안에 대한 논의도 점점 더 많은 사람들의 관심을 끌고 있다.
본 글에서는 지식인 web3가 Merlin 체인의 기술 방안에 초점을 맞춰 공개된 문서 및 프로토콜 설계 아이디어를 해석하고자 한다. 우리는 더 많은 사람들이 Merlin의 대략적인 작동 흐름을 이해하고, 보안 모델에 대해 보다 명확한 인식을 갖도록 하며, 이 '톱티어 비트코인 레이어2'가 어떻게 구동되는지를 직관적으로 이해할 수 있도록 돕고자 한다.
Merlin의 탈중앙화 오라클 네트워크: 개방형 오프체인 DAC 위원회
모든 레이어2 프로젝트에게 있어서, 이더리움 레이어2든 비트코인 레이어2든 간에, 데이터 가용성(DA)과 데이터 게시 비용은 해결해야 할 주요 문제 중 하나이다. 비트코인 네트워크 자체는 여러 가지 문제를 안고 있으며, 본질적으로 큰 데이터 처리량을 지원하지 않기 때문에, 이 귀중한 DA 공간을 어떻게 활용할 것인지가 레이어2 프로젝트팀의 상상력을 시험하는 난제가 되었다.
명백한 결론이 하나 있다. 레이어2가 무처리 상태의 거래 데이터를 직접 비트코인 블록에 게시한다면, 고처리량도, 저수수료도 실현할 수 없다. 현재 가장 일반적인 해결책은 두 가지인데, 하나는 데이터를 가능한 한 압축한 후 비트코인 블록에 업로드하는 것이고, 다른 하나는 데이터를 아예 비트코인 체인 외부에 게시하는 것이다.
첫 번째 접근법을 채택한 레이어2 중 가장 유명한 것은 Citrea일 수 있다. 이들은 일정 시간 동안 레이어2의 상태 변화(state diff), 즉 여러 계정의 상태 변경 결과와 해당 ZK 증명을 함께 비트코인 체인에 업로드하려 한다. 이렇게 하면 누구든지 비트코인 메인넷에서 state diff와 ZKP를 다운로드하여 Citrea의 상태 변화를 확인할 수 있다. 이 방법은 체인에 올리는 데이터 크기를 90% 이상 줄일 수 있다.
이 방식은 데이터 크기를 크게 줄일 수 있지만 병목 현상 역시 명확하다. 짧은 시간 내에 많은 계정의 상태가 변할 경우, 레이어2는 이러한 모든 변경 사항을 취합하여 비트코인 체인에 업로드해야 하며, 결국 데이터 게시 비용을 매우 낮게 유지하기 어렵다. 이것은 많은 이더리움 ZK 롤업에서도 마찬가지이다.
많은 비트코인 레이어2 프로젝트는 차라리 두 번째 경로를 선택한다. 즉, 비트코인 체인 외부의 DA 솔루션을 사용하거나, 자체 DA 계층을 구축하거나, Celestia나 EigenDA 등을 활용한다. B^Square, BitLayer 그리고 본문의 주인공인 Merlin 모두 이러한 오프체인 DA 확장 방안을 따르고 있다.
지식인 web3의 이전 글 —— 《B^2 신규 기술 로드맵 분석: 비트코인 오프체인 DA와 검증 계층의 필수성》에서 언급했듯이, B^2는 Celestia를 모방하여 체인 외부에 데이터 샘플링 기능을 지원하는 DA 네트워크(B^2 Hub)를 구축했다. 거래 데이터 또는 state diff 등의 'DA 데이터'는 비트코인 체인 외부에 저장되며, 비트코인 메인넷에는 datahash / merkle root만 업로드된다.
이는 사실상 비트코인을 신뢰 불필요한 공고판으로 사용하는 것이다. 누구든지 비트코인 체인에서 datahash를 읽을 수 있다. 당신이 오프체인 데이터 제공자로부터 DA 데이터를 받은 후, 이것이 체인 상의 datahash와 일치하는지 확인할 수 있다. 즉 hash(data1) == datahash1 인지를 확인하는 것이다. 두 값이 일치하면, 오프체인 데이터 제공자가 준 데이터가 정확하다는 의미이다.
(비트코인 체인 외부에 DA 계층을 두는 레이어2 원리도, 출처: 지식인 web3)
위 과정은 오프체인 노드가 제공하는 데이터가 레이어1의 특정 '단서'와 연관되어 있음을 보장하여, DA 계층이 악의적인 거짓 데이터를 제공하는 것을 방지할 수 있다. 하지만 여기엔 중요한 악용 시나리오가 존재한다. 만약 데이터의 출처인 시퀀서(Sequencer)가 datahash에 해당하는 실제 데이터를 전혀 배포하지 않고, datahash만 비트코인 체인에 올린 후, 의도적으로 해당 데이터를 아무에게도 공개하지 않는다면 어떻게 될까?
비슷한 예로는 ZK-Proof와 StateRoot만 게시하고, 대응하는 DA 데이터(state diff 또는 Transaction data)는 게시하지 않는 경우가 있다. 사용자는 ZKProof를 검증하여 Prev_Stateroot에서 New_Stateroot로의 계산 과정이 유효함을 알 수 있지만, 어떤 계정의 상태(state)가 변경되었는지는 알 수 없다. 이 경우 사용자의 자산은 안전하지만, 네트워크의 실제 상태를 알 수 없으며, 어떤 거래가 체인에 포함되었는지, 어떤 컨트랙트의 상태가 업데이트되었는지 알 수 없기 때문에 레이어2는 사실상 정지 상태와 같다.
이것이 바로 '데이터 보류(Data withholding)' 문제이다. 이더리움 재단의 Dankrad는 2023년 8월 트위터에서 이와 유사한 문제를 간단히 논의한 바 있으며, 특히 'DAC'라는 개념에 초점을 맞췄다.
많은 오프체인 DA 방안을 채택한 이더리움 레이어2는 종종 특별한 권한을 가진 몇 개의 노드를 선정해 위원회를 구성하는데, 이를 데이터 가용성 위원회(Data Availability Committee, DAC)라고 부른다. 이 DAC 위원회는 담보인 역할을 하여 "시퀀서가 실제로 체인 외부에 완전한 DA 데이터(transaction data 또는 state diff)를 게시했다"고 공언한다. 이후 DAC 노드들이 공동으로 다중 서명(multisig)을 생성하며, 이 다중 서명이 임계값(예: 2/4)을 충족하면 레이어1의 관련 스마트 컨트랙트는 시퀀서가 DAC 위원회의 검사를 통과하여 완전한 DA 데이터를 체인 외부에 게시했다고 간주한다.
이더리움 레이어2의 DAC 위원회는 대부분 POA(Poof of Authority) 모델을 따르며, KYC를 통과했거나 공식적으로 지정된 소수의 노드만 DAC 위원회에 참여할 수 있도록 제한한다. 이로 인해 DAC는 '중앙집중화', '컨소시엄 체인'의 대명사가 되었다. 또한 일부 DAC 기반 이더리움 레이어2의 경우, 시퀀서는 DA 데이터를 DAC 멤버 노드에게만 전송하며 다른 곳으로는 데이터를 거의 배포하지 않는다. 누구든지 DA 데이터를 얻으려면 반드시 DAC 위원회의 허가를 받아야 하며, 이는 컨소시엄 체인과 실질적 차이가 없다.
분명히, DAC는 탈중앙화되어야 한다. 레이어2는 DA 데이터를 레이어1에 직접 올리지 않을 수 있지만, DAC 위원회의 진입 권한은 열려 있어야 하며, 소수의 사람들이 공모하여 악행을 저지를 가능성을 방지해야 한다. (DAC의 악용 시나리오에 대한 논의는 Dankrad의 이전 트위터 발언을 참고하라)
Celestia가 이전에 제안한 BlobStream은 본질적으로 중앙화된 DAC를 Celestia로 대체하는 것으로, 이더리움 L2의 시퀀서가 DA 데이터를 Celestia 체인에 게시하면, Celestia 노드의 2/3 이상이 서명하면, 이더리움에 배포된 레이어2 전용 컨트랙트는 시퀀서가 DA 데이터를 정직하게 게시했다고 판단한다. 이는 실질적으로 Celestia 노드를 담보인으로 삼는 것이다. Celestia는 수백 개의 검증노드(Validator)를 보유하고 있기 때문에, 이 거대한 DAC는 비교적 탈중앙화되어 있다고 볼 수 있다.
Merlin이 채택한 DA 솔루션은 사실 Celestia의 BlobStream과 매우 유사하다. POS 방식을 통해 DAC의 진입 권한을 개방하여 탈중앙화를 추구하는 것이다. 누구나 충분한 자산을 스테이킹하면 DAC 노드를 운영할 수 있다. Merlin의 문서에서는 위의 DAC 노드를 오라클(Oracle)이라고 명명하며, BTC, MERL, 심지어 BRC-20 토큰까지 스테이킹할 수 있도록 유연한 스테이킹 메커니즘을 제공하고, Lido와 유사한 대리 스테이킹도 지원한다고 밝혔다. (오라클의 POS 스테이킹 프로토콜은 Merlin의 다음 단계 핵심 스토리 중 하나이며, 제공하는 스테이킹 수익률도 상당히 높다)
여기서 Merlin의 작동 흐름을 간략히 설명하겠다. (아래 이미지 참조):
- 시퀀서(Sequencer)는 다수의 거래 요청을 수신한 후 이를 취합하여 data batch(데이터 배치)를 생성하고, 이를 Prover 노드와 Oracle 노드(탈중앙화 DAC)에게 전달한다.
- Merlin의 Prover 노드는 탈중앙화되어 있으며, lumoz의 Prover as a Service 서비스를 채택한다. Prover 마이닝 풀은 여러 data batch를 수신한 후 대응하는 제로노울리지 증명(ZK Proof)을 생성하며, 이후 ZKP를 Oracle 노드에게 보내 검증을 맡긴다.
- Oracle 노드는 lumoz의 ZK 마이닝 풀이 보낸 ZK Proof가 Sequencer가 보낸 data batch와 일치하는지 검증한다. 만약 두 데이터가 일치하고 다른 오류가 없다면 검증을 통과한다. 이 과정에서 탈중앙화된 Oracle 노드들은 문턱 서명(threshold signature)을 통해 다중 서명을 생성하며, 외부에 다음과 같이 공언한다 — 시퀀서가 완전한 DA 데이터를 올바르게 게시했으며, 대응하는 ZKP는 유효하며 Oracle 노드의 검증을 통과했다.
- 시퀀서는 Oracle 노드로부터 다중 서명 결과를 수집하며, 서명 수가 임계값을 충족하면 이 서명 정보를 비트코인 체인에 전송하고, DA 데이터(data batch)의 datahash와 함께 외부에서 읽고 확인할 수 있도록 한다.
(Merlin 작동 원리도, 출처: 지식인 web3)
- Oracle 노드는 ZK Proof 검증 계산 과정을 특별히 처리하여 Commitment(약속)를 생성하고, 이를 비트코인 체인에 게시하여 누구든지 이 '약속'에 도전(challenge)할 수 있도록 한다. 이 과정은 bitVM의 사기 증명(fraud proof) 프로토콜과 기본적으로 동일하다. 도전이 성공하면 Commitment를 게시한 Oracle 노드는 경제적 처벌을 받는다. 물론 Oracle이 비트코인 체인에 게시해야 하는 데이터에는 현재 레이어2 상태의 해시인 StateRoot와 ZKP 자체도 포함되어 외부에서 검사할 수 있도록 한다.
참고자료: 《간단히 알아보는 BitVM: BTC 체인에서 사기 증명을 어떻게 검증하는가》
여기서 추가로 설명해야 할 세부 사항이 있다. 먼저 Merlin의 로드맵에 따르면, 향후 Oracle이 DA 데이터를 Celestia에 백업하도록 할 계획이다. 이를 통해 Oracle 노드는 로컬의 오래된 데이터를 적절히 폐기할 수 있고, 데이터를 영구적으로 로컬에 저장할 필요가 없다. 또한 Oracle Network가 생성한 Commitment는 사실 Merkle Tree의 root이며, 단순히 root를 공개하는 것만으로는 충분하지 않다. Commitment에 대응하는 전체 데이터셋을 모두 공개해야 하므로, 이를 위한 제3의 DA 플랫폼이 필요하다. 이 플랫폼은 Celestia나 EigenDA일 수도 있고, 다른 DA 계층일 수도 있다.
참고자료: 《B^2 신규 기술 로드맵 분석: 비트코인 오프체인 DA와 검증 계층의 필수성》
보안 모델 분석: 낙관적인 ZK롤업 + Cobo의 MPC 서비스
앞서 우리는 Merlin의 작동 흐름을 간략히 설명했으며, 독자들은 이제 그 기본 구조를 어느 정도 이해했을 것이다. 우리는 쉽게 알 수 있다. Merlin은 B^Square, BitLayer, Citrea와 마찬가지로 동일한 보안 모델 — 즉 '낙관적인 ZK-Rollup'을 따르고 있다.
처음 이 용어를 접하면 많은 이더리움 애호가들에게 이상하게 들릴 수 있다. '낙관적인 ZK-Rollup'이란 무엇인가? 이더리움 커뮤니티의 인식에서 ZK 롤업의 '이론적 모델'은 완전히 암호학적 계산의 신뢰성에 기반하며, 신뢰 가정(trust assumption)을 도입할 필요가 없다. 반면 '낙관적(optimistic)'이라는 표현은 오히려 신뢰 가정을 도입한다는 의미이다. 이는 대부분의 경우 롤업이 오류 없이 안정적이라고 낙관적으로 믿어야 한다는 뜻이다. 오류가 발생하면 사기 증명(fraud proof)을 통해 롤업 운영자를 처벌할 수 있는데, 이것이 바로 낙관적 롤업(Optimistic Rollup), 즉 OP 롤업의 명칭 유래이다.
롤업의 중심지인 이더리움 생태계 입장에서는 '낙관적인 ZK-Rollup'이 다소 어색하게 느껴질 수 있다. 그러나 이것은 오히려 비트코인 레이어2의 현실에 잘 부합한다. 기술적 제약으로 인해 비트코인 체인 상에서는 ZK Proof를 완전히 검증할 수 없으며, 특수한 경우에만 ZKP의 일부 계산 과정을 검증할 수 있다. 이러한 전제 하에서 비트코인 체인은 실질적으로 사기 증명 프로토콜만을 지원할 수 있다. 사용자는 체인 외부의 ZKP 검증 과정에서 특정 계산 단계에 오류가 있음을 지적하고 사기 증명을 통해 도전할 수 있다. 물론 이는 이더리움식 ZK 롤업만큼 완벽하지는 못하지만, 현재 비트코인 레이어2가 달성할 수 있는 가장 신뢰할 수 있고 안정적인 보안 모델이다.
위와 같은 낙관적인 ZK-Rollup 방식 하에서, 레이어2 네트워크에 N명의 도전 권한을 가진 사용자가 존재한다고 가정하자. 이 N명의 도전자 중 단 1명이라도 정직하고 신뢰할 수 있으며, 언제든지 오류를 감지하고 사기 증명을 제기할 수 있다면, 레이어2의 상태 전환은 안전하다. 물론 완성도가 높은 낙관적 롤업은 인출 브릿지(withdrawal bridge)도 사기 증명 프로토콜의 보호를 받아야 하지만, 현재 거의 모든 비트코인 레이어2는 이를 실현하지 못하고 다중 서명(MPC)에 의존하고 있다. 따라서 어떤 다중 서명/MPC 방안을 선택할지는 레이어2의 보안성과 밀접하게 연결된 문제이다.
Merlin은 브릿지 솔루션으로 Cobo의 MPC 서비스를 선택하였으며, 콜드/핫 월렛 분리 등의 조치를 통해 브릿지 자산을 Cobo와 Merlin Chain이 공동 관리한다. 모든 인출 행위는 Cobo와 Merlin Chain의 MPC 참여자가 공동으로 처리해야 하며, 본질적으로 기관의 신용을 통해 인출 브릿지의 신뢰성을 보장하는 것이다. 물론 이것은 현재 단계의 일시적 조치일 뿐이며, 프로젝트가 점차 완성됨에 따라 인출 브릿지는 BitVM과 사기 증명 프로토콜을 도입하여 1/N 신뢰 가정을 갖는 '낙관적 브릿지(optimistic bridge)'로 교체될 수 있다. 다만 이러한 방식의 실현 난이도는 매우 높다. (현재 거의 모든 레이어2 공식 브릿지는 다중 서명에 의존하고 있다)
전체적으로 보면, 우리는 Merlin이 POS 기반 DAC, BitVM 기반 낙관적 ZK-Rollup, Cobo의 MPC 자산 보관 솔루션을 도입하여 DA 문제를 해결하고, BitVM과 사기 증명 프로토콜을 도입하여 상태 전환의 보안을 보장하며, 유명 자산 보관 플랫폼 Cobo의 MPC 서비스를 도입하여 인출 브릿지의 신뢰성을 보장하고 있음을 정리할 수 있다.
Lumoz 기반의 2단계 검증식 ZKP 제출 방안
앞서 우리는 Merlin의 보안 모델을 정리하고 낙관적 ZK-롤업 개념을 소개했다. Merlin의 기술 로드맵에는 탈중앙화된 Prover에 대해서도 언급하고 있다. 잘 알려진 바와 같이 Prover는 ZK-Rollup 아키텍처의 핵심 역할 중 하나로서, 시퀀서가 게시한 Batch에 대한 ZKProof를 생성하는 책임을 진다. 그런데 제로노울리지 증명의 생성 과정은 하드웨어 자원을 매우 많이 소모하기 때문에 큰 문제이다.
ZK 증명 생성을 가속화하기 위해 작업을 병렬화하여 분할 처리하는 것은 가장 기본적인 방법이다.所谓 병렬화란, ZK 증명 생성 작업을 서로 다른 부분으로 나누어 다양한 Prover가 각각 완료한 후, 마지막에 Aggregator(집계자)가 여러 개의 증명을 하나로 통합하는 것을 말한다.
ZK 증명 생성 속도를 높이기 위해 Merlin은 Lumoz의 Prover as a service(PaaS) 방안을 채택할 계획이다. 이는 많은 하드웨어 장치를 모아 마이닝 풀을 구성한 후, 계산 작업을 각 장치에 분배하고 이에 따른 인센티브를 제공하는 것으로, POW 마이닝과 유사하다.
이러한 탈중앙화된 Prover 방안에는 소위 프론트런(front-running) 공격이라는 공격 시나리오가 존재한다. 예를 들어, 특정 집계자(Aggregator)가 ZKP를 생성한 후 보상을 받기 위해 이를 전송한다. 다른 집계자들이 ZKP 내용을 보고 자신보다 먼저 동일한 내용을 게시하여 "내가 먼저 생성했다"고 주장하는 경우, 이를 어떻게 해결할 것인가?
대부분이 떠올리는 가장 직관적인 해결책은 각 Aggregator에게 특정 작업 번호를 할당하는 것이다. 예를 들어 작업 1은 Aggregator A만 수행할 수 있고, 다른 사람이 작업 1을 완료하더라도 보상을 받지 못한다. 그러나 이 방법에는 단일 실패 지점(single point of failure)에 취약하다는 문제가 있다. 만약 Aggregator A가 성능 문제나 연결 끊김으로 작업을 완료하지 못하면, 작업 1은 계속해서 막힌다. 게다가 이러한 작업을 단일 실체에 할당하는 방식은 경쟁적 인센티브 메커니즘을 통해 생산 효율을 높일 수 없기 때문에 좋은 방법이 아니다.
Polygon zkEVM은 블로그에서 '효율성 증명(Proof of efficiency)'이라는 방법을 제안하면서, 다양한 Aggregator들 사이의 경쟁을 촉진하고 선착순 방식으로 인센티브를 분배해야 한다고 주장했다. 즉, ZK-Proof를 가장 먼저 체인에 제출한 Aggregator가 보상을 받는다는 것이다. 그러나 그는 MEV 프론트런 문제를 어떻게 해결할지는 언급하지 않았다.
Lumoz는 2단계 검증 방식의 ZK 증명 제출 방안을 채택한다. 특정 Aggregator가 ZK 증명을 생성한 후, 처음에는 완전한 내용을 게시하지 않고 ZKP의 해시만을 게시한다. 즉, hash(ZKP+Aggregator Address)를 게시하는 것이다. 이렇게 하면 다른 사람들이 해시 값을 봐도 대응하는 ZKP 내용을 알 수 없기 때문에 직접 프론트런을 할 수 없다.
누군가 전체 해시를 복사해서抢先 게시하더라도 의미가 없다. 왜냐하면 해시 안에는 특정 집계자 X의 주소가 포함되어 있기 때문이다. 집계자 A가 그 해시를抢先 게시하더라도, 해시의 원상(image)이 공개되면 그 안에 포함된 집계자 주소는 A가 아닌 X임을 모두 알게 된다.
이러한 2단계 검증식 ZKP 제출 방안을 통해 Merlin(Lumoz)는 ZKP 제출 과정에서 발생하는 프론트런 문제를 해결하고, 높은 경쟁성을 갖춘 제로노울리지 증명 생성 인센티브를 실현하여 ZKP 생성 속도를 향상시킬 수 있다.
Merlin's Phantom: 멀티체인 상호 운용성
Merlin의 기술 로드맵에 따르면, Merlin과 다른 EVM 체인 간의 상호 운용성도 지원할 예정이며, 이전 Zetachain의 접근 방식과 기본적으로 유사하다. Merlin을 소스 체인(source chain)으로 하고 다른 EVM 체인을 타겟 체인(target chain)으로 삼을 때, Merlin 노드가 사용자의 크로스체인 요청을 감지하면 타겟 체인에서 후속 작업 흐름을 트리거한다.
예를 들어, Polygon에 Merlin 네트워크가 제어하는 EOA 계정을 배포할 수 있다. 사용자가 Merlin 체인에서 크로스체인 상호 운용 명령을 게시하면, Merlin 네트워크가 먼저 그 내용을 해석하여 타겟 체인에서 실행할 거래 데이터를 생성한 후, Oracle Network가 해당 거래에 대해 MPC 서명을 처리하여 디지털 서명을 생성한다. 이후 Merlin의 Relayer 노드가 Polygon에서 이 거래를 실행하며, 타겟 체인의 EOA 계정에 있는 자산으로 후속 작업을 완료한다.
사용자가 요구한 작업이 완료되면, 해당 자산은 사용자의 타겟 체인 상 주소로 직접 전달되며, 이론적으로는 다시 Merlin 체인으로 직접 크로스체인될 수도 있다. 이 방안은 몇 가지 명백한 장점이 있다. 전통적인 자산 크로스체인 시 크로스체인 브릿지 컨트랙트와 관련된 수수료 마모를 피할 수 있으며, Merlin의 Oracle Network가 크로스체인 작업의 보안을 직접 보장하기 때문에 외부 인프라에 의존할 필요가 없다. 사용자가 Merlin 체인을 신뢰한다면, 이러한 크로스체인 상호 운용 작업은 문제가 없다고 간주할 수 있다.
결론
본문에서는 Merlin 체인의 전반적인 기술 방안을 간략히 해설하였다. 이를 통해 더 많은 사람들이 Merlin의 대략적인 작동 흐름을 이해하고, 보안 모델에 대해 보다 명확한 인식을 갖기를 기대한다. 현재 비트코인 생태계가 매우 활발한 점을 고려할 때, 이러한 기술 보급 활동은 가치 있으며 널리 필요로 된다고 생각한다. 앞으로도 우리는 Merlin뿐 아니라 bitLayer, B^Square 등 프로젝트에 대해 장기적으로 추적하여 보다 심층적인 기술 분석을 진행할 예정이니 많은 기대 부탁드린다!
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@godrealmx
