이동 쌍둥이: 수이와 앱토스가 블록체인 환경에 도전하는 방법

저자: Zeke, YBB Capital 펠로우, 0xjs@GoldenFinance 편집

서문

최근 시장이 점점 더 침체되면서 이 분야의 많은 OG가 산업의 목적에 대해 의문을 갖기 시작했습니다.

저는 이에 대한 개인적인 생각을 공유하고자 합니다. 저는 항상 과거의 많은 원대한 비전들이 처음부터 논리적으로 일관성이 없었기 때문에 '폭로'되었다고 생각해왔습니다. 비금융 디앱들은 탈중앙화의 가치를 강조함으로써 자신들의 단점을 숨기려고 하는 경우가 많습니다. 하지만 실제로는 구글, 트위터, 유튜브보다 다중 서명 지갑과 단일 노드 서버가 충분히 안전하다며 이를 신뢰해달라고 요청합니다. 이러한 비전 중 상당수는 검증되지 않았을 뿐이지 실제로 테스트된 적이 없습니다. 저는 이러한 비전이 처음 상상했던 것만큼 거창하지는 않더라도 여전히 중요하다고 생각하며, 이를 뒷받침할 강력한 기반이 필요하다고 생각합니다. 최소한 탈중앙화 또는 웹2.0에 상응하는 경험을 제공해야 합니다.

예를 들어, 한때는 과소평가되었지만 지금은 모든 면에서 업계 리더들을 따라잡고 있는 톤과 솔라나를 들 수 있습니다. 애플리케이션 지원 블록체인은 혁신을 필요로 하며, 혁신은 모든 주기에서 업계를 발전시킵니다. 오늘은 오랫동안 주목받지 못했던 블록체인인 무브 기반 블록체인을 살펴보겠습니다.

1. 무브

무브 프로그래밍 언어는 원래 메타의 메타버스 비전을 위한 기반으로서 보다 안정적이고 규제된 스테이블코인을 만드는 것이 목표였던 메타의 중단된 프로젝트인 디엠(원래 명칭은 리브라)을 위해 개발되었습니다. 그러나 이 프로젝트는 전 세계 규제 당국의 강력한 반대와 끊임없는 압력에 직면했습니다. 규제 당국은 디엠의 규모가 페이스북의 방대한 사용자 기반과 결합되어 금융 안정성, 통화 정책, 데이터 프라이버시에 위협이 될 수 있다고 우려했습니다. 특히 바이든 행정부의 압박을 받은 메타는 결국 Diem 프로젝트를 포기해야 했습니다.

디엠의 핵심은 완전히 포기되지 않았고, 원래 팀의 다양한 파벌은 계속해서 무브를 탐구하고 개발하여 무브 쌍둥이로 알려진 수이와 앱토스, 그리고 무브에서 영감을 받은 러스트 블록체인인 리네라와 최근에 추진된 무브와 같은 새로운 프로젝트를 만들었습니다.

세계 최초의 무브는 세계 최초의 블록체인입니다.

그렇다면 어떻게 반 토막 난 프로젝트가 이렇게 오래도록 남을 수 있었을까요?

최고 수준의 Web2가 블록체인용으로 개발한 프로그래밍 언어인 Move는 기존 블록체인 프로그래밍 언어, 특히 솔리디티의 성능과 보안 문제를 염두에 두고 설계한 매우 복잡한 언어입니다. 자산 관리와 접근 제어에 특화된 타입 시스템을 만드는 것이 목표입니다. 이 언어의 강점을 세 가지로 요약하면 다음과 같습니다.

- 보안: Move 언어의 첫 번째 설계 원칙은 보안입니다. 정적 유형 검사 및 리소스 관리를 사용하여 오버플로 오류 및 재진입 공격과 같은 일반적인 보안 취약성을 방지합니다. 다른 언어 가상 머신과 비교했을 때 Move는 아래 Nansen 비교 차트에서 볼 수 있듯이 다양한 보안 기능을 지원합니다.

< /p>

- 구성 가능성: Move는 모듈성과 구성 가능성을 지원하여 개발자가 다양한 스마트 컨트랙트를 쉽게 만들고 결합하여 더 복잡한 애플리케이션을 구축할 수 있습니다.

- 성능:

Move 언어의 가상 머신은 스마트 컨트랙트를 효율적으로 실행할 수 있도록 최적화(병렬 처리, 메모리 관리, 컴파일러 최적화 지원)되어 있어 트랜잭션 속도와 처리량이 증가합니다.

모듈형 EVM 블록체인이 넘쳐나는 시장에서 무브는 대담한 실험입니다. 위의 아이디어는 다른 블록체인 프로젝트에 대한 설명에서 익숙해 보일 수 있지만, 이러한 기능의 실질적인 이점을 충분히 이해하려면 직접 경험해 보시기를 적극 권장합니다.

2. 수이

2.1 아키텍처

제미니의 하나인 수이는 출시 이후 특히 에어드랍 및 토큰 분배 방식과 관련하여 비판을 받아왔던 것이 사실입니다. 그러나 이러한 문제를 제쳐두고 프로젝트 자체에 집중하면, 수이는 특히 게임과 관련하여 성능과 사용자 경험 측면에서 모두 뛰어난 것으로 입증되었습니다. 이러한 성공의 대부분은 주류 채택을 위해 개선된 혁신적인 아키텍처에 기인합니다. 다음은 Sui의 아키텍처 혁신에 대한 간략한 개요입니다.

• 객체 스토리지 모델: 이 구성 요소는 Sui가 개선한 Move의 핵심입니다. 객체 스토리지 모델은 데이터를 각각 고유 식별자를 가진 개별 객체로 취급합니다. 기존 데이터베이스 시스템과 달리 객체 스토리지 모델은 고정된 데이터 구조가 없으며 텍스트, 이미지, 동영상, 오디오 등 다양한 데이터 유형을 저장할 수 있습니다. 이 모델은 병렬 실행과 수평 확장(노드를 추가하여 저장 용량을 확장)을 허용하며, Sui는 이 모델을 중심으로 설계되었습니다.

• 인과 관계 순서: 트랜잭션이 인과 관계에 따라 동일한 순서로 실행되도록 하여 데이터 충돌과 불일치를 방지합니다. 이 기능을 통해 Sui는 데이터 일관성을 유지하면서 많은 수의 동시 트랜잭션을 처리할 수 있습니다.

• 나르할과 불샤크 합의 엔진: Sui는 합의 엔진으로 나르할과 불샤크를 사용합니다. 나르할은 트랜잭션 순서 지정과 유효성 검증을 담당합니다. 로컬 트랜잭션 풀을 유지하고, 인과관계에 따라 트랜잭션 순서를 정하고, 모든 노드가 동일한 유효한 트랜잭션 순서를 갖도록 브로드캐스팅하는 방식으로 작동합니다. 불샤크는 Narwhal로부터 정렬된 트랜잭션 목록을 받아 목록에 투표하고 비잔틴 장애 허용(BFT) 합의를 사용하여 모든 노드가 거래 순서에 동의하도록 보장합니다.

• Sui Move: Sui는 NFT 지원, 자산 관리, 데이터 저장소 등 새로운 기능을 추가하여 Move 언어를 확장합니다.

• Sui 프레임워크: Sui는 개발자가 애플리케이션을 빠르게 구축하고 배포하는 데 도움이 되는 포괄적인 프레임워크를 제공합니다. 이 프레임워크에는 수이 월렛, 수이 SDK, 수이 CLI와 같은 도구와 라이브러리가 포함됩니다.

수이의 아키텍처는 빠른 속도, 낮은 오버헤드, 보안을 유지하면서 많은 수의 동시 트랜잭션을 처리할 수 있도록 설계되었습니다. 또한 수이 무브 언어와 수이 프레임워크는 개발자에게 안전하고 확장 가능하며 사용자 친화적인 애플리케이션을 구축할 수 있는 강력한 도구를 제공합니다.

2.2 합의

수이 블록체인은 짧은 지연 시간과 높은 처리량을 최적화하도록 설계된 비잔틴 장애 허용(BFT) 기반 합의 메커니즘인 미스티세티(Mysticeti)라는 합의 메커니즘을 사용합니다.

미스티세티는 여러 검증자가 동시에 블록을 제안할 수 있어 네트워크 대역폭을 극대화하고 검열에 저항할 수 있습니다. 또한, 이 프로토콜은 최소한의 이론적 요건을 충족하고 pBFT를 병렬화하는 방향성 비순환 그래프(DAG)에서 블록을 제출하는 데 단 세 번의 메시징 라운드만 필요합니다. 커밋 규칙은 병렬 투표와 블록 리더 인증을 허용하여 중간값과 꼬리값 지연 시간을 더욱 줄여줍니다. 또한 커밋 지연 시간을 크게 늘리지 않고 사용할 수 없는 리더를 허용합니다.

수이 메인 네트워크 출시에 앞서 미스틱티는 테스트 네트워크에서 3개월간 테스트를 진행했으며, 지연 시간이 80% 감소하는 등 상당한 성과를 거두었습니다. 이제 수이 네트워크는 초당 수만 건의 트랜잭션을 1초 미만의 엔드투엔드 지연 시간으로 처리할 수 있습니다.

수이 블록체인은 위임지분증명(DPoS)으로 알려진 특정 유형의 지분 증명 합의를 채택하고 있습니다. Sui는 일각고래와 불샤크 합의 엔진을 사용하여 공유 객체와 관련된 복잡한 트랜잭션이 발생할 때 순위를 매깁니다. 블록체인에서 사용되는 다른 BFT 합의 메커니즘과 비교할 때, Sui의 합의는 다음과 같은 장점과 단점이 있습니다:

장점:

• 낮은 지연시간과 높은 처리량: 미스틱티 프로토콜은 블록을 병렬로 제안하고 메시징 프로세스를 최적화하여 합의 지연 시간을 크게 줄이고 네트워크 처리량을 증가시킵니다. 이를 통해 수이 블록체인은 1초 미만의 엔드투엔드 지연 시간으로 초당 수만 건의 트랜잭션을 처리할 수 있습니다.

• 검열에 대한 저항성: 미스틱티는 여러 검증자가 동시에 블록을 제안할 수 있도록 하여 네트워크의 검열에 대한 저항성을 강화합니다.

• 사용할 수 없는 리더에 대한 허용 범위: 커밋 규칙은 커밋 지연 시간을 크게 늘리지 않고도 사용 불가능한 리더에 대한 허용 범위(리더 노드가 실패하면 시스템이 자동으로 새 리더를 선출)를 허용합니다.

단점:

• 복잡성: 미스틱티 프로토콜의 설계는 비교적 복잡하며, 그 작동을 완전히 이해하려면 더 깊은 기술적 이해가 필요합니다. 더 깊은 기술적 이해가 필요합니다.

• 보안: 테스트 네트워크에서 Mysticeti 프로토콜의 성능이 우수하지만, 실제 애플리케이션에서 보안을 더 검증할 필요가 있습니다.

• 확장성: 향후 네트워크 규모와 거래량 증가에 적응할 수 있는지 확인하기 위해 Mysticeti 프로토콜의 확장성을 더 관찰해야 합니다.

2.3 계정 추상화

수이의 계정 추상화 모델은 사용자가 보다 간단하고 안전한 방식으로 계정과 트랜잭션을 관리할 수 있도록 하는 메커니즘입니다. 이는 기본 블록체인 프로토콜에서 계정 및 트랜잭션 로직을 추상화하여 더 높은 수준의 계정 관리와 트랜잭션 처리를 가능하게 합니다.

수이의 계정 추상화 모델에서 계정은 더 이상 단순한 공개-개인 키 쌍이 아니라 더 풍부한 속성과 동작을 가진 객체입니다. 각 계정에는 계정의 공개 키 및 개인 키 쌍과 연결된 계정 ID라는 고유 식별자가 있습니다.

Sui의 계정 추상화 모델의 주요 구성 요소는 다음과 같습니다.

1. 계정 개체: Sui에서 계정의 기본 단위입니다. 각 계정 개체에는 고유한 계정 ID가 있으며 계정의 속성 및 동작을 포함합니다.

2, 계정 데이터(계정 데이터): 계정 ID, 공개 키, 개인 키 쌍 및 기타 계정에 대한 기본 정보를 포함한 계정 개체의 핵심 구성 요소입니다.

3, 트랜잭션 컨텍스트: 수이에서 트랜잭션의 기본 단위입니다. 여기에는 트랜잭션 ID, 계정 ID, 트랜잭션 데이터 등 트랜잭션 관련 정보가 포함됩니다.

4, 계정 로직: 계정이 트랜잭션을 처리하고 상태를 관리하는 방법을 정의하는 동작과 규칙의 모음입니다.

Sui의 계정 추상화 모델은 다음 단계를 통해 트랜잭션을 처리합니다.

1. 트랜잭션 생성: 사용자가 트랜잭션을 생성하여 Sui 네트워크에 보냅니다.

2. 트랜잭션 유효성 검사: Sui 네트워크는 트랜잭션의 유효성과 무결성을 검증합니다.

3. 계정 조회: Sui 네트워크는 트랜잭션의 계정 ID를 기반으로 해당 계정 개체를 조회합니다.

4. 계정 로직 실행: Sui 네트워크는 계정 로직을 실행하여 트랜잭션을 처리하고 계정 상태를 업데이트합니다.

5. 트랜잭션 확인:

요약하면, Sui의 계정 추상화 모델은 계정 관리와 거래 처리를 간소화하고 애플리케이션을 보다 사용자 친화적으로 만드는 혁신적인 메커니즘입니다.

2.4 게임

블록체인이 두각을 나타내려면 탄탄한 기반이 있어야 합니다. 앞서 무브가 대담한 시도였다고 말씀드린 이유는 두 가지입니다.

첫째, 모듈성이라는 개념이 지배하는 시대에 무브 제미니와 같은 네이티브 무브 기반 블록체인은 레이어 1의 마지막 시도 중 하나였으며, 근본적으로 트렌드를 거스르는 것이었습니다. 그러나 최근 다양한 이기종 체인의 등장은 모듈성이 유일한 해답이 아니라는 것을 증명할 수 있습니다.

둘째, 새로운 프로그래밍 언어로 블록체인을 재구축하기로 한 결정은 오늘날 모바일 시장에서 iOS와 안드로이드와 경쟁할 새로운 운영체제를 만들려는 시도와 같으며, 이는 어려운 도전이 될 수밖에 없는 운명입니다. 향후 몇 년 안에 무브 기반 블록체인이 솔라나만큼 큰 규모로 성장할 수 있을지는 그들이 어떤 길을 선택하느냐에 따라 크게 달라질 것입니다. 수이에게 그 도전에 대한 답은 게임입니다.

게임은 웹3.0의 주요 진입점 중 하나이지만, 대부분의 블록체인은 게임을 잘 지원하지 않습니다. 블록체인은 주로 금융을 염두에 두고 설계되었으며, 탈중앙화된 아키텍처는 본질적으로 성능이 낮고 게임에는 적합하지 않기 때문입니다. 하지만 수이는 다릅니다. 이 모델은 DeFi 애플리케이션과 게임을 포함한 비금융 애플리케이션에 매우 적합합니다. 앞서 언급했듯이 Sui에서는 모든 것이 하나의 객체로 취급됩니다. 복잡한 에셋이 계층화된 게임이나 애플리케이션에서 Sui는 하나의 에셋이 다른 에셋을 소유할 수 있도록 허용합니다(에셋이 에셋을 소유할 수 있음). 예를 들어, 영웅 롤플레잉 게임에서 영웅은 해당 캐릭터에 속한 다른 디지털 자산이 포함된 인벤토리를 소유할 수 있습니다. 수이는 다른 블록체인이 할 수 없는 방식으로 이러한 데이터 계층 구조를 정확하게 모델링하여 개발자가 체인의 근본적인 한계를 극복할 필요 없이 앱을 구축할 수 있도록 합니다.

또한 수이는 지난해 국내 4대 게임 대기업 중 3개사(넷마블, NHN, 엔씨소프트)와 파트너십을 맺은 데 이어 올해는 틱톡과 블록체인 게임 및 소셜파이 프로젝트 개발을 위한 파트너십을 맺는 등 전통적인 웹2.0 대기업들과도 활발히 협력하고 있습니다. h2>

앱토스는 무브 언어 기반의 또 다른 레이어 1 블록체인으로, 고성능의 확장 가능한 웹3 인프라 구축에 중점을 두고 있습니다. 아키텍처 설계는 Sui와 많은 유사점을 공유하지만, 몇 가지 고유한 특징도 보여줍니다.

3.1 아키텍처

• 모듈식 설계: Aptos는 개발자가 여러 모듈을 독립적으로 개발하고 업그레이드할 수 있는 모듈식 아키텍처를 채택하여 개발 속도와 유연성을 높였습니다.

• 병렬 실행 엔진(Block-STM): 데이터 종속성을 미리 선언해야 하는 다른 블록체인과 달리 앱토스의 병렬 실행 엔진은 데이터의 위치를 미리 알 필요 없이 트랜잭션을 병렬로 처리할 수 있어 처리량을 높이고 지연 시간을 줄일 수 있습니다.

• 파이프라인 트랜잭션 처리: 앱토스는 트랜잭션 처리를 전파, 메타데이터 정렬, 대량 저장과 같은 여러 단계로 나눕니다. 이러한 단계는 처리량을 극대화하고 지연 시간을 최소화하기 위해 파이프라인 방식을 사용하여 병렬로 실행됩니다.

• 무브 프로그래밍 언어: 앱토스는 무브 프로그래밍 언어를 사용합니다. Sui의 혁신과 달리 Aptos는 언어 표준화, 더 강력한 기능 지원 및 사용자 지정 도입 등 언어 개선에 중점을 두고 있습니다.

• 유연한 상태 동기화: 노드가 전체 히스토리 동기화 또는 최신 상태 동기화 등 다양한 상태 동기화 전략을 선택할 수 있어 노드의 유연성이 향상됩니다.

• AptosBFT 합의 메커니즘: AptosBFT는 인증자 간의 통신과 동기화를 최적화하여 처리량을 개선하고 지연 시간을 줄이기 위해 Aptos에서 사용하는 비잔틴 장애 허용(BFT) 합의 메커니즘입니다. Sui에 비해 효율성과 충돌 복구가 일부 개선된 DiemBFT의 개선된 버전으로 볼 수 있으므로 여기서는 간략하게만 언급하겠습니다.

Aptos의 아키텍처는 빠른 속도, 낮은 오버헤드 및 보안을 유지하면서 많은 수의 동시 트랜잭션을 처리할 수 있도록 설계되었습니다. 또한 Move 언어와 앱토스 프레임워크는 개발자에게 안전하고 확장 가능하며 사용자 친화적인 애플리케이션을 구축할 수 있는 강력한 도구를 제공합니다.

3.2 Block-STM

여기서는 앱토스의 핵심 혁신인 병렬 실행 엔진 Block-STM에 대해 자세히 설명합니다.

블록-STM의 핵심 원리:

• 프리셋 순차적 실행: Block-STM은 블록 내에서 미리 설정된 트랜잭션 순서에 의존하며, 최종 상태의 일관성을 보장하기 위해 모든 트랜잭션은 이를 따라야 합니다.

• 낙관적 동시성 제어: Block-STM은 충돌이 발생하지 않는다고 가정하고 트랜잭션을 최적으로 병렬로 실행합니다. 낙관적 동시성 제어는 충돌이 드물다는 가정을 바탕으로 트랜잭션이 잠금 없이 데이터에 접근하고 수정할 수 있도록 합니다. 여러 트랜잭션이 동시에 충돌할 가능성이 낮다고 가정하여 수정을 계속할 수 있고 충돌이 있는 경우 최종 커밋 전에 확인할 수 있습니다.

• 다중 버전 데이터 구조: 최적의 동시성 제어를 지원하기 위해 Block-STM은 다중 버전 데이터 구조를 사용해 데이터를 저장합니다. 각 쓰기 작업은 데이터의 새 버전을 생성하고, 읽기 작업은 해당 데이터 버전에 액세스합니다.

• 검증 및 재시도: 트랜잭션을 실행한 후 Block-STM은 읽은 데이터 버전이 여전히 유효한지 확인합니다. 유효성 검사에 실패하여 충돌이 발생하면 트랜잭션은 유효하지 않은 것으로 표시되고 다시 실행됩니다.

• 협업 스케줄링: Block-STM은 협업 스케줄러를 사용해 스레드 간 실행 및 유효성 검사 작업을 조정하여 병렬성을 극대화합니다.

블록-STM의 워크플로:

• 트랜잭션 그룹화: 블록 내의 트랜잭션이 그룹화되어 병렬 실행을 위해 서로 다른 스레드에 할당됩니다.

• 최적 실행: 각 스레드는 자신에게 할당된 트랜잭션을 최적으로 실행하고 각 트랜잭션에 대한 읽기 및 쓰기 집합을 기록합니다.

• 검증: 스레드가 트랜잭션 실행을 완료하면 읽기 세트의 데이터 버전이 여전히 유효한지 확인합니다.

• 재검증: 유효성 검사에 실패하여 충돌이 발생하면 트랜잭션이 유효하지 않은 것으로 표시되고 다시 실행됩니다.

• Submit: 모든 트랜잭션의 유효성이 검사되면 결과가 블록체인 상태에 기록되어 트랜잭션 제출이 완료됩니다.

블록스톰의 장점:

• 높은 처리량: 최적의 동시성 제어와 협력적 스케줄링을 활용하여 블록스톰은 멀티코어 프로세서의 성능을 활용하여 높은 처리량을 달성할 수 있습니다.

• 낮은 지연 시간: Block-STM은 트랜잭션을 병렬로 실행할 수 있으므로 트랜잭션 확인 시간을 크게 단축합니다.

• 보안: Block-STM의 사전 정의된 순차적 실행 및 검증 메커니즘은 최종 상태의 일관성과 보안을 보장합니다.

요약하면, Block-STM은 최적의 동시성 제어, 다중 버전 데이터 구조, 협업 스케줄링 기술을 결합하여 블록체인 처리량을 극대화하는 동시에 보안과 정확성을 보장하는 효율적인 병렬 트랜잭션 실행 엔진입니다.

3.3 계정 추상화

수이의 계정 추상화에 대한 보다 직접적인 접근 방식과 달리 앱토스는 보다 제한된 수준의 추상화를 지원하며 사전 정의된 특정 표준이 부족합니다. 앱토스의 계정 추상화 기능은 주로 다음과 같은 영역에 있습니다.

• 모듈형 계정 관리: 개발자가 다양한 계정 유형과 기능을 구현하는 사용자 정의 모듈을 만들 수 있는 Move 모듈을 사용하여 계정을 정의하고 관리할 수 있습니다.

• 유연한 키 관리: 사용자가 하나의 키를 트랜잭션 서명에 사용하고 다른 키를 계정 관리에 사용하는 등 계정에서 서로 다른 작업을 위해 서로 다른 키를 사용할 수 있습니다.

• 프로그래밍 가능한 트랜잭션 유효성 검사: 개발자는 다양한 애플리케이션 시나리오에 맞게 이동 모듈 내에서 다중 서명 및 지출 한도와 같은 사용자 지정 트랜잭션 유효성 검사 로직을 정의할 수 있습니다.

3.4 마이크로소프트와의 협업

게임 개발에 더 중점을 둔 수이와 달리 앱토스는 구체적인 개발 목표가 없으며, 대신 가장 생산 친화적인 블록체인을 표방하고 있습니다. 앱토스가 마이크로소프트의 AI 기술을 블록체인에 접목하기 위해 마이크로소프트와 협력하고 있다는 점은 주목할 만합니다. 두 회사의 첫 번째 협업 제품인 앱토스 네트워크에 구축된 생성형 AI 비서인 앱토스 어시스턴트가 공식 웹사이트에 출시되었습니다. 앞으로 몇 달 안에 더 많은 AI 제품이 출시될 예정입니다.

4. 무브 생태계

수이는 최근 좋은 성과를 거두고 있지만, 무브 생태계는 EVM 체인이나 솔라나, 톤과 같은 이기종 체인에 비해 아직 성숙할 시간이 필요합니다. 수이와 앱토스의 스타 효과와 지속적인 기술 혁신에도 불구하고 무브 생태계의 전반적인 규모와 활동은 여전히 성숙한 생태계에 비해 뒤쳐져 있으며 개발자 수, 애플리케이션 유형, 사용자 규모 등이 안정화되기까지 시간이 걸립니다. 외부 협력부터 운영까지 두 프로젝트 모두 웹2.0 정신이 강하고 웹3.0 유전자가 일부 부족하며, 업계에서는 각종 협력 프로젝트가 상대적으로 냉담합니다.

그러나 무브 생태계의 잠재력을 고려할 때 아직 가야 할 길이 많이 남아있습니다. 일부 개발자들은 이미 무브의 미래 가치에 주목하고 있습니다. 소개에서 언급했듯이 이미 이더 레이어 2 생태계에 무브를 도입하기 위한 프로젝트가 진행되고 있으며, 앞으로 무브 생태계는 이더 레이어 2 공간에서 빛을 발할 가능성이 높습니다. 현재로서는 어떻게 하면 무브 생태계를 주목받을 수 있을지에 초점을 맞춰야 합니다.