원작자: Sui World DAO
작년에 a16z와 다른 기관들은 Sui로 대표되는 Move 퍼블릭 체인을 강력하게 홍보하여 Move 언어를 Meta Diem의 폐허에서 되살렸습니다.동시에 Sui Move가 등장한 순간부터 불리한 목소리가 항상 존재했습니다.
Move 언어가 Solidity나 다른 개발 언어보다 낫기 때문에 반드시 새로운 스마트 계약 언어가 필요하고 처음부터 새로운 Layer 1을 구축하게 되어 기쁠까요?
최근 a16z Crypto 팀과 MystenLabs의 공동 창립자이자 CTO이자 Move 언어의 아버지인 Sam Blackshear는 프로그래밍 언어 및 암호화를 주제로 팟캐스트 대화를 진행하여 Move가 중요한 방향인 이유에 대해 논의했습니다. 미래의 스마트 계약을 위해.
이 팟캐스트에서 a16z Crypto와 Sam Blackshear는 디자인 사고, 객체 지향 및 자산 프로그래밍, 보안, 공유 형식 검증, 거버넌스 및 커뮤니티 도구, 플랫폼 간 적응성 및 기타 주제에 대해 논의합니다.
주요 공유 내용은 다음과 같습니다.
1. 프로그래밍 언어 및 스마트 컨트랙트 히스토리
전통적인 프로그래밍에서 스마트 계약 프로그래밍, Move 프로그래밍까지. Move는 유형 시스템, 정적 타이핑 및 컴파일 시간 검사와 같은 문제를 수용하기 위해 언어를 설계하는 방법에 대한 최초의 시각이었습니다.
2. Move 스마트 계약의 혁신
EVM은 이더리움용으로 설계된 플랫폼의 구현 세부 사항을 오버핏합니다. 개발자들은 결국 이더리움을 확장하기 어렵게 만든 일부 버그를 포함하여 이더리움이 내린 많은 설계 결정을 물려받아야 했습니다. Move는 핵심 언어에 블록체인 관련 항목을 추가하지 않고 설계되었습니다. 소스 코드 언어 수준의 혁신은 매우 중요하며 Move가 궁극적으로 제공할 수 있는 것은 코드 유효성 검사기 및 다른 프로그래머의 공격으로부터 VM 수준 보호입니다.
3. 수이무브의 디자인 아이디어
Move는 사용자 트랜잭션 및 스마트 계약을 실행하는 데 사용되는 실행 가능한 바이트코드 언어입니다. Sui Move에서는 검증자를 보다 효율적으로 병렬화할 수 있으므로 이러한 항목을 프로토콜 수준으로 인코딩하지 않고도 저장 및 실행이 더 쉬워지고 사용자와 프로그래머가 이를 고려할 수 있습니다.
4. 보안
스마트 계약의 세계에서 우리는 제약 조건에 처해 있습니다. 우리는 아주 적은 양의 코드를 작성하고 완벽해야 하며 보안이 최우선 순위여야 합니다. 이동 보안은 프로그래머가 스스로 발을 딛는 것을 방지하는 것뿐만 아니라 가능한 경우 올바른 프리미티브를 제공하여 공격을 방어할 수 있도록 합니다.
5. 객체 지향 및 자산
Move는 대부분의 Web2 객체 지향 프로그래밍 언어가 그러하기 때문에 객체 지향 및 자산 지향 스마트 계약 프로그래밍 언어로 설계되었습니다. Sui Move에서는 객체에 사물의 중심점을 배치함으로써 세밀한 액세스를 가능한 한 정확하게 표현할 수 있는 높은 인센티브가 있습니다. Sui Move의 전역 저장소 구조는 개체 ID에서 개체 ID로의 매핑입니다.
6. 보안 비교
Move는 구성에 의한 스마트 계약 프로그래밍에서 재진입 및 누락된 권한 확인을 제거합니다. Move에서 객체 소유권 정보는 실제로 프로그래머가 제어할 수 있는 객체 메타데이터에 저장되지 않습니다. Move Prover는 스마트 계약 작성 시 언어 오류를 방지하도록 설계되어 개발자가 많은 기본적인 실수를 방지할 수 있습니다.
7. 스마트 계약 언어의 거버넌스
처음에 Move는 실제 거버넌스 없이 Facebook에서 개발되었습니다. 우리는 언어를 매우 신중하게 확장합니다. 단순함이 가장 중요하지만 우리는 그것을 적극적으로 확장할 것입니다. Sam Blackshear는 Move가 체인 EDM의 기본 기능 중 일부를 여전히 적용할 수 있는 크로스 플랫폼 언어로 설계되고 스마트 계약 개발 전문가와 Web2 신규 이민자 모두를 뛰어난 유연성으로 다루는 것과 같은 매우 구체적인 소망을 가지고 있습니다. .
8. 개발자를 위한 학습 제안
많은 코드를 읽는 것이 언어를 배우는 가장 좋은 방법입니다. 기꺼이 공유하고 더 깊이 파고들어 다른 사람과 코드를 공유하고 함께 오픈 소스 커뮤니티를 구축하는 것을 진정으로 즐기는 사람들을 찾으십시오. 당신의 일을 더 쉽게 해줄 수 있는 어떤 도구라도 그것이 어떻게 작동하는지 배워야 합니다.
첫 번째 레벨 제목
호스트 Sonal Chokshi 소개
차세대 인터넷 구축에 대한 a16z Crypto 팀의 쇼인 Web 3.0에 오신 것을 환영합니다. 저는 호스트인 Sonal Chokshi입니다.
이 쇼는 개발자, 크리에이터, 설계자, 비즈니스 리더 또는 정책 입안자 등 암호화 및 Web 3.0과 관련된 문제를 더 깊이 이해하고 파헤치려는 모든 사람을 돕기 위해 고안되었습니다. 우리는 이제 쇼의 새로운 시즌을 시작하고 있습니다. 오늘의 에피소드는 기존 스마트 계약 프로그래머와 이 분야에 뛰어들고자 하는 다른 개발자 모두를 위해 프로그래밍 언어와 암호화폐에 초점을 맞춥니다. 프로그래밍 언어의 진화와 출현에 대해 궁금한 사람들에게도 좋은 선택입니다.
오늘의 스페셜 게스트는MystenLabs의 공동 창립자이자 CTO인 Sam Blackshear, 회사는 Web 3.0의 분산된 미래를 위한 토대를 마련하고 있습니다. Sam은 박사 학위부터 Facebook에서 일하기까지, 스마트 계약 구축을 위한 오픈 소스 프로그래밍 언어 및 Move의 작성 및 저자가 되기까지 프로그래밍 언어 분야의 고위 경력을 가지고 있습니다. 이 주제에 대해 더 자세히 이야기하겠습니다.
프로그램 내내 우리는 또한 초대합니다Noah, a16z Crypto의 스마트 계약 연구 엔지니어, 그와 다른 파트너는 최근 Helios라는 이더리움용 경량 클라이언트를 개발하고 도전적인 가스 최적화에서 우승했습니다.
우리는 또한 초대a16z Crypto의 수석 엔지니어 Eddy Lazzarin첫 번째 레벨 제목
프로그래밍 및 스마트 계약의 역사
진행자 소날 촉시:
Noah가 먼저 말하고 Sam Blackshear와 Eddy가 그 뒤를 잇는 전통적인 프로그래밍의 역사부터 시작하겠습니다.
a16z Crypto Noah：
전통적인 프로그래밍, 스마트 계약 프로그래밍 및 Move 언어의 세 가지가 있다고 생각하기 때문에 프로그래밍 역사가 스마트 계약 프로그래밍의 역사에 어떤 영향을 미치는지 이해하고 싶습니다. 세 가지 모두 고유의 역사가 있습니다.
Sui CTO Sam Blackshear：
예, 저는 이 프레임워크를 좋아합니다. 사람들이 구문을 디자인하거나 사람들을 행복하게 만들기 위해 언어를 사용하는 것은 사실이지만 그 이상입니다. 그래서 저는 이 큰 그림 프레임워크를 매우 좋아합니다.
a16z Crypto Eddy Lazzarin：
이를 바탕으로 전통적인 프로그래밍은 지난 20~30년 동안 다양한 경향을 보였다. 전통적인 프로그래밍 언어가 변경되어 몇 가지 뜨거운 주제가 등장하고 있습니다. 유형 검사가 매우 느슨한 동적 프로그래밍 언어가 매우 인기가 있었던 때는 오래되었습니다. 일반적으로 뛰어들어 유형을 잊어버리고 모든 기술적 세부 사항을 잊어버리고 코드를 작성하는 것이 더 인체공학적인 방법이라고 믿어집니다.
Sui CTO Sam Blackshear：
그러나 최근에 사람들은 프로그램이 실행되기 전에 프로그램에 대해 가능한 한 많은 세부 사항을 알기 위해 유형 시스템, 정적 타이핑 및 컴파일 시간 검사와 같은 것에 대해 더 깊이 생각하기 시작했습니다. 이러한 추세는 끊임없이 변화하고 있습니다. 그러나 스마트 계약 프로그래밍의 경우 매우 새롭기 때문에 스마트 계약 프로그래밍에서 이러한 유형의 역사를 본 적이 없으며 이는 매우 다릅니다.
나는 Move 언어가 이것을 수용하기 위해 언어가 어떻게 설계될 수 있는지에 대한 우리가 본 가장 초기의 증거라고 생각합니다(유형 시스템, 정적 타이핑 및 컴파일 타임 검사와 같은 문제). 정적 및 동적 타이핑과 같은 스마트 계약 프로그래밍에서 어떤 변화를 기대하는지 궁금합니다. 현재 단 하나의 언어인 Solidity가 있기 때문에 이러한 주제는 아직 나오지 않을 수 있습니다.
진행자 소날 촉시:
그렇다면 이것이 스마트 계약 프로그래밍으로의 이동과 어떤 관련이 있습니까? 샘 다시 대답해 주세요?
Sui CTO Sam Blackshear：
이 스마트 계약 공간에서 EVM은 스마트 계약 언어의 첫 진입자로서 다양한 경향이 있습니다. 사람들은 스마트 계약으로 무엇을 하고 싶은지 모릅니다. 우리가 그것들을 쓰는 방법이나 이런 종류의 것들 그래서 나는 사용법을 발견해야 하는 전문가의 유형을 이해하려고 노력하는 유연성이 더 중요하다고 생각합니다. 이제 우리는 빌딩 블록에 대해 알고 있거나 최소한 알고 있는 것 같습니다.
스마트 계약의 추세는 매우 도메인에 따라 다릅니다. 자산에 대한 템플릿을 정의하고, 자산 전송을 위한 정책을 정의하고, 액세스 제어 및 권한을 확인합니다.
이것이 기본입니다. 컴파일러나 운영 체제 또는 스마트 계약 언어로 그런 유형의 것들을 작성하지 않습니다. 따라서 그것들은 범용 프로그래밍 언어에 비해 매우 훌륭하고 장점이 있습니다.
사람들은 EVM이 프로그래밍이 가능해진 지 한참 후에 ERC-20 표준이 나왔음에도 불구하고 EVM이 이더리움 프로그램을 작성하기 위한 기본 빌딩 블록 중 하나로 간주된다는 사실을 과소평가한다고 생각합니다. 나는 그 전에 가장 기본적인 것들이 명확하다는 어떤 명백한 증거도 보지 못합니다.
이제 유형을 당연하게 여길 수 있습니다. 유형과 이러한 것들을 우회하는 것은 어느 정도의 기술적 부채를 감당할 수 있다고 생각합니다. 규모가 작고 빠르게 움직이고 싶고 코드를 버릴 수 있다면 이런 종류의 기술 부채는 완벽하게 허용됩니다. 하지만 회사나 스타트업, 빠르게 성장하는 작은 회사, 모든 사람이 전체 코드 베이스를 이해하고 이런 종류의 기술적 부채는 감당할 수 있는 규모로 설명하는 것이 흥미롭습니다.
그러나 규모가 아주 크면 자신이 만들고 있는 새로운 객체와 시스템의 영향을 알지 못하는 수많은 사람들이 코드를 변경합니다. 이것을 유형 시스템에 넣으면 나중에 누군가가 우연히 부딪힐 유리 울타리를 실수로 만드는 대신 모호하지 않고 간단한 방식으로 코드를 작성하고 장애물에 부딪힐 수 있습니다.
예를 들어, 여러분이 말씀하신 것처럼 복제를 방지할 수 있고, 자산의 최대 공급량을 설정할 수 있습니다. 이러한 제약 조건은 매우 중요하며 프로젝트 규모에 관계없이 유지 관리해야 합니다. 프로젝트의 상태와 보안을 유지하는 데 매우 중요한 제약 조건입니다.이러한 경계를 알면 이제 이를 적용할 수 있는 프로그래밍 언어를 만들 수 있습니다. 그것이 제가 Move 언어를 보는 방식입니다.
올바른 작업을 수행하는 데 필요한 제약 유형을 배우면서 이제 언어 자체에 제약 조건을 포함할 수 있습니다. 그래서 나는 그것이 당신이 말했듯이 유형과 다소 비슷하다고 생각합니다.
유형이 프로그램 온전성과 안전에 매우 중요하다고 언급했습니다.소규모 프로젝트에는 동적 타이핑이 적합할 수 있지만 프로젝트가 커지면 정적 타이핑을 사용해야 한다고 말씀하셨습니다. 나는 약간 동의하지 않습니다. 완전히 정적 타이핑이 더 적합하다고 생각합니다. 이것은 참신한 테이크 일 수 있습니다. 프로그래머 정신을위한 것입니다. 내가 본 것 중 가장 무서운 것은 바로 가기 control k를 누를 때 함수 서명이 무엇인지 알려주는 것입니다. 파이썬을 작성할 때 이것은 나를 두렵게 한다. 함수 서명을 보고 매개변수의 이름만 봅니다. 나는 도대체 내가 무엇을하기를 원합니까?
a16z Noah：
사람들이 코드를 작성하고 다시는 보지 않는다는 생각을 받아들이다니 믿을 수 없습니다.
a16z Eddy Lazzarin：
그들은 시스템의 요구 사항을 염두에 둘 수 있다는 기본 가정을 받아들입니다.
a16z Noah：
그러나 100줄 프로그램이 있어도 이것을 기본값으로 설정하는 것이 가능하지 않다고 생각합니다.
Sam Blackshear ：
작동하지만 완벽하지는 않습니다.
a16z Eddy Lazzarin：
그 쪽이 맞는 거 같아요. 그리고 그 사고방식이 진화했다고 생각합니다. 이전에는 프로그래머를 동료로부터 보호하기 위해 유형 시스템이 사용되었습니다.시작이 너무 커질 때 유용합니다. 하지만 지금은 나 자신을 보호하는 것과 같습니다.
스마트 계약의 맥락에서 그것은 공격자로부터 나를 보호합니다. 일반 프로그램에서는 공격자가 유형 시스템에 묶여 있을 때 프로그램을 배포하지 않기 때문에 이것이 진정한 차이점입니다. 공격자는 다른 언어로 기계 코드를 작성할 수 있습니다. 자신의 방화벽을 보호하기만 하면 됩니다. 그러나 여기서는 공격자의 코드로 흘러들어가 그대로 유지될 멋진 형식의 개체를 작성합니다. 타입 시스템은 나를 안전하게 지켜줘야 합니다.
말씀하신 것처럼 다양한 요구 사항을 제공하는 훌륭한 도구이며 복사 방지와 같이 이를 시행해야 합니다. 그것은 일반적인 유형 시스템에서 생각하거나 삭제를 방지하거나 특정 방식으로 값을 사용하거나 파괴해야 하는 것이 아닙니다. 이것은 모두 우리가 스마트 계약에 대해 작업하고 있고 이러한 사용 사례에 대해 의미 있는 유형 시스템을 제시하려고 노력하고 있기 때문에 결국 이러한 것들을 이동에 추가하고 아마도 미래의 스마트 계약 언어도 추가하게 될 것입니다.
진행자 소날 촉시:
사실 여러분, 전통적인 프로그래밍과 스마트 계약 프로그래밍의 다른 차이점에 대해 조금 더 이야기해 봅시다. 하지만 더 진행하기 전에 스마트 계약 프로그래머가 사용할 수 있는 언어에 대한 간략한 개요를 제공할 수 있습니까? 솔리디티, 바이퍼 등과 같이 현 상태를 보고 싶기 때문에 큰 그림을 봐야 한다고 생각합니다. 어떤 콘텐츠를 알면 더 빨리 시작할 수 있습니다.
Sui CTO Sam Blackshear ：
예, 기본적으로 스마트 계약을 작성하려면 거의 항상 견고성을 사용하게 될 것입니다. 다른 여러 소규모 생태계 중 하나에 속하지 않는 한.
Polkadot 생태계에 있다면 기존 프로그래밍 언어인 ink!(Sui World Note: ink!는 Rust에서 스마트 계약을 작성하고 Wasm 코드로 컴파일하기 위해 Parity에서 개발한 스마트 계약 언어입니다)를 사용하게 됩니다. StarkNet 생태계에 있다면 Cairo를 사용합니다(Sui World 참고: Cairo는 STARK 증명 시스템을 위한 프로그래밍 언어 중 하나입니다).
그러나 대부분의 경우 스마트 계약 작성 방법에 대한 조언을 제공한다면 Solidity를 배우고 EVM을 배우는 것이 좋습니다. Viper를 사용하고 싶을 수도 있습니다. 유일한 단점은 Viper가 최신 버전이고 버그에 더 취약할 수 있다는 것입니다. 몇 년 전 입금 계약을 확인할 때 Viper 컴파일러에서 많은 버그를 발견한 것을 기억합니다. 이 버그를 발견한 사람은 현재 16z에서 일하고 있으며, 그는 Day June이며 공식 검증 전문가입니다.
Day June은 공식 검증 전문가이기 때문에 현재 a16z에서 일하고 있습니다. 현실은 일부 콘텐츠와 언어를 배워야 한다는 것입니다.
EVM을 깊이 있게 이해해야 하고 정말 훌륭한 스마트 계약 엔지니어가 되려면 EVM을 말도 안 되는 정도로 이해해야 합니다., 각 작업의 가스 비용을 알 수 있도록 가스 비용과 관련된 정확한 코드를 알려줄 수 있습니다. 이것이 현재 우리가 살고 있는 세상입니다.
a16z Eddy Lazzarin：
아마도 소프트웨어 엔지니어로서 코드를 실행하는 시스템에 대해 항상 배울 수 있다는 점을 언급할 가치가 있을 것입니다. 프로그래밍 환경에 대해 알아야 할 것이 많습니다. 그러나 스마트 계약 프로그래밍에서 환경은 매우 풍부하고 복잡합니다. 언어 자체와 거의 독립적으로 이해해야 할 많은 컨텍스트가 있습니다. 그것이 주변에서 일어나는 일, 주변에 어떤 물체가 있는지, 다른 코드가 호출되는 방식입니다. 이것은 매우 이상한 일입니다.
진행자 소날 촉시:
그렇다면 Solidity를 배우는 데 가장 가까운 사람들은 JavaScript를 아는 사람들이라는 것이 사실입니까?
Sui CTO Sam Blackshear ：
사람들은 자바스크립트처럼 함수라는 키워드를 사용하기 때문에 자바스크립트라고 말합니다. 그러나 불행히도 그것들은 그다지 비슷하지 않습니다.
a16z Eddy Lazzarin：
문법적 관점에서 Solidity는 많은 JavaScript 기능을 상속합니다. 눈을 가늘게 뜨고 있거나 기분이 좋지 않은 경우에는 비슷하게 느껴질 수 있지만 실제로는 상당히 다릅니다. 가상 시스템 환경은 매우 다양하므로 공통점이 거의 없습니다.
진행자 소날 촉시:
비슷한 프로그래밍 언어가 있습니까?
a16z Noah：
예, 직접적으로 유사한 프로그래밍 언어가 있다고 생각하지 않습니다. Was(Sui World Note: WebAssembly Studio, C/C++ 및 Rust 코드를 WASM 형식으로 컴파일하기 위한 온라인 도구)에 익숙하고 높은 수준의 격리가 필요한 환경(예: Surplus)에서 코드를 작성하려는 경우 ), 이것은 아마도 이러한 코드가 독립적으로 실행되는 가장 가까운 것이지만 어느 정도의 통신이 필요합니다. 그러나 여전히 그다지 유사하지 않고 사고 방식이 완전히 다르며 피상적 유사성은 위험할 수 있습니다.
a16z Eddy Lazzarin：
아마도 관련이 있는 것은 프로그래밍 언어의 역사에서 몇 가지 큰 실수입니다.블록체인과 관련하여 잘못된 길을 가는 불쾌한 역사가 있는지 모르겠습니다. 우리는 끔찍한 길을 갔습니까?
진행자 소날 촉시:
그건 좋은 질문이야.
Sui CTO Sam Blackshear ：
그건 좋은 질문이야. 1977년에 C 언어가 출시되었으며 Standard ML이 출시된 해이기도 합니다. 표준 ML은 매우 영향력이 큽니다. 지금은 OCaml 언어와 Rust 언어가 영향을 많이 받고 있고, Move 언어도 영향을 많이 받고 있습니다. 그러나 이러한 아이디어는 오랫동안 존재해 왔습니다. 많은 사람들이 C가 주류가 되는 대신 강력한 타이핑, 기본 제공 안전과 같은 표준 ML의 아이디어가 널리 수용되는 대안적인 미래에 대해 생각하고 있다고 생각합니다.
진행자 소날 촉시:
그렇다면 컴퓨터 기술의 이러한 추세는 무엇입니까? 실수라고 말하는 것은 아니지만 Standard ML과 같은 언어는 오늘날에도 매우 현대적으로 보입니다. 그 대체 우주를 상상하는 것은 흥미로운 일이고, 처음 발견했을 때 나는 깜짝 놀랐습니다.
a16z Eddy Lazzarin：
호기심에서 C와 같은 언어와 유사한 언어가 왜 그렇게 간단하고 명령적이라고 생각하십니까? 그들은 상대적으로 낮은 수준에서 컴퓨터에 대해 생각하고 프로그래밍 언어로서 그들은 실제로 많은 일을 하지 않습니다. 그것이 제가 C에 대해 느끼는 방식입니다. 왜 우리는 이 길을 갔습니까?
Sui CTO Sam Blackshear ：
당시 하드웨어 제약으로 인해 C를 사용할 수밖에 없었고 효율적인 프로그램을 작성하거나 컴퓨팅의 경계를 넓히고 싶다면 하드웨어를 앞으로 밀었다면 다른 길을 선택했을 것이라고 생각합니다. 하지만 제 생각에는 함수형 프로그래밍은 어렵고 여러 면에서 직관적이지 않습니다. C언어가 어렵지 않다는 것이 아니라 시작하기가 더 쉽다고 생각합니다. 그러면 당신은 내가 매우 복잡하거나 추론하기 어려운 일을 했음을 깨닫게 됩니다. 하지만 너무 늦었습니다. 그것은 좋은 생각입니다. 기능적 언어는 학습 곡선이 더 가파르지만 요령을 터득하면 제가 제 코드에 대해 스스로 꽤 잘 생각할 수 있고 일이 꽤 잘 풀린다는 것을 깨닫게 됩니다.
a16z Eddy Lazzarin：
컴퓨터가 하드웨어 수준에서 작동하는 방식에 대해 많이 생각하면 C와 같은 언어가 더 간단하다고 생각합니다. 그러나 프로그래밍 언어에 대해 잘 모른다면 C 언어가 시작하기 더 쉽습니다. 그러나 프로그래밍 언어를 잘 알고 있다면 ML 및 기능적 프로그래밍 유형의 언어가 더 많이 탐색해야 한다고 생각합니다.
Sui CTO Sam Blackshear ：
이것은 큰 그림 답변입니다. 그러나 내가 말하고 싶은 것은 소규모 컴퓨터 언어 오류 문제에 관한 것입니다.
a16z Noah：
그래서 저는 함수형 프로그래밍이 얼마나 멋진지 계속 듣고 있기 때문에 이것에 대해 약간 주저하지만 이해하기가 조금 어렵습니다. 그러나 내가 항상 궁금했던 질문은 함수형 프로그래밍이 그렇게 좋은 것이라면 왜 현재 프로그래밍 언어의 네트워크 효과를 극복할 수 없었을까 하는 것입니다. 그것이 나를 놀라게 하는 방식입니다.
그러나 함수형 프로그래밍이 우리에게 가져다주는 큰 공헌은 우리가 사용하는 모든 명령형 언어가 차용된 것이라고 생각한다고 덧붙이고 싶습니다. 하지만 가장 중요한 부분은 방금 말씀하신 것처럼 Rust는 표준 이메일의 영향을 많이 받지만 Rust는 기본적으로 명령형 언어라는 것입니다. 그러나 그것은 그들을 응시하는 데서 오는 모든 멋진 요정 먼지를 가지고 있습니다.
Sui CTO Sam Blackshear ：
일반적으로 진짜 문제는 명령형 언어가 1977년 이후로 너무 많은 영향을 미쳤다는 점이라고 생각합니다. 그런 다음 PRFP가 있습니다. 당신이 말했듯이 그것은 가장 위대한 것이 아니며 자체적으로 훌륭한 아이디어를 가지고 있으며 고립된 상태에서 모든 사람은 자신의 문제를 가지고 있습니다. 우리는 이제 러스트와 같은 실제 혼혈만이 그들과 아름답게 결혼하는 것을 볼 수 있습니다. 정말 풍경이 바뀝니다.
제가 언급하고 싶은 것 중 하나는 Tony Hoare가 노드 참조의 10억 달러 오류라고 부르는 것입니다. 그가 그 당시에는 과장했을지 모르지만 실수를 저지른 것보다 분명히 더 많은 비용이 들었습니다.
a16z Eddy Lazzarin：
첫 번째 레벨 제목
스마트 계약의 혁신적인 개발
a16z Noah：
가상 머신 계층 및 프로그래밍 언어 계층의 혁신과 스마트 계약 개발에 미치는 영향에 대해 많이 이야기하지 않은 것이 사실 궁금합니다.
Sui CTO Sam Blackshear ：
좋은 질문입니다. 사람들이 가상 머신 계층과 프로그래밍 언어 계층의 차이와 같은 차이점에 대해 충분히 생각하지 않았다고 생각합니다. 실제로 EVM과 새로운 가상 머신 계층 외에도 Viper와 같은 소스 코드 언어와 같은 많은 혁신이 있습니다. 이러한 것들은 여러 면에서 솔리디티보다 낫고 재미있습니다.
Move가 우리가 기대하는 Web 3.0의 법적 표준이 된다면 가상 머신 계층의 혁신은 느리고 점진적일 것이라고 생각합니다. 핵심이 고정되어 있기 때문에 완전히 재설계하는 것이 아니라 새로운 내용만 추가할 것입니다.
하지만 소스 코드 언어 수준에서의 혁신이 상당히 중요할 것이라고 생각합니다. 현재 우리는 하나의 소스 코드 언어만 가지고 있지만 바이트코드 형식과 밀접하게 연결되어 있습니다. 하지만 점점 더 많은 고객이 보안에 중점을 두고 스마트 계약을 사용함에 따라 시도할 다양한 소스 코드 언어가 많이 있을 것이라고 상상할 수 있으며 이는 흥미로운 연구 분야입니다. 아마도 당신은 당신의 이전 사실을 기록하는 것으로 시작한 다음 프로그램에서 당신을 위해 정보를 종합하거나 제한 사항에 대한 제안을 할 수 있습니다.
Move 전에 사실을 작성하여 시작한 다음 컴포지팅 프로그램이 프로그램을 채우거나 제약 조건을 제안하도록 할 수 있습니다.
예를 들어 장면 계층 구조처럼 보이는 매우 특정한 게임의 맥락에서 동작을 작성할 수 있습니다. Python 라이브러리로 작성되었지만 Move의 바이트코드로 컴파일되었을 수 있습니다. Solana 또는 다른 플랫폼과 마찬가지로 Move 통합을 생각하고 있지만 가상 머신을 통합하고 싶지는 않지만 Move의 바이트코드를 Salina의 바이트코드 형식으로 컴파일한 다음 개발자 수준에서 Move 소스 코드 언어를 사용합니다.
JVM(Java Virtual Machine)처럼 다양한 접근 방식이 있다고 생각합니다. JVM은 원래 Java만 지원하는 훌륭한 범용 가상 머신입니다. 그러나 시간의 시험을 견뎌냈고 이제 Scala, Groovy 및 이러한 기본 요소를 사용하여 사람들이 원하는 것과 매우 일치하는 다양한 프로그래밍 경험을 설계하는 몇 가지 흥미로운 방법이 있습니다.
따라서 저는 Viper가 소스 언어 수준에서 실험할 수 있는 많은 여지를 제공한다는 편향된 견해를 가지고 있습니다.
a16z Eddy Lazzarin：
모든 대체 EVM 바이트코드 언어에 대해 어떻게 생각하십니까? EVM을 위한 더 스마트하고 복잡한 언어를 구축하기 위한 FE, Iron, Viper 등과 같은 흥미로운 노력이 있다고 낙관하십니까?
Sui CTO Sam Blackshear ：
따라서 이들은 EVM 바이트코드로 컴파일된 다른 소스 코드 언어입니다.
a16z Eddy Lazzarin：
예, EVM 바이트코드로 컴파일됩니다.
Sui CTO Sam Blackshear ：
Facebook에서 Move 설계를 시작할 때 EVM을 빌드하는 다른 소스 코드 언어를 보았을 때 Solidity와 Viper를 살펴보았고 이때 EVM을 빌드하기 시작했습니다. 우리가 궁극적으로 내린 결론은 사람들이 안전한 스마트 계약을 작성하는 데 가장 어려운 문제는 EVM의 기본 특성과 유형화된 값을 신뢰할 수 있는 경계에서 흐르게 하는 방법과 동적 의사 결정 등입니다. EVM의 특징.
더 나은 소스 코드 언어를 구축하면 개발자가 망치기 어렵게 만들 수 있습니다. 더 고급 검증을 수행할 수 있습니다.그러나 궁극적으로 Move가 제공할 수 있는 것, 그리고 우리가 중요하다고 생각하는 것은 코드 유효성 검사기 및 다른 프로그래머로부터의 VM 수준 보호입니다.
소스 코드 언어는 이것을 제공할 수 없습니다. 완벽한 소스 코드 언어를 위해 EVM에서 몇 번을 반복하더라도 VM에 내장되어야 합니다. 저는 Solidity가 훌륭하고 더 잘할 수 있다고 생각합니다. 하지만 저는 VM에 내장된 이러한 기본 보호 장치를 사용하면 다른 경로만큼 좋지 않은 결과를 얻게 됩니다. Half가 멋지다고 생각해서 부끄럽지는 않지만 다른 경로만큼 최종 상태가 매력적이라고 생각하지 않기 때문입니다.
초기 스마트 컨트랙트 언어, 특히 EVM은 내부적으로 거래 구조, 계정 구조, 특정 유형의 암호화 사용 등에 대한 지침을 포함하여 이더리움용으로 설계된 플랫폼의 구현 세부 사항에 적합하다고 생각합니다.
제 생각에는 이더리움과 같지 않은 체인에서 EVM을 사용하는 것이 매우 어렵다고 생각하며 결국 이더리움이 내린 많은 설계 결정을 물려받아야 하고 경우에 따라서는 이더리움 어려움 확장 오류.
Move를 설계할 때 우리는 핵심 언어에 블록체인 관련 항목을 추가하지 않고 특정 블록체인에서 가능한 한 독립적으로 만드는 것을 매우 의식했습니다.
그래서 당신은 Move를 가져가서 스웨덴과 호주에서 하고 있는 또 다른 체인에서 할 수 있는 미친 트랜잭션 구조를 가진 작업 증명 체인에서 사용할 수 있습니다. 이렇게 하면 Move 개발자가 되기 위해 특정 체인에 베팅할 필요가 없습니다. 미래 체인을 포함하여 다양한 체인에서 기술을 사용할 수 있습니다. 언어의 가장 큰 자산은 커뮤니티이기 때문에 이것이 스마트 계약 언어의 생존에 매우 중요하다고 생각합니다. 그리고 기술을 하나의 언어에 과도하게 맞추지 않고 크로스 플랫폼으로 만들면 커뮤니티를 확장하고 성공할 수 있는 더 나은 위치에 설 수 있습니다. 그리고 큰 커뮤니티는 도구에 많은 돈을 투자하고 공공 도서관에 많은 돈을 투자하고 언어가 유명해지고 성공하는 데 정말로 필요한 모든 것을 가능하게 합니다.
그것이 우리가 처음부터 시도한 것입니다. 이제 우리는 언어를 통합하는 방식이 매우 다른 여러 개의 정말 다른 Move 체인을 보았습니다.
a16z Eddy Lazzarin：
이것이 node.js의 기본 테마 인 것 같습니다. 맞습니까?
진행자 소날 촉시:
예.
a16z Eddy Lazzarin：
JavaScript를 알고 있고 많은 일을 하고 싶어하는 사람들이 많이 있습니다. 그들은 다양한 라이브러리를 공유하고 싶어합니다. 기존 코드는 노드를 유용하게 만드는 서버 측 JavaScript 인스턴스를 시작할 수 있습니다. 이것은 백엔드 프로그래밍을 할 수는 없지만 뛰어들어 자신의 분야로 만들 수 있는 모든 종류의 개발자가 있다는 것을 의미합니다.
Sui CTO Sam Blackshear ：
좋은 비교라고 생각합니다. 또한 우리는 프로그래밍 언어 거버넌스에 대해 조금 이야기하고 싶었습니다. Node에는 분명히 매우 높은 수준의 거버넌스 분할 및 분할이 있고 모든 프로그래밍 언어 커뮤니티에는 많은 높은 프로필 거버넌스 분할 및 방향이 있기 때문입니다. 저는 Node를 다루었고 제가 가장 좋아하는 것 중 하나입니다. 하지만 이 주제를 확실히 끝내고 싶습니다. 다른 할 말이 있습니까? 나는 당신이 내가 사랑하는 우리 라디오 쇼의 레지던트 노인이라고 생각합니다.
a16z Noah：
그래서 대위법이 있거나 오히려 멋진 아이디어가 있습니다.왜 아무도 Move용 OP 롤업을 만들지 않았는지 궁금합니다. 정말 멋질 것입니다.OP의 Rollup 사람들이 Ethereum에서 구현된다는 점을 고려하면 MetaMask 및 ECDSA 서명을 사용하지만 Move가 ECDSA를 사용하지 않는 것처럼 우리와 동일한 서명 형식을 사용하지 않는 것 같습니다.
Sui CTO Sam Blackshear ：
예, Ethereum의 EdDSA 및 ECDSA 서명 형식을 지원합니다.
a16z Noah：
완벽하지만 내 요점은 정말 흥미로운 것을 만들 수 있다는 것입니다. 그런데 무브를 배우려고 할 때 디저트와 배우 개를 계속 쳐다봤다. 나는 혼란 스럽다.
Sui CTO Sam Blackshear ：
실제로 문제가 있습니까? 누군가 Move를 배우기 시작하면 혼란스러울 수 있습니다. 저는 스마트 계약 언어를 배우고 있는데 블록체인은 어디에 있습니까? 두 플랫폼 모두에 대한 코드를 작성하려고 하면 이들 간의 차이로 인해 문제가 발생할 수도 있습니다. 그래서 우리가 여전히 알아내고자 하는 도전은 플랫폼을 선택하고, 디저트를 선택하고, Optus를 선택하고, 깊이 있게 배운 다음, 여러분의 기술과 코드가 다른 플랫폼으로 쉽게 이전될 수 있다는 것을 발견하는 것입니다. 여기에는 몇 가지 고유한 문제가 있고 이를 쉽게 하기 위해 해결해야 할 몇 가지 문서 문제가 있다고 생각합니다.
a16z Eddy Lazzarin：
아마도 유추는 SQL을 이식 가능한 기술로 간주하는지 여부에 달려 있습니다. SQL에는 많은 방언이 있습니다. Anti-SQL이 있고 아무도 그것이 무엇인지 알지 못하지만 그들은 SQL을 배울 수 있습니다. 눈을 약간 가늘게 뜨면 어떤 데이터베이스도 사용할 수 있습니다. 특정 함수 이름이나 특정 유형에 대해 약간 혼란스러울 수 있지만 대략적으로 같은 모양. 이것이 SQL을 매우 강력하고 내구성있게 만든다고 생각합니다. 그것이 여전히 데이터의 공통어의 일부인 이유입니다. 이것이 Move의 미래일지도 모릅니다. 나는 우리가 더 잘할 수 있다고 생각합니다.
Sui CTO Sam Blackshear ：
첫 번째 레벨 제목
스마트 계약 프로그래밍의 독특한 점
진행자 소날 촉시:
우리는 기존 대 스마트 계약 프로그래밍, 특정 제약 및 차이점, 심지어 트레드와 스마트 계약 프로그래밍 사이의 일부 유사점을 중심으로 앞뒤로 이동했습니다. 우리가 다루지 않은 스마트 계약 프로그래밍에 대한 고유한 것이 있습니까?
a16z Eddy Lazzarin：
스마트 계약의 맥락에서 또 다른 매우 중요한 것은 Solidity의 가스 계량과 같은 리소스 사용입니다. 컴퓨팅 리소스는 많은 경우 상대적으로 풍부하지만 컴퓨팅 비용도 매우 중요합니다. 그러나 스마트 계약 컨텍스트 외부 또는 블록체인 컨텍스트 외부에서는 덜 건드려지고 고려된다는 것을 의미합니다. 나는 당신이 소비하는 자원이라는 언어의 개념이 스마트 계약 프로그래밍을 위한 흥미로운 자원이 될 수 있다고 생각합니다.
Sui CTO Sam Blackshear ：
그것은 우리가 매우 집중하고 있는 것입니다. 우리는 당신이 말했듯이 전통적인 프로그래밍 언어와 매우 다른 가스 계량을 EVM에 내장했습니다.
미래의 추세는 Gas Meeting이 각 명령에 대해 정말 세분되기보다는 자원 남용과 같은 심각한 문제를 방지하기 위해 점점 더 조악해 질 것이라고 생각합니다.
Gas Golfing(Sui World Note: Gas Golfing은 일련의 스마트 계약 점프 상호 작용에서 가장 가스 효율적인 코드를 작성하는 개발자의 도전을 의미함)와 같은 것이 매우 흥미롭지만 실제로는 코딩에 매우 중요하다고 생각합니다. . 스타일과 안전 모두 많은 해를 끼칩니다.
아이러니하게도 우리가 명령당 요금 모델에 대해서만 알고 있는 이유는 아마도 거대한 가상 머신이 있는 경우 실제로 실행 시간을 측정할 때 100k 명령을 실행하는 것과 500k 명령을 실행하는 것의 차이가 중요하지 않기 때문일 것입니다.
그렇다면 주문당 비용을 청구하는 이유는 무엇입니까? 그래서 저는 이것을 좀 더 거칠게 만드는 방법에 대한 추세를 보게 될 것이라고 생각합니다.
Solidity 코드에서 이 모든 안전하지 않은 블록과 수많은 인라인 어셈블리를 볼 때마다 우리가 얼마나 일찍 시작했는지를 상기시킵니다. 왜냐하면 이것은 스마트 계약 개발자가 고려해야 할 프로그래밍 문제가 아니기 때문입니다. 이것은 성숙의 신호가 아닙니다. 개발 생태계. 그러나 우리는 그 방향으로 나아가고 있습니다. 극단적인 경우를 고려해야 한다는 데 동의합니다. 올바른 알고리즘을 선택하고, 올바른 데이터 구조를 선택하고, 대부분의 소프트웨어 엔지니어링의 경우와 같이 올바른 일반적인 접근 방식을 선택하는 것이 모두 중요합니다. 그러나 각 명령의 비용을 정확히 계산하는 사소한 문제는 아마도 너무 많은 작업일 것입니다.
진행자 소날 촉시:
가스, 유형, 자산 및 보안 최적화에 대해 이야기했습니다. 어떤 다른 제한 사항을 고려해야 합니까?
Sui CTO Sam Blackshear ：
이것은 가스와 유사한 스레드이지만 내가 염두에 두고 있는 특정 하위 집합은 상태입니다. 이것은 저에게 큰 문제입니다. 가스 작업에 대해 생각할 때 저는 극한의 가스 최적화를 좋아합니다.
그러나 우리가 실제 자금을 보유하는 실제 스마트 계약을 다룰 때, 제 일반적인 조언은 이전에 사용한 것보다 약간 적은 상태를 사용하기 위해 길을 떠날 수 없다면 합리적으로 조직되어야 한다는 것입니다. 이것이 영원한 자원과 같기 때문에 더 적은 상태를 사용하기 위해 어리석은 일을 할 수 있다면 큰 어셈블리 블록을 사용할 유일한 시간이며 데이터의 위치를 실행하거나 호출하는 바로 위에 배치해야 합니다.
a16z Eddy Lazzarin：
근본적으로 비싸다고 생각하기 때문에 이 점에 전적으로 동의합니다. 플랫폼이 모든 계약이 상태의 일부를 건드리도록 허용한다면 병렬화하기 어려울 것입니다. 그리고 Squeeze 및 일부 다른 새로운 블록체인 플랫폼이 취하는 접근 방식은 트랜잭션이 액세스할 수 있는 상태를 명시적으로 제한하는 것입니다. 적어도 일부는 알려주세요. 이러한 방식으로 높은 수준에서 플랫폼은 실행 및 합의를 포함한 트랜잭션을 보다 쉽게 병렬화할 수 있습니다. 따라서 이것은 일부 프로그래머가 생각해야 하는 것입니다. 상태에 액세스할 때 가능한 한 빠르게 하고 불필요한 상태를 건드리지 않도록 하여 유효성 검사기가 보다 효율적으로 병렬화하고 더 많은 블록 공간을 확보할 수 있도록 해야 합니다.
a16z Noah：
이것은 역할극이 아닌 상황에서도 모든 유효성 검사기가 전체 상태를 다운로드할 필요가 없다는 사실에 세상을 열어 줍니까? 유효성 검사기가 처리할 수 있는 트랜잭션만 제공하도록 상태를 쉽게 분리할 수 있다면 가능할까요?
Sui CTO Sam Blackshear ：
그런 세상을 실현하는 것이 정말 가능하다고 생각합니다. 이것은 또한 다양한 접근 방식을 위한 길을 열어줍니다.
프로그래머의 관점에서 요약하자면, 다양한 트랜잭션을 통해 전 세계를 접할 수 있다는 것은 매우 가치 있는 일입니다. 그러나 롤업을 통해 또는 여러 트랜잭션에 걸쳐 구현해야 할 정도로 이 이점을 강조할 수는 없습니다. 이렇게 하면 사용자가 알아차릴 수 있는 보안이 줄어들 수 있기 때문입니다.
저는 블록체인의 가치가 이 추상화에서 나온다고 생각합니다. 원장이 있고 모든 가치 있는 상태가 이 원장에 있으며 한 번에 모두 만질 수 있습니다. 프로그래머의 관점에서 블록체인의 가치는 바로 여기에 있습니다. 문제는 어떻게 하면 보이지 않는 곳에서 일을 더 효율적으로 할 수 있느냐는 것입니다. 유효성 검사기가 보다 효율적으로 병렬화될 수 있도록 어떻게 더 희박하게 만들 수 있습니까? Sui에서 검증인은 각각 상태의 일부를 담당하는 여러 작업자를 가질 수 있습니다. 그러나 프로그래머의 입장에서, 심지어 다른 유효성 검사기의 입장에서도 모든 것을 수행하는 논리적 개체처럼 보입니다.
첫 번째 레벨 제목
스마트 컨트랙트 프로그래밍에 대한 생각의 변화
진행자 소날 촉시:
스마트 계약 프로그래밍과 관련된 몇 가지 고유한 측면에 대해 논의했습니다. 사고 방식의 다른 변화는 무엇입니까? 우리는 Eddie가 언급한 것처럼 프로그래밍 세계에서 적어도 컴퓨팅 초기부터 풍요의 세계에 있었지만 이 세계에서 우리는 제한의 세계에 다시 있습니다. 그것은 사고 방식의 예입니다. 다른 사고 방식 변화는 무엇입니까? 특히 스마트 컨트랙트 프로그래밍에 노출된 프로그래머로서 여러분을 놀라게 하거나 가르쳐 주거나 특정 사항에 대해 다르게 생각하게 만든 것은 무엇입니까?
a16z Eddy Lazzarin：
아마도 약간 어리석은 예일 것입니다. 저는 몇 년 전에 ERC-20 토큰의 잔액이 귀하의 계정 소유가 아니라는 것을 처음 알았을 때를 아직도 기억합니다. 귀하의 주소에는 토큰 잔액이 없습니다. 대신 어느 주소에 얼마나 많은 잔액이 있는지 기록하는 토큰 계약이 있습니다. 누군가에게 토큰을 전송하려고 할 때 토큰을 보내는 것이 아닙니다. 대신 계약으로 이동하여 이러한 모든 하위 수준 작업을 수행하여 주소와 해당 주소가 보유한 잔액을 변경해야 합니다. 귀하는 해당 계약을 조작하고 변경할 수 있는 권한이 있습니다. 이것은 매우 반직관적인 접근 방식으로, 제가 EVM과 Slippery에서 처음으로 알아차린 Move에 대한 생각의 흥미로운 변화입니다. 우리가 많이 듣는 영어 단어가 반드시 프로그래밍 모델과 일치하는 것은 아니기 때문에 사고 방식의 흥미로운 변화입니다.
Sui CTO Sam Blackshear ：
나는 당신이 실제로 그것을 할 때 쯤이라고 덧붙이고 싶습니다. 일반적인 세계에서 우리는 개발자 생산성에 대해 매우 우려하고 있습니다. 버그가 거의 없는 많은 코드를 작성하는 것이 엔지니어의 임무이고 이러한 버그가 그리 심각하지 않기 때문입니다. 반면에 스마트 계약의 세계에서 당신의 임무는 아주 적은 양의 코드를 작성하는 것이며 완벽해야 합니다. 모든 면에서 완벽해야 합니다. 그렇지 않으면 다른 사람들의 수억 달러의 돈을 잃게 될 것입니다. 완전히 다른 사고 방식으로의 전환입니다. 두 달 동안 1,000줄의 코드를 바라보며 어떻게 하면 더 좋게 만들 수 있을지, 더 중요하게는 어떻게 하면 완벽하게 만들 수 있을지 알아내려고 노력하면 리뷰어도 똑같은 작업을 수행하여 완벽 여부를 판단합니다.
진행자 소날 촉시:
이것은 생각의 큰 전환입니다. 프로그래밍의 세계에서 적어도 컴퓨팅 초기부터 우리는 풍요의 세계에 있었지만 이 세계에서 우리는 제약의 세계에 있습니다.
a16z Eddy Lazzarin：
생각의 또 다른 변화는 ERC 20 토큰의 세계에서 귀하의 주소가 토큰 잔액을 나타내지 않는다는 것입니다. 토큰을 보낼 수 없으며 토큰 계약을 방문하여 토큰 계약의 주소에 해당하는 토큰 잔액을 찾은 다음 주소와 잔액을 수정하여 토큰 전송을 완료해야 합니다. 이것은 다소 직관에 반하는 사고 방식이지만 EVM 및 Move에서는 매우 중요한 사고 방식의 전환입니다.
Sui CTO Sam Blackshear ：
스마트 계약 프로그래밍에서 귀하의 임무는 작은 코드를 작성하는 것이며 완벽해야 합니다. 이 코드는 수억 명의 자금 안전과 관련될 수 있기 때문입니다. 코드가 올바른지 확인하려면 코드를 면밀히 조사해야 합니다.
또한 스마트 계약에서는 코드를 변경할 수 없기 때문에 스마트 계약을 업그레이드하는 것이 모바일 앱이나 웹 사이트를 업그레이드하는 것보다 더 어렵습니다. 스마트 컨트랙트 프로그래밍에서는 안전한 업그레이드와 신뢰를 지원하는 방법에 대해 생각해야 하며, 이를 통해 전통적인 생태계처럼 보이게 합니다.
하지만 스마트 컨트랙트 프로그래밍에서는 다른 분야 사람들에게는 생소할 수 있는 적대적 사고방식이 필요합니다. 이는 스마트 계약의 배포 모델 때문입니다. 애플리케이션의 예상 사용량뿐만 아니라 의도하지 않은 사용량도 고려해야 합니다. 전통적인 프로그래밍에는 자신을 숨기거나 작은 API로 제한하거나 방화벽을 사용하여 공격자의 행동을 제한하는 등의 방법이 있기 때문입니다.
그러나 스마트 계약의 요점은 당신이 만든 것이 당신이 상상하지 못한 코드와 안전하게 상호 작용할 수 있다는 것입니다. 따라서 이 상황의 장점과 단점을 고려해야 합니다. 이것은 분명히 전통적인 프로그래밍에서 사고 방식의 변화입니다.
진행자 소날 촉시:
스마트 계약을 작성하고 스마트 계약 프로그래밍 언어를 사용하는 방법을 논의할 때 이것이 매우 중요한 질문이며 우선순위를 두어야 하는 질문입니까?
Sui CTO Sam Blackshear ：
네 그럼요. 사실 제가 가장 좋아하는 이야기입니다. 스마트 계약 언어 설계자가 고려해야 할 문제는 보안입니다. 그것이 주요 초점이며, 우리가 그것을 제거할 때까지 유일한 초점일 수도 있습니다.
제 생각에는 스마트 계약 보안은 더 넓은 암호화폐 채택에 대한 실존적 위협입니다. 이렇게 말하는 이유는 이더리움과 솔리디티, 그리고 가장 대중적인 플랫폼인 EVM과 솔리디티를 볼 수 있기 때문입니다. 이 코드를 작성한 초기 프로그래머를 볼 수 있습니다. 그들은 자격이 매우 높았고 기본 블록체인을 정말로 이해했으며 보안에 매우 민감했습니다. 그들은 그들이 무엇을 하고 있는지 알고 있습니다. 나는 그들이 수억, 수십억 달러를 관리하는 코드를 작성하는 책임을 매우 진지하게 생각한다고 생각합니다.
그런데 스마트 컨트랙트 보안 기록 어디를 봐도 꽤 안 좋은데, 이 사람들의 잘못이 아니다. 이것은 매우 어려운 질문이라고 생각합니다. 그리고 언어가 더 어렵게 만든다고 생각합니다. 그래서 내가 가장 좋아하는 사이트인 rakt.news를 보면 순위표를 보거나 매우 일상적이고 매주 또는 매월 발생하는 수천만 달러 가치의 10가지 해킹을 볼 수 있습니다. 규모에 따라 다릅니다. 동시에 스마트 계약 개발자 커뮤니티는 매우 작습니다. 정규직 EVM 프로그래머는 약 5,000명에 불과하며 이는 기존 개발자 커뮤니티에 비해 매우 작습니다.
그래서 우리가 가진 사람들이 가장 하드코어하고 안전을 의식하지만 개발 관행과 안전 기록이 지속 불가능하다고 믿는다면, 당신의 결론은 안전을 만들지 않고는 이 공간이 살아남을 수 있는 방법이 없다고 생각합니다. 문제가 계속된다면 더 나쁘게 성장하려면 전혀 성장하지 않는다는 의미일 수도 있고, Web3에 진입하려는 대형 금융 기관이나 회사처럼 스마트 계약 개발자를 고용해야 하는지 살펴보고 있는 것일까요? 나는 수천만 달러에 해킹을 당하고 긴장할 것입니다. 이러한 상황은 시간이 지날수록 더욱 악화될 것입니다. 그들은 부업에 머물 수 있습니다. 따라서 새로운 스마트 계약 언어를 설계하려는 사람으로서 보안을 가장 먼저 고려해야 합니다.
진행자 소날 촉시:
너희들은 실제로 자산을 잃지 않는다는 맥락에서 그것을 암시했지만 그것이 매우 중요하기 때문에 더 구체적으로 무엇을 의미합니까?
Sui CTO Sam Blackshear ：
내가 의미하는 보안은 프로그래머가 스스로 발을 딛는 것을 방지하고 가능한 한 올바른 프리미티브를 제공하여 그들이 공격을 방어할 수 있도록 하는 것입니다. 왜냐하면 스마트 계약은 코드가 공격에 배치되는 설정이기 때문입니다. 공격자 옆에 있는 공격자는 코드를 직접 호출하고 직접 링크할 수 있습니다. 귀하의 코드는 오픈 소스이거나 적어도 바이트 코드는 오픈 소스입니다.
이것은 지금까지 우리가 본 것 중 가장 적대적인 프로그래밍 환경이며 실수를 저지르는 데 가장 많은 비용이 듭니다. 따라서 스마트 계약 프로그래밍 설계에 대해 이야기하는 경우 항상 보안이 우선되어야 한다고 생각합니다. 일단 보안 문제를 해결하면 다른 표현 요소에 대해 생각할 수 있지만 다소 지루하지만 매우 중요하다고 생각하는 답변이 있습니다.
a16z Eddy Lazzarin：
어떤 기능이 보안에 영향을 미칠 수 있습니까? 이에 대한 몇 가지 예는 무엇입니까?
Sui CTO Sam Blackshear ：
가장 중요한 것은 캡슐화, 특히 캡슐화의 개별 하위 기능이라고 생각합니다. 코드를 작성할 때 공격자가 무엇을 시도할지 예측할 수 없으므로 공격자가 무엇을 할지 예측하지 않고 추론할 수 있어야 합니다. 따라서 소스 코드 수준뿐만 아니라 바이트코드 수준에서도 강력한 유형 시스템이 필요합니다. 그래야만 소스 코드를 작성할 때 얻을 수 있는 보장이 블록체인에 코드를 게시하고 다른 사람들이 의존할 때 거기에 있을 것입니다. on 켜져 있고 상호 작용합니다.
다른 영역에서 널리 사용되는 특정 기능(예: 동적 디스패치)은 본질적으로 스마트 계약 프로그래밍에서 부적절하다는 것을 관찰했습니다.
기존 프로그래밍에서 인터페이스 및 동적 디스패치와 같은 것은 어디에나 있는 핵심 추상화 메커니즘입니다. 인터페이스를 정의하면 다른 사람이 해당 인터페이스를 다른 논리로 다시 작성하고 해당 인터페이스에 대해 프로그래밍할 수 있으며 모든 것이 잘 작동합니다. 그러나 코드가 법인 세상에서 인터페이스는 범죄입니다.라는 속담이 있습니다.
a16z Noah：
농담입니다, 잠시만요. 코드가 법인 세상에서 인터페이스는 범죄입니다.
진행자 소날 촉시:
계속하기 전에 이 문장을 좀 더 설명해 주시겠습니까? 나는 그것을 너무 빨리 뛰어 넘고 싶지 않습니다.
Sui CTO Sam Blackshear ：
네, 맞습니다. 여기서 아이디어는 인터페이스가 동작을 정의하는 것이 아니라 예상되는 동작을 정의한다는 것입니다. 예를 들어 인터페이스, 매개변수 이름 또는 유형의 사양을 읽으면 수행하려는 작업이 무엇인지 알 수 있습니다. 그러나 그렇게 될 것이라는 보장은 없습니다.
따라서 무언가를 보호하기 위해 코드를 작성했지만 실제로는 공격자에게 백지 수표를 남기고 다른 사람이 채울 수 있습니다. 이것은 계약법상 범죄로 보입니다. 불특정 계약입니다. 저는 이 기능이 정말 마음에 듭니다. 전통적인 프로그래밍 언어에서 널리 사용되는 기능입니다. 그러나 우리는 스마트 계약에서 이것이 많은 다른 문제를 야기한다고 생각합니다. 예를 들어 재진입에는 동적 스케줄링이 필요합니다. 예를 들어 동적 스케줄링을 취소하면 재진입이 전혀 없습니다. 이더리움의 포이즌 토큰과 같은 현상은 전송 기능을 재작성하기 때문에 발생하며 모든 사람이 직관적으로 알고 있으며 자금을 전송하는 데 사용되며 다른 작업은 수행하지 않을 것입니다. 하지만 이제는 돈을 훔치는 것과 같이 예상을 뛰어넘는 일을 하게 만듭니다. 이는 제거하는 경우 코드에 대해 추론하고 적절하게 캡슐화하는 것이 훨씬 쉬워지는 기능의 예입니다. 호출 사이트를 볼 때마다 수행할 작업을 정확히 알 수 있기 때문에 나중에 당신을 놀라게 할 일을 하는 사람들.
a16z Eddy Lazzarin：
정확히 말하자면 네 개의 다리와 좌석이 있는 의자에 대한 인터페이스를 정의하고 행동 수준이 아닌 구체적인 수준에서 설명하면 설명하지 않는 것이 암시적일 수 있는 것과 같은 비유라고 생각합니다. 또는 기본 의자에 대한 다른 것들은 일종의 구조적 무결성, 특정 재료, 특정 방식으로 배치된 것과 같은 것입니다.
a16z Eddy Lazzarin：
우회할 수 있습니다. 즉, 인터페이스는 적용하려는 보안 제약 조건을 캡처하지 않는 임의의 설명 집합일 뿐입니다.
a16z Noah：
그것이 바로 정의입니다.
a16z Eddy Lazzarin：
잘못된 수준에서 사물을 정의합니다. 궁금해.
Sui CTO Sam Blackshear ：
그러나 인터페이스를 넘어 어떻게 모듈화합니까? 인터페이스가 범죄라면 저는 아마도 하나일 것입니다. 복잡한 스마트 계약을 구축하는 가장 좋아하는 방법 중 하나는 다른 목적으로 다른 계약을 맺는 것이기 때문입니다. 그리고 특히 매우 복잡한 시스템에서는 모듈이 어떤 종류의 인터페이스를 따르는 모듈 기반 기반을 가지고 있으며 주 계약은 다른 모듈을 호출하는 방법을 알 수 있습니다. 이러한 모듈은 일반적으로 거버넌스를 통해 라이선스가 부여됩니다. Super Express의 플러그 앤 플레이 모듈성은 어떻게 얻습니까? 표준화된 인터페이스가 없습니까? 유산을 얻는 방법?
a16z Eddy Lazzarin：
이 모든 것들이 인터페이스와 관련이 있는 것처럼요?
Sui CTO Sam Blackshear ：
이것은 정확히 올바른 질문입니다. 그들은 이것에 대해 하루 종일 논쟁할 수 있지만 유용한 코드를 작성하게 만드는 것을 제공하는 것은 어떻습니까? 집밖으로 나가지 못한다면 범죄가 아닙니다. 그러나 우리가 하는 방식은 인터페이스와 상속이 유일한 방법이 아니라는 것입니다. 저는 구성에서 생각하는 경향이 있습니다. 동적 스케줄러 인터페이스가 필요하지 않은 몇 가지 구성 프리미티브를 제공합니다.
그 중 하나가 제네릭입니다. 우리는 당신이 가지고 있는 것과 매우 유사한 런타임 상속을 가지고 있습니다. Clr(Sui World Note: 공용 언어 런타임, 공용 언어 런타임) 매우 구체적인 예를 들어 보겠습니다. 그렇지 않으면 매우 빠르게 추상화됩니다.
분명히 근본적으로 중요한 암호화 표준인 ERC-20과 같은 것입니다. 귀하의 플랫폼, 귀하의 언어가 그렇게 할 수 없다면 그다지 유용하지 않을 것입니다. Move와 같은 언어에서는 t라는 유형의 포인트를 정의합니다. 여기서 t는 일반 유형 매개변수이고 코인에 대한 함수(예: 2포인트를 결합하는 함수)를 구현합니다. 이것은 모든 동전 유형에 적용됩니다. 누군가가 덮고 싶어하는 것이 아닙니다. 분할을 정의합니다.
누군가가 토큰의 동작을 사용자 정의하기를 원할 때 예를 들어 토큰의 경우 기능 패턴이라고 하는 것을 사용하십시오. 사용자 정의할 수 있는 항목 중 하나는 총 공급이 무엇인지 또는 더 근본적으로 정책은 무엇입니까? 다음과 같이 표현할 수 있습니다. t 유형의 포인트 구조체가 있고 달러, 파운드 또는 기타 통화 유형과 같은 t의 다른 인스턴스화가 있습니다. 사용자 지정하려는 항목에 대해 기능 수준에서 제공하여 토큰 기능을 만듭니다. 당신은 이것이 내 토큰의 유형 매개변수라고 말하고 자금 자금의 능력이라는 것을 줄 것입니다. 그런 다음 t의 재무 용량을 보유한 사람만 유형 t의 토큰을 생성하고 파괴할 수 있도록 하는 다른 논리가 있습니다. 이 재무부 용량을 다른 계약에 잠그고 총 공급량에 제한을 적용할 수 있습니다. 화요일에만 댓글을 달고 목요일에는 댓글을 달지 않는다고 말하십시오. 임의의 조합을 만들 수 있도록 제어 흐름을 반전시킵니다. 이것은 트릭의 예이지만 트릭은 거의 모든 곳에서 작동하며 동작이 특정 방식으로 작동하려면 하드 코딩해야 합니다. 나쁘게 들리지만 특정 두 가지 방법을 구현한 다음 허용하려는 기능에 대해 해당 기능을 정의합니다.
a16z Eddy Lazzarin：
기능이 전통적인 프로그래머처럼 보이는 인터페이스에 추가할 수 있는 제약이라고 생각하십니까?
Sui CTO Sam Blackshear ：
예, 이러한 인터페이스 패턴의 대부분은 매우 간단하게 변형될 수 있다고 생각합니다. 컴파일하기가 조금 더 어렵지만 이 인터페이스가 하려는 것과 동등한 기능 모델이라고 주장할 수 있습니다.
진행자 소날 촉시:
그건 그렇고, 샘, 이게 만족스럽나요? 동의하지 않아도 됩니다. 약간의 갈등은 좋은 것입니다.
Sui CTO Sam Blackshear ：
저는 괜찮습니다. 사전 정의된 동작이 있는 모듈에 공급할 수 있는 고유 기능이 있는 모듈이나 구조체를 가질 수 있다면 모듈이 그렇게 할 수 있는 것처럼 정확히 동일한 동작으로 끝날 수 있기 때문입니다. 모듈은 추상 구조체를 허용하고 해당 구조체는 해당 모듈에서 정의되며 해당 구조체 내부에는 고유 기능이 있습니다. 이것은 실제로 매우 잘 작동합니다. 정말 멋진 권한 스타일 레지스트리를 얻을 수 있기 때문입니다. DS-Off 레지스트리라고 하는 것과 같이 거의 자연스럽게 여기에서 나옵니다. 맞습니까?
a16z Noah：
첫 번째 레벨 제목
객체 지향 및 자산 지향 프로그래밍
a16z Eddy Lazzarin：
그래서 속담보다 조금 앞서 있을지도 모르지만 이러한 기능이 유형 시스템에 표시됩니까? 프로그램의 정적 분석 중 프로그램의 어떤 지점에서 이러한 기능이 표시됩니까? 기능이 있는 특정 인스턴스화 코드를 작성하는 경우 기능을 실행하기 전에 기능을 위반하고 있음을 조기에 감지할 수 있습니까?
a16z Noah：
예, 이러한 기능은 유형 시스템에 표시되며 프로그램의 정적 분석 단계 중에 표시됩니다. 기능이 있는 특정 인스턴스화된 유형에 대한 코드를 작성하면 가상 머신에서 실행하지 않고 기능을 위반하는지 아주 일찍 알아낼 수 있습니다.
Sui CTO Sam Blackshear ：
질문에 간단히 대답한 다음 몇 가지 배경 정보를 제공하겠습니다. 컴파일러에서 볼 수 있으며 유형 시스템의 일부입니다. 이것은 우리에게 매우 중요한 활용 포인트입니다. 그러나 저는 Move 이동성 시스템의 구조와 그것이 감사와 같은 수준의 기능과 어떻게 관련되는지에 대해 조금 이야기하고 싶습니다. 그것이 산만하지 않다면.
Move에는 구조체 유형이 있고 다른 언어의 구조체와 마찬가지로 필드, 기본 유형의 필드 또는 기타 구조체를 가질 수 있습니다. 더 흥미롭고 아마도 훨씬 더 다른 점은 이러한 구조에 능력이 있다는 것입니다. Rust에 익숙하다면 기능은 트랜잭션을 표시하는 것과 비슷합니다. 구조체에서 수행할 수 있는 기본 제공 작업을 선언합니다.
마찬가지로 중요한 것은 능력이 없으면 그런 일을 할 수 없다는 것입니다. 비교적 간단한 능력이 매우 중요합니다. 즉, 복사하는 능력입니다. 토큰 유형이나 비동질 토큰과 같은 것이 컴퓨터에 있는 경우 컴퓨터에서 약간의 비트일 뿐이지만 다른 사람이 마음대로 복사하는 것을 허용하고 싶지는 않습니다.
Move에서 복사할 수 있는 구조체를 선언하지 않으면 man copy에 해당하는 것을 사용할 수 없습니다.
따라서 정수 및 문자열과 같은 것에는 복사본이 있습니다. 그러나 유형이 복사되는 기능을 원하지 않는다면 제공하지 마십시오. 그리고 삭제 기능이라고 하는 폐기와 같은 다른 기능이 있습니다. 흥미로운 선형 유형 항목이 들어오는 곳입니다. 범위를 벗어나거나 덮어쓰는 것과 같이 무언가를 드롭하려는 경우 드롭 기능을 부여합니다. 그러나 드롭을 제공하지 않는 경우 제거하는 유일한 방법은 해당 유형의 모듈에서 기대하는 정책을 정의하는 것입니다.
CLR(공용 언어 런타임) 특정 예를 들어 토큰의 총 공급량을 유지하려는 경우 토큰에 드롭 기능을 부여하지 않습니다. 그러면 선언된 모듈에 정의된 소각 기능 외에는 제거할 방법이 없으며, 총 공급량을 업데이트합니다. 이것들은 당신이 사용할 수 있는 모든 트릭입니다. 또한 글로벌 스토리지에 저장할 수 있는지 여부와 같은 몇 가지 스토리지 관련 기능이 있는데, 이 질문과 관련성이 높지 않기 때문에 자세히 설명하지 않겠습니다. 그러나 기본적으로 기능은 감사 프로그램에 포함되어 있으며 감사 프로그램은 유형 시스템을 이해하고 유형 시스템을 사용하여 문제를 해결하는 방법을 알고 있습니다. 그런 것이 하나만 있다는 진술을 작성하면 감사인은 이를 사용하여 이 속성을 증명할 수 있습니다. 따라서 기능과 유형 시스템 보증은 밀접한 관련이 있습니다.
a16z Noah：
당신이 드롭을 언급했을 때, 나는 내가 가장 좋아하는 것에 대해 이야기하고 싶었습니다. 핫 포테이토 모드가 무엇인지 조금 말씀해 주시겠습니까? 이와 같은 다른 멋진 기능이 있다면 Move에서 나온 이상한 기능 중 제가 가장 좋아하는 것 중 하나입니다.
Sui CTO Sam Blackshear ：
이것은 참으로 이상한 일입니다. 이것은 역량과 매우 밀접한 관련이 있습니다. 일반적으로 프로그래밍 언어에서는 값이 소멸될 수 있는 시기를 제어할 수 없습니다. 아마도 값이 사라질 시기를 알려주는 소멸자가 있을 수 있습니다. 그러나 때로는 소멸자 보장이 약하거나 내 유형을 삭제할 수 없습니다와 같은 말을 할 수 없습니다. 이것은 이상한 제한처럼 들릴 수 있지만 실제로는 특히 동적 디스패치 없이는 매우 강력합니다.
뜨거운 감자의 예부터 시작하겠습니다. 그런 다음 플래시 론과 같은 항목으로 드릴다운할 수 있습니다. 이더리움에서 플래시 론을 한다면, 그것은 표준이고, 무시할 수 있습니다. 기본적으로 플래시 론 계약과 같은 콜백 기능을 노출하고, 저에게 돈을 주고, 제 콜백 기능을 제공한 다음 일종의 돈을 돌려받고, Move에서 , 당신이하는 방식은 누군가가 플래시 대출 계약에 가서 그들이 말하는 것입니다. “이봐, 나에게 53 달러를 줘.
뜨거운 감자 개체는 구조체이며 기능이 없습니다. 복사되지 않았으므로 복사할 수 없습니다. 글로벌 스토리지 기능이 없으며 계약에 넣는 것처럼 숨길 수 없습니다. 또한 드롭 능력이 없으므로 드롭할 수 없습니다. 따라서 그것을 없애는 유일한 방법은 그것을 플래시론 계약으로 되돌려주는 것입니다. 플래시 대출 계약 코드를 다시 전달하여 상환하도록 합니다. 그렇지 않으면 해당 프로그램이 런타임에 실패하고 유형 검사도 통과하지 못합니다. 따라서 이것은 프로그래머로서 값의 파괴를 제어할 수 있는 흥미로운 기능입니다. 이러한 객체가 파괴될 수 있는 시기에 대해 언제든지 임의의 불변성을 부과할 수 있습니다. 이는 API 호출 패턴이 매우 구체적인 것처럼 보입니다. 또 다른 매우 분명한 예는 다른 사람이 잠금 해제를 호출한 후 강제로 잠금을 호출하도록 하고 싶지만 그 사이에 원하는 작업을 수행하려는 경우 이 방법으로도 수행할 수 있습니다.
a16z Eddy Lazzarin：
핫 포테이토 패턴에 대해 처음 들었을 때, 특정 개체의 사용을 강제하기 위해 인체 공학적 목적으로만 유형 시스템을 활용하는 음소거 텍사스와 같은 잠금 장치의 흥미로운 사용에 대해 생각했습니다. 방법은 거의 비즈니스 논리 수준의 요구 사항. 매우 영리하다고 생각합니다. 매우 현대적입니다. 아직 전통적인 프로그래밍 언어에서도 흔하지 않은 프로그래밍 언어에서 인체 공학을 고품질로 사용하지만 스마트 계약 환경에서는 분명히 매우 유용합니다. 가치, 거기에 있기 때문에 관련될 수 있는 가치와 보안을 고려할 때 더 논리적인 요구 사항입니다.
Sui CTO Sam Blackshear ：
구체적인 예에 대해 이야기하기 전에 객체 시스템에 대한 개략적인 개요를 간략하게 말씀해 주시겠습니까? 객체란 무엇이며 소유자는 누구입니까? 객체는 다른 객체를 어떻게 소유하고 모듈은 어떻게 작동합니까?
a16z Noah：
네, 맞습니다. 이것은 Move 언어의 방언, 특히 Sui Move에 관한 것입니다. 이것의 기본은 우리가 사용하던 원래 Move 방언의 전역 저장 체계와 다른 전역 저장 구조입니다. 원래 Move 글로벌 스토리지 체계는 Ethereum에서 사용하는 기업 모델과 매우 유사합니다.
Sui Move에서 우리는 객체에 사물의 중심점을 두고 가능한 한 정밀하게 세분화된 액세스를 나타낼 수 있도록 높은 인센티브를 부여하고자 합니다. 이를 통해 트랜잭션을 보다 효율적으로 처리하고 지갑 사용자에게 어떤 트랜잭션이 수행되는지 알려주는 등 이 팟캐스트에서 자세히 다루지 않을 많은 작업을 수행할 수 있습니다.
따라서 Sui Move에서 전역 저장 구조는 개체 ID에서 개체 ID로의 매핑입니다. 그러면 개체는 키라는 기능이 있는 Move 구조체일 뿐입니다. 이봐, 내가 열쇠가 될 수 있어.라고 말하며 전역 개체 풀에 나타날 수 있습니다. 그런 다음 각 개체에는 전역적으로 고유한 ID가 있어야 합니다. 그런 다음 개체를 직접 입력으로 사용할 수 있는 모듈에 대한 진입점 함수를 작성할 수 있습니다. 트랜잭션을 작성하는 경우 이 WeRunTime에 개체 ID가 있습니다. 트랜잭션을 작성하는 경우 WeRunTime은 이러한 ID를 사용하여 ID를 개체로 확인하고 이를 함수에 삽입할 수 있습니다.
이 개체 지향 및 자산 지향 프로그래밍 경험은 훌륭합니다. 원래 Move 버전에서 했던 것보다 훨씬 간단합니다. 부모 및 자식 개체와 개체 계층도 언급했습니다. 이것은 매우 유용하지만 여전히 대규모 컬렉션과 같은 것을 나타낼 수 있기를 원합니다.
DNS와 같은 레지스트리를 구축하고 있으며 수백만 개의 항목을 갖고 싶다고 가정해 보겠습니다. 개체 크기 제한이 있으며 개체는 몇 메가바이트일 수 있지만 더 클 수는 없습니다. 그러나 DNS와 같은 것이 있으면 임의로 커야 합니다. 우리가 표현하는 방식은 부모-자식 개체 관계를 사용하는 것입니다. 기본적으로 개체를 이기종 맵으로 보는 방법이 있습니다. 그런 다음 동적 선택 필드로 키를 추가할 수 있습니다. 이것은 어떤 면에서 JavaScript와 매우 유사합니다. 우리는 이 객체에 지도가 있다고 말할 수 있습니다. 그런 다음 이 지도에 무언가를 넣을 수 있습니다. 또는 내가 이 개체를 정의할 때 10개의 필드가 있지만 실제로 나중에 새 필드를 추가하고 계약을 업그레이드하려고 한다고 말할 수 있습니다. 사실 후에 새 필드를 추가하고 싶습니다.
우리가 그것을 표현하는 방식은 이러한 상위 및 하위 개체 관계를 사용하는 것이며 각 하위 개체는 문자열이나 u 64 또는 기타 원하는 값과 같은 임의의 Move 값이 될 수 있는 키 값과 연결됩니다.
a16z Noah：
네, 부모 개체의 개념과 관련하여 제 생각에 정말 유레카의 순간이 된 것은 사실 몇 달 전 제가 시간을 내어 Sui Move를 파헤치고 개체가 하나만 있는 프로그램을 작성하다가 대부분의 Uniswap V2 스타일 카드 조합을 다시 구현합니다. 내가 한 작은 프로젝트는 물건의 물건을 갖는 것이 얼마나 소중한지를 깨닫게 해주었습니다. 이 프로젝트에는 자물쇠, 금, 빈 장벽의 세 가지 개체만 있습니다. 키 개체가 소유한 금을 만드는 것을 상상할 수 있는 매우 기본적인 모듈이 있습니다. 그러면 금을 빼낼 수 있는 유일한 방법은 자물쇠와 열쇠를 가져가서 분명히 자물쇠를 파괴하고 금을 주고 열쇠를 파괴하는 기능을 갖는 것입니다. 이 접근 방식은 매우 흥미롭습니다. 이러한 방식으로 개체 간의 관계를 설명하고 매우 세분화된 방식으로 권한을 설명할 수 있습니다.
Sui CTO Sam Blackshear ：
첫 번째 레벨 제목
Move와 Solidity의 보안 비교
진행자 소날 촉시:
그런데 Wired 매거진에 오기 전에 Xerox Park에서 6일을 보냈는데 객체지향 프로그래밍의 역사가 조금 생각났습니다. 방금 말씀하신 내용은 매우 흥미롭습니다. 왜냐하면 그들은 오늘날 많은 객체 지향 프레임워크의 초기 선구자인 Smalltalk를 발명했기 때문입니다. 어쨌든, 토론하고 싶은 다른 주제가 있습니까?
a16z Noah：
일반적인 질문이 있습니다만, 유형 시스템 때문에 Move를 사용했다면 처음에는 발생하지 않았을 것이라고 EVM 세계에서 발생하는 핵이나 그런 일이 정말로 있습니까?
Sui CTO Sam Blackshear ：
EVM 세계에서 우리는 이미 동적 할당과 재진입에 대해 언급했습니다. Move는 구조에 의한 재진입을 제거하고 모든 재진입 관련 문제가 사라지며 사람들이 잘하고 있다고 생각합니다. 이제는 반응과보기를 피한다고 생각합니다.
a16z Eddy Lazzarin：
그러나 Move가 이러한 문제를 불가능하게 만드는 이유를 설명할 수 있습니까?
Sui CTO Sam Blackshear ：
재입고 맞죠? 무슨 일이에요? 일부 코드를 작성하고 특정 함수를 호출합니다. 문제는 누군가 처음에 예상하지 못한 기능 구현을 제공한다는 것입니다. 이것이 작동하려면 함수 호출이 동적이어야 합니다. 기본적으로 호출자(아마도 공격자)가 제공하는 함수 포인터인 코드를 호출해야 합니다. 동적 함수 호출이 없고 항상 함수 호출의 대상을 알고 있다면 이것은 호출하는 것과 마찬가지로 전혀 발생할 수 없습니다. 코드가 무엇을 하는지는 알 수 없지만 , 테스트할 수 있고 확인할 수 있습니다. 모든 것이 있습니다. 따라서 기본적으로 정적 함수 호출이기 때문에 모듈이 예상과 다르게 동작하도록 하는 코드를 다른 사람이 제공하는 것은 불가능합니다. 너무 멋지다.
a16z Eddy Lazzarin：
따라서 이것은 Solidity 개발에서 영원한 문제였던 재진입 공격을 제거합니다.
Sui CTO Sam Blackshear ：
예, Move는 기본적으로 스마트 계약 프로그래밍에서 누락된 권한 확인 문제를 제거한다고 생각합니다. 모든 계정을 명시적으로 전달해야 하는 코드를 작성하고 이 작업을 수행할 권한이 있는지 물어봐야 하는 경우가 있습니다. 간단한 코드를 작성했지만 보낸 사람이 누군가인지 또는 그 사람이 액세스할 수 있는지 확인하는 것을 잊었습니다. 이러한 문제는 꽤 자주 발생한다고 생각합니다.
따라서 Move에서 개체 소유권 정보는 실제로 개체 메타데이터에 저장됩니다. 이것은 프로그래머가 제어할 수 있는 것이 아닙니다.
이러한 객체를 보면 나는 이 주소가 소유하고 있습니다, 나는 이 다른 객체가 소유하고 있습니다, 나는 공유 객체입니다 또는 나는 불변 객체입니다라고 말합니다. . 프로그래머는 이 Sui 객체에 전달된 코드를 실행하기 전에 런타임이 확인하기 때문에 소유자를 확인하는 것을 잊을 수 없습니다. Runtime은 나는 이 교환을 보고, 그들이 사용하고자 하는 모든 객체를 봅니다. 나는 그들이 실제로 이러한 객체를 소유하고 있는지, 또는 중간에서 소유하는 객체를 가지고 있는지 확인하여 사용 권한을 얻습니다.
우리가 프로그래머에게 요청하는 많은 권한 검사는 We Run Time에서 발생하며 이러한 검사는 잊을 수 없습니다. 가장 보호하기 어려운 것은 프로그래머가 말하지 않은 사양이기 때문에 이것이 매우 중요하다고 생각합니다. 어떤 규범이 중요한지 알아낼 사람이 항상 필요하기 때문에 이러한 규범은 잊기 쉽고 정적 분석이나 다른 방법을 사용하여 파악하기 어렵습니다.
진행자 소날 촉시:
그건 그렇고, 사람들이 장기 또는 단기 계획 측면에서 이런 방식으로 더 많이 협력할 때 엔터프라이즈 규모에서 일어나는 일이 매우 흥미로울 것이라고 생각합니다. A 회사뿐만 아니라 때때로 사람들이 협력하기 때문입니다. 하지만 제 말은, 지금 옛날 방식을 생각해 보면 개발자와 이러한 모든 모범 사례가 있습니다.
