ข้อความถอดเสียงต่อไปนี้รวบรวมจาก Fork It ฉบับที่ 4Let’s Talk About MimbleWimble เพื่อให้แน่ใจว่าการอ่านมีความสมบูรณ์ เราถือว่า Zhang Ren เป็นมุมมองแรก จัดเรียงเนื้อหาบางส่วน และเสริมรายละเอียดทางเทคนิคในโปรแกรม (หากมีความคลาดเคลื่อนกับเนื้อหาของพอดแคสต์ เนื้อหา ของข้อนี้เป็นหลัก) นอกจากนี้รายละเอียดเล็กๆ น้อยๆ ในรายการพอดแคสต์ฉบับสมบูรณ์ก็น่าสนใจมาก โปรดคลิกลิงก์เพื่อฟัง
หากคุณมีความคิดเห็นอื่นๆ เกี่ยวกับ MimbleWimble ยินดีที่จะพูดคุยกับเราในพื้นที่แสดงความคิดเห็น
การตกแต่ง: Xiao Jie, Jin Xiaojia, การสอบเทียบ: Wan Cenchen, Zhang Ren
ทำความรู้จักกับ MimbleWimble
เมื่อประมาณ 2 ปีก่อน ฉันค้นพบโปรโตคอล MimbleWimble ในตอนนั้น ฉันคิดว่ามันน่าสนใจมากและเต็มไปด้วยความลึกลับ
ข้อตกลงนี้โพสต์โดยไม่ระบุตัวตนบน IRC Channel ของ Bitcoin ชื่อผู้เขียนนามแฝงคือชื่อของ Voldemort และเป็นชื่อของ Voldemort ใน "Harry Potter" เวอร์ชันภาษาฝรั่งเศสที่เรียกว่า Tom Elvis Jedusor ผู้เขียนใส่ Dot Onion ในเครือข่าย TorLinkของBlockstreamของAndrew Poelstraเชิงลึกวิจัยซึ่งพิสูจน์ความปลอดภัยของระบบ MimbleWimble คือความสมบูรณ์ที่แท้จริงของโปรโตคอลนี้ ดังนั้น ผู้เสนอข้อตกลงนี้สามารถรับเครดิตสำหรับ Idea และ Andrew Poelstra ควรรับเครดิตครึ่งหนึ่ง
จากมุมมองของนักเข้ารหัส มันไม่สมเหตุสมผลเลยที่จะจัดเก็บจำนวนการทำธุรกรรมทั้งหมดในรูปแบบข้อความล้วนบนบล็อกเชน ยิ่งไปกว่านั้น การเก็บธุรกรรมทั้งหมดที่ใช้ไปอย่างถาวรไว้ในฮาร์ดดิสก์ยังเป็นการสิ้นเปลืองอีกด้วย เพื่อความปลอดภัยของตัวโปรโตคอลเอง
และ MimbleWimble ก็ผสมผสานการออกแบบก่อนหน้านี้บางอย่างเข้าด้วยกันอย่างชาญฉลาดเพื่อแก้ปัญหาทั้งสองนี้ ทำให้ผู้คนรู้สึกสง่างามมาก
กำหนด MimbleWimble¶
เพื่อทำความเข้าใจกับ MimbleWimble คุณต้องทราบตำแหน่งของมันก่อนตำแหน่งของมันคือ Privacy Coในสกุลเงินดิจิทัลที่สามารถรองรับความเป็นส่วนตัวได้เป็นอย่างดี. ฉันคิดว่ามีเพียงสองเหรียญ Privacy ก่อน MimbleWimble หนึ่งเรียกว่า Zcash และอีกอันเรียกว่า Monero คนอื่น ๆ ที่อ้างว่าเป็น Privacy Coin นั้นไม่แข็งแกร่งพอในด้านเทคโนโลยี
แต่ Zcash และ Monero มีปัญหาเดียวกัน นั่นคือเพื่อความเป็นส่วนตัว ทั้งคู่จำเป็นต้องรักษาชุดที่จัดเก็บผลลัพธ์ธุรกรรมทั้งหมดที่ใช้ไป และเราเข้าใจได้ว่าเป็น "รายการโมฆะ"
หากคุณต้องการตรวจสอบว่าธุรกรรมใหม่เป็นธุรกรรมที่ถูกต้องหรือไม่ ก่อนอื่น คุณต้องตรวจสอบว่าอินพุตธุรกรรมของธุรกรรมใหม่อยู่ใน "รายการโมฆะ" หรือไม่ หากอินพุตธุรกรรมอยู่ใน "รายการโมฆะ" อยู่แล้ว แสดงว่า ข้อมูลที่ป้อนธุรกรรมหมดอายุแล้ว และหากไม่อยู่ใน "รายการโมฆะ" แสดงว่าการป้อนข้อมูลธุรกรรมนั้นถูกต้อง นักขุดจะรับรู้ธุรกรรม จากนั้นนักขุดจะใส่ธุรกรรมที่ป้อนลงใน "โมฆะ รายการ".
ดังนั้นสำหรับ Zcash และ Monero พวกเขาทั้งสองประสบปัญหาร้ายแรงมาก นั่นคือผลลัพธ์ของธุรกรรมที่เติบโตอยู่เสมอ หากโหนดเต็มเครือข่ายสาธารณะต้องการตรวจสอบว่าธุรกรรมใหม่ถูกต้องหรือไม่ จะต้องเก็บข้อมูลธุรกรรมชุดสมบูรณ์ เมื่อจำนวนการทำธุรกรรมสะสม จำนวนข้อมูลจะมากขึ้นเรื่อย ๆ และจะไม่เป็นมิตรต่อการใช้งาน
โปรโตคอล MimbleWimble ไม่มีปัญหานี้ มีความสามารถในการปรับขนาดได้ดีกว่า Zcash และ Monero และสามารถรับมือกับปัญหาการเติบโตของสถานะได้
ตัวอย่างเช่น Grin Coin ซึ่งใช้โปรโตคอล MimbleWimble ใช้พื้นที่ฮาร์ดดิสก์น้อยมาก และสามารถบีบอัดพื้นที่ฮาร์ดดิสก์ที่ใช้โดยเอาต์พุตธุรกรรมได้อย่างมาก
หากคุณเพียงแค่ลบเอาต์พุตธุรกรรมที่ใช้ไป เมื่อตรวจสอบความถูกต้องของบล็อก คุณจะไม่สามารถยืนยันได้ว่าบล็อกนั้นถูกต้องหรือไม่ และคุณไม่สามารถตรวจสอบลายเซ็นธุรกรรมได้ แต่ปัญหานี้ไม่มีอยู่ในโปรโตคอล MimbleWimble
สำหรับ MimbleWimble หลังจากลบเอาต์พุตธุรกรรมที่ใช้ไปและอินพุตธุรกรรมที่เกี่ยวข้องแล้ว การตรวจสอบกราฟธุรกรรมทั้งหมดจะไม่ได้รับผลกระทบเลย และลายเซ็นที่เหลือทั้งหมดจะยังคงใช้ได้ และหลังจากลบเอาต์พุตธุรกรรมที่ใช้ไปแล้ว บล็อกเชนทั้งหมดยังคงสามารถตรวจสอบได้โดยใช้ลายเซ็นและปริมาณงาน
คุณสามารถเข้าใจได้ง่ายๆ ว่านี่คือบางอย่างเช่น Accumulator ซึ่งสามารถบีบอัดหลักฐานการเข้ารหัสในอดีตจำนวนมากให้เป็นหลักฐานขนาดเล็ก คล้ายกับ Merkle Tree แต่จะมีประสิทธิภาพและประสิทธิผลมากกว่า Merkle Tree
3 ความเข้าใจผิดเกี่ยวกับ MimbleWimble
ความเชื่อที่ 1: พื้นที่บีบอัด = ความเป็นส่วนตัวที่ดีกว่า?
หลายคนขายคุณลักษณะของพื้นที่เก็บข้อมูลบนฮาร์ดดิสก์ที่ถูกบีบอัดของ MimbleWimble ว่าเป็นความเป็นส่วนตัวที่ดีกว่า แต่ในความเป็นจริงแล้ว มันไม่ได้ให้ความเป็นส่วนตัวที่ดีกว่า หากคุณเลือกที่จะบีบอัดพื้นที่ว่างในฮาร์ดดิสก์ของคุณ และคนอื่นๆ เลือกที่จะไม่บีบอัด พวกเขายังสามารถรับกราฟธุรกรรมที่สมบูรณ์ได้ และพวกเขาสามารถขุดค้นความสัมพันธ์ของธุรกรรมของธุรกรรมจากมันได้
แน่นอนว่าเมื่อทำการลบพื้นที่จัดเก็บในฮาร์ดดิสก์ ก็ยังจำเป็นต้องเก็บข้อมูลบล็อกเดิมของสองสามวันล่าสุดไว้ เนื่องจากยังไม่ทราบว่าจะมีส้อม การโจมตีซ้ำซ้อน เป็นต้น เมื่อพิจารณาแล้วว่าสายโซ่ยาวเพียงพอและข้อมูลจะไม่ถูกเปลี่ยนแปลง พื้นที่ว่างในฮาร์ดดิสก์ที่ถูกกำหนดว่าจะไม่เปลี่ยนแปลงจะถูกบีบอัด
โหนดแบบเต็มในเครือข่ายโดยทั่วไปจะตัดพื้นที่จัดเก็บตามค่าเริ่มต้น แต่ซอร์สโค้ดสามารถแก้ไขได้เพื่อไม่ให้ถูกตัด
ความเชื่อที่ 2: ฝ่ายเดียวสามารถปฏิเสธการทำธุรกรรมได้หรือไม่?
โปรโตคอล MimbleWimble มีคุณสมบัติที่วิธีการสร้างธุรกรรมเป็นแบบโต้ตอบ ซึ่งหมายความว่าการทำธุรกรรมจะต้องเสร็จสมบูรณ์โดยมีส่วนร่วมของทั้งสองฝ่าย ซึ่งแตกต่างจาก Bitcoin และ Ethereum อย่างมาก
ยกตัวอย่าง Grin ซึ่งใช้โปรโตคอล MimbleWimble ถ้าฉันให้เงินกับการแลกเปลี่ยนและการแลกเปลี่ยนไม่ทำอะไรเลยก็จะไม่ได้รับเงิน เฉพาะเมื่อเข้าร่วมในโปรโตคอลที่โต้ตอบกับฉันและทำธุรกรรมทางกฎหมายให้เสร็จสมบูรณ์เท่านั้นจึงจะได้รับเงิน
ถ้ามันสร้างธุรกรรมทางกฎหมายนี้กับฉันแสดงว่ามันรู้ถึงการมีอยู่ของธุรกรรมนี้ ดังนั้น หากไม่มีการแลกเปลี่ยนที่จะให้เงินฉัน ฉันปฏิเสธได้ นี่เป็นความเข้าใจผิดของ MimbleWimble จากโลกภายนอก
ความเข้าใจผิด 3: การทำธุรกรรมจำเป็นต้องให้ทั้งสองฝ่ายออนไลน์พร้อมกัน?
การทำธุรกรรมแบบโต้ตอบนี้ไม่จำเป็นต้องให้ทั้งสองฝ่ายในการทำธุรกรรมออนไลน์ และทั้งสองฝ่ายในการทำธุรกรรมสามารถส่งอีเมลได้อย่างสมบูรณ์เพื่อให้โครงสร้างการทำธุรกรรมสมบูรณ์
เมื่อไม่นานมานี้ ฉันไปดูการสาธิตกระเป๋าเงินของ Grin Conf กระเป๋าเงินเก็บข้อมูลกลางในกระบวนการสร้างธุรกรรมเป็นไฟล์ สำหรับผู้ที่เข้ามา เขาสามารถสร้างไฟล์แล้วส่งไฟล์นี้ไปยังผู้รับธุรกรรม หลังจากที่ผู้รับธุรกรรมได้รับไฟล์แล้ว เขาสามารถลากไฟล์ไปยังไคลเอ็นต์กระเป๋าเงินของเขา สร้างธุรกรรมทั้งหมดในไคลเอนต์ และส่งกลับไปยังผู้ส่งธุรกรรมเป็นไฟล์เพื่อสร้างธุรกรรมให้เสร็จสมบูรณ์ ดังนั้น ทั้งสองฝ่ายจำเป็นต้องเข้าร่วม แต่ไม่ได้หมายความว่าทั้งสองฝ่ายจำเป็นต้องออนไลน์พร้อมกัน และอาจเป็นกระบวนการแบบอะซิงโครนัสก็ได้
รายละเอียดทางเทคนิคของ MimbleWimble
ตอนนี้ให้ฉันพูดถึงรายละเอียดทางเทคนิคของ MimbleWimble โดยละเอียด
MimbleWimble มีองค์ประกอบพื้นฐาน 3 ส่วน องค์ประกอบพื้นฐานแรกเรียกว่า CT (ธุรกรรมที่เป็นความลับ) องค์ประกอบพื้นฐานที่สองเรียกว่า Coin Join และองค์ประกอบที่สามเรียกว่า OWAS (One Way Aggregate Signatures)
สิ่งที่เราเพิ่งพูดถึงเป็นส่วนหนึ่งของ OWAS ตอนนี้ฉันจะให้ภาพรวมสั้น ๆ แก่คุณโดยเริ่มจาก CT CT นั้นซับซ้อนที่สุด และอีกสองอันที่เหลือนั้นค่อนข้างง่าย
Confidential Transaction
แนวคิดของ CT ถูกเสนอครั้งแรกโดย Adam Back CEO ของ Blockstream Adam Back เป็นที่รู้จักในฐานะเจ้าพ่อแห่ง Bitcoin เพราะเขาเป็นผู้ประดิษฐ์อัลกอริทึมการขุด Hashcash และเขาถูกอ้างถึงโดย Satoshi Nakamoto ในบทความ
สำหรับเครื่องขุดหรือโหนดเครือข่ายสาธารณะ พวกเขากังวลมากที่สุดว่าธุรกรรมบางอย่างเป็นธุรกรรมที่ถูกต้องหรือไม่ และธุรกรรมนั้นไม่ก่อให้เกิดอัตราเงินเฟ้อในระบบ (ไม่มีการสร้างเงินใหม่ ตัวอย่างเช่น ผู้ส่งใช้ 50 bitcoins และ ผู้รับได้รับ 50 แทน 51) นอกเหนือจากนั้น พวกเขาไม่สนใจจำนวนเงินที่แน่นอนของการทำธุรกรรม
ดังนั้นแนวคิดดั้งเดิมของการทำธุรกรรมที่เป็นความลับคือจำนวนการทำธุรกรรมสามารถแปลงเป็นไซเฟอร์เท็กซ์ได้หรือไม่ ในขณะที่ต้องแน่ใจว่าความถูกต้องของการทำธุรกรรมจะไม่ได้รับผลกระทบ
Gregory Maxwell เป็นผู้ร่วมก่อตั้ง Blockstream และเป็นหนึ่งในห้าผู้พัฒนาหลักรายแรกของ Bitcoin เขาออกแบบโปรโตคอลดังกล่าวจริง ๆ ซึ่งเข้ารหัสจำนวนเงินของธุรกรรมด้วยวิธีหนึ่ง ๆ แต่ไม่ส่งผลต่อความถูกต้องของธุรกรรมเลย เพศ.
โปรโตคอลสามารถแสดงอินพุตหรือเอาต์พุตของแต่ละธุรกรรมในรูปแบบต่อไปนี้: (เรียกอีกอย่างว่า Pedersen Commitment)
v*G+r*H
(โดยที่ v คือจำนวน, r คือตัวเลขสุ่มที่แสดงถึงปัจจัยที่ทำให้ไม่เห็น, G คือตัวสร้าง 1 และ H คือตัวสร้าง 2)
สิ่งนี้เรียกว่าการทำให้จำนวนเงินในการทำธุรกรรมไม่ชัดเจน และ "จำนวนเงิน" ของธุรกรรมนั้นเข้าใจได้ง่าย ตัวสร้าง 1 และตัวสร้าง 2 เป็นตัวกำเนิดสองตัวของการเข้ารหัสแบบเส้นโค้งวงรี ก่อนที่จะคูณค่าด้วยตัวสร้าง มันเป็นข้อความธรรมดา หลังจากคูณด้วยตัวสร้าง คุณสามารถเข้าใจได้ว่ามันเป็นศิลปะการเข้ารหัสแบบง่าย การดำเนินการนี้เป็นแบบทางเดียว แม้ว่าทุกคนจะรู้ว่าตัวสร้างคืออะไร แต่เมื่อคูณแล้วจะไม่สามารถย้อนกลับได้ และไม่มีใครรู้ว่าข้อความธรรมดาดั้งเดิมคืออะไร ปัญหานี้เรียกว่า "ปัญหาลอการิทึมไม่ต่อเนื่อง"
ปัจจัยที่ทำให้ไม่เห็นคือตัวเลขสุ่มที่เลือกโดยตัวสร้างของอินพุตหรือเอาต์พุตของธุรกรรม มีเพียงคุณเท่านั้นที่รู้จักหมายเลขสุ่มนี้และไม่สามารถบอกผู้อื่นได้
ข้อดีของการปิดบังจำนวนเงินแต่ละรายการคือสามารถเก็บ "โฮโมมอร์ฟิซึ่มเสริม" สูตรมีดังนี้:
(v1*G + r1*H)+(v2*G + r2*H)=(v1 + v2)*G+(r1 + r2)*H
(โดยที่ v1 และ v2 คือจำนวนธุรกรรม 1 และจำนวนธุรกรรม 2, r1 และ r2 คือปัจจัยที่ทำให้ไม่เห็น 1 และปัจจัยที่ทำให้ไม่เห็น 2, G คือตัวสร้าง 1 และ H คือตัวสร้าง 2)
การเพิ่มหมายเลขที่เข้ารหัสจะเทียบเท่ากับการเพิ่มหมายเลขที่เข้ารหัสก่อนที่จะเข้ารหัส
สิ่งที่สำคัญที่สุดจนถึงตอนนี้คือการทำความเข้าใจว่าโฮโมมอร์ฟิซึ่มแบบเติมคืออะไร นั่นคือ เพิ่มก่อนแล้วจึงเข้ารหัส และเข้ารหัสก่อนแล้วจึงเพิ่ม ผลลัพธ์ที่ได้จากสองลำดับการทำงานที่แตกต่างกันจะเหมือนกัน บุคคลที่ไม่ทราบจำนวนเฉพาะยังคงสามารถตรวจสอบความถูกต้องของธุรกรรมได้ และสามารถตรวจสอบได้ว่าผลรวมของจำนวนทั้งสองนั้นถูกต้อง
เมื่อเราต้องการเพิ่มค่าธรรมเนียมการทำธุรกรรมให้กับธุรกรรม ค่าธรรมเนียมนั้นจะถูกส่งไปยังนักขุดในรูปแบบข้อความล้วน และไม่จำเป็นต้องมีการดำเนินการเข้ารหัสและถอดรหัสที่ซับซ้อนเพิ่มเติมในค่าธรรมเนียมการทำธุรกรรม นักขุดเพิ่ม f*G ให้กับ Pedersen Commitment ของเอาต์พุตธุรกรรมเพื่อตรวจสอบว่า Pedersen Commitment ของอินพุตธุรกรรมสามารถสมดุลกันได้หรือไม่ (f แสดงถึงจำนวนค่าธรรมเนียมการทำธุรกรรม)
ประเด็นความรู้: Pedersen Commitment: แทนที่มูลค่า Transaction Output (UTXO) ที่ไม่ได้ใช้งานซึ่งแสดงเป็นข้อความล้วนด้วย Commitment ที่เข้ารหัส นั่นคือทำให้ผู้คนสามารถตรวจสอบความถูกต้องของธุรกรรมได้โดยไม่ต้องเปิดเผยมูลค่าธุรกรรม
สรุปประโยชน์สองประการของโฮโมมอร์ฟิซึ่มแบบเพิ่มโดยสังเขป หนึ่งคือ ไม่จำเป็นต้องถอดรหัสและสามารถตรวจสอบความถูกต้องของการทำธุรกรรมได้โดยไม่ต้องทราบจำนวนเงินในการทำธุรกรรม อีกอย่างคือ สามารถคำนวณโดยตรงกับค่าธรรมเนียมการทำธุรกรรมในธรรมดา ข้อความและนักขุดสามารถดูรายได้ของตนเองได้โดยตรง คือ และสามารถตรวจสอบได้ว่าสมการนี้ถูกต้อง
อีกประเด็นหนึ่งคือผู้ส่งธุรกรรมและผู้รับธุรกรรมไม่ทราบปัจจัยที่ทำให้ไม่เห็นของกันและกัน กล่าวคือ ผู้ป้อนข้อมูลของธุรกรรมไม่ทราบปัจจัยที่ทำให้ไม่เห็นของเอาต์พุต และเอาต์พุตของธุรกรรมไม่ทราบ ปัจจัยที่ทำให้ไม่เห็นของปัจจัยที่ทำให้ไม่เห็นผู้ป้อนข้อมูล แต่พวกเขารู้จำนวนธุรกรรม
ผลที่ได้คือจำนวนการทำธุรกรรมทั้งสองด้านของสมการสามารถหักล้างได้โดยการปรับสมดุล แต่ไม่สามารถหักล้างปัจจัยที่ทำให้ไม่เห็นได้ หากคุณลบผลลัพธ์ออกจากอินพุต คุณจะจบลงด้วยคำศัพท์หนึ่งคำ:
(ro-ri)*H
(ro คือผลรวมของปัจจัยที่ทำให้ไม่เห็นของเอาต์พุตของธุรกรรม ri คือผลรวมของปัจจัยที่ทำให้ไม่เห็นของอินพุตของธุรกรรม และ H คือตัวกำเนิด 2)
เราสามารถเรียกมันว่า "ส่วนที่เหลือ"
หมายเหตุ: ไม่ว่า (ro-ri)*H หรือ (ri-ro)*H จะเท่ากับเศษที่เหลือนั้นไม่สำคัญ ขึ้นอยู่กับตัวเลือกเฉพาะของโครงการ
ในการทำธุรกรรมที่เป็นความลับของ MimbleWimble เพื่อพิสูจน์ว่าธุรกรรมนี้ไม่ได้ถูกสร้างขึ้นตามอำเภอใจ (ผู้ส่งออกและนำเข้าธุรกรรมต่างก็รู้ปัจจัยที่ทำให้มองไม่เห็นของตนเอง และไม่ใช้ผลลัพธ์ของธุรกรรมของผู้อื่นเพื่อสร้างธุรกรรมของตนเอง) จำเป็นต้องมีวิธีในการ แก้ปัญหา.
บิตคอยน์ค่อนข้างง่าย ซึ่งก็คือการลงนามธุรกรรมทั้งหมดโดยตรงด้วยคีย์ส่วนตัวของคุณเอง เพื่อพิสูจน์ว่าคุณเข้าร่วมและสร้างธุรกรรม
แต่แนวทางของ MimbleWimble นั้นแปลกใหม่ - คุณต้องพิสูจน์ว่าคุณรู้ถึงความแตกต่างของปัจจัยที่ทำให้ไม่เห็น
(หมายเหตุ: ความแตกต่างของปัจจัยที่ทำให้ไม่เห็นที่นี่คือ "ผลรวมของการทำให้ไม่เห็นของเอาต์พุตธุรกรรม - ผลรวมของปัจจัยที่ทำให้ไม่เห็นของอินพุตของธุรกรรม" ซึ่งเป็นแนวคิดเดียวกันด้านล่าง)
เนื่องจากผู้นำเข้าและผู้ส่งออกรู้เฉพาะปัจจัยที่ทำให้มองไม่เห็นของตนเอง แต่ไม่ทราบปัจจัยที่ทำให้ไม่เห็นของอีกฝ่าย พวกเขาจำเป็นต้องมีข้อตกลงเพื่อพิสูจน์ร่วมกันว่าความแตกต่างระหว่างปัจจัยที่ทำให้ไม่เห็นสามารถคำนวณได้โดยการเพิ่มความรู้ของทั้งสองคนเข้าด้วยกัน สิ่งนี้เทียบเท่ากับการลงนามในธุรกรรมทั้งหมดโดยตรง ซึ่งสามารถพิสูจน์ได้ว่าฉันไม่ได้สร้างธุรกรรมตามอำเภอใจ
กล่าวอีกนัยหนึ่ง หากฉันสามารถพิสูจน์ได้ว่าฉันทราบความแตกต่างของปัจจัยที่ทำให้ไม่เห็น ฉันยังดำเนินการลงนามที่ได้รับอนุญาตของธุรกรรมให้เสร็จสมบูรณ์โดยไม่ต้องลงนามในธุรกรรมด้วยคีย์ส่วนตัวที่ป้อนเข้า
ใน MimbleWimble อันที่จริงแล้ว ความแตกต่างของปัจจัยที่ทำให้ไม่เห็นนั้นถูกใช้เพื่อลงนามสตริงคงที่ เช่น 0 เพื่อพิสูจน์ว่าฉันทราบความแตกต่างของปัจจัยที่ทำให้ไม่เห็น และจากนั้นฉันก็เผยแพร่รายการที่เหลือในเวลาเดียวกัน
แกนหลักของย่อหน้าข้างต้นคือความรู้เกี่ยวกับความแตกต่างของปัจจัยที่ทำให้ไม่เห็นสามารถแทนที่รหัสส่วนตัวในการทำธุรกรรมแบบดั้งเดิมของ Bitcoin
มีข้อเพิ่มเติมคือ เราต้องมี Range Proof
สำหรับส่วนของจำนวนเงิน คุณต้องพิสูจน์ว่าไม่มีจำนวนลบในส่วนของจำนวนเงิน เนื่องจากเราไม่ต้องการให้ใครสร้างธุรกรรมโดยที่อินพุตของธุรกรรมคือ 1 และเอาต์พุตของธุรกรรมคือ 2 และ -1 ซึ่งจะสร้าง เงินบางส่วนหายไปจากอากาศ
เพื่อพิสูจน์ว่าไม่มีตัวเลขติดลบในผลลัพธ์ทั้งหมดของธุรกรรมนี้ เอาต์พุตธุรกรรมแต่ละรายการจำเป็นต้องมีการพิสูจน์ช่วง (Range Proof) ซึ่งเป็นการพิสูจน์ความรู้เป็นศูนย์สั้นๆ เพื่อพิสูจน์ว่าผลลัพธ์ของธุรกรรมทั้งหมดน้อยกว่าเกณฑ์ที่กำหนดและเป็นทั้งหมด เชิงบวก.
เพื่อให้แนวคิดที่เข้าใจง่ายแก่คุณ ข้อความไซเฟอร์เท็กซ์ที่เข้ารหัสของเอาต์พุตธุรกรรมแต่ละรายการมีขนาดประมาณ 33 ไบต์ แต่ตอนนี้ Range Proof มีขนาดประมาณ 5 KB และนี่เป็นผลลัพธ์ที่ปรับให้เหมาะสมแล้ว เนื่องจาก Range Proof เทียบเท่ากับการพิสูจน์ที่ไม่มีความรู้ ทำให้สั้นลงได้ยาก
Gregory Maxwell สร้างเวอร์ชันแรกของConfidential Transactionเขาได้พัฒนา Range Proof ให้สมบูรณ์แบบ จากนั้น Benedikt Bünz นักศึกษาของมหาวิทยาลัย Stanford ได้เสนอ Range Proof รุ่นปรับปรุง ซึ่งสั้นกว่า Range Proof ดั้งเดิมของ Gregory และมีความเร็วในการตรวจสอบที่เร็วกว่า เรียกว่ารุ่นปรับปรุงของ Range ProofBulletproofsตีพิมพ์ในการประชุมอันดับ 1 ในด้านความปลอดภัยของข้อมูล Bulletproofs ทำให้ RangeProof มีขนาดเล็กลงมาก โดยมีขนาดประมาณ 700 ไบต์
Pieter Wuille และ Gregory Maxwell เป็นทั้งผู้เขียนบทความนี้ พวกเขาช่วย Benedikt ในการดำเนินการและทดสอบ Bulletproofs ให้เสร็จสมบูรณ์ ซึ่งหมายความว่าความก้าวหน้าในการเข้ารหัสล่าสุดจะถูกนำไปใช้โดยตรงกับโครงสร้างการทำธุรกรรมที่เป็นความลับของ MimbleWimble
มาดูส่วนแรกโดยย่อกันตอนนี้ MimbleWimble มีองค์ประกอบพื้นฐานสามส่วน ส่วนแรกคือ Confidential Transaction ซึ่งตระหนักถึงการเข้ารหัสของจำนวนเงินและใช้ความแตกต่างของปัจจัยที่ทำให้ไม่เห็นโดยตรงเพื่อลงนามคีย์ส่วนตัวเพื่อพิสูจน์ความรู้ของรายการที่เหลืออยู่ แทนที่แบบดั้งเดิม คีย์ส่วนตัวอินพุตจะใช้เพื่อเซ็นชื่อโดยตรง และยังมีการแนบ Range Proof กับธุรกรรมที่เป็นความลับด้วย
Coin Join
ตอนนี้เรามาเริ่มพูดคุยเกี่ยวกับ Coin Join ซึ่งเป็นองค์ประกอบที่สองของ MimbleWimble
แนวคิดของ Coin Join นั้นง่ายมาก เมื่อฉันมีธุรกรรม 2 รายการ ด้านซ้ายและขวาของสมการธุรกรรมแต่ละรายการสามารถสมดุลได้:การเพิ่มด้านซ้ายและขวาของสมการธุรกรรมทั้งสองเข้าด้วยกันยังคงเป็นธุรกรรมทางกฎหมาย. สมมติว่าธุรกรรมหนึ่งมีอินพุต 1 และเอาต์พุต 1 และอีกธุรกรรมหนึ่งมีอินพุต 2 และเอาต์พุต 2 เราสร้างธุรกรรมใหม่ซึ่งมีสองอินพุต อินพุต 1 และอินพุต 2 และสองเอาต์พุต เอาต์พุต 1 และเอาต์พุต 2 ซึ่งเป็นธุรกรรมทางกฎหมายเช่นกัน
Coin Join ได้รับการเสนอครั้งแรกโดย Gregory Maxwell ซึ่งเป็นวิธีแก้ปัญหาเพื่อความเป็นส่วนตัวที่ดีขึ้นในยุคแรก ๆ ของ Bitcoin
แต่เมื่อ Gregory Maxwell เสนอโปรโตคอล Coin Join ทุกคนต่างมีคำถามใหญ่ นั่นคือ มีวิธีเดียวในการปรับสมดุลสำหรับแต่ละอินพุตและแต่ละเอาต์พุตของธุรกรรม ตัวอย่างเช่น อินพุตของธุรกรรมคือ 8 BTC เอาต์พุตคือ 3 และ 5 และอินพุตของธุรกรรมอื่นคือ 20 BTC เอาต์พุตคือ 10 และ 10 เรานำอินพุตและเอาต์พุตของธุรกรรมทั้งสองนี้มารวมกัน ผู้คนสามารถ จะเห็นได้ว่าเอาต์พุตใดสอดคล้องกับอินพุตใดก่อน ดังนั้น Coin Join เองจึงไม่ได้ให้ความเป็นส่วนตัวมากนัก
แต่เมื่อใช้ร่วมกับ Confidential Transaction เพื่อเข้ารหัสอินพุตและเอาต์พุตของธุรกรรมทั้งหมด มันสามารถให้ความเป็นส่วนตัวได้ดีมาก
โปรโตคอล Coin Join นั้นง่ายมาก แต่จะมีปัญหาในการเชื่อมต่อโดยตรงกับ CT หากเราใช้วิธีลายเซ็นแบบดั้งเดิม , เรา เป็นไปได้ทั้งหมดที่จะกำหนดว่าอินพุตใดสอดคล้องกับเอาต์พุตใดตามที่อยู่ที่ใช้สำหรับลายเซ็น
ดังนั้น Coin Join และการทำธุรกรรมที่เป็นความลับจึงจำเป็นต้องเลือกวิธีลายเซ็นอื่น ซึ่งก็คือการใช้รายการที่เหลือโดยตรงเป็นคีย์สาธารณะ ใช้ความแตกต่างของปัจจัยที่ทำให้ไม่เห็นเป็นคีย์ส่วนตัว และใช้คู่คีย์สาธารณะและส่วนตัวนี้เพื่อ ลงชื่อ 0 วิธีนี้จะแก้ไขสถานการณ์ที่อินพุตและเอาต์พุตสามารถเชื่อมโยงโดยตรงผ่านลายเซ็นของการทำธุรกรรม
เป็นไปได้ที่ Zcash จะใช้สัญญาอัจฉริยะสำหรับการพิสูจน์ที่ไม่มีความรู้ในอนาคต แต่จะช้ามาก ในสถานการณ์เงินสด โดยส่วนตัวแล้วฉันคิดว่าการสนับสนุนของ Bitcoin สำหรับสัญญาอัจฉริยะนั้นเพียงพอแล้ว เนื่องจาก Bitcoin มีฟังก์ชันการตรวจสอบพื้นฐานบางอย่าง เราสามารถจัดเตรียมและรวมฟังก์ชันเหล่านี้เพื่อให้งานการตรวจสอบที่จำเป็นสำหรับสัญญาอัจฉริยะจำนวนมากในโลกแห่งความเป็นจริง
ความสามารถในการรองรับสัญญาอัจฉริยะของ Grin Coin ในขณะออกแบบนั้นแย่กว่า Bitcoin และ Zcash แต่สิ่งนี้ยังกระตุ้นให้นักวิจัยคิดเกี่ยวกับวิธีการใช้สัญญาอัจฉริยะในระบบที่ไม่มีตัวระบุที่อยู่และธุรกรรมจำนวนมากจะถูกลบ
มีปัญหาอื่นกับ Coin Join ฉันได้กล่าวไว้ก่อนหน้านี้ว่ามีการเซ็นชื่อ 0 หากเซ็นชื่อเป็น 0 จริงๆ คุณสามารถเพิ่มลายเซ็นทั้งสองเข้าด้วยกันโดยตรงเพื่อสร้างลายเซ็นทางกฎหมายใหม่ อย่างไรก็ตาม ในระหว่างการทำงานจริงของโปรโตคอล พบว่าการใช้ 0 เป็นลายเซ็นนั้นไม่ดี แต่ควรเซ็นฟิลด์ที่มีรูปแบบตายตัว
เนื่องจากวัตถุประสงค์ของลายเซ็นธุรกรรมแต่ละรายการแตกต่างกัน จึงเป็นไปไม่ได้ที่จะเพิ่มลายเซ็นเหล่านี้เข้าด้วยกันโดยตรง แล้วจะเป็นไปได้อย่างไรที่จะเชื่อมต่อธุรกรรมร่วมกับ Coin Join เพื่อสร้างธุรกรรมขนาดใหญ่โดยไม่กระทบต่อการตรวจสอบธุรกรรม หลังจากเชื่อมต่อกันแล้ว มีวิธีใดบ้างที่เราจะสร้างใหม่ว่าอินพุตธุรกรรมใดที่สอดคล้องกับเอาต์พุตธุรกรรมใด
One Way Aggregate Signatures
สิ่งนี้เกี่ยวข้องกับเทคโนโลยีที่สามของเขาที่เรียกว่า One Way Aggregate Signatures ลายเซ็นรวมทางเดียว
ลายเซ็นรวมรายการเดียวจะแยกความแตกต่าง x ของปัจจัยที่ทำให้ไม่เห็นออกเป็นสองรายการ x1 และ x2 โดยที่ x1*H เป็นพับลิกคีย์ แน่นอนว่า x1 นั้นไม่ใช่สาธารณะและจำเป็นต้องมีลายเซ็นเพื่อพิสูจน์ว่าฉัน รู้ x1 x2 เป็นสาธารณะโดยตรง พิสูจน์ว่าฉันรู้จัก x2 ด้วย x1*H + x2*H เท่ากับเศษที่เหลือก่อนหน้า
หลังจากแยกความแตกต่างระหว่างปัจจัยที่ทำให้ไม่เห็นออกเป็นสองรายการแล้ว x1*H เรียกว่า Kernel Excess, x2 เรียกว่า Kernel Offsets และ Kernel Offsets คือ offset
การแบ่งความแตกต่างของปัจจัยที่ทำให้ไม่เห็นออกเป็นสองส่วนมีประโยชน์อย่างไร
เมื่อธุรกรรมทั้งหมดในบล็อกก่อตัวเป็นธุรกรรม Coin Join ขนาดใหญ่ การชดเชยเคอร์เนลเหล่านั้นที่เปิดเผยเป็นข้อความธรรมดาสามารถเพิ่มเข้าด้วยกันได้โดยตรง ซึ่งจะเป็นการละทิ้งข้อมูลของธุรกรรมแต่ละรายการ
สำหรับส่วนที่ต้องมีการเซ็นชื่อ เนื่องจากส่วนที่เซ็นชื่อไม่ได้เซ็นเป็น 0 ทั้งหมด แต่สำหรับลายเซ็นฟิลด์คงที่ จะไม่สามารถรวมเข้าด้วยกันได้ และลายเซ็นเหล่านี้จำเป็นต้องจัดเก็บแยกกัน กล่าวคือ Kernel Offsets ทั้งหมดจะถูกรวมเข้าด้วยกัน และ Kernel Offset เพียงอันเดียวจะถูกจัดเก็บไว้ในบล็อก แต่ Kernel Excess ยังคงถูกจัดเก็บแยกจากกัน ส่วนเกินของเคอร์เนลและลายเซ็นของฟิลด์คงที่โดยใช้ x1 จะถูกจัดเก็บไว้ในเคอร์เนลของแต่ละธุรกรรม
ข้อดีของสิ่งนี้คือเมื่อคุณได้รับบล็อกธุรกรรม Coin Join ขนาดใหญ่ คุณสามารถรวมรายการการรวมของ Kernel Offsets และลายเซ็นทั้งหมดอีกครั้งเพื่อตรวจสอบว่าธุรกรรมทั้งหมดในบล็อกนี้ถูกต้อง และเนื่องจาก Kernel Offsets ถูกรวมเข้าด้วยกัน จึงไม่มีทางที่จะแยกส่วน Offsets ที่เพิ่มเข้ามาได้ เราไม่มีทางรู้ว่าอินพุตและเอาต์พุตแต่ละลายเซ็นสอดคล้องกัน ดังนั้นจึงมีการใช้ One Way Aggregate Signatures
ให้ฉันอธิบายอีกครั้ง ฟังก์ชันพื้นฐานของ One Way Aggregate Signatures คือเมื่อคุณได้รับอินพุตและเอาต์พุตของธุรกรรมจำนวนมากในบล็อก คุณจะไม่มีทางตัดสินได้ว่าอินพุตและเอาต์พุตของธุรกรรมใดที่เดิมทีเป็นธุรกรรม วิธีการของมันคือการแบ่งความแตกต่างของปัจจัยที่มองไม่เห็นของธุรกรรมแต่ละรายการออกเป็นสองส่วน ส่วนหนึ่งคือการพิสูจน์ว่าฉันรู้ด้วยลายเซ็น และอีกส่วนหนึ่งคือการเผยแพร่ข้อความธรรมดาโดยตรงเพื่อพิสูจน์ว่าฉันรู้ สำหรับรายการที่เผยแพร่ข้อความธรรมดาโดยตรง สำหรับธุรกรรมทั้งหมด สามารถเพิ่มเข้าด้วยกันได้โดยตรง
ที่นี่ฉันจะเพิ่มแนวคิดของการตัดผ่าน
เนื่องจากผลลัพธ์ของธุรกรรมทั้งหมดที่ใช้ไปจะปรากฏทางด้านซ้ายของสมการในบล็อกและอีกครั้งทางด้านขวา เราจึงสามารถขีดฆ่าคำศัพท์ที่อยู่ทั้งสองด้านของสมการได้ แนวคิดของ Cut Through คือ สามารถลบทรานแซคชันเอาท์พุตที่ใช้ไปแล้วในบล็อกได้ เมื่อมีหลาย ๆ บล็อค เราสามารถลบทรานแซกชันอินพุทและเอาท์พุตของทรานแซกชันต่าง ๆ ข้ามบล็อคได้ เพื่อให้เกิดการบีบอัดตามวัตถุประสงค์ของการจัดเก็บฮาร์ดดิสก์ ช่องว่าง.
อย่างไรก็ตาม Mimblewimble จะมีหลายจุดที่ยากต่อการรวม หนึ่งคือ Range Proof ของเอาต์พุตธุรกรรมทั้งหมด เมื่อเวลาผ่านไป จะมี UTXO มากขึ้นในระบบ Mimblewimble และแต่ละเอาต์พุตของธุรกรรมจะมี Range Proof ของตัวเอง พิสูจน์ เพื่อพิสูจน์ว่าผลลัพธ์ของฉันไม่เป็นลบ
(หมายเหตุ: UTXO ไม่ได้เพิ่มขึ้นแบบจำเจเมื่อเวลาผ่านไป สิ่งที่แสดงในที่นี้คือเมื่อเวลาผ่านไป จำนวนผู้ใช้เพิ่มขึ้นและ UTXO เพิ่มขึ้น)
เมื่อคุณต้องการตรวจสอบความถูกต้องของ UTXO คุณต้องคำนวณ Range Proofs เหล่านี้ตั้งแต่ต้นจนจบ ซึ่งเทียบเท่ากับเวลาและพื้นที่จัดเก็บที่มากขึ้นสำหรับการตรวจสอบความถูกต้องของเอาต์พุตธุรกรรมเดียวมากกว่า Bitcoin
ดังนั้นปัญหาคอขวดของการคำนวณ Mimblewimble และพื้นที่จัดเก็บคือ Range Proof นอกจากนี้ หลังจากแยกปัจจัยที่ทำให้ไม่เห็นออกเป็นสองรายการแล้ว ธุรกรรมใหม่แต่ละรายการจะมีลายเซ็นของตัวเอง และรายการที่ไม่สามารถสรุปรวมได้นี้จะไม่สามารถบีบอัดได้
เมื่อคุณสำรวจบล็อกเชนทั้งหมด มันจะส่งผลต่อเวลาการตรวจสอบด้วย และสองรายการด้านบนคือสองรายการที่ส่งผลต่อการปรับขนาดมากที่สุด
การนำ MimbleWimble - Grin ไปใช้อย่างเป็นรูปธรรม
ต่อไป เรามาพูดถึงการใช้งานเฉพาะของ MimbleWimble—Grin ซึ่งมีอัลกอริธึมการขุดที่เรียกว่า Cuckoo Cycle
พูดง่ายๆ ก็คือ Cuckoo Cycle เป็นตารางแฮชสองตารางที่ยาวมาก แต่ละตารางมีหลายโหนด และเธรดจำนวนมากเชื่อมต่อระหว่างตารางแฮชทั้งสองในลักษณะสุ่มหลอก
ตารางแฮช 1 สามารถเชื่อมต่อกับตารางแฮช 2 เท่านั้น และตารางแฮช 2 สามารถเชื่อมต่อกับตารางแฮช 1 เท่านั้น ส่วนประกอบของตาราง 1 ไม่สามารถเชื่อมต่อได้ และส่วนประกอบของตาราง 2 ไม่สามารถเชื่อมต่อได้
ตัวปริศนาคือการค้นหาวงกลมที่มีความยาวเท่ากับ 42 นั่นคือ โหนด A ในตารางที่ 1 เชื่อมต่อกับโหนด B ในตารางที่ 2 โหนด B ในตารางที่ 2 เชื่อมต่อกับโหนด C ในตารางที่ 1 เป็นต้น เพื่อค้นหา วงกลมที่มีความยาว 42
จุดประสงค์ดั้งเดิมของการออกแบบนี้คือเพื่อให้ Puzzle ครอบครองพื้นที่หน่วยความจำให้ได้มากที่สุดก่อนที่จะเริ่มแก้ไข
เพราะถ้าคุณต้องการทราบว่าจุดใดในตารางที่ 1 เชื่อมต่อกับโหนดในตารางที่ 2 วิธีที่ดีที่สุดคือนับขอบทั้งหมดก่อน บันทึกไว้ในโครงสร้างข้อมูลหนึ่งๆ แล้วจึงค้นหาในโครงสร้างข้อมูลนี้ เพื่อให้มัน สามารถตรวจสอบให้แน่ใจว่าจำเป็นต้องเปิดพื้นที่หน่วยความจำขนาดใหญ่ก่อนที่จะทำการค้นหา เพื่อหลีกเลี่ยงการคำนวณ Puzzle ที่เกี่ยวข้องกับการใช้ CPU เท่านั้น และความตั้งใจเดิมของพื้นที่หน่วยความจำขนาดใหญ่ยังทำให้เกิดปัญหาบางอย่างสำหรับ ASIC
แต่ด้วยการพัฒนาของเวลา ทุกคนตระหนักว่า ASIC ยังคงมีอยู่ ดังนั้นการปรับปรุงบางอย่างจึงทำขึ้นโดยใช้อัลกอริทึมที่ดีที่สุดในการแก้ปัญหานี้ในขณะนั้น เพื่อให้สามารถนับปริศนาด้วย ASIC ได้ จะเลือกโปรโตคอลที่ไม่เป็นมิตรกับ ASIC ในระยะเริ่มต้นของโปรโตคอล แต่หลังจากผ่านไปสองปีจะถูกแทนที่ด้วยโปรโตคอลรุ่นปรับปรุงซึ่งสะดวกมากสำหรับ ASIC
นี่เป็นอีกประเด็นหนึ่งในฐานะนักเรียนของนักเข้ารหัส (ฉันไม่ใช่นักเข้ารหัส แต่เจ้านายของฉันเป็น) สิ่งที่น่าตกใจที่สุดเกี่ยวกับ Cuckoo Cycle คือในช่วงเริ่มต้นของการออกแบบ มันมีเพียงสัญชาตญาณเท่านั้น และไม่มีคณิตศาสตร์ การพิสูจน์ซึ่งอัลกอริทึมต้องเร็วที่สุด อัลกอริธึมสำหรับการแก้ปัญหา Cuckoo Cycle เหล่านี้ล้วนถูกกล่าวถึงเมื่อ Cuckoo Cycle มีชื่อเสียงอยู่แล้ว
ดังนั้นเมื่อไม่มีข้อพิสูจน์ทางคณิตศาสตร์ เป็นไปได้ว่าจู่ๆ บุคคลหนึ่งก็คิดค้นอัลกอริธึมที่รวดเร็วเป็นพิเศษเพื่อแก้ปัญหา Cuckoo Cycle เพื่อให้ Grin Coins ทั้งหมดถูกขุดโดยเขาคนเดียว นี่เป็นปัญหาสำหรับกรินในขณะนี้เช่นกัน
นี่เป็นบทเรียนสำหรับฉันด้วย ในปี 2013 ฉันใช้เวลาหนึ่งปีเพื่อพยายามออกแบบอัลกอริทึม PoW ของตัวเอง ซึ่งใกล้เคียงกับ Cuckoo Cycle มาก แต่สิ่งที่ทำให้ฉันทรมานในตอนนั้นคือฉันไม่สามารถหาข้อพิสูจน์ทางคณิตศาสตร์ได้ว่าอัลกอริทึมบางอย่างจะต้องแก้ปริศนา มันคือ เร็วที่สุด ฉันจึงไม่เคยโพสต์บทความล่าสุด เมื่อคิดถึงตอนนี้ ฉันรู้สึกเสียใจมาก เพราะความคิดที่ยังไม่บรรลุนิติภาวะประเภทนี้สามารถถูกโยนออกไปให้ทุกคนได้พูดคุย อาจมีแนวคิดดีๆ บางอย่างที่สามารถพูดคุยกันได้ และไม่ใช่ว่าทุกอย่างจะต้องพิสูจน์ด้วยคณิตศาสตร์
ดังนั้นเมื่อฉันได้ยินเกี่ยวกับการออกแบบของ Cuckoo Cycle เมื่อนานมาแล้ว ฉันรู้สึกเต็มไปด้วยอารมณ์
ถึงตอนนี้ รายละเอียดเกี่ยวกับ MimbleWimble ได้รับการกล่าวถึงแล้ว
Pick Time
ในช่วงสุดท้ายของการแบ่งปัน ผมอยากเล่าประสบการณ์การเรียนปริญญาเอกที่เบลเยี่ยมให้ฟัง โดยหวังว่าจะเป็นแรงบันดาลใจให้น้องๆ ที่สนใจด้านวิชาการ
การอ่านที่แนะนำ:
การอ่านที่แนะนำ:
บทความการวิเคราะห์ฉันทามติด้านความปลอดภัยของ Zhang Ren"การพัฒนาเกณฑ์ทั่วไป: การประเมินความปลอดภัยของโปรโตคอลที่สอดคล้องกันของ PoW"
Zhang Ren วิเคราะห์บทความโปรโตคอลฉันทามติจากมุมมองของการใช้แบนด์วิธ"Nervos CKB Consensus Protocol NC-Max: ทะลุขีดจำกัดของปริมาณงานฉันทามติของ Nakamoto"
