Anagram Build ใช้เวลาส่วนใหญ่ในการศึกษาหลักการคริปโตใหม่และใช้หลักการเหล่านี้ในผลิตภัณฑ์ที่เฉพาะเจาะจง หนึ่งในโครงการวิจัยล่าสุดของเราพาเราเข้าสู่โลกของ Verifiable Compute (VC) ทีมของเราใช้การวิจัยนี้เพื่อสร้างระบบโอเพ่นซอร์สใหม่ที่เรียกว่าBonsolเราเลือกพื้นที่การวิจัยนี้เนื่องจากการเกิดขึ้นของกรณีการใช้งานที่มีประสิทธิภาพที่ VC สามารถให้และความพยายามอย่างต่อเนื่องที่เกิดขึ้นในระหว่าง L1s ต่าง ๆ เพื่อเพิ่มประสิทธิภาพทางด้านความจุและขยายขอบเขตของ VC

ในบล็อกนี้ เรามีเป้าหมายสองอย่าง

• เราต้องการให้คุณเข้าใจเกี่ยวกับ VC ในฐานะแนวคิดและผลิตภัณฑ์ที่เป็นไปได้ที่ VC ช่วยให้ในระบบนิเวศ Solana ได้ดียิ่งขึ้น
• เราต้องการเสนอผลงานล่าสุดของเราBonsol.

Verifiable Compute หมายถึงอะไรนั่นแหละ?

คำว่า 'Verifiable Compute' อาจจะไม่ปรากฎในสไลด์การลงทุนของบริษัท Startup ในตลาดเบิร์น แต่คำว่า 'Zero Knowledge' มีความหมาย ดังนั้น คำว่าเหล่านี้หมายถึงอะไร?

การประมวลผลที่ตรวจสอบได้ (VC) กําลังเรียกใช้ปริมาณงานเฉพาะในลักษณะที่สร้างการรับรองการทํางานที่สามารถตรวจสอบได้แบบสาธารณะโดยไม่ต้องเรียกใช้การคํานวณอีกครั้ง Zero Knowledge (ZK) คือความสามารถในการพิสูจน์คําแถลงเกี่ยวกับข้อมูลหรือการคํานวณโดยไม่เปิดเผยข้อมูลทั้งหมดหรืออินพุตในการคํานวณ คํานี้ค่อนข้างสับสนในโลกแห่งความเป็นจริง ZK ค่อนข้างเป็นคนพูดผิด มันเกี่ยวข้องกับการเลือกข้อมูลที่ต้องเปิดเผยต่อสาธารณะเพื่อพิสูจน์คําแถลงเกี่ยวกับเรื่องนี้ VC เป็นคําที่แม่นยํากว่าและเป็นเป้าหมายโดยรวมในสถาปัตยกรรมระบบแบบกระจายที่มีอยู่มากมาย

วีซีช่วยเราสร้างผลิตภัณฑ์คริปโตที่ดีกว่าได้อย่างไร

เหตุใดเราจึงต้องการเพิ่มระบบ VC หรือ ZK นอกเหนือจากแพลตฟอร์มเช่น Solana และ Ethereum ดูเหมือนว่าคําตอบจะเกี่ยวกับความปลอดภัยสําหรับนักพัฒนามากกว่า ผู้พัฒนาระบบทําหน้าที่เป็นสื่อกลางระหว่างความไว้วางใจของผู้ใช้ปลายทางในกล่องดําและฟังก์ชั่นทางเทคนิคที่ทําให้ความไว้วางใจนั้นถูกต้องตามวัตถุประสงค์ ด้วยการใช้เทคนิค ZK / VC ผู้พัฒนาสามารถลดพื้นที่ผิวสําหรับการโจมตีในผลิตภัณฑ์ที่พวกเขากําลังสร้าง ระบบ VC เปลี่ยนสถานที่แห่งความไว้วางใจไปยังระบบพิสูจน์และปริมาณงานการประมวลผลที่ได้รับการพิสูจน์แล้ว นี่คือการผกผันความน่าเชื่อถือที่คล้ายกันซึ่งเกิดขึ้นเมื่อย้ายจากแนวทางไคลเอ็นต์/เซิร์ฟเวอร์ web2 ทั่วไปไปยังแนวทางบล็อกเชน web3 ความไว้วางใจเปลี่ยนจากการพึ่งพาคํามั่นสัญญาของ บริษัท ไปสู่การเชื่อถือรหัสโอเพนซอร์สและระบบการเข้ารหัสของเครือข่าย ไม่มีระบบ zero-trust ที่แท้จริงจากมุมมองของผู้ใช้และฉันยืนยันว่าสําหรับผู้ใช้ปลายทางทุกอย่างดูเหมือนกล่องดํา

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

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

ในฐานะที่เป็นส่วนหนึ่งของงานของเราที่ Anagram เรามีโอกาสพูดคุยกับผู้ก่อตั้ง / นักพัฒนา crypto จํานวนมากเพื่อทําความเข้าใจว่าสถานะปัจจุบันของสแต็คซอฟต์แวร์ของ crypto กําลังชะลอนวัตกรรมผลิตภัณฑ์ ในอดีตการสนทนาของเราช่วยให้เราระบุแนวโน้มที่น่าสนใจ โดยเฉพาะอย่างยิ่งกลุ่มโครงการกําลังย้ายตรรกะผลิตภัณฑ์แบบ on-chain นอกเครือข่ายอย่างแข็งขันเนื่องจากมีราคาแพงเกินไปหรือจําเป็นต้องเพิ่มตรรกะทางธุรกิจที่แปลกใหม่มากขึ้น ดังนั้นในท้ายที่สุดนักพัฒนาเหล่านี้พบว่าตัวเองพยายามค้นหาระบบและเครื่องมือเพื่อสร้างสมดุลระหว่างชิ้นส่วนทั้งในและนอกสายโซ่ของผลิตภัณฑ์ที่พวกเขากําลังพัฒนาซึ่งมีประสิทธิภาพมากขึ้นเรื่อย ๆ นี่คือจุดที่ VC กลายเป็นส่วนสําคัญของเส้นทางไปข้างหน้าในการช่วยเชื่อมต่อโลกทั้งในและนอกเครือข่ายโดยใช้วิธีการที่เชื่อถือได้และตรวจสอบได้

ไปเลย! ดังนั้น VC/ZK systems ทำงานอย่างไรในปัจจุบัน?

ฟังก์ชัน VC และ ZK กำลังถูกดำเนินการโดยส่วนใหญ่บนชั้นคำนวณทางเลือก (หรือเรียกว่า rollups, sidechains, relays, oracles, หรือ coprocessors) ที่มีอยู่ผ่านการเรียกกลับไปยังการทำงานของสมาร์ทคอนแทรค ในการเปิดใช้งานขั้นตอนนี้ หลายๆ โซน L1 กำลังมุ่งเน้นการพัฒนาเพื่อให้มีการทำงานที่รวดเร็วมากขึ้นนอกเหนือจากการทำงานของสมาร์ทคอนแทรค (เช่น syscalls หรือ precompiles) ที่ช่วยให้พวกเขาสามารถทำสิ่งที่จะเป็นที่จะแพงเกินไปบนเชน

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

การตรวจสอบแบบ On-chain อย่างสมบูรณ์

สําหรับระบบพิสูจน์ VC และ ZK ที่สามารถผลิตหลักฐานขนาดเล็กเช่น Groth16 หรือพันธุ์ Plonk บางสายพันธุ์หลักฐานจะถูกส่งแบบ on-chain และตรวจสอบ on-chain โดยใช้รหัสที่ปรับใช้ก่อนหน้านี้ ระบบดังกล่าวเป็นเรื่องธรรมดามากและวิธีที่ดีที่สุดในการลองใช้คือการใช้ Circom และตัวตรวจสอบ Groth16 บน Solana หรือ EVM ข้อเสียเปรียบคือระบบพิสูจน์เหล่านี้ค่อนข้างช้า พวกเขามักจะต้องเรียนรู้ภาษาใหม่ ในการตรวจสอบแฮช 256 บิตใน Circom คุณต้องจัดการกับ 256 บิตเหล่านั้นด้วยตนเอง มีไลบรารีมากมายที่อนุญาตให้คุณเรียกฟังก์ชันแฮช แต่เบื้องหลังคุณต้องใช้ฟังก์ชันเหล่านี้ในรหัส Circom ของคุณใหม่ ระบบเหล่านี้ยอดเยี่ยมเมื่อองค์ประกอบ ZK และ VC ของกรณีการใช้งานของคุณมีขนาดเล็กลงและคุณต้องมีหลักฐานที่ถูกต้องก่อนที่จะดําเนินการกําหนดอื่น ๆ Bonsol อยู่ในหมวดหมู่แรกนี้ในปัจจุบัน

การตรวจสอบ Off-chain

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

เครือข่ายการตรวจสอบ

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

การตรวจสอบบนเชื่อมต่อโซล

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

สรุป

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

การเสนอ Bonsol!

ป้อนBonsol, ระบบ VC ต้นฉบับของ Solana ที่เราที่ Anagram สร้างและเปิดเผย. Bonsol ช่วยให้นักพัฒนาสามารถสร้าง executable ที่สามารถยืนยันได้เกี่ยวกับข้อมูลส่วนตัวและสาธารณะ และผสานผลลัพธ์เข้ากับสมาร์ทคอนแทรค Solana โปรเจคนี้ต้องการ RISC0 toolchain ที่นิยม

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

ก่อนที่เราจะลงรายละเอียดของระบบ ให้เริ่มต้นด้วยการแสดงให้เห็นถึงพลังของ Bonsol ด้วยกรณีการใช้งานสองกรณีที่แตกต่างกัน

สถานการณ์หนึ่ง

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

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

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

ในขณะที่มีหลายวิธีในการทำระบบการขายบัตรจับฉลากนี้ คุณสมบัติของ Bonsol ทำให้ง่ายมากที่จะมีความเชื่อถือน้อยมากในองค์กรที่จัดขายบัตรจับฉลาก มันยังเน้นถึงความสามารถในการทำงานร่วมกันของ Solana และระบบ VC โปรแกรม Solana (สมาร์ทคอนแทรกต์) เล่น peran penting dalamการทำงานเพื่อเป็นตัวกลางในการสร้างความเชื่อถือเพราะมันยืนยันพรูฟและให้โปรแกรมทำการต่อไป

สถานการณ์ที่สอง

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

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

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

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

โครงสร้างบอนซอล

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

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

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

สร้างง่ายไหม? ไม่ง่ายนี่แหละ!

ไม่ได้หมายความว่าไม่มีความท้าทายในการสร้าง Bonsol ในการนําหลักฐาน Risco0 และตรวจสอบบน Solana เราจําเป็นต้องทําให้มันเล็กลง แต่เราไม่สามารถทําเช่นนั้นได้โดยไม่ต้องเสียสละคุณสมบัติด้านความปลอดภัยของการพิสูจน์ ดังนั้นเราจึงใช้ Circom และห่อ Risc0 Stark ซึ่งสามารถอยู่ใน ~ 200kb และห่อด้วยหลักฐาน Groth16 ซึ่งจบลงด้วยการเป็น 256 ไบต์เสมอ โชคดีที่ Risc0 จัดหาเครื่องมือตั้งไข่สําหรับสิ่งนี้ แต่มันเพิ่มค่าใช้จ่ายและการพึ่งพาระบบจํานวนมาก

เมื่อเราเริ่มสร้าง Bonsol และใช้เครื่องมือที่มีอยู่สําหรับห่อ Stark ด้วย Snark เราหาวิธีลดการพึ่งพาและเพิ่มความเร็ว Circom อนุญาตให้รวบรวมรหัส Circom เป็น C ++ หรือ wasm ก่อนอื่นเราพยายามรวบรวมวงจร Circom เป็นไฟล์ wasmu ที่ผลิตโดย LLVM นี่เป็นวิธีที่เร็วและมีประสิทธิภาพที่สุดในการทําให้เครื่องมือ Groth16 พกพาสะดวกและยังคงรวดเร็ว เราเลือก wasm เนื่องจากการพกพาเนื่องจากรหัส C ++ ขึ้นอยู่กับสถาปัตยกรรม cpu x86 ซึ่งหมายความว่า Macbooks ใหม่หรือเซิร์ฟเวอร์ที่ใช้ Arm จะไม่สามารถใช้สิ่งนี้ได้ แต่นี่กลายเป็นทางตันสําหรับเราในไทม์ไลน์ที่เราต้องทํางานด้วย เนื่องจากการทดลองวิจัยผลิตภัณฑ์ของเราส่วนใหญ่มีเวลากล่องจนกว่าพวกเขาจะพิสูจน์คุณค่าของพวกเขาเรามีเวลา dev 2-4 สัปดาห์ในการทดสอบแนวคิดนี้ คอมไพเลอร์ llvm wasm ไม่สามารถจัดการกับรหัส wasm ที่สร้างขึ้นได้ ด้วยการทํางานที่มากขึ้นเราอาจผ่านพ้นสิ่งนี้ไปได้ แต่เราลองใช้แฟล็กการเพิ่มประสิทธิภาพมากมายและวิธีที่จะทําให้คอมไพเลอร์ llvm ทํางานเป็นปลั๊กอิน wasmer เพื่อคอมไพล์โค้ดนี้ลงใน llvm แต่เราไม่ประสบความสําเร็จ เนื่องจากวงจร Circom มีรหัสประมาณ 1.5 ล้านบรรทัดคุณสามารถจินตนาการได้ว่าจํานวน Wasm นั้นใหญ่มาก จากนั้นเราก็หันมาพยายามสร้างสะพานเชื่อมระหว่าง C ++ และฐานรหัสรีเลย์ Rust ของเรา นอกจากนี้ยังพบกับความพ่ายแพ้อย่างรวดเร็วเนื่องจาก C ++ มีรหัสแอสเซมบลีเฉพาะ x86 ที่เราไม่ต้องการเล่นซอด้วย เพื่อให้ระบบออกสู่สาธารณะเราลงเอยด้วยการบูตระบบในลักษณะที่ใช้ประโยชน์จากรหัส C ++ แต่ลบการพึ่งพาบางส่วน ในอนาคตเราต้องการขยายสายการเพิ่มประสิทธิภาพอื่นที่เรากําลังดําเนินการอยู่ นั่นคือการใช้รหัส C ++ และรวบรวมเป็นกราฟการดําเนินการ สิ่งประดิษฐ์ C ++ เหล่านี้จากการรวบรวม Circom ส่วนใหญ่เป็นเพียงเลขคณิตแบบแยกส่วนมากกว่า เขตจำกัดด้วยจำนวนเฉพาะขนาดใหญ่มาก ๆ เป็นตัวสร้างรหัส นี้แสดงให้เห็นถึงผลลัพธ์บางอย่างที่ดีสำหรับอาร์ติฟัค C++ ที่เล็กและง่ายขึ้น แต่ต้องมีการทำงานเพิ่มเติมเพื่อให้สามารถทำงานได้กับระบบ Risc0 นี้ เนื่องจากโค้ด C++ ที่สร้างขึ้นมีประมาณ 7 ล้านบรรทัด และตัวสร้างกราฟดูเหมือนจะชนขีดจำกัดขนาดสแต็ก และการเพิ่มขนาดเหลวเหลวเหลวเหลวเหลวนั้นดูเหมือนจะทำให้เกิดข้อบกพร่องอื่นที่เรายังไม่มีเวลากำหนด เหมือนกับว่าแม้ว่าบางส่วนของเส้นทางเหล่านี้จะไม่สำเร็จ แต่เราสามารถมีส่วนร่วมกับโครงการ OSS และหวังว่าในบางช่วงเวลานั้นการมีส่วนร่วมเหล่านั้นจะถูกนำไปสู่ช่วงบน

ความท้าทายชุดต่อไปอยู่ในพื้นที่การออกแบบมากขึ้น ส่วนสําคัญของระบบนี้คือความสามารถในการมีปัจจัยการผลิตส่วนตัว อินพุตเหล่านั้นต้องมาจากที่ไหนสักแห่งและเนื่องจากข้อ จํากัด ด้านเวลาเราจึงไม่สามารถเพิ่มระบบเข้ารหัส MPC แฟนซีเพื่อให้อินพุตส่วนตัวอยู่ในระบบในวงปิด ดังนั้นเพื่อตอบสนองความต้องการนี้และปลดบล็อกนักพัฒนาเราได้เพิ่มแนวคิดของเซิร์ฟเวอร์อินพุตส่วนตัวซึ่งจําเป็นต้องตรวจสอบความถูกต้องของผู้ร้องขอซึ่งได้รับการตรวจสอบโดยลายเซ็นของเพย์โหลดคือผู้อ้างสิทธิ์ปัจจุบันของหลักฐานและให้บริการแก่พวกเขา ในขณะที่เราขยาย Bonsol เราวางแผนที่จะใช้ระบบถอดรหัสเกณฑ์ MPC ซึ่งโหนด Relay สามารถอนุญาตให้ผู้อ้างสิทธิ์ถอดรหัสอินพุตส่วนตัวได้ การอภิปรายทั้งหมดนี้เกี่ยวกับอินพุตส่วนตัวนําเราไปสู่วิวัฒนาการการออกแบบที่เราวางแผนที่จะให้บริการใน Bonsol repo นั่นคือ Bonsolace ซึ่งเป็นระบบที่ง่ายกว่าที่ช่วยให้คุณในฐานะนักพัฒนาสามารถพิสูจน์โปรแกรม zk เหล่านี้บนโครงสร้างพื้นฐานของคุณเองได้อย่างง่ายดาย แทนที่จะแยกตัวประกอบไปยังเครือข่ายผู้พิสูจน์คุณสามารถพิสูจน์ได้ด้วยตัวเองและตรวจสอบในสัญญาเดียวกันกับที่เครือข่ายผู้พิสูจน์ใช้ กรณีการใช้งานนี้มีไว้สําหรับกรณีการใช้ข้อมูลส่วนตัวที่มีมูลค่าสูงมากซึ่งต้องลดการเข้าถึงข้อมูลส่วนตัวโดยเสียค่าใช้จ่ายทั้งหมด

หมายเหตุสุดท้ายเกี่ยวกับ Bonsol ที่เราไม่เคยเห็นในที่อื่นโดยใช้ Risc0 คือเราบังคับให้มีความมุ่งมั่น (แฮช) มากกว่าข้อมูลอินพุตลงในโปรแกรม zk และเราตรวจสอบสัญญาว่าอินพุตที่ผู้พิสูจน์ต้องกระทําเพื่อให้ตรงกับสิ่งที่ผู้ใช้คาดหวังและส่งเข้าสู่ระบบ สิ่งนี้มีค่าใช้จ่ายบางอย่าง แต่ไม่ได้หมายความว่าผู้พิสูจน์สามารถโกงและเรียกใช้ zkprogram ผ่านอินพุตที่ผู้ใช้ไม่ได้ระบุ ส่วนที่เหลือของการพัฒนา Bonsol ตกอยู่ในการพัฒนา Solana ปกติ แต่ควรสังเกตว่าเราตั้งใจลองแนวคิดใหม่ ๆ ที่นั่น ในสัญญาอัจฉริยะเราใช้ flatbuffers เป็นระบบการออกหมายเลขกํากับเท่านั้น นี่เป็นเทคนิคที่ค่อนข้างแปลกใหม่ที่เราอยากเห็นการพัฒนาและสร้างเป็นเฟรมเวิร์กเพราะมันให้ยืมตัวเองอย่างดีกับ sdks ที่สร้างอัตโนมัติซึ่งเป็นแพลตฟอร์มข้ามแพลตฟอร์ม ข้อสังเกตสุดท้ายเกี่ยวกับ Bonsol คือปัจจุบันจําเป็นต้องมี precompile เพื่อให้ทํางานได้อย่างมีประสิทธิภาพมากที่สุด precompile นี้มีกําหนดจะลงจอดใน Solana 1.18 แต่จนถึงตอนนี้เรากําลังดําเนินการเพื่อดูว่าทีมมีความสนใจในการวิจัยนี้หรือไม่และมองไปไกลกว่า Bonsol ในเทคโนโลยีอื่น ๆ

สรุป

เกินจาก Bonsol ทีมงาน Anagram build กำลังมองอย่างลึกซึ้งไปที่หลายที่ในโดเมน VC โครงการเช่น Jolt, zkllvm, spartan 2, Binius เป็นโครงการที่เรากำลังติดตาม รวมถึง บริษัทที่ทำงานในพื้นที่ Fully Homomorphic Encryption (FHE) หากคุณไม่ทราบว่ามันคืออะไร ๆ อยู่ในระหว่างการติดตามเนื่องจากเราจะครอบคลุมมันในบางจุด

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

หากคุณกำลังทำงานในโครงการ VC ที่น่าสนใจ เราขอเชิญคุณสมัครที่นี่สำหรับโปรแกรม Anagram EIR โดยที่ร่วมกับทีม Anagram คุณจะสามารถทดสอบวิทยานิพนธ์ของคุณสร้าง บริษัท และจัดการกับปัญหาที่ใหญ่ที่สุดที่เป็นไปได้ อย่าลังเลที่จะมีส่วนร่วมหรือถามคําถามใด ๆ

Disclaimer：

1. บทความนี้ถูกพิมพ์อีกครั้งจาก [อนาแกรม], สิทธิ์ในการคัดลอกทั้งหมดเป็นของผู้เขียนต้นฉบับ [ austbot]. If there are objections to this reprint, please contact the Gate Learnทีม และพวกเขาจะจัดการกับมันโดยทันที

2. คำชี้แจงความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงเรื่องส่วนบุคคลของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางด้านการลงทุนใด ๆ

3. การแปลบทความเป็นภาษาอื่นๆ นำมาทำโดยทีม Gate Learn หากไม่ได้กล่าวถึงว่าอนุญาติให้คัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่ถูกแปล จะถูกห้าม