6월 30일 요약 Sui AMA: Move 샘 블랙셔와 함께하는 프로그래밍 언어

Jen:

전 세계 어디에서나 좋은 아침, 오후, 저녁을 보내세요. 미스텐 랩스의 공동 창립자이자 최고기술책임자(CTO)인 Sam과 함께 Move 프로그래밍 언어 AMA를 시작하게 되어 정말 기쁩니다. 자기소개를 해주시죠, Sam.

Sam:

물론이죠. 저는 샘입니다. 저는 Mysten의 공동 창립자이자 CTO이며 Move 언어의 창시자입니다.

제가 미스텐과 크립토에 오게 된 계기에 대해 조금 말씀드리겠습니다. 저는 프로그래밍 언어 연구원으로 경력을 시작했고, 정적 분석과 자동화된 버그 찾기 도구를 연구하고 있었습니다. 저는 하루 종일 재미있고 난해한 수학을 하면서 오픈 소스 소프트웨어에서 실행할 수 있는 도구를 만들고 구현하여 오픈 소스 개발자에게 보고할 버그를 찾아서 수정할 의향이 있는지 확인했습니다. 때때로 개발자들이 고쳐주면 정말 짜릿한 기분이 들었습니다. 하지만 대부분 재미있는 수학에 불과했고 특별히 실용적인 것은 아니었습니다.

박사 학위가 끝날 무렵, 저는 Facebook에서 인턴십을 할 기회가 있었습니다. 그곳에서는 우리가 학계에서 사용하던 기술을 프로덕션에 적용하기 위해 노력하고 있었죠. 페이스북이 웹에서 모바일로 전환하던 2014년이었죠. 그들은 모바일 앱에서 어떤 대가를 치르더라도 버그를 없애야 한다는 사실을 발견했습니다. 그래서 사후에 버그를 잡는 대신 사전에 버그를 잡을 수 있는 모든 종류의 기술에 투자했습니다. 저는 이러한 자동화된 버그 찾기 도구를 개발하면서 이전에 하던 것과 같은 종류의 연구 작업을 수행했지만, 지금은 수만 명의 Facebook 개발자들에게 이 도구를 공개하고 그들이 하는 일에 대해 실시간으로 피드백을 받을 수 있게 되었습니다.

한마디로 완전히 중독성 있는 경험이었습니다.

저는 연구와 생산의 교차점에서 일하는 것을 정말 좋아합니다. 인턴십을 마치고 Facebook에 입사해 수년간 이 분야에서 일했습니다. 기술 관련 블로그를 만들면서 버퍼 오버플로 데이터, 레이스, 노드 참조, 보안을 위한 콘텐츠 분석 등 모든 종류의 것들을 살펴봤어요. 하루 종일 정적 분석을 하고 버그를 찾기 위해 노력했기 때문에 언어 디자인에 대한 많은 의견을 형성할 수 있었습니다.

언어 관점에서 보면 최종 사용자를 위해 준비하던 것과 같은 자동화 도구의 코드를 추론하기가 어렵습니다. Move 의 이야기는 안전, 버그, 구성에 의한 나쁜 동작 방지 등에 대한 이러한 아이디어를 많이 가져와서 처음부터 설계된 언어가 어떻게 생겼으면 좋겠는지에 대해 생각한 것입니다.

저는 Facebook의 Diem 프로젝트에 참여했고, 그 일환으로 Move 를 만들었습니다. 이곳에서 프로토콜 디자인에 대한 많은 작업을 했고, Mysten의 공동 창립자들을 만났습니다. 그리고 작년에 회사에 합류하여 Sui 과의 새로운 통합 작업( Move )을 시작했습니다.

. . .

질문 #1: 프로젝트의 다음 단계의 개발 초점은 무엇인가요?

Sam:

오늘 오후에 있을 발표에 연결할 수 있는 좋은 기회가 있습니다. 공식적으로는 AMA 이후에 발표할 예정이지만, 이 자리에 계신 분들께 미리 정보를 알려드릴 수 있습니다. 오늘 저희는 곧 있을 인센티브형 테스트넷의 날짜를 발표합니다. 테스트넷은 Sui 에 기반한 물 테마에 맞게 일련의 파동으로 구성될 예정입니다. 각 웨이브는 두 부분으로 구성됩니다. 하나는 네트워크의 특정 부분에 대한 운영상의 문제인 싱크(Sink)로, 검증자 재구성, 모든 핵심 요소에 대한 스테이킹 등 항상 작동해야 하는 문제이며, 다른 하나는 Move 개발자가 직면한 문제인 스윔(Swim)으로 구성됩니다.

첫 번째는 아직 공개할 준비가 되지 않은 몇 가지 세부 사항이 있습니다. 하지만 앞으로 더 많이 듣게 될 코드워드가 있는데, 바로 첫 번째 Move 관련 챌린지의 주제가 될 Capybara입니다. 저희는 인센티브화된 테스트넷을 위해 네트워크를 준비하고 안정성 기능이 모두 갖추어져 있는지, 개발자 툴 체인이 이러한 새로운 도전에 대비하고 있는지 확인한 다음, 운영 경험을 쌓는 일련의 과정을 거치는 데 중점을 두고 있습니다.

네트워크를 운영하는 직원들은 사고 대응을 위한 준비는 물론 모든 것이 안전하고 메인넷을 위한 준비가 되어 있는지 확인하고 있으며, 연말까지 완료할 수 있기를 희망하고 있습니다. 그래서 지금은 이 부분에 집중하고 있습니다. 저희는 인센티브 테스트넷에 도달하기 위해 매우 집중하고 있습니다.

질문 #2: Move 의 역사는 무엇이며 솔리디티와 같은 다른 프로그래밍 언어와 차별화되는 점은 무엇인가요?

Sam:

네, 밀접한 관련이 있긴 하지만 따로 말씀드리겠습니다. 제가 2018년에 리브라 프로젝트에 합류했을 때 매우 광범위한 임무가 주어졌습니다. 리브라는 글로벌 블록체인 기반 결제 네트워크가 되어야 하고, 임의의 스마트 컨트랙트를 실행해야 한다는 임무가 주어졌습니다.

저희는 모두 페이스북 직원이고 암호화폐에 대해 조금 알고 있지만, 대부분 컴퓨터 과학자입니다. 그래서 저희는 사람들이 어떤 종류의 프로그램에 흥미를 느끼는지, 이러한 프로그램을 작성하는 가장 이상적인 방법은 무엇인지 등 스마트 컨트랙트의 핵심을 알아보고자 합니다. 기존의 스마트 컨트랙트 언어를 가져와서 더 안전하고 더 좋게 개조해야 할까요? 주류 언어를 가져와 스마트 컨트랙트 언어로 바꿔야 할까요? 아니면 처음부터 무언가를 설계해야 할까요?

그래서 저희는 이 세 가지 옵션을 모두 검토했습니다. 가장 먼저 고려한 것은 주류 언어를 모든 언어에 맞게 개조하는 것이었습니다. 이를 위해 가장 중요한 요소는 커뮤니티, 많은 라이브러리, 많은 프로그래머가 알고 있는 언어, 다양한 도구, 스택 오버플로 등입니다. 기존 언어 커뮤니티를 활용할 수 있다면 가장 이상적입니다. 하지만 저희가 발견한 것은 이러한 스마트 컨트랙트 언어의 경우 다양한 이유로 인해 주류 언어를 사용할 수 없다는 것입니다. 거의 모든 주류 언어가 충족하지 못하는 기본 요구사항이 있습니다.

그중 하나가 결정론입니다. 스마트 컨트랙트 언어가 있다면, 여러 검증자가 실행하는 트랜잭션을 실행하여 동일한 답을 얻어야 합니다. 경쟁자가 결정론적이지 않다면, 그들은 그렇게 할 수 없을 것입니다. 따라서 결정론이 내장되어 있지 않고 결정론을 제거하기 위해 언어를 개조하기가 매우 어렵기 때문에 많은 수의 기존 프로그래밍 언어가 사용되지 않습니다.

해시맵을 반복하는 것은 해시맵에 어떤 주소가 있는지에 따라 달라지고, 사용 중인 코드 라이브러리 어딘가에 사용하는 해시맵이 있는지 알 수 없기 때문에 비결정적이라는 것을 상상할 수 있습니다. 이 이야기의 교훈은 해당 언어가 안전하지 않기 때문에 이러한 프로그램을 사용할 수 없다는 것입니다. 또 다른 한 가지는 스마트 콘트랙트 프로그램이 주류 프로그램과 매우 다르게 보인다는 것입니다. 스마트 콘트랙트 프로그램은 자산을 중심으로 운영됩니다. 일반적인 트랜잭션은 일부 자산을 입력으로 받아 읽고, 쓰고, 전송하는 과정을 거칩니다.

자산의 소유자 또는 소유자인 다른 사람에 대한 권한 개념도 있지만, 주류 언어에는 이러한 개념이 전혀 존재하지 않으며 훨씬 더 낮은 수준입니다. 자산을 나타내는 것은 아무것도 없습니다. 권위에 관한 것도 없고요. 지속성도 없습니다. 계정도 없고 트랜잭션 같은 것도 없습니다. 그리고 아마도 필요하지 않은 모든 것들이 있습니다. 그래서 저희는 주류 언어를 사용하면 좋겠지만, 기본적으로 언어의 큰 하위 집합을 가져와서 이를 적용하는 도구를 구축해야 한다고 생각했습니다. 이는 훨씬 더 복잡해질 것입니다.

저희는 솔리디티와 EVM을 살펴보고 무엇이 잘 어울리는지 살펴봤습니다. 그러던 중 주류 언어가 가지고 있는 주요 문제 중 하나가 바로 이러한 프로그램이 모두 자산에 관한 것이라는 사실을 발견했습니다. 코인을 다루고 있죠. NFT에 관한 것이죠. 돈에 관한 것이죠. 하지만 언어에는 실제로 자산을 나타내는 유형이나 값이 없습니다. 자산의 데이터 모델은 어딘가에 해시 테이블이 있고, 사용자 주소는 이 해시 테이블의 키이며, 자산의 바이트는 해시 테이블의 값이라는 것입니다. 한 사용자에서 다른 사용자로 자산을 전송하는 프로그램을 작성하려면 함수를 호출하여 해당 자산을 프로시저에 전달하는 것이 아니라 해시 테이블에 들어가서 자산을 전송하는 몇 가지 비트를 조작해야 합니다.

따라서 자산을 프로시저에 입력으로 전달하거나, 프로시저에서 자산을 반환하거나, 데이터 구조 안에 자산을 넣거나, 자산을 다른 자산 안에 감싸는 등 자산을 사용하는 코드에서 자연스럽게 하고 싶은 아주 기본적인 작업을 수행하기가 어렵습니다. 솔리디티와 이더리움에서는 자산을 표현할 수 없기 때문에 이러한 작업을 수행할 수 없습니다. 언어에는 유형이 없으며, 낮은 수준에서는 모든 것이 바이트일 뿐입니다. 이러한 개념은 존재할 수 없습니다.

따라서 Move 에서 가장 중요한 것은 에셋을 사용한 프로그래밍에 적합한 추상화를 제공하고 이를 가장 낮은 수준에서 언어에 구워내는 것입니다. 리소스 유형이라는 개념이 있는데, 일반적인 프로그래밍 언어의 구조체처럼 보이지만 실제 세계의 에셋에서 원하는 것과 같은 보호 기능을 갖추고 있습니다. 예를 들어, 이 리소스는 권한이 있는 작업이므로 처음부터 새로 만들 수 없습니다. 또한 고의든 실수든 복사할 수 없습니다. 일반적으로 프로그래밍 언어로 "x를 y와 같게 하자"라고 작성하면 실제로는 "y"를 복사하는 것입니다. 하지만 'y'가 실제 가치가 있는 코인이라면 당연히 복사하고 싶지 않을 것입니다. 이전 값인 y는 더 이상 사용할 수 없으며, 그리고 y는 한 번에 한 곳에만 존재한다는 것이 매우 중요합니다.

저희가 중점을 두는 또 다른 보호 기능은 사용자가 프로그램에서 코인을 전달하고 반환하는 것을 잊어버려 자산을 실수로 파괴하는 것을 방지하는 것입니다. 따라서 바이트코드 수준에서 유형 시스템을 통해 이러한 모든 것을 보장하는 리소스 유형이 있습니다. 따라서 악의적인 프로그래머나 실수로 인해 무력화될 수 없으며, 이는 Move 프로그래머로서의 권리 장전의 일부일 뿐입니다.

그 외에도 개선하려고 노력한 부분이 많습니다. 재접속과 같은 EVM 프로그램에는 많은 보안 문제가 있었고 지금도 여전히 존재합니다. Move 을 설계할 당시만 해도 모든 사람의 관심사였던 DAO 해킹은 희소 자산을 안전하지 않은 방식으로 재진입하는 재진입과 관련이 있었습니다. Move 에서는 모든 함수 호출이 정적이므로 언제 함수를 호출하는지, 어떤 코드가 직접 호출될지 컴파일 시점에 정확히 알 수 있으며, 공격자가 호출 프레임 중간에 악성 코드를 삽입하려고 해도 놀라지 않습니다. 안전한 코드를 작성하기가 훨씬 쉬워집니다. 또한 감사 담당자처럼 코드를 살펴보고 안전한지 판단해야 하는 사람들이 보다 신속하게 업무를 수행할 수 있습니다. 그리고 코드에 대해 추론하는 Move Prover와 같은 고급 도구를 구축할 수 있습니다.

저의 정적 분석 배경과 정적 분석 및 프로그램 검증을 담당하는 Move 팀의 배경에 맞게, 우리는 프로그램의 정확성에 중요한 속성을 작성하는 매우 고급 형식 검증 도구인 Move Prover라는 도구를 사용하여 언어를 공동 설계했습니다. 이 사람만 이 리소스에 액세스하거나 이 함수를 호출할 수 있어야 할 수도 있습니다. 시스템에서 이러한 객체의 총 개수는 10개여야 합니다. 이 객체는 이 시간까지 존재해야 하고 그 이후에는 소멸되어야 합니다. Move 증명자는 공격자나 다른 사람이 무엇을 하든 상관없이 가능한 모든 트랜잭션, 가능한 모든 프로그램 실행에 대해 이러한 속성이 유지되는지 확인합니다.

이것은 매우 강력합니다. 이는 우수성과 정확성에 대한 가장 높은 기준과도 같습니다. 컴파일러와 Move 툴 체인 전체에 통합된 기능입니다. 이를 통해 안전한 코드를 훨씬 쉽게 작성할 수 있습니다. 또한 감사자가 코드를 보는 대신 사양을 보고 증명자를 실행하기만 하면 되기 때문에 이해하기가 더 쉬워집니다. 증명자를 실행하면 올바른 것을 지정했는지, 도구 체인이 올바르게 작동하는지 확인할 수 있습니다. 프로그래머가 코드 작성에만 집중하고 재진입과 같은 난해한 보안 문제에 대해 덜 걱정할 수 있게 될 것으로 생각합니다.

이것이 바로 저희가 Move 을 만들 때 시도했던 일이며, Diem과 Novi에서 진행했던 작업과 현재 진행 중인 작업입니다.

질문 #3: Move 의 사용자 지정 변형을 사용하는 이유는 무엇인가요? 핵심 Move 프로그래밍 언어와 비교했을 때 큰 차이가 있나요?

Sam:

따라서 저희는 실제로 Move 의 커스텀 변형을 사용하지 않습니다. Move 의 특성은 흥미로운 언어입니다. 저희는 의도적으로 특정 블록체인에 국한되지 않는 핵심 언어가 있는 크로스 플랫폼 언어로 설계했습니다. 여기에는 스트럭스, 부울, 정수, 주소와 같은 개념이 있지만 계정, 트랜잭션, 특정 플랫폼에서 사용하는 암호화, 특정 플랫폼에서 사용하는 컨센서스와 같은 개념은 모두 추상화되어 있습니다.

실제로는 블록체인에 대해 전혀 언급하지 않는 작은 핵심 언어일 뿐입니다. 실제로는 다양한 용도로 사용할 수 있습니다. Sui , 스타코인, 앱토스, 0L 등 특정 블록체인에서 Move 을 사용하고 싶을 때(모두 Move 을 사용하는 플랫폼입니다), Move 을 인스턴스화하여 해당 블록체인과 해당 블록체인이 하려는 일에 맞게 특수화할 수 있습니다.

다른 스마트 콘트랙트 언어와 비교했을 때, EVM과 같은 것을 사용하면 이더리움의 작동 방식에 대한 많은 구현 세부 사항을 과도하게 충족할 수 있기 때문에 이 부분이 정말 중요하다고 생각합니다. 따라서 방금 말씀드린 주소, 계정 구조, 심지어 합의와 같은 모든 것들이 어느 정도는 EVM에 베이킹됩니다.

차세대 블록체인을 구축하려는 경우, 이더리움의 몇 가지 한계를 해결해야 합니다. EVM이 이러한 기능에 과도하게 적합하다면 이를 상속받아야 합니다. 이로 인해 이더리움보다 확장성이 뛰어나거나, 이더리움이 사용하지 않는 새로운 암호화를 사용하거나, 다른 방식으로 작동하는 계정을 사용하거나, 다른 방식으로 혁신을 시도하는 새로운 블록체인을 구축하기가 어려워집니다.

저희는 Move 를 한 플랫폼에만 묶어두고 그 플랫폼이 내린 디자인 결정에 영원히 얽매이지 않도록 만드는 것을 매우 중요하게 생각합니다. 새로운 플랫폼의 크리에이터에게 다양한 실험을 할 수 있는 많은 여지를 주어 공간 전체를 발전시킬 수 있도록 하고 싶습니다. 하지만 동시에 새로운 플랫폼에 갈 때마다 새로운 블록체인을 하나씩 배울 필요는 없으며, 이는 오늘날의 최신 기술입니다.

솔라나는 솔라나만의 일을 합니다. 이더리움은 이더리움대로, 폴카닷은 폴카닷대로 각자의 일을 합니다. 플랫폼마다 하나의 언어만 있다면 활기찬 개발자 커뮤니티, 재사용 가능한 도구 또는 어디서나 사용할 수 있는 라이브러리를 만드는 데 좋지 않습니다. 내부적으로 매우 다른 다양한 플랫폼에서 작업해야 하며, 그렇지 않으면 활기찬 커뮤니티를 구축할 수 없습니다. 저희는 처음부터 플랫폼의 세부 사항에 지나치게 얽매이지 않고 핵심( Move )에 대해 매우 신중하게 생각했습니다.

원래 질문으로 돌아가서 길게 설명하자면, 실제로 기본값 Move 은 없지만 Sui 은 다른 것을 사용한다는 것입니다. 어떤 플랫폼에서도 사용할 수 없는 기본 Move 이 있습니다. 원래 Diem에서 사용되었던 전문화가 있는데, 저희는 Sui 에서 매우 다른 전문화를 하고 있습니다.

원래 Diem은 어떤 계정이 존재할 수 있는지, 해당 계정에 존재할 수 있는 물건의 종류, 계정 간 물건 이동 규칙에 대해 매우 엄격한 제한이 있는 임의의 스마트 컨트랙트를 수행하는 규제된 결제 네트워크였어야 했습니다. 예를 들어, 상대방이 사전에 "이 특정 유형의 물건을 받을 수 있도록 허락을 받고 싶습니다"라고 말하지 않는 한 다른 주소로 물건을 보낼 수 없다는 등의 결정이 내려졌죠. 이는 자본 통제와 같은 것들이 있었기 때문에 적절했습니다. 특정 관할권에 있는 계좌는 미국 달러를 받을 수 없었습니다. 따라서 누군가가 허락 없이 미국 달러를 송금할 수 없도록 하는 것이 매우 중요했습니다.

개방형 웹3.0 세계에서 이는 매우 안타까운 일입니다. 사전에 명시적으로 동의하지 않아도 누군가에게 NFT를 에어드랍하거나 토큰을 보내거나 무언가를 선물할 수 있기를 원할 것입니다. Sui 에서는 그렇게 할 수 있습니다. 오브젝트에는 전송 기능이 내장되어 있습니다. 오브젝트, NFT 등을 생성할 때 Sui 에서 전송 기능은 사용자가 직접 구현해야 하는 것이 아닙니다. 플랫폼의 기능으로 내장되어 있으며 성능도 매우 뛰어납니다.

투기 방지를 위해 특정 날짜 이후에만 전송할 수 있도록 제한하거나, 전송할 때 로열티를 지급하고 싶은 NFT가 있다면 대신 인코딩하는 방법이 있습니다. 하지만 기본적으로 모든 것을 자유롭게 전송할 수 있으므로 Diem 및 Diem 스타일의 인스턴스를 사용하는 다른 플랫폼보다 훨씬 쉽게 오픈 플랫폼을 구축할 수 있습니다.

또 다른 한 가지는 객체 중심성과 자산이 Move 에 얼마나 중요한지에 대해 많이 이야기해 왔다는 점입니다. Diem에 통합하는 방식에서 프로그래밍 관점에서 이를 실제로 달성했습니다. 최종 사용자 관점에서 트랜잭션이 사용자에게 어떻게 보이는지에 대한 측면에서는 그렇지 않았습니다. 트랜잭션의 함수 서명에는 여전히 문자열, 주소 또는 부울만 사용할 수 있었습니다. 이 트랜잭션이 객체에 대해 무엇을 할 것인지, 무엇을 건드릴 것인지 확인하기가 매우 어려웠습니다.

Sui 트랜잭션 모델은 자산 중심이며, 특정 함수가 체인에 게시되어 트랜잭션이 발생하면 해당 함수는 구조화된 객체를 입력으로 받습니다. 지루한 원숭이를 전송하는 경우, 해당 함수는 전송이라고 불리며, 해당 함수에는 지루한 원숭이라고 불리는 유형이 있습니다. 일종의 대체 불가능한 토큰 마켓플레이스에 지루한 원숭이를 올린다면, 해당 마켓플레이스가 트랜잭션의 명시적 서명이 될 것입니다. 트랜잭션은 입력으로 들어오는 이러한 객체에만 영향을 줄 수 있습니다. 따라서 최종 사용자나 툴링 작업을 하는 사람이 트랜잭션을 보면 해당 트랜잭션이 어떤 오브젝트를 건드리는지, 그리고 이동 유형 권한을 통해 해당 오브젝트로 무엇을 할 것인지 매우 명확하게 알 수 있습니다. 변경할 것인가? 전송할 건가요? 아니면 읽기만 할까요?

Move 의 장점을 스택에 더 깊숙이 적용하여 최종 사용자가 코드를 실행하고 어떤 일이 일어나는지 확인하는 대신 이를 볼 수 있도록 하는 것이 훨씬 쉬워졌습니다.

또 한 가지 중요한 변경사항이 있는데, 이는 더 넓은 암호화폐 공간에서 성장하고 있는 NFT에 매우 중요하다고 생각하며, 이질적인 컬렉션을 만들 수 있는 기능이 필요하다는 것입니다. 다양한 유형의 요소를 가진 컬렉션을 말합니다. NFT 컬렉션이나 마켓플레이스와 같은 것이 있을 때, 그 아래에 있는 모든 NFT가 동일한 Move 유형을 갖는 것은 아닙니다. 그림이나 음반 등이 포함된 컬렉션을 갖고 싶을 때 불편할 수 있기 때문입니다. 이들은 모두 서로 다른 Move 유형으로 구분할 수 있는 필드가 다릅니다.

Move 을 Diem과 핵심 Move 언어에 통합하는 과정에서 모든 컬렉션은 동질적이어야 합니다. 즉, 모두 동일한 유형의 객체를 가져야 합니다. Move 에서는 명시적인 객체 계층 구조를 통해 이 문제를 해결했습니다. 각 객체에는 최종 사용자의 주소가 될 수 있는 소유자가 있지만, 객체의 소유자는 다른 객체의 ID일 수도 있습니다. 이를 통해 객체 간에 부모와 자식 관계를 생성할 수 있으며, 컬렉션을 나타내는 부모 객체가 있고 해당 컬렉션의 각 사물이 해당 객체의 자식인 것처럼 NFT 컬렉션을 나타낼 수 있습니다.

예를 들어, 녹음 NFT는 하나의 자식이고, 그림 NFT는 또 다른 자식이고, 다른 것이 또 다른 자식일 수 있습니다. 이 기능을 사용하면 컬렉션을 터치할 때마다 컬렉션의 모든 요소에 액세스하는 데 비용을 지불하지 않고도 이전 인스턴스화에서 작동했던 방식대로 대규모 컬렉션을 가질 수 있습니다.

Move 에서 Sui 로의 이전을 통해 우리가 한 일의 하이라이트 중 일부는 Diem으로의 이전이라는 원래의 인스턴스화를 뛰어넘는다고 생각합니다. 하지만 앞으로 이곳에서 할 수 있는 다른 아이디어와 흥미로운 일들도 많이 있습니다. 또한 다른 사람들이 새로운 Move 기반 플랫폼을 만들 때 Move 에서 무엇을 할 수 있을지 매우 기대됩니다. 객체와 에셋으로 프로그래밍할 수 있는 안전한 추상화의 기반을 제공하는 것도 언어의 정신이지만, 사람들이 새로운 Move 기반 플랫폼을 만드는 방식에 있어서도 창의성을 발휘하길 바랍니다.

질문 #4: Move 에서는 사용자에게 다양한 형식의 개체를 어떻게 표시하나요?

Sam:

이 질문은 탐색기에 사물이 표시되는 방식을 말하는 것 같습니다. 각 거래에 대한 많은 정보, 모든 개체에 대한 아이디어, 호출되는 함수, 어떤 개체를 사용하기 위해 비용을 지불했는지, 가스 비용을 지불하기 위해 무엇을 사용했는지 등 많은 정보가 있습니다. 최종 사용자에게 너무 많은 정보를 제공하는 것 같다는 질문을 들었습니다. 저도 그 의견에 동의합니다. 익스플로러는 빌더를 위한 플랫폼이며, 빌더는 비용 지불에 어떤 코인을 사용할지 결정하고, 무엇이 잘못되었는지 디버깅하고, 전체 세부 정보를 확인할 수 있도록 이 모든 정보가 정말 필요합니다.

탐색기에서는 이 모든 작업을 쉽게 할 수 있는 기능에 중점을 두었습니다. 앞으로 익스플로러는 일반 사용자보다는 블록체인의 파워 유저를 위한 기능이라고 생각합니다. 지갑과 같이 많은 것을 추상화하여 사용자가 관심 있는 토큰이나 상호 작용할 덱과 같은 관련 세부 정보만 표시하는 경우입니다.

저희는 Sui 지갑에서 이러한 많은 작업을 해왔습니다. 사용자 경험과 Sui 트랜잭션이 얼마나 더 부드럽고 추상적으로 보이는지에 대해 매우 만족하실 거라고 생각합니다. 지갑 기능 중 특히 기대되는 한 가지는 사람이 읽을 수 있는 서명 요청이라는 기능을 개발 중이라는 점입니다. 이더리움, 솔라나, 그리고 제가 아는 다른 모든 블록체인의 가장 큰 문제점은 트랜잭션을 보면 트랜잭션이 무엇을 하고 있는지, 어떤 함수가 호출되는지는 알 수 있지만 그 이상의 정보는 알 수 없다는 것입니다. 최종 사용자에게 해당 함수의 코드를 찾아보고 제대로 작동하는지 확인하도록 요청할 수 없기 때문에 안전한 지갑을 만들기 위한 코드를 작성하기가 매우 어렵습니다.

기술 전문가가 아닌 최종 사용자에게는 항상 너무 어려운 일입니다. 이로 인해 많은 사기가 발생하고 있습니다. 기본적으로 사람들은 서명 요청이 신뢰할 수 있는 출처에서 온 것이기 때문에 서명하는 것이지, 서명 요청이 실제로 어떤 기능을 하는지 알기 때문에 서명하는 것이 아닙니다. 최근 지루한 유인원 커뮤니티에서 해킹이 발생했는데, 운영자가 "이봐요, 여기서 경품 이벤트가 열리고 있어요. 이 거래를 클릭하여 지갑을 연결하고 서명하면 한정판 상품을 드립니다."라는 메시지를 보냈습니다. 많은 사람들이 메시지의 출처를 신뢰했기 때문에 그렇게 했습니다. 하지만 알고 보니 이 디스코드는 해킹을 당했고 많은 사람들의 에이프, 돈, 기타 물건이 도난당했습니다.

저희( Sui )가 진정으로 원하는 것은 안전한 서명을 위해 서명 요청 소스에 의존할 필요가 없는 것입니다. 저희가 원하는 것은 도구 관점에서 서명 요청을 사람이 읽을 수 있고 권한을 부여하는 것으로, Android나 iOS에서 "여기 서명 요청이 있습니다"라는 메시지가 표시되는 것과 같은 방식입니다. 이렇게 하면 지루한 원숭이를 읽을 수 있는 권한이 부여되며, 이 권한은 양도하거나 도용할 수 없으므로 무해합니다. 반면, 누군가의 디스코드가 해킹되어 서명 요청이 포함된 메시지를 보냈는데 도구에 "이것은 프로모션 경품 이벤트입니다"라고 표시되어 지루한 원숭이를 전송할 수 있는 권한을 부여하는 경우입니다. 이쯤 되면 "잠깐만요, 이건 안전하지 않은 것 같은데요. 이걸 읽어야만 프로모션 상품을 받을 수 있는데, 양도를 요청하고 있으니 서명하지 않을 것 같아요."라고 생각할 수 있습니다.

그래서 저희는 Sui 지갑에 이와 같은 기능을 추가할 예정입니다. 이 기능을 통해 웹3.0 지갑을 사용하는 사용자들은 사기나 불쾌한 일들에 대해 걱정할 필요가 없기 때문에 훨씬 덜 위협적이고 안전해질 것으로 생각합니다. 이 도구는 전화번호부, 마이크, 위치 등에 액세스할 수 있는지 묻는 안드로이드 앱과 같이 모바일 플랫폼에서 흔히 볼 수 있는 권한을 부여하여 사용자를 보호할 것입니다. 이는 사용자가 이해할 수 있는 어휘 유형입니다.

그렇기 때문에 저희는 Sui 에서 Move 의 멋진 구조화된 표현을 사용하여 사용자에게 해당 정보를 제공할 수 있도록 객체 수준에서 제공하고자 합니다. 질문에 대한 답을 간단히 말씀드리자면, 익스플로러가 저희가 원하는 큐레이션된 최종 사용자 경험을 제공하지 못한다는 말씀이 맞다고 생각하지만, 저희는 지갑에서 이러한 경험을 제공할 것이며, 이를 선보일 수 있게 되어 매우 기쁩니다. 저희는 다른 곳보다 더 나은 경험을 제공할 수 있는 플랫폼 기능을 갖추고 있습니다.

질문 #5: Sui의 표준 라이브러리에서 랜덤 제너레이터도 제공하나요?

Sam:

결국에는 그렇겠죠. 괴짜이고 Sui 의 컨센서스를 따르는 분이라면 저희가 일각고래 엄니를 사용한다는 것을 알고 계실 겁니다. 일각고래 엄니 논문을 읽어보셨다면, 합의 과정에서 무작위성을 생성하기 위해 공통 코인이라는 것을 사용하는 Tusk의 변형이 있습니다. 아직 구현된 기능은 아닙니다. 하지만 구현이 완료되면 Move 을 통해 플랫폼 기능으로 무작위성을 노출할 수 있게 될 것입니다. 안전한 무작위성을 가진 다른 체인이 없기 때문에 이것은 엄청난 일이 될 것입니다. 안전하지 않다는 것은 스마트 컨트랙트 프로그래머를 위한 플랫폼 기능으로 지적하고 싶은 다른 이야기입니다.

한편, 플랫폼 기능이 아니더라도 무작위성을 얻을 수 있는 다른 방법은 여전히 많이 있습니다. 저희는 방정식의 일부로 무작위성이 필요한 크립토키티 스타일의 유전자 프로그래밍을 연구해왔습니다. 우리가 할 수 있는 흥미로운 일이 있습니다:

• 트랜잭션이 있으면 해시가 있습니다. 사용자가 트랜잭션에 들어가는 내용을 제어한 다음 해시를 변경할 수 있기 때문에 해시 자체는 무작위성의 소스로 사용하기에 좋지 않습니다.
• 대신 무작위성에 트랜잭션 ID와 다른 많은 사람이 접근할 수 있는 온체인 필드가 모두 포함되도록 설정할 수 있습니다.
• 따라서 난수가 무엇인지, 이 온체인 값을 해싱한 결과가 무엇인지, 트랜잭션 해시가 어떻게 될지 예측하기가 매우 어렵습니다.
• 궁극적으로 무작위성을 게임화하기가 매우 어렵습니다.

코드에 도표가 없어 자세히 설명하기는 어렵지만, 특정 경우에 효과가 있는 무작위성에 대한 몇 가지 좋은 접근 방식이 있습니다. 장기적으로는 이 기능을 플랫폼 기능으로 제공할 수 있게 되어 매우 기쁩니다.

질문 #6: 튜토리얼을 제공하나요? 초보자가 이 언어를 쉽게 배울 수 있는 방법이 있나요?

Sam:

최근 파트너로부터 받은 피드백에 따르면, 솔리디티 세계에서 오신 분이라면 Move 을 배우기가 매우 쉽습니다. 저희가 예상한 바에 따르면 솔라나의 스마트 컨트랙트 프로그래밍 프레임워크를 배우는 데 몇 달이 걸렸던 것에 비해 약 4~5일이면 마스터할 수 있습니다.

스마트 컨트랙트 프로그래밍에는 근본적으로 어려운 몇 가지 특이한 점이 있습니다. 가장 이상적인 배경은 다른 분야에서 스마트 컨트랙트 프로그래머로 활동한 사람이라고 생각합니다. 또한 스마트 컨트랙트 프로그래밍을 처음 접하는 웹2.0 배경을 가진 분들도 쉽게 접근할 수 있다고 생각합니다. Move 는 강력한 타입 시스템과 컴파일러를 통해 올바른 작업을 수행할 수 있도록 안내해줍니다. 처음에는 코드를 컴파일하는 것이 조금 어려울 수 있지만, 도구 체인은 작동하는 코드를 얻을 수 있도록 안내하도록 설계되었습니다. 일단 코드가 작동하면 안전할 것입니다. 솔리디티로 시작하면 재입력이나 기타 보안 문제와 같은 어려운 문제에 대해 배울 필요가 없습니다.

Rust 언어를 사용해 본 적이 있다면 Move 에 빠르게 접근할 수 있을 것입니다. Rust 팬이거나 Rust로 코드를 작성해 본 적이 있다면 Move 을 보면 구문상 많은 유사점을 발견할 수 있을 것입니다. Move 의 기능이 동일한 Rust 기능과 매우 유사하거나 동등한 경우 의도적으로 그렇게 합니다. Move 에 있는 기능이 Move 에 있다는 것을 상기시키기 위해 의도적으로 구문상의 차이를 두었습니다. Rust를 사용한다고 해서 동일하게 작동할 것이라고 생각하지 마세요. 특히 차용 검사기라고 부르는 참조 유형 시스템의 경우, Move 에는 훨씬 더 간단한 버전인 Rust의 차용 검사기가 있으며, 이는 Rust 프로그래머에게 친숙할 뿐만 아니라 배우기도 더 쉬울 것으로 기대합니다.

저희는 어디서든 쉽게 배울 수 있도록 Move 을 만드는 데 많은 신경을 쓰고 있습니다. 이를 위해 다양한 튜토리얼과 교육 콘텐츠를 개발하고 있습니다. 현재 출시된 콘텐츠는 다음과 같은 시리즈입니다. 객체를 사용한 프로그래밍이 시리즈는 Move 팀원 중 한 명이 작성한 것으로, 이 변형의 특정 렌즈를 통해 Move 에 들어가는 방법을 단계별로 설명합니다. 제가 아는 한 이것이 가장 좋은 소개라고 생각하며, Move 책을 보고 보완할 수 있습니다.

Move 책은 Move 기여자들이 만든 것으로 Move GitHub 리포지토리에 호스팅되어 있습니다. 이에 대한 많은 링크가 저희의 Sui docs. 또한 Move Book,도 있습니다. Move 의 모든 기능을 처음부터 끝까지 다룬 또 다른 책입니다.

저는 항상 튜토리얼이나 예제로 시작하는 것을 좋아합니다. GitHub에 다음과 같은 디렉토리가 있습니다. Sui_Programmability/Examples라는 디렉터리에 대체 가능한 토큰, 대체 불가능한 토큰, 대체 불가능한 토큰, 마켓플레이스, 게임의 예제 코드가 있습니다. 코드를 보고 모방하거나 수정하면서 배우는 것을 좋아하신다면 이것도 정말 좋은 방법입니다. 트위터에는 좋은 리소스가 많이 있지만, 활기찬 커뮤니티를 구축하기 위해 하고 싶은 일과 해야 할 일이 훨씬 더 많습니다.

Jen:

좋은 소식은 내부 엔지니어링 팀이 이러한 정보를 제공하는 데 매우 열정적이라는 점입니다. 앞으로 몇 주 동안 이 팀과 긴밀히 협력하여 화면 녹화를 통한 단계별 안내와 같은 다양한 유형의 학습 자료를 제공할 수 있는 방법을 모색하고 있습니다. 또한 실제로 어떻게 진행되는지 설명하는 블로그 게시물과 함께 GIF 형식으로 제작하는 방안도 검토하고 있습니다. 여기에서 이루어지는 채팅과 관련하여, 커뮤니티가 원하는 학습 방법에 대한 제안과 추천을 기꺼이 받겠습니다. 이는 학습 자료를 구성하는 데에도 도움이 되며, 여러분이 이해하기 쉽고 이해하기 쉬운 방식으로 정보를 공유할 수 있도록 하는 데에도 도움이 됩니다.

Sam:

네, 그 얘기를 꺼내주셔서 감사합니다. 저희는 학습에 가장 적합하다고 생각되는 리소스( Move)를 제작하고 있지만, 저희는 디자인에 종사하는 사람들과 이 언어에 대해 매우 깊이 알고 있는 사람들이라는 특이한 위치에서 출발하고 있습니다. 따라서 기존 문서 튜토리얼의 좋은 점, 보고 싶은 내용, 가장 도움이 될 만한 내용에 대한 피드백을 보내주시면 대단히 감사하겠습니다. 여러분의 도움이 정말 필요하며 대단히 감사합니다.

질문 #7: 특히 개발 중인 커뮤니티가 Sui 프로젝트에 매우 중요하다는 것을 알고 있는데, 어떤 커뮤니티 개발 계획이 있나요?

Sam:

Sui 에서는 다각적인 접근 방식을 취하고 있습니다. 이는 커뮤니티와 관련된 마케팅 전략에도 약간 영향을 미칩니다. Sui 에서 가장 기대되는 사용 사례는 사람들이 수천만 명의 대규모 사용자 기반을 충족하는 사용 사례를 구축하는 경우입니다. 기존 블록체인에서는 비용 효율적인 방식으로 할 수 없는 일들이기 때문입니다.

저희가 정말 기대하는 분야 중 하나는 게임입니다. 저희가 초기에 글을 쓰고 이야기했던 많은 파트너들을 살펴보면, 게임이 이미 디지털 자산을 중심으로 구축된 비즈니스인 경우를 많이 볼 수 있습니다. 동일한 퍼블리셔가 브랜드와의 크로스 프로모션이나 기타 흥미로운 일을 하기 위해 게임 자산과 온체인 자산 중 일부를 게임 자산으로 전환하여 여러 게임에서 상호 운용성을 위한 유동성에 더 폭넓게 접근할 수 있게 하는 것은 NFT와 매우 자연스러운 시너지 효과가 있습니다.

저희는 크고 작은 게임 스튜디오와 많은 작업을 진행하고 있습니다. Sui 의 고유한 기능을 활용하여 어떻게 하면 NFT를 비롯한 웹3.0 기능과 온체인 부정행위 방지, 크리에이터 수익화 등의 흥미로운 아이디어를 게임에 도입하고 이 모든 것이 작동하도록 할 수 있을지 고민하고 있습니다.

저희와 구축 커뮤니티의 핵심 기둥은 많은 사용자가 필요하고 플랫폼에 이러한 게임 회사와 같이 많은 최종 사용자를 보유한 대형 플레이어가 필요하며, 이상적으로는 두 개의 대형 게임을 가져와서 웹3.0을 모두 합친 것보다 더 많은 사용자를 플랫폼에 확보한 다음, 실제로 확장 가능한 블록체인이 이러한 사용자에게 제공할 수 있는 유용성을 보여주는 것입니다.

동시에, 저희는 게임 이외의 것에도 많은 관심을 가지고 있습니다. 웹3.0을 폐지하게 만드는 것은 스마트 컨트랙트 개발자 고객층에서 더 많이 나올 웹3.0의 경제 엔진, 인덱스 구축, NFT 마켓플레이스 구축과 같은 것들입니다. 저희는 다른 플랫폼에서 이러한 것들을 구축하는 방법을 아는 사람들이 Sui 에서 계속 그렇게 할 수 있도록 정말 쉽게 만들고 싶어요. 그리고 Sui의 고성능과 고유한 기능, 그리고 우리가 가진 멋진 무브 프로그래밍 모델을 활용하는 차세대 버전을 구축할 수 있습니다.

개발자가 애플리케이션에 서비스를 제공하는 데 사용할 수 있는 좋은 읽기 API를 보유하거나 체인에서 발생하는 이벤트를 쿼리하고, 온체인 분석을 수행하며, 다른 플랫폼의 유동성과 NFT를 Sui 로 가져오는 가교 역할을 하는 것과 같은 또 다른 종류의 엔티티가 있습니다. 이 또한 파트너십과 커뮤니티 구축 측면에서 저희가 노력하고 있는 부분입니다.

물론 그들은 반드시 빌더가 아니거나 파트너가 아니더라도 모드가 되는 것에 흥분하고, Sui 커뮤니티는 Sui 사용 사례나 Sui토큰을 전도하거나 함께 일하거나 소셜 미디어에서 Sui 팔로우하거나 Sui 에 대해 글을 쓰거나 사용자를 교육하거나 작동 방식에 대해 사람들을 교육하고 있습니다. 이 모든 것이 우리에게 매우 소중하기 때문에 커뮤니티는 한 가지가 아니라 Sui 에 무엇이 필요한지 생각해야 하며, 사람들이 있는 곳에서 사람들을 만나고 그들이 무엇에 흥미를 느끼는지? 그리고 그들이 우리를 어떻게 도울 수 있을까요? 아시다시피 저는 CTO이자 기술 담당자이므로 이에 대한 특정 관점을 가지고 있습니다. 하지만 이 모든 일에 깊이 관여하는 사람으로서, 그리고 이러한 문제에 대해 더 경험이 풍부하고 명료하게 설명할 수 있는 사람으로서 Jen의 생각을 듣고 싶습니다.

Jen:

전혀 예상하지 못했는데 이렇게 해주셔서 감사합니다. 커뮤니티 측면에서는 지금까지 사람들이 잘못된 점에 대해 정말 솔직하게 이야기해 주었고, 수정해야 할 사항이나 저희가 미처 대응하지 못한 부분에 대해 개인적으로 연락해 주신 것에 대해 정말 감사하게 생각합니다: 풀노드, 우리는 커뮤니티의 반응에 푹 빠져 있었고, 분명히 라이브를 시작하면 무언가가 깨지거나 고쳐야 할 문제가 있기 때문에 사람들이 우리가 가진 문제에 대해 매우 솔직 해졌지만, 이러한 문제를 해결하려고 할 때 모든 사람들이 얼마나 인내심을 가지고 있었는지 지적하고 싶습니다.

커뮤니티 프로그램과 관련해서는 최근 멋진 개발자 관계 책임자인 브라이언을 영입하여 현재 진행 중인 많은 프로그램에 도움을 주고 있으며, 곧 있을 AMA에서도 브라이언을 만날 수 있게 되어 매우 기쁩니다. 하지만 브라이언을 통해 제대로 된 프로그램도 구축할 예정입니다. 모드 프로그램 자체의 진행이 다소 느리다는 것을 알고 있고, 여전히 지원서를 받고 있지만 짧은 시간 동안 500개가 넘는 지원서가 접수되었다는 점을 강조하고 싶습니다. 따라서 지원자 한 명 한 명의 글을 읽고 최대한 피드백을 제공하고자 합니다.

따라서 저희 프로그램은 단순히 모드를 기반으로 하는 것뿐만 아니라 시각화가 정말 뛰어난 크리에이터를 영입하는 방법도 앞으로 검토하고 있습니다. 여러분 중 많은 분들이 그래픽 디자인에 뛰어난 재능을 가지고 있다는 것을 알고 있습니다.

마지막으로 중요한 것은 지역 시장에 어떻게 진출할 것인가 하는 점입니다. 현지 시장에 대한 전문 지식을 갖추고 있으며 영어를 주로 사용하지 않는 사람들도 번역과 정보에 접근할 수 있도록 도와줄 수 있는 사람들이 필요합니다. 따라서 저희는 자체 채널에 게시하는 것뿐만 아니라, 많은 분들이 텔레그램이나 트위터 또는 특정 디스코드 서버를 통해 구축한 신뢰도를 바탕으로 각자의 커뮤니티 내에서 자료를 공유하고자 하는 사람들이 자료에 액세스할 수 있도록 하기 위해 이러한 모든 사항을 검토하고 있습니다. 따라서 저희는 이 열차를 멈추게 하고 싶지 않으며, 여러분이 정보를 얻을 수 있도록 자료가 있는지 확실히 확인하고 싶습니다.

트위터의 커뮤니티 이니셔티브와 트위터가 봉쇄되지 않고 여러분과 함께 협력하기 위해 얼마나 노력하고 있는지에 대한 질문에 대한 답변이 되었기를 바랍니다. 반전된 답변에 감사드립니다.

질문 #8: Sui 의 강점은 무엇이며 다른 업체와 차별화되는 점은 무엇인가요?

Sam:

네, 물론이죠. 한 가지만 말씀드리자면, Sui 은 처음부터 증가하는 수요를 처리하고 수수료와 네트워크를 안정적으로 유지할 수 있도록 설계되었다는 점입니다. 기본적으로 저희 창립팀은 많은 사람들이 Diem과 Novi에서 수년간 멋진 블록체인을 구축한 경험이 있지만, 저희가 구축하고 있는 블록체인은 은행 간 결제 레이어로 설계되어 수백 개의 바스프가 프라이버시를 위해 대부분 오프체인에서 거래를 하지만, 결국에는 일부 규정 준수 확인을 통해 체인에서 일부 결제를 수행하도록 설계되었습니다. 우리가 설계한 것에는 몇 가지 좋은 점이 있지만, 임의의 스마트 컨트랙트를 처리하고 여러 대의 컴퓨터를 넘어 샤딩을 사용할 수 있는 검증자 소프트웨어를 갖추거나 초당 1000건의 트랜잭션을 넘어서는 높은 처리량을 처리할 수 있도록 확장하도록 설계되지는 않았습니다. 그래서 저희는 결제 사용 사례에 이 모든 것이 필요하다고 생각했습니다.

물론 미스텐을 시작할 때 DEM 플랫폼 위에 구축하는 것을 고려했지만, 저희는 시스템 작업을 해왔기 때문에 이 플랫폼의 한계에 대해 잘 알고 있었고, 이 플랫폼이 무엇을 하도록 설계되었고 무엇이 아닌지 알고 있었으며, 높은 처리량을 처리하는 L 플랫폼을 실행할 때 발생하는 모든 어려운 문제를 처리하기 위해 어떻게 확장할 수 있는지, 상태 부풀림을 어떻게 처리할 수 있는지 등을 조사했습니다. 샤딩은 어떻게 할까요? 수평적 확장성은 어떻게 할까요? 어떻게 구현할까요? 어떻게 하면 개발자 경험을 개선할 수 있을까요? 저희는 이 방식이 설계된 방식이 아니었고, 다른 방식으로 하면 이러한 많은 일들이 더 쉬워지고 Sui, 특히 게임 분야의 많은 파트너와 이야기를 나누면서 이 방식이 필요하다는 것을 알았기 때문에, 천만 명의 사용자가 있고 모든 사용자가 하루에 수천 건의 트랜잭션을 처리하기를 원한다고 말했고, 저희는 '그래, 계산을 해봐라. 이런 파트너가 한 명 있는데 또 다른 파트너가 들어온다면 용량이 부족해서 사람들을 내쫓는 것이 아니라, 모든 사용자를 플랫폼에 환영하고 트래픽이 아무리 많아도 규모를 유지할 수 있기를 원합니다.

이것이 바로 우리가 수평적 확장성을 허용하는 Sui 이라는 새로운 데이터 모델을 생각해 낸 방법입니다. 이것이 바로 우리가 여기서 추구하는 핵심 속성입니다. 검증자라면 한 대의 컴퓨터를 실행하고 일정량의 처리량과 일정량의 스토리지를 확보할 수 있지만 수요가 급증하면 다른 컴퓨터를 추가하고 다른 컴퓨터를 프로비저닝하여 더 많은 처리량과 스토리지를 확보할 수 있으며 전체 네트워크는 커뮤니티의 요구를 충족하는 데 필요한 만큼만 계속 확장할 수 있습니다.

중요한 것은 분산화된 시스템 확장 기술을 통해 검증자가 다른 검증자가 어떤 샤드를 실행하는지 알아야 하고, 사용자는 크로스 샤드 트랜잭션과 같은 세부 사항에 대해 걱정해야 하며, 무언가를 하고 싶었지만 데이터가 다른 샤드에 저장되어 있고 다른 보안 모델이나 다른 비용 모델이 있다는 사실을 알게 되는 멋진 탈중앙화 샤딩 프로토콜을 원하지 않는다는 점입니다. 사용자는 '여기 글로벌 지분이 있고, 트랜잭션을 연못에 던져 넣으면 결과가 나에게 돌아오면 끝이다'라고 생각하면 됩니다. 아키텍처는 이를 가능하게 하고 수평적 확장성을 제공합니다.

이것이 바로 저희가 집중하고 있는 부분입니다. 이것이 다른 모든 프로젝트와 차별화되는 점이라고 생각하며, 특정 TPS 수치와 같은 확장성에 대해 생각하지 않고 머신당 얻을 수 있는 TPS가 얼마인지, 그리고 그 수치를 필요한 만큼 올릴 수 있도록 시스템을 어떻게 설정할 것인지에 대해 생각합니다, 그렇지 않으면 웹3.0은 단일 머신 또는 단일 시스템이 처리할 수 있는 최대 TPS 수치만큼만 커질 것이기 때문에, 우리는 사람들이 우리에게 던지는 모든 것을 처리할 수 있는 유연성을 확보하기를 원합니다.

이것은 철학적 입장에 가깝지만 시스템 설계에 깊이 들어가서 우리가 왜 우리가 한 일을했는지, 우리가 무엇을 목표로하고 있는지, 심지어 개발자 커뮤니티와 같은 것들까지도 우리 사람들이 "아, 이제 EVM에서 솔리디티를 했어야하는 것과 같은 효과가 있습니다. Sui 그리고 나서 숫자를 보면 EVM을 기반으로 구축하는 개발자가 4000 명이라는 것을 알 수 있습니다, 하지만 1,600만 명의 자바스크립트 개발자나 1,200만 명의 iOS 개발자에 비하면 적은 숫자이고, 대규모 개발자 커뮤니티가 차세대 절대적인 세계를 구축하려면 4000명보다 훨씬 더 많은 인원이 필요합니다. 따라서 단순히 사람들을 전환하도록 설득하는 것이 아니라 주류로 끌어들이고 스마트 컨트랙트 개발자를 성장시킬 수 있는 개발자 확보 전략이 필요합니다.

따라서 저희가 하는 모든 일은 향후 수백만, 수십억 명의 사용자와 암호화폐를 더 이상 틈새 시장이 아닌 큰 시장으로 만드는 방법에 대해 생각하고 있습니다.

Jen:

이것이 우리가 실제로 검토한 양식에서 나온 최종 질문이지만, 아트 런치를 통해 나온 질문도 꽤 많이 있습니다. 재미있는 질문이 하나 나왔는데요, 실제로 처음 나온 질문입니다. 청중, 기분 패턴에 관한 책을 쓰고 있다고 쓰신 분이 '핫 포테이토'는 누가 생각해냈냐고 묻습니다. 그리고 어디에 넣어야 할까요?

Sam:

오래 전에 Facebook에서 이 이야기를 나눴는데, 기억을 더듬어 보면 여러 Move 팀원들이 동시에 아이디어를 내고, 이를 실행에 옮긴 다음 어떻게 작동할지 알아냈습니다. 제가 광범위하고 뜨거운 감자를 가지고 있긴 하지만 이동 어빌리티 시스템과 함께 사용되는 구체적인 방법이 있는데, 이 어빌리티 시스템은 Move 컴파일러를 만든 Todd Nowacki가 설계한 것으로, 이전에 AMA에서 들어보셨을 겁니다.

핫 포테이토는 어쩔 수 없이 사용해야 하는 무언가가 있다는 아이디어도 좋지만, 이를 가능하게 하는 유형 시스템 기능은 정말 유연하고 확장 가능한 방법이기 때문에 Todd가 그 공로를 인정받아야 할 것 같습니다. 하지만 Move 이 모든 것은 팀의 노력이며, 서로 아이디어를 주고받으며 최고의 버전을 만들어 냅니다.

질문 #9: Sui 에서 Move 로 테스트하는 미래에 대해 어떻게 생각하시나요? Move 로 작성하는 것이 더 기반이 될까요? 아니면 사람들이 Move 이외의 언어로 작성하기 위한 안전모와 같은 프레임워크를 개발하게 될까요?

Sam:

이미 Move 에서 테스트를 작성할 수 있는 단위 테스트 프레임워크가 있으며, 앞으로도 Move 코드를 테스트하는 가장 인기 있는 방법이 될 것으로 생각합니다.

커뮤니티에서 사람들은 질문자께서 말씀하신 것처럼 자바스크립트나 다른 곳에서 테스트를 작성하는 하드햇과 같은 것을 사용하여 시작했습니다. 하지만 시간이 지남에 따라 견고하게 직접 테스트를 작성할 수 있기를 원했고, 그렇게 할 수 있는 파운드리와 같은 새로운 프레임워크가 등장하여 많은 인기를 얻고 있으며, 사람들이 이러한 환경을 선호한다고 생각합니다.

Move 에서 이 점을 이해하고 바로 Move 에서 테스트를 작성할 수 있는 테스트 프레임워크를 시작했습니다. Move 에서 직접 퍼즈 테스트를 작성할 수 있도록 심볼릭 파라미터와 같은 몇 가지 기능을 추가하기 위해 노력하고 있으며, 물론 특정 입력 또는 입력 세트에 대해 컨트랙트가 작동하는지 테스트하거나 확인하는 것 이상으로 나아갈 수 있는 Move 프로버가 있습니다. 하지만 증명자를 사용하면 모든 가능한 입력, 모든 가능한 트랜잭션, 모든 가능한 프로그래밍에 대해 작동하는지 테스트할 수 있습니다. 따라서 테스트를 작성할 때보다 개발자와 테스트 노력을 훨씬 더 많이 활용할 수 있습니다.

물론 이것이 테스트의 필요성을 대체하는 것은 아니며 둘 다 있어야하지만 특히 적대적인 행동이나 예상하지 못한 것에 대해 걱정하는 경우 테스트로 확인하기가 매우 어려운 것들을 확인할 수 있습니다. 그래서 저는 Move 테스트의 미래는 멋진 단위 테스트 프레임워크를 성장시키는 것이라고 생각합니다. 이미 우리가 테스트하는 것과 같은 멋진 새로운 것을 지원해야하지만 공식적인 검증 도구의 증명자는 끝없는 연구 문제이며 중단 문제를 해결하려고 노력하고 있으며 구체적으로 할 수는 없지만 점근적으로 완벽에 접근 할 수는 있지만 매우 좋은 위치에 있습니다. 하지만 더 빠르게 실행하는 대신 더 풍부한 프로퍼티 세트를 지정할 수 있도록 하는 것이 더 나은 방향으로 나아갈 수 있는 방법이라고 생각합니다. 이런 부분은 앞으로도 계속 연구할 부분이고, 앞으로도 기대되는 부분입니다.

질문 #10: Move Prover는 Sui 에서 Move 과 어떻게 작동하나요? 그리고 변경 사항이 있나요?

Sam:

예, 작동하며, 모든 스마트 컨트랙트 작성자가 기본적으로 작성해야 하는 Sui 표준 라이브러리와 같은 표준 모듈 집합인 Sui 프레임워크의 빌드 프로세스에 통합하기 위해 작업 중입니다. Sui 에서 Move 와의 주요 차이점은 공급자가 하고 있는 많은 멋진 일들이 핵심 Move 의 스토리지 모델과 관련이 있다는 것입니다. Sui 에서는 이러한 모든 기능과 관련 복잡성을 제거하여 Sui 에 이러한 사실을 작성할 필요가 없습니다.

Sui 에서 데이터 불변성과 같은 것을 작성할 수 있고, 카운터가 있고, 이 카운터의 값이 항상 증가한다는 사양을 작성할 수 있으며, 함수가 있고, 증명자가 검사하는 사전 및 사후 조건을 작성할 수 있습니다. 부모 자식 객체의 이 기능과 같이 흥미로운 Sui 특정 증명 확장을 살펴볼 수 있습니다. 예를 들어 이 객체는 항상 이 부모의 자식이다, 이 부모는 자식이 세 명이다 등 객체 간의 부모 자식 관계에 대해 개선할 점이나 사양을 말할 수 있을 것입니다. 아직 이러한 기능을 추가하거나 승인 확장을 요구하지는 않았지만, 프로그래머가 작성해야 하는 Move 사양의 종류에 따라 결정될 것이며, 이를 위해 적절한 표현 사양 언어와 이러한 속성을 확인하기 위한 증명자 및 백엔드 지원을 모두 갖추도록 할 것입니다.

이 부분은 앞으로 검증 도구에 대해 더 많은 노력을 기울여야 할 부분입니다. Move 증명 도구는 다소 쉽게 사용할 수 있지만, 고급 사용법은 좀 더 연구하고 직접 사용해보아야 합니다.

질문 #11: Move 의 실질적인 차별화 요소는 무엇인가요?

Sam:

스마트 컨트랙트 개발을 위해 Move 대신 Rust를 사용하는 이유는 무엇인가요? 이 질문은 제가 자주 받는 질문이며, 이 질문에 대한 제 대답은 러스트는 스마트 컨트랙트 언어가 아니라는 것입니다. 스마트 컨트랙트 언어의 경우, 실제로 온체인에 게시된 무언가가 있고, 이것이 검증자가 실행하는 것이며, EVM의 경우, 이것이 EVM 바이트코드라는 점을 인식해야 합니다. 그리고 저희의 경우 코드상으로는 Move 이지만, 러스트는 코드상으로는 Move 에 해당하는 것이 없고, 소스 언어이기 때문에 실제로 실행하려면 컴파일러를 실행하고 LLVM을 거쳐서 머신 코드나 와섬 또는 다른 것을 가져와야 하므로 아까 말씀드린 것처럼 인 덤을 사용할 수 없습니다, 스마트 컨트랙트 언어에 대한 이러한 테이블 스테이크 속성을 사용하려면 Rust에는 없는 스마트 컨트랙트 언어, Rust에는 계정이 없거나 Rust에는 코인이 없거나 영구 저장소를 위한 내장 모델이 없는 등 여러 가지가 필요합니다. 따라서 솔라나처럼 스마트 컨트랙트 개발에 Rust를 사용하려는 경우, 실제로는 스마트 컨트랙트 언어로 Rust를 사용하는 것이지만, Rust에 내장된 스마트 컨트랙트 언어용 SDK나 API가 있을 수도 있고, 파이썬이나 자바 또는 다른 언어로 된 API일 수도 있습니다.

때때로 비결정론적 반복이 있는 해시 맵과 같은 Rust 기능을 스마트 컨트랙트 언어에서 사용할 수 없는 경우, 앞서 말씀드린 범용 언어를 스마트 컨트랙트 언어로 사용할 수 있으면 좋을 것 같다는 생각이 들었습니다. 저희는 실제로 Move 을 만들기 전에 Rust를 사용하는 것을 검토했고, 차이점을 비교하고 Rust에는 없는 스마트 컨트랙트 언어가 되기 위해 어떤 속성이 필요한지 평가했습니다.

그래서 저희는 Rust를 좋아하고 Sui 의 모든 부분이 Rust로 작성되었으며 Move 의 많은 부분이 Rust의 영향을 받았습니다. 기본적으로 사람들이 러스트 개발과 경험에 대해 정말 좋아하는 것들을 가져와서 언어에 구문적으로나 의미적으로 모두 표현하려고 노력했습니다. 또한 러스트는 효율적인 컴파일러와 운영체제를 작성할 수 있는 로우레벨 시스템 언어여야 하기 때문에 복잡한 작업을 수행하는 부분을 매우 적극적으로 단순화하려고 노력했습니다. Move 는 스마트 컨트랙트용으로, Move 은 스마트 컨트랙트용으로 사용할 수 있습니다.

따라서 기본적으로 Ross의 좋은 부분을 취하되, 가능한 모든 방식으로 Move 을 훨씬 더 접근하기 쉽게 만들기 위해 공격적으로 단순화하려고 노력합니다.

질문 #12: 체인의 규모가 기하급수적으로 커지면 확장성, 특히 처리량과 검증 시간 측면에서 확장성에 대해 어떻게 생각하시나요?

Sam:

앞서 이에 대해 조금 이야기했지만, 이에 대해 더 자세히 설명한 다음 확인 시간에 대해 이야기하겠습니다. 이 역시 매우 적절한 질문입니다.

처리량의 경우, 트랜잭션이 작동하는 방식에 대해 조금 더 자세히 설명하겠습니다. Sui 트랜잭션은 작동할 개체를 선언한 다음 런타임에 필요한 것은 실제로 트랜잭션이 아니라 해당 개체의 값이며, 해당 개체를 읽고, 쓰고, 업데이트하는 Move 코드를 실행한 다음 데이터베이스에 다시 적용해야 하는 몇 가지 효과를 생성합니다. 따라서 더 많은 처리량이 필요한 경우, 데이터베이스가 단일 머신 이상으로 커지거나 실행기가 단일 머신 이상으로 커지면 해당 머신에 객체를 분할한 다음 새 트랜잭션이 들어올 때 "좋아, 이 트랜잭션은 Sam이 보낸 거야, AMS 오브젝트가 있는 샤드로 가서 거기서 트랜잭션을 실행하면 쉽게 실행할 수 있고, 그 다음에는 젠의 트랜잭션이 들어와서 젠의 오브젝트가 있는 샤드로 보내면 크로스 샤드 읽기가 필요 없이 거기서 완전히 실행될 수 있고, 그 다음에는 계속해서 더 많은 머신을 계획에 추가하면 처리량을 계속 늘릴 수 있다는 것이 적어도 그 아이디어의 핵심입니다.

그리고 검증자가 더 많은 컴퓨터를 추가하고 더 많은 처리량을 얻을 수 있는 것은 좋지만, 검증자의 작업을 확인하려는 최종 사용자로서 이제 마이크로 클러스터를 실행해야 한다면 탈중앙화에는 좋지 않을 것이며, 처리량이 많은 체인을 구축하는 많은 사람들이 생각하지 못하는 문제가 있습니다. 사실 검증인의 경우 기본적으로 더 많은 컴퓨팅 파워를 추가하지 않고는 처리량을 늘릴 수 없지만, 탈중앙화를 위해서는 검증인이 악의적인 행동을 하지 않는지 확인하기 위해 체인에서 일어나는 일을 효율적으로 확인할 수 있는 대규모의 생태계가 필요합니다.

Sui 따라서 이 문제를 해결하는 방법은 Sui 트랜잭션 모델을 활용하는 희소 노드라는 개념이 있으며 희소 노드를 사용하면 특정 주소 또는 개체 집합이 있다고 가정하면 인과 경로라고 부르는데, 이는 내가 추적하려는 것들이 될 수 있으며 모든 거래를 추적하고 이러한 개체와 관련된 상태의 모든 거래를 추적하고 다시 실행하고 유효성을 검사 할 것입니다. 따라서 이러한 주소는 있지만 나머지 상태는 추적하지 않으며, 예를 들어 모든 지갑은 해당 지갑이 소유한 객체와 지갑이 관심을 갖는 다른 모든 것을 추적하는 스파스 노드이거나 게임 서버를 운영하는 게임 개발자라면 모든 플레이어와 게임의 상태를 추적하는 스파스 노드가 있을 수 있으며, 게임 상태는 객체이지만 다른 게임의 상태나 공격 상태 또는 자신과 관련이 없는 다른 것들은 추적하지 않을 수 있습니다. 따라서 모든 사용 사례와 관련된 상태의 트랜잭션을 모두 검증하는 비용을 지불하지 않고도 모든 트랜잭션의 유효성을 검사할 수 있으며, 시스템에서 발생할 수 있는 수천만 건의 트랜잭션을 모두 검증하는 비용을 지불하지 않고도 유효성 검사를 확장하는 정말 좋은 방법입니다. 기본적으로 유효성 검사 비용은 관심 있는 상태의 양에 비례하며, 대부분의 최종 사용자에게는 그 양이 적고 게임처럼 기본적으로 게임의 규모에 따라 달라지는 사용 사례의 경우 해당 비용을 지불하는 것이 적절하기 때문입니다.

불 노드와 네트워크는 TPS가 정말, 정말 낮기 때문에 확장성이 매우 중요합니다. 따라서 처리량이 많은 체인을 운영하는 사람이라면 검증을 확장할 수 있는 이 문제에 대한 좋은 해답이 있어야 하며, 그렇지 않으면 원치 않는 처리량 증가로 인해 탈중앙화에 많은 어려움을 겪게 될 것입니다.

질문 #13: 개인적으로 솔리디티를 통해 달성할 수 없거나 달성해서는 안 될 것을 Sui 에서 구축한 것에 대해 어떤 점이 기대되나요?

Sam:

저는 표준이 없는 차세대 대체 불가능한 토큰에 대해 매우 기대하고 있으며, 제가 의미하는 바는 ERC 721이나 1155와 같은 표준이 있을 때 모든 대체 불가능한 토큰이 이러한 규칙을 충족해야 하는 최저 공통분모에 부합한다고 생각한다는 것입니다. 예를 들어, 어떤 메타데이터를 변경할 수 있는 NFT가 있다고 가정할 때, 커뮤니티가 함께 모여 합의한 또 다른 표준이 있어야 하고, 그 표준이 원하는 최소 공통분모에 부합하는 방식으로만 변경할 수 있습니다. Sui, 한 가지 생각할 수 있는 방법은 모든 객체가 NFT이고, 모든 객체는 고유 ID를 가지고 있다는 것입니다, 721의 핵심 기능 중 하나이며 모든 객체에는 설명한대로 전송 기능이 내장되어 있으며 그 이상의 작업을 수행하려는 경우 NFT에 새 필드를 추가하고 업데이트 로직이 있도록 설정할 수 있으며 NFT와 다른 NFT를 래핑하고 부모 하위 객체 작업을 수행 할 수 있으며 디지털 객체로 수행 할 수있는 작업 측면에서 수갑을 벗고이를 훨씬 더 안전하고 빠르게 수행 할 수 있습니다.

크리에이터들이 이러한 제한적인 표준을 따르려는 족쇄에서 벗어나 모두가 공통적으로 하고 싶어 하는 제한적인 일들을 시도하게 되면, 이를 통해 무엇을 할 수 있을지 매우 기대가 됩니다. 그리고 NFT와 디지털 자산의 관점에서 제작하고 싶은 것에 초점을 맞출 수 있을 것입니다.

특히 Sui 의 저렴한 비용과 확장 기능, Move 에서 제공하는 훌륭한 개발자 경험과 결합하면 매우 흥미로울 것이라고 생각합니다.

Jen:

Sui의 라인이 기본적으로 경계 없이 구축되는 데에는 그만한 이유가 있습니다. 곧 출시할 플랫폼에서 사람들이 무엇을 만들고 그 과정을 지켜보는 것이 정말 기대됩니다. 시간이 촉박하다는 것을 잘 알고 있습니다. 시간을 내주셔서 Move 프로그래밍 언어에 대해 안내해 주신 Sam에게 감사드립니다.

다음 주에는 아직 주제를 확정 중이지만 Move-관련 내용은 없을 것입니다. 그 다음 주에 포럼에서 이와 관련된 주제를 다룰 예정이니 참고하세요.

추가 질문이 있으시면 트위터 계정뿐만 아니라 이벤트 채팅을 통해 계속 공유해 주시기 바랍니다. 다음 AMA 시리즈에서 이 질문을 다시 다룰 수 있도록 하겠습니다. 마지막으로 남기고 싶은 말이 있나요, 샘?

Sam:

저에게는 해당되지 않습니다. 훌륭한 질문을 보내주신 커뮤니티 여러분께 감사드립니다. 정말 즐거운 시간이었습니다.

Jen:

곧 다른 시리즈가 이어집니다. 여러분, 감사합니다. 아침, 오후, 저녁 어디에서든 멋진 하루 되세요.

. . .