IOSG Ventures: โปรเซสเซอร์ร่วม ZK เปลี่ยนจาก 0 เป็น 1 ทำอะไรได้บ้าง?
ผู้เขียนต้นฉบับ: IOSG Ventures
ขอขอบคุณคุณ Mo Dong จาก Celer Network และ Brevis สำหรับการสนทนาเชิงลึกเกี่ยวกับแนวคิดหลักและกรณีการใช้งานของตัวประมวลผลร่วม ZK ความคิดเหล่านี้เป็นแรงบันดาลใจในการสร้างสรรค์บทความชุดนี้
โปรเซสเซอร์ร่วม ZK เป็นนวัตกรรมที่น่าตื่นเต้นในพื้นที่บล็อกเชน บุกเบิกโดยโครงการต่างๆ เช่น Brevis, Axiom, Lagrange และ Herodotus โดยสัญญาว่าจะปฏิวัติวิธีที่เราพัฒนาแอปพลิเคชันบนบล็อกเชน ด้วยโปรเซสเซอร์ร่วม ZK นักพัฒนาสามารถสร้าง dApps ที่ขับเคลื่อนด้วยข้อมูล ซึ่งสามารถใช้ประโยชน์จากประวัติของข้อมูล Omnichain เพื่อทำการคำนวณที่ซับซ้อนโดยไม่ต้องอาศัยสมมติฐานด้านความน่าเชื่อถือเพิ่มเติมใดๆ ที่สำคัญกว่านั้น นำไปสู่รูปแบบการพัฒนาใหม่: สถาปัตยกรรมแอปพลิเคชันแบบอะซิงโครนัส ซึ่งนำประสิทธิภาพและความสามารถในการขยายขนาดที่ไม่เคยมีมาก่อนมาสู่เฟรมเวิร์กซอฟต์แวร์ Web 3.0
ในบทความชุดนี้ เราจะมาไขข้อสงสัยเกี่ยวกับโปรเซสเซอร์ร่วม ZK ไม่ว่าคุณจะสนใจแนวคิด การนำไปใช้จริง กลไกพื้นฐาน ความท้าทาย หรือกลยุทธ์ทางการตลาด หรือต้องการเปรียบเทียบโครงการต่างๆ เราหวังว่าบทความเหล่านี้จะนำแรงบันดาลใจใหม่ๆ มาให้คุณได้
กรณีของโปรแกรมเทรดเดอร์ VIP ที่หายไปใน DEX
เพื่อให้เข้าใจแนวคิดพื้นฐานของโปรเซสเซอร์ร่วม ZK เราต้องเริ่มต้นด้วยการสร้างแรงจูงใจให้กับตัวอย่างในโลกแห่งความเป็นจริง
ความแตกต่างที่ชัดเจนอย่างหนึ่งระหว่างการแลกเปลี่ยนแบบรวมศูนย์ (CEX) และการแลกเปลี่ยนแบบกระจายอำนาจ (DEX) คือการมีค่าธรรมเนียมตามปริมาณ หรือที่เรียกกันทั่วไปว่า “โปรแกรมความภักดีของเทรดเดอร์วีไอพี” โปรแกรมเหล่านี้เป็นเครื่องมือที่มีประสิทธิภาพในการรักษาเทรดเดอร์ เพิ่มสภาพคล่อง และเพิ่มรายได้จากการแลกเปลี่ยนในที่สุด
สิ่งที่น่าสนใจคือ แม้ว่า CEX ทุกแห่งจะมีโปรเจ็กต์ดังกล่าวอย่างน้อยหนึ่งโปรเจ็กต์ แต่ DEX ก็ไม่มีเลย ทำไม
เนื่องจากการนำฟังก์ชันนี้ไปใช้ใน DEX นั้นมีความท้าทายและมีค่าใช้จ่ายสูงกว่าใน CEX
ใน CEX การใช้โปรแกรมสะสมคะแนนต้องการ:
การบันทึกประวัติการทำธุรกรรมของผู้ใช้ทั้งหมดในฐานข้อมูลส่วนกลาง ซึ่งเป็นงานที่ช่วยลดค่าใช้จ่ายในการสืบค้นในอนาคต
การสืบค้นโดยตรงจะดำเนินการทุกเดือนในฐานข้อมูลส่วนกลางที่มีประสิทธิภาพสูง เพื่อกำหนดปริมาณธุรกรรมและระดับค่าธรรมเนียมของผู้ใช้แต่ละรายตามข้อมูลประวัติ
อย่างไรก็ตาม DEX เผชิญกับความท้าทายที่สำคัญเมื่อพยายามทำตามขั้นตอนเดียวกัน:
เนื่องจากบล็อคเชนมีค่าใช้จ่ายการจัดเก็บสูง จึงไม่สามารถจัดเก็บประวัติการทำธุรกรรมของผู้ใช้แต่ละรายในสัญญาอัจฉริยะได้โดยตรง การใช้ตรรกะนี้หมายความว่าผู้ใช้จ่ายค่าธรรมเนียมสูงขึ้น 4 เท่าต่อธุรกรรม
แม้ว่าเราจะมีการจัดเก็บข้อมูลบันทึกธุรกรรม แต่ค่าใช้จ่ายในการสืบค้นทางสถิติและการคำนวณข้อมูลนี้ก็สูงกว่า ตัวอย่างเช่น การคำนวณข้อมูลปริมาณธุรกรรมสำหรับธุรกรรม 10,000 รายการสำหรับผู้ใช้รายเดียวจะมีค่าใช้จ่าย 156 M Gas (ใช่แล้ว เราคำนวณไว้แล้ว)
คุณอาจจะพูดว่า “เดี๋ยวก่อน คุณกำลังพูดถึงบ้าอะไร บน blockchain ทุกธุรกรรมสำหรับผู้ใช้ทุกคนจะถูกเก็บไว้โดยอัตโนมัติ (เพราะมันเป็น blockchain!)” Homegrown Intelligence บน Blockchain สัญญาควรมีการเข้าถึงที่พร้อมสำหรับทั้งหมด ข้อมูลนี้ใช่ไหม?
ขออภัย ไม่!
ข้อมูลที่จัดเก็บไว้ในบล็อคเชนและข้อมูลที่เข้าถึงได้โดยสัญญาอัจฉริยะในเครื่องเสมือนบล็อคเชนนั้นแตกต่างอย่างสิ้นเชิง
สำหรับโหนดแบบเต็ม/ที่เก็บถาวรของบล็อกเชน จะเก็บข้อมูลจำนวนมากจากประวัติของบล็อกเชน โหนดเหล่านี้ช่วยให้คุณเข้าถึง:
สถานะของบล็อกเชนทั้งหมด ณ เวลาใดก็ตามในประวัติศาสตร์ (เช่น ใครเป็นเจ้าของคนแรกของ Cryptopunk)
ธุรกรรมและเหตุการณ์ที่เกิดจากธุรกรรมในช่วงเวลาใดเวลาหนึ่งในประวัติศาสตร์ (เช่น Charlie แลกเปลี่ยน $1,000 เป็น 0.5 ETH)
ในความเป็นจริง เครื่องมือจัดทำดัชนีหรือวิเคราะห์ข้อมูลนอกเครือข่ายยอดนิยม เช่น Nansen และ Dune Analytics สามารถใช้ประโยชน์จากชุดข้อมูลที่ครอบคลุมนี้สำหรับการวิเคราะห์เชิงลึกได้
อย่างไรก็ตาม สำหรับสัญญาอัจฉริยะที่ฝังอยู่ในเครื่องเสมือนบล็อคเชน ข้อจำกัดในการเข้าถึงข้อมูลนั้นยิ่งใหญ่กว่ามาก พวกเขาไม่สามารถใช้ข้อมูลที่สร้างโดยโซลูชันการจัดทำดัชนีแบบออฟไลน์ได้ เนื่องจากจะสร้างปัญหาความน่าเชื่อถือเพิ่มเติมสำหรับโซลูชันการจัดทำดัชนีภายนอกและบ่อยครั้งที่รวมศูนย์เหล่านี้
ในความเป็นจริง สัญญาอัจฉริยะสามารถเข้าถึงข้อมูลต่อไปนี้ได้อย่างง่ายดายและไม่น่าเชื่อถือเท่านั้น:
ข้อมูลที่จัดเก็บไว้ในสถานะเครื่องเสมือน (ไม่รวมข้อมูลธุรกรรมหรือเหตุการณ์)
ข้อมูลในบล็อกล่าสุด (จำกัดการเข้าถึงข้อมูลประวัติ)
ข้อมูลจากสัญญาอัจฉริยะอื่นๆ ที่เปิดเผยผ่านฟังก์ชัน ดู (ไม่รวมข้อมูลสัญญาส่วนตัวหรือภายใน)
ความแตกต่างที่สำคัญในข้อความข้างต้นคือคำว่า ง่าย
สัญญาอัจฉริยะไม่ได้รับรู้ข้อมูลทั้งหมดในบล็อกเชนอย่างสมบูรณ์ ใน EVM สัญญาอัจฉริยะสามารถเข้าถึงแฮชส่วนหัวของบล็อกของ 256 บล็อกล่าสุด ส่วนหัวของบล็อกเหล่านี้รวมกิจกรรมทั้งหมดบนบล็อกเชนจนถึงบล็อกปัจจุบัน ซึ่งย่อเป็นค่าแฮชขนาด 32 ไบต์ผ่านแผนผัง Merkle และแฮช Keccak
ของที่บีบอัดก็แตกได้...มันไม่ง่ายเลย😂
ลองนึกภาพหากคุณต้องการเข้าถึงข้อมูลเฉพาะในบล็อกก่อนหน้าอย่างไม่ไว้วางใจโดยใช้ส่วนหัวของบล็อกล่าสุด แนวทางนี้เกี่ยวข้องกับการรับข้อมูลนอกเครือข่ายจากโหนดเก็บถาวร จากนั้นสร้างแผนผัง Merkle และบล็อกการพิสูจน์ความถูกต้องเพื่อกำหนดความถูกต้องของข้อมูลในบล็อกเชน หลักฐานความถูกต้องจะถูกประมวลผลโดย EVM เพื่อการตรวจสอบและการตีความ การดำเนินการดังกล่าวยุ่งยากและลำบาก และอาจต้องใช้ Gas หลายสิบล้านเพื่อเรียกคืนโทเค็นยอดคงเหลือสองสามรายการที่ผ่านมา
รากฐานของความท้าทายนี้คือตัวบล็อกเชนเสมือนไม่สามารถจัดการข้อมูลจำนวนมากและการคำนวณที่เข้มข้นได้ (เช่น งานคลายการบีบอัดที่กล่าวถึงข้างต้น)
สถาปัตยกรรมตัวประมวลผลร่วม ZK
(ที่มา: สไลด์การนำเสนอของ Brevis ที่ ETHSG)
คงจะเหมาะเป็นอย่างยิ่งหากมีเวทย์มนตร์ที่ทำให้บล็อกเชนมอบหมายการคำนวณที่ต้องใช้ข้อมูลจำนวนมากและน่าเบื่อ และรับผลลัพธ์อย่างรวดเร็วด้วยต้นทุนที่ต่ำ และไม่มีสมมติฐานเกี่ยวกับความไว้วางใจเพิ่มเติมใดๆ
เพื่อน ๆ นั่นคือสิ่งที่โปรเซสเซอร์ร่วม ZK มีไว้เพื่อ
ชื่อ โปรเซสเซอร์ร่วม ได้รับแรงบันดาลใจจากประวัติความเป็นมาของสถาปัตยกรรมคอมพิวเตอร์ ตัวอย่างเช่น GPU ถูกนำมาใช้เป็นโปรเซสเซอร์ร่วมของ CPU เนื่องจาก CPU จะต้องมอบหมายงานการประมวลผลที่สำคัญบางอย่าง (เช่น การประมวลผลกราฟิกหรือการฝึกอบรมปัญญาประดิษฐ์) ที่มีราคาแพงและยากต่อการทำงานด้วยตัวเองให้กับ โปรเซสเซอร์เสริม นั่นคือ GPU
แต่ ZK ในโปรเซสเซอร์ร่วม ZK หมายถึงอะไร ก่อนที่เราจะเจาะลึกรายละเอียดทางเทคนิคที่ซับซ้อน เรามาดูความหมายและศักยภาพในวงกว้างของเทคโนโลยีที่เป็นนวัตกรรมนี้กันก่อน
เราต้องการ dApps ที่ขับเคลื่อนด้วยข้อมูลใน Web 3.0
การคืนเงินค่าธรรมเนียมการซื้อขายเป็นตัวอย่างที่ดี ตามแนวคิดนี้ ด้วยโปรเซสเซอร์ร่วม ZK โปรแกรมสะสมคะแนนต่างๆ สามารถนำไปใช้กับโปรโตคอล DeFi ต่างๆ ได้อย่างราบรื่น
อย่างไรก็ตาม นี่เป็นมากกว่าโปรแกรมสะสมคะแนน DeFi ตอนนี้คุณคงเห็นแล้วว่ามีปัญหาเดียวกันนี้ในส่วนอื่นๆ ของ Web 3.0 หากคุณลองคิดดู แอปพลิเคชัน Web 2.0 สมัยใหม่ทั้งหมดนั้นขับเคลื่อนด้วยข้อมูล แต่แอปพลิเคชัน Web 3.0 ก็ไม่มีข้อยกเว้น แนวทางที่ขับเคลื่อนด้วยข้อมูลนี้เป็นสิ่งที่ขาดไม่ได้หากเราต้องการสร้าง แอปพลิเคชันนักฆ่า และทำให้ประสบการณ์ผู้ใช้เทียบได้กับแอปพลิเคชันอินเทอร์เน็ตแบบดั้งเดิม
ลองดูอีกตัวอย่างหนึ่งจากพื้นที่ DeFi: ปรับปรุงประสิทธิภาพสภาพคล่องโดยการออกแบบกลไกการให้รางวัลการขุดสภาพคล่องใหม่
ปัจจุบัน กลไกสิ่งจูงใจด้านสภาพคล่องบน AMM DEX ใช้โมเดล จ่ายตามการใช้งาน ในโหมดนี้ รางวัลการทำฟาร์มจะแจกจ่ายให้กับ LP ทันทีเมื่อรางวัลเหล่านั้นมีส่วนทำให้มีสภาพคล่อง อย่างไรก็ตามรุ่นนี้ยังห่างไกลจากความเหมาะสม เกษตรกรมืออาชีพสามารถถอนสภาพคล่องได้อย่างรวดเร็วเมื่อรับรู้ถึงความผันผวนของตลาดเพื่อหลีกเลี่ยงการสูญเสียที่ไม่ถาวร ด้วยวิธีนี้ พวกเขาให้มูลค่าที่น้อยที่สุดแก่โปรโตคอล แต่ยังคงได้รับผลตอบแทนที่สำคัญ
กลไกจูงใจด้านสภาพคล่องของ AMM ในอุดมคติจะประเมินความมั่นคงของ LP ย้อนหลัง โดยเฉพาะอย่างยิ่งในช่วงที่ตลาดมีความผันผวนอย่างมาก ผู้ที่สนับสนุนพูลในสถานการณ์เช่นนี้เสมอควรได้รับรางวัลสูงสุด อย่างไรก็ตาม การได้รับข้อมูลพฤติกรรม LP ในอดีต ซึ่งมีความสำคัญสำหรับโมเดลนี้ ยังคงเป็นไปไม่ได้ในปัจจุบัน
เมื่อต้องการทำเช่นนี้ คุณต้องมีตัวประมวลผลร่วม ZK
ในพื้นที่ DeFi เราสามารถอ้างอิงตัวอย่างที่คล้ายกันมากมาย ไม่ว่าจะเป็นการใช้อัลกอริธึมและกฎที่กำหนดไว้ล่วงหน้าสำหรับการจัดการตำแหน่ง LP ที่ใช้งานอยู่ การใช้ตำแหน่งสภาพคล่องที่ไม่ใช่โทเค็นเพื่อสร้างวงเงินเครดิต หรือการกำหนดลักษณะการชำระบัญชีแบบไดนามิกสำหรับสินเชื่อตามพฤติกรรมการชำระคืนในอดีต
อย่างไรก็ตาม ศักยภาพของโปรเซสเซอร์ร่วม ZK ไม่ได้จำกัดอยู่ที่ DeFi
ใช้โปรเซสเซอร์ร่วม ZK เพื่อสร้างเกมออนไลน์พร้อมประสบการณ์ผู้ใช้ที่ยอดเยี่ยม
ตัวอย่างฟังก์ชันการทำงานแบบเรียลไทม์ของเกม Web 2.0
เมื่อคุณเข้าสู่เกม Web 2.0 ที่ติดตั้งใหม่ ทุกการเคลื่อนไหวของคุณจะถูกบันทึกอย่างละเอียด ข้อมูลเหล่านี้จะไม่ถูกใช้งาน แต่จะส่งผลอย่างมากต่อเส้นทางการเล่นเกมของคุณ โดยจะตัดสินใจว่าเมื่อใดที่จะเสนอตัวเลือกการซื้อในเกมให้คุณ เมื่อใดที่จะเปิดตัวเกมโบนัส เมื่อใดที่ควรส่งการแจ้งเตือนแบบพุชด้วยคำพูดอย่างระมัดระวังถึงคู่ต่อสู้ที่คุณคู่ควรด้วย และอื่นๆ สิ่งเหล่านี้คือองค์ประกอบทั้งหมดของสิ่งที่อุตสาหกรรมเกมเรียกว่าการดำเนินงานแบบเรียลไทม์ (LiveOps) และเป็นรากฐานสำคัญของการเพิ่มการมีส่วนร่วมของผู้เล่นและแหล่งรายได้
คุณสมบัติ LiveOps เหล่านี้จำเป็นเพื่อให้ประสบการณ์ผู้ใช้ของเกมออนไลน์เต็มรูปแบบเทียบได้กับเกมคลาสสิกของ Web 2.0 คุณสมบัติเหล่านี้ควรอิงตามการโต้ตอบและธุรกรรมในอดีตของผู้เล่นกับสัญญาอันชาญฉลาดของเกม
น่าเสียดายที่ในเกมบล็อคเชน ฟังก์ชั่นดังกล่าวขาดหายไปโดยสิ้นเชิงหรือยังคงขับเคลื่อนโดยโซลูชั่นแบบรวมศูนย์ เหตุผลเหมือนกับตัวอย่าง DEX: เป็นการยากที่จะขุดและคำนวณข้อมูลเกมในอดีตบนบล็อกเชน
ใช่ อีกครั้ง คุณต้องมีตัวประมวลผลร่วม ZK เพื่อให้บรรลุเป้าหมายนี้
แอปพลิเคชันโซเชียลและการระบุตัวตน Web 3.0 เป็นอีกพื้นที่หนึ่งที่ไม่สามารถทำงานได้หากไม่มีการสนับสนุนตัวประมวลผลร่วม ZK
ในโลกบล็อกเชน ข้อมูลประจำตัวดิจิทัลของคุณคือเว็บที่ถักทอจากการกระทำในอดีตของคุณ
ต้องการพิสูจน์ว่าคุณเป็น NFT OG หรือไม่? คุณต้องพิสูจน์ว่าคุณเป็นหนึ่งในนักขุดดั้งเดิมของ Cryptopunk
คุยโม้เกี่ยวกับการเป็นเทรดเดอร์ที่ยอดเยี่ยมใช่ไหม? พิสูจน์ให้ฉันเห็นว่าคุณได้จ่ายค่าธรรมเนียมการซื้อขายบน DEX มากกว่า $1 ล้าน
มีความสัมพันธ์ใกล้ชิดกับ Vitalik? พิสูจน์ให้ฉันเห็นว่าที่อยู่ของเขาส่งเงินไปยังที่อยู่ของคุณ
ระบบออฟเชน ไม่ว่าจะเป็นมนุษย์หรือแอปพลิเคชัน Web 2.0 สามารถสร้างการพิสูจน์ดังกล่าวได้อย่างง่ายดาย เนื่องจากระบบดังกล่าวสามารถเข้าถึงโหนดเก็บถาวรที่มีข้อมูลทั้งหมดนี้ เช่นเดียวกับตัวอย่างปริมาณธุรกรรม
การพิสูจน์ตัวตนตามการเข้าถึงข้อมูลโดยตรงนี้จำเป็นต้องมีการเชื่อมโยงที่อยู่กระเป๋าเงินที่แข็งแกร่ง ดังนั้นจึงต้องทนทุกข์ทรมานจากข้อเสียของการเสียสละความเป็นส่วนตัว แต่ก็เป็นไปได้
อย่างไรก็ตาม เช่นเดียวกับในตัวอย่างปริมาณธุรกรรม หากคุณต้องการให้สัญญาอัจฉริยะเชื่อถือตัวตน OG ของคุณและเข้าถึงสิ่งใหม่ๆ ก่อนใครโดยไม่ต้องมีหลักฐานพิสูจน์ความน่าเชื่อถือเพิ่มเติม ไม่มีวิธีใดที่ดีเลย
ด้วยโปรเซสเซอร์ร่วม ZK คุณสามารถสร้างหลักฐานพิสูจน์ตัวตนที่เชื่อถือได้ หลักฐานการกระทำในอดีตของคุณ หลักฐานที่สัญญาอัจฉริยะใดๆ จะยอมรับโดยไม่มีคำถาม การโต้ตอบของคุณในแอปพลิเคชันต่างๆ และแม้กระทั่งบล็อกเชนที่แตกต่างกันสามารถนำมารวมกันอย่างลงตัวเพื่อสร้างหลักฐานนี้
สิ่งที่น่าสนใจยิ่งกว่าคือความเป็นส่วนตัวโดยธรรมชาติของ ZK ที่อยู่กระเป๋าเงินของคุณไม่จำเป็นต้องเชื่อมโยงกับข้อมูลประจำตัวของคุณแบบสาธารณะ ตัวอย่างเช่น คุณสามารถพิสูจน์ได้ว่าคุณเป็นเจ้าของ Cryptopunk NFT โดยไม่ต้องเปิดเผยที่อยู่กระเป๋าเงินเฉพาะ หรือคุณสามารถพิสูจน์ได้ว่าคุณได้ทำธุรกรรม 10,000 รายการบน Uniswap โดยไม่เปิดเผยจำนวนที่แน่นอน
โปรเซสเซอร์ร่วม ZK เปิดขอบเขตใหม่ของการสร้าง dApp ที่ขับเคลื่อนด้วยข้อมูล แต่มันมีอะไรมากกว่านั้นอีกมาก
นอกเหนือจากกระบวนทัศน์ที่ขับเคลื่อนด้วยข้อมูล: การใช้ตัวประมวลผลร่วม ZK เพื่อสร้างโหมดอะซิงโครนัสสำหรับ Web 3.0
แม้ว่าโมเดล dApp ที่ขับเคลื่อนด้วยข้อมูลจะน่าดึงดูด แต่ก็เป็นเพียงส่วนเล็กเท่านั้น
การเกิดขึ้นของตัวประมวลผลร่วม ZK จะเปลี่ยนมุมมองของเราเกี่ยวกับการประมวลผลบล็อกเชนโดยสิ้นเชิง และสร้างยุคที่การประมวลผลแบบอะซิงโครนัสกลายเป็นมาตรฐาน Web 3.0 การเปลี่ยนแปลงนี้จะกำหนดวิธีจัดการงานใหม่ โดยโปรเซสเซอร์พิเศษสามารถทำงานได้อย่างอิสระ และเพิ่มประสิทธิภาพ
ให้เราทำความเข้าใจก่อนว่าการประมวลผลแบบอะซิงโครนัสคืออะไร
ลองนึกภาพร้านอาหารที่ประสานกันโดยที่บุคคลหนึ่งรับบทเป็นเชฟและพนักงานเสิร์ฟในเวลาเดียวกัน เมื่อคุณสั่งอะไรสักอย่าง เขาจะเริ่มจัดเตรียมและให้คุณรอ เขาสามารถรอลูกค้ารายอื่นหลังจากให้บริการคุณเท่านั้น แม้ว่าการตั้งค่านี้อาจเหมาะกับความต้องการของคุณ แต่ก็อาจเป็นเรื่องยากที่จะมีประสิทธิภาพสำหรับผู้อื่น
ในทางตรงกันข้าม ในร้านอาหารแบบอะซิงโครนัส เชฟและพนักงานเสิร์ฟที่แตกต่างกันจะทำงานร่วมกัน หลังจากที่บริกรรับออเดอร์ของคุณแล้ว เขาจะรีบโอนไปให้เชฟในขณะที่เสิร์ฟลูกค้ารายอื่นไปด้วย เมื่อทำอาหารเสร็จ เชฟจะส่งสัญญาณบอกพนักงานเสิร์ฟ จากนั้นจึงเสิร์ฟอาหารให้คุณ
ในระบบคอมพิวเตอร์:
สถาปัตยกรรมแบบซิงโครนัสเปรียบเสมือนร้านอาหารแห่งแรกที่คนคนหนึ่งรอแต่ละงานให้เสร็จก่อนที่จะดำเนินการต่อ สถาปัตยกรรมนี้เรียบง่ายและตรงไปตรงมา แต่อาจช้าได้เนื่องจากจะจัดการได้ครั้งละหนึ่งงานเท่านั้น นอกจากนี้บุคคลนี้อาจเป็นพนักงานเสิร์ฟที่ดีแต่ทำอาหารไม่เก่ง
สถาปัตยกรรมแบบอะซิงโครนัสเปรียบเสมือนร้านอาหารแห่งที่สองที่มีส่วนประกอบของระบบที่แยกส่วนและเชี่ยวชาญซึ่งส่งข้อมูลและงานให้กันและกันเพื่อเป็นช่องทางในการประสานงาน ซึ่งช่วยให้แต่ละส่วนประกอบสามารถจัดการสายงานของตนเองได้พร้อมๆ กัน แม้ว่าอาจต้องใช้วิธีการจัดการที่ซับซ้อนมากขึ้น แต่สถาปัตยกรรมนี้ก็รวดเร็วและมีประสิทธิภาพมากกว่า
แอปพลิเคชันอินเทอร์เน็ตสมัยใหม่ทุกตัวสร้างขึ้นบนสถาปัตยกรรมอะซิงโครนัสเพื่อประสิทธิภาพและความสามารถในการขยายขนาด และเราคิดว่า Web 3.0 ก็ควรจะเป็นเช่นนั้นเช่นกัน
ตัวประมวลผลร่วม ZK จะเป็นผู้นำของการเปลี่ยนแปลงนี้ สำหรับนักพัฒนา dApp บล็อกเชนเปรียบเสมือนพนักงานเสิร์ฟในร้านอาหารแบบอะซิงโครนัสของเรา โดยส่วนใหญ่จะจัดการกับการคำนวณที่เปลี่ยนแปลงสถานะของบล็อคเชนโดยตรง เช่น การเปลี่ยนแปลงความเป็นเจ้าของสินทรัพย์ที่อาจเกิดขึ้น การคำนวณอื่นๆ ทั้งหมดได้รับการจัดการโดยโปรเซสเซอร์ร่วม ZK ที่แข็งแกร่ง ซึ่งเหมือนกับมาสเตอร์เชฟ ที่ใช้พลังของการประมวลผลแบบอะซิงโครนัสเพื่อปรุงผลลัพธ์อย่างมีประสิทธิภาพและส่งให้กับพนักงานเสิร์ฟ
โดยเฉพาะอย่างยิ่ง หากการคำนวณในแอปพลิเคชันบล็อกเชนตรงตามเงื่อนไขหนึ่งในสอง เงื่อนไขความเป็นไปได้ ต่อไปนี้ คุณควรพิจารณาใช้ตัวประมวลผลร่วม ZK
เงื่อนไขการดำเนินการของตัวประมวลผลร่วม ZK:
ต้นทุนการประมวลผลแบบออนไลน์ > (การคำนวณตัวประมวลผลร่วม ZK แบบออฟไลน์ (รวมถึงการสร้างหลักฐาน) + ต้นทุนการตรวจสอบแบบออนไลน์)
ความล่าช้าในการคำนวณแบบออนไลน์ > (การคำนวณตัวประมวลผลร่วม ZK แบบออฟไลน์ (รวมถึงการสร้างหลักฐาน) + ความล่าช้าในการตรวจสอบความถูกต้องแบบออนไลน์)
แม้ว่าพวกเขาจะมีคุณสมบัติเพียงอย่างใดอย่างหนึ่ง แต่ก็คุ้มค่าที่จะพิจารณา!
ตอนนี้คุณจะเห็นแล้วว่าไม่ใช่แค่ dApps ที่ขับเคลื่อนด้วยข้อมูลเท่านั้น! มันเป็นวิธีใหม่โดยสิ้นเชิงในการนำการประมวลผลระดับสูงทั่วไป เช่น ML มาสู่บล็อกเชน แต่ที่สำคัญกว่านั้น มันยังแนะนำสถาปัตยกรรมอะซิงโครนัสที่เปลี่ยนแปลงกระบวนทัศน์สำหรับการสร้าง dApps ที่ไม่เคยทำได้มาก่อน
บทต่อไป….
หากเราประสบความสำเร็จในการโน้มน้าวคุณว่าตัวประมวลผลร่วม ZK เป็นแนวคิดที่จะมีผลกระทบในวงกว้าง อาจถึงเวลาที่ต้องพูดถึงวิธีการทำงานของพวกมัน ในบล็อกถัดไป เราจะสำรวจสถาปัตยกรรมหลักของตัวประมวลผลร่วม ZK และหารือเกี่ยวกับความท้าทายทางเทคนิคที่ใหญ่ที่สุดที่ยังคงอยู่ในพื้นที่นี้
