Move에 뛰어들어 보세요 - Facebook의 Libra 블록체인 프로그래밍 언어

다음으로, Move 언어의 주요 특성과 스마트 계약에 이미 널리 사용되는 다른 언어인 Solidity(Ethereum 플랫폼에서)와의 주요 차이점을 자세히 살펴보겠습니다. 이 자료는 26페이지 분량의 온라인 백서에 대한 연구를 기반으로 합니다.

소개

Move는 사용자 트랜잭션 및 스마트 계약을 실행하는 데 사용되는 실행 가능한 바이트코드 언어입니다. 다음 두 가지 사항에 유의하세요.

1. Move가 Move 가상 머신에서 직접 실행할 수 있는 바이트코드 언어인 반면, Solidity(Ethereum의 스마트 계약 언어)는 EVM(Ethereum Virtual Machine)에서 실행되기 전에 먼저 바이트코드로 컴파일되는 고급 언어입니다.
2. Move는 스마트 계약을 구현하는 것뿐만 아니라 사용자 지정 트랜잭션(나중에 자세히 설명)에도 사용할 수 있지만 Solidity는 스마트 계약 전용 언어입니다.

번역은 INDEX 프로토콜 프로젝트 팀에서 수행했습니다. 우리는 이미 번역했습니다 Libra 프로젝트를 설명하는 대형 자료, 이제 Move 언어를 좀 더 자세히 살펴보겠습니다. 번역은 Habrauser와 공동으로 진행되었습니다. 쿨슈

Move의 주요 기능은 선형 논리를 기반으로 하는 의미 체계로 사용자 정의 리소스 유형을 정의하는 기능입니다. 리소스는 복사되거나 암시적으로 삭제될 수 없으며 이동만 가능합니다. 기능적으로 이는 Rust 언어의 기능과 유사합니다. Rust의 값은 한 번에 하나의 이름에만 할당될 수 있습니다. 다른 이름에 값을 할당하면 이전 이름으로는 사용할 수 없게 됩니다.

예를 들어 다음 코드 스니펫은 오류를 발생시킵니다. 이동된 값 'x'의 사용. Rust에는 가비지 컬렉션이 없기 때문입니다. 변수가 범위를 벗어나면 변수가 참조하는 메모리도 해제됩니다. 간단히 말해서 데이터의 "소유자"는 한 명만 있을 수 있습니다. 이 예에서 x 원래 소유자이고 y 새 주인이 됩니다. 여기에서 이 동작에 대해 자세히 알아보세요..

개방형 시스템의 디지털 자산 표현

디지털로 표현하기 어려운 물리적 자산에는 두 가지 속성이 있습니다.

• 희박 (희소성, 원래 희소성). 시스템의 자산(배출량)의 수를 제어해야 합니다. 기존 자산의 복제는 금지되어야 하며 새 자산을 만드는 것은 특권 작업입니다.
• 액세스 제어... 시스템 참가자는 액세스 제어 정책을 사용하여 자산을 보호할 수 있어야 합니다.

물리적 자산에 자연스러운 이 두 가지 특성을 자산으로 간주하려면 디지털 개체에 대해 구현해야 합니다. 예를 들어, 희귀 금속은 자연적으로 희소성이 있으며, 당신만이 접근할 수 있고(예를 들어, 손에 들고) 판매하거나 사용할 수 있습니다.

이 두 속성에 도달한 방법을 설명하기 위해 다음 문장으로 시작하겠습니다.

제안 #1: 희소성과 접근 통제가 없는 가장 단순한 규칙

• G [K]: = n 키로 액세스할 수 있는 번호에 대한 업데이트를 나타냅니다. К 새로운 의미를 지닌 블록체인의 글로벌 상태 n.
• 거래 ⟨앨리스, 100⟩ Alice의 계정 잔액을 100으로 설정하는 것을 의미합니다.

위의 솔루션에는 몇 가지 주요 문제가 있습니다.

• 앨리스는 단순히 보내기만 하면 무제한의 코인을 받을 수 있습니다. 거래 ⟨앨리스, 100⟩.
• Alice가 Bob에게 보내는 동전은 Bob이 동일한 기술을 사용하여 무제한의 동전을 자신에게 보낼 수 있기 때문에 쓸모가 없습니다.

제안 #2: 적자 고려

이제 우리는 상황을 모니터링하여 코인의 수가 Ka 적어도 평등했다 n 이전 거래 전에. 그러나 이것이 희소성 문제를 해결하는 동안 앨리스의 코인을 보낼 수 있는 사람에 대한 정보는 없습니다(현재로서는 누구나 할 수 있으며, 가장 중요한 것은 금액 제한의 규칙을 어기지 않는 것입니다).

제안 #3: 희소성과 접근 통제의 결합

우리는 디지털 서명 메커니즘으로 이 문제를 해결합니다. 확인_시그 잔액을 확인하기 전에 Alice는 개인 키를 사용하여 거래에 서명하고 자신이 코인의 소유자인지 확인합니다.

블록체인 프로그래밍 언어

기존 블록체인 언어는 다음과 같은 문제에 직면해 있습니다(모두 Move에서 해결되었습니다(참고: 불행히도 이 기사의 저자는 비교에서 이더리움에만 호소하므로 이 맥락에서만 고려할 가치가 있습니다. 예를 들어 다음의 대부분은 EOS에서도 해결됩니다.)) :

자산의 간접 표현. 자산은 정수를 사용하여 인코딩되지만 정수는 자산과 동일하지 않습니다. 사실 비트코인/이더리움/<Any Coin>을 대표하는 종류나 값은 없습니다! 이로 인해 자산을 사용하는 프로그램 작성이 어렵고 오류가 발생하기 쉽습니다. 프로시저 간에 자산을 전달하거나 구조에 자산을 저장하는 것과 같은 패턴에는 언어의 특별한 지원이 필요합니다.

적자는 확장 불가능... 언어는 하나의 희소 자산만을 나타냅니다. 또한 희소성에 대한 구제책은 언어 자체의 의미에 직접 연결되어 있습니다. 개발자가 사용자 지정 자산을 만들려면 리소스의 모든 측면을 스스로 신중하게 제어해야 합니다. 이것이 바로 이더리움 스마트 계약의 문제입니다.

사용자는 가치와 총 공급량을 결정하기 위해 정수를 사용하여 자산인 ERC-20 토큰을 발행합니다. 새 토큰이 생성될 때마다 스마트 계약 코드는 배출 규칙 준수를 독립적으로 확인해야 합니다. 또한 자산의 간접 표시는 경우에 따라 심각한 오류(중복, 이중 지출 또는 자산의 완전한 손실)로 이어집니다.

유연한 액세스 제어 부족... 오늘날 사용되는 유일한 접근 제어 정책은 비대칭 암호화를 사용하는 서명 체계입니다. 희소성 보호와 마찬가지로 액세스 제어 정책은 언어의 의미에 깊숙이 포함되어 있습니다. 그러나 프로그래머가 자신의 액세스 제어 정책을 정의할 수 있도록 언어를 확장하는 방법은 종종 매우 까다로운 작업입니다.

이는 스마트 계약에 액세스 제어를 위한 기본 암호화 지원이 없는 Ethereum에서도 마찬가지입니다. 개발자는 예를 들어 onlyOwner 수정자를 사용하여 액세스 제어를 수동으로 설정해야 합니다.

나는 이더리움의 열렬한 팬이지만 보안 목적을 위해 자산 속성은 기본적으로 언어에서 지원되어야 한다고 믿습니다. 특히, Ether를 스마트 계약으로 이전하는 데에는 재진입 취약점이라는 새로운 종류의 버그가 발생하는 동적 디스패치가 포함됩니다. 여기서 동적 디스패치는 코드의 실행 논리가 컴파일 타임(정적)이 아닌 런타임(동적)에 결정된다는 의미입니다.

따라서 Solidity에서 계약 A가 계약 B의 함수를 호출하면 계약 B는 계약 A의 개발자가 의도하지 않은 코드를 실행할 수 있으며, 이로 인해 다음이 발생할 수 있습니다. 재진입 취약점 (계약 A는 계좌 잔액이 실제로 차감되기 전에 실수로 계약 B로 행동하여 돈을 인출합니다.)

Move 언어 디자인 기초

XNUMX차 자원

상위 수준에서 Move 언어의 모듈/리소스/프로시저 간의 상호 작용은 OOP 언어의 클래스/객체 및 메서드 간의 관계와 매우 유사합니다.
이동 모듈은 다른 블록체인의 스마트 계약과 유사합니다. 모듈은 선언된 리소스를 생성, 삭제 및 업데이트하기 위한 규칙을 정의하는 리소스 유형 및 절차를 선언합니다. 그러나 이 모든 것은 단지 관례일 뿐입니다("특수 용어”) 이동 중. 이 점은 잠시 후에 설명하겠습니다.

유연성

Move는 스크립팅을 통해 Libra에 유연성을 추가합니다. Libra의 모든 거래에는 본질적으로 거래의 핵심 절차인 스크립트가 포함되어 있습니다. 스크립트는 지정된 수신자 목록에 대한 지불과 같은 지정된 작업을 수행하거나 일반 논리가 지정된 프로시저를 호출하는 등 다른 리소스를 재사용할 수 있습니다. 이것이 바로 Move 트랜잭션 스크립트가 더 큰 유연성을 제공하는 이유입니다. 스크립트는 일회성과 반복 동작을 모두 사용할 수 있는 반면, Ethereum은 반복 가능한 스크립트(스마트 계약 방법에서 하나의 방법 호출)만 실행할 수 있습니다. 이를 "재사용 가능"이라고 부르는 이유는 스마트 계약의 기능이 여러 번 실행될 수 있기 때문입니다. (메모: 여기서의 요점은 매우 미묘합니다. 한편, 비트코인에는 의사 바이트코드 형태의 거래 스크립트도 존재합니다. 반면에 내가 이해하는 바에 따르면 Move는 이 언어를 실제로 본격적인 스마트 계약 언어 수준으로 확장합니다.).

Безопасность

Move 실행 파일 형식은 바이트코드입니다. 이는 어셈블리 언어보다 높은 수준의 언어이지만 소스 코드보다 낮은 수준입니다. 바이트코드는 바이트코드 검증기를 사용하여 런타임(온체인)에서 리소스, 유형 및 메모리 안전성을 확인한 후 인터프리터에 의해 실행됩니다. 이 접근 방식을 사용하면 Move가 소스 코드의 보안을 제공할 수 있지만 컴파일 프로세스나 시스템에 컴파일러를 추가할 필요가 없습니다. Move를 바이트코드 언어로 만드는 것은 정말 좋은 해결책입니다. Solidity의 경우처럼 소스에서 컴파일할 필요가 없으며 컴파일러 인프라에 대한 공격이나 실패 가능성에 대해 걱정할 필요가 없습니다.

검증 가능성

이 모든 작업이 체인 내에서 이루어지기 때문에 우리는 가능한 한 쉽게 검사를 수행하는 것을 목표로 합니다(참고: 온라인에서 각 트랜잭션이 실행되는 동안 지연이 발생하면 전체 네트워크가 느려집니다.) 그러나 초기에는 언어 설계가 오프체인 정적 검증 도구를 사용할 준비가 되어 있습니다. 이것이 더 바람직하지만 현재로서는 검증 도구(별도의 툴킷) 개발이 미래를 위해 연기되었으며 이제 런타임(온체인)의 동적 검증만 지원됩니다.

모듈성

이동 모듈은 데이터 추상화를 제공하고 리소스에 대한 중요한 작업을 현지화합니다. Move 유형 시스템이 제공하는 보호 기능과 결합된 모듈에서 제공하는 캡슐화는 모듈 유형에 설정된 속성이 모듈 외부의 코드에 의해 위반되지 않도록 합니다. 이것은 상당히 신중하게 설계된 추상화 설계입니다. 즉, 계약 내의 데이터는 계약 범위 내에서만 변경될 수 있고 외부에서는 변경되지 않습니다.

이동 개요

트랜잭션 스크립트 예제는 모듈 외부의 프로그래머에 의한 악의적이거나 부주의한 작업이 모듈 리소스의 보안을 손상시킬 수 없음을 보여줍니다. 다음으로 모듈, 리소스 및 절차를 사용하여 Libra 블록체인을 프로그래밍하는 방법의 예를 살펴보겠습니다.

PXNUMXP 결제

금액에 지정된 코인의 개수가 보낸 사람의 잔액에서 받는 사람에게 전송됩니다.
여기에는 몇 가지 새로운 사항이 있습니다(빨간색으로 강조 표시됨).

• 0 X 0: 모듈이 저장된 계정의 주소
• 환율: 모듈 이름
• 동전: 리소스 유형
• 프로시저에서 반환된 코인 값은 0x0.Currency.Coin 유형의 리소스 값입니다.
• 이동하다 (): 값을 다시 사용할 수 없습니다.
• 부(): 값은 나중에 사용할 수 있습니다.

코드 구문 분석: 첫 번째 단계에서 발신자는 다음이라는 프로시저를 호출합니다. 철수_from_sender 에 저장된 모듈에서 0x0.통화. 두 번째 단계에서는 송신자가 코인 자원 값을 모듈의 입금 절차로 이동하여 수신자에게 자금을 전송합니다. 0x0.통화.

다음은 검사에서 거부되는 코드 오류의 세 가지 예입니다.
통화를 변경하여 자금 복제 움직이다 (동전) 에 복사(동전). 리소스는 이동만 가능합니다. 일정량의 리소스를 복제하려고 합니다(예: 호출을 통해). 복사(동전) 위의 예에서) 바이트 코드를 확인하는 동안 오류가 발생합니다.

지정하여 자금 재사용 움직이다 (동전) 두 번 . 라인 추가 0x0.Currency.deposit (복사(some_other_payee), 이동(coin)) 예를 들어, 위의 경우 보낸 사람은 코인을 두 번 "사용"할 수 있습니다. 첫 번째는 수취인에게, 두 번째는 수취인에게 some_other_수취인. 이는 물리적 자산에서는 불가능한 바람직하지 않은 동작입니다. 다행히 Move는 이 프로그램을 거부할 것입니다.

거절로 인한 자금 손실 움직이다 (동전). 리소스를 이동하지 않는 경우(예: 다음을 포함하는 줄 삭제) 움직이다 (동전)), 바이트코드 확인 오류가 발생합니다. 이를 통해 Move 프로그래머가 우발적이거나 악의적인 자금 손실로부터 보호받을 수 있습니다.

통화 모듈

각 계정에는 0개 이상의 모듈(직사각형으로 표시)과 하나 이상의 리소스 값(원통으로 표시)이 포함될 수 있습니다. 예를 들어, 0 X 0 모듈 포함 0x0.통화 리소스 유형의 값 0x0.통화.코인. 주소에 있는 계좌 0 X 1 두 개의 리소스와 하나의 모듈이 있습니다. 주소에 있는 계좌 0 X 2 두 개의 모듈과 하나의 리소스 값이 있습니다.

몇 가지 순간 :

• 트랜잭션 스크립트는 원자적입니다. 완전히 실행되거나 전혀 실행되지 않습니다.
• 모듈은 전역적으로 액세스할 수 있는 수명이 긴 코드 조각입니다.
• 전역 상태는 해시 테이블로 구성되며, 여기서 키는 계정 주소입니다.
• 계정은 지정된 유형의 리소스 값을 하나만 포함할 수 있으며 지정된 이름을 가진 모듈은 하나만 포함할 수 있습니다(계정은 0 X 0 추가 리소스를 포함할 수 없습니다. 0x0.통화.코인 또는 이름이 다른 모듈 환율)
• 선언된 모듈의 주소는 유형(0x0.통화.코인 и 0x1.통화.코인 서로 바꿔서 사용할 수 없는 별도의 유형입니다)
• 프로그래머는 사용자 정의 리소스를 정의하여 이러한 유형의 리소스에 대한 여러 인스턴스를 계정에 저장할 수 있습니다.리소스 TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
• 충돌 없이 이름으로 리소스를 참조할 수 있습니다. 예를 들어 다음을 사용하여 두 리소스를 참조할 수 있습니다. 투코인스.c1 и 투코인스.c2.

코인 자원 발표

이름이 지정된 모듈 환율 그리고 이름이 지정된 리소스 유형 동전

몇 가지 순간 :

• 동전 유형이 하나인 필드가 있는 구조입니다. u64 (64비트 부호 없는 정수)
• 모듈 절차만 환율 유형의 값을 생성하거나 파괴할 수 있습니다. 동전.
• 다른 모듈과 스크립트는 모듈에서 제공하는 공개 프로시저를 통해서만 값 필드를 작성하거나 참조할 수 있습니다.

보증금 매각

이 절차에서는 리소스를 수락합니다. 동전 입력으로 사용하고 이를 리소스와 결합합니다. 동전수취인의 계정에 저장됩니다:

1. 입력 자원 코인을 파괴하고 그 가치를 기록합니다.
2. 수신자의 계정에 저장된 고유한 코인 리소스에 대한 링크를 받습니다.
3. 프로시저 호출 시 인자로 전달된 값으로 Coin 개수의 값을 변경합니다.

몇 가지 순간 :

• 포장 풀기, BorrowGlobal - 내장된 프로시저
• 짐 등에서 꺼내다 이는 유형 T의 리소스를 삭제하는 유일한 방법입니다. 프로시저는 리소스를 입력으로 사용하고 이를 삭제한 다음 리소스의 필드와 연결된 값을 반환합니다.
• 차용글로벌 주소를 입력으로 사용하고 해당 주소가 게시한(소유한) T의 고유 인스턴스에 대한 참조를 반환합니다.
• &뮤트 코인 이것은 리소스에 대한 링크입니다 동전

철회_from_sender 구현

이 절차는 다음과 같습니다.

1. 고유한 리소스에 대한 링크를 가져옵니다. 동전, 보낸 사람의 계정에 연결됨
2. 자원의 가치를 감소시킵니다. 동전 지정된 금액에 대한 링크를 통해
3. 새 리소스를 생성하고 반환합니다. 동전 업데이트된 잔액으로

몇 가지 순간 :

• 입금 누구나 원인이 될 수 있지만 철수_from_sender 호출 계정의 코인에만 접근할 수 있습니다.
• GetTxnSenderAddress 비슷하다 메시지.발신자 견고하게
• 거부하지 않는 한 비슷하다 필요 솔리디티에서. 이 확인이 실패하면 트랜잭션이 중지되고 모든 변경 사항이 롤백됩니다.
• 팩 이는 T 유형의 새 리소스를 생성하는 내장 프로시저이기도 합니다.
• 게다가 짐 등에서 꺼내다, 팩 리소스가 설명된 모듈 내에서만 호출할 수 있습니다. T

결론

Move 언어의 주요 특징을 살펴보고 이더리움과 비교하며 스크립트의 기본 구문에도 익숙해졌습니다. 마지막으로 꼭 확인해 보시기 바랍니다. 원본 백서. 여기에는 프로그래밍 언어 설계 원칙에 관한 많은 세부 정보와 유용한 링크가 많이 포함되어 있습니다.

출처 : habr.com