RDX Works의 수석 프로토콜 설계자인 Josh Primero의 의견입니다.  Babylon 네트워크에서 Radix Engine V2를 출시한 후 DeFi 장면에 떠오르는 새로운 VM 물결을 자세히 살펴보았습니다. 그 중 가장 강력한 것 중 하나는 Diem의 원래 MoveVM보다 향상된 Sui의 MoveVM입니다.  저는 Sui의 아키텍처가 Radix와 몇 가지 주요 기술 철학을 공유하기 때문에 한동안 흥미를 느꼈습니다.  자산 지향 프로그래밍을 가능하게 하기 위해 이동 의미론을 사용합니다.  상태 종속성에 대한 지식을 활용하여 부분 순서 지정을 통해 합의를 확장합니다(현재의 유행인 확장성을 과도하게 추상화하고 상위 계층으로 이동하는 대신).  기술적으로 말하자면, 일부 로직을 실행하는 데 필요한 최소 상태 종속성을 정적으로 캡처하는 언어와 컴파일된 바이트 코드를 활용하는 방법이 매우 멋지다고 생각했습니다.  이는 빠른 실행을 가져올 뿐만 아니라 트랜잭션의 상태 종속성과 상태 쓰기가 잘 제한되어 있으므로 보안 이점도 제공합니다.  하지만 이 성과에는 대가가 따릅니다. DeFi 프로그래머는 EVM의 잘 알려진 문제를 반복하면서 더 어렵고 때로는 직관적이지 않은 모델을 관리해야 합니다.  이제 Sui의 VM에서 발견한 네 가지 결함에서 이러한 문제를 살펴보겠습니다.  1. 너무 일반적인 객체 프리미티브  Sui의 MoveVM(또는 일반적으로 MoveVM)의 가장 큰 혁신은 바이트코드 계층에서 이동/빌림 의미 체계를 사용하는 것입니다. 이는 낮은 수준의 기계가 객체의 소유권과 이동을 이해할 수 있음을 의미합니다. 꽤 멋지다!  따라서 Sui VM의 모든 객체는  , 소유, 이동 및 공유할 수 있는 관련 논리가 포함된 입력된 값입니다.    NFT처럼 작동합니다  불행하게도 객체는 이 모델에서 더 많은 일반적인 작업을 수행할 수 있기 때문에 DeFi 프로그래머는 복잡한 객체 수명 상태 머신을 정의하고 관리해야 하는 부담을 지게 됩니다.   특히 Sui에서 새로운 구조를 정의할 때 프로그래머는 4가지 기능("복사", "삭제", "키" 및 "저장")의 조합을 지정해야 하며 각 기능은 서로 다른 방식으로 상태 머신에 영향을 미칩니다. 또한 프로그래머는 인스턴스화 시 개체를 공유, 전송, 값으로 반환 또는 고정해야 하는지 관리해야 합니다.  이들 중 하나에 잘못된 구성이 있으면 자금 손실로 이어질 수 있는 미묘한 버그가 발생할 수 있습니다.  예를 들어 다음 코드에서는 Sui의  간편플래시론을 구현합니다. 문제? 실수로 영수증에 드롭 기능을 추가했습니다.    뜨거운 감자 패턴  이 작은 실수로 인해 차용인은 영수증 자체를 삭제하여 대출금을 갚지 않고 대출금을 가지고 도망갈 수 있습니다. (FlashLoan과 영수증 관계에 또 다른 버그가 있습니다. 찾을 수 있는지 확인하세요!)  따라서 일련의 기능을 사용하여 단일 개체 추상화를 중심으로 VM을 구성하는 것은 개념적으로 우아하고 간단하지만, 프로그래머의 관점에서는 처리해야 할 하위 수준 상태가 너무 많기 때문에 각각의 영향을 이해하기 어렵습니다. 관리하다.  이는 이전 언어의 메모리 관리 문제와 가비지 수집 VM이 큰 성공을 거둔 이유와 크게 다르지 않습니다. 애플리케이션 프로그래머는 언제 메모리를 해제해도 괜찮은지와 같은 낮은 수준의 상태를 관리하는 데 신경 쓰지 않습니다. 그들은 사물과 그 사물들 사이의 관계에 관심을 갖습니다.  비슷한 맥락에서 DeFi 프로그래머는 근본적으로 자산과 이러한 자산의 이동 및 소유권에 관한 논리에 관심을 갖습니다. 자산 자체에는 고유한 논리가 없으며 이러한 자산을 관리하는 논리는 "이동"하거나 "소유"할 필요가 없습니다.  Sui의 MoveVM은 매우 다른 두 가지를 하나의 일반적인 객체 추상화로 결합하여 어려운 DeFi 프로그래밍 정신 모델을 만듭니다.  2. 동적 디스패치 없음  MoveVM의 정의 기능은 정적 디스패치를 사용한다는 것입니다. 즉, 런타임 중 함수 호출과 실행 사이에 간접 계층이 없다는 의미입니다. 함수 호출과 해당 기본 논리는 새 패키지가 게시될 때 정적으로 연결됩니다. 이를 통해 VM은 빠르고 예측 가능하지만 유연성이 떨어지고 프로그래밍 환경을 사용하기가 더 어려워집니다.  동적 디스패치 부족이 미치는 세 가지 영향을 살펴보겠습니다.  2a) 기능 구성 없음  VM은 코드 게시 시 호출될 정확한 함수를 알아야 하기 때문에 서로 다른 함수를 함께 구성하는 것은 불가능합니다. 일반 프로그래밍에서 매우 일반적인 패턴입니다(예: OO 언어의 인터페이스 또는 Rust의 특성).  간단한 유동성 풀 인센티브 프로그램을 살펴보겠습니다. Rust에서 귀하의 기여도에 10%를 추가하는 인센티브 프로그램을 작성한다면 다음과 같을 것입니다:   이런 식으로 내 LiquidityEnhancer는 Pool 특성을 구현하는 모든 풀에서 작동합니다(예, Rust nitpickers의 경우 이 특성도 정적으로 연결됩니다. 이는 함수 구성의 예일 뿐입니다).  "기여"는 이미 정의된 기능이어야 하므로 Sui에서는 이것이 불가능합니다. 대신, 새로운 풀 구현을 위해 정확한 풀 구현에 연결되는 새 패키지를 게시해야 합니다.  2b) 동적 콜백이나 함수 포인터 없음  이와 관련하여, 일부 일반 인터페이스를 통해 임의의 로직을 실행할 수 있다는 것은 특히 DeFi 설정에서 매우 유용한 구성입니다.  미래에 호출자가 임의의 논리(예: 지불 지연 사용)를 호출하도록 인센티브를 제공하는 인센티브가 부여된 미래 실행자를 상상해 보세요. Rust에서는 다음과 같습니다:   그러나 Sui에서는 동적 디스패치 기능이 없기 때문에 이는 불가능합니다. 대신, 이러한 기능을 사용하려는 각 방법에 대해 새로운 IncentivizedFutureExecution 패키지를 게시해야 합니다.  2c) 불편한 업그레이드 가능성  Sui는 다음을 지원합니다.  . 불행하게도 정적 디스패치 불변으로 인해 패키지 업그레이드 관리는 예상보다 더 어색하고 덜 안전합니다.   패키지 업그레이드 및 버전 관리  첫째, 원활하고 투명한 코드 업데이트가 불가능합니다. 다른 패키지를 호출하는 패키지가 있고 다른 패키지에 필수 버그 수정 업데이트가 있는 경우 수정 사항을 원하면 새 패키지를 직접 게시해야 합니다.   점점 더 많은 패키지 종속성으로 인해 자주 사용되는 패키지의 간단한 버그 수정만으로도 패키지 업그레이드가 폭발적으로 늘어날 수 있습니다.   둘째, 이 코드에 버그 및/또는 악성 코드가 있을 수 있는 경우에도 모든 이전 코드는 항상 존재합니다(이 코드에 종속된 다른 코드가 이를 호출할 수 있어야 하므로 필요함). 이에 대응하기 위해 애플리케이션 계층에는 객체 상태에서 합리적인 버전 관리 스키마를 유지해야 하는 부담이 있습니다.  3. 어색한 메일박스 패턴  수이는 최근에  이는 다른 개체가 알지 못하는 사이에 개체를 다른 개체로 보내는 방법으로 가장 잘 설명될 수 있습니다(이전에는 주소를 통해서만 가능했습니다). 해당 개체에 액세스하려면 이 전송에 대한 지식이 있는 별도의 트랜잭션을 실행해야 합니다.    객체로 전송 패턴  이러한 구성은 수신 객체의 상태에 대한 종속성을 제거하는 데 유용합니다. UTXO 모델의 다른 주소로 UTXO를 보내는 것과 다르지 않습니다(수신 부분도 UTXO 감시 스크립트를 통해 소유권을 증명하는 것과 유사합니다). 그러면 Sui의 합의는 이러한 경합 부족을 활용하고 그러한 거래를 더 잘 병렬화할 수 있습니다.  그러나 이러한 성능 향상에는 보안 상충관계가 없지는 않습니다. 수신 객체에 대한 정보(존재 여부 포함) 없이 객체를 수신할 수 있다는 사실은 전송된 객체에 대한 액세스를 영원히 잃을 가능성을 초래합니다.  이는 수신 개체가 전송되는 개체를 지원하지 않는 경우 가능합니다. 이러한 결함은 해당 토큰을 지원하지 않는 스마트 계약에 ERC-20 토큰을 잘못 보내는 것과 유사합니다(자금 손실의   일반적인 원인). 매우  게다가 부모-자식 관계에는 두 가지 유형, 즉 부모가 자식에 대해 아는 것과 자식이 부모에 대해 아는 것이 있다는 사실은 전통적인 프로그래밍에서 일반적인 것보다 더 복잡한 모델을 만듭니다.   이 어색한 구조에서 프로그래밍하지 않고 성능 이점을 유지하는 접근 방식이 있습니까? 나는 있다고 믿습니다. 다른 CRDT 접근 방식과 함께 불변 포인터를 사용해야 하지만 이에 대해서는 향후 기사에서 다루겠습니다.  4. 어색한 공유 상태 프로그래밍  Sui의 VM은 논쟁이 없는 상태를 프로그래밍하고 실행하도록 최적화되어 있습니다. 이로 인해 실제로 공유 상태를 처리해야 할 때 다소 어색한 프로그래밍 메커니즘이 발생했습니다. 이들 중 일부를 살펴보겠습니다.  4a) 저장된 참조 없음  Sui의 VM에는 저장된 참조에 대한 개념이 없습니다. 만약 그렇다면, 함수의 상태 종속성을 정적으로 분석하는 능력을 상실하게 되어 병렬화 능력도 상실하게 됩니다. 결과적으로 저장된 참조를 관리하는 부담은 이제 프로그래머/사용자에게 있습니다.  예를 들어, 기능 중 하나에서 특정 Oracle의 가격을 요구하는 개체가 있다고 가정해 보겠습니다. Rust에서는 다음과 같이 보일 수 있습니다:   Sui에서는 참조를 저장할 수 없기 때문에 MyDefi와 Oracle 간의 관계를 보다 기능적인 방식으로 설명해야 합니다.   하지만 기다려! 이제 임의의 오라클을 전달할 수 있습니다. 올바른 오라클이 사용되도록 하려면  반드시 사용해야 합니다:    ID 포인터 패턴  이 패턴은 일반 참조와 비교할 때 더 취약하므로 올바른 관계를 구현하려면 주의가 필요합니다. 객체 간의 관계 그래프가 성장하고 더욱 복잡해짐에 따라 이러한 프로그래밍 부담이 잘 확장되는 것을 상상하기 어렵습니다(예: Oracle get_price 호출에도 자체 종속성이 있는 경우 어떻게 될까요).  게다가, 트랜잭션이든 패키지 코드이든 항상 호출자에게 올바른 참조를 전달해야 하는 부담이 있습니다. 이 참조가 변경될 수 있는 경우 참조가 최신 상태로 업데이트되었는지 확인해야 하는 호출자에게 또 다른 추가 부담이 가해집니다.  4b) 관련 인스턴스에 대한 비동적 유형 안전성  기존 프로그래밍과 달리 DeFi 프로그래밍에서는 인스턴스가 다른 인스턴스와 동일한 "인스턴스 그룹"에 속해 있는지 유형을 확인할 수 있는 것이 매우 유용합니다.  예를 들어, 두 개의 동전을 결합하는 것이 동일한 동전 식별자인지 확인하는 것이 좋을 것입니다.   이를 전통적인 제네릭 의미론으로 구현할 때의 문제는 제네릭이 "관련 인스턴스 그룹"이 아닌 유형을 나타내는 데 사용된다는 것입니다.  다소 영리한 방법으로 Sui는 다음을 통해 이 문제를 해결할 수 있었습니다.  . 이 시스템 지원 패턴에서는 기본적으로 관련 인스턴스의 새 그룹을 원할 경우 이 그룹의 식별자를 나타내는 특별한 새 유형을 생성한다고 말했습니다.   일회성 증인 패턴  이것의 큰 이점은 언어 계층을 전혀 변경할 필요가 없으며 잘 알려진 일반 의미론을 사용하여 이러한 유형의 안전을 달성할 수 있다는 것입니다.  가장 큰 결점은 관련된 항목의 새로운 그룹이 생성될 때마다 새로운 유형(즉, 새로운 패키지)이 배포되어야 한다는 것입니다. 예를 들어 새 패키지를 배포하지 않고서는 새 Coin<T>을 동적으로 생성할 수 없습니다.   결론  Sui의 MoveVM은 시스템 엔지니어의 표준에 따라 구축되었습니다. 즉, 개념적으로 단순한 하위 수준 기본 요소를 기반으로 하고 정적으로 적용되는 VM입니다.  불행하게도 단순하다고 해서 쉬운 것은 아니며, 일반적인 공유 객체 패턴을 피해야 한다는 주장으로 인해 애플리케이션 계층이 상당히 복잡해지고 프로그래밍하기에 직관적이지 않게 됩니다.  DeFi는 누구나 접근할 수 있는 대규모 유동성을 갖춘 풀, 누구나 빌리고 빌릴 수 있는 대출 프로토콜, 누구나 호출할 수 있는 오라클, 그리고 이 모든 객체의 구성과 상호 작용이 동시에 일어나는 지저분하고 공유된 객체 세계입니다.  이러한 생태계를 병렬화하는 것은 DLT의 성배이며 Sui의 시도는 응용 프로그램 계층에 너무 많은 혼란을 가져오는 점을 제외하면 잘 수행됩니다.  일부 문제는 더 나은 도구 및 언어 지원으로 잠재적으로 해결될 수 있는 것이 사실이지만(   ), 일부는 대규모 VM 변경 없이는 복구할 수 없습니다(   ). 1개는 너무 일반적인 개체 기본 형식, 4개는 어색한 공유 상태 프로그래밍 2개 동적 디스패치 없음, 3개 어색함) 사서함 패턴

Buy XRD with card or bank transfer via Switchere.

이 오디오는 이야기의 원래 언어로 제작되었습니다!

Sui의 MoveVM: 종합적인 검토

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

볼츠만 뇌 이론에 대한 간략한 소개

디지털 유목민 들어보기: 태국의 새로운 DTV 비자에 대해 알아야 할 사항

독특한 생태계를 강화하는 비트코인 UTXO 모델

AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

볼츠만 뇌 이론에 대한 간략한 소개

디지털 유목민 들어보기: 태국의 새로운 DTV 비자에 대해 알아야 할 사항

독특한 생태계를 강화하는 비트코인 UTXO 모델

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps