스마트 계약 개발에 대한 심층 분석: Move와 Rust의 비교 연구
원래 제목: "Smart Contract Development—Move vs.Rust》
원문 편집: Guo Qianwen, Chain Catcher
원문 편집: Guo Qianwen, Chain Catcher
첫 번째 레벨 제목
1. 소개
최근 Aptos와 Sui에 대한 논의가 본격화되었습니다.이 두 가지는 고성능 L1 퍼블릭 체인으로 떠오르고 있으며 Move 스마트 계약 프로그래밍 언어는 이러한 새로운 체인에서 없어서는 안될 부분입니다. 일부 개발자는 스마트 계약 개발의 미래라고 선언하면서 Move로 적극적으로 전환하고 있습니다. 다른 사람들은 Move가 기존 프로그래밍 언어에 비해 너무 새로운 것을 많이 제공할 수 없다고 주장하면서 더 신중했습니다.
암호화 투자자들은 또한 이러한 L1 퍼블릭 체인의 독창성이 현재 고성능 L1의 주요 플레이어이며 Rust를 스마트 계약 프로그래밍으로 사용하는 것으로 알려진 Solana와 어떻게 경쟁할 수 있는지 궁금해하고 있습니다.
그러나 지금까지 본 논의는 특정 깊이에 도달하지 않았으며 이러한 새로운 기술이 우리에게 미치는 영향을 진정으로 이해할 수 있습니다. 이것은 토론의 양쪽 극단에 모두 적용됩니다. Move 회의론자들은 Move를 아무 것도 아닌 것으로 일축하고 그것의 미묘한(그러나 중요한) 측면을 인식하지 못하지만 Move 지지자들은 Move를 과장하여 그것이 무엇을 위대하게 만드는지 보지 못합니다. 이로 인해 엄청난 중간지점과 모호성이 발생하여 외부 관중, 암호화 개발자 및 투자자가 이 주제에 주의를 기울이지만 자신의 견해를 확신하지 못합니다.
이 게시물에서는 새로운 프로그래밍 모델인 Move, Sui 블록체인, Move의 기능을 활용하는 방법, Solana 및 프로그래밍 모델과 비교하는 방법에 대해 기술적으로 깊이 파고들 것입니다. Move의 기능을 강조하기 위해 Solana/Rust와 Sui/Move를 비교해 보겠습니다. 한 가지를 이미 익숙한 다른 것과 비교할 때 이해가 더 쉽기 때문입니다.어떤 면에서 약간 다른 Aptos Move와 같은 Move의 다른 변형이 있습니다. 이 기사의 요점은 Move의 다양한 변형 간의 미묘한 차이점을 논의하는 것이 아니라 Move의 일반적인 이점과 Solana 프로그래밍 모델과 비교하는 방법을 보여주는 것입니다. 따라서 간단하게 하기 위해 이 기사에서는 하나의 변형(Sui Move)만 사용합니다. 그러므로 나는그럼에도 불구하고 이 기사에서 논의된 Move의 모든 주요 이점은 Aptos를 포함하여 모든 Move 통합(기본적으로 Move 바이트코드 지원)에 적용됩니다. Sui가 더 익숙하고 기사의 형태로 표현하기가 더 직관적이고 쉬운 것 같아서 Sui를 선택했습니다.
첫 번째 레벨 제목
2. 솔라나 프로그래밍 모델
솔라나에서 프로그램(스마트 컨트랙트)은 상태 비저장이며 트랜잭션 간에 지속되는 상태에 자체적으로 액세스(읽기 또는 쓰기)할 수 없습니다. 상태에 액세스하거나 유지하려면 프로그램에서 계정을 사용해야 합니다. 각 계정에는 임의의 데이터를 저장할 수 있는 고유한 주소(Ed25519 키 쌍의 공개 키)가 있습니다.
솔라나의 계정 공간은 키가 계정 주소(pubkey)이고 값이 계정 데이터인 글로벌 키-값 저장소로 생각할 수 있습니다. 프로그램은 값을 읽고 수정하여 이 키-값 저장소에서 작동합니다.
계정에는 소유권 개념이 있습니다. 각 계정은 하나의 프로그램에서 소유합니다. 프로그램이 계정을 소유한 경우 해당 프로그램은 데이터를 수정할 수 있습니다. 프로그램은 자신이 소유하지 않은 계정을 수정할 수 없습니다(단, 읽을 수는 있음). 운영 중 프로그램 실행 전과 후의 계정 상태를 비교하여 이러한 종류의 동적 확인을 수행할 수 있으며 불법적인 수정이 있을 경우 트랜잭션이 실패합니다.
또한 각 계정에는 연결된 개인 키(해당 공개 키는 해당 주소)가 있으며 이 개인 키에 액세스할 수 있는 사용자는 이를 사용하여 트랜잭션에 서명할 수 있습니다. 이 메커니즘을 사용하여 Solana 스마트 계약에서 권한 및 소유권 기능을 구현합니다. 예를 들어 특정 자금을 얻기 위해 스마트 계약은 사용자에게 필요한 서명을 제공하도록 요구할 수 있습니다.
다른 프로그램을 호출할 때 고객은 호출 시 프로그램이 액세스할 계정을 지정해야 합니다. 이러한 방식으로 트랜잭션 처리 런타임은 데이터 일관성을 보장하면서 겹치지 않는 트랜잭션이 병렬로 실행되도록 예약할 수 있습니다. 이것은 높은 처리량을 제공하는 Solana의 설계 기능 중 하나입니다.
프로그램은 CPI 호출을 통해 다른 프로그램을 호출할 수 있습니다. 이러한 호출은 기본적으로 클라이언트에서 호출하는 것과 동일하게 작동합니다. 호출자 프로그램은 호출 수신자 프로그램이 액세스할 계정을 지정해야 하며 호출 수신자 프로그램은 클라이언트에서 호출하는 것처럼 입력 검사를 수행합니다(신뢰하지 않기 때문). 호출자 프로그램).
이것은 Solana에서 안전한 스마트 계약 프로그래밍의 기본 빌딩 블록입니다. 어느 정도 솔라나 프로그램은 운영 체제에 있는 프로그램, 계정은 파일이라고 생각할 수 있으며, 누구나 자유롭게 어떤 프로그램을 실행할 수 있고, 심지어 자신의 프로그램을 배포할 수도 있습니다. 프로그램(스마트 계약)이 실행되면 파일(계정)을 읽고 씁니다. 모든 파일은 모든 프로그램에서 읽을 수 있지만 파일에 대한 소유권이 있는 프로그램만 파일에 쓸 수 있습니다. 프로그램은 다른 프로그램도 실행할 수 있지만 서로 신뢰하지 않습니다. 프로그램을 실행하는 사람은 입력이 잠재적으로 악의적이라고 가정해야 합니다. OS는 누구에게나 전역적으로 액세스할 수 있기 때문에 사용자를 위한 권한 및 소유권 기능을 구현하기 위해 기본 서명 확인 지원이 프로그램에 내장되었습니다. 완벽한 유추는 아니지만 흥미로운 점입니다.
첫 번째 레벨 제목
3. Move의 프로그래밍 모델
솔라나에서 이는 모든 스마트 계약을 프로그램의 모듈로 게시하는 것과 같습니다. 이는 모든 스마트 계약(모듈)이 동일한 클래스 시스템에 포함되어 중간 API 또는 인터페이스를 거치지 않고 서로 직접 호출할 수 있음을 의미합니다. 이것은 매우 중요하며 그 의미는 이 기사에서 철저히 논의될 것입니다.
보조 제목
3.1 객체
아래 개체 개념은 Move의 Sui 변형에만 적용됩니다. Move의 다른 통합(예: Aptos 또는 Diem/core Move)에서는 상황이 약간 다를 수 있습니다. 그러나 크게 다르지 않은 동일한 작업(상태 지속성)을 달성하는 다른 Move 변형에도 유사한 솔루션이 있습니다.
여기서 Sui 변종을 소개하는 주된 이유는 기사 뒷부분의 코드 샘플이 모두 Move의 Sui 변종을 기반으로 하고 있으며 핵심 Move의 전역 저장 메커니즘과 같은 객체가 더 직관적이고 이해하기 쉽기 때문입니다. 중요한 것은 이 기사에서 논의된 Move의 모든 주요 이점이 Aptos를 포함하여 모든 Move 통합(기본적으로 Move 바이트코드 지원)에 적용된다는 것입니다.
개체는 런타임에 의해 저장되는 구조체 인스턴스이며 트랜잭션 간에 상태를 유지합니다.
객체에는 세 가지 유형이 있습니다(Sui).
소유한 물건
공유 객체
불변 객체
소유된 객체는 사용자에게 속한 객체입니다. 개체를 소유한 사용자만 트랜잭션에서 개체를 사용할 수 있습니다. 소유권 메타데이터는 완전히 투명하며 런타임에서 처리됩니다. 공개 키 암호화를 사용하여 구현됩니다. 각 개체는 공개 키(런타임 시 개체 메타데이터에 저장됨)와 연결되며 트랜잭션에서 개체를 사용하려면 언제든지 해당 서명을 제공해야 합니다(이제 지원됨). 곧 ECDSA 및 K-of-N 다중 서명을 지원할 예정인 Ed25519).
공유 객체는 소유 객체와 유사하지만 연결된 소유자가 없습니다. 따라서 트랜잭션에서 개인 키를 사용하기 위해 개인 키를 소유할 필요가 없습니다(누구나 사용할 수 있음). 소유한 개체는 (소유자에 의해) 공유될 수 있으며, 일단 공유된 개체는 영원히 공유된 상태로 유지됩니다. 다시는 양도되거나 자신의 개체가 될 수 없습니다.
Move 프로그래밍 모델은 매우 직관적이고 단순합니다. 각 스마트 계약은 기능 및 구조 정의로 구성된 모듈입니다. 구조는 함수에서 인스턴스화되며 함수 호출을 통해 다른 모듈로 전달될 수 있습니다. 트랜잭션 전체에서 구조를 지속시키기 위해 소유, 공유 또는 변경할 수 없는 개체로 만듭니다(Sui만 해당, 다른 Move 변형에서는 약간 다름).
첫 번째 레벨 제목
4. 이사의 보안
우리는 Move에서 그것을 보았습니다:
소유(또는 공유)하는 모든 객체를 모든 모듈의 모든 함수에 전달할 수 있습니다.
누구나 (잠재적으로 적대적인) 모듈을 게시할 수 있습니다.
Solana 계정의 경우와 같이 소유자 모듈이 구조를 변경할 수 있는 유일한 권한을 부여하는 모듈 소유 구조의 개념이 없습니다. 구조는 다른 모듈로 흐르거나 다른 구조에 내장될 수 있습니다.
문제는 이 관행이 안전한 이유입니다. 사람들이 악의적인 모듈을 게시하고 AMM 풀과 같은 공유 개체를 가져와 악의적인 모듈로 보내고 계속해서 자금을 소모하는 것을 막는 것은 무엇입니까?
이것이 Move의 참신함입니다. 리소스에 대해 이야기해 봅시다.
보조 제목
4.1 구조
구조체 유형을 정의하는 것은 예상한 것과 거의 같습니다.
지금까지는 좋았습니다. Rust에서 구조체를 정의하는 방법이기도 합니다. 그러나 Move에서 구조체는 고유하며 전통적인 프로그래밍 언어와 비교할 때 Move 모듈은 유형을 사용하는 방법에 더 많은 공간이 있습니다. 위의 코드 스니펫에 정의된 구조에는 다음 제한 사항이 적용됩니다.
구조체를 정의하는 모듈 내에서만 인스턴스화("패킹") 및 소멸("언패킹")할 수 있습니다. 즉, 다른 모듈의 함수에서 구조체 인스턴스를 인스턴스화하거나 소멸시킬 수 없습니다.
구조체 인스턴스의 필드는 해당 모듈 내에서만 액세스할 수 있으므로 변경할 수 있습니다.
구조체 인스턴스는 해당 모듈 외부에서 복제하거나 복사할 수 없습니다.
다른 구조체 인스턴스의 필드에 구조체 인스턴스를 저장할 수 없습니다.
즉, 다른 모듈의 함수에서 이 구조체의 인스턴스를 처리하는 경우 해당 필드를 변경하거나 복제하거나 다른 구조체의 필드에 저장하거나 폐기할 수 없습니다(함수 호출을 통해 다른 모듈에 전달해야 함). 장소). 문제는 다음과 같습니다. 구조의 모듈은 이러한 작업을 수행하기 위해 모듈에서 호출할 수 있는 함수를 구현합니다. 하지만 그 외에는 외부 유형에 대해 이러한 작업을 직접 수행할 수 없습니다. 이렇게 하면 해당 유형이 사용되는 방식과 사용되지 않는 방식을 모듈에 완벽하게 제어할 수 있습니다.
이러한 제약으로 인해 많은 유연성을 잃는 것 같습니다. 이것은 또한 사실입니다. 전통적인 프로그래밍에서 그러한 구조를 다루는 것은 매우 번거로울 것이지만 사실 이것은 스마트 계약에서 우리가 원하는 것입니다. 스마트 계약 개발은 결국 디지털 자산(자원)의 프로그래밍에 관한 것입니다. 위에서 설명한 구조를 보면 그것이 바로 자원입니다. 마음대로 만들 수도 없고 복사할 수도 없으며 우발적으로 파괴할 수도 없습니다. 따라서 우리는 여기서 약간의 유연성을 잃지만 우리가 잃는 유연성은 우리가 원하는 것입니다. 이렇게 하면 리소스를 직관적이고 안전하게 조작할 수 있기 때문입니다.
또한 Move를 사용하면 구조에 기능을 추가하여 이러한 제한 사항 중 일부를 완화할 수 있습니다. 키, 저장, 복사 및 삭제의 네 가지 기능이 있습니다. 이러한 능력의 조합을 구조에 추가할 수 있습니다.
그들이 하는 일은 다음과 같습니다.
Keys - 구조체가 객체가 되도록 허용합니다(Sui에만 해당, 핵심 Move 사례는 약간 다름). 앞에서 언급한 것처럼 개체는 영구적이며 자체 소유 개체인 경우 스마트 계약 호출에서 사용하려면 먼저 사용자가 서명해야 합니다. 키 기능을 사용할 때 구조의 첫 번째 필드는 UID 유형의 개체 ID여야 합니다. 이렇게 하면 참조할 수 있는 전역적으로 고유한 ID가 부여됩니다.
storage - 구조체를 다른 구조체의 필드로 포함할 수 있습니다.
copy - 어디에서나 구조를 임의로 복사/복제할 수 있습니다.
기본적으로 Move의 모든 구조는 기본 리소스입니다. 기능은 우리에게 이러한 제약을 미세하게 완화하여 기존 구조처럼 동작하도록 합니다.
보조 제목
4.2 코인
Sui 코드 저장소에서 전체 모듈 구현을 찾을 수 있습니다(링크）。
링크
코인 종류에는 키와 보관 기능이 있습니다. 키는 개체로 사용할 수 있음을 의미합니다. 이를 통해 사용자는 코인을 직접 소유할 수 있습니다(최상위 개체로). 당신이 코인을 소유하고 있을 때, 당신 외에는 아무도 거래에서 그것을 참조할 수 없습니다(사용은 고사하고). 스토리지는 코인을 다른 구조체에 필드로 포함할 수 있음을 의미하며 이는 구성 가능성에 유용합니다.
폐기 기능이 없기 때문에 기능 내에서 동전을 실수로 폐기(파기)할 수 없습니다. 이것은 매우 좋은 기능입니다. 즉, 실수로 동전을 잃어버릴 염려가 없습니다. 코인을 매개 변수로 사용하는 함수를 구현하는 경우 함수의 끝에서 이를 사용하여 명시적으로 무언가를 수행해야 합니다. 즉, 코인을 사용자에게 전송하거나, 다른 개체에 삽입하거나, 다음을 호출하여 다른 개체로 보내야 합니다. 기능(다시 무언가를 해야 함). 물론 coin 모듈에서 coin::burn 함수를 호출하여 코인을 소각하는 것도 가능하지만 의도적으로 소각해야 합니다(우연히 소각할 수는 없습니다).
복제 기능이 없다는 것은 아무도 코인을 복제할 수 없다는 것을 의미하며, 허공에서 새로운 공급을 창출합니다. 새로운 공급량 생성은 coin::mint 함수로 수행할 수 있으며 코인의 재무 기능 개체 소유자만 호출할 수 있습니다.
Move에서 리소스의 보안은 해당 유형으로 정의됩니다. Move에 전역 유형 시스템이 있다는 점을 감안할 때 이는 신뢰할 수 없는 코드 안팎으로 리소스를 직접 전달할 수 있는 보다 자연스럽고 안전한 프로그래밍 모델을 만듭니다.
보조 제목
4.3 바이트코드 검증
앞서 언급했듯이 모바일 스마트 계약은 모듈로 출시됩니다. 누구나 실행할 수 있도록 블록체인에 임의의 모듈을 생성하고 업로드할 수 있습니다. 우리는 또한 Move에 구조체가 사용되는 방식에 대한 규칙이 있음을 확인했습니다.
그렇다면 이러한 규칙이 모든 모듈에서 준수된다는 것을 보장하는 것은 무엇입니까? 사람들이 코인 객체를 수락한 다음 이러한 규칙을 우회하기 위해 내부 필드를 직접 변경하는 것과 같이 특별히 제작된 바이트코드로 모듈을 업로드하는 것을 막는 이유는 무엇입니까? 이렇게 함으로써 모든 코인의 수를 불법적으로 늘릴 수 있습니다. 바이트 코드의 구문만으로도 확실히 이것을 허용합니다.
바이트코드 확인은 이러한 유형의 남용을 방지하는 데 도움이 될 수 있습니다. Move Verifier는 Move 바이트코드를 분석하고 필요한 유형, 메모리 및 리소스 안전 규칙을 준수하는지 여부를 결정하는 정적 분석 도구입니다. 체인에 업로드된 모든 코드는 유효성 검사기를 통과해야 합니다. Move 모듈을 체인에 업로드하려고 하면 노드와 유효성 검사기는 제출을 허용하기 전에 유효성 검사기를 먼저 실행합니다. 모듈이 Move의 보안 규칙을 우회하려고 하면 유효성 검사기에 의해 거부되고 게시되지 않습니다.
Move 바이트코드와 유효성 검사기는 Move의 핵심 혁신입니다. 다른 곳에서는 불가능한 직관적인 리소스 중심 프로그래밍 모델을 구현합니다. 가장 중요한 것은 구조화된 유형이 무결성을 잃지 않고 트러스트 경계를 넘을 수 있다는 것입니다.
Move에서 유형은 모듈 간에 존재합니다. 유형 시스템은 전역입니다. 이는 CPI 호출, 계정 인코딩/디코딩, 계정 소유권 확인 등이 필요하지 않음을 의미합니다. 다른 모듈에서 직접 함수와 인수를 호출하기만 하면 됩니다. 전체 스마트 계약의 유형 및 리소스 안전성은 컴파일/릴리스 시 바이트코드 검증으로 보장되며 Solana와 같은 스마트 계약 수준에서 구현한 다음 런타임에 확인할 필요가 없습니다.
첫 번째 레벨 제목
이제 우리는 Move 프로그래밍이 어떻게 작동하는지, 왜 이것이 근본적으로 안전한지 살펴보았습니다. 따라서 이것이 구성 가능성, 인체 공학 및 보안 관점에서 스마트 계약 프로그래밍에 어떤 영향을 미치는지 자세히 살펴보겠습니다. 여기에서는 Move/Sui의 개발을 EVM 및 Rust/Solana/Anchor와 비교하여 Move의 프로그래밍 모델이 제공하는 이점을 이해하는 데 도움을 줄 것입니다.
보조 제목
5.1 플래시론
플래시 론은 대출 금액을 차용과 동일한 트랜잭션으로 상환해야 하는 DeFi의 대출 유형입니다. 이것의 주요 이점은 거래가 원자적(atomic)이기 때문에 대출이 완전히 무담보화될 수 있다는 것입니다. 이는 원금이 없어도 자산 간의 차익 거래에 사용할 수 있습니다.
이를 달성하는 데 있어 가장 큰 어려움은 플래시 대출 스마트 계약에서 대출 금액이 동일한 거래에서 상환된다는 것을 어떻게 보장합니까? 대출이 무담보가 되려면 트랜잭션이 원자적이어야 합니다. 즉, 동일한 트랜잭션에서 대출 금액이 상환되지 않으면 전체 트랜잭션이 실패해야 합니다.
EVM에는 동적 스케줄링이 있으므로 다음과 같이 이를 달성하기 위해 재진입을 사용할 수 있습니다.
Lightning Loan 사용자는 맞춤형 스마트 계약을 생성 및 업로드하고 계약이 호출되면 다음을 호출하여 제어권이 Lightning Loan 스마트 계약으로 전달됩니다.
그런 다음 플래시 대출 스마트 계약은 요청된 대출 금액을 맞춤형 스마트 계약으로 보내고 맞춤형 스마트 계약에서 executeOperation() 콜백 함수를 호출합니다.
맞춤형 스마트 계약은 받은 대출 금액을 사용하여 필요한 작업(예: 차익 거래)을 수행합니다.
맞춤형 스마트 컨트랙트가 작동을 완료한 후 대출 금액을 플래시론 스마트 컨트랙트에 반환해야 합니다.
이렇게 커스텀 스마트 컨트랙트의 executionOperation()이 완료되고 대출 금액이 제대로 반환되었는지 확인하는 플래시론 스마트 컨트랙트로 컨트롤이 반환됩니다.
맞춤형 스마트 계약이 대출 금액을 올바르게 반환하지 않으면 전체 거래가 실패합니다.
이것은 원하는 기능을 훌륭하게 달성하지만 문제는 재진입에 의존한다는 것입니다. 스마트 계약 프로그래밍에서는 원하지 않습니다. 재진입은 본질적으로 위험하고 악명 높은 DAO 해킹을 포함하여 많은 취약점의 근본 원인이기 때문입니다.
Solana는 재진입을 허용하지 않기 때문에 이 작업을 더 잘 수행합니다. 그러나 재진입 없이 플래시 대출 스마트 계약이 맞춤형 스마트 계약을 다시 호출할 수 없다면 어떻게 솔라나에서 플래시 대출을 구현할 수 있습니까? 성찰의 가르침 덕분입니다. 솔라나에서 각 트랜잭션은 여러 명령(스마트 계약 호출)으로 구성되며 모든 명령에서 동일한 트랜잭션에 존재하는 다른 명령(프로그램 ID, 명령 데이터 및 계정)을 확인할 수 있습니다. 이를 통해 다음과 같이 플래시 론을 구현할 수 있습니다.
번개 대출 스마트 계약은 차용 및 상환 지침을 구현합니다.
사용자는 동일한 트랜잭션에서 차입 및 상환 명령에 대한 호출을 스택하여 플래시 대출 트랜잭션을 생성합니다. 차입 주문이 실행되면 주문 검사를 사용하여 동일한 거래의 후반 단계에서 상환 주문이 예정되어 있는지 확인합니다. 상환 명령의 호출이 존재하지 않거나 유효하지 않은 경우 이 단계에서 트랜잭션이 실패합니다.
빌리고 상환하라는 요청 사이에 빌린 자금은 중간에 있는 다른 명령에서 자유롭게 사용할 수 있습니다.
거래 종료 시 상환 지시 호출은 자금을 Lightning Lender 스마트 계약으로 반환합니다(이 지시의 존재 여부는 차입 지시 반영 시 확인됩니다)
이 솔루션은 충분하지만 여전히 이상적이지는 않습니다. Instruction introspection은 Solana에서 일반적으로 사용되지 않는 다소 특수한 경우이며, 이를 사용하려면 개발자가 많은 개념을 숙달해야 하며 구현 자체도 약간의 뉘앙스가 적절하게 고려되어야 하기 때문에 매우 기술적입니다. 기술적인 한계도 있습니다. 상환 지시는 트랜잭션에 정적으로 존재해야 하므로 트랜잭션 실행 중에 CPI 호출을 통해 동적으로 상환을 호출할 수 없습니다. 이것은 큰 문제는 아니지만 다른 스마트 계약과 통합할 때 코드의 유연성을 다소 제한하고 클라이언트에 더 많은 복잡성을 부여합니다.
Move는 또한 동적 스케줄링 및 재진입을 금지하지만 Solana와 달리 매우 간단하고 자연스러운 플래시 대출 솔루션을 제공합니다. Move의 선형 유형 시스템을 사용하면 트랜잭션 실행 중에 정확히 한 번 소비되도록 보장되는 구조를 만들 수 있습니다. 이것은 키, 저장, 삭제 또는 복제 기능이 없는 구조인 소위 "뜨거운 감자" 패턴입니다. 이 패턴을 구현하는 모듈에는 일반적으로 구조를 인스턴스화하는 함수와 구조를 파괴하는 함수가 있습니다. "뜨거운 감자" 구조체에는 버리기, 키 또는 저장 기능이 없기 때문에 이를 소비하기 위해 파괴 함수가 호출되는 것이 보장됩니다. 모든 모듈의 다른 함수에 전달할 수 있지만 궁극적으로 destroy 함수에서 끝나야 합니다. 다른 처리 방법이 없고 검증인이 트랜잭션 종료 시 폐기를 요구하기 때문입니다(폐기 기능이 없으므로 임의로 폐기할 수 없습니다).
이를 사용하여 플래시 대출을 구현하는 방법을 살펴보겠습니다.
번개 대출 스마트 계약은 "뜨거운 감자" 영수증(Receipt) 구조를 구현합니다.
대출 기능을 호출하여 대출이 이루어지면 호출자에게 요청된 자금(코인 1개)과 상환해야 할 대출 금액을 기록하는 영수증이라는 두 가지 개체를 보냅니다.
그런 다음 차용자는 받은 자금을 필요한 작업(예: 차익 거래)에 사용할 수 있습니다.
차용인이 의도한 작업을 완료한 후 상환 기능을 호출해야 합니다. 이 기능은 차용 자금과 영수증을 매개변수로 받습니다. 이 함수는 호출자가 영수증 인스턴스를 제거할 수 있는 다른 방법이 없기 때문에 동일한 트랜잭션 내에서 호출되도록 보장됩니다(유효성 검사자가 요구하는 다른 개체에 포함되거나 폐기될 수 없음).
상환 기능은 영수증에 내장된 대출 정보를 읽어 정확한 금액이 반환되었는지 확인합니다.
Move의 자원 안전 기능은 재진입 또는 검사를 사용하지 않고 Move에서 플래시 대출을 가능하게 합니다. 그들은 영수증이 신뢰할 수 없는 코드에 의해 수정될 수 없도록 보장하고 거래가 끝날 때 상환 기능으로 반환되어야 합니다. 이렇게 하면 동일한 거래에서 정확한 금액의 자금이 반환된다는 것을 보장할 수 있습니다.
Flash Loan은 Move의 선형 유형 시스템 및 리소스 안전 보장을 통해 다른 프로그래밍 언어가 할 수 없는 방식으로 기능을 표현할 수 있는 방법을 보여주는 좋은 예입니다.
보조 제목
5.2 조폐국 잠금
"발행 권한 잠금" 스마트 계약은 토큰 발행 기능을 확장하여 화이트리스트에 있는 여러 당사자(기관)가 토큰을 발행할 수 있도록 합니다. 이 스마트 계약의 원하는 기능은 다음과 같습니다(Solana 및 Sui 구현 모두에 대해).
원래 토큰 발행 권한은 스마트 계약이 발행을 감독할 수 있도록 "조립 잠금"을 생성합니다. 호출자는 mintlock의 관리자가 됩니다.
관리자는 이 잠금에 대한 추가 발행 권한을 생성할 수 있으며, 이는 다른 당사자에게 위임할 수 있으며 언제든지 이 잠금을 사용하여 토큰을 발행할 수 있습니다.
각 발행 승인에는 발행할 수 있는 토큰 수에 대한 일일 제한이 있습니다.
관리자는 언제든지 채굴 권한을 차단(및 차단 해제)할 수 있습니다.
관리자의 권한을 다른 당사자에게 양도할 수 있습니다.
이 스마트 계약은 예를 들어 토큰의 발행 권한을 다른 사용자 또는 스마트 계약으로 이전하는 데 사용할 수 있으며, 동시에 원래 발행 기관(관리자)은 여전히 발행에 대한 통제권을 유지합니다. 그렇지 않으면 우리는 채굴에 대한 모든 권한을 다른 당사자에게 넘겨야 할 것입니다. 이는 그 권한을 남용하지 않도록 신뢰해야 하기 때문에 이상적이지 않습니다. 그리고 여러 당사자에게 권한을 부여하는 것은 불가능합니다.
이러한 스마트 계약의 전체 구현은 여기(Solana) 및 여기(Sui)에서 찾을 수 있습니다.
참고: 프로덕션 환경에서 이 코드를 사용하지 마십시오. 이것은 교육 목적으로만 제공되는 샘플 코드입니다. 기능을 테스트하는 동안 철저한 감사 또는 보안 테스트를 수행하지 않았습니다.
이제 코드를 살펴보고 구현이 어떻게 다른지 살펴보겠습니다. 아래는 이 스마트 계약의 전체 Solana 및 Sui 구현에 대한 코드 스크린샷입니다.
동일한 기능에 대해 Solana의 구현이 Sui보다 두 배 이상 크다는 것을 알 수 있습니다(230 LOC vs 104). 일반적으로 코드가 적다는 것은 버그가 적고 개발 시간이 짧다는 것을 의미하기 때문에 이것은 큰 문제입니다.
그렇다면 Solana는 이러한 추가 행을 어디에서 얻었습니까? Solana의 코드를 자세히 살펴보면 명령 구현(스마트 계약 논리)과 계정 확인의 두 부분으로 나눌 수 있습니다. 명령어 구현은 Sui에 있는 것과 비교적 비슷합니다. --- Solana에는 136줄이 있고 Sui에는 104줄이 있습니다. 추가 라인 수는 두 개의 CPI 호출(각각 약 10 LOC)의 참조 때문입니다. 가장 중요한 차이점은 계정 확인(위 스크린샷에서 빨간색으로 표시됨)에 있습니다. 이는 솔라나에서는 필수(사실상 중요)이지만 무브에서는 필요하지 않습니다. 계정 확인은 이 스마트 계약의 약 40%(91 LOC)를 차지합니다.
이동에는 계정 확인이 필요하지 않습니다. LOC의 감소는 이점을 가져올 수 있지만 계정 확인을 제거하는 것도 필요합니다. 이러한 확인을 올바르게 구현하는 것은 매우 까다롭고 한 가지 실수라도 종종 중대한 위반 및 사용자 자금 손실로 이어질 수 있기 때문입니다. 실제로 가장 큰(사용자 자금 손실 측면에서) Solana 스마트 계약 취약점 중 일부는 부적절한 계정 확인으로 인한 계정 대체 공격이었습니다.
- 웜홀(3억 3,600만 달러) - https://rekt.news/wormhole-rekt/
-캐시오(4,800만 달러) - https://rekt.news/cashio-rekt/
- 크레마 파이낸스(880만 달러) - https://rekt.news/crema-finance-rekt/
그렇다면 이러한 검사 없이 Move가 어떻게 안전할 수 있을까요? 이러한 검사가 실제로 수행하는 작업을 자세히 살펴보겠습니다. 다음은 mint_to 명령에 필요한 계정 확인입니다(권한 보유자는 이 명령을 호출하여 토큰을 발행합니다).
6개의 확인 항목이 있습니다(빨간색으로 표시됨).
1. 제공된 잠금 계정이 스마트 컨트랙트 소유인지, MintLock 유형인지 확인합니다. 들어오는 잠금은 (권한을 저장하는) 생성을 위한 토큰 프로그램에 대한 CPI 호출에 사용되기 때문에 필요합니다.
2. 제공된 채굴 권한 계정이 제공된 락에 속하는지 확인합니다. 발행 기관 계정은 권한 상태(공개 키, 금지 여부 등)를 보유합니다.
3. 명령 호출자가 권한에 필요한 키를 가지고 있는지 확인합니다(필요한 권한이 트랜잭션에 서명함).
4. 토큰 프로그램이 CPI 호출에서 변경(잔액 증가)하기 때문에 토큰 대상 계정을 전달해야 합니다. 잘못된 계정이 전달되면 CPI 호출이 실패하므로 발행 확인이 꼭 필요한 것은 아니지만 여전히 좋은 방법입니다.
5. 4와 유사합니다.
6. 토큰 프로그램 계정이 올바르게 전달되었는지 확인하십시오.
계정 확인(이 예에서)이 다음 5가지 범주로 분류되는 것을 볼 수 있습니다.
계정 소유권 확인(1, 2, 4, 5)
계정 유형 확인(1, 2, 4, 5)
계정 인스턴스 확인(계정 유형의 올바른 인스턴스가 전달되었는지 여부)(2, 5)
계좌 서명 확인(3)
프로그램 계정 주소 확인(6)
그러나 Move에는 계정 확인이나 그와 유사한 것이 없으며 함수 서명만 있습니다.
mint_balance 함수에는 4개의 매개변수만 필요합니다. 이 네 가지 매개변수 중에서 lock과 cap만이 개체를 나타냅니다(계정과 다소 유사함).
Solana에서는 6개의 계정을 선언하고 다양한 검사를 수동으로 구현해야 하는 반면 Move에서는 2개의 객체만 전달하면 되고 명시적인 검사가 필요하지 않습니다.
Move에서 이러한 검사 중 일부는 런타임에 투명하게 수행되고 일부는 컴파일 타임에 유효성 검사기에 의해 정적으로 수행되며 일부는 생성 시 전혀 필요하지 않습니다.
계정 소유권 확인 - Move에는 유형 시스템이 있으므로 이 디자인은 필요하지 않습니다. Move 구조는 모듈에 정의된 함수에 의해서만 변경될 수 있으며 직접 변경될 수 없습니다. 바이트코드 확인은 구조체 인스턴스가 불법적으로 변경되지 않고 신뢰할 수 없는 코드(다른 모듈)로 자유롭게 흐를 수 있도록 합니다.
계정 유형 확인 - 이동 유형이 스마트 계약 전체에 존재하므로 필요하지 않습니다. 유형 정의는 모듈 바이너리에 포함됩니다(블록체인에 게시되고 가상 머신에 의해 실행됨). 유효성 검사기는 컴파일/게시 중에 함수가 호출될 때 올바른 유형이 전달되는지 확인합니다.
계정 인스턴스 확인 - Move(때때로 Solana에서도)에서 함수 본문에서 이 작업을 수행합니다. 이 특별한 경우에는 잠금 및 캡 매개변수 유형의 일반 유형 매개변수 T가 들어오는 캡(조폐 능력/권한) 객체가 해당 잠금과 올바르게 일치하도록 강제하기 때문에 이는 필요하지 않습니다(각 코인 유형 T는 잠금만 가질 수 있음).
계정 서명 확인 - Sui에서 직접 서명을 처리하지 않습니다. 개체는 사용자가 소유할 수 있습니다. Minting 권한은 Minting Authority 능력 개체(관리자가 생성)의 소유권에 따라 부여됩니다. mint_balance 함수에서 이 개체에 대한 참조를 전달하면 발행할 수 있습니다. 소유한 객체는 소유자가 트랜잭션에서만 사용할 수 있습니다. 즉, 개체의 서명 확인은 런타임에 의해 투명하게 수행됩니다.
기본적으로 Move는 바이트코드 검증을 활용하여 디지털 자산에 대한 프로그래밍 모델을 보다 자연스럽게 만듭니다. Solana의 모델은 계정 소유권, 서명, CPI 호출, PDA 등을 중심으로 합니다. 하지만 뒤로 물러서서 생각해 보면 이러한 문제를 다루고 싶지 않다는 것을 깨닫게 됩니다. 그것들은 디지털 자산 자체와 관련이 없습니다. 오히려 Solana의 프로그래밍 모델에서 원하는 기능을 구현할 수 있기 때문에 우리는 그것들을 사용해야 합니다.
솔라나에서는 보다 세분화된 유형이나 자원의 안전을 보장하기 위한 바이트코드 검증이 없으며, 어떤 프로그램도 계정을 변경하도록 허용할 수 없으므로 계정 소유권 개념을 도입할 필요가 있습니다. 유사한 이유로(프로그램 호출 전반에 걸쳐 유형/리소스 안전성이 없음) 프로그램에 들어가고 나갈 수 있는 사용자 소유 개체에 대한 개념이 없으며 대신 권한을 증명하기 위해 계정 서명을 사용합니다. 때때로 프로그램은 계정 서명을 제공할 수 있어야 하므로 PDA...
Move의 기본 리소스 추상화를 통해 PDA와 같은 낮은 수준의 빌딩 블록을 도입하지 않고도 리소스를 직접 조작할 수 있습니다. 스마트 계약 경계를 넘어 유형 및 리소스 안전 보장은 유효성 검사기에 의해 보장되며 수동으로 구현할 필요가 없습니다.
보조 제목
5.3 솔라나 결합성의 한계
솔라나에서 스마트 컨트랙트 구성 가능성의 몇 가지 문제점을 강조하기 위해 한 가지 예를 더 들고 싶습니다.
Mint 권한 잠금 예제에서 Sui에 비해 Solana에서 더 많은 입력을 선언해야 한다는 것을 확인했습니다(mint_to는 Solana에서 6개의 계정을 호출하고 Sui에서는 2개의 객체를 호출함). 분명히 6개의 계정을 처리하는 것이 2개의 개체를 처리하는 것보다 더 번거로운 일입니다. 특히 계정에 대한 계정 확인도 구현해야 한다고 생각하는 경우에는 더욱 그렇습니다. 이론적으로 이 부분은 관리할 수 있지만 한 번의 호출로 여러 개의 서로 다른 스마트 계약을 함께 작성하기 시작하면 어떻게 될까요?
다음을 수행할 수 있는 스마트 계약을 만들고 싶다고 가정합니다.
발행 권한 잠금 프로그램에서 특정 토큰을 발행할 수 있는 권한을 가지며 발행할 수 있습니다.
호출되면 권한을 사용하여 사용자가 지정한 양의 토큰을 발행하고 AMM을 사용하여 다른 토큰으로 교환하고 동일한 명령으로 사용자에게 보냅니다.
이 예제의 초점은 발행 기관 잠금 스마트 계약과 AMM 스마트 계약이 결합되는 방법을 설명하는 것입니다. 명령에 의해 호출되는 계정 확인은 다음과 같습니다.
17개의 계정. CPI 호출당 5-6개의 프로그램(민팅 및 스와핑)과 프로그램 계정.
Sui에서 동등한 함수의 서명은 다음과 같습니다.
개체는 3개뿐입니다.
Solana의 계정에 비해 Sui에서 전달하는 개체 수가 훨씬 적은 이유는 무엇입니까(3 대 17)? 기본적으로 Move에서 포함(래핑)할 수 있기 때문입니다. 유형 시스템의 안전 보장을 통해 이를 수행할 수 있습니다.
아래는 AMM 풀의 상태를 유지하는 Solana 계정과 Sui 객체를 비교한 것입니다.
우리는 Solana에서 포인터와 같은 다른 계정의 주소(Pubkeys)를 저장하고 실제 데이터를 저장하지 않는 것을 볼 수 있습니다. 이러한 계정에 액세스하려면 개별적으로 전달되어야 하며 올바른 계정이 전달되었는지 수동으로 확인해야 합니다. Move에서 우리는 구조를 서로 포함하고 해당 값에 직접 액세스할 수 있습니다. Move의 글로벌 유형 시스템과 바이트코드 검증에 의해 구동되는 자원 안전 덕분에 자원 및 유형 안전 보장을 유지하면서 모든 모듈의 유형을 혼합하고 일치시킬 수 있습니다.
그러나 여러 개의 스마트 계약을 작성할 때 많은 계정을 전달(따라서 확인)해야 하므로 구현이 상당히 복잡하고 보안에 영향을 미칩니다. 이러한 계정 간의 관계는 필요한 모든 계정 확인을 추적하고 올바르게 구현되었는지 여부를 추적하기 어려울 정도로 매우 복잡할 수 있습니다.
사실, 그것이 Cashio 유출 사건(4,800만 달러)에서 일어난 일이라고 생각합니다. 다음은 취약점으로 이어진 (부적절한) 계정 확인의 분석입니다. 보시다시피 이러한 계정 확인은 조금 더 복잡해집니다. 개발자는 올바르게 확인하려는 의도는 좋지만 어느 순간 정신적 압박이 너무 커지고 오류가 발생하기 쉽습니다. 계정이 많을수록 오류가 발생하기 쉽습니다.
Move의 글로벌 유형 시스템과 보다 자연스러운 프로그래밍 모델은 심리적 스트레스의 한계에 도달하기 전에 보다 안전한 스마트 계약 구성을 추진할 수 있음을 의미합니다.
Move는 TCB 감소를 염두에 두고 설계되었습니다. Move는 TCB를 최대한 최소화하기 위해 여러 가지 결정을 내렸습니다. 바이트코드 검증기는 TCB에서 Move 컴파일러가 수행하는 많은 검사를 제거하는 반면 Rust/Anchor에는 신뢰할 필요가 있는 더 많은 구성 요소가 있으므로 치명적인 보안 버그에 대한 노출 영역이 더 큽니다.
첫 번째 레벨 제목
Move on Solana를 사용할 수 있습니까? 어떻게 할 수 있습니까?
보조 제목
6.1 전역적으로 안전한 앵커가 있습니까?
시작하기 전에 Anchor를 간단히 살펴보고 약간의 사고 실험을 해 봅시다. Move에서 얻을 수 있는 이점 중 일부를 제공하기 위해 Anchor를 어떻게든 업그레이드할 수 있을까요? 프로시저 간 호출에 대해 형식이 안전한 기본 지원을 받을 수 있을까요? 결국 Anchor 명령은 이미 Move의 진입 기능과 유사합니다.
계정을 명령 매개변수에 직접 전달할 수 있도록 Anchor를 확장할 수 있습니다.
계정 확인을 피할 수 있습니까?
이 경우 프로그램이 아닌 실행에 의해 유형 검사가 수행되기를 원합니다. 실행은 Anchor 계정 구분자(또는 이와 동등한 항목)를 읽고 전달된 계정이 필요한 구분자(Anchor 계정의 처음 8바이트).
Solana는 동일한 프로그램의 서로 다른 명령 호출을 구분하지 않으며, 이것은 프로그램에 의해 수동으로 구현됩니다(이 경우 무거운 작업은 Anchor에 의해 수행됨). 따라서 이를 수행하기 위해 런타임은 다른 명령어, 해당 서명, 유형 정보에 대해 어떻게든 알고 있어야 합니다.
Solana 프로그램은 SBF(Solana Bytecode Format, eBPF의 변형)로 컴파일되고 이러한 방식으로 체인에 업로드(및 실행)됩니다. SBF 자체에는 우리에게 도움이 되는 유형이나 함수 정보가 포함되어 있지 않습니다. 하지만 명령과 유형 정보를 바이너리에 포함하도록 SBF를 수정할 수 있을까요? 이렇게 하면 런타임이 바이너리에서 필요한 지침과 서명 정보를 읽을 수 있습니다.
우리는 실제로 이것을 할 수 있습니다. 특히 이전 프로그램과의 하위 호환성을 유지해야 한다는 점을 감안할 때 상당한 양의 엔지니어링이 필요하지만 다음과 같은 결과를 얻을 수 있습니다.
- 프로그램이 아닌 실행으로 계정 소유권 및 유형 확인
- 컴파일 타임에 주소가 알려진 계정(예: 프로그램 계정)의 경우 클라이언트에서 전달하는 것을 피할 수 있으며 이제 실행으로 전달할 수 있습니다.
- 바이너리에 계정 제약 조건을 포함하는 경우 클라이언트가 전달해야 하는 계정 수를 더 줄이고 런타임에 동적으로 다시 로드할 수 있습니다(포함된 제약 정보를 기반으로 함).
우리는 여전히 다음을 얻지 못합니다.
- 임베디드 계정. 우리는 여전히 다른 계정을 참조하기 위해 Pubkeys를 사용해야 하며 직접 삽입할 수 없습니다. 이것은 우리가 섹션 5.3에서 설명한 계정 팽창 문제를 제거하지 않는다는 것을 의미합니다.
- 프로그램 간 호출을 수행할 때 계정 유형 확인은 Move에서와 같이 컴파일 시간에 정적으로 수행되는 것이 아니라 런타임에 동적으로 수행되어야 합니다.
참고: 이것은 사고 실험일 뿐입니다. 안전하게 완료할 수 있다는 의미도 아니고 달성하기 어렵다는 의미도 아니며 이러한 이점이 공학적으로 노력할 가치가 있다고 광고하지도 않습니다.
이러한 이점은 확실히 좋지만 스마트 계약 개발 관점에서 근본적으로 아무것도 바꾸지 않습니다. 프로그램에서가 아니라 런타임에 유형 검사를 수행하면 약간의 성능상의 이점을 얻을 수 있으며 컴파일 시간에 클라이언트에서 수동으로 주소 계정을 전달할 필요가 없으므로 인체 공학이 어느 정도 향상됩니다(이는 도구로 완화할 수도 있음). 그러나 우리는 여전히 디지털 자산을 처리하는 데 더 많은 도움을 제공하는 Solana의 프로그래밍 모델을 궁극적으로 다루고 있습니다. 우리는 여전히 기본 리소스 보안이 없으며 계정을 포함할 수 없으므로 여전히 계정 팽창이 있습니다. 계정 서명 및 PDA로...
우리는 자연스러운 프로그래밍 모델을 원하지만 동시에 신뢰할 수 없는 코드를 다루고 있습니다. Solana에서 신뢰할 수 없는 코드를 안전하게 처리할 수 있지만 프로그래밍 모델에는 타협이 있습니다. 바이트코드 확인을 통해 우리는 둘 다 가질 수 있습니다. 그것 없이는 프로그래밍 모델을 개선할 수 없는 것 같습니다.
보조 제목
6.2 Solana 바이트코드 형식
앞서 언급한 바와 같이 솔라나 스마트 컨트랙트의 컴파일 및 온체인 스토리지 포맷인 SBF(Solana Bytecode Format)는 eBPF를 기반으로 합니다. 다른 바이트코드 형식(예: WASM) 대신 Solana에서 eBPF를 사용하는 것은 주로 Solana의 안전한 고성능 스마트 계약 실행 요구 사항이 eBPF 설계의 커널 샌드박스 프로그램 실행 요구 사항과 일치하기 때문입니다(보안 및 고성능도 필요함).
표면적으로는 eBPF가 확실한 선택입니다. 보안을 중심으로 설계된 고성능, 프로그램 크기 및 명령 수가 제한되어 있고 바이트코드 검증기가 있습니다... 멋져 보입니다.
그러나 이것이 실제로 무엇을 의미하는지 봅시다. 어떻게든 eBPF 유효성 검사기를 활용하여 스마트 계약의 보안을 개선할 수 있을까요? 다음은 eBPF 유효성 검사기가 수행하는 작업 중 일부입니다.
- 무한 루프를 허용하지 않습니다.
- 프로그램이 DAG(Directed Acyclic Graph)인지 확인
- 범위를 벗어난 점프는 허용되지 않습니다.
- 다양한 헬퍼 함수를 호출할 때 매개변수 유형을 확인합니다(헬퍼 함수는 커널에서 정의됩니다(예: 네트워크 패킷 수정).
글쎄, 범위를 벗어난 점프를 허용하지 않는 것은 유용해 보이지만 그렇지 않으면 제한적입니다. 사실, 프로그램이 DAG여야 하고 무한 루프가 없어야 한다고 명령하는 것은 프로그램의 운용성을 크게 제한하기 때문에 문제가 됩니다(Turing 완전성이 없습니다). 이것이 eBPF 프로그램에서 필요한 이유는 검증자가 프로그램이 특정 수의 명령 내에서 종료되는지 확인해야 하기 때문입니다(프로그램이 커널을 종료시키지 않도록 합니다. 이것은 유명한 정지 문제입니다). 미터링은 성능에 너무 많은 영향을 미치므로 옵션이 아닙니다.
이러한 절충은 고성능 방화벽을 구현하는 데는 좋지만 스마트 계약 개발에는 그리 좋지 않습니다. 대부분의 eBPF 유효성 검사기는 Solana 프로그램에서 재사용할 수 없습니다. 사실, Solana는 원래의 eBPF 유효성 검사기를 전혀 사용하지 않고 기본적으로 올바른 지침과 범위를 벗어난 점프를 확인하는 (더 기본적인) 사용자 지정 유효성 검사기를 사용합니다.
동시에 eBPF는 호출을 위해 최대 5개의 매개변수를 함수에 전달할 수 있도록 설계되었습니다. 이는 Rust 표준 라이브러리를 eBPF로 직접 컴파일할 수 없음을 의미합니다. 또는 스택 크기가 512바이트로 제한되어 힙 할당 없이 함수에 전달할 수 있는 인수의 크기가 줄어듭니다.
따라서 Rust가 LLVM으로 컴파일되고 LLVM용 eBPF 백엔드가 있고 eBPF용 Rust 컴파일러를 지원하더라도 Solana 스마트 계약이 eBPF로 컴파일되도록 할 수는 없습니다. 이것이 솔라나 팀이 Rust 코드베이스와 eBPF LLVM 백엔드(예: 스택을 통해 인수 전달)를 여러 번 수정해야 했던 이유입니다.
이러한 변경 사항 중 일부는 기본 지원 업스트림(Rust 또는 LLVM)이므로 Solana 팀은 현재 Rust 및 LLVM의 포크를 모두 유지 관리합니다. cargo build-bpf (Solana 스마트 컨트랙트를 구축하기 위한 일반적인 명령어)를 실행할 때, Cargo는 스마트 컨트랙트를 컴파일하기 위해 이 Solana 전용 버전의 rustc (Rust 프로그래밍 언어용 컴파일러)를 풀링할 것입니다 (원래의 rustc는 작동하지 않을 것입니다) ) .
이것이 SBF가 탄생한 방식입니다. Solana는 eBPF와 호환되지 않는 몇 가지 요구 사항을 요구합니다. Solana 팀은 현재 SBF를 별도의 LLVM 백엔드로 업스트림하고 별도의 포크를 유지하지 않도록 Rust 대상으로 추가하는 작업을 하고 있습니다.
따라서 eBPF는 스마트 계약의 형식으로 사용할 수 있지만 표면적으로 보이는 것처럼 이상적이지는 않습니다. 약간의 수정이 필요했으며 원래 유효성 검사기는 그다지 유용하지 않았습니다.
Move 및 Solana/SBF에 대한 논의에서 일부 사람들은 Move의 주요 아이디어가 eBPF를 기반으로 하기 때문에 SBF에 적용되어야 한다고 생각하는 오해가 있습니다. 런타임에 동적 검사를 수행합니다.
제 생각에는 이것은 모호한 주장입니다. 프로그램이 자신이 소유하지 않은 eBPF의 계정을 변경하지 않는다는 것을 증명하는 것이 가능하더라도(정확히 Move가 수행하는 작업) 이것이 Move의 주요 아이디어는 아닙니다.
Move의 주요 아이디어는 신뢰할 수 없는 코드와 자연스럽게 상호 작용할 수 있는 리소스 중심 프로그래밍 모델을 만드는 것입니다.
실제로 이는 다음을 의미합니다.
글로벌 유형 안전
리소스 보안(키, 복제, 숨김, 삭제)
포함 가능한 리소스
...
리소스는 신뢰할 수 없는 코드 간에 안전하게 흐릅니다.
주요 Move 아이디어를 eBPF/SBF에 도입하는 것은 매우 어렵습니다. "이 신뢰할 수 없는 코드는 T를 삭제할 수 없습니다"와 같은 속성을 적용하는 것은 eBPF를 크게 변경하지 않고는 불가능합니다. 이를 위해서는 많은 수정이 필요하므로 eBPF보다 Move에 더 가까운 새로운 바이트코드로 끝납니다.
사실 무브가 처음 탄생하게 된 것도 비슷한 생각이었다. Move 팀(당시 Diem)은 처음에 WASM, JVM 또는 CLR과 같은 다른 형식으로 시작하는 것을 고려했지만 나중에 추가하는 것이 너무 어려웠습니다. 선형성/용량이 틀에 얽매이지 않았기 때문입니다. 그래서 Move는 처음부터 경량 유효성 검사기 채널을 통해 이러한 검사를 효율적으로 수행한다는 아이디어로 설계되었습니다.
당신이 그것에 대해 생각한다면 이것은 실제로 그렇게 놀라운 일이 아닙니다. 결국 스마트 계약 프로그래밍은 시스템 프로그래밍, 백엔드 프로그래밍 또는 기타 전통적인 프로그래밍이 아니라 완전히 다른 유형의 프로그래밍입니다. 따라서 완전히 다른 사용 사례를 염두에 두고 설계되었기 때문에 기존 바이트 코드 및 명령 형식의 기능을 활용할 수 없다는 것은 놀라운 일이 아닙니다.
나는 eBPF를 사용하는 솔라나를 비난하는 것이 아닙니다. 사실, 상황을 감안할 때 팀의 꽤 확실한 선택이자 좋은 판단이라고 생각합니다. 돌이켜 보면 팀은 eBPF 대신 WASM을 선택했을 수 있습니다. 그러면 앞서 언급한 스마트 계약을 eBPF로 컴파일하는 문제를 피할 수 있었을 것입니다. 왜냐하면 WASM은 Rust에서 최고 수준의 지원을 제공하기 때문입니다(WASM에는 다른 문제가 있을 수 있음). 팀은 성능에 중점을 둔 eBPF가 더 안전한 선택이라고 느낄 수 있습니다. 게다가 이러한 디자인 선택이 이루어질 당시에는 Move가 발표되지도 않았으며 처음부터 새로운 언어를 만드는 것은 확실히 신생 기업을 위한 합리적인 선택이 아니었습니다. 궁극적으로 Solana는 성공적인 고성능 L1을 제공하는 데 성공했으며 이것이 중요한 것입니다.
Move on Solana를 얻는 방법에는 세 가지가 있습니다.
Move vm을 로컬 로더로 추가(SBF vm과 함께)
Move 가상 머신을 프로그램(예: Neon)으로 실행
SBF로 컴파일 이동(Solang과 동일)
먼저 (3)에 대해 논의해 봅시다. 여기서 아이디어는 SBF로 컴파일되도록 Move용 LLVM 프런트 엔드를 갖는 것입니다. SBF로 컴파일된 Move 스마트 계약은 Rust(또는 SBF로 컴파일할 수 있는 다른 언어)로 빌드된 스마트 계약처럼 투명하게 실행되며 런타임에 Move에 대한 구분이나 지식이 필요하지 않습니다. 운영 관점에서 이것은 보안 가정을 변경할 필요가 없기 때문에 매우 우아한 솔루션이 될 것입니다.
하지만 이런 식으로 스마트 계약을 개발하는 것은 Anchor를 직접 사용하는 것보다 더 나쁠 것이라고 생각합니다. (3)에서 얻는 것은 Solana 프로그래밍 모델의 Move 구문입니다. 이는 5장에서 논의한 Move의 모든 중요한 이점(전역 유형 안전성, 전역 자원 안전성, 포함 가능한 개체...)이 더 이상 존재하지 않음을 의미합니다. 대신 Rust에서와 마찬가지로 여전히 계정 확인, CPI 호출, PDA 등을 처리해야 합니다. 그리고 Move는 매크로를 지원하지 않기 때문에 이 작업 중 일부를 단순화하기 위해 eDSL을 사용하여 Anchor와 같은 프레임워크를 구현하는 것은 불가능합니다. 따라서 코드는 바닐라 Rust와 비슷할 것입니다. Rust 표준 라이브러리 및 생태계도 사용할 수 없으므로 계정 직렬화 및 역직렬화와 같은 기능을 Move에서 다시 구현해야 합니다.
Move는 다른 프로그래밍 모델과 함께 사용하기에 적합하지 않습니다. 이는 Move 바이트코드로 컴파일하고 유효성 검사기를 통과하도록 특별히 설계되었기 때문입니다. 이는 능력 및 차용 체커에 대한 사용자 지정 규칙을 고려할 때 필요합니다. 바이트코드 검증은 매우 구체적이어서 다른 언어는 Move 바이트코드로 컴파일하고 검증자를 통과할 가능성이 거의 없습니다. Move는 매우 특정한 종류의 바이트코드 검증을 중심으로 구축되었기 때문에 Rust와 같은 언어만큼 유연하지 않습니다.
바이트 코드를 제거하면 Move의 주요 이점이 모두 사라집니다. Move의 유형, 리소스 및 메모리 안전 기능은 프로그램 수준에서 보존되지만 전역적으로 보존되지는 않습니다. 그리고 프로그램 수준의 안전성은 많은 새로운 결과를 가져오지 않습니다. 이미 Rust로 달성했습니다.
Move의 스마트 계약 생태계도 Solana에서 작동하지 않습니다. 프로그래밍 모델이 너무 다르기 때문에 스마트 계약의 상당 부분을 다시 작성해야 합니다. 이 모든 것을 고려할 때 (3)으로 Move를 구현하는 것은 허용되지 않을 것이라고 예측합니다.
(1)의 경우 여기서 아이디어는 (SBF 로더와 함께) 런타임에 Move 로더에 대한 지원을 추가하는 것입니다. Move 스마트 계약은 Move 바이트코드 온체인으로 저장되고 Move VM에 의해 실행됩니다(Sui에서처럼). 이것은 우리가 SBF 스마트 계약의 생태계와 Move 스마트 계약의 생태계를 갖게 된다는 것을 의미합니다. 전자는 현재 Solana 프로그래밍 모델에서 실행되고 후자는 (아마도 더 발전된) Move 모델에서 실행됩니다.
이 접근 방식을 사용하면 Move 스마트 계약 간 상호 작용의 모든 이점을 유지할 수 있지만 여기서 한 가지 문제는 Move 스마트 계약이 SBF 스마트 계약과 상호 작용할 수 있도록 하는 것입니다. 솔라나에 대해 깊이 이해하고 있는 검증인도 조정해야 합니다.
런타임에 두 개의 서로 다른 로더를 유지 관리해야 하는 단점도 있습니다. 이는 공격 표면이 두 배가 됨을 의미하므로 보안에 영향을 미칩니다. 단일 로더 오류는 전체 체인이 악용될 수 있음을 의미할 수 있습니다. MoveVM에 대한 초기 지원은 실제로 2019년에 Solana에 추가되었지만(#5150) 나중에 보안 문제로 인해 제거되었습니다(#11184).
(2)의 경우 전체 Move VM을 하나의 Solana 프로그램(스마트 계약)으로 실행하는 아이디어입니다. Move VM은 Rust에서 구현되므로 아마도 SBF로 컴파일될 것입니다(스레드 또는 기타 지원되지 않는 API를 사용하지 않는 한). 이상하게 들리겠지만 Neon은 EVM을 Solana 프로그램으로 실행하는 유사한 접근 방식을 구현했습니다. 이 접근 방식의 이점은 실행에 대한 수정이 필요하지 않고 동일한 보안 가정을 유지할 수 있다는 것입니다.
Move의 주요 기능을 Solana로 가져오는 직접적인 방법은 없습니다. LLVM 프런트 엔드를 구축하고 Move to SBF를 컴파일하는 것은 가능하지만 프로그래밍 모델이 동일하게 유지되기 때문에 이것은 별로 도움이 되지 않습니다. 섹션 6.1의 사고 실험에서 알 수 있듯이 프로그래밍 모델은 일종의 바이트 코드 확인 없이는 개선될 수 없습니다. 바이트코드 검증을 지원하도록 eBPF/SBF를 변경하는 것은 매우 어려울 것입니다. 유일한 합리적인 옵션은 어떻게든 MoveVM을 실행하는 것 같습니다. 그러나 이것은 서로 다른 프로그래밍 모델에서 작동하는 두 개의 생태계가 있음을 의미하며 이들을 적절하게 상호 운용하는 것은 매우 어려운 일입니다.
보조 제목
6.4 이동의 수행
Move의 바이트코드는 범용 바이트코드 언어가 아닙니다. 필요한 모든 유효성 검사를 허용하도록 상당히 발전된 매우 "주장적인" 유형 시스템을 가지고 있습니다. 이는 네이티브 코드에 가까운 eBPF/SBF와 같은 다른 바이트코드 형식에 비해 성능이 낮다는 것을 의미하며 고성능 L1에서 사용하기에는 문제가 될 수 있습니다.
그러나 지금까지 스마트 계약 실행은 Solana(작성 당시 평균 3k TPS) 또는 Sui(팀이 수행한 초기 e2e 벤치마크 기반)에서 병목 현상이 되지 않았습니다. 트랜잭션 처리 성능을 향상시키는 주요 방법은 병렬 실행입니다. Solana와 Sui는 서로 다른 개체/계정 세트에 의존하는 트랜잭션 실행의 병렬 스케줄링과 종속성의 사전 선언을 요구함으로써 이를 구현합니다.
이 모든 것을 염두에 두고 Move의 성능이 가까운 미래에 큰 장애가 되지 않기를 바랍니다.
7. Move의 기타 기능
보조 제목
7.1 검증자
Move에는 Move Prover라는 스마트 계약용 공식 검증 도구가 있습니다. 이 도구를 사용하면 스마트 계약에 대해 다른 불변성이 유지되는지 여부를 판단할 수 있습니다. 배후에서 검증 조건은 SMT 공식으로 변환된 다음 SMT 솔버를 사용하여 확인됩니다. 이것은 예를 들어 입력 공간을 걸어다니면서 시행착오를 겪는 퍼징과는 매우 다릅니다. 예를 들어 퍼징 및 단위/통합 테스트는 특정 입력 또는 입력 조합에 대한 테스트에 실패할 경우 프로그램의 버그를 나타내는 잘못된 긍정을 제공할 수 있습니다. 반면에 Verifier는 기본적으로 제공된 프로그램에 대해 지정된 불변성이 유지되는 공식 증명을 제공합니다. 가능한 모든 입력에 대해 프로그램을 확인하는 것과 같지만 그럴 필요는 없습니다.
아래는 유효성 검사기의 예입니다("Move Prover를 사용한 스마트 계약의 빠르고 안정적인 공식 검증" 백서에서 가져옴).
보조 제목
7.2 지갑 보안
Sui는 트랜잭션이 액세스할 모든 개체가 함수 인수(글로벌 상태에서 동적으로 로드되지 않음)로 전달되고 이동 함수 서명이 유형 정보와 함께 바이트코드 자체에 저장되도록 요구하므로 지갑에서 보낼 수 있습니다. 사용자는 제공합니다. 거래 내용을 설명하는 더 의미 있는 정보.
예를 들어 다음과 같은 시그니처가 있는 함수가 있다고 가정합니다.
이 트랜잭션이 사용자의 3가지 자산(자산 유형)에 액세스한다는 것을 함수의 서명에서 볼 수 있습니다. 뿐만 아니라 & 및 &mut 키워드(또는 키워드 없음)에 따라 자산 1을 읽을 수 있고, 자산 2를 변경할 수 있으며(단, 전송하거나 파기할 수 없음), 자산 3을 변경, 양도 또는 파기할 수 있음을 알 수 있습니다. .파괴.
지갑은 이 정보를 사용자에게 표시할 수 있으며 사용자는 거래가 자산에 대해 수행할 수 있는 작업을 더 잘 알 수 있습니다. 예를 들어 Web3 애플리케이션의 트랜잭션 호출이 일부 자산이나 코인을 건드리는 것과 같이 무언가 비정상적인 경우 사용자는 이를 관찰하고 트랜잭션을 진행하지 않기로 결정할 수 있습니다.
계정에는 운영 관점에서 임의의 데이터가 포함되어 있기 때문에 Solana에서는 불가능합니다. 계정을 해석하려면 계정에 대한 외부 설명(애플리케이션에 따라 다름)이 필요하며 스마트 계약 발급자가 반드시 제공하지는 않습니다. 또한 자산 소유권의 개념은 Solana 런타임에 존재하지 않으며 각 스마트 계약은 이 의미를 수동으로 구현해야 합니다(일반적으로 계정 서명 및 PDA 사용). 이는 이를 추적할 일반적인 방법이 없음을 의미합니다.
보조 제목
7.3 단순하고 복잡한 트랜잭션
특히 Sui의 경우 특정 유형의 트랜잭션이 Byzantine Consistent Broadcast를 기반으로 하는 더 간단한 알고리즘을 위해 완전한 합의를 포기할 수 있도록 합의 수준에서 흥미로운 최적화가 있습니다. 이것의 장점은 이러한 트랜잭션이 합의 수준에서 병렬화되어 HOL(head-of-line) 차단을 제거하고 거의 즉각적인 완결성을 달성하여 본질적으로 web2의 확장성을 실현할 수 있다는 것입니다.
이는 Sui가 소유 객체와 공유 객체를 구분하기 때문입니다(섹션 3.1 참조). 자신의 개체만 포함하는 트랜잭션(단순 트랜잭션이라고 함)은 Sui에 대한 완전한 합의가 필요하지 않습니다. 자신의 객체는 발신자 이외의 트랜잭션에서는 사용할 수 없고 발신자는 한 번에 하나의 트랜잭션만 보낼 수 있으므로, 이는 그 자체로 이러한 트랜잭션을 다른 트랜잭션을 참조하여 정렬할 필요가 없음을 의미합니다(전체 정렬 및 인과 정렬). - 참조된 트랜잭션 개체는 다른 트랜잭션의 영향을 받을 수 없으며 트랜잭션은 다른 개체에 영향을 줄 수 없음을 알고 있습니다. 따라서 우리는 체인에서 병렬로 발생하는 다른 트랜잭션과 관련하여 해당 트랜잭션의 순서에 대해 신경 쓰지 않습니다. 실제로는 관련이 없습니다. Sui는 이 사실을 활용하여 간단한 트랜잭션 처리를 크게 최적화하여 수백 밀리초 안에 최종성을 달성할 수 있습니다. 그러나 단점은 보낸 사람이 한 번에 하나의 트랜잭션만 보낼 수 있다는 것입니다. 반면에 복잡한 트랜잭션으로 알려진 여러 공유 개체를 포함하는 트랜잭션에는 항상 완전한 합의가 필요합니다.
특정 유형의 응용 프로그램은 자체 개체의 생성, 전송 및 수정이 전적으로 단순 트랜잭션을 통해 수행될 수 있다는 점에서 단순 트랜잭션을 잘 활용할 수 있습니다. 좋은 예는 NFT(대량 주화 포함) 및 web3 게임입니다. 이러한 사용 사례는 대기 시간이 짧은 최종성과 피어 차단 제거로 인해 큰 이점을 얻음으로써 더 나은 사용자 경험과 확장성을 가능하게 합니다.
그러나 다른 유형의 애플리케이션은 복잡한 트랜잭션에 의존해야 합니다. 여기에는 대부분의 DeFi 애플리케이션이 포함됩니다. 예를 들어 AMM 유동성 풀은 공유 객체여야 합니다. 모든 종류의 교환 주문 실행에는 완전한 합의와 전체 주문이 필요하기 때문입니다. 기본적으로 동시에 여러 사용자로부터 여러 주문이 들어오면 누구의 주문이 먼저 실행될 것인지 합의해야 하기 때문에 각 사용자가 받을 실행 가격이 결정됩니다.
Sui 문서에는 단순하고 복잡한 트랜잭션에 대한 자세한 내용이 있습니다.
https://docs.sui.io/devnet/learn/sui-compared
https://docs.sui.io/devnet/learn/how-sui-works#system-overview
첫 번째 레벨 제목
8. 결론
이 기사에서는 Solana와 Sui의 프로그래밍 모델을 자세히 살펴보고 비교하며 Move 프로그래밍 언어에 대해서도 설명합니다.
두 번째 장은 Solana 프로그래밍 모델에 대한 요약이며, 세 번째 장은 Sui Move와 그 프로그래밍 모델을 소개합니다. 4장에서는 계속해서 Move의 유형 및 리소스 보안이 작동하는 방식을 설명합니다. Move 기능이 스마트 계약 개발에 미치는 영향은 즉시 명확하지 않으므로 5장에서 실제 사례를 사용하여 Solana와 SuiMove를 보다 철저하게 비교합니다. 6장에서는 eBPF/SBF에 대해 논의하며 Move 기능을 가져오거나 Move 자체를 Solana에서 작동시키는 것이 쉽지 않음을 보여줍니다. 7장에서는 Sui의 Move 관련 기능 중 일부에 대해 설명합니다.
스마트 계약 프로그래밍은 디지털 자산 프로그래밍에 관한 것입니다. 이것은 우리가 지금까지 본 다른 유형의 프로그래밍(예: 시스템, 백엔드...)과 매우 다른 새로운 유형의 프로그래밍이라고 할 수 있습니다. 이 때문에 기존 프로그래밍 언어와 프로그래밍 모델은 당연히 이 사용 사례에 적합하지 않습니다.
문제의 핵심은 리소스와 자연스럽게 작동하면서도 동시에 신뢰할 수 없는 코드와 상호 작용하는 프로그래밍 모델을 원한다는 것입니다. Solana는 여기서 타협을 합니다.신뢰가 필요 없는 환경에서 스마트 컨트랙트가 필요한 프로그래밍 가능성을 가질 수 있도록 하지만 프로그래밍 모델은 리소스를 사용하는 프로그래밍에 적합하지 않습니다. 바이트코드 확인을 통해 두 속성을 모두 가질 수 있습니다. 어떤 면에서는 신뢰할 수 없는 코드를 신뢰할 수 있는 코드로 바꿉니다.
Move는 스마트 계약 개발을 위한 새로운 프로그래밍 언어입니다. 핵심 혁신은 검증 가능하도록 의도적으로 설계된 바이트코드입니다. 바이트코드 검증 자체는 새로운 개념이 아니지만 Move가 수행하는 검증은 참으로 혁신적입니다. 바이트코드 및 검증을 통해 Move는 리소스에 대한 일류 지원으로 스마트 계약 프로그래밍 모델을 구현하고 신뢰할 수 없는 환경에서 안전한 프로그래밍을 보장합니다.
Move는 스마트 컨트랙트 개발에, React는 프론트엔드 개발에 있다고 생각합니다. "Move에서 할 수 있는 일을 Rust에서도 할 수 있다"고 말하는 것은 "React에서 할 수 있는 일을 jQuery에서도 할 수 있다"고 말하는 것과 같습니다. 물론 React 애플리케이션에 버금가는 jQuery 기반 애플리케이션을 구현하는 것도 가능하지만 실용적이지 않다. React는 개발자가 완전히 이해할 수 있지만 프런트 엔드 개발을 더 빠르고 확장 가능하며 간단하게 만드는 가상 DOM의 개념을 도입합니다. 마찬가지로 Move의 바이트코드 검증은 개발자도 이해하기 쉬운 저수준 기술이지만 보다 인체공학적이고 구성 가능하며 안전한 스마트 계약 개발을 제공합니다. Move는 또한 보안 및 보다 직관적인 프로그래밍 모델로 인해 스마트 계약 개발자의 진입 장벽을 크게 낮춥니다.
Move가 관심을 끌 수 있다면(그리고 그럴 것이라는 조기 징후가 있음) Solana에 심각한 위협이 될 수 있습니다. 두 가지 이유가 있습니다.
우선 Move 스마트 계약의 개발 시간이 훨씬 빠릅니다. Move에서 처음부터 스마트 계약을 개발하는 것은 Rust보다 2-5배 더 빠를 수 있습니다. 따라서 Move 생태계의 발전은 Solana를 능가할 수 있습니다. 블록체인의 개방적이고 무허가 특성으로 인해 심각한 잠금 효과가 없으며 유동성이 쉽게 이동할 수 있습니다. Solana 개발자는 순전히 경제적 고려 사항으로 인해 Move를 채택해야 할 수 있습니다. Move로 전환하거나 더 안전한 스마트 계약을 더 빨리 개발할 수 있기 때문에 Move 개발자를 능가할 수 있습니다. 스마트 계약 개발자를 고용하고 싶다면 하나의 스마트 계약을 구축할 수 있는 Rust 개발자를 고용하거나 동일한 시간에 두 개의 더 안전한 스마트 계약을 구축할 수 있는 Move 개발자를 고용할 수 있습니다. 이것은 React가 프론트엔드 개발에서 했던 것과 유사합니다.
둘째, Move는 Rust나 Solidity보다 진입 장벽이 훨씬 낮습니다. Move 구문이 더 간단하고 프로그래밍 모델이 더 직관적이기 때문입니다. 일부 개발자는 Rust 또는 Solidity에서 스마트 계약 개발을 수행할 수 없지만 Move에서는 가능할 수 있습니다. 배워야 할 개념이 적기 때문에 비 스마트 계약 개발자는 Rust(Rust 자체는 복잡한 언어이며 PDA와 같은 Solana 개념과 결합하면 초보자에게 많은 혼란을 야기할 것임) 또는 Solidity(당신은 안전한 스마트 계약을 개발할 수 있으려면 재진입과 같은 언어의 매우 미세한 세부 사항에 익숙해야 합니다.) 훨씬 쉽습니다. 기존 Solana 및 Solidity 개발자가 Move로 전환하지 않더라도 아직 공간에 진입하지 않은 개발자 시장은 공간의 기존 개발자 수보다 훨씬 더 큽니다. Move는 진입 장벽이 낮고 개발 속도가 빠르기 때문에 Rust나 Solidity보다 제품 시장 적합성이 더 우수하고 파이의 더 큰 조각을 차지할 수 있습니다. 새로운 개발자가 쏟아지기 시작하면 Rust나 Solidity가 아닌 Move로 시작했으면 합니다. 이는 React가 웹 산업에서 사용되는 방식과도 유사합니다.
이 때문에 저는 Solana가 중장기적으로 Move에 대한 최고 수준의 지원을 추가할 것으로 기대합니다. 하지만 쉽지 않습니다. Move의 주요 이점을 얻으려면 Move 바이트코드가 기본적으로 지원되어야 합니다. 즉, 단순히 Move를 eBPF/SBF로 컴파일하는 것은 불가능합니다(섹션 6.3 참조). 기존 생태계를 유지하기 위해서는 두 운영 모두 지원이 필요합니다. 주요 기술 과제는 작업 간에 적절한 상호 운용성을 달성하는 방법입니다. 이를 위해서는 Move와 Solana에 대한 깊은 이해가 필요하므로 Solana 팀이 Move 팀의 지원을 받아 이를 직접 추진하기를 바랍니다.
Move는 Meta(née Facebook)의 Diem 프로젝트에서 시작되었습니다. Sam Blackshear가 이끄는 Move 팀은 스마트 계약을 처리하는 방법을 파악하는 임무를 받았습니다. 문제를 파헤친 후 그들은 스마트 계약 프로그래밍이 디지털 자산(자원)에 관한 것이지만 기존 언어 중 어느 것도 이 사용 사례를 지원하지 않는다는 것을 발견하고 처음부터 새로운 프로그래밍 언어를 구축하기로 결정했습니다.
