그 이상을 구축하세요: 강력한 Sui Move

저희는 최근 미스텐 랩스의 최고기술책임자이자 Move 프로그래밍 언어의 창시자인 샘 블랙셔와 함께 새로운 스마트 컨트랙트 프로그래밍 언어를 개발한 이유, Sui 확장을 가능하게 하는 기능, 탈중앙화 기술이 빌더에게 주는 혜택에 대해 이야기를 나누었습니다.

먼저 프로그래밍 언어가 무엇인지, 개발자가 프로그래밍 언어를 선택할 때 가장 중요하게 생각하는 자질은 무엇인지, 그리고 직접 프로그래밍 언어를 개발하게 된 계기는 무엇인지에 대해 간략하게 설명해 주시겠어요?

프로그래밍 언어는 인간에게 친숙하고 안전하면서도 효율적이고 모호하지 않은 방식으로 컴퓨터와 인터페이스하기 위한 도구일 뿐이며, 컴퓨터에게는 이 부분이 특히 중요합니다. 자연어로 컴퓨터와 대화할 수 없는 이유는 자연어의 핵심이 풍부하고 표현력이 풍부하다는 점이기 때문입니다. 말투나 단어 선택에 따라 문장이나 문단이 완전히 달라지는 것처럼 말입니다. 반면 프로그래밍 언어에서 가장 중요한 것은 의미를 정확하게 정의하는 것입니다. 그리고 프로그램을 작성할 때 그 프로그램이 무엇을 할 것인지 정확히 알 수 있습니다. 조금만 수정해도 그 델타가 어떻게 될지 알 수 있습니다. 또한 소스 언어로 코드를 작성하면 의미가 있는 중간 표현으로 변환되고, 이 중간 표현은 기계의 실리콘에 이르기까지 동일한 의미를 갖는 것이 더 좋다는 것과 같이 여러 수준에서 보존됩니다.

프로그래밍 언어는 자연어와 달리 본질적으로 도메인별 또는 작업별이라고 생각합니다. 그렇지 않다면 프로그래밍 언어가 하나만 있으면 모든 것을 할 수 있을 것입니다. 하지만 프로그래밍 언어가 여러 개 존재하는 이유는 모든 것을 잘할 수 없기 때문입니다. 그리고 그들은 특정 문제 영역을 타겟팅하고 거기에 집중하려고 노력합니다. 예를 들어, Sui 블록체인을 작성하고 미스텐에서 수행하는 대부분의 다른 시스템 작업을 수행하는 데 사용한 프로그래밍 언어인 Rust를 살펴보면, 이 언어는 매우 빠르고 성능이 뛰어나면서도 안전한 코드를 작성하는 데 초점을 맞추고 있습니다. 메모리, 스레드 구조 또는 동시성과 같은 낮은 수준의 측면을 다룰 수 있지만, C나 C++와 같은 이전 언어가 그랬던 것처럼 발에 총을 쏘지 않아도 됩니다.

의 이야기는 Move 의 이야기도 이와 비슷합니다. 제가 이 언어를 만들었을 때는 새로운 언어를 만드는 것이 목표가 아니었습니다. 질문하신 다른 질문 중 하나는 개발자가 언어에서 무엇을 찾는지입니다. 개발자들은 "내가 원하는 작업에 적합한가?"라고 묻습니다. 하지만 그보다 더 중요한 것은 "이 언어에 큰 커뮤니티가 있는가? 사용 가능한 라이브러리가 많은가? 이 언어를 사용하는 프로그래머가 많은가? 좋은 교육 자료가 있는가?" 이 부분이 매우 중요하기 때문에 새로운 언어를 만드는 기준은 매우 높아야 합니다. 언어 자체가 훨씬 더 뛰어나더라도 다른 요소가 없으면 더 뛰어나도 소용이 없습니다. 그리고 제로에서 정말 크고 활기찬 커뮤니티를 만드는 것은 매우 어렵습니다.

Move 의 개발에 대해 자세히 알려주실 수 있나요?

Move 의 기원은 페이스북의 리브라 프로젝트에서 시작되었습니다. 제가 받은 임무는 새로운 언어를 만들라는 것이 아니라 "리브라에는 스마트 컨트랙트가 필요하니 어떻게 해야 할지 알아내라"는 것이었습니다. 그래서 여러 가지를 살펴봤죠. EVM에 솔리디티를 사용할 수 있을까요? WASM이나 JVM과 같은 기존의 범용 언어를 리브라에 사용해야 할까요? 아니면 우리만의 것을 만들어야 할까요? 저희만의 것을 만들기로 결정한 것은 기존 스마트 컨트랙트를 연구하고 프로그래머들이 무엇을 하려고 하는지, 그리고 그 언어가 어떤 부분에서 도움이 되고 어떤 부분에서 방해가 되는지 이해한 결과였습니다. 제가 내린 결론은, 많은 경우 프로그래밍 언어가 프로그래머들을 실망시키고 있다는 것이었습니다.

이는 솔리디티의 보안 실적이 좋지 않았기 때문이기도 하지만, 더 근본적인 이유는 이러한 스마트 콘트랙트가 매우 색다른 종류의 프로그램이기 때문일 수 있습니다. 그리고 솔리디티는 오늘날 사람들이 하는 일을 하기 위해 만들어진 언어가 아니었습니다. 솔리디티는 최초의 스마트 컨트랙트 언어였고 사람들이 무엇을 하고 싶어하는지 몰랐기 때문에 비판적인 의미는 아닙니다. 사람들이 솔리디티로 무엇을 하려고 하는지 보면, 솔리디티 언어가 제공하는 것과는 다른 추상화와 프로그래밍 도구를 원한다는 것이 분명해집니다.

스마트 콘트랙트는 매우 간단합니다. 스마트 컨트랙트는 기본적으로 두 가지 일을 합니다. 자산을 언제 전송할 수 있는지, 자산으로 무엇을 할 수 있는지, 누가 자산을 읽을 수 있는지, 누가 자산을 쓸 수 있는지에 대한 규칙을 포함하여 자산의 형태를 정의합니다. 그리고 누가 이 자산을 가지고 있는지, 누가 이 자산을 사용할 수 있는지, 누가 이 자산으로 무엇을 할 수 있는지에 대한 액세스 제어 정책을 확인합니다. 모든 것은 자산에 관한 것이며, 이러한 자산이 물리적 자산과 동일한 속성을 갖기를 원합니다. 내가 당신에게 무언가를 건네주면 당신은 그것을 가져야 하고 나는 그것을 더 이상 가져서는 안 됩니다.

소유권 및 소유권 이전이라는 개념이 있지만 컴퓨터에서는 모든 것이 비트와 바이트에 불과하며 자유롭게 복사할 수 있습니다. 그리고 아시다시피 이러한 개념은 존재하지 않습니다. 따라서 소유권과 대체 가능성에 대한 멋진 추상화를 제공하는 언어가 필요합니다. 물리적 세계에서와 마찬가지로 프로그래머가 재창조할 필요 없이 말이죠. 여러분은 이러한 기본적인 안전 보장을 원합니다.

이것이 바로 Move 의 목적이자 새로운 언어를 만들게 된 이유입니다. 스마트 컨트랙트 프로그래밍의 기본이 되는 작업들이 있습니다. 이러한 작업은 기존 스마트 컨트랙트 언어를 포함한 다른 언어로 재현하기 어렵기 때문에, 저희는 프로그래머가 코드를 작성할 때마다 매번 같은 작업을 반복하지 않고 안전하고 효율적으로 코드를 작성할 수 있도록 이러한 기본 요소를 제공하는 것을 중심으로 전체 언어를 설계하고자 했습니다.

Sui 는 Move 의 변형을 사용합니다. Sui Move. 이러한 변경의 원인은 무엇일까요? 그리고 Sui Move 의 어떤 특성이 웹3에서 제품을 구축하는 데 고유하게 적합할까요?

이러한 변화에 동기를 부여한 몇 가지 요인이 있었습니다. 하나는 원래 리브라 프로젝트의 목표가 규정을 준수하는 결제 네트워크를 구축하는 것이었기 때문입니다. 그래서 저희는 Move 을 범용 언어로 설계하려고 했습니다. 하지만 리브라가 갖고자 했던 제약 때문에 의도적으로 특정 작업을 수행하기도 했습니다. 한 가지 중요한 점은 사람들이 자산을 가져가서 아무데나 보내는 것을 원하지 않는다는 것이었습니다. 그들은 사람들이 명시적으로 계정을 만들고 계정 소유자가 KYC를 해야 하는 등 계정 생성과 관련된 몇 가지 규칙을 갖기를 원했습니다. 또는 계정 생성에 수수료를 부과하거나 계정 생성 권한이 있는 소수의 사람들만 계정을 만들 수 있도록 하는 등의 규칙을 만들었습니다. 이러한 제한이 있는 이유는 리브라가 이러한 규정을 준수하는 결제와 규정을 준수하는 스마트 컨트랙트를 하고자 했기 때문입니다. 하지만 보다 일반적인 웹3.0 분야에서는 정반대입니다. 스마트 컨트랙트의 개념인 기본 레이어에서 규정을 준수하는 것은 원치 않습니다. 가능한 한 자유롭게 무언가를 가져가서 원하는 주소로 보낼 수 있어야 합니다. 그리고 차단될 수 있는 모든 종류의 사용 사례가 있기 때문에 명시적인 계정 생성을 할 필요가 없어야 합니다. 이것이 가장 중요한 요소 중 하나였습니다.

또 다른 요인은 Move 에서 자산에 초점을 맞추고 있긴 했지만, 당시 리브라에서는 자산에 초점을 맞추는 방법을 트랜잭션 자체에 적용하는 것에 대해 생각하지 않았다는 점입니다. 따라서 Move 에서 코드를 작성하는 것은 좋았지만, 트랜잭션 레벨에 도달하면 여전히 자산이 아닌 숫자와 부울 등을 입력하는 API가 있고, Move 에서 해당 숫자를 사용하여 계정에서 자산을 가져오고 이런 모든 작업을 수행하는 것이었습니다. 그런데 실행 중인 코드 중 상당수가 이걸 꺼내고, 저걸 꺼내고, 다른 걸 꺼내고, 원하는 에셋은 다 가져왔다는 식의 지저분한 장부 관리라는 것을 알게 되었습니다. 이제 제 스튜디오에 다 모였으니 의미 있는 작업을 시작할 수 있습니다. 그런 다음 마지막에는 자산을 가져와서 이 계정에 다시 넣고, 저 계정에 다시 넣고, 재구성합니다.

Sui 에서 저희는 모든 프로그램이 이런 식으로 시작하고 이런 식으로 끝난다면 이를 추상화할 수 없을까에 대해 많은 고민을 했습니다. 그래서 트랜잭션을 처리하는 로직은 프로그래머를 위해 그렇게 할 것이고, 프로그래머의 입장에서는 흥미로운 작업을 바로 수행할 수 있도록 필요한 에셋만 준비되어 있으면 됩니다. 이것이 바로 Sui 에 존재하는 객체 중심 데이터 모델로 이어진 이유입니다. 원래 Move 에서는 자산이 계정 아래에 있고 프로그래머가 명시적으로 자산을 가져와야 하는 계정 기반 데이터 모델이 있었습니다. 그리고 Sui 에서는 Sui 런타임에서 이미 가져온 자산이 트랜잭션의 Move 부분으로 들어옵니다. 프로그래머 입장에서는 부기 전후에 이 모든 작업을 수행할 필요가 없기 때문에 더 편리할 뿐만 아니라, 트랜잭션을 실제로 실행하지 않고도 다른 트랜잭션과 병렬로 실행할 수 있는지 확인하고 Sui 을 수평적으로 확장하며 기타 여러 가지 작업을 더 효율적으로 수행할 수 있는 비결이기도 합니다.

저희는 객체 기반 데이터 모델을 활용하는 프로그래밍 가능한 트랜잭션 블록과 같이 매우 흥미로운 몇 가지 다른 작업도 해왔습니다. 이는 조금 더 기술적인 주제이지만, 기꺼이 다뤄보고 싶습니다. 하지만 이 두 가지가 원래의 Move 에서 벗어나게 된 주요 동기였습니다.

프로그래밍 가능한 트랜잭션 블록과 그 작동 방식에 대해 더 자세히 공유해 주시면 감사하겠습니다.

다른 블록체인은 쇼핑몰의 푸드코트와 같다고 비유하고 싶습니다. 아이스크림이 먹고 싶으면 아이스크림 가판대에 가서 신용카드를 꺼내서 결제합니다. 하지만 실제로 햄버거도 먹고 싶다고 결정하면 햄버거 가판대에 가서 거기서도 결제합니다. 저는 대식가는 아니지만 여덟 가지를 먹고 싶으면 여덟 번을 따로 결제해야 합니다. 반면 Sui 은 뷔페에 가깝습니다. 모든 거래가 한 가지로 끝나지 않습니다. 뷔페를 이용하기 위해 비용을 지불하면 추가 비용 없이 많은 것을 할 수 있습니다. 아이스크림도 살 수 있고, 햄버거도 살 수 있고, 함께 스매싱할 수도 있습니다.

이를 조금 덜 추상적으로 설명하자면, 100개의 트랜잭션을 전송하여 100개의 대체 불가능한 토큰을 발행하는 간단한 경우, 100개의 대체 불가능한 토큰을 발행하는 트랜잭션 하나를 전송할 수 있습니다. 이는 하나의 대체 불가능한 토큰을 발행하는 것과 거의 동일한 비용입니다. 또한 블록의 첫 번째 트랜잭션이 멀티서명 지갑에서 마리오 캐릭터를 가져오고, 블록의 두 번째 트랜잭션이 마리오를 요청하면 게임을 할 수 있도록 하는 등 이질적인 트랜잭션 번들링을 할 수도 있습니다. 그리고 게임에서 승리하여 트로피를 받으면 세 번째 트랜잭션에서 트로피를 가져와 트로피 케이스에 넣어 친구들과 공유할 수도 있습니다. 프로그래밍 가능한 트랜잭션 블록을 사용하면 프로그래머가 멀티서명 지갑이나 마리오가 어떻게 저장되는지 알 필요가 없는 방식으로 코드를 작성할 수 있다는 점이 멋진 점입니다. 또한 트로피 케이스나 트로피가 어떻게 구현되는지 알 필요도 없습니다.

프로그래밍 가능한 트랜잭션 블록은 이러한 트랜잭션으로 구성되며, 각 트랜잭션에는 입력 및 출력 객체가 있습니다. 입력 객체를 기대하는 무언가가 있다면, 그 객체가 어디에서 왔는지 신경 쓰지 않고 그 객체를 가져올 수 있고, 그 객체가 어디에서 왔는지 신경 쓰지 않고 그 객체를 기대하는 무언가로 출력을 파이프할 수도 있습니다. 다른 블록체인에서는 훨씬 더 많은 커플링이 필요하기 때문에 게임이 멀티시그 지갑과 트로피 케이스와 통합되거나 둘 다 공통 인터페이스를 구현하고 더 많은 커플링을 가져야 합니다. Sui 에서는 애드혹 구성이라고 부르는 작업을 훨씬 더 쉽게 할 수 있습니다. 파이프가 일치하면 한 번의 트랜잭션으로 처리할 수 있는 것과 같습니다.

프로그래밍 가능한 트랜잭션 블록은 사용자에게 어떤 이점이 있을까요?

사용자 입장에서는 별도의 거래를 하는 대신 한 번의 거래로 모든 것을 처리할 수 있기 때문에 가스 요금이 저렴하다는 이점이 있습니다. 또한 승인 횟수도 줄어듭니다. 거래 승인이 필요한 시스템을 사용하는 경우 세 번 승인하는 대신 한 번만 승인하면 모든 것이 한 번에 처리됩니다. 다른 하나는 원자성이라고 할 수 있는데, 세 가지 다른 작업을 수행하려고 할 때 첫 번째와 두 번째 작업이 성공해야만 세 번째 작업도 성공하도록 하려는 경우, 이러한 작업이 별도의 트랜잭션이어야 한다면 그렇게 할 수 없습니다. 하지만 이 모든 것을 하나로 통합할 수 있다면 문제없이 수행할 수 있습니다.

Sui 에서 개발하는 것이 프로그래머에게 얼마나 중요한 경험인지 여러분과 다른 사람들이 이야기하는 것을 들었습니다. Sui Move 에서 작업을 시작한 경력자와 신입 웹3 프로그래머 모두에게 공유할 수 있는 일화가 있으신가요?

다른 웹3 프로그래밍 언어를 사용하는 사람들은 Move 와 Sui Move 에서 훨씬 더 생산적이라고 느낄 것입니다. 그리고 훨씬 더 안전합니다. 얼마 전 버킷 프로토콜의 사람들과 팟캐스트에 출연했는데, 그들은 Sui 에서 매우 멋진 디파이 프로젝트를 구축하고 있습니다. 그리고 그들은 시스템 아키텍처를 살펴보면서 서로 어떻게 작동하는지에 대한 다양한 상자를 보여주었습니다. 솔리디티로 작성했다면 8개월이 걸렸겠지만 Sui Move 을 사용하면 2개월 만에 완료할 수 있으며, 안전성에 대해 매우 확신하고 있다고 합니다. 언어가 작동하는 방식이 프로젝트가 어떻게 진행되어야 하는지에 대해 머릿속에 있는 아이디어와 매우 밀접하게 매핑되기 때문입니다. 반면에 솔리디티 공간에서는 훨씬 더 간접적입니다.

한 가지 예이긴 하지만, 사람들이 이 언어를 사용하면 훨씬 더 빨라지고 결과물에 대해 훨씬 더 자신감이 생긴다는 이야기를 많이 들었습니다. 정말 기쁜 소식이죠. 하지만 어떤 면에서는 놀라운 일도 아닙니다. 저희는 솔리디티를 살펴보고 문제점이 무엇인지 살펴봤습니다. 그리고 어떻게 하면 더 안전하게 만들 수 있을까? 어떻게 하면 더 빠르게 만들 수 있을까요? 이 언어를 사용하는 사람들이 무엇을 하려고 하는지 살펴보고 그들이 가진 것이 아니라 그들이 원하는 것을 어떻게 디자인할 수 있을까요? 이 모든 것은 우리가 그 목표를 달성하는 것입니다. 이 언어는 사람들이 겪는 문제를 해결하기 위해 설계되었기 때문에 사람들이 이 언어를 사용하면 정말 고마워할 것이라고 생각합니다.

선점자 우위라는 말이 있지만, 이 경우에는 후발주자 우위라고 할 수 있습니다.

맞습니다. 맞아요.

Sui Move 과 Sui 의 객체 중심적 특성에 대해 언급하셨을 때 이에 대해 언급하신 적이 있습니다. 하지만 Sui Move 의 설계와 Sui 가 특히 짧은 지연 시간, 저렴한 비용, 확장성 등 웹3의 대량 채택에 대한 약속을 이행할 수 있는 능력 사이의 연관성을 좀 더 명확하게 설명해 주시겠습니까?

Sui 에 기여하면서 우리가 매우 경계하는 것은, 다른 플랫폼이 겪고 있는 문제라고 생각하는데, 이더리움처럼 15 TPS(초당 트랜잭션 수)이든 100이든 1,000이든 용량이 제한되어 있으면 플랫폼이 너무 성공하면 용량이 최대치에 도달하는 시점에 이르게 됩니다. 그 시점이 되면 플랫폼을 사용하는 모든 사람의 경험이 저하됩니다. 슬롯이 1,000개밖에 없다면 가장 중요한 1,000개를 골라야 하므로 가스 경매 등을 통해 이를 해결해야 합니다. 모든 사람의 가격이 올라가거나 모든 사람의 지연 시간이 증가하거나 둘 다 증가합니다. 가장 많은 비용을 지불할 수 있는 사용 사례가 승리하고 다른 사람들은 다른 곳으로 가거나 더 오래 기다려야 하기 때문에 많은 사용 사례가 잠기게 됩니다. 좋지 않죠.

Sui 에서 목표로 하는 것은 수평적 확장성입니다. 일정량의 하드웨어가 할당되면 일정량의 처리량을 달성할 수 있습니다. 더 많은 처리량을 원한다면 검증자는 더 많은 하드웨어를 도입할 수 있습니다. 여기에는 상한선이 없습니다. 이것이 모든 웹2.0 서비스가 작동하는 방식입니다. 물론 공학적 제약을 고려해야 하므로 확실하거나 쉬운 일은 아니지만, 확장 가능한 웹 서비스를 설계할 때 누구나 수평적 확장성을 원합니다.

Sui 에 더 많은 고객이나 사용자가 유입되면 Sui 이 계속 성장하고 모든 것이 정상적으로 작동하는 것이 목표입니다. 물론 지연 시간도 매우 짧게 유지해야 합니다. 처리량은 늘어나는데 지연 시간을 희생해야 하는 상황은 원치 않을 것입니다.

리브라 시스템에서는 이러한 특성을 염두에 두지 않았습니다. 수백 명의 결제 운영자가 하루에 수천 또는 수백만 건의 결제를 처리하는 소규모 결제 시스템이었지만 그 이상은 아니었습니다. 그래서 우리는 더 간단하고 충분할 것 같아서 단일 박스 아키텍처를 사용했습니다. Sui 에서는 리브라 시스템이 수평적 확장성이라는 속성이 없기 때문에 작동하지 않을 것이라는 것을 알고 있었습니다. 그래서 어떻게 하면 수평 확장성을 구현할 수 있는 디자인으로 처음부터 시작할 수 있을까 고민했습니다. 그래서 객체 중심 데이터 모델이 탄생했습니다. 기존의 계정 기반 데이터 모델은 수평적 확장성을 달성하기가 매우 어려웠기 때문에 창밖으로 던져 버렸습니다. 반면, 객체를 중심으로 모든 것을 구성하면 글로벌 상태는 객체 ID에서 객체까지 하나의 큰 맵에 불과합니다. 이것이 바로 키 값 저장소이며, 우리는 키 값 저장소를 확장하는 방법을 알고 있습니다. 이는 쉬운 엔지니어링 문제입니다.

그렇다면 키 값 저장소에서 데이터를 가져와서 업데이트하는 데 적합한 트랜잭션 구조를 어떻게 만들 수 있을까요? 키 값 저장소를 어떻게 샤딩할 수 있을까요? 트랜잭션이 처리될 위치를 어떻게 결정할 수 있을까요? 그래서 기본적으로 거기서 출발했습니다. 이것은 우리가 확장하는 방법을 알고 있는 것과 같습니다. 이를 어떻게 블록체인의 속성, 인증된 읽기, Move 와 함께 작동하는 등의 모든 종류의 속성을 가진 것으로 바꿀 수 있을까요? 그리고 어떻게 하면 가능한 한 원활하게 결합할 수 있을까요?

더 높은 수준에서, 회의적인 웹2.0 개발자들에게 탈중앙화 기술의 가능성에 대해 어떻게 이야기할 수 있을까요?

저는 블록체인과 암호화폐를 근본적으로 마찰을 제거하는 기술이라고 생각합니다. 금융 거래를 하거나 애플리케이션을 구축하거나 정보를 설정하는 방식에는 장벽이 존재하기 때문에 정보가 장벽을 넘을 방법이 없거나, 장벽을 넘더라도 이를 위해 임대료를 받는 제3자의 도움이 필요하기 때문에 일을 하기가 매우 어렵습니다.

사람들이 흔히 사용하는 전형적인 예는 주택을 구매할 때 주택 구매자와 주택 판매자가 있지만, 실제로 대금을 지불할 때는 구매자와 판매자가 서로를 완전히 신뢰하지 않기 때문에 에스크로 에이전트가 앉아서 돈을 보관하는 것 외에는 아무것도 하지 않아야 한다는 점입니다. 이것이 바로 현실입니다. 그리고 그것은 우리가 처리해야 하는 문제입니다. 하지만 에스크로 에이전트가 두 사람이 모두 볼 수 있는 코드이거나 제3자가 검증한 것이라면 무료 또는 훨씬 적은 비용으로 그 일을 할 수 있습니다. 부동산에서 에스크로를 없애는 것이 블록체인의 목적은 아닙니다. 이는 하나의 사용 사례일 뿐입니다. 하지만 이것이 일반적인 원칙입니다.

앱 A와 앱 B가 상호 운용성이 없는 대신 동일한 레일, 동일한 기반 플랫폼에 구축되어 인앱 아이템, 데이터, 크로스 프로모션 또는 두 앱 모두에 구축되는 타사 등 한 앱에서 다른 앱으로 무언가가 흐르도록 할 수 있다면 어떨까요? 또는 웹을 생각해보면 사이트들은 쿠키를 통해 서로 데이터를 공유하지만 이러한 쿠키는 읽기 전용 메타데이터입니다. 이러한 쿠키가 돈이 될 수 있다면 어떨까요? 또는 이것이 소비 가능한 객체라면 어떨까요? 로열티 프로그램이나 쿠폰이라면 어떨까요? 모든 것에 이러한 기능이 내장되어 있습니다. 이것은 매우 추상적이지만 이것이 바로 잠재력입니다. 보통 건물을 짓는 사람이라면 더 매력적인 무언가를 만드는 데 사용할 수 있는 새로운 초능력이라고 생각할 것입니다.

최종 사용자 입장에서는 기술 전문가가 아니더라도 코드를 신뢰해야 한다고 생각할 때, 다른 옵션이 투명하지 않은 대규모 중앙 기관이라고 해도 망설여지나요?

그렇지 않다고 생각합니다. 우리 모두 매일 이 작업을 하잖아요? 이메일에 로그인할 때 코드가 내 이메일 중 하나를 삭제하거나 보낼 때 실제로 무언가를 보내지 않을 것이라는 걱정은 별로 하지 않습니다. 만약 그런 일이 발생한다면 이메일 사용을 중단하거나 다른 서비스 제공업체를 이용할 것입니다. 물론 여기에서도 물론 많은 사람들만이 실제로 무언가를 읽고 어떻게 작동하는지 확인할 수 있는 것은 마찬가지라고 생각합니다. 제가 이메일을 통해 이를 확인하고 싶어도 코드가 없어서 확인할 수 없었습니다. 따라서 투명성이 중요한 측면 중 하나입니다. 모든 사람이 할 수 있는 것은 아니지만 일부만 확인할 수 있다는 사실입니다. 그리고 불변성 외에도 반복적으로 사용되는 모든 것에 대해서도 마찬가지입니다. 바로 여기에 문제가 있습니다. 이메일에 로그인하면 마지막으로 어떤 작업을 수행한 이후 코드가 변경되었는지 알 수 없습니다. 이에 대한 투명성이 없습니다. 웹3에서는 해당 정보를 알 수 있지만 다른 곳에서는 얻을 수 없습니다.

시간이 지남에 따라 Sui Move 어떻게 발전할 것으로 예상하시나요?

우리가 지금 검토하고 있는 많은 기능은 Sui Move 패키지의 초기 배치를 게시한 다음 어떻게 발전시키고 싶은지, 어떤 것이 발전하기 쉽고 어떤 것이 어려운지 살펴본 경험을 바탕으로 합니다. Sui Move 는 처음 패키지를 게시할 때 매우 좋은 언어이지만, 이 유형을 변경하고, 필드를 추가하고, 기능을 추가하고, 이 작업을 수행하거나 저 작업을 수행하면서 일관성을 유지하면서도 초기 패키지를 사용하던 사용자의 신뢰를 침해하지 않는 방식으로 패키지를 만드는 것은 매우 어려운 문제가 됩니다. 저희가 하는 일의 대부분은 이러한 문제를 살펴보고 프로그래머에게 유연하게 확장할 수 있는 기능을 추가하는 동시에 원래 코드를 사용하던 사람들의 신뢰를 유지할 수 있는 언어 수준 기능을 파악하는 것입니다.

특히 열거형과 관련된 여러 기능을 검토하고 있습니다. Move 를 프런트엔드 코드에 연결하는 경험과 관련하여 다른 많은 작업을 하고 있습니다. 일반적인 Sui 앱은 5% Move 코드와 95% 프론트엔드라는 농담을 하곤 합니다. 그래서 저희는 이 95%에 많은 신경을 쓰고 있습니다. Move 에 대해 이야기하는 데 많은 시간을 할애하지만, 다른 부분의 생산성을 높이고 연결을 더 쉽게 만드는 데 많은 신경을 쓰고 있습니다. 그리고 일반적으로 어떻게 하면 앱이 Move 로 더 많이 구성되어 안전성을 높일 수 있을까요? 그리고 어떻게 하면 코드의 95%에 해당하는 부분을 Move 프로그래머와Move 프로그래머가 모두 액세스할 수 있게 만들 수 있을까요?