ผู้แต่งต้นฉบับ: Sui World DAO

ปีที่แล้ว a16z และสถาบันอื่น ๆ ส่งเสริมเครือข่ายสาธารณะ Move ที่แสดงโดย Sui อย่างมาก ซึ่งทำให้ภาษา Move กลับมาจากซากปรักหักพังของ Meta Diem ในเวลาเดียวกัน นับตั้งแต่วินาทีที่ Sui Move ปรากฏตัว เสียงที่ไม่เอื้ออำนวยก็มีอยู่เสมอ:

หากเพียงเพราะภาษา Move อาจดีกว่า Solidity หรือภาษาสำหรับการพัฒนาอื่นๆ เราจำเป็นต้องมีภาษาสัญญาอัจฉริยะใหม่หรือไม่ และเรายินดีที่จะสร้างเลเยอร์ 1 ใหม่ตั้งแต่เริ่มต้นหรือไม่

เมื่อเร็ว ๆ นี้ ทีมงาน a16z Crypto และ Sam Blackshear ผู้ร่วมก่อตั้งและ CTO ของ MystenLabs และบิดาแห่งภาษา Move ได้จัดการสนทนาพอดแคสต์ในหัวข้อ "Programming Languages ​​& Crypto" โดยอภิปรายว่าทำไม Move ถึงเป็นทิศทางที่สำคัญ สำหรับสัญญาอัจฉริยะในอนาคต

ในพอดคาสต์นี้ a16z Crypto และ Sam Blackshear หารือเกี่ยวกับแนวคิดการออกแบบ การเขียนโปรแกรมเชิงวัตถุและสินทรัพย์ ความปลอดภัย และการตรวจสอบร่วมกันอย่างเป็นทางการ การกำกับดูแลและเครื่องมือชุมชน การปรับตัวข้ามแพลตฟอร์ม และหัวข้ออื่นๆ

เนื้อหาการแบ่งปันหลักประกอบด้วย:

1. ภาษาโปรแกรมและประวัติสัญญาอัจฉริยะ

ตั้งแต่การเขียนโปรแกรมแบบดั้งเดิมไปจนถึงการเขียนโปรแกรมสัญญาอัจฉริยะไปจนถึงการเขียนโปรแกรม Move Move เป็นวิธีแรกสุดในการออกแบบภาษาเพื่อรองรับปัญหาต่างๆ เช่น ระบบการพิมพ์ การพิมพ์แบบคงที่ และการตรวจสอบเวลาคอมไพล์

2. นวัตกรรมของ Move smart contract

EVM เกินรายละเอียดการใช้งานของแพลตฟอร์มซึ่งออกแบบมาสำหรับ Ethereum นักพัฒนาซอฟต์แวร์ต้องรับช่วงต่อการตัดสินใจออกแบบหลายอย่างของ Ethereum รวมถึงข้อบกพร่องบางอย่างที่ทำให้ Ethereum ปรับขนาดได้ยาก Move ได้รับการออกแบบโดยไม่เพิ่มสิ่งใดๆ ที่เกี่ยวข้องกับ blockchain ให้กับภาษาหลัก นวัตกรรมในระดับภาษาซอร์สโค้ดจะค่อนข้างสำคัญ และในที่สุดสิ่งที่ Move จะสามารถให้ได้คือตัวตรวจสอบโค้ดและการป้องกันระดับ VM จากการโจมตีโดยโปรแกรมเมอร์คนอื่นๆ

3. แนวคิดการออกแบบของ Sui Move

Move เป็นภาษา bytecode ที่เรียกใช้งานได้ซึ่งใช้ในการดำเนินการธุรกรรมของผู้ใช้และสัญญาอัจฉริยะ ใน Sui Move ตัวตรวจสอบสามารถขนานกันได้อย่างมีประสิทธิภาพมากขึ้น ซึ่งทำให้การจัดเก็บและการดำเนินการง่ายขึ้นโดยไม่ต้องเข้ารหัสสิ่งเหล่านี้ในระดับโปรโตคอล และให้ผู้ใช้และโปรแกรมเมอร์พิจารณา

4. ความปลอดภัย

ในโลกของสัญญาอัจฉริยะ เราอยู่ในสภาวะจำกัด เราเขียนโค้ดจำนวนน้อยมาก และต้องไม่มีที่ติ และความปลอดภัยต้องมีความสำคัญสูงสุด การรักษาความปลอดภัยของ Move นั้นเกี่ยวกับการป้องกันไม่ให้โปรแกรมเมอร์ก้าวขึ้นมาเอง แต่ยังให้สิ่งดั้งเดิมที่ถูกต้องหากเป็นไปได้ เพื่อให้พวกเขาสามารถป้องกันการโจมตีได้

5. การวางแนววัตถุและสินทรัพย์

Move ได้รับการออกแบบให้เป็นภาษาการเขียนโปรแกรมสัญญาอัจฉริยะเชิงวัตถุและสินทรัพย์ เนื่องจากภาษาโปรแกรมเชิงวัตถุ Web2 ส่วนใหญ่เป็นเช่นนั้น ในซุยมูฟ การวางจุดศูนย์กลางของสิ่งต่างๆ ไว้บนวัตถุ มีแรงจูงใจสูงที่จะสามารถแสดงการเข้าถึงแบบละเอียดได้อย่างแม่นยำที่สุดเท่าที่จะเป็นไปได้ โครงสร้างของที่เก็บข้อมูลส่วนกลางของ Sui Move เป็นการแมปจาก ID อ็อบเจ็กต์ไปยัง ID อ็อบเจ็กต์

6. การเปรียบเทียบความปลอดภัย

Move กำจัดการกลับเข้าใช้ใหม่และการตรวจสอบสิทธิ์ที่ขาดหายไปในการเขียนโปรแกรมสัญญาอัจฉริยะโดยการก่อสร้าง ใน Move ข้อมูลความเป็นเจ้าของออบเจกต์จะถูกจัดเก็บไว้ในข้อมูลเมตาของออบเจกต์ ซึ่งไม่ใช่สิ่งที่โปรแกรมเมอร์สามารถควบคุมได้ Move Prover ได้รับการออกแบบมาเพื่อป้องกันข้อผิดพลาดทางภาษาในการเขียนสัญญาอัจฉริยะ ซึ่งสามารถป้องกันไม่ให้นักพัฒนาทำผิดพลาดพื้นฐานมากมาย

7. การกำกับดูแลภาษาสัญญาอัจฉริยะ

ในขั้นต้น Move ได้รับการพัฒนาที่ Facebook โดยไม่มีการกำกับดูแลที่แท้จริง เราขยายภาษาอย่างระมัดระวัง ความเรียบง่ายเป็นสิ่งสำคัญ แต่เราจะขยายอย่างจริงจัง Sam Blackshear มีความปรารถนาที่เฉพาะเจาะจงมาก เช่น Move ได้รับการออกแบบให้เป็นภาษาข้ามแพลตฟอร์ม ซึ่งฟังก์ชันพื้นฐานบางอย่างของ chain EDM ควรยังคงใช้งานได้ และครอบคลุมทั้งผู้เชี่ยวชาญด้านการพัฒนาสัญญาอัจฉริยะและผู้มาใหม่ของ Web2 โดยมีความยืดหยุ่นสูง .

8. ข้อเสนอแนะการเรียนรู้สำหรับนักพัฒนา

การอ่านโค้ดจำนวนมากเป็นวิธีที่ดีที่สุดในการเรียนรู้เกี่ยวกับภาษา เต็มใจแบ่งปันและเจาะลึกมากขึ้น และค้นหาผู้ที่สนุกกับการแบ่งปันรหัสของคุณกับผู้อื่นและสร้างชุมชนโอเพ่นซอร์สร่วมกัน เครื่องมือใด ๆ ที่สามารถทำให้งานของคุณง่ายขึ้น คุณควรเรียนรู้วิธีการทำงาน

ชื่อระดับแรก

บทนำของโฮสต์ Sonal Chokshi

ยินดีต้อนรับสู่ Web 3.0 การแสดงจากทีมงานที่ a16z Crypto เกี่ยวกับการสร้างอินเทอร์เน็ตรุ่นต่อไป ฉันเป็นเจ้าภาพของคุณ Sonal Chokshi

รายการนี้ออกแบบมาเพื่อช่วยเหลือทุกคน ไม่ว่าจะเป็นนักพัฒนา ผู้สร้าง สถาปนิก ผู้นำธุรกิจ หรือผู้กำหนดนโยบายที่ต้องการทำความเข้าใจและเจาะลึกในเรื่องที่เกี่ยวข้องกับการเข้ารหัสและ Web 3.0 ขณะนี้เรากำลังเริ่มฤดูกาลใหม่ของรายการ ตอนของวันนี้มุ่งเน้นไปที่ภาษาการเขียนโปรแกรมและสกุลเงินดิจิทัล ทั้งสำหรับโปรแกรมเมอร์สัญญาอัจฉริยะที่มีอยู่และสำหรับนักพัฒนารายอื่น ๆ ที่ต้องการเจาะเข้าไปในช่องว่าง นอกจากนี้ยังเป็นตัวเลือกที่ดีสำหรับผู้ที่อยากรู้เกี่ยวกับวิวัฒนาการและการเกิดขึ้นของภาษาโปรแกรม

แขกรับเชิญพิเศษของเราในวันนี้คือSam Blackshear ผู้ร่วมก่อตั้งและ CTO ของ MystenLabsบริษัทกำลังวางรากฐานสำหรับอนาคตแบบกระจายอำนาจของ Web 3.0 แซมมีประวัติอาวุโสด้านภาษาโปรแกรมตั้งแต่ปริญญาเอกไปจนถึงการทำงานที่ Facebook ไปจนถึงการสร้างและเป็นผู้เขียน Move และภาษาโปรแกรมแบบโอเพ่นซอร์สสำหรับการสร้างสัญญาอัจฉริยะ เราจะพูดถึงหัวข้อนี้มากขึ้น

ตลอดทั้งรายการ นอกจากนี้ เรายังเชิญชวนNoah วิศวกรวิจัยสัญญาอัจฉริยะที่ a16z Cryptoเขาและหุ้นส่วนอีกคนเพิ่งพัฒนาไคลเอนต์น้ำหนักเบาสำหรับ Ethereum ชื่อ Helios และชนะการเพิ่มประสิทธิภาพก๊าซที่ท้าทาย

เรายังเชิญEddy Lazzarin หัวหน้าวิศวกรของ a16z Cryptoชื่อระดับแรก

ประวัติของการเขียนโปรแกรมและสัญญาอัจฉริยะ

โฮสต์ Sonal Chokshi:

เราจะเริ่มต้นด้วยประวัติของการเขียนโปรแกรมแบบดั้งเดิมโดยที่ Noah พูดก่อน ตามด้วย Sam Blackshear และ Eddy

a16z Crypto Noah：

เราต้องการเข้าใจว่าประวัติการเขียนโปรแกรมส่งผลต่อประวัติการเขียนโปรแกรมสัญญาอัจฉริยะอย่างไร เพราะฉันคิดว่ามีสามสิ่ง ได้แก่ การเขียนโปรแกรมแบบดั้งเดิม การเขียนโปรแกรมสัญญาอัจฉริยะ และภาษา Move ทั้งสามสิ่งมีประวัติศาสตร์ของตัวเองใช่ไหม?

Sui CTO Sam Blackshear：

ใช่ ฉันชอบเฟรมเวิร์กนี้ เป็นความจริงที่ผู้คนใช้ภาษาเพื่อออกแบบไวยากรณ์หรือทำให้ผู้คนมีความสุข แต่มันมากกว่านั้น ดังนั้นฉันจึงชอบโครงร่างภาพขนาดใหญ่นี้มาก

a16z Crypto Eddy Lazzarin：

บนพื้นฐานนี้ การเขียนโปรแกรมแบบดั้งเดิมมีแนวโน้มที่หลากหลายในช่วงสองหรือสามทศวรรษที่ผ่านมา ภาษาการเขียนโปรแกรมแบบดั้งเดิมมีการเปลี่ยนแปลง โดยมีประเด็นร้อนเกิดขึ้นเรื่อยๆ เป็นเวลานานแล้วที่ภาษาโปรแกรมไดนามิกที่มีการตรวจสอบประเภทหลวมๆ เป็นที่นิยมอย่างมาก เชื่อกันโดยทั่วไปว่าการกระโดดลงไป ลืมประเภท ลืมรายละเอียดทางเทคนิคทั้งหมด และเพียงแค่เขียนโค้ดเป็นวิธีการที่ถูกต้องตามหลักสรีรศาสตร์มากกว่า

Sui CTO Sam Blackshear：

แต่เมื่อเร็ว ๆ นี้ ผู้คนเริ่มคิดอย่างลึกซึ้งมากขึ้นเกี่ยวกับสิ่งต่าง ๆ เช่น ระบบการพิมพ์ การพิมพ์แบบคงที่ และการตรวจสอบเวลาคอมไพล์ เพื่อให้ทราบรายละเอียดมากที่สุดเท่าที่จะเป็นไปได้เกี่ยวกับโปรแกรมก่อนที่มันจะรัน แนวโน้มเหล่านี้มีการเปลี่ยนแปลงตลอดเวลา อย่างไรก็ตาม สำหรับการเขียนโปรแกรมสัญญาอัจฉริยะ เนื่องจากยังใหม่มาก เราจึงไม่เห็นประวัติประเภทนี้ในการเขียนโปรแกรมสัญญาอัจฉริยะ ซึ่งแตกต่างอย่างมาก

ฉันคิดว่าภาษา Move เป็นหลักฐานแรกสุดที่เราเห็นว่าภาษาสามารถออกแบบเพื่อรองรับสิ่งนี้ได้อย่างไร (ปัญหาต่างๆ เช่น ระบบประเภท การพิมพ์แบบคงที่ และการตรวจสอบเวลาคอมไพล์) ฉันอยากรู้ว่าการเปลี่ยนแปลงใดที่เราคาดว่าจะเห็นในการเขียนโปรแกรมสัญญาอัจฉริยะ เช่น การพิมพ์แบบสแตติกและไดนามิก หัวข้อเหล่านี้อาจยังไม่เกิดขึ้นเนื่องจากตอนนี้มีเพียงภาษาเดียวคือ Solidity

โฮสต์ Sonal Chokshi:

ดังนั้นสิ่งนี้เกี่ยวข้องกับการย้ายไปยังการเขียนโปรแกรมสัญญาอัจฉริยะอย่างไร แซมอีกครั้งโปรดตอบ

Sui CTO Sam Blackshear：

ในพื้นที่สัญญาอัจฉริยะนี้ มีแนวโน้มที่แตกต่างกับ EVM ในฐานะผู้เข้าใช้ภาษาสัญญาอัจฉริยะรายแรก ผู้คนไม่รู้ว่าพวกเขาต้องการทำอะไรกับสัญญาอัจฉริยะ? วิธีที่เราเขียนหรือประเภทใด ๆ เหล่านี้ ดังนั้นฉันคิดว่าความยืดหยุ่นมีความสำคัญมากกว่าในการพยายามทำความเข้าใจประเภทของผู้เชี่ยวชาญที่ต้องค้นหาการใช้งาน ฉันรู้สึกว่าตอนนี้เรารู้แล้ว หรืออย่างน้อยเราก็รู้อะไรบางอย่างเกี่ยวกับกลุ่มอาคาร

แนวโน้มของสัญญาอัจฉริยะนั้นมีความเฉพาะเจาะจงอย่างมาก คุณกำหนดเทมเพลตสำหรับสินทรัพย์ กำหนดนโยบายสำหรับการโอนสินทรัพย์ ตรวจสอบการควบคุมการเข้าถึงและการอนุญาต

นั่นคือพื้นฐาน คุณไม่ต้องเขียนคอมไพเลอร์หรือระบบปฏิบัติการหรือสิ่งอื่นใดในภาษาสัญญาอัจฉริยะ ดังนั้น ภาษาเหล่านี้จึงดีมาก ได้เปรียบเหนือภาษาโปรแกรมทั่วไป

ฉันคิดว่าผู้คนดูถูกดูแคลนว่า EVM ถือเป็นหนึ่งในหน่วยการสร้างพื้นฐานสำหรับการเขียนโปรแกรม Ethereum แม้ว่ามาตรฐาน ERC-20 จะเกิดขึ้นมานานหลังจากที่ EVM สามารถตั้งโปรแกรมได้ ฉันไม่เห็นหลักฐานชัดเจนว่าสิ่งพื้นฐานที่สุดมีความชัดเจนก่อนหน้านั้น

คุณพูดถูก ตอนนี้คุณสามารถยอมรับประเภทได้แล้ว ฉันคิดว่าประเภทและการข้ามสิ่งเหล่านี้สามารถแบกรับภาระหนี้ทางเทคนิคได้จำนวนหนึ่ง หากสเกลมีขนาดเล็ก คุณเพียงแค่ต้องการเคลื่อนไหวอย่างรวดเร็ว และโค้ดสามารถถูกโยนทิ้งไปได้ ดังนั้นหนี้ทางเทคนิคประเภทนี้จึงเป็นที่ยอมรับอย่างสมบูรณ์ แต่เป็นเรื่องน่าสนใจที่คุณอธิบายในแง่ของขนาดของบริษัทหรือสตาร์ทอัพ บริษัทเล็กๆ ที่เติบโตอย่างรวดเร็ว ซึ่งทุกคนเข้าใจโค้ดเบสทั้งหมด และหนี้ทางเทคนิคประเภทนี้พอรับได้

แต่เมื่อมันมีขนาดใหญ่มาก มีคนมากมายที่เปลี่ยนโค้ดโดยที่ไม่รู้ถึงการแตกสาขาของวัตถุและระบบใหม่ที่พวกเขากำลังสร้าง การใส่สิ่งนี้ลงในระบบประเภททำให้คุณสามารถเขียนโค้ดในลักษณะที่ไม่กำกวมและตรงไปตรงมา และชนสิ่งกีดขวางบนถนน แทนที่จะสร้างรั้วกั้นกระจกโดยไม่ตั้งใจซึ่งจะมีใครมาชนในภายหลัง

ตัวอย่างเช่น ตามที่พวกคุณพูดถึง ความสามารถในการป้องกันการทำซ้ำ ความสามารถในการกำหนดปริมาณสูงสุดของสินทรัพย์ ข้อจำกัดเหล่านี้มีความสำคัญมากและจำเป็นต้องรักษาไว้โดยไม่คำนึงว่าโครงการจะมีขนาดเท่าใด เป็นข้อจำกัดที่สำคัญมากในการรักษาสุขภาพและความปลอดภัยของโครงการของคุณการรู้ขอบเขตเหล่านี้หมายความว่าตอนนี้คุณสามารถสร้างภาษาโปรแกรมที่อนุญาตให้คุณบังคับใช้ได้ นั่นเป็นวิธีที่ฉันเห็นภาษา Move

ขณะที่เราเรียนรู้ประเภทของข้อจำกัดที่จำเป็นในการทำสิ่งที่ถูกต้อง ตอนนี้เรามีความสามารถที่จะรวมข้อจำกัดเหล่านี้ไว้ในภาษาด้วย ฉันคิดว่ามันค่อนข้างคล้ายกับประเภทอย่างที่คุณพูด

คุณกล่าวว่าประเภทมีความสำคัญมากต่อความมีเหตุผลและความปลอดภัยของโปรแกรมพวกคุณบอกว่าการพิมพ์แบบไดนามิกอาจใช้ได้ดีสำหรับโครงการขนาดเล็ก แต่เมื่อโครงการเติบโตขึ้น ควรใช้การพิมพ์แบบคงที่ ฉันไม่เห็นด้วย ฉันคิดว่าการพิมพ์แบบคงที่ทั้งหมดอาจเหมาะสมกว่า นี่อาจเป็นนวนิยาย มันสำหรับโปรแกรมเมอร์สติ สิ่งที่น่ากลัวที่สุดที่ฉันเคยเห็นคือเมื่อฉันกดทางลัด "control k" มันจะบอกฉันว่าลายเซ็นของฟังก์ชันคืออะไร สิ่งนี้ทำให้ฉันกลัวเมื่อฉันเขียน Python ฉันดูที่ลายเซ็นของฟังก์ชันและเห็นเฉพาะชื่อของพารามิเตอร์เท่านั้น ฉันเป็นแบบ คุณต้องการให้ฉันทำอะไร

a16z Noah：

ฉันไม่อยากเชื่อเลยว่าผู้คนจะยอมรับแนวคิดในการเขียนโค้ดและไม่เคยมองมันอีกเลย

a16z Eddy Lazzarin：

พวกเขายอมรับสมมติฐานเริ่มต้นที่สามารถคำนึงถึงความต้องการของระบบได้

a16z Noah：

แต่ถึงแม้จะมีโปรแกรม 100 บรรทัด ฉันก็ไม่คิดว่าจะสามารถตั้งค่าเริ่มต้นได้

Sam Blackshear ：

มันใช้งานได้ แต่ก็ไม่สมบูรณ์แบบ

a16z Eddy Lazzarin：

ฉันคิดว่าคุณถูก. และฉันคิดว่าความคิดนั้นมีการพัฒนา ก่อนหน้านี้ ระบบประเภทถูกใช้เพื่อปกป้องโปรแกรมเมอร์จากเพื่อนร่วมงานมันมีประโยชน์เมื่อการเริ่มต้นของคุณมีขนาดใหญ่เกินไป แต่ตอนนี้มันเหมือนกับการปกป้องตัวเองมากกว่า

ในบริบทของสัญญาอัจฉริยะ มันปกป้องฉันจากผู้โจมตี นี่คือข้อแตกต่างที่แท้จริง เนื่องจากในโปรแกรมปกติ คุณจะไม่ต้องปรับใช้โปรแกรมเมื่อผู้โจมตีถูกผูกมัดโดยระบบประเภท ผู้โจมตีสามารถเขียนรหัสเครื่องในภาษาอื่นๆ คุณเพียงแค่ต้องป้องกันไฟร์วอลล์ของคุณเอง แต่ที่นี่ฉันเขียนวัตถุที่พิมพ์อย่างสวยงามซึ่งจะไหลเข้าสู่รหัสของผู้โจมตีและทำให้มันเหมือนเดิม ระบบประเภทต้องทำให้ฉันปลอดภัย

อย่างที่คุณพูด มันเป็นเครื่องมือที่ยอดเยี่ยมที่นำเสนอข้อกำหนดต่างๆ ให้กับคุณ และคุณต้องบังคับใช้ข้อกำหนดเหล่านี้ เช่น การป้องกันการคัดลอก นั่นไม่ใช่สิ่งที่คุณต้องคิดในระบบประเภทปกติ หรือป้องกันการลบหรือตรวจสอบให้แน่ใจว่าคุณใช้หรือทำลายค่าด้วยวิธีใดวิธีหนึ่ง ทั้งหมดนี้เป็นเพราะเรากำลังทำงานกับสัญญาอัจฉริยะและพยายามสร้างระบบประเภทที่มีความหมายสำหรับกรณีการใช้งานเหล่านี้ ดังนั้นเราจะลงเอยด้วยการเพิ่มสิ่งเหล่านี้เพื่อย้าย และอาจรวมถึงภาษาสัญญาอัจฉริยะในอนาคตด้วย

โฮสต์ Sonal Chokshi:

อันที่จริง เรามาพูดถึงความแตกต่างอื่นๆ ระหว่างการเขียนโปรแกรมแบบดั้งเดิมกับการเขียนโปรแกรมสัญญาอัจฉริยะกันสักหน่อยดีกว่า แต่ก่อนที่เราจะไปมากกว่านี้ พวกคุณสามารถให้ภาพรวมโดยย่อของภาษาที่มีให้สำหรับโปรแกรมเมอร์สัญญาอัจฉริยะได้หรือไม่? ฉันคิดว่าเราต้องดูภาพรวมเพราะฉันต้องการดูสภาพที่เป็นอยู่ เช่น Solidity, Viper เป็นต้น การรู้ว่าเนื้อหาใดช่วยให้เราเริ่มต้นได้เร็วขึ้น

Sui CTO Sam Blackshear ：

ใช่ ฉันเดาว่าพื้นฐานคือถ้าคุณต้องการเขียนสัญญาที่ชาญฉลาด คุณจะต้องใช้ความแข็งแกร่งเกือบตลอดเวลา เว้นแต่คุณจะอยู่ในระบบนิเวศที่เล็กกว่าหลายแห่ง

หากคุณอยู่ในระบบนิเวศของ Polkadot คุณจะใช้หมึก (Sui World Note: ink! เป็นภาษาสัญญาอัจฉริยะที่พัฒนาโดย Parity สำหรับการเขียนสัญญาอัจฉริยะใน Rust และคอมไพล์เป็นโค้ด Wasm) ซึ่งเป็นภาษาโปรแกรมที่มีอยู่แล้ว หากคุณอยู่ในระบบนิเวศของ StarkNet คุณใช้ไคโร (Sui World Note: Cairo เป็นหนึ่งในภาษาโปรแกรมสำหรับระบบพิสูจน์ STARK)

แต่ส่วนใหญ่แล้ว ถ้าฉันจะให้คำแนะนำเกี่ยวกับวิธีการเขียนสัญญาอัจฉริยะ ฉันขอแนะนำให้คุณเรียนรู้ Solidity แล้วจึงเรียนรู้ EVM คุณอาจต้องการใช้ Viper ข้อเสียเพียงอย่างเดียวคือ Viper นั้นใหม่กว่าและอาจมีแนวโน้มที่จะเกิดข้อบกพร่องได้ง่ายกว่า ฉันจำได้เมื่อไม่กี่ปีที่ผ่านมา เมื่อตรวจสอบสัญญาการฝากเงิน พวกเขาพบบั๊กจำนวนมากในคอมไพเลอร์ของ Viper คนที่พบข้อบกพร่องเหล่านี้กำลังทำงานที่ 16z เขาคือ Day June เขาเป็นผู้เชี่ยวชาญด้านการยืนยันอย่างเป็นทางการ

เนื่องจาก Day June เป็นผู้เชี่ยวชาญด้านการตรวจสอบอย่างเป็นทางการ ตอนนี้เขาจึงทำงานที่ a16z และความจริงก็คือ คุณต้องเรียนรู้เนื้อหาบางอย่าง คุณต้องเรียนรู้ภาษา

คุณยังต้องเข้าใจ EVM อย่างลึกซึ้ง และหากคุณต้องการเป็นวิศวกรสัญญาอัจฉริยะที่ดีจริงๆ คุณต้องเข้าใจ EVM ในระดับที่ไร้สาระเพื่อให้คุณสามารถบอกต้นทุนก๊าซของแต่ละการดำเนินการได้ พวกเขาสามารถบอกรหัสที่เกี่ยวข้องกับต้นทุนก๊าซได้ นี่คือโลกที่เราอาศัยอยู่ในขณะนี้

a16z Eddy Lazzarin：

บางทีมันอาจจะคุ้มค่าที่จะกล่าวว่า ในฐานะวิศวกรซอฟต์แวร์ คุณสามารถเรียนรู้เกี่ยวกับเครื่องที่คุณกำลังรันโค้ดของคุณได้ตลอดเวลา มีสิ่งที่ต้องรู้มากมายเกี่ยวกับสภาพแวดล้อมการเขียนโปรแกรม แต่ในการเขียนโปรแกรมสัญญาอัจฉริยะ สภาพแวดล้อมมีความสมบูรณ์และซับซ้อนมาก มีบริบทมากมายให้เข้าใจ เกือบจะเป็นอิสระจากตัวภาษาเอง นั่นคือสิ่งที่เกิดขึ้นรอบๆ ตัวคุณ วัตถุต่างๆ รอบตัวคุณ รหัสต่างๆ ถูกเรียกอย่างไร นี่เป็นสิ่งที่แปลกมาก

โฮสต์ Sonal Chokshi:

จริงหรือไม่ที่คนที่อยู่ใกล้ที่สุดในการเรียนรู้ Solidity คือคนที่รู้จัก JavaScript?

Sui CTO Sam Blackshear ：

มีคนบอกว่ามันคือ JavaScript เพราะมันใช้คีย์เวิร์ด "function" เหมือนกับที่ JavaScript ทำ แต่น่าเสียดายที่พวกเขาไม่ได้คล้ายกันมาก

a16z Eddy Lazzarin：

จากมุมมองทางไวยากรณ์ Solidity สืบทอดคุณสมบัติ JavaScript มากมาย หากคุณกำลังหรี่ตาหรืออารมณ์ไม่ดี อาจรู้สึกคล้ายกัน แต่จริงๆ แล้วแตกต่างกันมาก สภาพแวดล้อมของเครื่องเสมือนมีความแตกต่างกันอย่างมาก ดังนั้นจึงมีสิ่งที่เหมือนกันน้อยมาก

โฮสต์ Sonal Chokshi:

มีภาษาโปรแกรมที่คล้ายกันหรือไม่?

a16z Noah：

ใช่ ฉันไม่คิดว่าจะมีภาษาโปรแกรมที่คล้ายกันโดยตรง หากคุณคุ้นเคยกับ Was (Sui World Note: WebAssembly Studio เครื่องมือออนไลน์สำหรับการคอมไพล์โค้ด C/C++ และ Rust ในรูปแบบ WASM ) และพยายามเขียนโค้ดในสภาพแวดล้อมที่ต้องการการแยกระดับสูง (เช่น Surplus ) นี่อาจเป็นสิ่งที่ใกล้เคียงที่สุดที่โค้ดเหล่านี้จะดำเนินการโดยอิสระ แต่ต้องมีการสื่อสารในระดับหนึ่ง แต่ก็ยังไม่ได้คล้ายกันมากนัก วิธีคิดก็แตกต่างไปจากเดิมอย่างสิ้นเชิง และความคล้ายคลึงเพียงผิวเผินอาจเป็นอันตรายได้

a16z Eddy Lazzarin：

บางทีความเกี่ยวข้องอาจเป็นความผิดพลาดครั้งใหญ่ในประวัติศาสตร์ของภาษาโปรแกรมฉันไม่รู้ว่ามีประวัติที่น่ารังเกียจเกี่ยวกับการเดินผิดทางเมื่อพูดถึงบล็อคเชนหรือไม่ เราได้ไปตามเส้นทางที่น่ากลัวบ้างไหม?

โฮสต์ Sonal Chokshi:

นั่นเป็นคำถามที่ดี

Sui CTO Sam Blackshear ：

นั่นเป็นคำถามที่ดี ในปี 1977 ภาษา C ได้รับการเผยแพร่ ซึ่งเป็นปีที่ Standard ML เปิดตัวด้วย Standard ML มีอิทธิพลอย่างมาก ตอนนี้ภาษา OCaml และภาษา Rust ได้รับอิทธิพลอย่างมากจากมัน และภาษา Move ก็ได้รับผลกระทบเช่นกัน แต่แนวคิดเหล่านี้มีมานานแล้ว ฉันคิดว่าผู้คนจำนวนมากกำลังคิดถึงอนาคตทางเลือก ซึ่งแทนที่จะใช้ C เป็นหลัก แนวคิดของ Standard ML ได้รับการยอมรับอย่างกว้างขวาง เช่น การพิมพ์ที่แข็งแรง ความปลอดภัยในตัว

โฮสต์ Sonal Chokshi:

แล้วแนวโน้มของเทคโนโลยีคอมพิวเตอร์นี้เป็นอย่างไร? ฉันไม่ได้บอกว่ามันเป็นความผิดพลาด แต่ฉันคิดว่าภาษาอย่าง 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 เรียกว่าข้อผิดพลาดพันล้านดอลลาร์ของการอ้างอิงโหนด แม้ว่าเขาอาจจะพูดเกินจริงในเวลานั้น แต่ความผิดพลาดนั้นแพงกว่าการไม่ทำมันอย่างชัดเจน

a16z Eddy Lazzarin：

ชื่อระดับแรก

การพัฒนานวัตกรรมของสัญญาอัจฉริยะ

 a16z Noah：

ฉันสงสัยจริง ๆ ว่าคุณไม่ค่อยได้พูดถึงนวัตกรรมในเลเยอร์เครื่องเสมือนและเลเยอร์ภาษาโปรแกรม และผลกระทบต่อการพัฒนาสัญญาอัจฉริยะอย่างไร

Sui CTO Sam Blackshear ：

นั่นเป็นคำถามที่ดี ฉันไม่คิดว่าผู้คนให้ความสำคัญกับความแตกต่างนี้มากพอ เช่น ความแตกต่างระหว่างเลเยอร์เครื่องเสมือนและเลเยอร์ภาษาโปรแกรม ในความเป็นจริง นอกจาก EVM และเลเยอร์เครื่องเสมือนใหม่แล้ว ยังมีนวัตกรรมอีกมากมาย เช่น ภาษาซอร์สโค้ด เช่น Viper สิ่งเหล่านี้ดีกว่า Solidity ในหลาย ๆ ด้านและสนุก

ฉันคิดว่าหาก Move กลายเป็นมาตรฐานทางกฎหมายสำหรับ Web 3.0 ที่เราคาดหวังไว้ นวัตกรรมในเลเยอร์เครื่องเสมือนจะช้าและเพิ่มมากขึ้น เนื่องจากแกนหลักได้รับการแก้ไข เราจะเพิ่มเฉพาะสิ่งใหม่ๆ ไม่ใช่การออกแบบใหม่ทั้งหมด

อย่างไรก็ตาม ฉันคิดว่านวัตกรรมในระดับภาษาซอร์สโค้ดจะค่อนข้างสำคัญ ขณะนี้ เรามีซอร์สโค้ดภาษาเดียว แต่เชื่อมโยงกับรูปแบบไบต์โค้ดอย่างใกล้ชิด อย่างไรก็ตาม เนื่องจากลูกค้าใช้สัญญาอัจฉริยะมากขึ้นเรื่อยๆ โดยเน้นที่ความปลอดภัย ฉันจึงจินตนาการได้ว่าจะมีซอร์สโค้ดภาษาต่างๆ มากมายให้ลองใช้ และนี่เป็นพื้นที่การวิจัยที่น่าสนใจ บางทีคุณอาจเริ่มต้นด้วยการเขียนข้อเท็จจริงก่อนหน้าของคุณแล้วสังเคราะห์ข้อมูลเหล่านั้นให้คุณในโปรแกรม หรือคำแนะนำสำหรับข้อจำกัด

บางทีคุณอาจเริ่มด้วยการเขียนข้อเท็จจริงก่อนการย้ายของคุณ จากนั้นให้โปรแกรมสร้างองค์ประกอบเติมข้อมูลในโปรแกรมให้คุณ หรือแนะนำข้อจำกัด

ตัวอย่างเช่น คุณอาจเขียน Moves ในบริบทของเกมที่เฉพาะเจาะจงซึ่งดูเหมือนลำดับชั้นของฉาก อาจเขียนในไลบรารี Python แต่คอมไพล์เป็น bytecode ของ Move บางทีคุณอาจกำลังคิดที่จะผสานรวม Move เช่น Solana หรือแพลตฟอร์มอื่นๆ แต่ไม่ต้องการผสานรวมเครื่องเสมือน แต่ด้วยการคอมไพล์ bytecode ของ Move เป็นรูปแบบ bytecode ของ Salina แล้วใช้ภาษาซอร์สโค้ด Move ในระดับผู้พัฒนา

ฉันคิดว่ามีหลายวิธีเช่นเดียวกับ JVM (Java Virtual Machine) JVM เป็นเวอร์ชวลแมชชีนสำหรับใช้งานทั่วไปที่ยอดเยี่ยมซึ่งแต่เดิมรองรับเฉพาะจาวาเท่านั้น แต่มันผ่านการทดสอบของเวลา และตอนนี้คุณมี Scala, Groovy และวิธีการที่น่าสนใจอื่นๆ ในการใช้พื้นฐานเหล่านี้ในการออกแบบประสบการณ์การเขียนโปรแกรมที่แตกต่างกัน ซึ่งสอดคล้องกับสิ่งที่ผู้คนต้องการทำเป็นอย่างมาก

ดังนั้น ฉันมีมุมมองแบบลำเอียงว่า Viper ให้พื้นที่มากมายแก่คุณในการทดลองในระดับภาษาต้นทาง

a16z Eddy Lazzarin：

คุณคิดอย่างไรกับภาษาไบต์โค้ด EVM ทางเลือกทั้งหมด คุณมองโลกในแง่ดีว่ามีความพยายามที่น่าสนใจเช่น FE, Iron, Viper เป็นต้น เพื่อสร้างภาษาที่ชาญฉลาดและซับซ้อนยิ่งขึ้นสำหรับ EVM หรือไม่

Sui CTO Sam Blackshear ：

ดังนั้นนี่คือภาษาซอร์สโค้ดต่างๆ ที่คอมไพล์เป็น EVM bytecode

a16z Eddy Lazzarin：

ใช่ คอมไพล์เป็น EVM bytecode

Sui CTO Sam Blackshear ：

เมื่อเราเริ่มออกแบบ Move ที่ Facebook เรามองไปที่ Solidity และ Viper เมื่อเราเห็นซอร์สโค้ดภาษาอื่นๆ สร้าง EVM และนั่นคือตอนที่เราเริ่มสร้าง EVM สิ่งที่เราได้ข้อสรุปในท้ายที่สุดคือปัญหาที่ยากที่สุดสำหรับผู้คนในการเขียนสัญญาอัจฉริยะที่ปลอดภัยคือลักษณะพื้นฐานของ EVM และวิธีทำให้ค่าที่พิมพ์ไหลบนขอบเขตที่เชื่อถือได้ และการตัดสินใจแบบไดนามิก เป็นต้น บน คุณสมบัติของ EVM

หากคุณสร้างซอร์สโค้ดภาษาที่ดีขึ้น คุณจะทำให้นักพัฒนาเสียโอกาสได้ยากขึ้น บางทีพวกเขาอาจทำการตรวจสอบขั้นสูงกว่านี้แต่ท้ายที่สุดแล้ว สิ่งที่ Move สามารถให้ได้และสิ่งที่เราคิดว่าสำคัญก็คือตัวตรวจสอบโค้ดและการป้องกันระดับ VM จากโปรแกรมเมอร์คนอื่นๆ

ภาษาซอร์สโค้ดไม่สามารถให้สิ่งนี้กับคุณได้ ต้องสร้างไว้ใน VM ไม่ว่าคุณจะทำซ้ำบน EVM กี่ครั้งเพื่อให้ได้ภาษาซอร์สโค้ดที่สมบูรณ์แบบ ฉันคิดว่า Solidity นั้นยอดเยี่ยมและเราทำได้ดีกว่า แต่ฉัน ลองคิดดูถ้าคุณไม่มี ด้วยการป้องกันพื้นฐานเหล่านี้ใน VM คุณจะจบลงด้วยผลลัพธ์ที่ไม่ดีเท่าเส้นทางอื่นๆ ฉันไม่อายเพราะฉันคิดว่า Half นั้นเจ๋ง แต่เพราะฉันไม่คิดว่าตอนจบจะน่าดึงดูดเท่ากับเส้นทางอื่นๆ

ฉันคิดว่าภาษาสัญญาอัจฉริยะในยุคแรกๆ โดยเฉพาะ EVM นั้นเกินรายละเอียดการใช้งานของแพลตฟอร์มซึ่งออกแบบมาสำหรับ Ethereum รวมถึงคำแนะนำภายในเกี่ยวกับโครงสร้างธุรกรรม โครงสร้างบัญชี การใช้การเข้ารหัสบางประเภท เป็นต้น

ฉันคิดว่านี่ทำให้การใช้ EVM บนเชนที่ไม่เหมือน Ethereum ทำได้ยากมาก และสุดท้ายแล้วคุณต้องรับช่วงต่อการตัดสินใจในการออกแบบที่ Ethereum ทำขึ้น และในบางกรณี บางสิ่งที่ทำให้ Ethereum ยาก ข้อผิดพลาดเพิ่มเติม

เมื่อออกแบบ Move เราตระหนักดีว่าจะไม่เพิ่มสิ่งใดๆ ที่เกี่ยวข้องกับบล็อกเชนลงในภาษาหลัก และทำให้เป็นอิสระจากบล็อกเชนนั้นๆ มากที่สุดเท่าที่จะเป็นไปได้

ดังนั้นคุณจึงสามารถนำ Move ไปใช้กับเครือข่ายพิสูจน์การทำงานที่มีโครงสร้างการทำธุรกรรมที่บ้าคลั่งซึ่งอาจทำสิ่งนี้ในสวีเดนและเครือข่ายอื่นที่ทำในออสเตรเลีย ด้วยวิธีนี้ คุณไม่ต้องเดิมพันกับเครือข่ายใดเครือข่ายหนึ่งเพื่อเป็นผู้พัฒนา Move คุณสามารถใช้ทักษะของคุณกับเครือข่ายต่างๆ ที่หลากหลาย รวมถึงเครือข่ายในอนาคต เราคิดว่าสิ่งนี้สำคัญต่อการอยู่รอดของภาษาสัญญาอัจฉริยะ เพราะทรัพย์สินที่ยิ่งใหญ่ที่สุดของภาษาคือชุมชนของมัน และด้วยการทำให้ทักษะของคุณข้ามแพลตฟอร์ม แทนที่จะใช้ภาษาใดภาษาหนึ่งมากเกินไป คุณจะสามารถขยายชุมชนของคุณและอยู่ในตำแหน่งที่ดีขึ้นเพื่อประสบความสำเร็จ จากนั้นชุมชนขนาดใหญ่คือสิ่งที่ทำให้เป็นไปได้ที่จะลงทุนเงินจำนวนมากในเครื่องมือ เงินจำนวนมากในห้องสมุดสาธารณะ และทุกสิ่งที่คุณต้องการจริงๆ เพื่อให้ภาษามีชื่อเสียงและประสบความสำเร็จ

นั่นคือสิ่งที่เราพยายามทำตั้งแต่เริ่มต้น และตอนนี้เราได้เห็น Move chains ที่แตกต่างกันหลายอันซึ่งแตกต่างกันมากในวิธีที่พวกมันรวมภาษา

a16z Eddy Lazzarin：

สำหรับฉันแล้วดูเหมือนว่านี่เป็นธีมพื้นฐานของ node.js ใช่ไหม

โฮสต์ Sonal Chokshi:

ใช่.

a16z Eddy Lazzarin：

มีผู้คนจำนวนมากที่รู้จัก JavaScript และพวกเขาต้องการทำสิ่งต่างๆ มากมาย พวกเขาต้องการแบ่งปันห้องสมุดต่างๆ รหัสที่มีอยู่สามารถเริ่มต้นอินสแตนซ์ JavaScript ฝั่งเซิร์ฟเวอร์ ซึ่งทำให้โหนดมีประโยชน์ ซึ่งหมายความว่ามีนักพัฒนาทุกประเภทที่อาจไม่ได้เขียนโปรแกรมแบ็กเอนด์ แต่สามารถเริ่มกระโดดเข้ามาและทำให้เป็นสาขาของตนได้

Sui CTO Sam Blackshear ：

ผมว่าเป็นการเปรียบเทียบที่ดี นอกจากนี้ เราต้องการพูดคุยเกี่ยวกับการกำกับดูแลภาษาโปรแกรมเล็กน้อย เพราะเห็นได้ชัดว่า Node มีการแยกและแยกการกำกับดูแลที่มีรายละเอียดสูง และทุกชุมชนภาษาโปรแกรมมีการแยกและทิศทางการกำกับดูแลที่มีรายละเอียดสูงจำนวนมาก ฉันได้ครอบคลุม Node แล้วและเป็นหนึ่งในรายการโปรดของฉัน แต่ฉันต้องการให้แน่ใจว่าเราจบหัวข้อนี้ มีอะไรจะพูดอีกไหม? ฉันคิดว่าคุณเป็นแฟนเก่าในรายการวิทยุของเรา ซึ่งฉันชอบ

a16z Noah：

ดังนั้นฉันจึงมีความแตกต่าง หรือค่อนข้างจะมีไอเดียเจ๋งๆฉันสงสัยว่าทำไมไม่มีใครสร้าง OP Rollup for Move นั่นคงจะเจ๋งมากเมื่อพิจารณาว่าผู้ใช้ Rollup ของ OP ใช้งานบน Ethereum พวกเขาใช้ลายเซ็น MetaMask และ ECDSA แต่ดูเหมือนจะไม่ใช้รูปแบบลายเซ็นเดียวกันกับเรา เช่น Move ดูเหมือนจะไม่ใช้ ECDSA

Sui CTO Sam Blackshear ：

ใช่ เรารองรับรูปแบบลายเซ็น EdDSA และ ECDSA ของ Ethereum

a16z Noah：

สมบูรณ์แบบ แต่ประเด็นของฉันคือคุณสามารถสร้างบางสิ่งที่น่าสนใจจริงๆ อย่างไรก็ตาม เมื่อฉันพยายามเรียนรู้ Move ฉันเอาแต่จ้องไปที่ Dessert และ Actor Dog ฉันสับสน

Sui CTO Sam Blackshear ：

แท้จริงแล้วเป็นปัญหาใช่ไหม? เมื่อมีคนเริ่มเรียนรู้ Move พวกเขาอาจสับสน: ฉันกำลังเรียนรู้ภาษาสัญญาอัจฉริยะ แต่บล็อกเชนอยู่ที่ไหน ความแตกต่างระหว่างพวกเขายังสามารถสร้างปัญหาหากคุณพยายามเขียนโค้ดสำหรับทั้งสองแพลตฟอร์ม ดังนั้นฉันคิดว่าความท้าทายที่เรายังคงพยายามหาคือ เลือกแพลตฟอร์ม เลือกของหวาน เลือก Optus เรียนรู้ในเชิงลึก จากนั้นคุณจะพบว่าทักษะและรหัสของคุณสามารถถ่ายโอนไปยังแพลตฟอร์มอื่นได้อย่างง่ายดาย ฉันคิดว่ามีปัญหาโดยธรรมชาติบางอย่างที่นี่ และปัญหาด้านเอกสารบางอย่างที่ต้องแก้ไขเพื่อให้ง่ายขึ้น

a16z Eddy Lazzarin：

บางทีการเปรียบเทียบขึ้นอยู่กับว่าคุณพิจารณาว่า SQL เป็นทักษะพกพาหรือไม่ มีหลายภาษาของ SQL มี anti-SQL ซึ่งไม่มีใครรู้จริง ๆ ว่ามันคืออะไร แต่พวกเขาสามารถเรียนรู้ SQL ได้ หากคุณเหล่ตาสักนิด คุณสามารถใช้ฐานข้อมูลใด ๆ ก็ได้ อาจจะสับสนเล็กน้อยเกี่ยวกับชื่อฟังก์ชันเฉพาะหรือประเภทเฉพาะ แต่โดยคร่าว ๆ รูปร่างเดียวกัน ฉันคิดว่าสิ่งนี้ทำให้ SQL มีประสิทธิภาพและทนทานมาก นั่นเป็นเหตุผลที่มันยังคงเป็นส่วนหนึ่งของภาษากลางของข้อมูล บางทีนี่อาจเป็นอนาคตของ Move ผมคิดว่าเราทำได้ดีกว่านี้

Sui CTO Sam Blackshear ：

ชื่อระดับแรก

สิ่งที่ไม่เหมือนใครเกี่ยวกับการเขียนโปรแกรมสัญญาอัจฉริยะ

โฮสต์ Sonal Chokshi:

เราได้ย้อนกลับไปมาเกี่ยวกับการเขียนโปรแกรมแบบดั้งเดิมเทียบกับการเขียนโปรแกรมสัญญาอัจฉริยะ ข้อจำกัดและความแตกต่างเฉพาะ และแม้แต่ความคล้ายคลึงกันบางประการระหว่างการเขียนโปรแกรมดอกยางและสัญญาอัจฉริยะ มีอะไรพิเศษเกี่ยวกับการเขียนโปรแกรมสัญญาอัจฉริยะที่เราไม่ได้กล่าวถึงหรือไม่?

a16z Eddy Lazzarin：

อีกสิ่งที่สำคัญมากในบริบทของสัญญาอัจฉริยะคือการใช้ทรัพยากร เช่น Gas Metering in Solidity แม้ว่าทรัพยากรด้านคอมพิวเตอร์จะมีค่อนข้างมากในหลาย ๆ กรณี แต่ต้นทุนด้านการคำนวณก็มีความสำคัญมากเช่นกัน แต่อยู่นอกบริบทของสัญญาอัจฉริยะหรือนอกบริบทของบล็อกเชน นั่นหมายถึงมันสัมผัสและพิจารณาน้อยลง ฉันคิดว่าความคิดในภาษาของทรัพยากรที่คุณใช้อาจเป็นทรัพยากรที่น่าสนใจสำหรับการเขียนโปรแกรมสัญญาอัจฉริยะ

Sui CTO Sam Blackshear ：

นั่นคือสิ่งที่เราให้ความสำคัญเป็นอย่างมาก เราได้สร้าง Gas Metering ไว้ใน EVM ซึ่งอย่างที่คุณพูด มันแตกต่างจากภาษาโปรแกรมแบบดั้งเดิมอย่างมาก

ฉันคิดว่าแนวโน้มในอนาคตคือ Gas Meeting จะมีเนื้อหยาบมากขึ้นเรื่อยๆ เพื่อป้องกันปัญหาร้ายแรง เช่น การใช้ทรัพยากรในทางที่ผิด แทนที่จะเป็นแบบละเอียดจริงๆ สำหรับแต่ละคำสั่ง

จริงๆ แล้วฉันคิดว่าสิ่งต่าง ๆ เช่น Gas Golfing (Sui World Note: Gas Golfing หมายถึงความท้าทายสำหรับนักพัฒนาในการเขียนโค้ดที่ประหยัดแก๊สที่สุดในชุดการโต้ตอบข้ามสัญญาอัจฉริยะ) นั้นน่าสนใจมาก แต่จริง ๆ แล้วสิ่งเหล่านี้สำคัญมากสำหรับการเขียนโค้ด ทั้งรูปแบบและความปลอดภัยทำอันตรายได้มากมาย

แดกดัน เหตุผลที่เรารู้เพียงเกี่ยวกับโมเดลการเรียกเก็บเงินต่อคำสั่ง อาจเป็นเพราะหากคุณมีเครื่องเสมือนขนาดใหญ่ ความแตกต่างระหว่างการเรียกใช้คำสั่ง 100k กับการเรียกใช้คำสั่ง 500k นั้นไม่มีนัยสำคัญเมื่อพูดถึงการวัดรันไทม์จริง ๆ

เหตุใดเราจึงเรียกเก็บเงินต่อการสั่งซื้อ ดังนั้นฉันคิดว่าเราจะเห็นแนวโน้มของวิธีการทำให้เนื้อหยาบมากขึ้น

เมื่อใดก็ตามที่ฉันเห็นบล็อกที่ไม่ปลอดภัยและแอสเซมบลีแบบอินไลน์จำนวนมากในรหัส Solidity มันจะเตือนฉันว่าเราเร็วแค่ไหนแล้ว เพราะนี่ไม่ใช่ความท้าทายในการเขียนโปรแกรมที่นักพัฒนาสัญญาอัจฉริยะควรพิจารณา นี่ไม่ใช่สัญญาณของความเป็นผู้ใหญ่ ระบบนิเวศการพัฒนา แต่เรากำลังก้าวไปในทิศทางนั้น ฉันยอมรับว่าเราจำเป็นต้องพิจารณากรณีขอบ การเลือกอัลกอริทึมที่เหมาะสม การเลือกโครงสร้างข้อมูลที่ถูกต้อง การเลือกวิธีการทั่วไปที่ถูกต้อง ซึ่งเป็นกรณีของวิศวกรรมซอฟต์แวร์ส่วนใหญ่ ล้วนมีความสำคัญ แต่คำถามเล็กน้อยเกี่ยวกับการคำนวณค่าใช้จ่ายของแต่ละคำสั่งนั้นอาจเป็นเรื่องที่ยุ่งยากเกินไป

โฮสต์ Sonal Chokshi:

เราได้พูดคุยเกี่ยวกับการปรับแก๊ส ประเภท ทรัพย์สิน และความปลอดภัยให้เหมาะสม ต้องคำนึงถึงข้อจำกัดอะไรอีกบ้าง

Sui CTO Sam Blackshear ：

นี่เป็นเธรดที่คล้ายกับแก๊ส แต่ส่วนย่อยเฉพาะที่ฉันมีอยู่ในใจคือสถานะ นี่เป็นปัญหาใหญ่สำหรับฉัน เมื่อฉันคิดเกี่ยวกับการทำงานของแก๊ส ฉันชอบที่จะเพิ่มประสิทธิภาพแก๊สอย่างมาก

อย่างไรก็ตาม เมื่อเราจัดการกับสัญญาอัจฉริยะจริงที่มีเงินทุนจริง คำแนะนำทั่วไปของฉันคือ เว้นแต่คุณจะสามารถใช้สถานะน้อยกว่าที่คุณเคยใช้มาก่อนได้ คุณควรจัดระเบียบอย่างสมเหตุสมผล นั่นเป็นครั้งเดียวที่ฉันจะใช้ชุดประกอบขนาดใหญ่หากคุณสามารถทำสิ่งที่โง่เขลาเพื่อใช้สถานะน้อยลงได้ เพราะนี่เป็นเหมือนทรัพยากรตลอดไป และเราควรวางไว้เหนือการดำเนินการหรือเรียกตำแหน่งของข้อมูล

a16z Eddy Lazzarin：

ฉันเห็นด้วยอย่างยิ่งกับประเด็นนี้ เพราะฉันคิดว่ามันแพงโดยพื้นฐาน หากแพลตฟอร์มอนุญาตให้ทุกสัญญาแตะต้องส่วนใดส่วนหนึ่งของรัฐ มันจะยากที่จะขนานกัน แนวทางของ Squeeze และแพลตฟอร์มบล็อกเชนใหม่อื่นๆ คือการจำกัดสถานะที่ธุรกรรมสามารถเข้าถึงได้อย่างชัดเจน อย่างน้อยก็แจ้งให้เราทราบบ้าง ด้วยวิธีนี้ ในระดับสูง แพลตฟอร์มสามารถทำธุรกรรมแบบขนานได้ง่ายขึ้น รวมถึงการดำเนินการและความเห็นพ้องต้องกัน ดังนั้นนี่คือสิ่งที่โปรแกรมเมอร์บางคนต้องคำนึงถึง: ให้เร็วที่สุดเท่าที่จะเป็นไปได้เมื่อเข้าถึงสถานะ และไม่แตะต้องสถานะที่ไม่จำเป็น เพื่อให้ตัวตรวจสอบสามารถขนานกันได้อย่างมีประสิทธิภาพมากขึ้นและได้พื้นที่บล็อกมากขึ้น

a16z Noah：

นี่เป็นการเปิดโลกสู่ข้อเท็จจริงที่ว่าผู้ตรวจสอบความถูกต้องไม่จำเป็นต้องดาวน์โหลดสถานะทั้งหมดแม้ในสถานการณ์ที่ไม่ได้สวมบทบาทหรือไม่? จะเป็นไปได้ไหมถ้าคุณสามารถแยกสถานะได้อย่างง่ายดายเพื่อให้ตัวตรวจสอบทำหน้าที่เฉพาะธุรกรรมที่สามารถจัดการได้

Sui CTO Sam Blackshear ：

ฉันคิดว่ามันเป็นไปได้จริง ๆ ที่จะตระหนักถึงโลกเช่นนั้น นอกจากนี้ยังเปิดเส้นทางสำหรับแนวทางต่างๆ

ให้ฉันสรุปจากมุมมองของโปรแกรมเมอร์ ความสามารถในการสัมผัสโลกทั้งใบผ่านธุรกรรมต่างๆ นั้นมีค่ามาก อย่างไรก็ตาม เราไม่สามารถเน้นย้ำถึงข้อได้เปรียบนี้ได้มากนักจนต้องดำเนินการผ่าน Rollup หรือในการทำธุรกรรมหลายรายการ เนื่องจากจะทำให้ผู้ใช้สังเกตเห็นความปลอดภัยน้อยลง

ฉันคิดว่าคุณค่าของ blockchain มาจากสิ่งที่เป็นนามธรรม: มีบัญชีแยกประเภท สถานะที่มีค่าทั้งหมดอยู่ในบัญชีแยกประเภทนี้ และฉันสามารถสัมผัสได้ทั้งหมดในคราวเดียว จากมุมมองของโปรแกรมเมอร์ นี่คือคุณค่าของบล็อกเชน คำถามคือคุณจะทำให้เบื้องหลังทำงานได้อย่างมีประสิทธิภาพมากขึ้นได้อย่างไร มันจะทำให้เบาบางมากขึ้นได้อย่างไรเพื่อให้ตัวตรวจสอบความถูกต้องสามารถขนานกันได้อย่างมีประสิทธิภาพมากขึ้น? ในซุย ผู้ตรวจสอบความถูกต้องสามารถมีคนงานได้หลายคน โดยแต่ละคนรับผิดชอบในส่วนของรัฐ แต่จากมุมมองของโปรแกรมเมอร์และแม้แต่จากมุมมองของโปรแกรมตรวจสอบความถูกต้องอื่นๆ ดูเหมือนว่าเอนทิตีเชิงตรรกะที่ทำทุกอย่าง

ชื่อระดับแรก

การเปลี่ยนแปลงวิธีคิดเกี่ยวกับการเขียนโปรแกรมสัญญาอัจฉริยะ

โฮสต์ Sonal Chokshi:

เราเพิ่งพูดถึงแง่มุมเฉพาะบางประการที่เกี่ยวข้องกับการเขียนโปรแกรมสัญญาอัจฉริยะ การเปลี่ยนแปลงความคิดอื่น ๆ คืออะไร? เราได้พูดคุยกันเล็กน้อย และอย่างที่ Eddie กล่าวไว้ การเปลี่ยนแปลงครั้งใหญ่คือในโลกของการเขียนโปรแกรม อย่างน้อยก็ตั้งแต่ยุคแรก ๆ ของการใช้คอมพิวเตอร์ เราอยู่ในโลกแห่งความอุดมสมบูรณ์ แต่ในโลกนี้ เรา' อยู่ในโลกแห่งข้อจำกัด นั่นเป็นตัวอย่างของวิธีคิด ความคิดอื่นใดที่เปลี่ยนไป? โดยเฉพาะอย่างยิ่งสำหรับคุณแต่ละคน ในฐานะที่คุณเป็นโปรแกรมเมอร์ที่ต้องเผชิญกับการเขียนโปรแกรมสัญญาอัจฉริยะ อะไรทำให้คุณประหลาดใจ หรือสอนคุณ หรือทำให้คุณคิดเกี่ยวกับบางสิ่งที่ต่างออกไป

a16z Eddy Lazzarin：

อาจเป็นตัวอย่างที่งี่เง่าเล็กน้อย ฉันยังจำครั้งแรกที่ฉันเรียนรู้เมื่อไม่กี่ปีที่ผ่านมาว่ายอดคงเหลือของโทเค็น ERC-20 ไม่ใช่สิ่งที่บัญชีของคุณเป็นเจ้าของ ที่อยู่ของคุณไม่มียอดโทเค็น แต่มีสัญญาโทเค็นที่บันทึกว่าที่อยู่ใดมียอดคงเหลือเท่าใด เมื่อคุณต้องการโอนโทเค็นให้ใครบางคน แสดงว่าคุณไม่ได้ส่งโทเค็นให้พวกเขา คุณต้องทำสัญญาและดำเนินการระดับต่ำเหล่านี้แทน โดยเปลี่ยนยอดคงเหลือที่ถือโดยที่อยู่ของคุณและที่อยู่ของพวกเขา คุณมีสิทธิ์จัดการและเปลี่ยนแปลงสัญญานั้น เป็นวิธีการที่สวนทางกับสัญชาตญาณมาก การเปลี่ยนแปลงที่น่าสนใจเกี่ยวกับ Move ที่ฉันสังเกตเห็นเป็นครั้งแรกใน EVM และ Slippery เป็นการเปลี่ยนแปลงความคิดที่น่าสนใจ เพราะคำภาษาอังกฤษที่เราได้ยินบ่อยๆ ไม่จำเป็นต้องสอดคล้องกับรูปแบบการเขียนโปรแกรม

Sui CTO Sam Blackshear ：

ฉันต้องการเพิ่มว่ามันเกี่ยวกับเมื่อคุณทำจริง ในโลกปกติ เรากังวลมากเกี่ยวกับประสิทธิภาพการทำงานของนักพัฒนา เนื่องจากเป็นหน้าที่ของวิศวกรที่จะต้องเขียนโค้ดจำนวนมากที่มีข้อบกพร่องเพียงเล็กน้อย และข้อบกพร่องเหล่านั้นไม่รุนแรงเกินไป ในขณะที่โลกของสัญญาอัจฉริยะ งานของคุณคือเขียนโค้ดจำนวนน้อยมาก และต้องไม่มีที่ติ จะต้องสมบูรณ์แบบในทุกวิถีทาง ไม่งั้นจะเสียเงินคนอื่นเป็นร้อยๆล้าน เป็นการเปลี่ยนแปลงวิธีคิดที่แตกต่างไปจากเดิมอย่างสิ้นเชิง ใช้เวลาสองเดือนในการดูโค้ด 1,000 บรรทัดและพยายามหาวิธีทำให้ดีขึ้น และที่สำคัญกว่านั้นคือทำอย่างไรจึงจะสมบูรณ์แบบ จากนั้นผู้ตรวจสอบก็ทำเช่นเดียวกัน โดยตัดสินว่ามันสมบูรณ์แบบหรือไม่

โฮสต์ Sonal Chokshi:

นี่เป็นการเปลี่ยนแปลงครั้งใหญ่ในความคิด ในโลกของการเขียนโปรแกรม อย่างน้อยก็ตั้งแต่ช่วงแรกๆ ของคอมพิวเตอร์ เราเคยอยู่ในโลกแห่งความอุดมสมบูรณ์ แต่ในโลกนี้ เราอยู่ในโลกแห่งข้อจำกัด

a16z Eddy Lazzarin：

การเปลี่ยนแปลงทางความคิดอีกอย่างคือในโลกของโทเค็น ERC 20 ที่อยู่ของคุณไม่ได้แสดงถึงยอดคงเหลือของโทเค็น คุณไม่สามารถส่งโทเค็นได้ คุณต้องไปที่สัญญาโทเค็น ค้นหายอดโทเค็นที่ตรงกับที่อยู่ในสัญญาโทเค็น จากนั้นทำการโอนโทเค็นให้เสร็จสมบูรณ์โดยแก้ไขที่อยู่และยอดคงเหลือ นี่เป็นวิธีคิดที่ค่อนข้างสวนทางกับสัญชาตญาณ แต่ใน EVM และ Move เป็นการเปลี่ยนแปลงที่สำคัญมากในการคิด

Sui CTO Sam Blackshear ：

ในการเขียนโปรแกรมสัญญาอัจฉริยะ งานของคุณคือเขียนโค้ดชิ้นเล็กๆ และต้องสมบูรณ์แบบ เพราะโค้ดนี้อาจเกี่ยวข้องกับความปลอดภัยของเงินทุนของผู้คนหลายร้อยล้านคน คุณต้องตรวจสอบโค้ดเพื่อให้แน่ใจว่าถูกต้อง

นอกจากนี้ การอัปเกรดสัญญาอัจฉริยะยังยากกว่าการอัปเกรดแอปบนอุปกรณ์เคลื่อนที่หรือเว็บไซต์ เนื่องจากในสัญญาอัจฉริยะ รหัสจะไม่เปลี่ยนรูป ในการเขียนโปรแกรมสัญญาอัจฉริยะ คุณต้องคิดถึงวิธีสนับสนุนการอัปเกรดที่ปลอดภัยและไว้วางใจได้ ทำให้ดูเหมือนเป็นระบบนิเวศแบบดั้งเดิมมากขึ้น

แต่ในการเขียนโปรแกรมสัญญาอัจฉริยะ คุณต้องมีวิธีคิดที่เป็นปฏิปักษ์ ซึ่งอาจไม่คุ้นเคยสำหรับผู้คนจากสาขาอื่น นี่เป็นเพราะรูปแบบการปรับใช้ในสัญญาอัจฉริยะ คุณต้องพิจารณาไม่เพียงแต่การใช้งานที่คาดไว้ของแอปพลิเคชันของคุณเท่านั้น แต่ยังรวมถึงการใช้งานที่ไม่ได้ตั้งใจด้วย เนื่องจากในการเขียนโปรแกรมแบบดั้งเดิม มีวิธีซ่อนตัวเอง จำกัดตัวเองให้ใช้ API ขนาดเล็ก หรือใช้ไฟร์วอลล์เพื่อจำกัดการกระทำของผู้โจมตี เป็นต้น

แต่ประเด็นทั้งหมดของสัญญาอัจฉริยะคือสิ่งที่คุณทำสามารถโต้ตอบกับโค้ดที่คุณไม่เคยคิดมาก่อน และทำได้อย่างปลอดภัย ดังนั้นคุณต้องพิจารณาข้อดีและข้อเสียของสถานการณ์นี้ นี่เป็นการเปลี่ยนแปลงความคิดจากการเขียนโปรแกรมแบบเดิมๆ

โฮสต์ Sonal Chokshi:

นี่เป็นคำถามที่สำคัญมากและเป็นคำถามที่ควรให้ความสำคัญเมื่อเราพูดถึงวิธีการเขียนสัญญาอัจฉริยะและใช้ภาษาโปรแกรมสัญญาอัจฉริยะหรือไม่

Sui CTO Sam Blackshear ：

ใช่อย่างแน่นอน มันเป็นเรื่องโปรดของฉันที่จะพูดถึง สิ่งนี้ทำให้ฉันกลัวมาก ประเด็นที่นักออกแบบภาษาสัญญาอัจฉริยะต้องพิจารณาคือความปลอดภัย นั่นคือจุดสนใจหลัก บางทีอาจเป็นจุดสนใจเดียวจนกว่าเราจะเอาสิ่งนั้นออกไป

ในความเห็นของฉัน ความปลอดภัยของสัญญาอัจฉริยะเป็นภัยคุกคามต่อการยอมรับสกุลเงินดิจิทัลที่กว้างขึ้น เหตุผลที่ฉันพูดแบบนี้คือคุณสามารถดู Ethereum และความแข็งแกร่ง และแพลตฟอร์มยอดนิยม EVM และ Solidity คุณสามารถดูโปรแกรมเมอร์ยุคแรกๆ ที่เขียนโค้ดนี้ พวกเขามีคุณสมบัติสูงมาก พวกเขาเข้าใจบล็อกเชนพื้นฐานอย่างแท้จริง พวกเขาใส่ใจในความปลอดภัยมาก พวกเขารู้ว่ากำลังทำอะไรอยู่ ฉันคิดว่าพวกเขารับผิดชอบในการเขียนโค้ดที่จัดการเงินหลายร้อยล้านและพันล้านดอลลาร์อย่างจริงจัง

แต่ถ้าคุณดูบันทึกการรักษาความปลอดภัยของสัญญาอัจฉริยะที่ใดก็ตาม มันแย่มาก และไม่ใช่ความผิดของคนเหล่านี้ ฉันคิดว่านี่เป็นคำถามที่ยากมาก และฉันคิดว่าภาษาทำให้มันยากขึ้น ดังนั้นหากคุณดูที่เว็บไซต์โปรดของฉัน rakt.news คุณสามารถดูลีดเดอร์บอร์ดหรือดูการแฮ็กทั้งสิบรายการที่มีมูลค่าหลายสิบหรือหลายร้อยล้านดอลลาร์ที่ทำเป็นประจำและเกิดขึ้นทุกสัปดาห์หรือทุกเดือนขึ้นอยู่กับขนาด ในขณะเดียวกัน ชุมชนนักพัฒนาสัญญาอัจฉริยะมีขนาดเล็กมาก มีโปรแกรมเมอร์ EVM แบบเต็มเวลาประมาณ 5,000 คนเท่านั้น ซึ่งน้อยมากเมื่อเทียบกับชุมชนนักพัฒนาแบบดั้งเดิม

ดังนั้น หากคุณเชื่อว่าผู้คนที่เรามีเป็นพวกไม่ยอมใครง่ายๆ และคำนึงถึงความปลอดภัยมากที่สุด แต่แนวทางปฏิบัติในการพัฒนาและบันทึกด้านความปลอดภัยนั้นไม่ยั่งยืน ฉันคิดว่าข้อสรุปของคุณก็คือไม่มีทางที่พื้นที่นี้จะอยู่รอดได้หากปราศจากการสร้างความปลอดภัย หากปัญหายังคงดำเนินต่อไป เติบโตในทางที่แย่ลง นั่นอาจหมายความว่าไม่เติบโตเลย หรือเช่นเดียวกับสถาบันการเงินหรือบริษัทขนาดใหญ่ที่ต้องการเข้าสู่ Web3 พวกเขากำลังมองว่าพวกเขาต้องจ้างนักพัฒนาสัญญาอัจฉริยะหรือไม่ ฉันจะถูกแฮ็กเงินนับสิบล้านดอลลาร์และประหม่า สถานการณ์นี้จะเลวร้ายลงเมื่อเวลาผ่านไป พวกเขาอาจอยู่ข้างสนาม ดังนั้น เมื่อมีบางคนพยายามออกแบบภาษาสัญญาอัจฉริยะใหม่ ความปลอดภัยจะต้องคำนึงถึงเป็นอันดับแรก

โฮสต์ Sonal Chokshi:

พวกคุณได้พูดเป็นนัยๆ ไปแล้วในบริบทของการไม่สูญเสียทรัพย์สิน แต่คุณหมายความว่าอย่างไรให้เจาะจงเพราะมันสำคัญมาก?

Sui CTO Sam Blackshear ：

สิ่งที่ฉันหมายถึงการรักษาความปลอดภัยคือเราทั้งคู่ป้องกันไม่ให้โปรแกรมเมอร์ก้าวเท้าของตัวเองและจัดหาสิ่งดั้งเดิมที่ถูกต้องให้มากที่สุดเท่าที่จะเป็นไปได้เพื่อให้พวกเขาสามารถป้องกันการโจมตีได้เนื่องจากสัญญาอัจฉริยะคือการตั้งค่าที่รหัสของคุณถูกปรับใช้ในการโจมตี ถัดจากผู้โจมตี ผู้โจมตีสามารถเรียกรหัสของคุณโดยตรง สามารถเชื่อมโยงไปยังรหัสโดยตรง รหัสของคุณเป็นโอเพ่นซอร์ส หรืออย่างน้อย bytecode เป็นโอเพ่นซอร์ส

นี่คือสภาพแวดล้อมการเขียนโปรแกรมที่เป็นปฏิปักษ์ที่สุดเท่าที่เราเคยเห็นมา และแพงที่สุดในการทำผิดพลาด ดังนั้น ฉันคิดว่าถ้าคุณกำลังพูดถึงการออกแบบโปรแกรมสัญญาอัจฉริยะ ความปลอดภัยต้องมาก่อนเสมอ เมื่อเราหลีกเลี่ยงความปลอดภัยแล้ว เราก็สามารถคิดถึงปัจจัยอื่นๆ ที่สื่อความหมายได้มากขึ้น แต่นี่คือคำตอบที่ค่อนข้างน่าเบื่อของฉัน แต่ฉันคิดว่าคำตอบที่สำคัญมาก

a16z Eddy Lazzarin：

คุณลักษณะใดที่อาจส่งผลต่อความปลอดภัย มีตัวอย่างอะไรบ้าง?

Sui CTO Sam Blackshear ：

ฉันคิดว่าสิ่งที่สำคัญที่สุดคือการห่อหุ้ม โดยเฉพาะอย่างยิ่ง คุณลักษณะย่อยแต่ละอย่างของการห่อหุ้ม เมื่อคุณเขียนโค้ด คุณไม่สามารถคาดเดาได้ว่าผู้โจมตีจะพยายามทำอะไร ดังนั้นคุณต้องสามารถหาเหตุผลได้โดยไม่ต้องคาดการณ์ล่วงหน้าว่าผู้โจมตีจะทำอะไร ดังนั้น คุณต้องมีระบบประเภทที่แข็งแกร่ง ไม่ใช่แค่ในระดับซอร์สโค้ด แต่ในระดับไบต์โค้ด ดังนั้นการรับประกันที่คุณได้รับเมื่อคุณเขียนซอร์สโค้ดของคุณจะอยู่ที่นั่นเมื่อคุณเผยแพร่โค้ดบนบล็อกเชนและคนอื่นๆ ไว้วางใจ เปิดอยู่และโต้ตอบกับมัน

เราสังเกตเห็นว่าคุณสมบัติบางอย่างที่เป็นที่นิยมในโดเมนอื่นนั้นไม่เหมาะสมโดยเนื้อแท้ในการเขียนโปรแกรมสัญญาอัจฉริยะ เช่น การจัดส่งแบบไดนามิก

ในการเขียนโปรแกรมแบบดั้งเดิม สิ่งต่างๆ เช่น อินเทอร์เฟซและไดนามิกดิสแพตช์เป็นกลไกสำคัญเชิงนามธรรมที่มีอยู่ทั่วไปทุกหนทุกแห่ง คุณสามารถกำหนดอินเทอร์เฟซ แล้วให้คนอื่นเขียนอินเทอร์เฟซนั้นใหม่ด้วยตรรกะที่แตกต่างกัน และคุณสามารถตั้งโปรแกรมเทียบกับอินเทอร์เฟซนั้น และทุกอย่างก็เรียบร้อยดี แต่เรามีเกร็ดเล็กเกร็ดน้อย: "ในโลกที่รหัสคือกฎหมาย อินเทอร์เฟซคืออาชญากรรม"

a16z Noah：

นี่เป็นเรื่องตลกหยุดสักครู่ ในโลกที่โค้ดคือกฎหมาย อินเทอร์เฟซคืออาชญากรรม

โฮสต์ Sonal Chokshi:

ก่อนที่คุณจะไปต่อ คุณช่วยอธิบายประโยคนี้อีกหน่อยได้ไหม? ฉันไม่อยากกระโดดข้ามมันเร็วเกินไป

Sui CTO Sam Blackshear ：

ใช่แล้ว แนวคิดในที่นี้คืออินเทอร์เฟซไม่ได้กำหนดพฤติกรรม แต่จะกำหนดพฤติกรรมที่คาดหวัง ตัวอย่างเช่น เมื่อคุณอ่านข้อมูลจำเพาะของอินเทอร์เฟซ ชื่อพารามิเตอร์หรือแม้แต่ประเภท มันจะบอกคุณว่าคุณต้องการทำอะไรให้สำเร็จ แต่ไม่มีการรับประกันว่าจะเกิดขึ้น

ดังนั้น หากคุณเขียนโค้ดเพื่อป้องกันบางสิ่ง แต่จริงๆ แล้วคุณปล่อยให้ผู้โจมตีเว้นว่างไว้ ให้คนอื่นเข้ามาเติมเต็ม สิ่งนี้ดูเหมือนจะเป็นอาชญากรรมในกฎหมายสัญญา นี่คือสัญญาที่ไม่ได้ระบุ ฉันชอบคุณสมบัตินี้มาก มันเป็นที่นิยมในภาษาการเขียนโปรแกรมแบบดั้งเดิม แต่เราคิดว่าในสัญญาอัจฉริยะ สิ่งนี้นำไปสู่ปัญหาต่างๆ มากมาย ตัวอย่างเช่น การกลับเข้าใหม่จำเป็นต้องมีการจัดกำหนดการแบบไดนามิก ตัวอย่างเช่น หากคุณยกเลิกการกำหนดเวลาแบบไดนามิก จะไม่มีการกลับเข้ามาใหม่เลย สิ่งต่างๆ เช่น โทเค็นพิษใน Ethereum เกิดขึ้นเพราะคุณเขียนฟังก์ชันการโอนใหม่ และทุกคนรู้ว่าโดยสัญชาตญาณแล้ว มันถูกใช้เพื่อโอนเงินเท่านั้น และอาจไม่ได้ทำอย่างอื่น แต่ตอนนี้กลับทำเกินคาด เช่น ขโมยเงิน นั่นเป็นตัวอย่างของฟีเจอร์ที่ถ้าคุณเอาออก มันจะง่ายกว่ามากในการให้เหตุผลเกี่ยวกับโค้ดของคุณและสรุปอย่างเหมาะสม เพราะทุกครั้งที่คุณเห็นไซต์การโทร คุณจะรู้ว่ามันจะทำอะไร คุณไม่ต้องกังวลเกี่ยวกับสิ่งอื่นๆ คนทำสิ่งที่คุณประหลาดใจในภายหลัง

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 ：

ใช่ ฉันคิดว่ารูปแบบอินเทอร์เฟซเหล่านี้ส่วนใหญ่สามารถปรับเปลี่ยนได้ค่อนข้างตรงไปตรงมา คอมไพล์ยากขึ้นเล็กน้อย แต่คุณสามารถโต้แย้งได้ว่ามันเป็นโมเดลความสามารถเทียบเท่ากับสิ่งที่อินเทอร์เฟซนี้พยายามทำ

โฮสต์ Sonal Chokshi:

อย่างไรก็ตาม แซม คุณคิดว่ามันน่าพอใจไหม อย่าลังเลที่จะไม่เห็นด้วย ความขัดแย้งเล็กน้อยเป็นสิ่งที่ดี

Sui CTO Sam Blackshear ：

ฉันสบายดีเพราะฉันคิดว่าถ้าคุณมีโมดูลหรือโครงสร้างที่มีความสามารถที่แท้จริงซึ่งสามารถป้อนเข้าสู่โมดูลที่มีลักษณะการทำงานที่กำหนดไว้ล่วงหน้าได้ คุณก็จะจบลงด้วยพฤติกรรมเดียวกันได้ เหมือนกับที่โมดูลสามารถทำได้ โมดูลยอมรับโครงสร้างที่เป็นนามธรรม โครงสร้างนั้นถูกกำหนดไว้ในโมดูลนั้น และมีความสามารถที่แท้จริงภายในโครงสร้างนั้น วิธีนี้ใช้งานได้ดีจริง ๆ เพราะคุณสามารถรับรีจิสตรีสไตล์การอนุญาตที่ดีมาก ๆ และพวกมันออกมาจากที่นี่เกือบจะเป็นธรรมชาติ เหมือนกับสิ่งที่เรียกว่ารีจีสทรี DS-Off ใช่ไหม

a16z Noah：

ชื่อระดับแรก

การเขียนโปรแกรมเชิงวัตถุและเชิงสินทรัพย์

a16z Eddy Lazzarin：

ดังนั้นฉันอาจจะนำหน้าสุภาษิตไปเล็กน้อย แต่ความสามารถเหล่านี้จะปรากฏให้เห็นในระบบประเภทหรือไม่? ความสามารถเหล่านี้มองเห็นได้ในจุดใดของโปรแกรมในระหว่างการวิเคราะห์แบบคงที่ของโปรแกรม ถ้าฉันเขียนโค้ดเฉพาะสำหรับการสร้างอินสแตนซ์ซึ่งมีความสามารถ เป็นไปได้ไหมที่จะตรวจจับได้ตั้งแต่เนิ่นๆ ว่าฉันกำลังละเมิดความสามารถก่อนที่จะเรียกใช้

a16z Noah：

ใช่ ความสามารถเหล่านี้มองเห็นได้ในระบบประเภทและมองเห็นได้ในระหว่างขั้นตอนการวิเคราะห์แบบคงที่ของโปรแกรม ถ้าฉันเขียนโค้ดสำหรับประเภทอินสแตนซ์เฉพาะที่มีความสามารถ ฉันสามารถทราบได้ตั้งแต่เนิ่นๆ ว่าฉันกำลังละเมิดความสามารถโดยไม่เรียกใช้บนเครื่องเสมือน

Sui CTO Sam Blackshear ：

ให้ฉันตอบคำถามสั้น ๆ แล้วให้ข้อมูลพื้นฐานบางอย่าง คอมไพเลอร์สามารถมองเห็นได้และเป็นส่วนหนึ่งของระบบประเภท นี่เป็นจุดใช้ประโยชน์ที่สำคัญมากสำหรับเรา แต่ฉันต้องการพูดเล็กน้อยเกี่ยวกับโครงสร้างในระบบการเคลื่อนที่ของ Move และวิธีการที่เกี่ยวข้องกับระดับความสามารถที่คล้ายกับการตรวจสอบ ถ้าไม่เป็นการรบกวน

ใน Move คุณมีประเภท struct และเช่นเดียวกับ struct ในภาษาอื่นๆ พวกมันสามารถมีฟิลด์ ฟิลด์ประเภทดั้งเดิม หรือโครงสร้างอื่นๆ สิ่งที่น่าสนใจกว่าและอาจแตกต่างกว่านั้นคือโครงสร้างเหล่านี้มีความสามารถ หากคุณคุ้นเคยกับ Rust ความสามารถจะเหมือนกับการทำเครื่องหมายธุรกรรม พวกเขาประกาศการดำเนินการในตัวที่คุณได้รับอนุญาตให้ดำเนินการกับโครงสร้าง

ที่สำคัญคุณไม่สามารถทำสิ่งเหล่านั้นได้หากคุณไม่มีความสามารถ ความสามารถที่ค่อนข้างง่ายมีความสำคัญมาก นั่นคือความสามารถในการคัดลอก หากคุณมีโทเค็นประเภทหนึ่งหรือบางอย่าง เช่น โทเค็นที่ไม่เป็นเนื้อเดียวกัน ในคอมพิวเตอร์ มันก็เป็นเพียงบิตบางบิต แต่คุณไม่ต้องการให้ผู้อื่นคัดลอกสิ่งนี้ตามต้องการ

ใน Move หากคุณไม่ประกาศโครงสร้างของคุณที่สามารถคัดลอกได้ คุณจะไม่สามารถใช้ "man copy" ที่เทียบเท่าได้

ดังนั้น สิ่งต่างๆ เช่น จำนวนเต็มและสตริงจึงมีสำเนา แต่ถ้าคุณไม่ต้องการให้ประเภทของคุณมีความสามารถในการคัดลอกคุณก็อย่าให้ แล้วยังมีความสามารถอื่นๆ อีก เช่น การละทิ้ง ซึ่งเรียกว่าความสามารถในการปล่อย นั่นคือที่มาของสิ่งที่เป็นประเภทเชิงเส้นที่น่าสนใจ หากคุณต้องการทิ้งบางอย่าง เช่น ทำให้มันเกินขอบเขตหรือเขียนทับมัน คุณก็ให้ความสามารถในการดรอป แต่ถ้าคุณไม่ยอมปล่อย วิธีเดียวที่จะกำจัดมันได้คือการกำหนดนโยบายใดๆ ที่โมดูลประเภทนั้นคาดหวัง

รันไทม์ภาษาทั่วไป (CLR) ตามตัวอย่างเฉพาะ หากคุณต้องการรักษาอุปทานทั้งหมดสำหรับโทเค็นของคุณ คุณจะไม่ให้โทเค็นของคุณลดลง จากนั้นไม่มีวิธีใดที่จะกำจัดมันออกไปได้นอกจากฟังก์ชันเบิร์นที่กำหนดไว้ในโมดูลที่มีการประกาศ ซึ่งจะอัพเดตแหล่งจ่ายทั้งหมด นี่คือเคล็ดลับทั้งหมดที่คุณสามารถใช้ได้ นอกจากนี้ยังมีความสามารถที่เกี่ยวข้องกับสตอเรจอีกหลายอย่าง เช่น สามารถจัดเก็บไว้ในโกลบอลสตอเรจได้หรือไม่ ซึ่งผมจะไม่ลงรายละเอียดเพราะไม่เกี่ยวข้องกับคำถามนี้มากนัก แต่โดยพื้นฐานแล้ว ความสามารถจะถูกรวมเข้ากับโปรแกรมการตรวจสอบ และโปรแกรมการตรวจสอบเข้าใจระบบประเภทและรู้วิธีใช้ระบบประเภทเพื่อแก้ปัญหา ถ้าฉันเขียนข้อความว่ามีเพียงสิ่งเดียว ผู้สอบบัญชีสามารถใช้สิ่งนี้เพื่อพิสูจน์คุณสมบัตินี้ได้ ดังนั้นความสามารถและการรับประกันระบบประเภทจึงไปด้วยกันได้

a16z Noah：

เมื่อคุณพูดถึงดรอป ฉันต้องการพูดถึงสิ่งที่ฉันชอบ คุณสามารถพูดคุยเกี่ยวกับโหมดมันฝรั่งร้อนได้หรือไม่? หากมีของเจ๋งๆ แบบนี้อีก ก็เป็นหนึ่งในของแปลกๆ ที่ฉันโปรดปรานที่ออกมาจาก Move

Sui CTO Sam Blackshear ：

นี่เป็นเรื่องแปลกจริงๆ สิ่งนี้เกี่ยวข้องอย่างใกล้ชิดกับความสามารถ โดยปกติในภาษาการเขียนโปรแกรม คุณไม่สามารถควบคุมได้มากนักว่าค่าของคุณจะถูกทำลายเมื่อใด บางทีคุณอาจมีตัวทำลายที่บอกว่าค่าของคุณจะหายไปเมื่อใด แต่บางครั้งการรับประกันของ destructor ก็อ่อนแอ หรือคุณไม่สามารถพูดง่ายๆ เช่น "คุณไม่สามารถลบประเภทของฉัน" นี่อาจฟังดูเป็นข้อจำกัดที่แปลก แต่จริงๆ แล้วค่อนข้างมีประสิทธิภาพ โดยเฉพาะอย่างยิ่งหากไม่มีการจัดส่งแบบไดนามิก

ฉันจะเริ่มต้นด้วยตัวอย่างมันฝรั่งร้อน จากนั้นเราจะเจาะลึกลงไปถึงสิ่งต่างๆ เช่น สินเชื่อแฟลช หากคุณทำการกู้ยืมเงินแบบแฟลชบน ethereum มันเป็นมาตรฐาน คุณสามารถแทนที่มันได้ โดยพื้นฐานแล้วคุณเปิดเผยฟังก์ชันการโทรกลับ เช่น สัญญาเงินกู้แบบแฟลช คุณให้เงินฉัน ฟังก์ชันการโทรกลับของฉันแล้วได้เงินคืน และใน Move วิธีที่คุณทำคือมีคนไปทำสัญญาเงินกู้แบบแฟลชและพูดว่า "เฮ้ ให้เงินฉัน 53 เหรียญ แต่พวกเขายังให้สิ่งที่พวกเขาเรียกว่าวัตถุมันฝรั่งร้อน

วัตถุมันฝรั่งร้อนเป็นโครงสร้าง มันไม่มีความสามารถ มันไม่ได้คัดลอก ดังนั้นคุณจึงไม่สามารถคัดลอกได้ ไม่มีความสามารถในการจัดเก็บข้อมูลส่วนกลาง คุณไม่สามารถซ่อนได้เหมือนกับที่คุณทำสัญญาไว้ มันไม่มีความสามารถในการดรอป ดังนั้นคุณจึงไม่สามารถดรอปได้ ดังนั้นวิธีเดียวที่จะกำจัดมันได้คือส่งมันกลับไปที่สัญญายืมแฟลช ให้คุณส่งรหัสของสัญญาเงินกู้แฟลชคืนโดยบังคับให้คุณชำระคืน หากคุณไม่ทำ โปรแกรมจะล้มเหลวในขณะรันไทม์และจะไม่ผ่านการตรวจสอบประเภทด้วยซ้ำ ดังนั้นนี่คือความสามารถที่น่าสนใจในการควบคุมการทำลายคุณค่าของคุณ ในฐานะโปรแกรมเมอร์ สามารถกำหนดความไม่แปรเปลี่ยนตามอำเภอใจได้ทุกเมื่อ เมื่อถึงเวลาที่วัตถุเหล่านี้สามารถถูกทำลายได้ สิ่งเหล่านี้ดูเหมือนรูปแบบการเรียก API ที่มีความเฉพาะเจาะจงมาก อีกตัวอย่างที่ชัดเจนมากคือ ถ้าคุณต้องการบังคับให้ใครซักคนโทรล็อคหลังจากโทรปลดล็อค แต่ทำทุกอย่างที่พวกเขาต้องการ คุณก็สามารถทำได้เช่นกัน

a16z Eddy Lazzarin：

เมื่อฉันได้ยินเกี่ยวกับรูปแบบ "มันฝรั่งร้อน" เป็นครั้งแรก ฉันคิดถึงการใช้ตัวล็อคที่น่าสนใจ เช่น "mute texas" ซึ่งใช้ประโยชน์จากระบบการพิมพ์เพื่อวัตถุประสงค์ด้านการยศาสตร์เท่านั้น เพื่อบังคับใช้กับวัตถุเฉพาะ วิธีการนี้เกือบจะเป็น ความต้องการของระดับตรรกะทางธุรกิจ ฉันคิดว่ามันฉลาดมาก ให้ความรู้สึกทันสมัยมาก เป็นการใช้การยศาสตร์คุณภาพสูงในภาษาโปรแกรมที่ยังไม่มีในภาษาโปรแกรมแบบดั้งเดิม แต่เห็นได้ชัดว่ามีประโยชน์มากในสภาพแวดล้อมสัญญาอัจฉริยะ ค่าเพราะมี เป็นข้อกำหนดเชิงตรรกะมากกว่าที่นี่ โดยพิจารณาถึงคุณค่าและความปลอดภัยที่อาจเกี่ยวข้อง

Sui CTO Sam Blackshear ：

ก่อนที่เราจะพูดถึงตัวอย่างที่เป็นรูปธรรม คุณช่วยอธิบายภาพรวมระดับสูงอย่างรวดเร็วของระบบออบเจกต์ของเราได้ไหม สิ่งของคืออะไรและใครเป็นเจ้าของ? อ็อบเจ็กต์เป็นเจ้าของออบเจ็กต์อื่นอย่างไร และโมดูลทำงานร่วมกับออบเจ็กต์ได้อย่างไร

a16z Noah：

ใช่แล้ว นี่เป็นเรื่องเกี่ยวกับภาษาถิ่นของภาษา Move โดยเฉพาะ Sui Move พื้นฐานของสิ่งนี้คือโครงสร้างของที่เก็บข้อมูลส่วนกลางที่แตกต่างจากโครงร่างที่เก็บข้อมูลส่วนกลางของภาษาถิ่นเดิมของ Move ที่เราเคยใช้ รูปแบบพื้นที่เก็บข้อมูลส่วนกลางของ Move ดั้งเดิมนั้นคล้ายกับรูปแบบองค์กรที่ใช้โดย Ethereum

ใน Sui Move เราต้องการใส่จุดศูนย์กลางของสิ่งต่าง ๆ ลงบนวัตถุ โดยได้รับการจูงใจอย่างสูงให้สามารถแสดงการเข้าถึงแบบละเอียดได้อย่างแม่นยำที่สุดเท่าที่จะเป็นไปได้ สิ่งนี้ช่วยให้คุณทำหลายสิ่งหลายอย่างที่เราจะไม่ลงรายละเอียดในพอดคาสต์นี้ เช่น ประมวลผลธุรกรรมอย่างมีประสิทธิภาพมากขึ้น บอกผู้ใช้กระเป๋าเงินว่าจะทำธุรกรรมอะไร เป็นต้น

ดังนั้นใน Sui Move โครงสร้างหน่วยเก็บข้อมูลส่วนกลางจึงเป็นการแมปจาก ID อ็อบเจ็กต์ไปยัง ID อ็อบเจ็กต์ ออบเจกต์เป็นเพียงการย้ายโครงสร้างที่มีความสามารถที่เรียกว่าคีย์ มันบอกว่า "เฮ้ ฉันเป็นกุญแจได้" มันสามารถปรากฏในพูลอ็อบเจกต์ส่วนกลาง จากนั้นแต่ละออบเจ็กต์ต้องมี ID ที่ไม่ซ้ำกันทั่วโลก จากนั้นคุณสามารถเขียนฟังก์ชันจุดเริ่มต้นสำหรับโมดูลของคุณที่สามารถใช้วัตถุเป็นอินพุตได้โดยตรง หากคุณกำลังเขียนธุรกรรม WeRunTime นี้จะมีรหัสวัตถุ หากคุณกำลังเขียนธุรกรรม WeRunTime สามารถใช้ ID เหล่านี้เพื่อแปลง ID เป็นวัตถุและแทรกลงในฟังก์ชัน

ประสบการณ์การเขียนโปรแกรมเชิงวัตถุและเชิงสินทรัพย์นี้ยอดเยี่ยมมาก มันตรงไปตรงมากว่าที่เราทำในเวอร์ชัน Move ดั้งเดิมมาก คุณยังกล่าวถึงออบเจ็กต์พาเรนต์และลูกและลำดับชั้นของอ็อบเจ็กต์ สิ่งนี้มีประโยชน์มาก แต่คุณยังต้องการแสดงสิ่งต่างๆ เช่น คอลเลกชันขนาดใหญ่

สมมติว่าฉันกำลังสร้างรีจีสทรีแบบ DNS และฉันต้องการมีรายการนับล้านรายการ เรามีขีดจำกัดของขนาดวัตถุ วัตถุอาจมีขนาดได้หลายเมกะไบต์ แต่ไม่เกินนี้ แต่ถ้าคุณมีบางอย่างเช่น DNS ก็ควรจะมีขนาดใหญ่โดยพลการ วิธีที่เรานำเสนอโดยใช้ความสัมพันธ์ของอ็อบเจกต์พ่อแม่ลูก โดยพื้นฐานแล้วเรามีวิธีการดูออบเจกต์เป็นแผนที่ที่แตกต่างกัน จากนั้นคุณสามารถเพิ่มคีย์ด้วยช่องไดนามิกไดนามิก สิ่งนี้คล้ายกับจาวาสคริปต์อย่างมาก เราสามารถพูดได้ว่า วัตถุนี้มีแผนที่อยู่ในนั้น แล้วฉันสามารถใส่บางอย่างลงในแผนที่นี้ได้ หรือคุณอาจพูดได้ว่า เมื่อฉันกำหนดวัตถุนี้ มันมีสิบฟิลด์ แต่จริงๆ แล้วฉันต้องการเพิ่มฟิลด์ใหม่ในภายหลัง และฉันจะอัปเกรดสัญญาของฉัน ฉันต้องการเพิ่มฟิลด์ใหม่หลังจากข้อเท็จจริง

วิธีที่เรานำเสนอคือความสัมพันธ์ของอ็อบเจกต์พาเรนต์และลูก และออบเจ็กต์ย่อยแต่ละรายการจะเชื่อมโยงกับค่าคีย์ ซึ่งสามารถเป็นค่าย้ายใดๆ ก็ได้ เช่น สตริงหรือ u 64 หรือสิ่งอื่นๆ ที่คุณต้องการ

a16z Noah：

ใช่ เกี่ยวข้องกับแนวคิดของอ็อบเจ็กต์พาเรนต์ สิ่งที่ฉันคิดว่าทำให้ "ช่วงเวลายูเรก้า" ของฉันเป็นจริงเมื่อไม่กี่เดือนก่อนเมื่อฉันใช้เวลาขุดคุ้ย Sui Move และเปลี่ยนจากการเขียนโปรแกรมที่มีอ็อบเจกต์เดียวเป็น เพื่อนำชุดการ์ดสไตล์ Uniswap V2 ส่วนใหญ่กลับมาใช้ใหม่ โครงการเล็ก ๆ ที่ฉันทำทำให้ฉันรู้ว่าการมีวัตถุสิ่งของมีค่าเพียงใด โปรเจ็กต์นี้มีเพียงสามอย่างคือ แม่กุญแจ ทอง และที่กั้นเปล่าๆ มีโมดูลพื้นฐานที่คุณสามารถจินตนาการถึงการสร้างทองคำที่เป็นของวัตถุหลักได้ จากนั้นวิธีเดียวที่จะดึงทองคำออกมาคือต้องมีฟังก์ชันที่จับแม่กุญแจและกุญแจ และเห็นได้ชัดว่าทำลายแม่กุญแจ ให้ทองคำแก่คุณ และจากนั้นก็ทำลายกุญแจของคุณ วิธีการนี้น่าสนใจมาก ด้วยวิธีนี้ คุณสามารถอธิบายความสัมพันธ์ระหว่างออบเจกต์ และอธิบายการอนุญาตได้อย่างละเอียด

Sui CTO Sam Blackshear ：

ชื่อระดับแรก

การเปรียบเทียบความปลอดภัยของ Move และ Solidity

โฮสต์ Sonal Chokshi:

อย่างไรก็ตาม ก่อนที่ฉันจะมาที่นิตยสาร Wired ฉันใช้เวลา 6 วันใน Xerox Park ซึ่งทำให้ฉันนึกถึงประวัติของการเขียนโปรแกรมเชิงวัตถุเล็กน้อย สิ่งที่คุณเพิ่งพูดไปนั้นน่าสนใจมาก เพราะพวกเขาคิดค้น Smalltalk ซึ่งเป็นผู้นำในยุคแรกๆ ของเฟรมเวิร์กเชิงวัตถุจำนวนมากในปัจจุบัน อย่างไรก็ตาม มีหัวข้ออื่นที่คุณต้องการพูดคุยอีกหรือไม่?

a16z Noah：

ฉันแค่มีคำถามทั่วไป แต่จริงๆ แล้วมีการแฮ็กและเรื่องดังกล่าวเกิดขึ้นในโลกของ EVM ที่คุณคิดว่าจะไม่เกิดขึ้นในครั้งแรกหรือไม่หากคุณใช้ Move เนื่องจากระบบประเภท

Sui CTO Sam Blackshear ：

ในโลกของ EVM เราได้พูดถึงการจัดสรรแบบไดนามิกและการกลับเข้าที่ใหม่แล้ว Move กำจัดการกลับเข้าที่ใหม่ด้วยการสร้าง ปัญหาที่เกี่ยวข้องกับการกลับเข้าที่ใหม่จะหมดไป และฉันคิดว่าผู้คนกำลังทำงานได้ดี ตอนนี้ฉันคิดว่ามันหลีกเลี่ยงปฏิกิริยาและการดู

a16z Eddy Lazzarin：

แต่คุณช่วยอธิบายได้ไหมว่าทำไม Move ทำให้ปัญหาเหล่านี้เป็นไปไม่ได้?

Sui CTO Sam Blackshear ：

re-entry ใช่ไหม? เกิดอะไรขึ้น? คุณเขียนโค้ดและเรียกใช้ฟังก์ชันบางอย่าง ปัญหาคือมีคนนำฟังก์ชันที่คุณไม่ได้คาดหวังไว้ตั้งแต่แรกไปใช้ เพื่อให้ใช้งานได้ การเรียกใช้ฟังก์ชันต้องเป็นไดนามิก มันต้องเรียกรหัส ซึ่งโดยพื้นฐานแล้วคือตัวชี้ฟังก์ชันที่ผู้โทรให้มา ซึ่งอาจเป็นผู้โจมตี หากคุณไม่มีการเรียกใช้ฟังก์ชันไดนามิกใดๆ หากคุณทราบเป้าหมายของการเรียกใช้ฟังก์ชันอยู่เสมอ สิ่งนี้จะไม่เกิดขึ้นเลย เช่นเดียวกับสิ่งที่คุณเรียกใช้ คุณอาจไม่รู้ว่าโค้ดทำอะไร แต่คุณรู้ว่ามันคืออะไร คือ คุณสามารถทดสอบ ตรวจสอบได้ ทุกอย่างอยู่ที่นั่น โดยพื้นฐานแล้ว เป็นไปไม่ได้ที่ผู้อื่นจะให้รหัสที่ทำให้โมดูลของคุณทำงานแตกต่างจากที่คุณคาดไว้ เพราะมันเป็นเพียงการเรียกฟังก์ชันแบบสแตติก เจ๋ง.

a16z Eddy Lazzarin：

ดังนั้นสิ่งนี้จึงช่วยขจัดการโจมตีแบบย้อนกลับซึ่งเป็นปัญหานิรันดร์ในการพัฒนา Solidity

Sui CTO Sam Blackshear ：

ใช่ ฉันคิดว่าโดยทั่วไปแล้ว Move จะช่วยขจัดปัญหาการตรวจสอบการอนุญาตที่ขาดหายไปในการเขียนโปรแกรมสัญญาอัจฉริยะ มีบางครั้งที่คุณเขียนโค้ดบางอย่างที่คุณต้องส่งผ่านบัญชีทั้งหมดอย่างชัดเจน และคุณต้องพูดว่า ฉันมีสิทธิ์ไหมที่จะทำสิ่งนี้ คุณเขียนรหัสง่ายๆ แต่ลืมตรวจสอบว่าผู้ส่งเป็นใคร หรือบุคคลนั้นสามารถเข้าถึงได้หรือไม่ ฉันคิดว่าปัญหาเหล่านี้เกิดขึ้นค่อนข้างบ่อย

ดังนั้นใน Move ข้อมูลความเป็นเจ้าของวัตถุจึงถูกจัดเก็บไว้ในข้อมูลเมตาของวัตถุ นี่ไม่ใช่สิ่งที่โปรแกรมเมอร์สามารถควบคุมได้

เมื่อคุณดูวัตถุเหล่านี้ พวกเขาจะบอกว่า "ฉันเป็นเจ้าของที่อยู่นี้" หรือ "ฉันเป็นเจ้าของวัตถุอื่นนี้" หรือ "ฉันเป็นวัตถุที่ใช้ร่วมกัน" หรือ "ฉันเป็นวัตถุที่ไม่เปลี่ยนรูป ". โปรแกรมเมอร์ไม่สามารถลืมตรวจสอบเจ้าของได้ เนื่องจากรันไทม์จะตรวจสอบก่อนที่จะรันโค้ดที่ส่งผ่านในอ็อบเจกต์ Sui นี้ รันไทม์กล่าวว่า "ฉันเห็นการแลกเปลี่ยนนี้ ฉันเห็นวัตถุทั้งหมดที่พวกเขาต้องการใช้ ฉันกำลังตรวจสอบเพื่อดูว่าพวกเขาเป็นเจ้าของวัตถุเหล่านี้จริงๆ หรือมีวัตถุที่เป็นของกลาง ดังนั้นพวกเขาจึงได้รับอนุญาตให้ใช้

การตรวจสอบสิทธิ์หลายรายการที่เราขอให้โปรแกรมเมอร์ทำใน We Run Time และการตรวจสอบเหล่านั้นเป็นสิ่งที่ลืมไม่ได้ ผมคิดว่าสิ่งนี้สำคัญมาก เพราะสิ่งที่ป้องกันยากที่สุดคือสเปคที่โปรแกรมเมอร์ไม่ได้บอกคุณ บรรทัดฐานเหล่านี้ง่ายต่อการลืม และยากที่จะตรวจจับโดยใช้การวิเคราะห์แบบคงที่หรือวิธีการอื่นๆ เนื่องจากคุณต้องการใครสักคนที่จะคอยค้นหาว่าบรรทัดฐานใดมีความสำคัญอยู่เสมอ

โฮสต์ Sonal Chokshi:

และอีกอย่าง ฉันคิดว่ามันน่าสนใจมากที่จะเกิดอะไรขึ้นในระดับองค์กร เมื่อผู้คนร่วมมือกันในลักษณะนี้มากขึ้นในแง่ของการวางแผนระยะยาวหรือระยะใกล้ เพราะมันกระจายอย่างเห็นได้ชัด ไม่ใช่แค่บริษัทเดียว บางครั้งผู้คนก็ร่วมมือกัน แต่ฉันหมายความว่า เมื่อคุณนึกถึงวิธีเก่าๆ ตอนนี้ คุณมีเหมือนนักพัฒนาซอฟต์แวร์และแนวทางปฏิบัติที่ดีที่สุดเหล่านี้ทั้งหมด