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

저자: YBB Capital 연구원; Zeke

서문

최근 시장 점점 더 냉랭해지면서 많은 'OG'의 서클도 산업의 존재 의의가 흔들리기 시작했습니다. 제 개인적인 감정을 몇 가지 말하자면, 저는 과거에 많은 위대한 비전이 "위조"된 이유는 처음부터 이러한 비전이 논리적으로 자기 일관성이 없기 때문이라고 항상 느꼈습니다. 비금융 애플리케이션을 제외한 디앱들은 탈중앙화의 가치를 강조함으로써 제품 자체가 좋지 않다는 사실을 항상 숨기려고 노력해왔습니다. 하지만 진실은 구글, 트위터, 유튜브는 믿지 말고 대신 다중 서명 지갑과 독립형 서버가 충분히 안전하다고 믿으라고 말하는 것입니다. 많은 비전이 위조된 것이 아니라 실제로 검증되지 않았기 때문입니다. 저는 대부분의 비전이 그렇게 거창하지 않더라도 의미가 있으며, 이를 뒷받침할 수 있는 충분한 기반이 필요할 뿐이라고 계속 믿습니다. 궁극적으로 탈중앙화와 웹2.0에 버금가는 좋은 경험은 적어도 하나 정도는 제공할 수 있을 것입니다. 이전과 마찬가지로 <톤>과 <솔라나>도 경멸을 받았지만 이제는 성능의 여러 측면에서 점차 빅 브라더를 따라잡고 있으며, 퍼블릭 체인의 적용이 혁신을 필요로 하는 상황에서 각 사이클에서 업계 발전을 촉진할 것입니다. 그래서 오늘은 오랫동안 과소평가되어 온 퍼블릭 체인의 한 유형인 무브 시스템에 대해 알아보도록 하겠습니다.

I. 무브

무브 프로그래밍 언어는 원래 메타의 기존 프로젝트인 디엠(초기에는 리브라로 알려짐)에서 탄생한 것으로, 메타버스 비전의 일환으로 보다 안정적이고 규제된 스테이블코인을 만들기 위해 시작되었습니다. 코인을 메타버스 비전의 기반으로 삼았습니다. 그러나 모든 예상과 달리 이 프로젝트는 전 세계 규제 당국의 강력한 반대와 지속적인 압력에 부딪혔습니다. 규제 당국은 디엠의 규모와 페이스북의 방대한 사용자 기반이 금융 안정성, 통화 정책, 데이터 프라이버시에 위협이 될 수 있다고 우려했고, 바이든 행정부의 압력으로 인해 결국 메타는 디엠 프로젝트를 포기해야 했습니다.

그러나 다행히도 Diem의 핵심은 포기되지 않았고, 원래 팀에서 분리된 여러 파벌은 계속해서 <무브>의 발굴과 개발을 고수하여 오늘날 우리가 알고 있는 <무브>로 발전했습니다. 또한, 최근 활발하게 홍보되고 있는 <무브먼트>와 다른 퍼블릭 체인 프로젝트인 <리네라>(무브먼트의 <러스트> 퍼블릭 체인을 기반으로 함)가 아직 초기 단계에 있습니다.

그렇다면 왜 허리 잘린 프로젝트가 이렇게 큰 뒷맛을 남길 수 있을까요? Move는 답안지의 블록체인 프로그래밍 언어를 위한 웹2.0 헤드 팩토리로서, 그 장점은 말할 필요도 없이 기존(특히 솔리디티) 중심의 블록체인 프로그래밍 언어 설계에 있습니다. 성능과 보안 문제를 많이 반영하여 자산 관리 및 접근 제어를 위한 맞춤형 형태의 시스템을 구현하는 것이 설계 목표입니다. 개인적으로 이를 세 가지로 간단히 요약하면 다음과 같습니다.

• 보안: Move 언어는 보안을 염두에 두고 설계되었으며 정적 타입 검사 및 리소스 관리를 사용하여 오버플로 버그와 재진입 공격과 같은 일반적인 보안 허점을 방지합니다. 재진입 공격과 같은 일반적인 보안 허점을 방지합니다. Nansen의 다음 비교 그래픽에서 볼 수 있듯이 Move는 다른 언어 VM에 비해 다양한 보안 기능을 지원합니다.

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

• 성능: Move Language의 가상 머신은 스마트 컨트랙트를 효율적으로 실행하도록 최적화(병렬 처리, 메모리 관리, 컴파일러 최적화)되어 있어 트랜잭션 속도가 빨라지고 처리량이 증가합니다.

현재 시장에 넘쳐나는 모듈형 퍼블릭 체인에서 무브는 일종의 용감한 시도로 평가받습니다. 나는 세 가지 요점의 매력을 말했고, 많은 퍼블릭 체인 프로젝트의 소개에서 비슷한 것을 보았을 수도 있습니다, 나는이 단어를 시각화하기 위해 개인적으로 경험하는 것이 좋습니다.

수이

2.1 아키텍처

쌍둥이 중 하나로서 쌍둥이 중 하나인 수이는 출시 초기에 에어드랍 문제와 토큰 발행 방식에 대한 비판을 받았습니다. 그러나 이러한 문제를 제쳐두고 프로젝트 자체는 적어도 성능과 경험 측면에서 충분히 좋으며 게임에서 성능은 매우 우수하여 개선 된 아키텍처 설계의 주류 채택을 위해 분리 할 수 없습니다. 여기서는 먼저 아키텍처의 혁신에 대해 간략하게 설명합니다.

1. 객체 스토리지 모델: 구성 요소는

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

3. Narwhal 및 Bullshark 합의 엔진: Sui는 합의 엔진으로 Narwhal과 Bullshark를 사용하며, Narwhal은 거래 주문과 유효성 검사를 담당합니다. 운영 원칙은 모든 노드가 동일하고 유효한 거래 순서를 갖도록 하기 위해 정렬 및 브로드캐스팅을 위한 거래 인과 관계에 따라 로컬 트랜잭션 풀을 유지하는 것입니다. 불샤크는 비잔틴 장애 허용 합의를 사용하여 모든 노드가 거래 목록에 동의하는지 확인하기 위해 일각고래의 정렬된 거래 목록을 수신하고 투표합니다.

4. 수이 이동: 수이는 NFT 지원, 자산 관리, 데이터 저장 등의 새로운 기능으로 이동 언어를 확장합니다.

5. Sui 프레임워크: Sui는 개발자가 애플리케이션을 빠르게 빌드하고 배포할 수 있는 완벽한 프레임워크를 제공합니다. 이 프레임워크에는 수이 월렛, 수이 SDK, 수이 CLI와 같은 도구와 라이브러리가 포함되어 있습니다.

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

2.2 합의

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

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

미스티세티는 메인 Sui 네트워크에 출시되기 전 3개월 동안 테스트 네트워크에서 운영되었으며, 지연 시간이 80% 단축되는 등 주목할 만한 성과를 거두었습니다. 이제 Sui 네트워크는 초당 수만 건의 트랜잭션을 1초 미만의 엔드투엔드 지연 시간으로 처리할 수 있습니다.

수이 블록체인은 또한 지분 증명(DPoS)이라는 특정 유형의 지분 증명 합의를 사용합니다. 공유 객체와 관련된 트랜잭션(복합 트랜잭션이라고 함)이 발생하면 Sui는 위에서 설명한 대로 일각고래 및 불샤크 합의 엔진을 사용하여 트랜잭션을 주문합니다. 다른 합의 메커니즘 퍼블릭 체인과 비교했을 때, Sui의 장점과 단점은 다음과 같이 여섯 가지로 요약할 수 있습니다.

장점:

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

• 검토 저항: Mysticeti 프로토콜은 여러 검증자가 블록을 병렬로 제안할 수 있도록 하여 네트워크의 검토 저항을 개선합니다.

• 검토 저항: 여러 검증자가 블록을 병렬로 제안할 수 있습니다. style="text-align: left;">사용할 수 없는 리더 허용: 커밋 규칙은 커밋 대기 시간을 크게 늘리지 않고도 사용 불가능한 리더(리더 노드가 실패하면 시스템이 자동으로 새 리더를 선출하여 이어받음)에 대한 허용을 허용합니다.

단점:

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

• 보안: Mysticeti 프로토콜은 테스트 네트워크에서 잘 작동하지만, 실제 애플리케이션에서 보안을 더 검증해야 합니다.

• 보안: Mysticeti 프로토콜은 테스트 네트워크에서 잘 작동하지만 실제 애플리케이션에서는 여전히 보안이 더 검증되어야 합니다.

• 확장성: 향후 네트워크 규모와 거래량의 증가를 수용할 수 있는지 확인하기 위해 Mysticeti 프로토콜의 확장성은 아직 지켜봐야 합니다.

2.3 계정 추상화

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

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

Sui의 추상 계정 모델에는 다음과 같은 주요 구성 요소가 포함됩니다.

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

2. 계정 데이터: 계정 데이터는 계정 개체의 핵심 구성 요소입니다. 여기에는 계정 ID, 공개 및 개인 키 쌍과 같은 계정에 대한 기본 정보가 포함됩니다.

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

4. Account Logic(계정 논리): 계정 로직은 Sui 계정의 동작 및 규칙 모음입니다. 동작 및 규칙의 모음입니다. 계정이 트랜잭션을 처리하고 상태를 관리하는 방법을 정의합니다.

Sui의 추상 계정 모델은 다음 단계로 트랜잭션을 처리합니다:

2. 계정 로직: 계정 로직은 계정의 트랜잭션 처리 및 상태 관리 방법을 정의하는 행동 및 규칙의 모음입니다. 왼쪽;">트랜잭션 생성: 사용자가 트랜잭션을 생성하여 수이 네트워크에 전송합니다.

3. 트랜잭션 유효성 검사: 수이 네트워크가 트랜잭션의 유효성과 무결성을 검증합니다.

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

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

6. 거래 확인: 네트워크가 거래 결과를 확인하여 블록체인에 기록합니다.

요약하자면, Sui의 추상 계정 모델은 계정 관리와 거래 처리를 간소화하여 앱을 더욱 앱답게 만드는 혁신적인 메커니즘입니다.

2.4 게임

퍼블릭 체인이 돋보일 수 있느냐 없느냐는 우선 강수량과 축적이어야 하는데, 위 기사에서 <무브>를 용감한 시도라고 하는 이유는 두 가지가 있습니다: 첫째, 네이티브 <이동> 부서의 시대의 일반화의 모듈 식 개념 (즉, <이동> 쌍둥이 자리)은 기본적으로 카운터 트렌드에 속하는 <층 1>에 대한 마지막 시도로 간주되지만 최근 여러 이기종 체인의 부상은 아마도 대답의 모듈성을 증명하는 유일한 것이 아닙니다. 두 번째는 퍼블릭 체인을 리메이크하고 새로운 프로그래밍 언어를 채택하는 것입니다. 이 움직임은 현재 휴대 전화 시장에서 시스템을 리메이크하여 iOS 및 Android에 도전하고 싶어하는 것처럼 상상할 수 있으며, 미래로가는 길은 가시로 가득 할 것입니다. 향후 몇 년 안에 시스템이 <솔라나>처럼 빛나고 뜨겁고 자신 만의 것이 될 수 있는지 여부를 이동하십시오. 개발 방향이 특히 중요할 것입니다.

게임은 Web3의 중요한 입구 중 하나이지만 게임에 대한 대다수의 퍼블릭 체인 지원은 좋지 않은데, 이는 탄생 이후 블록체인이 기본적으로 금융 중심으로 설계되었기 때문이기도 하지만 낮은 성능의 탈중앙화 구조로 인해 본질적으로 게임에 적합하지 않기 때문이기도 합니다. 그러나 수이는 이와는 달리 탈중앙화 금융 애플리케이션과 비금융 애플리케이션 및 게임 모두에 적합한 모델입니다. 위에서 언급했듯이 수이에서는 모든 것이 객체입니다. 게임이나 앱에는 계층적 관계를 가진 복잡한 자산이 있으며, Sui에서는 객체가 다른 객체를 소유할 수 있고, 자산이 다른 자산을 소유할 수 있습니다. 예를 들어 영웅 캐릭터가 있는 게임을 플레이하고 있는데, 그 영웅 캐릭터에 인벤토리가 있고 그 캐릭터에 속한 다른 디지털 자산이 있다고 가정해 보겠습니다. sui는 다른 블록체인에서는 불가능한 방식으로 이러한 데이터 계층구조를 정확하게 모델링할 수 있습니다. 그 결과 개발자는 체인의 근본적인 한계를 해결하지 않고도 자신이 만들고자 하는 앱을 표현할 수 있는 기회를 얻게 됩니다.

이 외에도 수이는 지난해 국내 4대 게임사 중 3개사(넷마블, NHN, 엔씨소프트)와의 파트너십을 시작으로 전통적인 웹2.0 대기업과의 파트너십을 활발히 추진하고 있습니다. 올해에는 '틱톡'과 '소셜파이' 프로젝트의 공동 개발 연계를 시작으로 전통의 강자들을 웹2.0으로 끌어들이고 있습니다.

셋째, 앱토스

무브 언어 기반의 또 다른 레이어 1 블록체인인 앱토스 역시 고성능의 확장 가능한 웹3 인프라를 구축하는 데 전념하고 있습니다. 이 아키텍처는 Sui와 많은 유사점을 공유하지만 몇 가지 고유한 특징도 있습니다.

3.1 아키텍처

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

2.

2. Block-STM: 사전 선언된 데이터 종속성이 필요한 다른 블록체인과 달리 앱토스의 병렬 실행 엔진은 데이터 위치에 대한 사전 지식 없이 트랜잭션을 병렬로 처리하여 처리량을 높이고 지연 시간을 낮춥니다.

3. -파이프라인 트랜잭션 처리: 앱토스는 트랜잭션 처리를 전파, 메타데이터 정렬, 배치 저장 등과 같은 여러 단계로 나누고 이러한 단계를 파이프라인 방식으로 병렬로 실행하여 처리량을 극대화하고 지연 시간을 줄입니다.

4. 프로그래밍 언어: 앱토스는 Move 프로그래밍 언어를 사용하며, 수이에서 도입한 혁신에 비해 앱토스는 이를 개선하기 위해 더 많은 노력을 기울였습니다. 예를 들어, 언어 표준화, 더 강력한 기능 지원, 사용자 정의 기능 도입 등이 있습니다.

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

6. AptosBFT 합의 메커니즘: AptosBFT는 인증자 간의 통신과 동기화를 최적화하여 처리량을 개선하고 지연 시간을 줄이기 위해 Aptos에서 사용하는 비잔틴 내결함성 합의 메커니즘입니다. Sui와 비교했을 때 효율성과 충돌 복구 저항성에서 약간의 개선이 이루어졌다고 볼 수 있으며, 여기서는 간략한 설명만 할 수 있습니다.

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

3.2 Block-STM

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

블록-STM의 핵심 원리:

1. 사전 설정된 주문 실행: 블록-STM은 다음을 기반으로 합니다. Block-STM은 최종 상태의 일관성을 보장하기 위해 모든 트랜잭션이 따라야 하는 블록의 사전 정의된 트랜잭션 순서에 의존합니다.

2. 낙관적 동시성 제어: Block-STM은 충돌이 발생하지 않는다고 가정하여 트랜잭션을 병렬로 최적으로 실행합니다. 낙관적 동시성 제어는 충돌이 드물다는 가정을 기반으로 하며, 트랜잭션이 잠금 없이 데이터에 액세스하고 수정할 수 있도록 허용합니다. 여러 트랜잭션이 동시에 충돌할 확률이 낮다고 가정하기 때문에 먼저 변경하고 최종 커밋 전에 충돌이 발생했는지 확인할 수 있습니다.

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

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

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

블록-STM 워크플로:

1. 트랜잭션 그룹화: 블록의 트랜잭션을 그룹화하여 다른 블록에 할당합니다. 블록의 트랜잭션을 그룹화하고 병렬 실행을 위해 다른 스레드에 할당합니다.

2. 최적 실행: 각 스레드가 할당된 트랜잭션을 최적으로 실행하고 각 트랜잭션의 읽기 및 쓰기 집합을 기록합니다.

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

4. Retry: 검증에 실패하여 충돌이 발생했음을 나타내는 경우 트랜잭션이 유효하지 않은 것으로 표시되고 재실행됩니다.

7. < p style="text-align: 왼쪽;">제출: 모든 트랜잭션의 유효성이 검사되면 그 결과가 블록체인 상태에 기록되어 트랜잭션 제출이 완료됩니다.

Block-STM 장점:

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

• 낮은 지연 시간: 트랜잭션이 병렬로 실행될 수 있으므로 Block-STM은 거래 확인 시간을 획기적으로 줄일 수 있습니다.

• 저지연: Block-STM은 거래 확인에 걸리는 시간을 크게 줄일 수 있습니다.

• 거래가 병렬로 실행될 수 있습니다.

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

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

3.3 추상 계정

수이의 추상 계정과 달리 앱토스가 지원하는 추상화 차원은 조금 더 제한적이며, 특정 사전 정의된 표준이 없기 때문에 추상 계정 기능은 주로 다음과 같은 측면에 반영됩니다.

1. 모듈식 계정 관리: 이동 모듈을 사용하여 계정을 정의하고 관리하면 개발자는 사용자 정의 모듈을 생성하여 다음을 달성할 수 있습니다. 개발자는 사용자 지정 모듈을 만들어 다양한 계정 유형과 기능을 구현할 수 있습니다.

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

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

3.4 Microsoft와의 협업

게임 개발에 더 집중하는 Sui에 비해 Aptos는 구체적인 개발 목표가 없습니다. 라는 슬로건은 블록체인 제작에 가장 적합한 슬로건입니다. 앱토스는 현재 마이크로소프트와 협력하고 있으며, 마이크로소프트의 인공지능 기술을 블록체인에 도입하는 것을 목표로 하고 있다는 점을 언급할 가치가 있습니다. 현재 두 제품 간의 첫 번째 협력 제품인 <앱토스 어시스턴트>가 공식 페이지에 공개되었으며, 이 제품은 <앱토스> 네트워크에 구축된 생성형 인공지능 비서이며, 후속 인공지능 제품은 몇 달 후에 순차적으로 발표될 예정입니다.

넷째, 이동 부서

최근 수이의 성과는 좋았으나 EVM 부서와 비교하면 부진했습니다. 솔라나, 톤 및 기타 이기종 체인.Move의 상승도 약간의 강수량이 필요하며, 현재 쌍둥이 자리의 수이 및 앱토스는 별 후광의 꼭대기에 있지만 기술적 돌파구에서도 있지만 이동 생태의 전체 규모 의 전반적인 규모와 활동은 다른 성숙한 생태계보다 여전히 적습니다. 개발자 수, 애플리케이션 유형, 사용자 규모를 축적하는 데 시간이 필요합니다. 외부 협력에서 운영 관점에 이르기까지 두 사람은 상대적으로 두꺼운 웹2 사고를 가지고 있으며 일부 웹3 유전자가 부족하고 서클의 다양한 협력 프로젝트가 따뜻한 상태였습니다.

그러나 '이동'의 잠재력 측면에서는 여러면에서 깊이 파고들 가치가 있으며, 일부 개발자들은 '이동'의 미래 가치도 주목하고 있습니다. 소개에서 언급했듯이 <이더 레이어 2> 프로젝트에 <이브>가 도입되었으며, <이브> 시스템의 미래도 <이더 레이어 2> 프로젝트에 있을 것이며, 현재 더 많은 작업이 필요한 것은 <이더 레이어 2> 프로젝트에 <이브>를 어떻게 넣을 것인가 하는 것입니다. 부서를 이동하여 싸우는 것입니다.