การเปลี่ยนผ่านของ Ethereum ไปสู่การพิสูจน์การถือครอง (Proof of Stake) หรือ The Merge กำลังใกล้เข้ามาแล้ว: เครือข่ายนักพัฒนาซอฟต์แวร์กำลังถูกจัดตั้งขึ้น ข้อกำหนดต่างๆ กำลังถูกสรุป และการติดต่อสื่อสารในชุมชนได้เริ่มต้นขึ้นอย่างจริงจัง The Merge ได้รับการออกแบบมาให้มีผลกระทบน้อยที่สุดต่อการทำงานของ Ethereum สำหรับผู้ใช้ปลายทาง สัญญาอัจฉริยะ และ dapps อย่างไรก็ตาม มีการเปลี่ยนแปลงเล็กน้อยบางอย่างที่ควรเน้นย้ำ ก่อนที่เราจะเจาะลึกลงไป ต่อไปนี้คือลิงก์บางส่วนเพื่อให้บริบทเกี่ยวกับสถาปัตยกรรม Merge โดยรวม:
ส่วนที่เหลือของโพสต์นี้จะถือว่าผู้อ่านคุ้นเคยกับเนื้อหาข้างต้น สำหรับผู้ที่ต้องการเจาะลึกยิ่งขึ้น ข้อมูลจำเพาะฉบับเต็มของ The Merge สามารถดูได้ที่นี่:
โครงสร้างแบบบล็อค
หลังจากการรวมเข้าด้วยกัน บล็อกการพิสูจน์การทำงานจะไม่มีอยู่บนเครือข่ายอีกต่อไป เนื้อหาเดิมของบล็อกการพิสูจน์การทำงานจะกลายเป็นส่วนประกอบของบล็อกที่สร้างขึ้นบน Beacon Chain จากนั้นคุณสามารถคิดถึง Beacon Chain ว่าเป็นเลเยอร์ฉันทามติการพิสูจน์การเดิมพันใหม่ของ Ethereum ซึ่งเข้ามาแทนที่เลเยอร์ฉันทามติการพิสูจน์การทำงานก่อนหน้า บล็อก Beacon Chain จะประกอบด้วย การดำเนินการเพย์โหลดซึ่งเทียบเท่ากับบล็อกในห่วงโซ่การพิสูจน์การทำงานปัจจุบันหลังการผสาน รูปภาพด้านล่างแสดงความสัมพันธ์นี้:
สำหรับผู้ใช้ปลายทางและนักพัฒนาแอปพลิเคชันเหล่านี้ การดำเนินการเพย์โหลด เป็นที่ที่การโต้ตอบกับ Ethereum เกิดขึ้น ธุรกรรมในเลเยอร์นี้จะยังคงได้รับการประมวลผลโดยไคลเอนต์ของเลเยอร์การดำเนินการ (Besu, Erigon, Geth, Nethermind เป็นต้น) โชคดีที่เนื่องจากเลเยอร์การดำเนินการมีความเสถียร The Merge จึงนำการเปลี่ยนแปลงที่สำคัญเพียงเล็กน้อยมาใช้เท่านั้น
การขุดและทุ่ง Ommer Block
หลังการผสาน ฟิลด์หลายฟิลด์ที่เคยอยู่ในส่วนหัวของบล็อกการพิสูจน์การทำงานจะไม่ได้ใช้งาน เนื่องจากฟิลด์เหล่านี้ไม่เกี่ยวข้องกับการพิสูจน์การถือครอง เพื่อลดการหยุดชะงักของเครื่องมือและโครงสร้างพื้นฐาน ฟิลด์เหล่านี้จึงถูกตั้งค่าเป็น 0 หรือเทียบเท่ากับโครงสร้างข้อมูล แทนที่จะถูกลบออกจากโครงสร้างข้อมูลทั้งหมด การเปลี่ยนแปลงทั้งหมดของฟิลด์บล็อกสามารถพบได้ใน อีไอพี-3675–
สนาม | ค่าคงที่ | ความคิดเห็น |
---|---|---|
ออมเมอร์ส | – | RLP(()) = 0xc0 |
ออมเมอร์แฮช | 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 | = เคคค256(RLP(())) |
ความยากลำบาก | 0 | |
ครั้งเดียว | 0x0000000000000000 |
เนื่องจากหลักฐานการถือครองไม่ได้สร้างโอมเมอร์ (หรือที่เรียกว่าบล็อกลุง) เหมือนกับหลักฐานการทำงาน รายการเหล่านี้ในแต่ละบล็อก (ออมเมอร์ส) จะว่างเปล่า และแฮชของรายการนี้ (ออมเมอร์แฮช) จะกลายเป็นแฮชที่เข้ารหัส RLP ของรายการว่าง ในทำนองเดียวกัน เนื่องจาก ความยากลำบาก และ ครั้งเดียว เป็นคุณสมบัติของการพิสูจน์การทำงาน ซึ่งจะถูกกำหนดไว้ดังนี้ 0ขณะที่เคารพค่าขนาดไบต์ของพวกเขา
มิกซ์แฮชฟิลด์ที่เกี่ยวข้องกับการขุดอีกฟิลด์หนึ่งจะไม่ถูกตั้งค่าเป็น 0 แต่จะมีค่า RANDAO ของบีคอนเชนแทน อ่านรายละเอียดเพิ่มเติมด้านล่าง
บล็อคแฮช – ความยากลำบาก การเปลี่ยนแปลงโอปโค้ด
หลังการรวมกัน บล็อคแฮช โอปโค้ดจะยังคงพร้อมให้ใช้งาน แต่เนื่องจากจะไม่มีการปลอมแปลงผ่านกระบวนการแฮชพิสูจน์การทำงานอีกต่อไป ความสุ่มเทียมที่โอปโค้ดให้มาจึงจะอ่อนแอลงมาก
ที่เกี่ยวข้องกัน ความยากลำบาก โอปโค้ด (0x44) จะได้รับการอัพเดตและเปลี่ยนชื่อเป็น พรีวรันดาวหลังจากผสานแล้ว ระบบจะส่งคืนผลลัพธ์ของบีคอนสุ่มที่จัดเตรียมโดยเชนบีคอน ดังนั้น โอปโค้ดนี้จึงเป็นแหล่งสุ่มที่แข็งแกร่งกว่า แม้ว่าจะยังมีความลำเอียงได้ก็ตาม สำหรับให้นักพัฒนาแอปพลิเคชันใช้มากกว่า บล็อคแฮช–
มูลค่าที่ถูกเปิดเผยโดย พรีวรันดาว จะถูกเก็บไว้ใน การดำเนินการเพย์โหลด ที่ไหน มิกซ์แฮชค่าที่เกี่ยวข้องกับการคำนวณหลักฐานการทำงานถูกเก็บไว้ โหลดของ มิกซ์แฮช สนามจะถูกเปลี่ยนชื่อด้วย ก่อนหน้าRandao–
นี่คือตัวอย่างที่แสดงให้เห็นว่า ความยากลำบาก – พรีวรันดาว โอปโค้ดทำงานก่อนและหลังการผสาน:
ก่อนการผสาน เราจะเห็น 0x44 Opcode ส่งคืน ความยากลำบาก ฟิลด์ในส่วนหัวของบล็อก หลังจากผสาน โอปโค้ด เปลี่ยนชื่อเป็น พรีวรันดาวชี้ไปที่ฟิลด์ส่วนหัวที่มีอยู่ก่อนหน้านี้ มิกซ์แฮช และตอนนี้เก็บเอาไว้ ก่อนหน้าRandao ค่าจากสถานะของบีคอนเชน
การเปลี่ยนแปลงนี้เป็นทางการใน EIP-4399ยังให้แอปพลิเคชันแบบออนเชนสามารถประเมินได้ว่าการผสานเกิดขึ้นหรือไม่ จาก EIP:
นอกจากนี้ การเปลี่ยนแปลงที่ EIP เสนอนี้ช่วยให้สัญญาอัจฉริยะสามารถระบุได้ว่าการอัปเกรดเป็น PoS เกิดขึ้นแล้วหรือไม่ ซึ่งสามารถทำได้โดยวิเคราะห์ค่าส่งคืนของ ความยากลำบาก โอปโค้ด ค่าที่มากกว่า 2**64 ระบุว่าธุรกรรมกำลังถูกดำเนินการอยู่ในบล็อค PoS
บล็อคเวลา
การผสานจะมีผลกระทบต่อเวลาบล็อกเฉลี่ยบน Ethereum ในปัจจุบันภายใต้การพิสูจน์การทำงาน บล็อกจะเข้ามาโดยเฉลี่ยทุกๆ ~13 วินาที โดยมีความคลาดเคลื่อนพอสมควรในเวลาบล็อกจริง ภายใต้การพิสูจน์การเดิมพัน บล็อกจะเข้ามาทุกๆ 12 วินาทีพอดี ยกเว้นเมื่อสล็อตหายไปเนื่องจากผู้ตรวจสอบออฟไลน์หรือเนื่องจากไม่ได้ส่งบล็อกตรงเวลา ในทางปฏิบัติ ปัจจุบันสิ่งนี้เกิดขึ้นในสล็อตน้อยกว่า 1%
นั่นหมายความว่าเวลาบล็อกเฉลี่ยบนเครือข่ายจะลดลงประมาณ 1 วินาที สัญญาอัจฉริยะที่ถือว่าเวลาบล็อกเฉลี่ยในการคำนวณจะต้องคำนึงถึงเรื่องนี้ด้วย
บล็อคสำเร็จรูป & หัวเซฟ
ภายใต้การพิสูจน์การทำงานนั้น มักจะมีความเป็นไปได้ที่จะมีการจัดระเบียบใหม่ แอปพลิเคชันมักจะรอให้มีการขุดบล็อกหลายบล็อกบนหัวใหม่ก่อนที่จะถือว่าไม่น่าจะถูกลบออกจากห่วงโซ่หลัก หรือ “ได้รับการยืนยัน” หลังจากการรวมเข้าด้วยกัน เรามีแนวคิดดังนี้ เสร็จสิ้น บล็อคและ หัวปลอดภัย เปิดเผยบนเลเยอร์การดำเนินการ บล็อกเหล่านี้สามารถใช้งานได้อย่างน่าเชื่อถือมากกว่าบล็อกพิสูจน์การทำงานที่ “ได้รับการยืนยัน” แต่ต้องมีการเปลี่ยนแปลงความเข้าใจเพื่อใช้งานอย่างถูกต้อง
บล็อกที่เสร็จสมบูรณ์คือบล็อกที่ได้รับการยอมรับว่าเป็นมาตรฐานโดยผู้ตรวจสอบมากกว่า 2/3 หากต้องการสร้างบล็อกที่ขัดแย้งกัน ผู้โจมตีจะต้องเผาอย่างน้อย 1/3 ของอีเธอร์ที่เดิมพันทั้งหมด แม้ว่าจำนวนเดิมพันอาจแตกต่างกันไป แต่การโจมตีดังกล่าวคาดว่าจะทำให้ผู้โจมตีสูญเสีย ETH เป็นจำนวนหลายล้านเสมอ
เอ หัวปลอดภัย บล็อคคือบล็อคหนึ่งที่ได้มี มีเหตุผล โดย Beacon Chain ซึ่งหมายความว่าผู้ตรวจสอบมากกว่า 2 ใน 3 รายรับรองแล้ว ภายใต้เงื่อนไขเครือข่ายปกติ เราคาดหวังว่าจะรวมอยู่ในเครือข่ายมาตรฐานและจะเสร็จสมบูรณ์ในที่สุด หากบล็อกนี้ไม่ได้เป็นส่วนหนึ่งของเครือข่ายมาตรฐาน ผู้ตรวจสอบส่วนใหญ่จะต้องร่วมมือกันโจมตีเครือข่าย มิฉะนั้น เครือข่ายจะต้องประสบกับความล่าช้าในระดับสูงสุดในการแพร่กระจายบล็อก หลังจากการรวม API ของชั้นการดำเนินการ (เช่น JSON RPC) จะเปิดเผย หัวปลอดภัย การใช้ ปลอดภัย แท็ก
บล็อกที่เสร็จสมบูรณ์จะถูกเปิดเผยผ่าน JSON RPC ผ่านใหม่ เสร็จสิ้น ธง สิ่งเหล่านี้สามารถใช้แทนการยืนยันหลักฐานการทำงานได้ดีกว่า ตารางด้านล่างนี้สรุปข้อมูลดังต่อไปนี้:
ประเภทบล็อค | กลไกการบรรลุฉันทามติ | เจสันอาร์พีซี | เงื่อนไขการจัดระเบียบใหม่ |
---|---|---|---|
ศีรษะ | หลักฐานการทำงาน | ล่าสุด | จะคาดหวังได้ต้องใช้ด้วยความระมัดระวัง |
หัวปลอดภัย | หลักฐานการเดิมพัน | ปลอดภัย | เป็นไปได้ ต้องใช้การล่าช้าของเครือข่ายขนาดใหญ่หรือการโจมตีเครือข่าย |
ได้รับการยืนยัน | หลักฐานการทำงาน | ไม่มีข้อมูล | ไม่น่าจะเป็นไปได้ ต้องใช้อัตราแฮชส่วนใหญ่ในการขุดโซ่เชิงลึกที่แข่งขันกัน > # ของการยืนยัน |
เสร็จสิ้น | หลักฐานการเดิมพัน | เสร็จสิ้น | ไม่น่าจะเป็นไปได้อย่างยิ่ง ต้องใช้ผู้ตรวจสอบมากกว่า 2/3 จึงจะสรุปเชนที่แข่งขันได้ โดยต้องตัดออกอย่างน้อย 1/3 |
หมายเหตุ: ข้อกำหนด JSON RPC ยังอยู่ระหว่างการพัฒนาอย่างต่อเนื่อง การเปลี่ยนแปลงการตั้งชื่อยังคงเป็นสิ่งที่ควรคาดหวัง
ขั้นตอนต่อไป
เราหวังว่าโพสต์นี้จะช่วยให้นักพัฒนาแอปพลิเคชันเตรียมพร้อมสำหรับการเปลี่ยนผ่านไปสู่ระบบ Proof of Stake ที่ทุกคนรอคอยมานาน ในอีกไม่กี่สัปดาห์ข้างหน้า เครือข่ายทดสอบระยะยาวจะพร้อมให้ชุมชนในวงกว้างได้ทดสอบ นอกจากนี้ ยังมีการทดสอบที่กำลังจะมีขึ้นในเร็วๆ นี้ รวมการโทรชุมชน สำหรับนักพัฒนาโครงสร้างพื้นฐาน เครื่องมือ และแอปพลิเคชันเพื่อถามคำถามและรับฟังข้อมูลอัปเดตทางเทคนิคล่าสุดเกี่ยวกับ The Merge พบกันที่นั่น 👋🏻
ขอขอบคุณ Mikhail Kalinin, Danny Ryan และ Matt Garnett สำหรับการตรวจทานฉบับร่างของโพสต์นี้