
롤업 열풍 속에서 VM은 여전히 이야기할 점이 있다
작성자: PSE Trading Analyst @cryptohawk
TL;DR
1. 가상 머신(VM)은 프로그램 실행을 위한 소프트웨어 기반 시뮬레이션 컴퓨터 시스템으로, 다양한 하드웨어 장치를 시뮬레이션하여 제어된 호환 가능한 환경에서 프로그램이 작동할 수 있도록 한다.
2. 이더리움 가상 머신(EVM)은 이더리움 스마트 계약을 실행하기 위한 스택 기반 VM이며, zkEVM은 EVM과의 동등성/호환성을 유지하면서 zk-proof 생성 효율을 최적화한 형태이다. 반면 zkVM은 EVM과의 호환성을 포기하고 zk 친화성을 우선시한다. privacy zkVM은 zkVM에 원시적인 프라이버시 기능을 추가한 구조이다. SVM, FuelVM, MoveVM은 모두 병렬 처리를 통해 성능 극대화를 추구하지만 설계 세부사항에서 각각 고유한 특징을 지닌다. ESC VM과 BitVM은 각각 ETH와 BTC 체인 상에서 혁신적인 컴퓨팅 레이어 실험을 수행했으나, 현재로서는 실제 적용 수요가 낮은 편이다.
3. EVM은 방대한 사용자 생태계를 보유하고 있어 이를 포기하는 블록체인 네트워크는 단기간 내에 경쟁하기 어렵다. 따라서 비-EVM 생태계는 트랜스파일러/컴파일러/바이트코드 인터프리터 또는 VM 호환 계층을 통해 EVM 생태계 사용자를 유입하고, 비-EVM 가상머신의 특성을 활용해 새로운 서사 구축을 도모하는 것이 성공을 위한 필수 전략이 될 수 있다.
1.1 VM이란 무엇인가?
가상 머신(VM)은 컴퓨팅 자원을 가상화하는 기본 구성 요소로, 애플리케이션 및 운영 체제 실행과 거의 동일한 기능을 제공한다. 이 개념은 새로운 것이 아니며 다양한 기술 생태계에서 광범위하게 사용되고 있다.
블록체인 맥락에서 VM은 일반적으로 스마트 계약 실행을 위한 런타임 환경으로 불리는 프로그램 실행용 소프트웨어이다. VM은 CPU, 메모리, 디스크, 네트워크 인터페이스 등 다양한 하드웨어 장치를 시뮬레이션하여 가상 컴퓨터 환경을 제공한다. 체인 상 거래가 제출되면 VM은 해당 거래를 처리하고 거래 실행에 따라 변경되는 블록체인 상태(전체 네트워크의 현재 글로벌 상태)를 업데이트한다. 네트워크 상태 변화의 구체적인 규칙은 VM이 정의하며, 거래 처리 시 VM은 스마트 계약 코드를 노드/검증기 하드웨어에서 실행 가능한 형식으로 변환한다.
VM의 핵심 내장 요소 중 가장 중요한 것은 LLVM(Low-Level Virtual Machine)으로, 컴파일러의 핵심이라고 볼 수 있다. 아래 그림은 초기 EVM의 작동 방식을 나타내며, 스마트 계약 코드는 LLVM IR이라는 중간 코드를 거쳐 바이트코드로 변환된다. 이 바이트코드는 블록체인에 저장되며, 스마트 계약이 호출될 때 바이트코드는 Opcode로 변환되어 EVM과 노드 하드웨어에 의해 실행된다.

1.2 주요 VM
1.2.1 EVM — 블록체인 VM의 절대 강자, EVM이 8할 차지, 나머지 2할 분배
대표 프로젝트: Optimism, Arbitrum
현재 산업 내 개발자 및 사용자 활성도가 가장 높은 블록체인 생태계인 이더리움 가상 머신(EVM)은 스택 기반의 가상 머신으로, CPU, 메모리, 저장장치, 스택 등의 하드웨어를 시뮬레이션하여 가상 컴퓨터 환경을 제공하며, 이를 통해 스마트 계약 명령어를 실행하고 상태 및 데이터를 저장한다. EVM의 명령어 집합에는 산술 연산, 논리 연산, 저장 연산, 점프 연산 등을 포함하는 다양한 오퍼코드(Opcode)가 있다.

EVM이 시뮬레이션하는 메모리와 저장장치는 스마트 계약의 상태 및 데이터를 저장하는 장치이다. EVM은 메모리와 저장장치를 서로 다른 두 영역으로 간주하며, 읽기 및 쓰기를 통해 스마트 계약의 상태와 데이터에 접근할 수 있다.
EVM이 시뮬레이션하는 스택은 명령어의 피연산자와 결과를 저장하는 용도로 사용된다. EVM 명령어 집합의 대부분은 스택 기반이며, 스택에서 피연산자를 읽고 결과를 다시 스택에 푸시한다.

EVM의 설계 과정은 명백히 하향식(bottom-up)이다. 먼저 스택, 메모리 등 하드웨어 환경을 정의하고, 그에 맞춰 자체적인 어셈블리 명령어 집합(Opcode)과 바이트코드(Bytecode)를 설계했다. EVM 실행 효율을 위해 이더리움 커뮤니티는 Solidity와 Vyper라는 두 가지 컴파일형 고급 언어를 개발했다. Solidity는 설명이 필요 없으며, Vyper는 Vitalik이 Solidity의 일부 결함을 개선하기 위해 설계한 EVM 고급 언어이나 커뮤니티에서 충분한 채택을 받지 못해 점차 역사 속으로 사라졌다.
1.2.2 zkEVM — 모두 원해: EVM 환경 호환 + 전체 상태 루트 전환에 대한 zk-proof 지원
대표 프로젝트: Taiko, Scroll, Polygon zkEVM
zk-proof 계산을 고려하지 않고 설계된 EVM은 증명 회로에 부적합한 특성을 지닌다. 특히 특정 오퍼코드, 스택 기반 아키텍처, 저장 오버헤드 및 증명 비용 측면에서 문제가 있다. 반면 zkEVM은 zk-proof 계산에 적합한 방식으로 스마트 계약을 실행하는 가상 머신으로, EVM의 실행 과정을 zk-proof/유효성 증명을 통해 더 효율적이고 저비용으로 검증할 수 있게 한다. OP Rollup 실행 계층이 EVM을 그대로 사용하는 것과 달리, EVM을 ZK 친화적으로 만드는 것은 ZK Rollup의 추가적인 도전 과제이다.
ZK-rollup은 이더리움 가상 머신(EVM)과의 호환성이 쉽지 않다. 일반적인 EVM 계산을 회로에서 증명하는 것은 앞서 설명한 토큰 전송 같은 단순 계산보다 훨씬 어렵고 리소스를 많이 소모한다.
그러나 최근 제로지식 기술의 발전은 EVM 계산을 제로지식 증명 안에 포장하려는 관심을 재점화시켰다. 이러한 노력들은 프로그램 실행의 정확성을 효율적으로 검증할 수 있는 제로지식 EVM(zkEVM) 구현을 목표로 하고 있다.
EVM과 마찬가지로 zkEVM도 특정 입력에 대해 계산을 수행한 후 상태 간 전이를 수행한다. 차이점은 zkEVM이 프로그램 실행의 각 단계 정확성을 검증하는 제로지식 증명 또한 생성한다는 점이다. 유효성 증명은 가상 머신의 상태(메모리, 스택, 저장 공간) 및 계산 자체의 작업 정확성(즉, 올바른 오퍼코드를 호출하고 이를 정확히 수행했는가?)을 검증할 수 있다.

아이디어는 아름답지만 현실은 냉혹하다. 현재 롤업들은 ZK 친화성과 EVM 호환성(혹은 동등성)을 동시에 달성하기 어렵다. 즉, 이더리움 L1 실행 계층을 해시, 상태 트리, 트랜잭션 트리, 사전 컴파일 등을 포함해尽可能 완벽하게 복제해 롤업 블록을 처리하기 위해 기존 이더리움 L1 클라이언트를 그대로 사용할 수도 있고, 혹은 EVM 호환성을 포기하고 회로에서 증명/검증을 위해 기존 오퍼코드를 재설계하여 스마트 계약 실행을 허용할 수도 있다.
1.2.3 zkVM — 둘 다 잡기는 어렵다: zk-proof 효율 중심의 비-EVM 가상 머신
대표 프로젝트: Starknet, Zksync, RISC ZERO
zkVM은 EVM과의 호환성을 포기하고 데이터 증명과 상태 업데이트를 핵심 목표로 삼아 암호학과 고급 언어 사이에서 공통 기반을 찾아 다양한 애플리케이션을 위한 범용 프레임워크를 제공한다.
Starkware는 ZK 분야에서 일찍 시작해 기술적 축적이 풍부하여 일정한 기술적 선도를 확보했다. 대표적인 ZK 중심주의 아키텍처로, ZK를 중심으로 Cairo VM과 Cairo 언어를 구축했다. 다만 Cairo 언어의 학습 곡선이 높다는 단점이 있다.
ZKsync 프레임워크는 EVM과 ZK 양측의 특징을 통합해 Solidity와 자체 개발한 회로 언어 Zinc를 결합하였으며, 컴파일러 내부에서 IR 계층에서 통합했다. 장점은 컴파일러 코어인 LLVM이 여러 언어와 호환 가능하다는 점이다.
RISC Zero는 RISC-V 아키텍처 기반 시뮬레이터를 사용해 개발자가 Rust, C/C++, Go 등의 일반 언어로 zkVM용 프로그램을 작성할 수 있도록 한다. 이는 애플리케이션 로직이 Solidity로 표현 가능한 내용에 국한되지 않고 체인 독립적인 코드 작성이 가능함을 의미한다.
1.2.4 Privacy zkVM — zk 친화성 + 원시 프라이버시 지원으로 생태계에 새로운 불씨를 지피다
대표 프로젝트: Aleo, Ola, Polygon Miden
블록체인은 공개 원장 시스템으로 모든 거래가 체인 상에서 이루어지며, 주소나 계정과 관련된 자산 정보를 포함한 상태 변화가 공개된다. 따라서 확장성 솔루션 외에도 일부 블록체인 팀은 다음 핵심 기능으로 프라이버시를 선택하고 있다.
Privacy zkVM은 zk 친화성을 통한 확장성 지원 외에도, 자체 프로그래밍 언어가 원시적으로 프라이버시 기능을 지원함으로써 상위 레이어 개발자들이 프라이버시 기반 dapp을 개발할 수 있게 한다. 이는 MEV 문제 완전 해결, 사용자 데이터 소유권 보호 등 새로운 애플리케이션 시나리오와 거대한 서사를 창출할 수 있다. 물론 Privacy zkVM은 설계상 복잡도가 높아 실현을 위해서는 대규모 기술 팀이 필요하며, 몇 년 더 기다려야 할지도 모른다.
1.2.5 SVM — 물결이 빠진 후에도 여전히 남은 불씨: 성능 설계가 극한에 달한 실행 환경
대표 프로젝트: Eclipse Mainnet, Nitro, MakerDAO Chain(아마도)
SVM(Solana Virtual Machine)은 고성능 실행 환경을 표방하며, 스마트 계약은 주로 Rust 언어로 작성된다. 단일 스레드 계산 방식의 EVM 및 EOS WASM 실행 환경과 비교해 Solana 트랜잭션은 실행 시 읽거나 쓸 모든 상태를 명시하도록 요구함으로써 서로 겹치지 않는 트랜잭션과 동일 상태만 읽는 트랜잭션의 동시 실행을 구현한다.

또한 대량의 트랜잭션 블록을 신속하게 검증하고 브로드캐스트하기 위해 Solana 네트워크는 CPU 설계에서 흔히 사용되는 파이프라인 최적화를 널리 활용한다. 일련의 단계를 거쳐 처리되는 입력 데이터 스트림에서 각 단계마다 별도의 하드웨어가 담당하는 구조이다. 대표적인 비유는 세탁기와 건조기로, 여러 배치의 옷을 순차적으로 세탁/건조/접는 작업을 수행한다. 세탁은 건조 전에, 건조는 접기 전에 이루어져야 하지만 세 가지 작업은 각각 별도의 장치에서 병렬로 실행된다.

또한 SVM은 레지스터 기반으로 EVM보다 훨씬 작은 명령어 집합을 가지며, 이로 인해 SVM의 실행을 ZK에서 증명하기가 더 쉬워진다. 낙관적 롤업의 경우 레지스터 기반 설계는 체크포인트 설정을 더욱 용이하게 한다.
1.2.6 Fuel VM — 버프 완전 충전: UTXO 프레임워크 기반 병렬 가상 머신
대표 프로젝트: Fuel
Fuel VM은 EVM, Solana, WASM, BTC 및 Cosmos 기술 프레임워크를 개선한 것으로, EVM과 비교하면 다음과 같은 특징이 있다:

가장 독특한 점은 Fuel이 SVM처럼 접근 리스트(access lists)를 설정해 겹치지 않는 트랜잭션의 병렬 실행이 가능할 뿐 아니라 UTXO 모델을 채택하여 토큰 UTXO와 계약 UTXO를 분리함으로써 접근 효율과 계산 처리량을 더욱 향상시켰다는 것이다.

또한 Fuel VM은 자체 도메인 특화 언어 Sway와 지원 툴체인 Forc를 통해 강력하고 매끄러운 개발자 경험을 제공한다. 개발 환경은 Solidity 같은 스마트 계약 언어의 장점을 유지하면서 Rust 툴 생태계에서 도입한 패러다임을 채택했다.
앞으로 Fuel VM은 Sway 언어 업그레이드를 통해 바이트코드 크기 최적화, 더 많은 백엔드 지원(Solidity/Vyper에서 Sway로 마이그레이션), 추상화의 경제성 향상, 컴파일러 수준의 재진입 분석 개선 등을 실현할 예정이다.
1.2.7 ESC VM — Ordinal/Smartweave의 계승자: 이더리움 상의 컴퓨팅 레이어
대표 프로젝트: Ethscriptions Protocol
ESC VM(Ethscriptions Virtual Machine)은 Ethscriptions Protocol이 제안한 스마트 계약 방식이다. Ethscriptions Protocol 자체는 BTC Ordinal과 유사한 이더리움 체인 상 프로토콜로, 스마트 계약 및 L2와는 다른 저비용 대안을 탐색하는 데 초점을 맞춘다.
Ethscriptions는 사용자가 스마트 계약 저장 및 실행을 우회해 매우 낮은 비용으로 calldata 내에서 미리 정의된 프로토콜 규칙에 따라 계산을 수행할 수 있게 한다. 간단히 말해, 이더리움 트랜잭션이 성공하고, calldata가 규정된 유효한 데이터 형식을 따르며, 고유하고, 'to' 주소가 0이 아니면 Ethscription 생성이 합법으로 간주된다. 'from' 주소는 생성자, 'to' 주소는 소유자가 된다.
초기 설계에서는 각 Ethscription이 NFT 형태에 더 가까웠다. 예를 들어 이미지 NFT의 경우 Base64 형식으로 이미지 내용을 직접 calldata에 기록:

최근 인기를 끈 eths는 brc-20 프로토콜 사양을 참고해 생성된 Ethscription이다:

ESC VM이 도입한 스마트 계약은 '덤 계약(Dumb Contract)'이라 불리며, 논리 계약을 공개하지만 자체적으로는 EVM 형식으로 체인 상에서 상호작용하지 않는다. 또한 ESC VM은 '컴퓨터 명령'이라는 특수 형식을 추가했는데, 이 형식으로 생성된 ethscriptions는 ESC VM에 의해 덤 계약과의 상호작용으로 인식되며, Deploy - 덤 계약 배포, Call - 덤 계약 호출 등이 가능하다.
이 방식은 몇 가지 한계가 있다. 첫째, '덤 계약' 함수는 payable이 아니므로 덤 계약을 통해 ETH를 보내려면 '브릿지 계약'을 거쳐야 하는데, 이 브릿지 계약 자체가 권한 남용 및 자산 도난 위험을 지닌다. 둘째, 생태계 진입 장벽이 존재해 임의로 덤 계약을 생성할 수 없으며, 코드는 Ethscriptions Protocol 거버넌스 제안을 통해 정의되어야 한다.
요약하면, ESC VM은 이더리움 L1을 데이터 저장 계층으로 삼고 그 위에 컴퓨팅 계층을 구축하는 것으로, 계약 로직, 호출, 데이터 등을 이더리움 tx의 calldata 내에 위치시키는 방식이다. ESC VM의 글로벌 상태 합의는 ESC VM 클라이언트 합의이며, Arweave의 SmartWeave 구현 로직과 유사하나, SmartWeave의 데이터 저장 계층은 Arweave이다.
1.2.8 Bit VM — 흥미로운 연구 실험: BTC 상의 P2P 실행 채널
대표 프로젝트: ZeroSync
ZeroSync 창립자 Robin Linus는 10월 9일 "BitVM: Compute Anything On Bitcoin"이라는 백서를 발표했다. 정확히 말해 VM은 아니며, 계약이 비트코인 체인 상에 저장되지만 논리 실행은 오프체인에서 이루어지는 튜링 완전한 컴퓨팅 공간을 만들려는 시도이다. 상대방이 위반했다고 판단되면 자신이 체인 상에서 도전을 제기할 수 있으며, 상대방이 올바른 응답을 하지 못하면 자신이 계약 내 모든 자금을 가져갈 수 있다.
장점은 비트코인에 튜링 완전성을 부여하면서도 비트코인 프로토콜 수정, 새로운 오퍼코드, 소프트포크 없이 언제든지 적용 가능하다는 점이다.
단점도 명확하다. 첫째, 양방향 거래(한쪽 증명, 한쪽 검증)만 지원하며, 둘째, 계약 생성 시大量 데이터 생성 및大量 거래 사전 서명이 필요해 오프체인 정보 저장 비용이 매우 크다.
기술 로직 간단 소개:
(1) 점 입력 커밋
점 입력 커밋은 증명자가 논리 게이트의 입력값을 0 또는 1로 설정할 수 있게 한다. 이 커밋에는 H(A0), H(A1) 두 개의 해시 값이 존재하며, 증명자는 A0의 해시 원상을 공개하면 입력값을 0으로 설정하고, A1을 공개하면 1로 설정한다.
(2) 논리 게이트 커밋
입력값이 결정된 후, 비트코인의 AND, NOT 등의 오퍼코드를 조합해 비트코인 스크립트 내에서 임의의 논리 게이트를 구성할 수 있다.
(3) 이진 회로 커밋
억 단위의 논리 게이트를 하나의 이진 회로로 구성하면 튜링 완전성을 실현할 수 있다. 이 이진 회로를 비트코인 네트워크에 커밋하기 위해 모든 논리 게이트를 Taproot 주소의 리프 노드에 넣어야 한다.

(4) 도전-응답 단계
단지 회로를 체인 상에 커밋하는 것으로는 충분하지 않다. 거래 당사자들 사이에는 계약 계산 결과가 정확한지 효과적으로 검증할 수 있는 방법이 필요하다. 이상적인 경우, 계약은 오프체인에서 실행되며 양측이 협력하고 결과에 이견이 없으면 좋다. 그러나 분쟁이 발생하면 도전-응답 단계를 통해 계산 결과를 검증하고 비트코인 스크립트를 통해 채널 잔액을 강제 분배해야 한다.

따라서 BitVM은 어떤 비트코인 롤업이나 L2와도 거리가 멀며, 완전한 가상 머신 실행 환경, 글로벌 상태, 복잡한 스마트 계약을 게시하기 위한 고급 언어, 임의의 수의 사용자가 이러한 계약과 쉽게 상호작용할 수 있는 능력을 갖추지 못했다. 쉽게 비유하자면, BitVM은 누구나 모바일 기기를 사용할 수 있는 시대에 방보다 큰 거대한 컴퓨터를 구축하는 것과 같다.
1.2.9 MoveVM — 페이스북 Web2 유전자를 이어받은 산물
대표 프로젝트: Aptos, Sui
Move는 안전한 스마트 계약을 작성하기 위한 프로그래밍 언어로, 페이스북이 Diem 블록체인을 위해 개발했다. Diem 프로젝트 종료 후 Aptos, Sui 등이 Move 언어를 계승했다. Move 블록체인의 가장 큰 특징은 계정 주소를 루트로 하는 트리 구조의 글로벌 저장소를 사용하며, 각 주소는 리소스 데이터와 모듈 코드를 저장할 수 있다는 점이다.

Move는 두 가지 유형의 프로그램을 가진다: 모듈과 스크립트. 모듈은 구조체 타입과 그 타입에 대한 연산 함수를 정의하는 라이브러리이다. 구조체 타입은 Move의 글로벌 저장 모델을 정의하며, 모듈 함수는 저장소 업데이트 규칙을 정의한다. 모듈 자체도 글로벌 저장소에 저장된다. 스크립트는 실행 파일의 진입점으로, 전통 언어의 main 함수와 유사하며 글로벌 저장소에 게시되지 않은 임시 코드 조각이다.

요약하면, Move 모듈은 시스템 실행 시 로드되는 동적 라이브러리 모듈과 유사하고, 스크립트는 메인 프로그램과 유사하다. 사용자는 글로벌 저장소에 접근하기 위한 자신의 스크립트를 작성할 수 있으며(모듈 호출 포함), 모듈 게시 또는 스크립트 실행은 Move VM을 통해 이루어진다.
1.3 생태계 발전 추세
현재 EVM의 네트워크 효과가 매우 강력하기 때문에, EVM 사용자의 비-EVM 체인 생태계로의 이동은 신생 블록체인 프로젝트의 가장 큰 성장 동력이 되었으며, 이는 더 많은 Dapp 조합 가능성과 더 큰 연결성을 가져오고, 향후 몇 년 내 더 빠른 사용자 증가를 유발할 수 있다.
1.3.1 지갑 프론트엔드 호환
EVM 사용자를 비-EVM 체인 생태계로 유입하는 것은 오랫동안 주요 장애였으나, 최근 출시된 MetaMask Snap이 이를 해결할 전망이다. EVM 사용자는 지갑을 전환하지 않고도 계속해서 MetaMask를 사용할 수 있다. Drift의 오픈소스 기여로 훌륭한 MetaMask Snap 구현이 완성되었으며, UX 측면에서 EVM 체인과의 상호작용과 거의 동일하다. Eclipse 메인넷 사용자는 MetaMask 내에서 네이티브 애플리케이션과 상호작용하거나 Solana 네이티브 지갑(Salmon 등)을 사용할 수 있다.

1.3.2 VM 백엔드 호환
1.3.2.1 트랜스파일러 / 컴파일러
대표 프로젝트: Warp
Warp는 Solidity-Cairo 트랜스파일러로, 현재 이더리움 유명 인프라 팀 Nethermind이 개발을 완료했다. Warp는 Solidity 코드를 Cairo로 변환할 수 있으나, 변환된 Cairo 프로그램은 종종 Cairo의 특성(내장 함수 호출, 메모리 최적화 등)을 추가하고 수정해야 실행 효율을 극대화할 수 있다.
1.3.2.2 바이트코드 인터프리터 / VM 호환 계층
대표 프로젝트: Kakarot, Neon EVM
Kakarot는 Starknet 상에 배포된 Cairo로 작성된 EVM 바이트코드 인터프리터로, 스마트 계약 형태로 EVM의 스택, 메모리, 실행 등을 시뮬레이션한다. 코드 트랜스파일링과 달리 Kakarot는 EVM의 Opcode와 사전 컴파일을 일일이 구현했으며, Account Registry, Blockhash Registry 등의 구성 요소를 통해 계정 주소 매핑, 블록 정보 조회 등을 추가 처리해 Kakarot의 원시 호환성을 더욱 높였다.

Neon EVM은 스마트 계약 형태로 실행되는 EVM으로, 어떤 SVM 체인에도 배포할 수 있다. Eclipse 메인넷 자체는 SVM을 실행 환경으로 사용하지만, Neon EVM을 통해 완전한 EVM 호환성(EVM 바이트코드 지원 및 이더리움 JSON-RPC 포함)을 달성했으며, 처리량이 단일 스레드 EVM보다 더 높다. 또한 각 Neon EVM 인스턴스는 자체 로컬 수수료 시장을 가지며, 하나의 블록 높이에서 단일 스마트 계약 계좌 상호작용과 관련된 계산 단위는 제한(블록 계산 단위의 1/4)이 있어 사용자는 특정 핫스팟 계약 상호작용이나 블록이 꽉 찼을 때만 priority fee를 지불하면 된다. 이 의미에서 애플리케이션이 자체 계약을 배포하면 앱 체인과 유사한 이점을 얻어 특정 계약 상호작용으로 인한 네트워크 전반의 사용자 경험, 보안, 유동성 손상을 줄일 수 있다.

TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News














