คำเตือน
ลังนี้ถูกเก็บถาวรแล้ว การพัฒนาได้ย้ายไปยังที่เก็บ zksync-crypto แล้ว กรุณาใช้มันแทน
zkSync Era เป็นการรวมเลเยอร์ 2 ที่ใช้การพิสูจน์ความรู้แบบศูนย์เพื่อปรับขนาด Ethereum โดยไม่กระทบต่อความปลอดภัยหรือการกระจายอำนาจ เนื่องจากเข้ากันได้กับ EVM (Solidity/Vyper) 99% ของโปรเจ็กต์ Ethereum จึงสามารถปรับใช้ใหม่ได้โดยไม่ต้องปรับโครงสร้างใหม่หรือตรวจสอบโค้ดบรรทัดเดียวอีกครั้ง zkSync Era ยังใช้คอมไพเลอร์ที่ใช้ LLVM ซึ่งในที่สุดแล้วจะช่วยให้นักพัฒนาเขียนสัญญาอัจฉริยะในภาษา C++, Rust และภาษายอดนิยมอื่น ๆ ได้
วัตถุประสงค์ของไลบรารีนี้คือการทำงานกับการคำนวณทางคณิตศาสตร์ที่เฉพาะเจาะจงมากพร้อมสมมติฐานเพิ่มเติมเกี่ยวกับขนาดฟิลด์ โดยคร่าวๆ เราคาดว่าจะมีฟิลด์ F พร้อมด้วย |F| ~ 64 บิต (ขนาดของคำของเครื่อง) (สมมติฐานเกี่ยวกับขนาดฟิลด์ไม่สำคัญสำหรับกลยุทธ์การคำนวณทางคณิตศาสตร์และการวางเกต แต่จะยืนยันในการใช้งาน Gadget สำหรับฟังก์ชันเฉพาะซึ่งขึ้นอยู่กับขนาดฟิลด์เฉพาะ)
ระบบมีลำดับชั้นของฟังก์ชันเชิงตรรกะ (แกดเจ็ต) - เกท (เอนทิตีที่สามารถจารึกตัวเองไว้ในการติดตาม) - และผู้ประเมิน (ความสัมพันธ์ระหว่างพหุนาม) ผู้ประเมินถูกเขียนในรูปแบบของคุณลักษณะที่ช่วยให้เราสามารถเขียนฟังก์ชันโดยอัตโนมัติในภายหลังเพื่อตรวจสอบความพึงพอใจและการพิสูจน์การคำนวณ เช่นเดียวกับการสังเคราะห์ตัวตรวจสอบแบบธรรมดาและแบบเรียกซ้ำ เกตส์มีเครื่องมือเพิ่มเติมติดอยู่ซึ่งช่วยให้เกตสามารถติดตามตรรกะว่าควรวางไว้ที่ใดในการติดตาม โปรดทราบว่าเราอาศัยข้อจำกัดในการคัดลอกของ Plonk และทำงานกับเอนทิตีตรรกะที่คัดลอกได้ของ "ตัวแปร" เพื่อสร้างคำสั่งพิสูจน์ได้ขั้นสุดท้าย ระบบไม่ได้มีไว้สำหรับการคำนวณ AIR และไม่อนุญาตให้แสดงข้อจำกัดที่ครอบคลุมหลายแถวของการติดตาม
โดยทั่วไป การติดตามจะจำกัดคอลัมน์ไม่กี่แบบ การแยกหลักอยู่ระหว่าง:
นอกจากนี้ การติดตามยังช่วยให้คุณเพิ่มอาร์กิวเมนต์การค้นหา ซึ่งยังสามารถใช้คอลัมน์พิเศษเพื่อจัดเก็บรายการของตารางการค้นหา หรือใช้คอลัมน์วัตถุประสงค์ทั่วไปก็ได้ ตารางถูกเข้ารหัสเป็นพหุนามเพียงชุดเดียวในขณะนี้ ดังนั้นความยาวรวมของการติดตามต้องมากกว่าจำนวนรายการทั้งหมดในตาราง
โปรดทราบว่า "ประตู" ทุกอัน (ที่เป็นประเภทสนิม) จะมีเอกลักษณ์เฉพาะตัว ดังนั้นประตูจึงสามารถวางไว้ในคอลัมน์เฉพาะหรือคอลัมน์วัตถุประสงค์ทั่วไปเท่านั้น แต่ไม่สามารถวางลงในทั้งสองคอลัมน์ได้ หากต้องการฟังก์ชันดังกล่าว ก็สามารถสร้าง wrapper ชนิดใหม่ได้
ฟังก์ชันลอจิคัลระดับที่สูงกว่า (เช่น การสลายตัวแบบบูลีน การตรวจสอบช่วง การตรวจสอบเป็นศูนย์ ฯลฯ) ถูกนำมาใช้เพื่อทำให้วงจรเขียนวงจรภายในในลักษณะที่แตกต่างกัน ขึ้นอยู่กับว่าบางเกตได้รับอนุญาตหรือไม่อนุญาตในกรณีเฉพาะของ CS อินสแตนซ์ของ CS ที่มีชุดเกตต่างกันถือเป็นประเภทที่แตกต่างจากมุมมองของ Rust และเราอาศัยงานเสา/คอมไพเลอร์แบบอินไลน์/คงที่เพื่อลดการแตกแขนงเป็นการข้ามแบบคงที่
|F| ดังนั้นเราจึงต้องทำซ้ำข้อโต้แย้ง) แต่สิ่งนี้จะถูกเปลี่ยนแปลงเพื่อให้เราย้ายไปยังฟิลด์ส่วนขยายตาม โดยเร็วที่สุดหลังจากให้คำมั่นกับพยานเพื่อหลีกเลี่ยงโอกาส "มาก" ที่จะได้เลขศูนย์ในตัวส่วน ผลกระทบต่อค่าใช้จ่ายในการคำนวณในการพิสูจน์ค่อนข้างน้อยมาก เราใช้อาร์กิวเมนต์การค้นหาที่บังคับใช้ผ่านความสัมพันธ์ sum_i selector(x_i) / (witness(x_i) + beta) == sum_i multiplicity(x_i) / (table(x_i) + beta) โดยที่การค้นหาผ่าน selector(x_i) เป็นเพียงตัวตน นอกจากนี้เรายังไม่เข้ารหัสตารางเป็นพหุนามที่มีดีกรีน้อยกว่าเพื่อกำจัดการตรวจสอบขอบเขตพิเศษของดีกรี และเติมด้วยศูนย์แทน โปรดทราบว่ารายการตารางไม่เคยมีองค์ประกอบ (0,0,...,0) เนื่องจากเราใช้คอลัมน์ ID แยกต่างหากสำหรับประเภทตารางในกรณีที่มีหลายตาราง (แม้ในกรณีที่มีการใช้เพียงตารางเดียว) และ ID เช่นนี้เริ่มต้นด้วย 1
คุณลักษณะที่ดีประการหนึ่งของอาร์กิวเมนต์การค้นหาเช่นนี้ก็คือ เนื่องจากลักษณะการบวกของมัน ถ้าเราค้นหาพหุนาม witness หลายรายการในตารางเดียวกัน แทนที่จะทำซ้ำอาร์กิวเมนต์สำหรับทุก ๆ (ทูเพิลของ) พหุนาม (ซึ่งจะต้องมี คอลัมน์พหุนามที่แยกจากกัน รวมถึงพหุนามตัวกลางสองสามตัวในภายหลัง) เราสามารถ "บวก" การคูณและแปลงอาร์กิวเมนต์ให้กลายเป็น sum_i selector_0(x_i) / (witness_0(x_i) + beta) + sum_i selector_1(x_i) / (witness_1(x_i) + beta) == sum_i total_multiplicity(x_i) / (table(x_i) + beta) ดังนั้นต้นทุนรวมของการค้นหา เป็นเพียง 1 คอลัมน์การคูณ และ 2 (ที่เกี่ยวข้องกับพยาน) + 1 (ที่เกี่ยวข้องกับตาราง) พหุนามกลางเพื่อเข้ารหัส ความสัมพันธ์ lhs และ rhs บนรากฐานของความสามัคคี
ความถูกต้องของข้อโต้แย้งนี้ชัดเจน เพื่อความสมบูรณ์ เราใช้อาร์กิวเมนต์ดั้งเดิมเช่นเดียวกับในเอกสาร "ผลหารแคชสำหรับการค้นหาอย่างรวดเร็ว" Lemma 2.4 เราต้องแสดงให้เห็นว่ามันเพียงพอแล้วที่จะยอมรับ total_multiplicity แทนที่จะใช้ผลคูณของ witness_0 และ witness_1 แยกกัน
สมมติว่าสมการ sum_i selector_0(x_i) / (witness_0(x_i) + X) + sum_i selector_1(x_i) / (witness_1(x_i) + X) == sum_i total_multiplicity(x_i) / (table(x_i) + X) ถือ เราต้องแสดงให้เห็นว่ามี witness_0 และ witness_1 อยู่ในตาราง t ให้ f = (witness_0 | witness_1) เป็นการต่อกันของค่าต่างๆ สมการข้างต้นแสดงถึง sum_i selector_i / (f_i + X) == sum_i total_multiplicity_i / (t_i + X) (โปรดทราบว่าความยาวของช่วง i บน LHS นั้นเป็นสองเท่าจากข้างบน) โดยบทแทรก 2.4 เราจะได้ f subset t : "subset" ในแง่ที่ว่าทุกพิกัดของเวกเตอร์ f เป็นพิกัดของ t โดยเฉพาะอย่างยิ่ง witness_0, witness_1 subset f subset t
โปรดทราบว่าข้อโต้แย้งนี้มีไว้สำหรับ witness_i หลายคนเช่นกัน อาร์กิวเมนต์ความถูกต้องที่เหลือสำหรับ beta ที่เลือก ตามมาโดยตรงในงานด้านบน
2^-40 ที่จะได้ 0 ในตัวส่วน มีการวัดประสิทธิภาพสำหรับ SHA256 ขนาด 8kB โดยใช้สิ่งที่เราคิดว่าเป็นการกำหนดค่าเกต + ตารางที่เหมาะสมที่สุดสำหรับวงจร SHA256 โปรดทราบว่าแม้ว่าตัวพิสูจน์จะค่อนข้างเร็ว แต่เราก็ไม่ได้ปรับ FFT ให้เหมาะสมอย่างเหมาะสมและยังคงใช้ Poseidon (ไม่ใช่ Poseidon2) สำหรับการกำหนดค่าที่เราคาดหวังว่าจะใช้การพิสูจน์สำหรับการเรียกซ้ำ สคริปต์สองตัว sha256_bench_recursive.sh และ sha256_bench_non_recursive.sh ช่วยให้คุณสามารถรันการทดสอบที่เกี่ยวข้องได้ (ไม่ว่าจะคาดว่าจะใช้การพิสูจน์ในการเรียกซ้ำหรือไม่ก็ตาม) และคุณควรมองหาบรรทัด Proving is done, taken ... เพื่อดูเวลาการพิสูจน์ เนื่องจากตัวตรวจสอบที่ทำงานหลังจากนั้นค่อนข้างละเอียด การวัดประสิทธิภาพเหล่านี้ใช้ปัจจัย LDE เท่ากับ 8 แม้ว่าข้อจำกัดทั้งหมดของเราจะอยู่ที่ระดับ 4 หรือน้อยกว่า อย่างไรก็ตาม เกณฑ์มาตรฐานดังกล่าวก็เป็นพารามิเตอร์ที่ใช้ในการวัดประสิทธิภาพสาธารณะอื่นๆ บางส่วน นอกจากนี้ เรายังไม่ใช้ PoW ในการพิสูจน์เหล่านั้น เนื่องจาก PoW สำหรับ 20 บิตนั้นมีค่าเล็กน้อย (30 มิลลิวินาที) และเราไม่รองรับ PoW ผ่านการแฮชพีชคณิต (อย่างไรก็ตาม สิ่งเหล่านี้ช้ากว่าเพียง ~2 เท่าเท่านั้น จึงน้อยมากเช่นกัน) ระดับความปลอดภัยอยู่ที่ประมาณ 100 บิต แต่ความสมบูรณ์ของ FRI สามารถเพิ่มขึ้นได้โดยการเพิ่มจำนวนการสืบค้น และการเพิ่มจำนวนการสืบค้นจะไม่เพิ่มเวลาในการพิสูจน์ (เพื่อไม่ให้สับสนกับการเปลี่ยนอัตรา FRI) ความยาวการติดตามคือ 2^16 และใช้คอลัมน์วัตถุประสงค์ทั่วไป 60 คอลัมน์ และอาร์กิวเมนต์การค้นหา 8 รายการที่มีความกว้าง 4
หมายเหตุ: การวัดประสิทธิภาพเพียงพยายามคอมไพล์เป็น Native Arch และมีเพียง AArch64 (อ่าน Apple M1) เท่านั้นที่ได้รับการทดสอบแบบ end-to-end ในตอนนี้ การใช้งานทางคณิตศาสตร์ x86-64 ได้รับการทดสอบความถูกต้อง แต่ไม่ได้พิสูจน์แบบครบวงจร โปรดทราบว่าประสิทธิภาพสูงสุด x86-64 ต้องใช้แฟล็กคุณลักษณะคอมไพเลอร์เพิ่มเติมนอกเหนือจาก cpu = native (ชุด AVX512 ไม่ได้ใช้โดยคอมไพเลอร์ Rust แม้แต่กับ CPU ดั้งเดิม)
สุภาษิต Boojum ได้รับการเผยแพร่ภายใต้เงื่อนไขของข้อใดข้อหนึ่ง
ตามตัวเลือกของคุณ
zkSync Era ได้ผ่านการทดสอบและตรวจสอบมากมาย แม้ว่าจะมีการเผยแพร่จริง แต่ก็ยังอยู่ในสถานะอัลฟ่า และจะต้องผ่านการตรวจสอบและโปรแกรมรางวัลจุดบกพร่องเพิ่มเติม เรายินดีรับฟังความคิดเห็นและข้อเสนอแนะของชุมชนเกี่ยวกับเรื่องนี้! สิ่งสำคัญคือต้องระบุว่าการฟอร์กตอนนี้อาจทำให้พลาดการอัปเดตความปลอดภัยที่สำคัญ คุณลักษณะที่สำคัญ และการปรับปรุงประสิทธิภาพ
ซอฟต์แวร์นี้มีส่วนประกอบจากบุคคลที่สาม สำหรับรายการส่วนประกอบเหล่านี้ทั้งหมดและใบอนุญาต โปรดดูไฟล์ประกาศของบุคคลที่สาม
