StarkWare

การแนะนำ

การแนะนำ

ทั้ง StarkEx และ StarkNet เป็นโปรเจ็กต์ที่พัฒนาโดยทีม StarkWare โปรเจ็กต์แรกนั้นคล้ายกับ Iaas ซึ่งคล้ายกับแอพพลิเคชั่นเชน StarkWare ช่วยโปรเจกต์ขนาดใหญ่พัฒนา Rollup แอพพลิเคชั่นที่เป็นกรรมสิทธิ์ ส่วนแบบหลังคือ Rollup ที่สามารถปรับใช้แอพพลิเคชั่นทั่วไป

StarkEx: เครื่องยนต์ ZKR ที่เป็นกรรมสิทธิ์

การแนะนำ

การแนะนำ

ในปีที่แล้วและช่วงครึ่งแรกของปีนี้ StarkWare ได้สร้างโมเดลธุรกิจการปรับขนาดเป็นบริการ (การปรับขนาดเป็นบริการ) โดยการจัดหาโซลูชันเทคโนโลยีการปรับขนาด StarkEx สร้างเครือข่ายเฉพาะแอปพลิเคชัน และให้บริการลูกค้าชั้นนำในอุตสาหกรรม dYdX , Sorare, ImmutableX, DeversiFi เป็นต้น

โครงสร้างโดยรวม

• เวิร์กโฟลว์ประกอบด้วยลิงก์สี่ลิงก์ต่อไปนี้

• ธุรกรรมแบบแพ็คเกจ: เซิร์ฟเวอร์ออฟไลน์ประมวลผลคำขอของลูกค้าและรวมธุรกรรมหลายรายการเป็น "แบทช์" เพื่อให้ StarkEx ดำเนินการ

• ยืนยันธุรกรรมและสถานะการอัปเดต: เซิร์ฟเวอร์ออฟไลน์ยืนยันว่าธุรกรรมนั้นถูกกฎหมายและอัปเดตสถานะของระบบในรูปแบบแฮชที่บีบอัด

• สร้างหลักฐานสำหรับธุรกรรม: หลังจากเสร็จสิ้นกระบวนการข้างต้น SHARP จะสร้างหลักฐาน STARK สำหรับธุรกรรมเพื่อยืนยันความถูกต้องของธุรกรรม จากนั้นหลักฐานและการอัปเดตจะถูกส่งไปยังสมาร์ทคอนแทรค on-chain Verifier เพื่อให้แน่ใจว่าการทำธุรกรรมมีความสมบูรณ์

หลักฐานที่ยืนยันแล้วบนเครือข่าย: เมื่อพิสูจน์หลักฐานของ STARK แล้ว การอัปเดตสถานะจะถูกคอมมิตและโอนกลับไปยังเครือข่ายหลักของ Ethereum ธุรกรรมทั้งหมดได้รับการประมวลผลและตรวจสอบแบบออฟไลน์ ขณะที่หลักฐานยืนยันความสมบูรณ์จะได้รับการตรวจสอบแบบออนไลน์

SHARP เป็นเครื่องพิสูจน์ที่ใช้ร่วมกันซึ่งให้บริการการสร้างการพิสูจน์พร้อมกันสำหรับไคลเอ็นต์/แอปพลิเคชันของ StarkEx หลายรายการ - สร้างหลักฐานการอ้างสิทธิ์ด้านความสมบูรณ์ของคอมพิวเตอร์

StarkWare Applications

Verifier เป็นสัญญาอัจฉริยะที่ใช้งานบน Ethereum เพื่อตรวจสอบความถูกต้องของการทำธุรกรรมจาก StarkEx

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

• ขั้นตอนมาตรฐาน

• ผู้ใช้เริ่มต้นธุรกรรม ธุรกรรมสามารถโต้ตอบโดยตรงกับสัญญาอัจฉริยะ

• ธุรกรรมแต่ละรายการมีรหัสเฉพาะ ซึ่งรวมกันเป็นขั้นตอนการทำธุรกรรม และแอปพลิเคชัน StarkEx จะส่งขั้นตอนการทำธุรกรรมไปยังแบ็กเอนด์

• แบ็กเอนด์ส่งการเปลี่ยนสถานะไปยัง SHARP และ SHARP จะสร้างหลักฐานสำหรับการเปลี่ยนสถานะ

• SHARP ส่งหลักฐานไปยังสัญญาของผู้ตรวจสอบ และหลังจากที่ผู้ตรวจสอบยืนยันเสร็จสิ้น ผู้ตรวจสอบจะบันทึกข้อมูลดังกล่าวใน Verifier Fact Registry จากนั้นแบ็กเอนด์จะดำเนินการเปลี่ยนสถานะในสัญญาอัจฉริยะของ StarkEx

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

ลิงค์อ้างอิง: บทนำ :: เอกสาร StarkEx

ภาพรวมระดับสูง

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

• ที่ส่วนหน้า ลูกค้าของ StarkEx รองรับการดำเนินการสองประเภท ทั้งแบบออนเชนและออฟเชน แบบแรกเป็นธุรกรรม Ethereum มาตรฐาน และผู้ใช้ฝากและถอนโดยตรงผ่านสัญญา StarkEx ในขณะที่แบบหลังเป็นการดำเนินการผ่านเอ็นจิ้น StarkEx เช่น dydx

• การตรวจสอบคำสั่งซื้อ ตั้งค่าและตรวจสอบโดยแบ็กเอนด์ของไคลเอ็นต์ StarkEx

• ตรรกะทางธุรกิจ ปรับแต่งสัญญา StarkEx (สัญญาย่อย) เพื่อรองรับตรรกะทางธุรกิจของลูกค้า

• ขั้นตอนการทำธุรกรรม ธุรกรรมทั้งหมดที่ส่งไปยัง StarkEx ได้รับการตรวจสอบและจัดทำดัชนีโดยใช้ตัวระบุต่อเนื่องที่เรียกว่า tx_ids ซึ่งคล้ายกับ nonces

• ผู้ส่งธุรกรรม เมื่อเกตเวย์ StarkEx ยืนยันว่าธุรกรรมถูกต้อง จะรับประกันว่าจะดำเนินการ (ไม่จริงในทันที) และจะแสดงให้ผู้ใช้ทราบล่วงหน้าที่ส่วนหน้า แทนที่จะรอการสรุปผลในห่วงโซ่

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

• การตรวจสอบแบทช์ ลูกค้าสามารถตรวจสอบแบทช์ใดๆ ก่อนที่จะส่งต่อไปยังเชน หากการเปลี่ยนแปลงไม่สอดคล้องกับสถานะที่คาดไว้ ไคลเอนต์จะไม่สามารถอนุมัติหรือย้อนกลับได้

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

StarkNet: ยูนิเวอร์แซล ZKR

การแนะนำ

การแนะนำ

ซึ่งแตกต่างจาก StarkEx ซึ่งปรับแต่ง ZK Rollup สำหรับแอปพลิเคชันต่างๆ StarkNet เป็น ZK Rollup ที่ใช้งานทั่วไป และนักพัฒนาสามารถปรับใช้แอปพลิเคชันบน StarkNet

การแนะนำเบื้องต้น

https://ethereum.org/zh/developers/docs/evm/ 

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

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

นอกจากนี้ เมื่อเทียบกับวิธีการของ Ethereum ในการอนุญาตให้แต่ละโหนดดำเนินการธุรกรรมได้อย่างเต็มที่ วิธีการของ StarkNet ในการสร้างการพิสูจน์ ZK สำหรับการทำธุรกรรมสามารถปรับปรุงความเร็วการทำงานของเครือข่ายได้อย่างมาก ลดทราฟฟิก การสื่อสารแบบ on-chain และเพิ่มทรูพุตของเครือข่าย ด้วย TPS ที่สูงขึ้นและ Gas ที่ต่ำกว่า

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

รองรับ EVM

เครือข่าย StarkNet นั้นไม่รองรับ EVM และ Cairo VM อีกชุดที่เป็นมิตรกับ ZK ได้รับการออกแบบมา

StarkNet ไม่ได้สร้างวงจร ZK สำหรับ Ethereum opcodes เช่น Hermez และ Scroll แต่สร้างชุดภาษาแอสเซมบลีที่เป็นมิตรกับ ZK, AIR (Algebraic Intermediate Representation) และภาษาไคโรระดับสูง

https://vitalik.eth.limo/general/2022/08/04/zkevm.html

StarkNet อยู่ในประเภท 4 ระดับที่กำหนดโดย Vitalik - zkEVM ที่เข้ากันได้กับภาษา (StarkNet เป็นของ zkVM อย่างเคร่งครัดเนื่องจากเครื่องเสมือนที่กำหนดเอง)

แม้ว่า StarkNet เองจะไม่สามารถทำงานร่วมกับ EVM ได้ แต่ StarkNet ก็ยังสามารถใช้งานร่วมกับ Ethereum ได้ด้วยวิธีอื่นๆ

1. Warp: นักแปลที่แปล Solidity เป็นภาษาไคโร

Warp เป็นตัวแปลภาษา Solidity-Cairo ที่พัฒนาโดยทีมโครงสร้างพื้นฐาน Ethereum ที่มีชื่อเสียงอย่าง Nethermind Warp สามารถแปลรหัส Solidity เป็นภาษาไคโรได้ แต่โปรแกรมไคโรที่แปลแล้วมักจะต้องแก้ไขและเพิ่มคุณสมบัติไคโร (เช่น การเรียกใช้ฟังก์ชันในตัว การปรับหน่วยความจำให้เหมาะสม ฯลฯ) เพื่อเพิ่มประสิทธิภาพการดำเนินการให้สูงสุด

2. Kakarot: zkEVM ที่เขียนด้วยภาษาไคโร

• Kakarot เป็นสัญญาอัจฉริยะที่เขียนขึ้นในกรุงไคโร ซึ่งปัจจุบันใช้งานบน Starknet (goerli testnet) และรหัสไบต์เทียบเท่ากับ EVM ขณะนี้อยู่ในรุ่นเบต้า แอปพลิเคชัน Ethereum สามารถพอร์ตไปยัง StarkNet ได้โดยการปรับใช้กับ Kakarot

• Kakarot สามารถ: (a) เรียกใช้ EVM bytecode ตามอำเภอใจ (b) ปรับใช้ EVM smart contract ตามที่เป็นอยู่ (c) ฟังก์ชันการโทร (วิธีการดูและเขียน) ของ EVM smart contract ที่ปรับใช้โดย Kakarot

ขณะนี้รองรับ opcodes ทั้งหมดของ EVM

https://github.com/sayajin-labs/kakarot

หลักการทำงาน

หลักการทำงาน

ส่วนประกอบ

https://david-barreto.com/starknets-architecture-review/#more-4602 

• StarkNet มีห้าองค์ประกอบ พวกเขาคือ Prover (ผู้รับรอง), Sequencer (ตัวเรียงลำดับ) และโหนดเต็มบน StarkNet และตัวตรวจสอบ (Verifier) ​​และสัญญาสถานะหลัก (StarkNet Core) ที่ปรับใช้บน Ethereum

• เมื่อเราเริ่มต้นธุรกรรมบน StarkNet เซิร์ฟเวอร์นอกเชน—ผู้คัดแยก—จะรับ จัดเรียง ตรวจสอบ และบรรจุเป็นบล็อก ดำเนินการธุรกรรม จากนั้นส่งการเปลี่ยนสถานะไปยังสัญญา StarkNet Core

• ผู้พิสูจน์จะสร้างหลักฐานสำหรับธุรกรรมและส่งไปยังสัญญาผู้ตรวจสอบของ Ethereum

ผู้ตรวจสอบจะส่งผลการตรวจสอบไปยังสัญญา StarkNet Core บน Ethereum และทริกเกอร์ชุดธุรกรรม Ethereum ชุดใหม่จากสัญญา StarkNet Core เพื่ออัปเดตสถานะส่วนกลางบนเชนเพื่อการเก็บบันทึก ธุรกรรมของรัฐจะถูกส่งเป็น "calldata" (Blob หลังจาก EIP-4844) เพื่อประหยัดธุรกรรม L1 "ข้อมูลเมตา" เหล่านี้สามารถถอดรหัสได้โดยโหนดเต็มของ StarkNet

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

ดูรีวิวสถาปัตยกรรมของ StarkNet โดยผู้สนับสนุนการพัฒนา StarkNet @barretodavid 【 1 】

เบราว์เซอร์ https://testnet.starkscan.co/, การสร้างบล็อกแบบไดนามิก L2, การชำระ Ethereum หนึ่งชั่วโมง

นามธรรมบัญชีและรูปแบบการทำธุรกรรม

แตกต่างจากการออกแบบสองบัญชีของ Ethereum EOA+CA, StarkNet ตระหนักถึงสิ่งที่เป็นนามธรรมของบัญชีเนทีฟ และการออกแบบบัญชีเพียงบัญชีเดียว โดยยึดตามจิตวิญญาณของ EIP 4337

https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781 

รูปต่อไปนี้แสดงรูปแบบการทำธุรกรรม

• สิ่งที่เป็นนามธรรมของบัญชีดั้งเดิมเปิดประตูสำหรับการเขียนโปรแกรมบัญชี ผู้สนับสนุนการพัฒนา StarkNet @barretodavid กล่าวถึงแนวคิดของการใช้กระเป๋าเงินแบบแข็งของโทรศัพท์มือถือบน StarkNet

• EOA บน Ethereum รองรับเฉพาะรูปแบบลายเซ็น ECDSA บนเส้นโค้งวงรี Secp 256 k 1

• สมาร์ทโฟนส่วนใหญ่ไม่รองรับเส้นโค้งวงรีของ Ethereum

• ดังนั้นโมบายล์วอลเล็ตจึงจำเป็นต้องพึ่งพาซอฟต์แวร์เพื่อเซ็นธุรกรรม ดังนั้นโมบายล์วอลเล็ตจึงเป็นฮอตวอลเล็ต

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

https://github.com/spartucus/nistp 256-cairo

ไคโรมีการใช้งาน nistp 256 (สำหรับ Smartphone Secure Enlave) แล้ว

STARK

พูดง่ายๆ ก็คือเรียกโมดูลการเข้ารหัสของโทรศัพท์มือถือโดยตรงเพื่อ "ลงนาม" ธุรกรรม

ปัจจุบันมีระบบการพิสูจน์ที่แตกต่างกันมากมาย (สร้างและตรวจสอบการพิสูจน์) เช่น Halo, PLONK, Groth 16, Groth 09, Marlin, Plonky 2 เป็นต้น ซึ่งทั้งหมดเป็นของระบบพิสูจน์ SNARK ระบบการพิสูจน์มีผู้พิสูจน์ที่สร้างหลักฐานและผู้ตรวจสอบที่ตรวจสอบหลักฐาน โครงการ ZK ที่แตกต่างกันเกือบทั้งหมดใช้ระบบพิสูจน์ที่แตกต่างกัน และ STARK ที่ StarkNet ใช้ก็เป็นของ SNARK พิเศษในแง่หนึ่ง

STARK มีนวัตกรรมมากกว่า SNARK ไม่จำเป็นต้องพึ่งพา "การตั้งค่าที่เชื่อถือได้" เช่น SNARK นอกจากนี้ยังมาพร้อมกับสมมติฐานการเข้ารหัสที่ง่ายขึ้น หลีกเลี่ยงความต้องการเส้นโค้งวงรี การจับคู่ และสมมติฐานความรู้แบบเอ็กซ์โปเนนเชียล พึ่งพาทฤษฎีแฮชและข้อมูลเท่านั้น ดังนั้นจึงทนทานต่อการโจมตีแบบควอนตัม โดยทั่วไปแล้ว STARK มีความปลอดภัยมากกว่า SNARK

https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/

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

สรุป เมื่อเทียบกับ SNARK แล้ว STARK มีความปลอดภัยมากกว่า และเวลาเฉลี่ยในการตรวจสอบและขนาดหลักฐานจะลดลงเมื่อขนาดการตรวจสอบเพิ่มขึ้น ข้อเสียคือ ขนาดหลักฐานเริ่มต้นมีขนาดใหญ่กว่า ดังนั้นจึงเหมาะสำหรับการใช้งานขนาดใหญ่ .

การขยายรายละเอียด

เวลาพิสูจน์มาตราส่วนเชิงเส้น: เวลาที่ใช้โดยผู้พิสูจน์มาตราส่วนเชิงเส้นโดยประมาณกับจำนวนการเรียกแฮช

https://eprint.iacr.org/2021/582.pdf

ที่ระดับความปลอดภัย 80 บิต เวลาดำเนินการของ Prover สำหรับการเรียกใช้แฮช 12288 ครั้งของ STARK คือ 1 วินาที ซึ่งเท่ากับ 12288 ครั้ง/วินาที และทุกๆ การเรียกใช้แฮช 98304 ครั้งต้องใช้เวลา 10 วินาที ซึ่งเท่ากับ 9830 ครั้ง/วินาที ดังนั้น เราสามารถ เป็นที่ทราบกันดีว่าเวลาพิสูจน์ของ STARK และการโทรแบบแฮชนั้นโดยพื้นฐานแล้วจะเป็นเส้นตรงโดยประมาณ ดังที่แสดงด้านล่าง

**มาตราส่วนลอการิทึมขนาดการตรวจสอบและพิสูจน์: เวลาการตรวจสอบ (และขนาดพิสูจน์) จะปรับขนาดลอการิทึมด้วยการโทรแบบแฮช **ตามที่แสดงด้านล่าง:

ดังที่เห็นได้จากรูปด้านซ้าย เมื่อการเรียกแฮชเพิ่มขึ้นจาก 3072 เป็น 49152 เวลาในการตรวจสอบจะเพิ่มขึ้นจาก 40 มิลลิวินาทีเป็น 60 มิลลิวินาที และเมื่อการโทรแฮชเพิ่มขึ้นจาก 49152 เป็น 786432 เวลาในการตรวจสอบก็เพิ่มขึ้นจาก 60 มิลลิวินาทีเป็น 80 มิลลิวินาทีเท่านั้น หลักฐานที่มีขนาดเท่ากัน ดังนั้น เราสามารถรู้ได้ว่ายิ่งมีการเรียกแฮชมาก เวลาการตรวจสอบเฉลี่ยก็จะสั้นลง และขนาดการพิสูจน์โดยเฉลี่ยก็จะยิ่งเล็กลง (การเรียกแฮชเพื่อสร้างค่าแฮช/การพิสูจน์)

พิสูจน์ซ้ำ"การพิสูจน์/ข้อโต้แย้งทั่วไปที่รวบรัดใดๆ ของระบบความรู้ (โดยเฉพาะ STARK) สามารถใช้เพื่อตรวจสอบการคำนวณแบบค่อยเป็นค่อยไป ซึ่งหมายความว่าการคำนวณสามารถพิสูจน์ความถูกต้องของตัวอย่างก่อนหน้าของการคำนวณนั้น ซึ่งเป็นแนวคิดที่รู้จักกันอย่างไม่เป็นทางการว่า "องค์ประกอบการพิสูจน์แบบเรียกซ้ำ"หรือ

STARK แบบเรียกซ้ำ"

https://medium.com/starkware/recursive-starks-78 f 8 dd 401025 

กล่าวอีกนัยหนึ่ง ตัวพิสูจน์ STARK แบบเรียกซ้ำสามารถสร้างหลักฐานสำหรับข้อความที่ระบุว่าสถานะของระบบสามารถย้ายจาก a เป็น +1 ได้ เนื่องจากตัวพิสูจน์ได้ตรวจสอบการพิสูจน์ (เรียกซ้ำ) ของความสมบูรณ์ของการคำนวณของ a และดำเนินการคำนวณของสถานะ a อย่างซื่อสัตย์ สถานะใหม่จึงมาถึง a+1 กล่าวโดยสรุปคือ คุณสามารถเข้าใจได้ว่ากระบวนการนี้เป็นการรวมการพิสูจน์ a และ a+1 เข้าด้วยกันเป็นหนึ่งการพิสูจน์** ดังแสดงด้านล่าง:**

Cairo VM: ตรวจสอบความถูกต้องของการคำนวณ

ภาพรวมไคโร VM

บางครั้งก็ปรากฏในรูปแบบของ StarkNet OS/Cairo OS เช่นกัน ซึ่งแตกต่างจาก EVM ในการคำนวณ Cairo VM นั้นสร้างเพียงการพิสูจน์สำหรับการคำนวณและตรวจสอบความถูกต้องเท่านั้น

Cairo VM เป็น CPU VM ที่ใช้สถาปัตยกรรม von Neumann ภาษาโปรแกรมเรียกอีกอย่างว่า Cairo ภาษาไคโรใช้แอสเซมบลีของไคโร ดังนั้น ประสิทธิภาพการคอมไพล์จึงสูงมาก ไคโรเป็นตัวย่อสำหรับ CPU Algebraic Intermediate Representation Cairo VM มี AIR เดียวเพื่อตรวจสอบชุดคำสั่งของ "CPU" นี้

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

ภาพรวมของภาษาไคโร

ไคโรเป็นภาษาสัญญาอัจฉริยะของ StarkNet ซึ่งอิงตามการออกแบบของ STARK โปรแกรมไคโรสามารถสร้างหลักฐานของ STARK ได้

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

การคำนวณที่ไม่ได้กำหนด

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

ตัวอย่างเช่น พิสูจน์ว่าสแควร์รูท y ของ x = 961 อยู่ในช่วง 0, 1,…, 100 วิธีที่ตรงไปตรงมาคือการเขียนโค้ดที่ซับซ้อนซึ่งเริ่มต้นที่ 961 คำนวณรากของมัน และตรวจสอบว่ารากนี้อยู่ในช่วงที่กำหนด

รหัสเทียมมีดังต่อไปนี้: เดาค่าของ y (นี่คือส่วนที่ไม่ได้กำหนด) คำนวณ y 2 และรับรองว่าผลลัพธ์เท่ากับ x ตรวจสอบว่า y อยู่ในช่วง และถ้าเราใช้วิธีคำนวณดังนี้ Y = SQRT(X) เราสามารถคำนวณแทนได้ดังนี้ (การคำนวณแบบไม่มีกำหนด) ย*ย=X

อย่างที่เราเห็น มีสองวิธีแก้ปัญหาที่เป็นไปได้ +Y และ -Y และเป็นไปได้ว่ามีเพียงหนึ่งรายการเท่านั้นที่จะปฏิบัติตามคำแนะนำที่เหลือ

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

สักขีพยานเกี่ยวกับเครื่องเสมือนที่กำหนดขึ้นและไม่ได้กำหนด

• an accepting input to the Cairo deterministic machine, that constitutes the witness to the nondeterministic machine.

ไคโรในที่นี้จะเกี่ยวข้องกับ Cairo VM เชิงกำหนดและ Cairo VM เชิงกำหนด แบบแรกคือ zkVM ที่จริงจัง การพิสูจน์และการตรวจสอบ ส่วนแบบหลังใช้สำหรับการคำนวณแบบไม่ได้กำหนด

อินพุตที่ยอมรับได้ของไคโรเชิงกำหนด VM ถือเป็นพยานของ VM เชิงกำหนดไม่ได้ และ ZKP จำเป็นต้องใช้พยานเป็นหลักฐานอินพุตและเอาต์พุต (พยานสำหรับคำสั่ง NP คือชิ้นส่วนของข้อมูลที่ช่วยให้คุณตรวจสอบได้อย่างมีประสิทธิภาพว่าข้อความนั้นเป็นจริง ตัวอย่างเช่น หากมีการระบุว่ามีวัฏจักรแฮมิลตันอยู่ในกราฟ พยานก็คือวัฏจักรดังกล่าว สามารถตรวจสอบได้อย่างมีประสิทธิภาพว่าเป็นแหวน Hamiltonian ที่ถูกต้องหรือไม่ แต่การหาแหวนดังกล่าวเป็นเรื่องยาก)

เป็นเครื่องสถานะคู่ขนาน

รูปแบบหน่วยความจำ: อ่านอย่างเดียวไม่กำหนด

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

และเป็นแบบต่อเนื่อง ถ้าว่าง จะเติมด้วยค่าใดค่าหนึ่ง

ข้อดีของ ROM ได้แก่

ต้นทุนต่ำ วงจรง่ายกว่า RAM

การจัดเก็บถาวร,

ไม่สามารถแก้ไขได้ ไม่สามารถแก้ไขและลบข้อมูลได้

ฟังก์ชันในตัว: ลดการคอมไพล์โค้ด

https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b 71976 ad 0108 

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

สถาปัตยกรรมไคโรไม่ได้ระบุชุดฟังก์ชันในตัวที่เฉพาะเจาะจง สามารถเพิ่มหรือลบฟังก์ชันในตัวออกจาก AIR (Algebraic Intermediate Representation) ได้ตามต้องการ

สถาปัตยกรรม CPU: ยืดหยุ่น

มีความยืดหยุ่นมากกว่าและสามารถใกล้เคียงกับประสิทธิภาพของ AISC ได้อย่างไม่มีที่สิ้นสุดผ่านการเขียนโปรแกรมซอฟต์แวร์ (ไคโรจะทำ CPU เหรอ?) แยกเครื่องเสมือนอื่น ๆ ด้วยไคโร

โหลดบูต: โหลดโปรแกรมจากแฮช

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

• ความสามารถในการปรับขนาด เวลาในการตรวจสอบ และขนาดของโปรแกรมแสดงความสัมพันธ์ของลอการิทึม ตามที่กล่าวไว้ในส่วน STARK

ความเป็นส่วนตัว ผู้ตรวจสอบสามารถตรวจสอบได้ว่าโปรแกรมทำงานอย่างถูกต้องโดยไม่ต้องใช้การคำนวณ

หน่วยความจำต่อเนื่อง: การเข้าถึงที่อยู่หน่วยความจำอย่างต่อเนื่อง

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

สินค้าคงคลังของนิเวศวิทยา StarkNet:

https://h 0 m 83 hhc 6 r.feishu.cn/docx/doxcnS 3 GGdXXc 1 PzKh 9 uTgTR 73 c

เกมลูกโซ่เต็มรูปแบบ

เกมลูกโซ่เต็มรูปแบบ

Matchbox DAO：https://mirror.xyz/matchboxdao.eth

The Future of On-Chain Gaming：

https://volt.capital/blog/the-future-of-on-chain-gaming

Game 2.0 ：

https://www.guiltygyoza.xyz/2022/07/game 2 

เกมเชนเต็มรูปแบบ—ประสิทธิภาพการผลิต + การเปลี่ยนแปลงประสบการณ์ผู้บริโภค โดยพื้นฐานแล้ว การคิด (บทความจากองค์กรและทีมต่างๆ) การฝึกฝน (โครงการเกมบนเชนและแฮ็กกาธอน) เงินทุน (การจัดหาเงินทุนและเงินช่วยเหลือ) และที่สำคัญที่สุดคือมีนักพัฒนาที่มีชีวิตชีวา ชุมชน.

ขอแนะนำทีม Topology Lootreamls

กระเป๋าเงินสัญญา

• มีสองวิธีในการตระหนักว่ากระเป๋าเงินสัญญากลายเป็นกระเป๋าเงินแข็ง

• ชั้นฉันทามติรองรับฮาร์ดแวร์โทรศัพท์มือถือ บน L2 ของสิ่งที่เป็นนามธรรมของบัญชีดั้งเดิม เช่น StarkNet (ภาษาโปรแกรมไคโร) รองรับเส้นโค้งวงรีที่หลากหลาย แทนที่จะรองรับเฉพาะ ECDSA (วินาที 256 k 1) เช่น Ethereum เพื่อให้ชิป/โมดูลการเข้ารหัสของโทรศัพท์มือถือ สามารถลงนามในการทำธุรกรรมได้โดยตรง (โทรศัพท์มือถือส่วนใหญ่ไม่รองรับ ECDSA) ดังนั้นใน L2 ที่บัญชีเนทีฟถูกแยกออกไป กระเป๋าสัญญาสามารถเซ็นธุรกรรมได้โดยตรงผ่านฮาร์ดแวร์เช่นเดียวกับกระเป๋าเงินแข็ง

เลเยอร์กระเป๋าเงินทำการถอดความลายเซ็น ในเครือข่ายการแยกบัญชีที่ไม่ใช่เจ้าของภาษาเช่น Ethereum กระเป๋าสัญญาสามารถลงนามและถอดความได้ เช่นเดียวกับ EIP-4337 คุณสามารถปรับแต่งตรรกะการตรวจสอบ และผู้ใช้ลงนามด้วยอัลกอริทึมที่ฮาร์ดแวร์โทรศัพท์มือถือรองรับ จากนั้นจึงแปลงเป็น ECDSA ที่สนับสนุนโดย Ethereum

• @barretodavid ผู้สนับสนุนการพัฒนาของ StarkNet กล่าวถึงแนวคิดของการใช้กระเป๋าเงินแบบแข็งสำหรับโทรศัพท์มือถือบน StarkNet

• EOA บน Ethereum รองรับเฉพาะรูปแบบลายเซ็น ECDSA บนเส้นโค้งวงรี Secp 256 k 1

• สมาร์ทโฟนส่วนใหญ่ไม่รองรับเส้นโค้งวงรีของ Ethereum

• ดังนั้นโมบายล์วอลเล็ตจึงจำเป็นต้องพึ่งพาซอฟต์แวร์เพื่อเซ็นธุรกรรม ดังนั้นโมบายล์วอลเล็ตจึงเป็นฮอตวอลเล็ต

https://twitter.com/barretodavid/status/1563584823884935168 

การสรุปบัญชีแบบเนทีฟของ StarkNet รองรับเส้นโค้งวงรีหลายเส้น และการตรวจสอบลายเซ็นสามารถตั้งโปรแกรมได้สูง ดังนั้นโมบายวอลเล็ตที่ใช้ StarkNet/ไคโรสามารถเปลี่ยนเป็นฮาร์ดวอลเล็ตได้อย่างสมบูรณ์

ไคโรมี [nistp 256](

) (สำหรับการใช้งาน Smartphone Secure Enlave)

การควบรวมของสัญญากระเป๋าเงิน + เกมเต็มรูปแบบเปิดสถานการณ์ใหม่นอกเหนือจากกระเป๋าเงิน + DeFi เงิน, Cartridge.gg กำลังทำอยู่

AI บนเครือข่าย

Modulus Labs：https://www.moduluslabs.xyz/

Giza - Machine Learning in the Blockchain：

https://gizatech.xyz/

StarkNet decentralization : Kicking off the discussion

mirror.xyz：https://community.starknet.io/t/starknet-decentralization-kicking-off-the-discussion/711 

ขณะนี้มีโครงการแมชชีนเลิร์นนิง 2 โครงการ ได้แก่ แพลตฟอร์ม ML Giza และหุ่นยนต์ซื้อขายบนเครือข่าย (Rockybot โดย ModulusLabs) กลุ่มชาวจีนของ StarkNet มีอีกโครงการหนึ่ง

แอปพลิเคชันประกอบด้วย: เกม ออราเคิล ธุรกรรม (รายได้อัตโนมัติ) แอนตี้แม่มด KYC ความเป็นส่วนตัวของข้อมูล การทำเหมืองด้วยคอมพิวเตอร์แบบจำลอง AI

ขอบคุณ

ขอบคุณ

บทความนี้ได้รับการสนับสนุนและเขียนโดย HackerDojo Hacker Dōjo เป็นชุมชนความรู้แบบโอเพ่นซอร์สด้านการเข้ารหัสและเทคโนโลยีชายแดน Web3 ซึ่งร่วมสร้างโดยแฮ็กเกอร์

ขอบคุณผู้สร้าง Maxlion และ HackerDojo