8월 10일 요약 Move AMA: Move 미스텐 엔지니어와 함께하는 프로그래밍 언어

Jen:

Move 프로그래밍 언어에 대한 새로운 AMA 세션에 오신 여러분을 환영합니다. 오늘 이 자리에는 미스텐의 사랑스러운 엔지니어인 아담과 토드가 함께했습니다. 자기소개 부탁드립니다.

Adam:

제 이름은 아담 웰크입니다. 저는 약 7~8개월 전부터 Mysten Labs의 Move 팀에서 일하고 있습니다. 저는 주로 개발자 경험과 툴링에 중점을 두고 있습니다.

Todd:

토드 노와키입니다. 저는 거의 창립 초기부터 Move 에 있었습니다. 소규모 팀이었기 때문에 저희 중 많은 사람이 당시 가장 우선순위가 높았던 작업에 집중해 왔습니다. 그 중 가장 큰 비중을 차지한 것은 컴파일러와 소스 언어였습니다. 최근에는 미스텐 랩에서 언어를 보다 Sui-특화적인 스타일링( Move)에 통합하는 작업을 더 많이 하고 있습니다.

. . .

질문 #1: Move 팀은 특히 새로운 언어라는 점을 고려할 때 더 많은 개발자를 온보딩하고 Move 언어의 개발자 채택을 가속화하기 위해 어떻게 계획하고 있나요?

Adam:

해커톤과 워크숍을 진행하는 이니셔티브를 시작했는데, 일부는 한국에서 열렸지만 앞으로는 전 세계 여러 지역에서 온라인과 오프라인으로 진행할 계획입니다. 이러한 방식으로 언어와 언어의 기능에 대한 인지도를 높이려고 노력하고 있습니다.

또 다른 측면은 이 언어가 메타에서 만들어졌지만 현재 여러 다른 체인에서 사용되고 있으며, Mysten Labs의 Sui 체인도 그중 하나라는 점입니다. 미스텐 랩스뿐만 아니라 다른 회사에서도 이 언어를 대중화하기 위한 커뮤니티의 노력이 계속될 것입니다.

Todd:

한 가지 간단히 덧붙이자면, 아직은 공간이 다소 젊고 작아서 이러한 것들을 구축하는 데 시간이 걸린다는 점입니다. 학습 리소스의 경우 인지도를 높이기 위해 노력하고 있습니다. 피드백이 있으시면Move 책 또는 다미르가 리포지토리에 쓴 글에 대한 피드백이 있으시면 알려주세요! 이런 피드백은 정말 큰 도움이 됩니다.

Jen:

아담의 말씀과 관련하여 다양한 기술 분야의 개발자를 온보딩하기 위한 더 많은 이벤트가 계획되어 있습니다. 많은 분들이 큰 관심을 가지고 있다는 것을 잘 알고 있으며, 내부적으로도 온라인 워크숍과 오프라인 워크숍을 검토하고 있습니다. 동영상 중심의 콘텐츠를 더 많이 확보해 달라는 압도적인 반응을 받았으며, 현재 이를 위해 노력하고 있습니다. 이러한 리소스가 필요하다는 의견을 주신 분들께 진심으로 감사드리며, 이러한 리소스를 제공할 수 있는 방법을 모색하고 있습니다.

. . .

질문 #2: 어떻게 Move 다른 기존 블록체인이 할 수 없는 방식으로 자산의 보안을 보장할 수 있나요?

Adam:

Move 는 1세대 스마트 컨트랙트 언어에 존재했던 아이디어가 진화한 것입니다. 따라서 안전과 보안에 대한 생각의 변화는 C언어, 심지어 C++ 언어가 개발되고 구현되던 시기와 Go나 Rust와 같은 언어가 등장한 지금 사이에 일어난 진화와 비슷합니다.

예전에는 "스레드로 프로그래밍하면 레이스나 교착 상태를 피하기 위해 정말 조심해야 한다"는 식이었죠. Rust는 이 부분에서 완전히 다른 접근 방식을 취했습니다. 기본적으로 프로그램을 작성하면 컴파일러가 그 프로그램을 받아들일 수 있도록 언어를 설계하겠다고 말했죠. 특정 종류의 오류는 정의나 설계상 프로그램에 존재하지 않을 것입니다. 예를 들어 Rust로 동시 프로그램을 작성하고 컴파일하면 C나 C++에서처럼 메모리를 할당 해제했다가 잘못 재사용할 수 없습니다.

그래서 Move 는 Rust가 기존 언어에서 했던 것과 같은 방향으로 나아가려고 노력했는데, 이는 설계적으로 이러한 것들을 방지하는 것입니다. 예를 들어, 설계상 이중 지출이 발생하지 않으며 모든 프로퍼티를 컴파일러에서 확인할 수 있는 것은 아닙니다. 코드에 작성하는 추가 사양과 함께 사용할 수 있는 Prover라는 추가 도구가 있습니다. 이러한 사양을 작성하면 런타임에 프로그램이 수행하거나 수행하지 않는 다른 것들을 증명할 수 있지만, 컨트랙트가 배포되기도 전에 이러한 것들을 정적으로 알 수 있습니다.

Todd:

정말 좋았어요. 한 가지 덧붙이고 싶은 것은 허용하지 말아야 할 것을 결정하는 데는 어려움과 미묘한 차이가 있다는 것입니다. Adam이 C++와 Rust에 대해 설명한 예시에서 C++에 가깝게 유지하고 싶지만 메모리 안전과 관련된 문제가 많이 발생한다는 생각이 들었습니다. 이 접근 방식에서는 메모리에 안전하지 않은 코드가 허용될 수 있기 때문에 코드를 감싸서 외부에서 볼 때 안전한 것으로 표시해야 합니다. Move Rust와 유사한 메모리 안전성을 보장하는 다른 접근 방식을 사용하기로 결정했습니다.

. . .

질문 #3: Move 언어에 안전과 보안이 내장되어 있는지 어떻게 확인할 수 있나요?

Todd:

Move 의 경우, 전부 아니면 전무와 같은 상황입니다. 가스 충전과 실패를 제외하고는 블록체인을 변경하지 않거나 저장소 변경에 성공합니다. Sui 용어로 설명하자면, 어떤 객체를 입력으로 받아 새로운 객체를 생성하거나 객체를 전송하거나 다른 방식으로 객체를 변경하거나 아무것도 하지 않는 것입니다. 매우 단순하게 들리겠지만 이러한 종류의 전부 아니면 전무 동작은 이러한 변경 사항의 메모리를 수동으로 관리할 필요가 없기 때문에 많은 버그를 배제합니다.

입력값이 0보다 크면 이 함수는 절대 실패하지 않는다와 같이 프로그램에 대한 광범위한 논리적 속성을 정의하고 싶을 때 증명자가 등장하기 시작합니다. 이 함수에 충분한 코인이나 토큰을 전달하면 실패할 수 없거나, 이 함수에 대해 키를 올바르게 인증하면 실패하지 않을 수 있다는 것을 알면 도움이 될 수 있습니다.

Adam:

언어 관점에서 말하자면, 로컬에서는 보고 있는 객체가 공유 객체인지 소유 객체인지 구분하기 어려운 경우가 있는데, 프로버를 사용하면 함수가 공유 객체를 기대하는 경우 전달되는 객체가 공유 객체인지, 아니면 전달되는 객체가 공유 객체가 아닌지 확인하는 데 도움이 될 수 있다고 생각합니다. 그런 다음 Todd가 언급 한 것과 유사한 속성을 정의 할 수 있지만 비 로컬로 확인할 수있는 객체의 속성과 관련하여 정의 할 수도 있습니다.

Todd:

앞서 말씀드렸듯이, 저희는 계속해서 언어를 개발하고 새로운 것을 배우며 시간이 지남에 따라 변경해 나갈 것입니다. Move 에서 가장 먼저 한 일 중 하나는 핵심 Move 계정 기반 스토리지 모델을 설정하는 것이었지만 여기에는 몇 가지 단점이 있습니다. 모든 코인이 이 하나의 코인 모듈에서 관리된다고 가정하면, 그 위에 이 코인 모듈을 호출하는 모듈이 있는지 알 수 없습니다. 따라서 누군가 이 함수를 호출하여 모든 코인을 훔칠 수 있는지 알 수 없습니다. 이 문제를 해결하기 위해 몇 가지 다른 방법을 시도해 보았지만 그다지 좋은 방법은 없었습니다. 하지만 Sui 객체 모델에서는 실제로 실행 시점에 수정할 모든 객체를 제시하도록 합니다. 따라서 실행을 시작할 때 메모리의 전체 영역을 분할하고 이 영역 내에서만 쓰거나 수정할 것이라고 말할 수 있습니다.

이는 Move 함수가 정확히 무엇을 하는지 훨씬 더 쉽고 이해하기 쉽게 해주는 또 다른 보증입니다.

. . .

질문 #4: VS Code 플러그인에 대한 맥락과 배경을 공유해 주시겠어요?

Adam:

기존 팀원 중 한 명이 Meta에서 개발한 상당히 초보적인 VS 코드 플러그인이 있었습니다. 제가 미스텐에 합류했을 때 이 플러그인이 완벽하지 않다는 것을 깨달았고, 기존 언어로 작업하는 데 익숙한 사람이라면 개발자 경험에 만족하지 못할 수도 있다는 것을 알았습니다. 그래서 처음에는 VS 코드 플러그인에 최신 IDE에서 원하고 기대할 수 있는 몇 가지 기능을 제공하는 작업에 착수했습니다. 예를 들어 유형 정의로 이동하고, 마우스오버 시 입력된 모든 참조를 찾고, 컴파일러 진단을 편집자에게 전달하는 등의 기능을 제공했습니다.

. . .

질문 #5: VS 코드 플러그인이 코딩 경험과 개발자 팀에 미치는 영향은 무엇인가요?

Adam:

사람들이 실제로 새로운 기능을 사용하기 시작했다는 보고를 받았어요. 한국에서 열린 워크샵에서 개발자 옹호자이자 Move 핵심 팀의 일원인 Damir가 직접 워크샵을 진행하며 사람들과 함께 작업했는데, 사람들이 실제로 이 기능을 사용하고 좋아한다는 비공식적인 피드백을 전해주었습니다.

Todd:

아마 다른 도구가 될 것 같아요. 앞으로 더 쉽게 이해할 수 있는 다양한 도구 세트를 상상할 수 있습니다. 사양이 적용되는 방식, 특정 항목의 적용 범위, 또는 코딩 경험을 개발자 경험과 다르게 느끼게 하는 다른 방법 등이 있을 수 있습니다. '내가 이 함수를 작성하고 있는데 다른 함수의 시그니처가 무엇인지, 아니면 여기 코드를 볼 수 있는지'에 더 가깝습니다. 코드 베이스에 익숙하지 않은 비개발자에게는 이 정의가 가장 유용할 것 같습니다. 코드 정의는 놀랍습니다.

결국, 다른 사람들을 생각하고 그들의 삶을 더 편하게 만들거나 Move 코드를 보는 다른 종류의 비기술적인 사람들을 생각한다면, 그들을 도울 수 있는 다른 도구 세트가 필요할 것입니다.

. . .

질문 #6: 사람들이 살펴보고 싶어 할 만한 외부 기여에는 어떤 것이 있나요?

Adam:

이미 기여한 분들과 이미 VS 코드 플러그인 확장에 참여하고 있는 분들에게 말씀드릴 수 있습니다. 따라서 Move 리포지토리에서 Move 분석기 태그로 이슈를 찾아보시면 저희가 직접 또는 커뮤니티의 도움을 받아 수행할 계획이 있는 것들을 더 자세히 확인할 수 있을 것입니다.

VS 코드 플러그인 확장이 최근에 이루어졌음을 기억하세요. 사람들은 여기에 추가된 기능, 즉 에디터 수준에서 더 스마트한 작업을 할 수 있는 중간 표현을 구축하는 더 긴밀한 컴파일러 통합을 통해 허용된 이러한 추가 기능에 대한 지원을 이제야 알아차리기 시작했습니다.

이를 통해 몇 가지 추가 작업이 가능했고, 그 중 하나는 편집 중인 파일의 개요 보기를 제공하는 것이었습니다. 일반적으로 VS 코드 편집기에 익숙하다면 왼쪽에 이 개요 창을 열면 함수, 유형 정의 및 파일에 정의된 소스 코드의 주요 개요가 표시되는 창이 있습니다. 이것은 외부 기여자 중 한 명이 추가한 것입니다.

. . .

질문 #7: Move의 일반 코드 작성 기능에 대한 계획은 무엇인가요?

Jen:

예를 들어, 최근에 일반 유형 T인 두 가지를 비교하는 사용 사례가 있었는데, 특성 바운드, 어빌리티, 함수를 다른 함수에 인수로 전달할 수 없다고 생각했습니다.

Todd:

예, 예상할 수 있듯이 특성은 Move 로는 절대 오지 않는 함수 포인터입니다. 여러분은 아마도 저는 항상 고차 프로그래밍을 사용하고 Rust나 JavaScript 또는 다른 프로그래밍 언어를 사용하는데 왜 Move 을 사용하지 않느냐고 생각할 것입니다. 하지만 Move 은 범용 프로그래밍 언어가 아니기 때문에 많은 문제를 예방할 수 있습니다. 저희는 안전하다는 것을 증명할 수 있는 안전한 것을 구축하려고 노력하고 있으며, 동적 디스패치를 사용하면 많은 부분이 사라집니다.

특성 인터페이스 패턴에 도달하는 것처럼 개발자로서 익숙한 코드를 재사용하는 다양한 방법이 있지만, 여기서는 조금 다른 방식으로 작업을 수행하여 더 높은 수준의 보증과 언어를 사용할 수 있도록 노력하고 있습니다.

. . .

질문 #8: Move EVM이 호환되나요, 아니면 호환될 예정인가요?

Adam:

짧은 대답은 '아니요'와 '예'입니다. 메타에서 언어 간 솔루션을 제공하거나 Move 을 EVM 바이트코드로 컴파일하거나 트랜스파일링하려는 노력이 있었습니다. 제가 아는 한 0x, Aptos 또는 Sui 와 같은 언어를 사용하는 다른 체인에서는 이 문제를 해결하지 못했습니다. Move 을 사용하는 이러한 체인 중 어느 것도 EVM과 호환되도록 만들 계획이 없는 것 같습니다. 메타에서 시도된 것으로 생각되는 이유는 언어를 작성하고 해당 언어로 코드를 개발하면서 쌓은 전문 지식을 재사용하여 더 넓은 공간, 특히 규제 문제로 인해 메타가 해당 공간에서 개발하던 오리지널 제품에 적용하려고 했기 때문이라고 생각하는데, 잘 되지 않은 것 같습니다.

Move 언어가 더 많은 사람들에게 더 친숙하게 다가갈 수 있도록 하기 위해 무엇을 할 수 있는지에 대한 논의였다고 생각합니다. 실행 모델과 EVM 측에서 제공하는 보증의 차이가 너무 커서 이것이 100% 작동할 수 있을지는 확신할 수 없습니다. 아직 개발 중인지도 모르겠지만 적어도 미스텐 연구소와 Sui 블록체인의 경우 EVM과 호환되도록 만들 계획이 없습니다.

. . .

질문 #9: 다른 언어로 전환하면 스마트 컨트랙트에서 대체 가능한 토큰과 대체 불가능한 토큰과 같은 자원과 자산의 요점을 놓치게 되나요?

Todd:

질문을 잘 이해하지 못하겠습니다. 리소스, 자산, 토큰이 Move 에서 일류 구워진 것들인지 잘 모르겠습니다. 자산이라는 단어 그 이상입니다. 우리는 거의 NFT에 해당하는 객체를 가지고 있으며, 실제로 해당 코인의 아이디어에 관심이 있다면 코인도 NFT입니다. 대체 가능성의 측면은 내가 무언가가 대체 가능하거나 대체 불가능한 것에 관심이있을 때 인간 수준의 분별력을 가진 개념입니다. 예를 들어, 내 지갑에 1달러 지폐가 있고 당신 지갑에 1달러 지폐가 있다면 우리는 상관없기 때문에 기꺼이 교환할 수 있지만 누군가 내 1달러 지폐에 사인을 했다면 나에게는 중요할지 모르지만 당신에게는 중요하지 않을 수 있습니다. 저에게는 대체 불가능한 것이지만 여러분에게는 여전히 대체 가능한 것입니다.

Adam:

사람들이 지폐를 사용할 때 지폐는 대체 가능한 토큰의 예이지만 실제로는 모든 지폐에 일련 번호가 있으므로 무시하고 하나를 다른 것으로 교환하기 때문에 대체 불가능하지만 Sui 모든 코인 객체에는 고유 ID가 있지만이를 무시하면 기본적으로 대체 가능한 자산을 갖게됩니다.