저자: Sui Foundation 컴파일: Cointime.com 237

우리는 최근 Mysten Labs의 CTO이자 Move 프로그래밍 언어의 창시자인 Sam Blackshear와 그가 새로운 스마트 계약 프로그래밍 언어를 개발한 이유, Sui가 어떻게 확장성을 가능하게 하는지, 그리고 개발자를 위한 탈중앙화의 이점에 대해 논의했습니다.

먼저, 프로그래밍 언어가 무엇인지, 개발자가 프로그래밍 언어를 선택할 때 가장 중요한 자질은 무엇인지, 자신의 언어를 개발하게 된 동기는 무엇인지에 대한 개요를 제공할 수 있습니까?

프로그래밍 언어는 컴퓨터와 친근하고 안전한 상호 작용을 위한 도구일 뿐이며, 컴퓨터에 효율적이고 모호하지 않은 것이 특히 중요합니다. 자연어의 전체 목적은 풍부함과 표현력이기 때문에 우리는 자연어를 사용하여 컴퓨터와 통신할 수 없습니다. 예를 들어, 억양이나 단어 선택을 조금만 바꾸면 문장이나 단락이 완전히 달라질 수 있습니다. 반면 프로그래밍 언어에서 가장 중요한 것은 의미 체계를 정확하게 정의하는 것입니다. 당신이 프로그램을 작성할 때, 당신은 그것이 무엇을 할지 압니다. 조금만 수정하면 변경 내용도 알 수 있습니다. 그리고 이 정확한 정의는 소스 언어로 코드를 작성할 수 있고 의미가 있는 것처럼 여러 수준에서 유지되며 기계 조각의 실리콘에 이르기까지 동일한 의미를 가져야 하는 중간 표현으로 변환됩니다. .

프로그래밍 언어는 본질적으로 도메인 특정 또는 작업 특정이라는 점에서 자연어와 다르다고 생각합니다. 그렇지 않으면 모든 것을 할 수 있는 단 하나의 프로그래밍 언어만 있을 것입니다. 하지만 여러 프로그래밍 언어가 존재하는 이유는 모든 것을 잘할 수는 없기 때문입니다. 그들은 실제로 특정 문제 영역을 목표로 하고 그것에 매우 집중하려고 합니다. 따라서 Sui 블록체인 및 Mysten에서 작동하는 다른 시스템을 작성하는 데 사용하는 Rust 프로그래밍 언어를 보면 매우 빠르고 성능이 뛰어나면서도 안전한 코드 작성에 중점을 둡니다. 기본 메모리, 스레딩 구조 또는 동시성에 대한 액세스를 제공하지만 이전 C 또는 C++ 언어처럼 자신을 망칠 수는 없습니다.

Move의 이야기는 매우 비슷합니다. 내가 그것을 만들 때 그것은 새로운 언어를 만드는 것이 아닙니다. 당신이 묻는 또 다른 질문은 개발자가 언어에서 무엇을 찾는가입니다. 그들은 "이게 내가 하고 싶은 작업에 적합합니까?"라고 묻지만 더 중요한 것은 "이 언어에 큰 커뮤니티가 있습니까? 사용할 수 있는 라이브러리가 많습니까? 를 사용하는 프로그래머가 많습니까? 좋은 교육 리소스가 있습니까?"입니다. ?" 이렇게 중요하기 때문에 새로운 언어를 만들기 위해서는 진입장벽이 매우 높아야 하고, 언어 자체가 더 좋아도 그런 지원 없이는 그 강점이 중요하지 않습니다. 제로에서 크고 활기찬 커뮤니티로 가는 것은 매우 어렵습니다.

Move의 개발에 대해 조금 말씀해 주시겠습니까?

Move의 기원은 Facebook의 Libra 프로젝트로 거슬러 올라갑니다. 당시 내 임무는 새로운 언어를 만드는 것이 아니라 "Libra는 스마트 계약이 가능해야 하므로 우리가 무엇을 해야 하는지 파악하는 것"이었습니다. Ethereum Virtual Machine에서 Solidity를 사용할 수 있습니까? WASM 또는 JVM과 같은 일반 링구아 프랑카를 사용하고 Libra에 사용해야 합니까? 아니면 우리만의 것을 만들어야 할까요? 내 자신의 무언가를 만들기로 한 결정은 기존 스마트 계약을 조사하고 프로그래머가 무엇을 하려고 했는지, 언어가 어디에서 도움이 되었고 어디에서 실패했는지 이해하는 것을 기반으로 했습니다. 내 결론은 많은 경우에 그것은 그들을 실망시킨다는 것이다.

이것은 Solidity의 열악한 보안 기록에서 볼 수 있지만 더 중요한 것은 이러한 스마트 계약이 매우 색다른 유형의 프로그램이라는 것입니다. Solidity는 오늘날 사람들의 요구를 충족시키기 위해 만들어진 언어가 아닙니다. 나는 그것이 최초의 스마트 계약 언어이고 사람들이 그것으로 무엇을 하고 싶어하는지 모르기 때문에 비판으로 말하는 것이 아닙니다. 사람들이 그것으로 무엇을 하려고 하는지 알게 되면, Solidity가 제공하는 언어와는 다른 추상화 및 프로그래밍 도구 세트가 필요하다는 것이 꽤 분명하다고 생각합니다.

따라서 이러한 스마트 계약은 매우 간단합니다. 그들은 주로 두 가지 일을 합니다. 첫째, 자산이 전송될 수 있는 시기, 수행할 수 있는 작업, 자산을 읽고 쓸 수 있는 사람에 대한 규칙을 포함하여 자산의 모양을 정의합니다. 둘째, 액세스 제어 정책을 검토하여 누가 자산을 소유하고 있고, 자산을 사용할 수 있으며, 자산에 대해 조치를 취할 수 있는 사람을 결정합니다. 모든 것은 자산을 중심으로 이루어지며 이러한 자산이 물리적 자산과 동일한 속성을 갖기를 원합니다. 내가 당신에게 무언가를 준다면 당신은 그것을 가져야 하는데 나는 더 이상 가질 수 없습니다.

컴퓨터에서는 모든 것이 자유롭게 복사할 수 있는 비트와 바이트에 불과합니다. 이러한 개념은 컴퓨터에 존재하지 않습니다. 따라서 소유권과 대체 가능성에 대한 멋진 추상화를 제공하는 언어를 원합니다. 실제 세계와 같지만 프로그래머가 바퀴를 재발명하도록 강요하지 않습니다. 이러한 기본 보안 보장을 원합니다.

그것이 바로 Move가 하는 일이며, 우리가 궁극적으로 새로운 언어를 만들기로 결정한 이유입니다. 이러한 기본적인 작업은 기존 스마트 계약 언어를 포함하여 다른 언어로 재현하기 어려운 스마트 계약 프로그래밍에 존재합니다. 우리는 이러한 기본 요소를 제공하도록 전체 언어를 설계하여 프로그래머가 코드를 작성할 때마다 바퀴를 다시 발명할 필요 없이 안전하고 효율적으로 코드를 작성할 수 있도록 합니다.

Sui는 Sui Move라는 Move의 변형을 사용합니다. 무엇이 이러한 변화를 일으켰습니까? Web3에서 제품을 구축하는 데 특히 적합한 Sui Move의 기능은 무엇입니까?

몇 가지 요인이 이러한 변화에 기여했습니다. 원래 Libra 프로젝트의 목표 중 하나는 규정을 준수하는 결제 네트워크를 구축하는 것이었습니다. 그래서 우리는 Move를 공용어로 디자인하려고 했습니다. 그러나 우리는 Libra가 요구하는 제약 조건을 충족시키기 위해 의식적으로 작업을 수행했습니다. 큰 문제 중 하나는 사람들이 특정 자산을 이동할 수 있기를 원하지 않는다는 것입니다. 그들은 사람들이 명시적으로 계정을 생성하기를 원하고 계정 소유자가 KYC 인증을 통과해야 하거나 계정 생성에 수수료가 있거나 소수의 사람들만 생성할 수 있는 것과 같은 계정 생성에 대한 몇 가지 규칙을 설정하기를 원합니다. 계정 생성 권한이 있는 사람. 이러한 제한은 Libra의 전체 목적이 규정을 준수하는 지불 및 규정을 준수하는 스마트 계약을 수행하는 것이기 때문에 존재합니다. 그러나 보다 일반적인 Web3 공간에서는 그 반대입니다. 후드 아래에서 규정 준수라는 개념을 갖기를 원하지 않습니다. 이것이 스마트 계약의 개념입니다. 당신은 물건이 가능한 한 무료이기를 원하고 어떤 주소로든 물건을 보내는 것이 완벽하게 가능합니다. 그런 다음 다양한 사용 사례를 방해할 수 있으므로 명시적인 계정 생성을 수행해서는 안 됩니다. 이것은 중요한 요소입니다.

또 다른 요인은 우리가 Move에서 자산에 초점을 맞추는 동안 Libra 프로젝트에서는 이 자산 초점을 트랜잭션 자체로 가져오는 방법에 대한 고려가 없었다는 것입니다. 따라서 Move에서 코드를 작성하는 것은 괜찮지만 트랜잭션 수준에 도달하면 여전히 이 API만 있고 숫자, 부울 등을 입력해야 합니다. 자산을 가져와 일련의 작업을 수행합니다. 당신이 실행하고 있는 대부분의 코드는 이것 빼기, 저거 빼기, 다른 것을 꺼내기, 음, 내가 원하는 모든 자산을 가지고 있는 것과 같은 부실한 부기입니다. 이제 저는 의미 있는 일을 시작할 수 있습니다. 그런 다음 그 자산을 이 계정에 다시 넣고 다시 그 계정에 넣고 재구성합니다.

Sui에서 우리는 질문에 대해 많이 생각했습니다. 모든 프로그램이 이런 식으로 시작하고 끝나면 추상화할 수 있을까요? 따라서 트랜잭션을 처리하는 로직은 프로그래머를 위해 처리할 것이며, 프로그래머의 관점에서 그들은 필요한 자산만 준비하면 흥미로운 작업을 바로 시작할 수 있습니다. 이것이 Sui에 존재하는 객체 중심 데이터 모델의 기초입니다. 원래 Move에는 계정 기반 데이터 모델이 있었고 자산은 계정에 저장되었으며 프로그래머는 이를 명시적으로 가져와야 했습니다. 반면 Sui에서는 Sui를 통해 실행될 때 이미 트랜잭션의 Move 부분으로 추출됩니다. 이것은 프로그래머에게 훨씬 더 친근한데 왜냐하면 그들은 이 모든 앞뒤 장부 기록을 할 필요가 없기 때문입니다. 또한 하나의 트랜잭션을 다른 트랜잭션과 병렬로 실행할 수 있는지, 실제로 트랜잭션을 실행하지 않고 Sui를 수평으로 확장할 수 있는지를 알 수 있는 방법이기도 합니다. 트랜잭션 및 기타 작업을 보다 효율적으로 수행하기 위한 팁.

우리는 또한 개체 기반 데이터 모델을 활용하는 프로그래밍 가능한 트랜잭션 블록과 같은 정말 흥미로운 몇 가지 작업을 수행했습니다. 이것은 약간 더 기술적인 주제이며 기꺼이 설명하겠습니다. 그러나 이 두 가지 요소가 원래 Move와 분기되는 주요 동인이었습니다.

원하신다면 프로그래밍 가능한 트랜잭션 블록과 해당 기능에 대한 자세한 정보를 공유할 수 있습니다.

우리는 또한 개체 기반 데이터 모델을 활용하는 프로그래밍 가능한 트랜잭션 블록과 같은 정말 흥미로운 몇 가지 작업을 수행했습니다. 이것은 약간 더 기술적인 주제이며 기꺼이 설명하겠습니다. 그러나 이 두 가지 요소가 원래 Move와 분기되는 주요 동인이었습니다.

원하신다면 프로그래밍 가능한 트랜잭션 블록과 해당 기능에 대한 자세한 정보를 공유할 수 있습니다.

여기서 사용하고 싶은 비유는 다른 블록체인이 쇼핑몰의 푸드 코트와 같다는 것입니다. 아이스크림이 먹고 싶으면 아이스크림 가판대에 가서 신용카드를 꺼내 결제합니다. 하지만 버거도 먹기로 결정했다면 버거 가판대에 가서 돈을 지불해야 합니다. 나는 대식가는 아니지만 여덟 가지를 먹고 싶다면 여덟 번의 개별 거래를 해야 한다. 반면 Sui는 무제한 뷔페에 가깝습니다. 각 거래는 단순한 항목 그 이상입니다. 뷔페 비용을 지불하면 추가 비용 없이 할 수 있는 일이 많습니다. 아이스크림을 먹을 수도 있고 햄버거를 먹을 수도 있고 모든 것을 함께 먹을 수도 있습니다.

이 개념을 좀 더 구체적으로 만들기 위해 100개의 트랜잭션을 100개의 NFT를 발행하는 간단한 경우에 1개의 트랜잭션을 100개의 NFT를 발행하는 데 보낼 수 있습니다. 이러한 비용은 NFT를 발행하는 비용과 거의 비슷합니다. 다중 서명 지갑에서 Mario 캐릭터를 가져오는 블록의 첫 번째 트랜잭션과 Mario를 요청하고 게임을 플레이할 수 있도록 하는 두 번째 트랜잭션과 같이 이기종 패키지 트랜잭션이 있을 수도 있습니다. 게임에서 이기고 트로피를 받으면 세 번째 트레이드를 통해 트로피를 친구와 공유하는 트로피 캐비닛에 넣을 수 있습니다. 이것에 대한 멋진 점 중 하나는 프로그래밍 가능한 트랜잭션 블록을 통해 프로그래머가 코드를 작성할 수 있으므로 게임이 다중 서명 지갑이나 Mario가 저장되는 방식에 신경 쓸 필요가 없다는 것입니다. 또한 트로피 캐비닛이나 구현 방법에 대해 알 필요가 없습니다.

프로그래밍 가능한 트랜잭션 블록은 입력 및 출력 개체가 있는 트랜잭션으로 구성됩니다. 트랜잭션이 입력 개체를 필요로 하는 경우 어디에서 왔는지 신경쓰지 않고 해당 항목을 가져올 수 있고 어디로 가는지 신경쓰지 않고 필요한 곳에 출력을 전달할 수 있습니다. 다른 블록체인에서는 결합이 더 높기 때문에 게임은 다중서명 지갑 및 트로피 보관함과 통합해야 하거나 모두 일부 공통 인터페이스를 구현하고 더 높은 결합을 가져야 합니다. Sui는 내가 즉흥 연주라고 부르는 것을 훨씬 더 쉽게 만듭니다. 마찬가지로 파이프라인이 일치하면 하나의 트랜잭션으로 모든 작업을 수행할 수 있습니다.

그렇다면 사용자를 위한 프로그래밍 가능한 트랜잭션 블록의 이점은 무엇입니까?

사용자 관점에서 다음과 같은 이점이 있다고 생각합니다. 여러 트랜잭션을 개별적으로 수행하는 대신 모든 작업을 하나의 트랜잭션으로 묶을 수 있기 때문에 가스 비용을 낮출 수 있습니다. 또한 승인 횟수도 줄었습니다. 트랜잭션 승인이 필요한 시스템을 사용하는 경우 한 번만 수행하고 한 번에 모두 수행하면 됩니다. 또한 원자성의 또 다른 지점이 있다고 생각합니다. 세 가지 다른 작업을 수행하고 첫 번째 두 작업이 성공할 때만 세 번째 작업이 성공하기를 원하는 경우 이러한 작업이 별도의 트랜잭션이어야 하는 경우에는 작동하지 않습니다. 하지만 그것들을 모두 하나의 트랜잭션에 넣을 수 있다면 아무 문제가 없습니다.

Sui의 개발 경험이 프로그래머에게 얼마나 중요한지에 대해 다른 사람들에게 이야기하는 것을 들었습니다. 경험이 많고 초보 Web3 프로그래머가 Sui Move를 시작하는 것에 대해 공유할 일화가 있습니까?

다른 Web3 프로그래밍 언어를 사용하는 개발자의 경우 Move 및 Sui Move에서 더 생산적으로 느껴집니다. 동시에 이 방법은 더 안전합니다. 나는 Bucket Protocol에 대한 팟캐스트에 있었고 그들은 Sui에서 정말 멋진 DeFi 프로젝트를 구축하고 있었습니다. 시스템 아키텍처를 시연하면서 서로 다른 구성 요소가 함께 작동하는 방식을 설명합니다. 그들은 이 프로젝트를 Solidity로 작성했다면 8개월이 걸렸을지 모르지만 Sui Move를 사용하면 2개월밖에 걸리지 않았고 보안에 매우 자신이 있다고 말했습니다. Sui Move의 프로그래밍 모델은 항목 구성 방법에 대한 아이디어와 매우 유사합니다. Solidity 세계에서 이 연결은 훨씬 더 간접적입니다.

이것은 하나의 예일 뿐이며, 사람들이 언어를 더 빨리 배우고 끝냈을 때 결과에 ​​대해 더 자신감을 느낀다고 말하는 유사한 사례를 많이 듣습니다. 이것은 나를 매우 행복하게 만듭니다. 그러나 어떤 면에서 그것은 놀라운 일이 아닙니다. 우리는 Solidity를 살펴보고 문제를 발견했습니다. 우리의 디자인은 더 안전하고 빠르게 만드는 방법을 중심으로 명시적으로 진행됩니다. 우리는 그 언어를 사용하는 사람들이 해결하려고 하는 문제와 존재하는 것뿐만 아니라 그들의 필요에 맞는 언어를 어떻게 설계할 것인지에 대해 생각합니다. 이 언어는 사람들이 직면하는 문제를 위해 설계되었으므로 이 언어로 전환하면 이점을 실제로 느낄 수 있습니다.

그들은 "선발자가 이긴다"고 말하지만, 이 경우에는 "마지막 무버가 이긴다"라고 말할 수 있을 것 같습니다.

예, 그렇습니다.

Sui Move와 Sui의 일반적인 객체 지향 특성을 언급할 때 이미 이에 대해 이야기하고 있습니다. 그러나 Sui Move의 설계와 Web3의 대량 채택을 달성하는 Sui의 능력, 특히 낮은 대기 시간, 낮은 비용 및 확장성 측면에서 더 명확하게 연결할 수 있습니까?

Sui Move와 Sui의 일반적인 객체 지향 특성을 언급할 때 이미 이에 대해 이야기하고 있습니다. 그러나 Sui Move의 설계와 Web3의 대량 채택을 달성하는 Sui의 능력, 특히 낮은 대기 시간, 낮은 비용 및 확장성 측면에서 더 명확하게 연결할 수 있습니까?

우리는 Sui에 기여하는 것에 대해 매우 신중하며, 이는 다른 플랫폼도 직면하고 있는 문제라고 생각합니다. 이더리움에서 15TPS(초당 트랜잭션), 100 또는 1,000과 같이 제한된 용량이 있는 경우 고정된 숫자인 경우 플랫폼이 너무 성공적이면 용량 한계에 도달합니다. 이 시점에서 플랫폼을 사용하는 모든 사람의 경험이 저하됩니다. 1,000개의 슬롯만 있는 경우 가스 경매 등을 통해 가장 중요한 1,000개를 선택해야 합니다. 모든 사람의 가격이 올라가거나 모든 사람의 대기 시간이 늘어나거나 둘 다입니다. 가장 높은 수수료를 지불하는 쪽만 이기고 나머지는 다른 곳으로 가거나 더 오래 기다려야 하기 때문에 많은 사용 사례가 제외됩니다. 이것은 이상적이지 않습니다.

Sui의 목표는 수평적 확장성입니다. 일정량의 하드웨어를 할당하면 일정량의 처리량을 달성할 수 있습니다. 더 많은 처리량이 필요한 경우 유효성 검사기는 더 많은 하드웨어를 도입할 수 있습니다. 이에 대한 상한선은 없습니다. 이것이 모든 Web2 서비스가 작동하는 방식입니다. 물론 일부 공학적 제약과 문제를 해결해야 하며 확실하거나 쉬운 일은 아니지만 확장 가능한 웹 서비스를 설계할 때 모두가 수평적 확장성을 달성하기를 원합니다.

Sui가 더 많은 고객이나 사용자를 얻는다면 목표는 Sui가 계속 성장하고 모든 것이 작동하는 것입니다. 물론 대기 시간을 매우 낮게 유지하십시오. 더 높은 처리량을 위해 대기 시간을 희생할 필요가 없습니다.

Libra 시스템에서는 이러한 속성을 고려하지 않습니다. 그것은 작은 규모의 결제 시스템입니다. 하루에 수백 명의 결제 운영자, 수천 또는 수백만 건의 결제가 가능하지만 그 이상은 아닙니다. 따라서 더 간단하고 사용하기에 충분하기 때문에 단일 프레임워크 아키텍처를 채택했습니다. 그러나 Sui의 경우 수평적 확장성 기능이 없기 때문에 Libra 시스템이 작동하지 않을 것임을 알고 있습니다. 그래서 우리는 이를 달성할 수 있는 시스템을 처음부터 어떻게 설계해야 하는지 생각했습니다. 여기서 객체 지향 데이터 모델이 등장합니다. 우리는 기본적으로 이전 계정 기반 데이터 모델에서 멀어졌습니다. 수평적 확장성을 달성하기가 너무 어려웠기 때문입니다. 모든 것을 개체로 구성하는 경우 전역 상태는 개체 ID에서 개체로의 하나의 큰 맵일 뿐입니다. 그것은 키-값 저장소이며 키-값 저장소를 확장하는 방법을 알고 있습니다. 이것은 간단한 엔지니어링 질문입니다.

그렇다면 문제는 키-값 저장소에서 데이터를 가져와서 업데이트하는 트랜잭션 구조를 어떻게 설계해야 하느냐입니다. 키-값 저장소를 어떻게 샤딩합니까? 어떤 트랜잭션을 처리해야 하는지 어떻게 결정합니까? 기본적으로 그게 다입니다. 예를 들어, 이것은 우리가 확장하는 방법을 알고 있는 것입니다. 인증된 읽기를 수행하고 Move 등을 사용하여 블록체인의 속성을 가진 시스템으로 어떻게 전환할 수 있습니까? 그런 다음 가능한 한 원활하게 모든 것을 통합하는 방법은 무엇입니까?

높은 수준에서 Web2 개발자에 회의적인 사람들에게 분산 기술의 약속을 어떻게 말합니까?

블록체인과 암호화폐는 본질적으로 마찰을 제거하는 기술이라고 생각합니다. 정보가 이러한 장벽을 넘을 수 없기 때문에 금융 거래, 애플리케이션 구축 또는 정보 설정을 매우 어렵게 만드는 몇 가지 장벽이 있습니다. 이러한 장벽을 넘을 경우 일부 제3자의 도움이 필요합니다. 그들은 특정 수수료를 청구할 것입니다.

전형적인 예는 집을 사면 사는 사람과 파는 사람이 있는데 실제 대금을 지불할 때는 아무 일도 하지 않고 그저 앉아서 돈을 쥐고 있는 제3의 보증인이 있어야 한다는 것입니다. 서로를 완전히 신뢰하지 마십시오. 이것은 삶의 사실입니다. 우리는 이것을 다룰 것입니다. 그러나 보증 에이전트가 양 당사자가 볼 수 있거나 일부 제3자에 의해 검증된 코드일 수 있는 경우 무료 또는 훨씬 적은 비용으로 작업을 수행할 수 있습니다. 블록체인의 목적은 부동산 보증을 없애는 것이 아닙니다. 그것은 단지 응용 사례입니다. 그러나 이것은 일반적인 원칙입니다.

앱 A와 앱 B가 서로 상호 운용되지 않도록 하는 대신 동일한 기본 플랫폼에 구축되므로 인앱 항목, 데이터, 교차 프로모션 등 모든 것이 한 앱에서 다른 앱으로 흐르도록 할 수 있습니다. , 또는 둘 다 위에 구축된 일부 타사 기능. 또는 사이트가 쿠키를 통해 데이터를 공유하지만 해당 쿠키는 읽기 전용 메타데이터인 인터넷을 생각해 보십시오. 이 쿠키가 화폐가 된다면 어떨까요? 아니면 소비 가능한 물건이 될 수 있습니까? 이것이 로열티 프로그램과 쿠폰이 될 수 있다면 어떨까요? 모든 것이 이 기능을 내장하고 있습니다. 매우 추상적이지만 잠재성이 있는 곳입니다. 일반적으로 건물을 짓는 사람들은 이것이 내가 더 매력적인 것을 만드는 데 사용할 수 있는 새로운 초능력이라고 생각합니다.

최종 사용자의 경우 기술 전문가가 아니더라도 다른 옵션이 불투명한 큰 중앙 엔터티인 경우에도 코드 신뢰에 대해 생각할 때 주저함을 느끼십니까?

최종 사용자의 경우 기술 전문가가 아니더라도 다른 옵션이 불투명한 큰 중앙 엔터티인 경우에도 코드 신뢰에 대해 생각할 때 주저함을 느끼십니까?

난 그렇게 생각하지 않아. 우리가 매일 이것을 하기 때문에, 맞죠? 내 이메일에 로그인할 때 코드가 내 메일을 삭제하거나 보낼 때 실제로 보내지 않을까봐 걱정하지 않습니다. 그런 일이 발생하면 이메일 사용을 중단하거나 다른 공급자를 사용할 것입니다. 여기에서도 매우 비슷하다고 생각합니다. 물론 많은 사람들만이 실제로 무언가를 읽고 어떻게 작동하는지 확인할 수 있습니다. 이메일을 확인하고 싶은데 코드가 없기 때문에 확인할 수 없습니다. 그래서 투명성은 그것의 중요한 측면입니다. 실제로 모든 사람이 할 수는 없지만 일부는 즉석 확인을 할 수 있습니다. 또한 재사용과 불변성이 있습니다. 이것이 핵심입니다. 이메일에 로그인할 때 마지막으로 작업을 수행한 이후 코드가 변경되었는지 여부를 알 수 없습니다. 이에 대한 투명성이 없습니다. Web3에서도 이 부분의 정보를 얻을 수 있으며 다른 곳에서는 얻을 수 없습니다.

Sui Move의 향후 발전에 대해 어떻게 예상하십니까?

지금 우리가 집중하고 있는 많은 기능은 사람들이 Sui Move 팩의 초기 배치를 출시한 다음 해당 팩을 어떻게 성장시키고 싶은지, 성장하기 쉬운 것과 어려운 것을 확인한 경험을 기반으로 합니다. 수이무브는 처음 패키지를 출시할 때 아주 좋은 언어인데, 초기 패키지 사용자 신뢰, 사용 원칙을 어기지 않고 타입을 바꾸고, 필드를 추가하고, 기능을 추가하고, 시너지 방식으로 하고 싶다면, 그러면 매우 어려운 문제가 됩니다. 우리가 하는 많은 작업은 이 문제를 살펴보고 프로그래머에게 원래 코드를 사용하는 사람들에 대한 신뢰를 유지하면서 코드를 확장할 수 있는 유연성을 제공할 수 있는 언어 수준의 기능을 파악하는 것입니다.

우리는 이와 관련된 많은 기능, 특히 열거형에 대해 작업하고 있습니다. Move를 프런트 엔드 코드에 연결하는 경험과 관련된 다른 작업도 진행 중입니다. 일반적인 Sui 앱의 5%는 Move 코드이고 95%는 프런트 엔드 코드라는 농담을 좋아합니다. 그래서 우리는 그 95%에 대해 많은 관심을 가지고 있습니다. 우리는 Move에 대해 이야기하는 데 많은 시간을 할애하지만 다른 부분을 더 생산적으로 만들고 연결하기 쉽게 만드는 데에도 많은 관심을 기울입니다. 일반적으로 보안을 개선하기 위해 애플리케이션을 Move로 더 많이 구성하려면 어떻게 해야 합니까? 동시에 Move 프로그래머와 Move 프로그래머가 아닌 프로그래머가 95%의 코드에 더 쉽게 액세스할 수 있도록 하려면 어떻게 해야 할까요?