พลิกสถานการณ์: สถานการณ์ของ Ethereum

ที่มา | บล็อก Ethereum

ที่มา | บล็อก Ethereum

จุดประสงค์ของบล็อกโพสต์นี้คือเพื่อเปิดเผยปัญหาร้ายแรงและชัดเจนอย่างเป็นทางการกับแพลตฟอร์ม Ethereum ก่อนการ Hard Fork ของเบอร์ลิน

จุดประสงค์ของบล็อกโพสต์นี้คือเพื่อเปิดเผยปัญหาร้ายแรงและชัดเจนอย่างเป็นทางการกับแพลตฟอร์ม Ethereum ก่อนการ Hard Fork ของเบอร์ลิน

ชื่อเรื่องรอง

สถานะ

เริ่มจากพื้นหลังของ Ethereum และ "สถานะ" ของมันกันก่อน

สถานะของ Ethereum ประกอบด้วย patricia-merkle trie ซึ่งเป็นต้นไม้คำนำหน้าประเภทหนึ่ง บทความนี้จะไม่ลงรายละเอียดทางเทคนิค พูดง่ายๆ ก็คือ เมื่อต้นไม้โตขึ้นกิ่งก้านของต้นไม้จะหนาแน่นขึ้นและหนาแน่นขึ้น แต่ละบัญชีที่เข้าร่วมเป็นใบใหม่ ระหว่างรากของต้นไม้และระหว่างใบมีโหนด "กลาง" จำนวนมาก

ในการค้นหาบัญชีเฉพาะหรือ "ใบไม้" ในต้นไม้ยักษ์นี้ จากรากของต้นไม้และผ่านโหนดระดับกลาง จำเป็นต้องแก้ไขแฮช 6-9 แฮชเพื่อแฮชข้อมูลที่เราต้องการคำนวณในที่สุด .

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

เนื่องจาก Ethereum เติบโตขึ้น จึงจำเป็นต้องเพิ่มต้นทุนการดำเนินการเข้าถึงต้นไม้อยู่เสมอ ในเดือนตุลาคม 2559 หลังจากประสบกับเหตุการณ์ "Shanghai Attack" เครือข่าย Ethereum ได้ทำการ hard fork ของ Tangerine Whistle ที่ความสูงของบล็อก 2,463,000 ซึ่งรวมถึง EIP 150 ซึ่งเพิ่มต้นทุนก๊าซของการดำเนินการบางอย่างอย่างมาก และแนะนำการเปลี่ยนแปลงจำนวนมากเพื่อป้องกัน ต่อต้านการโจมตี DoS

ค่าธรรมเนียมน้ำมันที่เพิ่มขึ้นอีกครั้งคือการอัปเกรดอิสตันบูลในเดือนธันวาคม 2019 ซึ่งเปิดใช้งาน EIP 1884

EIP-1884 แนะนำการเปลี่ยนแปลงค่าธรรมเนียมก๊าซดังต่อไปนี้:

➤SLOAD เพิ่มจาก 200 เป็น 800 แก๊ส

➤EXTCODEHASH เพิ่มจาก 400 เป็น 700 แก๊ส

ชื่อเรื่องรอง

ปัญหา

ในเดือนมีนาคม 2019 Martin Swende กำลังทำการวัดประสิทธิภาพของ EVM opcode EIP-1884 ที่ตามมาขึ้นอยู่กับการสืบสวนนี้ Broken Meter เผยแพร่เอกสารนี้ (2019/9) ไม่กี่เดือนก่อนที่จะเปิดใช้งาน EIP-1884

นักวิจัยด้านความปลอดภัยของ ethereum สองคน Hubert Ritzdorf และ Matthias Egli และหนึ่งในผู้เขียนรายงาน Daniel Perez ได้ "สร้างอาวุธ" ช่องโหว่และส่งไปยังโปรแกรมรางวัลบั๊กของ ethereum คือวันที่ 4 ตุลาคม 2562

ขอแนะนำให้ทุกคนอ่านเอกสารฉบับเต็มที่พวกเขาส่งมาซึ่งมีรายละเอียดมาก

ในวันเดียวกัน นักพัฒนาจาก Geth, Parity และ Aleth ได้เรียนรู้เกี่ยวกับเอกสารในช่องทางที่จัดทำขึ้นเพื่อการรักษาความปลอดภัยข้ามไคลเอนต์โดยเฉพาะ

สาระสำคัญของช่องโหว่นี้คือการเรียกใช้การสืบค้นแบบสุ่ม นี่คือตัวอย่างง่ายๆ:

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

• Parity: ~90s

• Geth: ~70s

➤ EXTCODEHASH (400 แก๊ส) ที่ใช้ 10 ล้านแก๊ส

• Parity : ~50s

• Geth : ~38s

➤ EXTCODEHASH (700 แก๊ส) ที่ใช้ 10 ล้านแก๊ส

เห็นได้ชัดว่าการเปลี่ยนแปลงใน EIP-1884 ช่วยลดผลกระทบจากการโจมตีครั้งนี้ แต่ยังไม่เพียงพอ

ใกล้จะถึงงานประชุมนักพัฒนาที่โอซาก้าแล้ว ในการประชุมนักพัฒนา มีการแชร์ข้อมูลเกี่ยวกับปัญหานี้กับนักพัฒนาไคลเอนต์บน mainnet เรายังได้พบกับ Hubert, Mathias และ Greg Markou (จาก Chainsafe ซึ่งทำงานเกี่ยวกับ ETC อยู่ในขณะนั้นด้วย) ผู้พัฒนา ETC ก็ได้รับรายงานนี้เช่นกัน

เมื่อปี 2019 ใกล้เข้ามา เราทราบดีว่าปัญหาเลวร้ายกว่าที่คาดการณ์ไว้ก่อนหน้านี้ เนื่องจากธุรกรรมที่เป็นอันตรายอาจผลักเวลาในการบล็อกให้อยู่ในช่วงนาที ยิ่งไปกว่านั้น ชุมชนนักพัฒนาไม่พอใจกับ EIP-1884 เนื่องจาก EIP-1884 ทำลายกระบวนการสัญญาบางอย่าง และผู้ใช้และผู้ขุดเหมืองต่างกระตือรือร้นที่จะเพิ่มขีดจำกัดก๊าซของบล็อก

ชื่อเรื่องรอง

สารละลาย

สารละลาย

วิธีที่สองคือการแก้ไขผ่านวิศวกรรมซอฟต์แวร์ การปรับเปลี่ยนโมเดลข้อมูลและโครงสร้างในไคลเอนต์

ชื่อเรื่องรอง

การทำงานของโปรโตคอลเลเยอร์

การเปิดตัวครั้งแรกเกี่ยวกับวิธีจัดการกับการโจมตีประเภทนี้อยู่ที่นี่ ในเดือนกุมภาพันธ์ 2020 ได้เปิดตัวอย่างเป็นทางการในชื่อ EIP 2583 แนวคิดคือการกำหนดบทลงโทษเมื่อใดก็ตามที่การค้นหาแบบ trie ส่งผลให้เกิดการพลาด

อย่างไรก็ตาม ปีเตอร์พบมาตรการตอบโต้ การโจมตีแบบ "รีเลย์ป้องกัน" ซึ่งจำกัดขอบเขตสูงสุดของบทลงโทษนี้ได้อย่างมีประสิทธิภาพ (ประมาณ 800)

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

ด้วยเหตุนี้ EIP นี้จึงถูกละทิ้งและเรากำลังมองหาทางเลือกอื่นที่ดีกว่า

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

➤ Martin ยังได้เขียนข้อเสนอที่คล้ายกันในเดือนพฤษภาคม 2020 (Gas And Karma)

ในขณะที่ทำซ้ำในกลไกต่างๆ เหล่านี้ Vitalik Buterin เสนอให้เพิ่มต้นทุนก๊าซโดยตรงและเก็บรายการการเข้าถึงไว้ ในเดือนสิงหาคม 2020 Martin และ Vitalik ได้เริ่มปรับปรุง EIP-2929 และ EIP-2930 ซึ่งเป็นเพื่อนร่วมทาง

EIP-2929 แก้ปัญหาก่อนหน้านี้ได้อย่างมีประสิทธิภาพ

➤ เมื่อเทียบกับ EIP-1884 ซึ่งเพิ่มต้นทุนก๊าซอย่างไม่มีเงื่อนไข EIP-2929 จะเพิ่มต้นทุนก๊าซในส่วนที่ไม่ได้เยี่ยมชมเท่านั้น ส่งผลให้ต้นทุนสุทธิเพิ่มขึ้นน้อยกว่าจุดเปอร์เซ็นต์

➤ ด้วยการเพิ่ม EIP-2930 จะไม่มีการหยุดชะงักของกระบวนการสัญญาใดๆ

ในวันที่ 15 เมษายน 2021 EIP ทั้งสองเปิดใช้งานในการอัปเกรดเบอร์ลิน

ชื่อเรื่องรอง

งานพัฒนา

วิธีแก้ปัญหาที่ Peter เสนอในเดือนตุลาคม 2019 คือ "ภาพรวมสถานะแบบไดนามิก"

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

➤ แทนที่จะอ่านดิสก์ O(log N) (x โอเวอร์เฮดของ LevelDB) เพื่อเข้าถึงบัญชีหรือสล็อตที่เก็บข้อมูล สแน็ปช็อตสามารถให้เวลาในการเข้าถึง O(1) โดยตรง (x โอเวอร์เฮดของ LevelDB)

➤ สแนปชอตรองรับการทำซ้ำในบัญชีและพื้นที่เก็บข้อมูลที่มีความซับซ้อน O(1) ต่อรายการ ซึ่งช่วยให้โหนดระยะไกลสามารถดึงข้อมูลสถานะตามลำดับได้ถูกกว่าเมื่อก่อนมาก

➤ สแนปชอตยังเปิดใช้งานกรณีการใช้งานที่แปลกใหม่ เช่น สถานะการตัดแต่งกิ่ง การพยายามออฟไลน์หรือการโยกย้ายไปยังรูปแบบข้อมูลอื่น

ข้อเสียของสแนปชอตคือบัญชีเดิมและข้อมูลพื้นที่เก็บข้อมูลจะถูกทำซ้ำอย่างมีประสิทธิภาพ สำหรับ mainnet นี่หมายถึงพื้นที่ SSD เพิ่มเติมอีก 25GB

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

➤ ตัดแบบออฟไลน์

➤ การซิงโครไนซ์สแน็ปช็อตแบบไดนามิก + สแน็ปช็อต

➤ ตระหนักถึงการกระจายสถานะ LES (Light Ethereum Subprotocol) ผ่านสถานะการแบ่งส่วน

ชื่อเรื่องรอง

สรุป

สรุป

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

ในแง่ของข้อตกลง การอัปเกรดเบอร์ลินจะเสร็จสิ้นในเดือนเมษายน 2564

ต่อไปนี้คือเกณฑ์มาตรฐานบางส่วนที่พัฒนาขึ้นในสภาพแวดล้อมการตรวจสอบ AWS ของเรา:

➤ ก่อนการอัปเกรดเบอร์ลิน ไม่มีสแนปช็อต ก๊าซ 25M: 14.3 วินาที

➤ ก่อนการอัปเกรดเบอร์ลิน มีภาพรวม ก๊าซ 25M: 1.5 วินาที

➤ หลังจากการอัปเกรดเบอร์ลิน ไม่มีสแน็ปช็อต ก๊าซ 25M: ~3.1 วินาที

➤ หลังจากการอัปเกรดเบอร์ลิน ด้วยสแนปชอต ก๊าซ 25M: ~0.3 วินาที

ตัวเลขคร่าวๆ แสดงให้เห็นว่าการอัปเกรด Perlin สามารถลดประสิทธิภาพของการโจมตีได้ 5 เท่า และสแนปช็อตได้ 10 เท่า เพื่อลดผลกระทบโดยรวมได้ 50 เท่า

เราประเมินว่าขณะนี้อยู่บน mainnet (ก๊าซ 15M) สำหรับโหนด geth ที่ไม่ใช้สแน็ปช็อต สามารถสร้างบล็อกด้วยเวลาดำเนินการ 2.5-3 วินาที สำหรับโหนดที่ไม่ใช่สแน็ปช็อต ตัวเลขนี้จะยิ่งแย่ลงเรื่อยๆ เมื่อสถานะเติบโตขึ้น

สำหรับความเป็นไปได้ในการดำเนินการโจมตีนี้ ค่าใช้จ่ายสำหรับผู้โจมตีในการซื้อบล็อกทั้งหมดนั้นอยู่ที่ประมาณไม่กี่ ETH (ก๊าซ 15 ล้านคือ 1.5 ETH สำหรับ 100 Gwei)

ชื่อเรื่องรอง

ทำไมต้องเผยแพร่ตอนนี้?

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

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

บทความนี้เขียนโดย Martin Holst Swende และ Peter Szilagyi เมื่อวันที่ 23-04-2021 จะมีการแชร์กับโครงการที่ใช้ Ethereum ในวันที่ 26-04-2021 และเผยแพร่สู่สาธารณะในวันที่ 2021-05-18

ลิงค์ต้นฉบับ:https://blog.ethereum.org/2021/05/18/eth_state_problems/