Forward the Original Title：解读Starknet智能合约模型与原生AA：特立独行的技术巨匠

ผู้เขียนต้นฉบับ: Shew & Faust, ที่ปรึกษา Web3: CryptoNerdCn, นักพัฒนาหลัก Starknet, ผู้ก่อตั้ง Browser-Side Cairo Development Platform WASM Cairo

บทคัดย่อ:

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

รูปแบบสัญญาอัจฉริยะที่กล่าวถึงข้างต้นของ Starknet เอื้อต่อการนํารหัสกลับมาใช้ใหม่การนําสถานะสัญญากลับมาใช้ใหม่การแบ่งชั้นการจัดเก็บและการตรวจจับสัญญาขยะ นอกจากนี้ยังเอื้อต่อการตระหนักถึงการเช่าพื้นที่เก็บข้อมูลและการขนานธุรกรรม แม้ว่าสองสัญญาหลังจะยังไม่ได้ดําเนินการ แต่โครงสร้างของสัญญาอัจฉริยะของไคโรได้สร้าง "เงื่อนไขที่จําเป็น" สําหรับพวกเขา · มีเพียงบัญชีสัญญาอัจฉริยะในห่วงโซ่ Starknet และไม่มีบัญชี EOA รองรับนามธรรมบัญชี AA ระดับเนทีฟตั้งแต่เริ่มต้น แผน AA รวมแนวคิดของ ERC-4337 ในระดับหนึ่งทําให้ผู้ใช้สามารถเลือกโซลูชันการประมวลผลธุรกรรมที่กําหนดเองได้สูง เพื่อป้องกันสถานการณ์การโจมตีที่อาจเกิดขึ้น Starknet ได้ใช้มาตรการตอบโต้มากมายและทําการสํารวจที่สําคัญในระบบนิเวศ AA

ข้อความ: หลังจากการออกโทเค็นบน Starknet STRK ค่อยๆกลายเป็นองค์ประกอบที่ขาดไม่ได้ในสายตาของผู้สังเกตการณ์ Ethereum ดาว Ethereum Layer 2 ดวงนี้เป็นที่รู้จักในด้านทัศนคติที่ "เป็นอิสระ" และ "ไม่สนใจประสบการณ์ของผู้ใช้" ได้แกะสลักอาณาเขตของตัวเองอย่างเงียบ ๆ ในระบบนิเวศ Layer 2 ที่เฟื่องฟูซึ่งเข้ากันได้กับ EVM เนื่องจากการละเลยผู้ใช้มากเกินไปและแม้แต่การตั้งค่าช่อง "ขอทานอิเล็กทรอนิกส์" อย่างเปิดเผยบน Discord Starknet จึงเคยถูกวิพากษ์วิจารณ์จากชุมชน ท่ามกลางข้อกล่าวหาว่า "ไร้มนุษยธรรม" ความเชี่ยวชาญทางเทคนิคที่ลึกซึ้งของมันดูเหมือนจะลดคุณค่าลงทันทีราวกับว่ามีเพียง UX และการสร้างความมั่งคั่งเท่านั้นที่เป็นทุกอย่าง บรรทัดจาก "The Temple of the Golden Pavilion" - "ความจริงที่คนอื่นไม่เข้าใจเป็นแหล่งความภาคภูมิใจเพียงอย่างเดียวของฉัน" - เกือบจะเป็นภาพเหมือนตนเองของ Starknet อย่างไรก็ตามการตั้งค่าเรื่องเล็ก ๆ น้อย ๆ เหล่านี้ของโลกขึ้นอยู่กับรสนิยมทางเทคนิคของ geeks รหัส Starknet และ StarkEx ในฐานะผู้บุกเบิก ZK Rollup เกือบจะเป็นสมบัติในสายตาของผู้ที่ชื่นชอบไคโร ในใจของนักพัฒนาเกมบล็อกเชนบางคน Starknet และ Cairo เป็นเพียงทุกสิ่งใน Web3 ที่เหนือกว่า Solidity และ Move ช่องว่างที่ใหญ่ที่สุดระหว่าง "นักวิชาการด้านเทคนิค" และ "ผู้ใช้" ในปัจจุบันส่วนใหญ่เกิดจากการขาดความเข้าใจของผู้คนเกี่ยวกับ Starknet ด้วยความสนใจในเทคโนโลยีบล็อกเชนและการสํารวจมูลค่าของ Starknet ผู้เขียนบทความนี้เริ่มต้นจากรูปแบบสัญญาอัจฉริยะของ Starknet และ AA ดั้งเดิมเพื่อร่างโซลูชันทางเทคนิคและการออกแบบกลไกสั้น ๆ โดยมีเป้าหมายเพื่อแสดงคุณสมบัติทางเทคนิคของ Starknet ต่อผู้คนจํานวนมากขึ้นในขณะเดียวกันก็หวังว่าจะช่วยให้ผู้คนเข้าใจ "โลนเรนเจอร์ที่เข้าใจผิด" นี้ หลังจากการแนะนําสั้น ๆ เกี่ยวกับภาษาไคโรในส่วนต่อ ๆ ไปเราจะมุ่งเน้นไปที่การหารือเกี่ยวกับรูปแบบสัญญาอัจฉริยะของ Starknet และนามธรรมบัญชีเนทีฟโดยอธิบายว่า Starknet บรรลุ AA ดั้งเดิมได้อย่างไร หลังจากอ่านบทความนี้ผู้อ่านจะเข้าใจด้วยว่าทําไมวลีความจําจากกระเป๋าเงินที่แตกต่างกันจึงไม่สามารถผสมใน Starknet ได้ แต่ก่อนที่จะแนะนํานามธรรมบัญชีพื้นเมืองก่อนอื่นเรามาทําความเข้าใจภาษาไคโรที่เป็นนวัตกรรมใหม่ที่สร้างขึ้นโดย Starknet ในกระบวนการพัฒนาของไคโรมีรุ่นแรกที่เรียกว่า Cairo0 ตามด้วยรุ่นที่ทันสมัย ไวยากรณ์โดยรวมของเวอร์ชันสมัยใหม่ของไคโรนั้นคล้ายกับ Rust และเป็นภาษา ZK ที่หลากหลาย นอกจากจะใช้ในการเขียนสัญญาอัจฉริยะบน Starknet แล้วยังสามารถใช้สําหรับการพัฒนาแอปพลิเคชันทั่วไปได้อีกด้วย ตัวอย่างเช่นเราสามารถพัฒนาระบบยืนยันตัวตน ZK โดยใช้ภาษาไคโรและโปรแกรมนี้สามารถทํางานบนเซิร์ฟเวอร์ของเราเองโดยไม่ต้องขึ้นอยู่กับเครือข่าย StarkNet อาจกล่าวได้ว่าโปรแกรมใด ๆ ที่ต้องการคุณสมบัติการคํานวณที่ตรวจสอบได้สามารถใช้งานได้โดยใช้ภาษาไคโร และไคโรอาจเป็นภาษาการเขียนโปรแกรมที่เอื้อต่อการสร้างหลักฐาน ZK มากที่สุด

จากมุมมองของกระบวนการคอมไพล์ Cairo ใช้วิธีการคอมไพล์บนฐานภาษากลาง ตามที่แสดงในรูปด้านล่าง Sierra ในรูปภาพเป็นการแสดงภาพระหว่าง (IR) ในกระบวนการคอมไพล์ภาษา Cairo และ Sierra จะถูกคอมไพล์เป็น represent รหัสที่ต่ำกว่า เรียกว่า CASM ซึ่งทำงานโดยตรงบนอุปกรณ์โหนด Starknet

การแนะนําเซียร์ราเป็นตัวแทนระดับกลางทําให้ภาษาไคโรเพิ่มคุณสมบัติใหม่ได้ง่ายขึ้น ในหลายกรณีจําเป็นต้องจัดการภาษากลางเซียร์ราโดยไม่ต้องเปลี่ยนรหัส CASM พื้นฐานโดยตรง สิ่งนี้ช่วยประหยัดปัญหาได้มากและไคลเอนต์โหนดของ Starknet ไม่จําเป็นต้องอัปเดตบ่อยๆ ด้วยวิธีนี้การทําซ้ําบ่อยครั้งของภาษาไคโรสามารถทําได้โดยไม่ต้องเปลี่ยนตรรกะพื้นฐานของ StarkNet ห้องสมุดมาตรฐานของไคโรยังมีโครงสร้างข้อมูลพื้นฐานมากมายที่จําเป็นสําหรับนามธรรมของบัญชี นวัตกรรมอื่น ๆ ของไคโรรวมถึงโซลูชันทางทฤษฎีที่เรียกว่า Cairo Native ซึ่งวางแผนที่จะรวบรวมไคโรเป็นรหัสเครื่องระดับต่ําที่สามารถปรับให้เข้ากับอุปกรณ์ฮาร์ดแวร์ต่างๆได้ โหนด Starknet จะไม่ต้องพึ่งพาเครื่องเสมือน CairoVM เมื่อเรียกใช้สัญญาอัจฉริยะ สิ่งนี้สามารถปรับปรุงความเร็วในการเรียกใช้โค้ดได้อย่างมาก [ยังอยู่ในขั้นตอนทางทฤษฎีและยังไม่ได้ดําเนินการ]

โมเดลสัญญาอัจฉริยะของ Starknet: ลบโลจิกของโค้ดและการเก็บ state

ไม่เหมือน Ethereum-compatible chains, Starknet ได้ทำนวััตกรรมที่น่าประทับใจในการออกแบบระบบสัญญาอัจฉริยะของตน, โดยใหญ่โตในการเตรียมการสำหรับ AA ภายในและคุณสมบัติที่กำลังจะมาเช่นการประมวลผลธุรกรรมแบบขนาน ที่นี่, สำคัญที่จะเข้าใจว่า, ไม่เหมือนโซ่สาธารณะแบบดั้งเดิมเช่น Ethereum, การใช้งานสัญญาอัจฉริยะบน Starknet กำหนดกระบวนการที่แตกต่าง ขอให้เราพิจารณาตัวอย่างการใช้งานสัญญาอัจฉริยะบน Ethereum

1. นักพัฒนาเขียนโค้ดสัญญาอัจฉริยะในท้องถิ่นและคอมไพล์โปรแกรม Solidity เป็นไบต์โค้ด EVM โดยใช้เอดิเตอร์ ไบต์โค้ดนี้จึงสามารถเข้าใจและประมวลผลได้โดยตรงโดย EVM

1. นักพัฒนาเริ่มกระบวนการทำธุรกรรมเพื่อใช้สัญญาอัจฉริยะ การสร้างเป็นการนำไฟล์ EVM bytecode ที่คอมไพล์แล้วไปใช้บนเชน Ethereum

แหล่งที่มา: not-satoshi.com

แม้ว่าสัญญาอัจฉริยะของ Starknet จะเป็นไปตามแนวคิดของ "คอมไพล์ก่อนแล้วจึงปรับใช้" แต่สัญญาอัจฉริยะจะถูกปรับใช้บนห่วงโซ่ในรูปแบบของ CASM bytecode ที่สนับสนุนโดย CairoVM อย่างไรก็ตามมีความแตกต่างอย่างมากระหว่างเครือข่ายที่เข้ากันได้กับ Starknet และ EVM ในวิธีการโทรและโหมดการจัดเก็บสถานะของสัญญาอัจฉริยะ สัญญาอัจฉริยะ Ethereum = ตรรกะทางธุรกิจ + ข้อมูลสถานะ ตัวอย่างเช่นสัญญา USDT ไม่เพียง แต่ใช้ฟังก์ชั่นทั่วไปเช่นการโอนและการอนุมัติ แต่ยังจัดเก็บสถานะสินทรัพย์ของผู้ถือ USDT ทั้งหมด รหัสและรัฐถูกรวมเข้าด้วยกันซึ่งนํามาซึ่งปัญหามากมาย ประการแรกไม่เอื้อต่อการอัปเกรดสัญญา DAPP และการโยกย้ายสถานะและไม่เอื้อต่อการประมวลผลธุรกรรมแบบขนาน มันเป็นภาระทางเทคนิคที่หนักหน่วง

ในการตอบสนองต่อสิ่งนี้ Starknet ได้ปรับปรุงวิธีการจัดเก็บสถานะ ในโซลูชันการใช้งานสัญญาอัจฉริยะตรรกะทางธุรกิจของ DApps จะถูกแยกออกจากสถานะสินทรัพย์อย่างสมบูรณ์และจัดเก็บแยกต่างหาก ประโยชน์ของวิธีการนี้เห็นได้ชัด: ประการแรกช่วยให้ระบบสามารถแยกแยะได้อย่างรวดเร็วว่ามีการปรับใช้โค้ดที่ซ้ํากันหรือซ้ําซ้อนหรือไม่ นี่คือวิธีการทํางาน: ใน Ethereum สัญญาอัจฉริยะประกอบด้วยทั้งตรรกะทางธุรกิจและข้อมูลสถานะ หากสัญญาหลายฉบับมีตรรกะทางธุรกิจที่เหมือนกัน แต่ข้อมูลสถานะที่แตกต่างกันแฮชของพวกเขาก็จะแตกต่างกันทําให้ระบบยากที่จะตรวจสอบว่ามี "สัญญาขยะ" อยู่หรือไม่ อย่างไรก็ตามในโซลูชันของ Starknet รหัสและข้อมูลสถานะจะถูกแยกออกจากกันทําให้ระบบสามารถตรวจจับได้ง่ายขึ้นว่ามีการปรับใช้รหัสเดียวกันหลายครั้งตามแฮชของส่วนรหัสหรือไม่ วิธีนี้จะช่วยป้องกันการปรับใช้โค้ดที่ซ้ํากันและประหยัดพื้นที่จัดเก็บบนโหนด Starknet

ในระบบสัญญาอัจฉริยะของ Starknet การใช้งานและการใช้งานของสัญญาถูกแบ่งออกเป็นสามขั้นตอน: “คอมไพล์, ประกาศ, และนำไปใช้.” หากผู้ออกสินทรัพย์ต้องการนำสัญญา Cairo ไปใช้งาน พวกเขาจะคอมไพล์รหัส Cairo ที่เขียนลงในรูปแบบ Sierra และรหัส bytecode ระดับต่ำ CASM บนอุปกรณ์ท้องถิ่นของพวกเขาก่อน จากนั้นผู้นำสัญญาไปใช้งานจะเผยแพร่ธุรกรรม “ประกาศ” โดยการนำ bytecode ของสัญญา CASM และรหัส Sierra ระดับกลางลงบนโซ่ โดยมีชื่อว่า Contract Class ให้

(Source: เว็บไซต์อย่างเป็นทางการของ Starknet)

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

หลังจากที่สัญญาอัจฉริยะถูกแยกเป็นคลาสและอินสแตนซ์ ตรรกะธุรกิจและข้อมูลสถานะถูกแยกออกจากกัน นำคุณลักษณะต่อไปนี้มาสู่ Starknet:

1. เป็นประโยชน์ต่อการทำให้ระบบชั้นการจัดเก็บและ "ระบบเช่าที่เก็บ" เป็นจริง

การเรียกชั้นการจัดเก็บข้อมูลต่าง ๆ หมายถึง นักพัฒนาสามารถวางข้อมูลในตำแหน่งที่กำหนดเองตามความต้องการของตนเอง เช่น ภายใต้เชือก Starknet chain StarkNet พร้อมที่จะเข้ากันได้กับ DA layers เช่น Celestia และ DAPP developers สามารถเก็บข้อมูลในเลเยอร์ DA ของบุคคลที่สามเหล่านี้ ตัวอย่างเช่น เกมสามารถเก็บข้อมูลสินทรัพย์ที่สำคัญสุดในเครือข่ายหลัก Starknet และเก็บข้อมูลอื่น ๆ ในเลเยอร์ DA นอกเชือกเช่น Celestia โซลูชั่นนี้ของการปรับแต่งเลเยอร์ DA ตามความต้องการด้านความปลอดภัยถูกตั้งชื่อว่า “Volition” โดย Starknet

ระบบเช่าที่เก็บข้อมูลที่เรียกว่าหมายความว่าทุกคนควรที่จะยังคงชำระค่าเช่าสำหรับพื้นที่เก็บข้อมูลที่พวกคุณครองครอยอยู่ พื้นที่บนเชือกเท่าใดที่คุณครองครอย คุณควรทึ่理ึกต่อการชำระค่าเช่า

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

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

1. บรรลุความสามารถในการนำโค้ดไปใช้ซ้ำได้อย่างแท้จริง และลดการใช้สัญญาขยะ

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

1. การใช้อีกครั้งของ “สถานะ” ของสัญญาจริง

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

เพื่อเปลี่ยนตรรกะธุรกิจของสัญญา Ethereum บางครั้งจำเป็นต้อง “นอกเหนือ” ตรรกะธุรกิจไปยังสัญญาหน่วยงาน และเปลี่ยนตรรกะธุรกิจของสัญญาหลักโดยการเปลี่ยนแปลงสัญญาหน่วยงานที่ขึ้นอยู่ อย่างไรก็ตามวิธีนี้ไม่เพียงพอและไม่ “เกิดธรรมชาติ” พอดี

Source: wtf Academy

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

1. เหมาะสมสำหรับการประมวลผลขั้นต่างๆ พร้อมกัน

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

การใช้บัญชี AA และการติดตั้งสัญญาบัญชีของ Starknet

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

หากเรามองผลิตภัณฑ์ชั้นยอด เช่น Starknet หรือ zkSyncEra “Native AA” chain จะเห็นได้ชัดว่ามีความแตกต่าง: คือ Starknet และ zkSyncEra มีประเภทบัญชีที่เป็นสมบัติเดียวกัน บนเชือกมีเพียงบัญชีสัญญาอัจฉริยะเท่านั้น ไม่มีบัญชี EOA ตั้งแต่เริ่มต้น (zkSync Era จะติดตั้งชุดรหัสสัญญาโดยค่าเริ่มต้นบนบัญชีที่สร้างขึ้นโดยผู้ใช้เพื่อจำลองลักษณะของบัญชี EOA ของ Ethereum เพื่อให้เข้ากันได้กับ Metamask)

อย่างไรก็ตาม Starknet ไม่ได้พิจารณาความเข้ากันได้โดยตรงกับอุปกรณ์ต่อพ่วง Ethereum เช่น Metamask เมื่อผู้ใช้ใช้กระเป๋าเงิน Starknet เป็นครั้งแรกบัญชีสัญญาเฉพาะจะถูกปรับใช้โดยอัตโนมัติ กล่าวอีกนัยหนึ่งอินสแตนซ์สัญญาที่กล่าวถึงก่อนหน้านี้จะถูกปรับใช้และอินสแตนซ์นี้เชื่อมโยงกับคลาสสัญญาที่ปรับใช้ล่วงหน้าโดยโครงการกระเป๋าเงิน ผู้ใช้สามารถเรียกฟังก์ชันบางอย่างที่เขียนในชั้นเรียนได้โดยตรง ตอนนี้เรามาเจาะลึกหัวข้อที่น่าสนใจ: เมื่ออ้างสิทธิ์ STRK airdrops หลายคนพบว่ากระเป๋าเงิน Argent และ Braavos เข้ากันไม่ได้ การนําเข้าความจําจาก Argent ไปยัง Braavos ไม่อนุญาตให้ส่งออกบัญชีที่เกี่ยวข้องส่วนใหญ่เกิดจากอัลกอริธึมการสร้างบัญชีที่แตกต่างกันที่ใช้โดย Argent และ Braavos ส่งผลให้ที่อยู่บัญชีที่แตกต่างกันสร้างขึ้นจากความจําเดียวกัน โดยเฉพาะใน Starknet ที่อยู่สัญญาที่ปรับใช้ใหม่สามารถได้รับผ่านอัลกอริธึมที่กําหนดได้ดังนี้:

ฟังก์ชัน 'pedersen()' ที่กล่าวถึงข้างต้นเป็นอัลกอริทึมแฮชที่ใช้งานง่ายในระบบ ZK กระบวนการสร้างบัญชีเกี่ยวข้องกับการให้พารามิเตอร์พิเศษหลายอย่างแก่ฟังก์ชัน pedersen เพื่อสร้างแฮชที่เกี่ยวข้องซึ่งเป็นที่อยู่บัญชีที่สร้างขึ้น ภาพด้านบนแสดงพารามิเตอร์ที่ใช้โดย Starknet เพื่อสร้าง "ที่อยู่สัญญาใหม่" 'deployer_address' หมายถึงที่อยู่ของ "ผู้ปรับใช้สัญญา" พารามิเตอร์นี้อาจว่างเปล่าซึ่งหมายความว่าแม้ว่าคุณจะไม่มีบัญชีสัญญา Starknet ล่วงหน้าคุณยังสามารถปรับใช้สัญญาใหม่ได้ 'เกลือ' คือค่าเกลือที่ใช้ในการคํานวณที่อยู่สัญญา ซึ่งโดยพื้นฐานแล้วเป็นตัวเลขสุ่มที่แนะนําเพื่อหลีกเลี่ยงที่อยู่สัญญาที่ซ้ํากัน 'class_hash' สอดคล้องกับค่าแฮชของคลาสที่กล่าวถึงก่อนหน้านี้ซึ่งอินสแตนซ์สัญญามีความเกี่ยวข้องด้วย 'constructor_calldata_hash' แสดงถึงแฮชของพารามิเตอร์การเริ่มต้นของสัญญา

โดยใช้สูตรข้างต้น ผู้ใช้สามารถคำนวณที่อยู่สัญญาที่สร้างขึ้นก่อน implement สัญญาลงบนเครือข่าย Starknet ช่วยให้ผู้ใช้สามารถ implement สัญญาโดยตรงโดยไม่ต้องมีบัญชี Starknet ล่วงหน้า ดังต่อไปนี้:

1. ผู้ใช้จะกำหนดอินสแตนซ์สัญญาที่ต้องการติดตั้งและคลาสสัญญาที่ต้องการเชื่อมโยงกับมัน โดยใช้แฮชของคลาสเป็นหนึ่งในพารามิเตอร์เริ่มต้น และคำนวณเกลือเพื่อกำหนดที่อยู่สัญญาที่สร้างขึ้น
2. หลังจากทราบที่พวกเขาจะนำสัญญามาใช้งาน ผู้ใช้จะโอนจำนวนเงิน ETH บางจำนวนไปยังที่อยู่ดังกล่าวเป็นค่าธรรมเนียมในการนำสัญญามาใช้งาน โดยทั่วไปแล้ว ETH นี้จำเป็นต้องถูกโอนจาก L1 ไปยังเครือข่าย Starknet ผ่านสะพานระหว่างโซ่
3. ผู้ใช้เริ่มต้นคำขอทรานแซ็กชันสำหรับการปรับปรุงสัญญา

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

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

1. คีย์ส่วนตัวที่ได้รับการใช้โดยกระเป๋าเงินเป็นเหมือนกับอัลกอริทึมลายเซ็นต์
2. กระบวนการคำนวณเกลือของกระเป๋าเงินเหมือนกัน;
3. คลาสสมาร์ทคอนแทรกต์ของกระเป๋าเงินไม่ต่างกันทางพื้นฐานในรายละเอียดการปฏิบัติ; \

ในกรณีที่กล่าวถึงมาก่อนหน้านี้ ทั้ง Argent และ Braavos ใช้อัลกอริทึมลายเซน ECDSA แต่วิธีการคำนวณสารเกลือต่างกันระหว่างสองฝั่ง ทำให้ที่อยู่บัญชีที่สร้างขึ้นจาก mnemonics เดียวกันไม่สอดคล้องกัน

ตอนนี้เรามาทบทวนหัวข้อเรื่องของการขนานบัญชีอีกครั้ง Starknet และ zkSync Era ได้ย้ายกระบวนการต่างๆ ที่เกี่ยวข้องกับการประมวลผลธุรกรรม เช่น การตรวจสอบสิทธิ (การตรวจสอบลายเซ็นดิจิทัล) และการชำระค่า gas ออกจาก “ชั้นของเครือข่าย” ผู้ใช้สามารถปรับแต่งรายละเอียดของการปฏิบัติด้านบนเองในบัญชีของตนเอง ยกตัวอย่างเช่น คุณสามารถเริ่มต้นฟังก์ชันการตรวจสอบลายเซ็นดิจิทัลที่กำหนดเองในบัญชีสมาร์ทคอนแทรกของคุณใน Starknet เมื่อโหนด Starknet ได้รับธุรกรรมที่เริ่มต้นโดยคุณ มันจะเรียกชุดกระบวนการประมวลผลที่กำหนดโดยคุณบนเครือข่าย

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

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

จากข้อมูลของเจ้าหน้าที่ zkSyncEra และ Starknet แนวทางแบบแยกส่วนนี้สําหรับฟังก์ชันบัญชีได้รับแรงบันดาลใจจาก EIP-4337 อย่างไรก็ตามสิ่งที่ทําให้พวกเขาแตกต่างคือ zkSync และ Starknet รวมประเภทบัญชีตั้งแต่เริ่มแรกประเภทธุรกรรมแบบรวมและใช้จุดเริ่มต้นเดียวเพื่อรับและประมวลผลธุรกรรมทั้งหมด ในทางตรงกันข้าม Ethereum เนื่องจากสัมภาระในอดีตและความปรารถนาของมูลนิธิที่จะหลีกเลี่ยงกลยุทธ์การทําซ้ําเชิงรุกเช่น hard forks ให้มากที่สุดสนับสนุน EIP-4337 โดยใช้วิธีอื่นในการแก้ปัญหา อย่างไรก็ตามผลลัพธ์ที่ได้คือบัญชี EOA และโซลูชัน EIP-4337 แต่ละบัญชีมีเวิร์กโฟลว์การประมวลผลธุรกรรมที่เป็นอิสระซึ่งดูอึดอัดและยุ่งยากซึ่งแตกต่างจากความคล่องตัวของ AAs ดั้งเดิม

แหล่งที่มา: กระเป๋าเงิน Argent

อย่างไรก็ตาม การนำเสนอบัญชีธรรมชาติใน Starknet ยังไม่ได้เติบโตอย่างสมบูรณ์ จากมุมมองทางปฏิบัติ ในขณะที่บัญชี AA ของ Starknet ได้ปรับใช้อัลกอริทึมการตรวจสอบลายมือที่กำหนดเอง ในปัจจุบันพวกเขารองรับการชำระค่าธรรมเนียมใน ETH และ STRK เท่านั้น และยังไม่รองรับการชำระค่าแก๊สที่เป็นของบุคคลที่สาม ดังนั้น ความก้าวหน้าของ Starknet ใน AA ธรรมชาติสามารถบอกได้ว่า "กรอบทฤษฎีเกือบเสร็จสมบูรณ์ ในขณะที่การปฏิบัติยังคงอยู่ในกระบวนการ" จาก Starknet ที่มีเพียงบัญชีสัญญาอัจฉริยะภายใน กระบวนการทั้งหมดของธุรกรรมของมันพิจารณาถึงผลกระทบจากสัญญาอัจฉริยะบัญชี ก่อนอื่น หลังจากที่ธุรกรรมได้รับการรับทราบโดย Mempool ของโหนด Starknet มันจะถูกตรวจสอบ ซึ่งรวมถึง:

1. การตรวจสอบว่าลายเซ็นดิจิตอลของธุรกรรมถูกต้อง ณ จุดที่ฟังก์ชันการตรวจสอบที่กำหนดเองของบัญชีผู้ลงลายเซ็นถูกเรียกใช้;
2. การตรวจสอบว่ายอดเงินในบัญชีของผู้เริ่มต้นสามารถประมาณค่าธรรมเนียมการจ่ายเงินได้หรือไม่ \

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

1. มีขีดจำกัดสูงสุดในจำนวนธุรกรรมที่ผู้ใช้คนเดียวสามารถเริ่มต้นภายในเวลาหน่วย;
2. ฟังก์ชันการยืนยันลายเซ็นที่ปรับแต่งในสัญญาบัญชี Starknet มีข้อจำกัดในเชิงซับซ้อน และฟังก์ชันการยืนยันลายเซ็นที่มีความซับซ้อนเกินไปจะไม่ได้รับการดำเนินการ Starknet จำกัดการใช้จ่ายแก๊สของฟังก์ชันการยืนยันลายเซ็น หากปริมาณแก๊สที่ใช้จ่ายโดยฟังก์ชันการยืนยันลายเซ็นสูงเกินไป ธุรกรรมจะถูกปฏิเสธโดยตรง ในเวลาเดียวกัน ฟังก์ชันการยืนยันลายเซ็นในสัญญาบัญชีไม่ได้รับอนุญาตให้เรียกใช้สัญญาอื่น

แผนภูมิการทำธุรกรรมของ Starknet คือดังนี้:

เป็นที่น่าสังเกตว่าเพื่อเร่งกระบวนการตรวจสอบธุรกรรมต่อไปไคลเอนต์โหนด Starknet ได้ใช้อัลกอริธึมการตรวจสอบลายเซ็นของกระเป๋าเงิน Braavos และ Argent โดยตรง เมื่อโหนดตรวจพบธุรกรรมที่สร้างขึ้นจากกระเป๋าเงิน Starknet หลักทั้งสองนี้ มันจะเรียกอัลกอริธึมลายเซ็น Braavos/Argent ในตัวในไคลเอนต์ ด้วยวิธีการแคชนี้ Starknet สามารถลดระยะเวลาการตรวจสอบธุรกรรมได้ หลังจากข้อมูลธุรกรรมได้รับการตรวจสอบโดยซีเควนเซอร์ (ขั้นตอนการตรวจสอบของซีเควนเซอร์นั้นละเอียดกว่าพูลหน่วยความจํามาก) ซีเควนเซอร์จะบรรจุและส่งธุรกรรมจากพูลหน่วยความจําไปยังตัวสร้างหลักฐาน ZK ธุรกรรมที่เข้าสู่ขั้นตอนนี้จะถูกเรียกเก็บค่าธรรมเนียมก๊าซแม้ว่าจะล้มเหลวก็ตาม อย่างไรก็ตามหากผู้อ่านคุ้นเคยกับประวัติของ Starknet พวกเขาจะสังเกตเห็นว่า Starknet เวอร์ชันก่อนหน้าไม่เรียกเก็บค่าธรรมเนียมสําหรับการทําธุรกรรมที่ล้มเหลว สถานการณ์ที่พบบ่อยที่สุดสําหรับความล้มเหลวในการทําธุรกรรมคือเมื่อผู้ใช้มีเพียง 1 ETH แต่พยายามถ่ายโอน 10 ETH ภายนอกซึ่งบ่งบอกถึงข้อผิดพลาดทางตรรกะอย่างชัดเจนและจะล้มเหลวอย่างหลีกเลี่ยงไม่ได้ แต่ไม่มีใครรู้ผลลัพธ์ก่อนดําเนินการ อย่างไรก็ตามในอดีต StarkNet ไม่ได้เรียกเก็บค่าธรรมเนียมสําหรับธุรกรรมที่ล้มเหลวดังกล่าว ธุรกรรมที่ผิดพลาดเหล่านี้ไม่มีค่าใช้จ่ายทําให้ทรัพยากรการคํานวณโหนด Starknet สูญเปล่าและอาจนําไปสู่สถานการณ์การโจมตี DDoS บนพื้นผิวการเรียกเก็บค่าธรรมเนียมสําหรับการทําธุรกรรมที่ผิดพลาดดูเหมือนจะตรงไปตรงมา แต่ในความเป็นจริงมันค่อนข้างซับซ้อน Starknet แนะนําเวอร์ชันใหม่ของภาษา Cairo1 ส่วนใหญ่เพื่อแก้ไขปัญหาการเรียกเก็บก๊าซสําหรับธุรกรรมที่ล้มเหลว อย่างที่เราทราบกันดีว่าหลักฐาน ZK เป็นหลักฐานยืนยันความถูกต้องและผลลัพธ์ของธุรกรรมที่ล้มเหลวนั้นไม่ถูกต้องและไม่สามารถทิ้งผลลัพธ์ไว้ในห่วงโซ่ได้ การพยายามใช้หลักฐานความถูกต้องเพื่อพิสูจน์ว่าการดําเนินการคําสั่งบางอย่างไม่ถูกต้องและไม่สามารถสร้างผลลัพธ์ที่ออกมาได้ฟังดูแปลกและไม่สามารถใช้งานได้จริง ดังนั้นในอดีต Starknet ไม่รวมธุรกรรมที่ล้มเหลวซึ่งไม่สามารถสร้างผลลัพธ์เมื่อสร้างหลักฐาน ต่อมาทีม Starknet ได้นําโซลูชันที่ชาญฉลาดยิ่งขึ้นมาใช้และสร้างภาษาสัญญาใหม่ Cairo1 ซึ่งทําให้มั่นใจได้ว่า "คําแนะนําการทําธุรกรรมทั้งหมดสามารถสร้างผลลัพธ์และอยู่ในห่วงโซ่ได้" เมื่อมองแวบแรกความจริงที่ว่าธุรกรรมทั้งหมดสามารถสร้างผลลัพธ์ได้หมายความว่าข้อผิดพลาดเชิงตรรกะจะไม่เกิดขึ้น อย่างไรก็ตามส่วนใหญ่การทําธุรกรรมล้มเหลวเนื่องจากพบข้อบกพร่องที่ขัดจังหวะการดําเนินการคําสั่ง การรับรองว่าธุรกรรมจะไม่ขัดจังหวะและสร้างผลลัพธ์ผลลัพธ์ได้สําเร็จนั้นทําได้ยาก แต่จริงๆ แล้วมีทางเลือกอื่นง่ายๆ ซึ่งก็คือการอนุญาตให้ธุรกรรมสร้างผลลัพธ์เอาต์พุตเมื่อพบข้อผิดพลาดทางตรรกะที่นําไปสู่การหยุดชะงัก แม้ว่าจะส่งคืนค่า False ที่ระบุว่าการดําเนินการของธุรกรรมไม่ราบรื่น สิ่งสําคัญคือต้องทราบว่าการส่งกลับค่า False จะส่งกลับผลลัพธ์เอาต์พุตซึ่งหมายความว่าใน Cairo1 ไม่ว่าคําสั่งจะพบข้อผิดพลาดทางตรรกะหรือถูกขัดจังหวะชั่วคราวก็สามารถสร้างผลลัพธ์เอาต์พุตและอยู่ในห่วงโซ่ได้ ผลลัพธ์นี้สามารถถูกต้องหรือข้อความแสดงข้อผิดพลาดที่ผิดพลาด ตัวอย่างเช่น พิจารณาข้อมูลโค้ดต่อไปนี้:

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

ภาพรวมสัญญา StarknetAA

โดยพิจารณาว่าบางผู้อ่านบทความนี้อาจมีพื้นฐานในการเขียนโปรแกรม นี่คือการสาธิตสั้น ๆ ของอินเตอร์เฟซของสัญญานามบัญชีใน Starknet:

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

1. การให้สิทธิให้โทเค็นกับสัญญา DeFi ในธุรกรรมแรก
2. การเรียกใช้ตรรกะของสัญญา DeFi ในธุรกรรมที่สอง
3. ยกเลิกการให้สิทธิ์ในสัญญา DeFi ในการทำธุรกรรมครั้งที่สาม

แน่นอนเนื่องจากความไม่ตัดกึ่งของ multicall จึงมีกรณีใช้ที่ซับซ้อนมากขึ้น เช่น การดำเนินการซื้อขายอาชญากรรม

สรุป

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

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

สัญญาอัจฉริยะของ Starknet แยกต่างหากจากการเก็บข้อมูลสถานะของโซน EVM ไม่เหมือนโซน EVM การติดตั้งสัญญา Cairo เกี่ยวข้องกับสามขั้นตอน: การคอมไพล์, การประกาศ, และการใช้งาน ตรรกะธุรกิจถูกประกาศในคลาสสัญญา และตัวอย่างสัญญาที่มีข้อมูลสถานะสามารถที่จะเกี่ยวข้องกับคลาส และเรียกใช้รหัสที่มีในนั้น

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

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

ข้อความปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกพิมพ์ใหม่จาก [ เว็บ 3 ของนักพัฒนา]. *Forward the Original Title‘解读Starknet智能合约模型与原生AA：特立独行的技术巨匠’.All copyrights belong to the original author [Shew & Faust]. If there are objections to this reprint, please contact the เกต เรียนทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นที่สองของคำแนะนำในการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่น ๆ จะดำเนินการโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือทำการลอกเลียน บทความที่ถูกแปล นอกเสียจากที่ระบุไว้