Move 언어의 혁신과 기회
요약
첫 번째 레벨 제목
솔리디티(Solidity)와 러스트(Rust) 언어에 이어 붕괴된 프로젝트 리브라(Libra)에서 고안된 차세대 프로그래밍 언어인 무브(Move)가 퍼블릭 체인 프로젝트인 앱토스(Aptos)와 수이(Sui)로 인해 다시 주목을 받고 있다. 블록체인의 개발 역사 전반에 걸쳐 신흥 퍼블릭 체인의 각 배치의 부상은 종종 개발 패러다임의 어느 정도 변화를 의미합니다. 무브의 재등장은 새로운 언어의 내러티브가 퍼블릭 체인 경쟁의 새로운 전장이 되고 있음을 암시하는 것으로 보인다.
자산 보안을 보다 잘 실현하기 위해 Move는 언어 설계, 가상 머신 및 검증 도구에 혁신적인 변화를 가져왔습니다: Move는 디지털 자산에 대한 새로운 리소스 유형을 정의하고 리소스가 충족해야 하는 두 가지 기본 속성을 추상화합니다. 강력한 데이터 추상화의 모듈 시스템, 계정의 권한 제어가 실현되고 자산 소유권 이전은 Rust의 소유권 시스템을 계승하여 실현됩니다. 또한 정적 호출, 형식 검증 및 바이트코드 검증기와 같은 메커니즘을 도입하여 디지털 자산의 보안을 여러 가지로 보장합니다.
언어 수용의 관점에서 Move는 개발자에게 매우 친숙합니다.그 목적은 개발자의 보안 임계값을 낮추어 계약 개발자가 비즈니스 논리에 집중하고 시작하기 쉽고 전체 개발자 마이그레이션 비용이 높지 않도록 하는 것입니다. ; 생태학적으로 보면 Move의 실제 적용 시나리오는 아직 초기 단계에 있으며 애플리케이션 생태학은 아직 대규모로 출시되지 않았습니다. 현재 무브가 인큐베이팅한 퍼블릭 체인 프로젝트는 압토스, 수이, 국내 스타코인뿐이다. 향후 Move for 금융의 특성과 트랙의 성숙도 등의 요인으로 인해 DEX, DeFi, Wallet 등의 금융 인프라가 먼저 구현되고 Socialfi, Gamefi와 같은 금융 관련 애플리케이션이 순차적으로 구현될 것입니다.
개요
첫 번째 레벨 제목
최근 퍼블릭 체인 트랙이 극도로 활발해졌습니다. 두 개의 새로운 퍼블릭 체인인 Aptos와 Sui가 시장을 강타하고 약 5억 달러의 자금을 조달하여 업계에서 광범위한 관심을 끌었습니다. 그들이 그렇게 뛰어난 능력을 가진 이유를 말하자면, 대부분의 창립 팀이 없어진 스테이블 코인 프로젝트 Libra(나중에 Diem으로 개명)의 깊은 배경에서 왔다는 사실을 제외하면 Diem의 핵심 유산을 물려받았을 가능성이 더 큽니다. . ——언어를 이동합니다.
지난 몇 년 동안 블록체인 분야의 새로운 퍼블릭 체인의 모든 물결에는 어느 정도의 개발 패러다임 전환이 포함되었습니다. 이제 Move가 이끄는 Diem 퍼블릭 체인은 새로운 프로그래밍 언어의 내러티브가 퍼블릭 체인 경쟁의 전쟁터 중 하나가 되었음을 암시하는 것 같습니다.
첫 번째 레벨 제목
1. 무브가 탄생한 이유
세상에는 이렇게 많은 언어가 있는데 리브라가 무브를 "압도적으로" 디자인한 이유는 무엇일까요? 우리는 Libra의 비전이 수십억 명의 사람들에게 권한을 부여하는 글로벌 통화의 금융 인프라가 되는 것임을 알고 있습니다. 따라서 Move는 자산 보안을 설계 목표의 맨 위에 두어야 합니다. 그러나 과거의 프로그래밍 언어는 이러한 요구 사항을 잘 충족하지 못했습니다.
SlowMist Hacked의 불완전한 통계에 따르면, 2021년에만 블록체인 생태계에서 200건 이상의 공개된 보안 사고가 있을 것이며 손실은 미화 98억 달러를 초과할 것입니다. 그 중 대부분의 보안 문제는 생태학적 DApp 또는 DeFi 프로토콜에서 나타납니다.
일반적인 계약 보안 공격에는 플래시 론, 재진입 공격, 이중 지출 공격, 숫자 오버플로, 트랜잭션 재생, 트랜잭션 영수증 등이 포함됩니다. 그들은 모두 Solidity로 대표되는 이전 세대의 프로그래밍 언어가 언어 기능, 계약 운영 및 가상 머신 설계 측면에서 보안 위험이 다소 있음을 반영합니다.
따라서 Libra는 기존의 스마트 컨트랙트 프로그래밍 언어를 과감히 포기하고 보다 안전한 Move 언어를 개발했습니다.
2. Move는 어떻게 자산 보안을 보장합니까?
자산 보안에서 Move의 성능은 이전 프로그래밍 언어보다 월등합니다.주로 이전 언어의 어깨에 혁신적인 개선이 이루어졌기 때문입니다.이러한 개선은 주로 언어 설계, 가상 머신 및 오프체인 검증 도구의 세 가지 측면에 반영됩니다.
보조 제목
2.1 언어 설계: 디지털 금융을 위해 탄생
무브는 점차 '디지털' 속성을 약화시키고 '자산' 속성을 강조하고 있다. 왜 그런 말을 해? Turing의 완전한 스마트 계약 언어가 과거에 디지털 자산을 어떻게 정의했는지 먼저 살펴보겠습니다.
우리는 이더리움이 거대한 거래 상태 기계인 계정 모델을 사용한다는 것을 알고 있습니다.모든 거래는 이더리움의 세계 상태를 변경하고 거래는 블록으로 패키지됩니다. 따라서 이더리움은 한편으로는 트랜잭션이 블록으로 패키징되어 형성된 원장 체인으로 볼 수 있고, 다른 한편으로는 블록 생성과 함께 하나의 세계 상태에서 다른 세계 상태로의 지속적인 전환으로 볼 수도 있습니다. 상태 기계.
또한 각 계정 정보의 합이 매 순간 세계의 상태를 구성합니다. 동시에 각 계정에 대해 주소에서 계정 상태로의 매핑입니다. 이 표현은 좀 더 추상적일 수 있습니다. 대중적인 방식으로 이해할 수 있습니다. 지갑을 열면 각 은행 카드가 은행 계좌에 해당합니다. 은행 카드의 카드 번호는 계좌의 주소와 동일하며 카드 번호의 자금 잔액, 소비 내역, 자산 관리 상품 보유량 등은 모두 계좌의 상태입니다. 따라서 각 카드는 특정 시점의 상태에 해당합니다. 모든 은행 카드의 수집은 자금의 세계 상태에 해당합니다. 거래 및 소비에 은행 카드를 사용함에 따라 은행 카드의 상태가 변경되고 자금의 세계 상태도 변경됩니다.
이 매핑 관계는 주로 Ethereum 계정의 키 필드에 있는 잔액에 반영됩니다. 직관적으로 이것은 일반적인 KV 키-값 쌍((address => uint256) 공개 잔액 매핑)이며 Value는 계정의 일종의 토큰 잔액에 반영됩니다. 따라서 Token은 Solidity에서 정수값 변수(단위)로 표현되며, 서로 다른 계정 간의 토큰 이체 과정은 디지털 덧셈과 뺄셈으로 운영됩니다.
다음은 Solidity를 사용하여 구현한 ERC20 전송 로직입니다."from user"(즉, 발신자가 "to user"(수신자)에게 토큰의 가치를 전송합니다. 주요 프로세스는 다음과 같습니다.
i. 보낸 사람 주소(from)의 초기 잔액 잔액을 매핑하고 oldFromVal 변수에 할당합니다.
ii. oldFromVal이 값보다 커야 합니다. 즉, 발신자가 충분한 잔액을 가지고 있어야 합니다.
iii. 수신자 주소(to)의 초기 잔액을 매핑하고 oldToVal 변수에 할당합니다.
iv. oldToVal + 값을 newToVal에 할당합니다.
v. oldFromVal 할당 — 값을 newFromVal에 할당;
vi. newFromVal을 보낸 사람 주소(from)의 새 잔액으로 설정합니다.
vii.newToVal을 수신기의 새 잔액으로 설정합니다.
일반적인 예를 들어 단순화하기 위해 Alice는 10위안을 Bob에게 전송하고 스마트 계약을 호출하여 Alice의 계정 주소에서 10을 빼고 Bob의 주소에 10을 더합니다. 잔액을 수정하는 전체 프로세스는 중앙 집중식 재무 시나리오에서 일반적인 공제 논리입니다.
그러나 온체인 세계는 다릅니다. 예를 들어 Bob의 잔액이 10 증가했지만 Alice의 잔액은 변경되지 않은 상황이 있습니까? 대답은 '예'입니다. 우리는 대부분의 온체인 행동이 스마트 계약에 의존하고 스마트 계약은 사전 설정된 규칙에 따라 자동으로 실행된다는 것을 알고 있습니다. 위의 예로 돌아가서 from과 to 주소가 같은 경우, 즉 자신에게 토큰을 보내는 경우입니다. 코드 실행순서에 따르면 발신자 주소에서 이체값을 먼저 차감하더라도 나중에 newFromVal의 값으로 newToVal의 값을 덮어쓰게 되어 계좌의 잔고는 늘었지만 차감은 되지 않는 효과가 있다. 만들어진. 이로 인해 토큰의 무제한 발행에 허점이 생겼습니다.
이 예에서 사용자 간의 거래 프로세스는 계약 코드의 논리에 의존하여 구현되며 최종적으로 주소 아래의 해당 번호 업데이트에 반영됨을 알 수 있습니다. 그것의 신뢰성은 계약의 개발자에 달려 있으며 일부 인적 오류가 발생하지 않을 것이라고 보장하기 어렵습니다. 최종 분석에서 Solidity는 자산 지향 언어가 아닌 블록체인 스마트 계약을 위한 언어입니다. 솔리디티에서 디지털 자산은 유형 정의 없이 더하고 뺄 수 있는 단순한 숫자이며, 숫자의 표현력이 부족하여 자산을 구분해야 합니다.
a) 일류 리소스 — — 디지털 자산 실현
위의 문제를 해결하기 위해 Move는 디지털 자산에 대한 새로운 데이터 유형인 First-class Resource를 구체적으로 정의합니다. 1급 시민의 의미는 이해하기 쉽다, 즉 프로그래밍 언어는 1급 시민을 프로그래밍할 1급 대상으로 삼아야 하며, 자원은 간단히 말해서 수적으로 제한된 자원이다. 가치를 창출할 수 있습니다. Move는 이 아이디어를 따르고 프로그래밍할 때 리소스가 따라야 하는 두 가지 제약, 즉 희소성과 액세스 권한을 추상화합니다.
●희소성
희소성은 물리적 세계의 금괴와 같은 귀중한 물리적 자산의 중요한 속성이며, 중간에 몇 번이나 순환하더라도 이 금괴는 1에서 2로 변하지 않으며 갑자기 사라지지 않습니다. 디지털 자산은 본질적인 물리적 희소성이 없습니다. 따라서 Move는 디지털 자산 계산 규칙이 프로그래밍 방식으로 이 희소성을 시행해야 한다고 믿습니다. 시스템 내 자산의 공급은 제한되어야 하고, 자산은 허공에서 사라질 수 없으며, 기존 자산을 복사하는 것은 금지되어야 하며, 새로운 자산을 생성하는 것은 특권적인 작업이어야 한다고 규정합니다. 여기서 말하는 프로그래밍 방식은 Move로 정의되는 어빌리티의 문법적 구조를 의미합니다. 복사(copy), 인덱싱(key), 폐기(drop), 저장(store)할 수 있는 다양한 변수에 대한 Move 초록의 4가지 속성을 포함하며, 개발자는 이러한 필드를 조합하여 변수에 다른 능력을 부여할 수 있습니다. 변수가 Resource type으로 선언되면 Key 및 Store 속성만 사용할 수 있으며 Copy 및 Drop에 추가할 수 없다는 점에 유의해야 합니다. 이러한 방식으로 Move는 프로그래밍 구문 구조에서 리소스 유형의 희소성을 보장합니다.
● 액세스 권한
자산 소유자는 일종의 액세스 제어 정책을 통해 자산을 보호할 수 있어야 합니다. 우리는 Ethereum이 주로 공개 키 서명 메커니즘에 의존한다는 것을 알고 있으며 Move는 이를 기반으로 새로운 모듈 시스템을 제공합니다. 모듈에 대해서는 나중에 자세히 설명할 것이므로 여기서는 보여주지 않겠습니다.
일반적으로 Move는 리소스를 사용하여 하위 계층의 자산 개념을 캡슐화하여 디지털 자산을 진정으로 계약 변수로 만들고 저장 및 할당할 수 있을 뿐만 아니라 함수/절차의 매개 변수 및 반환 값으로 사용할 수 있습니다. 위의 Move는 자원 변수에 대해 만든 필수 규칙을 반영하여 자산이 허공에서 사라지거나 임의로 복사될 수 없도록 하여 위에서 언급한 무한 복사 및 추가 발행 허점과 같은 보안 위험을 잘 방지합니다.
b) 모듈 — — 권한 제어 및 조합성을 구현합니다.
모듈은 Rust의 Mod 및 Solitidy의 Contract와 유사한 모듈입니다. Resource, Struct 및 Function을 포함하여 내부에 일련의 데이터 유형 및 함수를 선언할 수 있습니다. Struct 및 Resource는 모두 새로운 데이터 구조 유형을 정의하는 데 사용됩니다. 차이점은 Resource는 복사하거나 버릴 수 없다는 것입니다. Function 함수의 경우 대부분의 다른 언어와 유사하며 Module에 선언된 유형을 생성, 소멸 및 업데이트하는 데 사용할 수 있습니다. 전반적으로 Module은 다음과 같은 특징을 가지고 있습니다.
●강력한 데이터 추상화
Module이 강력한 데이터 추상화인 이유는 데이터 유형이 선언된 Module 내부에서는 투명하고 외부에서는 불투명하며 각 Resource 객체는 특정 Module에 캡슐화되어 모든 Control에서 결정되고 해당 계정의 업데이트가 결정되기 때문입니다. 세부 정책에 따라 자산을 생성, 수정 및 파기할 수 있는 외부 기능을 제공합니다. 앞서 언급했듯이 이 기능은 Move의 접근 제어에도 자주 사용됩니다. Module 외부는 Module을 우회하여 내부 Resource를 직접 동작시킬 수 없으며, 제공되는 기능을 통해 Resource를 일부 제한하여 사용해야 합니다. 코드에 반영되어 외부 개발자는 모듈에서 Public 유형의 함수만 호출할 수 있으며 모듈 내부의 정의에 따라 작동하여 우발적인 호출로 인한 잠재적인 안전 위험을 방지합니다.
●유연성과 무국적
모듈은 설계 시 컨트랙트 간 상호 결합 및 리소스 활용을 위해 외부에서 제공하는 모듈의 공용 인터페이스를 그대로 유지하며, 이는 솔리디티에서 사용하는 인터페이스 표준과 기능상 크게 다르지 않습니다. 예, 상태는 글로벌 스토리지에 보관됩니다. 특히 Solidity에서 ERC-20 계약의 토큰 구현은 원장의 상태 변경을 통해 계약과 각 사용자의 상호 작용에 대한 전체 데이터를 기록하는 원장과 비슷하며 Move는 모듈을 사용하여 자산을 캡슐화하고 저장합니다. 계정 주소 아래에는 레이블이 있는 독립형 금고와 비슷합니다.
c) 소유권 시스템 - 자산 소유권 실현
이 개념은 다음과 같이 소유권을 정의하는 Rust에서 상속됩니다.
1. 각 값에는 소유자라는 해당 변수가 있습니다.
2. 값에는 항상 한 명의 소유자만 있습니다.
3. 소유자가 범위를 벗어나면 값이 삭제됩니다.
간단히 말해서 값은 고유한 소유자만 가질 수 있으며 소유자는 함수일 수 있습니다. 새 함수에 값을 전달할 때 함수는 새 소유자가 되며 함수에 값을 전달하는 것은 변수에 값을 할당하는 것과 의미상 유사합니다.
따라서 Resource의 자원 속성을 되돌아보면 여전히 사용자 간의 Resource 트랜잭션이 자산의 가치에 따라 더해지고 빼지고 색인화되지만 하나의 균형을 줄이기 위해 Solidity에서 강제로 코드 논리를 사용하는 것과는 다릅니다. 주소를 지정하고 다른 주소의 잔액을 늘리십시오. 방법 간에는 본질적인 차이점이 있습니다. 자원의 전송 프로세스는 벽돌을 옮기고 한 계정에서 다른 계정으로 자원을 이동하는 것과 비슷하며 전송 중에 손실이나 중복이 없습니다. 자산 보안을 더 잘 보장합니다.
일반적으로 Move는 Linear type의 개념을 통해 데이터의 소유권을 명확히 하고, 리소스 희소성, 보호 및 액세스 제어를 강조하고 모듈 시스템을 사용하여 각 리소스의 수명 주기, 저장 및 액세스 모드를 정의합니다. 이러한 기능을 함께 사용하면 디지털 자산이 갑자기 생성되어 암묵적으로 폐기되지 않도록 하여 이중 지출 및 무제한 발행과 같은 보안 문제의 발생을 줄입니다.
보조 제목
2.2 가상 머신: Runtime Bytecode Verifier — — 실행 중 취약점 찾기
Move의 언어 설계 기능은 위에 소개되었으며 개발자는 이러한 기능을 사용하여 특정 요구 사항이 있는 스마트 계약을 작성할 수 있습니다. 그러나 Move와 Solidity는 모두 고급 프로그래밍 언어이며 컴퓨터는 이러한 소스 코드를 직접 읽고 실행할 수 없으므로 특정 계약을 구현하기 위해 전용 실행기에 의존해야 합니다.
현재 가상 머신은 스마트 계약의 주류 구현 중 하나이며 Move도 예외는 아닙니다. 그것은 완전히 투명한 실행 환경을 가진 프로그램을 최하위 계층에 제공할 수 있으며, 그 목적은 프로그램 개발자가 각각의 다른 서버와 호환성을 위해 다른 버전의 프로그램을 작성하도록 허용하는 대신 "한 번 작성하고 모든 곳에서 실행"하는 기능을 실현하는 것입니다. 이렇게 설계한 이유는 스마트 컨트랙트가 합의에 도달하기 위해서는 Byzantine 내결함성이 요구되는 분산 시스템 환경에서 실행되기 때문입니다. 각 노드에서 실행에 도달할 수 없음 합의 ; 가상 머신은 블록체인 노드 자체의 실행 환경 차이를 보호하고 모든 노드에서 일관되게 실행하여 스마트 계약의 확실성을 실현할 수 있습니다.
Move 가상 머신은 전형적인 스택 기반 바이트코드 인터프리터입니다. 입력은 바이트코드와 현재 세계 상태, 출력은 세계 상태로의 변경입니다. 모든 시스템을 실행하고 처리하기 위한 독립적인 명령 세트가 있습니다. 상태가 변경되면 사용자는 Move에서 제공하는 바이트 코드 비교 테이블에서 명령의 해당 의미를 찾을 수 있습니다.
●워크플로우
Move 가상 머신의 구체적인 작업 흐름은 다음과 같습니다: 먼저 소스 코드는 컴파일러를 통해 하위 수준 바이트 코드 바이트 코드로 변환되어 가상 머신에 전달됩니다. 바이트 코드를 수신한 후 가상 머신은 먼저 바이트 코드 검증자를 호출하여 확인 검증자는 Move 소스 코드에서 다양한 유형의 오류를 확인할 수 있으며 마지막으로 가상 머신 인터프리터는 각 데이터 또는 바이트 코드를 왼쪽에서 오른쪽으로 순회하면서 스크립트를 순차적으로 해석하고 실행합니다. 런타임은 스택 실행을 기반으로 하며, 데이터를 만나면 스택으로 푸시하고, 바이트코드를 만나면 해당 데이터의 데이터를 팝업하며, 바이트코드를 계산에 사용합니다. 종료될 때까지 스택에 다시 푸시됩니다.
이 과정을 통해 소스코드를 확인할 때 발생할 수 있는 타입 오류는 주로 다음과 같다.
i. 스택 아웃 오브 바운드 체크. 피연산자 스택에 액세스하기 위한 각 함수의 범위와 스택 높이가 유효한지 확인하십시오.여기서 스택은 바이트코드 검증기에 의해 생성된 각 바이트코드의 명령 블록(기본 블록)입니다.
ii. 유형 및 종류 확인. 파생 스택에 있는 변수의 특정 유형이 올바른지 확인하십시오.
iii. 인용 확인. 매달려 있는 참조를 방지하려면 각 참조가 할당된 저장 위치를 가리켜야 합니다.
EVM은 스마트 계약을 위해 체인 노드에 의해 생성된 격리되고 결정 가능한 샌드박스 환경입니다.여러 계약 프로그램은 동일한 프로세스의 서로 다른 가상 머신 샌드박스에서 실행됩니다. 즉, 이더리움 계약 간의 호출은 동일한 프로세스에서 서로 다른 스마트 계약 가상 머신 간의 호출이며 보안은 스마트 계약 가상 머신 간의 격리에 따라 달라집니다.
Move 가상 머신은 병렬 실행을 지원합니다. 계약 간 호출은 중앙 집중식 샌드박스에 배치됩니다. 이 아키텍처에서 계약 상태의 보안은 격리를 위해 가상 머신에 의존하지 않고 주로 프로그래밍 언어의 내부 보안을 통해 격리됩니다.
보조 제목
2.3 오프체인 도구: 공식 검증 — 실행 전 취약성 찾기
이상적으로 Move는 바이트코드 확인을 실행하여 계약 런타임에서 보안 허점을 찾을 수 있습니다. 그러나 이러한 종류의 온체인 검증의 계산 비용은 매우 높고 이러한 종류의 계산은 종종 많은 네트워크 리소스를 차지하여 체인의 TPS에 영향을 미칩니다. 따라서 Move가 채택하고자 하는 전략은 주요 보안 속성에 대한 경량 온체인 검증만 수행하고 다른 보안 문제에 대해서는 오프체인 정적 검증 도구에 의존하는 것입니다. 이 전략을 기반으로 Move는 인적 오류를 방지하고 코드 보안을 개선하기 위해 고유한 Move Prover 형식 검증기를 개발했습니다.
소위 정형 검증은 특정 형식 사양 또는 속성에 따라 프로그램의 신뢰성을 검증하는 것입니다. 이러한 사양은 일반적으로 수학적 모델을 설정하여 설정됩니다. 배포 전에는 버그가 없었습니다. 기존의 수동 감사 코드 보안과 비교하여 공식 검증은 수동 수단이 가능한 입력을 철저하게 열거할 수 없다는 단점을 해결할 수 있습니다.
● 정적 호출
Move Prover는 메커니즘 설계에서 동적 호출을 전혀 지원하지 않기 때문에 Move Prover는 정적 검증 도구라는 점을 언급할 가치가 있습니다. 동적 호출은 프로그램이 다른 프로그램을 호출하는 경우 호출 대상이 런타임에 결정되어야 하며 이러한 종류의 계약 호출을 동적이라고 합니다. 메커니즘 관점에서 보면 서버의 원격 호출과 다소 유사합니다. 그러나 동적 호출은 루프에서 호출할 때 동시성 문제를 일으킬 수 있습니다. 예를 들어 컨트랙트 A는 컨트랙트 B를 호출하고 컨트랙트 B는 컨트랙트 A를 호출합니다. 컨트랙트 A의 이전 실행이 완료되지 않고 다음 실행이 수행되므로 후속 실행에서 이전 중간 상태를 읽지 못하여 결국 보안 취약점. 유명한 The DAO 사고는 계약 동적 호출 문제로 인해 발생했습니다. 따라서 Move 설계에서 각 함수 호출은 정적이며 개발자는 프로그램이 실행되기 전에 특정 순서로 호출하는 함수를 알 수 있습니다. 이러한 종류의 정적 유형 시스템은 정식 검증을 통한 추론에 더 적합하고 컴파일 단계 전에 문제를 노출하여 런타임에 버그 가능성을 줄이고 보안 검사의 압력을 잘 공유합니다.
첫 번째 레벨 제목
3. 요약 및 전망
Bitcoin Script에서 Ethereum Solidity로의 전환이 계약 표현 기능의 변화라면 Solidity에서 Move로의 전환은 계약 보안 기능의 진화입니다. 그래서 무브에게도 시장의 높은 기대가 맡겨졌다.
언어 메커니즘의 관점에서 자산 보안에 대한 Move의 탐색은 매우 흥미진진합니다. 언어 디자인, 가상 머신 및 검증 도구의 세 가지 수준에서 혁신적인 변화를 만들었습니다.이 디자인은 유기적 전체입니다: 자산 지향 프로그래밍 디자인은 Move 언어가 분산 금융 응용 프로그램의 배포에 자연스럽게 적응하도록 합니다. 논리, 액세스 제어, 정적 호출 및 공식 검증은 또한 디지털 자산의 보안에 대한 여러 보증을 제공합니다.
이번 새로운 퍼블릭 체인 내러티브의 가장 큰 초점은 의심할 여지 없이 Move이며, 이 주주 스타일을 사용하여 시장에서 큰 차이를 만들 수 있을지 우리 모두 기대합니다.
참조
2. https://move-book.com/cn/index.html
3. https://move-dao.github.io/move-book-zh/modules-and-scripts.html
4. https://jolestar.com/why-move-1/
5.https://mirror.xyz/0xbuidlerdao.eth/MePeSGYe63OX8xXb8IwIrXzGk_S606NG7SR879XMXRE
6. https://mp.weixin.qq.com/s/bSS9GAcVp6tuWjedpTysQw
7. https://starcoin.org/zh/developers/others/starcoin_ecology/
8. https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/design/virtual_machine/evm.html
9. https://doc.rust-lang.org/book/
10. https://solidity-cn.readthedocs.io/zh/develop/
첫 번째 레벨 제목
공식 웹 사이트:
문의하기:
컨설팅 이메일: research@huobi.com
공식 웹 사이트:https://research.huobi.com/
Twitter： Huobi_Research
https://twitter.com/Huobi_Research
Medium： Huobi Research
https://medium.com/huobi-research
Telegram： Huobi Research
https://t.me/HuobiResearchOfficial
부인 성명
1. 후오비 블록체인 연구소는 보고서의 객관성, 독립성, 공평성에 영향을 줄 수 있는 이 보고서에 관련된 프로젝트 또는 기타 제3자와 어떠한 관계도 없습니다.
2. 이 보고서에 인용된 자료 및 데이터는 모두 규정을 준수하는 채널에서 가져온 것이며, 자료 및 데이터의 출처는 후오비 블록체인 연구소에서 신뢰할 수 있는 것으로 간주되며 진위, 정확성 및 완전성에 대해 필요한 검증이 수행되었지만 후오비 블록체인은 연구소는 그 진정성, 정확성 또는 완전성에 대해 어떠한 보증도 하지 않습니다.
3. 보고서의 내용은 참고용이며 보고서의 결론 및 의견은 관련 디지털 자산에 대한 투자 조언을 구성하지 않습니다. 후오비 블록체인 연구소는 법률 및 규정에 명시적으로 규정된 경우를 제외하고 이 보고서의 내용을 사용하여 발생하는 모든 손실에 대해 책임을 지지 않습니다. 독자들은 이 보고서만을 바탕으로 투자 결정을 내리거나 이 보고서를 바탕으로 독립적인 판단을 내리는 능력을 잃어서는 안 됩니다.
4. 이 보고서에 포함된 정보, 의견 및 추측은 보고서 작성일 현재 연구자의 판단을 반영한 것일 뿐이며, 향후 산업 변화 및 데이터 정보 업데이트에 따라 의견 및 판단이 업데이트될 가능성이 있습니다. .
3. 보고서의 내용은 참고용이며 보고서의 결론 및 의견은 관련 디지털 자산에 대한 투자 조언을 구성하지 않습니다. 후오비 블록체인 연구소는 법률 및 규정에 명시적으로 규정된 경우를 제외하고 이 보고서의 내용을 사용하여 발생하는 모든 손실에 대해 책임을 지지 않습니다. 독자들은 이 보고서만을 바탕으로 투자 결정을 내리거나 이 보고서를 바탕으로 독립적인 판단을 내리는 능력을 잃어서는 안 됩니다.
IOS
Android