ผู้แต่ง | Vitalik Buterin

ผู้แต่ง | Vitalik Buterin

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

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

เพื่อวิเคราะห์ blockchain ฉันพยายามแยกความน่าเชื่อถือออกเป็นมิติต่อไปนี้:

• คุณต้องประพฤติตัวตามความคาดหวังของคุณกี่คน?

• จำนวนคนทั้งหมดเท่าไหร่?

• คนเราต้องการแรงจูงใจอะไร? พวกเขาจำเป็นต้องเป็นผู้เห็นแก่ผู้อื่นหรือเป็นทหารรับจ้างหรือไม่? พวกเขาจำเป็นต้องหลีกเลี่ยงการทำงานร่วมกันหรือไม่?

• ระบบจะได้รับผลกระทบมากเพียงใดหากสมมติฐานเหล่านี้ถูกละเมิด?

สำหรับตอนนี้ เรามาเน้นที่จุดสองจุดแรกกัน และนี่คือไดอะแกรม:

ยิ่งสีเขียวเข้มขึ้นเท่าใด โมเดลก็จะยิ่งมีสุขภาพดีเท่านั้น มาวิเคราะห์รายละเอียดหมวดหมู่เหล่านี้กัน:

• 1 จาก 1: มีผู้เข้าร่วมเพียงคนเดียวในระบบทั้งหมด หากนักแสดงคนนี้ประพฤติตัวตามที่คุณคาดหวัง ระบบจะ (จะ) ทำงานอย่างถูกต้อง นี่คือโมเดล "การรวมศูนย์อำนาจ" แบบดั้งเดิม และยังเป็นโมเดลที่เราต้องการจะก้าวข้าม

• N จาก N: โลก "dystopian" ผู้เข้าร่วมทั้งหมดในระบบต้องประพฤติตนตามที่คาดไว้เพื่อให้ระบบทำงานได้อย่างถูกต้อง และเราไม่มีทางแก้ไขหากมีสิ่งใดที่ล้มเหลว

• N/2 จาก N: นี่คือวิธีการทำงานของบล็อกเชน หากผู้ขุดส่วนใหญ่ (หรือผู้ตรวจสอบความถูกต้องของ PoS) มีความซื่อสัตย์ บล็อกเชนจะทำงานได้อย่างถูกต้อง โปรดทราบว่ายิ่งค่าของ N มากเท่าใด N/2 ก็จะยิ่งมีค่ามากขึ้นเท่านั้น เครือข่ายของผู้ขุด/ผู้ตรวจสอบความถูกต้องที่กระจายอยู่ทั่วไปนั้นเหมาะสมกว่าบล็อกเชนที่ควบคุมโดยผู้ขุดเหมือง/ผู้ตรวจสอบจำนวนเล็กน้อย ถึงกระนั้น เราต้องการก้าวไปอีกขั้นด้วยระดับความปลอดภัยนี้ เนื่องจากมีความเป็นไปได้ที่จะถูกโจมตีถึง 51%

• 1 จาก N: มีนักแสดงหลายคนและตราบใดที่มีอย่างน้อยหนึ่งคนทำงานตามที่คาดไว้ ระบบจะทำงานได้อย่างถูกต้อง ระบบใด ๆ ที่ใช้หลักฐานการฉ้อโกงจัดอยู่ในหมวดหมู่นี้ เช่นเดียวกับการตั้งค่าความน่าเชื่อถือ แม้ว่าค่าของ N มักจะน้อยในกรณีนี้ โปรดทราบว่าเราต้องการให้ค่าของ N มากที่สุดเท่าที่จะเป็นไปได้!

• ไม่กี่ N: ตราบเท่าที่นักแสดงจำนวนน้อยและคงที่ทำงานตามที่คาดไว้ ระบบจะทำงานได้อย่างถูกต้อง การตรวจสอบความพร้อมใช้งานของข้อมูลเป็นหนึ่งในนั้น

• 0 จาก N: ระบบไม่จำเป็นต้องพึ่งพาตัวแสดงภายนอกเพื่อให้ทำงานได้อย่างถูกต้อง การตรวจสอบการบล็อกด้วยตัวคุณเองจัดอยู่ในหมวดหมู่นี้

แม้ว่ารุ่นอื่นที่ไม่ใช่ "0 จาก N" จะมีระดับ "ความน่าเชื่อถือ" อยู่บ้าง แต่ก็มีความแตกต่างกันมากระหว่างรุ่นเหล่านี้! การไว้วางใจว่าบุคคลใดบุคคลหนึ่ง (หรือองค์กร) จะประพฤติตนตามที่คาดไว้นั้นเป็นสถานการณ์ที่แตกต่างอย่างสิ้นเชิงกับการไว้วางใจว่าบุคคลใด ๆ จะประพฤติตนตามที่คาดไว้ "1 of N" คล้ายกับ "0 of N" มากกว่า "N/2 of N" ถึง "1 of 1" บางคนอาจคิดว่าโมเดล "1 ใน N" นั้นคล้ายกับโมเดล "1 ใน 1" เนื่องจากทั้งสองโมเดลพึ่งพาผู้เล่นคนเดียว แต่ในความเป็นจริงแล้ว ทั้งสองแบบแตกต่างกันมาก: ในระบบ "1 ใน N" ถ้า ผู้เข้าร่วมหายไปหรือดำคล้ำในทันที สามารถเปลี่ยนผู้เข้าร่วมรายอื่นได้ แต่ในระบบ "1 ต่อ 1" เราไม่มีทางเลือกอื่น

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

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

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

• รูปแบบ "ช่องทาง" (ช่องทางต่างๆ รวมถึงช่องทางของรัฐ เครือข่าย Lightning ฯลฯ): ใช้แบบจำลองความน่าเชื่อถือ "1 ต่อ 1" เพื่อให้มั่นใจถึงการใช้งานจริง (คู่สัญญาของคุณสามารถระงับเงินของคุณชั่วคราว แต่คุณสามารถกระจายเงินในหลายช่องทาง) การลดความเสี่ยง ใน ) โดยใช้โมเดล "N/2 ของ big N" เพื่อความปลอดภัย (ความเป็นไปได้ของการสูญเสียเงินทุนในการโจมตี 51%)

• Plasma (ตัวดำเนินการแบบรวมศูนย์): ใช้โมเดลความน่าเชื่อถือ "1 ใน 1" เพื่อให้แน่ใจว่ามีการใช้งานจริง (ตัวดำเนินการสามารถหยุดเงินของคุณชั่วคราว), โมเดล "N/2 ของ big N" เพื่อความปลอดภัย (เป็นไปได้ในการโจมตี 51% สูญเสียเงินทุนในกระบวนการ ).

• Plasma (ตัวดำเนินการแบบกึ่งกระจายศูนย์ เช่น DPOS): ใช้แบบจำลองความน่าเชื่อถือ "N/2 ของ N ขนาดเล็ก" เพื่อรับประกันความมีชีวิต และแบบจำลอง "N/2 ของ N ขนาดใหญ่" เพื่อรับประกันความปลอดภัย

• การยกเลิกในแง่ดี: ใช้โมเดลความน่าเชื่อถือ "1 จาก 1" หรือ "N/2 ของ N ขนาดเล็ก" เพื่อความมีชีวิตชีวา (ขึ้นอยู่กับประเภทของผู้ให้บริการ) และโมเดล "N/2 ของ N ขนาดใหญ่" เพื่อความปลอดภัย

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

• การยกเลิก ZK (ปรับปรุงการถอนเล็กน้อย): ไม่มีความเสี่ยงความล้มเหลวที่ใช้งานอยู่และความเสี่ยงความล้มเหลวด้านความปลอดภัย

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

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

บทสรุป: ถ้ามีคนบอกว่าระบบ "อาศัยกลไกความเชื่อใจ" เราก็สามารถหาสาเหตุได้! พวกเขาหมายถึงโมเดล "1 ใน 1" โมเดล "1 ใน N" หรือโมเดล "N/2 ของ N" หรือไม่ ระบบต้องการให้ผู้เข้าร่วมเห็นแก่ผู้อื่นหรือมีเหตุผลหรือไม่? หากเป็นความเห็นแก่ประโยชน์ผู้อื่น ผู้เข้าร่วมมีค่าใช้จ่ายเท่าไร? ฉันต้องรอนานเท่าใดจึงจะได้รับเงินคืนหากสมมติฐานถูกละเมิด? สองสามชั่วโมง? กี่วัน? หรือถูกแช่แข็งตลอดไป? เมื่อทราบคำถามเหล่านี้ เราอาจมีคำตอบที่แตกต่างกันมากว่าจะนำระบบนี้ไปใช้หรือไม่