Vitalik Buterin: เทคโนโลยี zk-SNARKs ปกป้องความเป็นส่วนตัวอย่างไร

zk-SNARKs เป็นเครื่องมือเข้ารหัสที่ทรงพลังซึ่งกลายเป็นส่วนสำคัญมากขึ้นเรื่อยๆ ของทั้งแอปพลิเคชันบล็อกเชนและที่ไม่ใช่บล็อกเชน ความซับซ้อนปรากฏชัดทั้งในการทำความเข้าใจวิธีการทำงานและวิธีการนำไปใช้อย่างมีประสิทธิผล บทความนี้เจาะลึกถึงวิธีที่ zk-SNARK ปรับเข้ากับแอปพลิเคชันปัจจุบัน ให้ตัวอย่างสิ่งที่ทำได้และไม่สามารถบรรลุผลสำเร็จ และเสนอแนวทางทั่วไปว่าเมื่อใดที่ zk-SNARK เหมาะสำหรับแอปพลิเคชันเฉพาะ จะเน้นเป็นพิเศษไปที่บทบาทของพวกเขาในการรับรองความเป็นส่วนตัว

zk-SNARK คืออะไร?

ลองนึกภาพว่ามีอินพุตสาธารณะ x อินพุตส่วนตัว w และฟังก์ชัน (สาธารณะ) f(x,w) → {True,False} ซึ่งตรวจสอบอินพุต ด้วย zk-SNARK เราสามารถพิสูจน์ได้ว่าพวกเขารู้ aw โดยที่ f และ x ที่กำหนด f(x,w) = True ทั้งหมดนี้โดยไม่เปิดเผยว่าจริงๆ แล้ว w คืออะไร ยิ่งไปกว่านั้น ผู้ตรวจสอบสามารถตรวจสอบความถูกต้องของการพิสูจน์ได้เร็วกว่ามากเกินกว่าที่พวกเขาจะคำนวณ f(x,w) แม้ว่าพวกเขาจะรู้ w ก็ตาม

สิ่งนี้ทำให้ zk-SNARK มีคุณลักษณะสองประการ: ความเป็นส่วนตัวและความสามารถในการปรับขนาด ตามที่กล่าวไว้ ตัวอย่างของเราในบทความนี้จะเน้นที่ด้านความเป็นส่วนตัวเป็นหลัก

หลักฐานการเป็นสมาชิก

สมมติว่าคุณมีกระเป๋าเงิน Ethereum และคุณต้องการพิสูจน์ว่ากระเป๋าเงินนี้ลงทะเบียนภายใต้ระบบพิสูจน์ความเป็นมนุษย์ โดยไม่เปิดเผยว่าใครคือบุคคลที่ลงทะเบียนจริงๆ ฟังก์ชันนี้สามารถอธิบายได้ทางคณิตศาสตร์ดังนี้:

อินพุตส่วนตัว (w): ที่อยู่ของคุณ A, รหัสส่วนตัวของที่อยู่ของคุณ k

ข้อมูลสาธารณะ (x): ชุดที่อยู่ของโปรไฟล์หลักฐานพิสูจน์ความเป็นมนุษย์ที่ได้รับการตรวจสอบแล้วทั้งหมด {H1…Hn}

ฟังก์ชั่นการตรวจสอบ f(x,w):

ตีความ w เป็นคู่ (A, σ) และ x เป็นรายการโปรไฟล์ที่ถูกต้อง {H1…Hn}

ยืนยันว่า A เป็นหนึ่งในที่อยู่ใน {H1…Hn}

ยืนยัน privtoaddr(k) = A

หากผ่านการตรวจสอบทั้งสองรายการ ให้ส่งคืน True หากรายการใดรายการหนึ่งล้มเหลว ให้คืนค่า False

ผู้พิสูจน์สร้างที่อยู่ A และคีย์ที่เกี่ยวข้อง k โดยให้ w=(A,k) เป็นอินพุตส่วนตัวสำหรับ f พวกเขาได้รับข้อมูลสาธารณะ ซึ่งเป็นชุดปัจจุบันของโปรไฟล์การพิสูจน์ความเป็นมนุษย์ที่ได้รับการตรวจสอบแล้ว {H1…Hn} จากห่วงโซ่ จากนั้นพวกเขาจะรันอัลกอริธึมการพิสูจน์ zk-SNARK ซึ่ง (สมมติว่าอินพุตถูกต้อง) จะสร้างการพิสูจน์ หลักฐานนี้จะถูกส่งไปยังผู้ตรวจสอบ พร้อมด้วยความสูงของบล็อกที่พวกเขาดึงรายการโปรไฟล์ที่ได้รับการยืนยัน

ผู้ตรวจสอบยังอ่านสายโซ่ โดยรับรายการ {H1…Hn} จากความสูงที่ระบุโดยผู้พิสูจน์ และตรวจสอบการพิสูจน์ หากการตรวจสอบเสร็จสมบูรณ์ ผู้ตรวจสอบจะเชื่อว่าผู้พิสูจน์มีโปรไฟล์การพิสูจน์ความเป็นมนุษย์ที่ได้รับการตรวจสอบแล้ว

ก่อนที่จะเจาะลึกตัวอย่างที่ซับซ้อนมากขึ้น ฉันขอแนะนำอย่างยิ่งให้ทำความเข้าใจตัวอย่างข้างต้นอย่างถ่องแท้

ทำให้หลักฐานการเป็นสมาชิกมีประสิทธิภาพมากขึ้น

ข้อเสียเปรียบประการหนึ่งของระบบพิสูจน์ที่กล่าวมาข้างต้นคือผู้ตรวจสอบจำเป็นต้องทราบชุดโปรไฟล์ทั้งหมด {H1…Hn} ซึ่งต้องใช้เวลา O(n) เพื่อ "ป้อน" ชุดนี้ลงในกลไก zk-SNARK ปัญหานี้สามารถแก้ไขได้โดยใช้รูท Merkle แบบออนไลน์ ซึ่งครอบคลุมโปรไฟล์ทั้งหมดเป็นอินพุตสาธารณะ (อาจเป็นเพียงรูทสถานะ) เราเพิ่มข้อมูลส่วนตัวอีกรายการหนึ่ง นั่นคือ Merkle proof M เพื่อยืนยันว่าบัญชีของผู้พิสูจน์ A อยู่ในส่วนที่เกี่ยวข้องของแผนผัง

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

ZK-SNARK และเหรียญ

โครงการเช่น Zcash และ Tornado.cash ช่วยให้เราสามารถครอบครองสกุลเงินที่ปกป้องความเป็นส่วนตัวได้ ตอนนี้ใครๆ ก็คิดว่าพวกเขาสามารถใช้ "การพิสูจน์โดยมนุษย์ ZK" ที่กล่าวถึงได้ แต่มันไม่ได้เกี่ยวกับการพิสูจน์การเข้าถึงการพิสูจน์โปรไฟล์ของมนุษย์ มันเกี่ยวกับการพิสูจน์การเข้าถึงเหรียญ นี่คือปัญหา: เราต้องจัดการทั้งความเป็นส่วนตัวและการใช้จ่ายซ้ำซ้อนพร้อมกัน นั่นคือเราไม่ควรใช้เหรียญเดียวกันสองครั้ง

ต่อไปนี้คือวิธีแก้ปัญหา: ใครก็ตามที่ครอบครองเหรียญจะมีความลับส่วนตัว “s” พวกเขาคำนวณ "leaf" L=hash(s,1) ในเครื่อง ซึ่งได้รับการเผยแพร่บนเครือข่าย และกลายเป็นส่วนหนึ่งของสถานะ N=hash(s,2) ซึ่งเราเรียกว่าตัวทำให้เป็นโมฆะ รัฐถูกเก็บไว้ในแผนภูมิ Merkle

หากต้องการใช้เหรียญ ผู้ส่งจะต้องสร้าง ZK-SNARK โดยที่:

• อินพุตสาธารณะประกอบด้วยตัว nullifier N, Merkle root R ปัจจุบันหรือล่าสุด และ leaf L' ใหม่ (มีไว้สำหรับผู้รับที่มีความลับ s' ส่งผ่านไปยังผู้ส่งเป็น L'=hash(s',1))

• อินพุตส่วนตัวประกอบด้วยข้อมูลลับ s ลีฟ L และสาขา Merkle M

การตรวจสอบฟังก์ชันการตรวจสอบ:

• M เป็นกิ่ง Merkle ที่ถูกต้อง โดยพิสูจน์ว่า L คือใบไม้ของต้นไม้ที่มีรากอยู่ที่ R โดยที่ R คือราก Merkle ของสถานะปัจจุบัน

• แฮช(s,1)=L และแฮช(s,2)=N

ธุรกรรมประกอบด้วยตัว nullifier N และลีฟใหม่ L' จริงๆ แล้วเราไม่ได้พิสูจน์อะไรเกี่ยวกับ L' แต่เป็นการ "ผสม" เข้ากับข้อพิสูจน์เพื่อป้องกันการแก้ไขโดยบุคคลที่สามในระหว่างการทำธุรกรรม เพื่อตรวจสอบความถูกต้องของธุรกรรม ลูกโซ่จะตรวจสอบ ZK-SNARK และตรวจสอบว่ามีการใช้ N ในการทำธุรกรรมก่อนหน้านี้หรือไม่ หากสำเร็จ N จะถูกเพิ่มเข้าไปในชุดของตัวลบล้างที่ใช้ไป ทำให้ไม่สามารถใช้งานได้อีกครั้ง L' ถูกเพิ่มเข้าไปในแผนผัง Merkle

เมื่อใช้ ZK-SNARK เราเชื่อมโยงสองค่า: L (ปรากฏบนสายโซ่เมื่อเหรียญถูกสร้างเสร็จ) และ N (ปรากฏขึ้นเมื่อใช้ไป) โดยไม่เปิดเผยว่า L ตัวใดเชื่อมต่อกับ N ตัวใด การเชื่อมต่อระหว่าง L และ N จะมองเห็นได้ก็ต่อเมื่อคุณ รู้ความลับที่สร้างมันขึ้นมา เหรียญที่สร้างเสร็จแต่ละเหรียญสามารถใช้ได้เพียงครั้งเดียว (เนื่องจากมี N ที่ถูกต้องเพียงอันเดียวสำหรับ L แต่ละอัน) แต่เหรียญเฉพาะที่ใช้ในเวลาใดก็ตามยังคงถูกปกปิดไว้

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

เหรียญที่มียอดคงเหลือตามอำเภอใจ

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

ZK การต่อต้านการปฏิเสธการให้บริการ

เครื่องมือต่อต้าน DOS ที่น่าสนใจ: ลองนึกภาพคุณมีเอกลักษณ์ออนไลน์บางอย่างที่ไม่ได้สร้างขึ้นง่าย ๆ อาจเป็นโปรไฟล์ที่พิสูจน์โดยมนุษย์หรือเครื่องมือตรวจสอบ ETH 32 รายการ หรือเพียงบัญชีที่มียอดคงเหลือ ETH ที่ไม่เป็นศูนย์ เราสามารถสร้างเครือข่ายเพียร์ทูเพียร์ที่ทนทานต่อ DOS ได้มากขึ้นโดยการยอมรับเฉพาะข้อความที่พิสูจน์ว่าผู้ส่งมีโปรไฟล์เท่านั้น แต่ละโปรไฟล์จะได้รับอนุญาตให้มีข้อความได้สูงสุด 1,000 ข้อความต่อชั่วโมง หากผู้ส่งโกง โปรไฟล์ของพวกเขาจะถูกลบออกจากรายการ แต่เราจะมั่นใจในความเป็นส่วนตัวได้อย่างไร?

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

เราจะแบ่งเวลาออกเป็นช่วงๆ แต่ละช่วงนาน 3.6 วินาที (คิดเป็น 1,000 ช่วงต่อชั่วโมง) เป้าหมายของเราคือการให้ผู้ใช้แต่ละคนส่งข้อความได้เพียงข้อความเดียวต่อช่วงเวลา ถ้าส่งพร้อมกันสองตัวจะโดนจับ เพื่อให้เกิดการระเบิดเป็นครั้งคราว พวกเขาสามารถใช้ช่วงเวลาล่าสุดได้ ดังนั้น หากผู้ใช้มีช่วงเวลาที่ไม่ได้ใช้ 500 ก็สามารถส่งข้อความได้ 500 ข้อความในคราวเดียว

มาตรการ

เริ่มจากเวอร์ชันพื้นฐานโดยใช้ตัวเว้นวรรค ผู้ใช้สร้าง nullifier ด้วย (N = \text{hash}(k, e)) โดยที่ (k) คือคีย์ของพวกเขา และ (e) คือหมายเลขยุค จากนั้นเผยแพร่ด้วยข้อความ (m) ZK-SNARK ทำให้สับสน (\text{hash}(m)) ไม่มีสิ่งใดเกี่ยวกับ (m) ที่ได้รับการยืนยันในกระบวนการนี้ ดังนั้นการพิสูจน์จึงผูกหลักฐานไว้ในข้อความเดียว หากผู้ใช้ผูกการพิสูจน์สองรายการกับข้อความสองข้อความที่แตกต่างกันโดยใช้ตัวลบล้างเดียวกัน ก็เสี่ยงต่อการถูกจับได้

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

สำหรับทุกยุค (e) เราเลือกบรรทัด (L_e(x) = \text{hash}(k, e) \times x + k) ความชันของเส้นคือ (\text{hash}(k, e)) และค่าตัดแกน y คือ (k) ซึ่งทั้งคู่ไม่รู้จักต่อสาธารณะ ในการสร้างใบรับรองสำหรับข้อความ (m) ผู้ส่งจะต้องจัดเตรียม (y = L_e(\text{hash}(m)) = \text{hash}(k, e) \times \text{hash}(m) + k ) พร้อมด้วยหลักฐาน ZK-SNARK ว่าการคำนวณ (y) นั้นแม่นยำ

โดยสรุป ZK-SNARK มีดังต่อไปนี้

อินพุตสาธารณะ:

• ({A_1…A_n}): รายการบัญชีที่ถูกต้อง

• (M): ข้อความกำลังได้รับการตรวจสอบโดยใบรับรอง

• (E): หมายเลขยุคของใบรับรอง

• (Y): การประเมินฟังก์ชันเส้น

อินพุตส่วนตัว:

• (K): รหัสส่วนตัวของคุณ

ฟังก์ชั่นการตรวจสอบ:

• ตรวจสอบว่า (\text{privtoaddr}(k)) มีอยู่ใน ({A_1…A_n}) หรือไม่

• ยืนยัน (y = \text{hash}(k, e) \time \text{hash}(m) + k)

แต่จะเกิดอะไรขึ้นถ้ามีคนใช้ยุคสมัยสองครั้ง? พวกเขาจะเปิดเผยค่าสองค่า (m_1) และ (m_2) พร้อมกับค่าใบรับรอง (y_1 = \text{hash}(k, e) \times \text{hash}(m_1) + k) และ (y_2 = \text{hash}(k, e) \times \text{hash}(m_2) + k) จากนั้นเราสามารถใช้สองจุดนี้เพื่อกู้คืนบรรทัดและต่อมาจุดตัด y ซึ่งเป็นคีย์ส่วนตัว

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

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

ชื่อเสียงเชิงลบของ ZK

ลองนึกภาพการก่อตั้ง 0chan ฟอรัมออนไลน์เช่น 4chan ที่นำเสนอการไม่เปิดเผยตัวตนโดยสมบูรณ์ (คุณไม่มีชื่อถาวรด้วยซ้ำ) แต่มีระบบชื่อเสียงในการโปรโมตเนื้อหาที่มีคุณภาพสูงขึ้น ระบบดังกล่าวอาจมี DAO กำกับดูแลเพื่อตั้งค่าสถานะโพสต์ที่ละเมิดกฎของระบบ โดยแนะนำกลไกการโจมตีสามครั้ง

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

โพสต์ที่เชื่อมโยง: ความรู้พื้นฐาน

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

อินพุตสาธารณะ:

• นัลลิฟายเออร์, เอ็น

• รูตสถานะ blockchain ล่าสุด R

• โพสต์เนื้อหา ('ผสม' ลงในหลักฐานเพื่อผูกเข้ากับโพสต์ โดยไม่มีการคำนวณใดๆ)

อินพุตส่วนตัว:

• รหัสส่วนตัวของคุณเค

• ข้อมูลประจำตัวภายนอก (ที่อยู่ A) หรือตัวทำให้เป็นโมฆะ Nprev ที่ใช้ในโพสต์ก่อนหน้า

• หลักฐาน Merkle, M, ว่าโซ่มี A หรือ Nprev

• โพสต์ที่คุณเผยแพร่โดยใช้บัญชีนี้

ฟังก์ชั่นการตรวจสอบ:

1. ยืนยันว่า M เป็นสาขา Merkle ที่ถูกต้อง โดยพิสูจน์ว่า (A หรือ Nprev แล้วแต่ว่าจะให้ไว้) เป็นใบของต้นไม้ที่มีราก R

2. ตรวจสอบ N = enc(i, k) โดยที่ enc เป็นฟังก์ชันการเข้ารหัส (เช่น AES)

3. ถ้า i=0 ให้ตรวจสอบ A=privtoaddr(k) หรือมิฉะนั้น ให้ตรวจสอบ Nprev=enc(i−1,k)

นอกเหนือจากการตรวจสอบความถูกต้องของการพิสูจน์แล้ว ลูกโซ่ยังตรวจสอบ (i) ว่า R เป็นรูทสถานะล่าสุดจริง ๆ และ (ii) ว่าไม่เคยใช้ตัวทำให้เป็นโมฆะ N มาก่อน จนถึงจุดนี้ มันคล้ายกับเหรียญรักษาความเป็นส่วนตัวที่อธิบายไว้ก่อนหน้านี้ แต่เราได้เพิ่มกระบวนการในการ 'สร้าง' บัญชีใหม่และลบความสามารถในการ 'ส่ง' บัญชีของคุณไปยังคีย์อื่น แต่ตัวสร้างค่าว่างทั้งหมดจะถูกสร้างขึ้นโดยใช้คีย์ดั้งเดิมแทน เราใช้ enc ที่นี่เพื่อทำให้ตัวลบล้างสามารถย้อนกลับได้ หากคุณมีคีย์ k คุณสามารถถอดรหัสตัว nullifier แบบออนไลน์ใดๆ ได้ หากผลลัพธ์เป็นดัชนีที่ถูกต้องแทนที่จะพูดพล่อยๆ แบบสุ่ม (เช่น เราสามารถตรวจสอบ dec(N) < 2^64) ได้ คุณจะรู้ว่า nullifier ถูกสร้างขึ้นโดยใช้คีย์ k

การเพิ่มชื่อเสียง:

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

เราได้ขยายข้อมูลที่จัดเก็บแบบออนไลน์สำหรับแต่ละโพสต์ แทนที่จะเก็บเฉพาะค่า nullifier N เราจะเก็บ {N, h¯, u¯} โดยที่:

• h! = hash(h, r) โดยที่ h แทนความสูงของบล็อกของสถานะรากที่อ้างอิงในการพิสูจน์

• u = hash(u, r) โดยที่ u คือคะแนนชื่อเสียงของบัญชี (เริ่มต้นที่ 0 สำหรับบัญชีใหม่)

R นี่คือค่าสุ่มที่เพิ่มเพื่อป้องกันไม่ให้ h และ u ถูกค้นพบผ่านการค้นหาแบบใช้กำลังดุร้าย ในแง่การเข้ารหัส การเพิ่ม R ทำให้แฮชมีความมุ่งมั่นแบบปกปิด

สมมติว่าโพสต์ใช้ root R และเก็บ {N, h¯, u¯} ภายในหลักฐาน มีการลิงก์ไปยังโพสต์ก่อนหน้าที่เก็บข้อมูล {Nprev, h¯prev, u¯prev} หลักฐานการโพสต์ยังต้องสำรวจรายการชื่อเสียงทั้งหมดที่โพสต์ระหว่าง hprev และ h สำหรับแต่ละ nullifier N ฟังก์ชันการตรวจสอบจะถอดรหัส N โดยใช้คีย์ของผู้ใช้ k หากการถอดรหัสออกผลลัพธ์เป็นดัชนีที่ถูกต้อง ระบบจะใช้การอัปเดตชื่อเสียง หากผลรวมของการอัปเดตชื่อเสียงทั้งหมดเท่ากับ δ จะพิสูจน์ว่า u = uprev + δ

หากเราต้องการใช้กฎ "การนัดหยุดงานสามครั้งแล้วคุณไม่อยู่" ZK-SNARK จะรับรองว่าคุณ > -3 ด้วย หากเราต้องการกฎที่โพสต์ที่มีตัวแทน ≥ 100 ได้รับแท็กพิเศษ “โพสต์ที่มีชื่อเสียงสูง” ก็สามารถทำได้เช่นกัน

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

การถือครองฝ่ายที่รวมศูนย์ต้องรับผิดชอบ

บางครั้ง จำเป็นต้องออกแบบระบบโดยมี “ผู้ปฏิบัติงาน” แบบรวมศูนย์ เหตุผลอาจแตกต่างกันไป ในบางครั้งเป็นเพราะความสามารถในการขยายขนาด และสำหรับเหตุผลอื่นๆ ก็เพื่อความเป็นส่วนตัว โดยเฉพาะอย่างยิ่งความเป็นส่วนตัวของข้อมูลที่ถือโดยผู้ให้บริการ ตัวอย่างเช่น ระบบการลงคะแนนเสียงต่อต้านการบีบบังคับของ MACI กำหนดให้ผู้ลงคะแนนเสียงส่งการลงคะแนนเสียงแบบออนไลน์ โดยเข้ารหัสด้วยคีย์ที่ถือโดยผู้ดำเนินการแบบรวมศูนย์ โอเปอเรเตอร์นี้จะถอดรหัสการโหวตออนไลน์ทั้งหมด นับคะแนน และแสดงผลสุดท้าย พวกเขาใช้ ZK-SNARK เพื่อพิสูจน์ว่าทุกสิ่งที่พวกเขาทำนั้นแม่นยำ ความซับซ้อนที่เพิ่มเข้ามานี้มีความสำคัญอย่างยิ่งต่อการรับประกันความเป็นส่วนตัวที่แข็งแกร่ง (เรียกว่าการต่อต้านการบีบบังคับ) ผู้ใช้ไม่สามารถพิสูจน์ให้ใครเห็นว่าตนลงคะแนนเสียงอย่างไร แม้ว่าพวกเขาต้องการก็ตาม ต้องขอบคุณบล็อคเชนและ ZK-SNARK ระดับความไว้วางใจของเราต่อผู้ดำเนินการจึงยังน้อยมาก ผู้ดำเนินการที่เป็นอันตรายสามารถฝ่าฝืนการต่อต้านการบีบบังคับ แต่เนื่องจากการโหวตถูกโพสต์บนบล็อคเชน พวกเขาจึงไม่สามารถโกงโดยการเซ็นเซอร์การโหวตได้ และเนื่องจากต้องระบุ ZK-SNARK พวกเขาจึงไม่สามารถโกงโดยการคำนวณผลลัพธ์ผิดได้

การรวม ZK-SNARK กับ MPC

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

อะไรที่เราไม่สามารถทำให้เป็นส่วนตัวได้?

ZK-SNARKs มีประสิทธิภาพสูงในการสร้างระบบที่ผู้ใช้มีสถานะส่วนตัว อย่างไรก็ตาม ไม่สามารถรักษาสถานะให้เป็นส่วนตัวที่ไม่มีใครรู้ได้ สำหรับข้อมูลที่จะพิสูจน์ ผู้พิสูจน์จะต้องรู้ด้วยข้อความธรรมดา Uniswap เป็นตัวอย่างที่ยากต่อการแปรรูป ใน Uniswap มี "เอนทิตี" เชิงตรรกะส่วนกลาง นั่นคือบัญชีผู้ให้บริการสภาพคล่องซึ่งไม่ได้เป็นของใครเลย และธุรกรรม Uniswap ทั้งหมดเกิดขึ้นกับบัญชีนี้ คุณไม่สามารถซ่อนสถานะของบัญชีนี้ได้ เนื่องจากมีคนจำเป็นต้องถือสถานะนี้เป็นข้อความธรรมดาเพื่อพิสูจน์ และธุรกรรมแต่ละรายการจะต้องมีส่วนร่วมอย่างจริงจัง คุณสามารถใช้วงจรที่อ่านไม่ออกของ ZK-SNARK เพื่อสร้าง Uniswap เวอร์ชันแบบรวมศูนย์ ปลอดภัย และเป็นส่วนตัว แต่ก็ไม่ชัดเจนว่าผลประโยชน์จะมีมากกว่าต้นทุนหรือไม่ มันอาจจะไม่ได้ให้ผลประโยชน์ที่แท้จริงใดๆ เลยด้วยซ้ำ: สัญญาจำเป็นต้องแจ้งให้ผู้ใช้ทราบถึงราคาสินทรัพย์ และการเปลี่ยนแปลงราคาต่อบล็อคสามารถเปิดเผยกิจกรรมการทำธุรกรรมได้ บล็อกเชนสามารถทำให้ข้อมูลของรัฐเป็นสากลได้ และ ZK-SNARK สามารถแปรรูปข้อมูลของรัฐได้ แต่ไม่มีวิธีการที่ชัดเจนในการทำให้เป็นสากลและแปรรูปข้อมูลของรัฐไปพร้อมๆ กัน

นำสิ่งพื้นฐานมารวมกัน

ในส่วนด้านบน เราเห็นตัวอย่างเครื่องมือที่มีประสิทธิภาพในตัวเอง แต่ยังสามารถใช้เป็นส่วนประกอบสำหรับแอปพลิเคชันอื่นๆ ได้ด้วย ตัวลบล้างซึ่งมีความสำคัญต่อสกุลเงิน จะปรากฏขึ้นอีกครั้งในกรณีการใช้งานอื่น ๆ เทคนิค "การเชื่อมโยงแบบบีบบังคับ" ที่ใช้ในส่วนชื่อเสียงเชิงลบมีการนำไปใช้อย่างกว้างขวาง วิธีนี้มีประสิทธิภาพสูงสำหรับแอปจำนวนมากที่ "โปรไฟล์" ของผู้ใช้เปลี่ยนแปลงเมื่อเวลาผ่านไปในรูปแบบที่ซับซ้อน และคุณต้องการบังคับให้ผู้ใช้ปฏิบัติตามกฎของระบบในขณะที่รักษาความเป็นส่วนตัว ผู้ใช้ยังสามารถมอบหมายให้แสดง "สถานะ" ภายในของตนโดยใช้แผนผัง Merkle ส่วนตัวเต็มรูปแบบ เครื่องมือ “กลุ่มความมุ่งมั่น” ที่กล่าวถึงสามารถสร้างได้ด้วย ZK-SNARK หากแอปบางตัวไม่สามารถทำงานได้แบบออนไลน์อย่างสมบูรณ์และต้องการตัวดำเนินการแบบรวมศูนย์ เทคนิคเดียวกันนี้ก็สามารถรักษาความซื่อสัตย์ของตัวดำเนินการได้ ZK-SNARK เป็นเครื่องมือที่มีศักยภาพ ซึ่งผสมผสานความรับผิดชอบและผลประโยชน์ด้านความเป็นส่วนตัวเข้าด้วยกัน แม้ว่าจะมีข้อจำกัด แต่ในบางกรณี การออกแบบแอปพลิเคชันที่ชาญฉลาดสามารถข้ามข้อจำกัดเหล่านี้ได้ ฉันหวังว่าจะเห็นแอปพลิเคชันอื่นๆ หันมาใช้ ZK-SNARK และในที่สุดก็สร้างแอปพลิเคชันที่รวม ZK-SNARK เข้ากับการเข้ารหัสรูปแบบอื่นๆ ในปีต่อๆ ไป

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [Foresightnews] ลิขสิทธิ์ทั้งหมดเป็นของผู้แต่งต้นฉบับ [Jacob Ko] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว