คำพูดล่าสุดของ Vitalik: การโจมตี 51% ที่ทับซ้อนกันกลายเป็นภัยคุกคามร้ายแรงต่อ PoW blockchain, PoS คือทางออกเ

หมายเหตุบรรณาธิการ: บทความนี้มาจาก Babbitt แปลโดย Free and Easy ประพันธ์โดย Vitalik Buterin (V God) ทำซ้ำโดย Odaily โดยได้รับอนุญาต

ตั้งแต่วันที่ 20 ถึง 22 กุมภาพันธ์ ตามเวลาปักกิ่ง การประชุม Stanford Blockchain ปี 2020 ซึ่งจัดโดย Findora จัดขึ้นที่ Stanford University การประชุมนี้มุ่งเน้นไปที่วิศวกรรมความปลอดภัยและวิธีการจัดการความเสี่ยงในระบบ blockchain และหารือเกี่ยวกับการประยุกต์ใช้เทคโนโลยีการเข้ารหัส โปรโตคอลแบบกระจายศูนย์ เป็นทางการ วิธีการและการวิเคราะห์เชิงประจักษ์ ฯลฯ เพื่อปรับปรุงความปลอดภัยของระบบบล็อกเชน

คำอธิบายภาพ

(รูปภาพ: Vitalik กล่าวสุนทรพจน์ในการประชุม Stanford Blockchain Conference 2020)

ต่อไปนี้เป็นเนื้อหาของสุนทรพจน์ของ Vitalik:

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

นี่คือประเภทหลักของการโจมตี 51% ที่เราพูดคุยกันมาตลอด 10 ปีที่ผ่านมา และเป็นแบบที่เราพิจารณามากที่สุด

1. การโจมตีประเภทอื่นๆ 51%

1.1 การโจมตีการตรวจสอบธุรกรรม อันที่จริง การตรวจสอบธุรกรรมเป็นการโจมตีอีก 51%! เนื่องจากโปรโตคอลเลเยอร์ 2 และ DeFi เป็นทั้งเมกะเทรนด์ล่าสุด การเซ็นเซอร์การทำธุรกรรมจึงเป็นอันตรายอย่างยิ่ง ในสภาพแวดล้อมของโปรโตคอลเลเยอร์ 2 จำนวนมาก (รวมถึงพลาสมา, ช่องสัญญาณ, ช่องสถานะทั่วไป, เครือข่ายฟ้าผ่า, Optimistic Rollup, คอมพิวเตอร์เชิงโต้ตอบ, TruBit เป็นต้น) การตรวจสอบหมายถึงการขโมย!

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

หากคุณสามารถตรวจสอบธุรกรรมบล็อคเชนของ ethereum ทุกรายการที่แตะ Uniswap จากนั้นรอหนึ่งวัน ราคาของ ether อาจผันผวนเล็กน้อย และฉันจะสามารถดึงมูลค่าการเก็งกำไรจำนวนมากจากการโจมตีนี้ได้

อาจกล่าวได้ว่าการเซ็นเซอร์เป็นสิ่งที่อันตราย และในโปรโตคอล DeFi และโปรโตคอลเลเยอร์ 2 การเซ็นเซอร์ธุรกรรมยังถือได้ว่าเทียบเท่ากับการโจรกรรม

1,2 การโจมตีไคลเอ็นต์แบบเบา ผู้คนจำนวนมากกำลังเรียกใช้ไคลเอ็นต์แบบเบา และหากคุณใช้งานไคลเอนต์แบบเบา การโจมตี 51% อาจทำให้ไคลเอ็นต์แบบเบายอมรับเชนที่มีการบล็อกธุรกรรมที่ไม่ถูกต้องโดยสิ้นเชิง ลายเซ็นปลอม ธุรกรรมที่ผิดรูปแบบ ลายเซ็นที่ไม่ได้รับอนุญาต (ขโมยเงินจากบัญชีหนึ่งและโอนไปยังบัญชีอื่น) พวกเขาสามารถบล็อกการใช้งานที่ยอมรับโดยเครือข่าย 1.3 การโจมตีความไม่พร้อมใช้งานของข้อมูล ใครคุ้นเคยกับปัญหาความพร้อมใช้งานของข้อมูลบ้าง ไม่ใช่ทุกคน แต่หลายคนได้รับมัน แนวคิดที่นี่คือคุณสามารถสร้างห่วงโซ่ที่คุณเผยแพร่ส่วนหัวของบล็อก ไคลเอนต์แบบไลท์สามารถเห็นเชน แต่ไม่สามารถเผยแพร่ข้อมูลบางส่วนหรือทั้งหมดในตัวบล็อกได้ สิ่งนี้ไม่ดีเพราะหากข้อมูลไม่ได้รับการเผยแพร่ ข้อมูลนั้นอาจเป็นจริงหรือไม่จริงก็ได้ และไม่มีทางสร้างข้อพิสูจน์ให้คนอื่นเห็นว่าอาจเป็นจริงได้ และคุณปฏิเสธผู้ที่อาจต้องการสร้างข้อมูลธุรกรรมในอนาคต ที่กล่าวว่าบล็อกที่ใช้ไม่ได้ก็เป็นอันตรายเช่นกัน 1, 4 การโจมตีด้วยความท้อแท้ การโจมตีด้วยความท้อแท้ การโจมตีด้วยความท้อแท้เป็นคำที่หมายถึงการก่อกวนผู้อื่นอย่างมุ่งร้าย ทำให้พวกเขาสูญเสียรายได้ และผลักดันให้พวกเขาสมรู้ร่วมคิดกับคุณ หรือถูกบังคับให้เลิก การขุดแบบเห็นแก่ตัวโดยใช้กำลังประมวลผลมากกว่า 1/3 เป็นตัวอย่างของการทำเช่นนี้ ที่กล่าวว่า การโจมตี 51% ก็เป็นการโจมตีเพื่อห้ามปรามที่ทรงพลังเช่นกัน 1.5 เกี่ยวกับการดัดแปลง blockchain ที่ไม่สามารถแก้ไขได้ การโจมตี 51% นั้นทรงพลังมากและการโจมตีประเภทนี้เป็นภัยคุกคามต่อการดัดแปลง blockchain ที่ไม่สามารถแก้ไขได้

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

นอกจากนี้ การโจมตี 51% นั้นไม่ใช่ประชาธิปไตย พวกเขาเป็นกลุ่มที่มีอุดมการณ์ ดังนั้นในฐานะวิธีการทางประชาธิปไตย จึงไม่ส่งผลดีต่อพวกเขา

2. การโจมตีที่เกิดขึ้นจริง 51% และสถานการณ์การโจมตีที่เลวร้ายที่สุด 51%

ในความเป็นจริงสามารถโจมตีได้ 51% นี่คือภาพถ่ายจากการประชุม Hong Kong Bitcoin Scaling Conference ปี 2015 ในภาพนี้ บางคนที่ควบคุม 90% ของพลังการประมวลผลของ Bitcoin กำลังนั่งอยู่ด้วยกัน ทำท่า "ฉันมีพลัง" ฮ่าๆ

สามารถทำการโจมตีได้ 51% ตัวอย่างเช่น ETC, Bitcoin Gold และอื่น ๆ พบการโจมตีทั้งหมด 51% ฉันแน่ใจว่าฉันพลาดการโจมตี 1-2 ครั้ง การโจมตีเหล่านี้เกิดขึ้นแล้ว

การโจมตีค่ายวางไข่เป็นการโจมตี 51% ที่เราเคยเห็นมา ไม่ใช่ครั้งเลวร้ายที่สุด การโจมตีค่ายวางไข่เป็นสถานการณ์ฝันร้ายที่เลวร้ายที่สุดสำหรับการโจมตีประเภทนี้ โดยพื้นฐานแล้ว คุณต้องมีฮาร์ดแวร์ให้เพียงพอเพื่อโจมตีเชน รอให้กู้คืน จากนั้นจึงโจมตีอีกครั้ง เนื่องจากคุณยังมีฮาร์ดแวร์อยู่ ในท้ายที่สุด ชุมชนจะต้องทนกับความทรมานนี้มามากพอแล้ว และพวกเขาจะเข้ามาแทนที่อัลกอริทึม Proof-of-Work (PoW) เนื่องจากพวกเขาไม่มีทางสร้าง ASIC ได้ในระยะเวลาอันสั้น ดังนั้นคุณเพียงแค่ต้อง เช่าพลังประมวลผล CPU และ GPU จำนวนมากเพื่อดำเนินการโจมตีต่อไป จากนั้น Chain ก็จะตาย เว้นแต่พวกเขาจะเปลี่ยนไปใช้ Proof of Stake (PoS) หรือกลายเป็นสิ่งที่รวมศูนย์อย่างสมบูรณ์

3. อัลกอริทึม Proof-of-stake (PoS) สามารถทำลายวงจรนี้ได้หรือไม่?

นี่คือบล็อกโพสต์ที่ฉันเขียนในปี 2559 ซึ่งฉันพยายามอธิบายปรัชญาเบื้องหลังว่า Proof of Stake (PoS) คืออะไร และเหตุใดจึงเป็นสิ่งที่เราควรคาดหวังว่าจะมีอยู่ และเหตุใดจึงเป็นสิ่งที่มีความหมาย มีความไม่สมดุลใน Proof of Stake (PoS) ซึ่งแตกต่างจาก Proof of Work (PoW) ซึ่งคุณมีเพียงรางวัล ดังนั้นคุณจึงถูกลงโทษสำหรับการเข้าร่วมในการโจมตีหรือไม่เข้าร่วมในการโจมตี เฉพาะส่วนรางวัลบล็อก . ในระบบ Proof-of-stake (PoS) สามารถตรวจจับการโจมตีของคุณได้ และเงินฝากที่คุณเสียไปจะมากกว่าเงินประกันที่คุณอาจถูกปรับ

พวกเขาใส่ไว้ใน Casper CBC และอัลกอริธึมการพิสูจน์สถานะการเดิมพัน (PoS) ที่ใช้เครื่องหมายสแลช ตามทฤษฎีแล้ว เป้าหมายของการออกแบบนี้คือทำให้การโจมตี 51% มีราคาแพงมาก โดยทั่วไป คุณต้องการโจมตีเครือข่าย PoS คุณต้องซื้อเหรียญจำนวนมาก คุณต้องควบคุมเหรียญในระบบมากกว่า 50% และจากนั้นเมื่อคุณถูกจับได้ว่าพยายามโจมตี คุณจะถูกปรับ ถ้า คุณต้องการทำมันอีกครั้ง เพื่อเริ่มการโจมตี คุณต้องซื้อเหรียญเพิ่ม เพราะคุณซื้อต่อไป ราคาเหรียญที่เพิ่มขึ้นจะทำให้คุณล้มละลายในที่สุด ดังนั้นจากมุมมองนี้ แทนที่จะให้ผู้โจมตีมุ่งเป้าที่ PoW เรา เป้าหมายคือทำให้ The chain ย้ายไปยัง PoS

แล้วการโจมตีประเภทอื่นล่ะ? ตอนนี้เรามาพูดถึงคำถามแรกกัน PoS แก้ปัญหาการโจมตีประเภทอื่นๆ ได้อย่างไร จนถึงตอนนี้ เรามุ่งเน้นไปที่การพลิกกลับของจุดสิ้นสุด นี่เป็นเรื่องธรรมดาในทฤษฎีฉันทามติที่ทนต่อความผิดพลาดของไบแซนไทน์ แนวคิดพื้นฐานคือหาก 2/3 ของฝ่ายอยู่ฝ่ายหนึ่งและอีก 1/3 อยู่อีกด้านหนึ่ง... 1/3 ของผู้ตรวจสอบความถูกต้องต้องส่งข้อความที่ขัดแย้งกันสองฉบับ คุณสามารถตรวจจับและลงโทษพวกเขาได้ ถึงกระนั้นก็เกี่ยวกับการโจมตีในทางกลับกัน

แล้วการโจมตีประเภทอื่นล่ะ? ข้อมูลไม่ถูกต้อง ข้อมูลไม่พร้อมใช้งาน การเซ็นเซอร์ การก่อกวน?

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

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

เราสามารถสรุปได้สองสิ่ง: การโจมตีความพร้อมใช้งานของข้อมูลและการโจมตีการเซ็นเซอร์

กระดาษกระดาษซึ่งฉันอธิบายโครงร่างที่ช่วยให้ไคลเอ็นต์บล็อกเชนตรวจสอบความพร้อมใช้งานของข้อมูลบล็อกเชนโดยพื้นฐานแล้วโดยไม่ต้องดาวน์โหลดข้อมูลทั้งหมด

รูปแบบของมนุษย์ฟางที่เรียบง่ายคือ: วิธีที่โง่ที่สุดในการตรวจสอบว่ามีบล็อกหรือไม่คือดาวน์โหลดสิ่งทั้งหมด แต่ที่นี่เราสมมติว่าเป็นบล็อกเชนที่ปรับขนาดได้และอาจเป็นบล็อกเชนที่มีการอัปโหลดข้อมูลมากกว่า 2 MB/วินาทีไปยังเชน และลูกค้าจะไม่สามารถดาวน์โหลดทุกอย่างได้ สำหรับลูกค้าที่ต้องการตรวจสอบความพร้อมใช้งานของข้อมูล สิ่งที่เราต้องทำคือทดสอบตัวอย่างแบบสุ่ม มันจะสุ่มเลือกชิ้นส่วนข้อมูลบางส่วน เช่น 30 ชิ้นส่วน 40 ชิ้นส่วน 80 ชิ้นส่วน... มันจะสุ่มเลือกตำแหน่งและขอหลักฐาน Merkle สำหรับตำแหน่งเหล่านี้ ตราบใดที่คุณได้รับการตอบกลับที่ถูกต้องจากตำแหน่งทั้งหมดที่คุณยอมรับ จากนั้น จากนั้นคุณยอมรับการบล็อกว่าถูกต้อง

หากคุณยอมรับการบล็อกโดยใช้รูปแบบนี้ คุณก็น่าจะรู้ว่าการบล็อกนั้นถูกต้อง หากมีข้อมูลน้อยกว่า 50% เช่น ข้อมูลทั้งหมดทางด้านซ้ายมีอยู่ ที่นี่ข้อมูลทั้งหมดทางด้านขวามีอยู่ การตรวจสอบอย่างน้อยหนึ่งรายการมักจะล้มเหลว

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

สิ่งนี้ไม่ได้พิสูจน์ว่าบล็อกนั้นพร้อมใช้งานอย่างสมบูรณ์ แต่อาจขาดหายไปบางส่วน แต่พิสูจน์ได้ว่ามีบล็อกอย่างน้อยครึ่งหนึ่ง คงจะดีไม่น้อยหากเรามีเทคนิคบางอย่างในการกู้คืนบล็อกข้อมูลทั้งหมดจากข้อมูล 50%

Erasure coding นี่คือที่มาของ Erasure coding ดังนั้นเราจะนำข้อมูลมา สมมติว่าเป็นการประเมินพหุนาม เราจะประเมินพหุนามเดียวกันที่จุดอื่นๆ ตอนนี้ 50% ของข้อมูลก็เพียงพอที่จะ กู้คืนข้อมูลทั้งหมด ด้วยโครงร่างนี้ คุณสามารถตรวจสอบได้ว่าบล็อกนั้นมีประโยชน์ และบล็อกนั้นพร้อมใช้งานในขนาดที่อาจใหญ่มาก ในขณะที่ดาวน์โหลดข้อมูลส่วนตัว 20-200 KB

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

พิสูจน์ความถูกต้อง ดังนั้นจะพิสูจน์ได้อย่างไรว่า root คือต้นตอของการเข้ารหัสการลบนี้ คุณจะพิสูจน์ได้อย่างไรว่าคุณไม่ได้รับข้อมูลขยะติดอยู่? คุณสามารถใช้หลักฐานการฉ้อโกงได้ เช่น แบบ 2 มิตินี้ และถ้าคุณเขียนโค้ดผิด จะมีคนสร้างหลักฐานการฉ้อโกงสั้นๆ และคุณสามารถเผยแพร่ไปยังเครือข่าย และเครือข่ายสามารถปฏิเสธการบล็อกได้ รูปแบบ 2 มิตินี้ได้รับการศึกษาในปี 2560 เมื่อเร็ว ๆ นี้มีบางอย่างเกี่ยวกับการเข้ารหัสต้นไม้ Merkle ซึ่งคุณเข้ารหัสแต่ละระดับในต้นไม้ Merkle ซึ่งมีคุณสมบัติที่ดี นอกจากนี้ยังมีวิธีการที่ไม่ต้องพึ่งพาการพิสูจน์การฉ้อโกง เช่น การใช้ STARK หรือ SNARK เพื่อพิสูจน์ว่าการคำนวณรากของ Merkle นั้นถูกต้อง ในขณะที่ความเป็นไปได้อื่นเกี่ยวข้องกับการผูกมัดพหุนาม คุณจะได้รับข้อมูลของคุณ และคุณจะตีความ เป็นการประเมินพหุนาม คุณจะคำนวณพหุนาม จากนั้นคุณจะทำการเปิดพหุนามที่คอมมิตกับพหุนามทั้งชุดที่จุดต่างๆ และการตรวจสอบความพร้อมใช้งานของข้อมูลของคุณจะขอตำแหน่ง 80 ตำแหน่งแทนที่จะเป็น 80 ช่องเปิด หรือ หากคุณใช้พีชคณิตที่ชาญฉลาดเพื่อรับการเปิดหลายทาง และคุณจะได้รับประสิทธิภาพมากยิ่งขึ้น

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

Sharding: Sharded blockchains ที่มีอยู่นอกเหนือจากคณะกรรมการมักจะขึ้นอยู่กับคณะกรรมการ แนวคิดก็คือคุณมีโหนดจำนวนมาก คุณสุ่มเลือกโหนดบางโหนด และคุณต้องการโหนดส่วนใหญ่หรือส่วนใหญ่ให้อยู่ในโซนใดโซนหนึ่ง การเซ็นบล็อกจึง ที่เครือข่ายยอมรับการบล็อกว่าถูกต้อง

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

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

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

การโจมตีที่นี่ค่อนข้างน่ารังเกียจ ผู้โจมตีแฮ็กเครื่องมือตรวจสอบความถูกต้องบางส่วนและทำให้พวกเขาโหวตบล็อกอื่น โดยใช้ตัวตรวจสอบความถูกต้องอื่น ๆ ลงคะแนนให้กับบล็อกของตนเองซึ่งมีเนื้อหาที่จะถูกเซ็นเซอร์จริง ๆ... แต่พวกเขาเองไม่มีคะแนนเสียงมากพอที่จะ ได้รับมากกว่า 51% ดังนั้นสิ่งที่พวกเขาพยายามเซ็นเซอร์จะไม่ถูกรวมเข้าด้วยกัน นี่เป็นผลกระทบทางอ้อมหลายชั้น ใน Ethereum 1.0 และ Ethereum 2.0 บุคคลที่ประสงค์ร้ายที่ทำการโจมตี 51% สามารถเซ็นเซอร์ได้ และเมื่อการเซ็นเซอร์แข็งแกร่งพอ ก็เป็นการยากที่จะตัดสินว่าจำเป็นต้องดำเนินการบางอย่างเกี่ยวกับเรื่องนี้หรือไม่

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

ดังนั้นคุณจึงมี blockchain ที่รวมบล็อกลุงไว้ด้วย

แนวคิด: Timeliness Detector (TD) ลองนึกภาพว่าอย่างน้อยเราอาจมีไคลเอ็นต์ออนไลน์ ไคลเอ็นต์บนเครือข่ายที่สามารถดาวน์โหลดสิ่งต่างๆ และสื่อสารกับไคลเอ็นต์อื่นๆ เป็นระยะๆ ให้พวกเขาตรวจสอบว่าบล็อกมาถึงตรงเวลาหรือไม่

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

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

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

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

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

ด้วยเหตุนี้ เราจึงต้องมีตัวตรวจจับความทันเวลา (TD) ที่ดีกว่านี้

Modified Timeliness Detector (TD) เราย้อนกลับไปที่ปัญหา Byzantine Generals ไปจนถึงบทความปี 1982 โดย Leslie Lamport ปรากฎว่ากระดาษมีอัลกอริทึมที่ผู้คนไม่ได้พูดถึง แต่พวกเขาน่าจะพูดถึงมากกว่านี้ มันซ่อนข้อความนี้อย่างเป็นนามธรรมด้วยข้อความเป็นลายลักษณ์อักษรที่ไม่สามารถเข้าใจได้ (เรียกว่าลายเซ็นดิจิทัล) แลมเบิร์ตอ้างว่าเขามีอัลกอริธึมที่สอดคล้องกันซึ่งสามารถทนต่อผู้โจมตีที่ผิดพลาดได้มากถึง 99% (เช่น 99% ที่ยอมรับความผิดพลาดของผู้โจมตี)

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

ฉันจะอธิบายเวอร์ชันผู้พิสูจน์คนเดียว ในที่นี้ สมมติว่าผู้พิสูจน์คนหนึ่งเป็นคนซื่อสัตย์ และมีผู้พิสูจน์ทั้งหมด n คน เราต้องการเพียง 1/n ของผู้พิสูจน์เท่านั้นที่จะซื่อสัตย์

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

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

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

ยิ่งไปกว่านั้น คุณสามารถตรวจจับห่วงโซ่การโจมตีและตรวจสอบการโจมตีได้โดยใช้ตัวตรวจจับความทันท่วงที

สี่ บทสรุป

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

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

เรามีเครื่องมือมากมายที่ลดความกลัวการโจมตีลงได้มากถึง 51% หรือสามารถเพิกเฉยหรือกู้คืนจากการโจมตีเหล่านั้นได้ ขอบคุณทุกคน.